[20170417]另类提升scn2.txt

简介: [20170417]另类提升scn2.txt --//上个星期的测试偶然发现,通过修改一些块的scn能够提升scn。我还是通过例子说明: --//如果数据库异常关闭,在某种特殊修复后,会出现数据文件块的scn大于数据文件头的scn号,这样在访问这些块时会报: ...

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

目录
相关文章
|
Oracle 关系型数据库 数据库管理
[20170419]bbed探究数据块.txt
[20170419]bbed探究数据块.txt --//bbed 是一个瑞士军刀,也是了解oracle内部数据块结构的好工具。我自己开始使用基本是看别人的帖子,对oracle数据块的内部也不是很了解。
1052 0
|
监控 Oracle 关系型数据库
[20170412]分析重做日志.txt
[20170412]分析重做日志.txt --//自己很少做重做日志转储,测试看看。 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER --...
1033 0
|
SQL 测试技术 索引
[20161029]无法窥视在PLSQL.txt
[20161029]无法窥视在PLSQL.txt --测试使用PL/SQL无法窥视绑定变量的情况: --例子链接:https://connormcdonald.wordpress.
693 0
|
Oracle 关系型数据库 数据库
[20160912]另类ORA-01157-文件大小不对
[20160912]另类ORA-01157.txt --前一阵子帮别人解决的问题,当时没有记录,现在在自己的系统上再现。 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION ...
1047 0
|
SQL Oracle 关系型数据库
[20160406] 恢复until scn NNN.txt
[20160406] 恢复until scn NNN.txt --昨天别人问的问题,如果使用rman恢复,restore database until scn NNN;是恢复到NNN,还是NNN-1.
838 0
|
Oracle 关系型数据库 测试技术
[20151109]提升scn号11g测试.txt
[20151109]提升scn号11g测试.txt --以前的测试都在10g下进行的,在11.2.0.4下重复测试. 1.测试环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION...
808 0
|
测试技术
[20150917]恢复使用scn比time更好.txt
[20150917]恢复使用scn比time更好.txt --oracle 提供一个函数SCN_TO_TIMESTAMP将scn转换成时间,但是这个存在一个精度问题,误差大约是3秒.
631 0
|
Oracle 关系型数据库 数据库
[20150806]scn headroom.txt
[20150806]scn headroom.txt 转载:http://www.askmaclean.com/archives/scn-headroom-1988-oracle.html SCN是Oracle数据库内部的一种逻辑时间戳,通过SCN将数据库内的事件理清次序, 这是保证事务属性ACID的必要信息。
1160 0
|
测试技术 Linux
[20150805]提升scn4.txt
[20150805]提升scn4.txt --昨天一直在做修改控制文件提升scn的方法,折腾了很久,浪费了一些时间做一些总结: --昨天的测试有一些乱。自己今天做一些总结(结论以此为准) ,我的测试环境: --10.2.0.4,11.2.0.3都是linux 64位版本。
760 0
|
Oracle 关系型数据库 测试技术
[20150804]提升scn3.txt
[20150804]提升scn3.txt --上午做了做了提升scn的试验,在10g下费劲周折到下午才测试通过。参考连接。 http://blog.itpub.net/267265/viewspace-1761508/ --下午在11g下测试看看。
725 0