1. 程式人生 > >如何利用閃回資料庫特性恢復failover 後的dataguard 環境?

如何利用閃回資料庫特性恢復failover 後的dataguard 環境?

11g dataguard standby 切成主庫,測試完成後恢復為原standby 環境


#######################
概述:
11204 單機對單機實施dg,因局方要求需要(讀寫模式)開啟standby ;而這時原生產環境不能有任何影響動,依然對外服務;
採用的思路是:standby 直接failover 為primary db;這時原有dg關係被破壞,互不影響;


#######################
思路概要:
1.確認主庫歸檔日誌存放空間是否足夠?(需考慮歸檔保留刪除策略?);關閉主庫到備庫的日誌傳輸
2.備庫確認是否開啟flashback database,以及閃回日誌存放空間是否充足?
3.備庫failover to primary (切換前確認是否日誌延遲傳輸?手工註冊)
4.業務測試
5.恢復failover 備庫
6.確認dg 環境恢復是否正常(日誌自動傳輸和應用?)?



#######################
具體實施步驟:

------主庫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 <standby_became_primary_scn of step 1>;

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;


--確認日誌是否都apply了?
select applied from v$archived_log;

select message from v$dataguard_status;


Step 5 Start Redo Apply. 
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Please see also fallowing docu:


TIPS:
Oracle? Data Guard Concepts and Administration
11g Release 2 (11.2)
13.2 Converting a Failed Primary Into a Standby Database Using Flashback Database

相關推薦

如何利用資料庫特性恢復failover dataguard 環境

11g dataguard standby 切成主庫,測試完成後恢復為原standby 環境 ####################### 概述: 11204 單機對單機實施dg,因局方要求需要(讀寫模式)開啟standby ;而這時原生產環境不能有任何影響動,依然對外服

【DG】利用資料庫(flashback)修復Failover的DG環境

13.2.1 Flashing Back a Failed Primary Database into a Physical Standby Database The following steps assume that a failover has been performed to a

oracle update並commit誤操作利用方法 flashback可以還原上個時間點的資料

今天在生產環境更新一個選單的URL時,用update更新資料,但是忘記加上where限定條件,將所有選單的URL都更新為同一個。一時間感覺我惹大事了,慌忙找了個以前的備份表將整個表替換掉。可是備份表與真是表之間存在一些差異,結果就只能一個一個查詢並修改了。 事後才淡定下來,

利用功能恢復刪除(drop,delete)的資料和表及資料,update之後資料恢復

一、drop表 從 flashback table 裡查詢被刪除的資料表 1、select * from recyclebin order by droptime desc 2、執行表的恢復flashback table '需要恢復的表名' to before drop

使用功能快速恢復用戶的誤操作

查看表 問題 使用 策略 mail 關註 because 基於 實驗 Oracle提供的閃回特性對於快速恢復誤操作的數據起到了非常大的幫助。在沒有這個特性的Oracle早期版本,如果需要恢復因用戶錯誤導致的數據丟失,需要大量的時間和精力去做不完全恢復。 不過,這種用空間換

記憶體資料庫事務恢復優化

事務處理事資料庫最獨特的地方,事務操作可以保證資料庫處理操作的原子性、一致性、隔離性和永續性,推動了資料庫在商業領域的成功應用。 事務恢復時資料庫支援事務的重要功能,可以保證資料的一致性和正確性,資料庫在實際的執行過程中,會不可避免的發生各種故障,那麼必須建立有效的事務恢復的措施。在快閃

oracle的查詢、表、資料庫(轉)

/* 一、 要使用閃回查詢,資料庫必須開啟automatic undo management,必須有undo表空間,必須設定好回滾段的保留時間 */ -- 在sqlplus中檢視undo_management引數值是否為AUTO,如果是“MANUAL”手動,需要修改為“A

oracle資料庫

SQL> alter system set db_recovery_file_dest_size=10g; System altered. SQL> alter system set db_recovery_file_dest='/arch';

oracle資料功能(恢復誤刪除的表資訊)

1  ORACLE用PL/SQL提交資料後執行回滾的方法  1、如果資料庫表,不支援閃回功能   alter table A enable row movement;  2、查詢刪除資料的時間點的資料(也就是閃回至該時間點之前的資料)    select * from A

Oracle DB執行資料庫

BEGIN_TIM END_TIME FLASHBACK_DATA DB_DATA REDO_DATA EST_FB_SZE --------- --------- -------------- ---------- ---------- ---------- 12-FEB-09 12-FEB-09 163

FlashBack總結之資料庫刪除

SQL> select * from v$flashback_database_logfile; NAME                                                                    LOG#    THREAD# SEQUENCE#      

ORA-38760: 此資料庫例項無法啟用資料庫:guarantee restore point 導致

        一大早起來開啟sqlplus的時候,發現數據庫啟動不了,並且出現下面的錯誤: SQL*Plus: Release 11.2.0.1.0 Production on Sat Aug 17 09:04:48 2013 Copyright (c) 1982, 2

drop恢復sql運行計劃異常

for 恢復 per style lec name ora acl ont -----正常運行計劃 set autotrace traceonly set linesize 1000 select /*+index(t idx_object

oracle數據庫誤刪數據,及時恢復數據

誤刪數據 不重復 timestamp 恢復數據 重復 恢復 重新 times oracl 刪除數據後最好不要進行其他無關操作 ①確定刪除數據的時間 ②此語句找出刪除的數據:select * from 表名 as of timestamp to_timestamp(‘刪除時間

oracle利用flashback 功能恢復delete資料

select * from tablename  as of timestamp to_timestamp('2010-06-12 13:00:00','yyyy-mm-dd hh24:mi:ss'); flashba

資料庫恢復區滿了解決

1、刪除歸檔日誌 $rman target / RMAN> list archivelog all; RMAN>crosscheck archivelog all; RMAN>change archivelog until logseq=130 th

Oracle技術之一Oracle 11g 利用FlashTable (表)恢復(用delete)誤刪的資料

閃回表,實際上就是將表中的資料快速恢復到過去的一個時間點或者系統改變號SCN上。實現表的閃回,需要用到撤銷表空間相關的UNDO資訊,通過SHOW PARAMETER UNDO命令就可以瞭解這些資訊。使用者對錶的資料的修改操作,都記錄在撤銷表空間中,這為表的閃回提供的資料恢

關於Oracle誤操作--資料被Commit的資料退恢復

     今天操作Oracle資料庫時,做一個Update資料時,不小心少寫了個where,看這粗心大意的。   於是乎,把所有的員工工號都給更新成一個同一個工號了。這是一個悲催的故事。   因為工號是Check了好多次才存入資料庫,工號是唯一性的啊~~   不過,

1. Oracle 特性(FLASHBACK DATABASE)

tables sys down stand mar lec ott file select 轉載自:http://blog.csdn.net/leshami/article/details/6100429 閃回技術通常用於快速簡單恢復數據庫中出現的認為誤操作等邏輯錯誤,

2.Oracle 特性(FLASHBACK DROP & RECYCLEBIN)

employ 功能 BE rim group .net rac tro acl 轉載自:https://blog.csdn.net/leshami/article/details/6105327 FLASHBACK DROP 特性允許在不丟失任何數據庫的情況下將指定的表