none
Terminalserver 2012R2 RDCms-DB Transaktionsprotokoll voll!! RRS feed

  • 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
    Montag, 13. Februar 2017 07:35

Antworten

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



    Montag, 13. Februar 2017 09:14
  • 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

    Montag, 13. Februar 2017 09:19
  • 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

    Montag, 13. Februar 2017 09:29
  • 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

    Montag, 13. Februar 2017 09:46
  • 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

    Montag, 13. Februar 2017 10:16
  • 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

    Montag, 13. Februar 2017 11:49
  • Genug Platz ist auf der Platte.

    Also ich kann die LOG Datei löschen? (Vorher Dienst"Interne Windows Datenbank" beenden)?

    Und diese wird dann neu erstellt?

    Montag, 13. Februar 2017 12:37
  • 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

    Montag, 13. Februar 2017 12:38
  • Und dies hat auch nichts mit der "Interne Windows Datenbank " zu tun. Hier läuft ein SQL Server welcher die Daten verwaltet


    Wieso nicht? Wenn nur ein CB läuft und keine Hochverfügbarkeit eingerichtet ist, ist die WID zuständig. Welche ja auch eine besondere Express-Instanz ist.

    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

    Montag, 13. Februar 2017 19:59
  • 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

    Dienstag, 14. Februar 2017 05:44
  • 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

    Dienstag, 14. Februar 2017 06:09
  • 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

    Donnerstag, 16. Februar 2017 14:37