2025年4月 – Database SOS

pdu完美支持金仓数据库恢复(KingbaseES)

最近朋友对pdu进行了一些完善,让其可以比较好的支持电科金仓数据库（KingbaseES）的v8/v9版本
使用pdu直接unload数据

[kingbase@xifenfei ~]$ isql -Usystem test
Password for user system: 
isql (V9.0)
Licesen Type: SALES-企业版.
Type "help" for help.

test=# select version();
         version         
-------------------------
 KingbaseES V009R002C010
(1 row)

test=# \dt
        List of relations
 Schema | Name  | Type  | Owner  
--------+-------+-------+--------
 public | t_xff | table | system
(1 row)

test=# drop table walminer_contents;
DROP TABLE
test=# select * from t_xff;
 id |       name       
----+------------------
  1 | 汉字
  2 | xff测试
  3 | 惜分飞测试
  4 | www.xifenfei.com
(4 rows)

test=# insert into t_xff values(5,'www.xifenfie.com
test'# www.orasos.com');
INSERT 0 1
test=# select * from t_xff;
 id |       name       
----+------------------
  1 | 汉字
  2 | xff测试
  3 | 惜分飞测试
  4 | www.xifenfei.com
  5 | www.xifenfie.com+
    | www.orasos.com
(5 rows)

test=# checkpoint;
CHECKPOINT

pdu直接unload恢复

test.public=# b; 
开始初始化...
 -pg_database:</data/kingbase/v9/data/global/1262>

数据库:test 
      -pg_schema:</data/kingbase/v9/data/base/13856/2615>
      -pg_class:</data/kingbase/v9/data/base/13856/1259> 共132行
      -pg_attribute:</data/kingbase/v9/data/base/13856/1249> 共8863行
      模式:
        -->public 1张表

数据库:kingbase 
      -pg_schema:</data/kingbase/v9/data/base/13857/2615>
      -pg_class:</data/kingbase/v9/data/base/13857/1259> 共131行
      -pg_attribute:</data/kingbase/v9/data/base/13857/1249> 共8855行
      模式:
        -->public 0张表
PDU.public=# use test;    
|----------------------------------------|
|          模式             |  表数量    |
|----------------------------------------|
|    public                 |  1         |
|----------------------------------------|
test.public=# set public;
|--------------------------------------------------|
|               表名                  |  表大小    |
|--------------------------------------------------|
|    t_xff                            |  8.00 KB   |
|--------------------------------------------------|

        仅显示表大小排名前 1 的表名
test.public=# param exmode sql;
-------------------------------------------------------------------
|              参数                |             当前值           |
-------------------------------------------------------------------
|    startwal                      |                              |
|    endwal                        |                              |
|    starttime                     |                              |
|    endtime                       |                              |
|    resmode(Data Restore Mode)    |              TX              |
|    exmode(Data Export Mode)      |              SQL             |
------------------------------------------------------------------
test.public=# unload tab t_xff;
正在解析表 <t_xff>. 已解析数据页: 1, 已解析数据: 5 条
表名<t_xff>-</data/kingbase/v9/data/base/13856/16384> 解析完成, 1 个数据页 ,共计 5 条数据. 成功 5 条; 失败 0 条 
COPY文件路径为:<test/public/t_xff.sql>

test.public=# unload ddl;

DDL导出完成. 文件路径: test/DDL/public_ddl.sql, 共计 1 张表

查看恢复结果,证明可以完美恢复金仓中表的数据

[root@xifenfei pdu]# cat test/public/t_xff.sql
INSERT INTO t_xff VALUES(1,'汉字');
INSERT INTO t_xff VALUES(2,'xff测试');
INSERT INTO t_xff VALUES(3,'惜分飞测试');
INSERT INTO t_xff VALUES(4,'www.xifenfei.com');
INSERT INTO t_xff VALUES(5,'www.xifenfie.com
www.orasos.com');
[root@xifenfei pdu]# cat test/DDL/public_ddl.sql
CREATE SCHEMA public;
set search_path to public;
CREATE TABLE t_xff(
        id int,
        name varchar
);

pdu恢复金仓数据库delete数据
删除数据尝试恢复

test=# delete from t_xff where id in(4,2);
DELETE 2
test=# checkpoint;
CHECKPOINT
test=# select * from t_xff;
 id |       name       
----+------------------
  1 | 汉字
  3 | 惜分飞测试
  5 | www.xifenfie.com+
    | www.orasos.com
(3 rows)

使用pdu恢复被删除数据

PDU.public=# use test;
|----------------------------------------|
|          模式             |  表数量    |
|----------------------------------------|
|    public                 |  1         |
|----------------------------------------|
test.public=# set public;
|--------------------------------------------------|
|               表名                  |  表大小    |
|--------------------------------------------------|
|    t_xff                            |  8.00 KB   |
|--------------------------------------------------|

        仅显示表大小排名前 1 的表名
test.public=# scan t_xff;

正在扫描表<t_xff>的删除记录...

开始扫描归档目录
|-起始文件<000000010000000000000005>
|-终点文件<000000010000000000000009>

正在扫描中

-------------------------------------------------------------------
当前为 事务号恢复 模式,扫描结果将以 事务号 为单位进行输出
---------------------------------------------------------------------

读取到最后的日志段： 0/504EC68: 


扫描结束,当前扫描的时间段为
|-开始时间：2025-04-06 19:13:15.280234 CST
|-结束时间：2025-04-08 01:45:59.493354 CST

---------------------------------------------------------------------------------------------------------
 时间戳：2025-04-08 01:45:59.493354 CST | 事务号：1120 | 数据文件oid：16384 | toast文件oid：0 |待恢复条数：2 
---------------------------------------------------------------------------------------------------------
test.public=# restore del 1120;
开始扫描归档目录
|-起始文件<000000010000000000000005>
|-终点文件<000000010000000000000009>

正在扫描中
读取到最后的日志段： 0/504EC68: 
|-已解析出2条数据读取到最后的日志段： 0/504EC68: 


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
解析结果：成功 2, 失败 0 (即对应FPW未找到), 共计2条数据
恢复出的csv文件路径为<restore/public/t_xff_1120.csv>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

扫描结束,当前扫描的时间段为
|-开始时间：2025-04-06 19:13:15.280234 CST
|-结束时间：2025-04-08 01:45:59.493354 CST

restore完成
test.public=# exit;
[root@xifenfei pdu]# cat restore/public/t_xff_1120.csv
2       xff测试
4       www.xifenfei.com

通过上述测试,证明pdu工具可以完美的恢复金仓中刚刚被删除的delete数据.

虚拟机故障引起ORA-00310 ORA-00334故障处理

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：虚拟机故障引起ORA-00310 ORA-00334故障处理

有客户由于硬件底层问题,导致运行在虚拟机环境中的oracle数据库突然爆大量错误

Reread (file 5, block 2371528) found same corrupt data (no logical check)
Errors in file /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_j000_10927.trc  (incident=397049):
ORA-01578: ORACLE data block corrupted (file # 5, block # 2371528)
ORA-01110: data file 5: '/home/oracle/app/oradata/users01.dbf'

Wed Apr 02 23:10:24 2025
Errors in file /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_j000_10927.trc  (incident=397050):
ORA-00600: internal error code, arguments: [5400], [], [], [], [], [], [], [], [], [], [], []

Wed Apr 02 23:15:29 2025
Errors in file /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_11605.trc  (incident=397075):
ORA-00600: internal error code, arguments: [ktbdchk1: bad dscn], [], [], [], [], [], [], [], [], [], [], []

Wed Apr 02 23:20:32 2025
Errors in file /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_11530.trc  (incident=397034):
ORA-00600: internal error code, arguments: [25027], [6], [196610], [], [], [], [], [], [], [], [], []

Wed Apr 02 23:20:52 2025
Errors in file /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_11528.trc  (incident=397027):
ORA-00600: internal error code, arguments: [ktspfpblk:kcbz_objdchk], [0], [0], [1], [], [], [], [], [], [], [], []

Wed Apr 02 23:22:53 2025
Errors in file /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_11609.trc  (incident=397082):
ORA-00600: internal error code, arguments: [6002], [6], [189], [1], [0], [], [], [], [], [], [], []

Wed Apr 02 23:26:41 2025
Errors in file /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_m000_11966.trc  (incident=397035):
ORA-00600: internal error code, arguments: [dbgrmblur_update_range_1], [11], [6], [], [], [], [], [], [], [], [], []

Wed Apr 02 23:31:47 2025
Errors in file /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_j000_10927.trc:
ORA-12012: error on auto execute of job "SYS"."ORA$AT_SA_SPC_SY_49685"
ORA-08102: index key not found, obj# 39, file 1, block 55190 (2)

Thu Apr 03 00:15:18 2025
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x8] [PC:0xB9EC41, ksuloget()+421] [flags: 0x0, count: 1]
Errors in file /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_m000_12633.trc  (incident=400879):
ORA-07445: exception encountered:core dump [ksuloget()+421][SIGSEGV][ADDR:0x8][PC:0xB9EC41][Address not mapped to object]

Thu Apr 03 00:15:23 2025
Errors in file /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_pmon_4097.trc  (incident=396817):
ORA-00600: internal error code, arguments: [1100], [0x2E3947E78], [0x2E3947E78], [], [], [], [], [], [], [], [], []

数据库crash掉之后,处理好硬件环境和虚拟机启动之后,数据库直接启动失败,报ORA-01172 ORA-01151

Beginning crash recovery of 1 threads
Started redo scan
Completed redo scan
 read 29239 KB redo, 4020 data blocks need recovery
Started redo application at
 Thread 1: logseq 211603, block 9107
Recovery of Online Redo Log: Thread 1 Group 4 Seq 211603 Reading mem 0
  Mem# 0: /home/oracle/app/oradata/orcl/redo04.log
  Mem# 1: /home/oracle/app/oradata/orcl/redo041.log
Hex dump of (file 2, block 4835) in trace file /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_19174.trc
Reading datafile '/home/oracle/app/oradata/orcl/sysaux01.dbf' for corruption at rdba: 0x008012e3 (file 2, block 4835)
Reread (file 2, block 4835) found same corrupt data (logically corrupt)
RECOVERY OF THREAD 1 STUCK AT BLOCK 4835 OF FILE 2
Aborting crash recovery due to error 1172
Errors in file /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_19174.trc:
ORA-01172: recovery of thread 1 stuck at block 4835 of file 2
ORA-01151: use media recovery to recover block, restore backup if needed
Errors in file /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_19174.trc:
ORA-01172: recovery of thread 1 stuck at block 4835 of file 2
ORA-01151: use media recovery to recover block, restore backup if needed
ORA-1172 signalled during: ALTER DATABASE OPEN...

然后再次尝试重启提示ORA-01113 ORA-01110

Fri Apr 04 09:34:36 2025
ALTER DATABASE OPEN
Errors in file /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_4076.trc:
ORA-01113: file 5 needs media recovery
ORA-01110: data file 5: '/home/oracle/app/oradata/users01.dbf'
ORA-1113 signalled during: ALTER DATABASE OPEN...

可以自行尝试了各种恢复,比如using backup controlfile,until cancel,rectl等操作,数据库均为open成功,基本上都是卡在类似如下报ORA-00310 ORA-00334错

Sat Apr 05 10:17:34 2025
ALTER DATABASE RECOVER database using backup controlfile
Media Recovery Start
started logmerger process
Sat Apr 05 10:17:34 2025
WARNING! Recovering data file 1 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 2 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 3 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 4 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 5 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 6 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 7 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 8 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 9 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 10 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 11 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 12 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 13 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 14 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 15 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
Parallel Media Recovery started with 28 slaves
ORA-279 signalled during: ALTER DATABASE RECOVER database using backup controlfile ...
Sat Apr 05 10:17:59 2025
ALTER DATABASE RECOVER LOGFILE '/home/oradata/redo02.log'
Media Recovery Log /home/oradata/redo02.log
Sat Apr 05 10:17:59 2025
Errors with log /home/oradata/redo02.log
Errors in file /u01/app/oracle/diag/rdbms/oorcl/oorcl/trace/oorcl_pr00_12141.trc:
ORA-00310: archived log contains sequence 211550; sequence 211603 required
ORA-00334: archived log: '/home/oradata/redo02.log'
ORA-310 signalled during: ALTER DATABASE RECOVER LOGFILE '/home/oradata/redo02.log' ...
ALTER DATABASE RECOVER CANCEL
Media Recovery Canceled
Completed: ALTER DATABASE RECOVER CANCEL

基于上述情况,数据库由于底层异常,导致所需要的redo和实际存在的redo文件内容不匹配,只能屏蔽一致性强制打开库

SQL> alter database open resetlogs ;
alter database open resetlogs 
*
ERROR at line 1:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [2662], [0], [1685409503], [0], [1685415469], [12583040], []
ORA-00600: internal error code, arguments: [2662], [0], [1685409502], [0], [1685415469], [12583040], []
ORA-01092: ORACLE instance terminated. Disconnection force
ORA-00600: internal error code, arguments: [2662], [0], [1685409498], [0], [1685415469], [12583040], []
Process ID: 10637
Session ID: 645 Serial number: 7

ORA-600 2662这个错误比较常见,通过修改数据库scn,进行规避然后尝试打开库

Sat Apr 05 10:31:45 2025
alter database open resetlogs
RESETLOGS is being done without consistancy checks. This may result
in a corrupted database. The database should be recreated.
RESETLOGS after incomplete recovery UNTIL CHANGE 1685409495
Resetting resetlogs activation ID 1725417463 (0x66d7c7f7)
Sat Apr 05 10:31:46 2025
Setting recovery target incarnation to 2
Initializing SCN for created control file
Database SCN compatibility initialized to 3
Warning - High Database SCN: Current SCN value is 1685409498, threshold SCN value is 0
Sat Apr 05 10:31:46 2025
Assigning activation ID 1725412798 (0x66d7b5be)
Thread 1 opened at log sequence 1
  Current log# 2 seq# 1 mem# 0: /home/oradata/redo02.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sat Apr 05 10:31:46 2025
SMON: enabling cache recovery
Undo initialization finished serial:0 start:61632504 end:61632514 diff:10 (0 seconds)
Dictionary check beginning
Tablespace 'TEMP' #3 found in data dictionary,
but not in the controlfile. Adding to controlfile.
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
*********************************************************************
WARNING: The following temporary tablespaces contain no files.
         This condition can occur when a backup controlfile has
SMON: enabling tx recovery
         been restored.  It may be necessary to add files to these
         tablespaces.  That can be done using the SQL statement:
 
         ALTER TABLESPACE <tablespace_name> ADD TEMPFILE
 
         Alternatively, if these temporary tablespaces are no longer
         needed, then they can be dropped.
           Empty temporary tablespace: TEMP
*********************************************************************
Database Characterset is AL32UTF8
Errors in file /u01/app/oracle/diag/rdbms/oorcl/oorcl/trace/oorcl_smon_22927.trc  (incident=8145):
ORA-00600: internal error code, arguments: [4137], [9.1.436887], [0], [0], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/oorcl/oorcl/incident/incdir_8145/oorcl_smon_22927_i8145.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Stopping background process MMNL
ORACLE Instance oorcl (pid = 17) - Error 600 encountered while recovering transaction (9, 1).
Errors in file /u01/app/oracle/diag/rdbms/oorcl/oorcl/trace/oorcl_smon_22927.trc:
ORA-00600: internal error code, arguments: [4137], [9.1.436887], [0], [0], [], [], [], [], [], [], [], []
Sat Apr 05 10:31:46 2025
Sweep [inc][8145]: completed
Errors in file /u01/app/oracle/diag/rdbms/oorcl/oorcl/trace/oorcl_smon_22927.trc  (incident=8146):
ORA-00600: internal error code, arguments: [4137], [9.1.436887], [0], [0], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/oorcl/oorcl/incident/incdir_8146/oorcl_smon_22927_i8146.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Sat Apr 05 10:31:46 2025
Errors in file /u01/app/oracle/diag/rdbms/oorcl/oorcl/trace/oorcl_p054_2643.trc  (incident=8625):
ORA-00600: internal error code, arguments: [kturbleurec1], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/oorcl/oorcl/incident/incdir_8625/oorcl_p054_2643_i8625.trc
Sat Apr 05 10:31:46 2025
Errors in file /u01/app/oracle/diag/rdbms/oorcl/oorcl/trace/oorcl_p034_2603.trc  (incident=8465):
ORA-00600: internal error code, arguments: [kturbleurec1], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/oorcl/oorcl/incident/incdir_8465/oorcl_p034_2603_i8465.trc
replication_dependency_tracking turned off (no async multimaster replication found)
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Completed: alter database open resetlogs
Sat Apr 05 10:31:48 2025
Starting background process CJQ0
Sat Apr 05 10:31:48 2025
CJQ0 started with pid=80, OS id=2852 
SMON: Restarting fast_start parallel rollback
Errors in file /u01/app/oracle/diag/rdbms/oorcl/oorcl/trace/oorcl_smon_22927.trc  (incident=8147):
ORA-00600: internal error code, arguments: [4137], [9.1.436887], [0], [0], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/oorcl/oorcl/incident/incdir_8147/oorcl_smon_22927_i8147.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Sat Apr 05 10:31:50 2025
Errors in file /u01/app/oracle/diag/rdbms/oorcl/oorcl/trace/oorcl_p000_2535.trc  (incident=8169):
ORA-00600: internal error code, arguments: [4198], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/oorcl/oorcl/incident/incdir_8169/oorcl_p000_2535_i8169.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
ORACLE Instance oorcl (pid = 17) - Error 600 encountered while recovering transaction (9, 1).
Block recovery from logseq 1, block 19 to scn 2147483682
Recovery of Online Redo Log: Thread 1 Group 2 Seq 1 Reading mem 0
  Mem# 0: /home/oradata/redo02.log
Block recovery completed at rba 1.734.16, scn 0.2147483683
Block recovery from logseq 1, block 404 to scn 2147483682
Recovery of Online Redo Log: Thread 1 Group 2 Seq 1 Reading mem 0
  Mem# 0: /home/oradata/redo02.log
Block recovery completed at rba 1.734.16, scn 0.2147483683
Errors in file /u01/app/oracle/diag/rdbms/oorcl/oorcl/trace/oorcl_smon_22927.trc  (incident=8148):
ORA-00600: internal error code, arguments: [4198], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/oorcl/oorcl/incident/incdir_8148/oorcl_smon_22927_i8148.trc
Sat Apr 05 10:31:50 2025
Sweep [inc][8147]: completed
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
SMON: Parallel transaction recovery slave got internal error
SMON: Downgrading transaction recovery to serial
Errors in file /u01/app/oracle/diag/rdbms/oorcl/oorcl/trace/oorcl_smon_22927.trc  (incident=8149):
ORA-00600: internal error code, arguments: [4137], [10.28.1201778], [0], [0], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/oorcl/oorcl/incident/incdir_8149/oorcl_smon_22927_i8149.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
ORACLE Instance oorcl (pid = 17) - Error 600 encountered while recovering transaction (10, 28).
Errors in file /u01/app/oracle/diag/rdbms/oorcl/oorcl/trace/oorcl_smon_22927.trc:
ORA-00600: internal error code, arguments: [4137], [10.28.1201778], [0], [0], [], [], [], [], [], [], [], []
Sat Apr 05 10:31:50 2025
Sweep [inc][8149]: completed
Checker run found 1 new persistent data failures
Errors in file /u01/app/oracle/diag/rdbms/oorcl/oorcl/trace/oorcl_smon_22927.trc  (incident=8150):
ORA-00600: internal error code, arguments: [4137], [10.28.1201778], [0], [0], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/oorcl/oorcl/incident/incdir_8150/oorcl_smon_22927_i8150.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
ORACLE Instance oorcl (pid = 17) - Error 600 encountered while recovering transaction (10, 28).
Errors in file /u01/app/oracle/diag/rdbms/oorcl/oorcl/trace/oorcl_smon_22927.trc  (incident=8151):
ORA-00600: internal error code, arguments: [4137], [10.28.1201778], [0], [0], [], [], [], [], [], [], [], []
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Sat Apr 05 10:31:51 2025
Sweep [inc][8150]: completed
ORACLE Instance oorcl (pid = 17) - Error 600 encountered while recovering transaction (10, 28).

虽然数据库open成功，但是有ORA-600 4137/ORA-600 kturbleurec1/ORA-600 4198等错误,但是这里比较明显的undo有问题,对于异常undo进行处理,然后逻辑导出数据,导入新库完成本次恢复任务

pg创建gbk字符集库

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：pg创建gbk字符集库

记录下，Postgres库创建中文字符集

postgres=# CREATE DATABASE mydb_gbk
postgres-#     ENCODING 'EUC_CN'
postgres-#     LC_COLLATE 'zh_CN' 
postgres-#     LC_CTYPE 'zh_CN'
postgres-#     TEMPLATE template0;
CREATE DATABASE
postgres=# \l
                                                 List of databases
   Name    |  Owner   | Encoding |   Collate   |    Ctype    | ICU Locale | Locale Provider |   Access privileges   
-----------+----------+----------+-------------+-------------+------------+-----------------+-----------------------
 mydb_gbk  | postgres | EUC_CN   | zh_CN       | zh_CN       |            | libc            | 
 postgres  | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |            | libc            | 
 template0 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |            | libc            | =c/postgres          +
           |          |          |             |             |            |                 | postgres=CTc/postgres
 template1 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |            | libc            | =c/postgres          +
           |          |          |             |             |            |                 | postgres=CTc/postgres
(4 rows)

前提系统必须支持zh_CN语言包,检查命令为:

[root@xifenfei yum.repos.d]# locale -a |grep zh_CN
zh_CN
zh_CN.gb18030
zh_CN.gbk
zh_CN.utf8

如果没有使用yum以下命令安装

yum groupinstall "fonts"
yum install glibc-langpack-zh.x86_64

PostgreSQL运行日志管理

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：PostgreSQL运行日志管理

PostgreSQL目前配置中,不直接记录日志文件,这样的情况给数据库后期出现问题(特别是无法正常启动的情况)分析带来很大麻烦,不知道具体问题所在,建议在PG安装完成之后,启用日志功能,便于数据库运行状态检查和错误跟踪,主要日志参数涉及以下配置

log_destination = 'stderr'              # Valid values are combinations of
                                        # stderr, csvlog, jsonlog, syslog, and
                                        # eventlog, depending on platform.
                                        # csvlog and jsonlog require
                                        # logging_collector to be on.

# This is used when logging to stderr:
logging_collector = on          # Enable capturing of stderr, jsonlog,
                                        # and csvlog into log files. Required
                                        # to be on for csvlogs and jsonlogs.
                                        # (change requires restart)
//是否将日志重定向至文件中，默认是off。

# These are only used if logging_collector is on:
log_directory = 'pg_log'                   # directory where log files are written,
                                        # can be absolute or relative to PGDATA
//日志文件目录，默认是PGDATA的相对路径，即PGDATA的相对路径，即{PGDATA}/pg_log，也可以改为绝对路径。
//日志文件可能会非常多，建议将日志重定向到其他目录或分区。
//将此配置修改其他目录时，必须先创建此目录，并修改权限，使得postgres用户对该目录有写权限。

log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' # log file name pattern,
                                        # can include strftime() escapes
log_file_mode = 0600                    # creation mode for log files,
                                        # begin with 0 to use octal notation
log_rotation_age = 1d                   # Automatic rotation of logfiles will
                                        # happen after that time.  0 disables.
log_rotation_size = 10MB                # Automatic rotation of logfiles will
                                        # happen after that much log output.
                                        # 0 disables.
#log_truncate_on_rotation = off         # If on, an existing log file with the
                                        # same name as the new log file will be
                                        # truncated rather than appended to.
                                        # But such truncation only occurs on
                                        # time-driven rotation, not on restarts
                                        # or size-driven rotation.  Default is
                                        # off, meaning append to existing files
                                        # in all cases.
//当日志文件已存在时，该配置如果为off，新生成的日志将在文件尾部追加，如果为on，则会覆盖原来的日志。

上述配置得到的结果如下

[postgres@xifenfei pg_log]$ pwd
/data/pg/15/data/pg_log
[postgres@xifenfei pg_log]$ ls -l
total 4
-rw------- 1 postgres postgres 1263 Apr  3 22:37 postgresql-2025-04-03_223117.log

ora-600 kdsgrp1 错误描述

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：ora-600 kdsgrp1 错误描述

当 fetch作找不到预期的行时，会引发 ora-600 [kdsgrp1] 错误。该错误在内存中命中，因此可能是仅内存错误或由磁盘损坏导致的错误。

此错误可能表示（但不限于）以下任何情况：

丢失写入
并行 DML 问题
索引损坏
数据块损坏
一致性读取 [CR] 问题
缓冲区缓存损坏

说明 285586.1 - ORA-600 [kdsgrp1] 中
提供了已知问题的完整列表：
每个错误都有一个简短描述，指示遇到它的情况。可以通过选择您的数据库版本来缩短 bug 列表，以仅显示可能影响您的问题。

此问题可能是间歇性的，也可能持续存在，直到修复底层磁盘级别损坏为止。间歇性问题可能是基于内存的（但是，对损坏的间歇性访问可能会与间歇性内存问题相混淆）。

常见的解决方法

如果问题仅在内存中，我们可以尝试通过刷新缓冲区缓存来立即解决问题，但请记住考虑对生产系统的性能影响：

更改系统刷新buffer_cache;

如果我们遇到间歇性一致性读取问题，我们可以尝试禁用 rowCR，这是一种优化，通过在初始化文件中设置 _row_cr=FALSE 来减少查询期间的一致性读取回滚。但是，这可能会导致查询的性能下降。请检查“RowCR hits”/“RowCR attempts”这两个统计信息的比率，以确定是否要使用解决方法。

如果这是索引损坏的结果，那么我们可以删除并重新构建索引。请注意，这将需要在生产系统上有一个 maintenance window。

根本原因确定
现在让我们看看我们如何发现问题的根本原因：查找此问题根本原因的第一步是检查生成的跟踪文件。ora-600 将在跟踪目录中生成跟踪文件，并在事件目录中的事件 ID 下生成事件文件。
跟踪文件的顶部告诉我们遇到错误时正在运行的 SQL：

—–此会话的当前 SQL 语句（sql_id=9mamr7xn4wg7x） —–

这立即向我们显示了访问的数据对象。在跟踪文件中搜索文本字符串 ‘Plan Table’ 将找到此跟踪文件中转储的 SQL 执行计划。对于持久性问题，这允许我们确定哪些索引已被访问，从而确定应验证以检查块损坏的索引：

SQL>分析索引 <OWNER>.<INDEX NAME>在线验证结构;

指数分析。

我们可以采取的另一种方法是使用 trace 文件中包含的 file 和 block 信息。在跟踪文件的顶部，我们将找到有关发现损坏的块的信息：

会话 ID：（3202.5644） 2011-03-19 04：12：16.910
行 07c7c8c7.a 在
文件# 31 块# 510151插槽 11 未找到的延续

此信息可用于识别 dba_extents 中的对象详细信息：

从 dba_extents 中选择 owner、segment_name、segment_type、partition_name，tablespace_name
其中 relative_fno = <文件 id>
并且 <block#> 在 block_id 和（block_id+blocks-1）之间;

然后我们可以验证这个对象，例如一个表和它的所有索引：

分析表 <OWNER>.<TABLE NAME>在线验证结构级联;

请记住，我们可能正在处理不在对象块本身中的永久损坏。这方面的示例包括：

可传输表空间作导致的字典损坏问题：检查 dba_tablespaces 以查看表空间是否已插入。
ASM 磁盘组镜像中的写入丢失 – 最有可能在存在大量 IO 和磁盘重新同步活动时看到。要检查此内容，请运行 dbms_diskgroup.checkfile 以检测镜像差异

如果 analyze 报告没有损坏，则检查表上是否有任何链接的行。如果存在这些，则可能存在未检测到的损坏，并且每当运行 SQL 时，问题都会再次出现。导出表也会检测到此问题。

如果 analyze 和 export 表（在存在链式行的情况下）都报告没有错误，则应将其视为一致性读取问题。

了解问题的性质后，您可以查看已知 bug 列表并确定哪个 bug 与您的条件匹配。如果您无法确定哪个问题影响了您，请向 Oracle 技术支持提交服务请求，并上传所有节点的 RDBMS 和 ASM（如果适用）实例警报日志、生成的任何跟踪和事件文件以及问题性质的完整描述。

Bug	Fixed	Description
32311758	23.1.0.0.0	ORA-600: internal error code, arguments: [kdsgrp1] on spatial physical standby database
32065006	23.1.0.0.0	Sdo_filter() fails with ORA-600: internal error code, arguments: [kdsgrp1]
32022223	19.12, 21.3.0.0.0	Sdo_filter fails with ORA-600: internal error code, arguments: [kdsgrp1]
28392179	19.11, 21.1.0.0.0	ORA-00600 [kdsgrp1] error on standby after intensive insert on the primary DB
29506942	18.11, 18.18, 19.8, 20.1	sdo_filter fails with ORA-600: internal error code, arguments: [kdsgrp1]
29311927	18.11, 18.18, 19.8, 20.1	sdo_filter fails with ORA-600: internal error code, arguments: [kdsgrp1]
28547478	12.2.0.1.DBRU:200714, 18.11, 18.18, 19.2, 20.1	ORA-600 [kdsgrp1] When Running Workload
27869764	19.1	Sdo_filter() call coredumps with [kdsgrp1] exception [optimized mbrs]
27397048	12.1.0.2.190115, 12.2.0.1.DBRU:190115, 18.18, 18.5, 19.1	Intermittent ORA-600[kdsgrp1] Raised By Query Using Index
26203182	11.2.0.4.200114, 12.1.0.2.190716, 12.2.0.1.DBRU:190115, 18.1	Lost Writes on ZFS if DNFS is enabled causing several Internal Errors. ORA-600 [kdsgrp1] ORA-8103 ORA-600 [3020] ORA-752 ORA-756
22581771	12.2.0.1.DBRU:180417, 18.1	ORA-600 [kdsgrp1] On Domain Index With Concurrent Insert And Select (With Clause)
21180699	18.1	ORA-7445/ ORA-00600 argument [kdibowrite()] / [kdibc3position()+78] / [20003] / [kcfrbd_3] / [25027] [kdsgrp1] with Execution plan ‘BITMAP’ access
22267274	12.2.0.1	CDB: Hit ORA-600 [kdsgrp1] and ORA-600 [4042]
17273253	12.1.0.1.1, 12.2.0.1	Various ORA-600 corruption errors with ASM
16195231	11.2.0.3.BP21, 11.2.0.4, 12.1.0.2, 12.2.0.1	ORA-7445 / ORA-600 from COMPRESSED table with LONG column
14576755	12.1.0.1.4, 12.1.0.2, 12.2.0.1	Corruption type ORA-600 errors from heavy concurrent DML on index cluster table
33005241	19.16, 21.7	ORA-00600 [kdsgrp1] error when using row CR
33599665	19.17	ORA-600 [kdsgrp_lost_piece] / ORA-600 [kdsgrp1-kdsgrp] While Running Flashback Query on FDA Enabled Table
31843845	19.13, 21.5	ORA-600 [kdsgrp1] Error or Wrong / Duplicate Results When Advanced Compressed Index Skip Scan Used to Access Rows
32417227	19.12	OLTP Compression Lock Bit Not Respected In Uncompressed Blocks
31228670	12.1.0.2.201020, 12.2.0.1.DBRU:201020, 18.12, 19.9	Corruption LOST Write : Rebalance disk resync causing lost write, mirror mismatches , several errors can be reported
31192039	12.2.0.1.DBRU:201020, 18.12, 18.18, 19.9	ORA-1554 and/or ORA-600 [kdsgrp1] While Deleting From A Compressed Index
31642462	19.14	ORA-600 [kdsgrp1-kdsgrp] when doing a version query using rowid having large row data with hybrid columnar compression enabled.
30651570	18.14, 18.18, 19.10	ORA-600: [kdsgrp1] After INSERT With APPEND Hint In Compressed Partitioned Table
32596207	21.0	ORA-600[kdsgrp1] failure using sdo_filter() function
29428230	18.11, 18.18, 19.8, 20.1	sdo_filter fails with ORA-600: internal error code, arguments: [kdsgrp1]
29362596	18.11.0.0.200714DBRU, 18.11, 18.18, 19.8.0.0.200714DBRU, 19.8, 20.1	sdo_filter fails with ORA-600: internal error code, arguments: [kdsgrp1]
29350868	18.11.0.0.200714DBRU, 18.11, 18.18, 19.8.0.0.200714DBRU, 19.8, 20.1	sdo_filter fails with ORA-600: internal error code, arguments: [kdsgrp1]
29139070	18.11.0.0.200714DBRU, 18.11, 18.18, 19.8.0.0.200714DBRU, 19.8, 20.1	very small adjacent insert causes index corruption ORA-600[kdsgrp1]
29048605	19.3.0.0.190416DBRU, 19.3, 20.1	index truncation causes index corruption ORA-600[kdsgrp1]
28881035	19.2, 19.2.0.0.181005R, 20.1	very small update causes index corruption ORA-600[kdsgrp1]
28802077	19.2, 19.2.0.0.181005R, 20.1	sdo_filter() fails with ORA-600[kdsgrp1]
27063461	19.11, 20.1	Physical Standby Hits ORA-600[kdbdmp_full:non-KDDBTDATA block. Use kcbtdu for it.]
28511632	23.4	Corruption LOST Write : Incomplete RMAN DUPLICATE can allow data file overwrites at Source database
27394954	19.1	sdo_filter fails with ORA-600 [kdsgrp1] after delete,insert,delete,insert,commit
27658186	12.2.0.1, 12.2.0.1.DBRU:190115, 18.5	ORA-600 [kdsgrp1] / Some rows not indexed in Text index in highly concurrent environment
24699619	12.2.0.1.171121DBRU, 12.2.0.1.171130WINDBBP, 12.2.0.1.DBRU:171121, 18.1	xdbstress hit ora 600 [kdsgrp1]
12690729	18.1	ORA-600 [kdsgrp1] errors when the active standby database recovery is enabled using CURRENT LOGFILE
22575209	12.2.0.1	ORA-600 [kdsgrp1] ORA-600 [25027] ORA-8103 ORA-1578 ORA-3254 in ADG Standby Database for Full Scan on ASSM segment – superseded
22519146	12.1.0.2.171017, 12.2.0.1	ORA-600 [kdsgrp1] or ORA-600 [kdsgrpcalcblockcount: hwmbno<=dbabno] or ORA-8103 in 12c on HCC Table in EXADATA
22241601	12.2.0.1	ORA-600 [kdsgrp1] ORA-1555 / ORA-600 [ktbdchk1: bad dscn] due to Invalid Commit SCN in INDEX block
21973601	12.2.0.0, 12.2.0.1	Querying a partitioned table may fail with ORA-00600 [kdsgrp1]
21634686	12.2.0.1	ORA-600 [kdsgrp1] / ORA-600 [ktfbhget:clsviol_kcbgcur_9] With Hybrid Columnar Compression (HCC)
21532755	11.2.0.4.171017, 12.1.0.2.171017, 12.2.0.1	ORA-600 [25027] By Concurrent queries while Create Index Online or ORA-8102 Table/Index mistmatch after Create Index Online or ONLINE_INDEX_CLEAN wait for DMLs
21096955	12.2.0.1	ORA-600 [kdsgrp1] / ORA-600 [ktfbhget:clsviol_kcbgcur_9] With Hybrid Columnar Compression (HCC)
19689979	11.2.0.4.170718, 12.1.0.2.160119, 12.1.0.2.DBBP07, 12.2.0.1	ORA-8103 or ORA-600 [ktecgsc:kcbz_objdchk] or Wrong Results on PARTITION table after TRUNCATE in 11.2.0.4 or above
19630914	12.2.0.1	ORA-600 [kdsgrp1] And Other Errors ORA-600 [6033] When BigSCN Testing Is Enabled
19614585	11.2.0.4.BP17, 12.1.0.2.DBBP03, 12.2.0.1	Wrong Results / ORA-600 [kksgaGetNoAlloc_Int0] / ORA-600 [12406] / ORA-7445 / ORA-8103 / ORA-1555 from query on RAC ADG Physical Standby Database
18607546	11.2.0.4.6, 11.2.0.4.BP16, 12.1.0.2.3, 12.1.0.2.DBBP06, 12.2.0.1	ORA-600 [kdblkcheckerror]..[6266] corruption with self-referenced chained row. ORA-600 [kdsgrp1] / Wrong Results / ORA-8102
18311351	12.2.0.1	ORA-1/ORA-10388 ORA-7445 [kdzsbuffercupiece_col] ORA-600 [kdsgrp1]/ORA-1499 Wrong Results, Index Inconsistency after Parallel Direct Path Insert of HCC table in EXADATA
17779978	12.2.0.1	ORA-00600 [kdsgrp1] & ORA-7445 [hshhsv] & ORA-7445 [pkrcd] errors on CDB
17761775	11.2.0.3.9, 11.2.0.3.BP22, 11.2.0.4.2, 11.2.0.4.BP03, 12.1.0.1.3, 12.1.0.2, 12.2.0.1	ORA-600 [kclchkblkdma_3] ORA-600 [3020] or ORA-600 [kcbchg1_16] Join of temp and permanent table in RAC might lead to corruption – superseded
17357359	12.1.0.2, 12.2.0.1	ORA-600 [kdsgrp1] during fetch by rowid
17160362	12.1.0.2, 12.2.0.1	ORA-600 [kdsgrp1] & [kclchkblk_3] & [kclchkblkdma_3] in rdbms
16849623	12.1.0.2, 12.2.0.1	ORA-600 [kdsgrp1] While Running Workload On Tables With Chained Rows
16698629	12.1.0.2, 12.2.0.1	ORA-600 [kdsgrp1] executing SELECT on table modified by a loosely coupled clusterwide global transaction
16555614	12.1.0.2, 12.2.0.1	mdidxridchk() causes buffer overrun problem when more than 4000 rows selected
16345143	12.2.0.1	Event 10231 does not skip row for IOT with non-existent nrid
14044260	12.1.0.2, 12.2.0.1	Update DML with long bind LOB that moves row to new partition fails with ORA-600 [kdsgrp1] – superseded
17449815	11.2.0.4.4, 11.2.0.4.BP11, 12.1.0.2, 12.2.0.1	ORA-8102 ORA-1499 after ORA-1/ORA-2291 by MERGE with DML ERROR LOGGING
17204397	12.1.0.2, 12.2.0.1	ORA-8005 ORA-8103 ORA-1410 ORA-600 [kdsgrp1] on Bitmap Index. Root Block may be repeatedly pinned/unpinned
16844448	11.2.0.3.9, 11.2.0.3.BP22, 11.2.0.4, 12.1.0.2, 12.2.0.1	ORA-600 [3020] after flashback database in a RAC
16563781	12.1.0.2, 12.1.0.2.180116, 12.2.0.1	version query may return wrong result on a table in TTS tablespace
21425496	11.2.0.4.190416, 12.1.0.1, 12.1.0.2.190716	ORA-752 or ORA-600 [3020] on recovery of Block Cleanout Operation OP:4.6
17518816	12.1.0.0, 12.1.0.1	ORA-600 [kdsgrp1] on select statements on a Active Dataguard Standby database
14790903	11.2.0.4, 12.1.0.1	ora 600 [kdsgrp1]
14527172	12.1.0.1	ORA-600 [4097] And [kdsgrp1] After unplugging and plugging the PDB In RAC Environment
13614906	12.1.0.1	ORA-600 [kdsgrp1] due to missing weak changes from an XA transaction in RAC – superceded
13399500	11.2.0.3.BP15, 11.2.0.4, 12.1.0.1	ORA-600 [kdsgrp1] when updating a chained rows on a ehcc table
13146182	11.2.0.2.11, 11.2.0.2.BP17, 11.2.0.3.10, 11.2.0.3.BP07, 11.2.0.4, 12.1.0.1	ORA-1499 ORA-8102 ORA-600 [kdsgrp1] Bitmap Index / Table mismatch
12821418	11.2.0.3.8, 11.2.0.3.BP18, 11.2.0.4, 12.1.0.1	Direct NFS appears to be sending zero length windows to storage device. It may also cause Lost Writes
12619529	11.2.0.3.BP18, 11.2.0.4, 12.1.0.1	ORA-600[kdsgrp1] from SELECT on plugged in tablespace with FLASHBACK
12330911	12.1.0.1	EXADATA LSI firmware for lost writes
10633840	11.2.0.2.7, 11.2.0.2.BP17, 11.2.0.3, 12.1.0.1	ORA-1502 on insert statement on INTERVAL partitioned table. ORA-8102 / ORA-1499 Index inconsistency
10245259	11.2.0.2.BP03, 11.2.0.3, 12.1.0.1	PARALLEL INSERT with +NOAPPEND hint or if PARALLEL INSERT plan is executed in SERIAL corrupts index and causes wrong results
10209232	11.1.0.7.7, 11.2.0.1.BP08, 11.2.0.2.1, 11.2.0.2.BP02, 11.2.0.2.GIBUNDLE01, 11.2.0.3, 12.1.0.1	ORA-1578 / ORA-600 [3020] Corruption. Misplaced Blocks and Lost Write in ASM
10205230	11.2.0.1.6, 11.2.0.1.BP09, 11.2.0.2.2, 11.2.0.2.BP04, 11.2.0.3, 12.1.0.1	ORA-600 / corruption possible during shutdown in RAC
9770451	10.2.0.5.3, 11.2.0.2.1, 11.2.0.2.BP02, 11.2.0.3, 12.1.0.1	ORA-600 [20022] with bitmap indexes
9734539	11.2.0.2, 12.1.0.1	ORA-8102 / ORA-1499 corrupt index after update/merge using QUERY REWRITE
9469117	10.2.0.5.4, 11.2.0.1.BP04, 11.2.0.2, 12.1.0.1	Corrupt index after PDML executed in serial. Wrong results. OERI[kdsgrp1]/ORA-1499 by analyze
9457185	11.2.0.1.BP12, 11.2.0.2, 12.1.0.1	Intermittent ORA-600 [kdsgrp1] during CR read
9231605	11.1.0.7.4, 11.2.0.1.3, 11.2.0.1.BP02, 11.2.0.2, 12.1.0.1	Block corruption with missing row on a compressed table after DELETE
9145541	11.1.0.7.4, 11.2.0.1.2, 11.2.0.2, 12.1.0.1	OERI[25027]/OERI[4097]/OERI[4000]/ORA-1555 in plugged datafile after CREATE CONTROLFILE in 11g
9061269	11.2.0.2, 12.1.0.1	ORA-600 [kdsgrp1] executing CTX_QUERY.COUNT_HITS during concurrent sync Text index
8951812	11.2.0.2, 12.1.0.1	Corrupt index by rebuild online. Possible OERI [kddummy_blkchk] by SMON
8837919	11.2.0.2, 12.1.0.1	DBV / RMAN enhanced to detect ASSM blocks with ktbfbseg but not ktbfexthd flag set as in Bug 8803762
8803762	11.1.0.7.6, 11.2.0.1.2, 11.2.0.1.BP06, 11.2.0.2, 12.1.0.1	ORA-600[kdsgrp1], ORA-600[25027] or wrong results on 11g database upgrade from 9i
8771916	10.2.0.5.3, 11.1.0.7.6, 11.2.0.1.BP12, 11.2.0.2, 12.1.0.1	OERI [kdsgrp1] during CR read
8635179	10.2.0.5, 11.2.0.2, 12.1.0.1	Solaris: directio may be disabled for RAC file access. Corruption / Lost Write
8597106	11.2.0.1.BP06, 11.2.0.2, 12.1.0.1	Lost Write in ASM when normal redundancy is used
8546356	10.2.0.5.1, 11.2.0.1.3, 11.2.0.1.BP07, 11.2.0.2, 12.1.0.1	ORA-8102/ORA-1499/OERI[kdsgrp1] Composite Partitioned Index corruption after rebuild ONLINE in RAC
7710827	11.2.0.2, 12.1.0.1	Index rebuild or Merge partition causes wrong results in concurrent reads instead of ORA-8103
7705591	10.2.0.5, 11.2.0.1.1, 11.2.0.1.BP04, 11.2.0.2, 12.1.0.1	Corruption with self-referenced row in MSSM tablespace. Wrong Results / OERI[6749] / ORA-8102
7251049	11.2.0.1.BP08, 11.2.0.2, 12.1.0.1	Corruption in bitmap index introduced when using transportable tablespaces
16579042	11.2.0.4	ORA-600 [kjbmpocr:alh] ORA-600 [kclchkblkdma_3] by LMS in RAC which may lead to corruption
9527635	11.2.0.1.BP04, 11.2.0.2, 12.1.0.1	ORA-00600 [kdsgrp1] On Exadata
8650661	11.1.0.7.2, 11.2.0.1	OERI / corruption type errors using global transactions in RAC
8588540	11.1.0.7.2, 11.2.0.1	Corruption / ORA-8102 in RAC with loopback DB links between instances
7682186	11.2.0.1	ORA-600[kdsgrp1] on consistent read in RAC with global transaction
7329252	10.2.0.4.4, 10.2.0.5, 11.1.0.7.5, 11.2.0.1	ORA-8102/ORA-1499/OERI[kdsgrp1] Index corruption after rebuild index ONLINE
7289224	11.2.0.1	ORA-600 [kdsgrp1] on CR read with parallel query
6791996	11.2.0.1	ORA-600 errors for a DELETE with self referencing FK constraint and BITMAP index
6772911	10.2.0.5, 11.1.0.7.3, 11.2.0.1	OERI[12700] OERI[qertbFetchByRowID] OERI[kdsgrp1] due to bad CR rollback of INDEX block
6445948	10.2.0.4.4, 10.2.0.5, 11.1.0.7.8, 11.2.0.1	Intermitent ORA-600 [kdsgrp1] accessing table with a LONG
6404058	10.2.0.5, 11.1.0.7, 11.2.0.1	OERI:12700 OERI:kdsgrp1 OERI:qertbFetchByRowID wrong results from CR rollback of split index leaf
6129296	11.2.0.1	ORA-600 [kdsgrp1] by PARALLEL select for update with LOB
5621677	10.2.0.4, 11.1.0.6	Logical corruption with PARALLEL update
5374225	10.2.0.4, 11.1.0.6	SDO_FILTER query fails with OERI[kdsgrp1]
5368945	10.2.0.5, 11.1.0.6	ORA-600 [kdsgrp1] on Index Organized Table with Overflow
4883635	10.2.0.4, 11.1.0.6	MERGE (with DELETE) can produce wrong results or Logical corruption in chained rows
3408192	9.2.0.6, 10.1.0.3, 10.2.0.1	Heavy concurrent DML scenarios can cause $R table to contain deleted rowids

GAM、SGAM 或 PFS 页上存在页错误处理

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：GAM、SGAM 或 PFS 页上存在页错误处理

有客户sql server数据库由于硬件故障,导致dbcc的时候报类似GAM、SGAM 或 PFS 页上存在页错误

kzj2025的 DBCC 结果。
Service Broker 消息 9675，状态 1: 已分析的消息类型: 14。
Service Broker 消息 9676，状态 1: 已分析的服务约定: 6。
Service Broker 消息 9667，状态 1: 已分析的服务: 3。
Service Broker 消息 9668，状态 1: 已分析的服务队列: 3。
Service Broker 消息 9669，状态 1: 已分析的会话端点: 0。
Service Broker 消息 9674，状态 1: 已分析的会话组: 0。
Service Broker 消息 9670，状态 1: 已分析的远程服务绑定: 0。
Service Broker 消息 9605，状态 1: 已分析的会话优先级: 0。
消息 8939，级别 16，状态 98，第 1 行
表错误: 对象 ID 0，索引 ID -1，分区 ID 0，分配单元 ID -2958221917649371136 
(类型为 Unknown)，页 (12337:808857908)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 12716041 和 -10。
消息 8998，级别 16，状态 2，第 1 行
GAM、SGAM 或 PFS 页上存在页错误，无法对数据库 ID 6 中从 (1:186024) 到 (1:194111) 
 的页继续进行分配完整性检查。原因请参阅其他错误消息。
CHECKDB 发现有 2 个分配错误和 0 个一致性错误与任何单个的对象都没有关联。
sys.sysrscols的 DBCC 结果。
对象 'sys.sysrscols' 的 171 页中有 16248 行。
sys.sysrowsets的 DBCC 结果。
……………………
对象 'gspz_pmaintainidx' 的 12 页中有 1658 行。
DiseasesMedicationsIndex_temp的 DBCC 结果。
对象 'DiseasesMedicationsIndex_temp' 的 0 页中有 0 行。
GSP_BackBill的 DBCC 结果。
对象 'GSP_BackBill' 的 0 页中有 0 行。
Gsp_L_KwGradeIndex的 DBCC 结果。
对象 'Gsp_L_KwGradeIndex' 的 0 页中有 0 行。
Web_T_Message的 DBCC 结果。
对象 'Web_T_Message' 的 0 页中有 0 行。
CHECKDB 在数据库 'kzj2025' 中发现 2 个分配错误和 0 个一致性错误。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

完成时间: 2025-03-29T19:53:21.6977003+08:00

由于GAM、SGAM 或 PFS是和sql数据库文件的空间分配有关系,对于这种情况,一般无法直接修复,需要对库进行重构的方法进行修复,我们处理之后,dbcc检查一切正常

月度归档：4月 2025