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

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

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

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

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

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

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

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

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

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

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


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