Мне нужно очистить файл LDF перед отправкой коллеге. Как заставить SQL Server усекать журнал?





В студии менеджмента:
Properties, затем Options.Tasks -> Shrink -> FilesВ качестве альтернативы SQL для этого:
ALTER DATABASE mydatabase SET RECOVERY SIMPLE
DBCC SHRINKFILE (mydatabase_Log, 1)
Ссылка: http://msdn.microsoft.com/en-us/library/ms189493.aspx
Что вы делаете в живой среде? Сначала сделайте резервную копию журналов?
Я не администратор баз данных, но да, я считаю, что резервное копирование журнала приведет к его усечению: technet.microsoft.com/en-us/library/ms179478.aspx
@JohnBubriski Если вы используете не простую модель восстановления, журналы являются основой для восстановления данных или отката транзакций. Таким образом, в производственной среде вам необходимо сначала сделать резервную копию этих журналов, прежде чем вы сможете сжать файлы журналов. В противном случае реальной возможности восстановления не было бы. К сожалению, если вы находитесь в ситуации восстановления, вам придется повторно загрузить все резервные копии журнала транзакций, чтобы полностью восстановить БД. Веселые времена, конечно! :)
в SQL Server 2012 мне пришлось use mydatabase перед запуском dbcc shrinkfile
Примечание. Файл журнала обычно называется DatabaseName_log, но может отличаться. Вы можете найти имя файла для текущей базы данных с помощью SELECT name FROM sys.master_files WHERE database_id = db_id() AND type = 1
Также 1 в команде сжатия относится к предполагаемому размеру журнала после сжатия. По умолчанию используется исходный размер файла журнала, поэтому некоторые ответы на этот вопрос имеют значение, а некоторые - нет. docs.microsoft.com/en-us/sql/t-sql/database-console-commands /…
Я видел, что скрипт работает быстрее, чем параметр «Задачи -> Сжать -> Файлы». Размер БД в основном составляет 200+ ГБ. Если я использую графический интерфейс, каждый раз это занимает более 15 минут. Но скрипту на это требуется не более 10 секунд. Есть идеи, почему графический интерфейс требует времени?
имя журнала резервного копирования с truncate_only, за которым следует команда dbcc shrinkfile
если я хорошо помню ... в анализаторе запросов или аналоге:
BACKUP LOG databasename WITH TRUNCATE_ONLY
DBCC SHRINKFILE ( databasename_Log, 1)
Это определенно лучше, чем установка модели восстановления базы данных на ПРОСТОЙ (как в ответе Blorgbeard), потому что, если ваша модель восстановления ПОЛНАЯ, у вас есть такая установка по какой-то причине.
truncate_only устарел в SQL Server 2008, поэтому вам нужно переключить db на простое восстановление msdn.microsoft.com/en-us/library/ms143729(SQL.90).aspx
Для SQL Server 2012 это работает, но без WITH TRUNCATE_ONLY.
Добавляя к тому, что сказал net_prog, для SQL Server 2012 я заменил первую строку на BACKUP LOG DatabaseNameHere TO DISK='NUL:'.
TRUNCATE_ONLY не является опцией BACKUP. (SQL Server 2019 RC1)
Для SQL Server 2008 команда:
ALTER DATABASE ExampleDB SET RECOVERY SIMPLE
DBCC SHRINKFILE('ExampleDB_log', 0, TRUNCATEONLY)
ALTER DATABASE ExampleDB SET RECOVERY FULL
Это уменьшило размер моего файла журнала с 14 ГБ до 1 МБ.
Поскольку вопрос о том, какая версия является неоднозначным, и принятый ответ неприменим к SQL Server 2008, этот ответ по-прежнему действителен независимо от возраста.
Спасибо, это помогло мне уменьшить большой файл журнала, который не реагировал с DBCC SHRINKFILE
Не забудьте изменить модель восстановления обратно на ПОЛНУЮ, когда закончите!
Вы должны сделать резервную копию перед тем, как сделать это (или любой другой вариант усечения). Если вы сделаете полную резервную копию и установите флажок «Копировать только резервную копию» в SSMS, тогда вам больше не понадобится журнал. (Это всего лишь резервное копирование на определенный момент времени).
Для SQL 2008 вы можете сделать резервную копию журнала на устройстве nul:
BACKUP LOG [databaseName]
TO DISK = 'nul:' WITH STATS = 10
Затем используйте DBCC SHRINKFILE для усечения файла журнала.
Это единственное, что сработало в моей ситуации ... У меня возникла ошибка при попытке использовать резервную копию с TRUNCATE_ONLY
Примечание: это может занять некоторое время, даже на SSD (он должен прочитать журнал, чтобы иметь возможность отменить его). Для файла журнала размером 30 ГБ на виртуальной машине Azure со средней мощностью требуется 10 минут, чтобы выполнить 40%. Не забудьте переключиться на дубль «Сообщения» в SSMS, чтобы увидеть обработанный процент.
Другой вариант - отключить базу данных через Management Studio. Затем просто удалите файл журнала или переименуйте его и удалите позже.
Вернувшись в Management Studio, снова подключите базу данных. В окне прикрепления удалите файл журнала из списка файлов.
БД подключается и создает новый пустой файл журнала. Убедившись, что все в порядке, вы можете удалить переименованный файл журнала.
Вероятно, вам не следует использовать это для производственных баз данных.
Никогда не делай этого! В журнале могут быть данные, которые еще не зафиксированы в файле данных. Вы потеряете такие данные.
Если в своем ответе вы предупреждаете не пробовать его в продакшене, публиковать его вообще не стоит.
Я не согласен с отрицательными голосами - это вариант. Администраторам просто нужно понять их сценарий. Например - незафиксированных данных не будет, если нет открытых транзакций.
Это единственное решение, которое у меня сработало. Мой диск был заполнен, я не мог выполнять резервное копирование или сжатие, и, похоже, ничего не работало. Спасибо!
Я согласен; это не лучшая практика, но это ценный инструмент, если у вас нет других вариантов, таких как сценарий Брайана.
Поскольку ответ для меня был похоронен в комментариях. Для SQL Server 2012 и более поздних версий вы можете использовать следующее:
BACKUP LOG Database TO DISK='NUL:'
DBCC SHRINKFILE (Database_Log, 1)
Ваш ответ только что спас мне день! Я не знал о параметре «Щелкните правой кнопкой мыши - Задачи -> Сжать». Спасибо!