Inleiding tot Sql Tuning
- Sql-instructies zijn geschreven om gegevens uit de database op te halen/op te halen. We willen dat onze sql-instructie snel werkt (sql-afstemming) en de resultaten in seconden levert.
- Een slecht ontworpen sql kan de hele databasebewerking vertragen en de hele bewerking stopzetten. Het is veel moeilijker om efficiënte SQL te schrijven dan om functioneel correcte SQL te schrijven. sql prestatieafstemming kan de gezondheid en prestaties van een systeem aanzienlijk verbeteren.
- De sleutel tot het afstemmen van SQL is het minimaliseren van de gegevens waartoe het toegang heeft om het resultaat te leveren. We kunnen de toegang tot gegevens minimaliseren om het resultaat te leveren via een optimaal zoekpad.
Een eenvoudig voorbeeld zou zijn
select * from dept where emp=10
- Nu moet deze query de hele tabelafdeling doorzoeken om de gegevens te vinden waarbij emp=10. Het moet dus toegang hebben tot de volledige tabel
- Als we nu de kolom index naar emp maken, kan deze gewoon toegang krijgen tot de index en het resultaat krijgen. Dus hier heb je toegang tot de minder gegevens
12 stappen om Sql-afstemming uit te voeren in Oracle
Hier de algemene tips voor het afstemmen van sql-prestaties
(1) Eerst moet je alle benodigde tools hebben voor het afstemmen van sql. Je moet goede informatie hebben over traceren, het formatteren van de trace, het uitleggen van het plan, het lezen van het uitlegplan in Oracle.
Goede kennis van de verschillende join-methoden die beschikbaar zijn in Oracle en hoe u ze efficiënt kunt gebruiken
(2) Lees minder gegevens en wees I/O-efficiënt.
Hoe meer gegevens u leest voor de sql-instructie, hoe meer vergrendelingen het moet verwerven en het vertraagt de prestaties. dus het moet altijd minder logische reads doen
Schrijf een verstandige sql-instructie waar de juiste filters . Controleer het aantal rijen in de verschillende betrokken tabellen en ontdek de beste methode om het sql-statement te maken
(2) Gebruik goede Oracle-indexen
B-Tree-indexen en Bitmap-indexen kunnen worden gebruikt om de prestaties van de query's te verbeteren als de geretourneerde gegevens minder dan 10% zijn. Maar we moeten voorzichtig zijn bij het maken van de index, omdat deze ook moet worden onderhouden voor het invoegen, bijwerken en verwijderen. Dus het creëren van een index creëert overhead over veel dingen. We moeten dus het effect van het maken van de index zorgvuldig onderzoeken.
(3) Vermijd sql die het gebruik van index uitschakelen
SQL die indexen uitschakelt
(a)Functies ( to_char(), to_date(), etc. )
Fix:verplaats de functie naar de "constante/bind variabele" kant
(b) Type Casting
In SQL
waar emp_no =10 (emp_no is een varchar2)
In PL/SQL
waar emp_no =v_emp_num (v_emp_num is een getal)
Modifiers
en id + 0 =111
en datum + 1 =sysdate (probeer datum =sysdate – 1)
Fix:verander het om het te vermijden
(4) Gebruik altijd de bindvariabele in de toepassing. Als u de bindvariabele in oracle niet gebruikt, wordt de sql elke keer geparseerd en heeft dit invloed op de databaseprestaties. Als het de bindvariabele bevat, wordt sql in de cache opgeslagen en is voor verdere uitvoering geen parsing vereist, waardoor de algehele prestaties van het systeem worden verbeterd
(5) UNIE versus OR. Gebruik UNION voor queries met twee duidelijke uitvoeringspaden; die elk een vrij klein aantal rijen retourneren. Gebruik unie niet voor zoekopdrachten die waarschijnlijk een groot aantal rijen zullen retourneren, aangezien alle rijen moeten worden gesorteerd en de meeste worden weggegooid. OF heeft de neiging om de index uit te schakelen
(6) Gebruik de nauwkeurige optimalisatiestatistieken op de tafel om het optimale plan te krijgen.
(7) Als u functie op uitdrukking voor de voorwaarde gebruikt, controleer dan of er een op functie gebaseerde index in die kolom is. Als deze niet aanwezig is, wordt de index niet gebruikt
(8) Gebruik bestaat vs in en Niet bestaat vs niet in voor gecorreleerde subquery's
(9) Vermijd slechte codeerpraktijken
Enkele tips
(a) Vermijd Cartesiaanse join . Zorg ervoor dat alle tabellen die vereist zijn in de query's nodig zijn en aan elkaar zijn gekoppeld
(b) Gebruik Decode om meerdere reizen naar de database te voorkomen
(c) Probeer outer join te vermijden
(d ) Soms maakt het ontleden van de logica in kleine delen het werk sneller
(10) Als u de complexe weergave probeert te gebruiken, controleer dan of de basistabellen in plaats daarvan kunnen worden gebruikt, omdat de weergave de prestaties slecht maakt
(11) Gebruik UNION ALL Vs UNION als u weet dat de opgehaalde gegevens geen dubbele rijen bevatten
( 12) Gebruik hints om het uitvoeringsplan te optimaliseren. Soms kan een hint worden gebruikt om het uitvoeringsplan voor de query te wijzigen om het meest optimale pad te nemen.
Soms kan bind peeking een slecht plan maken, dus in dat geval zet u de nodige hint om het plan te repareren, hulp bij het verkrijgen van de goede prestaties elke keer
De meest voorkomende hints zijn
/*+ LEADING (tabel alias) */ specificeert de tabel waarmee de join moet worden gestart
/*+ FIRST_ROWS */ zeer goed voor online schermen – gunsten NESTED LOOPS
/*+ INDEX ( tabel alias.index naam) */ specificeert de index die u wilt gebruiken. Opmerking:als de index wordt verwijderd en opnieuw wordt gemaakt en de naam verandert, is de hint niet langer geldig.
/*+ USE_NL (tabel alias1 tabel alias 2)*/ vraagt de optimizer om de Nested Loop Join te gebruiken voor de twee gespecificeerde tabellen
Vermijd onnodige optimalisatietips en gebruik ze met zorg
Dit zijn enkele van de tips om problemen te voorkomen en de sql-afstemming uit te voeren. Sql-tuning is een grote oceaan en je kunt dingen leren door alleen te oefenen. Veel succes!!
Leest ook
https://docs.oracle.com/cd/B19306_01/server.102/b14211/sql_1016.htm