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

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

Имеется ли достаточный объем свободного пространства? Следует учитывать, что для переупорядочения таблицы с кластеризованным индексом в среднем требуется дополнительный объем, превышающий в 1,2 раза объем пространства, которое в настоящее время занимает таблица (при этом учитывается необходимость распределения рабочего пространства и нового индекса). Поэтому, если обрабатывается очень большая таблица, может потребоваться весьма существенный объем дополнительного пространства, для распределения которого следует подготовить место. Между прочим, все названные операции осуществляются в самой базе данных, поэтому возможность переупорядочения любой кластеризованной таблицы определяется тем, какие значения опций максимального размера и роста заданы для базы данных.

Следует ли использовать опцию SORT IN TEMPDB? Если предусмотрено размещение базы данных tempdb на физическом жестком диске, отличном от того, где находится основная база данных, и на этом жестком диске имеется достаточный объем пространства, то ответ на этот вопрос, по-видимому, должен быть положительным.

Преимущества кластеризованных индексов

Юхастеризованные индексы целесообразно задавать на таких таблицах, в которых рассматриваемый столбец (столбцы) часто применяется в запросах, охватывающих целый ряд строк. Отличительной особенностью подобньгх запросов является то, что в них используются операции BETWEEN или операции сравнения < и >. Характерными примерами запросов, в которых осуществляется доступ к целому ряду строк и для выполнения которых хорошо подходят кластеризованные индексы, являются такие запросы, в которых применяются конструкции GROUP BY и агрегирующие функции МАХ, MIN и COUNT. Юхастеризация способствует успешному выполнению этих запросов, поскольку обеспечивается возможность начать поиск с определенной строки в составе хранимых данных, затем продолжать чтение до тех пор, пока остаются в силе условия, по которым должна быть выполнена выборка данных, а после этого прекратить обработку данных. Такая организация доступа к данным является чрезвычайно эффективной.

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

Недостатки кластеризованных индексов

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

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

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

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

ARXXXXXX Accounts Receivable Transactions

GLXXXXXX General Ledger Transactions

APXXXXXX Accounts Payable Transactions

В данном случае XXXXXX представляет собой последовательное числовое значение

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

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

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

Новые строки, относящиеся к главной книге (General Ledger- GL), действительно будут записываться вслед за последней строкой таблицы (поскольку префикс GL занимает после сортировки по алфавиту последнее место в списке префиксов, а номера

транзакций возрастают последовательно). Но при вводе данных, относящихся к транзакциям типа AR и АР, возникают серьезные проблемы, поскольку нарушается последовательный порядок вставки. После перехода к выполнению, допустим, операции вставки данных по транзакции с ключом АР000025, в СУБД SQL Server обнаруживается, что на соответствующей странице недостаточно места, после чего СУБД находит в таблице строку с ключом AR000001 и определяет, что операция вставки не является последовательной. Прежде чем появится возможность выполнить операцию вставки данных с ключом АР000025, необходимо скопировать половину строк со старой страницы на новую страницу.

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

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

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

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

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

Приведенный выше пример, по-видимому, наиболее отчетливо демонстрирует причины, по которым автор стремится так подробно описать действия, выполняемые