http___blog.yavor.info__m_200811_1.xml
http___dbaora.com_flashback-data-archive-11g_.xml
1.1 1.2 2.1 2.2 2.3 3.1 3.2 3.3 3.4 4.1 4.2 5.1 6.1 6.2 7.1 8.1 9.1 10.1 11.1 12.1 13.1 14.1 14.2 15.1 16.1 16.2 16.3 16.4 16.5 17.1 18.1 19.1 20.1 21.1 22.1 23.1 24.1 25.1 25.2 25.3 26.1 26.2 27.1 28.1 29.1 30.1 32.1 33.1 34.1 34.2 35.1 35.2 35.3 35.4 36.1 36.2 36.3 37.1 38.1 38.2 38.3 38.4 38.5 39.1 39.2 39.3 39.4
Не, не става дума за онзи готин филм с чичко Арни, който българските преводачи кръстиха „Зов за завръщане“. Става дума за нещо не-чак-толкова вълнуващо, но пък полезно – Total Recall опцията на Oracle Database 11g, която е известна още с името „Flashback Data Archive“. Започнах да я разучавам във връзка с евентуалното и използване в един бъдещ проект. По принцип едно от големите предизвикателства в информационните системи е как да направим функцията… хммм… абе ние си го наричаме хисторизация. Става дума за това да погледнем как са били данните към някоя дата – примерно по пладне на първия петък след второто пълнолуние след лятното слънцестоене 🙂 Има разни подходи за хисторизация и всеки си има минуси. Нямам намерение да ги разнищвам сега. Ще спомена само, че поне на пръв поглед Oracle Total Recall е перфектното средство за тази цел. Идеята е следната: – прави се т.нар. Flashback Data Archive, който има няколко свойства – tablespace, в който да се съхранява; време, за което да се съхраняват данните (обикновено години); евентуално, може да се зададе максимален размер: CREATE FLASHBACK ARCHIVE recall TABLESPACE recalltbs QUOTA 10G RETENTION 5 YEAR; След като се създаде, всеки потребител с определени права може да си включи табличките към него. Според документацията, правата се дават така: grant flashback archive on recall to scott; Включването на табличката към архива си го прави самия потребител scott и става така: alter table emp flashback archive recall; След това информация за миналото може да се получи с известния от flashback query синтаксис, примерно: SELECT * FROM emp AS OF TIMESTAMP TO_TIMESTAMP ('2008-11-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS'); SELECT * FROM emp AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL '60' MINUTE); До тук всичко е ОК. Както се казва – всичко е цветя и кебапчета 🙂 Забелязах, обаче, някои проблемчета и ограничения. Първо за ограниченията. Не се поддържат таблици, които са nested, clustered, temporary, remote, или external. Също така не се поддържат таблици, в които има LONG или nested колони. До тук добре – тези неща не ме притесняват. Лошото, обаче, е, че на таблица, на която е включен flashback archive, не се позволяват доста важни DDL операции: – ALTER TABLE statement that does any of the following: – – Drops, renames, or modifies a column – – Performs partition or subpartition operations – – Converts a LONG column to a LOB column – – Includes an UPGRADE TABLE clause, with or without an INCLUDING DATA clause – DROP TABLE statement – RENAME TABLE statement – TRUNCATE TABLE statement Особено неприятни са ограниченията, че не мога да променям структурата на таблицата или да и променям партишъните. За проект, който тепърва ще се разработва и внедрява, това прави total recall опцията почти неизползваема. И докато когато си правиш хисторизацията ръчно, можеш при промяна в таблицата да си измигрираш данните, когато използва total recall нямаш никакъв контрол. Второто, за което искам да спомена, е как се изключва таблица от архива. Според документацията синтаксиса е следния: alter table emp no flashback archive; Добре, ама като го пробвах ме заплю: SQL> alter table emp no flashback archive; alter table emp no flashback archive ERROR at line 1: ORA-55620: No privilege to use Flashback Archive. Ха, ядец. Оказа се, че това е недокументирана предпазна мярка 🙂 Идеята е да не може всеки потребител да си спира flashback архива. Сещам се за сериозни причини това да е така. Само дето не е документирано. Самото съобщение за грешка също не е прекалено информативно. Оказва се, че вариантите са два. SYS (или всеки, който е sysdba) може да спира всякакви таблици от всеки архив. А за да може определен потребител да прави такива неща, трябва да му се дадат още малко права: grant flashback archive administer to scott; Това явно са го измислили в последния момент. Първо защото не е документирано. Освен това не е много добре измислено. По-логично би било ако се дава право на потребителя да изключва таблици от определен архив (като са правата за включване). Но това може би ще е в следващия release. И така, още не съм решил дали да го използваме това нещо. Ако намеря начин да заобиколя ограничението за промяна на таблица, ще бъде супер. Още не съм пробвал и как се държи архива при expdp/impdp. Но за това – друг път.
1.1 2.1 2.2 3.1 4.1 5.1 5.2 6.1 7.1 8.1 8.2 9.1 10.1 11.1 11.2 12.1 13.1 13.2 14.1 14.2 14.3 15.1 16.1 17.1 17.2 17.3 17.4 18.1 19.1 20.1 21.1 22.1 23.1 24.1 25.1 25.2 26.1 27.1 28.1 29.1 30.1 31.1 32.1 33.1 34.1 35.1 36.1 37.1 38.1 39.1 40.1 41.1 42.1 43.1 44.1 45.1 46.1 47.1 48.1 49.1
This article presents new feature of 11g – Flashback Data Archive. This functionality allows to save all transactions executed on a table for longer period than just UNDO_RETENTION parameter and UNDO tablespace. In 11g you can create dedicated space to keep changed data(DML operations, DDL operations) for longer specified retention period. Historical records can be reviewed using standard flashback sql queries feature. Setup Flashback Data Archive NOTE – all commands are executed as user TOMASZ with role DBA. Only dedicated commands are executed as user SYS. Setup consists of following steps: Create Flashback Data Archive – you can create many flashback data archives – as user TOMASZ create flashback archive fda1 tablespace users quota 100m retention 1 year; flashback ARCHIVE created. create flashback archive fda2 tablespace users quota 100m retention 1 year; flashback ARCHIVE created. Specify default Flashback Data Archive if you have defined many – as user SYS Setting default Flashback Data Archive can be done only by sysdba using: - ALTER FLASHBACK ARCHIVE .. SET DEFAULT - CREATE FLASHBACK ARCHIVE DEFAULT … create flashback archive default fda3 tablespace users quota 100m retention 1 year; Flashback archive altered. alter flashback archive fda2 set default; Flashback archive altered. NOTE – if default is already defined command CREATE FLASHBACK ARCHIVE DEFAULT can fail. In such case create such flashback without DEFAULT and use ALTER FLASHBACK … SET DEFAULT SQL> create flashback archive default fda4 2 tablespace users quota 100m 3 retention 1 year; tablespace users quota 100m * ERROR at line 2: ORA-55609: Attempt to create duplicate default Flashback Archive Enable Flashback Data Archive on a table – as user TOMASZ create table test_tbl (id number); table TEST_TBL created. --enable flashback archive default is assigned to table alter table test_tbl flashback archive; table TEST_TBL altered. --disable flashback archive alter table test_tbl no flashback archive; table TEST_TBL altered. --enable flashback archive with specific name alter table test_tbl flashback archive fda2; table TEST_TBL altered. View Flashback data archive details Useful views: - *_FLASHBACK_ARCHIVE – information about created flashback data archives in database - *_FLASHBACK_ARCHIVE_TS – information about space allocated in tablespaces by flashback data archive - *_FLASHBACK_ARCHIVE_TABLES – information about tables that are using flashback archive select owner_name, flashback_archive_name, status from dba_flashback_archive; OWNER_NAME FLASHBACK_ARCHIVE_NAME STATUS ------------ -------------------------- ------- TOMASZ FDA1 TOMASZ FDA2 DEFAULT SYS FDA3 select * from dba_flashback_archive_ts; FLASHBACK_ARCHIVE_NAME FLASHBACK_ARCHIVE# TABLESPACE_NAME QUOTA_IN_MB ---------------------- ------------------ --------------- ----------- FDA1 1 USERS 100 FDA2 2 USERS 100 FDA3 3 USERS 100 select * from dba_flashback_archive_ts; TABLE_NAME OWNER_NAME FLASHBACK_ARCHIVE_NAME ARCHIVE_TABLE_NAME STATUS ---------- ---------- ---------------------- ------------------ ------ TEST_TBL TOMASZ FDA2 SYS_FBA_HIST_81365 ENABLED Review data It works in the same way as flashback sql queries. You can notice data is preserved even for TRUNCATE and DROP COLUMN operations. insert into test_tbl values(10); commit; truncate table test_tbl; alter table test_tbl add(id1 number); alter table test_tbl drop column id; insert into test_tbl values(20); commit; --old data survives truncate, drop column select * from test_tbl versions between scn minvalue AND maxvalue; ID1 D_1975947_ID ---------- ------------ 10 20 Flashback archive restrictions If flashback archive is enabled some DDL operations can cause ORA-55610 – Invalid DDL statement on history-tracked table - ALTER TABLE that includes UPGRADE TABLE - ALTER TABLE that moves or exchanges a partition or subpartition operation - DROP TABLE - More complex DDL can be performed using DISASSOCIATE_FBAand REASSOCIATE_FBAprocedures of the DBMS_FLASHBACK_ARCHIVE package drop table test_tbl; ORA-55610: Invalid DDL statement on history-tracked table You can’t enable Flashback Data Archive for - nested, clustered, temporary, remote or external tables - tables that contain LONG or nested columns Useful commands Privileges --grant privileges on a flashback archive to a user grant flashback archive on fda1 to tomasz; --grant privilege to manage flashback archive like create/drop grant flashback archive administer to tomasz; Modify retention --modify retention for flashback archive alter flashback archive fda1 modify retention 2 year; alter flashback archive fda1 modify retention 2 month; alter flashback archive fda1 modify retention 2 day; Remove old data -- remove old data from flashback archive alter flashback archive fda1 purge all; alter flashback archive fda1 purge before timestamp (systimestamp - interval '2' month); alter flashback archive fda1 purge before scn 256745; Drop flashback archive drop flashback archive fda1; Have a fun 🙂 Tomasz