SQL уменьшение размера LOG? #441313

На серваке 2005 стоит УПП, которая время от времени разрастается до неприличных размеров. Средствами интернет поиска было обнаружено, что помимо 1С:выгрузить/загрузить есть еще и SQL-решения проблемы, такие как: dbcc shrinkdatabase, backup Trunsactonly (не дословно). Была создана тестовая база, чтобы попробовать применить сие методы SQL. Однако в одном из описаний к данным командам было обнаружено: "необходимо запустить сервер SQL Server в однопользовательском режиме". Вопросы: - безопасно ли для основной базы методом тыка изучать sql команды на тестовой базе? - требует ли применение данных команд "остановки" SQL-сервера, отсоединение пользователей от основной базы, если они будут применяться к тестовой? - что лучше почитать, прежде чем на практике что-либо пробовать?

Я вот думаю - неужели MS настолько плохо документировала SQL Server, что люди не устают задавать вопросы? :/ 1. Думаю ты сам знаешь, что небезопасно. Нужно точно знать, что делаешь, прежде, чем делать. 2. Нет, не требует. Требует только внимательности - внимательно всегда смотри в оба, над какой базой ты производишь действия. 3. Ссылку выше + MSDN + sql.ru

сдуть ЛДФ просто, как два пальца об асфальт - надо перевести БД в режим simple, запустить шринк файла ЛДФ, потом вернуть в full (всё это из студии  мышью делается). Ни кого выгонять и останавливать при этом не надо. выгрудить/загрузить ЛДФ только увеличит.

Можно и не менять модель восстановления в данном случае.

Описание команд MS а также другие "описания" - есть. Вопрос, в том, что если уже есть реальная база, в которой работает предприятие, как понять, что можно делать on-line, что требует регламетных перерывов, этого в описании я пока не нашел, вот и спрашиваю.

Сделай Full Backup, это можно делать онлайн, и журнал после этого сдуется на ура...

ты имеешь в виду Full Backup? о_0

Для шринка необязательно менять модель восстановления. Для тебя это неожиданность?

а, ну да... а ты попробуй сравнить скорость, с которой сделается и, с которой шринканется файл.

В свойствах/файлы есть параметры: размер файл, шаг роста - их можно менять?

Можно, но с умом, пожалуйста :)

Не учи ученого, а? :)

установка simple модели производится простым выбором в графическом интерфейсе? И после этого ЛОГ сам начнет уменьшаться или в него просто не будет писаться лишнего, а чтобы уменьшить размер нужно его бэкапить?

при модели FULL шринк лога практически не меняет его размер. Для тебя это неожиданность?

не льсти себе, а? :)

после установки режима simple лог просто расти перестанет. Для того, чтобы он уменьшился, его нужно шринкануть, либо бэкап лога сделать. Но установка режима simple - это должен быть обдуманный шаг. Почитай про эти режимы.

менять можно, но зачем?

шаг поменять, чтобы не так быстро рос, например с 10% на 5%? А максимальный размер поставить с 2 Тэрабайт до 50 Гг к примеру? или глупость?

не поможет. просто бэкапь или шринкуй его раз в неделю и не биби мозги :)

Понятно. Спасибо!

Чушь. BACKUP LOG WITH TRUNCATE ONLY - шринканет лог до первоначального(заданного при создании базы) размера. DBCC SHRINKFILE c указанием размера - урезает лог до этого размера. Попробуй сам, если не веришь.

чайнег :)  BACKUP LOG WITH TRUNCATE_ONLY не шринкает лог, если база в режиме FULL (только что проверил вот этими самыми руками). А вот DBCC SHRINKFILE шринкает как за здасте. Не знал, спасибо, что носом ткнул :)

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

И чайник тут только один, и это явно не я. Для шринка не требуется переключать модель восстановления.

я ж тебе говорю, что проверил - initial size у ЛДФа был 1Мб, при этом BACKUP LOG WITH TRUNCATE_ONLY уменьшил его размер с 31Мб до 30.5 А вот DBCC SHRINKFILE дал именно ожидаемый результат.

>BACKUP LOG WITH TRUNCATE_ONLY не шринкает лог, если база в режиме FULL >BACKUP LOG WITH TRUNCATE_ONLY уменьшил его размер с 31Мб до 30.5 Тебе не кажется, что ты сам себе противоречишь? :)

не кажется. На точно такой же базе, но другой эта процедура уменьшила ЛДФ с 209Гб до 209Гб. В режиме FULL эта трахома только высвобождает неиспользуемое место (а это - жмурику припарка), а надо-то почистить.

+ размер о и после указа верно и да, размер одинаковый

BACKUP LOG WITH TRUNCATE_ONLY помечает "виртуальные лог-файлы" с неактивными транзакциями как "свободные", т.е. фактически место в файле появляется, но операционной системе место не выделяется. DBCC SHRINKFILE с параметром TRUNCAteonly как раз и отдаст место операционке. Просто DBCC SHRINKFILE, при модели восстановления FULL и отсутствии бэкапов журнала (которые в т.ч. и отмечают "забэкапленные" части журнала как свободные) ничего сделать не сможет.

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