利用ASH功能定位处理产生core文件超大问题

一．问题描述

  最近大半年，每隔一段时间就会出现数据库主机的ORACLE程序所在的文件系统空间突然全部用完，如ORACLE程序所在的文件系统为/appdb，可用空间有52G，在一到两分钟内，被生成在$ORACLE_HOME/dbs下的core文件用完，可用空间变为0，即core文件大小为52G，由于发现及时对文件进行了删除，所以前面出现多次对数据库运行没有太大影响。

 

二．问题分析

  昨天下午又出现了一次同样问题，今天通过oracle的ASH功能进行定位，发现在已发生问题时间段，会话7903一直出现pin
S wait on X等待事件，并定位到该会话的SQL，如后面所示SQL超长，条件in列表中的值无穷多个，不像是人为写的，似乎系统中类似SQL还有不少，仔细检查该SQL，怀疑与产生超大core文件有关系，如是在测试环境尝试运行该SQL，SQL在解析时很慢，解析无法完成，同时查看测试环境的$ORACLE_HOME/dbs下居然也产生了同样的core文件，Core文件大小不停在增加，所以通过测试完全验证刚开始的猜测：附件SQL与core文件超大(52G)有直接必然联系。

 

Sql如下：
SELECT …. FROM item where itemid IN(-1111051624,-1110889444,-1110443207,-1103164429,-1102966416,-1102616121,-1102504537,-1102477123,-1102398464,-1102377118,-1102375090,-1102366719,-1102261817,-1102261812,-1102240708,-1102227400,-1102208068,-1102207595,-1102139070,-1102076980,-1102064239,-1102063966,-1102063964,-1102063961,-1102063959,-1102063710,-1101635612,-1101629924,-1101629917,-1101629830,-1101629448,-1101629445,-1101629360,-1101629349,-1101629346,-1101431588,-1101431587,-1101431586,-1101305078,-1101294963,-1101294962,-1101276944,-1101276895,-1101208724,-1101208645,-1101208620,-1101206697,-1101205565,-1101205541,-1100597016,-1100590408,-1100560622,-1100555027,-1100531528,-1100508093,-1100505666,-1100504281,-2039717,-2039093,-2006291,-2005252,-1987709,-1987697,-1924392,-1706316,-1670094,-1630105,-1630028,-1629987,-1629823,-1629736,-1629706,-1629358,-1289485,-1282174,-1210613,-1209709,-1209705,-1209704,-1209701,-1209699,-1209694,-1209693,-1209690,-1209689,-1209679,-1209678,-1209676,-1209578,-1209520,-1209350,-1209337,-1209315,-1209234,-1209233,-1209218,-1209043,-1209041,-1209031,-1209030,-1209020,-1209012,-1208861,-1208857,-1208850,-1208848,-1208847,-1208735,-1208723,-1208713,-1208660,-1208659,-1208658,-1208657,-1208654,-1208653,-1208651,-1208650,-1208644,-1208625,-1208611,-1208610,-1208343,-1206483,-1205765,-1205697,-1205501,-1205362,-1205349,-1205348,-1205092,-1204983,-591779,-577047,-577046,-575509,-565813,-562145,-557507,-557029,-556020,-554113,-527709,-518350,-518349,-518348,-518347,-516871,-514384,-513561,-513092,-512691,-512243,-512232,-511411,-511017,-510050,-509778,-509777,-509251,-509248,-509017,-506828,-506518,-506103,-505896,-505892,-504349,-504279,1100501818,1100501996,1100501997,1100501998,1100501999,1100502000,1100502001,1100502002,1100502003,1100502004,1100502005,1100502006,1100502007,1100502008,1100502009,1100502010,1100502011,1100502012,1100502013,1100502014,1100502015,1100502016,1100502017,1100502018,1100502019,1100502020,1100502021,1100502022,1100502023,1100502024,1100502025,1100502026,1100502027,1100502028,1100502029,1100502030,1100502031,1100502032,1100502033,1100502034,1100502035,1100502036,1100502037,1100502038,1100502039,1100502040,1100502041,1100502042,1100502043,1100502044,1100502045,1100502046,1100502047,1100502048,1100502049,1100502050,1100502051,1100502052,1100502053,1100502054,1100502055,1100502056,1100502057,1100502058,1100502059,1100502060,1100502061,1100502062,1100502063,1100502064,1100502065,1100502066,1100502067,1100502068,1100502069,1100502070,…………………………..
 无数个in list值。
 
三．问题解决
 
将上面SQL发给开发人员检查业务逻辑，重写SQL，跟踪一段时间后，问题不再出现。