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

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

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

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

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

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



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

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

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



ОСОБЕННОСТИ РАБОТЫ С БАЗОЙ ДАННЫХ



В данной части будут кратко описаны некоторые моменты работы OE Replication.

Целостность

OE Replication для поддержания целостности базы данных обеспечивает обработку сбойных ситуаций (failure process). Поддержание целостности базы данных - это основная административная задача, т.к. как от целостности базы зависит работа всех пользователей системы. Поскольку цель работы OE Replication - это поддержка в идентичном состоянии минимум двух баз, целостность этих баз играет немаловажную роль и для репликации. Для достижения целостности OE Replication использует механизм синхронизации. Однако наличие двух синхронизированных баз не означает, что репликация может полностью заменить обычное резервное копирование баз данных. OE Replication является лишь одной из составляющих системы резервного копирования и восстановления.

Как только source-база запущена, менеджер базы начинает выполнять различные действия для обеспечения устойчивости базы данных к различным воздействующим факторам. Основным таким фактором является изменение содержимого базы данных пользователями, следовательно, OE Replication должен обеспечить копирование измененных данных на target-базы. Все изменения, которые могли произойти во время старта source-базы, реплицируются на target-базы путем синхронизации агентов и сервера репликации.

Доступность

Ещё одна функция OE Replication - это обеспечение доступности базы данных в случае возникновения сбойной ситуации. Поскольку OE Replication выполняет копирование данных на одну или более target-баз, любая целевая база может быть использована в случае недоступности основной, т.к. является её точной копией. Процесс перехода target-базы в source называется transition.

Режим ERO (Enhanced Read-Only)

После запуска агента репликации target-база переходит в режим Enhanced Read-Only (ERO). В этом режиме все пользователи базы данных имеют доступ только на чтение данных. Это означает, что любой пользователь или процесс не может изменить ее данные или получить блокировку записей, исключением является агент репликации.

ERO режим в отличие от RO (Read-Only) режима является режимом сервера базы данных. Режим предоставляет пользователям все возможности базы данных, такие как буферный пул, разделяемые (shared) и частные (private) буфера.

Режим Read-Only (RO) устанавливает ограничения на стороне клиента, в то время как Enhanced Read-Only (ERO) устанавливает их на стороне сервера.

В случае возникновения сбойной ситуации на source-базе и после выполнения процесса transition на target-базе все пользователи получают полный доступ. Тем не менее имеющиеся соединения будут отключены, но как только они переподключатся, то также получат полный доступ.

Блокировка схемы (schema lock)

Когда схема source-базы изменяется, происходит ее блокировка. Сервер репликации передает информацию о блокировке схемы агенту репликации, тем самым вызывая блокировку на target-базе. При этом информация о блокировке записывается агентом репликации в лог target-базы.

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

Альтернативой этому может быть установка параметра Schema-Lock-Action. Когда параметр установлен, агент будет пять раз пытаться получить блокировку схемы target-базы. Если после пятой попытки блокировать схему так и не получилось, то агент принудительно отключит всех пользователей и повторит попытку блокировки. Если же и эта попытка окажется неудачной, работа сервера и агента репликации будет завершена. Это позволит source-базе продолжить нормальную работу. По завершении корректировки схемы source-базы, агент и сервер репликации должны быть перезапущены.

Принудительное усечение before-image файла source-базы данных

Для принудительного усечения BI-файла используйте следующую команду:

proutil db-name -C truncate bi -F

При этом следует помнить, что после выполнения команды механизм after-imaging перестает работать, а после перезапуска базы выполняется следующее:

  • в логе базы будет зарегистрировано сообщение об отключении after-imaging;
  • OE Replication будет отключен;
  • база данных остановлена.

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

Точки останова (quit points) target-базы данных

Если на target-базе будет активирована точка останова (quit point), то source-база будет заблокирована. Блокировка будет удерживаться до тех пор, пока не будет снята точка останова на target-базе.

Выполнение online backup

В предыдущих версиях OE Replication выполнение online backup на target-базе было возможно только в процессе операции transition. Начиная с версии 10.1С online backup можно выполнять вне transition, т.е. в любое время, когда target-база запущена. Агент OE Replication - это по-прежнему единственный процесс, который может изменять target-базу, но в случае с online backup никаких изменений базы не происходит. Процесс backup только блокирует буфер и блоки, а не записи базы данных.

Во время выполнения online backup на target-базе активность source-базы сохраняется, пока выполняются следующие условия:

  • репликация выполняется в асинхронном режиме
  • сервер репликации способен получить блокировку разделяемой схемы source-базы, т.е. он должен иметь возможность получить эту блокировку на время работы процесса синхронизации
  • достаточно свободного пространства в AI-экстентах source-базы 

Выполнение online backup на target-базе ничем не отличается от обычного online backup на обычной базе, синтаксис команды тот же:

probkup online db-name [incremental] device-name [parameters]

Что происходит во время выполнения этой команды?

Для того чтобы online backup был успешно выполнен на target-базе, необходимо согласовать работу этого процесса с работой OE Replication. Далее будет описано, что происходит с системой при запуске команды PROBKUP:

  • Если агент репликации активен:
    • Утилита probkup посылает агенту репликации сообщение о том, что скоро начнется процедура online backup.
    • Агент репликации информирует сервер репликации о начале online backup на target-базе, при этом проверяется, что:
      • target-база на текущий момент не заблокирована (не активирована точка останова “quiet point”, не включен BI stall или AI stall, или не выполняется другой online backup)
      • агент репликации имеет связь с сервером репликации
      • на текущий момент не выполняется процесс синхронизации
  • Затем происходит одно из следующих действий:
    • Если сервер репликации способен получить блокировку разделяемой схемы на source-базе, и выполняется асинхронная репликация, то сервер репликации помечает базу данных как busy. Это позволяет базе продолжать нормальную работу. Затем сервер репликации отправляет положительный ответ агенту репликации.
    • Если же сервер репликации не может получить блокировку разделяемой схемы, он уведомляет об этом агента репликации, который в свою очередь сообщает пользователю, запустившему probkup, о невозможности выполнения процедуры на текущий момент.
  • Если агент репликации получает положительный ответ от сервера репликации, то online backup-у позволяется продолжать работу.
  • Утилита probkup выполняет работу.
  • Когда online backup завершен, агенту репликации отправляется соответствующее сообщение о завершении резервирования.
  • В свою очередь агент репликации отправляет сообщение о завершении работы probkup серверу репликации.
  • Сервер репликации запускает процесс синхронизацию с целью передачи всех изменений, сделанных во время выполнения online backup, с source-базы на target-базу. Как только синхронизация будет завершена, сервер репликации вернется к нормальному процессу работы.
  • Процесс online backup завершен.

Previous pageReturn to chapter overviewNext page




Главная |  Статьи |  Книги |  Гостевая |  Ссылки |  От автора |  Download ProKb


������ ᠩ� pr Online ProKB Blogger Welcome to Russian Progress Users Group at Facebook Welcome to Russian Progress Users Group at LinkedIn
© 2009 - 2011 Все права на материалы, находящиеся на сайте www.openedge.ru, охраняются в соответствии с законодательством РФ, в том числе, об авторском праве и смежных правах.
При любом использовании материалов сайта ссылка на источник обязательна.