менР1ть. Иными словами, журналы, предназначенные для восстановления, должны применяться в том же порядке, в каком происходило их резервное копирование.

На данном этапе можно было бы полностью разрешить доступ к базе данных, но допустим, что требуется оставить базу данных еще на какое-то время в автономном состоянии и только после этого снова перевести ее в активные! режим. Причем, даже если уже будут отсутствовать какие-либо другие журналы, предназначенные для применения, все равно потребуется повторно запустить на выполнение оператор RESTORE, чтобы снова перевести базу данных в активное состоянрхе: RESTORE LOG AdventureWorks WITH RECOVERY

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

USE AdventureWorks SELECT * FROM Region

Итак, будучи полностью уверенным в том, что так и произойдет, автор получает искомые результаты. И действительно, достаточно вызвать на выполнение несколько операторов SELECT, чтобы определить, восстановлена ли база данных должным образом.

После проведения такой проверки следует вспомнить, какая опция примен5гяась при восстановлении базы данных. В этом случае таковой была опция DBO ONLY. Вызвав на вьшолнение процедуру sp dboption, можно убедиться в том. что с базой данных в настоящее время не разрешено работать ником), кроме владельца: EXEC sp dboption

Об этом свидетельствует значение dbo use only: Settable database options:

ANSI null default ANSI nulls ANSI padding ANSI warnings arithabort

auto create statistics auto update statistics autoclose autoshrink

concat null yields null cursor close on commit db chaining dbo use only-default to local cursor merge publish numeric roundabort offline published quoted identifier read only recursive triggers select into/bulkcopy single user subscribed torn page detection trunc. log on chkpt.

После завершения восстановления базы данных необходимо отменить эту опцию, поскольку в противном случае обычные пользователи не смогут войти в систему: EXEC sp dboption AdventureWorks, dbo use only, false

С этого момента восстановленная база данных становится полностью работоспособной.

Сопровождение индексов

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

Команды, предназначенные для дефрагментации индексов, в последней версии SQL Server существенно изменились. В предыдущих выпусках применялись средства, известные под общим названием DBCC (DataBase Consistency Checker; некоторые специалисты также указывают, что эта аббревиатура расшифровывается как DataBase Console Command). К этим средствам в основном относятся команды DBCC INDEXDEFRAG, а также, в меньшей степени, DBCC DBREINDEX. В последней версии SQL Server указанные команды заменены новым оператором - ALTER INDEX.

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

Оператор alter index

Оператор ALTER INDEX предназначен не для модификации индекса, что, казалось бы, следует из его названия, а для выполнения другрсс действий. Все операторы ALTER, которые рассматривались до сих пор в настоящей книге, предназначены для корректировки определений тех или иных объектов. Например, оператор ALTER применительно к таблицам служил для добавления столбцов, а также ввода в действие или отмены ограничений. С другой стороны, оператор ALTER INDEX имеет иное назначение - он применяется исключительно для сопровождения индексов и не вносит никаких изменений в их структуру. Если требуется изменить определение индекса, то необходимо либо уничтожить его с помощью оператора DROP, а затем создать, применив оператор CREATE, либо воспользоваться оператором CREATE с опцией DROP EXISTING=ON.

Оператор ALTER INDEX имеет следующий синтаксис:

ALTER INDEX { <name of index> ALL } ON <table or view name> { REBUILD

[ [ WITH ( <rebuild index option> [ ,...n ] ) ] I [ PARTITION = <partition number>

[ WITH ( <partition rebuild index option> [ ,...n ] ) ] ] ]

DISABLE REORGANIZE

[ PARTITION = <partition number> ] [ WITH ( LOB COMPACTION = { ON OFF } ) ] SET ( <set index option> [ ,...n ] )

[ ; ]

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

Имя индекса

Если необходимо обеспечить сопровождение одного конкретного индекса, то следует указать имя этого индекса с помощью параметра <name of index>, а для выполнения операции сопровождения на каждом индексе, который связан с указанной таблицей, следует ввести ключевое слово ALL.

Имя таблицы или представления

Назначение параметра <table or view name> в основном соответствует его определению - этот параметр позволяет указать имя конкретного объекта (таблицы или представления), на котором должна быть выполнена операция сопровождения. Следует отметить, что должен быть указан один конкретный объект базы данных (иными словами, не допускается задавать в качестве этого параметра список объектов).

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

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

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

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