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

Выпуск 7

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

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

В 2005 году я собираюсь сделать выпуски рассылки более регулярными, скажем, выпускать очередную статью раз в две недели. Тематика уже была предварительно обозначена в самом первом выпуске. Но, поскольку многие из вас могли его и не читать, хочу повторить заданный в нем вопрос:

Что вы хотите узнать о СУБД Informix в 2005 году?

Впрочем, хочу задать и еще пару вопросов:

Как вы относитесь к проведению в городе Киеве регулярных (раз в две недели, например) бесплатных (или платных, но недорого) семинаров по администрированию и использованию СУБД Informix? Нужны ли вам такие семинары? Какой должна быть их тематика?

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

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

Резервное копирование на диск с помощью ontape

Теоретически, все просто. Есть утилита ontape, поддерживающая следующие опции:

 
C:\Informix>ontape -- 
недопустимый аргумент 
ontape 
использование: 
{ -a  | 
  -c  | 
  -l  | 
  -p  | 
  -r  [-D список_DB-пространств] | 
  -s  [-L уровень_архива] [-A список_баз_данных] [-B список_баз_данных] 
      [-N список_баз_данных] [-U список_баз_данных]  } 
 
-a Автоматическое резервное копирование логических журналов 
-c Непрерывное резервное копирование логических журналов 
-l Логическое восстановление 
-p Физическое восстановление для HDR 
-r Полное восстановление перечисленных DB-пространств/BLOB-пространств 
-s Архивирование системы в целом 
-A установить для следующих баз данных режим журнализации ANSI 
-B установить для следующих баз данных режим буферизованной журнализации 
-N отключить журнализацию для следующих баз данных 
-U установить для следующих баз данных режим небуферизованной журнализации 
 
 
Program over. 
 
(Я позволил себе перевести выдаваемую утилитой справочную информацию 
на русский - на английском вы ее и так получите.) 

Работает утилита ontape с устройствами, которые задаются следующими параметрами конфигурации (цитата из файла ONCONFIG, с переведенными комментариями):

 
# Ленточное устройство для архивирования системы 
 
TAPEDEV  \\.\TAPE0 # Полное имя файла устройства  
TAPEBLK  16  # Размер блока ленты (Кбайт) 
TAPESIZE 10240  # Максимальный объем данных на ленте (Кбайт) 
 
# Ленточное устройство для архивирования журналов 
 
LTAPEDEV NUL  # Полное имя файла устройства для журналов 
LTAPEBLK 16  # Размер блока ленты для журналов (Кбайт) 
LTAPESIZE 10240  # Максимальный объем данных на ленте для журналов (Кбайт) 

Представлены значения параметров по умолчанию - именно такими они и будут в рассматриваемой версии после установки сервера, пока вы их не измените (см. также файл %INFORMIXDIR%\etc\onconfig.std).

Так вот, архивирование сервера в целом (резервное копирование пространств) выполняется командой ontape -s и ведется на устройство TAPEDEV. При этом в один том архива записывается не более TAPESIZE килобайт. Потом надо "менять ленту". Запись идет блоками по TAPEBLK килобайт, что важно при работе с лентой (надо прочитать в документации, какого размера блоки предлагает использовать производитель - так, наиболее популярные сейчас ленты DDS-4 обычно предполагают размер блока 64 Кбайта). При работе с диском, что мы и предполагаем делать, этот параметр может, наверное, влиять на производительность, но соответствующих экспериментов я пока не делал и никогда стандартное значение не менял.

Про эффективное автоматическое многотомное архивирование на диск мы еще поговорим в отдельном выпуске рассылки, а пока же нам желательно задать параметр TAPESIZE таким, чтобы весь архив вмещался в один том. К счастью, на нашей версии и платформе, неприемлемых жестких ограничений на размер создаваемого утилитой ontape файла уже нет (Раньше было ограничение - не более 2 Гбайт. Теперь же все зависит от файловой системы, в которой будет создаваться том.). Можно задать любое значение, с запасом. Тем не менее, не мешает определить это значение поточнее. (Напомню, что в архив уровня 0 попадают все непустые страницы всех DB-пространств, кроме временных.) Можно, конечно, просто просуммировать размер всех чанков, кроме чанков временных DB-пространств, но можно получить более точную оценку сверху: просуммировать размеры всех выделенных экстентов. Это можно сделать следующим простым запросом (у нас размер страницы - 4 Кбайта):

 
select sum(size)*4 from sysmaster:sysextents 

 
C:\Informix>onstat -d 
 
Informix Dynamic Server Version 9.30.TC2     -- On-Line -- Up 04:13:22 -- 25472 
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    4546              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    24947             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 

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

С точным определением размером тома для копии журналов (LTAPEDEV) при такой постановке задачи возникает один нюанс. (Кстати, если вы зададите слишком маленькое значение, ничего страшного не произойдет. Будет создаваться многотомная копия, и вас попросят "вставить ленточку". Но зачем нам лишние заботы?) Он связан с использованием в таблицах столбцов типа TEXT и BYTE, размещенных в BLOB-пространствах (у меня одно такое пространство есть, blobdbs, как видно по представленным выше результатам выполнения команды onstat -d). Напомню, что если такие столбцы меняются, сами изменения не записываются в логические журналы. Записывается только информация об изменениях на страницах битовых карт пространства. Но, как уже упоминалось в предыдущем выпуске, при резервном копировании журнала сервер анализирует все большие объекты в BLOB-пространствах, и те из них, изменения в которых произошли по ходу транзакций, зарегистрированных в этом журнале, помещает в копию журналов перед содержимым самого журнала. Итак, в этом размер копии одного журнала может намного превосходить размер самого журнала!

Поэтому в качестве LTAPESIZE я рекомендую, по возможности, устанавливать значение, равное сумме размера самого большого журнала и размеров всех чанков BLOB-пространств. Иначе копия одного журнала может потребовать нескольких томов. В моем случае, с учетом максимального размера журнала (500 страниц или 2000 Кбайт) и размера единственного чанка blobdbs (2500 страниц или 10000 Кбайт):

 
C:\Informix>onstat -l 
 
Informix Dynamic Server Version 9.30.TC2     -- On-Line -- Up 04:38:48 -- 25472 
Kbytes 
 
Physical Logging 
Buffer bufused  bufsize  numpages numwrits pages/io 
  P-2  0        8        9        2        4.50 
      phybegin physize  phypos   phyused  %used 
      100107   500      377      0        0.00 
 
Logical Logging 
Buffer bufused  bufsize  numrecs  numpages numwrits recs/pages pages/io 
  L-2  0        8        156      6        4        26.0       1.5 
        Subsystem    numrecs  Log Space used 
        OLDRSAM      156      11452 
 
address  number   flags    uniqid   begin        size     used    %used 
ca376a8  1        U---C-L  31       1002fb        500       99    19.80 
ca376e0  2        U-B----  26       1004ef        500       12     2.40 
ca37718  3        U-B----  27       1006e3        500      154    30.80 
ca37750  4        U-B----  28       1008d7        500        4     0.80 
ca37788  5        U-B----  29       100acb        500       42     8.40 
ca377c0  6        U-B----  30       100cbf        500        7     1.40 
 6 active, 6 total 

получается, что параметр LTAPESIZE должен иметь значение не менее 12000.

Автоматизация резервного копирования журналов

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

Интереснее другое - как обеспечить это самое "регулярное, по мере заполнения" копирование логических журналов и совместить его с требованием размещать копию каждого журнала в отдельном файле на диске?

Для этого нам придется использовать механизм автоматического вызова заданной администратором программы при наступлении одного из предопределенных событий по ходу работы сервера Informix. Этому механизму, прекрасно описанному в документации, можно будет посвятить отдельный выпуск рассылки, а здесь нам достаточно будет знать, что соответствующий выполняемый (например, .bat на нашей платформе Windows) файл надо просто указать в качестве значения параметра конфигурации ALARMPROGRAM. Эта программа, ALARMPROGRAM, будет затем вызываться сервером автоматически, с передачей пяти параметров, описывающих особенности произошедшего события.

Нас будет интересовать второй параметр, числовой, класс события, и третий, строчный, сообщение класса. После завершения записи информации транзакций в логический журнал происходит событие класса 23, и вызывается указанная программа ALARMPROGRAM, которой в качестве третьего параметра командной строки передается текст вида:

 
Logical Log 8 Complete. 

Третьим его словом является число - uniqid логического журнала, с которым сервер только что завершил работу.

В качестве ALARMPROGRAM я использую сценарий командного интерпретатора, который на платформе Windows оформляется в виде командного (.bat) файла, созданного на основе "стандартной" программы обработки событий %INFORMIXDIR%\etc\log_full.bat. Обычно на платформе Windows я называю его alarm.bat и размещаю вместе с другими служебными .bat-файлами в подкаталоге BAT пакета DBA_Tools. (DBA_Tools - инструментарий системного администратора и АБД для Informix на платформе Windows, созданный широко известным специалистом по Informix Василием Шульженко. Он очень популярен среди начинающих и опытных администраторов Informix на платформе Windows, которым нравится программа Far...)

Итак, файл этот может иметь следующий вид:

 
@echo off 
 
set DBA=c:\DBA_Tools 
set WINROOT=%SystemRoot% 
if "x%WINROOT%" == "x" set WINROOT=C:\WINNT 
 
set BACKUP_DIR=c:\tmp 
set BACKUP_LOG_FILE=log 
 
set EXIT_STATUS=0 
set ALARM_LOG=c:\tmp\alarm.log 
 
set EVENT_SEVERITY=%1% 
set EVENT_CLASS=%2% 
set EVENT_MSG=%3% 
set EVENT_ADD_TEXT="%4%" 
set EVENT_FILE="%5%" 
 
 
date /t >> %ALARM_LOG% 
time /t >> %ALARM_LOG% 
echo %EVENT_SEVERITY% >> %ALARM_LOG% 
echo %EVENT_CLASS% >> %ALARM_LOG% 
echo %EVENT_MSG% >> %ALARM_LOG% 
echo %EVENT_ADD_TEXT% >> %ALARM_LOG% 
 
if %EVENT_CLASS% == 23 goto CONT_LOG 
 
set EXIT_STATUS=1 
goto DONE 
 
:CONT_LOG 
for /F "usebackq tokens=3 DELIMS== " %%i in (`echo %EVENT_MSG%`) DO @set LOG=%%i 
echo "%LOG%" >> %ALARM_LOG% 
 
ontape -a < %DBA%\bat\Enter_no 2>&1 >> %ALARM_LOG% 
 
REM # 0 означает, что ontape сработала успешно 
if ERRORLEVEL 1 goto ERROR 
if ERRORLEVEL 0 goto SUCCESS 
goto DONE 
 
:ERROR 
set EXIT_STATUS=1 
goto DONE 
 
:SUCCESS 
set EXIT_STATUS=0 
copy %BACKUP_DIR%\%BACKUP_LOG_FILE% %BACKUP_DIR%\%BACKUP_LOG_FILE%.%LOG% 
copy nul %BACKUP_DIR%\%BACKUP_LOG_FILE% 
 
:DONE 
exit %EXIT_STATUS% 

На вид он достаточно большой, но устроен предельно просто. После проверки и установки ряда переменных среды, мы выдаем в собственный журнал уведомлений (местонахождение которого задается переменной среды ALARM_LOG) дату и время возникновения события и все параметры, переданные нашему .bat-файлу в командной строке сервером Informix. Эта информация пригодится в дальнейшем, если вы захотите расширить возможности alarm.bat и обрабатывать события других классов, не связанные с заполнением логических журналов.

Далее, если произошло событие класса 23, мы в "хитрой" строке, начинающейся командой for, выбираем третье слово из третьего аргумента командной строки alarm.bat и помещаем его в переменную среды LOG. Я не большой специалист по командам DOS и Windows, да и рассылка наша не им посвящена, поэтому заинтересовавшихся, почему и как эта команда делает именно то, что я написал, я отошлю к документации. Выполните в любом окне командной строки Windows:

 
help for 

и прочитайте, какими широкими возможностями, при столь странном синтаксисе, обладает эта команда. Эта (большая по объему) информация вам пригодится в будущем!

Итак, получив и запомнив uniqid последнего заполненного логического журнала, мы выполняем команду ontape -a в "автоматическом" режиме, направляя заранее подготовленные в файле Enter_no "ответы" на задаваемые ею вопросы. Что это за вопросы? Если выполнить команду ontape -a непосредственно, задав параметру конфигурации LTAPEDEV значение, отличающееся от NUL, мы увидим примерно следующее:

 
C:\Informix>ontape -a 
 
Performing automatic backup of logical logs. 
 
Please mount tape 1 on c:\tmp\log and press Return to continue ... 
 
 
Do you want to back up the current logical log? (y/n) n 
 
Please label this tape as number 1 in the log tape sequence. 
 
This tape contains the following logical logs: 
    31 (partial) 
 
Program over. 

Итак, сначала нам предлагают "вставить ленту" и нажать клавишу Enter. После того, как мы это сделаем, задается вопрос о необходимости копирования текущего логического журнала. В нашем случае этого делать не нужно (нам нужна копия предыдущего, заполненного журнала), поэтому мы вводим n и нажимаем клавишу Enter.

Именно эти нажатия клавиш и надо выполнить в пустом изначально файле, который мы назвали Enter_no. В нем (на платформе Windows) должно оказаться 5 байтов, которые в шестнадцатеричном виде имеют следующие значения:

 
00000000:  0D 0A 6E 0D 0A 

Продолжим рассмотрение сценария alarm.bat. Если команда ontape -a выполнена успешно (тогда переменная среды ERRORLEVEL сразу после ее выполнения будет иметь значение 0), нам осталось скопировать или перенести "ленту", файл %BACKUP_DIR%\%BACKUP_LOG_FILE%, куда-нибудь и "вставить новую ленту", т.е. создать пустой файл %BACKUP_DIR%\%BACKUP_LOG_FILE%. Именно это и делают две последние команды copy. Обратите внимание, что мы в этом сценарии копируем "ленту" с журналом в файл в том же каталоге, с тем же именем, но с расширением .%LOG%, которое соответствует числовому значению uniqid для логического журнала, заполнение которого и вызвало срабатывание файла alarm.bat.

Примечание

Разумеется, вы можете (и, пожалуй, должны) копировать этот файл в другой каталог, на другой диск, на другую машину по сети, или сразу же дописывать на CDROM или на ленту. Я представляю здесь лишь основные особенности возможного решения проблемы автоматического резервного копирования журналов на диск с помощью ontape. Детали вам надо будет продумать самостоятельно.

Обратите внимание, что данный сценарий alarm.bat предполагает выполнять резервное копирование журналов в файл log, находящийся в каталоге c:\tmp. Эти значения вам может потребоваться изменить, и их придется указать в дальнейшем, при установке параметров конфигурации Informix.

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

1. Создание файлов для TAPEDEV и LTAPEDEV

В окне командной строки переходим в каталог, в который мы решили поместить файлы-устройства для резервного копирования, и создаем пустые файлы:

 
C:\Informix>cd c:\tmp 
 
C:\tmp>copy nul archive 
 
C:\tmp>copy nul log 

Можете создать их и другим способом, но куда уж проще...

2. Изменение параметров конфигурации

Далее, поскольку нам придется изменить значения нескольких параметров, останавливаем сервер Informix:

 
C:\tmp^gt;onmode -ky 

Затем, с помощью любого текстового редактора устанавливаем соответствующие, определенные ранее значения следующих параметров конфигурации:

 
ALARMPROGRAM c:\DBA_Tools\bat\alarm.bat # Было C:\Informix\etc\log_full.bat 
 
TAPEDEV  c:\tmp\archive  # Было \\.\TAPE0. Можно располагать и не в C:\tmp 
TAPESIZE 100000  # Было 10240 
 
LTAPEDEV c:\tmp\log      # Было NUL. Такое значение предполагает наш alarm.bat 
LTAPESIZE 10000  # Было 10240. Можно было и оставить... 

и снова запускаем сервер:

 
C:\tmp>starts ol_creator 
 
C:\tmp>onstat - 
 
Informix Dynamic Server Version 9.30.TC2     -- On-Line -- Up 00:00:28 -- 25472 
Kbytes 

3. Проверка полученного решения

Все готово для проверки настроенной "системы" резервного копирования. Чтобы в будущем можно было проверять различные варианты восстановления, мы пересоздадим демонстрационную базу demo_db:

 
dbaccessdemo -log demo_db -dbspace workdbs 

и зафиксируем текущее состояние (момент времени t0):

 
C:\tmp>onstat -l 
 
Informix Dynamic Server Version 9.30.TC2     -- On-Line -- Up 02:10:52 -- 25472 
Kbytes 
 
Physical Logging 
Buffer bufused  bufsize  numpages numwrits pages/io 
  P-1  3        8        259      33       7.85 
      phybegin physize  phypos   phyused  %used 
      100107   500      133      259      51.80 
 
Logical Logging 
Buffer bufused  bufsize  numrecs  numpages numwrits recs/pages pages/io 
  L-3  0        8        19916    804      356      24.8       2.3 
        Subsystem    numrecs  Log Space used 
        OLDRSAM      19916    2186496 
 
address  number   flags    uniqid   begin        size     used    %used 
ca376a8  1        U-B---L  31       1002fb        500      500   100.00 
ca376e0  2        U---C--  32       1004ef        500      404    80.80 
ca37718  3        U-B----  27       1006e3        500      154    30.80 
ca37750  4        U-B----  28       1008d7        500        4     0.80 
ca37788  5        U-B----  29       100acb        500       42     8.40 
ca377c0  6        U-B----  30       100cbf        500        7     1.40 
 6 active, 6 total 

Каждое из выполненных действий детально описано ниже.

Создание архива уровня 0

Итак, в момент времени t0 мы создаем архив нулевого уровня:

 
C:\tmp>ontape -s -L 0 
 
Please mount tape 1 on c:\tmp\archive and press Return to continue ... 
 
100 percent done. 
 
Please label this tape as number 1 in the arc tape sequence. 
This tape contains the following logical logs: 
 
 32 
 
Program over. 

В ответ на выделенную наклонным просьбу "вставить ленту" нажимаем клавишу Enter. Пока создается архив нулевого уровня, в отдельном окне изменяем стандартное состояние базы demo_db (по которому мы и будем "распознавать" в дальнейшем момент времени t0), добавляя, например, новую запись. В следующий момент времени, t1, база будет уже измененной.

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

 
C:\tmp>dir archive 
 Том в устройстве C имеет метку MAIN 
 Серийный номер тома: D0A3-4245 
 
 Содержимое папки C:\tmp 
 
19.01.2005  13:51        17 842 176 archive 
               1 файлов     17 842 176 байт 
               0 папок   2 348 716 032 байт свободно 

Надо скопировать полученный архив и "вставить новую ленту", выполнив команды:

 
C:\tmp>copy archive archive.0 
 
C:\tmp>copy nul archive 

Теперь перейдем на следующий журнал, зафиксировав момент времени t1:

 
C:\tmp>onmode -l 
 
C:\tmp>onstat -l 
 
Informix Dynamic Server Version 9.30.TC2     -- On-Line -- Up 02:49:18 -- 25472 
Kbytes 
 
Physical Logging 
Buffer bufused  bufsize  numpages numwrits pages/io 
  P-1  0        8        270      37       7.30 
      phybegin physize  phypos   phyused  %used 
      100107   500      147      0        0.00 
 
Logical Logging 
Buffer bufused  bufsize  numrecs  numpages numwrits recs/pages pages/io 
  L-2  0        8        19992    810      362      24.7       2.2 
        Subsystem    numrecs  Log Space used 
        OLDRSAM      19992    2193108 
 
address  number   flags    uniqid   begin        size     used    %used 
ca376a8  1        U-B----  31       1002fb        500      500   100.00 
ca376e0  2        U-B---L  32       1004ef        500      411    82.20 
ca37718  3        U---C--  33       1006e3        500        1     0.20 
ca37750  4        U-B----  28       1008d7        500        4     0.80 
ca37788  5        U-B----  29       100acb        500       42     8.40 
ca377c0  6        U-B----  30       100cbf        500        7     1.40 
 6 active, 6 total 

Создание инкрементного архива

Убеждаемся, что сделанное по ходу архивирования уровня 0 изменение есть (!), и, как и запланировано, создаем инкрементный архив. Он должен быть заметно меньше по размеру - мы ведь только вставили одну строку в таблицу state, записали успешное завершение архивирования уровня 0 и перешли на следующий журнал. Снова вызываем ontape:

 
C:\tmp<ontape -s -L 1 
 
Please mount tape 1 on c:\tmp\archive and press Return to continue ... 
100 percent done. 
 
Please label this tape as number 1 in the arc tape sequence. 
This tape contains the following logical logs: 
 
 33 
 
Program over. 

Проверим свое предположение в отношении размера архива, скопируем его и "вставим пустую ленту", как и раньше:

 
C:\tmp>dir archive 
 Том в устройстве C имеет метку MAIN 
 Серийный номер тома: D0A3-4245 
 
 Содержимое папки C:\tmp 
 
19.01.2005  14:13           262 144 archive 
               1 файлов        262 144 байт 
               0 папок   2 337 656 832 байт свободно 
 
C:\tmp>copy archive archive.1 
Скопировано файлов:         1. 
 
C:\tmp>copy nul archive 
Заменить archive [Yes (да)/No (нет)/All (все)]: y 
Скопировано файлов:         1. 

и перейдем на следующий журнал, соответствующий моменту времени t2:

 
C:\tmp>onmode -l 
 
C:\tmp>onstat -l 
 
Informix Dynamic Server Version 9.30.TC2     -- On-Line -- Up 03:05:54 -- 25472 
Kbytes 
 
Physical Logging 
Buffer bufused  bufsize  numpages numwrits pages/io 
  P-1  3        8        277      38       7.29 
      phybegin physize  phypos   phyused  %used 
      100107   500      151      3        0.60 
 
Logical Logging 
Buffer bufused  bufsize  numrecs  numpages numwrits recs/pages pages/io 
  L-3  0        8        20042    814      366      24.6       2.2 
        Subsystem    numrecs  Log Space used 
        OLDRSAM      20042    2195724 
 
address  number   flags    uniqid   begin        size     used    %used 
ca376a8  1        U-B----  31       1002fb        500      500   100.00 
ca376e0  2        U-B----  32       1004ef        500      411    82.20 
ca37718  3        U-B---L  33       1006e3        500        4     0.80 
ca37750  4        U---C--  34       1008d7        500        1     0.20 
ca37788  5        U-B----  29       100acb        500       42     8.40 
ca377c0  6        U-B----  30       100cbf        500        7     1.40 
 6 active, 6 total 

Дальнейшие изменения, защищенные только копиями журналов

Находясь в журнале 34, удаляем таблицу state (отсутствие Штатов станет характерным признаком момента времени t2) и переходим на следующий журнал, как и ранее. Выполненное изменение защищается только путем копирования журнала нашим сценарием alarm.bat, который автоматически вызывает сервер.

 
C:\tmp>onmode -l 
 
C:\tmp>onstat -l 
 
Informix Dynamic Server Version 9.30.TC2     -- On-Line -- Up 03:09:02 -- 25472 
Kbytes 
 
Physical Logging 
Buffer bufused  bufsize  numpages numwrits pages/io 
  P-2  3        8        304      42       7.24 
      phybegin physize  phypos   phyused  %used 
      100107   500      178      27       5.40 
 
Logical Logging 
Buffer bufused  bufsize  numrecs  numpages numwrits recs/pages pages/io 
  L-2  0        8        20080    819      371      24.5       2.2 
        Subsystem    numrecs  Log Space used 
        OLDRSAM      20080    2198528 
 
address  number   flags    uniqid   begin        size     used    %used 
ca376a8  1        U-B----  31       1002fb        500      500   100.00 
ca376e0  2        U-B----  32       1004ef        500      411    82.20 
ca37718  3        U-B----  33       1006e3        500        4     0.80 
ca37750  4        U-B---L  34       1008d7        500        5     1.00 
ca37788  5        U---C--  35       100acb        500        1     0.20 
ca377c0  6        U-B----  30       100cbf        500        7     1.40 
 6 active, 6 total 

Теперь, находясь в журнале 35, в момент времени t3 мы сымитируем сбой дискового компонента сервера. Для этого остановим сервер и почистим пару критически важных чанков (Как обычно говорят в телепрограммах типа "Кунсткамеры": "НЕ ПЫТАЙТЕСЬ ПОВТОРИТЬ ЭТО САМИ". Я имею в виду, на рабочем сервере и если не умеете восстанавливать его из резервной копии!):

 
C:\tmp>onmode -ky 
 
C:\tmp>copy nul c:\IFMXDATA\ol_creator\rootdbs_dat.000 
Заменить c:\IFMXDATA\ol_creator\rootdbs_dat.000 [Yes (да)/No (нет)/All (все)]: y 
 
Скопировано файлов:         1. 
 
C:\tmp>copy nul c:\IFMXDATA\ol_creator\workdbs_dat.000 
Заменить c:\IFMXDATA\ol_creator\workdbs_dat.000 [Yes (да)/No (нет)/All (все)]: y 
 
Скопировано файлов:         1. 
 
C:\tmp>dir c:\IFMXDATA\ol_creator 
 Том в устройстве C имеет метку MAIN 
 Серийный номер тома: D0A3-4245 
 
 Содержимое папки c:\IFMXDATA\ol_creator 
 
27.09.2004  15:29              . 
27.09.2004  15:29              .. 
19.01.2005  14:28        10 240 000 blobdbs_dat.000 
19.01.2005  14:29                 0 rootdbs_dat.000 
27.09.2004  18:14        51 200 000 sbspace_dat.000 
19.01.2005  14:29                 0 workdbs_dat.000 
               4 файлов     61 440 000 байт 
               2 папок   2 484 908 032 байт свободно 

Понятно, что в таком виде сервер не запустится. Давайте попробуем, и оставим его в таком состоянии до следующего выпуска рассылки:

 
C:\tmp>starts ol_creator 
 
C:\tmp>onstat - 
 
Informix Dynamic Server Version 9.30.TC2     -- Initialization -- Up 00:00:09 -- 
 17280 Kbytes 
 
C:\tmp>onstat - 
 
Informix Dynamic Server Version 9.30.TC2     -- Initialization -- Up 00:00:23 -- 
 17280 Kbytes 
 
C:\tmp>onstat -m 
shared memory not initialized for INFORMIXSERVER 'ol_creator' 
 
Message Log File: C:\PROGRA~1\Informix\ol_creator.log 
14:34:50  KAIO: error in kaio_READ, kaiocbp = 0xca4b77c, errno = 0 
14:35:05  fildes = 252 (gfd 3), buf = 0x0CC2B400, nbytes = 4096, offset = 8192 
14:35:05  Assert Failed: chunk failed sanity check 
 
14:35:05  Informix Dynamic Server Version 9.30.TC2 
14:35:05   Who: Session(1, informix@creator, 0, 0) 
                Thread(6, main_loop(), 0, 1) 
                File: rspartn.c Line: 7456 
14:35:05   Results: Chunk 1 is being taken OFFLINE. 
14:35:05   Action: Restore chunk from archive. 
14:35:05  stack trace for pid 3460 written to C:\tmp\af.3ee53f9 
14:35:06   See Also: C:\tmp\af.3ee53f9 
14:35:08  Releasing server from system block 
14:35:20  chunk failed sanity check 
 
14:35:20  chunk failed sanity check 
 
14:35:21  I/O error, Primary Chunk 'C:\IFMXDATA\ol_creator\rootdbs_dat.000' -- O 
ffline (sanity) 
14:35:21  Informix Dynamic Server Stopped. 
 
C:\tmp>onstat - 
shared memory not initialized for INFORMIXSERVER 'ol_creator' 

Сервер помучился секунд 30, но так и не смог запуститься. Оно и не удивительно - без первого чанка rootdbs серверы Informix работать не могут в любом случае... Что делать? Я выделил соответствующую запись, которую сервер поместил в журнал сообщений: восстанавливаться из архива! Как? Возможные варианты восстановления мы рассмотрим в следующем выпуске.

Отражение процесса архивирования в журнале сообщений

А откуда вообще взялась у меня уверенность, что этот сервер удастся запустить после всего, что он пережил. Минимальную уверенность дает мне то, что в журнале сообщений сервера я увидел информацию об успешном создании архивов и копий журналов:

 
13:50:54  Maximum server connections 1  
13:50:56  Level 0 Archive started on rootdbs, blobdbs, sbspace, workdbs 
13:51:06  Archive on rootdbs, blobdbs, sbspace, workdbs Completed. 
13:55:57  Fuzzy Checkpoint Completed:  duration was 0 seconds, 1 buffers not flushed. 
13:55:57  Checkpoint loguniq 32, logpos 0x198234 
 
13:55:57  Maximum server connections 1  
14:00:58  Fuzzy Checkpoint Completed:  duration was 0 seconds, 1 buffers not flushed. 
14:00:58  Checkpoint loguniq 32, logpos 0x199044 
 
14:00:58  Maximum server connections 1  
14:01:28  Logical Log 32 Complete. 
14:01:28  Logical Log 32 - Backup Started 
14:01:28  Logical Log 32 - Backup Completed 
14:05:58  Fuzzy Checkpoint Completed:  duration was 0 seconds, 1 buffers not flushed. 
14:05:58  Checkpoint loguniq 33, logpos 0x1044 
 
14:05:58  Maximum server connections 1  
14:13:11  Checkpoint Completed:  duration was 0 seconds. 
14:13:11  Checkpoint loguniq 33, logpos 0x2850 
 
14:13:11  Maximum server connections 1  
14:13:12  Level 1 Archive started on rootdbs, blobdbs, sbspace, workdbs 
14:13:16  Archive on rootdbs, blobdbs, sbspace, workdbs Completed. 
14:18:04  Logical Log 33 Complete. 
14:18:04  Logical Log 33 - Backup Started 
14:18:04  Logical Log 33 - Backup Completed 
14:18:30  Checkpoint Completed:  duration was 0 seconds. 
14:18:30  Checkpoint loguniq 34, logpos 0x1018 
 
14:18:30  Maximum server connections 1  
14:21:12  Logical Log 34 Complete. 
14:21:13  Logical Log 34 - Backup Started 
14:21:13  Logical Log 34 - Backup Completed 
14:23:30  Fuzzy Checkpoint Completed:  duration was 0 seconds, 7 buffers not flushed. 
14:23:30  Checkpoint loguniq 35, logpos 0x1074 
 
14:23:30  Maximum server connections 1  
14:28:31  Fuzzy Checkpoint Completed:  duration was 0 seconds, 7 buffers not flushed. 
14:28:31  Checkpoint loguniq 35, logpos 0x2074 
 
14:28:31  Maximum server connections 1  
14:28:51  Checkpoint Completed:  duration was 0 seconds. 
14:28:51  Checkpoint loguniq 35, logpos 0x3018 
 
14:28:51  Maximum server connections 1  
14:28:52  Informix Dynamic Server Stopped. 

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

Итоги

Мы рассмотрели, как подготовить и организовать архивирование данных и резервное копирование логических журналов на диск с помощью утилиты ontape. При этом мы обеспечили автоматическое копирование каждого журнала в отдельный файл по мере их заполнения. Архивирование и управление полученными файлами архивов мы вели вручную.

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

 
C:\tmp>dir archive.* log.* 
 Том в устройстве C имеет метку MAIN 
 Серийный номер тома: D0A3-4245 
 
 Содержимое папки C:\tmp 
 
19.01.2005  14:15                 0 archive 
19.01.2005  13:51        17 842 176 archive.0 
19.01.2005  14:13           262 144 archive.1 
 
 Содержимое папки C:\tmp 
 
19.01.2005  14:21                 0 log 
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 (archive.0) и соответствующий инкрементный, уровня 1 (arhcive.1), а также копии журналов с идентификаторами 32, 33 и 34 (log.32, log.33, log.34). Это позволит нам восстановить данные на любой из описанных выше моментов времени, t0, t1 и t2, причем, несколькими способами.

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

1.Informix Storage Manager Administrator's Guide, Version 2.2 (G251-0498-00).

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

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

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

Другие мои проекты

Обращаю ваше внимание, что, помимо рассылки по СУБД Informix, я веду еще несколько проектов. В частности, появились новости в проекте "Страницы справочного руководства ОС UNIX на русском" (начата публикация моего перевода man ksh(1)) и в проекте "Открыто о СУБД Oracle на русском" (там вообще много новостей). Посмотрите, кому интересно.

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

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

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

  В.К.