Il modo più semplice per ridurre i file di registro delle transactions in un database di produzione mirrored

Qual è il modo più semplice per ridurre il file di registro delle transactions in un database di produzione speculare?

Devo, poiché il mio spazio su disco sta esaurendo.

Farò un backup completo del database prima di farlo, quindi non ho bisogno di tenere alcunché dal registro delle transactions (vero? Ho un backup completo del database giornaliero, probabilmente non ho bisogno di ripristino in tempo reale, anche se manterrò l'opzione aperta se posso – questo è tutto il .ldf è davvero per, corretto?).

risolto:
OK, dopo aver eseguito 2 backup tramite SSMS (non TSQL) del solo registro, creando un set di backup totalmente nuovo , la window di dialogo Shrink-Files-Log in SSMS ha finalmente funzionato, liberando un certo spazio su disco.

Non so perché 2 backup quando è necessario o perché TSQL non funzionava e non c'era alcuna differenza nello spazio disponibile disponibile per essere recuperato nella window di dialogo di restringimento (era al 99% per tutti i tentativi di restringimento dopo il primo backup troppo, ma ancora non ha liberato spazio), ma il problema è stato risolto per ora. Ringrazia tutti.

    3 Solutions collect form web for “Il modo più semplice per ridurre i file di registro delle transactions in un database di produzione mirrored”

    Fai un backup del registro delle transactions, con qualunque metodo ti senti più comodo .

    Ciò causerà i registri delle transactions già impegnati nel database da eliminare dal disco. Idealmente, si dovrebbe effettivamente creare un task di manutenzione del database per farlo per voi su una base ricorrente proprio per questo motivo – eliminare i vecchi registri delle transactions in modo da non riempire il disco.

    Per l'altro bit della tua domanda … no, non proprio. Sì, eseguono quella function, ma non solo quella function.

    I database non vengono eseguiti in backup (o scritti) in modo tradizionale che altri file sono, perché il file di database stesso è costantemente in uso e cambia costantemente. Quindi un singolo "punto in tempo" di backup richiederebbe di richiedere il database offline per "congelarlo" in uno stato o un risultato coerente in diverse parti del backup contenenti dati diversi da quelli in cui è stato avviato il backup.

    Quanti registri delle transactions sono i record di each "transazione" eseguita dal database. Invece di scrivere al file di database each volta che un record viene modificato, aggiornato, aggiunto, rimosso, ecc., Queste azioni vengono scritte in un file separato, un registro delle transactions e quindi impegnate nel file di database quando il server SQL determina la sua sicurezza per farlo senza interrompere alcuna attività. Quindi i registri delle transactions sono, in effetti, where le modifiche al database vanno prima che apportino effettivamente modifiche al file [file].

    Quindi, se è necessario tornare a un determinato stato del database oa un punto in tempo, i registri delle transactions vengono "ripetuti". In sostanza, non copiare i dati dei file, ma andando al più recente stato point-in-time trovato per il database e quindi facendo tutte le stesse cose che hanno ottenuto il database allo stato di [stato successivo] specificato. Tuttavia, è importnte notare che in qualsiasi momento i tuoi registri delle transactions contengono transactions che non saranno ancora impegnate nel database. Quindi sono più che la capacità di eseguire un ripristino punto-in-tempo. Esse contengono alcuni cambiamenti che vengono effettuati o saranno brevemente inseriti nel database.

    Questo è il motivo per cui si è costretti a fare un backup prima di cancellare i registri delle transactions – una volta che il backup è stato fatto, il sistema ha una copia puntuale del database per fare riferimento a eventuali ripristini futuri e è in grado di determinare quali transactions hanno sono stati impegnati nel database e che non lo hanno fatto. E con queste informazioni, il sistema sa quali registri delle transactions obsoleti da eliminare per te e quali non.

    Ciò può tuttavia richiedere un certo tempo, a seconda della dimensione dei registri delle transactions. Se non l'hai mai fatto prima, preparatevi a prenderti un po '.

    Questa è una domanda più vecchia, ma ci sono alcune cose che non sono state spiegate bene e questo spero farà luce. Il modo di restringersi è stato risolto, per lo più, ma questo spiega la "perché" parte di quello che stai facendo.

    I backup, in particolare il backup dei log, svolgono diverse funzioni. I dati vengono scritti su disco come set di backup da utilizzare o scartati in seguito, se necessario. Ogni backup successivo viene aggiunto a tale insieme, in un DB completamente registrato. Troncare il registro o avviare un nuovo set di backup interrompe la catena e inibisce o in molti casi nega la capacità di ripristinare in un punto prima che la catena venisse interrotta.

    I dati nel registro non vengono effettivamente eliminati né il file di registro viene ridotto durante un backup. I VLF attivi sono contrassegnati inattivi, tranne quelli che non possono essere interamente impegnati – rimangono attivi. VLF inattivi sono in grado di essere riscritti, rendendo il vostro registro circolare, in effetti come un serpente che mangia la propria coda. Un punto di controllo viene rilasciato, come parte del backup, che indica al DB di iniziare a scrivere all'inizio del registro, una volta che il VLF attuale si riempie. Se si effettua un ritiro a questo punto, si otterrà tutto lo spazio alla fine del registro, fino al punto del VLF attivo.

    Il motivo per cui un secondo backup sembra "fare il trucco" è perché il VLF attivo in genere si riempie durante questo tempo e il registro viene scritto fin dall'inizio. Quando si prende il secondo backup, il VLF attivo viene scritto su disco come parte del set di backup (o no) e il VLF viene contrassegnato inattivo. Poiché questa era la fine di coda del registro a causa del precedente shrink, eseguire un shrink ora libera tutto lo spazio all'inizio del log, fino al VLF attualmente attivo.

    Tutto questo presuppone un paio di cose, 1.) non hai VLF massicci che richiedono ore o giorni per riempire e 2.) il tuo database è abbastanza inattivo e non ci sono un sacco di operazioni che vengono scritte nel log . Se una di queste condizioni è un problema per te, ridurre il tuo log sarà anche un problema.

    Tutto questo vale per entrambi i database non mirrored e mirrored. La differenza è che è sufficiente eseguire la manutenzione sul primario in uno scenario speculare, supponendo che lo specchio sia costruito in modo identico.

    La function di mirroring utilizza il registro per tenere traccia delle cose fino a quando non sa che l'altro server ha tali modifiche. Quindi, no, il ldf non è solo per il recupero point-in-time. (È anche importnte per alcuni schemi di replica, ma non lo fai.) Anche TRUNCATE_ONLY non butterà i cambiamenti registrati per le cose che SQL potrebbe avere bisogno. L'esempio classico è una transazione di grandi size o di lunga durata. Se sei a metà di una transazione di un'ora e un DBA gestisce TRUNCATE_ONLY, la tua roba non verrà eliminata dal LDF. Il LDF può continuare a crescere o sperimentare altri problemi. Se la DBA uccide la tua connessione, aspetta che il rollback finisca e poi esegua TRUNCATE_ONLY, il registro dovrebbe liberarsi.

    Hai provato a utilizzare:

     select log_reuse_wait_desc from sys.databases where name = 'mydb' 

    per vedere perché il registro è così grande? Microsoft documenta la tabella di sistema qui .

    Puoi anche eseguire:

     dbcc opentran() 

    Questo è un tipo di vecchia scuola, ma dovrebbe mostrare tutte le transactions a lungo termine in quel database. Documenti Microsoft che comandi qui .

    Vorrei fare in modo che ci sia un backup del registro che accada su un programma.

    Vorrei assicurarmi di dare il command TRUNCATE_ONLY un po 'di tempo per lavorare, a volte ci vuole un po' per SQL per iniziare a scrivere a un VLF verso la parte anteriore del file LDF. Se l'ultimo VLF nel file LDF è quello scritto, allora SQL non può abbreviare il file. In caso contrario, farei un BACKUP DATABASE completo (con COPY_ONLY o attendere che il backup normale avvenga, se non è troppo lontano in futuro). A volte sembra che il calcio inizia le cose, ma potrebbe essere che un backup mi distrae in attesa che l'attuale VLF si sposti nella parte anteriore del file LDF. Dopo che l'attuale VLF si sposta verso la parte anteriore del file LDF, dovresti essere in grado di utilizzare dbcc shrinkfile () e get il risultato previsto. Raccommand di cercare di rimuovere prima piccoli pezzi, piuttosto che cercare di fare tutto in un colpo.

    Inoltre, si vuole evitare di fare questo su base regolare, come entrare in un ciclo di ripetitive ritiro-autogruppo-ritiro-autogruppo può essere un killer di performance. (Può portre a file frammentati e il process di crescita effettivo può richiedere una quantità sorprendente, durante la quale nessuna transazione potrebbe essere in grado di impegnare. non si è affidato.

      Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.