ProD&L, и как с ним работать

 
Время простоя

Что нужно знать для оценки времени простоя?

- Время выполнения резервной копии Production Database.
- Время восстановления Production Database из резервной копии.
- Время, необходимое для наката (apply) полного (full) AI экстента.
- Время работы команды proutil dbanalys.

Уже ясно, что Pro D&L предназначен для сведения времени простоя промышленной базы данных к абсолютному минимуму. Общее время простоя может быт разделено на две стадии, и может быть определено следующим образом:

Phase 1

Это:
- Время, необходимое для остановки Production Database (далее этот термин будет означать что речь идет о промышленной базе данных).
- Время, для выполнения полной offline резервной копии Production Database. Продолжительность этого шага может быть сильно уменьшена, если включен механизм After Imaging. Подробнее об этом будет рассказано позже.
- Время, для добавления кода репликационных триггеров (Replication Triggers) в схему Production Database – это достаточно быстрая процедура.
- Время, для перемещения измененных стартовых скриптов и файлов параметров.
- Время, для перезапуска Production Database.

Как только первая стадия завершена, можно начать процедуру dump/load на копии Production Database. Все изменения, сделанные Progress-клиентами, во время выполнения dump/load, будут дублироваться во вспомогательной базе данных, которая в этом документе будет называться Replication Database. Когда dump/load будет завершен, большинство изменений, сделанных в Production Database за время его выполнения, будут записаны в новую базу данных, которую мы будем называть New Database. Как только этот процесс будет завершен, Production Database будет необходимо остановить во второй раз. Это будет переходом ко второй стадии.

Phase 2

Это:
- Время, для остановки Production Database;
- Время, для выполнения полной offline резервной копии Production Database, на случай, если во время процесса репликации возникнут ошибки. Это время так же может быть значительно сокращенно, если на этой базе работает механизм репликации;
- Время, для наката оставшихся репликационных данных на New Database;
- Необязательно, но может понадобиться - время, для выполнения dump/load небольших таблиц, которые не имеют индексы или не имеют уникальных индексов;
- Время, для копирования (или восстановления из резервной копии) New Database на место старой Production Database, далее Old Production Database;
- Время, для активации After Imaging, если используются AI. Заметьте, что этому процессу необходима полная резервная копия. Тем не менее, время этого шага можно так же сократить;
- Время, чтобы переформатировать файл Before Image с помощью proutil bigrow;
- Время, для восстановления стандартных скриптов запуска и файлов параметров;
- Время, для перезапуска базы данных.

Кратчайшие пути к дальнейшему уменьшению времени простоя

Если New Database не должна располагаться в том же месте что и Old Production Database, или если имя New Database будет отличаться от имени Old Production Database, то полная offline копия, описанная во второй стадии, не обязательна. Исключением является необходимость активации After Imaging для New Database.

Иной способ уменьшить время копирования под  Unix/Linux может быть следующий:
- Демонтируйте файловую систему с Old Production Database.
- Смонтируйте файловую систему с New Database, используя тоже имя каталога, как и у  Old Production Database.

Еще один способ, это перемещение .db файла Old Production Database в иное место, и копирование .db файла от New Database на место .db файла Old Production Database. После чего будет необходимо запустить prostrct repair, для обновления путей, хранящихся в .db файле. Этот метод будет детально описан позже.

Используйте After Imaging вместо выполнения двух offline копий Production Database (по одной на каждую фазу). Вместо выполнения полного offline копирования, можно создать копию Production Database и периодически накатывать на нее AI файлы, тем самым, поддерживая ее в актуальном состоянии. Настройка такого горячего резервирования может быть выполнена в любое время до запуска Pro D&L. Когда же понадобится offline копия для процесса Pro D&L, будет необходимо выполнить следующее:
    Остановить Production Database.
    Запустить команду rfutil aimage new.
    Скопировать все FULL AI экстенты.
    Пометить все FULL AI экстенты как EMPTY с помощью rfutil aimage empty.
    Перезапустить Production Database (только на первой стадии, для второй стадии необходимо выполнить дополнительные шаги перед перезапуском).
    Накатить все скопированные FULL AI экстенты на копию базы данных.

Во время второй стадии, если необходимо активировать After Imaging, но времени для выполнения полного offline копирования необходимо слишком много, то можно прибегнуть к следующим рекомендациям:
    Когда вы готовы к перезапуску New Production Database, пометьте ее как скопированную (backed up) с помощью rfutil mark backedup. Фактически, таким образом база данных Progress будет обманута, поскольку на самом деле она не скопирована.
    Запустите брокер базы данных.
    Немедленно запустите online копирование базы с помощью probkup online. Это инициирует переключение (switch) AI экстента. AI экстент, который был в состоянии BUSY, когда запускался probkup может быть отвергнут, поскольку отсутствует настоящая полная копия, и в этом есть риск. Все транзакции в этом экстенте потенциально могут быть потеряны, если будет необходимо восстановить базу данных. Поэтому, этот способ можно использовать, только если у вас имеется оригинальная Old Production Database, либо ее копия.

Некоторые производители «железа», поддерживают так называемые «снимки дисков» (“snapshot”). Снимок – это копия диска, которая может быть сделана очень быстро, обычно используя некоторую разновидность тройного зеркалирования (triple mirroring). Эту возможность можно будет интегрировать с Pro D&L для быстрого создания резервных копий. 

Требования к использованию Pro D&L

1.    Должен быть в наличии Progress V8.2 или выше.
2.    Должна быть возможность изменять схему базы данных (Schema changes) для добавления триггеров репликации (Replication Triggers). Для этого необходимо иметь полную лицензию для разработки (Progress 4GL Development). Поскольку будет необходимо генерировать и компилировать коды репликационных триггеров.
3.    Не должно существовать репликационных триггеров на промышленной базе данных. Если же они имеются, то:
    Существующие триггеры должны быть временно отключены или удалены, при условии, если это не повлияет на работу системы.
    Если такие триггеры имеются только у отдельных таблиц, то можно выполнить их dump/load в ручную во время второй стадии. Это имеет смысл только в случае, если такие таблицы имеют не большие размеры. В противном случае, вторая стадия может затянуться неприемлемо долго.
    Возможен вариант, когда к коду репликационных триггеров в Pro D&L будет добавлен код репликационных триггеров вашего приложения, но это трудоемкая задача, о которой надо подумать заранее.
4.    Нельзя использовать ABL операцию “DISABLE TRIGGERS” в приложениях, если для нее не включена опция ALLOW-REPLICATION. В противном случае, необходимо остановить работу программ, которые используют “DISABLE TRIGGERS” на время работы Pro D&L. Если используются приложения третьих лиц или приложения наемных разработчиков, то обратите на это особое внимание, поскольку это очень критично. Если невозможно проверить код или остановить использование таких программ, то во время второй стадии такие таблицы нужно будет выгрузить и загрузить (dump/load) вручную.
5.    Таблицы без уникальных индексов или без индексов вообще, требуют специальной обработки. Мы будем называть такие таблицы NUI (No Unique Index). Программа обследования (survey.p) идентифицирует такие таблицы. Для их обработки возможны следующие варианты:
    Dump/load таких таблиц в ручную во время второй стадии. Этот метод имеет значение, если количество записей в таблице очень маленькое, что позволит выполнить их перезагрузку (dump/load) достаточно быстро. Это время можно оценить с помощью тестовой выгрузки.
       Если возможно, то постарайтесь почистить NUI таблицы, для ускорения перезагрузки.
       Если можно гарантировать, что некоторые из таких таблиц на 100% являются статическими, то для ускорения ручной выгрузки во время Pro D&L можно заранее сделать их выгрузку и очистить таблицу.
    Pro D&L имеет специальную функцию для обработки подобных таблиц, которая использует так называемый Xref - метод. Этот метод усложняет работу процесса dump/load, увеличивая время его работы, но при этом может исключить ручную обработку NUI таблиц каких бы размеров они не были. Xref - метод будет обсужден подробно позже.
    Другие возможности:
    Можно временно добавить новый уникальный индекс, и удалить его когда dump/load будет завершен. Либо можно будет оставить этот индекс, для предотвращения проблем в будущем.
    Сообщите разработчику своей системы, что необходимо лучше изучить основы баз данных, поскольку хорошая реляционная база должна иметь в каждой таблице хотя бы один уникальный индекс.
6.    Должна быть возможность хранения репликационных данных (Replication Data) в промышленной базе данных или в иной базе, называемой Replication Database. Существуют различные преимущества и недостатки у каждого из этих методов.

Преимущества отдельной базы – Replication Database:
    Если на промышленной базе используется After Imaging, то все репликационные данные будут попадать в промышленные AI файлы. Это может привести к проблеме производительности и потребовать дополнительно дискового пространства для AI данных.
    Если репликационные данные хранятся в промышленной базе, то в определенный момент времени они должны быть удалены. В версиях V9/V10 удалить их не составит труда с помощью proutil truncate area, при условии, что они хранятся в отдельной области хранения (Storage Area). При этом схема для хранения репликационных данных, так же должна быть удалена.
    Проще скопировать Replication Database на отдельную машину, на которой будут происходить процессы наката, чем если бы эти процессы должны были бы устанавливать удаленное соединение с New Database. Как альтернативное решение, можно конечно развернуть New Database на промышленной машине, но выполняемые процессы, в этом случае, могут существенно снизить производительность системы в целом.
    Большой объем выполняемых транзакций процессами Pro D&L может также негативно отразиться на Production Database, поскольку Replication Database выполняет дублирование транзакций промышленной базы и обновление New Database.

Недостатки отдельной базы – Replication Database:
    Возможность возникновения несбалансированной транзакции, если не используется Two Phase Commit (2PC), и во время работы транзакции произойдет какой-либо сбой. К сожалению, использование 2PC это большая административная проблема, которая к тому же влияет на производительность. Окно уязвимости, хоть и не большое, но существует. Для появления несбалансированной транзакции необходимо чтобы системный сбой произошел ровно в середине выполнения транзакции.
    На операционных системах IBM и AIX, если промышленная база данных использует в общем 11 сегментов разделяемой памяти (shared memory segments), клиентский процесс (Client process) не сможет подключиться к Replication Database если количество сегментов используемых для промышленной базы не будет уменьшено путем уменьшения значения Buffer Cache (-B) на одной или более базах. К счастью, для Replication Database необходим только один сегмент.
    Поскольку каждый клиент теперь имеет дополнительный коннект, то возможно будет необходимо увеличить параметр Maximum Number of Connected Databases (-h) в клиентских скриптах запуска и файлах параметров. По умолчанию это значение равно 5.
    С дополнительной базой, количество открытых файлов в операционной системе возрастет. В некоторых операционных системах (ОС) это значение регулируется параметром «ядра». Возможно, вам придется увеличить его.
    Когда используется отдельная Replication Database, необходимо будет изменить стартовые скрипты и/или файлы параметров, для подключения к Replication Database из Production Database. Этот шаг может значительно усложниться, поскольку изменениям должны быть подвергнуты все 4GL клиенты, которые изменяют промышленную базу данных. А именно: Interactive Character Clients; Interactive GUI Clients; WebSpeed Agents; AppServers; Batch Processes. Альтернативой этому может быть использование функции Auto-Connect. В данном случае, Replication Database не будет подключаться при запуске сессии. Вместо этого, если клиент запросит таблицу, которая имеется в Replication Database, Progress автоматически подключится к этой базе и оставит соединения до завершения сессии. Более подробно об этом будет рассказано позже. Так же стоит отметить, что если к промышленной базе подключаются удаленные клиенты (Remote Clients), используя –H/-S, то для Replication Database необходимо запустить брокера с указанием порта или имени сервиса, и значения –H и –S этой базы должны быть добавлены в параметры удаленных клиентов. Лучше, если перед остановкой промышленной базы данных, для начала первой стадии, провести тестирование подключений к «фиктивной» Replication Database. Это поможет предотвратить возможные проблемы уже в процессе первой стадии.
7.    PROPATH используемый для 4GL клиентов должен быть изменен с целью включения пути расположения репликационных триггеров (Replication Triggers)
8.    Необходимо достаточно дискового пространства для: промышленной базы данных; Replication database (формулу расчета ее размера см. ниже); копии базы данных (копия промышленной базы, созданная на первой стадии); новой базы данных (создана во время dump/load); база «горячего резервирования» (Warm Spare), если используется; dump – файлов; файлов сортировки для переиндексации.
9.    Дисковое пространство не обязательно должно находиться на одной машине.

Расчет размера Replication Database

Для расчет размера Replication Database понадобится:
- Найти самый большой размер записи (используя proutil dbanalys), например, из 10 самых больших таблиц. Если значение окажется не нормально большим, то можно взять среднее.
- С помощью promon (#5 Activity) соберите информацию за 24 часовой период по следующим полям: Record Updates, Record Creates и Record Deletes. Выберите день или дни которые имеют обычную транзакционную активность.
- Необходимо знать, сколько дней промышленная база будет находиться между стадиями один и два, пока выполняется dump/load на ее копии.

Итоговая формула следующая:

((updates + creates + deletes) * (record size) * (days of activity)) * 1.25

Обратите внимание, что в Pro D&L имеется меню для мониторинга High Water Mark на Replication Database.
- Рекомендуется приостановить любые процессы, которые выполняют большие модификации данных в Production Database (например, чистка данных) между первой и второй стадиями, поскольку это сильно влияет на увеличение размеров репликационных данных и потенциально увеличит время простоя, когда эти данные будут вноситься в New Database.
- Результат последнего dbanalys должен быть использован для определения записей, размеры которых будут слишком большими для обработки Pro D&L. Pro D&L не может обрабатывать записи более чем примерно 15Kb.
- Определите замороженные (Frozen) таблицы в базе данных. Они должны быть разморожены для добавления репликационных триггеров во время первой стадии, и заморожены вновь во время второй. Пример программы определяющей замороженные таблицы приведен ниже, в будущих версиях эта возможность будет включена в качестве функции Pro D&L:

output to frozen.txt.
for each _file no-lock
where _file-num > 0
and _file-num < 32767
and _frozen:
      export _file-name.
end.

Предостережения и ограничения

Производительность промышленного приложения может упасть из-за дополнительной нагрузки связанной с запуском репликационных триггеров. Рекомендуется использовать параметр Quick Request (-q) для всех клиентов, с целью уменьшения влияния запуска триггеров. Другой способ, доступный только для V9/V10, это использование Shared Procedure Libraries, или еще называют Memory Mapped Procedure Libraries. Для поиска дополнительной информации по этому вопросу обратитесь к документации, ключевые слова: makeshared и prolib.

Dump/load так же влияет на производительность, поэтому рекомендуется выполнять его на другой машине.

Изменение схемы не должно выполняться во время всей работы Pro D&L.

Параметр Date Format (-d) должен быть одинаковым для всех клиентских сессий. Желательно установить его в $DLC/startup.pf и удалить из всех скриптов запуска, в других файлах параметров и т.п. Если имеется более чем один DLC, необходимо настроить startup.pf для каждого из них.

Использование параметра запуска Schema Cache (-cache) может привести к несрабатыванию репликационных триггеров. Для решения проблемы можно сгенерировать новый Cache файл после добавления репликационных триггеров и восстановить оригинал после завершения Pro D&L; удалить –cache из клиентских параметров на время работы Pro D&L, но это может привести к потере производительности для удаленных клиентов, использующих подключения через Wide Area Network.

Pro D&L может работать только с одной базой данных, т.е. перезагрузка может быть выполнена за один раз только одной базы.

Любые процессы использующие JDBC/ODBC для изменения промышленной базы данных должны быть остановлены на время выполнения Pro D&L. Как альтернатива этому, нужно определить, какие таблицы изменяются этими процессами, и выполнить dump/load для них во время второй стадии, как в случае с NUI таблицами.

Если используется OpenEdge Replication, то на время выполнения Pro D&L необходимо выполнить некоторые процедурные изменения на случай failover события:
    Прежде всего процесс Pro D&L должен быть прерван, поскольку возникновение события failover подразумевает наличие проблемы;
    Перед тем как разрешить доступ пользователей к target базе данных, необходимо удалить из нее репликационные триггеры. Эти триггеры находятся в целевой базе, поэтому они были реплицированы на target базу с помощь OpenEdge Replication. Используйте опцию меню Pro D&L чтобы удалить их. 

Подготовка

Перед началом работ на Production Database, протестируйте весь процесс на какой-нибудь небольшой тестовой базе данных.

Сгенерируйте копию Data Definitions (.df) на  Production Database. Запустите программу survey.p для той же базы с целью проверки наличия default индексов, репликационных триггеров и т.п. Программа не вносит какие-либо изменения и не работает долго, поэтому она безопасна для работы на промышленной базе данных.

Запустите proutil tabanalys или dbanalys. Проверьте полученный отчет на наличие записей размером более 15Kb.

В состав дистрибутива Pro D&L входят два файла в формате Excel:
- preparation_checklist.xls – чек-лист, используемый до начала работ;
- live_checklist.xls – чек-лист, используемый во время работы Pro D&L.

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

Действие	Продолжительность
Phase 1 Остановка промышленной базы данных
Phase 1 Формирование резервной копии промышленной базы
Phase 1 Установка репликационных триггеров  Pro D&L
Phase 1 Установка новых скриптов и файлов параметров
Phase 1 Перезапуск промышленной базы данных
Восстановление из резервной копии промышленной базы
Выгрузка данных (dump) из восстановленной промышленной базы
Загрузка данных (load) в новую промышленную базу
Перестройка индексов (idxbuild) новой промышленной базы данных
Сравнение данных старой и новой баз данных
Формирование резервной копии новой промышленной базы данных
Запуск наката репликационных данных из Replication DB в New DB
Phase 2 Остановка промышленной базы данных
Phase 2 Формирование резервной копии старой промышленной базы
Phase 2 Завершение наката репликационных данных
Phase 2 Ручной dump/load NUI-таблиц, если имеются
Phase 2 Dump/load Sequences, User Table, SQL92, и т.п.
Phase 2 Загрузка  триггеров в New DB
Phase 2 Формирование полной резервной копии для AI
Phase 2 Сверка старой и новой баз данных
Phase 2 Копирование новой базы данных поверх старой
Phase 2 Включение After Imaging
Phase 2 Перезапуск новой промышленной базы данных

Установка и настройка

Все программы, упомянутые в этом документе, разработаны для символьного режима (TTY). И так, начнем.

Определите таблицы, которые не должны реплицироваться. Например:
- Пустые временные таблицы. Это таблицы, которые не имеют постоянных данных;
- Производные (derived) таблицы. Это таблицы содержащие данные, являющиеся производными от данных других таблиц, а следовательно, они могут быть легко восстановлены.
- Таблицы Аудита (Auditing).
- Таблицы, не имеющие уникальных индексов. Они не должны реплицироваться:
    если могут быть выгружены во время второй стадии;
    если не использован Xref - метод для их обработки.

Таблицы из этой категории обычно не имеют большого количества записей.

Преимущества освобождения таблиц от репликации:
- маленький размер Replication Database;
- улучшение производительности, но тем не менее, не возможно заранее сказать будет это хорошо или нет.

Недостаток: процесс Pro D&L становится более сложным из-за дополнительных шагов.

Если имеются такие таблицы, ссылки на них в репликационных триггерах (Replication Triggers) Pro D&L должны быть удалены из Data Dictionary. Существует программа, которая может удалять репликационные триггеры из отдельных таблиц. Фактическое удаление репликационных триггеров будет выполнено во время первой стадии.

Загрузите файлы Pro D&L на машину, где располагается Промышленная база данных.

Если вы выбрали отдельное расположение Replication Database, то следующая часть для вас, если нет, то перейдите к части «Репликационные данные в Production Database». 

Отдельная Replication Database

Создайте 8-килобайтную пустую Progress базу данных (empty8.db) в каталоге с достаточным свободным дисковым пространством для хранения Репликационных данных. В прочем, размер блока базы остается на ваше усмотрение. Имя базы данных должно быть уникальным, чтобы не путать с именами промышленных баз. Затем загрузите Data Definitions (.df) с помощью Progress Data Dictionary. Для V9/V10 используйте image.df. Этот  файл содержит описания таблиц Replication Database, которые загружаются в отдельную область хранения. Для создания базы используйте структурный файл image10.st. Он содержит ссылку на область хранения prodl_data, в которую и будет загружена информация из .df файла.

Replication Database должна быть создана как многотомная с экстентами фиксированного размера, чтобы избежать зависаний при росте базы. Для дополнительной безопасности будет полезным включить поддержку больших файлов с помощью proutil EnableLargeFiles. Это позволит расти переменным данным и BI экстентам свыше 2Гб, если конечно же файловая система позволяет.

Заметьте, что BI файл Replication Database может вырасти больше 2Гб быстрее чем BI файл на Production Database. Это потому, что размеры записей в Replication Database больше чем в Production database. Следовательно, если в промышленной базе данных могут возникать большие транзакции, необходимо убедиться в следующем:
- места на дисках для BI файла должно быть выделено достаточно;
- размеры BI экстентов должны быть определены верно. Например, если используется один экстент переменной длины, то если не включена поддержка больших файлов, он может превысить предел в 2Gb, что не хорошо. В этом случае, лучше создать один экстент фиксированного размера, примерно до 2Гб, а второй переменного. Это позволит BI файлу вырасти до 4 Гб при необходимости.
- параметр –bithold для Replication Database должен быть выставлен пропорционально больше по сравнению с Production Database.

Replication Database должна быть настроена аналогично Production Database. Вот основные руководящие принципы:
- Должно быть достаточно много экстентов фиксированной длины для области с данными;
- BI Cluster size должен быть таким же как у Production Database (proutil –bi);
- По возможности расположите BI файл Replication Database на отдельном диске;
- Если имеется достаточно системной памяти – увеличьте Buffer Cache (-B) до 32Мб (-B 4096 для 8Кб размера блока базы);
- Для многопроцессорных систем установите –spin равным 10 000, либо таким же как и на промышленной базе;
- -bibufs равным 32, либо таким же как и на промышленной базе;
- Lock Table (-L) должен быть больше минимум в полтора раза (1,5) чем на промышленной базе;
- User Table (-n) должен быть равен –n на промышленной базе;
- Direct I/O (-directio) – только если он используется на промышленной базе;
- Если к промышленной базе подключаются удаленные пользователи (-H/-S), то для Replication Database также определите Service name (-S), Max Servers (-Mn) и Max Clients per Server (-Ma). Последние два лучше установить как на промышленной базе. Даже если нет удаленных (remote) клиентов, все равно будет полезно установить параметр –S, для обеспечения удаленного подключения к New Database;
- Добавьте –bithold, чтобы не допустить рост BI файла до не нормального размера;
- Добавьте –bistall;
- Запустите два процесса APW;
- Запустите один BIW;
- Если используется параметр –Mm, то Replication Database должна иметь тоже значение что и другие базы данных;
- Права на файлы (file permissions) для Replication Database, должны быть такие же, как у промышленной базы;
- Вы можете запустить After Imaging для Replication Database. Не ради безопасности, а ради облегчения наката транзакций на New Database, если она находится на другой машине. Прежде чем принять такое решение, вам нужно прочитать часть \"Накат Replication Database Data (RDD) на New Production Database\". Если AI все-таки включен, необходимо сделать следующие настройки:
    -aibufs должен быть равен –bibyfs;
    запустите AIW;
    -aiblocksize = -biblocksize.
- Запустите брокера для Replication Database. Запуск должен выполняться под тем же userid что и запуск промышленной базы данных.
- Не забывайте использовать параметры, упомянутые прежде. Существует файл параметров для Pro D&L (image.pf), который может быть использован как отправная точка. 

Репликационные данные в Production Database

Добавьте новую область хранения (Storage Area) с помощью prostrct add. Убедитесь что имеется достаточно дискового пространства для хранения репликационных данных. Имя области должно быть – «prodl_data». Используйте Record per Block  (RPB) равным 128 или 256.

Заметьте, что BI файл вырастет намного больше, чем обычно на Production Database. Это связанно с тем, что каждое изменений в промышленной базе будет дублироваться в Replication Database. Поэтому, если в промышленной базе возникают большие транзакции, необходимо убедиться в следующем:
·    места для BI должно быть выделено достаточно. Рекомендуется увеличить его минимум в два раза;
·    размеры BI экстентов определены правильно. Не забывайте об ограничении в 2Гб если не включена поддержка больших файлов с помощью proutil EnableLargeSize;
·    параметр –bithold должен быть установлен пропорционально высоко.

Запустите клиентскую сессию и через Data Dictionary загрузите Data Definition файл (image.df) в Промышленную базу.

Установка и настройка (продолжение)

Убедитесь, что каталог с Репликационными триггерами (Replication Triggers) содержится в путях поиска для каждого возможного типа клиента:
- Self Service clients
- Remote clients (those that connect with the –H and –S parameters)
- WebSpeed agents
- AppServers
- Batch processes

Для этого можно использовать следующее:
- параметр –trig. Заметьте, если этот параметр уже используется для других триггеров, то репликационные триггеры нужно будет расположить в указанном в параметре каталоге. Либо можно прибегнуть к другому методу;
- используйте переменную среды окружения PROPATH;
- Полное имя каталога может быть определено в Target Directory при выполнении первой стадии (Phase 1) > Create Triggers (create_trig.p).

Некоторые приложения могут иметь множество путей расположения триггеров, например один для символьных клиентов для Unix сервера, а другой для графических для Windows сервера.

Если репликационные триггеры хранятся в Shared Procedure Library, убедитесь что библиотека определена в PROPATH, используемом клиентскими сессиями.

Если используется отдельная база репликации (Replication Database) убедитесь, что все 4GL клиенты использует скрипт с возможностью подключения к этой базе данных. Для этого имеется два различных способа:
- добавить коннект к Replication Database в клиентские скрипты и/или файлы параметров;
- использовать функцию Progress Auto-Connect. О ней будет подробно рассказано позже.

Независимо от того, какой метод будет выбран, возможно, придется увеличить параметр Maximum Database Connections (-h), по умолчанию его значение равно 5. Рекомендуется сделать копии всех изменяемых скриптов и файлов параметров, поскольку после завершения Pro D&L они должны быть восстановлены.

Добавьте параметр Quick Request (-q) в клиентские скрипты и файлы параметров, если до этого времени он не использовался. Заметьте, что этот параметр не рекомендован для ABL(4GL) программистов и пользователей которые не используют R-код, а компилируют его «на лету».

Начинаем

Остановите промышленную базу данных. Остановите работу всех процессов использующих промышленную базу, как фоновых так и интерактивных. Например, в Unix можно временно отключить cron. Создайте копию промышленной базы данных одним из следующих способов:
a.    С помощью probkup;
b.    С помощью procopy;
c.    С помощью AI файлов, накатываемых на существующую копию промышленной базы.

Активируйте возможность подключения пользователей к Replication Database. Как уже говорилось ранее, это можно сделать одним из двух способов:
d.    Изменить клиентские скрипты подключения. При этом сохраните копию изменяемых скриптов;
e.    С помощью Progress Auto-Connect. Для этого:
i.    Запустите 4Gl редактор относительно промышленной базы;
ii.    Запустите утилиту редактирования Auto-connect:
1.    Character: Tools &#8594; Utilities &#8594; Edit PROGRESS Auto-Connect List &#8594; Add;
2.    GUI: Tools &#8594; Data Administration &#8594; Utilities &#8594; Edit PROGRESS Auto-Connect List &#8594; Add;
iii.    Введите Logical Database Name, для простоты используйте тоже имя, что и Physical Database Name (за исключением полного пути);
iv.    Введите Physical Database Name – полный путь и имя Replication Database;
v.    Параметр CONNECT не нужны за исключением, если существуют удаленные (remote) клиенты. Если таковые имеются укажите параметр –H и –S;
vi.    Выйдете из редактора;

Запустите клиентскую 4gl сессию, с подключением сначала к промышленной базе данных, а затем к Replication Database (одна сессия – два коннекта, если конечно же Replication Database не хранится в промышленной базе) и запустите программу menu.p. Для связи с промышленной базой данных, убедитесь, что логическое имя базы данных (параметр –ld), который используется прикладным кодом, то же самое, которое используется при соединении теперь. Иначе генерируемый код не будет работать на промышленной базе данных. Ниже приведен пример, где repldb представляет собой физическое имя Replication Database:

mpro -db promdb –ld prod -db repldb -p menu.p

Из появившегося меню выберите: Phase 1 -> Create Triggers. Эта программа выполняет следующее:
- Генерирует Репликационные триггеры для каждой таблицы промышленной базы данных
- Затем компилирует их. Эта возможность дополнительная, и она рекомендована для ускорения процесса, но не имеет смысла выполнять компиляцию на пример при тестовых работах;
- Генерирует программы, которые в конечном счете будут использоваться для наката репликационных данных на New Database;
- Добавляет репликационные триггеры в промышленную базу данных. Эта опция дополнительная;
- Дополнительно, можно создать программы dump/load для таблиц не имеющих уникальных индексов. Это Xref - метод, который описывался ранее.

Детально работа этой программы описана ниже.

Поле	Описание
Production Database	Имя промышленной базы данных.
Replication Database	Имя Replication Database.  Если эта база хранится в промышленной базе данных, то это поле будет отображать “?”.
Trigger Code Directory	Код репликационных триггеров будет размещен в этом каталоге.  Если будет выбрана опция Compile Code, R-code так же будет сохранен в этом каталоге.
Actual Trigger Directory	Это путь, который будет использоваться Progress ABL клиентами для поиска репликационных триггеров.  Этот путь хранится в Data Dictionary как часть Replication Trigger Definitions.  Возможные значения: - Полный путь к каталогу (например, /app/prodl/trig); - Относительный путь (например, prodl/trig); - Только имя каталога (например, trig); - Ни чего, т.е. пусто.
Apply Code Directory	Каталог хранения исходного кода для наката Replication Data на New Database
Create Dump Programs	Ответьте ‘yes’ на этот вопрос если нужно создать специальный код для выгрузки/загрузки (dump/load) таблиц, не имеющих уникальных индексов.  Эта опция (Xref - метод) усложняет процесс Pro D&L, но может быть необходимой если имеются большие таблицы без уникальных индексов.  Процесс использования этих программ будет обсужден чуть позже. Примечание: если вы ответите «no», это будет означать, что не будут созданы репликационные триггеры для NUI таблиц, и эти таблицы будет необходимо вручную перегружать (dump/load) во время второй стадии (Phase 2).
Dump/Load Code Directory	Код программ для выполнения dump/load будет сохранен в этом каталоге. Если конечно же на предыдущий вопрос вы ответили “yes”
Dump/Load Data Directory	Данные, выгруженные  (dumped) программами выгрузки будут храниться в этом каталоге.
Update Schema	Добавление репликационных триггеров в схему промышленной базы данных.
Compile Code	Компиляция репликационных триггеров для ускорения их работы.
Skip Record Length Test	Pro D&L не может работать с записями более 15Кб.  Но записи такого размера обычно очень редко встречаются.  Ответив ‘yes’, Replication Triggers не будут проверять записи больше 15К. Это позволит работать триггерам более эффективно.  Отвечайте на этот вопрос “yes” только если вы абсолютно уверены, что запись такого размера не  существуют и не могут появиться во время работы Pro D&L.  Максимальный размер записи можно проверить  с помощью proutil tabanalys запущенной относительно промышленной базы данных (колонка \'Max\')
Elapsed Time	Общее время, требующееся для генерации кода, изменения схемы и прочего, отображается в секундах.
Total Tables	Общее количество таблиц в промышленной базе данных. Не включает таблицы схемы и метасхемы.
Tables w/Write Trigger	Количество таблиц содержащих Replication Write триггеры
Tables w/Delete Trigger	Количество таблиц имеющих Replication Delete триггеры

Если была допущена ошибка, например ввели некорректный путь, и хотели бы исправить это, вы можете удалить все ссылки на Replication Triggers в промышленной базе данных запустив: Phase 1 &#8594; Remove ALL Replication Triggers.

Если Total Tables не соответствует Tables w/Write Triggers или Tables w/Delete Triggers, это различие может быть нормальным при наличии одной или более NUI таблиц. Это можно проверить двумя способами:
- По списку всех NUI таблиц: Other &#8594; Tables without Unique Indexes;
- По списку таблиц без Replication Triggers: Other &#8594; Tables without Replication Triggers.

Убедитесь, что Replication Triggers не созданы для таблиц из Replication Database. Это может случиться, если эти таблицы расположены в промышленной базе, а не в отдельной Replication Database, или если промышленная база не была выбрана как “current working database” при выполнении на первой стадии (Phase 1) пункта Create Triggers (Phase 1 &#8594; Create Triggers).

Проверьте, что права (permissions) на триггеры выставлены правильно, т.е. они доступны для чтения клиентским процессам.

Если необходимо, удалите Replication Triggers из выбранных таблиц, которые не должны выгружаться и загружаться, например для таких как, временные таблицы, таблицы аудита и прочее: Phase 1 &#8594; Remove Specific Triggers

При необходимости, скопируйте скомпилированный код Replication Trigger (.r файлы) в любые другие файловые сервера, используемые для хранения кода 4gl приложений.

Выйдете из промышленной базы.

Перезапустите промышленную базу.

Запустите приложение и измените какую-нибудь запись базы данных, после чего проверьте, что изменение появилось в Replication Database. Существует несколько программ в основном меню, которые могут использоваться для этих целей – они будут описаны позже.

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

Мониторинг Replication Database

Есть несколько программ, поставляемых с Pro D&L для мониторинга Replication Data (RD).

Monitoring -> Simple List of RD
Эта программа создает простой список всех записей в Replication Table

Monitoring -> Browse RD Table
Эта программа показывает все записи в Replication Table, используя 4gl browser.

Имеются следующие опции:
- Сортировка записей по Sequence# или Table;
- Сортировка по возрастанию (ascending) или по убыванию (descending).

Monitoring -> Range of RD Records
Программа идентична Browse RD Table, но имеется возможность указывать диапазон Sequence#

Monitoring -> Table Search
Программа идентична Range of RD Records, но по мимо диапазона Sequence# есть возможность указать таблицу.

Поле	Описание
Sort Field	Записи, отображаемые в окне, сортируются по Sequence# или Table Name.  По умолчанию по Sequence#.
Sequence	Записи могут отображаться по возрастанию или по убыванию. По умолчанию по убыванию (Descending).
Sequence#	Это последовательный номер Replication Data добавляемых в Replication Database. Этот номер так же используется для наката Replication Data в хронологическом порядке.
Applied	Значение ‘Yes’ означает что Replication Data записан в New Database.  Запись Replication Data в New Database описана ниже в этом документе.
Table Name	Имя таблицы к которой принадлежит запись в промышленной базе данных.
Event	Единственно возможные значения Write и Delete.  Write говорит о новой или измененной записи.
Batch	Отображается ‘yes’ если программа, создавшая запись в Replication Data запущена в фоновом (batch/background) режиме.
Trx Date	Дата транзакции.  Дата изменения.
Trx Time	Время транзакции.  Время изменения.
	Детали по каждой записи
Old Key	Оригинальный ключ. Только значимые для изменения существующих записей.
New Key	Новое ключевое значение после изменения. Только значимые для изменения существующей записи
Unk Val in Old Key	Отображает ‘yes’ если существует неопределенное значение (Unknown Value (?)) в любом из полей старого ключа (Old Key).  Поле необходимо в основном для диагностических целей.
Unk Val in New Key	Отображается ‘yes’ если существует неопределенное значение (Unknown Value (?)) в любом из полей нового ключа (New Key).  Поле необходимо в основном для диагностических целей.
Transaction#	Уникальный транзакционный номер, установленный Progress`овой транзакцией, которая создавала, удаляла или изменяла запись.
Recid	Recid записи, созданной, удаленной или измененной в старой промышленной базе данных.
Userid	userid процесса, создавшего Replication Data.
Date Format	Формат даты, используемый процессом, создавшим Replication Data.
Program	Имя программы или внутренней процедуры, изменившей запись в Production Database. Поскольку одно только имя внутренней процедуры не может быть полезно в процессе отладки, Pro D&L отображает список из двух имен разделенных символом «|»  -программы и внутренней процедуры.

Monitoring-> High Water Mark
Мониторинг High Water Mark в Replication Database

Monitoring -> BI Size
Мониторинг размера Before Image файла в Replication Database

Monitoring -> DB Stats
Различная статистика для мониторинга Replication Database

Monitoring -> Sequence Values
Мониторинг текущего значения Sequences записанного в Replication Database. До версии V10.1B Sequences были ограничены 2 миллиардами.

Dump/Load копии базы данных

Теперь, когда Pro D&L фиксирует изменения в промышленной базе данных, можно приступить к dump/load базы данных копии. Какой метод вы будете использовать, это зависит полностью от вас. Для Pro D&L не имеет значения, будет ли это бинарный или текстовый метод. Тем не менее, мы рекомендуем, при наличии повреждений в базе данных, не использовать двоичный метод. Это связано с тем, что двоичный dump/load  может просто перенести повреждения в New Database.

Восстановите базу данных, желательно на другой машине во избежание ухудшения производительности за счет возросшей I/O нагрузки из-за выполнения dump/load. Начните выгрузку.

Не забывайте, что возможно вам не нужно выгружать некоторые таблицы:
- Таблицы, не имеющие уникальных индексов, будут выгружены вручную на второй стадии (Phase 2);
- Таблицы, не имеющие уникальные индексы, которые будут выгружены и  загружены с помощью Xref – метода;
- Таблицы, которые исключены их процесса репликации по некоторым причинам:
    Временные таблицы;
    Таблицы журнала аудита;
    Прочие причины.

Dump и Load NUI таблиц с использованием Xref - метода

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

Основные шаги:
- Ответьте “Yes” на вопрос Create Dump Programs при выполнении Phase1 -> Create Triggers;
- При выгрузке из базы – копии, для выгрузки NUI таблиц используйте специальные программы;
- Создайте Xref - базу данных, используя соответствующий структурный файл (xrf8.st, xrf9.st или xrf10.st);
- Загрузите в нее соответствующий df-файл (xrf8.df или xrdf.df для v9/v10);
- Загрузите NUI таблицы в New Database используя специальные программы во время Dump/Load;
- При запуске программ, убедитесь, что сессия подключена к Xref - базе данных.

Детально этот процесс будет описан далее.

Процедура Xref Dump

Программы выгрузки (dump), созданные во время первой стадии (Phase 1 &#8594; Create Triggers), все предназначены для работы в batch – режиме. Они конечно же могут запускаться в диалогов режиме, но на экран ни чего выводиться не будет. Пример запуска прогрессовой программы в batch – режиме:

# bpro <dbname> -p d_customer.p -RO >> dump.log

Программы выгрузки имеют префикс «d_», сопровождающий имя для выгрузки (Dump Name) NUI таблицы, которое определено в Data Dictionary

Имена файлов выгрузки будут создаваться по следующей маске <tabledumpname><seq#>.dd. Где seq# , это целочисленное значение начинающееся с 1 и увеличивающееся на 1 при формирования множества файлов выгрузки для одной и той же таблицы. Множественные файлы выгрузки создаются размером примерно по 2 Гб. Суффикс .dd используется для отличия файлов выгрузки NUI таблиц от файлов выгрузки созданных из Progress Data Dictionary.
- При необходимости, каталог выгрузки может быть изменен путем редактирования соответствующей программы выгрузки. Но тогда  так же не забудьте изменить каталог для соответствующей программы загрузки;
- Количество записей, выгруженных для каждой таблицы, будет записываться в текстовый файл dump-cnt.log

Процедура Xref Load

Если вы собираетесь выполнить полную переиндексацию как часть процесса dump/load, то сначала загрузите NUI таблицы, чтобы перестройка индексов затронула так же и их индексы. Чтобы предотвратить двойную переиндексацию, перед загрузкой NUI таблиц деактивируйте их индексы ( Dictionary -> Utilites -> Index Deactivation).

Программы загрузки имеют префикс «l_», сопровождающий имя для выгрузки (Dump Name) NUI таблицы, которое определено в Data Dictionary. Они так же разработаны для использования в batch режиме.

Количество записей, загруженных для каждой таблицы, будет записываться в текстовый файл load-cnt.log.

Любые ошибки, возникшие в процессе загрузки, будут записаны в файл <tabledumpname>.e, который будет располагаться в каталоге, из которого программы были запущены.

Перед началом загрузки необходимо загрузить  файл xrf8.df (xrf.df для V9/V10) в пустую 8-килобайтную базу данных (empty8). В этом документе эту базу мы будем называть Xref Database, тем не менее вы не сможете назвать ее «xref» - Progress этого не даст. Для V9/V10, используйте соответствующий файл xrf9.st или xrf10.st, для создания окончательного структурного файла Xref Database, в котором RPB (Record Per Block) должен быть равным 256, поскольку xref-записи довольно малы. Возможно, лучше добавить несколько экстентов фиксированного размера, поскольку иногда Xref Database может вырасти более чем 2 Гб.

Рекомендуется включить поддержку больших файлов для Xref Database (Proutil EnableLargeFiles)

При работе программ Xref Load необходим коннект для двух баз New Database и Xref Database. Xref Database должна быть выделена отдельно от Replication Database, поскольку возможно, что Replication Database может располагаться на той же машине, что и Production Database, Xref Database  должна располагаться там же где находится New Database. Настройте Xref Database так же как и Production Database, используя такие же параметры, либо используйте параметры Replication Database.

Важное замечание:

Не возможно загрузить файлы Xref Load (.dd), с помощью Progress Dictionary или утилиты bulkload  (proutil bulkload). Pro D&L создает .dd-файлы в формате отличным от стандартных форматов Progress - утилит.

Накат Replication Database Data (RDD) на New Production Database

К этому моменту New Database должна быть полностью перезагружена (dump/load), а так же дожна быть выполнена перестройка индексов (indexes rebuilt).

Теперь вы готовы начать накат транзакций с Replication Database на New Database.

Replication Database и New Database расположены на разных машинах?

В этой ситуации возможно несколько путей для наката RDD на New Database, пока продолжается запись транзакций в Replication Database:

1.    Скопируйте (или используйте backup/restore) New Database на промышленную машину. Но это подразумевает наличие необходимого дискового пространства. Если вы прибегнете к обычному копированию, то потребуется воспользоваться prostrct repair после копирования, для обновления путей размещения экстентов.

Есть несколько преимуществ этого метода:
a.    Намного легче накатить RDD на New Database, поскольку обе они будут находиться на одной машине.
b.    Когда придет время остановки Production Database и запуска New Database, достаточно будет просто выполнить procopy New Database в Production Database.

Недостаток же следующий:

Если Replication Database используется для записи промышленных транзакций и наката RDD, могут возникнуть проблемы с :
i.    Размером BI-файла на Replication Database, если транзакции Production Database медленно завершаются;
ii.    С производительностью промышленного приложения, поскольку Replication Database занята;
iii.    Процесс наката увеличит загрузку промышленного сервера.
2.    Используйте опцию online утилиты probkup чтобы сформировать резервную копию Replication Database и восстановить ее на машине, где расположена New Database, и где будет выполняться накат RDD. В этом случае, вы должны быть предельно осторожны, при записи начальных и конечных номеров Sequence используемых для наката RDD, поскольку каждый раз, после копирования/восстановления Replication Database, флаги Replication Data указывающие, что они уже были применены (applied), могут быть потеряны. Информация о записанных Sequence сохраняется в файл apply.log.
3.    Используйте After Imaging для отправки репликационных данных (RDD) из Replication Database на её копию на другой машине. Этот метод наиболее сложный, поскольку вы не можете непосредственно применить RDD с копии базы, так как накат RDD изменит Replication Database и вынудит AI прекратить работу. Хитрость заключается в том, чтобы делать копию с копии. Другими словами, как только AI с промышленной Replication Database накатятся на копию, Вы можете сделать probkup с копии, используя опцию –norecover. После чего восстановите эту копию с помощью prorest и используйте эту базу данных для наката RDD.
4.    Можно хранить Replication Database и New Database и на различных машинах, используя во время наката RRD Remote Client Connection (-S). Для этого Replication Database должна быть запущена с параметров Service Name (-S). Это опция относительно проста, но не практична, впрочем, это зависит от скорости работы сети. Для начала, вы можете попробовать загрузить таким образом несколько тысяч записей, и посмотреть сколько времени будет выполняться этот процесс.

Шаги по накату (Apply) RDD

Сделайте backup New Database. Это на случай возможных проблем во время процесса наката. Так же сделайте backup базы данных Xref, если она имеется.

Запустите брокер для  New Database. По возможности используйте такой же файл параметров, как и для Production Database. Если время ограничено, то можно использовать опцию No Integrity (-i), но только если вы уверены, что резервная копия корректна. Так же это хороший момент, чтобы настроить такие параметры как BI Cluster Size (-bi), BI Block Size (-biblocksize), AI Block Size (-aiblocksize).

Запустите, как минимум один, Asynchronous Page Writers(APW) и BI Writer (BIW)

Обработка NUI таблиц

Если есть NUI таблицы, выполните следующие шаги:
- Скопируйте Xref Database на промышленный сервер. Этот шаг выполняется, только если New Database уже скопирована на промышленный сервер. Если New Database будет располагаться на отдельном сервере во время процесса наката, выполните резервную копию Xref Database на случай возможных проблем во время процесса.
- Запустите брокер для Xref Database, используя параметры, настроенные для лучшей производительности.
- Запустите два APW и один BIW для Xref Database.
- Запустите ABL клиента относительно New Database (убедитесь,  что вы не подключены к Replication Database) и запустите программу экспорта триггеров (Trigger Export) (см. Phase 1 -> Export Triggers), для экспорта и удаления всех триггеров схемы из New Database. Это необходимо, чтобы исключить вероятность изменения New Database репликационными данными (Replication Data). Триггеры буду восстановлены, когда накат репликационных данных будет завершен. Запишите количество экспортированных  триггеров для проверки во время процесса импорта. Далее приведен пример экрана:

Название поля	Описание
Verbose?	Если введено ‘yes’, на экране будет отображаться информация о каждом обрабатываемом триггере.
Table File Name	Имя текстового файла, который будет содержать табличные триггеры. По умолчанию установлено имя _table-trig.d.  экспортированные триггеры будут загружены повторно позже ( Phase 2 → Import Triggers ). Если Pro D&L используется для множества баз данных, переименуйте этот файл во избежание путаницы.
Field File Name	Имя текстового файла, который будет содержать триггеры полей таблицы, если они существуют. По умолчанию его имя равно _field-trig.d.
Option	(E)xport only – происходит экспорт триггеров без удаления. (D)elete only – выполняется только удаление триггеров, без экспорта. Эти значения используются, только если экспорт и удаление вы решили делать раздельно. (B)oth – Экспорт с последующим удалением триггеров.

- Теперь запустите ABL клиента с коннектом к двум базам: New Database и Replication Database. Если вы используете отдельную базу Replication Database, вы должны сначала подключиться к New Database и только потом к Replication Database. Другими словами, New Database должна быть, как это называет Progress, “current working database”. Для лучшей производительности клиента, рекомендуются следующие параметры запуска:
    Quick Request (-q);
    Directory Entries (-D 500);
    Execution Buffer (-mmax 8192 или выше);
    Data Format (-d) – этот параметр не имеет ни чего общего с производительностью, но он должен быть установлен так же как и у обычных клиентов, работающих с промышленной базой данных.
- Если вы ответили «yes» на вопрос в поле Create Dump/Load Programs из Phase 1 -> Create Triggers program, вам необходимо также подключиться к Xref Database.
- Использование Apply program (Phase 2 –> Apply Data) накатывает RDD данные до определенного порядкового номера (Sequence number). Поэтому, например, если установить текущий номер 10 547 302, это безопасно при наличии 10 400 000 записей. Процесс наката должен уменьшить время простоя системы, накатывая как можно больше транзакций до момента останова Production Database в Phase 2. Не забудьте делать записи о порядковых номерах, чтобы не потерять данные, если возникнут промежутки во времени наката. В случае, если вы всё таки забыли текущий порядковый номер, его можно посмотреть в файле apply.log. Phase 2 Apply Data может работать в интерактивном или batch режимах. Далее приведен пример окна работы программы в интерактивном режиме.

Примечание: Вы можете для начала накатывать не большое количество записей (1 – 1000), например, чтобы убедиться, что всё работает нормально. Такой “mini-apply” так же поможет дать грубую оценку времени, необходимого для полного наката.

Важное замечание: Если вы используете Replication Database как для регистрации промышленных транзакций, так и для наката RDD, очень важно не выполнять накат до текущего порядкового номера, т.е. 10 547 302, как в примере выше. Из соображений блокировки записей и размеров транзакции, для большей безопасности, накатывайте на 100 000 транзакций меньше существующего количеств записей, чтобы исключить «столкновения» с активными промышленными транзакциями.

Поле	Описание
Code Location	Расположение Apply программ, созданных на стадии Phase 1 → Create Triggers program.  Эти программы имеют префикс ‘ap_’.
Verbose	Ответ ‘yes’ на этот вопрос, будет периодически отображать на экране количество обработанных RDD записей. Период отображения настраивается в поле Display Count ниже.
Stop on Errors	Если возникнут любые ошибки, процесс наката будет прекращен немедленно. По умолчанию установлено ‘no’ (т.е. не останавливаться при ошибках) поскольку большинство ошибок обычно не критичные. Такие ошибки обычно не влияют на фактические данные, но считаются аномальными. Подробную информацию о них можно найти в файле apply.log.
Delete after Applied	При установке \'yes\', если RDD запись обработана успешно, она будет удалена. Преимущество заключается в том, что размеры Replication Database не будут расти, а освобожденное пространство может быть использовано повторно. Не достаток – не возможность восстановления в случае сбоя.
Start Sequence#	Работы RDD приложения будет начата с указанного порядкового номера (Sequence#). Если вы не уверены с какого номера начать, можно запустить программу Мониторинга (Monitoring programs) относительно Replication Database или посмотреть файл apply.log.
Ending Sequence#	Порядковые номера RDD записей не будут накатывать после этого значения.
Total Records	Здесь отображается текущее количество RDD записей в Replication Database.
Display Count	Если выбрана опция Verbose, то здесь можно установить частоту отображения на экране обработанных записей..  По умолчанию установлено 100.  Чем меньше значение, тем более вероятно, что увеличится дополнительная нагрузка из-за частых I/O операций на экран.  Так же в batch режиме, маленькое значение приведет к быстрому росту размера файла лога.
Elapsed Time	Как только процесс наката будет завершен, затраченное время будет отображено здесь. Небольшая подсказка: сначала загрузите небольшое количество записей (1 – 1000), и на основании появившегося значения в этом поле можете определить необходимое время для выполнения полного наката.
Records Applied	Общее количество загруженных записей в New Database во время текущего сеанса работы.
Total Errors	Общее количество ошибок. Каждая ошибка представляет RDD запись, которая не была обработана. Тем не менее, большинство таких ошибок не требует дополнительной обработки. Детали по ошибкам можно посмотреть в файле apply.log.

  
В примере ниже, мы установили Verbose в “yes”, Ending Sequence# в 12 000 и Display Count в 500. Это означает, что программа использует все не загруженные RDD записи с порядковым номером больше или равным 10 001 и меньше или равно 12 000. Verbose, укажет программе, отображать обработанные записи в поле “progress report” через каждые 500 записей.

Запуск apply_data.p (Phase 2 -> Apply Data) в batch режиме

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

Номер параметра	Описание
1	Каталог расположения Apply программ.
2	Начальный порядковый номер (Sequence#)
3	Конечный порядковый номер (Sequence#).  Если использовать  a ‘?’ вместо указания конечного значения, программа обработает все записи до конца в Replication Database.
4	Флаг остановки в случае ошибки. Корректно только \'yes\' или \'no\', т.е. нельзя использовать  \'y\' или \'n\'.
5	Display Count.  Запись в лог количества обработанных RDD данных через каждые n раз. Значение\'0\' означает, что ни чего записываться не будет.
6	Флаг удаления после наката. Корректно только \'yes\' или \'no\', т.е. нельзя использовать  \'y\' или \'n\'

Пример:

mbpro -db prod -db image -p apply_data.p -param “/prodl/apply,1,100000,no,0,no” > err.lg

В этом примере, будут обработаны первые 100 000 RDD записей (от 1 до 100 000). Пример не содержит некоторые параметры, которые могут ускорить процесс выполнения, например –q и –mmax. О них говорилось ранее. Все клиентские параметры запуска могут быт объединены в один файл параметров (.pf), для облегчения их использования и редактирования.

Ошибки возникшие во время запуска процесса, будут регистрироваться в файле err.lg. А ошибки возникшие во время работы процесса наката, записываются в файл apply.log.

Проверка работы Apply процесса. Проверить, что процесс наката (Apply) работает можно следующими способами:
- Запустите promon относительно Replication Database и понаблюдайте за совершением транзакций (опция меню 5)
- Запустите promon относительно New Database и понаблюдайте за совершением транзакций
- Просматривайте лог файл – apply.log.

Пример apply.log от Pro D&L

Ниже отображены две незначительные ошибки. Так же заметьте, что между Start Sequence# и End Sequence# разница равна 15 000 000, но обработано было только 14 999 899. даже если добавить две ошибочные записи – не хватает еще 99. Это связано с тем, что если транзакция еще не завершена, порядковый номер (Sequence#) будет продолжать увеличиваться. Поэтому, нет ни чего необычного в наличии пропусков в порядковых номерах.

========================================
Start Date        : 10/26/05
Start Time        : 08:38:49
Crash Recovery    : enabled
Batch Mode        : no
Stop on Error     : no
Delete after Apply: no
Date Format       : mdy
Code Page         : ISO8859-1
Numeric Format    : AMERICAN
Error for sr_wkfl Seq#:64613 NO UNK VALUE DELETE: cannot find record
Error for sr_wkfl Seq#:61998 NO UNK VALUE DELETE: cannot find record
Ending Date       : 10/26/05
Ending Time       : 09:20:51
Elapsed Time      : 2,522 seconds
Start Sequence#   :              1
End   Sequence#   :     15,000,000
Last Sequence#    :     15,000,000
Records Applied   :     14,999,899
Applied per Sec   :          5,947
Total Errors      :              2
========================================

В примере выше, «End Sequence#» эквивалентен «Last Sequence#». «End Sequence#» является порядковым номером, выбранным человеком. «Last Sequence#» это последний порядковый номер, обработанный Apply программой. Ошибка могла бы вызвать преждевременное завершение Apply процесса, так что Last Sequence# может облегчить возможность определения причины случившегося и перезапустить обработку снова, когда ошибка будет исправлена.

Примечание: файл apply.log изменяется в любом случае, не зависимо от того работает ли Apply  процесс в интерактивном или batch режиме.

Перезапуск Apply  процесса

Если во время работы Apply процесса возникли какие-либо проблемы, то перезапустить его достаточно легко. Для этого вам нужно:
- Восстановить резервную копию (backup) New Database, сделанную после того, как был выполнен dump/load;
- Сбросить флаги наката (Applied flags) в Replication Database. Сброс можно осуществить вызовом программы, которую можно найти так: Other -> Reset Applied Flags. Выполните следующие:
    Запустите Progress сессию, подключенную к Replication Database и запустите программу-меню Pro D&L;
    Выберете: Other -> Reset Applied Flags, эта программа имеет следующие опции:
       Сброс Applied flags для ALL RDD записей;
       Сброс Applied flags для RDD записей, находящихся в специфическом диапазоне порядковых номеров (Sequence numbers);
       Сброс Applied Flags для RDD записей из специфических таблиц.

Счетчик количества сброшенных флагов будет отображен в конце программы.

Возможные проблемы с Apply

Если во время Apply процесса вы столкнетесь с такой проблемой как Lock Table Overflow или если процесс будет работать очень и очень медленно, то возможные причины можно искать в следующем:
- Возможно проблема в записи (WRITE);
- Обрабатываемая запись возможно имеет неопределенное значение (unknown value) в индексе, который использует Apply программа;
- В таблице, записи которой обрабатываются, возможно имеется множество записей имеющих неопределенное значение в том же индексе.

Останавливаем Production Database в последний раз

Это последний раз, когда Production Database должна быть остановлена из-за Pro D&L. В это время Dump/Load должен быть окончательно завершен, и RDD должны быть закрыты. И так, продожим.

Остановите все процессы в Production Database, и фоновые и интерактивные. На время остановите работу cron`а в Unix системе, а в Windows остановите планировщик задач. Остановите (shutdown) Production Database.

Из Production Database выгрузите все таблицы, требующие ручной выгрузки. Это можно сделать с помощью бинарного или текстового дампа. Заметьте, что по умолчанию, бинарный дамп не индексирует данные во время загрузки, поэтому время простоя вашей базы может увеличится за счет необходимости дополнительной переиндексации. Но начиная с версии прогресса 9.1B у бинарной загрузки (binary load) появилась возможность использовать свойство build indexes, для построения индексов во время процесса загрузки. Утилита proutil bulkload также не строит индексы, но у него нет такого свойства, поэтому переиндексация будет нужна обязательно. Для исключения увеличения времени простоя за счет переиндексации, рекомендуется загружать данные с помощью Data Dictionary, но при условии что объем этих данных не большой. Для ускорения процесса загрузки через Data Dictionary можно воспользоваться параметром запуска No Integrity (-i), но имейте ввиду, что его использование несет определенный риск, поэтому перед началом работ обязательно сделайте резервную копию базы данных.

Выгрузите Sequence Data из Production Database. Это можно сделать с помощью Data Dictionary: Admin -> Dump Data and Definitions -> User Table Contents.

Выгрузите User Table из Production Database. Data Dictionary: Admin -> Dump Data and Definitions -> User Table Contents.

Дополнительно: если существуют SQL92 Privileges в Production Database воспользуйтесь KB# P17829 для их выгрузки.

Если New Database должна переписать Production Database, то из соображений безопасности, рекомендуется сделать еще одну резервную копию Production Database.

Накатите (Apply) оставшихся RDD данных из Phase 2 -> Apply Data program. Эта программа может запускаться в диалоговом или в фоновом режиме. Если осталось только несколько транзакций, то этот процесс можно выполнить в однопользовательском режиме (single user). В других случаях, запустите брокера базы в режиме No Integrity (-i), для улучшения производительности, и запустите Phase 2 -> Apply Data. Если вы запустите брокера, то убедитесь, что пользователи не могут получить доступ к базе данных. Ведите мониторинг файла apply.log, на предмет появления ошибок.

Дополнительно: проверьте что данные Old Production Database соответствуют данным New Database, для этого имеются следующие методы:
    Запустите proutil dbanalys относительно Old и New Databases и сравните количество записей для каждой таблицы;
    Запустите программу проверки (Phase 2 -> Verify Data)

Tabanalys, обычно является более эффективным способом проверки. Обратите внимание, что наличие небольших не соответствий в количестве записей не является проблемой, поскольку это может быть следствием следующего:
- Баг в proutil tabanalys, который должен был быть исправлен в версии V9.1D SP07;
- Запись была создана, но ни когда не изменялась, поэтому Pro D&L Replication Trigger ни когда не отрабатывал. Во многих случаях, это бессмысленные записи, потому что они не содержат ни каких данных;
- NUI таблицы, отличия в которых могут быть из-за времени синхронизации и времени запуска proutil tabanalys;

Если таблицы не большие, то на Unix/Linux идентифицировать записи можно сравнительно легко:
- Используя Data Dictionary выгрузите таблицу из Production Database;
- Выгрузите таблицу из  New Database;
- Используйте утилиту diff в командной строке для сравнения двух полученных файлов. При этом нужно проигнорировать различия в трейлерах, добавленных в конце каждого файла.

Устранить различие, в зависимости от размера несоответствий и количества записей в таблицах, можно будет легко, или наоборот – очень, очень сложно.

Проверка данных

Следующая программа создает закодированный файл выгрузки (dump file) для указанной таблицы. Как только будет создано два файла для New и Old Databases (для этого программа должна запускаться дважды) их можно сравнить средствами операционной системы, такими как diff. В конечном счете, Pro D&L обеспечивает сравнение  специальной программой. Но для этого клиентская сессия должна быть запущена в режиме Read Only (-RO).

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

Преимущество же в том, что вы можете быть уверены и спокойны, что всё в порядке. Пример экрана программы проверки:
Здесь:
- DB Name – Имя и путь New Database  или Old Production Database;
- Connect Params – параметры, необходимые для подключения к указанной базе данных;
- Version – old, для Production Database; new, для New Database;
- Table – имя таблицы для проверки;
- Dump Path – путь по которому будет сохранен dump – файл.

Продолжаем работать во второй фазе.

Остановите сессию. Загрузите таблицы, выгруженные вручную из Old Production Database в New Database. В New Database загрузите Sequence Data, который были выгружены ранее из Production Database. Data Dictionary: Admin -> Load Data and Definitions -> User Table Contents. Дополнительно: Восстановите SQL92 Privileges из Production Database, если они конечно же были. Для этого воспользуйтесь  советами из KB# P17829.

Запустите сессию в New Database и пересоздайте триггеры, которые экспортировались и удалялись ранее. Для этого используйте Phase 2 -> Import Triggers. Далее приведен пример экрана этой программы. Проверьте, что количество импортированных табличных триггеров и триггеров полей соответствует количеству ранее экспортированных триггеров.


Здесь:
- Table File Name – имя текстового файла, содержащего табличные триггеры выгруженные с помощью Phase 1 -> Export Triggers. По умолчанию, имя этого файла равно _table-trig.d;
- Field File Name – имя текстового файла, содержащего триггеры полей, выгруженные с помощью Phase 1 -> Export Triggers. По умолчанию имя файла - _field-trig.d;
- Verbose? – если “yes”, будет отображаться информация о каждом загруженном триггере.

Разместите New Database в соответствующем месте. Если имеется достаточно дискового пространства для хранения обеих баз (New и Production) на одной машине, то возможно, что будет достаточно изменить путь к базе данных в скриптах запуска/останова/подключений на New Database. Так же, вы можете просто скопировать .db файл New Database на место .db файла Production database. Прогресс использует этот файл для обнаружения всех файлов базы данных, поэтому менять скрипты вам не придется. Но вам нужно будет после копирования выполнить prostrct repair для обновления информации об экстентах New Database. Как вариант, вы можете воспользоваться утилитой procopy sourceDB targetDB, для копирования New Database в Production Database. Т.е. просто перезаписать  Production Database.

Если места не достаточно, для одновременного размещения обеих баз данных, то:
       Сделайте резервную копию (backup) New database
       Удалите Production Database командой prodel
       Восстановите New Database на место Production database из резервной копии

Если вы используете failover, например HP MC/ServiceGuard или IBM HACMP, то возможно инициировать failover из машины на которой запущена Production Database на машину с New Database.

Не зависимо от использованного вами метода, эта база данных теперь будет называться New Production Database. Установите для нее те же права (permissions), что были установлены для оригинальной Production Database. Если использовала отдельная Replication Database, то удалите из клиентских скриптов параметры подключения к ней. Вы можете отложить эту операцию, и выполнить ее позже, когда будет время. Т.к. поскольку в New Production Database отсутствуют триггеры репликации (Replication Triggers), то копирование данных происходить не будет, а у пользователей просто будет оставаться дополнительный коннект. Его можно будет использовать в будущих операциях Pro D&L. Хотелось бы обратить внимание на то, что если вы для подключения к Replication Database использовали Auto-Connect, то этот шаг вообще можно пропустить.

Проверьте, что для New Production Database правильно настроены следующие значения:
    BI Cluster Size;
    AI Block Size;
    BI Block Size;
    Возможно, вам понадобится включить поддержку больших файлов proutil EnableLargeFiles.

Если необходимо – включите after-imaging. Помните, для этого потребуется сформировать полную резервную копию (full backup). Если необходимо – включите Two Phase Commit. Переформатируйте BI файл с помощью proutil bigrow. Перезапустите New Production Database с помощью стандартных скриптов запуска промышленной базы. Восстановите работу всех процессов (интерактивных и  фоновых), работа которых была прекращена, или приостановлена на время Pro D&L. Сообщите пользователям, что базы данных готова к работе.

Теперь вы успешно завершили работу Pro D&L!