Як перенести табличний простір з бази в базу

Проблема перенесення даних в Oracle, так само як і багато інших, не має одного загального прийнятного рішення. З одного боку, прикладні вимоги до такого переносу завжди конкретні: частота, обсяг, швидкість здійснення і так далі. З іншого боку, пропоновані Oracle варіанти технічних рішень різноманітні і мають кожен своїми плюсами і мінусами. У версії 8.1 з'явився спосіб фізичного перенесення частин БД (тобто на рівні файлів, на противагу логічного переносу – на рівні об'єктів), точніше перенесення табличних просторів. Врахувавши застереження, зроблену першою фразою цього абзацу, згадаємо основне (Типове) достоїнство методу фізичного перенесення даних – швидкість і основний (типовий) недолік – неможливість переносити дані між різними платформами і версіями Oracle. Пославшись ще раз на ту ж застереження, розумно буде припустити, що в певних додатках фізичний перенесення буде не тільки припустимо, але і вигідний, а тому опис техніки такого перенесення заслуговує на увагу адміністратора БД.

Отже, подивимося, як можна швидко перенести з бази в базу табличний простір цілком. Можливість Oracle, яка при цьому використовується, носить оригінальна назва transportable tablespace. Технічно ця можливість реалізується перенесенням



Постановка завдання


Нехай є дві БД: DOLLY і DOLLY1, що працюють в ОС Windows NT під управлінням СУБД Oracle версії 8.1.7. В БД DOLLY є користувач DNA, що має якісь об'єкти в табличному просторі HEART. Покажемо, як це табличний простір можна перенести в базу DOLLY1. Після цього зробимо зміни в просторі HEART і виконаємо зворотній перенос.


Те, що приклад наводиться для Windows NT, зовсім не критичний і обмовляється тут лише для виправдання синтаксису імен файлів, а також щоб уникнути непорозумінь.


Вихід на вихідні позиції: підготовка тренувальних баз


Якщо Ви працюєте на одній машині, зручно буде завести на терміналі два консольних віконця: перший , Налаштоване на роботу з БД DOLLY і друга , Налаштоване на DOLLY1.


У перший віконці увійдемо в SQL * Plus від імені SYS і наберемо

CREATE TABLESPACE heart
DATAFILE ‘d:oracleoradatadollyheart1.dbf’ SIZE 1M;

CREATE USER dna IDENTIFIED BY dna
DEFAULT TABLESPACE heart TEMPORARY TABLESPACE temp;

GRANT CONNECT, RESOURCE TO dna;


Під друга віконці від імені SYS наберемо в SQL * Plus

CREATE USER dna IDENTIFIED BY dna;

GRANT CONNECT, RESOURCE TO dna;





Коментар. За допомогою команди GRANT новим користувачам повноваження були видані за допомогою ролей CONNECT і RESOURCE. Це зручно для прикладу, проте не варто забувати, що в робочій БД необхідно мати істотно більш продуману і регламентовану систему роздачі повноважень.

Знову в перший віконці від імені SCOTT наберемо

GRANT SELECT ON emp TO dna;
CONNECT dna/dna
CREATE TABLE empa AS SELECT * FROM scott.emp;

Тепер у DOLLY в HEART завелося 14 осіб – якщо, звичайно, у типовій схемі SCOTT Ви нічого не міняли. Наше завдання – перенести HEART з DOLLY в DOLLY1, а значить і перенести туди ж цих співробітників.


Переносимо табличний простір з першої бази в другу


Перш ніж робити сам перенесення, потрібно переконатися в тому, що переносний табличний простір – замкнутий, тобто не має зв'язків з іншими табличними просторами. Інакше перенесення такого простору був б некоректне. Для такої перевірки є процедура TRANSPORT_SET_CHECK в системному пакеті DBMS_TTS. Від імені SYS видамо в перший віконці послідовно:

EXEC DBMS_TTS.TRANSPORT_SET_CHECK( –
ts_list => ‘HEART’, –
incl_constraints => TRUE)
SELECT * FROM TRANSPORT_SET_VIOLATIONS;

Останній SELECT – це перевірка результату відпрацювання безпосередньо попередньої процедури. У нашому випадку перевірка дасть порожня множина, однак якби табличний простір HEARTS мало зовнішні зв'язки, в спеціальну системну виведену таблицю SYS.TRANSPORT_SET_VIOLATIONS вчинив би їх перелік, і ця таблиця не була б порожня.






Коментар. Назва першого параметра процедури TRANSPORT_SET_CHECK натякає на те, що в ньому може зазначатися список табличних просторів, а не окремий простір, як у нашому випадку. Це правда. Наприклад, ми могли б зберігати в одному просторі таблиці, а в іншому – їх індекси. У цих просторів за визначенням будуть "межтаблічние зв'язку", тому окремо переносити їх буде неможливо, а, в той же час, удвох – цілком припустимо. У цьому випадку в параметрі ts_list потрібно буде їх привести через кому, і буде перевірена замкнутість пари просторів.


Другий параметр процедури потрібно встановити в TRUE, якщо дані планується передавати разом з обмеженнями цілісності, і FALSE – у противному випадку.


Функціонально ідентичною процедурі TRANSPORT_SET_CHECK повинна бути булева функція ISSELFCONTAINED з тими ж параметрами. Вона не описана в документації, але в коді програми може опинитися зручніше.


Тепер можна видати:

ALTER TABLESPACE HEART READ ONLY;
HOST EXP TRANSPORT_TABLESPACE=Y TABLESPACES=(HEART) –
CONSTRAINTS=N GRANTS=Y TRIGGERS=N FILE=DHEART.DMP

Тут знадобиться в діалозі вказати користувача, що виконує цей специфічний вид експорту. Наприклад, INTERNAL / ORACLE AS SYSDBA, або ж іншого користувача, що володіє повноваженням (grant) EXECUTE_CATALOG_ROLE. Користувач SYS цим повноваженням спочатку володіє.


Тепер на рівні файлової системи скопіює файл heart1.dbf з d: oracleoradatadolly в d: oracleoradatadolly1.


Перш, ніж покинути перший віконце, не забудемо видати

ALTER TABLESPACE HEART READ WRITE;

Під друга віконці від імені SYS наберемо:

CREATE USER dna IDENTIFIED BY dna;
GRANT CONNECT, RESOURCE TO dna;
HOST IMP TRANSPORT_TABLESPACE=Y –
DATAFILES=(d:oracleoradatadolly1heart1.dbf)
FILE=DHEART.DMP

Знову в діалозі вказуємо INTERNAL / ORACLE AS SYSDBA. Як тільки всі пропрацює, дані перенесені. Не завадить, однак, виконати ще

ALTER TABLESPACE HEART READ WRITE;
ALTER USER dna DEFAULT TABLESPACE heart TEMPORARY
TABLESPACE temp;

Табличний простір в DOLLY1 повністю готове до експлуатації.


Переносимо табличний простір з другої бази в першу


Наберемо для перевірки під друга віконці від імені dna

INSERT INTO empa SELECT * from empa;
COMMIT;
SELECT * from empa;

У DOLLY в HEART утворилося в два рази більше людей: 28.


Тепер розглянемо зворотний перенос того ж простору з DOLLY1 в DOLLY. У принципі він дзеркально повторює виконані дії, але з одним нюансом: простір HEART в DOLLY вже існує. Тому в перший віконці наберемо

DROP TABLESPACE hearts INCLUDING CONTENTS;

А далі – все, як і раніше, по друга віконці:

EXEC DBMS_TTS.TRANSPORT_SET_CHECK( –
ts_list => ‘HEART’, –
incl_constraints => FALSE)
SELECT * FROM TRANSPORT_SET_VIOLATIONS;
ALTER TABLESPACE HEART READ ONLY;
HOST EXP TRANSPORT_TABLESPACE=Y TABLESPACES=(HEART)
FILE=DHEART.DMP

… Тут перервемося та скопіюємо файл файл heart1.dbf з d: oracleoradatadolly1 в d: oracleoradatadolly …

ALTER TABLESPACE HEART READ WRITE;

Перемикаємося на перший віконце і користувача SYS:

HOST IMP TRANSPORT_TABLESPACE=Y –
DATAFILES=(d:oracleoradatadollyheart1.dbf)
FILE=DHEART.DMP

Вкажемо в діалозі INTERNAL / ORACLE AS SYSDBA, чекаємо кінця підключення простору системою і виконуємо

ALTER TABLESPACE HEART READ WRITE;

Все. Можна перевіряти, скільки людей у DOLLY.


Про що не було сказано, але варто згадати


Перш за все потрібно сказати, що в одній БД після експорту, а в іншій – після імпорту, потрібно виконати резервне копіювання контрольного файлу; можна у полегшеному варіанті:

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

По-друге, вище було наведено працює, але всього лише один можливий варіант, і нічого не говорилося про масу різних варіацій, корисних для різних випадків. Що, наприклад, щодо цих деталей, як експорт повноважень, обмежень або описів тригерів, які згадувалися при виконанні експорту вищі? Чи є особливості при перенесенні секціонованими таблиць (а вони є)?


По-третє, про можливості такого методу. Переносити табличні простору можна між будь-якими двома БД, що працюють під управлінням однієї версії СУБД на одній платформі. Розумний приклад використання підходу пропонує фірма Oracle: це тиражування даних БД за допомогою CD-ROM.


Є й деякі обмеження щодо утримання, наприклад, стерпний набір табличних просторів не повинен (в поточних версіях Oracle) мати в собі "фотознімки" (snapshots, різновид materialized view); індекси, побудовані з використанням функціонального перетворення; черги в сенсі advanced queue; деякі інші більш спеціальні види об'єктів.


Посилання по темі

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*