设为首页 收藏本站

运维网

 找回密码
 立即注册
查看: 834|回复: 0

[经验分享] Oracle体系结构之SCN、实例恢复

[复制链接]
旃麒雅

尚未签到
发表于 2018-9-23 06:44:39 | 显示全部楼层 |阅读模式
　　SCN：System Change Number
　　SCN是Oracle数据库的一个逻辑的内部时间戳，用以标识数据库在某个确切时刻提交的版本。在事务提交或回滚时，它被赋予一个惟一的标识事务的SCN，用来保证数据库的一致性。
SQL> select dbms_flashback.get_system_change_number, SCN_TO_TIMESTAMP(dbms_flashback.get_system_change_number) from dual;　　
GET_SYSTEM_CHANGE_NUMBER SCN_TO_TIMESTAMP(DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER)
　　
------------------------ -------------------------------------------------------
　　
1819076 06-JUL-13 11.40.12.000000000 PM
　　
SQL>select  current_scn from v$database;
　　
CURRENT_SCN
　　
-----------
　　
1819065
　　SCN在数据库中是无处不在的，常见的控制文件、数据文件头部、日志文件等都记录有SCN。
　　控制文件中

  • 　　系统检查点SCN(System Checkpoint SCN)
SQL> select checkpoint_change# from v$database;　　
CHECKPOINT_CHANGE#
　　
------------------
　　
1809219

  • 　　文件检查点SCN(Datafile Checkpoint SCN)
  • 　　文件结束SCN(Stop SCN)
SQL> select name,checkpoint_change#,last_change# from v$datafile;　　
NAME                                          CHECKPOINT_CHANGE# LAST_CHANGE#
　　
--------------------------------------------- ------------------ ------------
　　
+DATA/orcl/datafile/system.256.817343229                 1809219
　　
+DATA/orcl/datafile/sysaux.257.817343231                 1809219
　　
+DATA/orcl/datafile/undotbs1.258.817343231               1809219
　　
+DATA/orcl/datafile/users.259.817343231                  1809219
　　
+DATA/orcl/datafile/example.265.817343543                1809219
　　数据文件头部

  • 　　开始SCN(Start SCN)
SQL> select checkpoint_change# from v$datafile_header;　　
CHECKPOINT_CHANGE#
　　
------------------
　　
1809219
　　
1809219
　　
1809219
　　
1809219
　　
1809219
　　日志文件中

  • 　　FIRST SCN：redo log file中第一条日志的SCN
  • 　　NEXT SCN：redo log file中最后一条日志的SCN(即下一个redo log file的第一条日志的SCN)
　　通常,只有当前的重做日志文件组写满后才发生日志切换,但是可以通过设置参数ARCHIVE_LOG_TARGET控制日志切换的时间间隔,在必要时也可以采用手工强制进行日志切换.
　　一组redo log file写满后，会自动切换到下一组redo log file。上一组redo log的High SCN就是下一组redo log的Low SCN,且对于Current日志文件的High SCN为无穷大(FFFFFFFF)。
SQL> select group#,sequence#,status,first_change#,next_change# from v$log;　　
GROUP#  SEQUENCE# STATUS           FIRST_CHANGE#       NEXT_CHANGE#
　　
---------- ---------- ---------------- ------------- ------------------
　　
1         34 INACTIVE               1746572            1770739
　　
2         35 INACTIVE               1770739            1808596
　　
3         36 CURRENT                1808596    281474976710655
　　实例崩溃恢复：
　　在open数据库时,Oracle通过控制文件进行了以下验证：

  • 　　检查数据文件头部所记录的Start SCN 和控制文件中所记录的System Checkpoint SCN 是否一致,若不同则需要进行介质恢复
  • 　　检查数据文件头部所记录的Start SCN 和控制文件中记录的Stop SCN是否也一致,若不同则需要进行实例恢复.
　　如果两个都一致了,说明所有已被修改的数据块已经写入到了数据文件中,才可以正常open,
　　当数据库open并正常运行期间,系统SCN、文件SCN和数据文件头部的开始SCN都是一致的,且(大于或)等于ACTIVE/CURRENT日志文件的最小FIRST SCN,但文件结束SCN为NULL(无穷大);
　　当数据库正常关闭时,Oracle通过完全检查点将buffer cache中的所有缓存写到磁盘上,同时根据关闭数据库的时间点更新控制文件中的系统SCN、文件SCN、结束SCN和数据文件头部中的开始SCN,且SCN都是一致的,且LRBA指针指向on disk RBA,否则需要前滚;
　　当数据库非正常关闭(崩溃/掉电)后启动实例时,Oracle将检测到控制文件中的系统SCN、文件SCN和数据文件头部的开始SCN都是一致的,但是结束SCN为NULL,则在需要参与实例崩溃恢复的redo log file中根据控制文件中记录的LRBA地址(前滚起点)和on disk RBA(前滚终点)地址找出相应的日志项进行实例崩溃恢复,最终才可将数据库open.
　　实例恢复的详细过程：

  • 　　前滚阶段(前滚靠redo,又叫缓冲区恢复cache recovery,即负责恢复已经在内存中但还没有写入数据文件中的内容)
　　Oracle是按照redo log file的记录来前滚的(不管有没有commit),所以前滚完成后,data file中可能会有没有提交的数据(所以需要后面的回退过程).
　　另外,由于undo的生成也是要记录redo log的,所以还会按照redo重新生成后面回退时需要的undo信息.

  • 　　数据库open阶段
　　前滚完毕后,数据库中所有已被修改的数据块已经写入到了数据文件中才可以正常open

  • 　　回滚阶段(回滚靠undo,又叫事务恢复transaction recoery,即负责回退实例崩溃前没有提交的事务)
　　正常关闭数据库时：
　　系统SCN、文件SCN、结束SCN和数据文件头部中的开始SCN都是相等的，且(大于或)等于ACTIVE/CURRENT日志文件中的最小FIRST SCN
SQL> shutdown immediate　　
Database closed.
　　
Database dismounted.
　　
ORACLE instance shut down.
　　
SQL> startup mount
　　
ORACLE instance started.
　　
Total System Global Area  459304960 bytes

　　
Fixed>
　　
Variable>　　
Database Buffers          159383552 bytes
　　
Redo Buffers                8298496 bytes
　　
Database mounted.
　　
SQL>  select checkpoint_change# from v$database;
　　
CHECKPOINT_CHANGE#
　　
------------------
　　
1822573
　　
SQL>  select name,checkpoint_change#,last_change# from v$datafile;
　　
NAME                                          CHECKPOINT_CHANGE# LAST_CHANGE#
　　
--------------------------------------------- ------------------ ------------
　　
+DATA/orcl/datafile/system.256.817343229                 1822573      1822573
　　
+DATA/orcl/datafile/sysaux.257.817343231                 1822573      1822573
　　
+DATA/orcl/datafile/undotbs1.258.817343231               1822573      1822573
　　
+DATA/orcl/datafile/users.259.817343231                  1822573      1822573
　　
+DATA/orcl/datafile/example.265.817343543                1822573      1822573
　　
SQL> select name,checkpoint_change# from v$datafile_header;
　　
NAME                                          CHECKPOINT_CHANGE#
　　
--------------------------------------------- ------------------
　　
+DATA/orcl/datafile/system.256.817343229                 1822573
　　
+DATA/orcl/datafile/sysaux.257.817343231                 1822573
　　
+DATA/orcl/datafile/undotbs1.258.817343231               1822573
　　
+DATA/orcl/datafile/users.259.817343231                  1822573
　　
+DATA/orcl/datafile/example.265.817343543                1822573
　　
SQL> select group#,sequence#,status,first_change#,next_change# from v$log;
　　
GROUP#  SEQUENCE# STATUS           FIRST_CHANGE#       NEXT_CHANGE#
　　
---------- ---------- ---------------- ------------- ------------------
　　
1         37 CURRENT                1822207    281474976710655
　　
3         36 INACTIVE               1808596            1822207
　　
2         35 INACTIVE               1770739            1808596
　　正常open数据库时：
　　文件结束SCN为NULL(无穷大)
SQL>>
Database>　　
SQL> select name,checkpoint_change#,last_change# from v$datafile;
　　
NAME                                          CHECKPOINT_CHANGE# LAST_CHANGE#
　　
--------------------------------------------- ------------------ ------------
　　
+DATA/orcl/datafile/system.256.817343229                 1822576
　　
+DATA/orcl/datafile/sysaux.257.817343231                 1822576
　　
+DATA/orcl/datafile/undotbs1.258.817343231               1822576
　　
+DATA/orcl/datafile/users.259.817343231                  1822576
　　
+DATA/orcl/datafile/example.265.817343543                1822576
　　异常关机（实例崩溃）时：
　　文件结束SCN仍为NULL(无穷大)
SQL> shutdown abort　　
ORACLE instance shut down.
　　
SQL> startup mount
　　
ORACLE instance started.
　　
Total System Global Area  459304960 bytes

　　
Fixed>
　　
Variable>　　
Database Buffers          159383552 bytes
　　
Redo Buffers                8298496 bytes
　　
Database mounted.
　　
SQL> select name,checkpoint_change#,last_change# from v$datafile;
　　
NAME                                          CHECKPOINT_CHANGE# LAST_CHANGE#
　　
--------------------------------------------- ------------------ ------------
　　
+DATA/orcl/datafile/system.256.817343229                 1822576
　　
+DATA/orcl/datafile/sysaux.257.817343231                 1822576
　　
+DATA/orcl/datafile/undotbs1.258.817343231               1822576
　　
+DATA/orcl/datafile/users.259.817343231                  1822576
　　
+DATA/orcl/datafile/example.265.817343543                1822576
　　启动实例将进行实例恢复：
SQL>>
Database>　　
$ tailf /u01/app/oracle/diag/rdbms/orcl/orcl/trace/alert_orcl.log
　　
Sun Jul 07 00:10:07 2013
　　
alter database open
　　
Beginning crash recovery of 1 threads
　　
parallel recovery started with 3 processes
　　
Started redo scan
　　
Completed redo scan
　　
read 192 KB redo, 87 data blocks need recovery
　　
Started redo application at
　　
Thread 1: logseq 37, block 533
　　
Recovery of Online Redo Log: Thread 1 Group 1 Seq 37 Reading mem 0
　　
Mem# 0: +DATA/orcl/onlinelog/group_1.261.817343457
　　
Mem# 1: +FRA/orcl/onlinelog/group_1.257.817343463
　　
Completed redo application of 0.15MB
　　
Completed crash recovery at
　　
Thread 1: logseq 37, block 918, scn 1843004
　　
87 data blocks read, 87 data blocks written, 192 redo k-bytes read
　　
Sun Jul 07 00:10:13 2013
　　
Thread 1 advanced to log sequence 38 (thread open)
　　
Thread 1 opened at log sequence 38
　　
Current log# 2 seq# 38 mem# 0: +DATA/orcl/onlinelog/group_2.262.817343467
　　
Current log# 2 seq# 38 mem# 1: +FRA/orcl/onlinelog/group_2.258.817343473
　　
Successful open of redo thread 1
　　
Sun Jul 07 00:10:14 2013
　　
SMON: enabling cache recovery
　　
Successfully onlined Undo Tablespace 2.
　　
Verifying file header compatibility for 11g tablespace encryption..
　　
Verifying 11g file header compatibility for tablespace encryption completed
　　
SMON: enabling tx recovery
　　
Database Characterset is AL32UTF8
　　
No Resource Manager plan active
　　
Sun Jul 07 00:10:17 2013
　　
replication_dependency_tracking turned off (no async multimaster replication found)
　　
Starting background process QMNC
　　
Sun Jul 07 00:10:21 2013

　　
QMNC started with pid=28, OS>　　
Sun Jul 07 00:10:31 2013

　　
Completed:>


运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表，该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有，请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意，请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息，一经发现立即删除。若您因此触犯法律，一切后果自负，我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集，我们仅提供一个展示、介绍、观摩学习的平台，我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责，亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏，不得用于商业或者其他用途，否则，一切后果均由您自己承担，我们对此不承担任何法律责任
7、如涉及侵犯版权等问题，请您及时通知我们，我们将立即采取措施予以解决
8、联系人Email：admin@iyunv.com 网址：www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址：https://www.iyunv.com/thread-600038-1-1.html 上篇帖子： oracle 10.2.0.4 patch的下载地址列表 下篇帖子： Oracle查询用户所有表、外键
回复

使用道具 举报

返回列表
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群，最新一手资源尽在官方微信交流群！快快加入我们吧...

扫描微信二维码查看详情

客服 E-mail:iyunvcom@gmail.com

本站由青云提供云计算服务

运维网--中国最专业的运维工程师交流社区

豫ICP备20007574号-1 Copyright © 2012-2025

关于我们

发展历程

联系我们

关注我们

广告服务

广告案例

隐私条款

免责声明

用户登录

用户注册

版主守则

申请版主

手机版

金币获取

帮助中心

每日签到

Good Good

Study

Day Day

UP


客服E-mail:kefu@iyunv.com 客服QQ：1061981298


QQ群⑦：运维网交流群⑦ QQ群⑧：运维网交流群⑧ k8s群：运维网kubernetes交流群


提醒：禁止发布任何违反国家法律、法规的言论与图片等内容；本站内容均来自个人观点与网络等信息，非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来，其版权均归原作者及其网站所有，我们尊重他人的合法权益，如有内容侵犯您的合法权益，请及时与我们联系进行核实删除！



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表