Как сделать шринк Data файла в sql 2008 #574784

не делался шринк лога. Перевел из Full в Simple модель. Сделал шринк. Лог образался, а data - нет. Кто в курсе - как обрезать data файл?

правой кнопкой по базе и сжать датабазу.

бекап-потом шринк-наслаждайся

а кто сказал что он обрежется...

Если там есть что резать, то так же как и лог

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

пробовал! не помогло! Пишет свободно 45%

не верю.

"сделай rebuild index для всех таблиц, потом шринкуй" Вредный совет. Если только для сжатия.

во я прогнал... последовательно: DBCC SHRINKFILE('имя файла данных', NOTRUNCATE, 0) DBCC SHRINKFILE('имя файла данных', TRUNCATEONLY, 0)

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

сжатие после ребилда - вредный совет.

а перевод в симпл - это симпл модель имеется ввиду? И почему в написано сначала NOTRUNCATE, а потом TRUNCATEONLY почему такой порядок

чем?

шринк сам по себе вредный. Вариант с ребилдом максимально сожмет файл. Второй вариант будет немного быстрее и немного менее "качественным"

"Вариант с ребилдом максимально сожмет файл" Ребилд никогда не сжимает это раз, во-вторых под ребилд нужно место и поэтому часто разрастается лог-файл

ответь на

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

NOTRUNCATE Перемещает распределенные страницы из конца файла на место нераспределенных страниц в начале файла с параметром target_percent или без него. Свободное место в конце файла операционной системе не возвращается, и физический размер файла не изменяется. Следовательно, если указан аргумент NOTRUNCATE, файл сжимается незначительно. Аргумент NOTRUNCATE применим только к файлам данных. На файлы журнала он не влияет. TRUNCATEONLY Освобождает все свободное пространство в конце файла операционной системе, но не перемещает страницы внутри файла. Файл данных сокращается только до последнего выделенного экстента. Аргумент target_size не обрабатывается, если указан аргумент TRUNCATEONLY. Аргумент TRUNCATEONLY применим только к файлам данных.

СПАСИБО!

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

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

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

в цикле

причём тут "кривизна рук"? Это делает сам сиквел "без спроса" делаешь "план обслуживания" xерез SQL Managment Studio

вот как это делает 1с в 77  SET NOCOUNT ON  DECLARE @TableName char  DECLARE SysCur CURSOR FOR SELECT name FROM sysobjects WHERE type='U'  OPEN SysCur  FETCH NEXT FROM SysCur INTO @TableName  WHILE @@FETCH_STATUS=0 BEGIN      DBCC DBREINDEX(@TableName)      FETCH NEXT FROM SysCur INTO @TableName  END  CLOSE SysCur  DEALLOCATE SysCur

при том что хрен его знает как вы там и что у себя делаете. При балк операциях лог растет очень-очень мало. А учитывая, что модель восстановления будет не балк-логгед, а симпл, то оооочень маленькая вероятность того, что лог вырастет сильно. Для примера. В фулл-моде 40 мб, в балк-логгед 3 мб. Практически на порядок меньше. Ясен пень, что база там маленькая, но пример показателен. Лог вырастет не больше чем на размер самой большой таблицы в базе (и то - это в самом худшем случае)

я говорю про базы SQL работающие под 1Совскими базами.. И при установленном симпл-режиме при размерах самих баз 20-30 Гб - лог-файлу улетают по 50Гб влёгкую ЗЫ.. Но теоретиГГам этого не понять :-)

в симпл-моде лог 50 гб? омфг, читайте . Только без слова "вероятно".

"для базы 30 гиг в симпл-моде лог" и далее по тексту

причем тут кривизна рук... все зависит от выполнения checkpoint-ов на базе...

и при каких условиях чекпойнты могут не выполняться своевременно? у пользователя есть только один параметр для модификации - recovery interval, который может быть коряво выстроен. Остальные причины вызова чекпойнта не могут быть перепределены.

длииииииииииииииииииная транзакция

а, ну если в длиииииииииинных транзакциях виноваты не кривые руки, то да, конечно, все дело в чекпойнтах

еще вариант - есть репликация, идет накопление данных

но это уже не к чекпоинтам, это вообще вариант - "почему растет база".

зачем репликация? Даже выполнение реструктуризации базы средствами 1С уже вызывает дикий рост лог-файла даже в симпл-моде