关于SCN另外两个有趣的知识点

Posted: March 24, 2012 | Author: | Filed under: Oracle | 9 Comments »

首先声明一下，这篇文章的结论来源于我昨天在机场接姗姗妈的时候跟大熊的讨论，并不是我的原创。

 

在步入正题之前，先普及一下关于Oracle里SCN的基本知识点：

1、Oracle的SCN在每秒16384次commit的情况下可以维持534年，每秒16384次commit是Oracle早先认为的任何系统的极限commit强度；

2、Oracle里SCN的起点是1988年1月1日；

3、_minimum_giga_scn=n的含义是把SCN往前推进到nG，但请注意，只有在SCN小于nG的时候才会用到这个隐含参数，反之则Oracle会置这个隐含参数于不顾。

 

好了，我们进入正题，这篇文章里要阐述的两个关于SCN的有趣的知识点如下：

1、SCN会随着dblink从高向低扩散；

2、过大的SCN可能会导致Oracle数据库打不开；

 

好了，我们来看两个证明上述观点的实例：

一、SCN会随着dblink从高向低扩散：

先连到名为cuihua的10.2.0.1的库：

SQL> conn sys/oracle@cuihua as sysdba;

Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.1.0

Connected as SYS

 

可以看到系统目前的SCN：

SQL> select dbms_flashback.get_system_change_number() from dual;

 

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

                    1073742134

 

当然，这个SCN会随着时间的推移而增长：

SQL> select dbms_flashback.get_system_change_number() from dual;

 

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

                    1073742140

 

这个库目前的对象数为51831：

SQL> select count(*) from dba_objects;

 

  COUNT(*)

———-

     51831

 

再另起一个session，连到名为cuihua112的11.2.0.1的库：

SQL> conn sys/oracle@cuihua112 as sysdba;

Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.1.0

Connected as SYS

 

从cuihua112中创建一个到上述10.2.0.1的库cuihua的dblink：

SQL> create public database link cuihua connect to scott identified by tiger using ‘cuihua’;

 

Database link created

 

可以看到在cuihua112中，系统目前的SCN仅为2100672：

SQL> select dbms_flashback.get_system_change_number() from dual;

 

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

                       2100672

 

当然，这个SCN会随着时间的推移而增长，但是增长的幅度有限（因为这个库很闲，我什么事情也没做）：

SQL> select dbms_flashback.get_system_change_number() from dual;

 

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

                       2100673

 

接着，我通过刚建的dblink去查一下cuihua中的对象数，结果是51831，和之前的查询结果一致：

SQL> select count(*) from dba_objects@cuihua;

 

  COUNT(*)

———-

     51831

 

接着我们马上再次查询系统的SCN，发现结果已经从之前的2100673猛增到1073742966，这个实际上已经足以证明SCN会随着dblink从高向低扩散：

SQL> select dbms_flashback.get_system_change_number() from dual;

 

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

                    1073742966

 

 

好了，我们再来看第二个实例：

二、过大的SCN可能会导致Oracle数据库打不开（我只测试了10.2.0.1）

现在这个名为10.2.0.1的库cuihua是可以正常打开的：

SQL> startup pfile=’D:\oracle\oradata\cuihua\initcuihua.ora’

ORACLE 例程已经启动。

 

Total System Global Area  608174080 bytes

Fixed Size                  1250404 bytes

Variable Size             209718172 bytes

Database Buffers          390070272 bytes

Redo Buffers                7135232 bytes

数据库装载完毕。

数据库已经打开。

 

今天是2012年3月24日：

SQL> select sysdate from dual;

 

SYSDATE

——————————

2012-3-24 22:04:17

 

2012年3月24日距离1988年1月1日有290.741935月：

SQL> select months_between (to_date(’20120324′,’YYYYMMDD’),to_date(’19880101′,’YYYYMMDD’) ) “MONTHS” from dual;

 

    MONTHS

———-

290.741935

 

在每秒16384的极限commit强度下，要超过当前时间（即要超过290.741935月，我这里选用了300），只需要将_minimum_giga_scn递增到12260即可：

SQL> select 16384*60*60*24*31*300/(1024*1024*1024) SCN from dual;

 

       SCN

———-

12260.7421

 

Shutdown上述库：

SQL> shutdown immediate;

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

 

修改initcuihua.ora文件，添加*._minimum_giga_scn=12260：

*.undo_management=’AUTO’

*.undo_retention=3600

*.undo_tablespace=’UNDOTBS1′

*.user_dump_dest=’D:\oracle\admin\cuihua\udump’

*._minimum_giga_scn=12260

 

改完后再启库的时候发现已经启动不了了，但这里Oracle报的错误是莫名其妙的：

SQL> startup pfile=’D:\oracle\oradata\cuihua\initcuihua.ora’

ORACLE 例程已经启动。

 

Total System Global Area  608174080 bytes

Fixed Size                  1250404 bytes

Variable Size             209718172 bytes

Database Buffers          390070272 bytes

Redo Buffers                7135232 bytes

数据库装载完毕。

ORA-01052: 未指定所需的目标 LOG_ARCHIVE_DUPLEX_DEST

 

SQL> select status from v$instance;

 

STATUS

————

MOUNTED

 

SQL> shutdown immediate;

ORA-01109: 数据库未打开

 

 

已经卸载数据库。

ORACLE 例程已经关闭。

 

再在cuihua112中计算一下，不超过当前时间（即不超过290.741935月，我这里选用了280）的_minimum_giga_scn的值应该是11443：

SQL> select 16384*60*60*24*31*280/(1024*1024*1024) SCN from dual;

 

       SCN

———-

11443.3593

 

修改initcuihua.ora文件，将_minimum_giga_scn的值改为11443：

*.undo_management=’AUTO’

*.undo_retention=3600

*.undo_tablespace=’UNDOTBS1′

*.user_dump_dest=’D:\oracle\admin\cuihua\udump’

*._minimum_giga_scn=11443

 

改完后上述库又可以成功启动了：

SQL> startup pfile=’D:\oracle\oradata\cuihua\initcuihua.ora’

ORACLE 例程已经启动。

 

Total System Global Area  608174080 bytes

Fixed Size                  1250404 bytes

Variable Size             209718172 bytes

Database Buffers          390070272 bytes

Redo Buffers                7135232 bytes

数据库装载完毕。

数据库已经打开。

 

SQL> select dbms_flashback.get_system_change_number() from dual;

 

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

                12286827692577

 

从结果里可以看到，SCN确实被我们推进到了我们想要推进的值：

SQL> select dbms_flashback.get_system_change_number()/(1024*1024*1024) from dual;

 

DBMS_FLASHBACK.GET_SYSTEM_CHAN

——————————

              11443.0000005225

 

如何用AMDU从不能mount的ASM磁盘组中往外抽取数据文件

Posted: March 4, 2012 | Author: | Filed under: Oracle | 2 Comments »

AMDU是Oracle 11g里自带的一个免费的工具，用于分析ASM磁盘组的元数据以及从不能mount的磁盘组中往外抽取数据文件。

“NOTE:553639.1 Placeholder for AMDU binaries and using with ASM 10g”明确指出：AMDU也可用于10g，并提供了可用于10g的AMDU的各个操作系统的版本供大家下载。

 

AMDU的原理是解析file directory，这一点ODU也是一样，只不过ODU做的更彻底一些，即使file directory全部损坏，ODU也可以把数据文件抽取出来，尽最大的可能挽救用户的数据。

 

我们来看一个用AMDU从不能mount的磁盘组中往外抽取数据文件的实例：

我们现在shutdown Oracle实例和ASM实例：

[root@bspdev odu]# su – oracle

[oracle@bspdev ~]$ sqlplus ‘/ as sysdba’;

 

SQL*Plus: Release 11.2.0.1.0 Production on Thu Feb 23 10:43:36 2012

 

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

 

 

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – Production

With the Partitioning, Automatic Storage Management, OLAP, Data Mining

and Real Application Testing options

 

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

 

SQL> exit

Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – Production

With the Partitioning, Automatic Storage Management, OLAP, Data Mining

and Real Application Testing options

 

[oracle@bspdev ~]$ su – grid

Password:

[grid@bspdev ~]$ sqlplus ‘/ as sysasm’;

 

SQL*Plus: Release 11.2.0.1.0 Production on Thu Feb 23 10:45:05 2012

 

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

 

 

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – Production

With the Automatic Storage Management option

 

SQL> shutdown immediate

ASM diskgroups dismounted

ASM instance shutdown

 

SQL> exit

Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – Production

With the Automatic Storage Management option

 

[grid@bspdev ~]$ crsctl status res

NAME=ora.DATA.dg

TYPE=ora.diskgroup.type

TARGET=OFFLINE

STATE=OFFLINE

 

NAME=ora.LISTENER.lsnr

TYPE=ora.listener.type

TARGET=ONLINE

STATE=ONLINE on bspdev

 

NAME=ora.RECO.dg

TYPE=ora.diskgroup.type

TARGET=OFFLINE

STATE=OFFLINE

 

NAME=ora.asm

TYPE=ora.asm.type

TARGET=OFFLINE

STATE=OFFLINE

 

NAME=ora.cssd

TYPE=ora.cssd.type

TARGET=ONLINE

STATE=ONLINE on bspdev

 

NAME=ora.diskmon

TYPE=ora.diskmon.type

TARGET=ONLINE

STATE=ONLINE on bspdev

 

NAME=ora.ora11g.db

TYPE=ora.database.type

TARGET=OFFLINE

STATE=OFFLINE

 

在ASM diskgroup不能mount的情况下asmcmd不能使用：

[grid@bspdev ~]$ asmcmd

Connected to an idle instance.

ASMCMD> ls

ASMCMD-08102: no connection to ASM; command requires ASM to run

 

但此时ODU内嵌的asmcmd是可以使用的，所以我们可以轻易的使用ODU内嵌的asmcmd命令来得到所有的datafile的名称：

[grid@bspdev ~]$ su -

Password:

[root@bspdev ~]# cd /u01/app/oracle/odu

[root@bspdev odu]# ./odu

 

Oracle Data Unloader:Release 4.2.1

 

Copyright (c) 2008,2009,2010,2011 XiongJun. All rights reserved.

 

Web: http://www.oracleodu.com

Email: magic007cn@gmail.com

 

loading default config…….

 

byte_order little

block_size  8192

block_buffers 1024

db_timezone -7

Invalid db timezone:-7

client_timezone 8

Invalid client timezone:8

asmfile_extract_path   /odu/asmfile

data_path   data

lob_path    /odu/data/lob

charset_name AL32UTF8

ncharset_name AL16UTF16

output_format text

lob_storage infile

clob_byte_order big

trace_level 1

delimiter |

unload_deleted no

file_header_offset 0

is_tru64 no

record_row_addr no

convert_clob_charset yes

use_scanned_lob  yes

trim_scanned_blob yes

lob_switch_dir_rows 20000

db_block_checksum yes

db_block_checking yes

rdba_file_bits 10

compatible 10

load config file ‘config.txt’ successful

loading default asm disk file ……

 

 

grp# dsk# bsize ausize disksize diskname        groupname       path

—- —- —– —— ——– ————— ————— ——————————————–

   1    0  4096  1024K     9000 DATA_0000       DATA            /dev/sda3

   1    1  4096  1024K     9000 DATA_0001       DATA            /dev/sda5

   1    2  4096  1024K     9000 DATA_0002       DATA            /dev/sda6

   2    0  4096  1024K     9000 RECO_0000       RECO            /dev/sda7

   2    1  4096  1024K     7288 RECO_0001       RECO            /dev/sda8

 

load asm disk file ‘asmdisk.txt’ successful

loading default control file ……

 

 

 ts#   fn  rfn bsize   blocks bf offset filename

—- —- —- —– ——– — —— ——————————————–

load control file ‘control.txt’ successful

loading dictionary data……done

 

loading scanned data……done

 

ODU> asmcmd 

 

Entering asmcmd module.

 

ASMCMD> ls

 

Current directory: <root>

 

Disk Group

————————————

DATA

RECO

 

ASMCMD> cd +DATA

 

Current directory: +DATA

 

ASMCMD> ls  

 

Current directory: +DATA

 

Name                                   

—————————————-

ASM                                       <DIR>

ORA11G                                    <DIR>

 

ASMCMD> cd ORA11G

 

Current directory: +DATA/ORA11G

 

ASMCMD> ls

 

Current directory: +DATA/ORA11G

 

Name                                   

—————————————-

DATAFILE                                  <DIR>

CONTROLFILE                               <DIR>

ONLINELOG                                 <DIR>

TEMPFILE                                  <DIR>

PARAMETERFILE                             <DIR>

spfileora11g.ora                           => +DATA.265.747311071

 

ASMCMD> cd DATAFILE   

 

Current directory: +DATA/ORA11G/DATAFILE

 

可以看到，当前的第259号（这个259是ASM的internal file number）文件名称为+DATA/ORA11G/DATAFILE / USERS.259.747310451：

ASMCMD> ls

 

Current directory: +DATA/ORA11G/DATAFILE

 

Name                                   

—————————————-

SYSTEM.256.747310449                   

SYSAUX.257.747310449                   

UNDOTBS1.258.747310451                 

USERS.259.747310451                    

MYTEST.266.761050749                   

GAOZCINDEX.267.770299335               

GAOZCINDEX1                                => +DATA.267.770299335

GAOZCDATA.268.770299347                

GAOZCDATA1                                 => +DATA.268.770299347

 

现在我们用AMDU把这个文件给抽出来，注意现在这个文件所在的磁盘组DATA还是处于unmount状态。

用AMDU抽取数据文件的语法非常简单，只需要指定磁盘组所在的设备文件名称（可以用*号模糊匹配），以及磁盘组的名称和待抽取的数据文件号（这里的数据文件号是指ASM的internal file number）就可以了：

[root@bspdev odu]# /u01/app/oracle/bin/amdu -diskstring ‘/dev/sda*’ -extract ‘DATA.259′

amdu_2012_02_23_11_21_34/

 

进入上述目录，可以看到抽取出的第259号文件DATA_259.f已经生成：

[root@bspdev odu]# cd amdu_2012_02_23_11_21_34

 

[root@bspdev amdu_2012_02_23_11_21_34]# ls -lrt

total 39744

-rw-r–r–. 1 root root     8600 Feb 23 11:21 report.txt

-rw-r–r–. 1 root root 40640512 Feb 23 11:21 DATA_259.f

 

我们现在再用ODU把259号文件提出来，跟AMDU做一个对比：

[root@bspdev amdu_2012_02_23_11_21_34]# cd ..

[root@bspdev odu]# ./odu

 

Oracle Data Unloader:Release 4.2.1

 

Copyright (c) 2008,2009,2010,2011 XiongJun. All rights reserved.

 

Web: http://www.oracleodu.com

Email: magic007cn@gmail.com

 

loading default config…….

 

byte_order little

block_size  8192

block_buffers 1024

db_timezone -7

Invalid db timezone:-7

client_timezone 8

Invalid client timezone:8

asmfile_extract_path   /odu/asmfile

data_path   data

lob_path    /odu/data/lob

charset_name AL32UTF8

ncharset_name AL16UTF16

output_format text

lob_storage infile

clob_byte_order big

trace_level 1

delimiter |

unload_deleted no

file_header_offset 0

is_tru64 no

record_row_addr no

convert_clob_charset yes

use_scanned_lob  yes

trim_scanned_blob yes

lob_switch_dir_rows 20000

db_block_checksum yes

db_block_checking yes

rdba_file_bits 10

compatible 10

load config file ‘config.txt’ successful

loading default asm disk file ……

 

 

grp# dsk# bsize ausize disksize diskname        groupname       path

—- —- —– —— ——– ————— ————— ——————————————–

   1    0  4096  1024K     9000 DATA_0000       DATA            /dev/sda3

   1    1  4096  1024K     9000 DATA_0001       DATA            /dev/sda5

   1    2  4096  1024K     9000 DATA_0002       DATA            /dev/sda6

   2    0  4096  1024K     9000 RECO_0000       RECO            /dev/sda7

   2    1  4096  1024K     7288 RECO_0001       RECO            /dev/sda8

 

load asm disk file ‘asmdisk.txt’ successful

loading default control file ……

 

 

 ts#   fn  rfn bsize   blocks bf offset filename

—- —- —- —– ——– — —— ——————————————–

   0    1    1  8192   112640 N       0 +DATA/ORA11G/DATAFILE/SYSTEM.256.747310449

   1    2    2  8192   119040 N       0 +DATA/ORA11G/DATAFILE/SYSAUX.257.747310449

   2    3    3  8192    70400 N       0 +DATA/ORA11G/DATAFILE/UNDOTBS1.258.747310451

   4    4    4  8192     4960 N       0 +DATA/ORA11G/DATAFILE/USERS.259.747310451

load control file ‘oductl.dat’ successful

loading dictionary data……done

 

loading scanned data……done

 

ODU> asmcmd

 

Entering asmcmd module.

 

注意：ODU的最新版本中extract命令已被copy命令替换了：

ASMCMD> extract asmfile +DATA/ORA11G/DATAFILE/USERS.259.747310451 to /u01/app/oracle/odu/amdu_2012_02_23_11_21_34/user01.dbf

 

starting extract asm file ‘+DATA/ORA11G/DATAFILE/USERS.259.747310451′ to ‘/u01/app/oracle/odu/amdu_2012_02_23_11_21_34/user01.dbf’,file size is 40640512

asm file extract completed.

 

ASMCMD> exit

 

Exiting asmcmd module.

 

[root@bspdev odu]# cd amdu_2012_02_23_11_21_34

[root@bspdev amdu_2012_02_23_11_21_34]# ls -lrt

total 79476

-rw-r–r–. 1 root root     8600 Feb 23 11:21 report.txt

-rw-r–r–. 1 root root 40640512 Feb 23 11:21 DATA_259.f

-rw-r–r–. 1 root root 40640512 Feb 23 11:27 user01.dbf

从结果里可以看到，两者大小一模一样。

 

从dbv校验的结果来看，两者内容也是一模一样：

[oracle@bspdev ~]$ dbv file=/u01/app/oracle/odu/amdu_2012_02_23_11_21_34/DATA_259.f blocksize=8192

 

DBVERIFY: Release 11.2.0.1.0 – Production on Thu Feb 23 11:29:50 2012

 

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

 

DBVERIFY – Verification starting : FILE = /u01/app/oracle/odu/amdu_2012_02_23_11_21_34/DATA_259.f

 

 

DBVERIFY – Verification complete

 

Total Pages Examined         : 4960

Total Pages Processed (Data) : 4442

Total Pages Failing   (Data) : 0

Total Pages Processed (Index): 33

Total Pages Failing   (Index): 0

Total Pages Processed (Other): 334

Total Pages Processed (Seg)  : 0

Total Pages Failing   (Seg)  : 0

Total Pages Empty            : 151

Total Pages Marked Corrupt   : 0

Total Pages Influx           : 0

Total Pages Encrypted        : 0

Highest block SCN            : 2132237218 (1932.2132237218)

 

[oracle@bspdev ~]$ dbv file=/u01/app/oracle/odu/amdu_2012_02_23_11_21_34/user01.dbf blocksize=8192

 

DBVERIFY: Release 11.2.0.1.0 – Production on Thu Feb 23 11:30:11 2012

 

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

 

DBVERIFY – Verification starting : FILE = /u01/app/oracle/odu/amdu_2012_02_23_11_21_34/user01.dbf

 

 

DBVERIFY – Verification complete

 

Total Pages Examined         : 4960

Total Pages Processed (Data) : 4442

Total Pages Failing   (Data) : 0

Total Pages Processed (Index): 33

Total Pages Failing   (Index): 0

Total Pages Processed (Other): 334

Total Pages Processed (Seg)  : 0

Total Pages Failing   (Seg)  : 0

Total Pages Empty            : 151

Total Pages Marked Corrupt   : 0

Total Pages Influx           : 0

Total Pages Encrypted        : 0

Highest block SCN            : 2132237218 (1932.2132237218)