Wie löschen Sie das SQL Server-Transaktionsprotokoll?

https://stackoverflow.com/questions/56628

09-06-2019
|

Frage

Ich bin kein SQL-Experte, und ich denke an die Tatsache jedes mal, wenn ich etwas zu tun, über die Grundlagen hinaus.Ich habe eine test-Datenbank, die nicht groß in der Größe, aber das Transaktionsprotokoll ist definitiv.Wie lösche ich aus dem Transaktionsprotokoll?

Lösung

eine Protokolldatei kleiner machen sollte wirklich für Szenarien reserviert werden, wo es unerwartetes Wachstum begegnet, die Sie nicht erwarten, wieder zu passieren. Wenn die Protokolldatei wieder auf die gleiche Größe wachsen wird, nicht sehr viel durch Schrumpfen es vorübergehend erreicht. Nun, je nach den Wiederherstellungszielen Ihrer Datenbank, das sind die Aktionen, die Sie sollten nehmen.

Nehmen Sie zuerst eine vollständige Sicherung

Sie keine Änderungen an der Datenbank vornehmen, ohne sicherzustellen, dass Sie es wiederherstellen sollte etwas schief gehen.

Wenn Sie kümmern sich um Point-in-Time-Recovery

(Und von Point-in-Time-Recovery, ich meine, Sie kümmern sich um die Lage, etwas anderes als eine vollständige oder differenzielle Sicherung wiederherstellen.)

Vermutlich Ihre Datenbank ist in FULL Recovery-Modus. Wenn nicht, dann stellen Sie sicher, es ist:

ALTER DATABASE testdb SET RECOVERY FULL;

Auch wenn Sie regelmäßig vollständige Backups einnehmen, wird die Protokolldatei wachsen und wachsen, bis Sie eine ausführen log Backup - das ist für Ihren Schutz ist, nicht unnötig weg zu essen auf Ihren Speicherplatz. Sie sollten diese Protokollsicherungen ziemlich häufig durchführen, entsprechend Ihrer Recovery-Ziele. Zum Beispiel, wenn Sie ein Unternehmen haben in der Regel, die Sie besagt, kann nicht mehr als 15 Minuten von Daten im Fall einer Katastrophe leisten zu verlieren, sollten Sie einen Job haben, dass das Protokoll alle 15 Minuten sichert. Hier ist ein Skript, das Namen timestamped Datei auf Basis der aktuellen Zeit generieren (aber Sie können dies auch mit Wartungsplänen usw., nur nicht wählen, eine der Schrumpfoptionen in Wartungspläne, sie sind schrecklich).

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

Beachten Sie, dass \\backup_share\ auf einer andere Maschine sein soll, die ein anderes zugrunde liegendes Speichergerät darstellt. Sichern diese auf die gleiche Maschine (oder auf eine andere Maschine, die die gleichen zugrunde liegenden Platten oder eine andere VM verwendet, die auf demselben physischen Host ist), die Ihnen nicht wirklich helfen, denn wenn die Maschine bläst, haben Sie Ihre Datenbank verloren und seine Backups. Je nach Netzwerkinfrastruktur kann es sinnvoller Backup lokal machen und sie dann übertragen auf eine andere Position hinter den Kulissen; in jedem Fall, wollen Sie sie aus der primären Datenbank-Maschine so schnell wie möglich erhalten.

Nun, wenn Sie regelmäßige Protokollsicherungen ausgeführt haben, sollte es sinnvoll sein, die Protokolldatei zu etwas günstiger als schrumpfen, was es gesprengt ist jetzt. Dies gilt nicht bedeuten läuft SHRINKFILE immer und immer wieder, bis die Protokolldatei 1 MB ist - selbst wenn Sie das Protokoll wird häufig sichern, es muss noch die Summe aller gleichzeitig ablaufenden Transaktionen aufzunehmen, die auftreten können. Log-Datei automatische Vergrößerung Ereignisse teuer sind, da SQL Server die Dateien auf Null aus haben (im Gegensatz zu Daten-Dateien, wenn die sofortige Dateiinitialisierung aktiviert ist), und Benutzertransaktionen warten müssen, während dies geschieht. Sie wollen, dies zu tun Anwachsbereich schrumpf wachsen Schrumpf Routine so wenig wie möglich, und Sie wollen sicher nicht Ihre Nutzer dafür bezahlen machen.

Beachten Sie, dass Sie möglicherweise das Protokoll zweimal vor einem Schrumpf sichern möglich ist (dank Robert).

So müssen Sie mit einer praktischen Größe für Ihre Log-Datei kommen. Niemand hier können Ihnen sagen, was das ist, ohne viel mehr über Ihr System zu wissen, aber wenn Sie häufig die Protokolldatei schrumpf worden sind und es hat wieder wächst, ein gutes Wasserzeichen ist wahrscheinlich 10-50% höher als die größten es war . Lassen Sie uns sagen, dass bis zu 200 MB kommt, und Sie wollen alle nachfolgenden Ereignisse automatische Vergrößerung 50 MB sein, dann können Sie die Größe der Protokolldatei auf diese Weise einstellen:

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

Beachten Sie, dass, wenn die Protokolldatei derzeit> 200 MB, können Sie ausführen müssen diese zuerst:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

Wenn Sie kümmern sich nicht um Point-in-Time-Recovery

Wenn dies eine Testdatenbank, und Sie kümmern sich nicht um Point-in-Time-Recovery, dann sollten Sie sicherstellen, dass Ihre Datenbank in SIMPLE Recovery-Modus.

ALTER DATABASE testdb SET RECOVERY SIMPLE;

Setzen Sie die Datenbank in SIMPLE Recovery-Modus wird sicherstellen, dass SQL Server erneut verwendet Teile der Protokolldatei (im Wesentlichen inaktive Transaktionen Phasing-out) statt zu wachsen, einen Datensatz zu halten von alle Transaktionen (wie FULL Erholung tut, bis Sie wieder nach oben das Protokoll). CHECKPOINT Ereignisse werden helfen, das Protokoll zu steuern und stellen Sie sicher, dass es nicht zu wachsen braucht es sei denn, Sie viele t-Protokollaktivität zwischen CHECKPOINTs erzeugen.

Als nächstes sollten Sie unbedingt darauf achten, dass dieses Protokoll Wachstum wirklich aufgrund eines abnormalen Ereignis war (etwa eine jährliche Frühjahrsputz oder Wiederaufbau Ihre größte Indizes) und nicht aufgrund des normalen, alltäglichen Gebrauchs. Wenn Sie die Protokolldatei auf eine lächerlich geringe Größe schrumpfen, und SQL Server hat nur um es zu wachsen wieder Ihre normale Tätigkeit aufzunehmen, was haben Sie erreicht? Konnten Sie Verwendung dieser Speicherplatz Sie nur vorübergehend freigegeben machen? Wenn Sie eine sofortige Korrektur benötigen, dann können Sie den folgenden:

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO

Andernfalls setzen eine angemessene Größe und Wachstumsrate. Gemäß dem Beispiel in dem Point-in-Time-Recovery Fall können Sie den gleichen Code und Logik verwenden, um zu bestimmen, welche Dateigröße angemessen und zumutbar automatische Vergrößerung Parameter eingestellt wird.

Einige Dinge, die Sie nicht wollen,

tun

Sichern Sie das Protokoll mit TRUNCATE_ONLY Option und dann SHRINKFILE . Zum einen hat sich diese TRUNCATE_ONLY Option veraltet und ist nicht mehr in den aktuellen Versionen von SQL Server. Zweitens, wenn Sie in FULL Wiederherstellungsmodell, wird dies Ihre Log-Kette zerstören und eine neue, vollständige Sicherung erforderlich ist.
die Datenbank trennen, die Protokolldatei löschen und neu befestigen . Ich kann gar nicht genug betonen, wie gefährlich das sein kann. Ihre Datenbank kann nicht wieder nach oben kommen, kann es als verdächtig kommen, Sie zu einem Backup wiederherstellen müssen können (falls Sie eine haben), usw. usw.
Verwenden Sie "schrumpfen Datenbank" Option . DBCC SHRINKDATABASE und die Option Wartungsplan die gleichen sind schlechte Ideen zu tun, vor allem, wenn Sie wirklich brauchen, um nur ein Protokoll Problem Problem zu beheben. Richten Sie die Datei, die Sie anpassen möchten, und stellen Sie es unabhängig, DBCC SHRINKFILE oder ALTER DATABASE ... MODIFY FILE mit (Beispiele oben).
Verkleinern Sie die Log-Datei auf 1 MB . Das sieht verlockend, weil, hey, SQL Server ich es in bestimmten Szenarien tun lassen, und schauen Sie sich alle den Raum es befreit! Es sei denn, Ihre Datenbank nur gelesen wird (und es ist, sollten Sie es als solche mit ALTER DATABASE markieren), wird dies absolut einfach zu vielen unnötiges Wachstum Ereignisse führen, da das Protokoll laufende Transaktionen unabhängig von dem Wiederherstellungsmodell aufnehmen muss. Was ist der Punkt der Befreiung vorübergehend, dass der Raum nach oben, nur so SQL Server kann es zurücknehmen langsam und schmerzhaft?
Erstellen Sie eine zweite Protokolldatei . Dies wird vorübergehend Entlastung für das Laufwerk, das die Festplatte voll ist, aber das ist wie der Versuch, eine punktierte Lunge mit einem Band-Aid zu beheben. Sie sollten direkt statt nur mit der problematischen Protokolldatei befassen ein anderes potenzielles Problem hinzufügen. Anders als einiges Transaktionsprotokoll Aktivität auf ein anderes Laufwerk umleiten, tut eine zweite Protokolldatei wirklich nichts für Sie (im Gegensatz zu einer Datei zweiten Daten), da nur eine der Dateien immer zu einem Zeitpunkt verwendet werden kann. Paul Randal erklärt auch, warum mehrere Protokolldateien beißen Sie später .

Seien Sie proaktiv

Stattdessen Ihre Log-Datei auf eine kleine Menge an Schrumpfung und ließ sie ständig mit einem kleinen Preis für seine eigene automatische Vergrößerung, setzen Sie ihn auf einige ziemlich große Größe (eine, die die Summe Ihrer größten Satz von gleichzeitig ablaufenden Transaktionen wird Platz) und stellen eine vernünftige automatische Vergrößerung als Ausweich Einstellung, so dass es nicht mehr Male muss wächst einzelne Transaktionen zu erfüllen und so, dass es relativ selten sein wird,es jemals während der normalen Geschäftsbetriebes zu wachsen hat.

Die schlimmsten möglichen Einstellungen hier sind 1 MB Wachstum oder Wachstum von 10%. Lustig genug, das sind die Standardeinstellungen für SQL Server (die ich über und fragte ohne Erfolg für Änderungen ) - 1 MB für Datendateien und 10% für die Log-Dateien. Ersteres ist viel zu klein, in der heutigen Zeit, und dieser führt jedes Mal länger und länger Ereignisse (zum Beispiel Ihre Log-Datei ist 500 MB, erste Wachstum ist 50 MB, das nächste Wachstum 55 MB, das nächste Wachstum beträgt 60,5 MB usw. usw. -. und auf langsame I / O, glauben Sie mir, Sie wirklich diese Kurve bemerken)

Weiterführende Literatur

Bitte hör nicht hier; während ein großer Teil der Beratung Log-Dateien über schrumpf Sie da draußen sehen von Natur aus schlecht ist und sogar potenziell katastrophal, gibt es einige Leute, die als Freisetzung von Speicherplatz mehr über die Datenintegrität sorgen.

ein Blog-Post ich 2009 schrieb, als ich ein paar sah „ist hier, wie die Protokolldatei schrumpfen“ Beiträge sprießen.

einem Blog-Post Brent Ozar vor vier Jahren schrieb, indem er auf mehrere Ressourcen, in Reaktion auf ein SQL Server Magazine Artikel, der sollte nicht veröffentlicht worden.

Ein Blog-Eintrag von Paul Randal erklären warum t-log Wartung ist wichtig und , warum sollten Sie Ihre Datendateien, entweder nicht schrumpfen.

Mike Walsh hat eine große Antwort Abdeckung auch einige dieser Aspekte, einschließlich der Gründe, warum Sie nicht in der Lage sein könnte, Ihre Log-Datei sofort schrumpfen.

Andere Tipps

HAFTUNGSAUSSCHLUSS: Bitte lesen Sie unten sorgfältig Kommentare, und ich nehme an, Sie haben bereits die akzeptierte Antwort lesen. Wie gesagt fast 5 Jahren:

, wenn jemand irgendwelche Kommentare zu Situationen hinzufügen, wenn dies keine ist ausreichend oder optimale Lösung bitte unten dann kommentieren

Rechtsklick auf den Namen der Datenbank.
Wählen Sie Aufgaben → Shrink → Datenbank
Klicken Sie dann auf OK

ich in der Regel den Windows-Explorer öffnen Verzeichnis die Datenbank-Dateien enthalten, so kann ich sofort den Effekt sehen.

Ich war eigentlich ziemlich überrascht, das hat geklappt! Normalerweise DBCC Ich habe vorher benutzt, aber ich habe gerade versucht, dass und es hat nichts schrumpfen, so habe ich versucht, die GUI (2005) und es funktionierte großartig - die Freisetzung 17 GB in 10 Sekunden

In Full Recovery-Modus kann dies nicht funktionieren, so dass Sie entweder auf das Protokoll sichern ersten oder auf einfache Wiederherstellung ändern, dann die Datei verkleinern. [Dank @onupdatecascade für diese]

PS: Ich schätze, was einige in Bezug auf die Gefahren dieses kommentiert haben, aber in meinem Umfeld habe ich habe keine Probleme vor allem diese selbst zu tun, da ich immer zuerst eine vollständige Sicherung. Also bitte berücksichtigen Sie, was Ihre Umgebung ist, und welche Auswirkungen dies auf Ihre Backup-Strategie und die Arbeitsplatzsicherheit, bevor Sie fortfahren. Alles, was ich tat, war zeigt Menschen auf ein Feature von Microsoft!

USE AdventureWorks2008R2;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2008R2_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY FULL;
GO

Von: DBCC SHRINKFILE (Transact-SQL)

Sie können zunächst sichern möchten.

Im Folgenden finden Sie ein Skript, das Transaktionsprotokoll schrumpfen, aber ich würde auf jeden Fall vor dem Schrumpfen es das Transaktionsprotokoll zu sichern empfehlen.

Wenn Sie nur schrumpfen die Datei, die Sie eine Tonne von Daten verlieren werden, die als Lebensretter im Fall einer Katastrophe kommen können. Das Transaktionsprotokoll enthält eine Menge nützlicher Daten, die ein Drittanbieter-Transaktionsprotokoll-Lesegerät gelesen werden können unter Verwendung von (manuell gelesen werden kann, aber mit äußerster Anstrengung obwohl).

Das Transaktionsprotokoll ist auch ein Muss, wenn es in-Time-Recovery-zu-Punkt kommt, also nicht nur werfen es weg, aber stellen Sie sicher, dass Sie wieder es vorher auf.

Hier sind mehrere Stellen, wo die Menschen Daten im Transaktionsprotokoll gespeichert verwendet Erholung zu erreichen:

USE DATABASE_NAME;
GO

ALTER DATABASE DATABASE_NAME
SET RECOVERY SIMPLE;
GO
--First parameter is log file name and second is size in MB
DBCC SHRINKFILE (DATABASE_NAME_Log, 1);

ALTER DATABASE DATABASE_NAME
SET RECOVERY FULL;
GO

Sie können einen Fehler, der so aussieht, wenn die Ausführung von Befehlen über

„Kann schrumpfen nicht Protokolldatei (log file name), weil die logische Protokolldatei am Ende der Datei befindet sich in Verwendung „

Das bedeutet, dass TLOG in Gebrauch ist. In diesem Fall versuchen Sie dies mehrere Male in Folge der Ausführung oder einen Weg finden, um Datenbankaktivitäten zu reduzieren.

Wenn Sie nicht über die Transaktionsprotokolle für Wiederherstellungen verwenden (das heißt Sie immer nur tun vollständige Sicherungen), können Sie Wiederherstellungsmodus auf „Simple“, und das Transaktionsprotokoll wird in Kürze schrumpfen und nie wieder aufzufüllen.

Wenn Sie SQL 7 oder 2000 verwenden, können Sie die Option „Protokoll bei Prüfpunkt abschneiden“ in der Datenbankoptionen Registerkarte. Dies hat den gleichen Effekt.

Dies ist nicht offensichtlich in Produktionsumgebungen empfohlen, da Sie nicht in der Lage sein wird, zu einem Zeitpunkt wiederherzustellen.

Hier ist eine einfache und sehr unelegant & potenziell gefährlich Art und Weise.

Backup DB
Detach DB
Umbenennen Log-Datei
Anhängen DB
Neue Protokolldatei neu erstellt werden
Löschen Renamed Log-Datei.

Ich vermute, dass Sie nicht Protokollsicherungen tun. (Welche gestutzt das Protokoll). Mein Rat ist, Wiederherstellungsmodell von rel="noreferrer"> auf einfach . Dies wird log aufblasen verhindern.

hier Die meisten Antworten so weit sind, vorausgesetzt, Sie sind nicht wirklich die Transaktionsprotokolldatei benötigen, aber wenn Sie Ihre Datenbank, um die FULL Wiederherstellungsmodell verwendet, und Sie möchten, dass Ihre Backups zu halten, falls Sie die Datenbank wiederherstellen müssen, dann nicht gestutzt oder die Protokolldatei die Art und Weise viele dieser Antworten vorschlagen löschen.

Die Beseitigung der Protokolldatei (durch sie abzuschneiden, sie zu verwerfen, löschen sie, usw.) werden Ihre Backup-Kette brechen, und werden Sie von der Wiederherstellung zu jedem Zeitpunkt seit dem letzten vollständigen, oder Transaktionsprotokollsicherung verhindern, bis die nächste vollständige oder differenzielle Sicherung wird.

Aus dem Microsoft-Artikel onBACKUP

Wir empfehlen, dass Sie nie NO_LOG oder TRUNCATE_ONLY verwenden manuell gestutzt, das Transaktionsprotokoll, da dies die Protokollkette bricht. Bis die nächste vollständige oder differenzielle Datenbanksicherung ist die Datenbank nicht geschützt von Medienfehlern. Verwenden Abschneiden manuelle Einbuchungs in nur sehr besondere Umstände, und sofort Backups der Daten erstellen.

Um das zu vermeiden, sichern Sie Ihre Log-Datei auf der Festplatte , bevor es zu schrumpfen. Die Syntax etwas wie folgt aussehen:

BACKUP LOG MyDatabaseName 
TO DISK='C:\DatabaseBackups\MyDatabaseName_backup_2013_01_31_095212_8797154.trn'

DBCC SHRINKFILE (N'MyDatabaseName_Log', 200)

Das SQL Server-Transaktionsprotokoll muss ordnungsgemäß beibehalten werden, um ihr unerwünschtes Wachstum zu verhindern. Dies bedeutet oft genug Transaktionsprotokollsicherungen ausgeführt werden. Durch das nicht tun, riskieren Sie das Transaktionsprotokoll voll zu werden und zu wachsen beginnen.

Neben den Antworten auf diese Frage, die ich empfehle die Lektüre und das Verständnis des Transaktionsprotokoll gemeinsame Mythen. Diese Messwerte können das Transaktionsprotokoll helfen zu verstehen und zu entscheiden, welche Techniken zu verwenden, um „klar“ es:

Von 10 wichtigsten SQL Server-Transaktion log Mythen :

Mythos: My SQL Server ist zu beschäftigt. Ich möchte nicht SQL Server-Transaktionsprotokollsicherungen
machen
Eine der größten Leistung intensiven Operationen in SQL Server ist ein Auto-grow-Ereignis der Online-Transaktionsprotokolldatei. Durch den Verzicht auf Transaktionsprotokollsicherungen oft genug zu machen, wird das Online-Transaktionsprotokoll voll werden und wachsen muß. Die Standard-Wachstumsgröße beträgt 10%. Die belebt die Datenbank ist, desto schneller ist das Online-Transaktionsprotokoll wird wachsen, wenn Transaktionsprotokollsicherungen nicht erstellt werden   nicht blockiert eine SQL Server-Transaktionsprotokollsicherung Erstellen das Online-Transaktionsprotokoll, sondern ein Auto-Wachstum Ereignis macht. Es kann alle Aktivitäten in dem Online-Transaktionsprotokoll blockieren

Von Transaktionslogdateien Mythen :

Mythos: Regelmäßige log Schrumpfen ist eine gute Wartung der Praxis


FALSCH. Log Wachstum ist sehr teuer, weil der neue Brocken genullt-out sein muss. Alle Schreibaktivität stoppt auf diese Datenbank, bis Nullbewertung abgeschlossen ist, und wenn Ihr Plattenschreib langsam ist oder automatische Vergrößerung Größe ist groß, kann diese Pause sehr groß sein und Anwender werden feststellen. Das ist ein Grund, warum Sie wollen Wachstum zu vermeiden. Wenn Sie das Protokoll schrumpfen, wird es wachsen wieder, und Sie verschwenden nur Plattenbetrieb auf unnötigen schrumpf und wächst wieder Spiel

Diese Technik, die John empfiehlt wird nicht empfohlen, da es keine Garantie dafür gibt, dass die Datenbank ohne die Log-Datei angehängt werden kann. Ändern Sie die Datenbank von voll zu einfach, einen Checkpoint zwingen, und ein paar Minuten warten. Der SQL-Server wird das Protokoll löschen, die Sie dann schrumpfen können DBCC SHRINKFILE mit.

Sie zuerst die Datenbank-Recovery-Modell überprüfen. Standardmäßig erstellt SQL Server Express Edition eine Datenbank für die einfache Wiederherstellung Modell (wenn ich mich nicht irre).

Backup log Database Mit truncate_only:

DBCC ShrinkFile(yourLogical_LogFileName, 50)

sp_helpfile geben Ihnen die logischen Protokolldateinamen.

Siehe auch:

wiederherstellen von einem vollständigen Transaktionsprotokoll in einer SQL Server-Datenbank

Wenn Sie Ihre Datenbank in vollständigem Wiederherstellungsmodell und wenn Sie nicht TL Sicherung nehmen, dann auf SIMPLE ändern.

Mit dem DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY) Befehl. Wenn dies eine Testdatenbank ist und Sie versuchen, um Platz zu sparen / zu, dies wird dazu beitragen.

Denken Sie jedoch daran, dass die TX-Protokolle habe eine Art von Minimum / Steady-State-Größe, die sie aufwachsen. Je nach Ihrem Wiederherstellungsmodell können Sie nicht in der Lage sein, um das Protokoll zu schrumpfen - wenn in FULL und Sie die Ausgabe nicht TX Protokollsicherungen das Protokoll kann nicht verkleinert werden - es für immer wachsen wird. Wenn Sie benötigen TX Protokollsicherungen nicht, schalten Sie das Wiederherstellungsmodell auf Einfach .

Und denken Sie daran, nie unter keinen Umständen das Protokoll (LDF) Datei löschen! Sie haben ziemlich viel Instant-Datenbank Korruption. Gekocht! Getan! Verlorene Daten! Wenn links „nicht repariert“ die Haupt MDF-Datei dauerhaft beschädigt werden könnte.

Sie niemals das Transaktionsprotokoll löschen - Sie werden Daten verlieren! Ein Teil Ihrer Daten ist in dem TX-Log (unabhängig vom Wiederherstellungsmodell) ... wenn Sie trennen und „Umbenennen“ TX Protokolldatei, die effektiv löscht Teil Ihrer Datenbank.

Für diejenigen, die die TX Log gelöscht haben, möchten Sie vielleicht ein paar checkdb Befehle auszuführen und die Korruption zu beheben, bevor Sie mehr Daten verloren gehen.

Überprüfen Sie heraus Paul Randals Blog-Beiträge auf diesem Thema, schlechte Beratung .

Auch in der Regel nicht auf den MDF-Dateien verwenden shrinkfile, wie es schwer Ihre Daten fragmentieren kann. Schauen Sie sich seinen Bad Beratungsbereich für weitere Informationen ( „Warum sollten Sie nicht Ihre Dateien schrumpfen“)

Schauen Sie sich Paul Webseite - er deckt diese sehr Fragen. Im vergangenen Monat ging er durch viele dieser Fragen in seiner Mythos Ein Tag Serie.

die Protokolldatei Kürzen:

Backup der Datenbank
Trennen Sie die Datenbank, entweder mithilfe von Enterprise Manager oder durch Ausführen: Sp_DetachDB [DBName]
Löschen Sie die Transaktionsprotokolldatei. (Oder die Datei umbenennen, nur für den Fall)
Re-attach die Datenbank wieder mit: Sp_AttachDB [DBName]
Wenn die Datenbank angeschlossen ist, wird eine neue Transaktionsprotokolldatei erstellt.

Um die Protokolldatei verkleinern:

Backup-Protokoll [DBName] mit no_log
Shrink die Datenbank entweder:

Mit Enterprise Manager: - Rechtsklick auf die Datenbank, die alle Aufgaben, Datenbank verkleinern, Dateien Wählen Sie Protokolldatei, OK.

Mit T-SQL: - DBCC SHRINKFILE ([Log_Logical_Name])

Sie können den logischen Namen der Protokolldatei finden, indem Sie sp_helpdb ausführen oder in den Eigenschaften der Datenbank in Enterprise Manager suchen.

Zu meiner Erfahrung auf den meist SQL-Server gibt es keine Sicherung des Transaktionsprotokolls. Vollständige Sicherungen oder differenzielle Sicherungen sind gängige Praxis, aber Transaktionsprotokollsicherungen sind wirklich selten. So ist die Transaktionsprotokolldatei wächst für immer (bis die Festplatte voll ist). In diesem Fall wird das Wiederherstellungsmodell gesetzt werden sollte " einfach ". Vergessen Sie nicht, die Systemdatenbanken „Modell“ und „tempdb“, zu ändern.

Eine Sicherung der Datenbank „tempdb“ macht keinen Sinn, so dass das Wiederherstellungsmodell dieser db sollte immer „einfach“.

Nehmen Sie eine Sicherung der MDB-Datei.
Stop SQL-Dienste
Benennen Sie die Protokolldatei
Starten Sie den Dienst

(Das System wird eine neue Protokolldatei erstellen.)

Löschen oder die umbenannte Protokolldatei verschieben.

Versuchen Sie folgendes:

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO

Datenbank → Rechtsklick Eigenschaften → Datei → andere Protokolldatei mit einem anderen Namen hinzufügen und dem Pfad die gleichen wie die alten Protokolldatei mit einem anderen Dateinamen.

Die Datenbank nimmt automatisch die neu erstellte Protokolldatei auf.

Backup DB
Detach DB
Umbenennen Log-Datei
Anhängen DB (während umbenannten LDF-Befestigung entfernen (Log-Datei) .Select es und entfernen Sie durch Drücken der Taste entfernen)
Neue Protokolldatei neu erstellt werden
Löschen Renamed Log-Datei.

Das funktioniert aber es wird vorgeschlagen, zunächst Sicherung Ihrer Datenbank zu übernehmen.

Beispiel:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

Es geschah mit mir, wo die Datenbank-Protokolldatei von 28 GBs war.

Was können Sie tun dies zu reduzieren? Eigentlich Protokolldateien derjenigediejenigedasjenige Dateidaten sind, die der SQL-Server hält, wenn eine Transaktion stattgefunden hat. Für eine Transaktion Prozess SQL Server ordnet Seiten für das gleiche. Aber nach dem Abschluss der Transaktion, werden diese nicht plötzlich die Hoffnung veröffentlicht, dass es eine Transaktion wie das gleiche kommt sein. Dies hält den Platz.

Schritt 1: Zuerst Führen Sie diesen Befehl in der Datenbankabfrage erforschte Kontrollpunkt

Schritt 2: Rechtsklick auf die Datenbank Aufgabe> Sichern Wählen Sie Backup-Typ als Transaktionsprotokoll eine Zieladresse hinzufügen und den Namen der Sicherungsdaten (BAK)

zu halten Datei

Wiederholen Sie diesen Schritt wieder und zu diesem Zeitpunkt einen anderen Dateinamen geben

Schritt 3: Gehen Sie nun in der Datenbank Rechtsklick auf die Datenbank

Aufgaben> Verkleinert> Dateien Wählen Sie Dateityp als Log Schrumpf Aktion als Freigabe ungenutzter Raum

Schritt 4:

Überprüfen Sie die Protokolldatei normalerweise in SQL 2014 kann dies auf

gefunden

C: \ Programme \ Microsoft SQL Server \ MSSQL12.MSSQL2014EXPRESS \ MSSQL \ DATA

In meinem Fall seine reduzierte sich von 28 GB bis 1 MB

Einige der anderen Antworten nicht für mich arbeiten: Es war nicht möglich, den Kontrollpunkt zu schaffen, während die db online war, weil das Transaktionsprotokoll voll war (wie ironisch). Nachdem jedoch die Datenbank in der Notbetrieb Einstellung konnte ich die Protokolldatei schrumpfen:

alter database <database_name> set emergency;
use <database_name>;
checkpoint;
checkpoint;
alter database <database_name> set online;
dbcc shrinkfile(<database_name>_log, 200);

DB Transaktionsprotokoll Shrink Größe auf min :

Backup: Transaktionsprotokoll
Shrink-Dateien: Transaktionsprotokoll
Backup: Transaktionsprotokoll
Shrink-Dateien: Transaktionsprotokoll

Ich habe Tests auf mehrere Anzahl der DBs: diese Sequenz funktioniert .

Es normalerweise schrumpft auf 2 MB .

oder durch ein Skript:

DECLARE @DB_Name nvarchar(255);
DECLARE @DB_LogFileName nvarchar(255);
SET @DB_Name = '<Database Name>';               --Input Variable
SET @DB_LogFileName = '<LogFileEntryName>';         --Input Variable
EXEC 
(
'USE ['+@DB_Name+']; '+
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2) ' +
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2)'
)
GO

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow