[20170417]另类提升scn2.txt

最新推荐文章于 2021-04-11 10:50:11 发布

cuixun7780

最新推荐文章于 2021-04-11 10:50:11 发布

阅读量104

点赞数

[20170417]另类提升scn2.txt

--//上个星期的测试偶然发现，通过修改一些块的scn能够提升scn。我还是通过例子说明：

--//如果数据库异常关闭，在某种特殊修复后，会出现数据文件块的scn大于数据文件头的scn号，这样在访问这些块时会报：
Errors in file /opt/oracle/admin/conner/udump/conner_ora_31607.trc:
ORA-00600: internal error code, arguments: [2662], [0], [897694446], [0], [897695488], [8388697], [], []

ORA-600 [2662] "Block SCN is ahead of Current SCN"，说明当前数据库的数据块的SCN早于当前的SCN，主要是和存储在UGA变量中的
dependent SCN进行比较，如果当前的SCN小于它，数据库就会产生这个ORA-600 [2662]的错误了。这个错误一共有五个参数，分别代表不同的含义
ORA-600 [2662] [a] [b] {c} [d] [e]
Arg [a] Current SCN WRAP
Arg [b] Current SCN BASE
Arg {c} dependent SCN WRAP
Arg [d] dependent SCN BASE
Arg [e] Where present this is the DBA where the dependent SCN came from.
注：897694446<897695488

--//参考链接： http://blog.itpub.net/267265/viewspace-750075/
--//错误原因:
1.使用隐含参数_ALLOW_RESETLOGS_CORRUPTION后resetlogs打开数据库
2.硬件错误引起数据库没法写控制文件和重做日志文件
3.错误的部分恢复数据库
4.恢复了控制文件但是没有使用recover database using backup controlfile进行恢复
5.数据库crash后设置了_DISABLE_LOGGING隐含参数
6.在并行服务器环境中DLM存在问题

--//一般通过提升scn来解决问题.

--//本来我想看看这些块出现在一些重要的系统对象，这样数据库将出现什么情况，结果得到一个竟然可以正常系统，通过例子来说明：
--//在测试前先说明这个数据库必须是"正常"关闭的数据库，不然依旧报上面的错误。

1.环境：
SYS@book> @ &r/ver1
PORT_STRING VERSION BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

SYS@book> select header_file,header_block from dba_segments where segment_name='UNDO$' and owner=user;
HEADER_FILE HEADER_BLOCK
----------- ------------
1 224
--// dba 1,225 就是undo$ 的数据块。

SYS@book> startup mount
ORACLE instance started.
Total System Global Area 634732544 bytes
Fixed Size                  2255792 bytes
Variable Size             197133392 bytes
Database Buffers          427819008 bytes
Redo Buffers                7524352 bytes
Database mounted.

SYS@book> SELECT file#, CHECKPOINT_CHANGE#,CHECKPOINT_TIME,UNRECOVERABLE_CHANGE#,UNRECOVERABLE_TIME,LAST_CHANGE#,LAST_TIME, OFFLINE_CHANGE#, ONLINE_CHANGE#,status,name FROM v$datafile;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME     UNRECOVERABLE_CHANGE# UNRECOVERABLE_TIME LAST_CHANGE# LAST_TIME           OFFLINE_CHANGE# ONLINE_CHANGE# STATUS NAME
----- ------------------ ------------------- --------------------- ------------------- ------------ ------------------- --------------- -------------- ------- --------------------------------------------------
    1        13276934882 2017-04-17 16:23:24                     0                      13276934882 2017-04-17 16:23:24          925701         925702 SYSTEM /mnt/ramdisk/book/system01.dbf
    2        13276934882 2017-04-17 16:23:24                     0                      13276934882 2017-04-17 16:23:24          925701         925702 ONLINE /mnt/ramdisk/book/sysaux01.dbf
    3        13276934882 2017-04-17 16:23:24                     0                      13276934882 2017-04-17 16:23:24          925701         925702 ONLINE /mnt/ramdisk/book/undotbs01.dbf
    4        13276934882 2017-04-17 16:23:24                     0                      13276934882 2017-04-17 16:23:24          925701         925702 ONLINE /mnt/ramdisk/book/users01.dbf
    5        13276934882 2017-04-17 16:23:24           13274819965 2017-01-16 22:00:05 13276934882 2017-04-17 16:23:24          952916         952921 ONLINE /mnt/ramdisk/book/example01.dbf
    6        13276934882 2017-04-17 16:23:24                     0                      13276934882 2017-04-17 16:23:24               0              0 ONLINE /mnt/ramdisk/book/tea01.dbf
6 rows selected.

--//CHECKPOINT_CHANGE#=LAST_CHANGE#,说明是正常关闭的数据库。

2.通过bbed观察记录dba=1,225块的scn。

p dba 1,225 kcbh.bas_kcbh
p dba 1,225 ktbbh.ktbbhitl[0].ktbitbas
p dba 1,225 ktbbh.ktbbhcsc.kscnbas

BBED> p dba 1,225 kcbh.bas_kcbh
ub4 bas_kcbh @8 0x175df2de

BBED> p dba 1,225 ktbbh.ktbbhitl[0].ktbitbas
ub4 ktbitbas @64 0x175df2de

BBED> p dba 1,225 ktbbh.ktbbhcsc.kscnbas
ub4 kscnbas @28 0x175df2dd

--//主要目的是先记录原来的值。
--//假设现在要修改块scn=14000000000.
select 14000000000,trunc(14000000000/power(2,32)) scn_wrap,mod(14000000000,power(2,32)) scn_base from dual
14000000000 SCN_WRAP SCN_BASE SCN_WRAP16 SCN_BASE16
------------ ------------ ------------ ---------- ----------
14000000000 3 1115098112 3 42770c00

assign dba 1,225 kcbh.bas_kcbh=1115098112
--//assign dba 1,225 kcbh.wrp_kcbh=3
assign dba 1,225 tailchk=0x0c000601
sum apply dba 1,225
verify dba 1,225

--//执行如下：
assign dba 1,225 kcbh.bas_kcbh=1115098112
--//assign dba 1,521 kcbh.wrp_kcbh=3 , 已经是3,不用修改

--//注意tailchk也要跟着修改，因为这部分包括{(bas_kcbh(低2字节))+(type_kcbh)+(seq_kcbh)}

BBED> p dba 1,225 tailchk
ub4 tailchk @8188 0xf2de0601

BBED> assign dba 1,225 tailchk=0x0c000601
ub4 tailchk @8188 0x0c000601

--//补充说明一下，使用assign命令修改tailchk,如果第1个大于0x8,不能这样修改。例子：
BBED> assign dba 1,225 tailchk=0x8c000601
BBED-00207: invalid offset specifier (8c000601)

--//要执行如下，注意cpu类型，大小头问题。
BBED> modify /x 0x008c 8190
File: /mnt/ramdisk/book/system01.dbf (1)
Block: 225 Offsets: 8190 to 8191 Dba:0x00400209
--------------------------------------------------------------------------------------------------
008c

<64 bytes per line>

BBED> p dba 1,225 tailchk
ub4 tailchk @8188 0x8c000601
---//

BBED> assign dba 1,225 tailchk=0x0c000601
ub4 tailchk @8188 0x0c000601

BBED> sum apply dba 1,225
Check value for File 1, Block 521:
current = 0x108e, required = 0x108e

BBED> verify dba 1,225
DBVERIFY - Verification starting
FILE = /mnt/ramdisk/book/system01.dbf
BLOCK = 225
--OK!

3.测试看看：
SYS@book> alter database open ;
Database altered.

SYS@book> select current_scn,dbms_flashback.get_system_change_number,current_scn from v$database;
CURRENT_SCN GET_SYSTEM_CHANGE_NUMBER CURRENT_SCN
------------ ------------------------ ------------
14000000307 14000000307 14000000307

--//你可以发现scn已经提升了。原来才13276934882。

4.做一些事务看看：
SCOTT@book> create table tx as select * from dba_objects ;
Table created.

SCOTT@book> update tx set object_name=object_name;
86990 rows updated.

SCOTT@book> commit ;
Commit complete.

SCOTT@book> SELECT file#, CHECKPOINT_CHANGE#, CHECKPOINT_TIME,CREATION_CHANGE# , RESETLOGS_CHANGE#,status, CHECKPOINT_COUNT,fuzzy,name,tablespace_name FROM v$datafile_header;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME     CREATION_CHANGE# RESETLOGS_CHANGE# STATUS CHECKPOINT_COUNT FUZ NAME                            TABLESPACE_NAME
----- ------------------ ------------------- ---------------- ----------------- ------- ---------------- --- ------------------------------- ---------------
    1        13276934885 2017-04-17 16:31:38                7            925702 ONLINE               845 YES /mnt/ramdisk/book/system01.dbf SYSTEM
    2        13276934885 2017-04-17 16:31:38             1834            925702 ONLINE               834 YES /mnt/ramdisk/book/sysaux01.dbf SYSAUX
    3        13276934885 2017-04-17 16:31:38           923328            925702 ONLINE               755 YES /mnt/ramdisk/book/undotbs01.dbf UNDOTBS1
    4        13276934885 2017-04-17 16:31:38            16143            925702 ONLINE               840 YES /mnt/ramdisk/book/users01.dbf   USERS
    5        13276934885 2017-04-17 16:31:38           952916            925702 ONLINE               751 YES /mnt/ramdisk/book/example01.dbf EXAMPLE
    6        13276934885 2017-04-17 16:31:38      13276257767            925702 ONLINE               219 YES /mnt/ramdisk/book/tea01.dbf     TEA
6 rows selected.

SCOTT@book> alter system checkpoint ;
System altered.

SCOTT@book> SELECT file#, CHECKPOINT_CHANGE#, CHECKPOINT_TIME,CREATION_CHANGE# , RESETLOGS_CHANGE#,status, CHECKPOINT_COUNT,fuzzy,name,tablespace_name FROM v$datafile_header;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME     CREATION_CHANGE# RESETLOGS_CHANGE# STATUS CHECKPOINT_COUNT FUZ NAME                            TABLESPACE_NAME
----- ------------------ ------------------- ---------------- ----------------- ------- ---------------- --- ------------------------------- ---------------
    1        14000000581 2017-04-17 16:34:09                7            925702 ONLINE               846 YES /mnt/ramdisk/book/system01.dbf SYSTEM
    2        14000000581 2017-04-17 16:34:09             1834            925702 ONLINE               835 YES /mnt/ramdisk/book/sysaux01.dbf SYSAUX
    3        14000000581 2017-04-17 16:34:09           923328            925702 ONLINE               756 YES /mnt/ramdisk/book/undotbs01.dbf UNDOTBS1
    4        14000000581 2017-04-17 16:34:09            16143            925702 ONLINE               841 YES /mnt/ramdisk/book/users01.dbf   USERS
    5        14000000581 2017-04-17 16:34:09           952916            925702 ONLINE               752 YES /mnt/ramdisk/book/example01.dbf EXAMPLE
    6        14000000581 2017-04-17 16:34:09      13276257767            925702 ONLINE               220 YES /mnt/ramdisk/book/tea01.dbf     TEA
6 rows selected.

--//可以发现数据库没有任何问题。scn已经大幅提升。
SCOTT@book> select current_scn,dbms_flashback.get_system_change_number,current_scn from v$database;
CURRENT_SCN GET_SYSTEM_CHANGE_NUMBER CURRENT_SCN
------------ ------------------------ ------------
14000000661 14000000661 14000000661

--//从以上测试也可以看出，如果oracle认为数据库是正常关闭，修改一些系统字典相关数据块，可以提升scn号，也说明oracle对这些块并没有严格检查。
--//而普通数据块是有问题的，可以参考我的链接：
http://blog.itpub.net/267265/viewspace-750075/ => [20121127]ora-0060[2662]错误的产生以及模拟.txt

-//总结：使用这种方法不实用，也许许多情况可能导致无法成功。仅仅是一次测试。
-//另外我还测试了

SYS@book> select header_file,header_block from dba_segments where segment_name='OBJ$' and owner=user;
HEADER_FILE HEADER_BLOCK
------------ ------------
1 240
--// dba 1,241 就是obj$ 的数据块。也就是修改dba 1,241的scn也是可以提升的scn的。
--// 我在10.2.0.4也做了同样测试，也一样通过。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/267265/viewspace-2137424/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/267265/viewspace-2137424/