sql >> Database >  >> RDS >> Oracle

Hoe het prestatieprobleem in een relationele database te beschrijven?

Voor Oracle Database geef deze informatie:

Beschrijf de symptomen van het probleem

Beschrijf het gedrag dat het probleem veroorzaakt. Is het gedrag van de query stabiel of komt het probleem slechts af en toe voor, met specifieke parameters of gewoon willekeurig. Kun je dit gedrag reproduceren in een IDE (bijvoorbeeld SQL Developer)?

Beschrijf de omgeving

Definieer de exacte versie van Oracle

 select * from v$version

Beschrijf hoe u verbinding maakt met de database:driver, ORM, programmeertaal. Geef namen en/of versienummers op.

Beschrijf de zoekopdracht

Plaats de vraagtekst. Probeer het te vereenvoudigen - toon een minimaal reproduceerbaar voorbeeld .

Voorbeeld - uw problematische query voegt 10 tabellen samen. Controleer of je dezelfde symptomen ziet in een zoekopdracht met 9 of 8 joins. Ga naar beneden totdat je de problemen ziet en toon alleen de verminderde zoekopdracht.

Ja, dit is duur, maar het vergroot de kans dat je ondersteuning krijgt enorm! Hoe kleiner de zoekopdracht, hoe meer supporters deze aantrekt.

Beschrijf het uitvoeringsplan

Voer deze instructie uit om het uitvoeringsplan te krijgen (vervang uw vraagtekst)

 EXPLAIN PLAN  SET STATEMENT_ID = '<some_id>' into   plan_table  FOR
     select * from ....   -- your query here 
 ;

Het uitvoeringsplan wordt opgeslagen in de PLAN_TABLE , voer deze zoekopdracht uit om het te zien

 SELECT * FROM table(DBMS_XPLAN.DISPLAY('plan_table', '<some_id>','ALL')); 

Toon het volledige resultaat (niet alleen de tabel met het uitvoeringsplan). Extreem belangrijk kan het predikaatgedeelte en de onderstaande toelichting zijn.

Voorbeeld voor select * from dual where dummy = :1;

Plan hash value: 272002086

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |     2 |     2   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |
--------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

   1 - SEL$1 / [email protected]$1

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("DUMMY"=:1)

Column Projection Information (identified by operation id):
-----------------------------------------------------------

   1 - "DUMMY"[VARCHAR2,1]

Knip en plak het grafische resultaat niet van uw IDE-uitlegplan.

Is dit uitvoeringsplan het echte plan dat wordt uitgevoerd?

Helaas niet altijd. Er zijn verschillende redenen waarom de uitgelegde uitvoeringsplan kan afwijken van het echte.

Als je twijfelt (vooral als je een goed plan ziet, maar de query loopt slecht), kun je het plan uit de DB-cache halen met een SQL_ID .

 SELECT t.* FROM  table(DBMS_XPLAN.DISPLAY_CURSOR('<SQL_ID>',null,'ALL')) t; 

De SQL_ID voor een query die momenteel wordt uitgevoerd (of die binnenkort wordt uitgevoerd en nog steeds in de cache is) kan worden gevonden met tekstovereenkomst en/of de databasegebruiker:

select sql_id, sql_fulltext from v$sql a where 
 lower(sql_text) like lower('%<some identifying part of the query text>%') 
  and parsing_schema_name = '<user running the query>';

Als je een AWR-licentie hebt, kun je daar het uitvoeringsplan vandaan halen, zelfs voor zoekopdrachten die in de geschiedenis worden uitgevoerd.

SELECT t.*
FROM  table(DBMS_XPLAN.DISPLAY_AWR('10u2rj016s96k'  )) t;

De SQL_ID kan worden gevonden met

select sql_id, sql_text 
from dba_hist_sqltext a 
where lower(sql_text) like lower('%<some identifying part of the query text>%')

Beschrijf de gegevens

Toon de DDL van de tabellen en indexen op die tabellen.

Vermeld of de optimalisatiestatistieken recentelijk zijn verzameld en toon de gebruikte dbms_stats verklaring verzamelen.

Geef voor de kritische tabel(len) informatie over segmentgrootte, rijnummer, partitionering,...

Voor de kolommen die worden gebruikt in access of joins, geeft u informatie over het aantal verschillende waarden. Zijn de waarden gelijkmatig verdeeld of scheef (bijv. een klein aantal waarden dat heel vaak voorkomt en een groot aantal zeldzame waarden). Definieert u histogrammen?

Iets anders?

Dit is natuurlijk alleen de basis en er kan nog steeds andere informatie nodig zijn, zoals systeemstatistieken of optimalisatieparameters. Maar probeer opnieuw de minimale informatie te verstrekken die (jou ding) het probleem kan identificeren. Post op verzoek aanvullende informatie.

Veel geluk!




  1. Heeft Mysql een equivalent van @@ROWCOUNT zoals in mssql?

  2. Hoe de functie TRANSLATE() werkt in SQL Server (T-SQL)

  3. Vastgelopen zoekopdracht beëindigen (inactief in transactie)

  4. Postgresql DROP TABLE werkt niet