Сокращение журнала транзакций зеркальной базы данных SQL Server 2005

Ну, технически можно уменьшить зеркальный журнал. Проблема заключается в резервном копировании журнала с помощью truncate_only. Зеркалирование не принимает это. Итак, один из способов — выполнить резервное копирование журнала на диск:

use [DATABASE_NAME]
checkpoint
BACKUP LOG [DATABASE_NAME] TO DISK =  'C:\LOG_BACKUPS\DATABASE_NAME'
dbcc shrinkfile(DATABASE_NAME_Log,1)

Это часть нашего текущего плана обслуживания, и он работает без проблем уже около 2 лет.

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

Чтобы сжать наши файлы, вы можете попробовать следующий скрипт:

exec sp_dboption ИмяБД, 'trunc. log on chkpt.', истинная контрольная точка DBCC SHRINKFILE (DBNameFileName, 500); exec sp_dboption ИмяБД, 'trunc. войти в chkpt.', false

Надеюсь это поможет.

Я подумал, что должен на самом деле ответить на этот вопрос, потому что об этом забыли.

Оказывается, вы не можете уменьшить t-log, если база данных зеркалируется, если только вы не деактивируете зеркало. Если я ошибаюсь, поправьте меня, но я не нашел работающего решения!

Доставка журналов подходит, если у вас всего два сервера. Зеркальное отображение почти бессмысленно без сервера-свидетеля, потому что единственный способ аварийного переключения — от основного сервера... в некотором роде теряет смысл наличие зеркала, если вы не можете выполнить аварийное переключение при сбое основного сервера.

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

1. Отключите зеркального партнера с помощью .. ALTER [DatabaseName] SET PARTNER OFF
2. Сделать резервную копию журнала транзакций на принципале..BACKUP LOG [DatabaseName] TO DISK='Drive:\DatabaseName_log_datetime.trn'
3. Скопируйте этот DatabaseName_log_datetime.trn в любое место на зеркальном сервере.
4. Восстановите этот журнал транзакций с параметром NoRecovery в зеркальной базе данных. RESTORE LOG [DatabaseName] FROM DISK ='Drive:\DatabaseName_log_datetime.trn'
5. Уменьшить файл журнала на основном и зеркальном серверах.
6. Снова сделайте резервную копию журнала транзакций на основном сервере... и восстановите этот журнал транзакций с параметром "Без восстановления"... в зеркальной базе данных на зеркальном сервере.
7. Настройте безопасность зеркалирования.

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

USE [DATABASE_NAME];
BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_FULL.bak' WITH FORMAT;
CHECKPOINT;
WAITFOR DELAY '00:00:02';
BACKUP LOG [DATABASE_NAME] TO DISK = 'E:\Backup\DATABASE_NAME_TL.trn';
WAITFOR DELAY '00:00:02';
DBCC SHRINKFILE('DATABASE_NAME_log', 500);

Использование OSQL может запускать вышеуказанные команды SQL в пакете DOS, ЗАДЕРЖКА ОЖИДАНИЯ является обязательной, если выполняется в пакетном режиме, например.

C:\Program Files\Microsoft SQL Server\100\Tools\Binn\osql.exe -E -S "DATABASE_SERVER" -Q "USE [DATABASE_NAME]; BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_FULL.bak' WITH FORMAT;"

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

BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_DIFF.bak' WITH DIFFERENTIAL;

единственный способ: 1) остановить зеркалирование 2) сжать файлы на основном 3) полное резервное копирование основного + jrnl транзакции 4) остановить зеркальный сервер, удалить mdf и ldf из mirrorDatabase 5) запустить зеркало и удалить базу данных mirrorDatabase 6) восстановить без резервных копий для восстановления 3) на mirroServer 7) переустановить зеркалирование Ouf !

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

Тогда все, что вам нужно сделать, это регулярно удалять резервные копии файлов. Например, вы можете сделать это:

USE your_database
GO
BACKUP LOG your_database TO DISK = 'x:\your_backup_filepath\your_database.tlog'
GO

Делайте это в нерабочее время, если можете.

Я не знаю, почему это работает, но это действительно работает. Я запускаю это как блок в окне запроса. Используйте по своему усмотрению. Конечно, было бы неплохо, если бы Microsoft прокомментировал.

use my_database
dbcc shrinkfile ( my_database_log, 1000 )
use my_database
dbcc shrinkfile ( my_database_log, 1000 )
alter database my_database
  modify file ( 
    name = my_database_log, 
    size = 1000MB
  )

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

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

Если вы хотите сделать сжатие, которое сжимает только файл транзакции, вы можете использовать следующий T-SQL:

USE [your_db_name]
GO
DBCC SHRINKFILE (N'your_db_name_logfile' , 0, TRUNCATEONLY)
GO

Затем вы просто используете этот фрагмент для каждой базы данных и запускаете его сразу после запуска резервного копирования.

Это должно уменьшить размер файла журнала на основном сервере и, следовательно, на вторичном/зеркальном сервере.

Надеюсь, это поможет.

Кстати. Если вы дошли до того, что на диске не осталось места для файлов журналов, единственный вариант — вывести его из зеркального режима, перевести базу данных в простой режим восстановления, сжать файл журнала, установить для него полный снова в режим восстановления и снова настройте зеркало (используя резервные копии файла журнала базы данных og для восстановления на зеркальном сервере).

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

Можно сжать файл транзакции для базы данных с зеркалом, необходимо выполнить резервное копирование, поскольку есть активы. Виртуальный файл журнала: http://www.xoowiki.com/Article/SQL-Server/tronquer-journal-de-log-sur-base-en-miroir-499.aspx

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

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