ORACLE数据块中的SCN是如何变化的？
[问题点数：40分]
ORACLE数据块中的SCN是如何变化的？
[问题点数：40分]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
本帖子已过去太久远了，不再提供回复功能。博客访问： 658967
博文数量： 349
注册时间：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： Linux
年初的时候拜读完了eygle写的《深入潜出》这本书，感觉收获很大。正好可以总结一下SCN和checkpoint这两个东东。Checkpoint很多人都把checkpoint的概念给复杂化了，其实checkpoint这个数据库概念引入的真正意义就是用来减少在数据库恢复过程中所花的时间(instance recovery),那么checkpoint是又谁来做的呢？我们都知道数据库中有个CKPT进程，这个是个可选进程，但是真正执行检查点的任务并不是有ckpt来完成的，而是ckpt在更新控制文件和数据文件头的有关信息后，通知DBWn进程，产生一个检查点，在产生检查点的时候，DBWn进程会将buffer cache中的脏数据(当前online redo log对应的脏数据)，写入我们的数据文件当中。那么这个时候如果数据库此时崩溃（比如我们做个shutdown abort），那么在进行实例恢复的时候就可以不需要当前online redo log的内容了，会很快就做完。因此ckpt进程只是个辅助进程，他的任务更多的是用来在系统做checkpoint的时候更新控制文件和数据文件头中的信息。其实在oracle 8i的时候呢，ckpt的任务一般都是由lgwr进程来完成，到了8i以后，随着CKPT进程的引入，lgwr的工作负担就减轻了很多(commit的速度加快了)那么如何来产生检查点呢？有三种方法，可以通过1.alter system checkpoint2.alter system switch logfile3.DBWn进程写出脏块SCN在Oracle中理解为一个内部同步时钟，是系统改变号的缩写（system change number）,在Oracle数据库中我们可以通过dbms_flashback包来查询当前系统的改变号：select dbms_flashback.get_system_change_一般来讲SCN主要是用来标识数据库所做的所有改变，这个SCN的改变是只能前进，不能回退，除非我们打算重建库，数据库中的SCN永远不会归0，一般来说SCN的前进触发是由commit来进行的，除了这些据我观察每隔3秒种系统也都会刷新一次SCN.需要注意的是：1.CKPT一定是是在checkpoint发生的时候将数据库当前的SCN更新入数据库文件头和控制文件当中，同时DBWn进程将buffer cache中的脏数据块（dirty block）写到数据文件当中(这个脏数据也一定是当前online redo log保护的那一部分)。
2.同时CKPT进程还会在控制文件当中记录(redo block address)RBA，这个地址用来标志恢复的时候需要从日志中的那个位置开始。
在Oracle数据库中和checkpoint相关的SCN总共有4个1.System checkpoint SCN& (存在于控制文件)在系统执行checkpoint后，Oracle会更新当前控制文件中的System checkpoint SCN。我们可以通过select checkpoint_change# from v$database:来查看
2.Datafile checkpoint SCN (存在于控制文件)由于控制文件中记录了Oracle中各个数据库文件的位置和信息，其中当然也包括了Datafile checkpoint SCN，因此在执行checkpoint的时候，Oracle还会去更新控制文件中所记录的各个数据文件的datafile checkpoint SCN.我们可以通过select checkpoint_change#& from v$来查看
3.Start SCN (存在于各个数据文件头)在执行checkpoint时，Oracle会更新存放在各个实际的数据文件头的Start SCN（注意绝对不会是控制文件中），这个SCN存在的目的是用于检查数据库启动过程中是否需要做media recovery(介质恢复)我们可以通过select checkpoint_change# from v$datafile_
4.End SCN(存在于控制文件)最后一类SCN,End SCN他也是记录在控制文件当中，每一个所记录的数据文件头都有一个对应的End SCN,这个End SCN一定是存在于控制文件当中。这个SCN存在的绝对意义主要是用来去验证数据库启动过程中是否需要做instance recovery。我们可以通过select name,last_change# from v$datafile那么其实在数据库正常运行的情况下，对于read/write的online 数据文件这个SCN号为#FFFFFF(NULL).下面来聊一聊SCN号于数据库的启动1.在数据库的启动过程中，当System Checkpoint SCN=Datafile Checkpoint SCN=Start SCN的时候，Oracle数据库是可以正常启动的，而不需要做任何的media recovery。而如果三者当中有一个不同的话，则需要做media recovery2.那什么时候需要做instance recovery呢？其实在正常open数据库的时候，oracle会将记录在控制文件中的每一个数据文件头的End SCN都设置为#FFFFFF(NULL)，那么如果数据库进行了正常关闭比如(shutdown or shutdown immediate)这个时候，系统会执行一个检查点，这个检查点会将控制文件中记录的各个数据文件头的End SCN更新为当前online数据文件的各个数据文件头的Start SCN,也就是End SCN=Start SCN,如果再次启动数据库的时候发现二者相等，则直接打开数据库，并再次将End SCN设置为#FFFFFF(NULL),那么如果数据库是异常关闭，那么checkpoint就不会执行，因此再次打开数据库的时候End SCNStart SCN这个时候就需要做实例恢复。说了那么多更新SCN操作什么的，这个更新操作到底是由谁做的呢？其实刚才已经说过了，就是我们的CKPT进程，他不仅仅会更新SCN，而且还会通知DBWn做他的事情。再说一下System Checkpoint SCN和Datafile Checkpoint SCN,这两个SCN都是记录在控制文件当中的。但是这两个SCN有什么作用呢？logzgh有段论述，我自己的想了一下，还是学习一下他的结论：1.对只读表空间，其数据文件的Datafile Checkpoint SCN、Start SCN和END SCN号均相同。这三个SCN在表空间处于只读期间都将被冻结。2.如果控制文件不是当前的控制文件(其实就是说，想比当前redo log的SCN来讲，控制文件已经过时了)，则System checkpoint SCN会小于Start SCN(Start SCN是来自实际的数据文件头，有比较依据)。记录这些SCN号，可以区分控制文件是否是当前的控制文件。当有一个Start SCN(从当前各个在线数据文件中获得)号超过了System Checkpoit SCN号时，则说明控制文件不是当前的控制文件，因此在做recovery时需要采用using backup controlfile。这是为什么需要记录SystemCheckpoint SCN的原因之一。当我们重建控制文件的时候，重建方式分两种（resetlogs 和 noresetlogs）1.使用resetlogs选项时，System Checkpoint SCN为被归为0，而其中记录的各个数据文件的Datafile Checkpoint SCN则来自于Start SCN（也就是说可能会从冷备份的数据文件的数据文件头中获取）。根据上述的描述，此时需要采用using backup controlfile做recovery. 因此情况是 System Checkpoint SCN=0 < Start SCN = Datafile Checkpoint SCN2.使用noresetlogs选项时，有一个前提就是：一定要有online redo log的存在。否则就要使用resetlogs选项。这个时候控制文件重建好时，其system checkpoint SCN=Datafile Checkpoint SCN=Lastest Checkpoint SCN in online redo log,我们可以看到Datafile Checkpoint SCN并没有从Start SCN中读取。而是读取了最新的日志文件中的SCN作为自己的数据。此时重建的控制文件在恢复中的作用跟最新的控制文件类似，System Checkpoint SCN(已经读取最新的redo log的checkpoint SCN信息)可能会>Start SCN （因为数据文件可能会从冷备份中恢复），恢复时就不需要加using backup controlfile子句了关于backup controlfile的补充：backup controlfile只有备份时刻的archive log信息，并没有DB crash时刻的archive log信息，所以并不会自动应用online redo log,而是提示找不到序号为Lastest Archive log sequence + 1 的archive log,尽管你可以手动指定online redo log来实现完全恢复，但因为一旦使用了using backup controlfile子句，Oracle就视为不完全恢复，必须open resetlogs! 实际上，假如你有旧的控制文件又不想resetlogs，那很简单，使用旧的控制文件mount然后 backup to trace ，然后手工创建控制文件，使用 reuse database ... noresetlogs .这样就可以 recover database 自动恢复并open database 而不用 resetlogs 了
阅读(5725) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
呵呵，不错~确实是本很好的书：）以后多交流
请登录后评论。博客访问： 540181
博文数量： 219
博客积分： 5308
博客等级： 大校
技术积分： 2151
注册时间：
DevOps让系统管理更轻松。
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： Oracle
在oracle数据库中我们可以利用oracle的内部事件调整SCN。增进SCN通常有两种常用方法:
1.alter session set events 'IMMEDIATE trace name ADJUST_SCN level x';
--需要数据库OPEN
2.通过10015事件
alter session set events '10015 trace name adjust_scn level x';
--在数据库无法打开，mount状态下。
注:level 1为增进SCN 10亿 (1 billion) (24=)
SQL> select dbms_flashback.get_system_change_
GET_SYSTEM_CHANGE_NUMBER------------------------&&&&&&&&&&&&&&&&& 571904
SQL> alter session set events 'IMMEDIATE trace name ADJUST_SCN level 1';
Session altered
--10g的告警日志会报这样的错：
Tue Mar 31 17:01:00 2009Errors in file c:\oracle\product\10.2.0\admin\orasjh\udump\orasjh_ora_2208.trc:ORA-01031: 权限不足
查看trace文件，有这样的报错：
Clearing ORA-1031 thrown by trace 'ADJUST_SCN'----- Dump for trace 'ADJUST_SCN': -----***
17:01:00.828ksedmp: internal or fatal errorORA-01031: 权限不足Current SQL statement for this session:
我在9i测试是没问题的。
SQL> select dbms_flashback.get_system_change_
GET_SYSTEM_CHANGE_NUMBER------------------------&&&&&&&&&&&&&
在测试一下在数据库关闭的情况下SCN的增进。
SQL>数据库已经关闭。已经卸载数据库。ORACLE 例程已经关闭。SQL>
SQL> startup mountORACLE 例程已经启动。
Total System Global Area&
bytesFixed Size&&&&&&&&&&&&&&&&&& 453552 bytesVariable Size&&&&&&&&&&&&
bytesDatabase Buffers&&&&&&&&&&
bytesRedo Buffers&&&&&&&&&&&&&&&& 667648 bytes数据库装载完毕。SQL> alter session set events '10015 trace name adjust_scn level 10';
会话已更改。
数据库已更改。
SQL> select dbms_flashback.get_system_change_
GET_SYSTEM_CHANGE_NUMBER------------------------&&&&&&&&&&&&& 1.0737E+10
增进SCN的意义？
在解决ORA-00600: internal error code, arguments: [2662]错误的时候会用到。
这里转载一个案例：
参考地址：
客户那边数据库突然出现一个current日志文件坏了，导致数据库crash了，然后现场工程师使用_ALLOW_RESETLOGS_CORRUPTION = TRUE这个隐含参数，做了不完全恢复后强行将数据库打开。可是打开数据库后发现只能用internal用户连接进去，别的用户连接都报错，错误信息如下：
ORA-00600: internal error code, arguments: [2662], [0], [], [0], [], [0], [], []
查询不了任何应用的表，应用也没法使用，于是想尝试全库的exp出来然后重新imp进去建库，结果发现exp数据也不成功，也是报同样的ORA-600的错误，用户当时数据没有任何的备份过，只能想办法尽量打开数据库，导出数据了。
处理过程：
先检查了600错误产生的trace文件：
*** SESSION ID:(7.15) 2004.11.23.23.28.16.824ksedmp: internal or fatal errorORA-00600: internal error code, arguments: [2662], [0], [], [0], [], [0], [], []Current SQL statement for this session:SELECT * FROM "WHSB"."SB_BSBF"&
得到的信息有限，只能看到是严重内部错误，剩下的都是内存堆栈的一堆信息，于是查找了一下这个错误的具体相关信息。
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.
我们分析错误中的提示，它的参数b=,d=,表明当前的SCN确实是小于dependent SCN，所以产生了这个600的错误。通过查阅文档，发现这个错误的产生原因主要有以下几条：
1.使用隐含参数_ALLOW_RESETLOGS_CORRUPTION后resetlogs打开数据库
2.硬件错误引起数据库没法写控制文件和重做日志文件
3.错误的部分恢复数据库
4.恢复了控制文件但是没有使用recover database using backup controlfile进行恢复
5.数据库crash后设置了_DISABLE_LOGGING隐含参数
6.在并行服务器环境中DLM存在问题
仔细对比了一下，发现问题可能是由于第一条产生的，由于设置了_ALLOW_RESETLOGS_CORRUPTION这个隐含参数后，虽然强制性的打开数据库，但是数据库本身存在了corruption，仍然存在严重的问题。于是想到使用ADJUST_SCN事件来调整当前的SCN，使其大于dependent SCN，然后保证数据库可以全库的导出，然后重建数据库导入数据。用internal用户登陆数据库后，连接别的用户，还是失败报错，执行：
alter session set events 'IMMEDIATE trace name ADJUST_SCN level 1';&
然后尝试连接别的用户，连接成功。最后exp整个数据库，重建数据库后导入数据，整个数据库恢复成功！
通过这个实例，我们可以看到，尽量的不要去使用那些隐含参数，这些参数是oracle所不推荐使用的，也不是万能的！如果使用了可能会存在一些遗留的问题，如果非要使用，建议使用后一定要exp/imp重建建立数据库。
阅读(1590) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。