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

Выпуск 6

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

В этом выпуске я решил рассмотреть две "проблемы" резервного копирования и восстановления данных (с помощью ISM и onbar): восстановление на определенный момент времени с помощью утилиты onbar и особенности резервного копирования и восстановления больших объектов, размещенных в BLOB-пространствах. С этими проблемами мне пришлось в последнее время столкнуться при чтении курсов по системному администрированию IDS и по ходу размышлений над применимостью механизма репликации HDR для систем, работающих с данными типа TEXT и BYTE. Это не совсем те проблемы, которые я обещал рассмотреть в прошлом выпуске, но, поверьте, разобраться с этим тоже интересно и полезно.

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

Восстановление на определенный момент времени

В теории (см. 1) все просто. Опция -t утилиты onbar позволяет восстановить данные по состоянию на определенный момент времени. Давайте попробуем.

Ситуация с резервными копиями, изначально, выглядит так (фрагмент журнала onbar):

 
 2004-09-27 13:57:21 2740  2740 C:\Informix\bin\onbar_d -b -w 
 2004-09-27 13:57:22 2740  2740 Begin level 0 backup rootdbs. 
 2004-09-27 13:57:24 2740  2740 Successfully connected to Storage Manager. 
 2004-09-27 13:59:48 2740  2740 Completed level 0 backup rootdbs (Storage Manager copy ID: 1117 0). 
 2004-09-27 13:59:48 2740  2740 Begin level 0 backup sbspace. 
 2004-09-27 13:59:49 2740  2740 Completed level 0 backup sbspace (Storage Manager copy ID: 1118 0). 
 2004-09-27 13:59:49 2740  2740 Begin level 0 backup workdbs. 
 2004-09-27 13:59:49 2740  2740 Completed level 0 backup workdbs (Storage Manager copy ID: 1119 0). 
 2004-09-27 13:59:58 2740  2740 C:\Informix\bin\onbar_d complete, returning 0 (0x00) 
 ... 
 2004-09-27 14:03:08 3556  3556 C:\Informix\bin\onbar_d -b -l 
 2004-09-27 14:03:08 3556  3556 Begin backup logical log 21. 
 2004-09-27 14:03:09 3556  3556 Successfully connected to Storage Manager. 
 2004-09-27 14:05:03 3556  3556 Completed backup logical log 21 (Storage Manager copy ID: 1122 0). 
 2004-09-27 14:05:04 3556  3556 C:\Informix\bin\onbar_d complete, returning 0 (0x00) 

Сейчас мы работаем в 22 логическом журнале:

 
C:\Informix>onstat -l 
 
Informix Dynamic Server Version 9.30.TC2     -- On-Line -- Up 01:34:01 -- 25472 
Kbytes 
 
Physical Logging 
Buffer bufused  bufsize  numpages numwrits pages/io 
  P-2  5        8        102      16       6.38 
      phybegin physize  phypos   phyused  %used 
      100107   500      43       5        1.00 
 
Logical Logging 
Buffer bufused  bufsize  numrecs  numpages numwrits recs/pages pages/io 
  L-3  0        8        942      44       32       21.4       1.4 
        Subsystem    numrecs  Log Space used 
        OLDRSAM      942      63780 
 
address  number   flags    uniqid   begin        size     used    %used 
ca376a8  1        U-B----  19       1002fb        500        3     0.60 
ca376e0  2        U-B----  20       1004ef        500       92    18.40 
ca37718  3        U-B---L  21       1006e3        500       13     2.60 
ca37750  4        U---C--  22       1008d7        500        1     0.20 
ca37788  5        U-B----  17       100acb        500       20     4.00 
ca377c0  6        U-B----  18       100cbf        500       11     2.20 

Давайте попробуем выполнить некоторое изменение в определенный момент времени, а затем - восстановить систему в состояние до начала этого изменения. Обычно в качестве примера изменения я добавляю очередной "штат" в таблицу state стандартной демонстрационной базы данных Informix под общеизвестным названием stores7 (я ее обычно создаю под именем demo_db командой dbaccessdemo -log demo_db).

Итак, судя по представленным данным, в момент времени 2004-09-27 14:05:03 у нас еще не было никакого изменения. Выполняем изменение (оператор insert into state values('UA', 'Ukraine') в dbaccess, я выполнил его примерно в 14:59) и останавливаем сервер Informix (onmode -ky).

В журнале сообщений имеем (по ходу дела произошел перезапуск сервера Informix, но его причина не имеет отношения к сути обсуждения):

 
14:03:08  Logical Log 21 - Backup Started 
14:05:03  Logical Log 21 - Backup Completed 
14:07:40  Fuzzy Checkpoint Completed:  duration was 0 seconds, 3 buffers not flushed. 
14:07:40  Checkpoint loguniq 22, logpos 0x1088 
 
14:07:40  Maximum server connections 0  
14:12:41  Fuzzy Checkpoint Completed:  duration was 0 seconds, 3 buffers not flushed. 
14:12:41  Checkpoint loguniq 22, logpos 0x2054 
 
14:12:41  Maximum server connections 0  
14:27:44  Fuzzy Checkpoint Completed:  duration was 0 seconds, 3 buffers not flushed. 
14:27:44  Checkpoint loguniq 22, logpos 0x3054 
 
14:27:44  Maximum server connections 1  
 
... 
 
14:52:01  Init operation complete - Mode Online 
14:52:01  On-Line Mode 
15:00:25  Checkpoint Completed:  duration was 0 seconds. 
15:00:25  Checkpoint loguniq 22, logpos 0x6018 
 
15:00:25  Maximum server connections 1  
15:00:26  Informix Dynamic Server Stopped. 

Теперь попробуем восстановить сервер на нужный момент времени. Утилита onbar для этого действия (которое можно выполнять только при выключенном сервере, и при восстановлении только всего сервера в целом) предлагает следующий синтаксис:

 
onbar -r -w [-e] [[-p] [ -t <time>] | -n <log>] [-O] 

Осталось задать момент времени, и попробовать:

 
C:\Informix>onbar -r -w -t 2004-09-27 14:05:03 
C:\Informix>onstat - 
 
Informix Dynamic Server Version 9.30.TC2     -- Quiescent -- Up 00:01:37 -- 3366 
4 Kbytes 
 
C:\Informix>onmode -m 

Простая проверка (select * from state) показывает, что успешно ранее добавленный новый "штат" отсутствует... И даже не пришлось брать значение момента времени в кавычки, как это рекомендуется в документации.

В журнале onbar этот процесс отразился следующим образом:

 
 2004-09-27 15:10:02 1900  1900 C:\Informix\bin\onbar_d -r -w -t 2004-09-27 14:05:03 
 2004-09-27 15:10:03 1900  1900 Successfully connected to Storage Manager. 
 2004-09-27 15:10:04 1900  1900 Begin salvage for log 22. 
 2004-09-27 15:10:04 1900  1900 Completed salvage of logical log 22. 
 2004-09-27 15:10:04 1900  1900 Successfully connected to Storage Manager. 
 2004-09-27 15:10:05 1900  1900 Begin cold level 0 restore rootdbs (Storage Manager copy ID: 1117 0). 
 2004-09-27 15:10:35 1900  1900 Completed cold level 0 restore rootdbs. 
 2004-09-27 15:10:36 1900  1900 Begin cold level 0 restore sbspace (Storage Manager copy ID: 1118 0). 
 2004-09-27 15:10:38 1900  1900 Completed cold level 0 restore sbspace. 
 2004-09-27 15:10:38 1900  1900 Begin cold level 0 restore workdbs (Storage Manager copy ID: 1119 0). 
 2004-09-27 15:10:40 1900  1900 Completed cold level 0 restore workdbs. 
 2004-09-27 15:10:41 1900  1900 Completed whole system restore. 
 2004-09-27 15:10:44 1900  1900 Successfully connected to Storage Manager. 
 2004-09-27 15:10:45 1900  1900 Begin restore logical log 21 (Storage Manager copy ID: 1122 0). 
 2004-09-27 15:10:46 1900  1900 Completed restore logical log 21. 
 2004-09-27 15:10:47 1900  1900 Begin restore logical log 22 (Storage Manager copy ID: 1125 0). 
 2004-09-27 15:10:48 1900  1900 Completed restore logical log 22. 
 2004-09-27 15:10:56 1900  1900 Completed logical restore. 
 2004-09-27 15:10:59 2564  2564 C:\Informix\bin\onbar_d -b -l 
 2004-09-27 15:11:00 2564  2564 Begin backup logical log 22. 
 2004-09-27 15:11:01 1900  1900 C:\Informix\bin\onbar_d complete, returning 0 (0x00) 
 2004-09-27 15:11:02 2564  2564 Successfully connected to Storage Manager. 
 2004-09-27 15:11:03 2564  2564 Completed backup logical log 22 (Storage Manager copy ID: 1126 0). 
 2004-09-27 15:11:03 2564  2564 C:\Informix\bin\onbar_d complete, returning 0 (0x00) 

В журнале сообщений сервера Informix видим:

 
15:10:06  Informix Dynamic Server Started. 
 
Mon Sep 27 15:10:06 2004 
 
15:10:06  Booting Language <c> from module <> 
15:10:06  Loading Module <CNULL> 
15:10:06  Booting Language <builtin> from module <> 
15:10:06  Loading Module <BUILTINNULL> 
15:10:11  Informix Dynamic Server Version 9.30.TC2     Software Serial Number AAC#J415297 
15:10:11  Informix Dynamic Server Initialized -- Shared Memory Initialized. 
 
15:10:11  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 
 
15:10:26  Dataskip is now OFF for all dbspaces 
15:10:26  Restartable Restore has been ENABLED 
15:10:26  Recovery Mode 
15:10:27  Physical Restore of rootdbs, sbspace, workdbs started. 
 
15:10:34  Checkpoint Completed:  duration was 0 seconds. 
15:10:34  Checkpoint loguniq 21, logpos 0x4fe8 
 
15:10:34  Maximum server connections 0  
15:10:37  Checkpoint Completed:  duration was 0 seconds. 
15:10:37  Checkpoint loguniq 21, logpos 0x4fe8 
 
15:10:37  Maximum server connections 0  
15:10:38  Checkpoint Completed:  duration was 0 seconds. 
15:10:38  Checkpoint loguniq 21, logpos 0x4fe8 
 
15:10:38  Maximum server connections 0  
15:10:41  Physical Restore of rootdbs, sbspace, workdbs Completed. 
15:10:41  Checkpoint Completed:  duration was 0 seconds. 
15:10:41  Checkpoint loguniq 21, logpos 0x4fe8 
 
15:10:41  Maximum server connections 0  
15:10:41  Logical Recovery Started. 
15:10:41  10 recovery worker threads will be started. 
15:10:41  Dynamically allocated new virtual shared memory segment (size 8192KB) 
15:10:41  Dynamically allocated new virtual shared memory segment (size 8192KB) 
15:10:42  Checkpoint Completed:  duration was 0 seconds. 
15:10:42  Checkpoint loguniq 21, logpos 0x4fe8 
 
15:10:42  Maximum server connections 0  
15:10:42  Start Logical Recovery - Start Log 21, End Log ? 
15:10:42  Starting Log Position - 21 0x4fe8 
15:10:42  Clearing the physical and logical logs has started 
15:10:44  Cleared 13 MB of the physical and logical logs in 2 seconds 
15:10:45  Checkpoint Completed:  duration was 0 seconds. 
15:10:45  Checkpoint loguniq 21, logpos 0xb054 
 
15:10:45  Maximum server connections 0  
15:10:47  Checkpoint Completed:  duration was 0 seconds. 
15:10:47  Checkpoint loguniq 22, logpos 0x1088 
 
15:10:47  Maximum server connections 0  
15:10:47  Checkpoint Completed:  duration was 0 seconds. 
15:10:47  Checkpoint loguniq 22, logpos 0x2054 
 
15:10:47  Maximum server connections 0  
15:10:47  Checkpoint Completed:  duration was 0 seconds. 
15:10:47  Checkpoint loguniq 22, logpos 0x3054 
 
15:10:47  Maximum server connections 0  
15:10:47  Checkpoint Completed:  duration was 0 seconds. 
15:10:47  Checkpoint loguniq 22, logpos 0x4018 
 
15:10:47  Maximum server connections 0  
15:10:47  PIT reached - logid: 22, logpos: 0x50b4 
15:10:56  Logical Recovery has reached the transaction cleanup phase. 
15:10:56  Checkpoint Completed:  duration was 0 seconds. 
15:10:56  Checkpoint loguniq 23, logpos 0x18 
 
15:10:56  Maximum server connections 0  
15:10:56  Logical Recovery Complete. 
   15 Committed, 1 Rolled Back, 0 Open, 0 Bad Locks 
 
15:10:56  Logical Recovery Complete. 
15:10:57  Quiescent Mode 
15:10:57  Logical Log 22 Complete. 
15:10:57  Checkpoint Completed:  duration was 0 seconds. 
15:10:58  Checkpoint loguniq 23, logpos 0x107c 
 
15:10:58  Maximum server connections 0  
15:10:58  Booting Language <spl> from module <> 
15:10:58  Loading Module <SPLNULL> 
15:11:00  Logical Log 22 - Backup Started 
15:11:03  Logical Log 22 - Backup Completed 
15:11:51  On-Line Mode 
15:15:57  Fuzzy Checkpoint Completed:  duration was 0 seconds, 3 buffers not flushed. 
15:15:57  Checkpoint loguniq 23, logpos 0xb054 
 
15:15:57  Maximum server connections 1  

Это все я веду к тому, что механизм действительно работает, как описано в документации. Формат для задания момента времени можно брать из журнала onbar. Но! Все это верно в "стандартной" локали:

 
C:\Informix>set db_ 
DB_LOCALE=EN_US.8859-1 
 
C:\Informix>set cli 
CLIENTNAME=Console 
CLIENT_LOCALE=EN_US.CP1252 

Когда я последний раз попытался продемонстрировать такой вариант восстановления на курсах (в локали UA_UA.1251), ничего не получилось - утилита onbar просто выдала список опций. Я был в некотором замешательстве, ведь этот способ восстановления многократно и прекрасно работал (на версии 7.3x, в Solaris, SCO Open Server, ну и что...) И только что под Windows на 9.30.TC2 тоже сработал. В очередной раз "погорел" на непроверенных примерах...

Попробуем разобраться. Останавливаем сервер, ставим (входящую в дистрибутив) "русскую локаль" и снова пытаемся выполнить восстановление:

 
C:\Informix>onmode -ky 
 
C:\Informix>set DB_LOCALE=ru_ru.1251 
 
C:\Informix>set CLIENT_LOCALE=ru_ru.1251 
 
C:\Informix>onbar -r -w -t 2004-09-27 14:05:03 
C:\Informix\bin\onbar_d -r -w -t 2004-09-27 14:05:03 
onbar usage 
... 

Вот мы и получили тот же печальный результат...

На самом деле, в документации четко написано, что формат для задания момента времени при восстановлении определяется переменной среды GL_DATETIME. Давайте установим ей значение явно:

 
C:\Informix>set GL_DATETIME=%Y-%m-%d %H:%M:%S 
C:\Informix>onbar -r -w -t 2004-09-27 14:05:03 
C:\Informix>onstat - 
 
Informix Dynamic Server Version 9.30.TC2     -- Quiescent -- Up 00:01:32 -- 3366 
4 Kbytes 

Восстановление прошло. Напрашивается два вывода: для "нестандартной" локали перед восстановлением на момент времени надо явно задать соответствующее (журналу onbar) значение переменной cреды GL_DATETIME. Ну, и совсем уж тривиальный - RTFM (читайте и перечитывайте документацию)!

Резервное копирование и восстановление данных типа TEXT и BYTE

Недавно я столкнулся с проблемой репликации HDR, состоящей в том, что изменения BLOB-объектов, размещенных в BLOB-пространствах, не реплицируются. Это абсолютно стандартное поведение, в том числе, и в версии 9.30.x. Оно делает такую репликацию не вполне пригодной в случаях, если такие объекты меняются достаточно часто по ходу нормальной работы с базами данных Informix. Нужно искать какие-то другие решения, позволяющие не потерять эти измененные BLOB-объекты. Я начал придумывать некую систему копирования и восстановления архивов и журналов на резервном сервере, но тут возник вопрос: а вообще можно обеспечить восстановление этих измененных BLOB-объектов, и при каких условиях? Для выяснения я, как обычно, решил поставить экcперимент.

Создадим BLOB-пространство blobdbs:

 
C:\Informix>onstat - 
 
Informix Dynamic Server Version 9.30.TC2     -- On-Line -- Up 00:20:16 -- 33664 
Kbytes 
 
C:\Informix>cd c:\IFMXDATA\ol_creator 
 
C:\IFMXDATA\ol_creator>copy nul blobdbs_dat.000 
Скопировано файлов:         1. 
 
C:\IFMXDATA\ol_creator>onspaces -c -b blobdbs -g 1 -p c:\IFMXDATA\ol_creator\blo 
bdbs_dat.000 -o 0 -s 10000 
Verifying physical disk space, please wait ... 
Space successfully added. 
 
** WARNING **  A level 0 archive of Root DBSpace will need to be done. 
 
C:\IFMXDATA\ol_creator>onbar -b -w 

Теперь в базе данных с журнализацией demo_db создадим таблицу:

 
create table blobtest ( 
  c1 serial, 
  c2 text in table, 
  c3 text in blobdbs) 

и вставим в нее пару строк в DB-Access:

 
load from "c:\tmp\texts.txt" 
insert into blobtest 

При этом заранее заготовленный файл c:\tmp\texts.txt имеет следующее содержание:

 
C:\tmp>type texts.txt 
1|first|second| 
2|third|fourth| 

В результате, мы получили две строки, содержащие известные значения типа TEXT. Давайте проверим, будут ли они восстановлены, если придется восстанавливать сервер (по журналам!). Для этого остановим сервер (onmode -ky) и попросим восстановить данные на момент останова:

 
C:\IFMXDATA\ol_creator>onmode -ky 
 
C:\IFMXDATA\ol_creator>onbar -r -w 
C:\IFMXDATA\ol_creator>onstat - 
 
Informix Dynamic Server Version 9.30.TC2     -- Quiescent -- Up 00:00:59 -- 3366 
4 Kbytes 
 
 
C:\IFMXDATA\ol_creator>onmode -m 

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

 
... 
17:13:15  Recovery Mode 
17:13:15  Physical Restore of rootdbs, blobdbs, sbspace, workdbs started. 
 
17:13:19  Checkpoint Completed:  duration was 0 seconds. 
17:13:19  Checkpoint loguniq 24, logpos 0x1553c 
 
17:13:19  Maximum server connections 0  
17:13:21  Checkpoint Completed:  duration was 0 seconds. 
17:13:21  Checkpoint loguniq 24, logpos 0x1553c 
 
17:13:21  Maximum server connections 0  
17:13:23  Checkpoint Completed:  duration was 0 seconds. 
17:13:23  Checkpoint loguniq 24, logpos 0x1553c 
 
17:13:23  Maximum server connections 0  
17:13:25  Checkpoint Completed:  duration was 0 seconds. 
17:13:25  Checkpoint loguniq 24, logpos 0x1553c 
 
17:13:25  Maximum server connections 0  
17:13:27  Physical Restore of rootdbs, blobdbs, sbspace, workdbs Completed. 
17:13:27  Checkpoint Completed:  duration was 0 seconds. 
17:13:27  Checkpoint loguniq 24, logpos 0x1553c 
 
17:13:27  Maximum server connections 0  
17:13:27  Logical Recovery Started. 
17:13:27  10 recovery worker threads will be started. 
17:13:27  Dynamically allocated new virtual shared memory segment (size 8192KB) 
17:13:27  Dynamically allocated new virtual shared memory segment (size 8192KB) 
17:13:28  Checkpoint Completed:  duration was 0 seconds. 
17:13:28  Checkpoint loguniq 24, logpos 0x1553c 
 
17:13:28  Maximum server connections 0  
17:13:28  Start Logical Recovery - Start Log 24, End Log ? 
17:13:28  Starting Log Position - 24 0x1553c 
17:13:28  Clearing the physical and logical logs has started 
17:13:30  Cleared 13 MB of the physical and logical logs in 2 seconds 
17:13:33  Checkpoint Completed:  duration was 0 seconds. 
17:13:33  Checkpoint loguniq 25, logpos 0x705c 
 
17:13:33  Maximum server connections 0  
17:13:33  Checkpoint Completed:  duration was 0 seconds. 
17:13:33  Checkpoint loguniq 25, logpos 0x9094 
 
17:13:33  Maximum server connections 0  
17:13:33  Checkpoint Completed:  duration was 0 seconds. 
17:13:33  Checkpoint loguniq 25, logpos 0xa094 
 
17:13:33  Maximum server connections 0  
17:13:34  Checkpoint Completed:  duration was 0 seconds. 
17:13:34  Checkpoint loguniq 25, logpos 0xc09c 
 
17:13:34  Maximum server connections 0  
17:13:34  Checkpoint Completed:  duration was 0 seconds. 
17:13:34  Checkpoint loguniq 25, logpos 0xd018 
 
17:13:34  Maximum server connections 0  
17:13:39  Logical Recovery has reached the transaction cleanup phase. 
17:13:39  Logical Recovery Complete. 
   18 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks 
 
17:13:39  Logical Recovery Complete. 
17:13:40  Quiescent Mode 
17:13:40  Logical Log 25 Complete. 
17:13:41  Checkpoint Completed:  duration was 0 seconds. 
17:13:41  Checkpoint loguniq 26, logpos 0x18 
 
17:13:41  Maximum server connections 0  
17:13:41  Booting Language <spl> from module <> 
17:13:41  Loading Module <SPLNULL> 
17:14:00  On-Line Mode 

Простая проверка (select * from blobtest) показывает, что данные - на месте. Но, не все так просто - мы ведь никак не поменяли данные на диске перед этим восстановлением. Давайте повторим эксперимент, но изменим данные в столбцах типа TEXT (оставив от значений первые два символа) и добавив еще две таких же строки:

 
update blobtest set c2 = c2[1,2], c3 = c3[1,2]; 
insert into blobtest(c2, c3) select c2, c3 from blobtest; 

затем выйдем из DB-Access, перейдем на следующий журнал, чтобы гарантированно получить его копию (журналы у меня - в rootdbs), и сымитируем сбой в пространствах rootdbs и blobdbs, где, фактически, и хранятся данные столбцов типа TEXT:

 
C:\IFMXDATA\ol_creator>onmode -l 
 
C:\IFMXDATA\ol_creator>onstat -l 
 
Informix Dynamic Server Version 9.30.TC2     -- On-Line -- Up 00:12:38 -- 33664 
Kbytes 
 
Physical Logging 
Buffer bufused  bufsize  numpages numwrits pages/io 
  P-2  0        8        84       12       7.00 
      phybegin physize  phypos   phyused  %used 
      100107   500      166      0        0.00 
 
Logical Logging 
Buffer bufused  bufsize  numrecs  numpages numwrits recs/pages pages/io 
  L-1  0        8        130      15       15       8.7        1.0 
        Subsystem    numrecs  Log Space used 
        OLDRSAM      130      9020 
 
address  number   flags    uniqid   begin        size     used    %used 
ca376a8  1        U-B----  25       1002fb        500       15     3.00 
ca376e0  2        U-B----  26       1004ef        500       12     2.40 
ca37718  3        U---C-L  27       1006e3        500        3     0.60 
ca37750  4        F------  0        1008d7        500        0     0.00 
ca37788  5        F------  0        100acb        500        0     0.00 
ca377c0  6        U-B----  24       100cbf        500       23     4.60 
 6 active, 6 total 
 
C:\IFMXDATA\ol_creator>onmode -ky 
 
C:\IFMXDATA\ol_creator>copy nul rootdbs_dat.000 
Заменить rootdbs_dat.000 [Yes (да)/No (нет)/All (все)]: y 
Скопировано файлов:         1. 
 
C:\IFMXDATA\ol_creator>copy nul blobdbs_dat.000 
Заменить blobdbs_dat.000 [Yes (да)/No (нет)/All (все)]: y 
Скопировано файлов:         1. 
 
C:\IFMXDATA\ol_creator>onbar -r -w 
C:\IFMXDATA\ol_creator>onstat - 
 
Informix Dynamic Server Version 9.30.TC2     -- Quiescent -- Up 00:01:35 -- 3366 
4 Kbytes 
 
C:\IFMXDATA\ol_creator>onmode -m 

Теперь выполняем select * from blobtest и... видим все выполненные изменения!!!!

Вы, возможно, поинтересуетесь, зачем так много восклицательных знаков? Дело в том, что, по известной мне ранее теории (которая образовалась по ходу изучения документации по версиям 7.x) изменения на страницах BLOB-пространств не отражаются в логическом журнале (т.е. там отражаются изменения в битовых картах, но не сами измененные данные). Я, если честно, ожидал увидеть изменения в столбце c2 (который хранится вместе с таблицей), но не увидеть изменения в столбце c3 (который хранится в blobdbs). Ведь резервную копию blobdbs я сделал только один раз, сразу же после добавления пространства. Оба чанка честно чистил... Неужели пошло восстановление BLOB-ов в BLOB-пространствах по журналам??? Тогда - слава IBM!

Я повторял эксперименты несколько раз, вставляя в столбцы типа TEXT достаточно большие объемы данных (af-файлы Informix; для вставки я использовал вот этот ODBC Explorer) и получал неизменный результат: при наличии резервной копии журнала данные столбцов типа TEXT в СУБД Informix версии 9.30.TC2 восстанавливаются!

Итоги

Я буду благодарен тем подписчикам, которые укажут на некорректность в поставленном эксперименте (если она есть) и поделятся результатами аналогичных экспериментов на других версиях Informix. Я же, в смущении, снова начну перечитывать документацию по версии 9.30. RTFM, RTFM и еще раз RTFM, как говорил дедушка Ленин!

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

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

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

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

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

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

Пока что при восстановлении мы исходили из предположения, что ISM был нормально установлен и запускается. Это не всегда так. Как люди этого добиваются, мне не всегда ясно. Но, ломать - не строить. В следующем выпуске я, скорее всего, займусь обсуждением именно этих проблем.

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

  В.К.