Добрий день, учасники спільноти!
На численні прохання сьогодні я розповім як можна створити і підняти бекап Terrasoft на СУБД Oracle.
Зробити це дуже просто, все робиться автоматично - потрібно лише запустити командний файл і ввести назви бази даних.
- Розпаковуємо вміст архіву Backup.zip на сервер, де встановлений сервер Oracle.
- Запускаємо BackupDatabase.cmd.
- Вказуємо: назва схеми, її пароль (схеми-користувача) і назва файлу дампа бази.
- В результаті отримуємо два файли: Grant.sql - скрипт зі створення розданих прав і власне сам дамп бази Oracle.
- Розпаковуємо вміст архіву Restore.zip на сервер, де встановлений сервер Oracle.
- Сюди ж обов'язково підкладаємо два файли (Grant.sql і дамп), які були створені при створенні бекапа.
- Запускаємо RestoreDatabase.cmd.
- Вказуємо: пароль користувача SYS, назва файлу дампа бази (backup db file name), стара назва схеми з якої робився дамп (old user schema), назва нової схеми (new user schema) і пароль користувача нової схеми (new user password).
- Далі все виконається автоматично: створиться нова схема, пролунають потрібні права, створяться необхідні типи, підніметься бекап бази під вказаною схемою, заміняться зав'язки об'єктів в системних таблицях Terrasoft на нові, пролунають потрібні права ролям на таблиці та подання.
В інсталяції Terrasoft вже йдуть в комплекті схожі скрипти, але там все зав'язано на те, що база створювалася з схеми TSAUTOBUILD. Мої скрипти додатково запрошують назва старої схеми.
Описав коротко, тільки найнеобхідніше. Якщо будуть питання - із задоволенням відповім.
Зазначу, що викладену інформацію необхідно розглядати як приклад, який кожен можете змінювати під свої потреби. Ці скрипти застосовні для Oracle встановленого на ОС Windows і запуск командного файлу потрібно виробляти на самому сервері. Для всіх інших варіантів (інша ОС, запуск з клієнтської машини) можете дописати самі.
Ключовим моментом при створенні бекапу є скрипт Grant.sql (див. Backup.zip), який створює "зліпок" розданих прав для моделі, яка застосована в Terrasoft CRM.
UPD: Дякую Саші Котенко за знайдений недолік в файлі BackupDatabase.cmd. Виправив.
Клієнти часто запитують, чому при піднятті резервної копії Oracle видає попередження, а також чому деякі об'єкти після імпорту в невалидность стані.
Спробую відповісти на ці питання.
Тип об'єкта "SCHEMA_NAME". "T_FieldInfo" вже існує з іншим ідентифікатором
У нашій системі використовуються об'єктні типи БД Oracle, OBJECT TYPE.
Справа в тому, що Oracle жорстко пов'язує об'єктні типи з їх ідентифікаторами, OID.
При цьому якщо на сервері був одного разу відновлений бекап схеми Terrasoft, там виникнуть усі використовувані типи ( "t_GetLoginInfo", "tbl_GetLoginInfo" і ін.).
Але через жорсткої прив'язки до OID, ці типи утворюються від OID, який прописаний в дампі.
Перший раз все буде нормально. Але при піднятті того ж, або іншого бекапу схеми Terrasoft на тому ж сервері, він знову буде створювати типи з тими ж OID - в результаті виникне помилка: об'єкт з таким OID вже існує. В результаті після підняття бекапу жоден з типів не створить.
Через цю особливість Oracle, ми зробили в скриптах підняття наших схем обхідний рішення:
- Перед підняттям бекапу скриптом CreateTypes.sql явно створюються всі необхідні типи, при створенні Oracle згенерує їм нові OID.
- При піднятті Oracle намагається створити типи з бекапу c їх старими OID, при цьому видається помилка IMP-00061: Увага: Тип об'єкта "Схема". "Тип" вже існує з іншим ідентифікатором
При виникненні такої помилки, створення типу пропускається.
Але в нашому випадку це не є помилкою, тому що це зроблено спеціально в якості обхідного рішення. Всі необхідні об'єктні типи створяться нашим скриптом безпосередньо перед підняттям бекапу.
Після підняття бекапу деякі об'єкти невалидность
Це також не є помилкою, а просто попередженням.
При імпортуванні схеми спочатку переносяться таблиці та подання, потім тригери і вже після цього збережені процедури і функції.
Якщо в одному з тригерів використовується виклик будь-якої процедури, що - після імпорту він буде невалідним.
Переходимо від теорії до практики. У нашій системі у багатьох таблиць є рядковий тригер BEFORE INSERT OR UPDATE. наприклад такий:
Як бачимо за кодом, цей тригер викликає функцію fn_CreateGUID. якої на момент перенесення тригера просто немає. Вона створиться пізніше, з усіма іншими ХП. Через це тригер залишається невалідним.
Система адміністрування Oracle в версії 341 істотно змінилася. У зв'язку з цим, змінився також і механізм створення та відновлення резервних копій.
Що змінилося в нових скриптах роботи з бекапу для 341
- З'явилася можливість вказувати інстанси Oracle для розгортання бекапу
- Можна вказати окреме табличний простір для розгортання схеми
- Виправлена ситуація з експортом порожніх таблиць (Oracle 11)
У новій системі адміністрування практично всі права користувачеві призначаються через ролі. Тому при відновленні резервної копії з'явилося 3 опції - режими перенесення прав користувачів. Зупинюся на цьому більш детально.
Опція № 0 - переприв'язати користувачів в нову схему (за замовчуванням)
При цьому всі користувачі Terrasoft, створяться і їм будуть роздані і призначені за замовчуванням ролі для доступу до нової схеми (до тієї яку ви розвертаєте). У користувачів автоматично забереться доступ на стару схему. Цей варіант підходить для початкового підняття бекапу на новому інстанси або для перенесення бойової схеми в нову схему.
Опція № 1 - Створити користувачів з періменованіем
Цей варіант передбачає, що всі користувачі Terrasoft будуть створені як нові користувачі Oracle c префіксами 'U' і їм буде роздано всі відповідні права. Наприклад в старій схемі був користувач User1. після підняття резервної копії новий користувач буде User1U. Таким чином старий користувач User1 буде продовжувати нормально працювати зі старою схемою, а новий буде мати всі ті ж права щодо нової схеми на одному інстанси. Цей варіант зручний при піднятті тестової схеми на тому ж інстанси, де вже працює бойова схема. При цьому користувачі будуть абсолютно незалежні.
Опція № 2 - Не створювати користувачів
В цьому випадку, при відновленні резервної копії створиться тільки користувач-схема Terrasoft. Йому призначаються права адміністратора Terrasoft і під ним потрібно зайти для самостійного закладу потрібних користувачів і замовлення ліцензій для них.
І найголовніше, скрипти в прикріпленому архіві.