9
RD Session Host - keine Verbindung möglich, da Log voll
Lustiger Titel, oder?
Moin Kollegen.
Unser Terminalserver (2012 R2) wollte von jetzt auf gleich keine RDP-Verbindung mehr annehmen, bestehende liefen weiter. Gleichzeitig läuft im Application-Eventlog folgender Eintrag ID 9002 auf:
"The transaction log for database 'RDCms' is full due to 'CHECKPOINT'."
Quelle: MSSQL$MICROSOFT##WID
Der Server loggt die Verbindungen und hat bei einer Loggröße von 170 MB einfach gemeint "ich mach dann mal zu".
Schaut man diese Datenbanken ("C:\Windows\rdcbDb\Rdcms_log.ldf") mal im SQL-Managementstudio an, sieht man, dass Ihre Maximalgröße auf 2 TB steht... warum also das Problem mit 170 MB?
Als Lösung habe ich vorerst diese Datei aus dem Backup (14 Tage alt) wiederhergestellt, sie ist 200 KB kleiner, aber funktioniert. Natürlich kann es gut sein, dass ich das Problem in 2 Wochen wieder bekomme. Google ich nach dem Event, finde ich keine, in Worten "Null", Leidensgenossen.
Hat jemand eine Idee dazu?
Moin Kollegen.
Unser Terminalserver (2012 R2) wollte von jetzt auf gleich keine RDP-Verbindung mehr annehmen, bestehende liefen weiter. Gleichzeitig läuft im Application-Eventlog folgender Eintrag ID 9002 auf:
"The transaction log for database 'RDCms' is full due to 'CHECKPOINT'."
Quelle: MSSQL$MICROSOFT##WID
Der Server loggt die Verbindungen und hat bei einer Loggröße von 170 MB einfach gemeint "ich mach dann mal zu".
Schaut man diese Datenbanken ("C:\Windows\rdcbDb\Rdcms_log.ldf") mal im SQL-Managementstudio an, sieht man, dass Ihre Maximalgröße auf 2 TB steht... warum also das Problem mit 170 MB?
Als Lösung habe ich vorerst diese Datei aus dem Backup (14 Tage alt) wiederhergestellt, sie ist 200 KB kleiner, aber funktioniert. Natürlich kann es gut sein, dass ich das Problem in 2 Wochen wieder bekomme. Google ich nach dem Event, finde ich keine, in Worten "Null", Leidensgenossen.
Hat jemand eine Idee dazu?
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: 315238
Url: https://administrator.de/forum/rd-session-host-keine-verbindung-moeglich-da-log-voll-315238.html
Ausgedruckt am: 07.04.2025 um 19:04 Uhr
9 Kommentare
Neuester Kommentar
Hi,
vielleicht hilft dir das weiter:
https://blogs.technet.microsoft.com/austria/2011/03/08/sql-server-the-tr ...
https://ask.sqlservercentral.com/questions/109501/attach-database-fails- ...
Bist also nicht allein
Gruß,
Mad-Eye
vielleicht hilft dir das weiter:
https://blogs.technet.microsoft.com/austria/2011/03/08/sql-server-the-tr ...
https://ask.sqlservercentral.com/questions/109501/attach-database-fails- ...
Bist also nicht allein
Gruß,
Mad-Eye
Hi. Bringt leider keine neuen Erkenntnisse.
Heyho
Hmm...
hatte mal das Problem bei einem Exchange, dass der keine Mails mehr versenden wollte, weil auf dem LW, auf dem die Transactionlogs liegen, keine 4GB FreeSpace mehr verhanden gewesen sind....
[EDIT:] folgendes deckt sich dann doch mit Mad-Eyes Post
Ansonsten habe ich mal hier geschaut:
http://www.eventid.net/display-eventid-9002-source-MSSQLServer-eventno- ...
und dort u.A. folgenden Eintrag gefunden (Begriff bei google verwendet)
https://msdn.microsoft.com/en-us/library/aa337278.aspx
Steht ggf. was exaktes in der
Spalte log_reuse_wait_desc der sys.databases
Gruß
em-pie
Hmm...
hatte mal das Problem bei einem Exchange, dass der keine Mails mehr versenden wollte, weil auf dem LW, auf dem die Transactionlogs liegen, keine 4GB FreeSpace mehr verhanden gewesen sind....
[EDIT:] folgendes deckt sich dann doch mit Mad-Eyes Post
Ansonsten habe ich mal hier geschaut:
http://www.eventid.net/display-eventid-9002-source-MSSQLServer-eventno- ...
und dort u.A. folgenden Eintrag gefunden (Begriff bei google verwendet)
https://msdn.microsoft.com/en-us/library/aa337278.aspx
Steht ggf. was exaktes in der
Spalte log_reuse_wait_desc der sys.databases
Gruß
em-pie
Was exaktes? Was meinst du damit? Habe schon Feierabend, schaue morgen. Konnte noch feststellen, dass ein Backup der genannten db via sql management misslingt, obwohl es jetzt ja alles funktioniert.
Hatte das Feld leicht Fehlinterpretiert -.-
Wie schaut es denn aus, wenn du den Befehl
mal ausführts?
Lt. dieser Beschreibung wird hier ja der tatsächlich eingestellte Speicherplatz dargestellt (welcher durch Headerinfos etwas weniger anzeigt, als tatsächlich zugewiesen)
Und schau mal mittels
wie hier die Werte sind; wobei ich das Feld size selbst nicht richtig deuten kann, da es lt. Beschreibung die "Aktuelle Größe der Datei in Seiten mit einer Größe von 8 KB" wiedergibt!?
Nähere Infos hier: Link
Ansonsten gibt es noich diese MS-Seite hier: Link, welche aber nur SInn macht, wenn man das Problem lokalisieren konnte...
Wie schaut es denn aus, wenn du den Befehl
DBCC SQLPERF(LOGSPACE) Lt. dieser Beschreibung wird hier ja der tatsächlich eingestellte Speicherplatz dargestellt (welcher durch Headerinfos etwas weniger anzeigt, als tatsächlich zugewiesen)
Und schau mal mittels
select * from [Name_der_DAb].[sys].[database_files]Nähere Infos hier: Link
Ansonsten gibt es noich diese MS-Seite hier: Link, welche aber nur SInn macht, wenn man das Problem lokalisieren konnte...
Zum ersten Kommando:
RDCms Logsize (MB)149.9922 Used (MB) 58.82272 0
Zum zweiten:
Ich weiß aber nicht, was das nun bringen soll, denn definitiv hat ja auf einem TS das SQL Management Studio gar nichts verloren, ich habe keine Ahnung, waum ich der Einzige mit diesem Problem bin.
RDCms Logsize (MB)149.9922 Used (MB) 58.82272 0
Zum zweiten:
So, die Logfile darf in der Tat 2TB groß sein (gut sagtest du ja bereits zu Beginn^^), aber es wäre ja denkbar gewesen, das MS das auf der einen Maske so anzeigt und auf der anderen was völlig anderes, wäre ja nicht neu...
Zugegebener Maßen bin ich kein MS RDS-Spezi, bin da eher im Citrix-Umfeld "zuhause".
Habe mich daher mehr auf das Log-File Size PRoblem "konzentriert" denn die Tatsache, dass es ein RDS-Problem ist
Dass auf dem TS ein MS SQL Management Studio installiert ist, war bis eben neu; ansonsten verwendet MS ja die RDCMS.mdf für alles mögliche, da ja intern. Von daher wundert es mich nicht, dass dort eine SQL-DB-File verweilt.
Mal im Folgenden (weiter) im Trüben gefischt/ laut gedacht:
Mein nächster Gedanke war es, dass die DB mit der Zahl der Daten vollgelaufen ist, aber was dagegen spricht: dass das Problem seeeehr selten zu sein scheint.
Ggf. muss die DB/ Log-File mal gesichert/ reorganisiert werden, da die irgendwie strubbelig ist:
https://technet.microsoft.com/en-us/library/ms189085(v=sql.105).aspx
Zugegebener Maßen bin ich kein MS RDS-Spezi, bin da eher im Citrix-Umfeld "zuhause".
Habe mich daher mehr auf das Log-File Size PRoblem "konzentriert" denn die Tatsache, dass es ein RDS-Problem ist
Dass auf dem TS ein MS SQL Management Studio installiert ist, war bis eben neu; ansonsten verwendet MS ja die RDCMS.mdf für alles mögliche, da ja intern. Von daher wundert es mich nicht, dass dort eine SQL-DB-File verweilt.
Mal im Folgenden (weiter) im Trüben gefischt/ laut gedacht:
Mein nächster Gedanke war es, dass die DB mit der Zahl der Daten vollgelaufen ist, aber was dagegen spricht: dass das Problem seeeehr selten zu sein scheint.
Ggf. muss die DB/ Log-File mal gesichert/ reorganisiert werden, da die irgendwie strubbelig ist:
https://technet.microsoft.com/en-us/library/ms189085(v=sql.105).aspx
Ggf. muss die DB/ Log-File mal gesichert/ reorganisiert werden, da die irgendwie strubbelig ist:
Habe ich versucht, ich schrieb jaKonnte noch feststellen, dass ein Backup der genannten db via sql management misslingt, obwohl es jetzt ja alles funktioniert.
Meine Vermutung ist: die Datei hatte einfach einen Schuss weg. Ich werde abwarten, ob es mit den Backupkopien wieder auftritt.
Denke auch, das da eher die Log-Datei ne Macke hat. Mir ist auf dem TS mal die Platte vollgelaufen, weil ne dll ne Macke hatte und die Logs wild verteilt hat, wodurch das Auto-Cleanup hinüber war...seit dem hab ich Monitoring :P
