一次'诡异'的执行SQL报错ORA-03113的问题处理

银行某系统存储过程报错，重新调起仍报错，而前几天这个一直正常。通过应用日志定位到报错信息，

ORA-03113: 通信通道的文件结尾
进程 ID: 36503726
会话 ID: 586 序列号: 65345

遇到这种错误，习惯性在网上找答案。然而网上那些关于这个经典错误的经典案例无一能和我的错误匹配

这时候我会习惯性的"看看SQL"

从存储过程里面定位到这个导致报错的SQL，单独拿出来跑，报错！！SQL语句如下：

SELECT *FROM (SELECT ROW_NUMBER() OVER(ORDER BY 1) AS RN, BUSINESS_QUERY.*FROM (select distinct t.*,t7.org_id as grant_user_id,t6.user_name,t2.grant_user,t4.cust_zh_name,t5.name,t2.grant_name,t2.grant_date,t2.grant_type,t2.grant_start_date,t2.grant_end_datefrom tttttttttttt1 tleft join tttttttttttt2 t2on t.grant_id = t2.idleft join scrm.tttttttttttt4 t4on t.cust_id = t4.cust_idleft join tttttttttttt6 t6on t2.grant_user = t6.account_nameleft join tttttttttttt5 t5on t5.emp_id = t.emp_idleft join tttttttttttt7 t7on t7.account_name = t2.grant_userwhere t.id in (select max(t1.id)from tttttttttttt1 t1group by t1.cust_id, t1.emp_id)and t2.grant_end_date >=to_date('2018-10-12', 'YYYY-mm-dd')and t2.grant_type = '1'and t7.org_id IN(SELECT UNITIDFROM SYS_UNITSWHERE UNITSEQ LIKE'%' || (SELECT UNITSEQFROM SYS_UNITSWHERE UNITID = 'B9999'))and t4.data_dt in( select crm_dt-1  from tttttttttttt9 )order by t.grant_id    desc,t2.grant_date desc,t2.grant_name desc) BUSINESS_QUERYwhere rownum <= 100) SUB_QUERYWHERE RN >= 1

这个SQL看起来平平无奇，如果单通过这个SQL想去定位问题，非常难！但是系统负责人那边还有个信息

"这个SQL之前一直没有出问题，前几天一切正常！"

如果是往常，我会看一下SQL的执行计划，因为执行计划“突变”，这类问题解决过太多次。而针对这个我觉得没有看执行计划的必要，因为ORA-03113不算“性能”类的错误，我坚信执行计划那里获取不到有用的信息，那么，下一步该怎么走

-----------------------------------------------------------一起思考一下-----------------------------------------------------------

-----------------------------------------------------------再往下想一点-----------------------------------------------------------

既然是前几天没有报错。。我们抓住了救命稻草：看SQL中的时间列，时间列，时间过滤列

SQL中的时间过滤列就两个

and t2.grant_end_date >= to_date('2018-10-12', 'YYYY-mm-dd')

and t4.data_dt in( select crm_dt-1 from o_pub_project_draw )

代入昨天的时间果然SQL正常~~~

下面的诊断方法，简单粗暴高效-------注释掉t2和t4所在的部分再跑SQL看看会不会报错

我这里先查一下T2和T4表大小以往的经验告诉我，大表出问题的概率一般比较大

tttttttttttt4 t4是一张视图，里面就一张基表 AAAAAAAAAA_SUM .表信息如下：

SQL> select segment_name,sum(bytes/1024/1024/1024)as GB from dba_segments where segment_name in('AAAAAAAAAA_SUM','TTTTTTTTTTT2') GROUP BY segment_name;

SEGMENT_NAME GB
-------------------------------------------------------------------------------- -----------------------
AAAAAAAAAA_SUM 60.9638671
TTTTTTTTTTT2 0.0001264

我们这里注释点t4部分 ,SQL无报错！

这里我们定位到T4表出了问题.........

我们先排查一下表上面有没有约束，主外键？ pass掉

剩下的排查方向就是两个：表有问题，表上面索引有问题

因为是分区表，我习惯性先排查global索引(解决过太多global索引失效的问题)，查看索引状态

SQL> SELECT INDEX_NAME,TABLE_NAME,TABLESPACE_NAME,BLEVEL,LEAF_BLOCKS,STATUS,LAST_ANALYZED,DEGREE,PARTITIONED FROM DBA_INDEXES WHERE TABLE_NAME IN('A_M_C_CUST_BASE_SUM','A_M_C_CUST_BASE_SUM_1010');INDEX_NAME                     TABLE_NAME                     TABLESPACE_NAME                    BLEVEL LEAF_BLOCKS STATUS   LAST_ANALYZED DEGREE                                   PARTITIONED
------------------------------ ------------------------------ ------------------------------ ---------- ----------- -------- ------------- ---------------------------------------- -----------
IDX_AAAAAAAAAA_SUM_NO            AAAAAAAAAA_SUM                                                    2      865562 N/A      2018/9/29 17: 16                                       YES
IDX_AAAAAAAAAA_SUM_02            AAAAAAAAAA_SUM            XXXXXXXXXXXX                          3     1915940 VALID    2018/10/10 15 1                                        NO
IDX_AAAAAAAAAA_SUM_ID            AAAAAAAAAA_SUM            XXXXXXXXXXXX                         3      984802 VALID    2018/10/11 14 4                                        NO

global索引没有问题~~~~~

排查表的问题没什么特别好的方法，使用cts（create table as）重建一张一模一样的表AAAAAAAAAA_SUM_1010

开整之前我还怀疑cts语句执行会不会报错。结果~没事。而且把表AAAAAAAAAA_SUM_1010代入到原SQL语句中，SQL完美执行，没有报错！！表确实有问题，但是CTS为何没有报错？（我当时排查的时候一直往表坏块的方向走）

正绝望中，看到了上面排查索引的结果：

STATUS LAST_ANALYZED DEGREE PARTITIONED
-------- ------------- ------- -----------
N/A 2018/9/29 17 16 YES
VALID 2018/10/10 15 1 NO
VALID 2018/10/11 14 4 NO
分区索引会不会失效？

select distinct status from dba_ind_partitions where index_name in ('IDX_AAAAAAAAAA_SUM_NO') status
----------
UNUSABLE
VALID顺便查一下又哪些索引失效
select 'alter index CCCC.IDX_AAAAAAAAAA_SUM_NO rebuild partition '||partition_name||' parallel 8;' from dba_ind_partitions where index_name in ('IDX_A_M_C_CUST_BASE_CUST_NO') and status='UNUSABLE';alter index CCCC.IDX_AAAAAAAAAA_SUM_NO rebuild partition P_20180829 parallel 8;
alter index CCCC.IDX_AAAAAAAAAA_SUM_NO rebuild partition P_20180830 parallel 8;
alter index CCCC.IDX_AAAAAAAAAA_SUM_NO rebuild partition P_20180831 parallel 8;
alter index CCCC.IDX_AAAAAAAAAA_SUM_NO rebuild partition P_20180901 parallel 8;
alter index CCCC.IDX_AAAAAAAAAA_SUM_NO rebuild partition P_20180902 parallel 8;
alter index CCCC.IDX_AAAAAAAAAA_SUM_NO rebuild partition P_20180903 parallel 8;
alter index CCCC.IDX_AAAAAAAAAA_SUM_NO rebuild partition P_20180904 parallel 8;
alter index CCCC.IDX_AAAAAAAAAA_SUM_NO rebuild partition P_20180905 parallel 8;
alter index CCCC.IDX_AAAAAAAAAA_SUM_NO rebuild partition P_20180906 parallel 8;
alter index CCCC.IDX_AAAAAAAAAA_SUM_NO rebuild partition P_20180908 parallel 8;
alter index CCCC.IDX_AAAAAAAAAA_SUM_NO rebuild partition P_20180909 parallel 8;
alter index CCCC.IDX_AAAAAAAAAA_SUM_NO rebuild partition P_20180910 parallel 8;
alter index CCCC.IDX_AAAAAAAAAA_SUM_NO rebuild partition P_20180911 parallel 8;
alter index CCCC.IDX_AAAAAAAAAA_SUM_NO rebuild partition P_20180912 parallel 8;
alter index CCCC.IDX_AAAAAAAAAA_SUM_NO rebuild partition P_20180913 parallel 8;
... ...
... ...
... ...
alter index CCCC.IDX_AAAAAAAAAA_SUM_NO noparallel;

索引REBUILD 重新调起存储过程~完美通过

这个系统上次给他们处理过一次问题，删除分区之后都会加update global indexes。没想到local index会出问题

总结：1.删除分区会导致全局和分区索引都失效，使用update global indexes对local索引没有效果。

2.ORA-03113报错无分析头绪的时候查看一下相关表的索引状态

一次'诡异'的执行SQL报错ORA-03113的问题处理相关推荐

数据库执行sql报错Got a packet bigger than 'max_allowed_packet' bytes及重启mysql
准备在mysql上使用数据库A,但mysql5经过重装后,上面的数据库已丢失,只得通过之前备份的A.sql重新生成数据库A. 1.执行sql报错在执行A.sql的过程中,出现如下错误:Got a p ...
关于执行SQL报错：java.lang.ArrayIndexOutOfBoundsException: 6
关于执行SQL报错:java.lang.ArrayIndexOutOfBoundsException: 6 由于工作需要,需创建一个表C,表数据由表A left join 表B生成,表A数据量大概30 ...
Oracle 执行sql报错 ORA-20401:Reject By Dbsec
在项目执行迁移数据的过程中有一条sql报错 Reject By Dbsec 字面意思被 Dbsec拒绝之后我将sql 贴出来放在Navicat中执行,也是报同样的错误,并且sql没有任何的语法错误 ...
java代码中执行sql报错：java.sql.SQLException: ORA-00923: 未找到要求的 FROM 关键字
最近写了特别多的数据库同步接口,需要在java程序中拼接大段的sql,然后再提交执行,出现了很多次ORA-00923错误,都有点见怪不怪了. 比如下面这段代码,在执行 db.execute(inser ...
执行sql报错，错误代码是 1064 ，其实是这个问题。
执行这条sql会报错 1064 CREATE TABLE `tb_user` (`id` INT(11) NOT NULL AUTO_INCREMENT,`username` VARCHAR(45) ...
Oracle执行SQL报错：ORA-00922
1. 问题描述 Oracle数据库执行序列化脚本时,报错:ora-00922 missing or invalid option. 2. 解决方法对于set define off ,这个是sqlpl ...
mysql里面using btree_MySQL - 执行sql报错USING BTREE
问题与分析在执行sql文件时发现报错如下: You have an error in your SQL syntax; check the manual that corresponds to yo ...
postgresql导出表然后再次执行sql报错
报relation "performance_id_seq" does not exist 运行如下建表语句,报错: -- 建表,并用上面的序列作为主键自增序列 CREATE TA ...
hive on spark 执行sql报错
sql差不多就是这个样子疯狂join,然后别人说这个sql跑不动了.报错 INFO] 2022-09-20 11:26:58.500 - [taskAppId=TASK-1850-1276992- ...

一次'诡异'的执行SQL报错ORA-03113的问题处理

一次'诡异'的执行SQL报错ORA-03113的问题处理相关推荐

最新文章

热门文章