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

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

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

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

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

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

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

(6) не верю.

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

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

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

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

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

(11) чем?

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

(14) "Вариант с ребилдом максимально сожмет файл"

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

(14) ответь на (12)

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

(16) http://msdn.microsoft.com/ru-ru/library/ms189493.aspx
NOTRUNCATE

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

Аргумент NOTRUNCATE применим только к файлам данных. На файлы журнала он не влияет.
TRUNCATEONLY

Освобождает все свободное пространство в конце файла операционной системе, но не перемещает страницы внутри файла. Файл данных сокращается только до последнего выделенного экстента.

Аргумент target_size не обрабатывается, если указан аргумент TRUNCATEONLY.

Аргумент TRUNCATEONLY применим только к файлам данных.

(18)СПАСИБО!

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

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

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

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

(22) в цикле

(21) причём тут "кривизна рук"? Это делает сам сиквел "без спроса"

(22) делаешь "план обслуживания" xерез SQL Managment Studio

вот как это делает 1с в 77

 SET NOCOUNT ON
 DECLARE @TableName char(32)
 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

(24) при том что хрен его знает как вы там и что у себя делаете. При балк операциях лог растет очень-очень мало. А учитывая, что модель восстановления будет не балк-логгед, а симпл, то оооочень маленькая вероятность того, что лог вырастет сильно.
http://blogs.msdn.com/b/sqlserverfaq/archive/2011/01/07/using-bulk-logged-recovery-model-for-bulk-operations-will-reduce-the-size-of-transaction-log-backups-myths-and-truths.aspx
Для примера. В фулл-моде 40 мб, в балк-логгед 3 мб. Практически на порядок меньше. Ясен пень, что база там маленькая, но пример показателен. Лог вырастет не больше чем на размер самой большой таблицы в базе (и то - это в самом худшем случае)

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

ЗЫ.. Но теоретиГГам этого не понять :-)

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

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

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

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

(31) длииииииииииииииииииная транзакция

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

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

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

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