Последствия использования proutil 'dbname' -C truncate bi -F

Когда база будет запущена вновь, начнется процесс, называемый rollback. Этот процесс состоит из двух этапов: 

• Redo Phase. Из-за того, как Progress оптимизирует запись в файлы данных (.d1,.d2 и т.д), некоторые транзакции, которые были завершены (commit) во время возникновения сбоя, могли быть записаны в Before-Image (BI) файл, но не записаны в файлы данных. Это полностью нормально. Во время Redo Phase, Progress сканирует два последних используемых BI-кластера, чтобы убедиться, что все завершенные транзакции сброшены (flushed) в файлы данных. Старт и завершение Redo Phase отмечается сообщениями с номерами 5326 и 7161 соответственно, которые появляются во время запуска базы данных: 

Begin Physical Redo Phase at <address>. (5326)

Physical Redo Phase Completed at blk <blk> off <off> upd <upd>.(7161)

• Rollback. Как только Redo Phase завершится, Progress выполняет обратное сканирование BI-файла на предмет наличия не завершенных транзакций к моменту возникновения сбоя. И любая не завершенная транзакция, будет откатана назад (rolled back), благодаря наличию информации в самом BI-файле. 

Принудительный доступ с –F

Когда к базе был применен принудительный доступ с параметром –F, оба этапа, redo phase и roll back  пропускаются (!), и BI файл перестраивается, таким образом информация необходимая для обеих этапов, считается потерянной. Поэтому не трудно понять, что после этого база данных будет находиться в неопределенном состоянии. А именно:

• Поскольку пропущена Redo Phase – все транзакции завершенные в момент сбоя не будут сохранены в файлы данных, или еще хуже, они могут быть сохранены частично. Это основная причина, почему база данных будет разрушена при использовании –F, даже если бы не было ни каких активных транзакций в момент сбоя. 

• Поскольку пропущен Roll Back, не завершенные транзакции к моменту сбоя, не будут отменены, а это влечет за собой следующие последствия: 

Не полностью будут обновлены записи.

Записи могут быть частично удалены.

Наличие фрагментов несуществующих записей.

Наличие не индексированных записей.

Наличие индексов, ссылающихся на несуществующие записи.

Наличие противоречий в Free и RM цепочках, которые используются для размещения новых записей.

Наличие логических противоречий из-за частичного завершения транзакций.

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

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

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

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

Исходя из всего этого, можно сказать, что восстановление базы данных из резервной копии, это наиболее простой и приемлемый способ, чем использование параметра –F.

Но если же вы все-таки решились на использование принудительного доступа, то вам обязательно нужно будет выполнить следующее рекомендации. В первую очередь, выполните резервное копирование базы данных. Имейте ввиду, что работа утилиты probkup может завершится аварийно, поскольку блоки базы данных могут быть повреждены, и в этом случае, вам придется воспользоваться утилитами операционной системы. Только после того, как вы убедитесь, что имеется копия базы, можно воспользоваться параметром –F в составе команды proutil <db> -C truncate bi –F.

Как только команда будет запущена, на экране появятся следующие сообщения:

The -F option has been specified to proutil. (6260)
Forcing into the database skips database recovery. (6261)
This leaves the database in unknown state, considered damaged. (6262)
Are you sure you want to skip crash recovery? (6263)
If you enter \"y\" for \"yes\", the forced access occurs and the following additional dire warnings are displayed and written to the log file:
** The FORCE option was given, database recovery will be skipped. (33)
** Your database was damaged. Dump its data and reload it. (37)

После этого, база данных должна быть перезагружена (dump/load) в новую базу. Но перед этим, желательно выполнить переиндексацию (idxbuild) чтобы иметь возможность получить доступ к как можно большему количеству записей. Учтите, что в этот момент вам может понадобиться копия базы данных, поскольку если во время работы idxbuild произойдет какой-либо сбой – базу можно будет восстановить только из копии!

В завершении, выгрузите данные с помощью Data Dictionary, и выполните их загрузку в новую базу с помощью утилиты bulkload. Использование бинарной выгрузки не рекомендуется, поскольку не проверяется целостность записей, что может привести к тому, что поврежденные записи будут просто скопированы в новую базу данных, и как следствие, её можно будет так же считать поврежденной.

Башкатов В.Г. 2009 г.