Het softwareproduct SQL Server Profiler is een grafische shell die is ontworpen voor het maken van traceringen en het analyseren van traceringsresultaten. Gebeurtenissen worden opgeslagen in een traceringsbestand, dat vervolgens kan worden geanalyseerd of gebruikt om specifieke reeksen stappen opnieuw af te spelen om opgetreden problemen te identificeren.

Om de acties die momenteel worden uitgevoerd te volgen, moet u MS SQL Profiler starten, een nieuwe tracering maken en de analyse van indicatoren configureren:

Op het tabblad Algemeen moet u de naam van de tracering opgeven. Geef op waar de vastgelegde traceergegevens worden opgeslagen: in een bestand en/of in een databasetabel.

Van groot belang is het tabblad ‘Evenementselectie’:

Op deze pagina worden de gebeurtenissen gespecificeerd die moeten worden gemonitord. In dit voorbeeld geven we de gegevens aan die nodig zijn om queryplannen bij te houden.

Ontvang gratis 267 videolessen over 1C:

Standaard wordt de tracering uitgevoerd op alle opgegeven gebeurtenissen in alle databases. Om selecties op de ontvangen gegevens toe te passen, moet u op de knop "Kolomfilters ..." klikken:

Laten we bijvoorbeeld de selectie instellen op infobase-ID (u kunt de database-ID achterhalen met behulp van de query SELECT DB_ID(N’BaseName’)).

Een tracering uitvoeren in Profiler voor 1C

Nadat alle instellingen zijn gemaakt, hoeft u alleen nog maar te beginnen met volgen; klik op "Uitvoeren". Vanaf dit moment worden alle acties die in het filter zijn gespecificeerd, opgenomen in de trace:

Ik voer bijvoorbeeld een tracering uit voor de duur van het document “Ontvangsten van goederen en diensten” om de meest arbeidsintensieve handelingen te volgen.

Zodra het spoor is ontvangen, moet het worden geanalyseerd.

Gegevens uit Profiler analyseren

Voor analyse kan de resulterende tracering in een bestand of in een tabel worden opgeslagen. We slaan het volgende op in een databasetabel:

16-05-2000 Itzik Ben-Gan

Net zoals het nabootsen van een misdaad helpt om de crimineel te vinden, helpt het traceren van een database knelpunten te identificeren en te elimineren.

Het artikel “Catch an Event”, gepubliceerd in een vorige uitgave van het tijdschrift, beschreef de architectuur van het SQL Server 7.0-traceringssysteem en liet zien hoe u een tracering grafisch kunt definiëren in SQL Profiler. Deze keer zullen we het hebben over hoe u traceringen opnieuw kunt maken met behulp van SQL Profiler, en hoe u automatisch starten kunt bepalen met behulp van uitgebreide, opgeslagen traceerprocedures. Voortbouwend op deze krachtige basis kunt u SQL Profiler en opgeslagen procedures vakkundig gebruiken om alles te onderzoeken, van langlopende query's tot complexe impasses.

Voorbereidende voorbereiding voor het reproduceren van de route

Met behulp van SQL Profiler kunt u opgeslagen traceringen herhalen om problemen met toepassingen te debuggen, testscenario's met verschillende praktijksituaties maken, databases configureren en nog veel meer. Als u de route opnieuw moet volgen, moet u wat voorbereidend werk doen. Eerst moet u een tracering definiëren om specifieke gebeurtenissen en kolommen met gegevens bij te houden, anders dan die waarin u geïnteresseerd bent. Het vastleggen van deze extra gebeurtenissen en kolommen zorgt ervoor dat alle acties precies worden herhaald zoals ze voorheen plaatsvonden. Ten tweede moet u de traceerresultaten opslaan in een bestand, tabel of SQL-script.

Voor elke herhaling zijn de gebeurtenissen Connect, Disconnect en ExistingConnection vereist, evenals RPC:Starting en SQL:BatchStarting. Bovendien moet u bij het afspelen van backend-API-cursors (dat wil zeggen servercursors die worden bestuurd door de API-cursorfuncties) de gebeurtenissen CursorExecute, CursorOpen en CursorPrepare vastleggen. Om voorbereide SQL-instructies aan de serverzijde te reproduceren, moet u ook de gebeurtenissen Exec Prepared SQL en Prepare SQL toevoegen. Voor reproductie zijn kolommen nodig die de volgende gegevens bevatten: applicatienaam, binaire informatie, verbindings-ID of serverproces-ID (SPID), database-ID, gebeurtenisklasse, gebeurtenissubklasse, hostnaam, digitale informatie, servernaam, gebruikersnaam SQL, run starttijd en tekstinformatie.

Het is belangrijk op te merken dat bij het opnieuw starten de opgenomen gebeurtenissen niet worden gesimuleerd, maar opnieuw plaatsvinden. Houd er daarom rekening mee dat u tijdens het eerste traceringsproces hoogstwaarschijnlijk uw database hebt gewijzigd. Wanneer u bijvoorbeeld een trace opnieuw afspeelt die een INSERT-instructie bevat, kan er een dubbele sleutel in de tabel verschijnen. Om dergelijke problemen te voorkomen, moet u de database terugzetten naar de oorspronkelijke staat als de tracering opnieuw wordt afgespeeld op de oorspronkelijke server (dat wil zeggen: de server waarop de oorspronkelijke tracering werd uitgevoerd).

Als u een herhaling op een andere server uitvoert, is het belangrijk ervoor te zorgen dat de database op die server zich in dezelfde staat bevindt als de database op de oorspronkelijke server. In dit geval moet u dezelfde gebruikersnamen, hun bevoegdheden en database-ID's gebruiken die op de bronserver zijn gebruikt.

Het gebruik van dezelfde ID's vereist speciale vaardigheden en ervaring, vooral omdat Microsoft niet aanmoedigt om rechtstreeks toegang te krijgen tot de systeemtabel sysdatabases om database-ID's te wijzigen. U kunt database-ID's op een andere manier matchen. Om dit te doen, kopieert u de gebruikersdatabasebestanden van de bronserver naar de server waarop de tracering wordt afgespeeld, en herstelt u vervolgens de hoofddatabaseback-up van de bronserver ernaar. Een alternatieve methode is om de back-up van de gebruikersdatabase van de bronserver te herstellen naar de server die voor de uitvoering is geselecteerd, en vervolgens de back-up van de hoofddatabase daar te herstellen. In beide gevallen zullen de databasebestanden op de server waar de trace wordt afgespeeld zich in dezelfde mappen bevinden als op de bronserver, en zullen de hoofddatabasesysteemtabellen de originele database-ID's bevatten. Om deze problemen volledig te elimineren, verwijdert u eenvoudigweg de database-ID-kolom uit de tracering en stelt u de standaarddatabase in voor elke gebruiker die tijdens de tracering wordt vastgelegd.

U kunt ook het scriptsynchronisatieniveau en de afspeelsnelheid regelen. Selecteer Instellingen in het menu Opnieuw afspelen om het dialoogvenster SQL Server opnieuw afspelen te openen. De parameter Synchronisatieniveau, die de synchronisatie binnen de verbinding regelt, kan de volgende waarden aannemen:

Volledige synchronisatie. Dit is de standaardwaarde. In dit geval worden alle gebeurtenissen die in één verband hebben plaatsgevonden, in hun oorspronkelijke volgorde weergegeven. Gedeeltelijke synchronisatie. Met deze waarde kunnen gebeurtenissen op één verbinding starten vóór gebeurtenissen die al op andere verbindingen zijn opgenomen. Geen synchronisatie. Met deze parameterwaarde kunnen gebeurtenissen plaatsvinden onmiddellijk na het einde van de vorige gebeurtenis in dezelfde verbinding, dat wil zeggen zonder enige synchronisatie binnen de verbinding.

De parameter voor de herhaalsnelheid, Replay Rates, kan worden ingesteld op een van de volgende waarden:

Zo snel mogelijk. Dit is de standaardwaarde. In dit geval begint de volgende gebeurtenis onmiddellijk nadat de vorige is geëindigd. Houd het interval tussen gebeurtenissen aan. Deze waarde behoudt het oorspronkelijke tijdsinterval tussen het optreden van gebeurtenissen. Onderhoud de relatie om de tijd te starten. Met deze waarde vinden gebeurtenissen op dezelfde tijdstippen plaats ten opzichte van het begin van het afspelen van de trace als in de oorspronkelijke trace.

Organisatie van het afspelen van routes

Stel dat u de uitvoeringstracering wilt reproduceren van voorbereide SQL-instructies aan de serverzijde. Dit zijn Transact-SQL-instructies (T-SQL) die door een gebruiker naar de server worden verzonden via ADO, OLE DB of ODBC. SQL Server 7.0 voert op de server voorbereide SQL-instructies uit met behulp van de sp_prepare en sp_execute pseudo-opgeslagen procedures, die worden aangeroepen door de clienttoepassing.

Door sp_prepare aan te roepen, bereidt SQL Server T_SQL-instructies voor op uitvoering door deze te compileren en uitvoeringsplannen in de cache op te slaan. Wanneer sp_execute wordt aangeroepen, voert SQL Server eerder in de cache opgeslagen plannen uit, mogelijk herhaaldelijk. Elke opgeslagen procedureaanroep genereert de gebeurtenissen RPC:BatchStarting, Prepare SQL en Exec Prepared SQL. Het is om deze reden dat deze gebeurtenissen moeten worden opgenomen in de definitie van de route.

SQL Profiler bevat verschillende voorbeelden van traceringsdefinities die u als sjablonen kunt gebruiken. Inclusief voorbeeld nummer 6, “T-SQL for Replay”, gerelateerd aan het opnieuw uitvoeren van een trace. Dit voorbeeld is nuttig voor het specificeren van de traceeruitvoer die tijdens het afspelen wordt gegenereerd. Om opgeslagen trace-uitvoer te openen voor afspelen, selecteert u Openen in het menu Bestand en selecteert u een bestand, tabel of SQL-script om de tijdens de trace verzamelde informatie op te slaan. U kunt het afspelen regelen met behulp van de opties die worden weergegeven in Tabel 1. Ze kunnen worden weergegeven door menu-items voor opnieuw afspelen of door knoppen op de werkbalk.

Uitgebreide opgeslagen procedures gebruiken

Sommige traceringsfuncties van SQL Profiler zijn niet beschikbaar. Deze omvatten het uitvoeren van een tracering volgens een schema, het uitvoeren wanneer een specifieke gebeurtenis plaatsvindt of wanneer SQL Server wordt gestart. Bovendien kan SQL Profiler niet worden geconfigureerd om traceringsresultaten naar het toepassingslogboek van Windows NT of Windows 2000 te verzenden. Om deze functies uit te voeren en meer vrijheid te bieden bij het programmatisch manipuleren van traceringen, kunt u een reeks uitgebreide opgeslagen procedures gebruiken die gezamenlijk xp_trace* worden genoemd.

Laten we eens kijken naar de principes van het gebruik van deze opgeslagen procedures aan de hand van het voorbeeld van het starten van een tracering sp_start_mytrace en de opgeslagen procedure van het stoppen van een tracering sp_stop_mytrace. De eerste opgeslagen procedure, sp_start_mytrace, definieert traceergebeurtenissen, gegevenskolommen en filters, en creëert een wachtrij om vastgelegde gebeurtenissen op te slaan. Vervolgens worden gebeurtenissen uit de wachtrij opgehaald en in een systeembestand geplaatst. De procedure sp_start_mytrace communiceert met de gebeurteniswachtrij en volgt de status ervan via de integer-wachtrijhandle die de procedure maakt wanneer de wachtrij wordt gebouwd. sp_stop_mytrace gebruikt deze handle wanneer de wachtrij moet worden gestopt.

Het bewaken van de status van een wachtrijhandle is geen gemakkelijke taak. Hoewel er veel methoden zijn om de waarde ervan te verkrijgen, is de eenvoudigste en meest functionele manier het maken van een tabel die gegevens vastlegt over alle traceringen en hun wachtrijen, evenals het tijdstip waarop de tracering begon, de gebruikers-ID van de gebruiker die de tracering heeft ingeschakeld trace en de naam van de computer waarvan het is gestart. Lijst 1 toont de instructies die zo'n tabel creëren, genaamd activetraces. Kijk naar deze tabel om te zien welke sporen momenteel worden vastgelegd. Om een ​​tracering te stoppen, vraagt ​​u eenvoudigweg in de tabel naar de corresponderende wachtrijdescriptor.

Opgeslagen procedure om een ​​tracering uit te voeren

Laten we deze twee opgeslagen procedures eens doornemen om te zien hoe de tracering wordt gestart en gestopt. De opgeslagen procedure waarmee de tracering begint, heeft vier optionele invoerparameters. Met de eerste twee, @spid_filter en @dbid_filter, kunt u de tijdens een tracering verzamelde informatie beperken tot alleen de informatie die betrekking heeft op een specifiek serverproces (geïdentificeerd door de SPID) en een bepaalde database. Als deze parameters niet zijn opgegeven, verzamelt de trace gegevens van alle processen en databases. Met de parameter @email_address kunt u een e-mailadres opgeven waarnaar gedetailleerde informatie over de voortgang van de tracering wordt verzonden. Als deze parameter niet is opgegeven, geeft sp_start_mytrace alleen informatie op het scherm weer. Als het is opgegeven, maar het adres is onjuist opgegeven, genereert de opgeslagen procedure een foutmelding en wordt deze afgesloten. De laatste parameter, @filename, is bedoeld om de naam op te geven van het bestand waarnaar de tijdens het traceren verzamelde informatie zal worden verzonden. In het geval dat deze parameter niet is gedefinieerd, wordt de standaardinformatie in het bestand c:\mytraceN.trc geplaatst, waarbij N het nummer van de wachtrijdescriptor is. Deze conventie, die een regel definieert voor het benoemen van traceringsgegevensbestanden, maakt het mogelijk dat meerdere traceringen tegelijkertijd worden gemaakt zonder dat een van hen het bestand kan vergrendelen om de resultaten voor zichzelf vast te leggen.

Wijzig de bestandseigenschappen om de triggerbewerking te testen:

ALTER DATABASE testdb BESTAND WIJZIGEN (NAAM = `testdb_dat`, MAXSIZE = 30MB)

U ontvangt een bericht waarin wordt aangegeven dat de bestandseigenschappen zijn gewijzigd:

Bestandseigenschappen gewijzigd:
Verklaring: ALTER DATABASE testdb MODIFY FILE (NAME = `testdb_dat`,
MAXGROOTTE = 30MB)
NT-gebruikersnaam: Gandalf
Applicatienaam: MS SQL Query Analyzer
SQL-gebruikersnaam: NA
Tijd: 22-11-2000 14:15:28

Het is altijd erg moeilijk om erachter te komen welke gebeurtenissen ertoe hebben geleid dat de impasse is ontstaan. SQL Profiler biedt echter speciale gebeurtenissen die “onderzoek” veel eenvoudiger kunnen maken. U kunt bijvoorbeeld het optreden van de gebeurtenis Lock:Deadlock traceren. Het optreden van deze gebeurtenis spreekt

dat er een impasse was ontstaan. Dit vertelt de gebruiker de serverproces-ID (SPID), de geblokkeerde transactie-ID, het tijdstip waarop de blokkering plaatsvond, de applicatienaam en de gebruikers-ID. De Lock: Deadlock Chain-gebeurtenis, die elke keer dat er een blokkering optreedt, wordt gegenereerd, is uiterst handig: u kunt er proces-identifiers (SPID's) en transacties mee achterhalen.

U kunt de ID's registreren van de transacties die betrokken zijn bij de impasse, vervolgens de traceerresultaten groeperen op transactie-ID's en alleen die transacties analyseren. Een andere benadering verzendt de traceringsresultaten naar een tabel. U kunt vervolgens query's gebruiken om deze te filteren op SPID-nummer of transactie-ID.

Om een ​​deadlock-situatie te genereren, maakt u twee tabellen, t1 en t2, die elk slechts één kolom met gehele getallen mogen hebben. Voer in elke tabel één rij in die de waarde 1 bevat. Definieer een tracering die de volgende reeks gebeurtenissen vastlegt: Lock:Deadlock, Lock: Deadlock Chain en de bijbehorende begin- en eindgebeurtenissen van de uitvoering van de operator (RPC, SP, SQL). De keuze moet worden gemaakt afhankelijk van de beoogde bron van blokkering. In ons voorbeeld hebben we alleen de SQL-gebeurtenissen nodig: StmtStarting en SQL:StmtCompleted.

Voeg naast de standaardgegevenskolommen een kolom toe om de transactie-ID en kolommen van uw keuze vast te leggen. Stel het traceringsfilter zo in dat het overeenkomt met de ID van de database waarmee u werkt. Open daarna twee verbindingen met de server vanuit Query Analyzer. Tijdens de eerste verbinding doet u het volgende:

BEGIN TRANSACTIE-UPDATE t1 SET col1 = 1

Op verbinding 2 start u de volgende transactie:

BEGIN TRANSACTIE
UPDATE t2 SET col1 = 1
SELECTEER * VANAF t1
TRANSACTIE VERBINTEN

Voer ten slotte in verbinding 1 de instructies uit:

SELECTEER * VANAF t2
TRANSACTIE VERBINTEN

Stop de tracering en open het traceringsbestand. Zoek naar Lock:Deadlock Chain-gebeurtenissen en noteer de betrokken transactienummers. Groepeer de uitvoer op transactie-ID's en vouw de bijbehorende transacties uit. De uitvoer ziet er ongeveer hetzelfde uit als in Scherm 1.

SQL Server Enterprise Manager bevat een wizard waarmee u traceringen kunt instellen, inclusief traceringen die worden gebruikt om de oorzaak van impasses te vinden. Om de wizard Trace maken te gebruiken om een ​​trace te definiëren, meldt u zich aan bij Enterprise Manager, selecteert u Wizards in het menu Extra, opent u vervolgens de categorie Beheer en selecteert u Wizard Trace maken.

Laatste opmerking

Dankzij de mogelijkheden voor tracering van SQL Profiler, in combinatie met de uitgebreide opgeslagen traceerprocedures van SQL Server 7.0, kunt u fouten in uw databases opsporen. Of u nu eenvoudigweg de gezondheid van uw SQL Server-omgeving bewaakt of prestatieproblemen van applicaties oplost, het is tijd om uw kennis in de praktijk te brengen.

Itzik Ben-Gan [e-mailadres beveiligd] beschikt over MCDBA-, MCSE+I-, MCSD-, MCT- en SQL Server MVP-certificeringen. Hij is hoofddocent voor SQL Server-cursussen aan het Hi-Tech College in Israël en voorzitter van de Israëlische SQL Server User Group.

In deze lezing zullen we de studie van opgeslagen procedures voortzetten die we zijn begonnen in ‘Opgeslagen procedures creëren en beheren’. U leert hoe u opgeslagen procedures en andere T-SQL-instructies analyseert met behulp van de Microsoft SQL Server Query Analyzer en de SQL Server Profiler. Op basis van deze analyse kunt u bepalen hoe effectief T-SQL-instructies zijn. Een efficiënte SQL Server-query gebruikt de juiste volgorde van bewerkingen en passende indexen om het aantal verwerkte rijen te verminderen en het aantal I/O-bewerkingen te minimaliseren.

Met Query Analyzer kunt u het geselecteerde uitvoeringsplan voor een T-SQL-instructie zien query-optimalisatie SQL-server Query-optimalisatie is een interne module die voor elke T-SQL-instructie zoekt naar het beste uitvoeringsplan. Query-optimalisatie analyseert elke T-SQL-instructie, bekijkt een aantal mogelijke uitvoeringsplannen en evalueert de "kosten" van elk plan in termen van vereiste middelen en verwerkingstijd. Het plan met de laagste kosten wordt geselecteerd. De kosten van elk plan worden bepaald op basis van de beschikbare statistieken, die door het systeem worden verzameld en mogelijk verouderd zijn. Omdat u wellicht meer over uw database en uw gegevens weet dan query-optimalisatie, dan kunt u mogelijk een plan maken dat beter is dan de queryoptimalisatie. Met behulp van de informatie die Query Analyzer produceert, kunt u bepalen of het plan van de query-optimalisatie voor een bepaalde instructie effectief zal zijn. Als dit niet het geval is, kunt u proberen die instructie te optimaliseren door deze aan te passen of SQL-hints te gebruiken. In deze lezing leert u hoe u T-SQL-instructies kunt optimaliseren en leert u ook Query Analyzer gebruiken.

Met Profiler kunt u bewerkingen binnen uw SQL Server-systeem analyseren om te bepalen welke SQL-instructies en opgeslagen procedures onnodige systeembronnen gebruiken. Met deze informatie kunt u uw afstemmingsinspanningen primair richten op deze verklaringen en opgeslagen procedures. Naast een beschrijving van het gebruik van Profiler, laat deze lezing ook zien hoe u de informatie die u met Profiler verkrijgt, zo effectief mogelijk kunt gebruiken.

Met behulp van SQL Query-analysator

Het hulpprogramma Query Analyzer wordt ter vervanging meegeleverd met Microsoft SQL Server 2000

In eerdere uitgaven (zie ComputerPress nr. 1, 3-5, 7, 9'2006) hebben we kwesties besproken die verband houden met de overgang naar SQL Server 2005 door migratie of upgrade, evenals de belangrijkste scenario's voor het gebruik van SQL Server 2005. Dit artikel bespreekt verschillende methoden voor het optimaliseren van zoekopdrachten en mogelijke benaderingen voor het oplossen van problemen die verband houden met het vinden van prestatieproblemen.

SQL Server levert services die draaien in een dynamische, voortdurend veranderende omgeving. Daarom kunt u door regelmatige monitoring van de werking van de server problemen identificeren in de fase waarin ze zich voordoen en onmiddellijk maatregelen nemen om ze te elimineren. Met de accumulatie van statistieken ontstaat inzicht in de belangrijkste trends in de werking van servers. Regelmatige verzameling van gegevens - zelfs in gevallen waarin de server zonder problemen draait - zal een zogenaamde serverprestatiebasislijn creëren, die als referentie kan dienen voor verdere metingen van de serverprestaties.

Zodra u een basislijnprestatiebenchmark hebt, kunt u de queryprestaties in verschillende scenario's analyseren. Het wordt aanbevolen om ten minste metingen uit te voeren vóór, tijdens en na het uitvoeren van verschillende optimalisatieprocedures, waardoor het succes van de ondernomen acties wordt gegarandeerd. Bovendien zullen regelmatige standaard prestatiemetingen (wekelijks, maandelijks, driemaandelijks, etc.) een duidelijker beeld geven van de serverprestaties.

De basisstandaard kan worden gebruikt om het tijdstip van de piekbelasting van de server en de downtime ervan (piek- en daluren), de responstijd van verzoeken en batches opdrachten, de uitvoeringstijd van procedures voor het maken van back-upkopieën en het herstellen van gegevens, enz. te bepalen. .

Queryprestaties

Queryprestaties moeten vanuit twee gezichtspunten worden bekeken: de bronnen die worden gebruikt om een ​​bepaalde query uit te voeren (bronnen omvatten objecten waartoe we toegang hebben tijdens het uitvoeren van query's, geblokkeerde objecten, enz.), en de tijd die wordt besteed aan het uitvoeren van de query duurt om een ​​verzoek te voltooien, hoe kleiner de kans dat we andere verzoeken en transacties tijdens het verzoekproces zullen blokkeren.

SQL Server 2005 bevat twee primaire tools voor het meten van de prestaties van query's: Performance Monitor en SQL Server Profiler. Om informatie te verkrijgen over de uitvoering van queries, kunt u bovendien T-SQL-taalconstructies gebruiken uit de groep SET STATISTICS - SET STATISTICS IO, SET STATISTICS PROFILE en SET STATISTICS TIME - en dynamische weergaven (Dynamic Management Views). Vervolgens gaan we dieper in op het gebruik van Prestatiemeter en SQL Server Profiler.

Prestatiemeter gebruiken

Het hulpprogramma Prestatiemeter wordt gebruikt om de prestaties van hardware- en softwarebronnen te analyseren, inclusief geheugen, netwerkgebruik, processortijd en informatie met betrekking tot de werking van SQL Server en andere softwareproducten - Microsoft Message Queuing (MSMQ), Microsoft .NET Framework en Microsoft Exchange-server. In het bijzonder kunt u Prestatiemeter gebruiken om SQL Server-bronnen, zoals vergrendelingen en transacties, te controleren.

Om de tellers waarin wij geïnteresseerd zijn toe te voegen, moet u de volgende stappen uitvoeren:

1. Op het menu Begin selecteer een elftal Loop en in het dialoogpaneel Loop binnenkomen perfmon. Hiermee wordt de Performance Microsoft Management Console (MMC) gestart, met een grafische weergave van een aantal prestatiemeteritems.
2. In het raam Systeemmonitor druk op de rechterknop op de kaart en selecteer de opdracht Tellers toevoegen.
3. In het dialoogpaneel Tellers toevoegen selecteer de computer waarin we geïnteresseerd zijn en het object dat we willen monitoren. Objecten die verband houden met SQL Server worden dienovereenkomstig voorafgegaan.
4. Om tellers te selecteren, moet u een van beide opties selecteren Alle tellers of een of meer tellers uit de vervolgkeuzelijst (Fig. 1).

1. Hierna moet u database-instances selecteren of de optie inschakelen Alle exemplaren.
2. Als u op de knoppen Toevoegen en Sluiten klikt, wordt het toevoegen van tellers voltooid.

Nadat de voor ons interessante tellers zijn toegevoegd, kunnen we hun waarden bekijken in de vorm van een grafiek of ze opslaan in een traceringsbestand (Fig. 2).

In het laatste geval moet je het element uitbreiden Prestatielogboeken en waarschuwingen en klik op de opdracht Nieuwe loginstellingen. In het dialoogpaneel Nieuwe loginstellingen U moet een protocolnaam opgeven en op OK klikken. Volgende in het dialoogvenster CounterLogNaam wij kiezen een team Tellers toevoegen. Het toevoegen van de tellers waarin wij geïnteresseerd zijn, gebeurt op dezelfde manier als hierboven beschreven. Houd er rekening mee dat een groot aantal tellers de systeemprestaties kan beïnvloeden. Wanneer u klaar bent met het toevoegen van tellers, klikt u op de knop Dichtbij.

Op het tabblad Algemeen in sectie Voorbeeldgegevens elke U kunt de bemonsteringsfrequentie (data-acquisitie) instellen. Het wordt aanbevolen om met een gemiddelde frequentie te beginnen, bijvoorbeeld eens per 5 minuten, en deze vervolgens, indien nodig, te verlagen of te verhogen. Houd er rekening mee dat hoe korter het bemonsteringsinterval, hoe meer systeem- en schijfbronnen vereist zijn. Er moet aan worden herinnerd dat intervallen die korter zijn dan de meterkwantiseringsperiode ook kunnen resulteren in onjuiste gegevensweergave. Op het tabblad Logbestanden u kunt de eigenschappen van het protocolbestand configureren, en Schema Er wordt een monitoringschema opgesteld. Als u op de knop OK klikt, wordt er een protocol aangemaakt voor het begin van de gegevensverzameling (Fig. 3).

Om het loggen handmatig te voltooien, klikt u met de rechterknop op het element Tellerlogboeken en selecteer een team Stop.

Om de verzamelde gegevens in het logbestand in Prestatiemeter te bekijken, moet u het element selecteren Systeemmonitor, in de taakbalk - opdracht Loggegevens bekijken en in het dialoogvenster Eigenschappen van systeemmonitor op het tabblad Bron geef de naam van het logbestand op.

De meest gebruikte prestatiemetertellers, die kunnen worden gebruikt om prestatieproblemen te helpen identificeren, zijn onderverdeeld in de volgende categorieën:

• gegevenstoegang - om de gegevenstoegangsmethoden te controleren die door SQL Server zelf worden gebruikt, wordt het object gebruikt SQLServer: Toegangsmethoden;
• statistieken - het object wordt gebruikt om de compilatie en hercompilatie van query's te controleren SQLServer:SQL-statistieken. Het biedt informatie over hoe snel en efficiënt SQL Server query's verwerkt;
• transacties - objectspecifieke tellers worden gebruikt om het aantal transacties per seconde te bepalen SQLServer: Databases En SQLServer: Transacties;
• vergrendelingen - het object wordt gebruikt om SQL Server-vergrendelingen te controleren die op bepaalde typen bronnen zijn geplaatst SQLServer: Vergrendelingen(Tabel 1).

Tabel 1. SQL Server Profiler-tellers

Tellernaam	Beschrijving
	Telt het aantal bereikscans voor indexen per seconde
	Telt het aantal volledige scans dat in de laatste seconde is voltooid
Indexzoekopdrachten/sec	Telt het aantal indexzoekopdrachten in de laatste seconde
Escalaties tafelvergrendeling/sec	Telt het aantal sloten op een tafel
Werktafels gemaakt/sec	Telt het aantal werkbladen dat in de afgelopen seconde is gemaakt
Batchverzoeken/sec	Telt het aantal Transact-SQL-opdrachtbatches per seconde. Een hoog aantal pakketten betekent een goede doorvoer
SQL-compilaties/sec	Telt het aantal querycompilaties per seconde. De waarde van deze teller moet vrijwel constant worden nadat de gebruiker basisacties heeft uitgevoerd
SQL-hercompilaties/sec	Telt het aantal hercompilaties van query's per seconde
SQLServer: Databaseobject. Transacties/sec-teller	Telt het aantal transacties dat in de afgelopen seconde in de database is gestart
SQLServer: Transacties-object. Teller van de langste looptijd van transacties	Berekent het aantal seconden sinds het begin van een transactie die langer actief is geweest dan welke andere huidige transactie dan ook. Als deze teller een zeer lange transactie aangeeft, gebruikt u de door het systeem opgeslagen procedure sys.dm_tran_active_transactions() om informatie over deze transactie te verkrijgen
SQLServer: Transacties-object. Update conflictratio-teller	Telt het percentage transacties dat gebruik maakt van snapshot-isolatie om conflicten met gegevensupdates op de laatste seconde op te lossen
Gemiddelde wachttijd (ms)	Berekent de gemiddelde wachttijd voor elk vergrendelingsverzoek dat een wachttijd veroorzaakt
Verzoeken vergrendelen/sec	Telt het aantal vergrendelingen en vergrendelingsconversies per seconde
Wachttijd vergrendelen (ms)	Berekent de totale wachttijd voor vergrendelingen in de laatste seconde
	Telt het aantal vergrendelingsverzoeken per seconde dat tot een wachttijd heeft geleid

Het tweede hulpprogramma dat u kunt gebruiken om de prestaties van query's te meten, is SQL Server Profiler. Vervolgens zullen we kijken naar de belangrijkste manieren om het te gebruiken.

Met behulp van SQL Server Profiler

Het hulpprogramma SQL Server Profiler wordt gebruikt om de prestaties te meten van individuele query's en query's die deel uitmaken van opgeslagen procedures en Transact-SQL-opdrachtbatches. Het kan worden gebruikt om prestatie-informatie te verzamelen, waaronder de tijd die is besteed aan het uitvoeren van een individueel commando, de blokkeertijd voor het uitvoeren van een commando en het uitvoeringsplan.

Om een ​​nieuw profiel aan te maken, moet u de volgende stappen uitvoeren:

1. Start SQL Server Profiler ( Microsoft SQL Server 2005 => Prestatiehulpmiddelen => SQL Server Profiler).
2. Op het menu Bestand selecteer een elftal Nieuw spoor.
3. In het dialoogpaneel Maak verbinding met de server selecteer de gewenste server en klik op de knop Verbinden.
4. In het dialoogpaneel Eigenschappen traceren u moet een profielnaam instellen (Tracenaam) en in de lijst Gebruik de sjabloon selecteer een van de beschikbare sjablonen of Leeg, als de sjabloon niet wordt gebruikt.
5. Om profileringsresultaten op te slaan, moet u de optie selecteren Opslaan in bestand om gegevens naar een bestand te schrijven en de maximale bestandsgrootte op te geven (standaardwaarde is 5 MB), optioneel kunt u de optie inschakelen Schakel bestandsrollover in om automatisch een nieuw bestand te maken wanneer de opgegeven profielgrootte is bereikt. De tweede optie is om de gegevens op te slaan in een databasetabel (Opslaan in tabel)- optie Stel maximale rijen in Hiermee kunt u het maximale aantal records instellen.
6. Om de eindtijd voor tracering in te stellen, kunt u de optie gebruiken Schakel de traceerstoptijd in(Afb. 4).

Om gebeurtenissen en gegevenskolommen voor een profiel in te stellen, moet u de volgende stappen uitvoeren:

1. In het dialoogpaneel Eigenschappen traceren ga naar tabblad Evenementen selectie.
2. Gebeurtenissen toevoegen aan of verwijderen uit een profiel met behulp van de gebeurtenisklassentabel.
3. Schakel de optie in om een ​​lijst met alle beschikbare evenementen te krijgen Toon alle evenementen(Afb. 5).

In tabel Tabel 2 bevat de meest gebruikte SQL Server Profiler-gebeurtenissen. Net als prestatiemeteritems vallen SQL Server Profiler-gebeurtenissen in een aantal categorieën, waarvan sommige van belang zijn voor onze doeleinden.

Tabel 2. SQL Server Profiler-gebeurtenissen

Naam evenement	Beschrijving
	Deze gebeurtenis vindt plaats wanneer de uitvoering van de externe procedureaanroep is voltooid.
	Deze gebeurtenis wordt geactiveerd wanneer de opgeslagen procedure de uitvoering voltooit.
SP:StmtVoltooid	Deze gebeurtenis vindt plaats na voltooiing van de uitvoering van een van de Transact-SQL-opdrachten in een opgeslagen procedure
SQL:Stmtvoltooid	Deze gebeurtenis vindt plaats na voltooiing van een Transact-SQL-opdracht.
SQL: Batch voltooid	Deze gebeurtenis vindt plaats na voltooiing van een batch Transact-SQL-opdrachten.
	Deze gebeurtenis wordt geactiveerd wanneer een transactie een vergrendeling op een bron verkrijgt.
	Deze gebeurtenis vindt plaats wanneer een transactie een eerder vergrendelde bron vrijgeeft.
	Deze gebeurtenis vindt plaats wanneer de time-out voor het verkrijgen van een vergrendeling wordt overschreden, omdat de vereiste bron al is vergrendeld door een andere transactie

Hoe de aanwezigheid van blokkades te bepalen

Elke keer dat een transactie een bron gebruikt (tabel, pagina, index, enz.), wordt er een slot aan toegewezen. Als een andere transactie probeert toegang te krijgen tot deze bron en het vergrendelingstype niet compatibel is met de vergrendeling die al in bezit is, wordt een nieuwe vergrendeling verkregen.

Om de aanwezigheid van blokkering te bepalen, kunt u de volgende methoden gebruiken:

• gebruik het hulpprogramma SQL Server Management Studio Activity Monitor, dat informatie weergeeft over processen, vergrendelingen op procesniveau en objectniveau. Om toegang te krijgen tot Activity Monitor in SQL Server Management Studio moet u het item selecteren Beheer, en daarin - Activiteitenmonitor en dubbelklik op dit element. Met Activity Monitor kunt u het volgende bekijken:

Vergrendelde objecten per proces: gebruik de proces-ID om het verzoek te bepalen dat de vergrendeling heeft veroorzaakt Serverproces-ID (SPID) op de pagina Procesinformatie,

Processen die ervoor zorgen dat andere processen wachten: gebruik de kolom om dergelijke processen te identificeren Geblokkeerd door op de pagina Procesinformatie(Fig. 6);

• gebruik SQL Server Profiler om een ​​rapport over geblokkeerde processen te krijgen - deze lijst geeft informatie weer over processen die langer dan een opgegeven tijd geblokkeerd zijn gebleven O

In ons werk komen we nogal eens een situatie tegen waarin een bepaald verzoek traag is en er geen duidelijke problemen zichtbaar zijn uit de tekst van het verzoek. Meestal is het in dit geval nodig om het probleem op een dieper niveau te onderzoeken. In de regel is het nodig om naar de tekst van een SQL-query en het bijbehorende plan te kijken, en dit is waar SQLProfiler ons helpt.

Wat is SQL Profiler en waarom is het nodig?

SQLProfiler is een programma dat bij MS SQL Server wordt geleverd en is ontworpen om alle gebeurtenissen die plaatsvinden op de SQL-server te bekijken of, met andere woorden, een trace vast te leggen. Waarom heeft een 1C-programmeur SQLProfiler nodig? Tenminste om de tekst van een query in SQL te krijgen en het plan ervan te zien. Dit kan natuurlijk met behulp van een technologiemagazine, maar dit vereist enige vaardigheden en het plan in het technische tijdschrift is niet zo mooi en leesbaar. In de profiler kun je niet alleen een tekstueel, maar ook een grafisch query-uitvoeringsplan bekijken, wat naar mijn mening veel handiger is. U kunt de profiler ook gebruiken om het volgende te bepalen: verzoeken langer dan een bepaalde tijd, verzoeken aan een specifieke tafel die wacht op vergrendelingen, deadlock-time-outs en nog veel meer...

Query's analyseren met SQL Profiler

De profiler wordt meestal gebruikt om zoekopdrachten te analyseren. In de regel hoeven we niet alle zoekopdrachten bij te houden; vaak moeten we zien hoe een bepaalde zoekopdracht in de 1C-taal in SQL wordt vertaald en het uitvoeringsplan ervan zien. We hebben dit bijvoorbeeld nodig om te bepalen waarom een ​​query langzaam wordt uitgevoerd, of we hebben mogelijk een grote query geschreven en willen er zeker van zijn dat de hoofdtekst van de SQL-query geen joins met een subquery bevat. Om de aanvraag in de tracering op te vangen, doet u het volgende:

1. Start SQL Profiler Start - Alle programma's - Microsoft SQL Server 2008 R2 - Productiviteitstools - SQLProfiler
2. Maak een nieuw traceerbestand - Traceer maken (Ctrl+N)
3. Geef de DBMS-server op waarop onze database zich bevindt en klik op “Verbinden”.

Uiteraard houdt niets u tegen om een ​​DBMS-server te traceren die zich op een andere computer bevindt. 4. Ga in het venster “Trace Properties” dat verschijnt naar het tweede tabblad “Select Events”

5. Nu moeten we de gebeurtenissen en eigenschappen van deze gebeurtenissen specificeren die we in de trace willen zien. We hebben query's en queryplannen nodig, dus we moeten de juiste gebeurtenissen inschakelen. Om een ​​volledige lijst met eigenschappen en gebeurtenissen weer te geven, schakelt u de vlaggen ‘Toon alle kolommen’ en ‘Toon alle gebeurtenissen’ in. Vervolgens hoeft u alleen de gebeurtenissen te selecteren die in de onderstaande afbeelding worden weergegeven; alle andere gebeurtenissen moeten worden uitgeschakeld.

Beschrijving van gebeurtenissen: ShowplanStatisticsProfile - uitvoeringsplan voor tekstquery's.
ShowplanXMLStatisticsProfile - grafisch query-uitvoeringsplan.
RPC:Completed - verzoektekst als deze als procedure wordt uitgevoerd (als een 1C-verzoek met parameters wordt uitgevoerd).
SQL:BatchCompleted - querytekst als deze wordt uitgevoerd als een gewone query (als een 1C-query is uitgevoerd zonder parameters).

6. Nu moet je een filter voor evenementen instellen. Als dit niet gebeurt, zien we query's voor alle databases die zich op deze DBMS-server bevinden. Klik op de knop “Kolomfilters” en specificeer een filter op databasenaam

Nu zullen we in de tracering alleen verzoeken zien naar de database “TestBase_8_2”. Indien gewenst kunt u een filter instellen op andere velden, de meest interessante daarvan zijn: Duration (Duration), TextData (meestal de tekst van het verzoek) en RowCounts (het aantal rijen dat door de aanvraag wordt geretourneerd).

Als ik bijvoorbeeld alle verzoeken aan de tabel “_InfoRg4312” die langer dan 3 seconden duren in de database “TestBase_8_2” moet opvangen, doe ik het volgende:
a) Filter op database, voorbeeld hierboven
b) Filter op duur in milliseconden.

C) Filter op verzoektekst


Hier specificeren we het masker. Als u zoekopdrachten wilt bijhouden die toegang hebben tot meerdere tabellen, maakt u verschillende elementen aan in het gedeelte 'Vergelijkbaar met'. Alle filteromstandigheden werken samen.

7. Nu kunt u de tracering uitvoeren. Klik op “Uitvoeren”, waarna de tracering begint te werken en u de gebeurtenissen kunt zien die u hebt geconfigureerd om weer te geven en die onder uw filters vallen. U kunt de knoppen op de opdrachtbalk gebruiken om de tracering te beheren.

Van links naar rechts: Gum - maakt het traceringsvenster leeg, Start - start het traceren, Pauze - pauzeert het traceren, klikken op Start hervat het traceren, Stop - stopt het traceren

8. Het traceervenster zelf bestaat uit twee delen. Bovenaan staan ​​evenementen en evenementeigenschappen. In het onderste gedeelte wordt verschillende informatie weergegeven, afhankelijk van het type gebeurtenis. In ons geval wordt hier de tekst van de aanvraag of het plan weergegeven.

9. Laten we het verzoek uitvoeren in de 1C-queryconsole en kijken hoe dit wordt weerspiegeld in de profiler.

Uit de tracering blijkt dat er meerdere verzoeken waren en dat slechts één daarvan de onze was. Overige verzoeken zijn serviceverzoeken.

10. Uit de eigenschappen van de gebeurtenissen kunt u begrijpen: hoeveel seconden de query is uitgevoerd (Duration), hoeveel logische metingen er waren (Reads), hoeveel rijen de query als resultaat heeft geretourneerd (RowCounts), enz. In mijn geval liep de query 2 milliseconden, voerde 4 logische lezingen uit en retourneerde 1 rij.

11. Als we één gebeurtenis omhoog gaan, kunnen we het queryplan in grafische vorm zien.
Zoals uit het plan blijkt, wordt er gezocht op index op prijs, hoewel dit plan niet ideaal kan worden genoemd, omdat de index dekt niet, de code- en naamvelden worden verkregen met behulp van KeyLookup, wat 50% van de tijd in beslag neemt.


Met behulp van het contextmenu kan het grafische plan worden opgeslagen als een afzonderlijk bestand met de extensie *.SQLPlan en worden geopend in een profiler op een andere computer of met behulp van het meer geavanceerde SQL Sentry Plan Explorer-programma.

12. Als we nog hoger gaan, zien we hetzelfde queryplan, maar dan in tekstvorm. Het is dit plan dat wordt weergegeven in TZ, TsUP en andere 1C-tools voor prestatiemonitoring. Om het te analyseren, raad ik aan een geavanceerde teksteditor met achtergrondverlichting te gebruiken, zoals Notepad++.

13. Ik gebruik het menu “Bestand-Opslaan als”, de volledige trace kan in verschillende formaten worden opgeslagen:
a) In het formaat van de profiler zelf, d.w.z. met extensie *.trc
b) In XML-formaat
c) U kunt van de trace een sjabloon maken. Zie volgend punt.
d) U kunt de tracering opslaan als een databasetabel. Een handige manier als we bijvoorbeeld het langzaamste verzoek in de gehele tracering moeten vinden of verzoeken op basis van een bepaalde parameter moeten selecteren. Bestand - Opslaan als - Traceertabel - Selecteer de DBMS-server en maak er verbinding mee. Vervolgens moet u een database op de opgegeven server selecteren en de naam opgeven van de tabel waarin de tracering zal worden opgeslagen. U kunt een bestaande tabel selecteren of een nieuwe naam schrijven, waarna de tabel automatisch in de geselecteerde database wordt aangemaakt.

Houd er rekening mee dat de duur in de tabel wordt opgeslagen in miljoensten van een seconde en dat het bij het weergeven van het resultaat raadzaam is om de waarde om te zetten in milliseconden. De kolom RowNumber wordt ook aan de tabel toegevoegd, waarin het nummer van deze rij in de tracering wordt weergegeven.

14. Als je de profiler vaak moet gebruiken om verzoeken te analyseren, wordt het instellen van de benodigde filters en evenementen snel saai en kost het ook veel tijd. Traceersjablonen komen te hulp, waarbij we de filters specificeren die we nodig hebben en de volgorde van de kolommen, en vervolgens eenvoudigweg dit sjabloon selecteren bij het maken van een nieuwe tracering. Om een ​​sjabloon aan te maken, gebruikt u het menu Bestand - Sjablonen - Nieuw sjabloon

Op het eerste tabblad is alles eenvoudig. We geven het servertype en de naam van de sjabloon aan en stellen, indien nodig, de vlag in om deze sjabloon standaard te gebruiken. Op het tweede tabblad selecteren we gebeurtenissen en configureren we filters, zoals hierboven al weergegeven. Ik raad ook aan om de volgorde van de kolommen in de trace aan te passen; dit bespaart tijd bij het analyseren van zoekopdrachten. Ik vind het bijvoorbeeld handiger om de volgende volgorde te hanteren.

Nu kunt u bij het aanmaken van een nieuwe trace eenvoudig het benodigde sjabloon opgeven, waarna alle filters en gebeurtenissen automatisch worden ingevuld op het tweede tabblad.

Natuurlijk worden hier niet alle manieren getoond om deze prachtige tool te gebruiken; er is interesse van het publiek, en in de toekomst zal het mogelijk zijn om de verzameling artikelen over dit onderwerp uit te breiden.