Benutzer mit den meisten Antworten
ReportServerTempDB wächst plötzlich stark an
Frage
-
Wir haben SSRS 2014 vor gut zwei Jahren installiert. Die ReportServerTempDB hatte die ganze Zeit eine Größe von rund 300MB. Seit etwa einem Monat wächst das Logfile dieser Datenbank aber stark an und hat jetzt eine Größe von ca. 13GB, die angeblich auch fast komplett belegt sind. Andererseits nehmen die Tabellen und Indices in dieser Datenbank nur sehr wenig Platz ein. Die ReportServerTempDB läuft im Simple-Mode und wird regelmäßig gesichert. Wir haben im letzten Monat keine Konfigurtionsänderungen gemacht, die ich in Zusammenhang mit diesem Problem sehen würde. Wie kann ich feststellen, was das plötzlichen starke Wachstum des Logfiles verursacht? Wie kann ich das wieder beheben?
SELECT db.Name AS DatabaseName, db.recovery_model_desc, COALESCE(CONVERT(VARCHAR(12), MAX(bs.backup_finish_date), 104),'-') AS LastBackUpTime FROM sys.databases db LEFT OUTER JOIN msdb.dbo.backupset bs ON bs.database_name = db.name GROUP BY db.Name, db.recovery_model_desc; DatabaseName recovery_model_desc LastBackUpTime tempdb SIMPLE - master SIMPLE 10.11.2016 ReportServer FULL 10.11.2016 model FULL 10.11.2016 ReportServerTempDB SIMPLE 10.11.2016 msdb SIMPLE 10.11.2016
SELECT DB_NAME() AS DbName, name AS FileName, size/128.0 AS CurrentSizeMB, size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS FreeSpaceMB FROM sys.database_files; DbName FileName CurrentSizeMB FreeSpaceMB ReportServerTempDB ReportServerTempDB 360.187500 285.937500 ReportServerTempDB ReportServerTempDB_log 13138.187500 856.976563
SELECT t.NAME AS TableName, i.name AS IndexName, SUM(p.rows) AS RowCounts, SUM(a.total_pages) AS TotalPages, SUM(a.used_pages) AS UsedPages, SUM(a.data_pages) AS DataPages, (SUM(a.total_pages) * 8) / 1024 AS TotalSpaceMB, (SUM(a.used_pages) * 8) / 1024 AS UsedSpaceMB, (SUM(a.data_pages) * 8) / 1024 AS DataSpaceMB FROM sys.tables t INNER JOIN sys.indexes i ON t.OBJECT_ID = i.object_id INNER JOIN sys.partitions p ON i.object_id = p.OBJECT_ID AND i.index_id = p.index_id INNER JOIN sys.allocation_units a ON p.partition_id = a.container_id GROUP BY t.NAME, i.object_id, i.index_id, i.name ORDER BY 9 desc; TableName IndexName RowCounts TotalPages UsedPages DataPages TotalSpaceMB UsedSpaceMB DataSpaceMB Segment PK_Segment 16678 4946 4860 4310 38 37 33 ChunkSegmentMapping PK_ChunkSegmentMapping 8339 209 173 168 1 1 1 ChunkSegmentMapping UNIQ_ChunkId_StartByte 8339 201 169 165 1 1 1 SegmentedChunk IX_ChunkId_SnapshotDataId 529 17 11 9 0 0 0 TempCatalog UNIQ_TempCatalogID 0 0 0 0 0 0 0 TempDataSources IX_DataSourceItemID 0 0 0 0 0 0 0 TempDataSets IX_DataSetLinkID 0 0 0 0 0 0 0 SessionData IX_SessionSnapshotID 55 2 2 1 0 0 0 ExecutionCache IX_SnapshotDataID 0 0 0 0 0 0 0 SnapshotData IS_SnapshotExpiration 83 2 2 1 0 0 0 ChunkSegmentMapping IX_ChunkSegmentMapping_SegmentId 8339 145 122 119 1 0 0 SegmentedChunk UNIQ_SnapshotChunkMapping 529 57 16 13 0 0 0 TempCatalog IX_Cleanup 0 0 0 0 0 0 0 TempDataSets PK_TempDataSet 0 0 0 0 0 0 0 SessionData IX_EditSessionID 55 2 2 1 0 0 0 ExecutionCache IX_CacheLookup 0 0 0 0 0 0 0 SegmentedChunk PK_SegmentedChunk 529 25 22 20 0 0 0 DBUpgradeHistory PK_DBUpgradeHistory 41 2 2 1 0 0 0 TempCatalog PK_TempCatalog 0 0 0 0 0 0 0 TempDataSources PK_DataSource 0 0 0 0 0 0 0 TempDataSets IX_TempDataSet_ItemID_Name 0 0 0 0 0 0 0 SessionData IX_SessionCleanup 55 2 2 1 0 0 0 ExecutionCache PK_ExecutionCache 0 0 0 0 0 0 0 SnapshotData IX_SnapshotCleaning 83 2 2 1 0 0 0 ChunkData PK_ChunkData 0 0 0 0 0 0 0 Segment IX_SegmentMetadata 8339 97 78 76 0 0 0 SessionLock IDX_SessionLock 112 2 2 1 0 0 0 SessionData IDX_SessionData 165 1674 1484 17 13 11 0 ExecutionCache IX_ExecutionCache 0 0 0 0 0 0 0 SnapshotData IX_SnapshotData 166 1962 1921 13 15 15 0 ChunkData IX_ChunkData 0 0 0 0 0 0 0 PersistedStream PK_PersistedStream 4 4 4 1 0 0 0
Antworten
-
Bei mir sieht das Bild auch so aus, aber ich habe keine so alten Prozesse laufen. Ich würde hier mal den Reporting Service (Dienst) abschalten und prüfen ob nun alle alten Verbindungen weg sind. Wenn nicht alle Prozesse von diesem Tag killen und dann den Dienst wieder starten.
Danach müsste das Log sich wieder leeren.
Benjamin Hoch
MCSE: Data Platform
MCSE: Data Management and Analytics
MCSA: SQL Server 2012/2014
MCSA: Windows Server 2012
Blog- Als Antwort markiert uwdn Freitag, 11. November 2016 12:21
Alle Antworten
-
Hallo,
kann es sein dass es einen (sehr) lange laufenden Prozess gibt welcher den Platz belegt? Im Wiederherstellungsmodell Simple wird das Log automatisch geleert.
Benjamin Hoch
MCSE: Data Platform
MCSE: Data Management and Analytics
MCSA: SQL Server 2012/2014
MCSA: Windows Server 2012
Blog -
Ja, es scheint etwas mit langlaufenden Prozessen zu tun zu haben. Aber was bedeutet es, dass in der folgenden Abfrage viele ReportServer-Prozesse am 10.10. gestartet sind, welche alle den Status "Sleeping" und "Awaiting Command" haben. Der 10.10. ist in der Tat der Tag, an dem das Anwachsen der Datenbank begonnen hat. Und normal sind diese alten Report-Server-Prozesse offensichtlich nicht, wie ich an unserer Testumgebung sehe:
select spid, blocked, waittime, lastwaittype, cpu, dbid, login_time, last_batch, status, program_name, cmd, replace(replace(loginame,'Domainname','*******'),'Username','**') loginname from master.dbo.sysprocesses P order by last_batch; spid blocked waittime lastwaittype cpu dbid login_time last_batch status program_name cmd loginname 1 0 41303 QDS_PERSIST_TASK_MAIN_LOOP_SLEEP 31 0 2016-06-09 10:18:10.847 2016-06-09 10:18:10.847 background UNKNOWN TOKEN sa 2 0 40369 QDS_CLEANUP_STALE_QUERIES_TASK_M 93 0 2016-06-09 10:18:10.847 2016-06-09 10:18:10.847 background UNKNOWN TOKEN sa 3 0 12 SLEEP_TASK 19562 0 2016-06-09 10:18:10.847 2016-06-09 10:18:10.847 background UNKNOWN TOKEN sa 4 0 123 LOGMGR_QUEUE 61390 0 2016-06-09 10:18:10.920 2016-06-09 10:18:10.920 background LOG WRITER sa 5 0 31 DIRTY_PAGE_POLL 3218 0 2016-06-09 10:18:10.920 2016-06-09 10:18:10.920 background RECOVERY WRITER sa 6 0 303 LAZYWRITER_SLEEP 229265 0 2016-06-09 10:18:10.920 2016-06-09 10:18:10.920 background LAZY WRITER sa 7 0 13402042064 KSOURCE_WAKEUP 0 1 2016-06-09 10:18:10.920 2016-06-09 10:18:10.920 background SIGNAL HANDLER sa 8 0 499 REQUEST_FOR_DEADLOCK_SEARCH 3480984 0 2016-06-09 10:18:10.923 2016-06-09 10:18:10.923 background LOCK MONITOR sa 10 0 0 SOS_SCHEDULER_YIELD 22078 0 2016-06-09 10:18:10.933 2016-06-09 10:18:10.933 background RESOURCE MONITOR sa 11 0 81981 XE_DISPATCHER_WAIT 593 0 2016-06-09 10:18:10.933 2016-06-09 10:18:10.933 background XE DISPATCHER sa 12 0 1389 XE_TIMER_EVENT 17109 0 2016-06-09 10:18:10.937 2016-06-09 10:18:10.937 background XE TIMER sa 13 0 0 MISCELLANEOUS 0 1 2016-06-09 10:18:11.387 2016-06-09 10:18:11.387 sleeping TASK MANAGER sa 14 0 3446 SQLTRACE_INCREMENTAL_FLUSH_SLEEP 109 1 2016-06-09 10:18:11.487 2016-06-09 10:18:11.487 background TRACE QUEUE TASK sa 15 0 55508 SP_SERVER_DIAGNOSTICS_SLEEP 50515 0 2016-06-09 10:18:11.500 2016-06-09 10:18:11.500 background SYSTEM_HEALTH_MO sa 16 0 0 PREEMPTIVE_OS_REPORTEVENT 15 0 2016-06-09 10:18:11.503 2016-06-09 10:18:11.503 background RECEIVE sa 17 0 13402042788 ONDEMAND_TASK_QUEUE 0 1 2016-06-09 10:18:11.540 2016-06-09 10:18:11.540 background TASK MANAGER sa 18 0 7851 CHECKPOINT_QUEUE 131203 1 2016-06-09 10:18:11.540 2016-06-09 10:18:11.540 background CHECKPOINT sa 22 0 13402042023 BROKER_EVENTHANDLER 0 1 2016-06-09 10:18:12.087 2016-06-09 10:18:12.087 background BRKR EVENT HNDLR sa 23 0 13402042223 BROKER_TRANSMITTER 0 1 2016-06-09 10:18:12.103 2016-06-09 10:18:12.103 background BRKR TASK sa 24 0 13402042223 BROKER_TRANSMITTER 0 1 2016-06-09 10:18:12.103 2016-06-09 10:18:12.103 background BRKR TASK sa 25 0 315 HADR_FILESTREAM_IOMGR_IOCOMPLETI 2078 1 2016-06-09 10:18:12.103 2016-06-09 10:18:12.103 background BRKR TASK sa 26 0 221 BROKER_TO_FLUSH 593 1 2016-06-09 10:18:12.103 2016-06-09 10:18:12.103 background BRKR TASK sa 51 0 0 MISCELLANEOUS 0 4 2016-06-09 10:18:13.987 2016-06-09 10:18:13.987 sleeping SQLAgent - Email Logger AWAITING COMMAND *******\SQL_AGENT 53 0 0 MISCELLANEOUS 0 5 2016-10-10 09:28:43.200 2016-10-10 09:28:43.200 sleeping Report Server AWAITING COMMAND NT SERVICE\ReportServer$SQL2014 57 0 0 MISCELLANEOUS 0 5 2016-10-10 09:28:43.210 2016-10-10 09:28:43.210 sleeping Report Server AWAITING COMMAND NT SERVICE\ReportServer$SQL2014 56 0 0 MISCELLANEOUS 0 5 2016-10-10 09:28:43.213 2016-10-10 09:28:43.327 sleeping Report Server AWAITING COMMAND NT SERVICE\ReportServer$SQL2014 62 0 0 MISCELLANEOUS 0 5 2016-10-10 09:28:56.860 2016-10-10 09:28:56.860 sleeping Report Server AWAITING COMMAND NT SERVICE\ReportServer$SQL2014 55 0 0 MISCELLANEOUS 0 5 2016-10-10 09:28:56.873 2016-10-10 09:28:56.870 sleeping Report Server AWAITING COMMAND NT SERVICE\ReportServer$SQL2014 52 0 0 MISCELLANEOUS 0 5 2016-10-10 09:28:56.873 2016-10-10 09:28:56.917 sleeping Report Server AWAITING COMMAND NT SERVICE\ReportServer$SQL2014 67 0 0 MISCELLANEOUS 0 5 2016-10-10 09:30:05.260 2016-10-10 09:30:05.263 sleeping Report Server AWAITING COMMAND NT SERVICE\ReportServer$SQL2014 59 0 0 MISCELLANEOUS 0 5 2016-10-10 09:30:05.280 2016-10-10 09:30:05.277 sleeping Report Server AWAITING COMMAND NT SERVICE\ReportServer$SQL2014 68 0 0 MISCELLANEOUS 0 5 2016-10-10 09:30:05.283 2016-10-10 09:30:05.597 sleeping Report Server AWAITING COMMAND NT SERVICE\ReportServer$SQL2014 69 0 0 MISCELLANEOUS 0 5 2016-10-10 09:30:17.237 2016-10-10 09:30:17.240 sleeping Report Server AWAITING COMMAND NT SERVICE\ReportServer$SQL2014 70 0 0 MISCELLANEOUS 0 5 2016-10-10 09:30:17.253 2016-10-10 09:30:17.250 sleeping Report Server AWAITING COMMAND NT SERVICE\ReportServer$SQL2014 71 0 0 MISCELLANEOUS 0 5 2016-10-10 09:30:17.257 2016-10-10 09:30:17.287 sleeping Report Server AWAITING COMMAND NT SERVICE\ReportServer$SQL2014 54 0 0 MISCELLANEOUS 796 4 2016-06-09 10:18:13.987 2016-11-10 12:42:32.430 sleeping SQLAgent - Generic Refresher AWAITING COMMAND *******\SQL_AGENT 30 0 0 MISCELLANEOUS 0 1 2016-11-11 11:46:38.550 2016-11-11 11:46:38.550 sleeping TASK MANAGER sa 29 0 0 MISCELLANEOUS 0 1 2016-11-11 11:50:38.597 2016-11-11 11:50:38.597 sleeping TASK MANAGER sa 75 0 0 MISCELLANEOUS 548 6 2016-11-11 09:39:15.943 2016-11-11 11:51:32.173 sleeping Microsoft SQL Server Management Studio - Abfrage AWAITING COMMAND *******\*** 64 0 0 MISCELLANEOUS 32 1 2016-11-11 09:45:03.797 2016-11-11 11:51:49.467 sleeping Microsoft SQL Server Management Studio AWAITING COMMAND sa 20 0 0 MISCELLANEOUS 0 1 2016-11-11 11:54:43.627 2016-11-11 11:54:43.627 sleeping TASK MANAGER sa 32 0 0 MISCELLANEOUS 0 1 2016-11-11 11:54:58.627 2016-11-11 11:54:58.627 sleeping TASK MANAGER sa 21 0 0 MISCELLANEOUS 0 1 2016-11-11 11:58:43.657 2016-11-11 11:58:43.657 sleeping TASK MANAGER sa 19 0 0 MISCELLANEOUS 0 1 2016-11-11 11:58:43.657 2016-11-11 11:58:43.657 sleeping TASK MANAGER sa 9 0 0 MISCELLANEOUS 0 1 2016-11-11 11:58:43.657 2016-11-11 11:58:43.657 sleeping TASK MANAGER sa 65 0 0 MISCELLANEOUS 25474 4 2016-06-09 10:20:00.127 2016-11-11 11:59:00.223 sleeping SQLAgent - Job invocation engine AWAITING COMMAND *******\SQL_AGENT 27 0 0 MISCELLANEOUS 0 1 2016-11-11 11:59:08.660 2016-11-11 11:59:08.660 sleeping TASK MANAGER sa 28 0 0 MISCELLANEOUS 0 1 2016-11-11 11:59:08.660 2016-11-11 11:59:08.660 sleeping TASK MANAGER sa 31 0 0 MISCELLANEOUS 0 1 2016-11-11 11:59:38.667 2016-11-11 11:59:38.667 sleeping TASK MANAGER sa 33 0 0 MISCELLANEOUS 0 1 2016-11-11 11:59:38.667 2016-11-11 11:59:38.667 sleeping TASK MANAGER sa 34 0 0 MISCELLANEOUS 0 1 2016-11-11 11:59:38.667 2016-11-11 11:59:38.667 sleeping TASK MANAGER sa 35 0 0 MISCELLANEOUS 0 1 2016-11-11 11:59:38.667 2016-11-11 11:59:38.667 sleeping TASK MANAGER sa 63 0 0 MISCELLANEOUS 62 5 2016-11-11 11:51:55.440 2016-11-11 12:00:06.470 runnable Microsoft SQL Server Management Studio - Abfrage SELECT sa 58 0 0 MISCELLANEOUS 0 5 2016-11-11 12:00:53.473 2016-11-11 12:00:53.473 sleeping Report Server AWAITING COMMAND NT SERVICE\ReportServer$SQL2014 77 0 0 MISCELLANEOUS 0 5 2016-11-11 12:02:38.270 2016-11-11 12:02:38.267 sleeping Report Server AWAITING COMMAND NT SERVICE\ReportServer$SQL2014 61 0 0 MISCELLANEOUS 0 5 2016-11-11 12:02:38.933 2016-11-11 12:02:38.943 sleeping Report Server AWAITING COMMAND NT SERVICE\ReportServer$SQL2014 74 0 0 MISCELLANEOUS 0 5 2016-11-11 12:02:47.187 2016-11-11 12:02:47.183 sleeping Report Server AWAITING COMMAND NT SERVICE\ReportServer$SQL2014 66 0 0 MISCELLANEOUS 0 5 2016-11-11 12:03:22.707 2016-11-11 12:03:22.707 sleeping Report Server AWAITING COMMAND NT SERVICE\ReportServer$SQL2014 76 0 0 MISCELLANEOUS 0 5 2016-11-11 12:03:28.277 2016-11-11 12:03:28.277 sleeping Report Server AWAITING COMMAND NT SERVICE\ReportServer$SQL2014
-
Bei mir sieht das Bild auch so aus, aber ich habe keine so alten Prozesse laufen. Ich würde hier mal den Reporting Service (Dienst) abschalten und prüfen ob nun alle alten Verbindungen weg sind. Wenn nicht alle Prozesse von diesem Tag killen und dann den Dienst wieder starten.
Danach müsste das Log sich wieder leeren.
Benjamin Hoch
MCSE: Data Platform
MCSE: Data Management and Analytics
MCSA: SQL Server 2012/2014
MCSA: Windows Server 2012
Blog- Als Antwort markiert uwdn Freitag, 11. November 2016 12:21
-
Ja, mit einem Neustart des Reporting Services Dienst waren die alten Prozesse verschwunden, in der ReportServerTempDB_log war plötzlich wieder ganz viel freier Platz und die Datei ließ sich dann auch verkleinern. Bleibt noch die Frage, wie es zu diesem Zustand kommen konnte.
-
Hallo,
ich hatte auch mal diesen Effekt gehabt. Irgendwie hatte sich eine SSRS Session aufgehangen. Auf der relationalen Datenbank, die abgefragt werden sollte, hatte ich auch immer noch einen "verwaisten" Prozess. Evtl. hat eine Abfrage zu lange gedauert und die SSRS Engine ist dann in eine Art Timeout gelaufen, hat aber Ihrerseits Verbindungen nicht sauber beendet.
Falls das noch mal auftreten sollte, dann schau mal nach, ob auf der eigentlichen Datenquelle, aus der der Report gefüttert wird, nicht auch noch eine Session existiert.
Du könntest mal über die SSRS Historie schauen, welcher Report angefragt wird, der aber dann in einen Fehler läuft oder wo ggf. die Abfrage der Daten bzw das Rendering sehr lange dauert.
Es gibt auch ein Reporting Services Diagnostic Reports Project, was einem etliche Informationen visualisiert. Vielleicht hilft das ebenfalls weiter. http://www.sqlservercentral.com/articles/Reporting+Services+(SSRS)/69257/
Und auch mal gucken, ob es irgendwelche auffälligen Einträge im SSRS Log gibt.
Gruß Dirk
May you never suffer the sentiment of spending a day without any purpose
