Группы доступности AlwaysOn и задания SQL Server: дополнительные способы аварийных переключений заданий
Содержание:
1. Управление заданиями с помощью главных серверов;
2. «Продвинутые» системы ;
3. Дополнительные способы аварийных переключений заданий (Вы читаете данный раздел);
4. Еще один способ работы с аварийными переключениями и активацией заданий.
Во всех статьях данной серии я исходил из довольно пессимистичного представления о том, как специалисты большинства организаций управляют заданиями агентов SQL Server. Иначе говоря, почти все фрагменты кода и приведенные мною примеры базируются на допущениях о том, как осуществляется управление изменениями, вносимыми в задания.
• Управление изменениями. Основываясь на прошлом опыте, я пришел к следующему выводу. Если возникает необходимость внести в задание агента SQL Server какое-то изменение, оказывается, что во многих организациях не разработана соответствующая политика. Когда некое задание необходимо изменить, такая политика со стопроцентной гарантией должна обеспечивать внесение изменений на любом сервере (или на всех серверах), где размешается текущая группа доступности. Учитывая это обстоятельство, я подготовил ряд статей, демонстрирующих, как выполняются проверки синхронизации, позволяющие извещать администраторов обо всех несоответствиях, которые могут возникнуть после того, как кто-нибудь непреднамеренно изменяет ту или иную часть задания и забывает зафиксировать это изменение на всех остальных серверах. Так что рекомендую вам купить планшетный компьютер (http://www.shop.mts.ru/planshety/) и начать читать их уже на рабочем месте, где вы сможете произвести всю необходимую настройку вашего оборудования.
• Активация и деактивация заданий. Подобным же образом я исходил из того, что если в течение нескольких дней не будет необходимости выполнять то или иное пакетное задание, специалисты большинства организаций предпочтут не удалять это задание, а просто деактивировать его. Например, если имеется некое задание по обработке данных, которое нужно будет отключить, скажем, на три дня, я полагал, что администраторы предпочтут найти это задание и деактивировать его, вместо того чтобы удалить, а потом воссоздать через несколько дней. Дело не только в том, что процедуры активации и деактивации, на мой взгляд, выполнять проще, но и в том, что когда вы ограничиваетесь этими процедурами, сохраняется история выполненных операций. Проблема, разумеется, состоит в том, что если вы, к примеру, просто деактивируете задание на сервере А, то, когда вам придется переключаться на сервер В (в качестве основного), вы получите задание, которое должно быть «с логической точки зрения» отключено, но, скорее всего, будет активировано.
Все это может привести к катастрофическим последствиям. Поэтому я описал прием, позволяющий решить данную проблему с помощью «таблицы состояний». Напомнив еще раз о логической основе своего скептицизма, хочу отметить, что если в вашей организации действительно предусмотрена необходимая политика, позволяющая обойтись без проверок синхронизации заданий или если ваша организация предпочитает удалять задания (воссоздавая их, если потребуется), вместо того чтобы деактивировать и активировать их, имейте в виду, что существуют приемы, с помощью которых вы сможете легко решить проблему управления заданиями в ситуациях, когда в вашей среде реализованы группы доступности.
1. Управление заданиями с помощью главных серверов;
2. «Продвинутые» системы ;
3.
4. Еще один способ работы с аварийными переключениями и активацией заданий.
Во всех статьях данной серии я исходил из довольно пессимистичного представления о том, как специалисты большинства организаций управляют заданиями агентов SQL Server. Иначе говоря, почти все фрагменты кода и приведенные мною примеры базируются на допущениях о том, как осуществляется управление изменениями, вносимыми в задания.
• Управление изменениями. Основываясь на прошлом опыте, я пришел к следующему выводу. Если возникает необходимость внести в задание агента SQL Server какое-то изменение, оказывается, что во многих организациях не разработана соответствующая политика. Когда некое задание необходимо изменить, такая политика со стопроцентной гарантией должна обеспечивать внесение изменений на любом сервере (или на всех серверах), где размешается текущая группа доступности. Учитывая это обстоятельство, я подготовил ряд статей, демонстрирующих, как выполняются проверки синхронизации, позволяющие извещать администраторов обо всех несоответствиях, которые могут возникнуть после того, как кто-нибудь непреднамеренно изменяет ту или иную часть задания и забывает зафиксировать это изменение на всех остальных серверах. Так что рекомендую вам купить планшетный компьютер (http://www.shop.mts.ru/planshety/) и начать читать их уже на рабочем месте, где вы сможете произвести всю необходимую настройку вашего оборудования.
• Активация и деактивация заданий. Подобным же образом я исходил из того, что если в течение нескольких дней не будет необходимости выполнять то или иное пакетное задание, специалисты большинства организаций предпочтут не удалять это задание, а просто деактивировать его. Например, если имеется некое задание по обработке данных, которое нужно будет отключить, скажем, на три дня, я полагал, что администраторы предпочтут найти это задание и деактивировать его, вместо того чтобы удалить, а потом воссоздать через несколько дней. Дело не только в том, что процедуры активации и деактивации, на мой взгляд, выполнять проще, но и в том, что когда вы ограничиваетесь этими процедурами, сохраняется история выполненных операций. Проблема, разумеется, состоит в том, что если вы, к примеру, просто деактивируете задание на сервере А, то, когда вам придется переключаться на сервер В (в качестве основного), вы получите задание, которое должно быть «с логической точки зрения» отключено, но, скорее всего, будет активировано.
Все это может привести к катастрофическим последствиям. Поэтому я описал прием, позволяющий решить данную проблему с помощью «таблицы состояний». Напомнив еще раз о логической основе своего скептицизма, хочу отметить, что если в вашей организации действительно предусмотрена необходимая политика, позволяющая обойтись без проверок синхронизации заданий или если ваша организация предпочитает удалять задания (воссоздавая их, если потребуется), вместо того чтобы деактивировать и активировать их, имейте в виду, что существуют приемы, с помощью которых вы сможете легко решить проблему управления заданиями в ситуациях, когда в вашей среде реализованы группы доступности.
