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


tretja-lovushka-na-puti-dinamicheskoj_1.png

Выше я показал, почему попытка динамически вставить команду USE myTargetDatabase в системе SQL Server удается лишь в случае использования таких небезопасных средств как перенаправления из хранимых процедур или применение динамического SQL.

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

Динамическая проверка в процессе выполнения заданий агента SQL Server

В самом общем виде предлагаемый мною метод сводится к следующему. Администратор вводит в уже существующие задания либо перед ними новый шаг задания агента SQL Server и предписывает системе в ходе этого шага выполнить определенный код. В результате система возвращает ответ на вопрос, нужно ли выполнять некий другой фрагмент кода, содержащийся в последующих шагах задания.

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

Представим себе, что наше задание первоначально состоит всего из одного шага (см. экран 3).

Комментарии