Не, не става дума за онзи готин филм с чичко Арни, който българските преводачи кръстиха „Зов за завръщане“. Става дума за нещо не-чак-толкова вълнуващо, но пък полезно – 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. Но за това – друг път.