Уважаемые подписчики рассылки!
В этом выпуске, который логически дополняет предыдущий (кстати, на сайте
рассылки размещена исправленная и немного дополненная версия предыдущего выпуска),
я, снова кратко и упрощенно, расскажу о том, как при наличии резервной копии, созданной с помощью
утилиты onbar и диспетчера хранения данных ISM, восстановить все данные сервера Informix.
Изложение будет вестись на примере версии IDS 9.30.TC2 для Windows NT/2000 и штатно устанавливаемого вместе с ним ISM 2.20. Тем не менее, последовательность и суть выполняемых действий не зависит от операционной системы и версии.
Итак, резервная копия DB-пространств и журналов, созданная с помощью onbar и ISM, у нас есть (в прошлом выпуске рассылки мы создали ее на диске, в каталогах c:\tmp\bardata и c:\tmp\barlog.). Достаточно ли созданных там файлов для успешного восстановления в случае любого сбоя? Конечно, нет!
В разделе "Which Administrative Files to Back UP?" руководства по резервному копированию Informix сказано, что для успешного восстановления в случае сбоя дисков, на которых находилось ПО Informix, или для восстановления данных на другой машине, необходимо, в простейшем случае, иметь также актуальную копию следующих административных файлов:
Актуальность копии административных файлов означает, что входящие в нее файлы соответствуют моменту создания последней успешной резервной копии сервера в целом. Рекомендуется копировать эти административные файлы сразу же после успешного резервного копирования сервера с помощью onbar.
Итак, считаем, что мы полностью подготовились к восстановлению. У нас есть резервные копии всех необходимых административных файлов, а также резервная копия сервера в целом, созданная так, как было описано в предыдущем выпуске рассылки.
И тут на нашем сервер Informix произошел сбой. В результате сбоя стали недоступны все чанки всех DB-пространств. Для демонстрации я просто удалю каталог c:\IFMXDATA, в котором у меня созданы чанки всех DB-пространств.
c:\IFMXDATA>cd c:\ c:\>rmdir /s /q IFMXDATA
Чанков нет вообще. Мы "потеряли" все данные. Попытаемся запустить сервер из окна командной строки Informix:
C:\Informix>starts ol_creator C:\Informix>onstat -m Informix Dynamic Server Version 9.30.TC2 -- Initialization -- Up 00:00:06 -- 17280 Kbytes Message Log File: C:\Informix\ol_creator.log ... 16:10:40 Informix Dynamic Server Started. Sun May 16 16:10:41 2004 16:10:41 Booting Language <c> from module <> 16:10:41 Loading Module <CNULL> 16:10:41 Booting Language <builtin> from module <> 16:10:41 Loading Module <BUILTINNULL> 16:10:46 Informix Dynamic Server Version 9.30.TC2 Software Serial Number AA C#J415297 16:10:46 Cannot Open Primary Chunk 'C:\IFMXDATA\ol_creator\rootdbs_dat.000', er rno = 2 C:\Informix>onstat - shared memory not initialized for INFORMIXSERVER 'ol_creator'
Как видите, сервер не запускается, поскольку не доступен, как минимум, первый чанк rootdbs. Это и будет исходная задача, которую предстоит решать.
Мы предполагаем, что ОС работает, все диски уже доступны, ПО сервера Informix установлено и все содержимое каталога %INFORMIXDIR% доступно. Сервер зарегистрирован как служба, хотя и не запускается. Предполагаем также, что в %ISMDIR% доступно содержимое подкаталога bin (это программы, обеспечивающие работу ISM), и подкаталогов index, mm и res (это файлы конфигурации и данных диспетчера хранения данных, которые мы копировали отдельно). Предполагаем, что все три службы ISM успешно запущены. Кстати, в процессе запуска они и создадут, при необходимости, недостающие подкаталоги %ISMDIR%.
Все последующие шаги по восстановлению системы в целом я и опишу далее. Вариантов восстановления может быть несколько - до момента времени, до определенного журнала, до момента, максимально близкого к моменту сбоя и т.п. Все они будут отличаться, по сути, только опциями, которые надо будет задать утилите onbar на конечном этапе восстановления.
Конечно, возможны сбои, в результате которых у нас ничего описанного выше тоже не будет. Например, компьютер, на котором работает сервер Informix, могут просто украсть. Тогда надо сначала привести (новую) систему к тому состоянию, которое описано выше, а именно:
Описание всех этих действий выходит за рамки данного выпуска. Впрочем, процедуру простой установки ПО Informix на платформе Windows, если на то будет желание подписчиков, я могу описать в одном из следующих выпусков. Выполнение же первых двух действий имеет отношение, скорее, к администрированию ОС...
Останавливаем службы ISM, если они работают, и помещаем на свои места все описанные выше административные файлы. У вас ведь есть их актуальные копии, правда?
Речь идет о следующих файлах:
Далее, воссоздаем содержимое реестра SQLHOSTS. По идее, конфигурация, существовавшая на момент создания последней резервной копии, восстановлена. Снова запускаем службы ISM.
Если все файлы конфигурации и данных ISM восстановлены полностью, мы должны увидеть смонтированные устройства (они же были смонтированы на момент завершения копирования). В окне командной строки сервера Informix выполняем:
C:\Informix>set PATH=%PATH%;c:\ISM\2.20\bin C:\Informix>ism_show -devices (nothing) mounted on 4mm tape \\.\Tape0 file disk Data1 mounted on c:\tmp\bardata, write enabled file disk Logs1 mounted on c:\tmp\barlog, write enabled C:\Informix>ism_show -volumes volume pool flags written (%) expires Bootstrap1 ISMDiskData 0 KB 04/21/06 Data1 ISMDiskData 16 MB 100% 04/21/06 Logs1 ISMDiskLogs 192 KB 100% 04/21/06
Итак, устройства доступны, тома смонтированы. Если это не так (вы демонтировали тома, и лишь затем скопировали файлы конфигурации и данных ISM), придется воспользоваться командами монтирования томов (см. предыдущий выпуск рассылки). Если отсутствуют устройства, с которыми вы ранее работали, значит, копия файлов данных и конфигурации ISM оказалась не настолько актуальной... Ищем актуальную копию или готовимся к тому, что данные восстановить не удастся.
У нас, похоже, конфигурация в порядке, поэтому можно переходить к восстановлению сервера в целом, с автоматическим созданием отсутствующих чанков.
Выполняем соответствующую команду onbar (см. руководство по восстановлению):
C:\Informix>onbar -r -w -O Verifying physical disk space, please wait ... Error opening file C:\IFMXDATA\ol_creator\rootdbs_dat.000.
Ага, проблемы... Похоже, файл чанка автоматически создать не получилось. Посмотрим, что пишет утилита onbar в своем журнале сообщений (по умолчанию, %INFORMIXDIR%\bar_имя_сервера.log):
2004-05-16 17:12:10 2864 2864 C:\Informix\bin\onbar_d -r -w -O 2004-05-16 17:12:11 2864 2864 Unable to create C:\IFMXDATA\ol_creator\rootdbs_dat.000, there may not be enough space 2004-05-16 17:12:11 2864 2864 There are no storage spaces/logical logs to backup/restore. 2004-05-16 17:13:33 2864 2864 C:\Informix\bin\onbar_d complete, returning 147 (0x93)
Создадим вручную каталог, в котором он находился:
C:\Informix>mkdir c:\IFMXDATA\ol_creator
Кстати, если вам пришлось восстанавливать ПО Informix путем переустановки сервера и последующей инициализации, а все чанки находились в одном, стандартном, каталоге, то такая проблема может и не возникнуть.
Пробуем теперь еще раз. Теперь результат лучше:
C:\Informix>onbar -r -w -O Verifying physical disk space, please wait ... Verifying physical disk space, please wait ... Verifying physical disk space, please wait ... C:\Informix>echo %ERRORLEVEL% 179
Отсюда вывод: опция -O не создаст каталоги, в которых находятся чанки. Каталоги придется создать вручную. Что именно создавать, будет понятно по сообщениям onbar.
У нас, похоже, были воссозданы три чанка. Код возврата 179, как сказано в руководстве по onbar, означает успешное воссоздание отсутствующих чанков в ходе восстановления. Посмотрим, что сказано в журнале сообщений onbar:
2004-05-16 17:22:34 3160 3160 C:\PROGRA~1\Informix\bin\onbar_d -r -w -O 2004-05-16 17:22:43 3160 3160 Creating C:\IFMXDATA\ol_creator\rootdbs_dat.000 to allow restore 2004-05-16 17:22:51 3160 3160 Creating c:\IFMXDATA\ol_creator\sbspace_dat.000 to allow restore 2004-05-16 17:23:02 3160 3160 Creating c:\IFMXDATA\ol_creator\workdbs_dat.000 to allow restore 2004-05-16 17:23:05 3160 3160 Successfully connected to Storage Manager. 2004-05-16 17:23:07 3160 3160 Begin cold level 0 restore rootdbs (Storage Manager copy ID: 1099 0). 2004-05-16 17:23:42 3160 3160 Completed cold level 0 restore rootdbs. 2004-05-16 17:23:43 3160 3160 Begin cold level 0 restore sbspace (Storage Manager copy ID: 1100 0). 2004-05-16 17:23:45 3160 3160 Completed cold level 0 restore sbspace. 2004-05-16 17:23:46 3160 3160 Begin cold level 0 restore workdbs (Storage Manager copy ID: 1101 0). 2004-05-16 17:23:47 3160 3160 Completed cold level 0 restore workdbs. 2004-05-16 17:23:49 3160 3160 Completed whole system restore. 2004-05-16 17:23:52 3160 3160 Successfully connected to Storage Manager. 2004-05-16 17:23:52 3160 3160 Begin restore logical log 17 (Storage Manager copy ID: 1102 0). 2004-05-16 17:23:53 3160 3160 Completed restore logical log 17. 2004-05-16 17:23:54 3160 3160 Begin restore logical log 18 (Storage Manager copy ID: 1105 0). 2004-05-16 17:23:55 3160 3160 Completed restore logical log 18. 2004-05-16 17:23:56 3160 3160 Begin restore logical log 19 (Storage Manager copy ID: 1107 0). 2004-05-16 17:23:57 3160 3160 Completed restore logical log 19. 2004-05-16 17:24:05 3160 3160 Completed logical restore. 2004-05-16 17:24:07 2360 2360 C:\Informix\bin\onbar_d -b -l 2004-05-16 17:24:08 2360 2360 C:\Informix\bin\onbar_d complete, returning 0 (0x00) 2004-05-16 17:24:11 3160 3160 C:\Informix\bin\onbar_d complete, returning 179 (0xb3)
Похоже, сервер восстановлен вплоть до последнего логического журнала, резервная копия которого была обнаружена. Что и требовалось. Проверим режим работы и сообщения сервера:
C:\Informix>onstat -m
Informix Dynamic Server Version 9.30.TC2 -- Quiescent -- Up 00:34:21 -- 3366
4 Kbytes
Message Log File: C:\Informix\ol_creator.log
17:24:05 Logical Recovery Complete.
20 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks
17:24:05 Logical Recovery Complete.
17:24:06 Quiescent Mode
17:24:06 Logical Log 19 Complete.
17:24:06 Checkpoint Completed: duration was 0 seconds.
17:24:06 Checkpoint loguniq 20, logpos 0x18
17:24:06 Maximum server connections 0
17:24:08 Booting Language <spl> from module <>
17:24:08 Loading Module <SPLNULL>
17:29:31 Fuzzy Checkpoint Completed: duration was 0 seconds, 2 buffers not flu
shed.
17:29:31 Checkpoint loguniq 20, logpos 0x804c
17:29:31 Maximum server connections 0
17:34:31 Fuzzy Checkpoint Completed: duration was 0 seconds, 2 buffers not flu
shed.
17:34:31 Checkpoint loguniq 20, logpos 0x904c
17:34:31 Maximum server connections 0
Переводим сервер в многопользовательский режим, и все:
C:\Informix>onmode -m C:\Informix>onstat - Informix Dynamic Server Version 9.30.TC2 -- On-Line -- Up 00:46:49 -- 33664 Kbytes
Все действительно так просто, при наличии резервных копий всего, что необходимо. Даже чанки вручную создавать не пришлось.
В этом выпуске я описал основные шаги восстановления данных сервера Informix при наличии резервной копии на диске, созданной с помощью утилиты onbar и диспетчера хранения данных ISM. Мы рассмотрели ряд нюансов этой простой процедуры, дополнительные шаги по резервному копированию всех необходимых административных файлов, а также определили предварительные условия, при которых она непосредственно применима.
С удовольствием отвечу на вопросы и замечания к описанной процедуре в следующих выпусках рассылки. Жду ваших комментариев!
Все вышедшие выпуски рассылки можно найти на сайте рассылки. Там же реализована возможность поиска материалов по ключевым словам (с помощью Google)
Вероятно, я еще раз обращусь к теме настройки, установки и переустановки диспетчера хранения данных ISM. Но, возможно, я опишу процесс резервного копирования на диск и восстановления данных с помощью более простой и давно используемой утилиты ontape.
С наилучшими пожеланиями,
В.К.
|
|