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

Navigieren in SQL Server-Fehlerprotokollen

Einführung

Eine der wichtigsten Fähigkeiten, die Sie als Datenbankadministrator oder IT-Mitarbeiter benötigen, ist im Allgemeinen die Fähigkeit, Systeme sehr sorgfältig zu überwachen. Das Fehlen dieser Schlüsselqualifikation kann zu Fehldiagnosen bei der Fehlerbehebung führen. SQL Server bietet eine Reihe von Tools, die den DBA bei der Behebung von Problemen unterstützen können, die in der Produktion auftreten. Das SQL Server-Fehlerprotokoll und das SQL Server-Agentenprotokoll sind zwei der wichtigsten Einrichtungen für die Problembehandlung von SQL Server. In diesem Artikel werden wir untersuchen, wie wir die Server- und Agentenprotokolle manipulieren können.

Standardverhalten

Standardmäßig speichert SQL Server die letzten sechs Fehlerprotokolle und die letzten neun Agentenprotokolle in der Instanz. Standardmäßig wird bei jedem Neustart der Instanz des Agenten eine neue Protokolldatei generiert. Die Anzahl der aufbewahrten Protokolldateien kann für die SQL Server-Protokolle mithilfe der Anweisung der entsprechenden GUI unten geändert werden (Abb. 1). Um diese GUI im Objekt-Explorer zu öffnen, klicken Sie mit der rechten Maustaste auf Verwaltung , Wählen Sie SQL Server-Fehlerprotokoll aus und klicken Sie auf Konfigurieren .

Abb. 1. Die letzten sechs Fehlerprotokolle

Jede Protokolldatei wird beim Neustart generiert und physisch in C: gespeichert \Programme\Microsoft SQL Server\MSSQL14.\MSSQL\Log zusammen mit Trace-Dateien und Dump-Dateien. SQL Server-Fehlerprotokolle heißen ERRORLOG.x (wobei x eine Zahl ist), während SQL Agent-Protokolle SQLAGENT.x heißen.

Während des Instanzstarts schreibt die Engine wichtige Informationen in das Fehlerprotokoll, darunter:

Details zur SQL Server-Version Systemhersteller

  • SQL Server-Prozess-ID
  • Verwendete Portnummer
  • Authentifizierungsmodus
  • Startparameter der Registrierung
  • Dienstkonto
  • Größe von CPU und Arbeitsspeicher erkannt
  • Status der Schlüsseloptionen, z. Large Pages, Buffer Pool Extension, In-Memory OLTP etc.

Diese Informationen können sehr nützlich sein, wenn Sie nur schnell etwas über sie aus der Instanz erfahren möchten, die Ihnen vorgestellt wird.

Fehlerprotokolloptionen konfigurieren

Wie bereits erwähnt, sind bestimmte Aspekte des SQL-Fehlerprotokolls und des Agentenprotokolls konfigurierbar. In meiner Umgebung setzen wir NumErrorLogs auf 30, weil wir die Protokolle der letzten 30 Tage täglich aufbewahren möchten. Wir stellen sicher, dass jede Protokolldatei die Daten eines Tages enthält, indem wir sp_cycle_errorlog (und sp_cycle_agent_errorlog) um Mitternacht mit einem Agent-Job ausführen. Listing 3 zeigt die Details dieses Jobs. Diese gespeicherten Prozeduren können auch sehr nützlich sein, um das Fehlerprotokoll explizit zu durchlaufen, wenn Sie ein Problem reproduzieren und beobachten möchten, wie es sich entwickelt (d. h. bevor es an SQL Profiler oder Extended Events eskaliert).

-- Listing 1: Configure NumErrorLogs
USE [master]
GO
EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'NumErrorLogs', REG_DWORD, 30 GO

Abb. 2. Einstellen der maximalen Anzahl von Fehlerprotokolldateien

Das SQL Agent-Fehlerprotokoll kann bis zu einem gewissen Grad detailliert konfiguriert werden, indem Sie mit der rechten Maustaste auf SQL Server Agent klicken , und dann Fehlerprotokolle und wählen Sie Konfigurieren aus dem Menü. Listing 2 und Abb. 2 zeigen, wie man den Logging-Level verändert.

-- Listing 2: Setting Error Logging Level
USE [msdb]
GO
EXEC msdb dbo.sp_set_sqlagent_properties @errorlogging_level 7 GO

Abb. 3. Festlegen der Optionen für das Fehlerprotokoll des SQL-Agenten

-- Listing 3
/* Create Job to Cycle Server and Agent Error Logs */
USE [msdb]
GO
/****** Object: Job [Cycle Error Logs] Script Date: 01/25/2015 15:40:34 ******/
BEGIN TRANSACTION
DECLARE @ReturnCode INT
SELECT @ReturnCode = 0
/****** Object: JobCategory [[Uncategorized (Local)]]] Script Date: 01/25/2015 15:40:34 ******/
IF NOT EXISTS (SELECT name FROM msdb.dbo.syscategories WHERE name=N'[Uncategorized (Local)]' AND
category_class 1
BEGIN
EXEC @ReturnCode = msdb dbo sp_add_category @class N'JOB', @type=N'LOCAL',
@name=N'[Uncategorized (Local)]'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
END
DECLARE @jobId BINARY(16
EXEC @ReturnCode = msdb dbo sp_add_job @job_name=N'Custom_Cycle_Error_Logs',
@enabled 1
@notify_level_eventlog 0,
@notify_level_email 0,
@notify_level_netsend 0
@notify_level_page 0
@delete_level 0,
@description=N'No description available.',
@category_name=N'[Uncategorized (Local)]',
@owner_login_name N'COMPANYDOMAIN\kigiri', @job_id = @jobId OUTPUT IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback /****** Object: Step [Step 1] Script Date: 01/25/2015 15:40:35 ******/
EXEC @ReturnCode = msdb dbo sp_add_jobstep @job_id @jobId, @step_name N'Step 1',
@step_id 1
@cmdexec_success_code 0
@on_success_action 1
@on_success_step_id 0,
@on_fail_action 2
@on_fail_step_id 0,
@retry_attempts 0
@retry_interval 0
@os_run_priority 0, @subsystem=N'TSQL',
@command=N'EXEC master.sys.sp_cycle_errorlog GO
EXEC msdb.dbo.sp_cycle_agent_errorlog
GO',
@database_name=N'master',
@flags 0
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb dbo sp_update_job @job_id = @jobId @start_step_id = 1
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb dbo sp_add_jobschedule @job_id @jobId @name N'Daily Schedule', @enabled 1 @freq_type 4,
@freq_interval 1 @freq_subday_type 1 @freq_subday_interval 0 @freq_relative_interval 0 @freq_recurrence_factor 0 @active_start_date 20121208,
@active_end_date 99991231 @active_start_time 0 @active_end_time 235959
[email protected]_uid=N'f3eb3e85-9875-4cf5-a789-8c558b772d27'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb dbo sp_add_jobserver @job_id = @jobId @server_name = N'(local)' IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback COMMIT TRANSACTION
GOTO EndSave
QuitWithRollback:
IF (@@TRANCOUNT > 0) ROLLBACK TRANSACTION
EndSave:
GO
/* Change Maximum Number of Error Log Files to 30 */
USE [master]
GO
EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'NumErrorLogs', REG_DWORD, 30 GO
/* Set jo history length and agent properties */
EXEC msdb dbo.sp_purge_jobhistory @oldest_date '2015-11-28T19:29:00'
GO
USE [msdb]
GO
EXEC msdb dbo.sp_set_sqlagent_properties @jobhistory_max_rows 10000, @jobhistory_max_rows_per_job 1000
GO

"Durchströmen" von Baumstämmen

Sich mit dem Fehlerprotokoll vertraut zu machen, ist hilfreich, um Dinge wie die im zweiten Abschnitt aufgeführten Elemente zu identifizieren oder Ereignisse wie die Wiederherstellung einer großen Datenbank zu überwachen. Wenn Sie jedoch nach einem bestimmten Element suchen, z. B. nach Anmeldefehlern oder ähnlichen Fehlern, die im Meer von Protokollen versteckt sind, möchten Sie möglicherweise den Filter verwenden oder Suchen Fähigkeit.

Abb. 4. Filtern und Suchen

Die Suche wäre nützlich, wenn Sie nach einer bestimmten Fehlernummer oder einem bestimmten Text suchen. Die Suche gibt jeweils die Vorkommen des Elements zurück, das zeilenweise erforderlich ist. Wenn Sie das Fehlerprotokoll anhand bestimmter Kriterien eingrenzen müssen, verwenden Sie den Filter. Sie können nach Verbindung filtern , Datum oder allgemein Details.

Abb. 5. Suchkriterium

Abb. 6. Filterkriterium

Wenn die Instanz fehlschlägt

Eine gute Frage, die ein begeisterter Leser stellen würde, ist, was passiert, wenn SQL Server nicht gestartet werden kann? Wie untersuchen wir die Protokolle? Nun, neben der Tatsache, dass die Fehlerprotokolle in Flatfiles geschrieben werden, deren Pfad zuvor angegeben wurde, können Sie auch die Server- und Agentenprotokolle in der Windows-Ereignisanzeige anzeigen. Sie müssen lediglich die Anwendungsprotokolle der Ereignisanzeige nach Ereignissen mit der Quelle MSSQLSERVER. filtern In fortgeschritteneren Umgebungen können SQL Server-Protokolle wie alle anderen Windows-Protokolle in einem Drittanbieter-Tool wie SEIM oder Splunk gespeichert werden. Das macht die Sache so viel einfacher. Ab SQL Server 2012 ist es auch möglich, Offline-Fehlerprotokolle von einer anderen Instanz vollständig anzuzeigen, sowohl mit registrierten Servern als auch mit WMI und WQL.

Abb. 7. Anzeigen von SQL Server-Protokollen in der Ereignisanzeige

Schlussfolgerung

Das SQL Server-Fehlerprotokoll kann als Ausgangspunkt für die Problembehandlung häufiger Fehler angesehen werden. Andere Protokolle, wie z. B. Ablaufverfolgungsdateien, die von SQL Trace generiert oder von SQL Profiler oder Extended Events Session erfasst wurden, geben weitaus mehr Details darüber, was in der Engine passiert. Es gibt auch spezielle Protokolle wie die zu Datenbank-E-Mail oder Replikation. Obwohl diese alle sehr nützlich für die Fehlersuche bei Problemen in SQL Server sind, würde ich SQL Server-Fehlerprotokolle als guten Ausgangspunkt empfehlen.

Referenzen

Anzeigen des SQL Server-Fehlerprotokolls

Anzeigen von Offline-Protokolldateien

Sp-Zyklus-Fehlerprotokoll

Sp-Cycle-Agent-Fehlerprotokoll

SQL Server-Standardinstallationspfad