Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Усечение лога транзакций ( репликация + зеркалирование )  [new]
Папуша Дмитрий
Member

Откуда: Санкт-Петербург
Сообщений: 131
Вечера доброго.

Враждебная среда описывается просто.
SQL Server version:
Microsoft SQL Server 2005 - 9.00.4053.00 (X64)   May 26 2009 14:13:01   Copyright (c) 1988-2005 Microsoft Corporation  Standard Edition (64-bit) on Windows NT 5.2 (Build 3790: Service Pack 2) 

Настроена репликация ( merge ). Сервер выполняет функции издателя и подписчика одновременно. Реплицируется 4 базы, не полностью. Часть данных из этих баз переливается в их "мобильные" аналоги.
Для этих 6 ( 3*2 ) баз настроено зеркалирование ( automatic failover ) на другой сервер, находящийся в локальной сети. То есть одна из реплицируемых НЕ зеркалируется.

Все сеансы репликации выполняются в ночное время поочереди для каждой базы. Распределены так, что бы не было ожидания агентов.

Настроен Maintenance Plan, который единожды в день делает полный бекап перед репликацией, затем в течение дня 3 разностных и 2 бекапа логов. Все эти бекапы, исключая полный, делаются уже после репликации.

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

1 из этих баз не зеркалируется. А следовательно, подозреваю, что виновата все же репликация.

Лог этих баз перестал усекаться. При подъеме из бекапа любой из них и принудительном бекапировании лога - чудо не заставляет себя долго ждать: available free space = 99%.

Вопрос: почему не усекаются логи на этих боевых базах и как это победить?
9 ноя 09, 19:15    [7904274]     Ответить | Цитировать Сообщить модератору
 Re: Усечение лога транзакций ( репликация + зеркалирование )  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
DBCC OPENTRAN в контексе базы что вернет?
10 ноя 09, 06:22    [7905470]     Ответить | Цитировать Сообщить модератору
 Re: Усечение лога транзакций ( репликация + зеркалирование )  [new]
Папуша Дмитрий
Member

Откуда: Санкт-Петербург
Сообщений: 131
tpg,

вернуло следующее:

Replicated Transaction Information:
        Oldest distributed LSN     : (0:0:0)
        Oldest non-distributed LSN : (13519:17412:1)

Я так понимаю, что это означает следующее: "Log reader is not able to keep up or is disabled.."
Как ему в этом помочь? Что может быть причиной такого поведения? Повторюсь, есть учавствующие в репликации базы, для которых лог усекается нормально и DBCC OPENTRAN ничего не возвращает.
10 ноя 09, 19:55    [7910419]     Ответить | Цитировать Сообщить модератору
 Re: Усечение лога транзакций ( репликация + зеркалирование )  [new]
Glory
Member

Откуда:
Сообщений: 104760
Папуша Дмитрий
tpg,

вернуло следующее:

Replicated Transaction Information:
        Oldest distributed LSN     : (0:0:0)
        Oldest non-distributed LSN : (13519:17412:1)

Я так понимаю, что это означает следующее: "Log reader is not able to keep up or is disabled.."
Как ему в этом помочь? Что может быть причиной такого поведения? Повторюсь, есть учавствующие в репликации базы, для которых лог усекается нормально и DBCC OPENTRAN ничего не возвращает.

Вы уверены, что репликация на этой базе работает ?
Потому при репликации транзакции лог нельзя усекать, пока эти транзакции не реплицированы
10 ноя 09, 20:01    [7910432]     Ответить | Цитировать Сообщить модератору
 Re: Усечение лога транзакций ( репликация + зеркалирование )  [new]
Папуша Дмитрий
Member

Откуда: Санкт-Петербург
Сообщений: 131
Glory,

у меня репликация слиянием и снапшотами. В этом случае Ваш вопрос все еще актуален?
Если да, то.. я только что запустил все репликации на одной из "проблемных" баз, они выполнились успешно. После чего я сделал полный бекап и бекап лога. Результат - available free space 7%. Что означает, что не помогло колдовство.
Такой вопрос..
У меня И издательские базы И подписчики реплицируются одним maintenance plan-ом. Нужно ли определять как то очередность создания бекапов для этих типов баз? Например, сначала обязательно должны бекапироваться подписчики, а затем издатель или наоборот.
10 ноя 09, 20:27    [7910488]     Ответить | Цитировать Сообщить модератору
 Re: Усечение лога транзакций ( репликация + зеркалирование )  [new]
Glory
Member

Откуда:
Сообщений: 104760
Папуша Дмитрий
Glory,

у меня репликация слиянием и снапшотами. В этом случае Ваш вопрос все еще актуален?

Откуда же тогда берутся Replicated Transaction Information: ?
10 ноя 09, 20:33    [7910509]     Ответить | Цитировать Сообщить модератору
 Re: Усечение лога транзакций ( репликация + зеркалирование )  [new]
Папуша Дмитрий
Member

Откуда: Санкт-Петербург
Сообщений: 131
Glory,

просто пытаюсь исключить непонимание. Мое непонимание :)

select log_reuse_wait_desc,name from sys.databases

Этот запрос вывел мне мои злосчастные "проблемные базы" с значением log_reuse_wait_desc = "REPLICATION".
У остальных реплицируемых баз это значени "NOTHING".

Никакой разницы между ними я найти не могу.. Это "тестовая", "предпродакшн" и "продакшн" версии одной и той же базы. Хотя никакой гарантии, что используются они одинаково - нет ( мысли вслух ).
10 ноя 09, 20:42    [7910526]     Ответить | Цитировать Сообщить модератору
 Re: Усечение лога транзакций ( репликация + зеркалирование )  [new]
Glory
Member

Откуда:
Сообщений: 104760
Папуша Дмитрий

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

Разница в том, что для репликации этой базы транзакции не реплицируются. И поэтому "забивают" журнал
10 ноя 09, 20:47    [7910536]     Ответить | Цитировать Сообщить модератору
 Re: Усечение лога транзакций ( репликация + зеркалирование )  [new]
Папуша Дмитрий
Member

Откуда: Санкт-Петербург
Сообщений: 131
Glory,

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

Этот пост, кажется, о моем случае.
Осталось только разобраться в найденном решении... а главное, убедиться, что некую sp_repldone можно запускать безбоязненно на боевой базе.
10 ноя 09, 20:52    [7910552]     Ответить | Цитировать Сообщить модератору
 Re: Усечение лога транзакций ( репликация + зеркалирование )  [new]
Папуша Дмитрий
Member

Откуда: Санкт-Петербург
Сообщений: 131
Ребята, нужна ваша помощь.

Проблему пофиксил. Запустил sp_replrestart на издателе, забекапил лог, получил 98% свободного места в лог файле. То же самое проделал с подписчиком. Работает!

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

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

Мой вопрос в том:
1. Прав ли я в своих догадках или весь процесс происходит иначе?
2. Как можно узнать инфу о транзакции ( тип, кем инициированна, дата ) по LSN, получаемому в DBCC OPENTRAN?
3. Обнаружил, что на одной из проблемных ДБ процедура sp_repltrans возвращает лишь 1 запись. Значит ли это, что проблема лишь в этой транзакции? И если да.. то возможно ли решить проблему конкретно с ней, не перезапуская агента ?

Я мало знаю о работе механизмов, крутящихся вокруг моей проблемы. Поэтому прошу вашего совета.
11 ноя 09, 02:10    [7911310]     Ответить | Цитировать Сообщить модератору
 Re: Усечение лога транзакций ( репликация + зеркалирование )  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
https://www.sql.ru/articles/mssql/2005/083102HowToTransactionalReplication.shtml
11 ноя 09, 06:21    [7911413]     Ответить | Цитировать Сообщить модератору
 Re: Усечение лога транзакций ( репликация + зеркалирование )  [new]
Папуша Дмитрий
Member

Откуда: Санкт-Петербург
Сообщений: 131
Хм..

Выполнил sp_repltrans на DB_UAT (проблемная база). Вернулась одна строка:
xdesid xact_seqno
0x0000458D0000EEBE0001 0x0000458D0000F0090001

Затем выполнил
sp_browsereplcmds @xact_seqno_start = '0x0000458D0000F0090001'
на базе distribution.

Получил результат:
\\10.1.4.10\replicationfolder\unc\SRV_DB_PROD_ONEWAY_ONCEDAYPROD\20091111043012\T_Global_Access_2.pre
\\10.1.4.10\replicationfolder\unc\SRV_DB_PROD_ONEWAY_ONCEDAYPROD\20091111043012\T_Global_Access_2.sch
[ImmediateExecution]ALTER TABLE [dbo].[T_Global_Access_Client] ADD CONSTRAINT [PK_T_Global_Access] PRIMARY KEY CLUSTERED ([PK_Global_Access])
\\10.1.4.10\replicationfolder\unc\SRV_DB_PROD_ONEWAY_ONCEDAYPROD\20091111043012\T_Global_Access_2.idx
sync -t"T_Global_Access_Client" -o"dbo" -d"\\10.1.4.10\replicationfolder\unc\SRV_DB_PROD_ONEWAY_ONCEDAYPROD\20091111043012\T_Global_Access_2.bcp" -hORDER([PK_Global_Access] ASC)
[i][QueueCommand]ALTER TABLE [dbo].[T_Global_Access_Client] ADD CONSTRAINT [IX_T_Global_Access] UNIQUE NONCLUSTERED ([Email])
[FlushQueuedCommands][/i]

SRV_DB_PROD_ONEWAY_ONCEDAYPROD - название пуш снапшот репликации. В ней 6 статей. Вышеупомянутый блок строк - это блок для статьи T_Global_Access. Этот блок повторяется 1 раз для каждой статьи - естественно меняется значение столбцов article_id ,command_id и имя статьи в командах. И лишь 2 выделенные строки появляются только у этой статьи.

Мое первое непонимание, почему я наблюдаю проблемы и открытые транзакции в DB_UAT, а скрипт выполняется из публикации на DB_PROD?

Второе: эта снапшот публикация переносит изменения из T_Global_Access на издателе в T_Global_Access_Client на подписчике. Я проверил в базе подписчике для DB_UAT - в таблице назначении T_Global_Access_Client нет индекса IX_T_Global_Access. То есть эта транзакция действительно не перенеслась.

Третье: Для DB_PROD создана все те же публикации.. и в ней так же не перенесен этот индекс, но нет повисших транзакций.

Почему это случилось - так и остается загадкой. Если больше не откопаю подобных транзакций, то и на DB_UAT выполню sp_replrestart, а с индексом уже разберусь вручную.
11 ноя 09, 15:58    [7915133]     Ответить | Цитировать Сообщить модератору
 Re: Усечение лога транзакций ( репликация + зеркалирование )  [new]
Папуша Дмитрий
Member

Откуда: Санкт-Петербург
Сообщений: 131
Хм, плохо знаком с форматированием.. )

[QueueCommand]ALTER TABLE [dbo].[T_Global_Access_Client] ADD CONSTRAINT [IX_T_Global_Access] UNIQUE NONCLUSTERED ([Email])
[FlushQueuedCommands]


Эти 2 строки должны были быть выделенными.
11 ноя 09, 16:00    [7915152]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить