Frage

Ich habe alle über das Internet gesucht, und ich kann nicht eine akzeptable Lösung für mein Problem finden, ich frage mich, ob es überhaupt eine Lösung ohne einen Kompromiss ist ...

Ich bin kein DBA, aber ich bin ein Ein-Mann-Team auf einer großen Website ohne zusätzliche Mittel für zusätzliche Stellen arbeiten, so dass ich tue, was ich kann.

Unser Backup-Plan saugt, und ich bin eine wirklich harte Zeit, es zu verbessern ist. Derzeit gibt es zwei Server mit SQL Server 2005 Ich habe eine gespiegelte Datenbank (kein Zeuge), das gut zu funktionieren scheint. Ich habe eine vollständige Sicherung am Mittag und um Mitternacht. Diese erhalten auf Band gesichert durch unsere Service-Provider jede Nacht, und ich brenne die Backup-Dateien auf DVD wöchentlich alte Aufzeichnungen auf der Hand zu halten. Schließlich würde ich Versand anmelden wechseln möchten, da die Spiegelung ohne Zeugenserver irgendwie sinnlos scheint.

Das Problem ist, dass das Transaktionsprotokoll non-stop wächst. Von der Forschung, die ich getan habe, so scheint es, dass ich nicht eine Protokolldatei einer gespiegelten Datenbank verkürzen kann. Also, wie verhindere ich die Datei von immer mehr!?

Basierend auf dieser Webseite habe ich versucht, dies:

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

Aber das hat nicht funktioniert. Alles andere, was ich gefunden habe, sagt, ich brauche den Spiegel zu deaktivieren, bevor das Sicherungsprotokoll Befehl in fahrbereitem Zustand für sie arbeiten.

Meine Frage (TL; DR)

Wie kann ich meine Transaktionsprotokolldatei verkleinern, ohne den Spiegel zu deaktivieren?

War es hilfreich?

Lösung 3

Ich dachte, ich sollte eigentlich dieses Sehen beantworten, wie es über links wurde vergessen.

Es stellte sich heraus, können Sie nicht ein T-log schrumpfen, wenn die Datenbank gespiegelt wird, wenn Sie den Spiegel deaktivieren. Wenn ich falsch bin, bitte korrigieren Sie mich, aber ich habe keine Lösung gefunden, die funktioniert!

Der Protokollversand ist der Weg zu gehen, wenn Sie nur zwei Server haben. Mirroring ist fast sinnlos ohne Zeugenserver, weil der einzige Weg von der Haupt Failover ist ... irgendwie besiegt den Zweck, einen Spiegel zu haben, wenn Sie nicht, wenn der Haupt Abstürze Failover können.

Wenn jemand kümmert sich mehr Informationen oder Anregungen zu diesem Thema zu teilen, werde ich willkommen sein, um sie zu hören.

Andere Tipps

Nun, technisch gesehen ist es möglich, ein gespiegeltes LOG zu schrumpfen. Was ist Ärger machen, ist zu Sicherungsprotokoll mit truncate_only. Mirroring ist es nicht akzeptieren. So ein Weg ist, ein Sicherungsprotokoll auf der Festplatte auszuführen:

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

Dieser Teil unserer aktuellen Wartungsplan ist und es withot Probleme für etwa 2 Jahre gearbeitet hat.

Wenn die Spiegel-Server-Instanz hinter der Prinzipalserverinstanz fällt, wird die Menge der aktiven Protokollspeicher wachsen. In diesem Fall müssen Sie die Datenbankspiegelung, nehmen Sie eine Log-Sicherung stoppen, die das Protokoll abschneidet, gelten diese Protokollsicherung auf der Spiegeldatenbank und starten Spiegelung nicht die Antwort, die Sie gehofft hatten, ich weiß = (

Um unsere Dateien schrumpfen könnten Sie das folgende Skript versuchen:

exec sp_dboption DBName, ‚trunc. anmelden chkpt. ', true Kontrollpunkt DBCC SHRINKFILE (DBNameFileName, 500); exec sp_dboption DBName, ‚trunc. anmelden chkpt. ', false

Hope, das hilft.

Es ist möglich, Transaktionsdatei für eine Datenbank mit Spiegel schrumpfen, Backup durchgeführt werden muss, da es Aktive virtuelle Protokolldatei ist: http: / /www.xoowiki.com/Article/SQL-Server/tronquer-journal-de-log-sur-base-en-miroir-499.aspx

  1. Set Spiegel Partner unter Verwendung .. ALTER [DatabaseName] SET PARTNER OFF
  2. off
  3. Nehmen Sie Transaktionsprotokollsicherung auf principal..BACKUP LOG [DatabaseName] TO DISK='Drive:\DatabaseName_log_datetime.trn'
  4. Kopieren Sie diesen DatabaseName_log_datetime.trn an einem beliebigen Ort auf dem Spiegel-Server.
  5. Wiederherstellen dieses Transactional Protokoll mit NoRecovery option..on Spiegeldatenbank. RESTORE LOG [DatabaseName] FROM DISK ='Drive:\DatabaseName_log_datetime.trn'
  6. Shrink-Datei auf Haupt & Spiegel-Server anmelden.
  7. Nehmen Sie Wieder Transaktionsprotokollsicherung auf principal..and Wiederherstellung dieses Transactional Protokoll mit keiner Erholung option..on gespiegelte Datenbank auf dem Spiegel-Server.
  8. Konfigurieren Mirroring Sicherheit.

einige Vorschläge in diesem Beitrag nicht getestet, fand ich, dass, nach dem vollständigen Sicherung, Checkpointbefehl und Transaktionsprotokollsicherung, die Hauptprotokollgröße Datenbanktransaktion geschrumpfte werden kann. Die Spiegeldatenbank Transaktionsprotokollgröße wird dann synchronisiert mit Haupt geschrumpfter Größe.

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);

Mit OSQL kann die oben genannten SQL-Befehle in DOS Batch ausführen, ist die WAITFOR DELAY ein Muss, wenn im Batch ausführen, z.

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;"

Ich denke, die anderen Backup auch gearbeitet werden sollte, aber prüft nicht. Die unten diff Sicherungsbefehl werden die Daten statt überschreiben hängen.

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

der einzige Weg: 1) Stop-Spiegelung 2) schrumpfen Dateien auf Haupt 3) vollständige Sicherung des Nennwerts + Transaktion JRNL 4) Anschlagspiegelserver, löschen MDF- und LDF von mirrorDatabase 5) beginnen mirrorser und löschen mirrorDatabase 6) wiederherstellen ohne Recovery Backups von 3) auf mirroServer 7) neu installiert Spiegelung Ouf!

Es ist wahr, dass Sie nicht das Datenbank-Protokoll schrumpfen können, wenn es zu groß bekommt ist - an diesem Punkt Ich denke, die einzige Möglichkeit ist, den Spiegel zu brechen, schrumpft und neu zu erstellen. Ferner trotz der Probleme, ob Sie sollte mit nur zwei Servern mit zu spiegeln, was ich sagen kann, ist, dass, wenn Sie tun, dann regelmäßig Sicherungs das Transaktionsprotokoll. Der Raum wird von ihm freigegeben werden, wodurch MSSQL ermöglicht innerhalb der Protokolldatei den toten Raum wieder zu verwenden. Dies hat nichts schrumpfen, aber es erfüllt die Anforderung des Anhaltens es wächst.

Dann alles, was Sie tun müssen, ist regelmäßig die Datei-Backups löschen. Zum Beispiel könnten Sie dies tun:

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

Do it out von Stunden, obwohl, wenn Sie können.

Ich weiß nicht, warum das funktioniert, nur dass es tatsächlich funktioniert. Ich betreiben diese als Block in einem Abfragefenster. Verwenden Sie in Ihrem eigenen Ermessen. Sicher wäre schön, wenn ein Microsoftie würde kommentieren.

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
  )

Sie können nicht wirklich etwas auf eine gespiegelte Datenbank tun, ohne sie aus dem Spiegel zu nehmen, solange es nicht die Hauptdatenbank ist.

Was sollte, ist arbeiten, wenn Sie ein Backup Ihrer Datenbanken auf dem Prinzipalserver og Sie eine danach schrumpfen. Dh Ihr Wartungsplan sollte eini schrumpf Job sind. Diese Änderungen sollten automatisch auf den sekundären (Spiegel) -Server verwinden durch Synchronisieren.

Wenn Sie eine Schrumpfung machen, die nur die Transaktionsdatei schrumpfen Sie folgenden T-SQL verwenden kann:

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

Dann nutzen Sie genau das Snippet für jede Datenbank und führen Sie es direkt nach dem Backup ausgeführt hat.

Das sollte die Protokolldatei klein auf dem Prinzipalserver halten und damit auf dem sekundären / Spiegel-Server.

Ich hoffe, das hilft.

Btw. Wenn Sie auf den Punkt bekommen haben, wo es keinen Platz auf dem Datenträger für die Protokolldateien vorhanden ist, ist die einzige Option, um es aus Spiegelmodus zu nehmen, um die Datenbank zu einfachen Wiederherstellungsmodus eingestellt ist, um die Protokolldatei verkleinern, setzen Sie sich auf volles Recovery-Modus wieder und Setup erneut der Spiegel (Sicherungen der Datenbank og Protokolldatei auf dem Spiegelserver wiederherstellen verwenden).

Futhermore Sie eine SQL Express als Zeuge Server verwenden können, wenn das Problem Lizenzierung. Es sollte nicht zu viele Ressourcen benötigen, so dass Sie einen Webserver verwenden können, wenn dies eine Web-Anwendung ist. Denken Sie daran, auch die Protokolldateien für den Zeugenserver zu beobachten.

** Schrumpfen kann in Spiegelung durchgeführt werden, was wir nicht können, ist das Protokoll gestutzt, als das Protokoll ist das, was an den Spiegelserver ausgeliefert wird und wartet dann auf der Haupt die Bestätigung.

Eine Lösung für das Problem ist für die Sicherung des Protokoll ohne truncate und dann die Protokolldatei schrumpft, oder Sie können sogar das Schrumpfen ignorieren. Wenn das nicht funktioniert, versuchen Sie einen Kontrollpunkt vor Ihrem Log sichern. Dies sollte funktionieren ...

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top