Как обрезать лог файл в SQL базе #435233

Торговля на SQL: база весит 6 Гб, а лог 11,5 Гб. Как этот лог обрезать? Shrink не помогает? Что будет, если просто убить ldf? Будет ругаться или просто создаст новый пустой?

шринк помогает...

Shrink не помогает...пробовал

шринк датабэйс помогает...

Ну говорю же - пробовал...файл остается такого же размера

а ругается хоть?

Так что, поможет ли убийство ldf файла?

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

мне помогала чистка журнала регистраций

Т.е. сначала журнал грохнуть, а потом шринк?

Предлагаю сначала грохнуть сисадмина... Ибо настолько тупы вопросы в тырнете плодятся пачаками..

Резервное копирование базы данных средствами SQL сервера делается?

Для дураков: Recovery mode установите в Simple + ежедневный full backup.

Ну зачем же сразу для дураков? Пусть будет как для нормальных людей Recovery mode - Full. Если будут делать регулярное резервное копирование базы данных и файла транзакций, то все будет в порядке.

Shrink file с явным указанием размера помогает всегда. А вообще - , если париться не хочется.

Это? Уменьшение размера журнала транзакций Microsoft SQL Server Проблема Рост файла журнала транзакций. С помощью команды DBCC SHRINKFILE не удается уменьшить размер файла журнала транзакций до нужного размера . Решение Для решения описанной проблемы необходимо предварительно удалить неактивные записи журнала транзакций с помощью команды BACKUP LOG, а затем уже с помощью команды DBCC SHRINKFILE уменьшить размер файла журнала транзакций. Последовательность команд, которую нужно исполнить в Query Analyzer, выглядит следующим образом: BACKUP LOG Имя_Базы_Данных WITH TRUNCATE_ONLY go DBCC SHRINKFILE(Имя_Файла_Журнала_Транзакций) go Более подробное описание и рекомендации по использованию этих команд можно найти в документации по Microsoft SQL Server.

Судя по тому, что у вас файл не уменьшается - модель восстановления full и бэкапы журнала транзакций вы не делаете.. Меняйте на simple. Для очистки журнала транзакций используйте команды: backup log your_database with truncate_only Логические имя файла можете узнать с помощью use [your_database_name] select * from sys.database_files (правда не знаю есть ли в 2000-м такое представление)

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

Сделай сначала бекап LDF, а потом он уже шринканется

SQL.ru FAQ: Вопрос N1

Удаление работает. Отключи базу от сервака, удали журнал транзакций, подключи. Будет создан новый пустой журнал транзакций.

с дуба рухнул? --- дуб с маленькой буквы - типа дерево такое )))

Ответил на поставленный вопрос. Ещё раз скажу: журнал транзакций можно удалить, при присоединении будет создан новый. В чём проблема, если в данном случае человеку текущий ldf человеку не нужен?

типа и данные не пропадуть? или плевать? ))

Данные в файле данных. Не пропадут.

А при отсоединении базы все незавершенные транзакции будут автоматически "откачены" назад?

хм, я думал в мдф начальные данные + в лдф все изменения и пока фулл бэкап не сделаешь данные в мдф не переносятся при модели фулл --- и продолжаю так думать )))

8)

Думай дальше. Нет, ни в коем случае. После того, как транзакция зафиксирована, она назад не откатится.

Неправильно думаешь

Я немного не то имел в виду. Попробую переформулировать. Данные записываются в mdf файл по чекпойнту, либо лэйзи райтером. При отсоединении БД - данные уже измененные в памяти будут записаны в файл?

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

и зря Вы так продолжаете думать) В жунале транзакций содержится информация о транзакциях. Активная часть - не зафикисрованные транзакции. Модель восстановления simple не используется для восстановления на определенный момент времени, т.е. данные о зафиксированных транзакциях, условно говоря, удаляются. В модели восстановления full/bulk-logged, информация о зафиксированных транзакциях перестает быть нужной после создания бэкапа журнала транзакций. Еще раз. Я записал документ и корректно завершил работу с системой. Все изменения были произведены в памяти. Данные будут записаны только по чекпойнту, либо lazy writer'ом. Вы уверены, что при отсоединении БД, будет вызван чекпойнт или запустится lazy writer? "При перезапуске, служба SQL Server использует журнал транзакций для обнаружения завершенных транзакций, которые внесли изменения в данные, но не были записаны на диск и незавершенных транзакций" ( - пруфлинк, четвертый абзац раздела "How does SQL use the log?")

Просто метод аттача без журнала какой-то "варварский" :). Я понимаю его необходимость при переносе базы и повреждении ldf-файла, но для очистки журнала...

Чтобы устранить все сомнения, лучше, конечно же, сначала попробовать на тестовой базе.

>журнал транзакций можно удалить, при присоединении будет создан новый. Ну не совсем так, определённые шаманские действия все же нужно произвести: Данный метод работает только для версии SQL2000 1. Создаем новую базу с таким же именем и такимиже по именам и расположению .mdf и .ldf файлами 2. Останавливаем сервер, подменяем файл .mdf 3. Стартуем сервер, не обращаем внимания на статус базы 4. Из QA выполняем скрипт Use master go sp_configure 'allow updates', 1 reconfigure with override go 4. Там же выполняем select status from sysdatabases where name = '<db_name>' и запоминаем/записываем значение на случай неудачи ребилда лога 5.Там же выполняем update sysdatabases set status= 32768 where name = '<db_name>' 6. Перезапускаем SQL Server 7. В принципе база должна быть видна (в emergency mode). Можно, например, заскриптовать все объекты 8. Из QA выполняем DBCC REBUILD_LOG('<db_name>', '<имя нового лога с указанием полного пути>') SQL Server скажет - Warning: The log for database '<db_name>' has been rebuilt. 9. Если все нормально, то там же выполняем Use master go sp_dboption '<db_name>', 'single user', 'true' go 9a. Если Вам не удалось перевести базу в single user mode, то для проверки целостности данных можно попробовать dbo only mode sp_dboption '<db_name>', 'dbo use only', 'true' 10. Если все в порядке, то sp_dboption '<db_name>', 'single user', 'false' go Use master go sp_configure 'allow updates', 0 go

Линуксоид? Любишь в гамаке в ластах в противогазе и стоя? Нормальные люди для этого исползуют sp_attach_single_file_db...

Ты FAQ читал? У меня как правило ldf терялись не спроста, или диск наворачивался или еще что. А в этом случае база суспект и никакой sp_attach_single_file_db не поможет. Вывалит ошибку. А самому ldf удалять, чтобы лог уменьшить это конечно придумать надо.

выгрузить загрузить, log убьется.

Слишком много времени займет... А можно ли из QA принудительно записать все накопленные изменения (транзакции), а потом грохнуть ldf?

они сами записываются по коммиту.

Вы , пробовали? Операция быстрая. Что видите в результате?

Пригласите специалиста.

Достаточно пригластить человека, умеющего читать техническую литературу на русском языке...