Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Сжать базу после удаления данных в SQL 2000  [new]
bahadyr
Member

Откуда:
Сообщений: 102
Здравствуйте.
поскажите плиз.
есть БД Sql2000. (называется WEST)
база 4 Тб.

не давно удалили данные за 2006 - 2007 год. получается что в БД уменшились логические данные, но физический он не уменшился. Занимает ту же пространство на диске.
что нужно сделать чтобы сжать? провести дефрагментацию индексов, БД в целом?
какую процедуру произвести?
спасибо.
6 дек 12, 08:35    [13585418]     Ответить | Цитировать Сообщить модератору
 Re: Сжать базу после удаления данных в SQL 2000  [new]
Гость333
Member

Откуда:
Сообщений: 3683
bahadyr,

Можно узнать вашу роль в управлении этой БД? Просто несколько удивительно, чтобы администратор БД, имеющий дело с базой в 4 терабайта, не знал таких вещей. Поверьте, если не очень квалифицированный сотрудник начнёт уменьшать физический размер такой базы, с базой могут случиться проблемы (к примеру, дикая фрагментация индексов).
6 дек 12, 08:56    [13585499]     Ответить | Цитировать Сообщить модератору
 Re: Сжать базу после удаления данных в SQL 2000  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31429
bahadyr
что нужно сделать чтобы сжать? провести дефрагментацию индексов, БД в целом?
какую процедуру произвести?
Либо шринк с реорганизацией, либо пересоздать кластерные индексы, а потом обычный быстрый шринк.

Если это пустое место опять заполнится за ближайший год-два, и оно не слишком большое относительно общего размера, лучше вообще не делать сжатие.
6 дек 12, 08:58    [13585507]     Ответить | Цитировать Сообщить модератору
 Re: Сжать базу после удаления данных в SQL 2000  [new]
Гость333
Member

Откуда:
Сообщений: 3683
alexeyvg
либо пересоздать кластерные индексы

Только при этом ТС должен учесть, что на время пересоздания кластерного индекса соответствующая таблица будет недоступна, т.к. в MSSQL 2000 нет онлайн-перестроения индексов. Кроме того, во время пересоздания кластерного индекса БД может увеличиться -- то есть нужно проверить, хватит ли свободного места на дисках.
6 дек 12, 09:06    [13585535]     Ответить | Цитировать Сообщить модератору
 Re: Сжать базу после удаления данных в SQL 2000  [new]
bahadyr
Member

Откуда:
Сообщений: 102
Гость333
bahadyr,

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

я там делаю только бэкапы )
если бы знал, то раньше бы сделал. Тут страшновато с 4 Тб делать что либо с индексами. поэтому все указал.
вот и ответил. жду ответа от вас, к чему задавали такой вопрос.
6 дек 12, 15:05    [13588558]     Ответить | Цитировать Сообщить модератору
 Re: Сжать базу после удаления данных в SQL 2000  [new]
Гость333
Member

Откуда:
Сообщений: 3683
bahadyr,

Сначала по совету alexeyvg нужно оценить, сколько места вы выиграете от сжатия базы, и за какой срок после сжатия база снова вырастет. Размер свободного места в БД можно выяснить запуском процедуры sp_spaceused.

Затем:
alexeyvg
Если это пустое место опять заполнится за ближайший год-два, и оно не слишком большое относительно общего размера, лучше вообще не делать сжатие.


Если всё же пришли к выводу, что сжимать нужно, то возможны варианты.

1) DBCC SHRINKDATABASE (WEST, TRUNCATEONLY). Это самый быстрый и безболезненный вариант. Но он вряд ли освободит место, т.к. он просто обрезает файлы по последнему используемому экстенту, а удалённые данные находятся где-то в начале/середине файлов.

Более "продвинутые" способы (DBCC SHRINKDATABASE, DBCC SHRINKFILE без опций TRUNCATEONLY и NOTRUNCATE) сначала перемещают страницы в начало файла, а потом обрезают файл. При перемещении страницы перемешиваются, возникает фрагментация индексов (причём фрагментация в районе 99% — обычное явление при сжатии БД).

Далее идёт более подробное изложение вариантов от alexeyvg.

2) Если у вас есть сервисное окно, то можно пересоздать кластерные индексы на таблицах (команда DBCC DBREINDEX). Эта команда эксклюзивно блокирует таблицу, с которой работает в данный момент. Поэтому никакие запросы к таблице не будут возможны. Кроме того, если прервать операцию, то её результаты не сохранятся. Поэтому вы должны быть полностью уверены, что индекс успеет перестроиться за время сервисного окна. После перестроения индексов, делаете DBCC SHRINKDATABASE (WEST, TRUNCATEONLY).

3) Сервисного окна нет или оно слишком короткое. Тогда можно запустить команду DBCC SHRINKDATABASE или DBCC SHRINKFILE (без опций TRUNCATEONLY и NOTRUNCATE). При этом нужно учесть, что эти команды могут дать сильную нагрузку на дисковую подсистему. Если с базой идёт интенсивная работа, то вы можете сильно просадить производительность системы. После того, как шринк отработает, индексы скорее всего будут сильно фрагментированы, и это тоже может очень сильно уменьшить производительность системы. Поэтому нужно будет проверить фрагментацию при помощи команды DBCC SHOWCONTIG, и при необходимости дефрагментировать их командой DBCC INDEXDEFRAG. В отличие от DBCC DBREINDEX, эта операция не блокирует таблицу. Кроме того, она может быть прервана в любой момент, и результаты её работы при этом сохранятся. Недостаток INDEXDEFRAG в том, что он может работать на порядок медленнее, чем DBREINDEX.

Вот полезная ссылка, советую изучить: Microsoft SQL Server 2000 Index Defragmentation Best Practices
6 дек 12, 16:20    [13589179]     Ответить | Цитировать Сообщить модератору
 Re: Сжать базу после удаления данных в SQL 2000  [new]
bahadyr
Member

Откуда:
Сообщений: 102
Гость333
bahadyr,

Сначала по совету alexeyvg нужно оценить, сколько места вы выиграете от сжатия базы, и за какой срок после сжатия база снова вырастет. Размер свободного места в БД можно выяснить запуском процедуры sp_spaceused.

Затем:
alexeyvg
Если это пустое место опять заполнится за ближайший год-два, и оно не слишком большое относительно общего размера, лучше вообще не делать сжатие.


Если всё же пришли к выводу, что сжимать нужно, то возможны варианты.

1) DBCC SHRINKDATABASE (WEST, TRUNCATEONLY). Это самый быстрый и безболезненный вариант. Но он вряд ли освободит место, т.к. он просто обрезает файлы по последнему используемому экстенту, а удалённые данные находятся где-то в начале/середине файлов.

Более "продвинутые" способы (DBCC SHRINKDATABASE, DBCC SHRINKFILE без опций TRUNCATEONLY и NOTRUNCATE) сначала перемещают страницы в начало файла, а потом обрезают файл. При перемещении страницы перемешиваются, возникает фрагментация индексов (причём фрагментация в районе 99% — обычное явление при сжатии БД).

Далее идёт более подробное изложение вариантов от alexeyvg.

2) Если у вас есть сервисное окно, то можно пересоздать кластерные индексы на таблицах (команда DBCC DBREINDEX). Эта команда эксклюзивно блокирует таблицу, с которой работает в данный момент. Поэтому никакие запросы к таблице не будут возможны. Кроме того, если прервать операцию, то её результаты не сохранятся. Поэтому вы должны быть полностью уверены, что индекс успеет перестроиться за время сервисного окна. После перестроения индексов, делаете DBCC SHRINKDATABASE (WEST, TRUNCATEONLY).

3) Сервисного окна нет или оно слишком короткое. Тогда можно запустить команду DBCC SHRINKDATABASE или DBCC SHRINKFILE (без опций TRUNCATEONLY и NOTRUNCATE). При этом нужно учесть, что эти команды могут дать сильную нагрузку на дисковую подсистему. Если с базой идёт интенсивная работа, то вы можете сильно просадить производительность системы. После того, как шринк отработает, индексы скорее всего будут сильно фрагментированы, и это тоже может очень сильно уменьшить производительность системы. Поэтому нужно будет проверить фрагментацию при помощи команды DBCC SHOWCONTIG, и при необходимости дефрагментировать их командой DBCC INDEXDEFRAG. В отличие от DBCC DBREINDEX, эта операция не блокирует таблицу. Кроме того, она может быть прервана в любой момент, и результаты её работы при этом сохранятся. Недостаток INDEXDEFRAG в том, что он может работать на порядок медленнее, чем DBREINDEX.

Вот полезная ссылка, советую изучить: Microsoft SQL Server 2000 Index Defragmentation Best Practices

места будут заполнятся в будущем.
Дефрагментацию лучше не буду делать. Так решил.
а вот DBCC SHRINKDATABASE (без опций TRUNCATEONLY и NOTRUNCATE) у меня идет по плану раз в месяц.

спасибо за подробности.
7 дек 12, 08:04    [13591558]     Ответить | Цитировать Сообщить модератору
 Re: Сжать базу после удаления данных в SQL 2000  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31429
bahadyr
а вот DBCC SHRINKDATABASE (без опций TRUNCATEONLY и NOTRUNCATE) у меня идет по плану раз в месяц.
А вот этого не надо, вы таким образом фрагментируете файлы, скорость уменьшается.

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

В штатно работающей базе его применять не нужно, он как минимум бесполезен.

И в случае применения в нештатной ситуации нужно использовать TRUNCATEONLY, это по крайней мере не повредит структуру данных в файлах.
7 дек 12, 08:43    [13591655]     Ответить | Цитировать Сообщить модератору
 Re: Сжать базу после удаления данных в SQL 2000  [new]
bahadyr
Member

Откуда:
Сообщений: 102
alexeyvg
bahadyr
а вот DBCC SHRINKDATABASE (без опций TRUNCATEONLY и NOTRUNCATE) у меня идет по плану раз в месяц.
А вот этого не надо, вы таким образом фрагментируете файлы, скорость уменьшается.

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

В штатно работающей базе его применять не нужно, он как минимум бесполезен.

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

а как часто нужно запускать DBCC SHRINKDATABASE (WEST, TRUNCATEONLY) ?
если база 4 Тб и в месяц увеличивается 50-70 Гб.

у меня вот такая команда включена DBCC SHRINKDATABASE (WEST, 10)
7 дек 12, 13:48    [13594247]     Ответить | Цитировать Сообщить модератору
 Re: Сжать базу после удаления данных в SQL 2000  [new]
WarAnt
Member

Откуда: Питер
Сообщений: 2421
bahadyr,

не чаще чем возникают нештатные операции по усечению данных.
7 дек 12, 13:54    [13594304]     Ответить | Цитировать Сообщить модератору
 Re: Сжать базу после удаления данных в SQL 2000  [new]
bahadyr
Member

Откуда:
Сообщений: 102
WarAnt
bahadyr,

не чаще чем возникают нештатные операции по усечению данных.

Все понял.
спасибо большое всем за огромную поддержку. :)
7 дек 12, 17:00    [13596118]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить