Галактика в вопросах и ответах

Добрый день.

Имеем Gal 8.10, Oracle 10G.

Мы думаем на тему политики резервного копирования. В данный момент табличное пространство индексов занимает 70% БД (29Gb).
Необходимо ли включать его в резервное копирование, или можно, восстановив все остальные табличные пространства, запустить процедуру создания индексов, которая используется на этапе импорта при конвертации БД (CRDRIDX)?

Создаст ли эта утилита все необходимые индексы?

Создать то она их создаст, но смысл? Выигрыша по времени это не даст, скопировать 30 гектарный файл табличного пространства по любому быстрее будет. Да и статистика при таком раскладе пойдет лесом.

Интересно, а как вы собрались не включать в резервное копирование табличное пространство не являющееся временным(если конечно оно холодное) - тогда у вас база просто не поднимется?. Или вы собрались дамп делать?

Речь идет о долгосрочном хранении бэкапов. оперативное резервное копирование будет проходить целиком

Все равно не ясно как у вас база поднимется без индексного тоабличного пространства. Или перед долгосрочным бэкапом собираетесь удалять индексы и пересоздавать файл табличного пространства индексов?

oiko прав, больше проблем будет с подъмом такой базы. скопировать 29Гб это сколько времени, ну, до 15 минут, оно того не стоит. А что вы понимаете под долгосрочным бэкапом? сколько хранить? и для чего?
Может проще выгружать в dbf и хранить, если вы лимитированы объемом хранения, правда, подъм базы займет много времени

P.S. беседовал с одним банковским работником, так он мне сказал, что у них по правилам БД со всеми логами хранится 5 лет.

Приблизительный план такой, на практике не опробованный. Даже не знаю получится такое или нет, поэтому и спрашиваю.
1. Создаем новую БД;
2. Создаем нужные табличные пространства, создаем нужные схемы для галактики, дропаем индексы;
3. Восстанавливаем необходимые табличные пространства, без табл.пространства индексов;
4. Пересоздаем индексы.
По поводу п.3. Не пробовал это делать на галактической бд, но однажды мне приходилось восстанавливать табличные пространства которые были из разных бэкапсэтов, база стартовала, но это зависит от внутренней организации данных конечно. Надо пробовать.

Бэкапы нужно хранить достаточно долго, это основная учетная система. Которая регулярно чистится от старых данных. Разные ситуации могут возникнуть в жизни.
Просто если сделать способ хранения без индексов, то бэкапов можно хранить в 3 раза больше. Я про это.
С дбфами идея неплохая, надо подумать. Думаю тут будет не критично время восстановления БД. Сейчас БД на 50гб. Из дбф поднимается за 6-7 часов с созданием индексов. Я думаю вряд ли кому-то сиюминутно понадобятся прошлогодние данные.

расскажите пожалуйста как у вас хранятся бэкапы, чем их делаете и т.п. на тему резервного копирования. интересует как и оперативное копирование так и долгосрочное.

Попробуйте воспользоваться exp_dbi.exe - утилитой экспорта словаря и данных для инсталятора. Утилита предназначена для выгрузки таблиц словаря и данных для подключенной БД. Таблицы выгружаются в специальном формате dbi, используемом при инсталляции баз данных.

Формат dbi - это чисто данные в бинарном формате, да еще по моему и упакованные.

Закачивать обратно можно используя стандартные утилиты DB_INST инсталляции баз данных.

Еще один вариант используйте функцию сохранения и восстановления БД системы автоматического тестирования AQA. Архивы AQA это тоже упакованный бинарный формат.

Правда оба предложения могут оказаться нестабильными на большом объеме данных. Ну и по скорости конечно не быстрые.

однажды мне приходилось восстанавливать табличные пространства которые были из разных бэкапсэтов, база стартовала

- возможно только если включен режим архивлога (или если у вас много больших логов), если нет то ничего вы не поднимете - контрольные файлы видя что база рассогласована ее просто не откроют. Помочь вытащить данные вам сможет только ТП Оракла за приличные деньги.
Кстати оракловая база очень неплохо пакуется в 5-10 раз ужимается.
Ежедневно ночью тормозим базу делаем ее полную холодную копию (если включен архивлог то журналы не копируем - при холодном копировании они не нужны), стартуем базу, запускаем процесс архивации копии. В течении месяца архив держи кадый день, в течении полугода - каждый месяц, больше полугода раз в квартал.

Можете воспользоваться оракловой технологией горячего копирования: раз в квартал полный холодный бэкап а затем каждый день на горячую копировать только архивы журнала (обязательно включен архивлог).