Открыто о СУБД Informix на русском : Восстановление сервера с помощью ontape

Выпуск 8

Уважаемые подписчики рассылки!

На свой вопрос "Что вы хотите узнать о СУБД Informix в 2005 году?" я не получил ровно ни одного ответа. Поэтому я буду вести рассылку в тех направлениях, которые будут интересны мне. Соответственно, в этом году я предполагаю рассмотреть следующие вопросы:

• Восстановление IDS в случае разнообразных сбоев
• Автоматизация многотомного архивирования при использовании ontape
• Репликация данных
• Использование Informix HPL для эффективной загрузки больших объемов данных
• Получение и интерпретация планов выполнения запросов в базах данных Informix
• Новые возможности и особенности IDS 9.40 (и 9.50, как появится)
• Использование фрагментации в IDS
• Администрирование и использование подсистемы PDQ
• Как Informix хранит данные на диске (внутренняя архитектура)

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

Изложение, как и раньше, ведется на примере версии IDS 9.30.TC2 для Windows NT/2000. Тем не менее, последовательность и суть выполняемых действий не зависит от операционной системы и версии.

Уточнения по процедуре резервного копирования и нерешенные проблемы

В прошлом выпуске я упустил ряд нюансов и проблем, не существенных для рассматриваемой простой, "домашней" системы Informix версии 9.30. Тем не менее, о некоторых из них вам следует знать.

1. Определение значений параметров TAPESIZE и LTAPESIZE

Как справедливо было замечено, начиная с версии 9.40 в качестве значения параметров TAPESIZE и LTAPESIZE можно указывать 0, и утилита ontape будет писать в указанные файлы до тех пор, пока не запишет все, что считает нужным, или пока не закончится свободное пространство в файловой системе. В прежних версиях можно указать эти значения просто с большим запасом.

Тем не менее, даже если места на диске достаточно, определение размера архива я считаю занятие не праздным. Носители, на которых в конечном итоге окажется архив, например, CD, имеют ограниченный объем, и не мешает знать, сколько их понадобится. Кроме того, от размера архива определенно зависит продолжительность архивирования, а в некоторых ситуациях не мешает заранее определить ее поточнее.

Был предложен входящий в пакет DBA_Tools запрос size_all.sql для более точного определения количества непустых страниц в системе:

 
------------------------------------------------- 
-- Gives the total size allocated 
--  and the total size ACTUALLY used. 
--   All db's (whole instance) 
-- 
--  Using in \DBA_Tools\bat\ontape_auto.bat  
-- 
-- V.Shulzhenko DBA_Tools (by John Carlson, CDI) 
------------------------------------------------- 
set isolation to dirty read; 
select  round(sum(nptotal*v.sh_pagesize/1024)) total_KB 
        ,round(sum(npused*v.sh_pagesize/1024)) used_KB 
from sysptnhdr h, sysptprof p, sysdatabases d, sysshmvals v 
where h.partnum = p.partnum 
  and p.dbsname = d.name; 

Чуть позже, восстановив сервер, мы проверим его в действии. Обратите внимание, как в запросе получается размер страницы Informix.

2. Утилита ontape отказывается переписывать копии логических журналов

Обратите внимание, что если в файле, указанном в качестве LTAPEDEV, уже находится копия журнала, команда ontape -a откажется его переписывать. Именно поэтому мы в файле alarm.bat (с таким же успехом его можно было назвать и alarm.cmd) и занимались копированием файлов под девизом "вставляем пустую ленту".

3. Альтернативы alarm.bat и проблемы в представленном файле

Предложенный простой сценарий alarm.bat далек от совершенства. Вместо него можно использовать входящий в состав DBA_Tools файл event_alarm.bat или, если вы работаете с версией 9.40, стандартный %INFORMIXDIR%\etc\alarmprogram.bat, просто добавив соответствующую обработку события класса 23.

Серьезных проблем в предложенном сценарии alarm.bat, мне кажется, три. Во-первых, если уж копировать файл LTAPEDEV, то в другой каталог, желательно - на другом диске или вообще на другой системе. Вместо создания локальной копии, имеет смысл команду

 
copy %BACKUP_DIR%\%BACKUP_LOG_FILE% %BACKUP_DIR%\%BACKUP_LOG_FILE%.%LOG%  

заменить командой

 
rename %BACKUP_DIR%\%BACKUP_LOG_FILE% %BACKUP_DIR%\%BACKUP_LOG_FILE%.%LOG%  

С именем создаваемой копии журнала тоже не все так просто. Как мы увидим в этом выпуске, при восстановлении происходит так называемая "реинкарнация" сервера, он начинает "проживать новую жизнь". Идентификаторы логических журналов в этой "новой" жизни будут совпадать с идентификаторами некоторых журналов из "прежней" жизни, но содержимое будет отличаться! Если оставить alarm.bat без изменений, эти новые копии будут переписаны поверх копий из "прежней" жизни, что не всегда допустимо.

Решить эту проблему несложно. Надо в имя копии добавить временную отметку, например, получив дату и время в переменные среды, как это сделано в файле ontape_auto.bat все в том же пакете DBA_Tools:

 
  rem -- Установить текущую дату (для названия файла) -- 
Set _PARSEARG="eol=; tokens=1,2,3,4* delims=/,. " 
For /F %_PARSEARG% %%i in ('date /t') Do SET _YYYYMMDD=%%l_%%k_%%j 
 
  rem -- Установить текущее время (для названия файла) -- 
Set _PARSEARG="eol=; tokens=1,2,3* delims=:, " 
For /F %_PARSEARG% %%i in ('time /t') Do Set _HHMM=_%%i%%j 

После этого можно использовать значения переменных _HHMM и _YYYYMMDD в имени файла, в который мы помещаем резервную копию журнала. Мне бы хотелось указывать время с точностью большей, чем до минуты, и это можно сделать, анализируя вместо результатов time /t значение переменной среды time:

 
C:\Informix>echo %time% 
14:03:14,79 

Правда, в NT4 эта переменная еще не поддерживалась... Впрочем, если восстановление выполняется дольше, чем за минуту (так оно и будет в реальной ситуации), никаких серьезных проблем не возникает. Каждая копия журнала уникально идентифицируется.

Третья, и наиболее серьезная проблема, на которую мне указали, состоит в том, что пока копируется журнал, может заполниться следующий. Что при этом произойдет ("подхватит" ли текущий процесс ontape -a новый заполненный журнал или нет, не будет ли конфликтов при одновременной работе двух и более процессов ontape -a и возможна ли она вообще) - надо исследовать. Я собираюсь рассмотреть эту проблему в одном из следующих выпусков. А пока - пора восстанавливать Informix, а то мне без него скучно...

Восстановление сервера с помощью ontape

Теоретически, восстанавливать сервер из резервной копии так же просто, как и создавать ее. Если сервер "упал" и не запускается, необходимо найти подходящие резервные копии, поместить соответствующий архив уровня 0 в устройство, задаваемое параметром конфигурации TAPEDEV, и выполнить восстановление с помощью команды ontape -r.

1. Восстановление из архива уровня 0

 
C:\Informix>cd c:\tmp 
 
C:\tmp>copy /y archive.0 archive 
Скопировано файлов:         1. 
 
C:\tmp>dir archive* 
 Том в устройстве C имеет метку MAIN 
 Серийный номер тома: D0A3-4245 
 
 Содержимое папки C:\tmp 
 
19.01.2005  13:51        17 842 176 archive 
19.01.2005  13:51        17 842 176 archive.0 
19.01.2005  14:13           262 144 archive.1 
... 
 
C:\tmp>ontape -r 
 
Please mount tape 1 on c:\tmp\archive and press Return to continue ... 
 
Archive Tape Information 
 
Tape type:      Archive Backup Tape 
Online version: Informix Dynamic Server Version 9.30.TC2 
Archive date:   Wed Jan 19 13:50:53 2005 
User id:        openxs 
Terminal id:    CREATOR 
Archive level:  0 
Tape device:    c:\tmp\archive 
Tape blocksize (in k): 16 
Tape size (in k): 100000 
Tape number in series: 1 
 
Spaces to restore:1 [rootdbs 
                                                                     ] 
2 [blobdbs 
                                                   ] 
3 [sbspace 
                                                   ] 
4 [workdbs 
                                                   ] 
 
Archive Information 
 
Informix Dynamic Server Copyright(C) 1986-1999  Informix Software, Inc. 
Initialization Time       04/15/2003 09:28:15 
System Page Size          4096 
Version                   12 
Archive CheckPoint Time   01/19/2005 13:50:54 
 
Dbspaces 
number   flags    fchunk   nchunks  flags    owner                            name 
1        1        1        1        N        informix                         rootdbs 
2        8001     2        1        N S      informix                         sbspace 
3        1        3        1        N        informix                         workdbs 
4        11       4        1        N B      informix                         blobdbs 
 
 
Chunks 
chk/dbs offset   size     free     bpages   flags pathname 
1   1   0        12800    5413              PO-   C:\IFMXDATA\ol_creator\rootdbs_dat.000 
2   2   0        12500    544               POS   c:\IFMXDATA\ol_creator\sbspace_dat.000 
3   3   0        25000    24206             PO-   c:\IFMXDATA\ol_creator\workdbs_dat.000 
4   4   0        2500              2500     POB   c:\IFMXDATA\ol_creator\blobdbs_dat.000 
 
Continue restore? (y/n)y 
Do you want to back up the logs? (y/n)y 
 
Please mount tape 1 on c:\tmp\log and press Return to continue ... 
Log files are corrupt. 
Could not salvage logs, continue restore? (y/n)y 
Restore a level 1 archive (y/n) n 
Do you want to restore log tapes? (y/n)n 
 
Program over. 
 
C:\tmp>onstat - 
 
Informix Dynamic Server Version 9.30.TC2     -- Fast Recovery (CKPT REQ) -- Up 0 
0:11:50 -- 25472 Kbytes 
Blocked:CKPT 
 
C:\tmp>onstat - 
 
Informix Dynamic Server Version 9.30.TC2     -- Quiescent -- Up 00:11:53 -- 2547 
2 Kbytes 
 
C:\tmp>onmode -m 
 
C:\tmp>onstat - 
 
Informix Dynamic Server Version 9.30.TC2     -- On-Line -- Up 00:12:10 -- 25472 
Kbytes 
 
C:\tmp>onstat -l 
 
Informix Dynamic Server Version 9.30.TC2     -- On-Line -- Up 00:20:05 -- 25472 
Kbytes 
 
Physical Logging 
Buffer bufused  bufsize  numpages numwrits pages/io 
  P-1  0        8        0        0        0.00 
      phybegin physize  phypos   phyused  %used 
      100107   500      141      0        0.00 
 
Logical Logging 
Buffer bufused  bufsize  numrecs  numpages numwrits recs/pages pages/io 
  L-2  0        8        1        1        1        1.0        1.0 
        Subsystem    numrecs  Log Space used 
        OLDRSAM      1        32 
 
address  number   flags    uniqid   begin        size     used    %used 
ca376a8  1        F------  0        1002fb        500        0     0.00 
ca376e0  2        U---C-L  32       1004ef        500      408    81.60 
ca37718  3        F------  0        1006e3        500        0     0.00 
ca37750  4        F------  0        1008d7        500        0     0.00 
ca37788  5        F------  0        100acb        500        0     0.00 
ca377c0  6        F------  0        100cbf        500        0     0.00 
 6 active, 6 total 
 
 
C:\tmp>dir log* 
 Том в устройстве C имеет метку MAIN 
 Серийный номер тома: D0A3-4245 
 
 Содержимое папки C:\tmp 
 
01.02.2005  14:50            16 384 log 
19.01.2005  13:22         2 097 152 log.31 
19.01.2005  14:01         1 736 704 log.32 
19.01.2005  14:18            65 536 log.33 
19.01.2005  14:21            65 536 log.34 
... 

Вот так все просто. Мы выполнили минимальное восстановление, только из архива уровня 0. В соответствии с представленной в прошлом выпуске таблицей:

это соответствует моменту времени t0. Сомневающиеся могут выполнить запрос select * from state и убедиться, что таблица state существует, но штата Украина в ней (пока) нет.

Обратите внимание на вопрос утилиты ontape о копировании журналов при восстановлении. Она пытается сохранить всю доступную информацию о транзакциях, ведь, как минимум, текущий на момент сбоя журнал наверняка не скопирован. У нас попытка копирования журналов закончилась сбоем (логические журналы, как это ни прискорбно, размещались в rootdbs, а с его первым чанком мы поступили жестоко... Теперь вы знаете еще одну причину, почему логические журналы имеет смысл выносить в отдельное DB-пространство и на отдельный диск.

Надеюсь, вы понимаете, что текущий журнал с идентификатором 32 отличается от того, копия которого хранится в файле log.32? Когда мы восстановили сервер, он начал работать с того же момента времени t0 заново, это та самая "реинкарнация". В журнале с идентификатором 32 теперь записано про успешное восстановление из архива и запуск сервера, но ничего не записано про добавление "штата Украина".

Кстати, в журнале сообщений Informix наш процесс восстановления отразился следующим образом:

 
14:53:06  Informix Dynamic Server Started. 
 
Tue Feb 01 14:53:07 2005 
 
14:53:07  Booting Language <c> from module <> 
14:53:07  Loading Module <CNULL> 
14:53:07  Booting Language <builtin> from module <> 
14:53:07  Loading Module <BUILTINNULL> 
14:53:12  Informix Dynamic Server Version 9.30.TC2     Software Serial Number AAC#J415297 
14:53:12  Informix Dynamic Server Initialized -- Shared Memory Initialized. 
 
14:53:12  Data replication type and state information reset. To start DR, use 
          the 'onmode -d' command and wait for the pair to be operational, 
          before shutting down the database server 
 
14:53:27  Dataskip is now OFF for all dbspaces 
14:53:27  Restartable Restore has been ENABLED 
14:53:27  Recovery Mode 
14:53:28  Physical Restore of rootdbs, blobdbs, sbspace, workdbs started. 
 
14:53:37  Checkpoint Completed:  duration was 1 seconds. 
14:53:37  Checkpoint loguniq 32, logpos 0x196850 
 
14:53:37  Maximum server connections 0  
14:53:37  Checkpoint Completed:  duration was 0 seconds. 
14:53:37  Checkpoint loguniq 32, logpos 0x196850 
 
14:53:37  Maximum server connections 0  
14:53:38  Checkpoint Completed:  duration was 0 seconds. 
14:53:38  Checkpoint loguniq 32, logpos 0x196850 
 
14:53:38  Maximum server connections 0  
14:53:49  Checkpoint Completed:  duration was 0 seconds. 
14:53:49  Checkpoint loguniq 32, logpos 0x196850 
 
14:53:49  Maximum server connections 0  
14:53:49  Physical Restore of rootdbs, blobdbs, sbspace, workdbs Completed. 
14:53:49  Checkpoint Completed:  duration was 0 seconds. 
14:53:49  Checkpoint loguniq 32, logpos 0x196850 
 
14:53:49  Maximum server connections 0  
15:04:52  No logical log restore will be performed. 
15:04:52  Preparing Physical Log for Fast Recovery ... 
15:04:52  Clearing the physical and logical logs has started 
15:04:53  Cleared 12 MB of the physical and logical logs in 0 seconds 
15:04:53  Dropping temporary TBLspace 0x300026, recovering 28 pages. 
15:04:53  Physical Recovery Started at Page(1:404). 
15:04:53  Physical Recovery Complete: 0 Pages Examined 0 Pages Restored. 
 
15:04:53  Logical Recovery Started. 
15:04:53  10 recovery worker threads will be started. 
15:04:53  Dynamically allocated new virtual shared memory segment (size 8192KB) 
15:04:54  Checkpoint Completed:  duration was 0 seconds. 
15:04:54  Checkpoint loguniq 32, logpos 0x196850 
 
15:04:54  Maximum server connections 0  
15:04:56  Logical Recovery has reached the transaction cleanup phase. 
15:04:56  Logical Recovery Complete. 
   0 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks 
 
15:04:57  Bringing system to Quiescent Mode with no Logical Restore. 
 
15:04:58  Quiescent Mode 
15:04:58  Checkpoint Completed:  duration was 0 seconds. 
15:04:58  Checkpoint loguniq 32, logpos 0x197018 
 
15:04:58  Maximum server connections 0  
15:05:15  On-Line Mode 

2. Восстановление из инкрементного архива

Восстановление состояния сервера на момент времени t1 можно выполнить двумя способами: восстановление из архива уровня 0 и затем логическое восстановление по журналам или восстановление из архива уровня 0 и инкрементного архива уровня 1. Вот это способ мы и рассмотрим. Я приведу только те детали, которые отличают рассматриваемую процедуру восстановления от предыдущей:

 
C:\tmp>onmode -ky 
 
C:\tmp>onstat - 
shared memory not initialized for INFORMIXSERVER 'ol_creator' 
 
C:\tmp>ontape -r 
... 
 
Continue restore? (y/n)y 
Do you want to back up the logs? (y/n)y 
 
Please mount tape 1 on c:\tmp\log and press Return to continue ... 
Would you like to back up log 32? (y/n) y 
 
Please label this tape as number 1 in the log tape sequence. 
 
This tape contains the following logical logs: 
    32 
Log salvage is complete, continuing restore of archive. 
Restore a level 1 archive (y/n) y 
Ready for level 1 tape 
 
Please mount tape 1 on c:\tmp\archive and press Return to continue ... 

Тем временем, в другом окне командной строки мы сохраняем копию журнала 32 из новой "реинкарнации" (это был пример успешного выполнения log salvage, поскольку не заполненный и не скопированный журнал доступен) и, когда нас попросили вставить ленточку с архивом уровня 1 (но не раньше), копируем соответствующий файл в TAPEDEV:

 
C:\Informix>cd c:\tmp 
 
C:\tmp>rename log log.32.salvaged 
 
C:\tmp>copy nul log 
Скопировано файлов:         1. 
 
C:\tmp>copy /y archive.1 archive 
Скопировано файлов:         1. 

и нажимаем в первом окне Enter. Получаем:

 
Archive Tape Information 
 
Tape type:      Archive Backup Tape 
Online version: Informix Dynamic Server Version 9.30.TC2 
Archive date:   Wed Jan 19 14:13:11 2005 
User id:        openxs 
Terminal id:    CREATOR 
Archive level:  1 
Tape device:    c:\tmp\archive 
Tape blocksize (in k): 16 
Tape size (in k): 100000 
Tape number in series: 1 
Restore a level 2 archive (y/n) n 
Do you want to restore log tapes? (y/n)n 
 
Program over. 
 
C:\tmp>onstat - 
 
Informix Dynamic Server Version 9.30.TC2     -- Quiescent -- Up 00:05:20 -- 2547 
2 Kbytes 
 
C:\tmp>onmode -m 
 
C:\tmp>onstat - 
 
Informix Dynamic Server Version 9.30.TC2     -- On-Line -- Up 00:05:27 -- 25472 
Kbytes 

Инкрементного архива уровня 2 у нас нет, а восстановление по копиям журналов мы снова решили не выполнять.

Можно проверить, что это действительно состояние на момент времени t1, выполнив запрос select * from state where code = 'UA'.

3. Восстановление до момента сбоя

В большинстве случаев реального сбоя одного из DB-пространств сервер надо восстановить как можно ближе к моменту сбоя. Вот и мы давайте восстановим сервер на момент времени t2 (состояние t3 нельзя восстановить, так как логический журнал с идентификатором 35 был безнадежно утрачен вместе с rootdbs)

Выполненная перед этим успешная попытка восстановления на момент времени t1, в сочетании с недостатками использованного alarm.bat, нам, правда, немного помешают. Обратите внимание:

 
C:\tmp>dir log* 
 Том в устройстве C имеет метку MAIN 
 Серийный номер тома: D0A3-4245 
 
 Содержимое папки C:\tmp 
 
19.01.2005  14:21            65 536 log 
19.01.2005  13:22         2 097 152 log.31 
01.02.2005  16:19            32 768 log.32 
01.02.2005  16:08         1 720 320 log.32.salvaged 
19.01.2005  14:18            65 536 log.33 
19.01.2005  14:21            65 536 log.34 

Копия журнала 32 переписана - у нее сегодняшняя дата. Правда, есть копия, которую мы сделали перед попыткой восстановления... Допустим, никто не обратил на это внимание и снова выключил сервер для восстановления, "вставив ленту" с архивом уровня 0:

 
C:\tmp>onmode -ky 
 
C:\tmp>copy /y archive.0 archive 
Скопировано файлов:         1. 
 
C:\tmp>ontape -r 
... 
Continue restore? (y/n)y 
Do you want to back up the logs? (y/n)n 
Restore a level 1 archive (y/n) n 

Для разнообразия, давайте восстановимся после архива уровня 0 только по журналам:

 
Do you want to restore log tapes? (y/n)y 
 
Roll forward should start with log number 32 
 
Please mount tape 1 on c:\tmp\log and press Return to continue ... 

В соседнем окне, не долго думая, "вставляем ленту" с журналом 32, и жмем Enter в первом окне:

 
C:\tmp>copy /y log.32 log 
Скопировано файлов:         1. 

Но что это за сообщение?

 
Unexpected end of log tape (errno 0), continuing... 

Ага! Мы же (ПО ОШИБКЕ!) скопировали сегодняшнюю копию журнала 32. Но у нас есть сохраненная:

 
C:\tmp>copy /y log.32.salvaged log 
Скопировано файлов:         1. 

И пробуем снова:

 
Do you want to restore another log tape? (y/n)y 
 
Please mount tape 2 on c:\tmp\log and press Return to continue ... 

Вроде прошло:

 
Do you want to restore another log tape? (y/n)y 
 
Please mount tape 3 on c:\tmp\log and press Return to continue ... 

В другом окне:

 
C:\tmp>copy /y log.33 log 
Скопировано файлов:         1. 

Продолжаем дальше:

 
Do you want to restore another log tape? (y/n)y 
Please mount tape 4 on c:\tmp\log and press Return to continue ... 

В другом окне:

 
C:\tmp>copy /y log.34 log 
Скопировано файлов:         1. 

Больше копий у нас нет:

 
Do you want to restore another log tape? (y/n)n 
 
Program over. 
 
C:\tmp>onstat - 
 
Informix Dynamic Server Version 9.30.TC2     -- Quiescent -- Up 00:03:34 -- 3366 
4 Kbytes 
 
C:\tmp>onmode -m 
 
C:\tmp>onstat -l 
 
Informix Dynamic Server Version 9.30.TC2     -- On-Line -- Up 00:03:47 -- 33664 
Kbytes 
 
Physical Logging 
Buffer bufused  bufsize  numpages numwrits pages/io 
  P-1  0        8        1        1        1.00 
      phybegin physize  phypos   phyused  %used 
      100107   500      142      0        0.00 
 
Logical Logging 
Buffer bufused  bufsize  numrecs  numpages numwrits recs/pages pages/io 
  L-2  0        8        0        0        0        0.0        0.0 
        Subsystem    numrecs  Log Space used 
 
address  number   flags    uniqid   begin        size     used    %used 
ca376a8  1        F------  0        1002fb        500        0     0.00 
ca376e0  2        U-B----  32       1004ef        500      410    82.00 
ca37718  3        U-B----  33       1006e3        500        4     0.80 
ca37750  4        U-B----  34       1008d7        500        5     1.00 
ca37788  5        U---C-L  35       100acb        500        1     0.20 
ca377c0  6        F------  0        100cbf        500        0     0.00 
 6 active, 6 total 

Отлично, не правда ли? Но что ЭТО????

 
C:\tmp>onstat -d 
 
Informix Dynamic Server Version 9.30.TC2     -- On-Line -- Up 00:09:12 -- 33664 
Kbytes 
 
Dbspaces 
address  number   flags      fchunk   nchunks  flags    owner    name 
c9e27d0  1        0x1        1        1        N        informix rootdbs 
ca37c30  2        0x8001     2        1        N S      informix sbspace 
ca37d78  3        0x5        3        1        ND       informix workdbs 
ca37ec0  4        0x11       4        1        N B      informix blobdbs 
 4 active, 2047 maximum 
 
Note: For BLOB chunks, the number of free pages shown is out of date. 
      Run 'onstat -d update' for current stats. 
 
Chunks 
address  chk/dbs offset   size     free     bpages   flags pathname 
c9e2918  1   1   0        12800    5413              PO-   C:\IFMXDATA\ol_creato 
r\rootdbs_dat.000 
ca377f8  2   2   0        12500    11005    11605    POS   c:\IFMXDATA\ol_creato 
r\sbspace_dat.000 
                 Metadata 842      544      842 
ca37960  3   3   0        25000    0                 PD-   c:\IFMXDATA\ol_creato 
r\workdbs_dat.000 
ca37ac8  4   4   0        2500    ~2500     2500     POB   c:\IFMXDATA\ol_creato 
r\blobdbs_dat.000 
 4 active, 2047 maximum 

Пространство workdbs, в котором находится наша демонстрационная база, недоступно! Не удивительно - сохраненная копия журнала 32 и та, которую надо было подложить, немного, но отличаются. Сервер не смог согласовать данные, о чем и написал в журнал сообщений:

 
16:27:28  Physical Restore of rootdbs, blobdbs, sbspace, workdbs started. 
 
16:27:30  Checkpoint Completed:  duration was 0 seconds. 
16:27:30  Checkpoint loguniq 32, logpos 0x196850 
 
16:27:30  Maximum server connections 0  
16:27:30  Checkpoint Completed:  duration was 0 seconds. 
16:27:30  Checkpoint loguniq 32, logpos 0x196850 
 
16:27:30  Maximum server connections 0  
16:27:31  Checkpoint Completed:  duration was 0 seconds. 
16:27:31  Checkpoint loguniq 32, logpos 0x196850 
 
16:27:31  Maximum server connections 0  
16:27:31  Checkpoint Completed:  duration was 0 seconds. 
16:27:31  Checkpoint loguniq 32, logpos 0x196850 
 
16:27:31  Maximum server connections 0  
16:27:31  Physical Restore of rootdbs, blobdbs, sbspace, workdbs Completed. 
16:27:31  Checkpoint Completed:  duration was 0 seconds. 
16:27:31  Checkpoint loguniq 32, logpos 0x196850 
 
16:27:31  Maximum server connections 0  
16:27:57  Logical Recovery Started. 
16:27:57  10 recovery worker threads will be started. 
16:27:57  Dynamically allocated new virtual shared memory segment (size 8192KB) 
16:27:57  Dynamically allocated new virtual shared memory segment (size 8192KB) 
16:27:57  Checkpoint Completed:  duration was 0 seconds. 
16:27:57  Checkpoint loguniq 32, logpos 0x196850 
 
16:27:57  Maximum server connections 0  
16:27:57  Start Logical Recovery - Start Log 32, End Log ? 
16:27:57  Starting Log Position - 32 0x196850 
16:27:57  Clearing the physical and logical logs has started 
16:27:58  Cleared 12 MB of the physical and logical logs in 1 seconds 
16:29:39  Checkpoint Completed:  duration was 0 seconds. 
16:29:39  Checkpoint loguniq 32, logpos 0x197018 
 
16:29:39  Maximum server connections 0  
16:29:39  Checkpoint Completed:  duration was 0 seconds. 
16:29:39  Checkpoint loguniq 32, logpos 0x198018 
 
16:29:39  Maximum server connections 0  
16:30:00  Checkpoint Completed:  duration was 0 seconds. 
16:30:00  Checkpoint loguniq 33, logpos 0x1044 
 
16:30:00  Maximum server connections 0  
16:30:00  Rollforward of log record failed. iserrno = 0 
16:30:00  Log Record: log = 33, pos = 0x21b4, type = OLDRSAM:CHALLOC(51), trans = 8 
16:30:00  Rollforward of log record failed. iserrno = 0 
16:30:00  Log Record: log = 33, pos = 0x2040, type = OLDRSAM:BLDCL(32), trans = 8 
16:30:01  Ignoring the ONDBSPACEDOWN option during logical recovery. Dynamic Server 
will NOT BLOCK at the next checkpoint 
16:30:01  Assert Failed: Chunk 3 is being taken OFFLINE. 
16:30:01  Informix Dynamic Server Version 9.30.TC2     
16:30:01   Who: Session(11, informix@creator, 0, 0) 
  Thread(32, xchg_2.0, 0, 1) 
  File: rsmirror.c Line: 1855 
16:30:01   Results: DBspace workdbs is disabled. 
16:30:01   Action: Restore DBspace workdbs 
16:30:01  stack trace for pid 1036 written to C:\tmp\af.4089268 
16:30:01   See Also: C:\tmp\af.4089268 
16:30:03  Releasing server from system block 
16:30:14  Chunk 3 is being taken OFFLINE. 
16:30:14  Chunk 3 is being taken OFFLINE. 
16:30:14  Rollforward of log record failed. iserrno = 172 
16:30:14  Log Record: log = 33, pos = 0x21b4, type = OLDRSAM:CHALLOC(51), trans = 8 
16:30:14  Ignoring the ONDBSPACEDOWN option during logical recovery. Dynamic Server 
will NOT BLOCK at the next checkpoint 
16:30:14  Assert Failed: Chunk 3 is being taken OFFLINE. 
16:30:14  Informix Dynamic Server Version 9.30.TC2     
16:30:14   Who: Session(11, informix@creator, 0, 0) 
  Thread(28, xchg_1.6, 0, 1) 
  File: rsmirror.c Line: 1855 
16:30:15   Results: DBspace workdbs is disabled. 
16:30:15   Action: Restore DBspace workdbs 
16:30:15  stack trace for pid 1036 written to C:\tmp\af.4049268 
16:30:15   See Also: C:\tmp\af.4049268 
16:30:28  Chunk 3 is being taken OFFLINE. 
16:30:28  Chunk 3 is being taken OFFLINE. 
16:30:28  Rollforward of log record failed. iserrno = 172 
16:30:28  Log Record: log = 33, pos = 0x2040, type = OLDRSAM:BLDCL(32), trans = 8 
16:30:28  Checkpoint Completed:  duration was 0 seconds. 
16:30:28  Checkpoint loguniq 33, logpos 0x2850 
 
16:30:28  Maximum server connections 0  
16:30:29  Checkpoint Completed:  duration was 0 seconds. 
16:30:29  Checkpoint loguniq 34, logpos 0x1018 
 
16:30:29  Maximum server connections 0  
16:30:36  Logical Recovery has reached the transaction cleanup phase. 
16:30:36  Logical Recovery Complete. 
   11 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks 
 
16:30:36  Logical Recovery Complete. 
16:30:37  Quiescent Mode 
16:30:37  Logical Log 34 Complete. 
16:30:37  Checkpoint Completed:  duration was 0 seconds. 
16:30:37  Checkpoint loguniq 35, logpos 0x18 
 
16:30:37  Maximum server connections 0  
16:30:51  On-Line Mode 

Там же написано, что делать: восстанавливать чанк workdbs! У нас сервер в режиме On-Line, так что, давайте попрактикуемся в теплом (при работающем сервере) восстановлении отдельного пространства (архив уровня 0 у нас на месте):

 
C:\tmp>dir archive* 
 Том в устройстве C имеет метку MAIN 
 Серийный номер тома: D0A3-4245 
 
 Содержимое папки C:\tmp 
 
19.01.2005  13:51        17 842 176 archive 
19.01.2005  13:51        17 842 176 archive.0 
19.01.2005  14:13           262 144 archive.1 
... 
 
C:\tmp>ontape -r -D workdbs 
 
Please mount tape 1 on c:\tmp\archive and press Return to continue ... 
 
Archive Tape Information 
 
Tape type:      Archive Backup Tape 
Online version: Informix Dynamic Server Version 9.30.TC2 
Archive date:   Wed Jan 19 13:50:53 2005 
User id:        openxs 
Terminal id:    CREATOR 
Archive level:  0 
Tape device:    c:\tmp\archive 
Tape blocksize (in k): 16 
Tape size (in k): 100000 
Tape number in series: 1 
Continue restore? (y/n)y 
 
Spaces to restore:1 [workdbs 
                                                                     ] 
Restore a level 1 archive (y/n) y 
Ready for level 1 tape 
 
Please mount tape 1 on c:\tmp\archive and press Return to continue ... 

В соседнем окне выполняем:

 
C:\tmp>copy /y archive.1 archive 
Скопировано файлов:         1. 

Потом жмем на Enter в окне, из которого выполнена команда ontape, и получаем:

 
Archive Tape Information 
 
Tape type:      Archive Backup Tape 
Online version: Informix Dynamic Server Version 9.30.TC2 
Archive date:   Wed Jan 19 14:13:11 2005 
User id:        openxs 
Terminal id:    CREATOR 
Archive level:  1 
Tape device:    c:\tmp\archive 
Tape blocksize (in k): 16 
Tape size (in k): 100000 
Tape number in series: 1 

Так и только ТАК! Подходящей копии журнала 32 у нас нет (мы только что убедились в этом, поэтому используем инкрементный архив (к сачстью, он есть!), чтобы восстанволение по журналам начать с нормальной копии журнала 33. Продолжаем:

 
Restore a level 2 archive (y/n) n 
Do you want to restore log tapes? (y/n)y 
 
Roll forward should start with log number 33 
 
Please mount tape 1 on c:\tmp\log and press Return to continue ... 

В соседнем окне подкладываем копию журнала 33 и жмем Enter в окне восстановления:

 
C:\tmp>copy /y log.33 log 
Скопировано файлов:         1. 

Мы же хотим восстановить как можно ближе к моменту сбоя? Вот и продолжаем дальше:

 
Do you want to restore another log tape? (y/n)y 
 
Please mount tape 2 on c:\tmp\log and press Return to continue ... 

В соседнем окне подкладываем копию журнала 34 и жмем Enter в окне восстановления:

 
C:\tmp>copy /y log.34 log 
Скопировано файлов:         1. 

И завершаем процесс восстановления:

 
Do you want to restore another log tape? (y/n)n 
 
Program over. 
 
C:\tmp>onstat - 
 
Informix Dynamic Server Version 9.30.TC2     -- On-Line -- Up 00:15:31 -- 33664 
Kbytes 
 
 
C:\tmp>onstat -d 
 
Informix Dynamic Server Version 9.30.TC2     -- On-Line -- Up 00:15:34 -- 33664 
Kbytes 
 
Dbspaces 
address  number   flags      fchunk   nchunks  flags    owner    name 
c9e27d0  1        0x1        1        1        N        informix rootdbs 
ca37c30  2        0x8001     2        1        N S      informix sbspace 
ca37d78  3        0x1        3        1        N        informix workdbs 
ca37ec0  4        0x11       4        1        N B      informix blobdbs 
 4 active, 2047 maximum 
 
Note: For BLOB chunks, the number of free pages shown is out of date. 
      Run 'onstat -d update' for current stats. 
 
Chunks 
address  chk/dbs offset   size     free     bpages   flags pathname 
c9e2918  1   1   0        12800    5413              PO-   C:\IFMXDATA\ol_creato 
r\rootdbs_dat.000 
ca377f8  2   2   0        12500    11005    11605    POS   c:\IFMXDATA\ol_creato 
r\sbspace_dat.000 
                 Metadata 842      544      842 
ca37960  3   3   0        25000    24247             PO-   c:\IFMXDATA\ol_creato 
r\workdbs_dat.000 
ca37ac8  4   4   0        2500    ~2500     2500     POB   c:\IFMXDATA\ol_creato 
r\blobdbs_dat.000 
 4 active, 2047 maximum 

Те, кто не верит в свое счастье, могут проверить, что таблицы state нет. Это и есть момент времени t2!

Итоги

Мы рассмотрели несколько различных процедур восстановления сервера при наличии необходимых архивов и резервных копий журналов, созданных с помощью ontape. Было показано, как восстановить данные на любой из описанных в предыдущем выпуске моментов времени, t0, t1 и t2, при условии, что разрушены были только некоторые чанки Informix.

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

Мы также увидели явное ограничение утилиты ontape - восстановить сервер можно "с точностью" до одного логического журнала. Журнал либо восстанавливается полностью, либо не восстанавливается вообще. Вот почему на производственных серверах размер одного журнала редко превосходит пару мегабайт. Чем меньше журнал, тем меньше изменений будет потеряно в случае сбоя и тем "ближе" к требуемому моменту времени можно будет выполнить восстановление!

Документация:

1.Informix Backup and Restore Guide, Version 8.31/9.3 (G251-0481-00).

Архив рассылки

Все вышедшие выпуски рассылки можно найти на сайте рассылки. Там же реализована возможность поиска материалов по ключевым словам (с помощью Google)

В следующем выпуске

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

С наилучшими пожеланиями,

  В.К.