none
SQL Server Performanceprobleme analysieren, brauche Hilfe. RRS feed

  • Frage

  • Hallo,

    wir haben eine Client/Server Anwendung, die mit einem SQL Server arbeitet. Bei allen Kunden hatten wir keine Probleme mit der Performance.

    Einer unserer Kunden hat sich vor ein paar Monaten entschieden, 7 Datenbanken (einzelne Standorte) zu einer zusammenzupacken und unsere Anwendung über Citrix zur Verfügung zu stellen. Seitdem haben wir Performanceprobleme, die aber nicht immer konstant sind. Es schwankt sehr stark. Das Rechenzentrum, bei dem die Software läuft weiß auch nicht weiter.

    Wir würden nun also gerne ein paar Kennzahlen aus dem System bekommen, mit denen wir die Problematik eingrenzen könnten. Leider haben wir so gut wie keine Erfahrung was den SQL Server angeht, also sind wir auf Eure Hilfe angewiesen.

    SQL Server ist ein 2016 Express auf einem Windows Server 2012 R2 mit 6 GB RAM und einem Intel Xeon E7-4890 v2 2.80 GHz (64Bit). Auf dem System läuft nur der SQL Server. Die User greifen über einen Citrix Server zu.

    Wir haben Zeitmessungen aus unserer Software heraus gemacht und 36 Testfälle aufgerufen und die Zeiten gemessen. Die Zeiten waren immer Konstant. Unter Citrix brauchte der Test immer doppelt so lange wie direkt auf dem Server aufgerufen. Das Rechenzentrum suchte das Problem also unter Citrix. Nun haben wir aber seit 3 Wochen das Problem, dass auch auf dem Server die Zeiten schlechter werden. Hier war der Testlauf normalerweise in 1:30 Min durch nun braucht der teilweise über 4 Minuten.
    Wird der Server neu gestartet und man macht den Test sofort nach Neustart erreicht man wieder die 1:30, sobald User drauf sind geht es wieder in die 4-6 Minuten Zeiten. Aktuell sind 18 User auf der DB und die Testzeit liegt bei 4 Minuten.

    Nun zu meiner eigentlichen Frage: Was für Parameter kann man aufrufen, um den Engpass einzugrenzen um überhaupt eine Idee zu bekommen woran es liegt?

    Habe was von Wartezeiten auf dem Server gelesen, aber leider kann ich die Werte nicht wirklich analysieren bzw. weiß ich auch nicht, ob das ein Problem ist oder nicht. In dem Beitrag wurde folgender SQL genannt und das Werte über 10 % schlecht sind. Bei uns sind es aktuell 24 %.

    SELECT CAST(100.0 * SUM(signal_wait_time_ms) / SUM(wait_time_ms) AS NUMERIC(20,2)) AS [%signal (cpu) waits] , CAST(100.0 * SUM(wait_time_ms - signal_wait_time_ms) / SUM(wait_time_ms) AS NUMERIC(20, 2)) AS [%resource waits]FROM sys.dm_os_wait_stats ;

    Wäre Euch echt dankbar, wenn Ihr die Geduld aufbringt einem Anfänger ein paar Tipps zu geben.


    Vielen Dank und Gruß Martin

    Mittwoch, 4. Oktober 2017 10:29

Antworten

  • Hallo,

    führe bitte mal die folgenden TSQL Skripte aus und poste hier mal die Ergebnisse.

    WITH [Waits] AS
    (
    	SELECT	[wait_type],
    			[wait_time_ms] / 1000.0 AS [WaitS],
    			([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS],
    			[signal_wait_time_ms] / 1000.0 AS [SignalS],
    			[waiting_tasks_count] AS [WaitCount],
    			100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage],
    			ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum]
        FROM	sys.dm_os_wait_stats
        WHERE	[wait_type] NOT IN
    	(
    		N'BROKER_EVENTHANDLER',         N'BROKER_RECEIVE_WAITFOR',
    		N'BROKER_TASK_STOP',            N'BROKER_TO_FLUSH',
    		N'BROKER_TRANSMITTER',          N'CHECKPOINT_QUEUE',
    		N'CHKPT',                       N'CLR_AUTO_EVENT',
    		N'CLR_MANUAL_EVENT',            N'CLR_SEMAPHORE',
    		N'DBMIRROR_DBM_EVENT',          N'DBMIRROR_EVENTS_QUEUE',
    		N'DBMIRROR_WORKER_QUEUE',       N'DBMIRRORING_CMD',
    		N'DIRTY_PAGE_POLL',             N'DISPATCHER_QUEUE_SEMAPHORE',
    		N'EXECSYNC',                    N'FSAGENT',
    		N'FT_IFTS_SCHEDULER_IDLE_WAIT', N'FT_IFTSHC_MUTEX',
    		N'HADR_CLUSAPI_CALL',           N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
    		N'HADR_LOGCAPTURE_WAIT',        N'HADR_NOTIFICATION_DEQUEUE',
    		N'HADR_TIMER_TASK',             N'HADR_WORK_QUEUE',
    		N'KSOURCE_WAKEUP',              N'LAZYWRITER_SLEEP',
    		N'LOGMGR_QUEUE',                N'ONDEMAND_TASK_QUEUE',
    		N'PWAIT_ALL_COMPONENTS_INITIALIZED',
    		N'QDS_PERSIST_TASK_MAIN_LOOP_SLEEP',
    		N'QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP',
    		N'REQUEST_FOR_DEADLOCK_SEARCH', N'RESOURCE_QUEUE',
    		N'SERVER_IDLE_CHECK',           N'SLEEP_BPOOL_FLUSH',
    		N'SLEEP_DBSTARTUP',             N'SLEEP_DCOMSTARTUP',
    		N'SLEEP_MASTERDBREADY',         N'SLEEP_MASTERMDREADY',
    		N'SLEEP_MASTERUPGRADED',        N'SLEEP_MSDBSTARTUP',
    		N'SLEEP_SYSTEMTASK',            N'SLEEP_TASK',
    		N'SLEEP_TEMPDBSTARTUP',         N'SNI_HTTP_ACCEPT',
    		N'SP_SERVER_DIAGNOSTICS_SLEEP', N'SQLTRACE_BUFFER_FLUSH',
    		N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
    		N'SQLTRACE_WAIT_ENTRIES',       N'WAIT_FOR_RESULTS',
    		N'WAITFOR',                     N'WAITFOR_TASKSHUTDOWN',
    		N'WAIT_XTP_HOST_WAIT',          N'WAIT_XTP_OFFLINE_CKPT_NEW_LOG',
    		N'WAIT_XTP_CKPT_CLOSE',         N'XE_DISPATCHER_JOIN',
    		N'XE_DISPATCHER_WAIT',          N'XE_TIMER_EVENT')
    	AND	waiting_tasks_count > 0
    	)
    SELECT	MAX ([W1].[wait_type]) AS [WaitType],
    		CAST (MAX ([W1].[WaitS]) AS DECIMAL (16,2)) AS [Wait_S],
    		CAST (MAX ([W1].[ResourceS]) AS DECIMAL (16,2)) AS [Resource_S],
    		CAST (MAX ([W1].[SignalS]) AS DECIMAL (16,2)) AS [Signal_S],
    		MAX ([W1].[WaitCount]) AS [WaitCount],
    		CAST (MAX ([W1].[Percentage]) AS DECIMAL (5,2)) AS [Percentage],
    		CAST ((MAX ([W1].[WaitS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgWait_S],
    		CAST ((MAX ([W1].[ResourceS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgRes_S],
    		CAST ((MAX ([W1].[SignalS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgSig_S],
    		'http://documentation.red-gate.com/display/SM4/' + W1.wait_type AS [DocumentLink]
    FROM	[Waits] AS [W1] INNER JOIN [Waits] AS [W2]
    		ON ([W2].[RowNum] <= [W1].[RowNum])
    GROUP BY
    		[W1].[RowNum],
    		w1.wait_type
    HAVING	SUM ([W2].[Percentage]) - MAX ([W1].[Percentage]) < 99;
    GO


    und

    USE master;
    GO
    
    WITH database_storage
    AS
    (
    	SELECT	LEFT(mf.physical_name, 2)	AS Drive,
    			SUM(num_of_reads)			AS num_of_reads,
    			SUM(io_stall_read_ms)		AS io_stall_read_ms,
    			SUM(num_of_writes)			AS num_of_writes,
    			SUM(io_stall_write_ms)		AS io_stall_write_ms,
    			SUM(num_of_bytes_read)		AS num_of_bytes_read,
    			SUM(num_of_bytes_written)	AS num_of_bytes_written,
    			SUM(io_stall)				AS io_stall
    	FROM	sys.master_files AS MF
    			CROSS APPLY sys.dm_io_virtual_file_stats(mf.database_id, mf.file_id) AS vfs
    	GROUP BY
    			LEFT(mf.physical_name, 2)
    )
    SELECT	[Drive],
    		CASE WHEN num_of_reads = 0
    			THEN 0 
    			ELSE io_stall_read_ms / num_of_reads 
    		END AS [Read Latency],
    		CASE 
    			WHEN io_stall_write_ms = 0 THEN 0 
    			ELSE (io_stall_write_ms/num_of_writes) 
    		END AS [Write Latency],
    		CASE 
    			WHEN (num_of_reads = 0 AND num_of_writes = 0) THEN 0 
    			ELSE (io_stall/(num_of_reads + num_of_writes)) 
    		END AS [Overall Latency],
    		CASE 
    			WHEN num_of_reads = 0 THEN 0 
    			ELSE (num_of_bytes_read/num_of_reads) 
    		END AS [Avg Bytes/Read],
    		CASE 
    			WHEN io_stall_write_ms = 0 THEN 0 
    			ELSE (num_of_bytes_written/num_of_writes) 
    		END AS [Avg Bytes/Write],
    		CASE 
    			WHEN (num_of_reads = 0 AND num_of_writes = 0) THEN 0 
    			ELSE ((num_of_bytes_read + num_of_bytes_written)/(num_of_reads + num_of_writes)) 
    		END AS [Avg Bytes/Transfer]
    FROM	database_storage
    ORDER BY
    		[Drive] OPTION (RECOMPILE);
    

    und zum Schluss noch

    USE master;
    GO
    
    -- Page Life Expectancy (PLE) value for each NUMA node in current instance!
    SELECT	@@SERVERNAME											AS	[Server Name],
    		[object_name],
    		[instance_name],
    		[cntr_value]											AS	[Page Life Expectancy],
    		GETDATE()												AS	[Measure_Date_Time],
    		(SELECT sqlserver_start_time FROM sys.dm_os_sys_info)	AS	Server_Start_Date_Time
    FROM	sys.dm_os_performance_counters WITH (NOLOCK)
    WHERE	[object_name] LIKE N'%Buffer Node%' AND
    		[counter_name] = N'Page life expectancy' OPTION (RECOMPILE);
    

    Die Skripte liefern eine Übersicht über den Zustand deines SQL Servers.


    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012

    Donnerstag, 5. Oktober 2017 05:31

Alle Antworten

  • Das ist ein stochern im Nebel.

    1.
    Wichtig zu wissen ist, ob für die SQL's, die deine Anwendung so lostritt auch entsprechende Indizes erstellt sind.
    Hierzu muss man wissen, dass für die Felder einer Where-Klausel oder beim Join der On-Klausel ein Index der schnellste Zugriff ist.
    Hat man allerdings berechnete Ausdrücke in der Where-Klausel kann man keinen Index erstellen.

    2.
    Ressourcenbeschränkung des SQL-Serverexpress:
    10GB DB-Größe
    1GB RAM
    Und gerade letzteres ist bei Multiuser-Betrieb ein Problem, da je nach DB-Größe durchaus jede Menge Daten je User gecached werden müssen und bei der Anzahl der User dann ein Verdrängungswettbewerb im Speicher stattfinden.
    M.a.W.: der Server ist dann mehr damit beschäftigt Metadaten und sonstiges (z.B. Transaktionsjournale) zu verwalten als tatsächlich Daten zu verarbeiten.

    Lösung:
    In dieser Größenordnung (leider) einen Standard-SQL-Server einrichten:
    Aber Achtung bei der Lizensierungsfrage!

    Mittwoch, 4. Oktober 2017 11:02
  • Hallo,

    ja, das ist wirklich ein stochern im Nebel, aber der Hinweis mit dem Standard Server und den Metadaten ist gut. Das war mir nicht so klar, denn ich bin nur von tatsächlichen Daten ausgegangen und bei einer 800 MB Datenbank habe ich mir da keine Sorgen gemacht. Aber klar, bei 18 Usern hat der schon etwas zu verwalten.
    Ich habe beim Rechenzentrum jetzt endlich durchbekommen, dass wir einen Test auf der Standard Version machen können. Das soll bis ende der Woche erfolgen.

    Vielen Dank schonmal für den Tipp. Ich werde berichten, wie es ausgeht.

    Zu den Indizes: Die haben wir gesetzt, das müsste passen.


    Vielen Dank und Gruß Martin


    • Bearbeitet Martin Dziubany Mittwoch, 4. Oktober 2017 12:25 Rechtschreibfehler beseitigt
    Mittwoch, 4. Oktober 2017 12:25
  • Moin,

    ein schneller Wurf, um zu sehen, ob Du einen RAM-Engpass hast, ist der Vergleich zweier PerfMon-Counter aus der Kategorie "MSSQL$SQLEXPRESS:MemoryManager": Total Server Memory (Zielspeicher) und Target Server Memory (Gesamtspeicher). Alles nicht in Stein gemeißelt, aber als schnelle Orientierungshilfe kann man folgendes annehmen, bis das Gegenteil bewiesen ist:

    • Liegt der Zielspeicher über dem Gesamtspeicher und der Gesamtspeicher ist an der konfigurierten Höchstgrenze, würde die Instanz definitiv von mehr RAM profitieren.
    • Liegt der Zielspeicher über dem Gesamtspeicher und der Gesamtspeicher bleibt dauerhaft unter der konfigurierten Höchstgrenze, verhindert etwas im Betriebssystem den weiteren Aufbau des Cache.
    • Liegt der Zielspeicher unterhalb des Gesamtspeichers, bedeutet dies, dass SQL gerade seinen Zielspeicher abgesenkt hat. Das geschieht in aller Regel auf Anforderung durch das Betriebssystem und bedeutet, dass diesem an anderer Stelle Arbeitsspeicher fehlt.
    • Ist der Zielspeicher exakt gleich dem Gesamtspeicher und liegen beide unterhalb der konfigurierten Höchstgrenze, so ist alles Pufferbare aus der Datenbank in den Puffer geladen und kann dort dauerhaft bleiben. Das ist der Idealzustand, der bedeutet, dass weder in der SQL-Instanz noch im Betriebssystem ein RAM-Problem besteht.


    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

    Mittwoch, 4. Oktober 2017 13:50
  • Ich sehe das Problem auch in der Grundkonfiguration. Denn der Express kann auch nur einen Kern (CPU) ansprechen, bei 1:30 Abfragezeit kann es durchaus auch zu "Staus" im Scheduler kommen.

    RAM und Kernerhöhung bzw. aktuelle Konfiguration passen also nicht zu ExpressEdition. Eine Standardedition dürfte es also schon sein.

    Donnerstag, 5. Oktober 2017 04:57
  • Hallo,

    führe bitte mal die folgenden TSQL Skripte aus und poste hier mal die Ergebnisse.

    WITH [Waits] AS
    (
    	SELECT	[wait_type],
    			[wait_time_ms] / 1000.0 AS [WaitS],
    			([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS],
    			[signal_wait_time_ms] / 1000.0 AS [SignalS],
    			[waiting_tasks_count] AS [WaitCount],
    			100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage],
    			ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum]
        FROM	sys.dm_os_wait_stats
        WHERE	[wait_type] NOT IN
    	(
    		N'BROKER_EVENTHANDLER',         N'BROKER_RECEIVE_WAITFOR',
    		N'BROKER_TASK_STOP',            N'BROKER_TO_FLUSH',
    		N'BROKER_TRANSMITTER',          N'CHECKPOINT_QUEUE',
    		N'CHKPT',                       N'CLR_AUTO_EVENT',
    		N'CLR_MANUAL_EVENT',            N'CLR_SEMAPHORE',
    		N'DBMIRROR_DBM_EVENT',          N'DBMIRROR_EVENTS_QUEUE',
    		N'DBMIRROR_WORKER_QUEUE',       N'DBMIRRORING_CMD',
    		N'DIRTY_PAGE_POLL',             N'DISPATCHER_QUEUE_SEMAPHORE',
    		N'EXECSYNC',                    N'FSAGENT',
    		N'FT_IFTS_SCHEDULER_IDLE_WAIT', N'FT_IFTSHC_MUTEX',
    		N'HADR_CLUSAPI_CALL',           N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
    		N'HADR_LOGCAPTURE_WAIT',        N'HADR_NOTIFICATION_DEQUEUE',
    		N'HADR_TIMER_TASK',             N'HADR_WORK_QUEUE',
    		N'KSOURCE_WAKEUP',              N'LAZYWRITER_SLEEP',
    		N'LOGMGR_QUEUE',                N'ONDEMAND_TASK_QUEUE',
    		N'PWAIT_ALL_COMPONENTS_INITIALIZED',
    		N'QDS_PERSIST_TASK_MAIN_LOOP_SLEEP',
    		N'QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP',
    		N'REQUEST_FOR_DEADLOCK_SEARCH', N'RESOURCE_QUEUE',
    		N'SERVER_IDLE_CHECK',           N'SLEEP_BPOOL_FLUSH',
    		N'SLEEP_DBSTARTUP',             N'SLEEP_DCOMSTARTUP',
    		N'SLEEP_MASTERDBREADY',         N'SLEEP_MASTERMDREADY',
    		N'SLEEP_MASTERUPGRADED',        N'SLEEP_MSDBSTARTUP',
    		N'SLEEP_SYSTEMTASK',            N'SLEEP_TASK',
    		N'SLEEP_TEMPDBSTARTUP',         N'SNI_HTTP_ACCEPT',
    		N'SP_SERVER_DIAGNOSTICS_SLEEP', N'SQLTRACE_BUFFER_FLUSH',
    		N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
    		N'SQLTRACE_WAIT_ENTRIES',       N'WAIT_FOR_RESULTS',
    		N'WAITFOR',                     N'WAITFOR_TASKSHUTDOWN',
    		N'WAIT_XTP_HOST_WAIT',          N'WAIT_XTP_OFFLINE_CKPT_NEW_LOG',
    		N'WAIT_XTP_CKPT_CLOSE',         N'XE_DISPATCHER_JOIN',
    		N'XE_DISPATCHER_WAIT',          N'XE_TIMER_EVENT')
    	AND	waiting_tasks_count > 0
    	)
    SELECT	MAX ([W1].[wait_type]) AS [WaitType],
    		CAST (MAX ([W1].[WaitS]) AS DECIMAL (16,2)) AS [Wait_S],
    		CAST (MAX ([W1].[ResourceS]) AS DECIMAL (16,2)) AS [Resource_S],
    		CAST (MAX ([W1].[SignalS]) AS DECIMAL (16,2)) AS [Signal_S],
    		MAX ([W1].[WaitCount]) AS [WaitCount],
    		CAST (MAX ([W1].[Percentage]) AS DECIMAL (5,2)) AS [Percentage],
    		CAST ((MAX ([W1].[WaitS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgWait_S],
    		CAST ((MAX ([W1].[ResourceS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgRes_S],
    		CAST ((MAX ([W1].[SignalS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgSig_S],
    		'http://documentation.red-gate.com/display/SM4/' + W1.wait_type AS [DocumentLink]
    FROM	[Waits] AS [W1] INNER JOIN [Waits] AS [W2]
    		ON ([W2].[RowNum] <= [W1].[RowNum])
    GROUP BY
    		[W1].[RowNum],
    		w1.wait_type
    HAVING	SUM ([W2].[Percentage]) - MAX ([W1].[Percentage]) < 99;
    GO


    und

    USE master;
    GO
    
    WITH database_storage
    AS
    (
    	SELECT	LEFT(mf.physical_name, 2)	AS Drive,
    			SUM(num_of_reads)			AS num_of_reads,
    			SUM(io_stall_read_ms)		AS io_stall_read_ms,
    			SUM(num_of_writes)			AS num_of_writes,
    			SUM(io_stall_write_ms)		AS io_stall_write_ms,
    			SUM(num_of_bytes_read)		AS num_of_bytes_read,
    			SUM(num_of_bytes_written)	AS num_of_bytes_written,
    			SUM(io_stall)				AS io_stall
    	FROM	sys.master_files AS MF
    			CROSS APPLY sys.dm_io_virtual_file_stats(mf.database_id, mf.file_id) AS vfs
    	GROUP BY
    			LEFT(mf.physical_name, 2)
    )
    SELECT	[Drive],
    		CASE WHEN num_of_reads = 0
    			THEN 0 
    			ELSE io_stall_read_ms / num_of_reads 
    		END AS [Read Latency],
    		CASE 
    			WHEN io_stall_write_ms = 0 THEN 0 
    			ELSE (io_stall_write_ms/num_of_writes) 
    		END AS [Write Latency],
    		CASE 
    			WHEN (num_of_reads = 0 AND num_of_writes = 0) THEN 0 
    			ELSE (io_stall/(num_of_reads + num_of_writes)) 
    		END AS [Overall Latency],
    		CASE 
    			WHEN num_of_reads = 0 THEN 0 
    			ELSE (num_of_bytes_read/num_of_reads) 
    		END AS [Avg Bytes/Read],
    		CASE 
    			WHEN io_stall_write_ms = 0 THEN 0 
    			ELSE (num_of_bytes_written/num_of_writes) 
    		END AS [Avg Bytes/Write],
    		CASE 
    			WHEN (num_of_reads = 0 AND num_of_writes = 0) THEN 0 
    			ELSE ((num_of_bytes_read + num_of_bytes_written)/(num_of_reads + num_of_writes)) 
    		END AS [Avg Bytes/Transfer]
    FROM	database_storage
    ORDER BY
    		[Drive] OPTION (RECOMPILE);
    

    und zum Schluss noch

    USE master;
    GO
    
    -- Page Life Expectancy (PLE) value for each NUMA node in current instance!
    SELECT	@@SERVERNAME											AS	[Server Name],
    		[object_name],
    		[instance_name],
    		[cntr_value]											AS	[Page Life Expectancy],
    		GETDATE()												AS	[Measure_Date_Time],
    		(SELECT sqlserver_start_time FROM sys.dm_os_sys_info)	AS	Server_Start_Date_Time
    FROM	sys.dm_os_performance_counters WITH (NOLOCK)
    WHERE	[object_name] LIKE N'%Buffer Node%' AND
    		[counter_name] = N'Page life expectancy' OPTION (RECOMPILE);
    

    Die Skripte liefern eine Übersicht über den Zustand deines SQL Servers.


    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012

    Donnerstag, 5. Oktober 2017 05:31
  • der Express kann auch nur einen Kern (CPU) ansprechen,

    Hier wollen wir mal differenzieren ;-) Bis 2008R2 war es tatsächlich so, ab 2012 ist es zwar weiterhin nur eine CPU, aber bis zu vier Kerne.

    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

    Donnerstag, 5. Oktober 2017 07:12
  • Abfrage Nr. 1


    Nr. 2


    Nr. 3


    Vielen Dank schonmal.

    Der Sache mit dem Ziel- und Gesamtspeicher gehe ich noch nach.



    Vielen Dank und Gruß Martin

    Donnerstag, 5. Oktober 2017 07:13
  • Für mich stellt sich auch die Frage, was denn da so 1:30 Minuten dauert.
    Wenn man bedenkt, dass ca. 100 SQL's (ggf. aber auch mehr) je Sekunde ausgeführt werden können müsstest du theoretisch 9000 SQL's in 90 Sekunden abgeben.
    Dies kann ichjedoch nicht glauben.
    Also was dauert da so lange, dass der SQL-Express 90 Sekunden dafür benötigt.

    Das nächste Problem sind die Satzsperren:
    https://msdn.microsoft.com/de-de/library/dd301365.aspx?f=255&MSPPError=-2147217396

    Wenn deine Transaktion also 90 Sekunden benötigt, werden alle Daten dieser Transaktion gesperrt.
    Kommt nun eine 2. Transaktion einer 2. Verbindung und liest Daten sequentiell und stößt dabei auf gesperrte Daten, wird diese 2. Transaktion so lange geparkt bis entweder die Sperre aufgehoben oder ein Timeout auftritt.

    Das heißt, dass die parallelen Transaktionen mehrerer User somit sequentialisiert werden.

    Nun heißt es also zu überlegen, wie deine Transaktionen genau aussehen, was da so lange dauert und ob ggf. die Aktionen in einzelne Transaktionen zerlegt werden könnten ohne die Datenkonsistenz dadurch aufzuheben.

    Es ist nun mal grundsätzlich anders, für einzelne User einer DB Transaktionen zu entwerfen als für eine Multi-User-Umgebung in der Transaktionen durchaus auch parallel auftreten werden.

    Donnerstag, 5. Oktober 2017 07:22
  • Hallo Martin,

    Kann es sein, dass du den SQL Server jede Nacht neu starten tust? Denn die Wait Analyse ist nicht besonders aufschlussreich und die Disk Laufzeit ist auch gut. Selbst der PLE Wert ist eigentlich ganz gut aber da die Werte nur die letzten Stunden Inhalten kann man nicht viel daraus lesen.

    Der Arbeitsspeicher ist mit 5 Stunden PLE ganz gut da der Server ja erst seit 5 Stunden gelaufen ist. Damit musste der SQL Server nie Daten aus dem Speicher auslagern. Es wäre gut wenn du die Abfragen heute Abend nochmal machen würdest.

    Gruß Benjamin


    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012

    Donnerstag, 5. Oktober 2017 07:23
  • Für mich stellt sich auch die Frage, was denn da so 1:30 Minuten dauert.
    Wenn man bedenkt, dass ca. 100 SQL's (ggf. aber auch mehr) je Sekunde ausgeführt werden können müsstest du theoretisch 9000 SQL's in 90 Sekunden abgeben.
    Dies kann ichjedoch nicht glauben.
    Also was dauert da so lange, dass der SQL-Express 90 Sekunden dafür benötigt.


    Es ist nicht ein SQL Befehl, der 1:30 Minuten dauert. Dieses Testszenario wurde in unserer Software eingebaut und ruft 36 recht komplexe Formulare nacheinander auf. Die bestehen aus mehreren SQL Abfragen, die z.B. die Daten holen, die bearbeitet werden und auch nur Daten holen, die z.B. den Inhalt einer Auswahlbox beinhalten. Wir versuchen bei der Programmierung die Zugriffe, die Sperren setzen natürlich so gering wie möglich zu halten.
    Bei dem Testszenario werden die Datensperre nach dem Aufbau des Formulares sofort wieder gelöscht.

    @Benjamin

    Ja, der Server wird jede Nacht um 4:00 Uhr neu gestartet. Die ersten User sind ab 7:30 drauf gewesen, also sind die Werte ca. 1,5 Stunden alt. Ich werde heute abend die Abfragen nochmal machen und dann die Ergebnisse hier posten.

    Danke Euch allen.


    Vielen Dank und Gruß Martin

    Donnerstag, 5. Oktober 2017 07:38
  • Hallo Martin,

    erste Empfehlung von mir. Startet den SQL Server nur neu wenn es wirklich zwingend notwendig ist. Mit jedem Neustart werden die Statistikdaten, die History und der Plancache gelöscht und damit fängt der SQL Server wieder bei Null an und muss die ganze Optimierung wieder neu berechnen und lernen. Damit wird die ganze Arbeit vom Vortag zunichte gemacht.


    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012

    Donnerstag, 5. Oktober 2017 08:25
  • Schade, dass es solche Seiten nicht deutsch gibt, aber hier ist eine gute Erklärung, warum sich Ausführungspläne zur Laufzeit des Servers durchaus verändern können.

    https://www.red-gate.com/simple-talk/sql/performance/execution-plan-basics/

    Es kann auch (leider) durchaus mal vorkommen, dass sich Pläne auf Grund von Auslastungen auch verschlechtern können. Immerhin sind es Schätzungen, die hinterher mit der tatsächlichen Ausführung verglichen werden, und wenn die Schätzung stimmt, ist der Plan doch gut.

    Hier in NRW werden Staus in die Navizeiten eingerechnet. Somit komme ich meistens genau dann an, wie das Navi gerechnet hat. Nur bremst so ein Stau leider aus, was in die Berechnung aber einfliest.
    Fahre ich nachts, gibts kaum Staus, der Plan schätzt daher ohne Stau und das Ergebnis stimmt dann auch. Nur habe ich dann die halbe Zeit benötigt.
    In beiden Fällen stimmen Plan und Ergebnis weitestgehend überein.


    Donnerstag, 5. Oktober 2017 09:16
  • Und genau deswegen ist es wichtig den Server nicht neu zu starten. Denn nur dadurch hat der SQL Server die Möglichkeit die "guten" Pläne weiter zu nutzen und muss nicht jedes neu anfangen und je nach Last die Pläne wieder verwerfen und neu erstellen. 

    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012

    Donnerstag, 5. Oktober 2017 10:37
  • Hallo,

    und entschuldigung, dass ich mich erst jetzt melde. War viel unterwegs und in der Zwischenzeit gab es einige Bewegung bei dem Rechenzentrum. Aber eine Verbesserung war leider nicht dabei. Die unten aufgeführten Messungen wurden eben gemacht. Auf der Anlage ist aktuell kein User.

    Die oben erwähnte Performancemessung dauert 3:07 Minuten. Immer noch doppelt so lange wie zu der besten Zeit.

    Was wir herausfinden konnten ist, dass an dem Tag, also die Performance schlechter wurde, das Rechenzentrum die VMWare Version aktualisiert hat. Kann das damit was zu tun haben? Wir haben irgendwie das Gefühl, dass die Anlage nicht mehr mit voller leistung was Prozessor und Kerne läuft. Im Ressourcen Monitor kann man bei einer virtualisierten Maschine ja leider nur die Prozessoren sehen (2 Stück) und nicht die Kerne. Oder gibt es da doch eine Möglichkeit?
    Die Aussage des Rechenzentrums ist: "An dem Update kann es nicht liegen."

    Abfrage Nr. 1


    Abfrage Nr. 2


    Abfrage Nr. 3


    Vielen Dank.

    Vielen Dank und Gruß Martin

    Dienstag, 10. Oktober 2017 18:54
  • Hallo Martin,

    Nach diesen Werten hat der SQL Server kein Problem mit dem RAM oder den Platten. Die Werte sehen sehr gut aus. Auch die Wartestatistik zeigt keine auffälligen Werte welche auf ein Performance Problem im SQL Server hindeuten. Da ich mich mit VMware nicht auskenne, kann ich nicht einschätzen ob eine Konfigurationsänderung durch das Update hier Einfluss hat.


    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012

    Mittwoch, 11. Oktober 2017 04:08
  • Nach diesen Werten hat der SQL Server kein Problem mit dem RAM oder den Platten. Die Werte sehen sehr gut aus. Auch die Wartestatistik zeigt keine auffälligen Werte welche auf ein Performance Problem im SQL Server hindeuten.

    Dem würde ich zustimmen. Lasst euch vom RZ die Statistik aus VM-Sicht geben, die für den Zeitraum eurer SQL-Performance-Messung folgendes umfasst:

    - CPU Usage

    - CPU Ready Time

    - CPU Wait Time

    Nebenfrage: Wurden die VMware Tools im SQL Server nach dem Hostupdate aktualisiert?


    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

    Mittwoch, 11. Oktober 2017 06:05
  • Nebenfrage: Wurden die VMware Tools im SQL Server nach dem Hostupdate aktualisiert?


    Hallo und vielen Dank für die Antworten. Ich werde das heute mit dem RZ besprechen.

    Zu dem Zitat: Ich habe da leider keine Ahnung von. Um welche Tools handelt es sich da und woran sehe ich ob die aktuell sind?


    Vielen Dank und Gruß Martin

    Mittwoch, 11. Oktober 2017 06:38
  • Zu dem Zitat: Ich habe da leider keine Ahnung von. Um welche Tools handelt es sich da und woran sehe ich ob die aktuell sind?


    Vielen Dank und Gruß Martin

    Es sind die Integrationstools, die Treiber für die virtuelle Hardware sowie die Kommunikation zwischen Host und Gast bereitstellen. Ob sie aktualisiert werden müssen, siehst Du am gelben Warndreieck am grauen Icon in der System Tray mit "VM" drauf.

    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

    Mittwoch, 11. Oktober 2017 06:44
  • Hallo, die Tools von VMWare sind aktuell. Das passt.

    Folgendes ist aber in der Zwischenzeit passiert:

    Da ich letzte Woche im Ressourcenmanager nur 2 CPUs gesehen habe auf der virtualisierten Maschine, kam mir der Verdacht, dass der SQL Server, der 1 Prozessor mit 4 Kernen laufen kann, nur auf 2 Kernen läuft, die auch noch das Betriebssystem bedienen.
    Ab heute morgen habe ich 4 Kerne im System und wir erreichen seit heute morgen wieder konstant die 1:30 bei unseren Messungen. Aussage des RZ ist, dass es nicht sein kann, dass der schneller ist, denn ein SQL Express kann nur einen Kern pro Instanz in einer virtuellen Maschine nutzen. d.h. unsere Datenbankinstanz kann da nur auf einen Kern zugreifen???

    Habe ich da jetzt einen Denkfehler drin, oder ist das wirklich so, dass ein SQL Server in einer virtuellen Maschine nur einen Kern pro Datenbankinstanz nutzt?

    Ein Eingreifen seitens des RZ soll es aber im Zeitraum der Verschlechterung natürlich nicht gegeben haben, also lief die Maschine angeblich schon immer mit 2 Kernen.


    Vielen Dank und Gruß Martin

    Mittwoch, 11. Oktober 2017 10:49
  • Moin,

    SQL Express nutzt ab 2012 eine CPU mit bis zu vier Kernen. Auf vSphere kann man die Verteilung der zugewiesenen vCPUs steuern, dann wird es dem Gast-OS wahlweise als 1 CPU mit 4 Kernen, 2 CPU mit 2 Kernen oder 4 CPU mit 1 Kern präsentiert, wenn am Ende 4 vCPUs rauskommen sollen. Dass es sich ohne Eingriff des vSphere-Betreibers von alleine verstellt hat, halte ich für nahezu ausgeschlossen.


    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

    Mittwoch, 11. Oktober 2017 10:53
  • Hallo,

    ich denke das Thema ist geklärt. Seitdem wir die verschwundenen Kerne wieder haben, läuft der Server wieder wie er soll. Vielen, vielen Dank für Eure Hilfe.


    Vielen Dank und Gruß Martin

    Donnerstag, 12. Oktober 2017 07:21