Функции резервного копирования

В данной серии статей по SQL Server 2014 описываются самые важные функции, добавленные компанией Microsoft в новую версию продукта. На этот раз я начну с изменений в функциях резервного копирования. SQL Server 2014 располагает рядом технологий обеспечения доступности, такими как группы Always On и экземпляры отказоустойчивого кластера SQL Server, но механизмы резервного копирования остаются основными технологиями аварийного восстановления.

Шифрование резервных копий SQL Server

Одним из самых долгожданных улучшений в механизме резервного копирования SQL Server была возможность шифровать резервные копии и таким образом защищать хранимые данные. Эта возможность уже присутствовала в продуктах резервного копирования других компаний, но Microsoft впервые реализовала встроенную функцию резервного копирования в SQL Server 2014. Шифрование резервных копий поддерживается в версиях SQL Server 2014 Standard, Business Intelligence и Enterprise. Используются следующие алгоритмы шифрования резервных копий: AES 128, AES 192, AES 256 и Triple DES. Для шифрования нужно создать главный ключ базы данных, который представляет собой симметричный ключ, используемый для защиты частных ключей сертификатов, и асимметричные ключи в базе данных. Кроме того, необходимо подготовить сертификат или асимметричный ключ, который будет использоваться для шифрования резервной копии базы данных.

Резервное копирование по URL-адресу

Интеграция с «облаком» была одним из основных приоритетов Microsoft во время работы над SQL Server 2014, и, как следствие, в SQL Server 2014 появилась возможность резервного копирования в «облако». Резервные копии SQL Server 2014 могут быть направлены по URL-адресу, указывающему на хранилище данных Azure Storage. В сущности это означает, что устройство архивации представляет собой URL-адрес Azure Storage, а не целевой диск или накопитель на магнитной ленте. Резервное копирование по URL-адресу позволяет без труда сохранять резервные копии в удаленном хранилище или вне основного центра обработки данных. Для использования резервного копирования по URL-адресу необходимо иметь:

  • подписку Azure;
  • доступ к Azure через портал Azure или с использованием PowerShell;
  • учетную запись хранилища данных Azure;
  • контейнер в учетной записи хранилища данных Azure.

Управляемые резервные копии

SQL Server Managed Backup to Windows Azure предназначен в первую очередь для малого и среднего бизнеса (SMB) и, в сущности, автоматизирует процесс создания резервных копий и перенаправляет их в хранилище данных Windows Azure. Управляемые резервные копии можно назначать на уровне базы данных или на уровне экземпляра для управления всеми базами данных на сервере. Экземпляр SQL Server может функционировать локально, в виртуальной машине или в качестве виртуальной машины Windows Azure. В основе стратегии резервного копирования, используемой SQL Server Managed Backup to Windows Azure, лежит период хранения и транзакционная рабочая нагрузка на базу данных. Как и в случае с резервным копированием по URL-адресу, для SQL Server Managed Backups to Windows Azure требуются подписка и учетная запись хранилища данных Azure.

Агент SQL Server Managed Backup to Windows Azure назначает полное резервное копирование базы данных, когда:

  • SQL Server Managed Backup to Windows Azure включен с настройками по умолчанию на уровне экземпляра;
  • SQL Server Managed Backup to Windows Azure включается первый раз для базы данных;
  • объем журнала со времени последнего полного резервного копирования базы данных увеличивается более чем на 1 Гбайт;
  • прошла неделя со времени последнего полного резервного копирования базы данных;
  • испорчена цепочка журналов.

SQL Server Managed Backup to Windows Azure назначает полное резервное копирование журнала транзакций, если:

  • отсутствует история резервного копирования журналов;
  • размер журнала транзакций составляет 5 Мбайт или более;
  • прошло два часа со времени последнего резервного копирования журнала;
  • если резервное копирование журнала транзакций отстает от полного резервного копирования базы данных.

Дополнительные сведения об улучшениях в механизме резервного копирования SQL Server 2014 можно найти на сайте MSDN в разделах SQL Server Backup to URL Best Practices (https://msdn.microsoft.com/en-us/library/jj919149(v=sql.120).aspx) Troubleshooting и SQL Server Managed Backup to Windows Azure (https://msdn.microsoft.com/en-us/library/dn449496(v=sql.120).aspx).

Расширение буферного пула

Теперь мы переходим к расширению серверного пула, которое повышает производительность приложений OLTP. Давайте посмотрим, как расширение серверного пула SQL Server 2014 может повысить производительность приложений.

Сначала вспомним, что такое буферный пул. Буферный пул SQL Server — это кэш-память, где временно хранятся результаты запросов. Благодаря хранению результатов запросов в буферном пуле SQL Server последующие запросы, дающие аналогичные результаты, выполняются значительно быстрее, поскольку для их выполнения нет необходимости обращаться к диску для извлечения данных. Из буферного пула данные извлекаются гораздо быстрее, чем при считывании с диска, когда задействованы операции ввода-вывода. В зависимости от рабочей нагрузки, буферный пул SQL Server динамически расширяется и сжимается. Буферный пул SQL Server состоит из пула буфера и диспетчера буфера. Пул буфера — это совокупность 8-килобайтных страниц с результатами недавних запросов. Диспетчер буфера обрабатывает операции чтения данных или страниц индексов из файлов диска с базой данных в буферный кэш и записи измененных страниц обратно на диск.

Буферный пул повышает скорость выполнения запросов, но его размер ограничен общим размером оперативной памяти, которым располагает экземпляр SQL Server. Размер буферного пула также может ограничиваться заданным значением максимального объема памяти сервера. Если ограничение отсутствует, SQL Server динамически увеличивает буферный пул до тех пор, пока максимальная доступная память сервера не выходит на уровень между 4 и 10 Мбайт. По достижении этого предела рост буферного пула прекращается. Расширение буферного пула открывает возможность увеличения буферной памяти сервера за счет использования флеш-накопителей, например твердо­тельных дисков (SSD), если таковые имеются в системе. Малая задержка и высокая производительность случайных операций ввода-вывода у современных SSD позволяют эффективно использовать их для увеличения размера серверного пула SQL Server. Такая возможность особенно полезна для старых серверов, у которых уже выбрана максимальная память. В этом случае производительность экземпляра SQL Server все же можно увеличить за счет использования буферного пула большего объема. Функция расширения буферного пула, реализованная в SQL Server 2014, позволяет разместить в нем рабочее множество большего размера без обязательной замены дорогостоящего сервера.

Функция расширения буферного пула доступна для выпусков SQL Server 2014 Enterprise, Business Intelligence и Standard x64. В случае SQL Server Enterprise размер расширения может в 32 раза превышать размер максимальной памяти сервера (значение max_server_memory), а для Business Intelligence и Standard — в четыре раза. Рекомендуемое соотношение между размером физической памяти (max_server_memory) и размером расширения буферного пула не должно превышать 1:16. Хорошей отправной точкой является соотношение 1:4.

Включить расширение серверного пула можно с помощью команды ALTER SERVER CONFIGURATION:

ALTER SERVER CONFIGURATION
SET BUFFER POOL EXTENSION ON
SIZE = 50 GB
FILENAME = 'F:\SSDBUFFERPOOL.BPE'

Подробную информацию о новом буферном пуле SQL Server 2014 можно найти на сайте MSDN (https://msdn.microsoft.com/en-us/dn133176.aspx) и в блоге, посвященном SQL Server (http://blogs.technet.com/b/dataplatforminsider/archive/2013/07/25/buffer-pool-extension-to-ssds-in-sql-server-2014.aspx).

Кластеризованный индекс columnstore

Следующая наша тема — доработка индекса columnstore. Этот индекс специалисты Microsoft впервые применили в версии SQL Server 2012, что привело к значительному повышению производительности при обработке запросов по технологии информационных хранилищ. Разработчики утверждают, что при выполнении некоторых типов запросов индексы columnstore позволяют добиться повышения производительности в 10 раз.

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

Первая реализация индексов columnstore обеспечила значительное повышение производительности при выполнении запросов в хранилищах данных. Однако у этого метода есть свои ограничения. Базовая таблица должна быть предназначена только для чтения. Чтобы обновить эту таблицу, необходимо отключить индекс columnstore и затем воссоздать его по завершении обновления таблицы. В версии SQL Server 2014 данное ограничение снимается, так что новый индекс columnstore можно обновлять. Базовую таблицу можно обновлять без предварительного отключения индекса columnstore. Давайте рассмотрим усовершенствования, внесенные в индекс columnstore системы SQL Server 2014, более подробно.

Индексы SQL Server 2014 columnstore реализованы в версиях Enterprise, Developer, а также Evaluation, и не могут использоваться наряду с другими индексами. Индексы columnstore подвергаются исключительно высокой степени сжатия. Сжатие данных дает возможность сокращать объем таблиц до 7 раз. В системе SQL Server 2014 изменяется способ реализации индекса columnstore — она позволяет работать как с кластеризованными, так и с некластеризованными индексами columnstore. Версия SQL Server 2012 поддерживала только некластеризованные индексы columnstore. Совместимость версии SQL Server 2014 с кластеризованными индексами columnstore позволяет обновлять индексы columnstore.

К характеристикам некластеризованных индексов columnstore относятся следующие:

  • эти индексы не обновляются;
  • допускается индексирование подмножества столбцов;
  • для хранения копии столбцов в индексе требуется дополнительный объем памяти;
  • перед созданием индекса данные необходимо отсортировать.

Теперь перечислим характеристики кластеризованных индексов columnstore:

  • эти индексы допускают обновление;
  • они представляют собой главный метод хранения всей таблицы.

Возможно, у вас возникнет вопрос: если уровень сжатия данных в кластеризованном индексе columnstore столь высок, каким образом этот индекс обеспечивает выполнение таких операций, как вставка, обновление и удаление? Для осуществления вставки, обновления и удаления система SQL Server 2014 использует конструкции deltastores и битовые карты delete bitmaps, в которых осуществляется временное хранение данных. Выполняемый в фоновом режиме процесс асинхронно внедряет изменения в базовую таблицу. Кластеризованные индексы SQL Server 2014 columnstore можно задействовать при работе с группами доступности SQL Server AlwaysOn. Однако здесь имеется одно существенное ограничение: поскольку кластеризованные индексы columnstore не поддерживают уровень изоляции моментального снимка, эти индексы нельзя использовать при работе с доступными для чтения вспомогательными репликами. Более подробную информацию о реализованных в системе SQL Server 2014 усовершенствованных индексах columnstore можно найти в статье Columnstore Indexes Described на сайте MSDN.