none
Probleme mit nicht zu verkleinerndem Logfile unter SQL 2008 R2 RRS feed

  • Frage

  • Hallo,

    ich habe ein Problem unter SQL 2008 R2 bei einem Kunden

    Dort läuft eine Datenbank  für ein Dokumentenmanagementsystem. Die Anwendung läuft einwandfrei. Die Datenbank wird regelmäßig durch Wartungspläne gewartet und jede Stunde läuft eine Transaktionsprotokollsicherung der DB ohne Fehler, somit sollte das Logfile gar nicht groß werden, bzw dann wieder klein werden nach einer entsprechenden Transaktionsprotokollsicherung.

    Die DB hat eine Größe von 58 GB und das Logfile eine Größe von 61 GB.

    Normalerweise, lässt sich das Protokoll nach einer Sicherung durch Verkleinern der Datei auf eine vernünftige Größe bringen. Jedoch nicht hier. Bei Verkleinern der Protokolldatei wird ein freier Platz von fast 0 angegeben, d.h. ca. 61 GB belegt.

    Versuche ich die Datenbank auf einfach und anschliessend wieder auf vollständig zu schalten um danach die Datei zu verkleinern ändert sich nichts.

    Nun das kuriose: Beim Backup der Datenbank wird ein Backupfile von ca. 58GB angelegt und nach einer sehr langen Laufzeit wächst das Backup auf 119 GB an.

    Ich finde keine Möglichkeit das Log zu verkleinern.

    Habe versucht mittels Kopierassistent die Daten in eine neue DB zu kopieren, das klappt und die DB ist gemauso groß wie die urspüngliche DB mit einem kleinen Logfile. Lediglich die Anwendung kann damit wohl nicht gut umgehen, ist danach furchtbar langsam.

    Habe Indexe neu angelegt, die geändert DB heisst auch so wie die vorherige. DBCCC CHECKDB zeigt keine Fehler. Das ist aber ein anderes Problem, das hier nicht unbedingt zur Debatte steht, Falls aber jemand ne Idee dazu hat, nur zu!

    Aber nun zum Kernthema: Wie krieg ich bei der alten DB dieses "aufgeblasenene" Logfile klein?

    Kann mir hier jemand helfen?

    Christian Schulz

    Donnerstag, 24. Januar 2013 14:41

Antworten

Alle Antworten

  • Hallo Christian,

    ich vermute, dass es noch offene Transaktionen gibt, die VLF belegen. Dadurch kann das Logfile nicht verkleinert werden.
    Zunächst prüfe mal, ob das LOG überhaupt in Use ist und anschließend, ob es offene Transaktionen gibt.

    SELECT database_id, name, log_reuse_wait_desc
    FROM sys.databases;
    SELECT s.spid,S.open_tran, a.text,s.Hostname,s.nt_domain,nt_username,net_address,s.loginame
    FROM sys.sysprocesses s CROSS APPLY sys.dm_exec_sql_text(S.SQL_HANDLE) AS a
    WHERE s.open_tran = 1


    Uwe Ricken

    MCSA - SQL Server 2012
    MCITP Database Administrator 2005
    MCITP Database Administrator 2008
    MCITP Microsoft SQL Server 2008, Database Development

    db Berater GmbH
    http://www-db-berater.de
    SQL Server Blog (german only)

    Donnerstag, 24. Januar 2013 16:28
  • Hallo Uwe,

    Danke für die Antwort, habe den Befehl mal abgesetzt und noch ein paar Infos dazu.

    Bekomme folgendes Ergebnis:

    database_id	  name	        log_reuse_wait_desc
    1	          master	NOTHING
    2	          tempdb	ACTIVE_TRANSACTION
    3	          model	        NOTHING
    4	          msdb	        NOTHING
    6	          DMS	        REPLICATION

    wobei die Datenbank DMS die betroffene Datenbank ist

    Die Abfrage

    USE master
    GO
    sp_helpdb DMS
    GO

    ergibt folgendes:

    name  db_size	    owner	            dbid   created	status	compatibility_level
    DMS   117570.00 MB  RIS-TEST\Administrator  6	   Jan 25 2013	Status=ONLINE, Updateability=READ_WRITE, UserAccess=MULTI_USER, Recovery=FULL, Version=661, Collation=Latin1_General_CI_AS, SQLSortOrder=0, IsAutoShrink, IsAnsiNullDefault, IsAnsiNullsEnabled, IsAutoCreateStatistics, IsAutoUpdateStatistics, IsFullTextEnabled	100
    
    name	fileid	filename	                                                filegroup  size	        maxsize	        growth	        usage
    DMS	1	E:\MSSQLDB2008R2\MSSQL10_50.MSSQL2008R2\MSSQL\DATA\DMS.mdf	PRIMARY	   62453760 KB	Unlimited	10240 KB	data only
    DMS_log	2	E:\MSSQLDB2008R2\MSSQL10_50.MSSQL2008R2\MSSQL\DATA\DMS_1.ldf	NULL	   57937920 KB	2147483648 KB	10240 KB	log only
    Vielleicht hilft die Info was

    Freitag, 25. Januar 2013 09:46
  • Hallo Fersl,

    dann ist schon fast die Ursache gefunden. Ich vermute, dass die Replikation noch nicht alle Daten zum Subscriber übertragen hat.Prüfe doch mal den Status der Replikation im Replikationsmonitor. Ich vermute aus den Problemen, dass es sich um eine Transactionsreplikation handelt.

    Solange nicht alle Logs zu ALLEN Subscribern repliziert wurden, wird das Log nicht abgeschnitten.

    Führe den folgenden Befehl aus, um noch nicht replizierte Transaktionen zu demarkieren
    EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0,     @time = 0, @reset = 1

    Anschließend kann das Log verkleinert werden.

    Uwe Ricken

    MCSA - SQL Server 2012
    MCITP Database Administrator 2005
    MCITP Database Administrator 2008
    MCITP Microsoft SQL Server 2008, Database Development

    db Berater GmbH
    http://www-db-berater.de
    SQL Server Blog (german only)



    Freitag, 25. Januar 2013 09:56
  • Hallo,

    sorry hat ein wenig gedauert, da das Problem bei Kunden besteht, kann ich da am WE nichts machen.

    Also ich glaub ich hab mich zu früh gefreut.

    Meldung 18757, Ebene 16, Status 1, Prozedur sp_repldone, Zeile 1
    Die Prozedur kann nicht ausgeführt werden. Die Datenbank ist nicht veröffentlicht. Führen Sie die Prozedur in einer Datenbank aus, die für die Replikation veröffentlicht wird.

    Wie kann sowas denn zustande kommen?

    Ich hatte sowas bei einem Kunden schon mal und hab mir dadruch beholfen, dass ich die Daten mit dem DTS-Wizard aus der Quelldatenbank in eine neu DB kopiert habe, Da war dann das Log wieder schön klein. Mir ist aber nach wie vor ein Rätsel wie so etwas überhaupt zustande kommt.

    Replikation ist hier nicht aktiv, bzw. kein Replikationspartner konfiguriert.

    Wenn ein Kunde viel Platz auf dem DB-Server hat, merkt man das unter Umständen gar nicht. Hier ging halt der Platz fürs Backup aus.

    Grüße

    Christian


    Montag, 28. Januar 2013 12:26
  • Hallo Fersl,

    hast du das Script auch IN der richtigen Datenbank ausgeführt?
    Ansonsten würde ich empfehlen - sofern sonst keine Datenbanken Partner von Replikationen sind - einfach die Replikation generell abzuschalten / deaktivieren. Dann sollte es funktionieren.


    Uwe Ricken

    MCSE - SQL Server 2012
    MCSA - SQL Server 2012
    MCITP Database Administrator 2005
    MCITP Database Administrator 2008
    MCITP Microsoft SQL Server 2008, Database Development

    db Berater GmbH
    http://www-db-berater.de
    SQL Server Blog (german only)

    Montag, 28. Januar 2013 12:38
  • Hallo Uwe,

    Vielen Dank für die schnelle Antwort!

    ich habe das Skript auf die richtige DB abgesetzt.

    Replikation ist auf dem SQL-Server prinzipiell nicht aktiviert/konfiguriert.

    Gibt es in der DB einen Schalter dafür? Wenn ja, kann der im Betrieb geändert werden?

    Chrstian Schulz

    Montag, 28. Januar 2013 13:55
  • Hallo Christian,

    hmm - jetzt wird es komplizierter :)
    Zunächst einmal ist heraus zu bekommen, ob die Datenbank, die Du verkleinern willst, ein Publisher ist (dann ist Replikation auf jeden Fall aktiviert) oder aber ob es sich nur um einen Subscriber handelt.

    Gibt es auf dem Server eine Datenbank mit dem Namen "Distributor"?

    Wie man eine Replikation von einem Subscriber löscht, findest Du u. a. hier:
    http://msdn.microsoft.com/en-us/library/ms146906(v=sql.105).aspx


    Uwe Ricken

    MCSE - SQL Server 2012
    MCSA - SQL Server 2012
    MCITP Database Administrator 2005
    MCITP Database Administrator 2008
    MCITP Microsoft SQL Server 2008, Database Development

    db Berater GmbH
    http://www-db-berater.de
    SQL Server Blog (german only)


    Montag, 28. Januar 2013 14:05
  • Hallo Uwe

    Ich komm an den Quellserver nicht mehr ran für heute.

    Auf meinem Testserver auf dem ich eine Kopie der DB eingespielt habe, habe ich natürlich keine distribution.

    Ich werde versuchen morgen die Daten einzuholen.

    Danke!

    Montag, 28. Januar 2013 15:29
  • Also, ich war eben auf einem Kundenserver aufgeschaltet.

    Ergebnisse der Abfragen sind die gleichen, wie oben gepostet und es gibt keine Datenbank distribution.

    Hmm nun wirds wohl echt schwierig.

    Wie gesagt, ich weiss nicht seit wann das so ist, versuche hier aber noch entsprechende Infos einzuholen.

    Dienstag, 29. Januar 2013 10:55
  • Hallo fersl,

    da wird Dir dann wohl nichts anderes übrig bleiben, als zunächst einmal den Datenstrom zurückzuverfolgen. Es ist eigenartig, dass als log_reuse_wait "REPLICATION" ausgegeben wird, die DB aber - gem. Deiner Aussage - nicht repliziert ist...

    Mehr als seltsam! Um da weiter zu machen, benötigt man schon mehr Informationen über den Verleger!


    Uwe Ricken

    MCSE - SQL Server 2012
    MCSA - SQL Server 2012
    MCITP Database Administrator 2005
    MCITP Database Administrator 2008
    MCITP Microsoft SQL Server 2008, Database Development

    db Berater GmbH
    http://www-db-berater.de
    SQL Server Blog (german only)

    Dienstag, 29. Januar 2013 13:57
  • Hallo Uwe,

    Kannst Du mir da ein wenig Hilfestellung geben?

    Ich meine die Sache mit dem Verleger, damit hatte ich bisher nichts zu tun.

    Bzw. welche Informationen bräuchte man da, oder wie kann man die wo herausbekommen?

    Da würdest du mir schon sehr helfen.

    Danke!


    Dienstag, 29. Januar 2013 15:32
  • Hallo fersl,

    schau Dir mal den Artikel an:
    http://blogs.msdn.com/b/jorgepc/archive/2011/03/09/database-log-cannot-be-shrunk-because-it-is-marked-as-replication-when-replication-has-not-been-configured.aspx

    Dort werden die einzelnen Schritte - teilweise von Uwe bereits genannt - aufgeführt um eine nicht gewollte Replikation wieder loszuwerden.

    Gruß Elmar

    Dienstag, 29. Januar 2013 18:17
  • Hallo Elmar,

    bin morgen im Aussendienst und kann erst am Donnerstag hier wieder Infos geben.

    Danke das höst sich vielversprechend an!

    Werde auf alle Fälle berichten.

    Gruß Christian

    Dienstag, 29. Januar 2013 19:00
  • Hallo,

    habe nun die Vorgehensweise durchgeführt, wie in dem Blogartikel beschrieben.

    Das Log hat von Replication auf NONE gewechselt und nach meinem ersten Versuch, wohl gemerkt Versuch der nachfolgenden Skripte habe ich folgenden Status:

    DMS	ACTIVE_TRANSACTION	DMS	6	NULL	

    Das Einrichten hat ja wie beschrieben bestens funktioniert. Bei dem Entfernen der Publikation schleuderts mich dann.

    Folgendes Skript

    USE DMS;
    GO
    EXEC sp_droppublication @publication = N'DMS_Test'

    Erzeugt folgendes Ergebnis:

    Wobei DMS_Test der Name meiner Publikation ist.

    Meldung 15517, Ebene 16, Status 1, Prozedur sp_replcmds, Zeile 1
    Die Ausführung als Datenbankprinzipal ist nicht möglich, weil der Prinzipal 'dbo' nicht vorhanden ist, für diesen Typ von Prinzipal kein Identitätswechsel möglich ist, oder Sie nicht die erforderliche Berechtigung haben.

    Ich führe diese Abfragen natürlich bei mir aus, weil das nicht am offenen Herzen beim Kunden machen will.

    Ich habe dazu ein Backup des Kunden auf einem SQL-Server bei mir eingespielt.

    Die gleiche Meldung bekomme ich auch, wenn ich die Publikation über den Assistenten entfernen will.

    Schema dbo ist in der Datenbank vorhanden und ist auch Besitzer aller Tabellen.

    Ausführung als Windows-Admin oder sa, gleiches Ergebnis

    Donnerstag, 31. Januar 2013 15:35
  • Hallo,

    da passt der Datenbankbesitzer nicht mehr. Lege den Besitzer via ALTER AUTORIZATION fest:

    ALTER AUTHORIZATION ON DATABASE::DMS TO sa
    Gruß Elmar
    • Bearbeitet Elmar Boye Donnerstag, 31. Januar 2013 15:57
    Donnerstag, 31. Januar 2013 15:56
  • Also nun schaut es wohl gut aus, habe das nochmal im Ganzen durchgespielt.

    Werde dann am Montag noch das Verhalten der Anwendung testen und hier dazu informieren.

    Vielen Dank schon mal vorab!!!!

    Freitag, 1. Februar 2013 12:17
  • Hallo zusammen,

    wollte nur noch vermelden, dass das Problem als gelöst gilt.

    Vielen, Vielen Dank für die kompetente und sehr schnelle Hilfe hier!!!!

    Mich würde zwar immer noch interessieren, wie so etwas zustande kommen kann, aber das wird wohl verborgen bleiben.

    Montag, 4. Februar 2013 14:38
  • Hallo,

    Danke für die Rückmeldung.

    Was die Ursachen angeht:
    Naja, der SQL Server ist ein hochkomplexes Projekt und hier reicht das Setzen eines Bits um das Ganze "auszubremsen". Der BLOG- Artikel geht auch nicht auf alle Möglichkeiten ein, so dass es da vermutlich noch einige dunkle Bereiche gibt.

    Gruß Elmar

    Montag, 4. Februar 2013 15:41