Прошу форумчан помочь в решении такой проблемы.
Была УПП 1.2.37. Сейчас мы перевели тестовую базу на 1.3, некоторые документы удалили.
Во первых база переводилась долго - почти 7 часов. Писалось идет реструктуризация регистров (похоже всех - и бух и накопления и сведений).
Во вторых распухла дико - вместо 56 Гб MDF и 10 Гб LDF стала 80 и 85 Гб соответственно.
Непонятно почему так?
Сделал шринк свободного места LDF - не помогло - 4 Гб высвободилось.
Помогло только выгрузка базы, убийство скульной, создание пустой и загрузка. Тогда стала 42 Гб. Но это не дело - база распределенная и так делать крайне долго.
Вопрос - почему все это произошло и как победить методами SQL.
Буду благодарен за помощь

прошу перенести в раздел V8

а в чём проблема-то? место кончилось?

индексы наверное...

увеличилась в 7 раз!
Вопрос - почему?
А место... Да - его немного

ну не в 7 - я погорячился, но в 3 точно

(4) сделайте отчет по таблицам и посмотрите. в чем проблема то?

шринк только после бэкапа работает норм, типа бэкап транзакшен лог виф ноу транкейт, и шринк

(7)плохо.
А никак больше шринк не сделать?

(8) А что плохого? Шринкование стоит у меня в планах обслуживания.

(9)бэкап долго тоже делается.
А так просто как бы взять и отрезать ненужные LDF

только в момент шринкования базу надо в монопольный режим загонять на sql

ну и "регламентное обслуживание" сделай, ребуилд индекс например, потом сбэкапь, зашринкуй и норм должно стать

В свойствах базы есть пунктик "Модель восстановления" скорее всего стоит "полная". Переведите на "простую" сделайте шринк и опять верните на полную.

регистры, распухли, скорее всего, посмотрите по регистрам по сравнению с 1.2.

(10) бэкап транзакшен лог виф ноу транкейт не долго делается

(13) Ересь. Просто нужно правильно бэкап настроить, тогда лог транзакций больше 100 метров не распухнет. А Бэкап лога транзакций никогда никому не мешал.

(16) на фулл модели распухнет всё равно, надо шринкование делать

)))
86 год

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

(19) я откатывал, когда занимался этим, на 2005 скл. по ночам был бэкап и обрезание логов. В течении дня т.е. могли откатить

один раз понадобилось за 1,5 года... так что ставить или нет решайте сами)

(19) Не умею. Но полная модель всегда лучше простой в плане объёма резервных копий и частоты создания резервных копий.

(17) Ага 7 раз распухнет. У меня лог транзакций бэкапится каждые 15 минут. При бэкапе лога транзакций в полной модели восстановления его неактивная часть сразу помещается в базу данных и становится доступна для перезаписи. При правильном выборе интервала копирования лог транзакций замирает на одном размере, т.к. не успевает переполняться. И да, откаты имели место...

(19)стоит полная - а почему - так принято. Как откатить не имею понятия

(13)спасибо, попробую

+(22) Даже не представляю как можно обслуживать большие базы с простой моделью.

(22) каким боком к бэкапам он отношение имеет? или вы дописываете только лог транзакций к имеющемуся бэкапу?

Телепатирую версионирование включено ...

(23) зачем тогда фул модель? если каждые 15 минут мы теряем возможность откатить на время до этого момента?

в 8.2.13

есть ошибка: не создаются индексы на определенные типы таблиц
метаданных (реиндексация не помогает).

так что проверте.

возможно 56-42 = недостающие индексы

какие типы таблиц -не помню.

(26) Полное непонимание работы SQL. Читать до просветления.

(28) Кто сказал, что теряем, если все бэкапы лога транзакций есть в наличии? Ночная копия базы плюс N копий логов дают восстановиться куда угодно.

(27)Да! Версионирование включено !
Неужели из за этого?

(30) да, великий, пойду просветляться

(33) Эта ссылка у меня на панели Избранное

http://msdn.microsoft.com/ru-ru/library/ms345583(SQL.90).aspx

(28) SQL Server не умеет ничего откатывать. Вы можете только восстановить БД на какой-то момент времени. В простой модели - только на момент завершения полного или диф. бэкапа. В полной - на абсолютно любой момент времени, если в наличии есть полный/диф бэкап, все бэкапы логов с момента полного/дфи бэкапа и не было всяких "бэкап транзакшен лог виф ноу транкейт" между имющимися бэкапами логов.

(18) Так чо там про 86-й год?

(35) по памяти вспоминал, каюсь, очепятка. имел ввиду вот это вот:

select name,size  from sys.database_files

Test        172544

Test_Log    579072

Backup log Test with Truncate_only

DBCC Shrinkfile(Test_log)

select name,size  from sys.database_files

Test        172544

Test_Log    128