|
|
17.01.2013, 17:53
|
#1 |
|
Участник
|
распух EVENTCUD
Добрый день.
Подскажите пожалуйста, как лучше быть? 2 дня назад, коллега что-то криво настроил в оповещениях, так что таблица EVENTCUD распухла за 2 дня до 700 гб, место на сервере стремительно кончается, нашли задание тормознули, между тем БД сильно выросла в размере. Truncate на сколько я понял лучше не делать, решил delete from EVENTCUD where created by = 'XXXXX', и вот далее возникает проблема, как быстро уменьшить базу SHRINKDATABASE, на тестовом сервере идет уже полтора суток, сколько еще будет идти не понятно, на промышленном поидее должно быть быстрее, ввиду хорошего железа, но угадать сложно. Размер БД сейчас 1.2 ТБ. Кто нибудь сталкивался? Как боролись? |
|
|
|
17.01.2013, 18:02
|
#2 |
|
Участник
|
Почему не truncate? Тем более на тестовой базе? Ну потеряете часть оповещений (еще на высланных пользователям), чего страшного?
__________________
Ivanhoe as is.. |
|
|
|
17.01.2013, 22:10
|
#3 |
|
Участник
|
truncate на тестовой сделал, все ок, правда shrinkdatabase идет больше суток. Речь о промышленной базе. Вот думаю может сделать ребилд индексов, поидее ребилд должен положить индексы в начало файла. После ребилда в конце файла останутся только таблицы без кластерного индекса, если таковые есть, если нет, то шринк TRUNCATEONLY отработает в момент и все сделает.
Так вот это просто догадки, может кто то сталкивался и подскажет как можно сделать |
|
|
|
18.01.2013, 00:27
|
#4 |
|
Модератор
|
Цитата:
Сообщение от godzila46
truncate на тестовой сделал, все ок, правда shrinkdatabase идет больше суток. Речь о промышленной базе. Вот думаю может сделать ребилд индексов, поидее ребилд должен положить индексы в начало файла. После ребилда в конце файла останутся только таблицы без кластерного индекса, если таковые есть, если нет, то шринк TRUNCATEONLY отработает в момент и все сделает.
Так вот это просто догадки .. Размер БД сейчас 1.2 ТБ
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
|
17.01.2013, 22:11
|
#5 |
|
Участник
|
да и в таком случае поидее можно будет сделать DBCC SHRINKFILE, что впринципе быстрее shrinkdatabase.
|
|
|
|
| За это сообщение автора поблагодарили: Logger (3). | |
|
18.01.2013, 10:42
|
#6 |
|
Участник
|
Решили все таки сделать truncate, вот теперь думаю проделать описанное мной выше, дабы базу ужать.
|
|
|
|
18.01.2013, 10:51
|
#7 |
|
Участник
|
Реиндексацию? Сделайте, полезно будет)
|
|
|
|
18.01.2013, 12:25
|
#8 |
|
Участник
|
Ну она у меня и так выполняется 2 раза в неделю, сейчас решил непосредственно сделаю перед SHRINKFILE, ставил эксперимент на тестовой зоне, с копией пром базы, прошло все достаточно быстро (5 мин).
|
|
|
|
18.01.2013, 12:26
|
#9 |
|
Участник
|
ну и + 7 часов на ребилд
|
|
|
|
23.01.2013, 10:14
|
#10 |
|
Участник
|
вообщем, при работающей системе подобная схема не прокатывает
Пришлось все тормозить. |
|
|
Комбинированный вид
