Benutzer mit den meisten Antworten
Terminalserver 2012R2 RDCms-DB Transaktionsprotokoll voll!!

Frage
-
Hallo,
seit gestern können User sich nicht am Terminalserver per RDP anmelden. Im Eventlog steht folgender Fehler "Das Transaktionsprotokoll für die RDCms-Datenbank ist aufgrund von 'CHECKPOINT' voll."
Wie kann ich das Protokoll verkleinern? Das Management Studio ist nicht installiert. Wenn ich es installieren würde wie melde ich mich an der Datenbank an?
Nachtrag:
Ich habe das Management Studio installiert und konnte und konnte mich auf die entsprende Instanz verbinden.
Das Transaktionsprotokoll der RDCms DB ist voll und steht auf "Checkpoint". Leider kann ich die DB nicht sichern, das Transaktionsprotokoll verkleinern etc. . Es kommt immer die Fehlermeldung das das Transaktionsprotokoll auf Grund von "Checkpoint" voll ist.
Was kann ich nun machen?
MfG
R.Zumbeel
- Bearbeitet Zumbeel Montag, 13. Februar 2017 08:58
Antworten
-
Danke für die Info.
Ich habe den Server aus dem Backup wieder hergestellt und jetzt läuft er erstmal wieder.
Sollte das Problem wieder auftreten werde ich ihren Tip(Wiederherstellungsmodell ändern) mal testen.
MfG
R.Zumbeel
- Als Antwort markiert Mihaela ParedesMicrosoft contingent staff, Moderator Freitag, 24. Februar 2017 10:15
Alle Antworten
-
Hallo r.Zumbeel,
zunächst wäre es gut zu wissen in welchem Wiederherstellungsmodel die Datenbank ist. Wenn sie im Model FULL ist, muss das Transaktionslog regelmässig gesichert werden.
Aktuell wird nur die Chance bleiben die Log Datei zu vergrößern um Platz zu schaffen. Vorher wäre aber die Info zum Wiederherstellungsmodel wichtig für das weitere Vorgehen.
https://msdn.microsoft.com/de-de/library/ms189272.aspx
Benjamin Hoch
MCSE: Data Platform & Data Management and Analytics
MCSA: SQL Server 2012/2014 & 2016 DB Administration
MCSA: Windows Server 2012
- Bearbeitet Benjamin.Hoch Montag, 13. Februar 2017 09:16
-
Führe doch mal bitte dieses Skript aus und poste hier das Ergebnis um mal einen Überblick zu bekommen wie es mit der Datenbank und dem Server aussieht
USE master; GO -- Dirty reads zulassen, um möglichst keine Ressourcen zu sperren! SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; GO -- Variables for the passing through all databases DECLARE @Result TABLE ( Database_Name sysname NOT NULL, Database_Owner sysname NULL, compatibility_level VARCHAR(10) NOT NULL, collation_Name sysname NOT NULL, state_mode VARCHAR(30) NOT NULL, recovery_mode VARCHAR(30) NOT NULL, snapshot_isolation VARCHAR(5) NOT NULL DEFAULT ('OFF'), read_committed_SI TINYINT NOT NULL DEFAULT (0), Logical_Name sysname NOT NULL, type_desc VARCHAR(10) NOT NULL, physical_name VARCHAR(255) NOT NULL, size_MB DECIMAL(18, 2) NOT NULL DEFAULT (0), growth_MB DECIMAL(18, 2) NOT NULL DEFAULT (0), used_MB DECIMAL(18, 2) NOT NULL DEFAULT (0), is_percent_growth TINYINT NOT NULL DEFAULT (0), percent_growth TINYINT NOT NULL DEFAULT (0), PRIMARY KEY CLUSTERED ( Database_Name, logical_name ), UNIQUE (physical_name) ); INSERT INTO @Result EXEC sys.sp_MSforeachdb @command1 = N'USE [?]; SELECT DB_NAME(D.database_id) AS [Database Name], SP.name AS [Database_Owner], D.compatibility_level, D.collation_name, D.state_desc, D.recovery_model_desc, D.snapshot_isolation_state_desc, D.is_read_committed_snapshot_on, MF.name, MF.type_desc, MF.physical_name, MF.size / 128.0 AS [size_MB], CASE WHEN MF.[is_percent_growth] = 1 THEN MF.[size] * (MF.[growth] / 100.0) ELSE MF.[growth] END / 128.0 AS [growth_MB], FILEPROPERTY(MF.name, ''spaceused'') / 128.0 AS [used_MB], MF.[is_percent_growth], CASE WHEN MF.[is_percent_growth] = 1 THEN MF.[growth] ELSE 0 END AS [percent_growth] FROM sys.databases AS D INNER JOIN sys.master_files AS MF ON (D.database_id = MF.database_id) LEFT JOIN sys.server_principals AS SP ON (D.owner_sid = SP.sid) WHERE D.database_id = DB_ID();'; SELECT R.Logical_Name, R.type_desc, R.size_MB, R.growth_MB, R.used_MB, R.is_percent_growth, R.percent_growth /* for more detailed information about the databases */ --, --R.Database_Name, --R.physical_name FROM @Result AS R;
Benjamin Hoch
MCSE: Data Platform & Data Management and Analytics
MCSA: SQL Server 2012/2014 & 2016 DB Administration
MCSA: Windows Server 2012 -
Hallo,
das Wiederherstellungsmodell steht auf EINFACH.
Hier die gewünschte Info:
master ROWS 4.00 0.40 3.25 1 10 mastlog LOG 0.75 0.08 0.36 1 10 modeldev ROWS 2.06 1.00 2.06 0 0 modellog LOG 0.75 0.08 0.45 1 10 MSDBData ROWS 20.25 2.03 18.94 1 10 MSDBLog LOG 0.75 0.08 0.52 1 10 RDCms ROWS 99.06 1.00 98.38 0 0 RDCms_log LOG 150.00 15.00 150.25 1 10 tempdev ROWS 2.00 0.20 2.75 1 10 templog LOG 0.50 0.05 0.59 1 10
-
Hallo,
kannst du die LOG Datei mal händisch vergrößern auf z.B. 200 MB und dann mal folgendes Skript ausführen
use RDCms go; checkpoint
https://msdn.microsoft.com/de-de/library/ms175890.aspx
Benjamin Hoch
MCSE: Data Platform & Data Management and Analytics
MCSA: SQL Server 2012/2014 & 2016 DB Administration
MCSA: Windows Server 2012 -
Das Script gibt folgendes aus:
Mindestens eine zur RDCms-Datenbank gehörige Wiederherstellungseinheit konnte keinen Prüfpunkt generieren. Dies ist normalerweise auf fehlende Systemressourcen wie unzureichenden Datenträger- oder Arbeitsspeicher zurückzuführen. In einigen Fällen kann auch die Datenbank beschädigt sein. Überprüfen Sie das Fehlerprotokoll auf frühere Einträge, um ausführlichere Informationen zu diesem Fehler zu erhalten. Die Anweisung wurde beendet. Meldung 9002, Ebene 17, Status 1, Prozedur sp_flush_commit_table, Zeile 16 Das Transaktionsprotokoll für die RDCms-Datenbank ist aufgrund von 'CHECKPOINT' voll.
Das händische vergrößern wird auch mit Fehlermeldung nicht ausgeführt.
MfG
R.Zumbeel
-
Prüfe doch bitte mal ob auf der Platte wo die Log Datei liegt noch Platz ist.
Dann erstelle bitte eine neue LOG Datei auf einem Platte mit ausreichend Speicherplatz.
Wenn die neue Datei da ist sollte die Checkpoint Operation funktionieren.
https://msdn.microsoft.com/de-de/library/ms189253.aspx?f=255&MSPPError=-2147217396
Benjamin Hoch
MCSE: Data Platform & Data Management and Analytics
MCSA: SQL Server 2012/2014 & 2016 DB Administration
MCSA: Windows Server 2012 -
auf gar keinen Fall löschen. nur eine neue Datei anfügen.
Und dies hat auch nichts mit der "Interne Windows Datenbank " zu tun. Hier läuft ein SQL Server welcher die Daten verwaltet
Benjamin Hoch
MCSE: Data Platform & Data Management and Analytics
MCSA: SQL Server 2012/2014 & 2016 DB Administration
MCSA: Windows Server 2012 -
Und dies hat auch nichts mit der "Interne Windows Datenbank " zu tun. Hier läuft ein SQL Server welcher die Daten verwaltet
Evgenij Smirnov
I work @ msg services ag, Berlin -> http://www.msg-services.de
I blog (in German) @ http://it-pro-berlin.de
my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
Exchange User Group, Berlin -> http://exusg.de
Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com -
Hallo Evgenij,
gibt es für die WID besondere Einschränkungen bei der Größe, denn ich kann hier keinen Grund sehen warum die LOG Datei nicht wachsen kann?
Benjamin Hoch
MCSE: Data Platform & Data Management and Analytics
MCSA: SQL Server 2012/2014 & 2016 DB Administration
MCSA: Windows Server 2012 -
Moin,
die WID ist quasi eine Express ohne Netzwerk und inzwischen auch ohne Größenbeschränkung für die Datenbank (aufgehoben IIRC zu WSS 3.0-Zeiten, da sonst SharePoint oft voll gelaufen ist)
Der Fehler mit dem CHECKPOINT ist nicht spezifisch WID und auch nicht spezifisch RDS, sondern passiert auch in anderen Szenarien. Probieren kann man da folgendes:
- Widerherstellungsmodus auf FULL setzen. Wenn das gelingt, Dateigröße erhöhen, Log wegsichern und wieder auf SIMPLE setzen
- (Achtung kein Weg zurück!) HA-Modus für Connection Broker konfigurieren und somit die DB auf eine SQL (Express) migrieren
- (Achtung Verlust der Konfiguration) Connection Broker neu machen
Evgenij Smirnov
I work @ msg services ag, Berlin -> http://www.msg-services.de
I blog (in German) @ http://it-pro-berlin.de
my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
Exchange User Group, Berlin -> http://exusg.de
Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com -
Danke für die Info.
Ich habe den Server aus dem Backup wieder hergestellt und jetzt läuft er erstmal wieder.
Sollte das Problem wieder auftreten werde ich ihren Tip(Wiederherstellungsmodell ändern) mal testen.
MfG
R.Zumbeel
- Als Antwort markiert Mihaela ParedesMicrosoft contingent staff, Moderator Freitag, 24. Februar 2017 10:15