Этот сайт посвящается администрированию баз данных OpenEdge Progress.
Не корысти ради, а познания для!

С уважением,
Валерий Башкатов

Сайт разработан при участии компании Progress Technologies, официального дистрибьютора Progress Software Corp. на территории стран СНГ и Латвии.

RSS подписка на обновления сайта

Поиск по сайту

Лучшие материалы

На сайте функционирует система коррекции ошибок. Обнаружив неточность в тексте, выделите её и нажмите Ctrl+Enter

Результаты опроса: Нужны ли книги по Progress OpenEdge на русском языке? (опрос проводился с мая 2009 по ноябрь 2010)

Да, нужны. Потому что будет легче понять материал - 268
Нет, не нужны. Достаточно материалов на английском языке - 10
Не знаю, мне всё равно - 6

А знаете ли вы что..

Защита данных - Восстановление базы данных

prorest dbname device-name {-list | -vp | -vf}

Где,
dbname
       имя базы данных, которую необходимо восстановить

device-name
       определяет путь к резервной копии базы данных, из которой будет происходить восстановление

-list
       Отображает описание всех областей хранения данных содержащихся в копии. Используйте ее для формирования нового структурного файла и создания базы данных, в которую будет происходить восстановление копии.

-vp
       Определяет необходимость проверки копии путем вычисления CRC кода блоков копии и сравнения его с CRC кодом указанным в                заголовке блока. Для восстановления поврежденного блока, необходимо определить показатель избыточности при формировании копии        базы данных.

-vf
       Определяет необходимость сравнения каждого блока копии с каждым блоком базы данных. Работает только при условии, что базы данных        не используется.

Примечание: при использовании параметров –vp и –vf, восстановление базы данных не происходит. Для восстановления необходимо повторно запустить PROREST, но уже без этих параметров.

При первом запуске базы данных, восстановленной из online копии, сначала запустится механизм восстановления (crash recovery), чтобы откатить все транзакции, которые были не завершены на момент копирования базы.

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

Если PROREST при восстановлении сталкивается с поврежденными блоками копии, которые он не в состоянии восстановить - данные в этих блоках будут потеряны. Количество потерянных данных приблизительно равно количеству поврежденных блоков умноженных на значение параметра –bf (blocking factor).

Перед началом восстановления на экране отобразится сообщение о дате копии и необходимом количестве блоков для восстановления базы данных.

Важные правила для восстановления базы

Есть несколько важных правил, которых стоит придерживаться при выполнении процедуры восстановления:

Если восстановление происходит в уже существующую базу, проверьте копии перед началом восстановления. В случае, если существующая базы находится в единственном экземпляре, перед восстановлением сформируйте копию этой базы.
Восстанавливайте копию на той же версией OpenEdge, на которой копия была сформирована.
Восстановление инкрементальной копии возможно только на уже восстановленную ранее базу данных.
Создайте пустую базу данных перед началом восстановления.
Восстанавливайте базу данных в той же последовательности, в какой формировали копию. Т.е сначала восстанавливайте полную копию, потом первую инкрементальную, затем вторую и т.д. При попытке восстановления базы в не правильной последовательности, вы получите ошибку восстановления.
Если вторая инкрементальная копия была потеряна и был использован фактор перекрытия 1, то третья копия будет успешно восстановлена, т.к. содержит потерянные данные второй.
После восстановления полной копии, не используйте базу данных, если вы собираетесь продолжить восстановление из инкрементальных копий. Если база данных будет изменена до окончания восстановления всех копий, все последующий инкрементальные копии, которые не были восстановлены) восстановиться не смогут, и придется повторять всю процедуру восстановления заново, начиная с полной копии.
Если в момент выполнения восстановления произошла системная ошибка, то запустите процедуру восстановления заново начиная с той копии, которая восстанавливалась на момент системной ошибки.
Если восстановление происходит в существующую структуру базы данных, то она должна иметь одинаковый с копией размер блока базы данных, одинаковые области хранения данных и достаточное количество экстентов этих областей. PROREST, при необходимости, расширяет область хранения данных, для обеспечения полного восстановления, но если количество экстентов области будет не достаточным, восстановление будет аварийно завершено.

Получение описания областей хранения с помощью PROREST

Для получения описания областей хранения необходимых для восстановления копии, используйте утилиту PROREST с параметром –list. Синтаксис следующий:

prorest db-name device-name -list

В следующем примере показано, как будет отображен результат работы утилиты:

OpenEdge Release 10.1B as of Fri Nov 7 02:56:17 EST 2003
Area Name: Schema Area
Size: 7680, Records/Block: 32, Area Number: 6, Cluster Size: 1
Area Name: Info Area
Size: 1024, Records/Block: 32, Area Number: 7, Cluster Size: 1
Area Name: Customer/Order Area
Size: 2560, Records/Block: 32, Area Number: 8, Cluster Size: 8
Area Name: Primary Index Area
Size: 32, Records/Block: 1, Area Number: 9, Cluster Size: 8
Area Name: Customer Index Area
Size: 256, Records/Block: 1, Area Number: 10, Cluster Size 64
Area Name: Order Index Area
Size: 8192, Records/Block: 32, Area Number: 11, Cluster Size 64

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

Пример восстановления из полной копии

1. Введите следующую команду:

prorest newdev /dev/rrm/0m

Где,
newdev - это пустая база данных,
/dev/rrm/0m – определяет устройство с которого база данных будет восстанавливаться.

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

This is a full backup of /usr1/develop/devel.db. (6759)
This backup was taken Wed Nov 18 15:34:43 1999. (6760)
The blocksize is 1024. (6990)
It will require a minimum of 3065 blocks to restore. (6763)
Read 41 blocks in 00:00:02

2. Подключитесь к базе данных после окончания восстановления.

Пример восстановления из инкрементальной копии

Для восстановления инкрементальной копии, сначала необходимо восстановить полную копию, на которой основывается инкрементальная.

1. Введите следующую команду для восстановления инкрементальной копии, при условии, что полная копия уже восстановлена:

prorest newdev /dev/rrm/0m

Как видим синтаксис не изменился. На экране при начале восстановления появится следующая информация:

This is an incremental backup of /usr1/develop/devel.db. (6759)
This backup was taken Wed Nov 18 15:41:47 1999. (6760)
The blocksize is 1024. (6990)
It is based on the full backup of Wed Nov 18 15:34:43 1999. (6761)
It will require a minimum of 3065 blocks to restore. (6763)
Read 41 blocks in 00:00:00

2. Как только восстановление будет завершено, можно подключаться к базе данных.

Другие способы восстановления базы данных

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

Введение в механизм восстановления

OpenEdge RDBMS имеет три механизма восстановления:

Crash recovery - использует данные BI
Roll-forward recovery – использует резервные копии и After-image для восстановления после дисковых сбоев
Two-phase commit – гарантирует завершении транзакция между несколькими базами данных

В зависимости от ваших требований, можно использовать не все три механизма. Рисунок 6-1 показывает приоритеты этих механизмов. Crash recover использует BI лог (primary recovery log), и не требует вмешательства со стороны. Roll-forward recovery требует работы After-Imaging (AI). Two-phase commit требует использования лога транзакций (transaction log – TL). При использовании Two-phase commit необходимо также использование After-imaging.

Рисунок 6-1 Механизм восстановления OpenEdge

Каждый механизм использует описание изменений, для записи в файл и последующей записи в базу данных. Для примера, была сделана одна запись, изменившая один блок в базе данных. Движок базы данных автоматически записывает описание изменения в BI файл. Если after-imaging активирован, он также записывает описание изменения в AI файл (after-image log). Если активирован Two-phase commit, также записываются транзакции и описания изменений в TL файл (transaction log).

Crash recover

Этот механизм работает в автоматическом режиме. Он использует информацию из primary recovery log (BI), для восстановления после системных сбоев. BI файл является активной частью базы данных. Он рассматривается как неотъемлемая часть базы данных. Когда происходит копирование и восстановление базы данных, вместе с базой копируется и восстанавливается BI файл. Никогда не удаляйте файлы BI в ручную.

Когда база данных работает, информация о транзакциях базы хранится в трех местах:

В базе данных на диске
В буфере памяти
В BI файлах на диске

Когда изменяется запись в базе данных, сначала изменения происходят в памяти. Когда транзакция завершена, изменения записываются в BI файл. Со временем, движок базы данных вносит изменения в базу данных на диске. Если происходит системный сбой, информация, находящаяся в буфере памяти, теряется. Движок базы данных выполняет восстановление, используя информацию из BI файла, для восстановления потерянных транзакций, а транзакции, которые не были завершены к момент сбоя - отменяются.

Перед изменением базы данных, движок базы делает копию текущих данных и записывает ее в файл BI. Это происходит по завершению операции изменения. Если происходит системный сбой во время транзакции, движок базы восстанавливает из BI файла базу данных в предшествующее состояние. Движок использует информацию BI файла, также, и при нормальной работе, для отката транзакций.

Например, допустим, выполняется следующая программа на языке ABL (Advanced Business Language):

FOR EACH customer:
UPDATE name max-credit.
END.

Мы изменили записи о клиенте 1 и 2, и пока меняли данные о клиенте 3, произошел системный сбой. При перезагрузке базы данных (.lg), в логе базы данных появятся следующие сообщения:

11:13:54 Single-user session begin for marshall on /dev/pts/25 (451)
11:13:54 Begin Physical Redo Phase at 256 . (5326)
11:13:56 Physical Redo Phase Completed at blk 800 of 8165 and 31829 (7161)
11:13:56 Begin Physical Undo 1 transactions at blk 800 offset 8189 (7163)
11:14:38 Physical Undo Phase Completed at 1020 . (5331)
11:14:38 Begin Logical Undo Phase, 1 incomplete transactions are being backed out. (7162)
11:14:38 Logical Undo Phase Complete. (5329)
11:14:46 Single-user session end. (334)

В сообщении указаны фазы crash recovery, которые выполняет движок базы данных для приведения базы в состояние до системного сбоя. Движок выполняет crash recovery каждый раз, когда вы открываете базу данных, но не все фазы восстановления отображаются в логе базы. Например, движок выполняет и, безусловно регистрирует в логе фазу Physical Redo, но фазы Physical Undo и Logical Undo выполняет и регистрирует в логе только в случае обнаружения незавершенных транзакций.

Если после этого перезапустить программу, то мы обнаружим, что клиенты 1 и 2 были изменены, а клиент 3 остался без изменений, так как на основании BI файла движок вернул его информацию в первоначальное состояние.

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

Roll-forward recovery

Roll-forward recovery совместно использует after-imaging и резервную копию базы, позволяя восстанавливать ее после ошибок или после потери носителя. Используйте последнюю резервную копию, а затем roll-forward recovery для восстановления базы в состояние до возникновения ошибки или до потери носителя. Этот механизм использует информацию из AI файлов для последовательного наката транзакций, совершенных после формирования последней резервной копии, до возникновения сбоя.

Для использования механизма roll-forward recovery, необходимо:

Постоянно выполнять резервные копии, т.к. они являются основой для работы механизма.
Активировать на базе данных механизм After-imaging
Постоянно делать резервные копии сформированных AI - файлов.
Храните AI-файлы на другом диске, отличном от того на котором находятся база данных и BI-файлы.

При активированном After – imaging, информация об изменениях записывается движком базы в AI-файлы. Если ai-файлы будут храниться на том же диске, что и база данных или BI – файлы, то в случае повреждения диска, вы будете не в состоянии восстановить базу данных.

Следующий пример, показывает как AI – файлы используются для восстановления базы данных. Допустим, что выполняется следующая программа ABL:

FOR EACH customer:
UPDATE name max-credit.
END.

Вы изменяете клиентов 1 и 2, но в момент изменения данных о клиенте 3, происходит повреждение диска, на котором хранится база данных. Вы не можете использовать BI –файл для восстановления транзакций, т.к. база данных находится в поврежденном состоянии или полностью потеряна.

Тем не менее, если after-imaging был активирован, для восстановления базы можно использовать механизм roll-forward recovery. Иначе, мы потеряли бы все внесенные изменения в базу данных с момента формирования последней резервной копии.

Перед изменением базы данных, движок помечает изменения как текущие и сохраняет их в BI и AI файлы. AI-файлы содержат копии всех завершенных транзакций с момента последней резервной копии. Восстановите последнюю копию базы данных, и запустите механизм roll-forward recovery, для воспроизведения всех завершенных транзакций, таким образом, мы получим полноценную базу данных до момента сбоя.

Two-phase commit

Two-phase commit гарантирует, что транзакция между несколькими базами данных последовательно пройдет через все используемые базы. Two-phase commit не нужен для транзакций, работающих с одной базой данных.

Расположение файлов, гарантируещее безопасное восстановление

AI-файлы совместно с последней резервной копией базы данных, содержат ту же самую информацию, что и действующая база данных. Если теряется диск, содержащий DB и BI файлы, можно используя AI и резервную копию, восстановить базу данных. Соответственно AI - файлы логично хранить на другом диске, отдельно от файлов DB и BI. Рисунок 6-2 показывает пример безопасного расположение DB, BI, AI и Lg файлов.

Рисунок 6-2. Хранения файлов базы данных

Разработка плана восстановления

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

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

Какое количество транзакции вы можете потерять?
Как долго приложения, работающие с базой данных, могут находиться в Offline при проведении плановых работ, например формирование резервных копий?
Если база данных или операционная система становятся не работоспособными, сколько времени понадобится на их восстановление?
Если используются транзакции, работающие с многочисленными базами, можете ли Вы позволить себе нарушение целостности этих баз данных?
Как вы будет тестировать Ваш план?

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

Время, необходимое для восстановления

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

Основные принципы восстановления

Следуйте следующим принципам, для гарантированного восстановления.

Всегда:

Включите пошаговые инструкции и чек - листы в план восстановления
Держите копию плана восстановления на бумажном носителе
Регулярно копируйте базы данных
Расположите AI файлы отдельно от DB и BI файлов.
Помечайте, тестируйте и храните резервные копии в отдельном безопасном хранилище.

Ни когда:

Не храните BI файлы на одном диске с AI – файлами.
Не удаляйте файлы DB, AI или BI, если Вы не уверены, что база данных Вам больше не понадобится, или если у Вас отсутствует защищенная копия базы.
Не копируйте файлы базы данных отдельно от связанным с базой файлом BI.
Не восстанавливайте базу данных без соответствующего BI файла.
Не копируйте базу данных средствами операционной системы без применения к ней команды PROQUIT.

Предупреждение: если база данных запущена с параметром OpenEdge Unreliable Buffered I/O (-r) и произошел системный сбой, вы не сможете восстановить базу данных. Если использовался параметр No Crash Protection (-i) и произошел сбой в базе данных, вы не сможете восстановить её.

Команды After-imaging и Roll-forwad

В следующей таблице описано назначение основных команд After-imaging и Roll-forward commit. Более подробное описание будет приведено далее.

Команды утилиты	Функциональность
BUSY	Проверяет статус базы данных.
PROBKUP	Выполнение резервного копирования.
RFUTIL MARK BACKEDUP	Помечает базу данных как скопированную. Используется в случае, если резервное копирование выполнялось не средствами PROBKUP.
RFUTIL AIMAGE NEW	Запуск новых AI файлов. После того как база и ai- файлы будут скопированы, можно усечь файлы AI
RFUTIL AIMAGE END	Отключение after-imaging.
RFUTIL ROLL FORWARD RETRY	Перезапуск операции roll-forward. Используется для повторного наката ai-файлов, ранее прерванного из-за системного сбоя.

Восстановление после системных сбоев

Before-imaging активируется автоматически для обеспечения восстановления после системной ошибки. Если возник системный сбой – выбор техники восстановления зависит от операций, выполняющихся в момент сбоя.

Системная ошибка во время работы RFUTIL ROLL FORWARD

Если системная ошибка произошла во время работы команды RFUTIL ROLL FORWARD, вы можете использовать классификатор RETRY, и продолжить восстановление:

rfutil db-name -C roll forward retry

При использовании классификатора, RFUTIL находит транзакцию, восстановление которой из AI-файла происходило в момент системного сбоя, и продолжает восстановление, начиная с нее.

Системная ошибка во время работы других утилит

Если системный сбой произошел в момент работы указанных ниже утилит, просто перезапустите их:

BUSY
HOLDER
TRUNCATE BI
RFUTIL AIMAGE BEGIN
RFUTIL AIMAGE END
RFUTIL AIMAGE NEW
RFUTIL MARK BACKEDUP
RFUTIL ROLL FORWARD RETRY
RFUTIL AIMAGE AIOFF
RFUTIL AIMAGE END
RFUTIL AIMAGE SCAN
RFUTIL AIMAGE EXTENT EMPTY
RFUTIL AIMAGE TRUNCATE
RFUTIL AIMAGE EXTENT FULL

Системная ошибка во время резервного копирования базы данных

Если ошибка произошла во время формирования резервной копии базы данных – запустите процедуру копирования заново.

Системная ошибка во время работы базы данных

Если системная ошибка произошла во время работы базы данных – перезапустите базу данных. Автоматически включится механизм crash recovery и произойдет восстановление базы на основании данных в BI файле.

Предупреждение: если база данных запущена с параметром OpenEdge Unreliable Buffered I/O (-r) и произошел системный сбой, вы не сможете восстановить базу данных. Если использовался параметр No Crash Protection (-i) и произошел сбой в базе данных, вы не сможете восстановить её.

Восстановление после ошибок носителя

After-imaging, это комбинация резервной копии и механизма roll-forward используемых в случаях, если диск на котором находилась база данных разрушен, либо по другим причинам, когда другой механизм восстановления базы не возможен. After-imaging должен быть активирован заранее, прежде чем произойдет разрушение базы, также необходимо выполнять резервные копии баз, с которых будет восстановлена разрушенная база. Резервные копии и ai файлы, должны храниться как минимум до момента формирования новой копии.

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

Потеря файлов DB, BI

Если диск, на котором расположены файлы DB и BI, разрушен, или файлы были случайно удалены, восстановление возможно следующим образом:

1. Скопируйте текущие AI файлы и заполненные не архивированные AI файлы до начала наката. Это важный шаг, так как вы защищаете сами себя от возможной случайной перезаписи этих фалов. Не забудьте о том, что ai файлы должны храниться на носителе отличном от того, на котором размещена база данных. Ai файлы содержат информацию о всех транзакциях на любую дату.
2. Создайте структуру базы данных, в которую будет происходить восстановление.
3. Восстановите наиболее последнюю полную копию базы данных. Для восстановления инкрементальных копий, вы должны сначала восстановить полную копию, на которой они базируются.
4. Если активирован After-imaging, последовательно накатите файл за файлом на последнюю восстановленную копию, используя RFUTIL.
5. Сформируйте полную копию только что восстановленной базы данных.
6. Перезапустите after-imaging и two-phase commit, если это необходимо.
7. Перезапустите базу данных.
8. Перезапустите приложения и продолжите работать с базой данных.

Потеря AI файлов

Следующие шаги выполняются в случае, если диск, хранящий ai-файлы, был поврежден или файлы были случайно удалены.

1.    Если two-phase commit активирован для базы данных, завершите его работу утилитой PROUTIL 2PHASE END. Вы должны это выполнить до выполнения следующих шагов.
2.    отключите after-imaging, используя утилиту RFUTIL AIMAGE END.
3.    Сформируйте полную резервную копию базы данных, используя утилиту PROBKUP или с помощью утилит операционной системы.
4.    Если для копирования использовались утилиты операционной системы, пометьте базу данных как скопированную с помощью утилиты RFUTIL MARK BACKEDUP.
5.    Активируйте after-imaging
6.    Активируйте two-phase commit, так как он был деактивирован в шаге первом.

Потеря резервной копии

Если after-imaging активирован, вы можете восстановить потерянную или разрушенную базу данных путем наката ai-файлов на последнюю целую резервную копию.

1.        архивируйте текущие ai файлы, чтобы убедиться, что копия будет доступна, например, если случайно текущие заполненные ai файлы будут перезаписаны). Не забудьте о хранении ai-файлов на другом носителе.
2.        Восстановите копию, сделанную до потерянной копии. Если используются инкрементальные копии, то сначала восстановите последнюю полную копию, а потом накатите на нее инкрементальные.
3.        Восстановите Ai-файлы из архива до времени формирования потерянной или поврежденной копии.
4.        используйте утилиту RFUTIL ROLL FORWARD для наката разархивированных ai-файлов на базу данных.
5.        используйте утилиту RFUTIL ROLL FORWARD для наката текущих ai-файлов на базу данных.
6.        Сформируйте резервную копию, следуя стандартной процедуре резервирования
7.        Активируйте after-imaging и two-phase commit, если это необходимо.
8.        перезапустите базу данных.
9.        перезапустите приложения и продолжите работать с базой данных

Потеря лога транзакций – TL

Если не возможно получить доступ к базе данных из-за потерянного лога транзакций (TL), необходимо сначала деактивировать two-phase commit , а потом активировать снова.

1. PROUTIL 2PHASE END
2. PROUTIL 2PHASE BEGIN
3. Верните базу данных в online

Воостановление после нехватки места на диске

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

1. очистить диск от не нужных фалов
2. запустить базу данных, при этом запустится механизм автоматического восстановления

Если вы не в состоянии обеспечить необходимое свободное место на диске для того, чтобы отработал механизм восстановления, необходимо выполнить определенные шаги, которые зависят от того, какая информация хранилась на диске.

Диск с After-image файлами

Если after-image экстент переменной длины заполнил всё дисковое пространство, то база должна переключиться автоматически на следующий пустой экстент. Если же он окажется заполненным, то база данных остановится, если параметр запуска базы After-image Stall (-aistall) не был установлен.

Перезапуск базы данных после останова вследствие заполнения AI экстента:
1.    Сделайте копию последнего используемого полного ai экстента. Для его нахождения используйте утилиту RFUTIL AIMAGE EXTENT FULL.
2.    С помощью утилиты RFUTIL AIMGE EXTENT EMPTY пометьте его как пустой, для дальнейшего использования.
3.    Перезапустите базу данных.

Диск, содержащий Control или Primary recovery области

Процедура восстановления базы после окончания места на диске, зависит от того, находится ли bi экстент переменой длины на заполненном диске или нет. Если он находится на заполненном диске, вы не можете запустить базу данных, так как BI во время фазы восстановления растет.

Восстановление, если BI файл не на заполненном диске:
1.    Усеките BI файл утилитой PROUTIL TRUNCATE BI. Это позволит откатить все не завершенные транзакции в момент останова базы. Либо Вы можете также сделать тоже, если зайдете в базу в однопользовательском режиме.
2.    Добавьте экстенты в необходимые области утилитой PROSTRCT ADD.
3.    Перезапустите базу.

Восстановление, когда BI файл находится на заполненном диске:
1.    Используя утилиту PROSTRCT ADD, добавьте дополнительный BI экстент на диск со свободным местом. Максимально необходимое свободное место для дополнительного экстента и последующего восстановления, должно быть как минимум равно размеру заполненного текущего экстента. Если у вас имеется диск с достаточным местом, то поместите экстент на нем. Отметьте, что рост размер BI экстента при восстановлении это вполне нормальное явление. При добавлении экстента размер последнего экстента будет зафиксирован на уровне размера экстента в момент останова базы.
2.    Зайдите в базу данных в однопользовательском режиме. Это позволит отработать механизму crash recovery. Выйдите из однопользовательской сессии.
3.    Перезапустите базу в нормальном режиме.

Диск, содержащий лог транзакций (transaction log – TL)

Для восстановления после окончания места на диске с TL файлами, необходимо деактивировать two-phase commit.
1.    Для отключения two-phase commit используйте утилиту PROUTIL 2PHASE END.
2.    Усеките BI – файл
3.    Активируйте two-phase commit
4.    Запустите базу в нормальном режиме.

Усечение файла BI

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

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

Для усечения используется классификатор TRUNCATE BI утилиты PROUTIL:

proutil db-name -C truncate bi

Очистка разделяемой памяти

Если брокер базы «умер» или был «убит» средствами, не относящимися к средствам базы данных, например, вместо “proshut” использовалась команда ОС “kill”, он не в состоянии очистить за собой сегменты выделенной для него разделяемой памяти. Используйте PROUTIL –C DBIPCS для определения не очищенных сегментов памяти, а для их удаления используйте команду Unix ОС ipcrm –m.

Утилита PROUTIL DBIPCS отображает сегменты разделяемой памяти, закрепленные за всеми базами данных OE Progress:

proutil -C DBIPCS

Для работы утилиты не нужно указывать имя базы данных.

Вот что отобразится на экране после запуска:

OpenEdge SHARED MEMORY STATUS
ID   ShMemVer   Seg#   InUse   Database
68   -                       -          -            (not OpenEdge)
100 3                       0          Yes       /db/work5/sports
101 3                       1          -           /db/work5/sports
120 3                       0         No         /db/work5/test
150 2                        -            -         (unsupported shared memory version)

В таблице 6-6 описано назначение столбцов

Столбец	Описание
ID	ID разделяемой памяти
ShMemVer	Версия разделяемой памяти
Seg#	Номер сегмента разделяемой памяти. Одна база может иметь множество сегментов
InUse	Статус использования сегмента. Yes или No указывается только для сегментов с номером 0. Для всех других отображается дефис (-). Для определения, используется ли сегмент, необходимо найти сегмент с номером ноль и посмотреть его статус.
Database	Указывается полный путь к базе данных, которой принадлежит сегмент

Восстановление потеряной или поврежденной контрольной области

В случае, если контрольная область (DB) потеряна или повреждена, используйте для ее восстановления утилиту PROSTRCT BUILDDB. Утилита восстанавливает контрольную область из имеющегося структурного файла (.st). Пример:

prostrct builddb db-name structure-description-file

Где,
db-name
       Имя базы данных

structure-description-file
       имя структурного файла для восстановления. Если оно не определено, то по умолчанию        используется st- файл восстанавливаемой базы – db-name.st

Разблокировка поврежденной базы данных

В базе данных может возникнуть несоответствие между экстентами из-за неправильного использования системных утилит копирования или некорректного административного использования утилит резервного копирования и восстановления. Движок базы данных синхронизирует файлы DB, BI и AI, гарантируя их согласованность. Если он обнаруживает несоответствие в этих файлах, он выдает сообщение об ошибке и пресекает любые попытки открыть базу данных. Если это произошло, попытайтесь восстановить базу данных с резервной копии. В качестве последней попытки, вы можете использовать утилиту PROSTRCT с классификатором UNLOCK, чтобы разблокировать базу и выгрузить данные. Используйте этот классификатор только, и только если больше ни чего не помогло. Заблокированная база данных может и не разблокироваться, либо результатом разблокировки может стать разрушение базы данных.

Для разблокировки поврежденной базы сделайте следующее:

1.    Введите следующую команду:

prostrct unlock db-name

2.    Выгрузите данные из разблокированной базы.
3.    Выйдете из базы.
4.    Создайте новую, пустую базу данных
5.    Стартуйте новую базу, загрузите в нее описания таблиц и ранее выгруженные данные.

Выгрузка таблиц из поврежденной базы данных

Бывают случаи, когда данные повреждены, и попытки перекомпиляции базы просто не работают. Тогда, вы можете использовать следующие ABL код для выгрузки данных, на примере таблицы “item”. К сожалению, подобная выгрузка будет работать очень медленно для больших таблиц. Прибегать к этому способу желательно только в случае, если переиндексации не возможна.

DEFINE VARIABLE i AS INTEGER.
FIND _file "item".
OUTPUT TO item.d.
DO i = 1 TO 10000:
    FIND item WHERE RECID(item) = i NO-ERROR.
    IF AVAILABLE item AND i <> INTEGER(_file._template)
   THEN EXPORT item.
END

Этой программой данные из таблицы “item” будут выгружены в файл “item.d”, который в свою очередь и должен быть использован для загрузки данных этой таблицы в новую базу.

Значение, установленной в блоке DO, может быть и выше, рассчитать наиболее безопасное значение можно по формуле:

100 + 32 (database-size-in-bytes / database-block-size)

Размер блока базы может меняться в зависимости от ОС. Для того чтобы убедиться в размере блока базы для вашей системы, используйте утилиту PROSTRCT STATISTICS.

Принудительный достпу к поврежденной базе

Если восстановить доступ к базе данных не представляется возможным, вам остается только восстановить ее с резервной копии. Ну, а если копии нет, и больше не существует альтернативных путей, то можно получить доступ к поврежденной базе, используя параметр “-F”.

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

Для принудительного доступа:

1. Создайте резервную копию базы данных.
2. Запустите команду PROUTIL c параметром –F:

proutil db-name -C truncate bi -F

Вы получите следующее сообщение:

The -F option has been specified to . (6260)
Forcing into the database skips database recovery. (6261)

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

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

Follow @vbashkatov

© 2009 - 2011 Все права на материалы, находящиеся на сайте www.openedge.ru, охраняются в соответствии с законодательством РФ, в том числе, об авторском праве и смежных правах.
При любом использовании материалов сайта ссылка на источник обязательна.