.
Но AlwaysOn — не единственное удачное новшество SQL Server 2012. Так, недавно я описал некоторые предназначенные для разработчиков компоненты и улучшения SQL Server 2012 в журнале для разработчиков Dev Pro.
Среди достоинств SQL Server 2012 — несколько скрытых жемчужин, таких как косвенные контрольные точки, indirect checkpoint.
Упрощенный обзор контрольных точек
В силу особенностей работы SQL Server (изменения при INSERT, UPDATE, DELETE и других подобных операциях не вносятся сразу в файлы. mdf/.ndf, а записываются напрямую в журнал, а затем переносятся в память), возможна ситуация, когда изменения в памяти (и журналах) медленно «перевешивают» процесс восстановления. Таким образом, если произойдет сбой или закрытие SQL Server со слишком большим числом изменений, записанных ТОЛЬКО в памяти и в журнале, при перезагрузке сервера после аварии придется потратить слишком много времени на согласование изменений, сохраненных только в журналах, но не на диске (в. mdf/.ndf или файлах данных). Процесс контрольной точки периодически запускается и, в сущности, используется SQL Server, чтобы ответить на вопрос: «Если в данную секунду произойдет авария, как много времени потребуется, чтобы обработать все транзакции в журнале транзакций (для всех баз данных) и выполнить накат любых выполненных транзакций, а также откат всех незавершенных транзакций?»
По умолчанию, если предполагаемое время превышает 1 минуту (если процесс применяется ко всем базам данных), то SQL Server начинает согласование изменений в памяти (и журнале) с файлами данных. mdf/.ndf. При этом SQL Server просто берет «грязные страницы» в памяти и записывает их на диск — таким образом, зафиксированная транзакция оказывается не только устойчивой (это уже обеспечено журналом транзакций), но и согласованной с файлами данных на диске. Поэтому изменения данных, сделанные пользователями или приложениями, в конце концов сохраняются в файлах данных.
Это чрезвычайно упрощенное описание процесса. Пропущены многочисленные детали, в том числе то обстоятельство, что грязные страницы могут быть записаны на диск в силу других причин — например, неполадок с памятью — и т.д.
Управление интервалом контрольной точки в версиях, предшествующих SQL Server 2012
Главная особенность, которую нужно отметить в механизме протоколирования и организации контрольных точек — наличие стандартного интервала контрольных точек (1 минута). В версиях, предшествующих SQL Server 2012, это значение можно было поменять, изменив параметр recovery interval с помощью хранимой процедуры sp_configure. Обратите внимание, что процесс контрольной точки можно запустить вручную, используя команду T-SQL CHECKPOINT. Впрочем, в электронной документации отмечается, что с ней не следует экспериментировать, если вы не представляете ясно последствий своих действий.
В версиях, предшествующих SQL Server 2012, проблема заключалась в том, что это значение можно было установить только на уровне сервера (то есть любое заданное значение применялось не только ко всем базам данных, но и как функция общего целевого интервала восстановления для всех баз данных). Это обстоятельство, и минимальное значение, равное 1 минуте, означало, что до появления SQL Server 2012 можно было только расширить или увеличить временной интервал сверх одной минуты.
Таким образом, каждый раз, когда SQL Server терпит сбой или закрывается (кроме случаев, когда закрытие выполнено с помощью команды SHUTDOWN, с согласованием журналов/баз данных), повторный запуск начинается с процесса восстановления. Этот процесс восстановления будет применяться ко всем базам данных. Чтобы представить себе, что это такое, просто взгляните на журналы SQL Server и действия при запуске, и вы увидите, как SQL Server выполняет восстановление для всех баз данных (см. экран).
.jpg) |
| Экран. Операции SQL Server при восстановлении всех баз данных |
На мой взгляд, одно из главных достоинств SQL Server – безупречная временная синхронизация процесса контрольной точки, чтобы процесс восстановления мог быть совершен приблизительно в минутный интервал, указанный по умолчанию. Другими словами, такая способность SQL Server представляет собой удивительное инженерное достижение, и на сотнях серверов, с которыми мне доводилось работать как администратору баз данных или консультанту, я обязательно проверял это значение по журналам. В ходе этой проверки сообщение Recovery is complete («Восстановление завершено») почти всегда обнаруживалось в течение одной минуты после запуска — как часы (практически на каждом сервере, с которым я работал, за редкими исключениями).
Отказ, отработка отказа и запуск без косвенных контрольных точек
Итак, какова же цель этого рассказа о контрольных точках, восстановлении и т.д.?
Только напомнить, что при каждом запуске SQL Server будет потрачено дополнительное время на процесс восстановления. Конечно, это относится к возобновлению работы изолированного экземпляра SQL Server после аварий, сбоев питания и других неполадок.
Но сказанное применимо и в случаях, когда SQL Server входит в кластер или необходимо зеркалировать базу данных, имеющую критическое значение для функционирования компании.
Если имеется зеркальная или кластеризованная база данных, то даже в случае волшебной отработки отказа (что имеет место при правильной настройке) все равно неизбежны потери времени, связанные с процессом восстановления.
Например, если имеется кластер с двумя узлами, и узел A работает безупречно, то каждые несколько секунд запускается процесс контрольной точки, для проверки, что восстановление не займет более одной минуты. Но если узел A выходит из строя, то запускается процесс обхода отказа — узел B обнаруживает, что узел A отказал, а затем совместно с контроллером домена быстро завладевает виртуальным IP-адресом/именем системы, связанным с кластером. Затем начинается процесс доступа к общим накопителям, на которых находятся. mdf и. ldf файлы базы данных.
На данном этапе узел B обнаруживает аварийную систему, где базы данных не были согласованы до закрытия. Поэтому необходимо выполнить процесс восстановления (то есть все незавершенные транзакции отменяются, а полностью завершенные корректно вносятся в. mdf/.ndf файлы, чтобы избежать потерь зафиксированных изменений). Конечно, этот процесс занимает приблизительно одну минуту (если вы не настроили SQL Server на более длительный интервал).
То же самое, в сущности, происходит с зеркалированием.
Аналогично, такой же интервал восстановления требуется при отработке отказов AlwaysOn Failover Groups, так как им необходимо пройти по этапам такого же процесса восстановления.
Косвенные контрольные точки
В SQL Server 2012 администраторы баз данных наконец-то получили новый механизм, с помощью которого можно решить задачу интервала восстановления, а также настраивать и переключать его.
Главное, что появилась возможность настройки и переключения для отдельных баз данных. Это очень удобно, так как не все базы данных равноценны. С помощью нового компонента INDIRECT CHECKPOINT в SQL Server 2012 администраторы баз данных могут:
- указывать интервалы контрольных точек в секундах (а не только в минутах);
- при необходимости указывать интервалы контрольных точек МЕНЬШЕ 1 минуты;
- вносить эти изменения в отдельных базах данных.
Таким образом, если время безотказной работы имеет значение, например для одной базы данных в кластеризованном экземпляре, можно воспользоваться командой ALTER DATABASE и задать TARGET_RECOVERY_TIME 30 секунд вместо 1 минуты. В этом случае, если происходит изменение, следует ожидать, что база данных сможет восстановиться спустя 30 секунд после перезапуска или после отработки отказа кластерного, зеркального экземпляра или даже группы доступности AlwaysOn. При этом для других баз данных (для которых это значение не задано), время восстановления по-прежнему будет обычным — одна минута.
Очевидно, что возможности нового компонента очень полезны для администраторов баз данных, желающих оптимизировать минимальную продолжительность восстановления (RPO) и директивный срок восстановления (RTO), благодаря резкому снижению времени восстановления. Главное достоинство заключается в том, что если AlwaysOn IS — компонент SQL Server 2012 Enterprise Edition, то косвенные контрольные точки доступны для всех разновидностей SQL Server 2012. Таким образом, эта функция доступна, если вы хотите использовать зеркалирование, традиционные кластеры, или просто намерены улучшить время восстановления автономного компьютера.
Вероятно, вы уже поняли: за преимущества придется заплатить. Теперь SQL Server придется работать интенсивнее, улучшая синхронизацию изменений в журналах/памяти с файлами данных с целью сократить время восстановления.
Поэтому, если вы заинтересованы в использовании этой функции, обязательно учитывайте предостережения в электронной документации по SQL Server 2012 (обратитесь к разделу Impact of Recovery Interval on Recovery Performance по адресу http://msdn.microsoft.com/en-us/library/ms189573.aspx). Внедрять эту функцию следует ОЧЕНЬ осторожно. Нельзя рисковать перегрузкой серверов при высоких требованиях к процессу контрольных точек/согласования. Кроме того, помните: если имеется большое число выполняющихся в течение длительного времени транзакций, то этот компонент может не принести ожидаемых преимуществ.