这个十一过得不太平了，幸亏没安排什么活动，不然就扫兴了。前天下班时，全部check了一遍，没想到还是出问题了。

某个系统表，报空间满，不能insert记录了，相关操作hang在那，但查下系统表空间，是还有空间的。难道有设这个表在系统表空间的配额?查了DBA_TS_QUOTAS表，没找到，奇怪。只有转储先解决问题了。

数据库系统alert一直在报如下错误：
Errors in file /appprod/proddb/9.2.0/admin/PROD_oracleerp/udump/prod_j000_13722.trc:
ORA-07445: exception encountered: core dump [00000001009E10C4] [SIGSEGV] [Address not mapped to object] [0x000000000] [] []
查看跟踪文件发现是一job引起，看job what内容，应该也没问题的。在metalink select了一番，也没找到匹配文档，baidu,google发现，可能把job参数置为0，然后再置回来有效果。就先这样做了，后面看看效果。
今早用户打电话过来，说某个应用有问题。check一下，服务器空间满了，一晚上生产了60多G的core,晕！
估计这种情况，重启可能有效果，要申请，太麻烦。看job what程序，发现此job可能是作报表汇总用的，影响不大。只能先停用了，后续观察停用此job，系统正常。

这个问题，咱也没太多办法，提交给Oracle Support了。依照Oracle GBS正常流程，先不说问题能不能解决，就看这速度和需要反馈的内容，这个假期是有得忙了！

借用manager的一句话，Oracle就是一个Bug居多的软件集合。有啥办法呢（就算你工作做得再到位，软件本身不靠谱，层出不穷的Bug,也总是有问题的），谁叫咱吃这碗饭的！

这次貌似Oracle GBS速度蛮快的，没几个回合问题就解决了，确定为Bug 4098853 ，解决方案如下：
Set event 10122
OR query_rewrite_enabled=TRUE
OR Patching