DG°²×° (1)

提示:

这份文档只是适合我自己的习惯写出来的,多次修改，逻辑也可能有问题，仅供参考,若有

疑问可联系本人。

QQ:54110058 清江石

用 GC 安装物理 dg

这里选择保留备份,看后面能否用

确保空间 3750m 以上，否则报错

出现这个错误原来是权限不对造成的：remote operation error-error:nmo not setuid-root

在 odd 机器上,安装 agent 的机器

后来用 root 用户执行如下

再次执行 ok

好像在 Database 里要先手工添加 EMREP 库，否则这里无法显示 event.domain 的选择项

这里选择Customize进去修改路径,而且备库已经存在的 tns和 listener.ora不删除看能否覆盖?

如果所有文件放到一个路径下只需要在 set locations 栏里填写而后点击 go 自动改变下面路

径，否则只能一个一个去修改了,目录如果没有会自己去创建，只要权限够.

tempfiles 放到 Disk2 目录

下一步会问是否自己去创建这些目录

会回到上面的窗口，继续下一步

后来把 Target Name 换成 STD 了才行,原因还不知道啊,修改了/etc/oratab 还是不行

从 dgmgrl 移除后就不再报告名字重复了

我这次碰到的是没有 Physical 的名字，因此移除了仍然报名字存在，无语

问题真正原因应该在这里，删除 PRODSTD 就好了

这里会出一个整体的设置报告，可以查看路径等是否都设置正确.

创建的时间好像几分钟就可以完成了,但注意这里的 data guard 状态是 creation in progress

可以监控 PROSTD 的 alert 日志查看恢复完成情况

怎么一 switchover 竟然找不到 standby 库了啊,怀疑是主库的一些参数没有清理照成(以前手

工搞过 dg)log_archive_dest_2,valid_for,dg_config

下面来将计就计，看能否手工配置好目前的 dg

把主库的参数文件重新设置了一遍重启,发现备库可以接受日志了

select max(sequence#) from v$archived_log; --两边可以一直了,这时上面的界面也可以调出

来了.

在更改保护类型时候才会两边添加 standby redo ,原有的 standby_log 不会删除，可以自己

drop 掉

主库创建一个测试表空间

create tablespace test datafile ‘/u01/app/oradata/PROD/Disk1/test01.dbf’ size 10M;

图形虽然简单,但好像无法控制

1:

backup as compressed database format '/home/oracle/backup/all_%U.bak';

2:

SQL>create pfile='/home/oracle/PROD.ora' from spfile;

SQL> alter database create standby controlfile as '/home/oracle/ctl_01.ctl';

先一下把参数文件和控制文件都传到一个位置去

[oracle@odd ~]$ scp ctl_01.ctl PROD.ora event:/home/oracle

在 even 机上修改 PRODSTD.ora 参数,控制文件位置等,基本参数文件，别的都删除掉,

不要修改 db_name,

需要设置 db_unique_name ,service_names 会跟着改变的,这里要注意主库的 tns 配置名字要

变

[oracle@event ~]$ export ORACLE_SID=PRODSTD

SQL> startup nomount ---验证参数文件正确性

SQL> create spfile from pfile='/home/oracle/PRODSTD.ora';

SQL> shutdown immediate;

SQL> startup nomount; --利用主库过来的控制文件启动

SQL> show parameter contro --查看控制文件位置，把主库过来的控制文件拷贝过去

select controlfile_type from v$database;

SQL> select name from v$dbfile; --确定原数据文件位置

alter system set

db_file_name_convert='/u01/app/oradata/PROD/Disk1/','/u01/app/oradata/PRODSTD/Disk1/','/

u01/app/oradata/PROD/Disk2/','/u01/app/oradata/PRODSTD/Disk1/','/u01/app/oradata/PROD/

Disk3/','/u01/app/oradata/PRODSTD/Disk1/','/u01/app/oradata/PROD/Disk4/','/u01/app/oradata

/PRODSTD/Disk1/','/u01/app/oradata/PROD/Disk5/','/u01/app/oradata/PRODSTD/Disk1/'

scope=spfile;

这里是否可以在 PRODSTD 下面也建 5 个目录，可以节省时间

因为要做切换,备考也需要 redo 日志

alter system set db_file_name_convert='PROD','PRODSTD'scope=spfile;

alter system set log_file_name_convert='PROD','PRODSTD'scope=spfile;

SQL> shutdown abort;

SQL> startup mount;

从 10.2.0.1 备份恢复到 10.1.0.4 出现下面错误

ORA-00218: block size 16384 of controlfile

'/u01/app/oradata/PRODSTD/Disk1/control_01.ctl' does not match DB_BLOCK_SIZE

后来改到 10.2.0.1 环境下去恢复就没有这个问题了

SQL> select name from v$dbfile; --验证位置正确性

RMAN> restore database; --开始恢复数据,同时可以做下面的事情

在主库创建一个表便于测试

SQL> create table test as select * from dba_objects;

编辑 listener.ora transname.ora 查看监听是否捕获到 PRODSTD

在 odd 机上添加 transname.ora --注意服务名字还是 PROD

[oracle@odd admin]$ tnsping PRODSTD --确保能 ping

[oracle@event dbs]$ orapwd file=orapwPRODSTD password=oracle

SQL> conn sys/oracle@PRODSTD as sysdba --在远端添加 orapw 文件,否则下面错误

ERROR:

ORA-01031: insufficient privileges

SQL> alter system set log_archive_dest_2='service=PRODSTD'; --默认会用 arch 传归档,非实时

sql >alter system set log_archive_dest_state_2='enable';

alter system switch logfile;

在 even 端自动恢复日志

alter database recover managed standby database disconnect from session;

alter database recover managed standby database cancel;

,查看错误原因

select dest_name,error from v$archive_dest;

SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

SQL> select

PROTECTION_MODE,PROTECTION_LEVEL,SWITCHOVER_STATUS,OPEN_MODE,DATABASE_ROLE

from v$database;

如果这里 PROTECTION_LEVEL 是 RESYNCHRONIZATION 表示不正常的,要查看原因

先把主变成备，再备变主

Alter database commit to switchover to physical standby

ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected

有活动会话，执行下面语句

alter database commit to switchover to physical standby with session shutdown;

告警日志里必须有 End-of-Redo 提示表示成功

shutdown immediate;

startup mount;

select PROTECTION_MODE,SWITCHOVER_STATUS,OPEN_MODE,DATABASE_ROLE from

v$database;

此时变成 PHYSICAL STANDBY

在 PRODSTD 经行一次恢复

SQL>Alter database recover managed standby database disconnect from session;

等后台恢复结束后

SQL> alter database recover managed standby database cancel; --一定要先停止恢复来再做切

换,否则报下面错误

SQL > alter database commit to switchover to primary;

此时 PRODSTD 的 database_role 已经变成 PRIMARY

正常很快就会切换完成

不正常如下:

日志有如下信息，好像很慢

If media recovery active, switchover will wait 900 seconds

原来是 SWITCHOVER_STATUS=sessions active

要加 with session shutdown ,可以 ctrl+c 结束上面的语句再执行这个,还是报错,原来是没有结

束恢复日志照成的

Alter database commit to switchover to primary with session shutdown;

ORA-01153: an incompatible media recovery is active

alter database open;

select controlfile_type,open_mode from v$database;

老的主库端可以关闭远端传输

alter system set log_archive_dest_state_2=defer;

设置新的主库端

alter system set log_archive_dest_2=’service=prod’;

SQL> alter system set log_archive_dest_state_2=enable;

创建一个 tablespace 测试下能否从当前 PRODSTD 到 PROD

SQL> create tablespace TEST datafile '/u01/app/oradata/PRODSTD/Disk1/test01.dbf' size 20M;

这里 PRODSTD 可以创建成功,但在 PROD 无法查到啊,日志也没有错误

select sequence#,applied from v$archived_log order by sequence#;

--原来是忘记启用 PROD 上面的日志应用了

SQL> alter database recover managed standby database disconnect from session;

这一次日志里面出现了期待的错误,也需要把路径转换才行

ORA-01274: cannot add datafile '/u01/app/oradata/PRODSTD/Disk1/test01.dbf' - file could not

be created

alter system db_file_name_convert=’PRODSTD’,’PROD’ scope=spfile;

当现在的备机 PROD 再次启动到 mount


可以成功应用日志了,因为之前的错误路径,导致如下提示

ORA-01111: name for data file 13 is unknown - rename to correct file

ORA-01110: data file 13: '/u01/app/oracle/product/10.2.0/db_1/dbs/UNNAMED00013'

手工在相应目录下产生了一个文件

[oracle@odd Disk1]$ touch test01.dbf

[oracle@odd Disk1]$ ls

control_01.ctl lob_data01.dbf redo01.log sysaux01.dbf temp01.dbf undotbs01.dbf

data01.dbf oltp_01.dbf reg_01.dbf system01.dbf test01.dbf

SQL> alter database rename file '/u01/app/oracle/product/10.2.0/db_1/dbs/UNNAMED00013' to

'/u01/app/oradata/PROD/Disk1/test01.dbf';

SQL> Alter database recover managed standby database disconnect from session;

恢复报错，呵呵，不认识我建立的文件啊

Errors in file /u01/app/admin/PROD/bdump/prod_mrp0_15241.trc:

ORA-01110: data file 13: '/u01/app/oradata/PROD/Disk1/test01.dbf'


ORA-01115: IO error reading block from file 13 (block # 1)

ORA-27069: attempt to do I/O beyond the range of the file

删除了也无法通过日志恢复

Errors in file /u01/app/admin/PROD/bdump/prod_mrp0_15348.trc:


ORA-01157: cannot identify/lock data file 13 - see DBWR trace file


Thu May 8 13:11:50 2014

MRP0: Background Media Recovery process shutdown (PROD)

Thu May 8 13:11:51 2014

Completed: Alter database recover managed standby database disconnect from session

单独在 PRODSTD 备份新建的数据文件在 PROD 恢复看看

RMAN> backup as copy datafile 13 format '/home/oracle/backup/test01.dbf';

[oracle@event backup]$ scp test01.dbf odd:/u01/app/oradata/PROD/Disk1/

再次在 PROD 上恢复,这次可以成功恢复了

再次测试下数据能否传过去

SQL> create table tt tablespace test as select * from test;

在备机 PROD 上

SQL> alter database recover managed standby database cancel;

SQL> alter database open read only;

SQL>select segment_name,tablespace_name from dba_segments where segment_name='TT';

可以查询到 TT 确实建立在 TEST 空间下

SQL> drop tablespace test including contents and datafiles;

也可以在 PROD 上发现被删除 --因为 PROD 重启了,需要在 PRODSTD 上 enable 下

再次切换回主机也没有任何问题，很快完成

select process,pid,status,client_process from v$managed_standby;

可以查看 rfs 进程号

,默认是 performance

结论:要设置成 AVAILABILITY 模式,主库的 LOG_ARCHIVE_DEST_1 2 必须设置成 SYNC,而且备

库必须有 standby redo

select protection_mode,protection_level from v$database;


SQL> startup mount;

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;

SQL> alter database open; --启动不起来,自动当掉

ORA-03113: end-of-file on communication channel

alert 有明确的日志

LGWR: Primary database is in MAXIMUM AVAILABILITY mode

LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR

LGWR: Minimum of 1 LGWR standby database required

Thu May 8 14:56:15 2014

Errors in file /u01/app/admin/PROD/bdump/prod_lgwr_19607.trc:

ORA-16072: a minimum of one standby database destination is required

先在 PRODSTD 添加 standby log

SQL> alter database add standby logfile group 4

'/u01/app/oradata/PRODSTD/Disk1/redostd01.log' size 10M;


'/u01/app/oradata/PRODSTD/Disk1/redostd02.log' size 10M;

PROD

还是启动不起来

alter system set log_archive_dest_state_2=enable; --原来是 2 没有 enable

SQL> alter system set log_archive_dest_2='service=PRODSTD LGWR ASYNC AFFIRM'

必须要用 SYNC

SQL> alter system set log_archive_dest_2='service=PRODSTD LGWR SYNC AFFIRM'

SQL> alter database open;

可以成功打开了

select protection_mode,protection_level from v$database;

LOG_ARCHIVE_CONFIG 默认就是 send,receive

实验下不发生日志看看

无法设置 NOSEND ,NORECEIVE

下面实验把 prod 主库变成最大保护模式

SQL> startup mount;

alter database set standby database to maximize protection;

报告如下错误，并当掉了

ORA-16057: DGID from server not in Data Guard configuration --告诉需要设置 dg_config

Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED

LGWR: Error 16057 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host

'PRODSTD'

LGWR: Continuing...

LGWR: Minimum of 1 applicable standby database required

SQL> alter system set log_archive_config='dg_config=(PROD,PRODSTD)';

SQL> alter system set log_archive_dest_2='service=PRODSTD LGWR SYNC AFFIRM

DB_UNIQUE_NAME=PRODSTD';

ORA-16047: DGID mismatch between destination setting and standby

检查 log_archive_config, log_archive_dest_2,很可能是那个地方设置错误了

把主库的 log_archive_config, log_archive_dest_2 重新设置了一遍，重启好了

测试备库也要是 log_archive_config 才不会报告这个错误

真正的原因是LOG_ARCHIVE_DEST_2里的DB_UNIQUE_NAME跟目标地址的不一致造成的.

(ID 172779.1)

结论要配置为 protecion,主库必须设置 LOG_ARCHIVE_CONFIG,并且 LOG_ARCHIVE_DEST_2 必

须是 LGWR SYNC AFFIRM,而且必须有 DB_UNIQUE_NAME

再次来实验下切换实验

LGWR: RFS network connection re-established at host 'PROD'

LGWR: Error 16086 opening RFS destination for reconnect

Thu May 8 16:06:10 2014

Errors in file /u01/app/oracle/product/10.2.0/db_1/rdbms/log/prodstd_lgwr_17904.trc:

ORA-16086: standby database does not contain available standby log files

LGWR: Error 16086 creating archivelog file 'PROD'

PROD 库明明已经有 standby 日志了啊

SQL> select group#,sequence#,bytes,used,archived,status from v$standby_log;

GROUP# SEQUENCE# BYTES USED ARC STATUS

---------- ---------- ---------- ---------- --- ----------

4 0 10485760 512 YES UNASSIGNED

5 0 10485760 512 YES UNASSIGNED

6 0 10485760 512 YES UNASSIGN

删除了重建照样报错

后来只能先变到

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;

才能成功打开

再次切换回去又报告如下错误,是归档进程在作怪,但不影响使用

ORA-16009: remote archive log destination must be a STANDBY database

可以加入 valid_for 解决

两变都设置后没有再报 ORA-16009 错误

alter system set log_archive_dest_2='service=PRODSTD LGWR SYNC AFFIRM

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PRODSTD';

alter system set log_archive_dest_2='service=PROD LGWR SYNC AFFIRM

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PROD';

备变主，主再变备是报告如下错误

alter database commit to switchover to physical standby with session shutdown;

ORA-16416: Switchover target is not synchronized with the primary

备库出现 gap sequence 现象

日志有如下提示


ORA-01153: an incompatible media recovery is active

Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization

parameter is defined to a value that is sufficiently large

enough to maintain adequate log switch information to resolve

archivelog gaps.

这里检查发现就是备库的控制文件 CURRENT_SCN 比 datafile 和 datafile_header 小,后面两个

跟主库是一致的

SELECT CURRENT_SCN FROM V$DATABASE;

select CHECKPOINT_CHANGE# from v$datafile;

select CHECKPOINT_CHANGE# from v$datafile_header;

处理方法: 在主库重新产生控制文件覆盖到备考

我这边碰到的情况是 current_scn 比数据文件 scn 大,结果重新主库产生控制文件到备库好了

主库:

alter database create standby controlfile as '/home/oracle/cont.ctl';

备库:



拷贝主库产生的控制文件到备库相应位置

SQL> startup mount;


备库错误依旧,参考 http://www.xifenfei.com/1176.html

备库:

SQL> SELECT CURRENT_SCN FROM V$DATABASE;

CURRENT_SCN

-----------

707981

主库操作

--在出现意外 datafile header scn不一致的时候,需要根据提示归档日志,找出最小 scn

确认有没有新加数据文件:

SQL> select FILE#,name from v$datafile where CREATION_CHANGE#> =707981;

no rows selecte

增量备份,并传到备库相应目录

BACKUP INCREMENTAL FROM SCN 707981 DATABASE

FORMAT '/home/oracle/backup/INC_%U';

备库停日志

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

备库进行恢复

catalog start with '/home/oracle/backup';

RMAN> recover database noredo;

主库创建 standby controlfile 传到备库

backup current controlfile for standby format '/home/oracle/control.bak';

[oracle@event ~]$ scp control.bak odd:/home/oracle/backup

备库恢复

SQL> shutdown;

SQL> startup nomount;

RMAN> restore standby controlfile from '/home/oracle/backup/control.bak';

RMAN> alter database mount;

清空所有备库日志组:

alter database clear logfile group 1-5;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

SQL> alter system switch logfile;

select max(sequence#) from v$archived_log;

--我的问题依旧,两边没有设置 fal,备库日志如下,总是无法应用最新的日志

Wed May 21 16:18:45 2014

FAL[client]: Failed to request gap sequence

GAP - thread 1 sequence 98-99

DBID 259228821 branch 847390485

FAL[client]: All defined FAL servers have been attempted.

-------------------------------------------------------------

Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization

parameter is defined to a value that is sufficiently large

enough to maintain adequate log switch information to resolve

archivelog gaps.

碰到 gap 也可手工把主库的日志文件传到备库来注册

scp 1_4[98-99]_8000120.dbf 192.168.11.91:/u01/Disk2/arch/ 实验了批量不行啊

alter database register logfile '/home/oracle/arch/1_52_853765302.dbf';

…….

经过注册这些信息,保证备库的 V$ARCHIVED_LOG 可以查到这些日志信息，而后再执行

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

就会慢慢应用这些日志

后来备库添加的 standby_log

SQL> alter database add standby logfile group 6 '/u01/app/oradata/PROD/Disk1/redostd06.log'

size 100M reuse;

SQL> alter database add standby logfile group 7 '/u01/app/oradata/PROD/Disk1/redostd07.log'

size 100M reuse;

问题依旧


SQL> select error from v$archive_dest;

ORA-16086: standby database does not contain available standby

log files

当主库也添加了 standby logfile 后，问题消失了,两边最大日志一致

碰到一次主备两边都有也报这个错误，后来删除了重建就 ok 了

又一次重建也无法解决啊，而且备库日志组比主还多一组，大小也一样

推测是设置成 MAXIMIZE AVAILABILITY,要做更多的检查,按理是不需要 standby log 也行的啊.


'/u01/app/oradata/PRODSTD/Disk1/redostd06.log' size 100M reuse;

SQL> SQL> alter database add standby logfile group 7

'/u01/app/oradata/PRODSTD/Disk1/redostd07.log' size 100M reuse;


SQL> select max(sequence#) from v$archived_log;

ORA-16401: archivelog rejected by RFS

这个错误官网说是主库的 log_archive_dest_2 对应 service 名字跟备库 fal_client 不一致造成，

可我设置成了还是报错，后来干脆降级到 PERFORMANCE,并且主库重建备库控制文件并覆盖

到备库启动后正常.

模拟异常恢复

主库:

SQL> shutdown abort

备库: SQL> alter database recover managed standby database finish force;

--如果是 sync 不会丢数据

SQL> alter database commit to switchover to primary;

SQL> alter database open;

在当前主库这些状态不变的情况下用 gc 创建备库

这里也不删除主库的 local_listener 和 resouce plan

主库上有两个监听 1521,1526

主库改为 performance 后可以继续了

可以创建成功,而且主库原有的参数没有改变,包括 log_archive_dest_2,valid_for,dg_config 等

但我主库切换日志备库没有反应

SQL> alter system set log_archive_dest_state_2=enable 也不凑效

ORA-12154: TNS:could not resolve the connect identifier specified

我重启主库后好像症状消失

貌似要两边 max(sequence#)相等才能出现下面界面

在主库添加数据文件测试

备库老是无法转变路径,已经设置了 db_file_name_convert 好像没有

通过 GC 创建 dg 后备库无法启动，创建失败

Errors in file /u01/app/oracle/product/10.2.0/db_1/rdbms/log/prodstd_ora_25735.trc:

ORA-07452: specified resource manager plan does not exist in the data dictionary

Error 7452 happened during db open, shutting down database

USER: terminating instance due to error 7452

Instance terminated by USER, pid = 25735

ORA-1092 signalled during: ALTER DATABASE OPEN READ ONLY..

官网解释:

Attempt to open the database without resource manager plan.

看来需要之前把资源管理 resource_plan 去掉

题目要求只需要 2 组 standby_redo,而用 GC 建出来的是 6 组 standby 日志,备库可以先停止接

受日志，再删除多余，重启到

mount 状态,gc 里面就可以看不到错误状态了(保护模式为 max imize availability )


select group#,sequence# from v$standby_log;

alter database drop logfile group 8;




删除上面 standby 日志后状态会有错，可以点击进去 reset 下

SQL> alter database recover managed standby database cancel;

Database altered.

SQL> alter database drop logfile group 6;

alter database drop logfile group 6

ERROR at line 1:

ORA-00261: log 6 of thread 1 is being archived or modified

ORA-00312: online log 6 thread 1: '/u01/app/oradata/SPDB/DIsk1/std01.log'

促使 RFS 进程释放 standby redo log 文件有两种方法：

1．等待 RFS 进程的 network timeout，通常需要等待 8 分钟左右

2．关闭 standby 数据库，再重新开启，这样会强制 RFS 进程释放 standby redo log

我们可以通过 v$managed_standby 视图来监控 RFS 进程何时释放

切换一次竟然发生了下面错误: ora-16136 ora-16139

原因是变成备库后没有 recover 日志

alter database recover managed standby database disconnect from session;

--变成备库后这一步一定要执行，如果不应用日志，再切换回来报告 ora-16139 错误的

因为手工创建过,主库忘记修改参数了，直接用 gc 创建,出现 ORA-07452 错误，没有成功,

准备第二次创建报告如下错误 ora-16504

dgmgrl sys/oracle@prod

dgmgrl >show configuration;

手工删除这两个配置文件,并从 GC 里面删除 PROD 库而后重新注册进去

下面这个错误好像选择另外一个端口 1380 就可以,为什么客户端一个 agent 有两个端口

客户端 agent 对应的有效端口确实是 1830

下面这个错误多刷新下下就没了

默认备库是不启用实时应用日志的

因为空间问题不小心删除了归档日志，还没有来得及应用到备库上，报告如下错误:

Clearing online redo logfile 4 complete

Media Recovery Waiting for thread 1 sequence 107

Fetching gap sequence in thread 1, gap sequence 107-107

Sun Sep 28 13:23:26 2014



DBID 270895426 branch 859057090

1: SQL> SELECT SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE# FROM v$archived_log WHERE

SEQUENCE# >106;

2:增量备份

backup device type disk incremental from scn 2729603 database format

'/home/oracle/backup/incr_%U.bak';

拷到备库

[oracle@odd backup]$ scp incr_* even:/home/oracle/backup

SQL> ALTER DATABASE recover managed standby DATABASE cancel;

RMAN> catalog backuppiece '/home/oracle/backup/incr_14pjlabd_1_1.bak';

catalog backuppiece '/home/oracle/backup/incr_15pjlabt_1_1.bak';

recover DATABASE noredo;

ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION;

备库仍然报告



SELECT file#,checkpoint_change# FROM v$datafile ORDER BY 1;

FILE# CHECKPOINT_CHANGE#

---------- ------------------

1 2731453

SELECT file#,checkpoint_change# FROM v$datafile_header ORDER BY 1;

FILE# CHECKPOINT_CHANGE#

---------- ------------------

1 2739320

SQL> ALTER DATABASE recover managed standby DATABASE cancel;

Database altered.


ERROR at line 1:

ORA-16004: backup database requires recovery

ORA-01152: file 1 was not restored from a sufficiently old backup

ORA-01110: data file 1: '/u01/app/oradata/SPDB/Disk1/system01.dbf'

重新创建备库控制文件

alter database create standby controlfile as '/home/oracle/std.ctl';

[oracle@odd ~]$ scp std.ctl even:/home/oracle

RMAN> startup nomount;

RMAN> restore controlfile from '/home/oracle/std.ctl';

RMAN> alter database mount;

ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION;

ALTER DATABASE recover managed standby DATABASE cancel;

问题依旧啊


ORA-16004: backup database requires recovery

ORA-01152: file 1 was not restored from a sufficiently old backup

ORA-01110: data file 1: '/u01/app/oradata/SPDB/Disk1/system01.dbf'

Documents

DG°²×° (1)