Überwachen der Windows Azure SQL-Datenbank mit dynamischen Verwaltungssichten
Microsoft Windows Azure SQL-Datenbank ermöglicht das Diagnostizieren von Leistungsproblemen mit einigen der dynamischen Verwaltungssichten. Leistungsprobleme können beispielsweise durch blockierte Abfragen oder durch Abfragen mit langer Ausführungszeit bzw. durch Ressourcenengpässe, unzureichende Abfragepläne oder Ähnliches verursacht werden. Dieses Thema enthält Informationen zum Erkennen allgemeiner Leistungsprobleme mithilfe der dynamischen Verwaltungssichten in Windows Azure SQL-Datenbank.
Von Windows Azure SQL-Datenbank werden drei Kategorien von dynamischen Verwaltungssichten teilweise unterstützt:
-
Datenbankbezogene dynamische Verwaltungssichten
-
Ausführungsbezogene dynamische Verwaltungssichten
-
Transaktionsbezogene dynamische Verwaltungssichten
Eine Liste mit vollständig unterstützten dynamischen Verwaltungssichten in Windows Azure SQL-Datenbank finden Sie unter Systemsichten (Windows Azure SQL-Datenbank). Ausführliche Informationen zu dynamischen Verwaltungssichten finden Sie in der SQL Server-Onlinedokumentation unter Dynamische Verwaltungssichten und Funktionen (Transact-SQL).
Berechtigungen
Zum Abfragen einer dynamischen Verwaltungssicht in Windows Azure SQL-Datenbank werden VIEW DATABASE STATE-Berechtigungen benötigt. Die VIEW DATABASE STATE-Berechtigung gibt Informationen zu allen Objekten innerhalb der aktuellen Datenbank zurück.
Führen Sie die folgende Abfrage aus, um die VIEW DATABASE STATE-Berechtigung einem bestimmten Datenbankbenutzer zu erteilen:
GRANT VIEW DATABASE STATE TO database_user;
In einer lokalen Instanz von SQL Server geben dynamische Verwaltungssichten Informationen zum Serverstatus zurück. In Windows Azure SQL-Datenbank geben sie nur Informationen zur aktuellen logischen Datenbank zurück.
Hinweis |
|---|
| Beim Ausführen der Sichten "sys.dm_exec_requests" und "sys.dm_exec_sessions" gilt Folgendes: Wenn der Benutzer für die Datenbank über die VIEW DATABASE STATE-Berechtigung verfügt, werden dem Benutzer alle ausgeführten Sitzungen der Datenbank angezeigt. Andernfalls wird dem Benutzer nur die aktuelle Sitzung angezeigt. |
Berechnen der Datenbankgröße
Ihnen werden die Edition und die Kapazität der jeweiligen SQL-Datenbanken in Rechnung gestellt. Wenn die Größe der Datenbank den Wert für MAXSIZE erreicht, wird der Fehlercode 40544 ausgegeben. Sie können dann so lange keine Daten hinzufügen/aktualisieren oder neue Objekte (wie Tabellen, gespeicherte Prozeduren, Sichten oder Funktionen) erstellen, bis Sie den MAXSIZE-Wert der Datenbank aktualisieren oder Daten löschen. Weitere Informationen finden Sie unter Konten und Abrechnung in der Windows Azure SQL-Datenbank. Die sys.dm_db_partition_stats-Sicht gibt für jede Partition in der Datenbank Informationen zur Seiten- und Zeilenanzahl zurück, mit deren Hilfe sich die Datenbankgröße berechnen lässt.
Die folgende Abfrage gibt die Größe der Datenbank (in Megabyte) zurück:
-- Calculates the size of the database. SELECT SUM(reserved_page_count)*8.0/1024 FROM sys.dm_db_partition_stats; GO
Die folgende Abfrage gibt die Größe einzelner Objekte in der Datenbank (in Megabyte) zurück:
-- Calculates the size of individual database objects. SELECT sys.objects.name, SUM(reserved_page_count) * 8.0 / 1024 FROM sys.dm_db_partition_stats, sys.objects WHERE sys.dm_db_partition_stats.object_id = sys.objects.object_id GROUP BY sys.objects.name; GO
Überwachen von Verbindungen
Mithilfe der sys.dm_exec_connections (Windows Azure SQL-Datenbank)-Sicht können Sie Informationen zu den mit einem bestimmten SQL-Datenbank-Server hergestellten Verbindungen sowie Details zu den einzelnen Verbindung abrufen. Außerdem ist die sys.dm_exec_sessions-Sicht beim Abrufen von Informationen zu allen aktiven Benutzerverbindungen und internen Aufgaben hilfreich.
Mit der folgenden Abfrage werden Informationen zur aktuellen Verbindung abgerufen:
-- monitor connections
SELECT
e.connection_id,
s.session_id,
s.login_name,
s.last_request_end_time,
s.cpu_time
FROM
sys.dm_exec_sessions s
INNER JOIN sys.dm_exec_connections e
ON s.session_id = e.session_id
GO
Überwachung der Abfrageleistung
Langsame Abfragen oder Abfragen mit langer Ausführungszeit können zu einer hohen Auslastung der Systemressourcen führen. Dieser Abschnitt veranschaulicht das Erkennen einiger allgemeiner Leistungsprobleme bei Abfragen mithilfe dynamischer Verwaltungssichten. Ausführliche Informationen finden Sie im Microsoft TechNet-Artikel Behandeln von Leistungsproblemen in SQL Server 2005.
Ermitteln der ersten N-Abfragen
Das folgende Beispiel gibt Informationen zu den fünf Abfragen mit der höchsten durchschnittlichen CPU-Zeit zurück. Die Abfragen werden in diesem Beispiel anhand des Abfragehashes aggregiert, sodass logisch identische Abfragen basierend auf dem kumulierten Ressourcenverbrauch gruppiert werden.
-- Find top 5queries
SELECT TOP 5 query_stats.query_hash AS "Query Hash",
SUM(query_stats.total_worker_time) / SUM(query_stats.execution_count) AS "Avg CPU Time",
MIN(query_stats.statement_text) AS "Statement Text"
FROM
(SELECT QS.*,
SUBSTRING(ST.text, (QS.statement_start_offset/2) + 1,
((CASE statement_end_offset
WHEN -1 THEN DATALENGTH(st.text)
ELSE QS.statement_end_offset END
- QS.statement_start_offset)/2) + 1) AS statement_text
FROM sys.dm_exec_query_stats AS QS
CROSS APPLY sys.dm_exec_sql_text(QS.sql_handle) as ST) as query_stats
GROUP BY query_stats.query_hash
ORDER BY 2 DESC;
GO
Überwachen blockierter Abfragen
Langsame Abfragen oder Abfragen mit langer Ausführungszeit können eine übermäßige Ressourcenauslastung verursachen und auf blockierte Abfragen zurückzuführen sein. Zu den möglichen Ursachen für die Blockierung zählen unter anderem ein unausgereifter Anwendungsentwurf, unzureichende Abfragepläne oder ein Mangel an nützlichen Indizes. Informationen zur aktuellen Sperraktivität in der SQL-Datenbank können mithilfe der sys.dm_tran_locks-Sicht abgerufen werden. Beispielcode finden Sie in der SQL Server-Onlinedokumentation unter sys.dm_tran_locks (Transact-SQL).
Überwachen von Abfrageplänen
Eine erhöhte CPU-Auslastung kann auch auf einen ineffizienten Abfrageplan zurückzuführen sein. Im folgenden Beispiel wird mithilfe der sys.dm_exec_query_stats-Sicht die Abfrage mit der höchsten kumulativen CPU-Auslastung ermittelt.
-- Monitor query plans
SELECT
highest_cpu_queries.plan_handle,
highest_cpu_queries.total_worker_time,
q.dbid,
q.objectid,
q.number,
q.encrypted,
q.[text]
FROM
(SELECT TOP 50
qs.plan_handle,
qs.total_worker_time
FROM
sys.dm_exec_query_stats qs
ORDER BY qs.total_worker_time desc) AS highest_cpu_queries
CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS q
ORDER BY highest_cpu_queries.total_worker_time desc
Siehe auch
Hinweis