閃回原理測試（二）(r11筆記第23天)

    對於閃回部分，Oracle本身提供了非常多相關的特性，我個人對於閃回資料庫這個特性最為喜愛，尤其是應用再Data Guard環境中，真是一大殺器。

    而對於DML的閃回部分其實也相對比較容易理解，畢竟就是原操作的逆操作，之前透過logminer的方式來讀取redo來間接得以印證。Oracle閃回原理-Logminer解讀redo（r11筆記第17天）

    但是對於DDL的閃回，這個特性真是非常強悍了。比如一個truncate操作，它的逆操作改怎麼定義，就很難去界定了。當然這個裡面肯定有一些很有意思的實現方式值得好好玩味。

    我簡單測試了truncate和delete的操作，雖然步驟簡單，但是是帶著特定的眼光來審視這個過程。

    我們來建立一些資料，先建立200萬的資料壓壓驚。

SQL> create table test_fb as select level object_id,'obj_'||level object_name from dual connect by level <=2000000;
Table created.

然後持續插入一些資料，目的是保證這個表的資料量足夠大。

SQL> insert into test_fb select *from test_fb;
2000000 rows created.
SQL> /
4000000 rows created.
SQL> /
8000000 rows created.
SQL> select count(*)from test_fb;
  COUNT(*)
----------
  16000000
SQL> commit;
Commit complete.資料準備工作就這些，簡單看看對應的段，會發現段的大小在近400M的樣子。

SQL> select segment_name,bytes/1024/1024 size_MB from user_segments where segment_name='TEST_FB';
SEGMENT_NAME                      SIZE_MB
------------------------------ ----------
TEST_FB                               384雖然看起來不是特別大的段，不過已經能夠說明問題了。我們開啟閃回資料庫的功能。

alter database flashback on;這個時候檢視閃回區，會發現突然多出了兩個閃回日誌。

[oracle@newtest flashback]$ ll
total 102420
-rw-r--r-- 1 oracle oinstall      171 Aug 21 20:37 a.sql
-rw-r----- 1 oracle oinstall 52436992 Dec 24 22:34 o1_mf_d5x1vjlb_.flb
-rw-r----- 1 oracle oinstall 52436992 Dec 24 22:34 o1_mf_d5x1vjvc_.flb可以理解這是一個初始化的過程。因為從alert日誌可以看到啟動了RVWR程式，SGA裡面其實也分配了閃回區的快取.
Sat Dec 24 22:34:24 2016
 alter database flashback on
Starting background process RVWR
Sat Dec 24 22:34:24 2016
RVWR started with pid=37, OS id=21314
Flashback Database Enabled at SCN 192530049424
Completed:  alter database flashback on這個時候資料庫標示，閃回資料庫是基於某一個SCN的。
下面我們來做一個truncate操作，為了讓閃回的過程看起來自然一些，我們就建立一個還原點，畢竟基於SCN,基於時間戳還是有些取巧的感覺。

create restore point fb_recover_trunc guarantee flashback database;

對於還原點更多的資訊可以聯絡v$restore_point來檢視，其實從資料字典裡檢視，這部分資訊也會清晰不少。

 col NAME for a20
 col TIME for a35
 set lines 200
 col STORAGE_SIZE for a50
 SELECT NAME, SCN, TIME, DATABASE_INCARNATION# DI,GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE/1024/1024/1024
 FROM V$RESTORE_POINT
 WHERE GUARANTEE_FLASHBACK_DATABASE='YES';
NAME                                       SCN TIME                                        DI GUARAN STORAGE_SIZE/1024/1024/1024
---------------- ----------------------------- ----------------------------------- ---------- ------ ---------------------------
FB_RECOVER_TRUNC                  192530049487 24-DEC-16 10.35.16.000000000 PM             10 YES                     .048828125

這個過程，閃回日誌沒有大小的任何變化,但是閃回日誌的時間戳會發生變化，證明是在持續更新。
我們來操作truncate，這個操作絕對是很多資料庫災難的源頭。

truncate table test_fb;

但是操作完成之後檢視閃回日誌，竟然還是沒有任何大小的變化。
可見truncate的操作，在閃回日誌中不會記錄逆操作的資訊，這個應該是在其它的地方來做的。

我們來開啟閃回資料庫，嘗試閃回到指定的還原點

shutdown immediate;
startup mount

從啟動日誌可以清晰的看到，SGA裡面是分配了60多M的flashback generation buffer.

Successful mount of redo thread 1, with mount id 806293483
Allocated 63749952 bytes in shared pool for flashback generation buffer
Starting background process RVWR
Sat Dec 24 22:38:39 2016
RVWR started with pid=23, OS id=21403開始閃回到指定的還原點

flashback database to restore point fb_recover_trunc;這個時候閃回日誌還是沒有任何大小的變化。不過資料庫日誌需要格外關注。

Sat Dec 24 22:39:17 2016
flashback database to restore point fb_recover_trunc
Flashback Restore Start
Flashback Restore Complete
Flashback Media Recovery Start
 started logmerger process
Parallel Media Recovery started with 24 slaves
Sat Dec 24 22:39:18 2016
Recovery of Online Redo Log: Thread 1 Group 3 Seq 11412 Reading mem 0
  Mem# 0: /U01/app/oracle/oradata/newtest2/redo03.log
Incomplete Recovery applied until change 192530049488 time 12/24/2016 22:35:16
Flashback Media Recovery Complete
Completed: flashback database to restore point fb_recover_trunc

這段日誌很寶貴，可以看到是幾個階段，restore,media recovery,其中恢復的過程中是使用logmerger來處理的。這些個過程是後續進行分析的重要內容了。
為了簡單驗證，我們啟動資料庫至read only狀態

alter database open read only;確認無誤，後續的操作就是啟動資料庫，糾結的部分還是到來是，是一個resetlogs的操作。

shutdown immediate
startup mount
alter database open resetlogs;在主庫上還是有些糾結，所以我喜歡在備庫上來玩閃回資料庫。
整個resetlogs的過程會重置redo.
但是閃回日誌的大小依舊不會有任何的變化。
聽起來閃回日誌的作用還是不大明顯，如果你做了DML的操作，那這個過程的影響就會放大數倍。

當前的這個測試表資料量在1600萬。

SQL> select count(*)from test_fb;
  COUNT(*)
----------
  16000000

我們做一個大動作，閃回1000萬資料。

SQL> delete from test_fb where rownum<10000000;
9999999 rows deleted.

這個過程會持續一些時間，可以看到後臺的redo非常忙，切換了近90次。
而閃回日誌是否很忙呢，這下終於忙起來了，而且非常忙，生成了非常多的閃回日誌。

[oracle@newtest flashback]$ ll
total 2446012
-rw-r--r-- 1 oracle oinstall       171 Aug 21 20:37 a.sql
-rw-r----- 1 oracle oinstall  52436992 Dec 24 22:49 o1_mf_d5x1vjlb_.flb
-rw-r----- 1 oracle oinstall  52436992 Dec 24 22:49 o1_mf_d5x1vjvc_.flb
-rw-r----- 1 oracle oinstall  52436992 Dec 24 22:49 o1_mf_d5x2qv3h_.flb
-rw-r----- 1 oracle oinstall  52436992 Dec 24 22:49 o1_mf_d5x2r454_.flb
-rw-r----- 1 oracle oinstall  52436992 Dec 24 22:50 o1_mf_d5x2rf6s_.flb
-rw-r----- 1 oracle oinstall  52436992 Dec 24 22:50 o1_mf_d5x2rm8d_.flb
-rw-r----- 1 oracle oinstall  52436992 Dec 24 22:50 o1_mf_d5x2rwb0_.flb
-rw-r----- 1 oracle oinstall  52436992 Dec 24 22:50 o1_mf_d5x2s5co_.flb
-rw-r----- 1 oracle oinstall  52436992 Dec 24 22:50 o1_mf_d5x2sgfb_.flb
-rw-r----- 1 oracle oinstall  52436992 Dec 24 22:50 o1_mf_d5x2sngx_.flb
-rw-r----- 1 oracle oinstall  52436992 Dec 24 22:50 o1_mf_d5x2sxjk_.flb
-rw-r----- 1 oracle oinstall  52436992 Dec 24 22:50 o1_mf_d5x2t6l6_.flb
-rw-r----- 1 oracle oinstall  52436992 Dec 24 22:51 o1_mf_d5x2thmt_.flb
-rw-r----- 1 oracle oinstall  52436992 Dec 24 22:51 o1_mf_d5x2toof_.flb
-rw-r----- 1 oracle oinstall  52436992 Dec 24 22:51 o1_mf_d5x2tyq2_.flb
-rw-r----- 1 oracle oinstall 104865792 Dec 24 22:51 o1_mf_d5x2v4rn_.flb
-rw-r----- 1 oracle oinstall 209723392 Dec 24 22:52 o1_mf_d5x2vfvm_.flb
-rw-r----- 1 oracle oinstall 389283840 Dec 24 22:53 o1_mf_d5x2vx2o_.flb
-rw-r----- 1 oracle oinstall 453705728 Dec 24 22:54 o1_mf_d5x2wyhs_.flb
-rw-r----- 1 oracle oinstall 560545792 Dec 24 22:53 o1_mf_d5x2yxz0_.flb

而且尤其值得關注的是，後面生成的閃回日誌不是按照原有的50M而是逐步遞增的節奏。
如果你繼續使用truncate的方式清理資料，閃回日誌的大小還是沒有任何的變化。這應該不是巧合，也是故弄玄虛，flashback restore,flashback media recovery這些需要關注，後臺程式RVWR來維護整個閃回資料庫的過程，自有它的道理。