Напомню, что эта статья, как и отчасти предыдущая, тоже посвящена ловушкам и представляет интерес не для всех читателей. Если вы читаете материалы данной серии, что называется, для общего развития и вас интересует лишь проблема выбора решения, пользы от этих статей для вас будет немного. Работая над ними, я имел намерение пояснить, почему попытки динамически определить, следует ли выполнять то или иное задание, не всегда достигают цели. В последнем разделе предыдущей статьи, посвященном первой ловушке на пути динамического выявления, было показано, почему
попытка запустить код, представленный на экране 1, не удается, если базируется на неосновной реплике AlwaysOn Availability Replica (предназначенной к тому же не только для чтения).
Причина такого сбоя (который происходит несмотря на то, что администратор реализовал тестовую логику с целью определения, является ли целевая реплика основной) состоит в том, что база данных MyAGDatabase на вторичном сервере, в сущности, пребывает в состоянии восстановления, и потому доступ к ней принципиально невозможен.
Поэтому, если рассуждать логически, можно прийти к такому заключению: чтобы код функционировал корректно, достаточно придать ему чуть больше динамизма и, возможно, начать в главной базе данных (или в какой-либо иной), а затем по завершении выявления с помощью оператора USE перейти в MyAGDatabase (см. экран 2).
Логика подсказывает, что код, представленный на экране 2, должен работать. Если основная реплика размещается на сервере, где выполняется код, мы перейдем к логике, которая приведет нас в базу данных MyAGDatabase и запустит наш код. А если наш сервер не является основным, то код завершает работу нормально, не выполняя никаких действий. Логически все должно работать нормально, но здесь мы попадаем в ловушку № 2.
Комментарии