Oracle Database
tips

parametrar

Parallell tips

Parallelltips på uttalandenivå är de enklaste:

SELECT /*+ PARALLEL(8) */ first_name, last_name FROM employee emp;

Parallell tips på objektnivå ger mer kontroll men är mer benägna att göra fel; utvecklare glömmer ofta att använda alias istället för objektnamnet, eller de glömmer att ta med några objekt.

SELECT /*+ PARALLEL(emp,8) */ first_name, last_name FROM employee emp;

SELECT /*+ PARALLEL(table_alias,Degree of Parallelism) */ FROM table_name table_alias;

Låt oss säga att en fråga tar 100 sekunder att köra utan att använda parallellt ledtråd. Om vi ändrar DOP till 2 för samma fråga, kommer idealiskt samma fråga med parallellt led att ta 50 sekunder. På liknande sätt tar det 25 sekunder att använda DOP som 4.

I praktiken är parallellkörning beroende av många andra faktorer och skalas inte linjärt. Detta gäller särskilt för små körtider där det parallella omkostnaden kan vara större än vinsterna från att köra i flera parallella servrar.

USE_NL

Använd kapslade slingor.

Användning: use_nl(AB)

Detta tips kommer att be motorn att använda kapslad slingmetod för att gå med i tabellerna A och B. Det är jämförelse rad för rad. Tipset tvingar inte ordningen på sammanfogningen, ber bara om NL.

SELECT /*+use_nl(e d)*/ *
FROM Employees E
JOIN Departments D on E.DepartmentID = D.ID

BILAGA TIPS

"Använd metoden DIRECT PATH för att infoga nya rader".

APPEND instruerar motorn att använda direkt vägbelastning . Detta innebär att motorn inte kommer att använda ett konventionellt skär med minnesstrukturer och standardlås, utan kommer att skriva direkt till tabellområdet data. Skapar alltid nya block som läggs till i tabellens segment. Detta kommer att vara snabbare, men har några begränsningar:

• Du kan inte läsa från tabellen du bifogade i samma session förrän du skickar in eller återför transaktionen.
• Om det finns triggers definierade på bordet kommer Oracle inte att använda direktväg (det är en annan historia för sqlldr-laster).
• andra

Exempel.

INSERT /*+append*/ INTO Employees
SELECT *
FROM Employees;

USE_HASH

Instruerar motorn att använda hashmetod för att gå med tabeller i argumentet.

Användning: use_hash(TableA [TableB] ... [TableN])

Som förklarats på många ställen , "i en HASH-anslutning, får Oracle åtkomst till ett bord (vanligtvis det mindre av de sammanfogade resultaten) och bygger ett hashtabell på kopplingsnyckeln i minnet. Det skannar sedan det andra bordet i kopplingen (vanligtvis det större en) och undersöker hashtabellen för matchningar till den. "

Det är att föredra mot Nested Loops-metoden när tabellerna är stora, inga index finns till hands, etc.

Obs : Tipset tvingar inte sammanfogningens ordning, ber bara om HASH JOIN-metoden.

Exempel på användning:

SELECT /*+use_hash(e d)*/ *
FROM Employees E
JOIN Departments D on E.DepartmentID = D.ID

FULL

FULL-antydningen berättar för Oracle att utföra en fullständig tabellscanning på ett specificerat bord, oavsett om ett index kan användas.

create table fullTable(id) as select level from dual connect by level < 100000;
create index idx on fullTable(id);

Med inga tips används indexet:

select count(1) from fullTable f where id between 10 and 100;
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    13 |     3   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE   |      |     1 |    13 |            |          |
|*  2 |   INDEX RANGE SCAN| IDX  |     2 |    26 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------

FULL antydning tvingar en fullständig genomsökning:

select /*+ full(f) */ count(1) from fullTable f where id between 10 and 100;
--------------------------------------------------------------------------------
| Id  | Operation          | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |           |     1 |    13 |    47   (3)| 00:00:01 |
|   1 |  SORT AGGREGATE    |           |     1 |    13 |            |          |
|*  2 |   TABLE ACCESS FULL| FULLTABLE |     2 |    26 |    47   (3)| 00:00:01 |
--------------------------------------------------------------------------------

Resultatcache

Oracle ( 11g och högre ) gör att SQL-frågor kan cachelagras i SGA och återanvändas för att förbättra prestandan. Det frågar data från cache snarare än databas. Efterföljande exekvering av samma fråga är snabbare eftersom nu data dras från cache.

SELECT /*+ result_cache */ number FROM main_table;

Utgång -

Number
------
   1
   2
   3
   4
   5
   6
   7
   8
   9
   10

Elapsed: 00:00:02.20

Om jag kör samma fråga igen nu kommer tiden att köra att minska eftersom data nu hämtas från cache som ställdes in under den första exekveringen.

Utgång -

Number
------
   1
   2
   3
   4
   5
   6
   7
   8
   9
   10

Elapsed: 00:00:00.10

Lägg märke till hur den förflutna tiden minskade från 2,20 sekunder till 0,10 sekunder .

Resultatcache håller cachen tills data i databasen uppdateras / ändras / raderas. Alla ändringar kommer att släppa cachen.