Зменшити журнал транзакцій під час використання групи AlwaysOn Availability

Ми використовуємо AlwaysOn Availability Groupфункцію SQL Server 2012. Регулярні резервні копії баз даних та резервні копії журналу транзакцій проводяться щодня у вторинній базі даних.

Я читав тут, роблячи резервну копію журналу транзакцій або в первинній репліці, або в вторинній репліці, буде позначено як журнали транзакцій обох реплік як багаторазові. У будь-якому випадку розмір резервного копіювання журналу транзакцій великий і його можна зменшити, використовуючи файл скорочення:

Я відновив базу даних локально і виконую операцію скорочення. Розмір файлу журналу зменшився до 160 Мб.

Моє запитання, на якій базі даних я повинен виконувати операцію скорочення над файлом журналу транзакцій (первинний, вторинний або обидва)?

Я здогадуюсь протягом останніх років не робилося резервного копіювання файлу журналу, тому він став таким величезним. Виконуючи, DBCC SQLPERF (LOGSPACE)я можу бачити, що використовується тільки 0.06%файл - немає сенсу зберігати такі величезні розміри файлу журналу. У [sys].[database_files]перевіряю , що його max_sizeвстановлено в -1с growthк , 65536так що я думаю , коли це потрібно більше місця , він отримає. У всякому разі, я можу скоротити його до 5%, наприклад, щоб запобігти майбутньому зростанню. Я намагаюся знайти якесь підтвердження того, що мені це не погано.

Насправді резервні копії (на базі даних та файлах журналів) виконуються лише на вторинних базах даних, тому буде легше виконувати файл скорочення, але чи зменшиться також розмір основного файлу журналу?

В АГ записи можуть виникати лише на первинному. Скорочення операцій пише. Тому ви повинні робити усадку на первинному. Зауважте, що скорочення може зменшитися не так сильно, як ви очікували, ваш тест на відновленій БД мабуть використав просту модель відновлення. Прочитайте, як зменшити журнал SQL Server для отримання додаткової інформації.

Не стискайте до 160МБ. Визначте, чому журнал виріс до 121Gb, щоб він не повторювався (у вас є підозра, було б добре підтвердити, якщо можливо). Розмір журналу до розміру, відповідного вашим операційним потребам. Зростання журналу є серйозною проблемою, він не може використовувати миттєву ініціалізацію файлів, і вся активність вашої бази даних буде заморожена під час зростання журналу та його ініціалізації. Користувачі та програми ненавидять його, коли він виникає. Якщо ви розумієте вплив та ваші користувачі все в порядку, ви можете один раз зменшити його до невеликої кількості (хоча, 160 МБ, мабуть, занадто мало) і дати йому зростати, поки він не стабілізується.

Ви можете спробувати:

1. База даних на всіх серверах групи доступності повинна бути в синхронізованому стані.
2. Перемістіть використані сторінки для початку журналу транзакцій, перш ніж зменшити їх.
3. Іноді вільний простір журналу становить 99%, але SQL Server не може звільнити невикористаний простір. Спробуйте перезавантажити кожен сервер групи доступності.
4. Іноді вам потрібно здійснити накопичення та скорочення журналу транзакцій 2 рази, перш ніж MS SQL Server звільнить вільний простір (Неможливо зменшити файл журналу (DB_Log), оскільки використовується логічний файл журналу, що знаходиться в кінці файлу.)

Спробуйте цей сценарій:

    - Встановіть поточну базу даних всередині кроку завдання або сценарію
    --Перевірка на виконання лише на первинному
    if (SELECT роль)
        ВІД sys.dm_hadr_available_replica_states AS a
        ПРИЄДНАЙТЕ sys.available_replicas AS b
            ON b.replica_id = a.replica_id
    ДЕ b.replica_server_name = @@ SERVERNAME) = 1
    ПОЧАТОК
        - Використовуйте [test_db] - Не працює для MS SQL 2014, просто прокоментуйте цей рядок та встановіть поточну базу даних у кроці завдання чи скрипті
        - 1) Bakup Trn
        BACKUP LOG [test_db] ДИСК = N'D: \ MSSQL \ Резервне копіювання \ test_db.trn 'З NOFORMAT, INIT, NAME = N' Trn Backup ', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10
        - 2) Переміщення використаних сторінок
        SHRINKFILE DBCC (N'test_db_log ', 3000, NOTRUNCATE)
        - 3) Журнал SHRINKFILE
        SHRINKFILE DBCC (N'test_db_log ', 3000)
    КІНЦЯ