Sqlserver
 sql >> Datenbank >  >> RDS >> Sqlserver

Abrufen von SQL Server-Statistikinformationen mithilfe von Systemstatistikfunktionen

Häufig müssen wir Systemstatistiken zu laufenden SQL Server-Instanzen sammeln, z. B. die Anzahl der seit dem Start versuchten Verbindungen zur SQL Server-Instanz oder die Zeit, die SQL Server im aktiven Betrieb verbracht hat usw. Microsoft hat uns einen separaten Satz davon gebracht Systemfunktionen zum Abrufen der systembezogenen Statistiken. Heute werde ich solche Systemstatistikfunktionen anhand der Anwendungsfälle erläutern.

Systemstatistikfunktionen in SQL

Systemstatistikfunktionen sind eine Art Skalarfunktion, die einen einzelnen Wert in der Ausgabe zurückgibt. Dieser liefert statistische Informationen über das System. Ein wesentlicher Hinweis ist, dass alle Funktionen, die unter diese Kategorie fallen, nicht die gleiche Ausgabe zurückgeben, wenn Sie sie ausführen. Für jede Ausführung erhalten Sie ein anderes Ergebnis. Aus diesem Grund sind Systemstatistikfunktionen nicht deterministisch.

SQL Server verfügt über mehrere integrierte Systemstatistikfunktionen, die die systembezogenen Statistiken zurückgeben. Unten ist die Liste:

  • @@VERBINDUNGEN
  • @@PACK_RECEIVED
  • @@CPU_BUSY
  • @@PACK_SENT
  • @@TIMETICKS
  • @@IDLE
  • @@TOTAL_ERRORS
  • @@IO_BUSY
  • @@TOTAL_READ
  • fn_virtualfilestats
  • @@PACKET_ERRORS
  • @@TOTAL_WRITE

Lassen Sie uns sie jetzt genauer untersuchen.

Die Systemfunktionen @@CPU_BUSY und @@TIMETICKS verstehen

@@CPU_BUSY ist entscheidend, wenn wir verstehen müssen, wie viel Zeit in Millisekunden die CPU für die Arbeit an SQL Server-Operationen aufgewendet hat. Das Ergebnis dieser Funktion ist bei jeder Ausführung seit dem letzten Neustart von SQL Server inkrementell. Das bedeutet, dass wir für jeden Lauf einen inkrementellen Wert in der Ausgabe erhalten. Siehe Beispiel:

--Execute below T-SQL to get how busy your CPU is
SELECT @@CPU_BUSY

Die Ausgabe:

Es gibt einen einzelnen numerischen Wert zurück, was bedeutet, dass die CPU seit dem letzten Neustart des SQL Server-Dienstes 641 Millisekunden für die Ausführung der SQL Server-Transaktionen aufgewendet hat.

Lassen Sie uns nun eine einfache SELECT-Anweisung ausführen. Ich werde die obige T-SQL-Anweisung erneut ausführen, um zu überprüfen, ob die Ausgabe inkrementell ist.

--Fetch top 1000 rows for a table
SELECT TOP (1000) [BusinessEntityID]
      ,[PersonType]
      ,[NameStyle]
      ,[Title]
      ,[FirstName]
      ,[MiddleName]
      ,[LastName]
      ,[Suffix]
      ,[EmailPromotion]
      ,[AdditionalContactInfo]
      ,[Demographics]
      ,[rowguid]
      ,[ModifiedDate]
  FROM [AdventureWorks2019].[Person].[Person]

Die Ausgabe:

Lassen Sie uns SELECT @@CPU_BUSY ausführen erneut, um die Ausgabe zu sehen:

Hier sehen wir einen inkrementellen Wert von 653 Millisekunden im Vergleich zu dem im ersten Screenshot zurückgegebenen Wert von 641 Millisekunden. Daher haben wir validiert, dass diese Systemfunktionen einzelne inkrementelle Werte zurückgeben.

Lassen Sie uns nun tiefer eintauchen. Wir werden prüfen, wie @@CPU_BUSY verwendet wird in verschiedenen Szenarien für unsere Anforderungen.

Wie oben erwähnt, ist @@CPU_BUSY Systemfunktion gibt die Ausgabe in Millisekunden zurück . Wenn Sie die Ausgabe in Mikrosekunden erhalten möchten , müssen Sie die @@TIMETICKS verwenden Funktion, während die @@CPU_BUSY T-SQL-Anweisung ausgeführt wird (siehe die folgenden Befehle).

@@TIMETICKS gibt die Anzahl der Mikrosekunden pro Tick zurück .

Tick ​​ist eine Art Scheduling-Ereignis, das bewirkt, dass die Scheduler ausgeführt werden. Die Zeitdauer pro Tick ist der computerabhängige Wert, der durch Ausführen der folgenden T-SQL-Anweisung abgerufen werden kann:

--Get @@TIMETICKS output
SELECT @@TIMETICKS

Hier ist die Ausgabe:

Wir werden beide Funktionen zusammen verwenden, um ihre Ausgabe in Mikrosekunden und Sekunden zu erhalten:

--Get @@CPU_BUSY output in Microseconds & seconds
SELECT @@CPU_BUSY*@@TIMETICKS As [CPU Busy Microseconds]
Go
SELECT @@CPU_BUSY*@@TIMETICKS/1000000 As [CPU Busy Seconds]
Go 

Nachdem wir beide T-SQL-Anweisungen ausgeführt haben, können wir die Ausgaben sehen:

Hinweis:Wenn Sie die Ausgabe von @CPU_BUSY in einem Float-Datentyp erhalten möchten , können Sie dies auch erledigen, indem Sie die folgenden Anweisungen ausführen:

--Get @@CPU_BUSY output in Microseconds & seconds with float data type
SELECT @@CPU_BUSY*CAST (@@TIMETICKS As float) As [CPU Busy Microseconds], 
@@CPU_BUSY*CAST (@@TIMETICKS As float)/1000000 As [CPU Busy Seconds]
Go

Die Ausgabe:

Fahren Sie fort und verwenden Sie die Systemfunktionen @@CPU_BUSY und @@TIMETICK gemäß Ihren geschäftlichen Anforderungen.

Verstehen der @@IO_BUSY-Systemfunktion

Wie der Name schon sagt, gibt diese Systemfunktion die Gesamtzeit in Millisekunden zurück, die der SQL Server seit dem letzten Neustart von SQL Server mit der Ausführung von IO-Operationen (Input\Output-Operationen) verbracht hat. Die Ausgabe dieser Systemfunktion ist auch jedes Mal inkrementell, wenn Sie sie ausführen.

Führen Sie die folgende T-SQL-Anweisung aus:

--Get total time SQL Server has taken in IO operations since its last restart
SELECT @@IO_BUSY

Die Ausgabe im unteren Bild beträgt 194 Millisekunden.

Wir können auch die Systemfunktion @@TIMETICKS verwenden, um den Wert in Mikrosekunden zu erhalten:

--Get total time SQL Server has taken in IO operations since its last restart
SELECT @@IO_BUSY*@@TIMETICKS AS [IO Microseconds]
GO
SELECT @@IO_BUSY*@@TIMETICKS/1000000 AS [IO Seconds]

Hier ist die Ausgabe der obigen T-SQL-Anweisung:

Wenn Sie einen arithmetischen Überlauf vermeiden möchten, während Sie den Wert mit der @@TIMETICKS-Systemfunktion in Mikrosekunden umwandeln, führen Sie den folgenden Befehl aus, um seine Ausgabe in einem Float-Datentyp zu erhalten, wie wir es zuvor für die @@CPU_BUSY-Funktion getan haben:

--Get total time SQL Server has taken in IO operations since its last restart
SELECT @@IO_BUSY*CAST (@@TIMETICKS As float) AS [IO Microseconds]
GO
SELECT @@IO_BUSY*CAST (@@TIMETICKS As float)/1000000 AS [IO Seconds]
Go

Verstehen der @@IDLE-Systemfunktion

Diese Systemfunktion gibt die Zeit in Millisekunden für den SQL Server-Leerlauf seit dem letzten Neustart zurück. Führen Sie den folgenden Befehl aus:

--Get total time SQL Server was idle
SELECT @@IDLE

Hier ist die Ausgabe:

Sie können auch die GETDATE()-Funktion zusammen mit allen oben genannten Systemfunktionen verwenden, um ihren Wert zwischen der aktuellen Uhrzeit und der Uhrzeit des Neustarts von SQL Server abzurufen. Wenn Sie diesen Wert in Mikrosekunden erhalten möchten, verwenden Sie die Funktion @@TIMETICKS wie für die Funktionen @@CPU_BUSY und @@IO_BUSY gezeigt.

Die folgende T-SQL-Anweisung ist den vorherigen Beispielen sehr ähnlich. Es gibt die Anzahl der Sekunden und Mikrosekunden in einem Float-Datentyp zurück.

--Get total time SQL Server was idle
SELECT @@IDLE* CAST(@@TIMETICKS AS Float) As [IO Microseconds]
GO
SELECT @@IDLE*CAST(@@TIMETICKS AS Float)/1000000 AS [IO Seconds]
Go

Die Ausgabe:

Verstehen von @@PACK_SENT, @@PACK_RECEIVED und @@PACKET_ERRORS

Diese statistischen Systemfunktionen beziehen sich auf Netzwerkpakete. Sie sind äußerst nützlich bei der Analyse der Informationen über Netzwerkpakete.

  • @@PACK_SENT – gibt die Anzahl der Ausgabepakete zurück, die SQL Server seit dem letzten Neustart ins Netzwerk geschrieben hat.
  • @@PACK_RECEIVED – zeigt die Anzahl der Eingabepakete an, die SQL Server seit dem letzten Neustart aus dem Netzwerk gelesen hat.
  • @@PACKET_ERRORS – Zeigt die Anzahl der Netzwerkpaketfehler an, die seit dem letzten Neustart bei SQL Server-Verbindungen aufgetreten sind.

Wir können die folgenden T-SQL-Anweisungen verwenden, um die Anzahl der Eingabe- und Ausgabepakete zu erhalten, die von SQL Server gelesen oder geschrieben werden sollen.

--Get the number of packets received or sent
SELECT @@PACK_SENT AS [Packets Sent]
GO
SELECT @@PACK_RECEIVED AS [Packets RECIEVED]
GO

Die Details zu diesen Paketen finden Sie in der Ausgabe:

Sie können auch @@PACKET_ERRORS ausführen ähnlich, um die Gesamtzahl der Paketfehler zu erhalten:

--Get number of packets Errors
SELECT @@PACKET_ERRORS

Verstehen von @@TOTAL_READ, @@TOTAL_WRITE und @@TOTAL_ERRORS

Die festplattenbezogenen Systemstatistikfunktionen rufen die Anzahl der von SQL Server ausgeführten Lese-, Schreib- und Schreibfehler auf der Festplatte ab.

  • @@TOTAL_READ – zeigt die Anzahl der Festplattenlesevorgänge von SQL Server seit dem letzten Neustart an.
  • @@TOTAL_WRITE – zeigt die Anzahl der Festplattenschreibvorgänge von SQL Server seit dem letzten Neustart an.
  • @@TOTAL_ERRORS – zeigt die Anzahl der Festplattenschreibfehler von SQL Server seit dem letzten Neustart an. Denken Sie daran, dass nicht schwerwiegende Schreibfehler von dieser Funktion nicht erfasst werden – sie werden vom System selbst behandelt.

Ich habe alle 3 Systemfunktionen in einer T-SQL-Anweisung zusammengefasst, um die Ausgabe von allen auf einen Schlag anzuzeigen:

--Get Disk related statistics
SELECT @@TOTAL_READ AS [Reads], 
@@TOTAL_WRITE AS [Writes], 
@@TOTAL_ERRORS As [Disk Errors]

Unten sehen Sie die Anzahl der Lese-, Schreib- und Schreibfehler:

Verstehen der @@CONNECTIONS-Systemfunktion

Diese Systemfunktion zeigt die Gesamtzahl der Verbindungsversuche mit SQL Server unabhängig von ihrem Erfolg seit dem letzten Neustart von SQL Server an. Führen Sie die folgende T-SQL-Anweisung aus:

--Get the number of attempted connections
SELECT @@CONNECTIONS AS [Total Connections]

Die folgende Ausgabe zeigt, dass die Gesamtzahl der Verbindungsversuche für diese SQL Server-Instanz 3130 beträgt. Das bedeutet nicht, dass alle 3130 Versuche erfolgreich waren.

Alle statistischen Systemfunktionen in einer T-SQL-Anweisung

Wir können auch alle diese Systemfunktionen in einer T-SQL-Anweisung kombinieren und eine einzelne Ausgabe für jeden Systemstatistikwert erhalten. Ich habe jede der Systemfunktionen separat erklärt, da diese für Ihre Arbeitsanforderungen und Anforderungen sehr nützlich sein könnten.

Führen Sie das folgende T-SQL-Skript aus, um die Ausgabe aller beschriebenen Systemstatistiken auf einmal zu erhalten:

--Get system statistics
SELECT @@CPU_BUSY*CAST (@@TIMETICKS As float) As [CPU Busy Microseconds],
@@CPU_BUSY*CAST (@@TIMETICKS As float)/1000000 As [CPU Busy Seconds],
@@IO_BUSY*CAST (@@TIMETICKS As float) AS [IO Microseconds],
@@IO_BUSY*CAST (@@TIMETICKS As float)/1000000 AS [IO Seconds],
@@IDLE* CAST(@@TIMETICKS AS Float) As [IO Microseconds],
@@IDLE*CAST(@@TIMETICKS AS Float)/1000000 AS [IO Seconds],
@@PACK_SENT AS [Packets Sent],
@@PACK_RECEIVED AS [Packets RECIEVED],
@@TOTAL_READ AS [Reads], 
@@TOTAL_WRITE AS [Writes], 
@@TOTAL_ERRORS As [Disk Errors],
@@CONNECTIONS AS [Total Connections]

Hier ist die Ausgabe des obigen Skripts, die alle statistikbezogenen Informationen in einer Ausgabe anzeigt:

Gespeicherte Prozedur zum Abrufen von SQL Server-Statistiken verwenden

Es gibt auch eine spezielle gespeicherte Microsoft-Systemprozedur, die es uns ermöglicht, eine ähnliche Ansicht der Systemstatistiken zu sehen . Der Name dieser gespeicherten Prozedur lautet sp_monitor . Es eignet sich hervorragend zum Nachverfolgen der Verwendungen und Werte jedes SQL Server-Statistiktyps seit der letzten Ausführung durch dieselbe gespeicherte Prozedur

Hinweis:Sie müssen über die Sysadmin-Rolle verfügen, um diese gespeicherte Prozedur auszuführen.

Ich habe den sp_monitor ausgeführt Stored Procedure – sehen Sie, dass es in einer bestimmten Form wie value(value)-value% angezeigt wird oder Wert(Wert). Wir können cpu_busy sehen Ausgabe, die als 20(19)-0% angezeigt wird. Jetzt denken Sie vielleicht darüber nach, wie wir diese Ausgabe lesen können. Lesen und verstehen Sie die folgende Tabelle – sie enthält die Erklärung für beide Ausgabetypen:

Systemparameter Ausgabe Interpretation
Cpu_busy 20(19)-0 % CPU war seit dem letzten Start von SQL Server 20 Sekunden beschäftigt\restartedCPU war seit der letzten Ausführung von sp_monitor 19 Sekunden beschäftigt0 % der Gesamtzeit seit der letzten Ausführung von sp_monitor.
Pakete_erhalten 1467(1428) SQL Server hat seit dem letzten Start 1467 Pakete empfangen\restartedSQL Server hat 1428 Pakete empfangen seit der letzten Ausführung von sp_monitor.

Schlussfolgerung

Jetzt können Sie sehen, wie Sie die systembezogenen Statistiken für Ihre SQL Server-Instanz erhalten. Die Systemfunktionen und die gespeicherte Prozedur sp_monitor wird sehr effizient und bequem sein. Verwenden Sie diese T-SQL-Codes in Ihrer Entwicklungsarbeit oder für Systemanalyseaktivitäten.

Bitte teilen Sie diesen Artikel in Ihren bevorzugten sozialen Netzwerken. Und wenn Sie diese Informationen diskutieren und Ihre Meinungen und Tipps teilen möchten, sind Sie im Kommentarbereich herzlich willkommen.