Сокращение временных табличных пространств
Иногда может понадобиться увеличить временное табличное пространство, чтобы вместить данные очень крупного задания, которое интенсивно использует это временное табличное пространство. После завершения такого задания можно сократить это временное табличное пространство, используя конструкцию SHRINK SPACE в операторе ALTER TABLESPACE. Вот пример:
SQL> ALTER TABLESPACE temp SHRINK SPACE; Tablespace altered. SQL>
Конструкция SHRINK SPACE уменьшит временные файлы до минимального размера,который составляет около 1 Мбайт. С помощью конструкции KEEP можно задать минимальный размер для временных файлов, как показано ниже:
SQL> ALTER tablespace temp SHRINK SPACE KEEP 250m;
Oracle использует специальную логику при сжатии временных файлов во временном табличном пространстве. Предположим, что имеется временное табличное пространство, содержащее два временных файла по 1 Гбайт. Для сокращения табличного пространства до 1 Гбайт выдается следующая команда:
SQL> ALTER TABLESPACE temp SHRINK SPACE KEEP 1000M; Tablespace altered. SQL>
Если запросить представление V$TEMPFILE, можно будет увидеть следующее:
SQL> SELECT file#, name, bytes/1024/1024 mb FROM v$tempfile; FILE# NAME MB ----- ------------------------------------ --------- 1 /u01/app/oracle/tempfile/temp01.dbf 999.9375 2 /u01/app/oracle/tempfile/temp02.dbf' 1.0625
База данных сократит один из двух временных файлов вплоть до 1 Мбайт, а другой — только на 1 Мбайт, оставив в нем нетронутыми 999 Мбайт пространства. Если ваша цель — сократить определенный временный файл до заданного минимума, можете сделать это, указав имя временного файла, который нужно сократить:
SQL> ALTER TABLESPACE temp SHRINK SPACE TEMPFILE tempfile '/u01/app/oracle/oradata/prod1/temp02.dbf' KEEP 100m; Tablespace altered. SQL>
Приведенный выше оператор ALTER TABLESPACE сокращает только указанный временный файл до размера, заданного в конструкции KEEP. Остальные временные файлы из табличного пространства TEMP остаются нетронутыми. Конструкция KEEP в приведенном выше операторе гарантирует, что временный файл, который был специфицирован, сохранит 500 Мбайт пространства. Следующий пример демонстрирует, как сократить отдельный временный файл, не указывая сохранившегося пространства:
SQL> ALTER TABLESPACE temp SHRINK tempfile '/u01/app/oracle/tempfile/temp03.dbf';
Поскольку в предыдущем операторе конструкция KEEP указана не была, база данных сокращает указанный временный файл до минимально возможного размера, который составляет около 1 Мбайт.
Удаление неактивных и повторно запущенных пользователем сеансов — обработкой в фоне или внешней обработкой
На экране монитора при запуске конфигурации нередко приходится видеть обидное сообщение «Не обнаружено свободной лицензии». Особенно это актуально, когда у вас 100 лицензий и при этом работает порядка 90 пользователей. При этом, очень актуальна жесткая политика — «Один сеанс в одни руки». Для автоматизации ручной работы администратора 1С по удалению сеансов пользователей и предназначена данная обработка. Обработка может быть использована как внешняя, так и поставлена в дополнительные отчеты и обработки с установкой расписания запуска, в этом случае обработка будет выполняться как фоновое задание. Обработка предназначена для работы в клиент-серверных базах и тестировалась на платформе 8.3.14.1854. Обработка установленная на платформе не ниже 8.3.6, позволяет управлять сеансами конфигураций установленных на платформе 8.2
1 стартмани
Удаление неактивных и повторно запущенных пользователем сеансов — обработкой в фоне или внешней обработкой
На экране монитора при запуске конфигурации нередко приходится видеть обидное сообщение «Не обнаружено свободной лицензии». Особенно это актуально, когда у вас 100 лицензий и при этом работает порядка 90 пользователей. При этом, очень актуальна жесткая политика — «Один сеанс в одни руки». Для автоматизации ручной работы администратора 1С по удалению сеансов пользователей и предназначена данная обработка. Обработка может быть использована как внешняя, так и поставлена в дополнительные отчеты и обработки с установкой расписания запуска, в этом случае обработка будет выполняться как фоновое задание. Обработка предназначена для работы в клиент-серверных базах и тестировалась на платформе 8.3.14.1854. Обработка установленная на платформе не ниже 8.3.6, позволяет управлять сеансами конфигураций установленных на платформе 8.2
1 стартмани
«Стандартные отчеты» в пользовательском интерфейсе Management Studio
SQL Server Management Studio предоставляет минимальный необходимый набор стандартных отчетов для получения информации о размере базы данных/ее файлов/таблиц/индексов в режиме пользовательского интерфейса.
Доступ к этим отчетам может быть выполнен через «Обозреватель объектов» (Object explorer) → Правый клик мыши по базе данных → «Отчеты» (Reports) → «Стандартный отчет» (Standard reports)
Стандартные отчеты по использованию дискового пространства
Отчет «Занято места на диске» (Disk Usage)
Отчет содержит общие сведения об использовании места на диске базой данных.
В отчете представлена информация следующего рода:
- Общий объем, занятый на диске (Total space reserved)
- Место, занятое файлами данных (Data files space reserved)
- Место, занятое журналом транзакций (Transaction log space reserved)
- Отражает графически процент пространств в составе файлов данных: индексов (index), данных (data), не выделенного (unallocated) и не используемого (unused)
- Отражает графически процент примененного (used) и неиспользуемого (unused) пространства в составе журнала транзакций
- Выводит записи событий автоматического увеличения (autogrow) и/или сжатия (autoshrink) для базы данных
- Выводит информацию о месте на диске, используемом файлами данных
Отчет «Занято места на диске» (Disk Usage)
Отчет содержит подробные данные об использовании места на диске таблицами, расположенными в базе данных. Отличие этих двух отчетов заключается лишь в том что в отчете «By Top Tables» вывод происходит только для «верхних» (первых) 1000 таблиц.
В отчете представлена информация:
- Количество записей в таблице базы данных (Records)
- Размер зарезервированного пространства на диске (Reserved)
- Размер данных на диске (Data)
- Общий размер индексов таблицы на диске (Indexes)
- Размер не используемого пространства (Unused)
Отчет «Использование дисковой памяти таблицей» (Disk Usage by Table)
Отчет «Использование дисковой памяти секцией» (Disk Usage by Partition)
Отчет содержит подробные данные об использовании места на диске индексом и секциями, расположенными в базе данных.
Хотел бы обратить Ваше внимание что в данном отчете неверно рассчитывается дисковое пространство по кластерному индексу. Для получения реально используемого дискового пространства кластерным индексом можно: из «объема, используемого всеми индексами таблицы» (указанном в отчете «Использование дисковой памяти таблицей») вычесть «объем всех не кластерных индексов» (по отчету «Использование дисковой памяти секцией»). В отчете представлена информация:
В отчете представлена информация:
- Число записей в индексе/секции (Records)
- Зарезервированное пространство на диске (Reserved)
- Используемое пространство на диске (Used)
Отчет «Использование дисковой памяти секцией» (Disk Usage by Partition)
Вопросы производительности
Хотя операции с индексами в сети допускают одновременную работу пользователей, в этом случае они выполняются тем дольше, чем интенсивнее происходит обновление данных. Обычно операции с индексами в сети выполняются медленнее, чем аналогичные операции вне сети, независимо от текущей интенсивности обновления данных.
![Настройка выделения памяти опциями "maximum server memory" и "minimum server memory" [вики it-kb]](https://fuzeservers.ru/wp-content/uploads/b/6/3/b63893b6c9f3c3488400f49116d16082.jpeg)
Поскольку и исходная, и целевая структуры обслуживаются во время выполнения операции с индексами в сети, увеличивается потребление ресурсов при вставке, обновлении и удалении, и это увеличение может доходить до двукратного. Это может привести к снижению производительности и повышению нагрузки на систему, особенно ресурсов ЦП. Операции с индексами в сети полностью записываются в журнал.
Несмотря на то, что рекомендуется выполнять операции с индексами в сети, необходимо предварительно оценить среду и определенные требования. Возможно, оптимальным решением может оказаться переключение в режим вне сети. При этом на время выполнения операции пользователи будут иметь ограниченный доступ к данным, но она быстрее закончится и в итоге займет меньше ресурсов.
Поскольку на финальной фазе удерживаются блокировки S-lock и Sch-M, будьте внимательны при выполнении операций с индексами в сети внутри явно объявленных пользовательских транзакций (например: в блоке BEGIN TRANSACTION…COMMIT), поскольку в этом случае блокировка будет удерживаться до окончания транзакции, мешая одновременной работе пользователей.
Перестроение индекса в сети может привести к увеличению фрагментации, когда оно выполняется с параметрами и . Дополнительные сведения см. в статье Как это работает. Перестроение индекса в сети может привести к увеличению фрагментации.
Представление (VIEW) в Microsoft SQL Server
Представление (VIEW) – это объект базы данных Microsoft SQL Server, который хранит в себе запрос SELECT и в случае обращения к данному объекту будет возвращен результирующий набор данных, который формирует запрос, указанный в определении представления.
Иными словами, это виртуальная (логическая) таблица, она не содержит в себе данных, но к ней можно обращаться как к обычной таблице, и она будет возвращать Вам данные. Обычно такой объект называют «Вьюха».
Для чего нужны представления
Если достаточно часто в своих SQL запросах Вы используете однотипные вложенные запросы, которые возвращают табличные данные, т.е. являются производными таблицами, то для удобства и сокращения кода Вы можете сохранить такие вложенные запросы в виде представления. И затем, где Вам требуется использовать именно тот набор данных, который Вы указали в запросе, Вы будете указывать название представления, точно так же как мы указываем название таблиц, согласитесь — это очень удобно!
Таким образом, представления нужны для:
- Упрощения и сокращения кода запроса;
- Повышения читабельности кода запроса;
- Сокрытия сложности реализации задачи от пользователя;
- Обеспечения эффективных путей доступа к данным;
- Обеспечения корректности производных данных;
- Более легкого управления. Чтобы внести изменения в алгоритм, формирующий данные, которые возвращает представление, не требуется изменять код везде, где используется этот алгоритм, достаточно изменить код в одном определении представления.
Как Вы понимаете, представления мы можем использовать не только для упрощения и сокращения кода SQL запроса, а еще для повышения безопасности, сокрытия сложности реализации алгоритмов и для обеспечения корректности производных данных.
Какие бывают представления
Представления бывают:
- Пользовательские – это те, которые мы сами создаем;
- Системные – это представления, которые уже есть в SQL сервере. Они возвращают нам системную информацию.
Аппаратное обеспечение
При размещении временной базы данных для ускорения ее работы используются различные аппаратные решения:
- SSD, в т.ч. PCI Express — с падением стоимости и увеличением надежности может стать оптимальным решением для сервера базы данных. Один твердотельный накопитель может заменить по производительности RAID-массив из HDD, будучи дешевле. Но необходимо тщательно выбирать на основе параметров подходящую модель (см., например, рекомендации SQL Server and SSDs).
- RAID 10, в т.ч. на основе SSD — поскольку временная база данных является системной и ее сбой приведет к остановке сервера базы данных, необходимо, помимо производительности, также обеспечить надежность.
- RAM disk — размещение файлов в оперативной памяти (программное решение) или на PCI карте с DIMM (аппаратное решение). Может ускорить производительность операций с временной базой данных на порядок и более.
Источники
- База данных tempdb
- Tempdb Configuration Best Practices in SQL Server
- Working with tempdb in SQL Server 2005
- TempDB Performance and Configuration
- Recommendations to reduce allocation contention in SQL Server tempdb database
- Using Solid State Disks in SQL Server Storage Solutions
- Migrating Server Storage to SSDs: Analysis of Tradeoffs
- Put TEMPDB on a RAM DRIVE
- Уровни RAID и SQL Server
Обработка восстановления последовательности (НЕ МОНОПОЛЬНО, с возможностью задать отбор по Контрагентам и по Фирмам) Промо
Обработка предназначена для восстановления последовательности проведения документов.
Пригодится, когда возникает ситуация необходимости перепроведения документов, в хронологическом порядке или в том порядке, в котором нужно пользователю за определенный период времени.
Отличается от стандартной обработки «Проведение документов», тем что, можно сделать отбор документов по фирме, по контрагенту или группе контрагентов, и нет необходимости в монопольном доступе, а также можно менять последовательность документов по усмотрению пользователя.
Эта версия обработки для использования на платформе 8.2 в типовых конфигурациях БП 2.0, а также и для УТ 10.3 и УТП 1.2
1 стартмани
Настройка версионности
Для каждой базы данных, которую мы хотим перевести в режим версионности, необходимо выполнить следующую команду:
ALTER DATABASE AdventureWorks SET ALLOW_SNAPSHOT_ISOLATION ON;
Команда не блокируется подключением других пользователей и выполняется в отложенном режиме до завершения всех текущих транзакций. Новые транзакции после данной команды начнут создавать версии строк при модификации данных.
До завершения перехода базы данных в режим версионности попытка выполнения команд с уровнем изоляции SNAPSHOT_ISOLATION будет приводить к программной ошибке 3956.
Проверить состояние базы данных можно следующим запросом:
select snapshot_isolation_state, snapshot_isolation_state_desc from sys.databases where name = 'AdventureWorks'
Если вернутся значения snapshot_isolation_state = 1 или snapshot_isolation_state_desc = ON, то это значит что база данных перешла в режим версионности и можно запускать сессии с этим уровнем изоляции.
Для запуска сессии в режиме версионности требуется выполнить следующую команду:
SET TRANSACTION ISOLATION LEVEL SNAPSHOT
Не всегда мы можем исправить существующий код чтобы явно установить уровень изоляции с версионностью. В этом случае требуется выполнить команду, которая уровень по умолчанию READ COMITTED (блокировка чтения при записи) заменит на версионность:
ALTER DATABASE AdventureWorks SET READ_COMMITTED_SNAPSHOT ON
Команда блокируется подключением других пользователей. Для ее выполнения требуется монопольный доступ к базе данных.
Если в коде используется «грязное чтение» (уровень изоляции READ UNCOMITTED, подсказка NOLOCK), то мы не получим преимуществ по производительности от версионности.
Но данный режим работы базы данных нам потребуется для поддержки распределенных транзакций, снижения нагрузки на временную базу данных и предотвращения конфликтов при обновлении данных. Если имеются распределенные транзакции, то для поддержки версионности требуется перевести в этот режим все участвующие базы данных.
Формула для оценки дополнительного пространства в tempdb: 2 * * .
Фазы построения индекса
Процесс построения индекса компонентой Компонент Database Engine состоит из следующих фаз.
-
Сначала компонент Компонент Database Engine просматривает страницы данных базовой таблицы, чтобы получить значение ключа, и строит конечную строку индекса для каждой строки данных. Когда внутренние буферы сортировки заполняются конечными элементами индекса, эти элементы сортируются и записываются на диск как промежуточный проход сортировки. Затем компонент Компонент Database Engine возобновляет просмотр страниц данных, пока буфер сортировки не заполнится вновь. Процедура просмотра нескольких страниц данных с последующей сортировкой и записью результатов сортировки продолжается до тех пор, пока не будут обработаны все строки базовой таблицы.
В кластеризованном индексе конечные строки являются строками данных таблицы, поэтому промежуточная сортировка содержит все строки. В некластеризованном индексе конечные строки могут содержать неключевые столбцы, но в целом они меньше, чем кластеризованный индекс. Если ключи индекса большие или в индекс входят несколько неключевых столбцов, то операция некластеризованной сортировки может быть большей. Дополнительные сведения о неключевых столбцах см. в разделе Create Indexes with Included Columns.
-
-
Компонент Компонент Database Engine объединяет отсортированные потоки конечных строк индекса в единый отсортированный поток. Компонент объединенной сортировки компонента Компонент Database Engine начинает с первой страницы каждой операции сортировки, отыскивает самый нижний ключ во всех страницах и передает эту конечную строку компоненту создания индекса. Затем обрабатывается следующий индекс снизу, потом следующий и т. д. Когда последняя конечная строка индекса извлекается из страницы операции сортировки, процесс переходит к следующей странице этой операции сортировки. Когда все страницы в операции сортировки обработаны, кластер страниц освобождается. Когда каждая конечная строка индекса пересылается в компонент создания индекса, она включается в конечную страницу индекса в буфере. Каждая конечная страница записывается по мере заполнения. По мере записи конечных страниц компонента Компонент Database Engine также строит верхние уровни индекса. Каждая страница индекса верхнего уровня записывается по мере заполнения.
3.2.9. Опции
Теперь посмотрим, какие дополнительные параметры можно использовать во время создания процедуры. Таких параметров два:
- RECOMPILE – указывает на то, что MS SQL Server не должен сохранять план выполнения, компиляция будет происходит при каждом выполнении;
- ENCRYPTION – запись в таблице syscomments с текстом процедуры должна шифроваться.
Посмотрим, как можно использовать шифрование:
CREATE PROCEDURE GetPhones WITH ENCRYPTION AS SELECT pl.vcFamil, pl.vcName, pl.vcSurName, dDateBirthDay, vcPhoneNumber FROM tbPeoples pl, tbPhoneNumbers pn WHERE pn.idPeoples=*pl.idPeoples
Опция WITH ENCRYPTION указывается после всех параметров процедуры, но до ключевого слова AS.
Теперь посмотрим, что сервер сохранил в своих системных таблицах. Для этого выполните следующий запрос:
SELECT * FROM sysobjects so, syscomments sc WHERE name='GetPhones' AND so.id=sc.id
В колонке text вы увидите только бессмысленные символы. Для любой другой процедуры здесь будет ее текст, а для зашифрованной будут данные, которые не несут полезной информации.
Давайте посмотрим на запрос, который мы использовали для получения информации о процедуре. Здесь у нас выбираются данные из двух таблиц sysobjects и syscomments. В первой таблице находятся имена всех объектов базы данных, а в таблице syscomments находятся параметры объекта. Для хранимой процедуры здесь можно увидеть текст самой процедуры в поле «text», если он не зашифрован.
Создание временного табличного пространства
Вы создаете временное табличное пространство точно так же, как и постоянное,лишь с тем отличием, что указываете конструкцию TEMPORARY в операторе CREATE TABLESPACE и подставляете эту конструкцию TEMPFILE вместо DATAFILE. Вот пример:
SQL> CREATE TEMPORARY TABLESPACE temp_demo TEMPFILE 'temp01.dbf' SIZE 500M AUTOEXTEND ON;
Конструкция SIZE во второй строке указывает размер файла данных и, как следствие, размер временного табличного пространства — 500 Мбайт. В приведенном операторе конструкция AUTOEXTEND ON приведет к автоматическому увеличению размера временного файла и вместе с ним — размера временного табличного пространства. По умолчанию все временные табличные пространства создаются с экстентами унифицированного размера — 1 Мбайт. Тем не менее, можно указать конструкцию UNIFORM SIZE,чтобы задать другой размер, как показано в следующем операторе:
SQL> CREATE TEMPORARY TABLESPACE temp_demo TEMPFILE 'temp01.dbf' SIZE 500M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 16M;
В приведенном операторе конструкция EXTENT MANAGEMENT необязательна.Конструкция UNIFORM SIZE специфицирует специальный размер экстента в 16 Мбайт вместо 1 Мбайт по умолчанию.
Совет. При выделении места временному табличному пространству применяйте конструкцию TEMPFILE вместо DATAFILE.
Обычно принято создавать одно временное табличное пространство (именуемое, как правило, Temp) для каждой базы данных, но вполне можно иметь и несколько временных табличных пространств, входящих в группу временных табличных пространств,если база данных нуждается в выполнении интенсивных операций сортировки.Чтобы уничтожить данные во временном табличном пространстве по умолчанию,необходимо сначала воспользоваться командой ALTER TABLESPACE для создания нового табличного пространства по умолчанию в базе данных. Предыдущее временное табличное пространство по умолчанию затем можно уничтожить подобно любому другому.
На заметку! Oracle рекомендует устанавливать в качестве временного табличного пространства по умолчанию управляемое локально временное табличное пространство с унифицированным размером экстента в 1 Мбайт.
3.2.8. Использование процедур при вставке данных
Оператор INSERT может заполнять локальную таблицу результирующим набором, который возвращается из локальной или удаленной процедуры. Сервер SQL заполняет таблицу данными, которые возвращаются оператором SELECT в процедуре. Таблица должна существовать и типы данных должны совпадать.
Рассмотрим эту возможность. Для начала создадим процедуру, которая будет выбирать данные на определенную дату:
CREATE PROCEDURE GetGoods @Date datetime AS SELECT * FROM Товары WHERE Дата=@Date
Следующий пример использует процедуру для вставки данных в таблицу товаров:
INSERT INTO Товары EXEC GetGoods '01.01.2005'
Данный запрос вставляет в таблицу товаров результат выполнения процедуры GetGoods. Количество и типы полей должны совпадать, а у нас они будут совпадать, потому что процедура выбирает данные из той же таблицы товаров данные за указанную дату.
Теперь если просмотреть таблицу товаров, то вы увидите, что данные за первое января 2005-го года в таблице содержаться дважды. Именно на эту дату процедура выбирала данные, и их вставили в таблице товаров. Чтобы лучше было двойные записи, отсортируйте их по дате и названию:
SELECT * FROM Товары ORDER BY Дата,
Оптимизация индексов в Microsoft SQL Server
В результате выполнения операций обновления, добавления или удаления данных в таблицах SQL сервер автоматически вносит соответствующие изменения в индексы, но со временем все эти изменения могут вызвать фрагментацию данных в индексе, т.е. они окажутся разбросанными по базе данных. Фрагментация индексов влечет за собой снижение производительности запросов, поэтому периодически необходимо выполнять операции обслуживания индексов, а именно дефрагментацию, к таким можно отнести операции реорганизации и перестроения индексов.
В каких случаях использовать реорганизацию индекса, а в каких перестроение?
Чтобы ответить на этот вопрос сначала необходимо определить степень фрагментации индекса, так как в зависимости от фрагментации индекса тот или иной метод дефрагментации будет предпочтительней и эффективней. Для определения степени фрагментации индекса можно использовать системную табличную функцию sys.dm_db_index_physical_stats, которая возвращает подробные сведения о размере и фрагментации индексов. Например, используя следующий запрос, Вы можете узнать степень фрагментации индексов у всех таблиц в текущей базе данных.
SELECT OBJECT_NAME(T1.object_id) AS NameTable,
T1.index_id AS IndexId,
T2.name AS IndexName,
T1.avg_fragmentation_in_percent AS Fragmentation
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS T1
LEFT JOIN sys.indexes AS T2 ON T1.object_id = T2.object_id AND T1.index_id = T2.index_id
В данном случае нас интересует столбец avg_fragmentation_in_percent, т.е. процентная доля логической фрагментации.
Так вот, Microsoft рекомендует:
- Если степень фрагментации менее 5%, то реорганизацию или перестроение индекса вообще не стоит запускать;
- Если степень фрагментации от 5 до 30%, то имеет смысл запустить реорганизацию индекса, так как данная операция использует минимальные системные ресурсы и не требует долговременных блокировок;
- Если степень фрагментации более 30%, то необходимо выполнять перестроение индекса, так как данная операция, при значительной фрагментации, дает больший эффект чем операция реорганизации индекса.
Лично я могу добавить следующее, если у Вас небольшая компания и база данных не требует максимальной отдачи в режиме 24 часа в сутки, т.е. она не суперактивная БД, то Вы можете смело периодически выполнять операцию перестроения индексов, при этом даже не определяя степень фрагментации.
Реорганизация индексов
Реорганизация индекса – это процесс дефрагментации индекса, который дефрагментирует конечный уровень кластеризованных и некластеризованных индексов по таблицам и представлениям, физически переупорядочивая страницы концевого уровня в соответствии с логическим порядком (слева направо) конечных узлов.
Для реорганизации индекса можно использовать как графический инструмент SSMS, так и инструкцию Transact-SQL.
Реорганизация индекса с помощью Management Studio
Реорганизация индекса с помощью Transact-SQL
ALTER INDEX IX_NonClustered ON TestTable REORGANIZE GO
Перестроение индексов
Перестроение индекса – это процесс, при котором происходит удаление старого индекса и создание нового, в результате чего фрагментация устраняется.
Для перестроения индексов можно использовать два способа.
Первый. Используя инструкцию ALTER INDEX с предложением REBUILD. Эта инструкция заменяет инструкцию DBCC DBREINDEX. Обычно для массового перестроения индексов используется именно этот способ.
Пример
ALTER INDEX IX_NonClustered ON TestTable REBUILD GO
И второй, используя инструкцию CREATE INDEX с предложением DROP_EXISTING. Можно использовать, например, для перестроения индекса с изменением его определения, т.е. добавления или удаления ключевых столбцов.
Пример
CREATE NONCLUSTERED INDEX IX_NonClustered ON TestTable
(
CategoryID ASC
)
WITH(DROP_EXISTING = ON)
GO
В Management Studio функционал для перестроения также доступен. Правой кнопкой по нужному индексу «Перестроить».
На этом материал по основам индексов в Microsoft SQL Server закончен, если Вас интересует SQL и T-SQL, рекомендую посмотреть мои видеокурсы по T-SQL, с помощью которых Вы «с нуля» научитесь работать с SQL и программировать с использованием языка T-SQL в Microsoft SQL Server, удачи!
Нравится29Не нравится2
