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

Question

Я искал по всему интернету и не могу найти приемлемого решения своей проблемы, мне интересно, есть ли вообще решение без компромисса ...

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

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

Проблема в том, что журнал транзакций непрерывно растет. Из проведенного мною исследования кажется, что я не могу обрезать файл журнала зеркальной базы данных. Так как мне остановить рост файла!?

Основываясь на этой веб-странице , я попробовал это:

USE dbname
GO
CHECKPOINT
GO
BACKUP LOG dbname TO DISK='NULL' WITH NOFORMAT, INIT, NAME = N'dbnameLog Backup', SKIP, NOREWIND, NOUNLOAD
GO
DBCC SHRINKFILE('dbname_Log', 2048)
GO

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

Мой вопрос (TL; DR)

Как мне сжать файл журнала транзакций без отключения зеркала?

Answer 1

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

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

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

Answer 2

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

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

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;

Answer 3

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. Настройка зеркальной защиты.

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

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

exec sp_dboption DBName, 'trunc. войти в систему chkpt. ', true контрольно-пропускной пункт DBCC SHRINKFILE (DBNameFileName, 500); exec sp_dboption DBName, 'trunc. войти в систему chkpt. ', false

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

Answer 7

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

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

Answer 8

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

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

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

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

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

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

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

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

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

Answer 9

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

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
  )

Answer 10

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

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

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

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