ORA-00600
Table of Contents
1 前言
ORA-006000 錯誤，一般都會涉及到Oracle 的BUG 問題。所以這種問題很難解決。這里只 能對已經發生過的,進行一些總結。以供對比和判斷。如果各種條件能完全匹配，則可以 嘗試進行對應方法的解決。如果條件不匹配，在購買Oracle 服務的情況下，可以申請 Oracle 支持。
另外，也有可能信息補充不及時，最好是直接到 MOS 賬號上查詢。
下面各個部分，以錯誤的第一個參數為區分點。
1.1 3020
1.2 kcblin_3
總體來說，這個參數的報錯，是由於內存管理方面的問題。比如參數設置過大，或者內 存自動管理與手動管理的沖突等。
- 觸發條件及解決方法
-
- _PGA_MAX_SIZE 設置超過2G,
- 解決方法
-
- 將該參數值調整至2G,或者更低
- 升級至12.2
- 安裝補丁：17951233
- SORT_AREA_SIZE 設置過大
- 觸發條件
-
- 操作系統使用大頁
- 以下三個參數被設置並生效 workarea_size_policy=manual sort_area_size=2147483647 sort_area_retained_size=2147483647
- 解決方法
- 設置sort_area_size=2145386946 或者更小
- _smm_max_size 設置過大
- 觸發條件
- _SMM_MAX_SIZE 設置超過2G.
- 解決方法
-
- 升級至12.2
- 安裝補丁:17951233
- 內存參數配置沖突
- 觸發條件
-
一方面是使用了內存的自動管理memory_target/sga_target，又手動設置了以下幾個參數:
- sort_area_size
- hash_area_size
- workarea_size_policy
- 解決辦法
- 將以上三個參數去除。
- _PGA_MAX_SIZE 設置超過2G,
1.3 kghfrunp
kghfrunp - kernel generic heap manager free unused space in a heap free unpinned space 堆管理時，用於釋放未不再使用的內存空間和釋放pin的空間。
1.3.1 no duration
EXPDP執行時報錯ORA-00600[kghfrunp: no duration]。 當操作需要SGA釋放部分領域來使用時，由於沒有正常釋放就會報錯ORA-00600[kghfrunp]。 Bug 13914613 Excessive time holding shared pool latch in kghfrunp with auto memory management 回避策為
SQL> alter system set "_enable_shared_pool_durations"=false scope=spfile;
1.4 kdBlkCheckError
1.4.1 現象
在數據庫宕機前出現ORA-00600錯誤。 日志內容如下：
ORA-01595: error freeing extent (4) of rollback segment (31))
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [kdBlkCheckError], [3], [3], [18018], [], [], [], [], [], [], [], []
Corrupt Block Found
TSN = 2, TSNAME = UNDOTBS1
RFN = 3, BLK = 3, RDBA = 12582915
OBJN = 2, OBJD = -1, OBJECT = , SUBOBJECT =
SEGMENT OWNER = , SEGMENT TYPE =
Wed Aug 02 10:00:05 2017
Dumping diagnostic data in directory=[cdmp_20170802100005], requested by (instance=1, osid=24055 (SMON)), summary=[incident=48868].
Errors in file /oracle/app/oracle/diag/rdbms/aiboss/aiboss/trace/aiboss_smon_24055.trc (incident=61108):
ORA-00600: internal error code, arguments: [kdBlkCheckError], [3], [3], [18018], [], [], [], [], [], [], [], []
Incident details in: /oracle/app/oracle/diag/rdbms/aiboss/aiboss/incident/incdir_61108/aiboss_smon_24055_i61108.trc
Wed Aug 02 10:00:11 2017
PMON (ospid: 24025): terminating the instance due to error 474
System state dump requested by (instance=1, osid=24025 (PMON)), summary=[abnormal instance termination].
System State dumped to trace file /oracle/app/oracle/diag/rdbms/aiboss/aiboss/trace/aiboss_diag_24035.trc
Instance terminated by PMON, pid = 24025
Wed Aug 02 10:40:19 2017
1.4.2 分析
- 錯誤分析 ORA-01595,ORA-00607,ORA-00600錯誤出現后，10:00:05秒Oracle開啟記錄此錯誤的相關信息,隨后 Oracle PMON進行由SMON於無法清理資源，無法保證數據一致性而停止實例。 ORA-01595錯誤提的是數據庫smon 進行清理回滾段的extent. 說明undo表空間出現問題。
- BUG 確認
從宕機前的日志記錄來看，數據庫遇到的是oracle BUG 12349316. 依據為：
freeing extent (4) of rollback segment (31)) =====> 與oracle BUG 12349316引發的條件一致，都是在清理extent時引發BUG. [kdBlkCheckError], [ 3], [ 3], [ 18018] =====> 與oracle BUG 12349316 中600錯誤返回參數一致，都帶有18018. trace 日志(aiboss_smon_24055_i61108.trc)中發現 delete extent 函數 =====> FRAME [ 32] (ktusp_delextent()+76 -> ktsxr_delete())
1.4.3 故障處理
主要的處理思路是先跳過有問題的undo段，然后重建undo表空間
-
修改參數文件 數據庫啟動時，查找參數文件的順序是spfile<ORACLE_SID>.ora –> init<ORACLE_SID>.ora –> init.ora. 因此Oracle 數據庫傾向於使用spfile啟動數據庫。一般環境中也都使用spfile. 如何確認數據庫使用的是spfile 還是pfile,使用 " show parameter spfile " 命令即可查看。
當數據庫使用的是spfile參數文件時，由於spfile是 二進制 文件，我們不便於直接修改，因此需要先創建出一個pfile 文本文件。
create pfile='/tmp/pfile.ora' from spfile; 此命令的執行不需要啟動數據庫,進入sqlplus環境即可。
在參數文件中加入以下內容： undo_management = MANUAL # UNDO 段管理方式改為manual # 其他可添加內容： *.fast_start_parallel_rollback=high # 以4*cpu 個數開啟回滾進程，但是實際上不會真的開始這么多。 *._allow_resetlogs_corruption = true # 如果數據庫需要恢復，且undo與redo不一致，部分redo 無法恢復時需要此參數，允許resetlogs
-
啟動數據庫
startup mount pfile='/tmp/pfile.ora'; alter database open;
如果數據庫需要recovery,則執行以下命令:
recover database until cancel; alter database open resetlogs;
-
offline存在活動事務的的undo塊
select segment_name,status,tablespace_name from dba_rollback_segs where status not in ('ONLINE', 'OFFLINE') ; SEGMENT_NAME STATUS TABLESPACE_NAME ------------------------------ ---------------- ------------------------------ _SYSSMU3_4004931649$ NEEDS RECOVERY UNDOTBS1 _SYSSMU4_1126976075$ NEEDS RECOVERY UNDOTBS1 _SYSSMU5_4011504098$ NEEDS RECOVERY UNDOTBS1
將以上內容添加至剛創建的/tmp/pfile.ora中:
_CORRUPTED_ROLLBACK_SEGMENTS = ('_SYSSMU3_4004931649$','_SYSSMU4_1126976075$','_SYSSMU5_4011504098$')"_corrupted_rollback_segments" 作用是不使用這幾個回滾段。
-
重啟數據庫
startup force pfile='/tmp/pfile.ora'; -
重新創建undo 表空間
alter tablespace undotbs1 offline ; drop tablespace undotbs1 including contents and datafiles; create undo tablespace undotbs1 datafile '/data0/aiboss/undotbs1.dbf' size 30G autoextend off; alter system set undo_tablespace='UNDOTBS1';
-
重啟數據庫 重啟數據庫前，需要修改/tmp/pfile.ora 參數文件，將以下參數去除:
undo_management=manual _allow_resetlogs_corruption=true fast_start_parallel_rollback=high
重啟:
startup force pfile='/tmp/pfile.ora'; create spfile from pfile='/tmp/pfile.ora'; startup force;
1.5 keltnfy-ldmInit
1.5.1 [46][1]
hostname 修改后，沒有在/etc/hosts 中添加ip 與hostname 的對應關系。
1.6 kkzlpllg:5
該錯誤是materialized view 中出現的。錯誤信息如下:
ORA-00600: internal error code, arguments: [kkzlpllg:5], [], [], [], [], [], [], [], [], [], [], [] ORA-06512: at \"SYS.DBMS_SNAPSHOT\", line 2809 ORA-06512: at \"SYS.DBMS_SNAPSHOT\", line 3025 ORA-06512: at \"SYS.DBMS_SNAPSHOT\", line 2994
-
原因
出現這個錯誤信息，是由於之前刪除物化視圖與刪除表之間的順序不對。引起的數據字典sys.snap_logdep$中的數據，在進行刷新 或者建立物化視圖時，數據出現多行而無法完成完成操作引起的。
我們刪除物化視圖和表時，一定要先刪除物化視圖，再刪除物化視圖日志，最后再刪除表。如果順序錯了，有些信息是不會被刪除掉的。
-
解決
將sys.snap_logdep$ 中rscn 列是空值的字段設置為非空即可。比如:
select * from sys.snap_logdep$ where rscn is null; TABLEOBJ# SNAPID SNAPTIME RSCN ---------- ---------- --------- ---------- 85590 3 16-NOV-17 77461 3 16-NOV-17 update sys.snap_logdep$ set rscn=999999 where rscn is null; 2 rows updated. SQL> commit;
Created: 2020-05-22 Fri 20:25