1,只需要执行以下个脚本即可。
2,查看utl_file_dir设置
3, 可以通过命令行修改此参数,也可以通过修改pfile文件设置此参数。
4,该参数为静态参数,需重启数据库后生效,创建LOGMNR数据字典。
5,添加需要分析的归档日志。
6,开始日志挖掘,分析日志。
7,查看日志信息,就可以了。
win10系统不同的还原方式所要使用的时间不同:
1、只还原C盘部分所要使用的时间很短,约一小时左右。
2、还原所有文件(释放镜像),约5到6小时。
3、还原点还原,约4到5小时。
还原点提供与闪回数据库和其他介质恢复 *** 作相关的功能。 特别是,在系统改变号(SCN)上创建的保证还原点可以使用闪回数据库将数据库回滚到此SCN。 还原点功能和闪回数据库功能可以单独使用,也可以一起使用。
扩展资料
保证还原点与正常还原点一样充当恢复 *** 作中SCN的别名。 主要区别在于保证的还原点永远不会超出控制文件的范围,必须明确删除。它的使用和正常还原点没有区别。
需要注意的是,无论是否启动了闪回数据库功能,保证还原点都可以使用闪回数据库将数据库回滚到还原点SCN的状态。 如果启用了闪回日志记录,则保证还原点会强制保留从最早的保证还原点之后,闪回数据库闪回到任意SCN所需的闪回日志。
因此,如果启用了闪回日志记录,则可以将数据库闪回到开启保证还原点以后的任何SCN,而不是仅闪回到单个SCN。
参考资料来源:
百度百科——还原点
-----主库defer 日志传输alter system set log_archive_dest_2=defer
---enable 日志传输:
alter system set log_archive_dest_2=enable;
-----备库(mount)配置 flashback database:
STANDBY DATABASE: Stop redo apply, configure flashback retention,
start flashback database, open the database and start redo apply (Is active DG).
---检查备库是否启用flashback database:
select flashback_on from v$database
注意这里需要确认下备库打开模式: mount?readonly with apply?
在11g 环境下备库可能启用了 ADG 特性 备库日志处于实时应用,数据库模式为 readonly with apply
这时需要重启数据库到mount状态修改flashback database 模式;
如果备库处于mount 状态,可以先取消日志apply ,直接打开闪回数据库特性;
---取消备库日志应用:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
---需要配置一下两个参数来打开flashback database 特性:
ALTER SYSTEM SET db_recover_file_dest='/lixora/lixora/lixora/'
ALTER SYSTEM SET db_recover_file_dest_size=100G
ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=240---4hours
ALTER DATABASE FLASHBACK ON
--手工创建还原点(该步骤没有测试过):
Creating Restore point in Physical Standby:
CREATE RESTORE POINT before_damage GUARANTEE FLASHBACK DATABASE
-------备库failover to primary db 应急切换步骤:
(注:模拟主库由于故障无法正常switchover,需要执行failover,强制备库->pridb并接管业务)
1.备库:
由于是failover,所以理解主库这时候已经无法正常使用,只需备库切换至pridb
【前提主库还是可用的:可选】查询没有应用的日志:
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP
select distinct thread#,max(sequence#) over(partition by thread#) a from v$archived_log
该语句取得当前数据库各线程已归档文件最大序号,如果primary 与standby 最大序号不相同,
必须将多出的序号对应的归档文件复制到待转换的standby服务器。
Cp过来并register
ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1'
停止应用恢复模式
alter database recover managed standby database finish
or
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE
转换standbydb为primary db
alter database commit to switchover to primary
重启数据库,恢复正常业务
alter database open;
数据库角色查看:
select open_mode,database_role from v$database
OPEN_MODE DATABASE_ROLE
---------- ----------------
OPEN PRIMARY
------恢复failover 的备库:
C. Using SQL*PLUS
Step 1 Determine the Standby Became Primary SCN.
Step 2 Flashback the Failed Primary Database.
Step 3 Convert to physical standby database.
Step 4 Restart Redo Transport.
Step 5 Start Redo Apply.
Step 1 Determine the SCN at which the old standby database became the primary database.
SQL>SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE
Step 2 Flashback the Failed Primary Database to SCN standby_became_primary_scn.
SQL>SHUTDOWN IMMEDIATE
SQL>startup mount
SQL>FLASHBACK DATABASE TO SCN
Step 3 Convert the database to a physical standby database and Restart database in mount stage.
SQL>ALTER DATABASE CONVERT TO PHYSICAL STANDBY
SQL>SHUTDOWN IMMEDIATE
SQL>STARTUP MOUNT
Step 4 Restart Redo Transport to the New Physical Standby Database.
1. If you have not set the remote archive destination on current primary then set remote archive destination:
SQL>ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 = 'SERVICE=lixora VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=lixora' SCOPE=BOTH
2. Enable the destination
SQL>ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE
3. Perform a log switch to ensure that standby database begins receiving redo data from the new primary database
SQL>ALTER SYSTEM SWITCH LOGFILE
SQL>SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST WHERE DEST_ID=2
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)