Как можно быстро сделать копию базы данных Oracle?

Question

[DigitalGod]

Доброго времени суток.
Подскажите, как можно быстро сделать копию базы данных Oracle?
На данный момент разворачивание дампа в 44Гб занимает около 5 часов. Раньше использовали Veritas Replication Exec на 32-битной версии Windows и копировали через VSS. Сейчас уже стоит 64-битная Windows и Veritas на ней не работает. Идея копировать измененные блоки файлов понравилась, но аналогичного софта не нашли.

Comments

[DigitalGod]

Копии баз создаются на разных серверах. Исходную базу тушить нельзя.

[DigitalGod]

Еще несколько моментов:
1. Oracle 102.0.5, возможно скоро перейдем на 11
2. Standby не подойдет, поскольку необходимости в постоянном обновлении нет. Утром загрузили дамп, разработчики поковырялись на базе. Следующим утром база затерлась новым дампом.

Answer 1

[Александр Коньков]

По существу вопроса:
Мы сделали 3 standby из которых:
1 - собственно standby,
а 2 других как раз для разработчиков, тестов и т.п.

Эти самые "2 других" ночью полноценные physical standby - накатывают данные с рабочей,
а днём переключаются в snapshot standby - для работы "разработчиков, тестов и т.п.".
Переключение организованно скриптами по cron-у - утром "открываем", вечером "закрываем".
Вечером, если надо, можно и не закрывать - главное, чтобы хватало место на диске.

При этом каждый день мы имеем свежий "срез" рабочей БД для "разработчиков, тестов и т.п.".

P.S.
"На данный момент разворачивание дампа в 44Гб занимает около 5 часов. " -
что-то не шибко быстро.
Мы разворачиваем отдельную (not standby) тестовую БД часов за 20.
~6Tb, rman duplicate from active or backup location, 12 потоков

Comments

[DigitalGod]

Вопрос - а как быть с теми изменениями, которые делают разработчики в течении дня? Они как-то затираются или данные с боя накатываются поверх?

P.S.
Зависит от мощности серверов :) нам пока выделили совсем немного.

[Александр Коньков]

Затираются. При переключении в snapshot, Oracle создаёт гарантированноую точку восстановления в flashback. При возврате из snapshot-а БД восстанавливается на точку восстановления и далее накатывается всё, что было пока БД была в snapshot... Надеюсь понятно написал :)

Answer 2

[Никита Чуков]

Прочтите это:
http://www.oracle-base.com/articles/10g/oracle-data-pump-10g.php
База размером 38-40 Gb переносится меньше чем за час.

Или наверное более верный путь:
http://www.oracle-base.com/articles/11g/duplicate-database-using-rman-11gr2.php

Comments

[DigitalGod]

Вот как раз через Data Pump этот дамп разворачивается часа 4-5. Понятное дело что это не на промышленном сервере, где более 100 Гб памяти и от 16 ядер процессора.

[Никита Чуков]

Вы правы, просто у нас и на тестовом 256 GB памяти и 32 ядра

[DigitalGod]

Будь у нас такие же запасы мощности на серверах разработки - вряд ли я задался подобным вопросом.

Answer 3

[Qwadrat]

Если 11g, то можно клонировать на лету с активной базы без создания бэкапа:

rman target sys@db1 auxiliary sys@db2

DUPLICATE TARGET DATABASE TO db2
FROM ACTIVE DATABASE
DB_FILE_NAME_CONVERT '/u01/oradata/db1/','/u01/oradata/db2/'
SPFILE
PARAMETER_VALUE_CONVERT '/u01/oradata/db1/','/u01/oradata/db2/'
SET LOG_ARCHIVE_DEST '/u01/oradata/arc/db2/'
SET LOG_FILE_NAME_CONVERT '/u01/oradata/db1/','/u01/oradata/db2/';

Конвертация имен файлов актуальна, если делаем копию на этом же хосте

Answer 4

[Евгений Ульянов]

А насколько часто нужно эту операцию производить? Если для отказоустойчивости, то не думали в сторону Standby-базы в режиме Mirror к основной?

При этом все транзакции, совершаемые на основной базе, будут автоматически применяться на Standby; базу можно будет использовать для Read-only операций (к примеру, отчетность), и оперативно превратить в production, если возникнет необходимость.

Comments

[DigitalGod]

На самом деле нужно делать ночную копию рабочей базы. Плюс иногда требуется развернуть копию за какое-то давнее число. Ждать по 5 часов возможности нет.

Про Standby думали, и он у нас есть. Но нам не нужно чтобы данные постоянно обновлялись, достаточно утренней копии на весь день.

Answer 5

[Евгений Ульянов]

А если автоматизировать на ночь заливку dump'а? В таком случае даже 5 часов не проблема - пусть себе спокойно переливает с production к developer'ам.

Или production ночью критичен для такой нагрузки?

При таком подходе все равно остается проблема разворачивания копии за давнее число, но тут уже больше в железо упирается... Bottleneck в дисках?

Comments

[DigitalGod]

Само собой сделать заливку дампа ночью - вполне логично. Только это временное решение, сейчас дамп 44Гб. И он только растет. И скоро просто не уложиться в ночь.
Что касается дисков - девелоперский сервер конечно же не блещет мощностью, и можно было бы увеличить память/процессор. И опять-таки - бесконечно увеличивать мощность тоже не вариант.

Хотелось бы узнать как другие компании, у которых наверняка дампы побольше будут, решают проблему разворачивания.

Через VSS это происходит быстро, но грамотного софта под 64-битную систему я не нашел.

[Евгений Ульянов]

У меня была необходимость изредка (раз в два-три месяца) обновлять базу Developer и Testing сред dump'ом с продуктива; при размере базы в ~200 Gb я просто исключал из дампа тяжелые таблицы (вложения, CLOB'ы), что облегчало дамп до 12 Gb; такой дамп сливался за 10-15 минут, заливался около 30.

Все сервера были виртуальными (VMware), и с очень неплохим оборудованием - однако по количеству ядер / памяти никаких космических значений не было - если не ошибаюсь, на Production было 8 ядер и 16 Gb RAM.

Я бы одновременно с поиском софта смотрел в сторону уменьшения размера дампа до необходимого разработчикам; возможно - виртуализация, чтобы создавать копию не базы, а целиком виртуальной машины.

[DigitalGod]

В нашем случае размер дампа уменьшить не получится. Никаких тяжелых таблиц нет. Исключительно данные, которые почистить нельзя.

Что касается виртуализации - почти все находится на виртуалках, но БД сидит на отдельном сервере (оракловый кластер).

Возможно нужно действительно увеличивать мощность серверов.