Riduzione del registro delle transazioni di un database di SQL Server 2005 con mirroring

StackOverflow https://stackoverflow.com/questions/1033158

Domanda

Ho cercato su Internet e non riesco a trovare una soluzione accettabile al mio problema, mi chiedo se esiste anche una soluzione senza compromessi ...

Non sono un DBA, ma sono un team composto da un solo uomo che lavora su un enorme sito Web senza finanziamenti extra per altri enti, quindi sto facendo del mio meglio.

Il nostro piano di backup fa schifo e sto facendo davvero fatica a migliorarlo. Attualmente, ci sono due server che eseguono SQL Server 2005. Ho un database con mirroring (nessun testimone) che sembra funzionare bene. Faccio un backup completo a mezzogiorno ea mezzanotte. Questi vengono sottoposti a backup su nastro dal nostro fornitore di servizi ogni notte e masterizzo i file di backup su dvd settimanalmente per tenere a portata di mano i vecchi record. Alla fine vorrei passare al log shipping, dato che il mirroring sembra un po 'inutile senza un server di controllo.

Il problema è che il registro delle transazioni sta crescendo ininterrottamente. Dalla ricerca che ho fatto, sembra che non riesca a troncare un file di registro di un database con mirroring. Quindi, come posso impedire la crescita del file !?

Basato su questa pagina web , ho provato questo: 

USE dbname
GO
CHECKPOINT
GO
BACKUP LOG dbname TO DISK='NULL' WITH NOFORMAT, INIT, NAME = N'dbnameLog Backup', SKIP, NOREWIND, NOUNLOAD
GO
DBCC SHRINKFILE('dbname_Log', 2048)
GO

Ma non ha funzionato. Tutto il resto che ho trovato dice che devo disabilitare il mirror prima di eseguire il comando di registro di backup affinché funzioni.

La mia domanda (TL; DR)

Come posso ridurre il mio file di registro delle transazioni senza disabilitare il mirror?

È stato utile?

Soluzione 3

Pensavo di dover effettivamente rispondere a questa visione poiché è stata dimenticata.

Si scopre che non è possibile ridurre un registro t se il database è speculare a meno che non si disattivi il mirror. Se sbaglio, per favore correggimi, ma non ho trovato nessuna soluzione che funzioni!

La spedizione dei log è la strada da percorrere se hai solo due server. Il mirroring è quasi inutile senza un server di controllo, perché l'unico modo per eseguire il failover è dal principale ... kinda sconfigge lo scopo di avere un mirror se non è possibile eseguire il failover in caso di crash del principale.

Se qualcuno si preoccupa di condividere maggiori informazioni o suggerimenti in merito, saremo lieti di ascoltarli.

Altri suggerimenti

Beh, tecnicamente è possibile ridurre un LOG con mirroring. Ciò che sta causando problemi è il backup del registro con truncate_only. Il mirroring non lo accetta. Quindi un modo è quello di eseguire un registro di backup su disco: 

use [DATABASE_NAME]
checkpoint
BACKUP LOG [DATABASE_NAME] TO DISK =  'C:\LOG_BACKUPS\DATABASE_NAME'
dbcc shrinkfile(DATABASE_NAME_Log,1)

Fa parte del nostro attuale piano di manutenzione e ha funzionato senza problemi per circa 2 anni.

Se l'istanza del server mirror è in ritardo rispetto all'istanza del server principale, la quantità di spazio di registro attivo aumenterà. In questo caso, potrebbe essere necessario interrompere il mirroring del database, eseguire un backup del log che tronca il log, applicare quel backup del log al database mirror e riavviare il mirroring, non la risposta che speravi, lo so = (

Per ridurre i nostri file puoi provare il seguente script:

exec sp_dboption DBName, 'trunc. accedi chkpt. ', vero posto di controllo DBCC SHRINKFILE (DBNameFileName, 500); exec sp_dboption DBName, 'trunc. accedi chkpt. ', false

Spero che questo aiuti.

È possibile ridurre il file di transazione per un database con mirror, il backup deve essere eseguito in quanto sono presenti file di registro virtuale attivi: http: / /www.xoowiki.com/Article/SQL-Server/tronquer-journal-de-log-sur-base-en-miroir-499.aspx

  1. Disattiva il mirror partner utilizzando .. ALTER [DatabaseName] DISATTIVA PARTNER
  2. Esegui il backup del registro delle transazioni sul principale .. BACKUP LOG [DatabaseName] TO DISK = 'Drive: \ DatabaseName_log_datetime.trn'
  3. Copia questo DatabaseName_log_datetime.trn in qualsiasi posizione sul server mirror.
  4. Ripristina questo registro transazionale con l'opzione NoRecovery sul database mirror. RIPRISTINA LOG [DatabaseName] FROM DISK = 'Unità: \ DatabaseName_log_datetime.trn'
  5. Riduci il file di registro sull'entità & amp; server mirror.
  6. Ancora una volta Esegui il backup del log delle transazioni su principal..e ripristina questo log transazionale con l'opzione No Recovery ... sul database con mirroring sul server mirror.
  7. Configura sicurezza mirroring.

Testato alcuni suggerimenti in questo post, ho scoperto che, dopo il backup completo, il comando checkpoint e il backup del registro delle transazioni, è possibile ridurre le dimensioni del registro delle transazioni del database principale. La dimensione del registro delle transazioni del database mirror viene quindi sincronizzata con la dimensione ridotta principale. 

USE [DATABASE_NAME];
BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_FULL.bak' WITH FORMAT;
CHECKPOINT;
WAITFOR DELAY '00:00:02';
BACKUP LOG [DATABASE_NAME] TO DISK = 'E:\Backup\DATABASE_NAME_TL.trn';
WAITFOR DELAY '00:00:02';
DBCC SHRINKFILE('DATABASE_NAME_log', 500);

L'uso di OSQL può eseguire i comandi SQL sopra riportati in batch DOS, il WAITFOR DELAY è un must se eseguito in batch, ad es. 

C:\Program Files\Microsoft SQL Server\100\Tools\Binn\osql.exe -E -S "DATABASE_SERVER" -Q "USE [DATABASE_NAME]; BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_FULL.bak' WITH FORMAT;"

Penso che anche i diversi backup dovrebbero funzionare, ma non li testano. Il seguente comando di backup diff aggiungerà i dati invece di sovrascriverli. 

BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_DIFF.bak' WITH DIFFERENTIAL;

l'unico modo: 1) Interrompere il mirroring 2) ridurre i file sul principal 3) backup completo di principal, + transazione jrnl 4) arrestare il server mirror, eliminare mdf e ldf di mirrorDatabase 5) avviare mirrororser ed eliminare mirrorDatabase 6) ripristinare senza backup di ripristino di 3) su mirroServer 7) reinstallare il mirroring Ouf!

È vero che non è possibile ridurre il registro del database una volta che è diventato troppo grande - a quel punto penso che l'unica opzione sia quella di rompere il mirror, restringere e ricreare. Inoltre, nonostante il fatto che tu abbia pensato di utilizzare il mirroring con solo due server, ciò che posso dire è che se lo fai, esegui regolarmente il backup del registro delle transazioni. Lo spazio verrà rilasciato da esso consentendo così a MSSQL di riutilizzare lo spazio morto all'interno del file di registro. Questo non riduce nulla ma soddisfa il requisito di fermarlo in crescita.

Quindi tutto ciò che devi fare è eliminare regolarmente i backup dei file. Ad esempio potresti farlo: 

USE your_database
GO
BACKUP LOG your_database TO DISK = 'x:\your_backup_filepath\your_database.tlog'
GO

Se possibile, fallo fuori orario.

Non so perché funzioni, solo che funziona davvero. Lo eseguo come un blocco in una finestra di query. Usalo a tua discrezione. Sarebbe bello se un microsoftie commentasse. 

use my_database
dbcc shrinkfile ( my_database_log, 1000 )
use my_database
dbcc shrinkfile ( my_database_log, 1000 )
alter database my_database
  modify file ( 
    name = my_database_log, 
    size = 1000MB
  )

Non puoi davvero fare nulla su un database con mirroring senza estrarlo dal mirror, purché non sia il database principale.

Ciò che dovrebbe funzionare è se si esegue il backup dei database sul server principale o si fa successivamente una riduzione. Vale a dire il tuo piano di manutenzione dovrebbe includere un lavoro in calo. Tali modifiche dovrebbero passare automaticamente al server secondario (mirror) mediante la sincronizzazione.

Se si desidera effettuare una riduzione che riduce solo il file di transazione, è possibile utilizzare il seguente T-SQL: 

USE [your_db_name]
GO
DBCC SHRINKFILE (N'your_db_name_logfile' , 0, TRUNCATEONLY)
GO

Quindi basta usare quel frammento per ciascun database ed eseguirlo subito dopo l'esecuzione del backup.

Ciò dovrebbe mantenere il file di registro piccolo sul server principale e quindi sul server secondario / mirror.

Spero che questo aiuti.

Btw. Se sei arrivato al punto in cui non c'è spazio sul disco per i file di registro, l'unica opzione è quella di uscire dalla modalità mirror, impostare il database in modalità di recupero semplice, ridurre il file di registro, impostarlo su pieno modalità di ripristino di nuovo e configurare nuovamente il mirror (utilizzando i backup del file di registro del database per ripristinare sul server mirror).

Inoltre è possibile utilizzare un SQL Express come server di controllo, se il problema riguarda le licenze. Non dovrebbe richiedere troppe risorse, quindi potresti usare un server web, se questa è un'applicazione web. Ricorda solo di guardare anche i file di registro per il server di controllo.

** la riduzione può essere eseguita nel mirroring, ciò che non possiamo fare è troncare il registro, poiché il registro è ciò che viene spedito al server mirror e quindi l'entità attende il riconoscimento.

Una soluzione al problema è il backup del registro senza troncamento e quindi la riduzione del file di registro, oppure è possibile anche ignorare la riduzione. Se il problema persiste, provare un checkpoint prima di eseguire il backup del registro. Questo dovrebbe funzionare ...

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top