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

Опция drop existing

Если задана опция DROP EXISTING, то перед созданием нового индекса удаляется существующий индекс с именем, которое совпадает с именем создгшаемого индекса. Эта опция обеспечивает гораздо более эффективное формирование индекса по сравнению с тем, когда происходит просто удаление и повторное создание существующего индекса, если он используется в сочетании с кластеризованным индексом. Если в результате перестройки должен быть получен индекс, полностью совпадающий с существующим индексом, то СУБД SQL Server определяет, что такой некластеризованный индекс не следует подвергать операции удаления и повторного создания, а при выполнении явно заданных операций удаления и создания поневоле прргходится дважды выполнять перестройку всех некластеризованных индексов с учетом изменения местонахождения строк. Если же структура индекса модифицируется с применением опции DROP EXISTING, то перестройка некластеризованных индексов осуществляется не два раза, а только один раз. Более того, невозможно просто удалить и повторно создать индекс, сформированный с помощью ограничения, например, чтобы ввести в действие определенное значение коэффицрхента заполнения. А опция DROP EXISTING позволяет обойти это ограничение.

Опция statistics norecompute

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

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

Опция sort in tempdb

Применение опции SORT IN TEMPDB имеет смысл, только если база данных tempdb хранится на физическом жестком диске, отличном от того, где хранится база данных, в состав которой должен войти новый индекс. Функция распределения файлов по жестким дискам в основном относится к области деятельности администратора базы данных, поэтому в настоящем разделе будет дан лишь краткий обзор того, что означает эта опция и почему имеет смысл размещать базу данных tempdb на отдельном физическом устройстве.

При формировании индекса в СУБД SQL Server выполняется целый ряд операций чтения, описанных ниже, для осуществления различных этапов создания индекса.

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

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

3. Создание все новых и новых нелистовых страниц по мере заполнения листовых страниц.

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

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

Прежде чем приступишь к использованию опции SORT IN TEMPDB, убедитесь в том, что в базе данных tempdb имеется достаточный объем, пространства для формирования индексов на используемых таблицах.

Опция online

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

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

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

Опции allow row locks и allow page locks

Опции ALLOW ROW LOCKS и ALLOW PAGE LOCKS, в отличие от опции ONLINE, были введены в состав оператора CREATE INDEX в более ранних верси5гх:. Учитывая назначение данной книги, а также то, что приведенное в ней до сих пор описание блокировок таблиц является очень кратким, остановимся на довольно простом пояснении.

В данной книге уже неоднократно использовался термин блокировка . Как было описано выше, блокировка- это своего рода способ резервирования ресурсов, позволяющий предотвратить конфликты между операциями доступа к данным, которые могли бы привести к нарушению целостности данных. Опции ALLOW ROW LOCKS и ALLOW PAGE LOCKS служат для указания на то, могут ли применяться для создаваемого индекса блокировки на уровне страницы или на уровне строки. Использование этих опций может оказывать весьма заметное влияние на производительность, поэтому к ним следует прибегать с исключительной осторожностью.