Сжатие журнала транзакций зеркальной базы данных SQL Server 2005
https://stackoverflow.com/questions/1033158
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я искал по всему Интернету и не могу найти приемлемого решения своей проблемы, мне интересно, есть ли вообще решение без компромисса...
Я не администратор базы данных, но я команда из одного человека, работающая над огромным веб-сайтом без дополнительного финансирования дополнительных сотрудников, так что я делаю все, что в моих силах.
Наш запасной план - отстой, и мне очень трудно его улучшить.В настоящее время существует два сервера, на которых работает 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)
Как я могу уменьшить размер файла журнала транзакций, не отключая зеркало?
Решение 3
Я подумал, что на самом деле должен ответить на это видение, поскольку о нем забыли.
Оказывается, вы не можете сжать t-log, если база данных зеркалирована, если вы не деактивируете зеркало. Если я ошибаюсь, исправьте меня, но я не нашел подходящего решения!
Доставка журналов - это путь, если у вас есть только два сервера. Зеркальное отражение почти бессмысленно без следящего сервера, потому что единственный способ восстановления после сбоя - от принципала ... своего рода побеждает цель иметь зеркало, если вы не можете переключаться при сбое, когда происходит сбой принципала.
Если кто-то захочет поделиться дополнительной информацией или предложениями по этому вопросу, я буду рад их услышать.
Другие советы
Ну, технически можно уменьшить зеркальный журнал. Проблема заключается в резервном копировании журнала с помощью 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 DBName, 'trunc. войти в систему chkpt. ', true контрольно-пропускной пункт DBCC SHRINKFILE (DBNameFileName, 500); exec sp_dboption DBName, 'trunc. войти в систему chkpt. ', false
Надеюсь, это поможет.
Возможно сжать файл транзакции для базы данных с зеркалом, резервное копирование должно быть выполнено, поскольку есть активные файлы виртуального журнала: http: / /www.xoowiki.com/Article/SQL-Server/tronquer-journal-de-log-sur-base-en-miroir-499.aspx
ALTER [имя_базы_данных] SET PARTNER OFF РЕЗЕРВНЫЙ ЛОГ [DatabaseName] TO DISK = 'Drive: \ DatabaseName_log_datetime.trn' DatabaseName_log_datetime.trn в любое место на зеркальном сервере. NoRecovery в зеркальной базе данных.
RESTORE LOG [DatabaseName] FROM DISK = 'Диск: \ DatabaseName_log_datetime.trn' Протестировав некоторые предложения в этом посте, я обнаружил, что после полного резервного копирования, команды контрольной точки и резервного копирования журнала транзакций размер журнала транзакций основной базы данных можно уменьшить. Размер журнала транзакций зеркальной базы данных затем синхронизируется с основным уменьшенным размером.
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, WAYITFOR DELAY является обязательным, если выполняется в пакетном режиме, например.
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) запустите mirrorser и удалите mirrorDatabase 6) восстановление без резервных копий восстановления 3) на mirroServer 7) переустановить зеркалирование Оуф!
Это правда, что вы не можете сжать журнал базы данных, когда он станет слишком большим - в этот момент я думаю, что ваш единственный вариант - разбить зеркало, сжать и заново создать. Кроме того, несмотря на то, что вы должны использовать зеркалирование только с двумя серверами, я могу сказать, что если вы будете делать регулярные резервные копии журнала транзакций. Из него будет освобождено пространство, что позволит MSSQL повторно использовать мертвое пространство в файле журнала. Это ничего не сокращает, но соответствует требованию остановить его рост.
Тогда все, что вам нужно сделать, это регулярно удалять резервные копии файлов. Например, вы можете сделать это:
USE your_database
GO
BACKUP LOG your_database TO DISK = 'x:\your_backup_filepath\your_database.tlog'
GO
Делайте это в нерабочее время, если можете.
Я не знаю, почему это работает, только то, что это действительно работает. Я запускаю это как блок в окне запроса. Используйте по своему усмотрению. Конечно, было бы неплохо, если бы прокомментировал комментарий.
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
)
На самом деле вы ничего не можете сделать с зеркальной базой данных, не извлекая ее из зеркала, если это не основная база данных.
Что должно сработать, так это если вы создадите резервную копию своих баз данных на основном сервере, а затем выполните сжатие.Т.е. ваш план технического обслуживания должен включать работу по сокращению som.Эти изменения должны автоматически передаваться на вторичный (зеркальный) сервер путем синхронизации.
Если вы хотите выполнить сжатие, которое сжимает только файл транзакции, вы можете использовать следующий T-SQL:
USE [your_db_name]
GO
DBCC SHRINKFILE (N'your_db_name_logfile' , 0, TRUNCATEONLY)
GO
Затем вы просто используете этот фрагмент для каждой базы данных и запускаете его сразу после создания резервной копии.
Это должно уменьшить размер файла журнала на основном сервере и, следовательно, на вторичном / зеркальном сервере.
Я надеюсь, что это поможет.
Кстати.Если вы дошли до того, что на диске не осталось места для файлов журналов, единственный вариант - вывести его из зеркального режима, перевести базу данных в режим простого восстановления, сжать файл журнала, снова перевести его в режим полного восстановления и снова настроить зеркало (используя резервные копии файла журнала базы данных og для восстановления на зеркальном сервере).
Кроме того, вы можете использовать SQL Express в качестве сервера-свидетеля, если проблема связана с лицензированием.Для этого не должно требоваться слишком много ресурсов, поэтому вы могли бы использовать веб-сервер, если это веб-приложение.Просто не забудьте также просмотреть файлы журналов для сервера-свидетеля.
** сжатие может быть выполнено в зеркальном отображении, но мы не можем усечь журнал, поскольку журнал - это то, что отправляется на зеркальный сервер, а затем субъект ожидает подтверждения.
Решением проблемы является резервное копирование журнала без усечения, а затем сжатие файла журнала, или вы можете даже игнорировать сжатие. Если это не работает, попробуйте контрольную точку, прежде чем создавать резервную копию журнала. Это должно работать ...
