авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 26 | 27 || 29 | 30 |   ...   | 33 |

«Е.Мамаев MS SQL SERVER 2000 Книга посвящена одной из самых мощных и популярных современных систем управления базами данных - Microsoft SQL Server 2000. ...»

-- [ Страница 28 ] --

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

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

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

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

Глава 23. Индексы Замечание Некластерные индексы обычно создаются в качестве дополнительных индексов, то гда как в качестве основного используется кластерный индекс. Рекомендуется при менять кластерный индекс к данным, которые наиболее часто выступают в качестве критериев поиска.

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

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

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

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

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

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

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

1024 Часть IV. Разработка и сопровождение баз данных О Столбец часто применяется при группировке (раздел GROUP BY) ИЛИ ДЛЯ слияния (раздел JOIN), особенно в качестве внешнего ключа (FOREIGN KEY).

Для выполнения этих операций сервер всегда выполняет сортировку данных.

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

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

Уникальный индекс Как не трудно догадаться по названию, уникальный индекс (Unique Index) пред назначен для обеспечения уникальности значений соответствующего индекса.

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

Уникальный индекс не существует как самостоятельный физический тип индек са. Он является всего-навсего своеобразной надстройкой над кластерными и некластерными индексами. Можно сказать, что уникальный индекс представля ет собой ограничения целостности UNIQUE, примененное к данным индекса. То есть нельзя создать просто уникальный индекс — этот индекс всегда будет либо кластерным, либо некластерным.

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

Использование уникального индекса оправдано для данных, единственность которых обеспечивается самой их природой. Примером таких данных может служить номер паспорта, неповторимость которого обеспечивается государст венными структурами. Однако если уникальность значений применяется как средство поддержания целостности данных, то лучше всего будет использовать не уникальный индекс, а ограничения целостности Unique или Primary Key.

Первое из них специально предназначено для обеспечения уникальности дан ных в одном или более столбцов. При существовании первичного ключа (Primary Key) уникальность данных является одной из его характеристик. Оба перечисленных ограничения целостности автоматически создают уникальный индекс. Трудно провести грань между использованием ограничений целостности и уникальным индексом. В большинстве случаев рекомендуется применять именно ограничение целостности, а не просто уникальный индекс/ Глава 23. Индексы Фактор заполнения Ранее уже говорилось, что строки таблиц в конечном счете располагаются в файлах базы данных на страницах (page). Такие страницы, содержащие строки таблиц, называются страницами данных (data page). Но и данные индексов также располагаются на аналогичных 8-килобайтовых страницах. Однако страницы, используемые для хранения данных индексов, называются индексными страни цами (index page).

( Замечание ) Подробно различные типы страниц, а также физическая архитектура базы данных, были рассмотрены в главе 18. * *" " Каждая индексная страница может содержать данные множества элементов ин декса. Вся страница разбивается на отдельные слоты (slot), в которых собствен но и располагается информация. Каждый такой слот может быть либр пустым, либо содержать один элемент индекса. Не всегда слоты страницу заполнены последовательно друг за другом. Вполне возможно, что на странице будут чере доваться пустые и заполненные слоты.

Каждая индексная страница предназначена для хранения данных только одного индекса. Страницы, содержащие данные одного и того же индекса, связаны друг с другом в виде списка. Первая страница ссылается на вторую страницу, вторая на третью, третья на четвертую и т. д. Такой подход к хранению данных можно сравнить с хранением файлов в файловой системе, когда в таблице раз мещения файлов (FAT, File Allocation Table) каждый кластер файла (точнее ячейка FAT) содержит указатель на следующий кластер.

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

;

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

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

исправляются рсылки страниц друг на друга, т. е. в^, цепочку вставляется новое звено. В итоге вместо одной, полнрстью,заполненной страницы дол^чается две.страницы, заполнен ные наполовину. Теперь новый элемент можно добавить на нужную страницу,, 1026 Часть IV. Разработка и сопровождение баз данных Операции расщепления страниц занимают довольно много времени по сравне нию с самой вставкой элементов индекса. При частом изменении в индексиро ванных столбцах сервер должен будет соответствующим образом перестраивать индекс, т. е. удалять элементы индекса с одних страниц и вставлять их на дру гие страницы. При этом часто приходится выполнять расщепление страниц, что отрицательно сказывается на производительности. Можно снизить количество расщеплений страниц, если зарезервировать на каждой странице достаточно свободных слотов. SQL Server 2000 позволяет контролировать количество пустых слотов с помощью фактора заполнения страницы.

Фактор заполнения (fill factor) — это параметр, в процентах определяющий плотность записи данных на странице. Его значение определяет, какая часть индексной страницы будет заполнена. Чем более высокий фактор заполнения был задан при построении индекса, тем меньше свободного места останется на странице, и тем более компактно будет размещена информация об индексе.

Фактор заполнения указывается при создании индекса. Например, если размер элемента индекса таков, что на одной индексной странице может быть создано 240 слотов, и при создании индекса был установлен фактор заполнения 70%, то на странице будет заполнено 168 слотов. Оставшиеся 72 слота будут заполняться по мере вставки и изменений данных в таблице.

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

При выборе конкретного фактора заполнения следует оценить частоту измене ний и добавлений данных в таблицу, а также вид этих изменений. Например, если необходимо создать индекс в системе поддержки принятия решений (DSS, Decision Support System), то оправдано применение фактора заполнения, рав ного 100%. Дело в том, что данные в системах DSS практически не изменяются, а используются только для чтения.

Если же индекс создается в системе оперативной обработки транзакций (OLTP, Online Transaction Processing), то лучше использовать как можно меньший фак тор заполнения, т. к. системы OLTP характеризуются большим количеством изменений данных.

Однако если индекс создается для столбца первичного ключа, в качестве кото рого используется столбец-счетчик (IDENTITY), TO МОЖНО установить высокий фактор заполнения, даже если предполагается большое количество добавлений или удалений строк в таблице. Дело в том, что значения в столбце-счетчике мо нотонно возрастают. Это значит, что новые строки будут добавляться в конец индекса и надобности в расщеплении страниц не будет.

Необходимо отдельно обратить внимание, что фактор заполнения определяется в момент создания индекса. В дальнейшем степень заполнения страниц может претерпеть существенные изменения — некоторые страницы будут переполнены Глава 23. Индексы и их потребуется расщепить, тогда как степень заполнения других страниц мо жет уменьшиться. В SQL Server 2000 нет встроенных средств поддержания сте пени заполнения на постоянном уровне, да это и не нужно. Если бы сервер по стоянно пытался поддержать фиксированный фактор заполнения, то в целом это потребовало еще больших затрат, чем выполнение расщеплений страниц.

Хотя со временем степень заполнения страниц может существенно меняться, SQL Server 2000 позволяет выполнять перестроение индексов (rebuild index), в ходе которого для каждой страницы устанавливается указанный фактор запол нения. В частности, такая реорганизация может производиться периодически вручную или как часть плана сопровождения базы данных (Database Maintenance Plan). Например, можно выполнять реорганизацию индексов каждую ночь, ко гда активность пользователей минимальна.

Индексирование представлений Одним из важных нововведений в SQL Server 2000 является возможность индек сирования представлений и вычисляемых столбцов. Если индексирование по следних осуществляется легко — достаточно просто выбрать нужные столбцы при создании индекса, то индексирование представлений имеет некоторые осо бенности. Данный раздел и будет посвящен рассмотрению индексирования представлений.

) ( Замечание Индексирование представлений поддерживается только редакциями Enterprise Edi tion и Developer Edition. Подробно создание представлений было рассмотрено в предыдущей главе.

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

Замечание Индексируемое представление не может включать столбцы с типом данных t e x t, ntext и image, даже если они и не применяются для создания индекса.

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

1028 Часть IV. Разработка и сопровождение баз данных О ОПЦИИ ANSI_NULLS И QUOTEDIDENTIFIER ДОЛЖНЫ быТЬ у с т а н о в л е н ы В ON:

• Таблицы, на которые ссылается индексируемое представление, должны быть созданы с опцией, установленной в ON.

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

П Представление, а также все используемые в представлении пользовательские функции, должны быть созданы с параметром SCHEMABINDING.

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

О Если в представлении указываются пользовательские функции, то они всегда должны возвращать один и тот же результат при одних и тех же входных па раметрах. Таким образом, не разрешается задание функций SUSERSNAME (), HOST_NAME () И Т. Д.

Помимо указанных требований, также существует ряд требований к запросу SELECT, на основе которого строится представление:

П Не разрешается применять ссылки на все столбцы таблицы — символ +.

Вместо этого необходимо явно указать имя каждого из столбцов.

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

• Не допускается ссылаться в разделе FROM на таблицы, построенные с помо щью подзапроса, а также на функции работы с наборами строк (rowset function).

О Не разрешается использовать ключевые слова ТОР И DISTINCT.

• Нельзя применять разделы ORDER BY, COMPUTE И COMPUTE BY.

• Нельзя указывать функции для работы с полнотекстовыми каталогами — !

CONTAINS И FREETEXT.

'О Не разрешается использовать функции агрегирования AVG, MAX, MIN, STDEV, STDEVP, VAR И VARP.

D При использовании раздела GROUP BY в разделе SELECT должна быть указана функция COUNT_BIG(*), но при этом не разрешается использование ключе вых СЛОВ CUBE, ROLLUP И HAVING.

Замечание Если в запросе S E L E C T, на основе которого строится представление, существует раздел GROUP BY, TO уникальный кластерный индекс может ссылаться только на столбцы, указанные в разделе GROUP BY. ССЫЛКИ на столбцы представления, яв ляющиеся результатом выполнения функций агрегирования, не разрешаются.

:

Глава 23. Индексы После того, как было создано представление в соответствии со всеми указан ными требованиями, можно приступать к,созданию кластерного индекса, а впо следствии и некластерных индексов. Однако прежде чем приступить к выпол нению команды CREATE INDEX, следует установить в OFF параметр NUMERIC_ ROUNDABORT, и указать ON для следующих параметров:

• ANSI_NULLS •'•••-.

• ANSI_PADDING. ••,,•, -. -.

• ANSI_WARNINGS..,.. :

• ARITHABORT • CONCAT_NULL_YIELDS_NULL ••"•••"' • : •, J • QUOTED IDENTIFIERS '"'. '.,..

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

На этом рассмотрение особенностей индексирования представлений можно за кончить. На основе индексированного представления можно создавать другие представления. Однако эти представления не могут быть индексированы. При удалении индексированного представления автоматически удаляются все индек сы, определенные для этого представления. Если же для представления удаляет ся кластерный индекс, то автоматически удалятся и йсе некластерные индексы, т. к. при удалении кластерного индекса будет изъята информация о содержимом представления. Некластерные же индексы могут удаляться по отдельности.

Управление индексами SQL Server 2000 предлагает различные механизмы управления индексами, рас считанные на пользователей с разным уровнем подготовки. Если Пользователь не имеет опыта работы с индексами, *н может прибегнуть к помощи специаль ных мастеров. Например, создание индекса можно легко выполнить с помощью мастера Create Index Wizard, вводя информацию в пошаговом режиме в окнах мастера. Для более опытных пользователей предлагается воспользоваться сред ствами Enterprise Manager. Тем не менее, этот же метод могут использовать „и опытные пользователи, желающие быстро и нагляднъ выполнить необходимые действия.

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

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

1030 Часть IV. Разработка и сопровождение баз данных В следующих разделах будет обсуждено создание индексов всеми тремя спосо бами, а также рассмотрено управление существующими индексами, их пере строение и удаление.

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

П При определении в таблице первичного ключа (ограничений целостности Primary Key). Как уже было сказано, в этом случае сервер автоматически создает уникальный индекс. Этот индекс будет кластерным (CLUSTERED), если в таблице уже не существует кластерного индекса. Однако пользователь мо жет явно указать, что для первичного ключа должен быть создан некластер ный индекс (NONCLUSTERED).

• Уникальный индекс также автоматически создается при определении в таб лице ограничений целостности UNIQUE.

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

П Индекс может быть создан уже после создания таблицы с помощью команды CREATE INDEX, специально предназначенной для этого.

Мы не будем рассматривать три первых ситуации, в которых происходит созда ние индекса. Определение индекса как части процесса создания таблицы было рассмотрено в главе 21. Создание же индексов при определении ограничений целостности Primary Key и Unique выполняется сервером автоматически и не представляет интереса.

Использование Transact-SQL Начнем рассмотрение методов создания индексов с Transact-SQL. В этом случае необходимо использовать команду CREATE INDEX, имеющую синтаксис:

CREATE [UNIQUE] [CLUSTERED I NONCLUSTERED] INDEX index_name ON { t a b l e I view} (column [ASC | DESC] [,... n ]) [WITH i n d e x _ o p t i o n [,... n ] ] [ON f i l e g r o u p ] Рассмотрим назначение и применение параметров команды:

• UNIQUE При указании этого параметра будет создан уникальный индекс, т. е. в ин • дексируемом столбце (или столбцах) будет запрещено появление повторяю Глава 23. Индексы ' щихся значений. Прежде чем создать индекс, сервер выполняет проверку на уникальность значений. Если индексируемый столбец содержит повторяю щиеся значения, то попытка создания индекса закончится неудачей. Сервер не предпринимает никаких действий по устранению повторяющихся значе ний, поэтому прежде чем создать уникальный индекс, пользователь обязан позаботиться об отсутствии повторов, изменив или удалив соответствующие строки. Все сказанное остается в силе даже при использовании параметра IGNOREDUPKEY, описание которого будет рассмотрено далее. Также реко мендуется запретить для индексируемого столбца хранение значений NULL.

Дело в том, что значения NULL воспринимаются уникальным индексом как обычные значения, т. е. в индексированном столбце нельзя будет иметь двух строк со значением. Если при вставке строки пользователь не станет указы вать явно значение для столбца, то сервер будет добавлять значение NULL, из за чего операция вставки будет отклонена, если в столбце уже имеется значе ние NULL. Аналогичная ситуация и со значением по умолчанию. После созда ния уникального индекса сервер будет отклонять все команды INSERT И UPDATE, которые приводят к нарушению уникальности значений в индекси рованном столбце.

• CLUSTERED При использовании этого параметра создаваемый индекс будет кластерным, т. е. порядок строк в таблице будет определяться создаваемым индексом. Ес ли при создании кластерного индекса указывается параметр ON f iiegroup, то таблица окажется перенесенной в указанную группу. Для хранения информа ции кластерного индекса необходимо пространство, равное примерно 20% от объема таблицы. Если параметр CLUSTERED не указывается, то будет создан некластерный индекс. Поскольку при создании кластерного индекса проис ходит изменение некластерных индексов, рекомендуется создавать кластер ный индекс самым первым в таблице. В каждой таблице может быть создан только один кластерный индекс.

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

О index_name С помощью этого параметра задается имя, которое будет присвоено индексу.

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

tO32 4acn.IV. Разработка и сопровождение-баз данных u r table Т v i e w ''' " П :' ' '•'•"••• -'" -' '" '••••'• •&••••''•'•• Этот параметр, определяет имя таблицу или представления, для которого бу дет создаваться индекс^ Дополнительно можно указать имя владельца и имя базы данных, в которой находится нужный объект.

• (column [ASCI DESC] [',... п ] ) Этот параметр служит для задания имен столбцов таблицы, для которых бу дет создаваться индекс. Если указывается более одного столбца, то будет соз дан составной индекс (composite index), значение которого получается в ре зультате объединения значений входящих в его состав столбцов. Индекс не может включать столбцы с типом данных t e x t, n t e x t, ima$e и b i t. Отметим, что индекс может быть создан на основе вычисляемых (computed) столбцов, что не было возможно в предыдущих версиях SQL Server. Как уже было ска зано, общее количество столбцов в составном индексе ограничено 16, причем общая длина значений всех столбцов не должна превышать 900 байтов. С помощью ключевых слов АЙС и DESC МОЖНО предписать серверу сортировать данные столбца соответственно По возрастанию и убыванию. Отметим, что эта возможность является нововведением SQL Server 2000.

С Замечание ^ При создании составных индексов следует сначала указывать имена столбцов, в ко торых имеется минимальное количество повторов. Это позволит быстрее находить нужные данные. Например,, если имеется три столбца, в которых соответственно существует 70%, 20% и 50% одинаковых строк, то следует сначала указать имя вто рого столбца, затем третьего и, наконец, имя первого столбца.

• WITH iridex_option"{,...n] Посредством этого параметра можно управлять некоторыми расширенными свойствами индексов. Конструкция i n d e x _ o p t i o n имеет следующий син таксис;

. -. • ',.. ',,,.-. •., ••: •......:'..

. 4, ADJENBPX | F I L L F A C T O R s = X i l l f a c t o r I IGNORE_DUP_KEY |,.

. BRQPJEXIgTJNG I STATISIICS_NPRECOMPUTE I SORT^IN_TEMPDB } Рассмотрим назначение приведенных параметров:

• PAD_INDEX.,.....-" При указании этого параметра при создании индекса будет резервироваться место во внутренних структурах индекса для добавления новых страниц.

Обычно этот параметр применяется только совместно с параметром FILLFACTOR, т. к. использует значение фактора заполнения. Если фактор за полнения не указан, то поведение сервера при задании параметра PADINDEX будет таким же, как;

если бы этот параметр не был указан вовсе.

FJbLFACTOR = f i l l f a c t o r «,, Этот' параметр определяет' файсгор заполнения индексных страниц, т. е.

сколько процентов пространства каждой страницы будет заполнено сразу Глава 23. Индексы же при создании индекса. Остальное пространство резервируется для по следующих операций изменения и вставки данных. Если в результате вы числения количества слотов страницы, которые должны быть заполнены, получается дробное значение, то сервер округляет количество строк в большую сторону. Пользователь может указывать значение параметра f n i f a c t o r в интервале от 1 до 100. Значение 100 применяется в системах, где не выполняются команды UPDATE И INSERT. ЕСЛИ параметр FILLFACTOR не указывается, то при создании индекса будет использоваться значение фактора заполнения по умолчанию, определенное на уровне сервера и распространяющееся на все базы данных. Изменить это значение можно с помощью хранимой процедуры e p c o n f i g u r e с опцией ' f i n f a c t o r 1.

Сразу же после установки SQL Server 2000 значение по умолчанию равно 0, что соответствует 100% заполнению страниц с резервированием доста точного количества страниц для последующих операций расщепления.

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

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

• IGNORE_DUP_KEY Этот параметр предназначен только для уникальных индексов, т. е. совме стно с параметром UNIQUE, И определяет поведение сервера при выполне нии операций, приводящих к появлению в индексе повторяющихся зна чений. Если уникальный индекс был создан с параметром IGNOREDUPKEY, то при попытке пользователя вставить (или изменить) в таблицу большое количество строк сервер будет отменять добавление только тех строк, которые нарушают уникальность значений. При этом будет выдано соответствующее сообщение об ошибке и список всех по вторяющихся строк, но транзакция откатана не будет. После этого поль зователь обязан найти повторяющиеся строки и внести в них необходи мые изменения, после чего эти строки могут быть добавлены в таблицу.

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

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

Параметр может использоваться как для кластерных, так и некластерных индексов. Однако наибольшую выгоду от применения этого параметра можно получить при повторном создании кластерного индекса в таблице с множеством некластериых индексов. Если выполнить удаление индекса обычным способом, т. е. с помощью команды DROP INDEX, TO сервер ДОЛ 1034 Часть IV. Разработка и сопровождение баз данных жен будет перестроить все некластерные индексы для использования в качестве указателей физического адреса строки. При повторном создании в таблице кластерного индекса необходимо будет произвести обратную операцию — перестроить некластерные индексы на использование в каче стве указателей элементов кластерного индекса. Подобное перестроение некластерных индексов может потребовать довольно много времени. Если же повторное создание кластерного индекса в таблице выполняется с по мощью параметра DROPEXISTING, TO сервер лишь обновит указатели не кластерных индексов.

Замечание В SQL Server 2000 нет встроенной команды изменения индекса, поэтому рекоменду ется применять параметр D R O P E X I S T I N G ДЛЯ более быстрого удаления и повтор ного создания индекса.

• STATISTICS_NORECOMPUTE Наличие этого параметра запрещает автоматическое обновление устарев шей статистики, что повышает производительность операций вставки и изменения строк. Однако оптимизатор запросов в этом случае не сможет создать оптимальный план исполнения запроса. Позже можно разрешить автоматическое обновление статистики, выполнив команду UPDATE STATISTICS без параметра NORECOMPUTE.

» SORT_IN_TEMPDB При указании этого параметра сервер будет использовать при построении индекса базу данных Tempdb, располагая в ней промежуточные результаты сортировки. Эта возможность оказывается полезной, когда файлы базы данных Tempdb и базы данных, в которой создается индекс, располагаются на разных физических дисках. Таким образом, можно добиться уменьше ния времени, необходимого для создания индекса. Параметр SORTINTEMPDB появился только в SQL Server 2000.

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

В качестве примера приведем код, позволяющий организовать для таблицы Categories базы Данных Northwind кластерный индекс PK_Categories на осно ве столбца CategoryiD. Создаваемый индекс будет расположен в первичной группе файлов. Задание же параметра DROPEXISTING позволяет гарантировать успешность выполнения команды даже в случае существования для таблицы индекса с указанным именем:

USE Northwind GO CREATE UNIQUE CLUSTERED 103S Глава 23.

[CategorylD]) INDEX [PK_Categories] ON [dbo].[Categories] WITH DROP_EXISTING ON [PRIMSRY] Использование Enterprise Manager В предыдущем разделе мы рассмотрели создание индексов средствами Transact SQL. В этом же разделе внимание будет уделено описанию создания индексов с помощью Enterprise Manager. Этот метод сочетает простоту и наглядность соз дания индексов с достаточно большой функциональностью.

Для управления индексами таблицы или представления используется окно Man age Indexes (рис. 23.1), открыть которое можно с помощью контекстного меню таблицы или представления, выбрав в нем команду All Tasks, а затем команду Manage Indexes.

Рис. 2 3. 1. Окно Manage Indexes Рассмотрим элементы управления, имеющиеся в окне Manage Indexes:

О Database. С помощью этого раскрывающегося списка можно выбрать имя одной из баз данных, имеющихся на текущем сервере. Соответственно, в списке Table/view будет выведен набор таблиц и представлений, имеющихся в выбранной базе данных.

• Table/view. Этот раскрывающийся список содержит перечень таблиц и пред ставлений, имеющихся в базе данных. Чтобы работать с индексами той или иной таблицы (представления), необходимо выбрать ее имя в списке.

Часть IV. Разработка и сопровождение баз данных П Include system objects. Установка этого флажка^редйисывает выводить в спи ске Table/view имена не только пользовательских, но и системных объектов.

• Existing indexes. В этой таблице перечислены все индексы, созданные для таблицы или представления, выбранного в списке Table/view. Рассмотрим, какие же колонки имеет эта таблица:

• Index — имя индекса;

• Clustered — если отображено значение Yes, то соответствующий индекс кластерный;

• Columns — список столбцов, на основе которых построен индекс.

• New. Эта кнопка служит для создания нового индекса.

• Edit. Нажав эту кнопку, можно открыть окно редактирования существующего индекса.

• Delete. С помощью этой кнопки можно удалить индекс, выбранный в табли це Existing indexes.

Мы рассмотрели назначение элементов управления, имеющихся в окне Manage Indexes. Теперь же рассмотрим собственно создание'индекса. Прежде всего, не обходимое помощью списков Database и Table/view выбрать таблицу или пред ставление, для которого надо создать новый индекс. После этого следует нажать кнопку New. В ответ откроется окно Create New Index (рис. 23.2), с помощью которого и создается индекс.

Рис. 23.2. Окно Create New Index Глава 23. Индексы В верхней части окна Create I^ew Index размещено поле Index name, в котором необходимо указать имя создаваемого индекса. Напомним, что имя индекса должно быть уникально в пределах таблицы. При выборе имени следует при держиваться общих правил именования объектов базы данных.

В центральной части окна существует таблица, определяющая набор столбцов, на основе которых будет построен индекс. В колонке Column этой таблицы пе речислены все столбцы, имеющиеся в выбранной для индексирования таблице или представлении. Установка флажка слева от имени столбца предписывает включить его в индекс. С помощью колонки Sort Order можно определить по рядок сортировки, который будет применяться для соответствующего столбца.

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

В остальных же колонках выводится информация о соответствующем столбце:

типе данных (Data Type), количестве используемых байт или символов (Length), возможность хранения значений NULL (Nullable), максимально допустимое коли чество цифр (Precision), а также количество цифр после запятой (Scale).

С помощью кнопок Up и Down можно изменять порядок включения значений столбцов в индекс. Этот момент достаточно важен, т. к. порядок перечисления столбцов может весьма заметно сказаться на производительности индекса. Ре комендуется наиболее часто используемые столбцы, в то же время подвержен ные минимальным изменениям, размещать первыми.

Рассмотрим набор флажков, имеющихся в группе Index options:

• Clustered index. При установке флажка создаваемый индекс будет кластер ным. Флажок доступен только в том случае, если в таблице (или представле нии) ранее еще не было создано кластерного индекса.

• Unique values. Установка флажка предписывает создать уникальный индекс.

При этом станет доступным следующий флажок:

• Ignore duplicate values — в случае установки этого флажка при попытке пользователя вставить (или изменить) большое количество строк сервер будет отменять вставку только тех строк, которые нарушают уникальность значений, а не всего блока данных.

• Pad index. При выборе флажка при создании индекса будет резервироваться место во внутренних структурах индекса для добавления новых страниц.

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

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

П Do not recompute statistics (not recommended). Установив этот флажок, можно запретить автоматическое обновление статистики для создаваемого индекса.

• File group. Если необходимо расположить данные индекса в конкретной группе файлов, то следует установить рассматриваемый флажок и выбрать с Часть IV. Разработка и сопровождение баз данных помощью раскрывающегося списка имя нужной группы файлов. Если же флажок сброшен, то данные индекса будут располагаться в той же группе файлов, что и данные таблицы.

Мы рассмотрели элементы управления, имеющие непосредственно отношение к созданию индекса. В нижней же части окна имеется кнопка Edit SQL, с помо щью которой можно открыть окно Edit Transact-SQL Script (рис. 23.3). С по мощью этого окна можно просмотреть код команды CREATE INDEX, которая по зволяет создавать индекс. Эта команда генерируется на основе сведений, введенных пользователем в окне Create New Index. Помимо просмотра кода ко манды, можно внести и изменения в него. Для проверки правильности синтак сиса команды следует нажать кнопку Parse. Нажав же кнопку Execute, можно выполнить приведенный код, создав тем самым индекс.

Рис. 2 3. 3. Окно Edit Transact-SQL Script В общем же случае создание индекса производится после нажатия кнопки ОК в окне Create New Index. Редактирование же свойств существующего индекса осуществляется с помощью окна Edit Existing Index, открыть которое можно с помощью кнопки Edit в окне Manage Indexes, предварительно выбрав нужный индекс. Работа с окном Edit Existing Index практически ничем не отличается от работы с окном Create New Index и поэтому рассматриваться не будет.

Использование мастера Create Index Wizard Последний метод создания индекса, который необходимо рассмотреть — это использование мастера Create Index Wizard. Запустить данный мастер можно с Глава 23. Индексы помощью окна Select Wizard, открыть которое можно с помощью кнопки Run a Wizard, расположенной в панели инструментов Enterprise Manager.

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

Второе окно мастера имеет имя Select Database and Table (рис. 23.4) и предна значено для выбора таблицы, которую необходимо индексировать. Как видно из рисунка, в распоряжении пользователя имеются два раскрывающихся списка — Database name и Object name. С помощью первого из них выбирается база дан ных, таблицу которой предполагается индексировать. С помощью второго же списка указывается собственно объект, для которого будет создаваться индекс.

После того, как объект будет определен, можно переходить к следующему окну.

Рис. 23.4. Окно Select Database and Table мастера Create Index Wizard Третье окно мастера называется Current Index Information (рис. 23.5). В нем вы водится список всех индексов, уже созданных для выбранного в предыдущем окне объекта. Каждая строка таблицы, имеющейся в окне, описывает отдельный индекс. Для индекса указывается его имя (колонка Index Name), тип (колонка Clustered), а также список столбцов, входящих в индекс (колонка Columns). Ок но Current Index Information выводится для того, чтобы пользователь имел пред ставление об уже существующих индексах. Вполне возможно, что нужные столбцы уже были проиндексированы, и создание нового индекса не требуется.

В этом случае остается только нажать кнопку Cancel и тем самым прервать про цесс создания индекса.

3 4 Зое Часть IV. Разработка и сопровождение баз данных Рис. 23.5. Окно Current Index Information мастера Create Index Wizard Рис. 23.6. Окно Select Columns мастера Create Index Wizard Если все же пользователь решил создать новый индекс, то следует перейти к окну Select Columns (рис. 23.6), позволяющему выбрать столбцы, которые будут индексироваться. Устанавливая флажок в колонке Include in Index, можно вклю чить соответствующий столбец в индекс. Если же флажок устанавливается в ко Глава 23. Индексы лонке Sort Order(DESC), то данные соответствующего столбца в индексе будут располагаться по убыванию.

Следующее окно — Specify Index Options (рис. 23.7) — предназначено для управ ления параметрами создаваемого индекса. Рассмотрим элементы управления, имеющиеся в этом окне:

П Make this a clustered index. Установка этого флажка предписывает создать конфигурируемый индекс как кластерный. Заметим, что флажок доступен только в том случае, если в таблице еще не существует кластерного индекса.

О Make this a unique index. Если необходимо, чтобы создаваемый индекс был уникальным, то следует установить этот флажок.

П Fill factor. С помощью этого переключателя задется метод определения фак тора заполнения индексных страниц:

• Optimal — в этом случае степень заполнения страниц будет выбираться сервером автоматически наиболее оптимальным (по мнению сервера) об разом;

• Fixed — при установке переключателя в это положение пользователь имеет возможность указать произвольную степень заполнения индексных страниц.

Рис. 23.7. Окно Specify Index Options мастера Create Index Wizard Когда все параметры индекса будут сконфигурированы, можно переходить к очередному окну мастера (рис. 23.8), которое является последним. В нем поль зователь может с помощью кнопок Move Up и Move Down изменять порядок включения столбцов в индекс. Так же можно указать имя, которое будет иметь 34* 1042 Часть IV. Разработка и сопровождение баз данных создаваемый индекс. Когда и эти действия будут завершены, остается только нажать кнопку Finish, после чего и будет создан индекс.

Completing the Create Index Wizard The columns included n the nonclustered index on the 'Employees' table in the 'Northwind' database ace shown below.

Рис. 2 3. 8. Последнее окно мастера Create Index Wizard Перестроение индексов Как уже было сказано, SQL Server 2000 не поддерживает автоматически фактор заполнения индексных страниц на конкретном уровне. Поэтому со временем сте пень заполнения страниц может существенно измениться по сравнению с перво начальным состоянием. Некоторые страницы могут оказаться заполненными пол ностью, тогда как другие практически пустыми. Если количество заполненных страниц становится слишком велико, то приходится часто производить расщепле ние страниц, что отрицательно сказывается на производительности.

Чтобы повысить производительность до прежнего уровня, достаточно выпол нить перераспределение строк индексных страниц, чтобы установить фактор заполнения на нужный уровень. Такой процесс называется перестроением индек са (rebuild index).

Для выполнения перестроения индексов предназначена команда DBCC DBRE INDEX, имеющая синтаксис:

DBCC DBREINDEX (['database.owner.table_name' [, index_name [, fillfactor]]]) [WITH NO_INFOMSGS] Рассмотрим назначение параметров команды:

Глава 23. Индексы • database.owner.table_name Этот параметр определяет таблицу, в которой будет выполняться перестрое ние одного или более индексов. Помимо самого имени таблицы можно ука зать ее владельца и базу данных, в которой она находится. То есть пере строение индексов можно осуществлять не только в текущей базе данных, но и в любой базе данных текущего сервера.

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

• fillfactor Этот параметр определяет фактор заполнения, который будет установлен для указанного индекса. Если задается значение 0 или параметр f i l l f a c t o r во обще опускается, то для индекса будет использован фактор заполнения, на значенный при создании индекса.

П WITH NO_INFOMSGS При использовании этого параметра при выполнении перестроения будут по давляться все информационные сообщения с уровнем серьезности с 0 до 10.

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

) ( Замечание С помощью одной команды DBCC DBRE INDEX МОЖНО перестроить все индексы ука занной таблицы.

Переименование индекса Иногда бывает необходимо создать в таблице индекс с определенным именем.

При этом требуется, чтобы имя индекса было уникально в пределах таблицы.

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

Для переименования индексов служит хранимая процедура sprename, имеющая синтаксис:

sp_rename [Oobjname =] 'object_name', [Snewname =] 'new_name', 'INDEX' С помощью аргумента object_name указывается имя индекса, который необхо димо переименовать. Новое имя задается с помощью аргумента newname.

1044 Часть IV. Разработка и сопровождение баз данных Удаление индекса Какого бы увеличения производительности не давали индексы, все же иногда приходится их удалять. Это может быть связано с удалением неверно созданных индексов, удалением индексов вследствие изменения структуры таблицы или создания новых индексов, которые позволяют лучше выполнять запросы.

Для удаления индекса используется команда DROP INDEX, имеющая синтаксис:

DROP INDEX 'table.index [,...n] Как видно из синтаксиса, с помощью команды DROP INDEX МОЖНО удалить один или несколько индексов только текущей базы данных.

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


При удалении индекса происходит освобождение всех страниц, которые исполь зовались для хранения данных индекса.

Просмотр информации о фрагментации Чтобы взвесить, насколько необходимо выполнение перестроения индексов, нужно иметь какую-то информацию о выполнении запросов. Для получения такой информации используется команда DBCC SHOWCONTIG, имеющая следую щий синтаксис:

DBCC SHOWCONTIG [ ({table_name I table_id I view_name I view_id} [, index_name I index_id])] [WITH {ALL_INDEXES I FAST [, ALL_INDEXES] I TABLERESULTS [, {ALL_INDEXES}] [, {FAST | ALL_LEVELS }]} ] Рассмотрим назначение параметров команды:

О {table_name I table_id I view_name | view_id} С помощью данного параметра указывается объект текущей базы данных (таблицу или представление), информацию об индексах которого необходимо получить. Как видно, объект может быть указан как по имени, так и с помо щью идентификационного номера.

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

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

• FAST Вызывая команду с этим параметром, будет выдаваться минимальное количе ство информации. Соответственно, при этом будет анализироваться лишь не большая часть данных, что позволяет быстро получить статистическую ин формацию.

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

• ALL_LEVELS Этот параметр может использоваться только совместно с параметром TABLERESULTS и предписывает выполнить анализ всей информации об индек се. Таким образом, в распоряжении пользователя будет максимально досто верная и полная информация.

Команда DBCC SHOWCONTIG ВЫВОДИТ информацию в двух режимах — текстовом и виде набора строк (при указании параметра WITH TABLERESULTS). При этом на бор данных, возвращаемых в каждом из режимов, различается. Рассмотрим, ка кая же информация возвращается в текстовом режиме:

О Pages Scanned. Количество страниц в таблице или индексе.

• Extents scanned. Количество групп страниц (экстентами, extents) в таблице или индексе.

П Extent Switches. Количество переключений между экстентами, которое бы ло выполнено в процессе сканирования данных командой DBCC SHOWCONTIG.

Если количество переключений значительно превышает общее количество экстентов, то это означает, что экстенты фрагментированы.

О Avg. Pages per Extent. Среднее количество страниц на один экстент ин декса или таблицы.

• Scan Density [Best Count: Actual Count]. ПЛОТНОСТЬ сканирования В про центах. Чем выше значение, тем меньше непроизводительных затрат. Допол нительно указываются два значения — идеальное количество экстентов, и текущее количество экстентов. Первое из этих значений показывает, к скольким экстентам бы выполнялось обращение, если бы все данные распо 1046 Часть IV. Разработка и сопровождение баз данных лагались упорядочение, и каждый экстент был бы полностью заполнен. Это значение получается при делении количества страниц на 8 (количество стра ниц в экстенте). Если значение дробное, то выполняется округление вверх.

Текущее значение отражает количество экстентов, к которым было выполне но обращение. Считается каждое повторное обращение к одному и тому же экстенту. Чем больше разница между идеальным и текущим количеством, тем более фрагментированы данные. То есть чем меньше значение параметра scan Density, тем более фрагментированы данные. При значении 100% дан ные не фрагментированы.

О Logical Scan Fragmentation. Степень логической фрагментации данных, указывается в процентах. Чем выше значение, тем более фрагментированы данные. В идеале фрагментация данных должна составлять 0%. Логическая фрагментация происходит, когда в цепочке IAM указан номер страницы, иной, чем в цепочке индексов. Хотя влияние логической фрагментации на скорость выполнения запроса не велико, тем не менее, не стоит пренебре гать им.

• Extent scan Fragmentation. Степень фрагментации экстентов, указывается в процентах. Фрагментация экстентов — это ситуация, когда следующий экстент цепочки индекса или таблицы физически находится не после текущего экстен та. Когда экстенты не фрагментированы, то будет выведено значение 0%.

d Avg. Bytes free per Pages. Среднее количество свободного пространства на сканированных страницах в байтах. Это значение напрямую связано с фактором заполнения страниц. Если на странице мало свободного простран ства, то последующие операции вставки и изменения данных потребуют вы полнения расщеплений страниц, что отрицательно сказывается на произво дительности. Малое количество свободного пространства на странице служит индикатором, что пора выполнить перестроение данных на страницах. Для нормальной работы страница должна иметь достаточно свободного про странства для вставки новых строк. Напомним, что размер страницы состав ляет 8 Кбайт.

О Avg. Page density ( f u l l ). Это значение говорит о средней плотности дан ных на странице. Величина значения указывается в процентах и обратно пропорциональна значению предыдущего параметра, — чем больше свобод ного пространства на странице, тем меньше плотность заполнения страницы.

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

Рассмотрим пример информации фрагментации таблицы authors базы данных pubs:

DBCC SHOWCONTIG (authors) Будет получен следующий результат:

DBCC SHOWCONTIG scanning •authors' t a b l e...

Table: ' a u t h o r s ' (1977058079);

index ID: 1, d a t a b a s e ID: TABLE l e v e l scan performed.

Глава 23. Индексы - Pages Scanned : - Extents Scanned : - Extent Switches : - Avg. Pages per Extent : 1. - Scan Density [Best Count:Actual Count] : 100.00% [1:1] - Logical Scan Fragmentation : 0.00% - Extent Scan Fragmentation : 0.00% - Avg. Bytes Free per Page : 6010. - Avg. Page Density (full) : 25.75% DBCC execution completed. If DBCC printed error messages, contact your sys tem administrator.

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

• ObjectName — имя объекта, об индексах которого выводится информация;

• object id — идентификационный номер объекта базы данных, об индексах которого выводится информация;

О indexName — имя индекса;

• indexid — идентификационный номер индекса;

О Level — уровень индекса;

О Pages — количество страниц, занимаемых проиндексированными данными;

О Rows — количество проиндексированных строк;

D MinimumRecordSize — минимальный размер, который могут иметь значения индексированных столбцов;

О MaximumRecordSize — максимальный размер, который могут иметь значения индексированных столбцов;

• AverageRecordSize — средний размер, который имеют значения индексиро ванных столбцов;

О Extents — количество экстентов, занимаемых проиндексированными дан ными.

К сожалению, нет возможности привести пример данных, возвращаемых коман дой DBCC SHOWCONTIG при указании параметра WITH TABLERESULTS, Т. К. объем этой информации достаточно велик и не поместится на страницу книги по ши рине. Тем не менее, эту информацию легко увидеть в Query Analyzer, выполнив в нем, например, следующую команду:

USE pubs GO DBCC SHOWCONTIG (authors) WITH TABLERESULTS, ALL LEVELS Глава Статистика Как было сказано в предыдущей главе, SQL Server 2000 выполняет оптимиза цию операций поиска данных в индексе с помощью статистики (statistics).

Статистика представляет собой данные о распределении в таблице, упорядо ченные с помощью индекса данных. Информация об индексах хранится в системной таблице sysindexes, имеющейся в каждой базе данных. Каждый индекс представлен отдельной строкой. Информация о статистике индекса хранится в столбце s t a t b l o b, имеющем тип данных image, максимальный размер которого равен 2 Гбайт.

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

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

При необходимости можно запретить обновление статистики и тем самым по высить производительность вставки и изменения данных. Однако скорость вы полнения выборки данных может снизиться.

( Замечание ) SQL Server 2000 позволяет создавать статистику не только для индексированных столцов, но и для неиндексированных.

Создание статистики Создание статистики выполняется с помощью команды CREATE STATISTICS, имеющей следующий синтаксис:

CREATE STATISTICS statistics_name ON {table I view} (column [,...n]) [ WITH [ [ FULLSCAN | SAMPLE number (PERCENT I ROWS}] [ ] ], [ NORECOMPUTE] Глава 24. Статистика Рассмотрим использование и назначение параметров команды:


О statistics_name Имя группы создаваемой статистики, которое должно быть уникальным в пределах таблицы и следовать стандартным правилам именования объектов.

• (table I view} Имя таблицы или представления, для которого создается статистика. Допол нительно можно указать имя владельца и имя базы данных, в которой распо ложена таблица.

П (column [,...п] ) С помощью этого параметра задается имя одного или более столбцов табли цы, для которых будет создана статистика. Не могут указываться вычисляемые (computed) столбцы и столбцы с типами данных t e x t, ntext и image.

• FULLSCAN При указании этой опции для создания статистики будет выполняться пол ное сканирование всей таблицы, т. е. будут обработаны все значения столбца, для которого создается статистика.

О SAMPLE number {PERCENT I ROWS} Использование этой опции позволяет выполнять выборочное сканирование лишь части строк таблицы. Количество сканируемых строк задается либо в процентах с помощью параметра PERCENT, либо в виде абсолютного количе ства строк с помощью параметра ROWS. Использование SAMPLE loo PERCENT равнозначно указанию параметра FULLSCAN. ОПЦИИ FULLSCAN И SAMPLE num ber не могут применяться совместно.

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

Управление статистикой После того, как статистика создана, оптимизатор запросов начинает использо вать ее автоматически. Если статистика не обновляется автоматически, то поль зователь может сделать это вручную, используя команду UPDATE STATISTICS, имеющую следующий синтаксис:

UPDATE STATISTICS {table | view} [ index | (statistics_name[, n]) ] [ WITH [ [FULLSCAN] | SAMPLE number {PERCENT | ROWS}] | RESAMPLE ] [[,] [ALL I COLUMNS | INDEX] [[,) NORECOMPUTE] 1050 Часть IV. Разработка и сопровождение баз данных Рассмотрим назначение и использование параметров команды:

• {table I view} Этот параметр указывает имя таблицы или представления, статистику кото рой необходимо обновить. Дополнительно можно задать имя владельца и имя базы данных.

П index Параметр используется, когда необходимо обновить статистику конкретного индекса. Если имя индекса не указывается, то будет обновлена статистика всех индексов таблицы.

• (statistics_name[,...п]) С помощью этого параметра определяется одно или более имен статистик, созданных в таблице.

• FULLSCAN При указании этой опции во время обновления статистики станет выпол няться полное сканирование всей таблицы, т. е. будут обработаны все значе ния столбца, для которого создается статистика.

• SAMPLE number {PERCENT | ROWS} Использование этой опции позволяет выполнять выборочное сканирование лишь части строк таблицы. Количество сканируемых строк задается с помо щью параметра number. Если указывается ключевое слово PERCENT, TO параметр number означает количество процентов строк, которое будет сканироваться, и он не должен превышать 100%. Если же указывается ключевое слово ROWS, TO параметр number задает физическое количество строк. Использование SAMPLE 100 PERCENT равнозначно использованию параметра FULLSCAN. ОПЦИИ FOLLSCAN и SAMPLE number PERCENT не могут применяться совместно.

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

• ALL | COLUMNS I INDEX Эти опции позволяют выполнить обновление статистики для всех столбцов (COLUMNS), индексов (INDEX) ИЛИ И тех и других сразу (ALL). При использовании любой из этих опций нет необходимости указывать имя индекса или столбцов.

О NORECOMPUTE При выполнении обновления статистики с использованием этой опции в дальнейшем запрещается автоматическое обновление статистики для указан ных объектов. Если ранее автоматическое обновление статистики было за прещено и обновление выполняется без указания опции NORECOMPUTE, TO В дальнейшем сервер станет автоматически обновлять статистику.

Глава 24. Статистика Команда UPDATE STATISTICS выполняет обновление статистики только в преде, лах одной таблицы. Если необходимо обновить несколько десятков таблиц, то команду UPDATE STATISTICS придется выполнять для каждой из них. Однако в SQL Server 2000 имеется системная хранимая процедура spupdatestats, вы полняющая обновления статистики во всех таблицах текущей базы данных:

sp_updatestats [[Oresample =] 'resample'] Как видно, эта хранимая процедура имеет единственный параметр. Указание для этого параметра значения ' resample' эквивалентно использованию пара метра RESAMPLE при работе с командой UPDATE STATISTICS. Все остальные зна чения параметра процедуры игнорируются.

Если вы не хотите выполнять обновление статистики, но необходимо разрешить или запретить автоматическое обновление, то нужно будет использовать не ко манду UPDATE STATISTICS, а хранимую процедуру sp_autostats, изменяющую непосредственно значения в системных таблицах базы данных. Эта хранимая процедура имеет следующий синтаксис:

sp_autostats [Stblname =] 'table_name' [, [Oflagc =] 'stats_flag'] [, [Sindname =] 'index_name'] Параметр table_name определяет имя таблицы, параметры статистики которой необходимо изменить. С помощью параметра index name указывается имя ин декса, которому принадлежит статистика. Параметры, которые будут установле ны для статистики, задаются с помощью параметра s t a t s f lag, который может принимать значения ON ИЛИ OFF, соответственно, разрешающие или запрещаю щие автоматическое обновление статистики. Если параметр s t a t s f i a g не ука зан, то выводится текущее состояние автоматического обновления статистики.

Если не определен параметр index_name, то будет выведено состояние всех ста тистик указанной таблицы.

Например, просмотрим статистику таблицы authors базы данных pubs:

USE pubs EXEC sp_autostats authors Будет получен такой результат:

Global statistics settings for [pubs]:

Automatic update statistics: ON Automatic create statistics: ON Settings for table [authors] Index Name AUTOSTATS Last Updated [UPKCL_auidind] ON 1999-06-03 19:20:05. [aunmind] ON 1999-06-03 19:20:05. [_WA_Sys_state_07020F21] ON 1999-04-26 12:20:54. [_WA_Sys_contract_07020F21] ON 1999-05-06 22:29:56. [_WA_Sys_city_07020F21] ON 1999-05-06 22:30:30. [_WA_Sys_au_fnarae_07020F21] ON 1999-06-30 14:58:11. (6 row(s) affected) 1052 Часть IV. Разработка и сопровождение баз данных Просмотр статистики Пользователь может просмотреть состояние статистики, чтобы определить, ка i|oe повышение производительности дает тот или иной индекс. На основе полу ченной информации он может принять решение об удалении индекса.

Для просмотра состояния статистики предназначена команда:

DBCC SHOW_STATISTICS ( t a b l e, t a r g e t ) Параметр t a b l e определяет имя таблицы, которой принадлежит интересующая статистика. Имя объекта (статистики или индекса) указывается с помощью па раметра t a r g e t.

Команда возвращает информацию в виде следующего набора колонок:

О updated. Дата и время последнего обновления статистики.

• ROWS. Количество строк в таблице.

О Rows sampled. Количество строк таблицы, которые были использованы для создания статистики. Если статистика давно не обновлялась, то значение в этой колонке может превышать значение в колонке Rows.

• steps. Количество интервалов распределения, созданных в статистике.

О Density. Плотность данных в индексе.

П Average key length. Средняя длина значения в столбце, для которого соз дана статистика.

• All density. Плотность в индексе конкретного столбца.

П Columns. Имя столбца таблицы, для которого выводится плотность.

П steps. В этой колонке выводятся все шаги диаграммы, созданные для стати стики.

Рассмотрим пример получения информации о статистике:

DBCC SHOW_STATISTICS (authors, [_WA_Sys_au_fname_07020F21]) Будет получен следующий результат:

Statistics for collection '_WA_Sys_au_fname_07020F21'.

Updated Rows Rows Sampled Steps Density Average key Jun 30 1999 2:58PM 23 23 23 4.3478262E-2 17. (1 row(s) affected) All density Columns Глава 24. Статистка Albert Ann Anne Burt Charlene Cheryl Dean Dirk Heather Innes Johnson Livia Marjorie Meander Michael Michel Morningstar Reginald Sheryl Stearns Sylvia (23 row(s) affected) ЧАСТЬ V.

ПРОГРАММИРОВАНИЕ Глава 25. Основы Transact-SQL Глава 26. Типы данных SQL Server Глава 27. Функции SQL Server Глава 28. Вставка, удаление и изменение данных Глава 29. Выборка данных Глава 30. Хранимые процедуры Глава 31. Использование курсоров Глава 32. Триггеры Глава Основы Transact-SQL Целью любой системы управления базами данных является предоставление пользователю простых и эффективных механизмов манипулирования данными.

Для этого можно использовать самые различные методы управления данными.

Одним из таких методов является язык структурированных запросов (SQL, Structured Query Language).

Язык SQL является хорошим примером использования технологии клиент сервер. Когда пользователю требуется произвести некоторые операции с дан ными, он описывает действия, которые необходимо выполнить, с помощью ко манд языка SQL. Подготовленные команды, называемые запросом (query), от правляются на сервер баз данных. В соответствии с полученными инструкциями сервер осуществляет необходимые действия и отправляет клиенту лишь резуль тат работы. Таким образом, вся работа с данными производится на сервере.

Первая версия языка SQL была разработана в 1970 г. фирмой IBM. SQL изначаль но разрабатывался как язык управления реляционными базами данных. Это была не первая и не последняя попытка создания мощного и удобного механизма управления данными. Однако именно язык SQL стал общепринятым стандартом доступа к данным. Практически все современные системы управления базами данных используют для доступа к данным ту или иную модификацию языка SQL.

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

В 1992 г. американским национальным институтом стандартизации (ANSI, American National Standard Institute) был разработан стандарт на язык SQL, на званный ANSI SQL-92- Этот стандарт не только определяет основные правила использования команд, идентификаторов, переменных и т. д., но и регламенти рует работу самой системы управления базами данных. В частности, в стандарте ANSI SQL-92 были рассмотрены механизмы работы транзакций и блокировок.

Стандарт ANSI SQL-92 был хорошей попыткой зарегистрировать языки доступа к данным, используемые в различных СУБД. Однако со временем каждый из производителей начал улучшать и модернизировать возможности языка, под 1058 Часть V. Программирование страивая под конкретную СУБД. С одной стороны, это позволяет более эффек тивно использовать возможности той или иной СУБД. С другой стороны, опять же привело к потере совместимости продуктов. В настоящее время стандарт ANSI SQL-92 рассматривается скорее как общие рекомендации к построению эффективной системы управления базами данных, чем как конкретный список шагов по построению СУБД.

Корпорация Microsoft, как и многие другие производители, разработала свою версию языка SQL, назвав его Transact-SQL. Именно этот язык используется в SQL Server 2000 для доступа к данным, Этот язык удовлетворяет требованиям ANSI SQL-92, но предлагает пользователю еще и ряд дополнительных возмож ностей, позволяющих более гибко и эффективно работать с данными. Язык Transact-SQL активно используется не только в программных продуктах корпо рации Microsoft, но и в пакетах независимых разработчиков.

Глава 25. Основы Transact-SQL Прежде чем начать использовать переменную, ее необходимо создать — объявить.

При объявлении переменной указывается имя и ее тип данных. Для объявления переменной предназначена команда DECLARE, имеющая следующий синтаксис:

D C A E {@local_variable data_type} [,..л] ELR Имя переменной обязательно должно начинаться с символа @. Следующие сим волы могут быть любыми, исключая специальные символы. Ограничений на второй символ имени не накладывается.

1060 Часть V. Программирование PRINT @аа ;

,,,,,.-.....

.

SELECT её В результате на экран будет выведена следующая информация:

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

Переменные используются для хранения одиночных значений. Для временного хранения больших объемов информации в SQL Server 2000 предназначены вре менные таблицы. Временные таблицы бывают двух типов: глобальные и локаль ные. Независимо от типа временной таблицы, они всегда создаются в систем ной базе данных tempdb и автоматически уничтожаются при завершении работы. Даже если при создании временной таблицы будет явно указано имя базы данных, в которой она должна быть создана, оно проигнорируется, и таб лица все равно будет создана в базе данных tempdb.

( Замечание } В SQL Server 2000 появился новый тип данных— t a b l e. Переменные этого типа могут использоваться для хранения сложных наборов данных наподобие таблиц.

Работа с типом данных t a b l e будет рассмотрена в следующей главе.

Доступ к глобальной временной таблице (global temporary table) может быть получен из любого соединения, независимо от того, в каком именно из них она была соз дана. Это предоставляет удобный интерфейс для обмена данными между различ ными копиями хранимых процедур. Одна и та же хранимая процедура, запускае мая разными пользователями, может обращаться к глобальной временной таблице для получения информации. Кроме того, глобальные временные таблицы могут быть использованы для обмена данными между различными приложениями.

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

Для того чтобы создать глобальную временную таблицу, достаточно в начале ее имени при создании указать символы ##. Когда сервер встречает эти символы, он обращается к базе данных tempdb для поиска указанной таблицы. При этом игнорируется имя владельца таблицы и имя базы данных. В остальном же рабо Глава 25. Основы Ttansact-SQL та с временными таблицами ничем не отличается от работы с обычными табли цами. Для создания, изменения и удаления временных таблиц применяются те же команды, что и при работе с обычными таблицами. • Глобальная временная таблица существует до тех пор, пока пользователь явно не уничтожит ее с по мощью команды DROP TABLE или пока не будет закрыто соединение, в котором она создавалась. Кроме того, как глобальные, так и локальные временные таб лицы также уничтожаются при останове сервера.

( Замечание } Хотя глобальная временная таблица существует до закрытия соединения, тем не менее, она может быть'удалена или изменена ш любых других соединений.

Локальные временные таблицы (local temporary table) видны только из того со единения, в котором они были созданы. При закрытии соединения такая табли ца автоматически уничтожается. При следующем открытии соединения она должна быть создана заново. Кроме того, если локальная временная таблица была образована в хранимой процедуре, то После выхода из этой процедуры та кая таблица также автоматически уничтожается. В разных соединениях могут создаваться временные локальные таблицы с одинаковыми именами.

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

Для создания локальной временной таблицы необходимо перед именем таблицы при ее создании указать один символ #. В дальнейшем для ссылки на созданную таблицу также необходимо в ее имени указывать символ #. Приведем пример создания и использования локальной временной таблицы:

CREATE TABLE #Tbll_tmp (TID int, TName nvarchar(15) NULL) INSERT INTO #Tbll_tmp (TID, TName) VALUES (1234, 'String values') SELECT * FROM #Tbll_tmp DROP TABLE #Tbll_ttnp В результате выполнения приведенных команд будет создана временная таблица #Tbii_tmp с двумя столбцами — TID и TName. В таблицу будет вставлена одна строка. Затем выведется содержимое таблицы, после чего она уничтожится. При выполнении команд будет выведена следующая информация^ (1 row(s) affected) TID TName 1234 String values (1 row(s) affeeted) 1062 Часть V. Программирование Также допускается создание временной таблицы с помощью конструкции INTO команды SELECT:

USE pubs SELECT au_id, au_lname, au_fname INTO ##GlTbl FROM authors WHERE state != 'CA SELECT * FROM ##GlTbl В результате будет отображена следующая информация:

Создание временных таблиц с помощью конструкции INTO команды SELECT пре доставляет удобный механизм для обработки данных в хранимых процедурах.

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

Выражения Transact-SQL, как и многих других языков, состоят из операндов и операторов. Операнды — это исходные данные, используемые в выражении.

Значения этих данных не меняются. Операторами же являются действия, кото рые необходимо выполнить над операндами для вычисления выражения (например, сложение или умножение).

Операнды Операнды Transact-SQL бывают следующих типов:



Pages:     | 1 |   ...   | 26 | 27 || 29 | 30 |   ...   | 33 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.