Почему я не могу уменьшить файл журнала транзакций, даже после резервного копирования?
Проблема не в кипарисе, но у вас проблема в "редуксе". У меня нет опыта работы с Redux, поэтому я не могу вам с этим помочь.
Я попробовал ваш код, он отлично работает в моей среде и открывает базовый URL-адрес (в моем случае определяется как « http: // localhost: 80 »)
10 ответов
Спасибо всем за ответы. 1227 Мы наконец нашли проблему. В sys.databases log_reuse_wait_desc был равен «репликация». Очевидно, это что-то означает, что SQL Server ожидает завершения задачи репликации, прежде чем он сможет повторно использовать пространство журнала.
Репликация никогда не использовалась в этой БД, или этот сервер был разыгран однажды время на этой базе данных. Мы очистили неправильное состояние, запустив sp_removedbreplication. После того, как мы запустили это, резервный журнал и dbcc shrinkfile работали просто отлично.
Определенно один для мешочков.
Источники:
You cannot shrink a transaction log smaller than its initially created size.
Переведите БД обратно в полный режим, запустите резервное копирование журнала транзакций (а не просто полное резервное копирование), а затем выполните сжатие.
После сокращения вы можете вернуть БД в простое состояние. mode и его журнал txn останутся неизменными.
Попробуйте использовать целевой размер, который вам нужен для TRUNCATEONLY, в DBCC:
DBCC SHRINKFILE ('Wxlog0', 1)
И проверьте это к статьям:
http://msdn.microsoft.com/en-us/library/ms189493 (SQL.90) .aspx
http://support.microsoft.com/kb/907511
Редактировать:
Вы можете попытаться переместить выделенные страницы в начало файла журнала сначала с помощью
DBCC SHRINKFILE ('Wxlog0', NOTRUNCATE)
, а затем
DBCC SHRINKFILE ('Wxlog0', 1 )
Попробуйте создать еще одну полную резервную копию после резервного копирования журнала с помощью truncate_only (IIRC вы должны сделать это в любом случае, чтобы поддерживать цепочку журналов). В простом режиме восстановления ваш журнал в любом случае не должен сильно расти, так как он эффективно усекается после каждой транзакции. Затем попробуйте указать нужный размер файла журнала, например
-- shrink log file to c. 1 GB
DBCC SHRINKFILE (Wxlog0, 1000);
Параметр TRUNCATEONLY не переставляет страницы в файле журнала, поэтому у вас может быть активная страница в конце файла, что может помешать этому. от сокращения.
Вы также можете использовать DBCC SQLPERF (LOGSPACE), чтобы убедиться, что в файле журнала действительно есть место для освобождения.
Вы пробовали из среды управления SQL Server с графическим интерфейсом. Щелкните правой кнопкой мыши по базе данных, задачам, сжатию, файлам. Выберите тип файла = Журнал.
Я работал на меня неделю назад.
Если вы установите режим восстановления для базы данных в 2005 году (не знаю, что было до 2005 года), он полностью удалит файл журнала, а затем вы сможете вернуть его в режим полного восстановления. перезапустить / восстановить файл журнала. Мы столкнулись с этим с помощью SQL 2005 Express в том смысле, что мы не могли приблизиться к пределу в 4 ГБ с данными, пока не изменили режим восстановления.
Вам это не нужно
DBCC SHRINKFILE ('Wxlog0', 0)
Просто убедитесь, что вы знаете об опасностях: см. Здесь: Не обрезайте свои файлы PDF!
И здесь Журнал резервного копирования с Truncate_Only: как медвежья ловушка
Вы можете столкнуться с этой проблемой, если ваша база данных настроена на автоматическое наращивание журнала, и в результате вы получаете множество виртуальных файлов журнала.
Запустите DBCC LOGINFO ('databasename') и посмотрите на последнюю запись, если это 2, то ваш файл журнала не будет уменьшаться. В отличие от файлов данных, файлы виртуальных журналов нельзя перемещать внутри файла журнала.
Вам потребуется несколько раз запустить BACKUP LOG и DBCC SHRINKFILE, чтобы сжать файл журнала.
Для получения дополнительных бонусных баллов, запустите DBBC LOGINFO между бревна и ширки
В прошлом у меня была такая же проблема. Обычно сокращение и резервное копирование trn должны выполняться несколько раз. В крайних случаях я устанавливаю для БД режим восстановления "Simple", а затем выполняю операцию сокращения файла журнала. Это всегда срабатывает. Однако недавно у меня возникла ситуация, когда это не сработало. Проблема была вызвана долго выполнявшимся запросом, который не завершался, поэтому любые попытки уменьшить файл были бесполезны, пока я не смог убить этот процесс, а затем запустить операцию уменьшения. Речь идет о файле журнала, который вырос до 60 ГБ и теперь уменьшился до 500 МБ.
Помните, что как только вы перейдете из режима восстановления FULL в режим Simple и выполните сжатие, не забудьте вернуть его в режим FULL. Сразу после этого необходимо сделать ПОЛНОЕ резервное копирование БД.