Не вдається обрізати журнал транзакцій, log_reuse_wait_desc - AVAILABILITY_REPLICA

Сьогодні вранці мене прокинуло повне сповіщення журналу транзакцій про одну з наших баз даних. Цей сервер - це завжди кластер, а також абонент транзакційної реплікації. Я перевірив log_reuse_wait_desc, і він показав резервне копіювання. Хтось випадково відключив завдання резервного копіювання 4 дні раніше, я знову включив завдання резервного копіювання журналу і журнал видалився. Оскільки це було 4 години ранку, я думав, що пішов в офіс пізніше того ранку і закрутив журнал, оскільки він виріс до 400 ГБ.

10:00 - Я в офісі, і я перевіряю використання журналу, перш ніж скорочуватися, і це було близько 16%. Я був здивований і перевірив log_reuse_wait_desc, який показав реплікацію. Я був розгублений, оскільки це був абонент реплікації. Потім ми побачили, що db увімкнено для CDC і подумали, що це може бути причиною, тому відключений CDC і тепер log_reuse_wait_desc показує AVAILABILITY_REPLICA.

Тим часом використання журналу все ще стабільно зростає і зараз становить 17%. Я перевіряю панель приладів alwayson і перевіряю надіслану та повторну чергу, і обидва фактично дорівнюють нулю. Я не впевнений, чому повторне використання журналу відображається як AVAILABILITY_REPLICA і не вдається очистити журнал.

Будь-яка ідея, чому це відбувається?

Якщо ви це зробите:

SELECT * FROM sys.databases

І log_reuse_wait_desc показує AVAILABILITY_REPLICA, це означає, що SQL Server чекає, щоб надіслати дані журналу до однієї з реплік групи "Завжди в наявності". Одна з реплік може відставати через повільну мережу, або може знизитися зовсім.

Якщо ви перевірите інформаційну панель AG і на ній немає черг, можливо, ви стали жертвою виснаження ниток. Відомо, що приладова панель AG припиняє оновлюватись після виснаження робочих ниток. Вам потрібно буде перевірити стан кожної репліки безпосередньо, а не покладатися на основну. Примітка Ніка в цьому елементі Connect говорить про те, що ви можете просто змінити властивості репліки, щоб перезапустити реплікацію, але це не завжди працює (особливо якщо у вас є сотні баз даних на репліку з великою кількістю даних, які потрібно надіслати, і перезапуск реплікації може просто знову призвести до виснаження робочої нитки.)

Якщо останній хлопець створив репліку AG, і вона більше не повинна існувати, тоді прийшов час видалити цю AG та / або репліку. Будьте обережні, щоб програми не вказували на ім’я слухача, щоб підключитися до вашого SQL Server.