Riduci registro transazioni durante l'utilizzo del gruppo di disponibilità AlwaysOn

Stiamo utilizzando la AlwaysOn Availability Groupfunzionalità di SQL Server 2012. Backup regolari completi del database e backup del registro delle transazioni vengono eseguiti ogni giorno sul database secondario.

Ho letto qui che il backup del registro delle transazioni sulla replica primaria o secondaria contrassegnerà i registri delle transazioni di entrambe le repliche come riutilizzabili. In ogni caso, la dimensione del backup del registro delle transazioni è grande e può essere ridotta utilizzando il file di riduzione:

Ho ripristinato il database localmente ed eseguo l'operazione di compattazione. La dimensione del file di registro è stata ridotta a 160 MB.

La mia domanda è su quale database devo eseguire un'operazione di compattazione sul file di registro delle transazioni (primario, secondario o entrambi)?

Immagino che in passato per diversi anni non sia stato effettuato alcun backup del file di registro, quindi diventa così enorme. In fase di esecuzione DBCC SQLPERF (LOGSPACE)vedo che 0.06%viene utilizzato solo il file: non ha senso conservare dimensioni così grandi del file di registro. In [sys].[database_files]verifico che la sua max_sizeè impostato -1con growthal 65536quindi credo che quando si ha bisogno di più spazio otterrà. Ad ogni modo, posso ridurlo al 5% per esempio per prevenire la crescita futura. Sto cercando di trovare una conferma che non è una cattiva idea farlo.

In realtà, i backup (sul database e sui file di registro) vengono eseguiti solo sui database secondari, quindi sarà più semplice eseguire il file di riduzione su di essi, ma ridurranno anche le dimensioni del file di registro primario?

In AG le scritture possono avvenire solo sul primario. Le operazioni di riduzione sono scritture. Pertanto è necessario eseguire la riduzione sul primario. Si noti che il restringimento potrebbe non ridursi tanto quanto ci si aspetta, il test sul DB ripristinato aveva probabilmente sfruttato un semplice modello di recupero. Leggi Come ridurre il registro di SQL Server per ulteriori informazioni.

Non ridurre a 160 MB. Determina perché il registro è cresciuto fino a 121 GB, quindi non si ripete (hai un sospetto, sarebbe bello confermare se possibile). Ridimensionare il registro in una dimensione appropriata per le esigenze operative. La crescita dei registri è un problema serio, non può utilizzare l'inizializzazione dei file istantanea e tutte le attività del database si bloccheranno mentre il registro cresce e viene inizializzato a 0. Gli utenti e le app lo odiano quando si verifica. Se capisci l'impatto e i tuoi utenti stanno bene, puoi ridurne una volta in piccola parte (160 MB è probabilmente troppo piccolo) e lasciarlo crescere fino a quando non si stabilizza.

Puoi provare:

1. Il database su tutti i server nel gruppo di disponibilità deve essere nello stato Sincronizzato.
2. Spostare le pagine usate per iniziare il registro delle transazioni, prima di ridurlo.
3. A volte lo spazio disponibile disponibile nel registro è del 99%, ma SQL Server non può liberare spazio inutilizzato. Prova a riavviare a turno ciascun server nel gruppo di disponibilità.
4. A volte è necessario eseguire il bakup e ridurre il registro delle transazioni 2 volte prima che MS SQL Server rilasci spazio libero (Impossibile ridurre il file di registro (DB_Log) perché è in uso il file di registro logico situato alla fine del file.).

Prova questo script:

    --Impostare il database corrente all'interno della fase o dello script del lavoro
    --Controllare Esegui solo su primario
    if (SELEZIONA ruolo
        DA sys.dm_hadr_availability_replica_states AS a
        ISCRIVITI sys.availability_replicas AS b
            ON b.replica_id = a.replica_id
    DOVE b.replica_server_name = @@ SERVERNAME) = 1
    INIZIO
        - Usa [test_db] - Non funziona per MS SQL 2014, commenta questa riga e imposta il database corrente all'interno del passaggio o dello script del lavoro
        - 1) Bakup Trn
        BACKUP LOG [test_db] DA DISCO = N'D: \ MSSQL \ Backup \ test_db.trn 'CON NOFORMAT, INIT, NAME = N' Trn Backup ', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10
        - 2) Sposta le pagine usate
        DBCC SHRINKFILE (N'test_db_log ', 3000, NOTRUNCATE)
        - 3) Registro SHRINKFILE
        DBCC SHRINKFILE (N'test_db_log ', 3000)
    FINE