Какой самый проверяемый способ организации сценариев / расписаний обслуживания базы данных?

Question

Я использую PHP, Oracle и crontab. Crontab вызывает скрипт php, который синхронизирует некоторые данные между локальной и удаленной базами данных.

Сначала я подумал о том, чтобы поместить все это в один большой анонимный встроенный PL / SQL-блок и выполнить его на PHP. Проблема в том, что без создания таблицы для аудита процедуры она действительно непрозрачна для моего PHP-кода, пока не вернется. И затем, когда он действительно возвращается, лучшее, что я могу сделать, - это получить строку в выходном параметре, который я объединил вместе в качестве журнала аудита.

Затем я подумал о том, чтобы разбить его на несколько операторов SQL, и чтобы PHP выполнял промежуточный аудит / ведение журнала и манипулирование данными между каждым из них.

Я не очень доволен ни одним из них. Как вы организуете код обслуживания, который вызывается в cronjob?

Answer 1

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

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

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

Answer 2

Я предполагаю, что вы используете режим ручной фиксации для этого типа скриптов. Большинство сценариев обслуживания, которые я использую, просто выполняют работу с довольно маленькими запросами (не то, что чем меньше, тем лучше, а чем меньше, тем проще) и генерируют исключения, когда что-то идет не так, если исключения не восстанавливаются, тогда я откатываю модификации и использую error_log() и для критической задачи mail() для вывода проблемы. Если все работает хорошо, вывод не производится вообще, изменения просто фиксируются. Если мне нужен флаг или что-то еще, я могу использовать apc_store / apc_fetch() или простой файл.

Answer 3

Если как локальная, так и удаленная базы данных являются Oracle, то вы можете рассмотреть Oracle Replication в качестве более устойчивой альтернативы сценарию PHP