Вопросы и ответы по SQL. Сжатие резервных копий, перенаправление клиентов при помощи зеркалирования баз данных

Q Мы собираемся обновить большая часть наших серверов до SQL Server 2008, и одна из функций, возникновения которых в производственной среде я жду с нетерпением, – сжатие запасных копий. Я знаю, что могу включить ее по дефлоту для всех баз данных на каждом сервере, но я также слышал, что, может быть, этого не стоит делать. Я не уверен, почему ее может быть не нужно включать по дефлоту, так как кажется, что терять тут нечего. Не могли бы вы посодействовать разъяснить предпосылки этого?

О. Ответом тут будет мой постоянно возлюбленный: все находится в зависимости от событий! Позвольте мне для разъяснения привести некую базисную информацию.

Главным моментом, который следует учитывать, является степень сжатия, которую будет иметь любая запасная копия базы данных, когда включено сжатие запасных копий. Степень сжатия при использовании хоть какого метода определяется тем, какие конкретно данные сжимаются.

Случайные данные (маленькие целочисленные значения, к примеру) буду сжиматься не очень отлично, так что вероятную степень сжатия будет определять в главном содержимое таблиц и индексов в базе данных.

Вот несколько примеров случаев, когда сжатие запасных копий может не дать высочайшей степени сжатия:

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

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

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

Кратко, если основная часть баз данных получит выгоды от сжатия запасных копий, имеет смысл включить сжатие запасных копий на уровне сервера и вручную поменять несколько задач запасного копирования, чтоб специально использовать параметр WITH NO_COMPRESSION. Как вариант, если основная часть баз данных не получит выгоды от сжатия запасных копий, имеет смысл отключить сжатие запасных копий на уровне сервера и вручную поменять несколько задач запасного копирования, чтоб специально использовать параметр WITH COMPRESSION.

В. В прошедшем году мы обновили наши базы данных, чтоб внести в их зеркалирование, позволяющее в случае сбоя перейти на зеркальную копию и продолжить работу. При разработке системы мы делали такие переходы для базы данных, и всё работало нормально. На прошлой неделе мы столкнулись с реальным сбоем, и переход базы данных произошел, но все транзакции приложения тормознули, и приложение не подключилось к отказоустойчивому серверу. Как я могу установить SQL Server в дальнейшем, чтоб он не сбрасывал подключения к приложениям в процессе перехода, чтоб транзакции могли длиться?

О. Давайте разобьем ответ на две части: как приложения могут управляться с отказоустойчивостью и как управлять перенаправлением клиентов при помощи зеркалирования баз данных.

Когда происходит переход при нарушении с внедрением хоть какой из технологий высочайшей доступности, имеющихся в SQL Server, подключение клиента к потерпевшему сбой серверу сбрасывается, и все находившиеся в работе транзакции теряются. Перенос находящейся в пути транзакции меж серверами неосуществим (как в случае перехода при отказе, так и любом другом). Зависимо от используемой технологии высочайшей доступности находящаяся в работе транзакция или не будет существовать вообщем на отказоустойчивом сервере, или будет существовать как находящаяся в работе транзакция, но будет откатана назад в качестве процесса восстановления работоспособности базы данных на отказоустойчивом сервере.

Что касается зеркалирования баз данных, повсевременно пересылающего записи журнальчика транзакций от основного сервера к зеркальному серверу, то обычно произойдет 2-ое – находящиеся в работе транзакции откатываются в процессе восстановления работоспособности зеркальной базы данных на новеньком участнике безопасности.

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

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

Единственная разработка высочайшей доступности тут, которая не просит непосредственно конфигураций на клиенте, чтоб позволить перенаправление клиентских подключений после перехода, – это отказоустойчивая кластеризация. Клиенты подключаются к имени виртуального сервера и прозрачно перенаправляются к активному узлу физического кластера.

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

Можно агрессивно закодировать имя отказоустойчивого сервера в клиент, чтоб пробы повторного подключения были ориентированы на этот сервер.
Можно использовать балансировку сетевой нагрузки с настройкой 100/0—0/100, что позволит потом переключить подключение на отказоустойчивый сервер.
Можно использовать чего-нибудть вроде псевдонима сервера либо переключения записей в таблице DNS.

При помощи зеркалирования баз данных сработает хоть какой из этих вариантов. Но зеркалирование баз данных также имеет интегрированные способности направления клиента. Строчка подключения клиента может прямо указать имя зеркального сервера, к которому автоматом произойдет попытка подключения если оно нереально к основному. Этот процесс известен как прямое перенаправление.

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

В техническом документе по SQL Server 2005 «Реализация отказоустойчивости приложений при помощи зеркалирования баз данных» эти варианты объяснены подробнее.

В. Когда мы перебежали на SQL Server 2005, мы переработали наши большие таблицы, чтоб они делились на разделы образом, позволяющим пользоваться пораздельным обслуживанием и механизмом скользящего окна. Это было описано в выпуске за август 2008 года («Разделение, проверки согласованности и другое»). Но мы столкнулись с неувязкой. Иногда параллельные запросы приложения испытывают блокировку по всей таблице, даже когда запросы пробуют получить доступ к разным разделам. Я слышал, что в SQL Server 2008 данная неувязка исправлена – не могли бы вы разъяснить, как я могу приостановить эту блокировку?

Вопросы и ответы по SQL. Сжатие запасных копий, перенаправление клиентов с помощью зеркалирования баз данных
Прирастить

Рис. 1. Исследование блокировок на таблице, поделенной на разделы

О. Наблюдаемая неувязка вызвана механизмом, называемым укрупнением блокировок. SQL Server получает блокировки на данные, чтоб защитить их, пока запрос читает либо записывает данные. Он может получать блокировки на целые таблицы, странички файлов данных либо отдельные строчки таблиц/индексов, и любая блокировка занимает маленькое место в памяти.

Если запрос вызывает получение очень огромного числа блокировок, SQL Server может решить поменять все блокировки на строчки либо странички в таблице единой блокировкой на всю таблицу (порог, где это происходит, составляет приблизительно 5000 блокировок, но четкий метод заковырист и настраиваем). Этот процесс именуется укрупнением блокировок.

В SQL Server 2005, если запрос А работает на одном разделе таблицы и вызывает получение достаточного числа блокировок, чтоб вызвать их укрупнение, вся таблица становится заблокированной. Это может предупредить работу запроса Б на другом разделе той же таблицы. В силу этого, запрос Б блокируется, пока запрос А не окончит работу и не сбрасывает свои блокировки.

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

Тогда запрос Б сумеет работать на другом разделе, не подвергаясь блокировке. Запрос Б даже сумеет сам вызвать укрупнение блокировок, которое перекроет только раздел, на котором работает запрос Б, а не всю таблицу.

Эту модель укрупнения блокировок можно установить, используя последующий синтаксис:

ALTER TABLE MyTable SET (LOCK_ESCALATION = AUTO);
GO

Этот синтаксис показывает диспетчеру блокировок SQL Server использовать укрупнение блокировок на уровне разделов, если таблица разбита на их, и обыденное укрупнение на уровне таблицы, если нет. Поведением по дефлоту является внедрение укрупнения блокировок на уровне таблицы. Устанавливать этот режим следует со осторожностью, так как зависимо от поведения запросов он может привести к взаимоблокировкам.

К примеру, если любой из запросов А и Б вызывает укрупнение блокировок разных разделов в таблице, но потом пробует получить доступ к разделу, заблокированному другим, один из запросов будет прерван монитором взаимоблокировок.

На рисунке показан пример запроса представления системного каталога sys.partitions (1-ый набор результатов) и динамического административного представления sys.dm_os_locks (2-ой набор результатов), чтоб изучить блокировки, удерживаемые для запросов на таблице, поделенной на разделы, где вышло укрупнение блокировок на уровне разделов. В этом случае есть две исключительные блокировки уровне раздела (блокировки HOBT в выводе), но блокировки таблиц (блокировки OBJECT в выводе) не исключительны, так что несколько запросов сумеют получать доступ к разделам, невзирая на укрупнение блокировок. Заметьте, что идентификаторы ресурсов для этих 2-ух блокировок разделов совпадают с идентификаторами разделов для первых 2-ух разделов таблицы в выводе для sys.partitions.

Ранее в этом году расположил в блог пример сценария, показывающий, как работает эскалация блокировок на уровне раздела и потенциал для взаимоблокировок. В теме электрической документации по SQL Server 2008 под заглавием «Блокировка в механизме базы данных» содержится подробное объяснение всех качеств блокировок в SQL Server 2008.

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

О. Кратко ответ заключается в том, что о восстановлении журнальчика транзакций я мог бы задуматься, только если восстановление из запасных копий нереально. Хотя вам и известны угрозы восстановления журнальчика транзакций (читатели могут поглядеть запись в моем блоге «Крайние меры, используемые сначала…», чтоб выяснить о их), факт того, что база данных стала ненадежной, значит то, что восстановление окончилось неудачей, – или при восстановлении после сбоя, или при откате транзакции. Это значит реальную возможность повреждения данных в базе данных.

Хотя неувязка и появилась в тихое время, поразмыслили ли вы о запланированных и фоновых задачках? В момент повреждения журнальчика полностью могла работать задачка обслуживания, восстанавливающая либо реорганизующая кластеризованный индекс. Фоновая задачка полностью могла вести фантомную чистку на страничках в куче либо кластеризованном индексе. Неважно какая из этих задач, для примера, могла заносить конфигурации в структуры кластеризованного индекса, которые в случае непроведения правильного отката привели бы к повреждениям в базе данных и вероятным потерям данных.

В общем, восстановление журнальчика транзакций всегда должно быть самой последней и последней мерой в любом варианте аварийного восстановления из-за больших способностей для последующих повреждений и утраты данных. Как минимум, на базе данных нужно выполнить полный DBCC CHECKDB, чтоб проверить, нет ли повреждений.

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

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.