4
SQL-Sessions trennen vor DBCC SHRINKFILE
Hallo,
ich habe ein kleines Problem mit meinem neu aufgesetzten SQL-Server 2005. Ich möchte die physische Dateigröße des Transaktionsprotokolls einer Datenbank verringern (mittlerweile ca. 65 GB!).
Hierzu lasse ich folgendes Script laufen:
Auf dem alten Server (auch 2005) lief das per Task nachts problemlos. War ja auch keiner weiter eingeloggt.
Bei dem neuen klappt es aber nicht. Es kommt dann nur die folgende Meldung:
"Cannot shrink log file 2 (MeineDB_Log) because all logical log files are in use."
Wenn ich die Zugriffe auf die Datenbank per Script abrufe sehe ich auch mehrere Einträge, obwohl diese User definitiv keine Verbindung zur Datenbank zu diesem Zeitpunkt haben.
Irgendwie scheinen sie nicht sauber getrennt zu werden.
Selbst wenn ich die Datenbank als "SINGLE_USER" setze sehe ich sie noch und kann bekomme dann die gleiche Meldung.
Warum werden diese User nicht sauber getrennt? Gibt es da eine generelle Einstellung? oder wie kann ich sie ganz hart rauswerfen?
Torsten
ich habe ein kleines Problem mit meinem neu aufgesetzten SQL-Server 2005. Ich möchte die physische Dateigröße des Transaktionsprotokolls einer Datenbank verringern (mittlerweile ca. 65 GB!).
Hierzu lasse ich folgendes Script laufen:
USE MeineDB
CHECKPOINT
BACKUP LOG MeineDB WITH NO_LOG
DBCC SHRINKFILE(MeineDB_Log,NOTRUNCATE)
DBCC SHRINKFILE(MeineDB_Log,TRUNCATEONLY)Auf dem alten Server (auch 2005) lief das per Task nachts problemlos. War ja auch keiner weiter eingeloggt.
Bei dem neuen klappt es aber nicht. Es kommt dann nur die folgende Meldung:
"Cannot shrink log file 2 (MeineDB_Log) because all logical log files are in use."
Wenn ich die Zugriffe auf die Datenbank per Script abrufe sehe ich auch mehrere Einträge, obwohl diese User definitiv keine Verbindung zur Datenbank zu diesem Zeitpunkt haben.
Irgendwie scheinen sie nicht sauber getrennt zu werden.
Selbst wenn ich die Datenbank als "SINGLE_USER" setze sehe ich sie noch und kann bekomme dann die gleiche Meldung.
Warum werden diese User nicht sauber getrennt? Gibt es da eine generelle Einstellung? oder wie kann ich sie ganz hart rauswerfen?
Torsten
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 136023
Url: https://administrator.de/forum/sql-sessions-trennen-vor-dbcc-shrinkfile-136023.html
Ausgedruckt am: 09.04.2025 um 01:04 Uhr
4 Kommentare
Neuester Kommentar
Hallo,
eventuell funktioniert es so.
Der erste Befehl bewirkt, dass die Datenbank in den Single-User-Mode gesetzt wird und fährt dabei gleichzeitig alle offenen Transaktionen zurück
Beim zweiten wird die Datenbank wieder in den Normal-Mode zurückgesetzt.
Allerdings würde ich zuerst abklären wieso Connections offen bleiben. Eventuell arbeitet die Client-Software nicht sauber.
eventuell funktioniert es so.
ALTER DATABASE [TestDb] SET SINGLE_USER WITH ROLLBACK IMMEDIATE 2
ALTER DATABASE [TestDB] SET MULTI_USER Beim zweiten wird die Datenbank wieder in den Normal-Mode zurückgesetzt.
Allerdings würde ich zuerst abklären wieso Connections offen bleiben. Eventuell arbeitet die Client-Software nicht sauber.
Hallo Tommy70,
leider funktioniert es so auch nicht. Es ist mir ein echtes Rätsel. Wenn die Datenbank in Beim alten Server hat es mit den gleichen Clients perfekt funktioniert. Die Clientversionen haben sich auch nicht geändert. Halt nur ein neuer Server.
Torsten
leider funktioniert es so auch nicht. Es ist mir ein echtes Rätsel. Wenn die Datenbank in Beim alten Server hat es mit den gleichen Clients perfekt funktioniert. Die Clientversionen haben sich auch nicht geändert. Halt nur ein neuer Server.
Torsten
Moin TorstenB,
Schau mal bitte im Enterprise Manager bei alter (falls noch vorhanden) und neuer Datenbank unter (neudeutsch: ) "Properties", "Options", "Recovery Mode (FULL oder SIMPLE) und vermutlich auf deutsch "Eigenschaften", "Optionen", "Wiederherstellungmodus?".
SIMPLE Recovery ist zwar nichts, was einer Prod-DB angetan werden sollte, aber wenn ihr eh Transactions-Logs jede Nacht verkürzt... *lach*
Wie kommt ihr denn auf den Bolzen, dass das halb-manuell per Skript gemacht werden muss? Jede Nacht, wenn normale DBs schlafen?
Das Transaction-Log sollte eigentlich immer eine konstante (physische/von außen erkennbare) Größe behalten und NUR verkleinert werden, wenn abzusehen ist, dass es auch nie nie wieder auf die einmal erreichte Größe anwachsen wird (z.B. weil der Server nicht mehr 5000 Tabellen und 10 Appz & DBs beherbergt, sondern nur noch 200 Tabellen und 1 Appz).
Wenn ihr meint, der Server braucht mehr freien Plattenplatz--> auf nach eBucht/DasIsMeinLaden und größere Platte kaufen.
Grüße
Biber
Zitat von @goodbytes:
Hallo Tommy70,
leider funktioniert es so auch nicht. Es ist mir ein echtes Rätsel. Wenn die Datenbank in Beim alten Server hat es mit den
gleichen Clients perfekt funktioniert. Die Clientversionen haben sich auch nicht geändert. Halt nur ein neuer Server.
Torsten
Dann kann es nach menschlichem bzw biberschen Ermessen nur so sein, dass die vorherige vermeintlich baugleiche Serverinstanz im SIMPLE Recoverymodus lief, die neue/jetzige dagegen im FULL Recovery Mode.Hallo Tommy70,
leider funktioniert es so auch nicht. Es ist mir ein echtes Rätsel. Wenn die Datenbank in Beim alten Server hat es mit den
gleichen Clients perfekt funktioniert. Die Clientversionen haben sich auch nicht geändert. Halt nur ein neuer Server.
Torsten
Schau mal bitte im Enterprise Manager bei alter (falls noch vorhanden) und neuer Datenbank unter (neudeutsch: ) "Properties", "Options", "Recovery Mode (FULL oder SIMPLE) und vermutlich auf deutsch "Eigenschaften", "Optionen", "Wiederherstellungmodus?".
SIMPLE Recovery ist zwar nichts, was einer Prod-DB angetan werden sollte, aber wenn ihr eh Transactions-Logs jede Nacht verkürzt... *lach*
Wie kommt ihr denn auf den Bolzen, dass das halb-manuell per Skript gemacht werden muss? Jede Nacht, wenn normale DBs schlafen?
Das Transaction-Log sollte eigentlich immer eine konstante (physische/von außen erkennbare) Größe behalten und NUR verkleinert werden, wenn abzusehen ist, dass es auch nie nie wieder auf die einmal erreichte Größe anwachsen wird (z.B. weil der Server nicht mehr 5000 Tabellen und 10 Appz & DBs beherbergt, sondern nur noch 200 Tabellen und 1 Appz).
Wenn ihr meint, der Server braucht mehr freien Plattenplatz--> auf nach eBucht/DasIsMeinLaden und größere Platte kaufen.
Grüße
Biber
Hallo Biber,
standardmässig steht die Prod-DB auf FULL. Ich hatte vor paar Tagen mal eine Test-Datenbank auf dem SQL-Server versuchsweise von FULL auf SIMPLE gesetzt und ein Backup gezogen. Genauso hatte ich im FULL-Modus mal die Transaktionsprotokolle gesichert. Alles hat nix gebracht; die physische Dateigroße wächst und wächst...
Damit werden auch die Backups immer größer, welche ja noch irgendwie mit auf die täglichen Bandsicherungen passen müssen. Mittlerweile ist ein DB-Backup gut 100 GB groß.
Mich würde einfach interessieren, warum das Shrinken nicht funktioniert. Wenn ich folgendes Script auf meinen SQL-Server loslasse sehe ich seltsamerweise noch bestehende Logins, obwohl die User gar nicht eingeloggt sein können:
Hier eine Zeile der Ausgabe:
Wenn ich aus der Anwendung heraus von einem Client nach eingeloggten Usern schaue ist dort nichts. Offenbar werden die Sessions einfach nicht sauber getrennt. Wie kann ich sie nun wirklich wenigstens testweise mal canceln?
Weitere Nachforschungen ergaben, dass die Datenbank offenbar noch auf Replikationen wartet.
Genau wie hier: SQL Server 2005 Transaktionsprotokoll kann nicht verkleinern, da Transkationen noch aktiv
Ich denke, dass es eine generelle falsche Einstellung am SQL-Server ist, da es alle Datenbanken betrifft (sogar meine VMware vSphere-Datenbanken, bei welchen sich ja momentan wirklich nichts tut).
Was also tun?
Torsten
standardmässig steht die Prod-DB auf FULL. Ich hatte vor paar Tagen mal eine Test-Datenbank auf dem SQL-Server versuchsweise von FULL auf SIMPLE gesetzt und ein Backup gezogen. Genauso hatte ich im FULL-Modus mal die Transaktionsprotokolle gesichert. Alles hat nix gebracht; die physische Dateigroße wächst und wächst...
Damit werden auch die Backups immer größer, welche ja noch irgendwie mit auf die täglichen Bandsicherungen passen müssen. Mittlerweile ist ein DB-Backup gut 100 GB groß.
Mich würde einfach interessieren, warum das Shrinken nicht funktioniert. Wenn ich folgendes Script auf meinen SQL-Server loslasse sehe ich seltsamerweise noch bestehende Logins, obwohl die User gar nicht eingeloggt sein können:
SELECT
I.NTUserName,
I.loginname,
I.SessionLoginName,
I.databasename,
Min(I.StartTime) as first_used,
Max(I.StartTime) as last_used,
S.principal_id,
S.sid,
S.type_desc,
S.name
FROM
sys.traces T CROSS Apply
::fn_trace_gettable(CASE
WHEN CHARINDEX( '_',T.[path]) <> 0 THEN
SUBSTRING(T.PATH, 1, CHARINDEX( '_',T.[path])-1) + '.trc'
ELSE T.[path]
End, T.max_files) I LEFT JOIN
sys.server_principals S ON
CONVERT(VARBINARY(MAX), I.loginsid) = S.sid
WHERE
T.id = 1 And
I.LoginSid is not null
Group By
I.databasename,
I.NTUserName,
I.loginname,
I.SessionLoginName,
S.principal_id,
S.sid,
S.type_desc,
S.nameHier eine Zeile der Ausgabe:
NULL user1 user1 MeineDB 11.02.2010 11:53 15.02.2010 09:51 281 0x2615590140F99742A836EFC2E6B54649 SQL_LOGIN user1Wenn ich aus der Anwendung heraus von einem Client nach eingeloggten Usern schaue ist dort nichts. Offenbar werden die Sessions einfach nicht sauber getrennt. Wie kann ich sie nun wirklich wenigstens testweise mal canceln?
Weitere Nachforschungen ergaben, dass die Datenbank offenbar noch auf Replikationen wartet.
Genau wie hier: SQL Server 2005 Transaktionsprotokoll kann nicht verkleinern, da Transkationen noch aktiv
Ich denke, dass es eine generelle falsche Einstellung am SQL-Server ist, da es alle Datenbanken betrifft (sogar meine VMware vSphere-Datenbanken, bei welchen sich ja momentan wirklich nichts tut).
Was also tun?
Torsten
