Поскольку все файлы логического журнала, расположенные в конце файла, используются
Обновлено: 21.11.2024
Невозможно сжать файл журнала 2 (LOG FILE), так как все логические файлы журнала используются.
Также в сетке результатов я получаю следующее.
DbID FileID CurrentSize MinimumSize UsedPages EstimatedPages
7 2 3111832 2560 3111832 2560
26 февраля 2007 г., 12:04
Вы делаете резервные копии журнала транзакций?
27 февраля 2007 г., 00:04
Здравствуйте, ознакомьтесь с этим сообщением. В нем объясняется, почему не работает файл сжатия DBCC и что для этого нужно сделать
27 февраля 2007 г., 00:26
Какая у вас модель восстановления?
<р>1. Создайте резервную копию журнала транзакций.3 Создайте план обслуживания, чтобы регулярно выполнять резервное копирование.
"Больше зелени, больше кислорода!! Посади дерево сегодня"
14 января 2009 г., 23:06
-- Я делаю следующее в плане обслуживания (SQL2005)
Вставлена задача T-SQL после успешного выполнения заданий резервного копирования и проверки целостности DBCC.
Это происходит через "простые" базы данных recovery_model, резервные копии которых я только что создал, и делает следующее:
DBCC SHRINKFILE (DBLogicalName_Log, TRUNCATEONLY)
Если база данных не находится в ПРОСТОМ режиме восстановления (или имеет какую-либо другую проблему), вы получите следующую ошибку (в интерактивном режиме):
"Невозможно сжать файл журнала 2 (DBLogicalName_Log), так как все логические файлы журнала используются."
Это не предусмотрено планом обслуживания.
В моем случае некоторые файлы журналов не были усечены, но ошибок в журналах/истории не было.
Попробовав те же команды в SSMS в интерактивном режиме, я смог увидеть приведенное выше сообщение и предпринять корректирующие действия.
Если это необходимо и допустимо, измените модель восстановления на простую. В моем случае я был удивлен, обнаружив, что для некоторых баз данных установлено ПОЛНОЕ восстановление, хотя я этого не имел в виду. Это должно быть связано с тем, что исходная установка экземпляра установила для базы данных «model» значение «FULL», поэтому вновь созданные базы данных (даже восстановленные с другого сервера, где они находились в режиме «SIMPLE») стали «FULL».
HTH какой-то другой подающий надежды администратор баз данных. . .
15 января 2009 г., 00:03
Зачем нужно сжимать журнал?
Пожалуйста, прочтите это – Управление журналами транзакций[/url]
Миназ Амин (27.02.2007)
1. Создайте резервную копию журнала транзакций.2. Сократите его.
3. Создайте план обслуживания, чтобы регулярно делать резервную копию.
Создайте план обслуживания для регулярного резервного копирования журнала. Не рекомендуется регулярно сжимать журнал
Гейл Шоу
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: обсуждение производительности БД с периодическими отклонениями в вопросах восстановления
15 января 2009 г., 4:50
GilaMonster (15 января 2009 г.)
Зачем нужно сжимать журнал?Пожалуйста, прочтите это – Управление журналами транзакций[/url]
Создайте план обслуживания для регулярного резервного копирования журнала. Не рекомендуется регулярно сжимать журнал
уже прочитал вашу замечательную статью и многому научился из нее.
Политика нашего сайта не предусматривает восстановление на определенный момент времени.
Мы делаем полное резервное копирование каждую ночь, поэтому аварийное восстановление может "потерять" дневной объем данных.
По этой причине модель восстановления базы данных должна была быть "ПРОСТОЙ".
Видя, что некоторые файлы журналов чрезмерно разрастаются, я решил добавить "сжатие журнала" в план ночного обслуживания, эффективно усекая журнал до нуля (из-за нехватки места). Именно тогда я столкнулся с сообщением об ошибке, которое мы пытаемся разъяснить другим.
Перечитывая вашу статью, я теперь понимаю, что чрезмерный рост журнала мог быть связан с тем, что модель восстановления была непреднамеренно установлена на «ПОЛНЫЙ», хотя мы никогда не делали резервную копию ЖУРНАЛА, чтобы помочь восстановить пространство!
Тем не менее, если базы данных достаточно малы для полного резервного копирования и нам не нужно предлагать восстановление данных на определенный момент времени, журнал может усекаться каждую ночь, поскольку он бесполезен после успешного полного резервного копирования и целостности БД. проверить.
Это не то, что сделал бы каждый, и я внимательно рассмотрю возможность изменения политики для некоторых баз данных. Но что касается сжатия вручную или по расписанию, это будет работать только для баз данных в простом режиме восстановления.
15 января 2009 г., 6:20
Ol'SureHand (15.01.2009)
Тем не менее, если базы данных достаточно малы для полного резервного копирования и нам не нужно предлагать восстановление данных на определенный момент времени, журнал можно усекать каждую ночь, так как это бесполезно после успешного полного резервного копирования БД и проверки целостности.
Если БД находится в режиме простого восстановления, нет необходимости явно усекать журналы. Это происходит через равные промежутки времени. Проще говоря, единственной причиной роста журнала может быть ошибочная репликация или длительные транзакции. Перестроение индекса относится ко второму типу.
Что касается сжатия, сжимайте журнал только в том случае, если вы знаете, что он больше не достигнет такого размера.log растут дорого и замедляют работу БД на время. Кроме того, многократное сжатие/увеличение вызывает фрагментацию на уровне файла, которую трудно исправить.
Гейл Шоу
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: обсуждение производительности БД с периодическими отклонениями в вопросах восстановления
20 декабря 2009 г., 15:40
просто возродить эту тему, а не начинать новую.
У меня похожая проблема: производственная база данных размером 20 ГБ (модель полного восстановления) с размером файла журнала обычно около 2 ГБ. Раз в неделю запускается задание обслуживания и переиндексирует базу данных — в основном, запуская сценарий переиндексации, предоставленный поставщиком (и некоторые другие вещи). Проблема в том, что переиндексация увеличивает размер журнала до более чем 20 ГБ, потребляя большую часть оставшегося свободного места на диске. В настоящее время увеличение размера диска невозможно.
На сегодняшний день я вручную уменьшил размер файла журнала до 2 ГБ на следующий день после запуска задания обслуживания (для этого мне обычно приходится создавать резервную копию журнала один или несколько раз, прежде чем использовать команду DBCC SHRINKFILE для сжатия журнала). Недавно я пытался автоматизировать процесс с помощью запланированного задания, т. е. шаг 1: резервное копирование журнала, шаг 2: сжатие журнала, но до сих пор задание всегда было безуспешным, потому что (согласно сообщению об ошибке) «Невозможно сжать файл журнала 2». (xxx_Log), потому что все логические файлы журналов используются». Я понятия не имею, что будет использовать файл журнала посреди ночи - уж точно никаких других запланированных заданий. База данных является зеркальной, поэтому переход на ПРОСТОЕ восстановление также невозможен
Я понимаю, что сжатие журнала не очень хорошая практика, но это необходимо из-за нехватки места на диске. Есть ли кто-нибудь еще в аналогичном положении? Если да, то как вы решили эту проблему?
Спасибо за любой вклад 🙂
20 декабря 2009 г., 18:03
Согласно MS, вы должны иметь возможность сжимать журнал после резервного копирования журнала транзакций:
"В этой статье описывается, как использовать инструкцию DBCC SHRINKFILE для ручного сжатия файла журнала транзакций в модели полного восстановления в базе данных SQL Server 2005".
но также говорится:
"При попытке сжать файл журнала транзакций, в котором мало свободного места в SQL Server 2005, может потребоваться выполнить дополнительную операцию резервного копирования журнала. Дополнительная операция резервного копирования журнала усекает файл журнала транзакций до меньшего размера."
Внимание: все нижеследующее носит теоретический характер!
Поскольку вы повторно запускали резервные копии журналов вручную, это может быть вашей проблемой. Попробуйте сделать то же самое в коде.
Выполняйте свою работу в хранимой процедуре, вызываемой из плана обслуживания или агента SQL.
В хранимой процедуре есть что-то вроде этого:
BACKUP LOG имя_базы_данных НА имя_устройства
DBCC SHRINKFILE(transactionloglogicalfilename, TRUNCATEONLY)
BACKUP LOG имя_базы_данных НА имя_устройства
GOTO label_for_Goto -- осторожно, не тратьте ночь на повторное резервное копирование . . .
--этот сценарий предлагается в качестве образца и никогда не использовался на практике.
Также проверьте информацию Гейл и Кимберли о том, что происходит с REINDEX . кажется, вы получите подвох, если вы запустите его в неправильном порядке.
Обучение никогда не прекращается для консультанта. В этом блоге я хотел бы поделиться еще одним обучающим и обсудить сообщение: невозможно сжать файл журнала, поскольку используется логический файл журнала, расположенный в конце файла.
Перенос лицензии atol на другой компьютер