备库
Thu Feb 14 09:00:32 2019
Errors in file /u01/app/oracle/diag/rdbms/trstdb/trstdb/trace/trstdb_ora_90063.trc (incident=880729):
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/trstdb/trstdb/incident/incdir_880729/trstdb_ora_90063_i880729.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
vi /u01/app/oracle/diag/rdbms/trstdb/trstdb/trace/trstdb_ora_90063.trc
G
---一般出现 kdsgrp1 这个表示是 有 物理或者 逻辑坏块 ---
* kdsgrp1-2: *************************************************
Incident 880729 created, dump file: /u01/app/oracle/diag/rdbms/trstdb/trstdb/incident/incdir_880729/trstdb_ora_90063_i880729.trc
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
---搜索 not found
* kdsgrp1-1: *************************************************
row 0x031f8070.6 continuation at
0x031f8070.6 file# 12 block# 2064496 slot 6 not found
KDSTABN_GET: 0 ..... ntab: 1
---根据 日志信息 查询对应的 表
select *
from dba_extents a
where a.FILE_ID = 12
and block_id <= 2064496
and (a.BLOCK_ID + a.BLOCKS) >= 2064496
SQL> select a.owner,a.segment_name,a.EXTENT_ID from dba_extents a where a.FILE_ID = 12 and block_id <= 2064496 and (a.BLOCK_ID + a.BLOCKS) >= 2064496;
OWNER SEGMENT_NAME EXTENT_ID
------------------------------ ------------------------------ ----------
SSP T_TRADE_201902_POS_1_0000 237
SQL> col name for a60
SQL> select name from v$datafile where file#=12;
NAME
------------------------------------------------------------
/u01/app/oracle/oradata/trstdb/ssp_data04.dbf
---备份这个文件，没有问题；说明不是物理坏块，是逻辑坏块
RMAN> backup as copy datafile 12;
Starting backup at 14-FEB-19
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=4087 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00012 name=/u01/app/oracle/oradata/trstdb/ssp_data04.dbf
output file name=/u01/app/oracle/product/11.2/db_1/dbs/data_D-TRADB_I-2790025021_TS-SSP_DATA_FNO-12_1btprptj tag=TAG20190214T103011 RECID=16 STAMP=1000204276
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:15
Finished backup at 14-FEB-19
----对比 上面的文件出现的信息 核实是否是 一个表
[oracle@trstdb trace]$ more /u01/app/oracle/diag/rdbms/trstdb/trstdb/incident/incdir_880729/trstdb_ora_90063_i880729.trc
Dump file /u01/app/oracle/diag/rdbms/trstdb/trstdb/incident/incdir_880729/trstdb_ora_90063_i880729.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /u01/app/oracle/product/11.2/db_1
System name: Linux
Node name: tradbstydb
Release: 3.8.13-98.7.1.el7uek.x86_64
Version: #2 SMP Wed Nov 25 13:51:41 PST 2015
Machine: x86_64
Instance name: trstdb
Redo thread mounted by this instance: 1
Oracle process number: 91
Unix process pid: 90063, image: oracle@trstdb
*** 2019-02-14 09:00:32.995
*** SESSION ID:(6755.20243) 2019-02-14 09:00:32.995
*** CLIENT ID:() 2019-02-14 09:00:32.995
*** SERVICE NAME:() 2019-02-14 09:00:32.995
*** MODULE NAME:(JDBC Thin Client) 2019-02-14 09:00:32.995
*** ACTION NAME:() 2019-02-14 09:00:32.995
Dump continued from file: /u01/app/oracle/diag/rdbms/tradbstdy/tradbstdy/trace/tradbstdy_ora_90063.trc
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
========= Dump for incident 880729 (ORA 600 [kdsgrp1]) ========
*** 2019-02-14 09:00:33.003
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
----- Current SQL Statement for this session (sql_id=81mx7ad094quv) -----
SELECT count(1)
FROM
T_TRADE_201902_POS_1_0000
t
WHERE
t.TRAN_DATE BETWEEN TO_DATE(:1 ,'yyyyMMdd') AND TO_DATE(:2 ,'yyyyMMdd')
AND t.ROOT_AGENT_NO = :3
AND t.TR_STS='S' AND t.TR_FLG='N'
AND t.AGENT_PATH LIKE :4 ||'%'
AND t.BUSINESS_NO = :5
AND t.TR_CD in ('1011','1005','1025','1050')
-----
今天早上新代理商交易查询库出现ORA-600错误，该错误是一类紧急错误。
经排查是T_TRADE_201902_POS_1_0000表的一个逻辑错误，需要对该库进行另行维护。flush整库内存资源。
flush时长约5分钟。flush后数据库内sql跑的慢属于正常现象，因为需要重新解析SQL。
alter ststem flush buffer_cache;