Извините, если на вопрос был дан ответ или задан неверно - я разработчик, а не системный администратор или администратор базы данных.
Проблема: mdf-файл SQL Server 2005 Express (размер 370 МБ) не менял дату своего файла в течение двух месяцев (даже после перезагрузки сервера), в то время как ldf-файл вырос до 56 ГБ.
База данных работает на сервере Windows 2003 Webedition Server.
Это важный заказчик, я не хочу ничем рисковать (поэтому я не пробовал опцию «Сжать» в Management Studio, опасаясь потери данных или длительного простоя.
Мы пытаемся настроить новый сервер и пытаемся восстановить последний файл .bak, но он уже некоторое время остается на уровне «Выполняется 90%».
Что может быть сделано? 1. Подождите намного дольше 2. Попробуйте уменьшить исходную базу данных, будет ли веб-сайт запущен 3. Что-нибудь еще
Любая помощь приветствуется.
Спасибо Олаф
Два других ответа полностью верны, но я думаю, что основная причина здесь может не обнаруживаться:
В режиме полного восстановления SQL Server не записывает данные в файл mdf (data)... он только записывает в журнал транзакций.
Единственный способ поместить эти данные в файл данных - сделать резервную копию журнала транзакций. Принято считать, что для активной производственной базы данных в режиме полного восстановления должна быть создана резервная копия журнала транзакций. хотя бы раз в час.
Ранее были опубликованы предложения по временному переключению базы данных в простой режим восстановления. В этом режиме SQL Server не сохраняет данные записи транзакций (отредактированы, чтобы не путать некоторые люди) в журнале транзакций за любой период времени. Если вы сделаете это изменение, SQL Server будет обрабатывать много времени на диске, поскольку он фиксирует транзакции из журнала в файл данных.
Когда это будет завершено, вы по-прежнему иметь файл журнала транзакций объемом 56 ГБ, и ваш файл данных будет больше. (хотя и не намного больше). Файл журнала транзакций не станет меньше, пока вы его не уменьшите.
обычно это то, что вы никогда не должны делать
Но из-за беспорядка, в котором находится эта база данных, вероятно, будет хорошей идеей уменьшить журнал транзакций до половины размера файла данных после описанного выше процесса.
Затем ... переключите базу данных обратно в режим полного резервного копирования и немедленно составить план обслуживания.
Комментатор ниже предполагает, что мой ответ «совершенно неправильный», основываясь на выбранной паре крошечных гнид. Я мог бы выбрать те же гниды с этим комментарием и сказать, что Это тоже "совершенно неправильно".
Но следует отметить: «записи транзакций» данные.
Другие примечания, которые я делаю, ясно показывают, что я очень хорошо знаю, что содержит журнал транзакций - например, мое заявление о том, что, хотя файл данных будет расти после резервного копирования TL, он не вырастет почти так же, как размер TL.
Суть в том, что модель восстановления изменяет то, что SQL Server делает с записями журнала транзакций. В Simple, он сохраняет эти транзакции в данных в файле данных и «быстро» удаляет их из TL. В Full, он оставляет их в покое, пока не будет выполнено резервное копирование TL.
Вы можете возразить, что модель восстановления не имеет ничего общего, в частности, с файлом данных или когда в него записываются данные. Но это все равно, что утверждать, что нажатие на педаль акселератора в машине не заставляет ее двигаться быстрее, потому что, ну; все, что он на самом деле делает, это заставляет двигатель вращаться быстрее.
Возможно, технически правильно, но совершенно бесполезное добавление информации в контексте, о котором мы говорим.
Два варианта
Что вы должны сделать:
Управлять уборщицей - это все равно, что вести машину. Не зная, что ты делаешь ... у тебя проблемы. Как ты делаешь.
- дата файла mdf не меняется
IIRC он изменяется, когда файл закрывается .... и SQL Server закрывает файлы только при его завершении.
- ldf файл становится огромным
Потому что вы не делаете правильные резервные копии? Без ПОЛНЫХ И РЕЗЕРВНЫХ КОПИЙ ЖУРНАЛА - журнал заполняется полностью. это сделано намеренно, я настоятельно рекомендую вам прочитать о резервном копировании баз данных, иначе вы потеряете этого клиента.
Чтобы решить неотложную проблему, измените модель восстановления базы данных на простую, чтобы записи в журнале не сохранялись в течение длительного времени. Затем через день или час уменьшите файл журнала до приемлемого уровня. Это все еще ситуация «вы потеряете клиента», но, по крайней мере, ваш диск не загружается полностью.
Чтобы НЕ потерять клиента в долгосрочной перспективе, убедитесь, что у вас есть понимание восстановления базы данных после сбоя на начальном уровне, и приступайте к созданию резервных копий.