 |
Oracle Tips från Burleson Consulting |
inom dessa två optimerare tillhandahåller Oracle flera optimeringslägen. Ett optimeringsläge kan ställas in för hela databasen, eller det kan ställas in för en specifik Oracle-session. Optimeringslägena inkluderar rule, first_rows, all_rows och choose. Låt oss titta närmare på vart och ett av dessa mål.
Regelläge
regeltipset ignorerar CBO och statistiken och genererar en exekveringsplan baserad enbart på grundläggande dataordboksinformation. Det är alltid bra att försöka ställa in ett specifikt SQL-uttryck genom att använda RBO med hjälp av en regeltips eller genom att utfärda Alter session set optimizer_goal=rule. Kom dock alltid ihåg att RBO kan välja ett mindre än idealiskt index för att betjäna en fråga.
Optimizer_mode=välj
välj optimeringsläge gör att Oracle kan välja det mest lämpliga optimeringsmålet. Detta är standardoptimeringsläget i Oracle, och det använder i allmänhet närvaron av statistik för att bestämma vilken optimerare som ska åberopas. Om det inte finns någon statistik kommer Oracle att använda regelmålet. Om det finns statistik väljer Oracle first_rows eller all_rows, beroende på förekomsten av index och inställningen för parallelism och db_file_multiblock_read_count.
varning: att ha ofullständig statistik med choose optimizer-läget kan orsaka enorma avmattningar. Om Oracle upptäcker en enda tabell i en fråga med statistik kommer den att använda den kostnadsbaserade optimeraren och beräkna statistik för de andra tabellerna vid körning. Detta kan orsaka enorm avmattning av SQL-körning. Detta problem är mycket vanligt med Oracle Remote DBA nybörjare eftersom standardläget är Välj, och eftersom nybörjare fjärr DBA ibland selektivt utfärda kommandot analysera, utan att inse att de påverkar SQL exekveringstider.
first_rows mode
detta är ett kostnadsbaserat optimeringsläge som returnerar rader så snart som möjligt, även om den övergripande frågan körs längre eller förbrukar mer resurser. First_rows optimizer-läget innebär vanligtvis att man väljer en fullindexskanning över en parallell full-table-skanning. Eftersom first_rows-läget gynnar indexskanningar över hela tabellskanningar är first_rows-läget lämpligast för onlinesystem där slutanvändaren vill se några resultat så snabbt som möjligt.
all_rows mode
detta är ett kostnadsbaserat optimeringsläge som säkerställer att den totala söktiden minimeras, även om det tar längre tid att ta emot den första raden. Detta innebär vanligtvis att man väljer en parallell full-table scan över en full-index scan. Eftersom all_rows-läget gynnar hela tabellskanningar är all_rows-läget bäst lämpat för batchorienterade frågor där mellanliggande rader inte krävs för visning.
vilket är ”bättre”? Snabb körning vs. minimal resursanvändning.
för att förstå Oracles filosofi om snabb körning och minimal resursförbrukning måste vi titta på ett enkelt exempel. För att illustrera skillnaden mellan all_rows och first_rows med ett alltför förenklat exempel, överväga följande fråga:
välj
last_name
från
kund
Beställ med
last_name;
denna fråga kan servas på två sätt:
-
full-table scan-här utför vi en full-table scan parallellt och sorterar raderna i TEMP tablespace. För illustrationens skull, låt oss anta att denna exekveringsplan ger den snabbaste totala exekveringstiden och minimal resursanvändning (Figur 2).
Figur 2: Utför en fullständig tabellsökning och en sortering (all_rows)
-
Full Index scan-här hämtar vi raderna i efternamn ordning med hjälp av en last_name_index. Denna teknik resulterar i mer fysiska läsningar, men börjar returnera sorterade rader nästan omedelbart (Figur 3).
Figur 3: Utför en indexhämtning (first_rows)
igen, förutsatt att vi accepterar full-table-skanningen och sorteringen är mindre i/O-intensiv än full-index-skanningen, så kan vi tydligt se skillnaden i optimeringsmålen. Fullindexskanningen börjar returnera rader nästan omedelbart på bekostnad av extra I/O, medan fullbordsskanningen kräver mindre resurser, men resultatuppsättningen kommer inte att vara tillgänglig till slutet av frågan.
Detta är ett utdrag från ”Oracle high-Performance SQL Tuning” av Donald K. Burleson, publicerad av Oracle Press.
