ADG 误删除system01.dbf故障处理

一、描述
11.2.0.4单实例主备库,主库system01.dbf误删除,导致数据库启动失败。

二、现象
SQL> startup
ORACLE instance started.

Total System Global Area 3089920000 bytes
Fixed Size 2257232 bytes
Variable Size 654315184 bytes
Database Buffers 2415919104 bytes
Redo Buffers 17428480 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: ‘/oradata/devdb/system01.dbf‘

三、处理过程

  1. 停备库,传输数据文件
    scp system01.dbf 1xx.55.3.xx:/oradata/devdb/
  2. 启动主库、恢复数据文件
    SQL> startup
    ORACLE instance started.

Total System Global Area 3089920000 bytes
Fixed Size 2257232 bytes
Variable Size 654315184 bytes
Database Buffers 2415919104 bytes
Redo Buffers 17428480 bytes
Database mounted.
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: ‘/oradata/devdb/system01.dbf‘

SQL> recover database;
Media recovery complete.
SQL> alter database open;

Database altered.

3.启动备库、启用恢复进程
SQL> startup
SQL> alter database recover managed standby database using current logfile disconnect from session;

Database altered.

SQL> select process,status from v$managed_standby;

PROCESS STATUS



ARCH CLOSING
ARCH CONNECTED
ARCH CONNECTED
ARCH CLOSING
RFS IDLE
RFS IDLE
RFS IDLE
MRP0 APPLYING_LOG

8 rows selected.

原文地址:https://blog.51cto.com/roidba/2458054

时间: 2024-11-06 09:26:57

ADG 误删除system01.dbf故障处理的相关文章

ORA-19502: write error on file "/u01/app/oracle/oradata/standby/system01.dbf", blockno 40321 (blocksize=8192)【error收集】

在RMAN备份中,出现了一个问题,就是出现坏块了. ORA-19502: write error on file "/u01/app/oracle/oradata/standby/system01.dbf", blockno 40321 (blocksize=8192) ORA-27072: File I/O error Linux Error: 9: Bad file descriptor 解决方案: blockrecover datafile 1 block 40321 为什么我知

ORA-01146: cannot start online backup - file 1 is already in backup ORA-01110: data file 1: 'C:\ORACLE\ORADATA\ORCL8\SYSTEM01.DBF'

问题: Error: [1146] ORA-01146: cannot start online backup - file 1 is already in backup ORA-01110: data file 1: 'C:\ORACLE\ORADATA\ORCL8\SYSTEM01.DBF' 以上问题是指,system这个表空间现在是备份状态 解决: alter tablespace system end backup; ORA-01146: cannot start online back

RMAN DUPLICATE ADG DEMO

RMAN DUPLICATE ADG DEMO 生产环境谨慎使用,建议生产环境采用RMAN备份恢复的方式. 本演示案例所用环境:   primary standby OS Hostname pry std OS Version RHEL6.5 RHEL6.5 DB Version 11.2.0.4 11.2.0.4 db_name stephen stephen db_unique_name stephen standby service_names stephen standby instan

Oracle误删除表空间的恢复

对于误删除表空间的恢复,本文通过基于数据库的时间点恢复和基于表空间的时间点恢复分别加以讨论 一 通过基于数据库的时间点恢复被误删除的表空间 1 需要注意的事项 a 基于数据库的时间点恢复将会回退整个数据库. b 误删除表空间,当数据库有之前可用于恢复的全库备份和相关归档,如果对数据库执行不完全恢复,恢复该数据库到删除表空间之前的状态,便可恢复误删除的表空间.但实际上当我们删除表空间,数据库备份中将不存在关于该表空间的的信息,直接进行恢复将会出现问题.如下所示: RMAN> list backup

Oracle 数据文件误删除的不完全恢复

应用环境: 我的一个表被人不小心误删除了,这时候,我不可以把整个库都恢复回去,那样太麻烦了. 所以现在我就从新到一个新库,只将这一个数据文件拷贝过来恢复. 那我们Oracle在恢复文件的时候是不可以只恢复一部分数据文件的,因为oracle  要保证数据文件块头信息一致,所以如果我们要恢复部分文件的话,就得采取以下这种方法: 可以另起一个库,再把要恢复的数据文件拷贝过来,恢复.(当然不单单是该数据文件,还要包括system表空间,undo表空间) 1)另起一个库很简单,可以搞出参数文件,在参数文件

配置ORACLE 11G ADG

以前装过10g的,没有做笔记,昨天使用duplicate方法装了个11g ADG,过程艰辛,记录下: 一.环境配置 主库 IP地址:192.168.233.128/24 操作系统版本:rhel5.8 64bit 数据库版本:11.2.0.1 64bit 数据库sid名:orcl 数据库名:orcl 数据库db_unique_name:orcl1 主机名:pr 物理备库 IP地址:192.168.233.129/24 操作系统版本:rhel5.8 64bit 数据库版本:11.2.0.1 64bi

Linux下Oracle 数据文件被物理误删除的恢复

#加深对Linux句柄的理解/紧急情况下Oracle的快速恢复 不同于从Oracle中drop掉数据文件,在某些情况下,可能会遇到数据库在运行时数据文件在操作系统级别被删除,而此时Oracle实例并未崩溃,仍然处于open状态.此时就要求尽量在最小的影响下最高效率地完成恢复.现将恢复过程整理出来,以备不时之需. <<过程模拟>> <STEP 1>模拟删除 [email protected] >select name from v$datafile; NAME --

最简单的11g Active DataGuard(ADG)搭建配置过程(项目步骤)

最简单的11g Active DataGuard(ADG)搭建配置过程(项目步骤) 一.环境介绍: 我在db01和db02两台Linux虚拟机上首先分别安装了一套数据库软件,在db01主机上创建了名为woo的数据库:我们这次的实验是要搭建了一套Oracle 11g Active DataGuard:目的是为了实现数据库同步的功能,并且了解Oracle 11g DG的基本功能. db01:192.168.1.50db02:192.168.1.51 二.11g ADG部署: 1.pri端和sty端配

11g ADG环境实施文档-1204

11g adg 环境搭建实施手册-1204 2017年8月30日 9:16 s 11g adg 环境搭建实施手册-0824 2017年8月24日 10:18     ################################################################ 简介   从11g 开始oracle提供了一个新功能Active Database Duplication for A standby database来创建配置物理standby 数据库. Active