[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> 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也做了同样测试，也一样通过。
