- 浏览: 5093926 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
silence19841230:
先拿走看看
SpringBoot2.0开发WebSocket应用完整示例 -
wallimn:
masuweng 写道发下源码下载地址吧!三个相关文件打了个包 ...
SpringBoot2.0开发WebSocket应用完整示例 -
masuweng:
发下源码下载地址吧!
SpringBoot2.0开发WebSocket应用完整示例 -
masuweng:
SpringBoot2.0开发WebSocket应用完整示例 -
wallimn:
水淼火 写道你好,我使用以后,图标不显示,应该怎么引用呢,谢谢 ...
前端框架iviewui使用示例之菜单+多Tab页布局
本文地址:http://wallimn.iteye.com/blog/1199561,转载请保留。
1、系统检查点(记录在控制文件中)
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
539625
2、数据文件检查点(记录在控制文件中)
SQL> select file#,checkpoint_change#,last_change# from v$datafile;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
1 539625
2 539625
3 539625
4 539625
5 539625
3、数据文件头检查点(记录在数据文件中)
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 539625
2 539625
3 539625
4 539625
5 539625
以上三个checkpoint_change#要一致(只读、脱机表空间除外),数据库才能正常打开。否则会需要进行一步的处理。正常关库时,会生成新的检查点,写入上述三个checkpoint_change#,同时数据文件中的last_change#也会记录下该检查点,也就是说三个checkpoint_change#与last_change#记录着同一个值。
通过以下SQL可以证明
SQL> shutdown immediate
SQL> startup mount
SQL> select file#,checkpoint_change#,last_change# from v$datafile;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
1 540270 540270
2 540270 540270
3 540270 540270
4 540270 540270
5 540270 540270
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
540270
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 540270
2 540270
3 540270
4 540270
5 540270
数据库成功打开后,数据文件中的last_change#会被清空。正常关库时,再重新下最后的检查点。shutdown abort关库,这个值是空的(感兴趣可自行验证),此时数据库需要进行实例恢复(不需要用户干预),恢复后数据库才正常打开。
checkpoint_change#、last_change#实际上全部来自于SCN,可以通过下面的语句验证:
SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
------------------------
540741
使用查询系统SCN号的函数,可以发现checkpoint_change#与之是接近的。SCN有很多触发的条件,可能不会特别接近。
下面举几个全备后恢复的例子,以及相关场景下checkpoint_change#的情况。
问题1:数据文件损坏的恢复
此时控制文件中记录的checkpoint_change#比数据文件头中记录的要大,数据库需要介质或者实例恢复。
SQL> startup
Database mounted.
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/u02/oradata/orcl/system01.dbf'
恢复一下,数据库就可以打开了。
SQL> recover database;
ORA-00279: change 539624 generated at 10/18/2011 08:27:31 needed for thread 1
ORA-00289: suggestion : /u02/oradata/orcl/arc/1_5_764840495.dbf
ORA-00280: change 539624 for thread 1 is in sequence #5
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 540768 generated at 10/18/2011 12:17:11 needed for thread 1
ORA-00289: suggestion : /u02/oradata/orcl/arc/1_6_764840495.dbf
ORA-00280: change 540768 for thread 1 is in sequence #6
ORA-00278: log file '/u02/oradata/orcl/arc/1_5_764840495.dbf' no longer needed for this recovery
Log applied.
Media recovery complete.
SQL> alter database open;
Database altered.
问题2:控制文件损坏的恢复
如果控制文件损坏,使用备份的控制文件是无法打开数据库的,
SQL> startup
Database mounted.
ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: '/u02/oradata/orcl/system01.dbf'
ORA-01207: file is more recent than controlfile - old controlfile
会提示数据文件与控制文件新,实际上就是控制文件中记录的checkpoint_change#比数据文件头中的checkpoint_change#要小,这种情况是不能打开数据库的。但数据可以启动到mount状态,此时可以用命令
alter database backup controlfile to trace;
生成一个控制文件的脚本,在udump目录中。使用该脚本可以重建控制文件,进行实例恢复后或打开数据库。
如果没有备份的控制文件,数据库只能打开的nomount状态,不能获取重建控制文件的脚本,如果也没有备份过重建控制文件脚本,那就悲剧了。如果数据库不太复杂,可以手写一个。
问题3:数据文件、控制文件全部损坏(当然都有备份,日志是好的)
恢复数据文件、控制文件后,数据库仍然是无法打开的。
SQL> startup
Database mounted.
ORA-00314: log 1 of thread 1, expected sequence# doesn't match
ORA-00312: online log 1 thread 1: '/u02/oradata/orcl/redo01.log'
提示的意思也就是日志中的检查点比较控制文件中记录的大。
SQL> select checkpoint_change# from v$datafile;
CHECKPOINT_CHANGE#
------------------
539624
539624
539624
539624
539624
SQL> select checkpoint_change# from v$datafile_header;
CHECKPOINT_CHANGE#
------------------
539624
539624
539624
539624
539624
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
539624
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1 1 5 10485760 1 NO CURRENT 539571 18-OCT-11
2 1 4 10485760 1 YES INACTIVE 539116 18-OCT-11
3 1 3 10485760 1 YES INACTIVE 537456 18-OCT-11
此时可以使用下面的命令恢复数据库
SQL> recover database using backup controlfile;
恢复成功后,v$database中记录的checkpoint_change#并未发生变化。
SQL> select checkpoint_change# from v$datafile;
CHECKPOINT_CHANGE#
------------------
602574
602574
602574
602574
602574
SQL> select checkpoint_change# from v$datafile_header;
CHECKPOINT_CHANGE#
------------------
602574
602574
602574
602574
602574
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
539624
因为不一致,所以数据库仍然打不开:
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/u02/oradata/orcl/system01.dbf'
此时的情况类似于问题2,解决办法也相同。shutdown abort,startup nomount,重建控制文件,recover database,alter database open;
问题4、数据库冷备过,新建的表空间的数据文件损坏,且无备份。
这种情况的处理办法:
restore备份的数据文件;
startup;
会提示无法定位数据文件,数据库无法打开,
alter database create datafile '提示的无法定位的数据文件名称';--此时查看checkpoint_change#,会发现新建的与其它的不相同。
set autorecovery on
recover database;
alter database open;
1、系统检查点(记录在控制文件中)
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
539625
2、数据文件检查点(记录在控制文件中)
SQL> select file#,checkpoint_change#,last_change# from v$datafile;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
1 539625
2 539625
3 539625
4 539625
5 539625
3、数据文件头检查点(记录在数据文件中)
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 539625
2 539625
3 539625
4 539625
5 539625
以上三个checkpoint_change#要一致(只读、脱机表空间除外),数据库才能正常打开。否则会需要进行一步的处理。正常关库时,会生成新的检查点,写入上述三个checkpoint_change#,同时数据文件中的last_change#也会记录下该检查点,也就是说三个checkpoint_change#与last_change#记录着同一个值。
通过以下SQL可以证明
SQL> shutdown immediate
SQL> startup mount
SQL> select file#,checkpoint_change#,last_change# from v$datafile;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
1 540270 540270
2 540270 540270
3 540270 540270
4 540270 540270
5 540270 540270
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
540270
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 540270
2 540270
3 540270
4 540270
5 540270
数据库成功打开后,数据文件中的last_change#会被清空。正常关库时,再重新下最后的检查点。shutdown abort关库,这个值是空的(感兴趣可自行验证),此时数据库需要进行实例恢复(不需要用户干预),恢复后数据库才正常打开。
checkpoint_change#、last_change#实际上全部来自于SCN,可以通过下面的语句验证:
SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
------------------------
540741
使用查询系统SCN号的函数,可以发现checkpoint_change#与之是接近的。SCN有很多触发的条件,可能不会特别接近。
下面举几个全备后恢复的例子,以及相关场景下checkpoint_change#的情况。
问题1:数据文件损坏的恢复
此时控制文件中记录的checkpoint_change#比数据文件头中记录的要大,数据库需要介质或者实例恢复。
SQL> startup
Database mounted.
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/u02/oradata/orcl/system01.dbf'
恢复一下,数据库就可以打开了。
SQL> recover database;
ORA-00279: change 539624 generated at 10/18/2011 08:27:31 needed for thread 1
ORA-00289: suggestion : /u02/oradata/orcl/arc/1_5_764840495.dbf
ORA-00280: change 539624 for thread 1 is in sequence #5
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 540768 generated at 10/18/2011 12:17:11 needed for thread 1
ORA-00289: suggestion : /u02/oradata/orcl/arc/1_6_764840495.dbf
ORA-00280: change 540768 for thread 1 is in sequence #6
ORA-00278: log file '/u02/oradata/orcl/arc/1_5_764840495.dbf' no longer needed for this recovery
Log applied.
Media recovery complete.
SQL> alter database open;
Database altered.
问题2:控制文件损坏的恢复
如果控制文件损坏,使用备份的控制文件是无法打开数据库的,
SQL> startup
Database mounted.
ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: '/u02/oradata/orcl/system01.dbf'
ORA-01207: file is more recent than controlfile - old controlfile
会提示数据文件与控制文件新,实际上就是控制文件中记录的checkpoint_change#比数据文件头中的checkpoint_change#要小,这种情况是不能打开数据库的。但数据可以启动到mount状态,此时可以用命令
alter database backup controlfile to trace;
生成一个控制文件的脚本,在udump目录中。使用该脚本可以重建控制文件,进行实例恢复后或打开数据库。
如果没有备份的控制文件,数据库只能打开的nomount状态,不能获取重建控制文件的脚本,如果也没有备份过重建控制文件脚本,那就悲剧了。如果数据库不太复杂,可以手写一个。
问题3:数据文件、控制文件全部损坏(当然都有备份,日志是好的)
恢复数据文件、控制文件后,数据库仍然是无法打开的。
SQL> startup
Database mounted.
ORA-00314: log 1 of thread 1, expected sequence# doesn't match
ORA-00312: online log 1 thread 1: '/u02/oradata/orcl/redo01.log'
提示的意思也就是日志中的检查点比较控制文件中记录的大。
SQL> select checkpoint_change# from v$datafile;
CHECKPOINT_CHANGE#
------------------
539624
539624
539624
539624
539624
SQL> select checkpoint_change# from v$datafile_header;
CHECKPOINT_CHANGE#
------------------
539624
539624
539624
539624
539624
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
539624
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1 1 5 10485760 1 NO CURRENT 539571 18-OCT-11
2 1 4 10485760 1 YES INACTIVE 539116 18-OCT-11
3 1 3 10485760 1 YES INACTIVE 537456 18-OCT-11
此时可以使用下面的命令恢复数据库
SQL> recover database using backup controlfile;
恢复成功后,v$database中记录的checkpoint_change#并未发生变化。
SQL> select checkpoint_change# from v$datafile;
CHECKPOINT_CHANGE#
------------------
602574
602574
602574
602574
602574
SQL> select checkpoint_change# from v$datafile_header;
CHECKPOINT_CHANGE#
------------------
602574
602574
602574
602574
602574
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
539624
因为不一致,所以数据库仍然打不开:
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/u02/oradata/orcl/system01.dbf'
此时的情况类似于问题2,解决办法也相同。shutdown abort,startup nomount,重建控制文件,recover database,alter database open;
问题4、数据库冷备过,新建的表空间的数据文件损坏,且无备份。
这种情况的处理办法:
restore备份的数据文件;
startup;
会提示无法定位数据文件,数据库无法打开,
alter database create datafile '提示的无法定位的数据文件名称';--此时查看checkpoint_change#,会发现新建的与其它的不相同。
set autorecovery on
recover database;
alter database open;
发表评论
-
Oracle数据库相关系统突然提示“SQLException:违反协议”
2024-02-19 15:50 301SQLException:违反协议这个异常可能由很多的 ... -
CentOS在Docker中安装Oracle
2024-02-06 12:13 3771.拉取Oracle镜像,并检 ... -
Windows Server安装oracle数据库一直停在82%
2023-02-04 12:01 385网上有个说法:服务器超过一定数量的CPU后,将不能正常安装 ... -
ORA-04030错误处理
2023-02-04 11:52 2150【错误描述】 错误信息如下: ORA-04030:在尝 ... -
ORA-04030错误处理
2023-02-04 11:45 403【错误描述】 错误信息如下: ORA-04030:在尝 ... -
Linux安装MySQL数据库
2019-06-10 22:27 16011.进入安装包所在目录,解压: tar zxvf mysql- ... -
确定MySQL在Linux系统中配置文件的位置
2019-04-14 19:30 26061.通过which mysql命令来查看mysql的安装位置。 ... -
mysql set names 命令和 mysql 字符编码问题
2019-04-12 00:34 986转自:https://www.cnblogs.com/digd ... -
MYSQL中取当前周/月/季/年的第一天与最后一天
2018-11-17 23:16 2072转自:https://blog.csdn.net/ ... -
Oracle删除大量数据的实践
2016-11-07 18:03 5657一、引言 从来没有 ... -
Oracle 数据库简明教程 V0.1
2016-03-23 21:01 1894供初学者入门学习使用,以开发者常见、常用的知识为主,基本上 ... -
Oracle拆分字符串函数
2016-03-23 10:58 3211create or replace type string ... -
Oracle数据库远程连接无响应
2016-03-21 10:20 4124故障现象: 服务器本机使用sqlplus / as s ... -
Oracle PGA详解
2015-10-21 15:34 11245转自:http://yanguz123.iteye.com/b ... -
Oracle12C导入dmp数据
2015-10-08 23:43 20404Oracle12C,发生了较大的变化。以前熟悉的东西变得陌 ... -
SQLLDR数据导入小结
2015-07-25 22:06 73771.创建数据表 CREATE TABLE ... -
Window7安装Oracle10
2015-03-06 12:14 1494每次安装都要百度,转到自己的博客上,找起来方便,还能增加访 ... -
Oracle SQL Developer 连接 Mysql 数据库
2015-02-25 19:36 3546下载JDBC包,解压缩这里只要mysql-connector- ... -
Mysql数据备份与恢复
2015-02-25 19:15 1242备份/恢复策略 1. 要定期做 mysql备份,并考虑系统可以 ... -
Oracle中merge into的使用
2015-01-23 22:57 3907引自:http://www.cnblogs.com/highr ...
相关推荐
lightweight-pytorch训练好的模型checkpoint_iter_370000.pth
将基于TensorFlow的谷歌发布的官方BERT模型转化为基于Pytorch的BERT模型
bios 应用AMIBIOS8_Checkpoint_and_Beep_Code_List_1.9.RAR
ORACLE中的checkpoint
checkpoint__R70_Firewall_AdminGuide中文版
bert预训练模型tensorflow版本转为pytorch版本的脚本文件,使用时记得更改文件路径以及文件名。
CheckPoint_R65_SmartCenter_AdminGuide
CheckPoint_R61_SecureRemote_SecureClient_UserGuide
CheckPoint_R61_SmartCenter_UserGuide
CheckPoint_R61_Firewall_SmartDefense_UserGuide
CheckPoint_R65_SecurePlatform_SecurePlatformPro_AdminGuide
checkpoint_instructors.ppt
CheckPoint_R62_CLI_UserGuide
AMIBIOS8_Checkpoint_and_Beep_Code_List_PUB[1].pdf
checkpoint_classification-400_91.ckpt
第十二章:Oracle中表的几种类型 第十三章:数据库审计 audit 第十四章:数据装载 SqlLoader 第十五章:Oracle 网络 第三部分:管理Oracle数据库 第十六章:Oracle ASM 管理 第十七章:逻辑备份与恢复 第十八章:...
用matlable画出自己想画的图像
手写的DNN,帮助理解神经网络原理, 解压后为ipython文件,可在jupyter中打开
马尔可夫部分检测
小球以水平的速度抛出,最后落在地面上的轨迹