SYSTEM毁坏恢复

system毁坏恢复
建议做整个库的冷备(datafile+controlfile+redo log file)
(1)shutdowm

(2)拷贝文件datafile+controlfile+redo log file

(3)startup

(5)rm system01.dbf

(6)再次打开数据库,报错
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: ‘/orcl_backup/cold/system01.dbf

(7) SQL> select file#, name,CHECKPOINT_CHANGE# from v$datafile;

FILE# NAME CHECKPOINT_CHANGE#
---------- ----------------------------------- ------------------
1 /orcl_backup/cold/system01.dbf 5020712
2 /orcl_backup/cold/sysaux01.dbf 5020712
3 /orcl_backup/cold/undotbs01.dbf 5020712
4 /orcl_backup/cold/users01.dbf 5020712
5 /orcl_backup/cold/tp01.dbf 5020712

SQL> select file#, name,CHECKPOINT_CHANGE# from v$datafile_header;

FILE# NAME CHECKPOINT_CHANGE#
---------- ----------------------------------- ------------------
1 0 ====》文件已经不出在了。
2 /orcl_backup/cold/sysaux01.dbf 5020712
3 /orcl_backup/cold/undotbs01.dbf 5020712
4 /orcl_backup/cold/users01.dbf 5020712
5 /orcl_backup/cold/tp01.dbf 5020712

CHECKPOINT_COUNT ====>计数器,数据文件和控制文件头。

(8)拷贝备份的system01到目标文件夹
cp system01.dbf /orcl_backup/cold/system01.dbf

(9)查看v$datafile_header;
SQL> select file#, name,CHECKPOINT_CHANGE# from v$datafile_header;

FILE# NAME CHECKPOINT_CHANGE#
---------- ----------------------------------- ------------------
1 /orcl_backup/cold/system01.dbf 5019954
2 /orcl_backup/cold/sysaux01.dbf 5020712
3 /orcl_backup/cold/undotbs01.dbf 5020712
4 /orcl_backup/cold/users01.dbf 5020712
5 /orcl_backup/cold/tp01.dbf 5020712

发现现在的 5019954与其他的检查点不同。
SQL> select file#, name,CHECKPOINT_CHANGE# from v$datafile;

FILE# NAME CHECKPOINT_CHANGE#
---------- ----------------------------------- ------------------
1 /orcl_backup/cold/system01.dbf 5020712
2 /orcl_backup/cold/sysaux01.dbf 5020712
3 /orcl_backup/cold/undotbs01.dbf 5020712
4 /orcl_backup/cold/users01.dbf 5020712
5 /orcl_backup/cold/tp01.dbf 5020712

这样的原因:当buffer cache 中的数据完成写入文件上那一刻的时间。把scn写到文件头上,同时信息会拷贝到控制文件。

此时文件就是比较旧

(10)SQL> recover datafile 1;
ORA-00279: change 5019954 generated at 12/29/2014 23:06:33 needed for thread 1
ORA-00289: suggestion : /app/oracle/archive_log/1_327_861876939.dbf
ORA-00280: change 5019954 for thread 1 is in sequence #327

说明:
QL> select file#, name,CHECKPOINT_CHANGE# from v$datafile_header;

FILE# NAME CHECKPOINT_CHANGE#
---------- ----------------------------------- ------------------
1 /orcl_backup/cold/system01.dbf 5019954
2 /orcl_backup/cold/sysaux01.dbf 5020712
3 /orcl_backup/cold/undotbs01.dbf 5020712
4 /orcl_backup/cold/users01.dbf 5020712
5 /orcl_backup/cold/tp01.dbf 5020712
当 recover datafile 1去扫描1号文件,偏移量为484的地方。找到检查点

找到/app/oracle/archive_log/1_327_861876939.dbf的日志,从数据文件数文件头一号块上的500偏移量的RBA 的中读到的RBA的位置开始恢复。

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

说明 RET回车,应用归档日志
filename:自己想要的归档日志
AUTO:自动应有所有的归档
CANEL:不完全恢复

(11)回车

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00279: change 5020630 generated at 12/29/2014 23:34:05 needed for thread 1
ORA-00289: suggestion : /app/oracle/archive_log/1_328_861876939.dbf
ORA-00280: change 5020630 for thread 1 is in sequence #328

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00279: change 5020633 generated at 12/29/2014 23:34:07 needed for thread 1
ORA-00289: suggestion : /app/oracle/archive_log/1_329_861876939.dbf
ORA-00280: change 5020633 for thread 1 is in sequence #329

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00279: change 5020636 generated at 12/29/2014 23:34:08 needed for thread 1
ORA-00289: suggestion : /app/oracle/archive_log/1_330_861876939.dbf
ORA-00280: change 5020636 for thread 1 is in sequence #330

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

Log applied.
Media recovery complete. =======》到这里完成

(12)查看v$log,只恢复到330.

SQL> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ ---------
1 1 331 52428800 512 1 YES INACTIVE 5020639 29-DEC-14 5020642 29-DEC-14
3 1 333 52428800 512 1 NO CURRENT 5020645 29-DEC-14 2.8147E+14
2 1 332 52428800 512 1 YES INACTIVE 5020642 29-DEC-14 5020645 29-DEC-14

在查看 告警日志

ORA-279 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
Tue Dec 30 01:43:52 2014
ALTER DATABASE RECOVER CONTINUE DEFAULT
Media Recovery Log /app/oracle/archive_log/1_329_861876939.dbf
ORA-279 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
ALTER DATABASE RECOVER CONTINUE DEFAULT
Media Recovery Log /app/oracle/archive_log/1_330_861876939.dbf
Recovery of Online Redo Log: Thread 1 Group 1 Seq 331 Reading mem 0
Mem# 0: /orcl_backup/cold/redo01.log
Recovery of Online Redo Log: Thread 1 Group 2 Seq 332 Reading mem 0
Mem# 0: /orcl_backup/cold/redo02.log
Recovery of Online Redo Log: Thread 1 Group 3 Seq 333 Reading mem 0
Mem# 0: /orcl_backup/cold/redo03.log

它使用redo log进行恢复

alter database open;时,
oracle进行了实例恢复
alter database open
Beginning crash recovery of 1 threads
parallel recovery started with 2 processes

在重做一遍的redo log:
Thread 1 opened at log sequence 334
Current log# 1 seq# 334 mem# 0: /orcl_backup/cold/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Tue Dec 30 01:48:29 2014
因为,这个是正在这个日志上,没有被归档。

时间: 2024-08-24 23:11:52

SYSTEM毁坏恢复的相关文章

LVM管理-元数据及分区表的恢复

日常我们为了查看物理卷.卷组.逻辑卷信息会使用一些命令,例如: 这些信息被放置在物理卷的第二扇区中,称为LVM标签,而LVM标签包含UUID号.记录块设备大小.记录元数据位置.其中,LVM的元数据包含了LVM卷组的详细配置并且可以ASCLL格式保存. 一.元数据备份 LVM的元数据默认放置的位置: 我们可以查看元数据文件: 对元数据作备份有3种方法: 第一种: 使用dd将设备信息输出到一个文件中,不过值得注意的是输出的文件我们在查看时会看到一些乱码,在恢复信息时候我们需要将文件中的乱码手动删除.

atitit.修复xp 操作系统--重装系统--保留原来文件不丢失

1. 修复目标...保持c盘文件,恢复system文件走ok... 1 2. 重装系统以前的操作 1 2.1. 避免格式化c盘/ghost 1 2.2. 备份document 用户目录andwindows..... 1 2.3. 最好不个系统安装到个另一个分区... 2 3. 重装系统 2 3.1. 制造u盘启动,U大师 umaster...320M,整合了pe ,maxdos 环境... 2 3.2. 下载xp安装版本..WINXPSP3_SRS_DRVS_SOFT_201103.iso  6

oracle 启动模式

转载自:http://blog.csdn.net/nsj820/article/details/6573525 <一>.ORACLE数据库启动模式 1.启动SQL*PLUS不与数据库连接 SQLPLUS /NOLOG 2.以SYSDBA角色与Oracle连接 CONNECT username/password AS SYSDBA 3.启动实例   1>.启动一个实例,装配和打开一个数据库 STARTUP; 或 STARTUP PFILE='d:/oracle/admin/mydb/scr

关于 SQLNET.AUTHENTICATION_SERVICES 验证方式的说明

今天去客户那里巡检,客户提出为了提高数据库安全性考虑,需要修改sys/system密码,并通过数据库验证方式来取代默认的操作系统方式,现在我来把这两种验证方式总结一下. 操作系统验证,即通过操作系统账户的权限访问数据库,举个例子,如果已经拥有了windows下的系统管理员administrator的权限,那么当采用该方式验证的话,无需输入用户/密码就可以访问,比如:sqlplus / as sysdba;哪怕是任意输入的用户名和密码,也无所谓,比如:sqlplus abc/efg as sysd

Android手机fastboot 刷机命令【转】

本文转载自:http://luke-feng.iteye.com/blog/2171090 简介:在安卓手机中fastboot是一种比recovery更底层的模式.fastboot是一种线刷,就是使用USB数据线连接手机的一种刷机模式.这种模式是更接近于硬件的界面,所以这个模式一般好似在手机变砖或者修复时使用的.今天就说说fastboot的详细教程. 一.常用命令:1.先进入fastboot文件所在目录:2.输入fastboot.exe启动fastboot:3.查看连接电脑的设备命令:fastb

Android中的系统服务(代理模式)

一,系统启动 Android设备的开机流程总得来分可以分为三部分: 加载引导程序 引导程序bootloader是开机运行的第一个小程序,因此它是针对特定的主板与芯片的.bootloader有很多种,可以使用比较流行的如redboot.uboot.ARMBoot等,也可以开发自己的引导程序,它不是Android操作系统的一部分.引导程序也是OEM厂商或者运营商加锁和限制的地方. 引导程序初始化硬件设备.创建存储器空间的映射等软件运行时所需要的最小环境:加载Linux内核镜像文件(本文只针对Andr

Ubuntu系统常见问题整理(Part 2)

23 ***文件名带空格的文件 把文件名中间的空格加双引号.例: rm  my"空格"file 进入或者执行文件名带空格文件的命令格式也一样 24 更改MAC地址 00:1a:73:d7:3b:e2 sudo ifconfig eth2 down sudo ifconfig eth2 hw ether XX:XX:XX:XX:XX:XX sudo ifconfig eth2 up 以上修改重启后会失效,若要永久修改,可直接编辑/etc/network/interfaces文件 pre-

数据库原理-数据库故障

数据库恢复定义 把数据库从错误状态恢复到某一已知的正确状态(亦称为一致状态或完整状态) 数据库故障 事务内部的故障 系统故障 介质故障 计算机病毒 1.事物内部的故障 事务内部更多的故障是非预期的,是不能由应用程序处理的.运算溢出.并发事务发生死锁而被选中撤销该事务和违反了某些完整性限制等都有可能引发事务故障. 解决这类故障的方法是撤销事务(undo),就像事务从来没有发生一样. 2.系统故障 称为软故障,是指造成系统停止运转的任何事件,使得系统要重新启动. 特点: 整个系统的正常运行突然被破坏

(转)AIX光盘备份与恢复

AIX光盘备份与恢复 在此之前,说明一下光盘映像的格式UDF和ISO9660 ISO9660: 这是国际标准化组织(ISO)于1985年颁布的通用光盘文件系统.目前使用最广泛的光盘文件系统,能被所有的CD-ROM和操作系统识别.它支持8.3格式的文件名,不支持长文件名.支持DOS,Windows9x/NT,OS/2,Linux,MAC OS等操作系统. UDF: 这是国际标准化组织于1996年制定的通用光盘文件系统.它采用标准的包刻录技术来简化刻录机的使用.UDF文件系统使用户可以象操作硬盘那样