Søren Eggert Lundsteen Olsen
cb99778a3f
After the rebase onto 1.4 the 16 SQLI-WIN/SQLI-SYN scripts had their own /* */ format, so SqlScriptTests (rule ids, review header, -- Kilde: blocks) failed. - The scripts have main's header (Regel-id, Titel, Alvor, Versioner, Vurdering, Grænseværdier, Rettigheder, Data kommer fra, Regelkode, Read-only); the Windows WQL/XPath stays word for word in comments. - The synthetic SQL check's SQL is registered (SyntheticCheckRunner.UseDatabaseSql, BeginTransactionSql, RollbackSql, SyntheticCheckSettings.DefaultQuery) and shown as -- Kilde: blocks in SQLI-SYN-001/002 and _collectors/SyntheticCheckRunner.sql. - SqlScriptTests know ServerRuleCatalog; only those rules may be without SQL blocks. - ServerScriptTests: every CimQueries query/filter is in a SQLI-WIN script word for word. - The SQL check cancels the rest of a large answer instead of draining it on close. - Rule counts: README (108 built-in: 92 SQL Server + 13 Windows + 3 synthetic), SQL Scripts/README (rule table, 124 rules, Windows/synthetic section), RuleCatalogTests, CONTRIBUTING (how to add a server rule). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
73 lines
4.4 KiB
Transact-SQL
73 lines
4.4 KiB
Transact-SQL
-- ===================================================================================================================
|
||
-- SQLI-SYN-002: Et syntetisk tjek svarer langsomt
|
||
-- ===================================================================================================================
|
||
-- Regel-id: SQLI-SYN-002
|
||
-- Titel: Et syntetisk tjek svarer langsomt
|
||
-- Alvor: Medium.
|
||
-- Versioner: Som SQLI-SYN-001.
|
||
--
|
||
-- Hvad tjekkes, og hvorfor:
|
||
-- Tjekket lykkes, men svaret har de seneste gange taget længere end tjekkets grænse. Brugerne oplever det som en langsom
|
||
-- applikation, længe før den holder op med at svare.
|
||
--
|
||
-- Vurdering (sker i C# ud fra de indsamlede data, ikke på den overvågede server):
|
||
-- Er de seneste SlowRunsBeforeFinding kørsler alle lykkedes og alle langsommere end grænsen, er det et fund.
|
||
--
|
||
-- Grænseværdier (agentens appsettings.json og tjekkets indstillinger):
|
||
-- Pr. tjek: "Langsomt svar over (ms)" (insight.SyntheticChecks.SettingsJson: warnMilliseconds). Uden grænse: "ikke relevant".
|
||
-- SQLInsight:SyntheticChecks:SlowRunsBeforeFinding standard 3 (langsomme svar i træk før et fund)
|
||
--
|
||
-- Rettigheder:
|
||
-- Som SQLI-SYN-001.
|
||
--
|
||
-- Data kommer fra (collector, fil – medlemmer, interval):
|
||
-- src/SQLInsight.Servers/Synthetic/SyntheticCheckRunner.cs – SyntheticCheckRunner.RunAsync (DurationMs: hele tjekket, for
|
||
-- SQL login + forespørgsel), fra src/SQLInsight.Agent/Servers/SyntheticCheckService.cs – RunCheckAsync.
|
||
-- Regelkode: src/SQLInsight.Rules/Servers/SyntheticCheckRules.cs : SyntheticCheckSlowRule
|
||
--
|
||
-- Read-only: Ja. Ved et SQL-tjek valideres forespørgslen som én skrivebeskyttet SELECT, både når tjekket gemmes og
|
||
-- før hver kørsel (src/SQLInsight.Core/CustomRules/ReadOnlyQuery.cs), og den køres i en transaktion, der
|
||
-- altid rulles tilbage. Andre typer tjek sender ingen SQL og ændrer intet.
|
||
-- Kørsel: Kør i SSMS som tjekkets login. Hver GO er en separat kommando på samme forbindelse; ret [msdb] til
|
||
-- tjekkets database, eller udelad USE, hvis tjekket ingen database har.
|
||
-- ===================================================================================================================
|
||
|
||
-- SQL: Et SQL-tjek kører præcis det samme som i SQLI-SYN-001 (svartiden er login plus forespørgsel):
|
||
|
||
-- -------------------------------------------------------------------------------------------------------------------
|
||
-- SyntheticCheckRunner: SQL-tjekket (login, sessionsindstillinger, forespørgslen i en transaktion, der rulles tilbage)
|
||
-- -------------------------------------------------------------------------------------------------------------------
|
||
|
||
-- Variant: Alle versioner: sættes på hver forbindelse, agenten åbner (også tjekkets)
|
||
-- Kilde: SqlConnectionFactory.SessionSettings
|
||
-- Kode: src/SQLInsight.Connectivity/SqlConnectionFactory.cs : SqlConnectionFactory.SessionSettings
|
||
SET LOCK_TIMEOUT 5000; SET DEADLOCK_PRIORITY LOW; SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
|
||
GO
|
||
|
||
-- Variant: Kun når tjekket har en database (vist for msdb)
|
||
-- Kilde: SyntheticCheckRunner.UseDatabaseSql
|
||
-- Kode: src/SQLInsight.Servers/Synthetic/SyntheticCheckRunner.cs : SyntheticCheckRunner.UseDatabaseSql(database)
|
||
USE [msdb];
|
||
GO
|
||
|
||
-- Variant: Alle versioner fra SQL Server 2005: før forespørgslen
|
||
-- Kilde: SyntheticCheckRunner.BeginTransactionSql
|
||
-- Kode: src/SQLInsight.Servers/Synthetic/SyntheticCheckRunner.cs : SyntheticCheckRunner.BeginTransactionSql
|
||
BEGIN TRANSACTION;
|
||
GO
|
||
|
||
-- Variant: Standardforespørgslen, når tjekket ikke har sin egen (en egen forespørgsel køres her i stedet, højst 10.000 rækker læses)
|
||
-- Kilde: SyntheticCheckSettings.DefaultQuery
|
||
-- Kode: src/SQLInsight.Core/SyntheticChecks/SyntheticCheckDefinitions.cs : SyntheticCheckSettings.DefaultQuery
|
||
SELECT 1
|
||
GO
|
||
|
||
-- Variant: Alle versioner fra SQL Server 2005: altid efter forespørgslen, også når den fejler
|
||
-- Kilde: SyntheticCheckRunner.RollbackSql
|
||
-- Kode: src/SQLInsight.Servers/Synthetic/SyntheticCheckRunner.cs : SyntheticCheckRunner.RollbackSql
|
||
IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION;
|
||
GO
|
||
|
||
-- Ikke-SQL-tjek, efterprøv svartiden med PowerShell (skrivebeskyttet):
|
||
-- Measure-Command { Invoke-WebRequest -Uri https://ep.firma.local/ -UseDefaultCredentials -UseBasicParsing } | Select-Object TotalMilliseconds
|
||
-- Measure-Command { Test-NetConnection -ComputerName aos01 -Port 2712 } | Select-Object TotalMilliseconds
|