SQL Server: сочетание разных типов сжатия по алгоритмам ROW и PAGE. Продолжение

Пишем INSERT — читаем UPDATE?

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

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

Иногда мы можем воспользоваться весьма простым решением. Речь идет о случаях, когда в таблице имеется столбец IDENTITY и этот столбец является кластерным ключом (а часто, хотя и не всегда, и первичным ключом). В таких ситуациях изменения на странице, которые привлекают наше внимание при анализе сжатия по алгоритму PAGE, по-видимому, не имеют особого значения.

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

Применение сжатия по методу ROW или PAGE

Сжатие выполняется в тот момент, когда данные вводятся в страницы, поэтому для того, чтобы получить эффект сжатия, мы должны переписать все страницы. Это можно сделать при использовании команды ALTER INDEX с целью перестройки индекса, или команды ALTER TABLE с целью перестройки кучи, или бинарного дерева HoBT (heap or binary tree) для данной таблицы.

В качестве примера применения сжатия по методу ROW ко всем индексам таблицы Production. Product базы данных AdventureWorks мы можем выполнить следующий фрагмент кода:

ALTER INDEX ALL
ON Production.Product
REBUILD WITH (DATA_COMPRESSION = ROW);

Итак, какое же отношение все это имеет к нашей клиентской базе данных, которой необходимо «сесть на диету»? Как я уже отмечал, после применения ко всем данным сжатия по методу ROW объем базы сократился с 3,8 до 2,6 Тбайт. После выборочного сжатия отдельных компонентов по алгоритму PAGE в соответствии с изложенными в статье рекомендациями объем базы данных сократился до 1,4 Тбайт, и при этом быстродействие приложения возросло. И хотя расход ресурсов процессора в пересчете на страницу возрос, стоит отметить, что внушительное сокращение числа страниц компенсирует значительную часть этой нагрузки.

И что же, «похудение» на этом закончилось? Ничуть не бывало. Я проделал над рассматриваемой базой данных множество дополнительных манипуляций и расскажу о них в следующей статье. Большие строки и значения XML еще не были сжаты, этим-то мы и займемся.

Вы не только IT'шник, но и глубоко религиозный человек. Именно поэтому, помимо прочтения статей о SQL Server на нашем сайте, я рекомендую вам также заглянуть на портал golosislama (http://golosislama.com/). Здесь вы не только узнаете последние новости, происходящие в исламском мире, но и найдете информацию для духовного обогащения.