Поскольку все файлы логического журнала, расположенные в конце файла, используются

Обновлено: 04.07.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 растут дорого и замедляют работу БД на время. Кроме того, многократное сжатие/увеличение вызывает фрагментацию на уровне файла, которую трудно исправить.

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 . кажется, вы получите подвох, если вы запустите его в неправильном порядке.

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

SQL SERVER — ограничение ENABLE_PARALLEL_PLAN_PREFERENCE, подсказка

SQL SERVER — 2005 — Получить имя поля и тип таблицы базы данных

Оставить ответ Отменить ответ

Пинал Дэйв — эксперт по настройке производительности SQL Server и независимый консультант с более чем 17-летним практическим опытом. Он имеет степень магистра наук и многочисленные сертификаты по базам данных.

Нупур Дэйв – независимый консультант и любитель социальных сетей. В основном она занимается базой данных, помогая клиентам создавать краткосрочные и долгосрочные многоканальные кампании, чтобы привлечь потенциальных клиентов для своей воронки продаж.

Эксклюзивный информационный бюллетень

Ваш SQL Server работает медленно, и вы хотите ускорить его работу, не передавая учетные данные сервера? В рамках моей Комплексной проверки работоспособности базы данных мы можем работать вместе удаленно и устранять самые серьезные проблемы с производительностью менее чем за 4 часа.

Как только вы узнаете мои деловые секреты, вы решите большинство проблем в будущем.

Вы когда-нибудь открывали какую-либо презентацию PowerPoint, когда сталкивались с чрезвычайными ситуациями, связанными с настройкой производительности SQL Server? Практический семинар по настройке производительности SQL Server — мой САМЫЙ популярный тренинг без презентаций PowerPoint и 100% практических демонстраций.

По сути, я делюсь своими бизнес-секретами, чтобы оптимизировать производительность SQL Server.

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

Во-первых, я просто зашел в SSMS, свойства БД, файлы и отредактировал значение начального размера (МБ) на 10. Это уменьшило файл журнала до 62 ГБ (не совсем те 10 МБ, которые я ввел). Итак, я подключил SQL Profiler, увидел, что вызывается DBCC SHRINKFILE. Затем я ввел эту команду в редактор запросов, и вот результат.

И результат был таким:

Затем я провел небольшое исследование и нашел следующее:

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

Итак, я решил сделать резервную копию файла журнала, а затем выполнить команду DBCC SHRINKFILE (и я изменил новый размер файла журнала на 12800, так как это был минимальный размер, определенный в выходных данных предыдущей команды DBCC SHRINKFILE)< /p>

Результат был таким же, как и при первом обходе. Я могу уменьшить размер файла журнала только до 62 ГБ.

Я не уверен, что делаю неправильно и что мне следует попробовать дальше.

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

Моя проблема заключалась в установке ПРИОСТАНОВЛЕННОЙ РЕПЛИКАЦИИ/ЗЕРКАЛЬНОГО ЗЕРКАЛЬНОГО ЗЕРКАЛЬНОГО ЗЕРКАЛЬНОГО ЗЕРКАЛЬНОГО ОБЕСПЕЧЕНИЯ. Похоже, sql не будет сжимать tlog-файлы, если считает, что они потребуются для репликации. Вероятно, это не будет проблемой для многих людей, но может помочь некоторым.

9 ответов 9

Хорошо, вот решение для уменьшения физического размера файла транзакции, но без изменения режима восстановления на простой.

В базе данных найдите file_id файла журнала, используя следующий запрос.

В моем случае файл журнала имеет идентификатор file_id 2. Теперь мы хотим найти используемые виртуальные журналы и сделать это с помощью следующей команды.

Здесь вы можете увидеть, используются ли какие-либо виртуальные журналы, увидев, имеет ли статус 2 (используется) или 0 (бесплатно). При сжатии файлов пустые виртуальные журналы физически удаляются, начиная с конца файла, пока он не достигнет первого использованного состояния. Вот почему сжатие файла журнала транзакций иногда уменьшает его часть, но не удаляет все свободные виртуальные журналы.

Если вы заметили статус 2, который появляется после 0, это означает, что сжатие блокирует полное сжатие файла. Чтобы обойти это, сделайте еще одну резервную копию журнала транзакций и немедленно запустите эти команды, указав идентификатор файла, найденный выше, и размер, до которого вы хотите уменьшить файл журнала.

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

При попытке сжать журнал транзакций мы получаем следующее сообщение.

Сообщение 155, уровень 15, состояние 1, строка 2
'TRUNCATE_ONLY' не является распознаваемым параметром BACKUP.
Невозможно сжать файл журнала 2 (mdb_log), поскольку используется логический файл журнала, расположенный в конце файла.

Я нашел в Интернете, что решение состоит в том, чтобы изменить режим восстановления на ПРОСТОЙ, сжать файлы журналов, а затем перейти на ПОЛНЫЙ режим восстановления.

Будет ли это работать и можно ли изменить режим восстановления на простой с базой данных в сети?

Угрозы кибербезопасности и потребность в надежном резервном копировании

2022-03-29 18:00:00 UTC Вебинар Вебинар: Spanning — угрозы кибербезопасности и потребность в надежном резервном копировании Сведения о событии Просмотреть все события

Переключаться на простую модель восстановления для уменьшения размера файла — очень плохой совет. Это нарушает цепочку журналов и влияет на возможность использования этих файлов для восстановления базы данных.

Чтобы сжать файл журнала, необходимо сначала выполнить 2 последовательных резервных копии журнала. Выполнение их подряд, как это, приводит к тому, что текущий активный VLF циклически переходит к началу файла журнала. затем вы можете сжать файл журнала.

Я должен добавить, что регулярное сжатие файла журнала — очень плохая вещь. Он просто снова вырастет (что очень влияет на производительность) и приведет к большому количеству виртуальных файлов журнала (VLF). Высокий уровень VLF вызывает проблемы с производительностью любого процесса, которому необходимо сканировать файл журнала, например выполнение восстановления при запуске или репликация транзакций.

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

Сжатие файлов базы данных, даже в экстренных случаях, очень плохо сказывается на производительности. Избегайте этого, если можете. Процесс сжатия файла данных очень тупой. Он берет блоки с конца файла и перемещается настолько далеко к началу файла, насколько это возможно. Это приводит к чрезвычайно высокой фрагментации, из-за чего сканирование и большие поиски занимают намного больше времени. Исправление фрагментации требует перестроения индексов, что, в свою очередь, увеличивает размер файлов.

Нет, резервное копирование не увеличивает размер базы данных. Он обновляет некоторые существующие страницы в базе данных, но никогда не добавляет новые страницы. Это может косвенно привести к увеличению файла журнала, если для завершения резервного копирования требуется очень много времени. Пока выполняется полное резервное копирование, файл журнала нельзя очистить для повторного использования. Это означает, что даже если резервные копии журналов создаются во время полного резервного копирования, резервные копии журналов в основном являются резервными копиями «только для копирования». Если файл журнала заполняется во время полного резервного копирования, он должен увеличить размер файла журнала.

Читайте также: