Это может случиться с каждым - либо кто-то выдал DROP, либо DELETE, которые он не должен был выдавать, и пропала таблица! (… или самые нужные ее строки).
Не буду поучать, что критические данные нужно особо защищать от потерь, то есть, что нужно предохраняться. Каждый, кто так не делает, рискует, а все мы - люди взрослые. Но пусть тот, кто ни разу в жизни не восстанавливал файл, бросит в меня камень. Так что же делать, когда беда пришла на ваш сервер?
Вообще-то, все зависит от обстоятельств, и пути разрешения возникшей незадачи могут быть в Oracle разные. Ниже будет рассмотрен один из них, характерный своей универсальностью и тем, что в случае, если вся работа ведется на одном компьютере, останавливать рабочую базу не требуется. Кроме того, применяемая ниже техника с некоторыми поправками может быть употребима и в других ситуациях.
Схема восстановления
Единственным условием будет являться наличие холодной копии БД со старой версией таблицы, которую мы хотим восстановить. Для простоты рассмотрим ситуацию, когда со времени снятия холодной копии в базе структурных изменений не производилось, и сведения о файлах БД, а также связи таблицы в текущей базе сохранились прежними. Если это не так, то возможно вам придется на время остановить рабочую базу и запустить (соблюдая предосторожности) холодную копию, чтобы получить из нее старую метаинформацию. Это будет единственной поправкой к действиям ниже.
Общая схема восстановления таблицы довольно проста. Сначала "оживим" холодную копию БД под другим именем (мы ведь не хотим получить конфликта имен с уже работающей БД), а еще лучше - ее часть, не отягощенную не относящимися к таблице данными. Потом запустим ее и произведем экспорт таблицы. После этого можно делать импорт в рабочую базу и удалить "ожившую" базу за ненужностью.
Для оживления базы будет использована техника клонирования, не раз описанная в литературе. Здесь она подправлена для наших потребностей и для Windows NT/2000.
Пример будет излагаться для версии 8.1.6 на NT. Пользователи Unix/Linux вполне в состоянии понять, где им потребуется сделать упрощения описываемой процедуры.
Готовим клон холодной копии
Нам нужно "оживить" холодную копию в нужном объеме. Для начала следует узнать, какие файлы могут понадобиться для (частичного) клона. Нужно выдать запрос к базе:
SELECT fil.name, tsp.name FROM v$datafile fil, v$tablespace tsp
WHERE fil.ts# = tsp.ts#;
Строго говоря, этот запрос нужно давать "мертвой" БД, то есть холодной копии, а чтобы это сделать, рабочую базу придется на время остановить, а холодную копию запустить (еще раз вспомним: у них совпадают имена, и они не могут работать на одной машине одновременно). Но если вы уверены , что состав файлов и табличных пространств у вас не изменялся, то этот запрос можете обратить к "живой" БД.
Полученный перечень нужно внимательно просмотреть и исключить из него файлы, относящиеся к пользовательским табличным пространствам, которых не хранится требуемая таблица (или несколько, если нужно восстановить несколько таблиц), ее индексы и внешние связи. То есть, в списке оставим файлы для SYSTEM, RBS (скорее всего табличное пространство для сегментов отката называется у вас именно так) и для USERS (это если ваша таблица находится в пространстве USERS).
Готовим каталоги для клона
Далее создаете две структуры каталога: для вспомогательных файлов и для данных. В наиболее простом и распространенном варианте это будут структуры admin\< newSID >\… и oradata\< newSID >\…, где < newSID > - новое имя БД для "оживляемой" холодной копии. Первую структуру проще всего создать копированием admin\< SID >\…, где < SID > - это имя БД из холодной копии; вторую структуру проще всего создать вручную.
Во вторую структуру копируем контрольные, журнальные файлы и файлы с сегментами отката из холодной копии, а также выбранные нами файлы с нужным табличным пространством (или с пространствами, если их несколько). Контрольный файл достаточно для экономии диска скопировать в одном экземпляре - если до этого их было несколько.
В первой структуре особым вниманием будет наделен файл init< SID >.ora. Во-первых, его нужно переименовать в init< newSID >.ora (иногда формат имени файла - просто init.ora, тогда менять имя, естественно, не нужно). Во-вторых, нужно откорректировать его содержимое:
- заменить параметры db_name, instance_name и service_names, проставив для них < newSID >
- в параметре control_files оставить один контрольный файл - в зеркалировании для нашего случая нужды нет
- поменять в соответствии с организованными только что каталогами значения параметров audit_file_dest, background_dump_dest, control_files, core_dump_dest, log_archive_dest и user_dump_dest.
- закомментировать параметры global_names и db_domain, если они имеются
- провести корректировку других параметров (по желанию), исходя из того, что "вызываться из небытия" холодная копия будет только для экспорта
Создаем сценарий для получения нового контрольного файла
Если вы предусмотрительно этого не делали, то нужно получить сценарий для создания контрольного файла для новой БД. Делается это просто выдачей от имени sys:
ALTER DATABASE BACKUP CONTROL FILE TO TRACE;
Опять, корректнее было бы выдать эту команду на "живой" холодной копии, но если конфигурация файлов у вас за прошедшее время не менялась, то можно выдать и на рабочей базе.
Выданная команда породит сценарий, который попадет в user_dump_dest\*.trc. Конкретное имя трассировочного файла придется поискать контекстным поиском в содержимом, но если вы выдали эту команду только что, то скорее всего это будет самый свежий трассировочный файл.
Ищется текст, начинающийся со строк
STARTUP NOMOUNT
CREATE CONTROLFILE …
Этот текст нужно вырезать до конца предложения CREATE CONTROLFILE (комментарии, а также RECOVER DATABASE и дальше, нам не нужно). Запоминаем этот текст в файле с информативным именем и начинаем его править.
Предложение
CREATE CONTROLFILE REUSE DATABASE "< SID >" NORESETLOGS NOARCHIVELOG
заменяем на
CREATE CONTROLFILE REUSE SET DATABASE "<new SID >" NORESETLOGS NOARCHIVELOG
Из раздела LOGFILE выкидываем ненужные члены групп журнальных файлов и оставляем по одному, если только их было больше.
В разделе DATAFILES оставляем только те пользовательские файлы, которые мы скопировали в новый каталог - упоминание об остальных выкидываем.
Сценарий создания нового контрольного файла готов.
Создаем клон
Создаем контрольный файл клона
Прежде, чем это сделать фактически, в Windows нужно выдать
ORADIM -NEW -SID < newSID > -INTPWD dba -STARTMODE m -PFILE= path \INIT< newSID >
а затем
SET ORACLE_SID=< newSID >
Теперь можно выдать
SQLPLUS /NOLOG
SQL> CONNECT INTERNAL
Connected to an idle instance
SQL> @< имя файла со сценарием создания контрольного файла >
Открываем "новую" базу
Сразу после этих действий, не выходя из SQL*Plus, набираем
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE;
Media recovery complete
Не исключено, однако, что вы получите в ответ что-то вроде
ORA-00279 …
ORA-00289…
ORA-00280…
Specify log: …
В одном из он-лайновых журналов осталась запись, которую просит процедура восстановления. Имя журнала она может вам предложить совсем несусветное; можно простым перебором попытаться "подсунуть" системе один из журнальных файлов, пока она его не "съест":
Z:\…\redo01.log
Log applied
Теперь:
SQL> ALTER DATABASE OPEN RESETLOGS;
Database opened
Созданный клон готов к работе.
Восстановление таблицы
Дальнейшее чрезвычайно просто. С помощью программы exp выгружаем таблицу (или несколько таблиц) в файл из клона холодной копии, и с помощью программы imp выполняем загрузку в рабочую базу.
Таблица восстановлена.
Завершаем работу
Убираем за собой
Когда все сделано, не забудем выполнить
ORADIM -SHUTDOWN -SID < newSID >
ORADIM -DELETE -SID < newSID >
и удалить созданные каталоги.
Извлекаем уроки
Описанная схема восстановления поначалу может показаться сложной, но в своей основе она проста. Немного освоившись, вы сами научитесь ее модифицировать для самых разных конкретных вариаций случившейся неприятности. Но, все же, некоторое занудство выполняемых операций может послужить лучшей гарантией того, что вы попытаетесь избежать их повторения в будущем и предупредить ситуацию.
Для этого требуется одно: обеспечить дополнительной защитой критичные таблицы. Средств для этого в Oracle хватает: это и архивация журналов, и использование триггеров, журнализующих изменения в таблицах, и запрет на удаление таблиц (или удаление строк из таблиц) для определенных категорий пользователей, и другие. Снимайте почаще резервную копию данных и, особенно, контрольного файла - места она просит совсем чуть-чуть.
В выборе средств и можно проявить свое творчество, если вас не устраивает рутина регулярного восстановления.