Delen via


Problemen met het verschil in queryprestaties tussen een databasetoepassing en SSMS oplossen

Wanneer u een query uitvoert in een databasetoepassing, wordt deze langzamer uitgevoerd dan dezelfde query in een toepassing zoals SQL Server Management Studio (SSMS), Azure Data Studio of SQLCMD.

Dit probleem kan een of meer van de volgende oorzaken hebben:

  • Query's gebruiken verschillende parameters of variabelen.

  • Query's worden via verschillende netwerken naar de server verzonden of er is een verschil in hoe de toepassingen gegevens verwerken.

  • SET-opties in de databasetoepassing en SSMS verschillen.

Volg deze stappen voor het oplossen van het probleem:

Stap 1: Controleer of de query's worden verzonden met dezelfde parameters of variabelen

Volg deze stappen om deze query's te vergelijken en ervoor te zorgen dat ze op elke manier identiek zijn:

  1. Open uw SSMS en verbind deze met de database-engine die u gebruikt.

  2. Voer de volgende opdrachten uit om een sessie met uitgebreide gebeurtenissen te maken:

    CREATE EVENT SESSION <EventSessionName> ON SERVER
    ADD EVENT sqlserver.existing_connection(SET collect_options_text=(1)),
    ADD EVENT sqlserver.login(SET collect_options_text=(1)
        ACTION(sqlserver.client_app_name)),
    ADD EVENT sqlserver.rpc_completed,
    ADD EVENT sqlserver.sp_statement_completed(
        ACTION(sqlserver.client_app_name)),
    ADD EVENT sqlserver.sql_batch_completed(
        ACTION(sqlserver.client_app_name)),
    ADD EVENT sqlserver.sql_statement_completed(
        ACTION(sqlserver.client_app_name))
    ADD TARGET package0.event_file(SET filename=N'<FilePath>')
    WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 
    SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
    GO
    

    Notitie

    Vervang de tijdelijke aanduidingen <EventSessionName> en <FilePath> door de aanduidingen die u wilt maken.

  3. Voer de volgende opdrachten uit om de sessie EventSessionName te starten:

    ALTER EVENT SESSION <EventSessionName> ON SERVER
    STATE = START
    
  4. Voer uw query's uit om het probleem te reproduceren.

  5. Gebruik een van de volgende methoden om de verzamelde gegevens te analyseren:

    • Open Windows Verkenner, zoek het .xel-doelbestand en dubbelklik erop. Het bestand wordt geopend in een ander SSMS-venster dat u kunt gebruiken om het weer te geven en te analyseren.

    • Vouw in Objectverkenner Het uitgebreide beheergebeurtenissessies>>>EventSessionName uit, klik met de rechtermuisknop op package0.event_file en selecteer Doelgegevens weergeven....

    • Zoek de locatie van de .xel-bestanden en lees dit bestand met behulp van de functie sys.fn_xe_file_target_read_file.

  6. Vergelijk de veldinstructie door de volgende gebeurtenissen te controleren:

    • sp_statement_completed
    • sql_batch_completed
    • sql_statement_completed
    • rpc_completed

Zie de volgende voorbeelden voor meer informatie over de identieke query's:

  • Als de opgeslagen procedures of functies verschillende parameterwaarden hebben, kunnen de querytijden verschillen:

    • SpUserProc @p1 = 100

    • SpUserProc @p1 = 270

  • De volgende query's zijn verschillend. De eerste query maakt gebruik van gemiddelde dichtheid uit het histogram voor kardinaliteitschatting, terwijl de tweede query de histogramstap gebruikt voor de schatting van kardinaliteit:

    • declare @variable1 = 123
      select * from table where c1 = @variable1
      
    • select * from table where c1 = 123
      

Om dezelfde reden als hierboven kan het vergelijken van de uitvoering van een opgeslagen procedure met de uitvoering van de equivalente ad-hocquery (met behulp van lokale variabelen) verschillen. Identieke instructies moeten worden vergeleken.

Stap 2: De uitvoeringstijd op de server meten

Voor een nauwkeurige vergelijking van queryduur kunt u de tijd voor netwerklatentie of toepassingsspecifieke verwerkingstijd uitsluiten. Gebruik een van de volgende methoden om alleen de uitvoeringstijd op de SQL Server te meten:

  • Voer uw query uit met BEHULP van SET STATISTICS TIME:

    SET STATISTICS TIME ON
    <YourQuery>
    SET STATISTICS TIME OFF
    
  • Gebruik XEvent uit stap 1 om de duur of verstreken tijd van een query (gebeurtenisklasse SQL:StmtCompleted, SQL:BatchCompletedof RPC:Completed) te onderzoeken.

In sommige gevallen kan het tijdsverschil tussen de query's worden veroorzaakt door één toepassing die wordt uitgevoerd in een ander netwerk of de toepassing zelf. Wanneer u de uitvoering op de server vergelijkt, vergelijkt u hoe lang de query's op de server hebben geduurd.

Stap 3: Set-opties voor elke verbinding controleren

Er zijn SET-opties die van invloed zijn op het queryplan, wat betekent dat ze de keuze van het queryplan kunnen wijzigen. Als een databasetoepassing daarom verschillende setopties van SSMS gebruikt, kan elke setoptie een ander queryplan krijgen. Bijvoorbeeld ARITHABORT, NUMERIC_ROUNDABORT, ROWCOUNT, FORCEPLAN en ANSI_NULLS. Het meest voorkomende verschil tussen SSMS- en .NET-toepassingen is de optie SET ARITHABORT . Standaard is de optie ingesteld op AAN in SSMS, maar ingesteld op UIT in de meeste databasetoepassingen. Stel ARITHABORT op basis van uw toepassingsbehoeften in op dezelfde instelling in zowel SSMS als toepassing voor een geldige vergelijking tussen de twee.

Waarschuwing

De standaardinstelling ARITHABORT voor SQL Server Management Studio is ON. Clienttoepassingen die ARITHABORT op OFF instellen, ontvangen mogelijk verschillende queryplannen, waardoor het moeilijk is om problemen met slecht presterende query's op te lossen. Dat wil gezegd, dezelfde query kan snel worden uitgevoerd in Management Studio, maar traag in de toepassing. Bij het oplossen van problemen met Management Studio moet u altijd overeenkomen met de ARITHABORT-instelling van de client.

Zie Opties instellen voor een lijst met alle opties die van invloed zijn op het plan.

Voer de volgende stappen uit om ervoor te zorgen dat de SET-opties in zowel SSMS als de toepassing hetzelfde zijn om een geldige vergelijking uit te voeren:

  1. Gebruik de verzamelde gegevens in stap 1.

  2. Vergelijk de ingestelde opties door de gebeurtenissen login te controleren, existing_connectionmet name de options_text kolommen en opties.