Flashback Database - Größe der Logs
Flashback Database ist ein probates Mittel, um nach fehlgeschlagenen Updates oder Upgrades den Urzustand wiederherstellen zu können oder um in einer Data Guard Umgebung nach einem Failover eine Datenbank einfach und ohne erneutes Duplicate reinstantiieren zu können. Ist Flashback Database eingeschaltet, werden in der Fast Recovery Area (FRA) zusätzlich Logs, die Flashback Logs, generiert. Diese ergänzen die Archivelogs. Die Vorhaltezeit der Flashback Logs wird über den Parameter "db_flashback_retention_target" gesteuert und wird in Minuten angegeben. Per Standard sind her 1440 Minuten, also 1 Tag, voreingestellt.
Wenn man sich nun die Flashback Logs genauer ansieht, stellt man fest, das deren Größe offenbar von der Größe der Redo Logs abgeleitet wird.
SQL> select group#, status, bytes from v$log;
GROUP# STATUS BYTES
---------- ---------------- ----------
1 CURRENT 1073741824
2 INACTIVE 1073741824
3 INACTIVE 1073741824
SQL> alter database flashback on;
Database altered.
SQL> select * from v$flashback_database_logfile;
NAME LOG# THREAD# SEQUENCE# BYTES FIRST_CHANGE# FIRST_TIME TYPE CON_ID
-------------------------------------------------------------------------------- ---------- ---------- ---------- ---------- ------------- ------------------- --------- ----------
/u03/app/oracle/fast_recovery_area/MMISI2/flashback/o1_mf_h1xp7lv0_.flb 1 1 1 1073741824 3886676 2020-01-15 10:18:44 NORMAL 0
/u03/app/oracle/fast_recovery_area/MMISI2/flashback/o1_mf_h1xp7pnk_.flb 2 1 1 1073741824 0 RESERVED 0
SQL> !ls -l /u03/app/oracle/fast_recovery_area/MMISI2/flashback/
total 2097168
-rw-r----- 1 oracle dba 1073750016 Jan 15 10:22 o1_mf_h1xp7lv0_.flb
-rw-r----- 1 oracle dba 1073750016 Jan 15 10:18 o1_mf_h1xp7pnk_.flb
Aber wie verhält es sich, wenn sich die Größe der Redo Logs ändert? Dazu werden neue, kleinere Gruppen angelegt und anschließend die alten Gruppen entfernt. Das Entfernen geht natürlich nur, wenn die Gruppen den Status INACTIVE haben, also ein Checkpoint durchgeführt wurde.
SQL> alter database add logfile group 10 size 256m;
Database altered.
SQL> alter database add logfile group 11 size 256m;
Database altered.
SQL> alter database add logfile group 12 size 256m;
Database altered.
SQL> alter database drop logfile group 2;
Database altered.
SQL> alter database drop logfile group 3;
Database altered.
SQL> alter system switch logfile;
System altered.
SQL> alter system checkpoint;
System altered.
SQL> alter database drop logfile group 1;
Database altered.
SQL> select group#, bytes, status from v$log;
GROUP# BYTES STATUS
---------- ---------- ----------------
10 268435456 CURRENT
11 268435456 UNUSED
12 268435456 UNUSED
Aber was ist mit den Flashback Logs passiert? Die sind nach wie vor 1GB groß.
SQL> select log#, thread#, sequence#, bytes, type from v$flashback_database_logfile;
LOG# THREAD# SEQUENCE# BYTES TYPE
---------- ---------- ---------- ---------- ---------
1 1 1 1073741824 NORMAL
2 1 1 1073741824 RESERVED
Aber vielleicht ändert sich etwas, wenn ein paar Änderungen stattgefunden haben. Das lässt sich testen.
SQL> create table dings tablespace users as select * from dba_source;
Table created.
SQL> insert into dings select * from dings;
283698 rows created.
SQL> insert into dings select * from dings;
567396 rows created.
SQL> insert into dings select * from dings;
1134792 rows created.
SQL> insert into dings select * from dings;
2269584 rows created.
SQL> insert into dings select * from dings;
4539168 rows created.
SQL> commit;
Commit complete.
SQL> select group#, sequence#, bytes, status from v$log;
GROUP# SEQUENCE# BYTES STATUS
---------- ---------- ---------- ----------------
10 11 268435456 ACTIVE
11 12 268435456 ACTIVE
12 13 268435456 CURRENT
SQL> select log#, thread#, sequence#, bytes, type from v$flashback_database_logfile;
LOG# THREAD# SEQUENCE# BYTES TYPE
---------- ---------- ---------- ---------- ---------
1 1 1 1073741824 NORMAL
2 1 1 1073741824 RESERVED
Die Größe hat sich nicht geändert. Noch nicht einmal ein neues Flashback Log wurde generiert. Also hat sich nicht genügend geändert? Vielleicht hilft ein zeilenweises Löschen? Aber bitte nicht nachmachen, inperformanter und ineffizienter kann man Datensätze kaum löschen.
SQL> begin
2 for rec in (select rowid from dings) loop
3 delete from dings where rowid = rec.rowid;
4 commit;
5 end loop;
6 end;
7 /
PL/SQL procedure successfully completed.
SQL> select group#, sequence#, bytes, status from v$log;
GROUP# SEQUENCE# BYTES STATUS
---------- ---------- ---------- ----------------
10 53 268435456 CURRENT
11 51 268435456 INACTIVE
12 52 268435456 INACTIVE
SQL> select log#, thread#, sequence#, bytes, type from v$flashback_database_logfile;
LOG# THREAD# SEQUENCE# BYTES TYPE
---------- ---------- ---------- ---------- ---------
1 1 1 1073741824 NORMAL
2 1 1 1073741824 RESERVED
Offenbar wurden damit genügend Logswitches generiert, aber bei den Flashback Logs ist die Lage unverändert. Beeinflusst am Ende derParameter "db_flashback_retention_target" die Flashback Logs?
SQL> show parameter flashb
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_flashback_retention_target integer 1440
SQL> alter system set db_flashback_retention_target=10;
System altered.
SQL> select log#, thread#, sequence#, bytes, type from v$flashback_database_logfile;
LOG# THREAD# SEQUENCE# BYTES TYPE
---------- ---------- ---------- ---------- ---------
1 1 1 1073741824 NORMAL
2 1 1 1073741824 RESERVED
Nein, es bleibt alles beim Alten. Beeinflussen am Ende andere Operationen die Generierung von Flashback Logs? Index Maintenance möglicherweise?
QL> insert into dings select * from dba_source;
283698 rows created.
SQL> commit;
Commit complete.
SQL> create index dings_ix1 on dings(owner, name, line) tablespace new;
Index created.
SQL> insert into dings select * from dings;
283698 rows created.
SQL> insert into dings select * from dings;
567396 rows created.
SQL> insert into dings select * from dings;
1134792 rows created.
SQL> insert into dings select * from dings;
2269584 rows created.
SQL> commit;
Commit complete.
SQL> select group#, sequence#, bytes, status from v$log;
GROUP# SEQUENCE# BYTES STATUS
---------- ---------- ---------- ----------------
10 65 268435456 ACTIVE
11 66 268435456 ACTIVE
12 67 268435456 CURRENT
SQL> select log#, thread#, sequence#, bytes, type, first_time from v$flashback_database_logfile;
LOG# THREAD# SEQUENCE# BYTES TYPE FIRST_TIME
---------- ---------- ---------- ---------- --------- -------------------
3 1 3 1073741824 NORMAL 2020-01-15 11:27:47
4 1 1 1073741824 RESERVED
1 1 1 1073741824 NORMAL 2020-01-15 10:18:44
2 1 2 1073741824 NORMAL 2020-01-15 11:26:36
SQL> !ls -l /u03/app/oracle/fast_recovery_area/MMISI2/flashback/
total 4194336
-rw-r----- 1 oracle dba 1073750016 Jan 15 11:26 o1_mf_h1xp7lv0_.flb
-rw-r----- 1 oracle dba 1073750016 Jan 15 11:27 o1_mf_h1xp7pnk_.flb
-rw-r----- 1 oracle dba 1073750016 Jan 15 11:28 o1_mf_h1xt6z4y_.flb
-rw-r----- 1 oracle dba 1073750016 Jan 15 11:27 o1_mf_h1xt95vj_.flb
Tatsächlich wurden durch das Befüllen der Tabelle mit einem existierenden Index nun neue Flashback Logs erzeugt. Allerdings ist deren Größe nach wie vor 1GB.
Bleibt als letzte Möglichkeit nur noch, die Funktion aus- und wieder einzuschalten.
SQL> alter database flashback off;
Database altered.
SQL> alter database flashback on;
Database altered.
SQL> select log#, thread#, sequence#, bytes, type, first_time from v$flashback_database_logfile;
LOG# THREAD# SEQUENCE# BYTES TYPE FIRST_TIME
---------- ---------- ---------- ---------- --------- -------------------
1 1 1 268435456 NORMAL 2020-01-15 11:30:01
2 1 1 268435456 RESERVED
SQL> !ls -l /u03/app/oracle/fast_recovery_area/MMISI2/flashback/
total 524304
-rw-r----- 1 oracle dba 268443648 Jan 15 11:30 o1_mf_h1xtf8yz_.flb
-rw-r----- 1 oracle dba 268443648 Jan 15 11:30 o1_mf_h1xtfck6_.flb
Das hat schlußendlich Wirkung gezeigt, die Flashback Logs haben nun wieder die Größe der Redo Logs. Leider gehen dadurch aber die alten Flashback Informationen verloren. Man sollte den Zeitpunkt dafür also gut wählen um nicht versehentlich noch benötigte Flashback Logs zu verlieren.
Kommentare
Keine Kommentare