derwowusste
Goto Top

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?

Content-Key: 315238

Url: https://administrator.de/contentid/315238

Ausgedruckt am: 19.03.2024 um 09:03 Uhr

Mitglied: Mad-Eye
Mad-Eye 14.09.2016 um 16:39:33 Uhr
Goto Top
Mitglied: DerWoWusste
DerWoWusste 14.09.2016 um 16:58:51 Uhr
Goto Top
Hi. Bringt leider keine neuen Erkenntnisse.
Mitglied: em-pie
em-pie 14.09.2016 aktualisiert um 17:19:19 Uhr
Goto Top
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
Mitglied: DerWoWusste
DerWoWusste 14.09.2016 um 17:57:46 Uhr
Goto Top
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.
Mitglied: em-pie
em-pie 15.09.2016 um 12:51:35 Uhr
Goto Top
Hatte das Feld leicht Fehlinterpretiert -.-

Wie schaut es denn aus, wenn du den Befehl
DBCC SQLPERF(LOGSPACE) 
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
select * from [Name_der_DAb].[sys].[database_files]
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...
Mitglied: DerWoWusste
DerWoWusste 15.09.2016 um 16:27:04 Uhr
Goto Top
Zum ersten Kommando:
RDCms Logsize (MB)149.9922 Used (MB) 58.82272 0
Zum zweiten:
capture
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.
Mitglied: em-pie
em-pie 15.09.2016 um 17:42:13 Uhr
Goto Top
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
Mitglied: DerWoWusste
DerWoWusste 15.09.2016 um 18:45:57 Uhr
Goto Top
Ggf. muss die DB/ Log-File mal gesichert/ reorganisiert werden, da die irgendwie strubbelig ist:
Habe ich versucht, ich schrieb ja
Konnte 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.
Mitglied: Voiper
Voiper 16.09.2016 um 19:56:01 Uhr
Goto Top
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