标签云
asm 恢复 asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 ORACLE恢复 Oracle 恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (100)
- 数据库 (1,598)
- DB2 (22)
- MySQL (70)
- Oracle (1,463)
- Data Guard (49)
- EXADATA (7)
- GoldenGate (21)
- ORA-xxxxx (158)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (13)
- ORACLE 21C (3)
- Oracle ASM (65)
- Oracle Bug (7)
- Oracle RAC (47)
- Oracle 安全 (6)
- Oracle 开发 (27)
- Oracle 监听 (27)
- Oracle备份恢复 (530)
- Oracle安装升级 (84)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (75)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (36)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (19)
-
最近发表
- PostgreSQL解析wal日志之—walminer
- Oracle 19c/21c最新patch信息-202404
- PostgreSQL恢复系列:pg_filedump批量处理
- PostgreSQL部分主要字典信息
- PostgreSQL恢复系列:pg_filedump恢复字典构造
- PostgreSQL 16 源码安装
- ORA-00742 ORA-00312 恢复
- 数据库open成功后报ORA-00353 ORA-00354错误引起的一系列问题(本质ntfs文件系统异常)
- ORA-600 ktsiseginfo1故障
- ORA-00600: internal error code, arguments: [16703], [1403], [4] 原因
- 最近遇到几起ORA-600 16703故障(tab$被清空),请引起重视
- ORA-600 2662快速恢复之Patch scn工具
- TNS-12518: TNS:listener could not hand off client connection
- ora.storage无法启动报ORA-12514故障处理
- 断电引起文件scn异常数据库恢复
- ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance
- .[hudsonL@cock.li].mkp勒索加密数据库完美恢复
- 模拟带库实现rman远程备份
- 又一例:ORA-600 kclchkblk_4和2662故障
- Oracle误删除数据文件恢复
月归档:十月 2013
因RAC的undo_management参数不一致导致数据库mount报ORA-01105 ORA-01606
环境Linux 5.8 10.2.0.5 RAC,两个节点只能一个节点mount,如果尝试mount另外节点就报ORA-01105和ORA-01606错误
数据库版本
SQL> select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi PL/SQL Release 10.2.0.5.0 - Production CORE 10.2.0.5.0 Production TNS for Linux: Version 10.2.0.5.0 - Production NLSRTL Version 10.2.0.5.0 - Production
crs资源情况
[oracle@node1 dbs]$ $ORA_CRS_HOME/bin/crs_stat -t Name Type Target State Host ------------------------------------------------------------ ora....D1.inst application OFFLINE OFFLINE ora....D2.inst application ONLINE ONLINE node2 ora.PROD.db application ONLINE ONLINE node2 ora....SM1.asm application ONLINE ONLINE node1 ora....E1.lsnr application ONLINE ONLINE node1 ora.node1.gsd application ONLINE ONLINE node1 ora.node1.ons application ONLINE ONLINE node1 ora.node1.vip application ONLINE ONLINE node1 ora....SM2.asm application ONLINE ONLINE node2 ora....E2.lsnr application ONLINE ONLINE node2 ora.node2.gsd application ONLINE ONLINE node2 ora.node2.ons application ONLINE ONLINE node2 ora.node2.vip application ONLINE ONLINE node2
节点1 mount报错
SQL> startup ORACLE instance started. Total System Global Area 171966464 bytes Fixed Size 2094832 bytes Variable Size 113248528 bytes Database Buffers 50331648 bytes Redo Buffers 6291456 bytes ORA-01105: mount is incompatible with mounts by other instances ORA-01606: gc_files_to_locks not identical to that of another mounted instance
Error: ORA 1105 Text: mount is incompatible with mounts by other instances ------------------------------------------------------------------------------- Cause: An attempt was made to mount the database, but another instance has already mounted a database by the same name, and the mounts are not compatible. dditional messages will accompany this message to report why the mounts are incompatible. Action: See the accompanying messages for the appropriate action to take. Error: ORA 1606 Text: GC_FILES_TO_LOCKS not identical to that of another mounted instance ------------------------------------------------------------------------------- Cause: The initialization parameter GC_FILES_TO_LOCKS is not the same as another instance mounted in parallel mode. This parameter must be the same as that for all shared instances. Action: Modify the parameter to be compatible with the other instances, then shut down and restart the instance.
根据这个错误提示,查询两个节点的gc_files_to_locks参数,均为空值(默认值),也就是值相同
SQL> show parameter gc_files_to_locks; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ gc_files_to_locks string
检查两个节点的gc相关隐含参数,发现所有值也均一致
NAME DESCRIPTION VALUE ------------------------------ --------------------------------------------------------------------- ------- _gc_affinity_limit dynamic affinity limit 50 _gc_affinity_minimum dynamic affinity minimum activity per minute 6000 _gc_affinity_time if non zero, enable dynamic object affinity 10 _gc_async_memcpy if TRUE, use async memcpy FALSE _gc_check_bscn if TRUE, check for stale blocks TRUE _gc_coalesce_recovery_reads if TRUE, coalesce recovery reads TRUE _gc_defer_time how long to defer down converts for hot buffers 3 _gc_dissolve_undo_affinity if TRUE, dissolve undo affinity after an offline FALSE _gc_dynamic_affinity_locks if TRUE, get dynamic affinity locks TRUE _gc_element_percent global cache element percent 103 _gc_global_lru turn global lru off, make it automatic, or turn it on AUTO _gc_initiate_undo_affinity if TRUE, initiate undo affinity after an online TRUE _gc_integrity_checks set the integrity check level 1 _gc_keep_recovery_buffers if TRUE, make recovery buffers current TRUE _gc_latches number of latches per LMS process 8 _gc_maximum_bids maximum number of bids which can be prepared 0 _gcs_fast_reconfig if TRUE, enable fast reconfiguration for gcs locks TRUE _gcs_latches number of gcs resource hash latches to be allocated per LMS process 64 _gcs_pkey_history number of pkey remastering history 4000 _gcs_process_in_recovery if TRUE, process gcs requests during instance recovery TRUE _gcs_resources number of gcs resources to be allocated _gcs_shadow_locks number of pcm shadow locks to be allocated _gc_statistics if TRUE, kcl statistics are maintained TRUE _gcs_testing GCS testing parameter 0 _gc_tsn_undo_affinity if TRUE, use TSN undo affinity TRUE _gc_undo_affinity if TRUE, enable dynamic undo affinity TRUE _gc_undo_affinity_locks if TRUE, get affinity locks for undo TRUE _gc_use_cr if TRUE, allow CR pins on PI and WRITING buffers TRUE _gc_vector_read if TRUE, vector read current buffers TRUE
仔细对比数据库参数,发现undo异常
--节点1 SQL> show parameter undo NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ undo_management string MANUAL undo_retention integer 900 undo_tablespace string SYSTEM --节点2 SQL> show parameter undo NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ undo_management string AUTO undo_retention integer 900 undo_tablespace string UNDOTBS1
这里已经明确,因为两个节点的undo_*相关参数配置不正确,导致数据库只能一个节点mount。进一步定位问题发现,原来是因为dba粗心在编辑节点1的参数文件的时候把undo_*相关的参数给弄丢了,从而数据库使用了默认值undo_management=manual,undo_tablespace=system
win平台rman备份和删除dg备库归档日志脚本
总觉得使用windows跑oracle是不靠谱的事情,可以这个世界上总有很多人喜欢做类似这样的事情,对于数据库比较常见的两件事情:rman和删除dg备库归档日志,在linux/unix平台上使用shell实现很简单,可是跑到win里面,就变的烦了,不是因为其麻烦,而是因为用的人少,不知道怎么下手处理该事情,我编写了简单的实现初级功能的win下面rman备份和删除备库归档日志脚本,供大家参考,也更加欢迎朋友提出来更加好的处理方法(win是真心的不懂)
rman备份脚本
--backup_oracle.bat文件 rman target / cmdfile=D:\backup\rman\backup_db.rman log=d:/backup/rman/logfile/rmanlog%date:~0,4%%date:~5,2%%date:~8,2%.log --backup_db.rman文件 CONFIGURE RETENTION POLICY TO REDUNDANCY = 2; CONFIGURE DEVICE TYPE DISK PARALLELISM 2; CONFIGURE DEFAULT DEVICE TYPE TO DISK; backup filesperset = 5 as compressed backupset database format 'd:/backup/rman/full_%U.rman'; sql 'alter system archive log current'; backup filesperset = 50 as compressed backupset archivelog all format 'd:/backup/rman/arch_%U.rman' delete input; DELETE noprompt OBSOLETE; crosscheck backup; delete noprompt expired backup; backup format 'd:/backup/rman/ctl_%U.rman' current controlfile; backup spfile format 'd:/backup/rman/spfile_%U.rman' ; exit;
backup_oracle.bat文件加入到计划任务即可
删除dg备库归档日志(已经应用)
--delete_dg_archivelog.bat rem 注意修改 部署目录 cd D:\win_xifenfei d: rem 注意delete_archive.sql 查询是否有记录 echo delete archivelog staring > delete_archivelog.bak sqlplus / as sysdba @delete_archive.sql echo rman target / cmdfile=rman_checkcross.rman>>delete_archivelog.bat delete_archivelog.bat >>delete_dg_archivelog_%DATE:~0,4%%DATE:~5,2%%DATE:~8,2%".log exit --delete_archive.sql set lines 150 col name for a150 set pagesize 0 feedback off verify off heading off echo off spool delete_archivelog.bat select 'del '||name from v$archived_log where APPLIED='YES' AND NAME IS NOT NULL and DEST_ID=1; spool off exit; --rman_checkcross.rman crosscheck archivelog all; delete noprompt expired archivelog all; exit
delete_dg_archivelog.bat加入到计划任务即可
发表在 Data Guard
评论关闭
db_block_checksum实质是通过flg_kcbh来控制block checksum
db_block_checksum 用于DBWn和direct loader数据块写入到磁盘时,基于块内的所有字节计算得出一个校验值并将其写入块头。在该参数设置为typical和full时,当读入时候重新计算校验和写出时候的校验对比,如果不同则认为是块损坏。如果设置为FULL模式,则基于update/delete应用程序语句级别的改变发生后,校验值会被重新计算并写入。同时对于日志块,在写入之前,同样会生产校验值并写入到块头。该参数主要是防止IO硬件和IO子系统的错误。
这里提示我们是在系统参数级别使用db_block_checksum来控制block是否进行验证,那在block本身级别,是否有类似的值来控制,实现对block值的checksum?通过dump结合bbed给出相关答案
db_block_checksum为TYPICAL测试
CDB_CDB$ROOT@SYS> show parameter db_block_checksum; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_block_checksum string TYPICAL CDB_CDB$ROOT@SYS> conn / as sysdba 已连接。 CDB_CDB$ROOT@SYS> alter session set container=pdb; 会话已更改。 CDB_CDB$ROOT@SYS> alter database open; 数据库已更改。 CDB_CDB$ROOT@SYS> alter session set current_schema=chf; 会话已更改。 CDB_CDB$ROOT@SYS> create table t_xifenfei(id number,name varchar2(100)); 表已创建。 CDB_CDB$ROOT@SYS> insert into t_xifenfei values(1,'www.xifenfei.com'); 已创建 1 行。 CDB_CDB$ROOT@SYS> alter system checkpoint; 系统已更改。 CDB_CDB$ROOT@SYS> select dbms_rowid.rowid_relative_fno(rowid) file_no, 2 dbms_rowid.rowid_block_number(rowid) block_no from t_xifenfei; FILE_NO BLOCK_NO ---------- ---------- 9 19229 CDB_CDB$ROOT@SYS> SELECT NAME FROM V$DATAFILE WHERE FILE#=9; NAME --------------------------------------------------------------------- E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF
dump 该block
buffer tsn: 3 rdba: 0x02404b1d (9/19229) scn: 0xb8c.3c232935 seq: 0x01 flg: 0x06 tail: 0x29350601 frmt: 0x02 chkval: 0xe08b type: 0x06=trans data Hex dump of block: st=0, typ_found=1 tab 0, row 0, @0x1f81 tl: 23 fb: --H-FL-- lb: 0x1 cc: 2 col 0: [ 2] c1 02 col 1: [16] 77 77 77 2e 78 69 66 65 6e 66 65 69 2e 63 6f 6d end_of_block_dump End dump data blocks tsn: 3 file#: 9 minblk 19229 maxblk 19229
这里可以看到因为db_block_checksum=TYPICAL,因此插入记录的时候,dump block发现flg: 0×06 和 chkval: 0xe08b
使用bbed查看相关记录
补充:在win系统中,bbed查看block和block num相差1
BBED> p kcbh struct kcbh, 20 bytes @0 ub1 type_kcbh @0 0x06 ub1 frmt_kcbh @1 0xa2 ub1 spare1_kcbh @2 0x00 ub1 spare2_kcbh @3 0x00 ub4 rdba_kcbh @4 0x02404b1d ub4 bas_kcbh @8 0x3c232935 ub2 wrp_kcbh @12 0x0b8c ub1 seq_kcbh @14 0x01 ub1 flg_kcbh @15 0x06 (KCBHFDLC, KCBHFCKV) ub2 chkval_kcbh @16 0xe08b ub2 spare3_kcbh @18 0x0000
通过对比bbed和dump出来数据,可以得出flg: 0×06(flg_kcbh),chkval: 0xe08b(chkval_kcbh)
使用bbed修改block验证chkval_kcbh
提问:在使用bbed修改block的时候,一般都需要使用sum apply 处理下,为什么呢?
BBED> d /v File: E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF (0) Block: 19230 Offsets: 8165 to 8191 Dba:0x00000000 ------------------------------------------------------- 2c010202 c1021077 77772e78 6966656e l ,...?.www.xifen 6665692e 636f6d01 063529 l fei.com..5) <16 bytes per line> --没有修改任何值,sum的current和required值相同,而且和chkval_kcbh也相同 BBED> sum Check value for File 0, Block 19230: current = 0xe08b, required = 0xe08b --尝试修改值 BBED> m /x 78 offset 8173 File: E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF (0) Block: 19230 Offsets: 8173 to 8191 Dba:0x00000000 ------------------------------------------------------------------------ 78772e78 6966656e 6665692e 636f6d01 063529 <32 bytes per line> BBED> d /v offset 8165 File: E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF (0) Block: 19230 Offsets: 8165 to 8191 Dba:0x00000000 ------------------------------------------------------- 2c010202 c1021077 78772e78 6966656e l ,...?.wxw.xifen 6665692e 636f6d01 063529 l fei.com..5) <16 bytes per line> --发现current<>required BBED> sum Check value for File 0, Block 19230: current = 0xe08b, required = 0xef8b --apply把current修改为required值 BBED> sum apply Check value for File 0, Block 19230: current = 0xef8b, required = 0xef8b --发现chkval_kcbh也修改为了required值 BBED> p kcbh.chkval_kcbh ub2 chkval_kcbh @16 0xef8b
通过这里可以发现,在flg_kcbh含(KCBHFCKV)的情况下,如果block发生改变,则运行sum apply之后chkval_kcbh也发生改变
继续dump block
buffer tsn: 3 rdba: 0x02404b1d (9/19229) scn: 0xb8c.3c232935 seq: 0x01 flg: 0x06 tail: 0x29350601 frmt: 0x02 chkval: 0xef8b type: 0x06=trans data Hex dump of block: st=0, typ_found=1 tab 0, row 0, @0x1f81 tl: 23 fb: --H-FL-- lb: 0x1 cc: 2 col 0: [ 2] c1 02 col 1: [16] 77 78 77 2e 78 69 66 65 6e 66 65 69 2e 63 6f 6d end_of_block_dump End dump data blocks tsn: 3 file#: 9 minblk 19229 maxblk 19229
证明上述结论正确:dump.flg=bbed.flg_kcbh,dump.chkval=bbed.chkval_kcbh
db_block_checksum为FALSE测试
CDB_CDB$ROOT@SYS> alter system set db_block_checksum=false; 系统已更改。 CDB_CDB$ROOT@SYS> drop table t_xifenfei_new purge; 表已删除。 CDB_CDB$ROOT@SYS> alter session set current_schema=chf; 会话已更改。 CDB_CDB$ROOT@SYS> create table t_xifenfei_new(id number,name varchar2(100)); 表已创建。 CDB_CDB$ROOT@SYS> insert into t_xifenfei_new values(1,'www.orasos.com'); 已创建 1 行。 CDB_CDB$ROOT@SYS> commit; 提交完成。 CDB_CDB$ROOT@SYS> select dbms_rowid.rowid_relative_fno(rowid) file_no, 2 dbms_rowid.rowid_block_number(rowid) block_no from t_xifenfei_new; FILE_NO BLOCK_NO ---------- ---------- 9 19237 CDB_CDB$ROOT@SYS> alter system checkpoint; 系统已更改。 CDB_CDB$ROOT@SYS> alter system dump datafile 9 block 19237; 系统已更改。
dump block分析
buffer tsn: 3 rdba: 0x02404b25 (9/19237) scn: 0xb8c.3c23c8b2 seq: 0x01 flg: 0x02 tail: 0xc8b20601 frmt: 0x02 chkval: 0x0000 type: 0x06=trans data Hex dump of block: st=0, typ_found=1 tab 0, row 0, @0x1f83 tl: 21 fb: --H-FL-- lb: 0x1 cc: 2 col 0: [ 2] c1 02 col 1: [14] 77 77 77 2e 6f 72 61 73 6f 73 2e 63 6f 6d end_of_block_dump End dump data blocks tsn: 3 file#: 9 minblk 19237 maxblk 19237
这里可以发现当设置db_block_checksum=false之时,插入数据,显示flg: 0×02,chkval: 0×0000,由此猜测无对block写入进行部分验证(tailchk依然验证)
使用bbed修改block
BBED> set filename 'E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF' FILENAME E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF BBED> set blocksize 19238 BBED-00108: illegal BLOCKSIZE (19238) specified BBED> set blocksize 8192 BLOCKSIZE 8192 BBED> set block 8192 BLOCK# 8192 BBED> set blocksize 19238 BBED-00108: illegal BLOCKSIZE (19238) specified BBED> set block 19238 BLOCK# 19238 BBED> p kcbh struct kcbh, 20 bytes @0 ub1 type_kcbh @0 0x06 ub1 frmt_kcbh @1 0xa2 ub1 spare1_kcbh @2 0x00 ub1 spare2_kcbh @3 0x00 ub4 rdba_kcbh @4 0x02404b25 ub4 bas_kcbh @8 0x3c23c8b2 ub2 wrp_kcbh @12 0x0b8c ub1 seq_kcbh @14 0x01 ub1 flg_kcbh @15 0x02 (KCBHFDLC) ub2 chkval_kcbh @16 0x0000 ub2 spare3_kcbh @18 0x0000 --这里看到flg_kcbh与chkval_kcbh和dump结果一致 BBED> sum Check value for File 0, Block 19238: current = 0x0000, required = 0x0000 --required为0,表示不验证 BBED> d /v offset 8174 File: E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF (0) Block: 19238 Offsets: 8174 to 8191 Dba:0x00000000 ------------------------------------------------------- 7777772e 6f726173 6f732e63 6f6d0106 l www.orasos.com.. b2c8 l 踩 <16 bytes per line> BBED> set mode edit MODE Edit BBED> m /x 78 Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y File: E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF (0) Block: 19238 Offsets: 8174 to 8191 Dba:0x00000000 ------------------------------------------------------------------------ 7877772e 6f726173 6f732e63 6f6d0106 b2c8 <32 bytes per line> BBED> d /v File: E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF (0) Block: 19238 Offsets: 8174 to 8191 Dba:0x00000000 ------------------------------------------------------- 7877772e 6f726173 6f732e63 6f6d0106 l xww.orasos.com.. b2c8 l 踩 <16 bytes per line> --修改了block,但是sum依然提示required为0 BBED> sum Check value for File 0, Block 19238: current = 0x0000, required = 0x0000 BBED> sum apply Check value for File 0, Block 19238: current = 0x0000, required = 0x0000
dump block核对
buffer tsn: 3 rdba: 0x02404b25 (9/19237) scn: 0xb8c.3c23c8b2 seq: 0x01 flg: 0x02 tail: 0xc8b20601 frmt: 0x02 chkval: 0x0000 type: 0x06=trans data Hex dump of block: st=0, typ_found=1 tab 0, row 0, @0x1f83 tl: 21 fb: --H-FL-- lb: 0x1 cc: 2 col 0: [ 2] c1 02 col 1: [14] 78 77 77 2e 6f 72 61 73 6f 73 2e 63 6f 6d end_of_block_dump End dump data blocks tsn: 3 file#: 9 minblk 19237 maxblk 19237
修改flg_kcbh测试
BBED> m /x 06 offset 15 Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y File: E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF (0) Block: 19238 Offsets: 15 to 30 Dba:0x00000000 ------------------------------------------------------------------------ 06000000 00010000 00d86b01 00aec823 <32 bytes per line> BBED> sum Check value for File 0, Block 19238: current = 0x0000, required = 0x04b3 --修改flg_kcbh=x06后,sum中的required出现了非0值,表示已经启动了block完整性检测 BBED> m /x 79 offset 1876 File: E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF (0) Block: 19238 Offsets: 1876 to 1891 Dba:0x00000000 ------------------------------------------------------------------------ 79391b01 0000c24e 07000205 c406573f <32 bytes per line> BBED> sum Check value for File 0, Block 19238: current = 0x0000, required = 0x049d --修改了chkval_kcbh值 BBED> sum apply Check value for File 0, Block 19238: current = 0x049d, required = 0x049d
再次检查dump block
buffer tsn: 3 rdba: 0x02404b25 (9/19237) scn: 0xb8c.3c23c8b2 seq: 0x01 flg: 0x06 tail: 0xc8b20601 frmt: 0x02 chkval: 0x049d type: 0x06=trans data Hex dump of block: st=0, typ_found=1 tl: 21 fb: --H-FL-- lb: 0x1 cc: 2 col 0: [ 2] c1 02 col 1: [14] 78 77 77 2e 6f 72 61 73 6f 73 2e 63 6f 6d end_of_block_dump End dump data blocks tsn: 3 file#: 9 minblk 19237 maxblk 19237
证明修改flg_kcbh后,block的sum验证起效
完整测试
--flg_kcbh=2,chkval_kcbh为04b3,修改block观察变化 BBED> sum Check value for File 0, Block 19238: current = 0x04b3, required = 0x04b3 BBED> p kcbh struct kcbh, 20 bytes @0 ub1 type_kcbh @0 0x06 ub1 frmt_kcbh @1 0xa2 ub1 spare1_kcbh @2 0x00 ub1 spare2_kcbh @3 0x00 ub4 rdba_kcbh @4 0x02404b25 ub4 bas_kcbh @8 0x3c23c8b2 ub2 wrp_kcbh @12 0x0b8c ub1 seq_kcbh @14 0x01 ub1 flg_kcbh @15 0x02 (KCBHFDLC) ub2 chkval_kcbh @16 0x04b3 ub2 spare3_kcbh @18 0x0000 BBED> m /x 11 offset 7184 File: E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF (0) Block: 19238 Offsets: 7184 to 7199 Dba:0x00000000 ------------------------------------------------------------------------ 110000c2 39b50002 05c40721 07280000 <32 bytes per line> BBED> undo BBED> modify /x 00 filename 'E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF' block 19238. offset 7184. File: E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF (0) Block: 19238 Offsets: 7184 to 7199 Dba:0x00000000 ------------------------------------------------------------------------ 000000c2 39b50002 05c40721 07280000 <32 bytes per line> BBED> m /x 11 offset 8174 File: E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF (0) Block: 19238 Offsets: 8174 to 8189 Dba:0x00000000 ------------------------------------------------------------------------ 1177772e 6f726173 6f732e63 6f6d0106 <32 bytes per line> BBED> sum Check value for File 0, Block 19238: current = 0x04b3, required = 0x04b3 --证明当flg_kcbh=2修改block之后chkval_kcbh依然为04b3,证明flg_kcbh不含(KCBHFCKV), --修改block不会导致chkval_kcbh改变,也就是说,该block为启用db_block_checksum --flg_kcbh=6的时候验证修改block导致的chkval_kcbh变化 BBED> m /x 06 offset 15 File: E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF (0) Block: 19238 Offsets: 15 to 30 Dba:0x00000000 ------------------------------------------------------------------------ 06b30400 00010000 00d86b01 00aec823 <32 bytes per line> --刚刚修改flg_kcbh=6,马上看到required非0 BBED> sum Check value for File 0, Block 19238: current = 0x04b3, required = 0x04da BBED> sum apply Check value for File 0, Block 19238: current = 0x04da, required = 0x04da --尝试修改block BBED> m /x 22 offset 8174 File: E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF (0) Block: 19238 Offsets: 8174 to 8189 Dba:0x00000000 ------------------------------------------------------------------------ 2277772e 6f726173 6f732e63 6f6d0106 <32 bytes per line> --required发生改变 BBED> sum Check value for File 0, Block 19238: current = 0x04da, required = 0x04e9 BBED> sum apply Check value for File 0, Block 19238: current = 0x04e9, required = 0x04e9 --修改为以前值,验证required BBED> m /x 11 offset 8174 File: E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF (0) Block: 19238 Offsets: 8174 to 8189 Dba:0x00000000 ------------------------------------------------------------------------ 1177772e 6f726173 6f732e63 6f6d0106 <32 bytes per line> BBED> sum Check value for File 0, Block 19238: current = 0x04e9, required = 0x04da BBED> sum apply Check value for File 0, Block 19238: current = 0x04da, required = 0x04da --发现当block修改回来后,required值和以前一致(也就是说chkval_kcbh值还原) --进步一说明chkval_kcbh取决于block内部值
通过相关测试db_block_checksum是在实例级别启动block checksum,但是具体到每个block是通过flg_kcbh来控制,而具体体现是在chkval_kcbh值上