Zmniejsz dziennik transakcji podczas korzystania z grupy dostępności AlwaysOn

Korzystamy z AlwaysOn Availability Groupfunkcji SQL Server 2012. Regularne kopie zapasowe pełnej bazy danych i kopie zapasowe dziennika transakcji są wykonywane codziennie w dodatkowej bazie danych.

Przeczytałem tutaj, że tworzenie kopii zapasowej dziennika transakcji na replice podstawowej lub replice dodatkowej oznaczy dzienniki transakcji obu replik jako wielokrotnego użytku. W każdym razie rozmiar kopii zapasowej dziennika transakcji jest duży i można go zmniejszyć za pomocą pliku zmniejszania:

Mam przywrócić bazę danych lokalnie i wykonać operację zmniejszania. Rozmiar pliku dziennika został zmniejszony do 160 MB.

Moje pytanie dotyczy tego, w której bazie danych powinienem wykonać operację zmniejszania pliku dziennika transakcji (podstawowy, pomocniczy lub oba)?

Wydaje mi się, że w przeszłości od kilku lat nie są tworzone kopie zapasowe pliku dziennika, więc stało się ono tak ogromne. Podczas wykonywania DBCC SQLPERF (LOGSPACE)widzę, że 0.06%używany jest tylko plik - nie ma sensu utrzymywać tak dużego rozmiaru pliku dziennika. W [sys].[database_files]sprawdzić, że jego max_sizejest ustawiony -1ze growthdo 65536tak myślę, gdy potrzebujesz więcej miejsca będzie to dostać. W każdym razie mogę go zmniejszyć na przykład do 5%, aby zapobiec przyszłemu wzrostowi. Próbuję znaleźć jakieś potwierdzenie, że nie jest to zły pomysł.

W rzeczywistości kopie zapasowe (w bazie danych i plikach dziennika) są wykonywane tylko w dodatkowych bazach danych, więc łatwiej będzie na nich wykonać plik zmniejszania, ale czy zmniejszy się również rozmiar podstawowego pliku dziennika?

W AG zapisy mogą występować tylko na urządzeniu pierwotnym. Operacje zmniejszania są zapisywane. Dlatego musisz wykonać zmniejszenie na podstawowym. Zwróć uwagę, że kurczenie się może nie zmniejszyć się tak, jak się spodziewasz, w teście na przywróconej bazie danych prawdopodobnie wykorzystano prosty model odzyskiwania. Przeczytaj Jak zmniejszyć dziennik SQL Server, aby uzyskać więcej informacji.

Nie zmniejszaj do 160 MB. Określ, dlaczego dziennik urósł do 121 Gb, aby się nie powtarzał (masz podejrzenia, dobrze byłoby potwierdzić, jeśli to możliwe). Dopasuj dziennik do rozmiaru odpowiedniego do potrzeb operacyjnych. Wzrost dziennika jest poważnym problemem, nie może on korzystać z natychmiastowej inicjalizacji pliku, a cała aktywność bazy danych zawiesza się, podczas gdy dziennik rośnie i jest inicjowany na 0. Użytkownicy i aplikacje nienawidzą tego, gdy się pojawia. Jeśli rozumiesz wpływ, a użytkownicy są w porządku, możesz raz zmniejszyć się do niewielkiej ilości (160 MB jest prawdopodobnie zbyt małe) i pozwolić mu rosnąć, aż się ustabilizuje.

Możesz spróbować:

1. Baza danych na wszystkich serwerach w grupie dostępności powinna być w stanie zsynchronizowanym.
2. Przenieś używane strony na początek dziennika transakcji, zanim go zmniejszysz.
3. Czasami dostępne wolne miejsce w dzienniku wynosi 99%, ale SQL Server nie może zwolnić nieużywanego miejsca. Spróbuj po kolei zrestartować każdy serwer w grupie dostępności.
4. Czasami musisz rozwinąć i zmniejszyć dziennik transakcji 2 razy, zanim MS SQL Server zwolni wolne miejsce (Nie można zmniejszyć pliku dziennika (DB_Log), ponieważ plik dziennika logicznego znajdujący się na końcu pliku jest używany).

Wypróbuj ten skrypt:

    - Ustaw bieżącą bazę danych wewnątrz kroku zadania lub skryptu
    - Zaznacz opcję Wykonaj tylko na poziomie podstawowym
    if (WYBIERZ rolę
        OD sys.dm_hadr_availability_replica_states AS a
        DOŁĄCZ do sys.availability_replicas AS b
            ON b.replica_id = a.replica_id
    GDZIE b.replica_server_name = @@ SERVERNAME) = 1
    ZACZYNAĆ
        - Użyj [test_db] - Nie działa dla MS SQL 2014, po prostu skomentuj ten wiersz i ustaw bieżącą bazę danych w kroku zadania lub skrypcie
        - 1) Bakup Trn
        KOPIA ZAPASOWA [test_db] NA DYSK = N'D: \ MSSQL \ Backup \ test_db.trn 'Z NOFORMAT, INIT, NAME = N' Trn Backup ', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10
        - 2) Przenieś używane strony
        DBCC SHRINKFILE (N'test_db_log ', 3000, NOTRUNCATE)
        - 3) Dziennik SHRINKFILE
        DBCC SHRINKFILE (N'test_db_log ', 3000)
    KONIEC