Ключевое слово disable

По своему назначению ключевое слово DISABLE (Отменить) полностью соответствует своему определению. Но следует учитывать, что отмена действия индекса, осуществляемая при использовании этого ключевого слова, приводит к более серьезным последствиям, чем кг1жется на первый взгляд. Разумеется, было бы неплохо, если бы оператор с этим ключевым словом просто переводил индекс в автономный режим на то время, пока происходит подготовка к дальнейшим действиям, но вместо этого указанный оператор отмечает индекс как непригодный для дальнейшего использования. После отмены действия индекса необходимо вьшолнить его перестройку (еще раз подчеркиваем, не реорганизацию, а перестройку, с помощью ключевого слова REBUILD), и только после этого индекс снова вводится в действие.

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

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

Ключевое слово reorganize

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

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

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

Для этого проведем реорганизацию индекса на таблице базы данных Adventure -Works. Превосходным примером таблицы, в которую с наибольшей вероятностью со временем вставляется большое количество строк, после чего эти строки удаляются в связи с тем, что истекает интервал времени, в течение которого необходимо хранить информацию о транзакциях, является таблица Production. TransactionHistory.

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

ALTER INDEX ALL

ON Production.TransactionHistory REORGANIZE;

СУБД SQL Server при выполнении команды ALTER INDEX обнаруживает, что вместо определенного имени индекса задано ALL, и определяет, какие индексы относятся к рассматриваемой таблице Production. TransactionHistory (любые отмененные индексы игнорируются, поскольку процедура перестройки индексов на них не распространяется). После этого в СУБД незаметно для пользователя производится обработка каждого индекса и выполняется перестройка с реорганизацией только листового уровня каждого индекса (включая реорганизацию фактически хранимых в таблице данньпс, поскольку реорганизуется также кластерный индекс, заданный на этой таблице).

После выполнения этого оператора из СУБД не поступает какая-либо содержательная информация, передается лишь простое сообщение об успешном завершении: Command(s) completed successfully .

Архивирование данных

Задача архивирования данных является очень сложной. Достаточно сказать, что, наверное, каждый специалист по конструированию баз данных предлагает собственный способ архивирования данных. К тому же многое зависит от самого прможения. Например, если создается база данных OLAP, предназначенная для использования в сочетании со службами Analysis Services, то приходится учитывать, насколько далеко в прошлое могут быть обращены аналитические запросы. Но, независимо от используемого метода определения допустимого срока хранения данных, рано или поздно наступает такой день, когда приходится сталкиваться с проблемой удаления из работающей системы устаревших данных, из-за большого объема которых производительность неизбежно снижается.

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

Если данные уже хранятся в базе данных OLAP, то, по-видимому, запись этих данных в архив в связи с удалением из базы данных не требуется. Но этот вопрос должен быть решен на уровне руководства компании.

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

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

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

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

Заблаговременно и тщательно проверяйте все процедуры архивирования.

Резюме

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

Несколько лет тому назад автору довелось столкнуться с одной ситуацией, которая стала замечательным примером того, что разработчики должны брать на себя ответственность за все происходящее в связи с эксплуатацией созданного ими приложения. Для некоммерческой группы, которая работает на северо-западе Соединенных Штатов, по специальному заданию была разработана замечательная система. Но примерно через восемь месяцев посяе начала эксплуатации этой системы в компанию, разработавшую программное обеспечение, поступил тревожный звонок. После обсуждения всех обстоятельств происшествия было определено, что в файлах базы данных возникло какое-то искажение информации, поэтому специалисты компании порекомендовали заказчику восстановить базу данных из резервной копии. Но в ответ прозвучал недоуменный вопрос: Л что такое резервная копиям Рассматриваемая в данном примере компания-разработчик упустила нечто очень важное. Ее специалисты знали, что перед ними - неопытный заказчик, который не собирается привлекать к администрированию базы данных квалифицированный персонал. Кто же тогда должен был сообщить заказчику, что нужно создавать резервные копии, и помочь ему организовать такую работу, если об этом не подумали сами разработчики Я счастлив сообщить, что рассматриваемая здесь компания извлекла урок из полученного ею опыта, что не мешает также сделать всем прочим разработчикам.