巧用flashback database實現靈活的資料切換
今天是DTCC第二天了,抽空去聽了下,因為手頭有一些活,聽到一半隻能趕回公司繼續工作。
客戶今天有一個需求,因為開發現在在生產環境中遇到了一些困難,需要在測試生產環境中復現問題,這樣就需要從生產環境抽取出一些資料,可能資料量相對比較小,有個1G左右。需要把這些資料載入到測試生產環境中,
還是來張圖更加清晰。我們需要把圖中右邊部分的生產環境中抽取部分資料匯入到測試生產環境中,這裡所說的測試生產環境是按照生產環境的結構來複制的。測試環境已經有一些測試資料,很可能和生產環境中的資料衝突。
就如同圖中下面的部分列出的細節一樣,很可能會存在資料衝突導致資料載入出現問題。
按照一般的情況下,我們是建議對測試生產環境做一個備份,採用expdp即可,然後清空對應schema下的資料,然後倒入需要重現問題的資料。問題復現之後,可以使用備份把資料恢復回來。
但是這種固有的思想還是存在一定的問題。
客戶反饋的情況如下,說對應的schema下的資料量是相當大的,差不多2T多,如果做備份也是需要不少的空間,匯出匯入都是相當消耗時間和資源的。
OWNER SUM(BYTES)/1024/1024
------------------------------ --------------------
APPO 2144666.63
這套環境借用的時間為3天,所以相對來說測試環境的高可用要求就沒那麼高了。
我們可以嘗試採用flashback database來完成這種需求。
使用flashback database會有一些的顧慮和隱患,比如
閃回時間的考慮,如果考慮不周很可能達不到預期的效果。
資料庫中預設是不會啟用閃回資料庫功能的,需要啟用,完成資料恢復之後,再禁用,這些過程都是需要停庫啟庫的,對於中介軟體來說就需要重新啟動,需要和開發測試部分做協調,是否同意這種方式。
資料庫做閃回操作之後,閃回到了資料清除前的狀態,這個時候如果要開啟資料庫,是需要使用open resetlogs這種方式的,這樣的話這個時間點之前的備份就失效了。也需要做確認,確保不會出現業務上意料之外的情況。
很快得到了回覆,看來對於這種方式大家也是認可的,畢竟能夠免去大量的備份和資料匯入匯出之苦。操作上也相對比較方便。
我們使用下面的指令碼來簡單模擬一下。我們建立一個表,然後啟用flashback database功能,做truncate操作,然後匯入一些新的資料,之後再做閃回資料庫操作,閃回到truncate之前的資料情況,最後啟用資料庫即可。
修改閃回保留的時間,預設是1440分鐘,即24小時
SQL> show parameter flashback
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_flashback_retention_target integer 1440
我們建立了一個表,大小為2G左右,這樣能夠簡單驗證一下閃回日誌的增長情況。
SQL> select segment_name,bytes from user_segments where segment_name='AA';
SEGMENT_NAME BYTES
--------------- ----------
AA 2153775104
SQL> SELECT COUNT(*)FROM AA;
COUNT(*)
----------
18340352
我們開始啟用閃回資料庫功能。
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 435224576 bytes
Fixed Size 1337044 bytes
Variable Size 272632108 bytes
Database Buffers 155189248 bytes
Redo Buffers 6066176 bytes
Database mounted.
SQL> alter database flashback on;
Database altered.
SQL>
SQL> alter database open;
Database altered.
啟用之後,得到一個時間戳,一次來作為我們完成閃回的時間點。
select systimestamp from dual;
接著我們來做一個清理工作。
SQL> truncate table aa;
Table truncated.
我們嘗試插入一部分
SQL> insert into aa select*from all_objects;
71642 rows created.
SQL> commit;
Commit complete.
這個資料量相比原本的2G就小了很多。
然後我們嘗試使用閃回資料庫功能,閃回到刪除之前的狀態。
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down
SQL> startup mount;
ORACLE instance started.
Total System Global Area 435224576 bytes
Fixed Size 1337044 bytes
Variable Size 272632108 bytes
Database Buffers 155189248 bytes
Redo Buffers 6066176 bytes
Database mounted.
SQL> Flashback database to timestamp to_timestamp('2015-04-17 17:42:29','yyyy-mm-dd hh24:mi:ss');
Flashback complete.
以只讀方式開啟,做驗證,保證閃回沒有問題。
SQL> alter database open read only;
Database altered.
SQL> conn n1/n1
Connected.
SQL> select count(*)from aa;
COUNT(*)
----------
18340352
資料又回來了。
檢視閃回日誌的大小,可以看到還是很少的。
total 16040
-rw-r----- 1 ora11g dba 8200192 Apr 17 17:43 o1_mf_bm1oc2qt_.flb
-rw-r----- 1 ora11g dba 8200192 Apr 17 17:45 o1_mf_bm1ofwb7_.flb
[ora11g@oel1 flashback]$ pwd
/u02/ora11g/flash_recovery_area/TEST11G/flashback
[ora11g@oel1 flashback]$
另外說明一下,對於閃回資料庫功能,如果禁用之後,閃回日誌會自動清除。
客戶今天有一個需求,因為開發現在在生產環境中遇到了一些困難,需要在測試生產環境中復現問題,這樣就需要從生產環境抽取出一些資料,可能資料量相對比較小,有個1G左右。需要把這些資料載入到測試生產環境中,
還是來張圖更加清晰。我們需要把圖中右邊部分的生產環境中抽取部分資料匯入到測試生產環境中,這裡所說的測試生產環境是按照生產環境的結構來複制的。測試環境已經有一些測試資料,很可能和生產環境中的資料衝突。
就如同圖中下面的部分列出的細節一樣,很可能會存在資料衝突導致資料載入出現問題。
按照一般的情況下,我們是建議對測試生產環境做一個備份,採用expdp即可,然後清空對應schema下的資料,然後倒入需要重現問題的資料。問題復現之後,可以使用備份把資料恢復回來。
但是這種固有的思想還是存在一定的問題。
客戶反饋的情況如下,說對應的schema下的資料量是相當大的,差不多2T多,如果做備份也是需要不少的空間,匯出匯入都是相當消耗時間和資源的。
OWNER SUM(BYTES)/1024/1024
------------------------------ --------------------
APPO 2144666.63
這套環境借用的時間為3天,所以相對來說測試環境的高可用要求就沒那麼高了。
我們可以嘗試採用flashback database來完成這種需求。
使用flashback database會有一些的顧慮和隱患,比如
閃回時間的考慮,如果考慮不周很可能達不到預期的效果。
資料庫中預設是不會啟用閃回資料庫功能的,需要啟用,完成資料恢復之後,再禁用,這些過程都是需要停庫啟庫的,對於中介軟體來說就需要重新啟動,需要和開發測試部分做協調,是否同意這種方式。
資料庫做閃回操作之後,閃回到了資料清除前的狀態,這個時候如果要開啟資料庫,是需要使用open resetlogs這種方式的,這樣的話這個時間點之前的備份就失效了。也需要做確認,確保不會出現業務上意料之外的情況。
很快得到了回覆,看來對於這種方式大家也是認可的,畢竟能夠免去大量的備份和資料匯入匯出之苦。操作上也相對比較方便。
我們使用下面的指令碼來簡單模擬一下。我們建立一個表,然後啟用flashback database功能,做truncate操作,然後匯入一些新的資料,之後再做閃回資料庫操作,閃回到truncate之前的資料情況,最後啟用資料庫即可。
修改閃回保留的時間,預設是1440分鐘,即24小時
SQL> show parameter flashback
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_flashback_retention_target integer 1440
我們建立了一個表,大小為2G左右,這樣能夠簡單驗證一下閃回日誌的增長情況。
SQL> select segment_name,bytes from user_segments where segment_name='AA';
SEGMENT_NAME BYTES
--------------- ----------
AA 2153775104
SQL> SELECT COUNT(*)FROM AA;
COUNT(*)
----------
18340352
我們開始啟用閃回資料庫功能。
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 435224576 bytes
Fixed Size 1337044 bytes
Variable Size 272632108 bytes
Database Buffers 155189248 bytes
Redo Buffers 6066176 bytes
Database mounted.
SQL> alter database flashback on;
Database altered.
SQL>
SQL> alter database open;
Database altered.
啟用之後,得到一個時間戳,一次來作為我們完成閃回的時間點。
select systimestamp from dual;
接著我們來做一個清理工作。
SQL> truncate table aa;
Table truncated.
我們嘗試插入一部分
SQL> insert into aa select*from all_objects;
71642 rows created.
SQL> commit;
Commit complete.
這個資料量相比原本的2G就小了很多。
然後我們嘗試使用閃回資料庫功能,閃回到刪除之前的狀態。
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down
SQL> startup mount;
ORACLE instance started.
Total System Global Area 435224576 bytes
Fixed Size 1337044 bytes
Variable Size 272632108 bytes
Database Buffers 155189248 bytes
Redo Buffers 6066176 bytes
Database mounted.
SQL> Flashback database to timestamp to_timestamp('2015-04-17 17:42:29','yyyy-mm-dd hh24:mi:ss');
Flashback complete.
以只讀方式開啟,做驗證,保證閃回沒有問題。
SQL> alter database open read only;
Database altered.
SQL> conn n1/n1
Connected.
SQL> select count(*)from aa;
COUNT(*)
----------
18340352
資料又回來了。
檢視閃回日誌的大小,可以看到還是很少的。
total 16040
-rw-r----- 1 ora11g dba 8200192 Apr 17 17:43 o1_mf_bm1oc2qt_.flb
-rw-r----- 1 ora11g dba 8200192 Apr 17 17:45 o1_mf_bm1ofwb7_.flb
[ora11g@oel1 flashback]$ pwd
/u02/ora11g/flash_recovery_area/TEST11G/flashback
[ora11g@oel1 flashback]$
另外說明一下,對於閃回資料庫功能,如果禁用之後,閃回日誌會自動清除。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-1584057/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 巧用flashback database實現靈活的資料回滾Database
- 資料庫訪問抽象類實現專案資料庫靈活切換資料庫抽象
- [Flashback]Flashback Database閃回資料庫實驗Database資料庫
- 【Flashback】Flashback Database閃回資料庫功能實驗Database資料庫
- 【Flashback】Flashback Database閃回資料庫功能實踐Database資料庫
- 如何實現車聯網的靈活資料採集
- VC中實現多格式影像的靈活轉換 (轉)
- 實現了所有主流APP的分類切換效果,可快速接入,靈活擴充套件(swift)APP套件Swift
- Flashback Database 閃回資料庫Database資料庫
- 【Flashback】啟用Flashback Database閃回資料庫功能Database資料庫
- 巧用濾鏡實現高階感拉滿的文字快閃切換效果
- Spring實現多資料來源動態切換Spring
- MHA實現mysql主從資料庫手動切換的方法MySql資料庫
- Flashback DatabaseDatabase
- Java升級那麼快,多個版本如何靈活切換和管理?Java
- 閃回資料庫(flashback database)知識分享資料庫Database
- 使用 JavaScript 實現靈活的固定導航功能JavaScript
- EMQX Cloud 自定義函式實現多種 IoT 資料形式的靈活轉化MQCloud函式
- Physical Standby Database 切換到 Snapshot Standby DatabaseDatabase
- flashback技術之---flashback databaseDatabase
- flashback database 方法Database
- 配置Flashback DatabaseDatabase
- 專案要實現多資料來源動態切換,咋搞?
- 巧用ROW_NUMBER 實現SQL資料任意排序SQL排序
- 巧用 Data Instance 實現 XForms 中的資料處理ORM
- 使用Broker實現DG切換
- 彩色 TabBar 切換動畫實現tabBar動畫
- 純CSS實現Tab欄的切換CSS
- jquery中點選切換的實現jQuery
- activity切換無動畫效果的實現動畫
- flashback系列文章三(flashback database)Database
- 萬國資料攜手聯想凌拓 合力實現資料雲上雲下靈活排程
- 閃回資料庫時間視窗(flashback database window)資料庫Database
- 第5章 閃回資料庫Understanding the Flashback Database資料庫Database
- Redis 實戰篇:巧用資料型別實現億級資料統計Redis資料型別
- AbstractRoutingDataSource 實現動態資料來源切換原理簡單分析
- 關於flashback databaseDatabase
- How to enable the flashback database:Database