(Возврат на основную страницу)
Репликация модулей кода в SQL Server 2005
Помимо репликации табличных статей, SQL
Server 2005, как и предыдущие версии, позволяет реплицировать модули
кода: хранимые процедуры, представления
(в том числе индексированные) и пользовательские функции. Здесь я расскажу вам
об этой функциональности и поясню, в каких случаях стоит ей воспользоваться.
SQL Server 2005, как и предыдущие версии, позволяет реплицировать модули кода: хранимые процедуры, представления (в том числе индексированные) и пользовательские функции (userdefined function, UDF). В статье приведен обзор этой функциональности и объясняется, в чем ее преимущества.
Агенты транзакционной репликации в SQL Server 2005
Агенты репликации в SQL Server 2005 изначально настроены оптимальным образом, но иногда вам может потребоваться изменить их поведение по умолчанию, модифицировав значения параметров. В SQL Server 2005 некоторые из параметров, которые раньше были доступны только из командной строки или через шаги заданий агентов, теперь можно настроить с помощью графического интерфейса.
Эта статья посвящена внутренним особенностям работы агентов репликации: параметрам безопасности, свойствам и профилям. Я также расскажу о нескольких системных процедурах для программного управления агентами репликации. Особо я выделю представленные в SQL Server 2005 улучшения и научу, как извлечь из них максимальную пользу.
Кластеры в SQL Server 2005
Функциональность высокой доступности в SQL Server 2005 совершила гигантский скачок вперед, представив небольшие изменения в области кластеризации и новые возможности обеспечения высокой доступности как для небольших, так и для крупных компаний.
В этой статье я сконцентрируюсь на том, что кластеризация может дать вашей компании, что нового появилось в этой области в SQL Server 2005 и как эти улучшения могут обеспечить надежность вычислительной среды. Еще мы поговорим о том, как наилучшим образом применять кластеры SQL Server в целях обеспечения высокой доступности.
Большая часть разговоров о высокой доступности вокруг SQL Server 2005 сводится к зеркалированию БД, так что остается вопрос, когда же стоит применять кластеризацию. Даже в SQL Server 2005 создание кластеров должно стоять первым в списке возможных вариантов обеспечения высокой доступности, если вы можете себе позволить такое решение. Особенно подкупает в кластеризации тот факт, что вы можете настроить ее единожды и она будет работать для любой добавленной на сервер БД. Зеркалирование и репликацию нужно настраивать отдельно для каждой БД, так что при создании новой базы вам придется повторить весь процесс сначала.
В SQL Server 7.0 создание кластеров было довольно утомительной задачей. Если вы могли создать кластер и поддерживать его в стабильном состоянии, то были очень востребованным специалистом и возможность потери работы вас волновала даже меньше, чем президента компании. Боюсь, что с выходом Windows 2003 и SQL Server 2005 ситуация изменилась. Когда я рассказываю, как создать кластер на базе Windows 2003, первое, что я слышу: «И это все?!». Благодаря мастерам от Microsoft я был свидетелем, как прежнее восхищение моих коллег сменилось этим ужасающим вопросом. Неплохой удар по самолюбию для тех, кто считал себя незаменимым, потому что мог объединять серверы в кластеры.
Прежде чем углубиться в кластеризацию SQL Server, нужно познакомиться с базовой терминологией. Когда я впервые имел дело с кластеризацией компьютера на базе Windows, терминология вызывала у меня панику, поскольку была мне совершенно чужой. Посмотрим, смогу ли я объяснить все лучше. Кластеризация позволяет иметь набор серверов, которые делят между собой набор дисков. Если один из серверов выходит из строя, его ресурсы, такие как SQL Server, переносятся с текущего сервера на один из оставшихся. В правильно сконфигурированном кластере весь процесс занимает меньше минуты. Бывает и так, что SQL Server требуется около 5 минут для переноса ресурсов с одного сервера на другой. Время варьируется в зависимости от применяемого аппаратного обеспечения и в значительной мере от времени, необходимого для останова служб на одном сервере и запуска на другом.
Самое распространенное заблуждение, связанное с кластерами на базе Windows, заключается в том, что их применение повышает производительность, но это не так. Кластеризация — это не механизм для масштабирования или распределения трафика. Идея в том, что, если один из серверов выходит из строя, его службы и разделяемые данные переносятся на другой сервер в кластере. А для масштабирования трафика предназначены распределенные разделенные представления и репликация. Основное ПО для управления кластеризацией в Windows — это Microsoft Cluster Service (MSCS). Для создания кластера вы должны использовать как минимум Windows 2003 Enterprise Edition. Windows 2003 Data Center предоставляет гораздо лучшую защиту от сбоев, но по очень высокой цене. Можно купить ПО и оборудование сторонних разработчиков, но MSCS становится все надежнее, что приводит к вытеснению с этого рынка многих производителей. Например, HP/Compaq недавно отказались от своего решения для кластеризации под названием RSO, и их персонал по продажам теперь продвигает MSCS.
Каждый участвующий в кластеризации сервер называют узлом (node). Windows 2003 Server Enterprise Edition и DataCenter Edition поддерживают до восьми узлов в кластере. В Windows 2000 Enterprise Edition вы могли создавать кластеры лишь из двух узлов. Инструмент под названием Cluster Administrator управляет в Windows ресурсами кластера, в том числе ресурсами SQL Server, например такими, как SQL Server Agent. В Cluster Administrator можно задать, какой сервер будет предпочтительным владельцем ресурса (вроде SQL Server), а также кто может владеть ресурсом кроме него. То есть, имея возможность создавать кластеры из восьми узлов, вы можете возложить задачу отказоустойчивости данной службы на конкретный узел. Кроме того, можно указать, что одна служба зависит от другой. Указав зависимую службу, можно гарантировать, что SQL Server не запустится, пока не готовы диски.
Зеркалирование: новый взгляд на проблему высокой доступности
Не так давно для журнала «SQL Server Standard» я написал статью, где рассказал, что такое зеркалирование и как оно работает. Эта статья в чемто повторяет предыдущую, но здесь я более подробно остановлюсь на защите от сбоев и сравнении разных подходов к обеспечению высокой доступности.
Каждому требуется высокая доступность (High Availability, HA) данных, но это не только техническая проблема. HA часто меряют в процентах от общего рабочего времени за год, когда система была доступна для использования. «Святым Граалем» высокой доступности считаются 5 девяток, то есть цель в том, чтобы система была готова к работе 99,999% времени, что составляет примерно 5 минут простоя в год. Насколько ваша организация близка к этой цели? Достичь ее можно, лишь объединив Людей, Процессы и Технологии. Как все мы знаем, DBA защищают второй по важности ресурс организации — данные. А самый ценный ресурс любой организации — люди. Достижение HA начинается с нужных людей. Лишь правильно подобранный персонал сможет воплотить в жизнь процессы и технологии, способные сделать данные действительно высокодоступными. Все технологии мира вместе с самыми совершенными процессами не решат задачи, если люди не являются ключевой частью уравнения.
Процессы должны быть задокументированы, чтобы персонал знал, какие именно действия он должен предпринять для достижения высокой доступности. Процессы включают в себя отработку правильных действий до возникновения аварийной ситуации, это помогает проверить работу всей системы в целом. Неотъемлемой частью такого тестирования является выполнение ключевых задач членом команды с наименьшим опытом. Цепь прочна настолько, насколько прочно ее самое слабое звено. Вы в курсе, где ваши самые слабые звенья?
Мы сосредоточимся на технологии зеркалирования БД, а также других встроенных решениях SQL Server, готовых к применению сразу после установки.
Обзор зеркалирования
Зеркалирование баз данных — одна из наиболее ожидаемых функций SQL Server 2005. В двух словах, она позволяет иметь на другом сервере актуальную копию вашей рабочей БД. При сбое все будет выглядеть так, словно БД с отказавшего сервера была восстановлена на другом и готова обслуживать подключения. В некоторых сценариях зеркалирование можно настроить таким образом, чтобы автоматическое переключение на копию БД занимало меньше трех секунд. Сервер с копией БД не обязательно должен находиться поблизости от оригинала в географическом смысле; это, конечно, способствует повышению производительности, но в данном случае все зависит от особенностей среды и ваших нужд. Еще одним плюсом этой технологии является отсутствие особого списка совместимого оборудования (Hardware Compatibility List, HCL), которому должно отвечать аппаратное обеспечение сервера, чтобы пользоваться новой функциональностью. Минимальные требование к оборудованию те же, что и для SQL Server 2005. При зеркалировании можно даже смешивать 32 и 64разрядные компьютеры. В отличие от кластеризации, эта функция работает на уровне БД, а не системы в целом. Выбирая серверы, помните, что если база была восстановлена на сервере с более скромными характеристиками, производительность, скорее всего, тоже пострадает. Поскольку технология совсем новая, пока еще не опубликовано готовых рецептов ее применения, но здравый смысл подсказывает, что нельзя чтото получить, не отдав ничего взамен.
SQL, вопросы и ответы
Предотвращение перезагрузок, установка нескольких обновлений и др.
(Возврат на основную страницу)