ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Медленная фиксация на вторичной реплике в группе доступности AlwaysOn
13 сообщений из 13, страница 1 из 1
Медленная фиксация на вторичной реплике в группе доступности AlwaysOn
    #39947908
Фотография Mandarin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mandarin
Участник
Всем привет! Подскажите пожалуйста как правильно диагностировать и решить следующую проблему.
Есть два сервера с одинаковым железом, первичная и вторичная реплики в группе AlwaysOn с синхронной фиксацией.
На серверах крутится две БД примерно равные по объёму каждая по 600ГБ.
Ночью выполняются задачи по оптимизации БД, это удаление старых данных и перестроение индексов.
После таких оптимизаций она БД сильно отстаёт, очередь не зафиксированных транзакций после 7 часов работы может составлять порядка 150ГБ при всём при том, что вторая БД полностью синхронизирована. В БД которая сильно отстаёт много данных удаляется и вставляется в процессе оптимизаций. Общее количество вставленных и удалённых строк порядка 500-700 млн. Планы обслуживания у БД одинаковые. Базы лежат на одном и том же дисковом массиве, логи лежат на другом дисковом массиве, но тоже вместе, поэтому я не могу сказать, что дело в дисковой подсистеме. DBCC CHECKDB ошибок не показывает. На обеих базах настроена доставка журналов (Log shiping) на третий сервер. Во время ночных оптимизаций, я вижу, что размеры бэкапов логов транзакций, для передачи на третий сервер, примерно одинаковые по размеру. Это говорит о том, что размер изменений примерно одинаковый. Задержку сети тоже исключаю т.е. БД лежат на одних и тех же серверах. Скорее всего вопрос в каких-то блокировках которые мешают быстрой фиксации.

Версия SQL Sever 2017 CU 14
...
Рейтинг: 0 / 0
16.04.2020, 10:37
| Ответить | Цитировать | Написать  
Медленная фиксация на вторичной реплике в группе доступности AlwaysOn
    #39947914
Alexander Titkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexander Titkin
Гость
Mandarin,

Переключайтесь на асинхронную фиксацию в момент перестроения индексов
...
Рейтинг: 0 / 0
16.04.2020, 10:53
| Ответить | Цитировать | Написать  
Медленная фиксация на вторичной реплике в группе доступности AlwaysOn
    #39947920
Фотография Mandarin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mandarin
Участник
Alexander Titkin,

Спасибо за совет. Попробую.

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

Что ещё можно проверить, как вы думаете?
...
Рейтинг: 0 / 0
16.04.2020, 11:00
| Ответить | Цитировать | Написать  
Медленная фиксация на вторичной реплике в группе доступности AlwaysOn
    #39947940
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владислав Колосов
Участник
Mandarin,

Задержки можно проверить, например, запросом, который выполняется на первичной реплике:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
SELECT
		rpl.database_id,
		rpl.log_send_queue_size,
		rpl.log_send_rate,
		rpl.redo_queue_size,
		rpl.redo_rate,
		rpl.secondary_lag_seconds,
		rpl.suspend_reason_desc
	FROM sys.dm_hadr_database_replica_states rpl WITH (NOLOCK)



Создайте джоб, который будет записывать результат в таблицу с каким-то интервалом. Или можете записать аналогичные счетчики производительности.
...
Рейтинг: 0 / 0
16.04.2020, 11:15
| Ответить | Цитировать | Написать  
Медленная фиксация на вторичной реплике в группе доступности AlwaysOn
    #39947947
Фотография Mandarin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mandarin
Участник
Alexander Titkin
Mandarin,

Переключайтесь на асинхронную фиксацию в момент перестроения индексов

Если я правильно понял документацию на тему "Синхронный/Ассинхронный режимы фиксации", то что вы предложили менять на ассинхронный режим, не повлияет на ситуацию, потому как транзакция на первичной реплике завершилась, данные передались на вторичную реплику. Реплики соединены напрямую сетевым кабелем, скорость между ними 20 ГБ/сек. А если данные передались то уже какая разница какой тип фиксации? Вопрос в том как быстро переданные данные восстанавливаются на вторичной реплике.
...
Рейтинг: 0 / 0
16.04.2020, 11:23
| Ответить | Цитировать | Написать  
Медленная фиксация на вторичной реплике в группе доступности AlwaysOn
    #39947949
Фотография Mandarin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mandarin
Участник
Владислав Колосов
Mandarin,

Задержки можно проверить, например, запросом, который выполняется на первичной реплике:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
SELECT
		rpl.database_id,
		rpl.log_send_queue_size,
		rpl.log_send_rate,
		rpl.redo_queue_size,
		rpl.redo_rate,
		rpl.secondary_lag_seconds,
		rpl.suspend_reason_desc
	FROM sys.dm_hadr_database_replica_states rpl WITH (NOLOCK)



Создайте джоб, который будет записывать результат в таблицу с каким-то интервалом. Или можете записать аналогичные счетчики производительности.


Спасибо. Какие выводы можно сделать из полученных цифр?
...
Рейтинг: 0 / 0
16.04.2020, 11:24
| Ответить | Цитировать | Написать  
Медленная фиксация на вторичной реплике в группе доступности AlwaysOn
    #39948112
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владислав Колосов
Участник
Mandarin,

можно проверить достаточность скорости канала передачи данных и скорости дисков на вторичной реплике.
...
Рейтинг: 0 / 0
16.04.2020, 16:56
| Ответить | Цитировать | Написать  
Медленная фиксация на вторичной реплике в группе доступности AlwaysOn
    #39948316
Фотография Александр Гладченко
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Гладченко
Участник
Если тормозит REDO, на это может влиять очень много факторов. Например, вы могли включить CDC, QS или началась популяция FT...
Но первым делом, посмотрите, оптимально ли у вас настроено обслуживание. Например, многие до сих пор продолжают ребилдить все индексы, хотя базы уже на SSD или обновление статистики тупо настроено с фулсканом... Оптимизировав это вы можете сильно облегчить жизнь синхронизации реплик. Кстати, вполне возможно, что очередной деплой привёл к увеличению фрагментации или статистика стала быстрее протухать из-за изменившегося характера данных (тут подобного можно ещё много нафантазировать).
Если "копать железо", то тут тоже многое может повлиять, например, выросла нагрузка на дисковый контроллер, и его кеш перестал справляться. На дешёвых контроллерах мы иногда ставили страйп в 64Кб, что бы нивелировать проседание REDO.
Чисто логически, тоже можно найти причины. Например, выросло число обращений к репликам на чтение. Не всегда это бывает безобидно, особенно с явными транзакциями... тоже может тормозить процесс REDO.
Сомневаюсь, что ваши политики DR пзволяют отказаться совсем от синхронного режима и автоматического перехода при отказе. Но можно синхронной оставить только одну реплику, а остальные сделать асинхронными, да ещ включить там trace flag 1448.
Здорово будет, если удастся выполнить все условия для многопоточного REDO. А то бывает, добрые люди решают включить оптимзированные в памяти таблицы или версионность побаловаться, а потом незнаю, что делать с REDO и фантомными строками...
В общем, вопрос не такой простой для решения....
...
Рейтинг: 0 / 0
17.04.2020, 11:38
| Ответить | Цитировать | Написать  
Медленная фиксация на вторичной реплике в группе доступности AlwaysOn
    #39948551
Фотография Mandarin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mandarin
Участник
Александр Гладченко,
Большое спасибо за развёрнутый ответ!

Из всего что вы сказали, пока понятно только то, что нужно поменять политику перестроения индексов :) Базы лежат на SSD и индексы постоянно перестраиваются. Как определить когда нужно перестраивать, а когда реорганизовать индекс, если база лежит на ssd?
...
Рейтинг: 0 / 0
18.04.2020, 09:40
| Ответить | Цитировать | Написать  
Медленная фиксация на вторичной реплике в группе доступности AlwaysOn
    #39948562
Фотография Александр Гладченко
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Гладченко
Участник
Реиндексация нужна только для устранения фантомных строк. Всё остальное бессмысленно на SSD.
...
Рейтинг: 0 / 0
18.04.2020, 11:48
| Ответить | Цитировать | Написать  
Медленная фиксация на вторичной реплике в группе доступности AlwaysOn
    #39948567
Фотография Mandarin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mandarin
Участник
Александр Гладченко,

А откуда они берутся и как с ними бороться?
...
Рейтинг: 0 / 0
18.04.2020, 12:21
| Ответить | Цитировать | Написать  
Медленная фиксация на вторичной реплике в группе доступности AlwaysOn
    #39948569
Фотография Mandarin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mandarin
Участник
Если я не ошибаюсь фантомные записи удаляются в фоне, как это связанно с перестроением индекса?
...
Рейтинг: 0 / 0
18.04.2020, 12:37
| Ответить | Цитировать | Написать  
Медленная фиксация на вторичной реплике в группе доступности AlwaysOn
    #39948644
Фотография Александр Гладченко
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Гладченко
Участник
Их пораждают изменения и особенно версионность. Удаляются они медленно. Всё это подробно описано в BOL.
...
Рейтинг: 0 / 0
18.04.2020, 19:33
| Ответить | Цитировать | Написать  
13 сообщений из 13, страница 1 из 1
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Медленная фиксация на вторичной реплике в группе доступности AlwaysOn
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=46&msg=39947947&tid=1686211]:
 0ms
get settings:
 11ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 42ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 53ms
get tp. blocked users:
 1ms
others: 287ms
total:  432ms
созд. / загр.: 432ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]