Apr

2006

Oracle Databaser - Del I, General Database Struktur: memory, prosesser, filer

Skrevet af: Karsten Birch-Johansen i Oracle

Technorati Tags: Oracle database General Database Struktur

0 kommentarer : Blogs der linker : Tilføj til del.icio.us : Tilmeld dig feeds herfra : E-Mail posten

Oracle databasen kan groft deles op i 3 hovedkategorier;

1. Memory

2. Database filer, Kontrol filer, Parameter filer

3. Prosessor - Kommunikation mellem Memory og Filer

Udgangspunktet for denne gennemgang er førstegangs brugere eller brugere/udviklere der skal arbejde med Oracle databaser. For alt i nedenstående er der taget udgangspunkt i en dedikeret Oracle server løsning. Det primære fokus ligger på forespørgsler mod databasen dvs. SELECT samt DML (Data Manipulation Language) dvs. INSERT/UPDATE samt DELETE. DCL (Data Control Language) GRANT, REVOKE m.v samt DDL (Data Definition Language) CREATE TABLE, CREATE INDEX m.v gennemgåes i en senere artikel (Den jeg pt ikke har skrevet).

Ligeledes som ved Oracle XE database gennemgangen - benytter jeg TOAD som er et udviklingsværktøj til Oracle databaser - en freeware version kan findes her - man kan også vælge at benytte SQL*Plus der kommer sammen med Oracle Databasen eller hvad med at prøve Oracle's egen SQL Developer som du også finder på ovenstående link.

Men her først en gennemgang af Oracle Database struktur.

1. Memory

Memory delen også kaldet SGA (System Global Area) består af 3 enheder eller strukturer overordnet set.

1. Shared pool er som navnet indikererer et sted hvor ting deles - På et oracle system kan man jo sikkert sagtens forestille sig at forespørgelser, data manipulationer m.v mange gange er identiske og deraf opstår der jo en naturligt behov for genbrug.

Følgende ting gemmes b.la i Shared Pool;

Optimerede query plans, sikkerheds checks, parsede SQL statements, pakker (packages) samt objekt informationer.

F.eks kunne man forestille sig, SELECT * FROM firmaets_centrale_tabel; enten foretaget ved mange brugere fra f.eks SQL*PLUS, laver denne forespørgsel dagligt mange gange. Mere naturligt ville dog være en knap i f.eks ORACLE FORMS der hed "Hent kunde data", eller en knap i et PHP program der kaldte en STORED PROCEDURE der også hentede kundedata.

Data genbruges ved 100% identiske udtryk - så ved mange manuelle forespørgsler vil der ofte være forskel i forespørgslerne - et ekstra mellemrum osv. at dette ikke udnyttes optimalt. Derfor og også afhensyn til fejlrettelser mv. er det optimalt at benytte samme udtryk foretaget et sted fra.

Derfor har Oracle lavet en funktionalitet således at er et udtryk allerede evalueret og parset - og er 100% identiske forsøges der benyttet den parsede version. For os brugere har det en cost effekt der er til at mærke tingene går nemlig hurtigere. Shared Pool er igen delt op i 2 områder;

Library Cache og Data Dictionary Cache.

Dictionary Cache er der Oracle slår op for at checke b.la om hvorvidt et givent objekt eksisterer, har brugeren ret til at gøre hvad denne forsøger. Dictionary cachen bruges så ofte af Oracle at den faktisk eksisterer 2 steder - det ene område er dette der her omtales også omtalt som Row cache og det andet sted er i library cachen. Oracle's bruger prosesser, benytter disse 2 caches for at tilgå information omkring data dictionary.

Hvis vi forestiller os en bruger - der iøvrigt hedder Ole. Ole sidder ved sin PC med en lokal Oracle Database kørende. Når man kommunikerer med en Oracle Database foregår dette via brugere. En bruger på et system har ret til at se og manipulerer alt det man vil med sine egne objekter. For at se andre objekter skal der gives ret til dette og det kan styres på niveau hvor giveren kan sætte læse adgang eller læse/skrive adgang eller eksekverings adgang m.v til objekter i Oracle databasen. Ole er logget som Ole/Ole på sin lokale PC, og han benytter TOAD for at udføre/eksekverer SQL udtryk mod sin database, og skriver SELECT * FROM my_table; hvilket er en tabel han lige har lavet der indeholder 10 rækker. I det øjeblik han sender udtrykket til Oracle Serveren checkes der i Dictionary for Objektet, eksisterer dette - med dette navn, Har Ole ret til at læse fra objektet m.v.

For såvidt dette er sandt - vil udtrykket blive parset - der findes bla bedste eksekverings vej m.v og data retuneres til Data Buffer Cachen og videre til brugeren der ser de 10 rækker.

Laver Ole en gentagelse af sit SQL udtryk vil prosessen for check være den samme - rettigheder kan jo sagtens ændre sig BOFH; men der vil denne gang blive benyttet den parsede version af SQL udtrykket der ligger i SQL area.

Ligeledes læses data ikke fysisk fra disk men fra Data Buffer Cachen hvor data lige før er blevet placeret. Der sker nemlig det ved læsninger og andet at data indlæses til Database Buffer Cachen. Det betyder at der checkes om data eksisterer der FØR en fysisk læsning - også kaldet en LOGISK læsning.

Library Cachen er delt op i;

- Shared SQL Area

Dette område indeholder et parse træ samt en eksekverings plan for et givent SQL udtryk. Oracle benytter denne fremgangs måde, idet mange SQL udtryk ofte udføres mange gange - og er udtryk somsagt 100% identiske benyttes det der allerede eksistere i shared SQL area. Hvis udtryk ikke benyttes ofte ryger de ud fra området via en LRU mekanisme.

- PLSQL procedures

Det samme gælder for procedurer, triggers, anonyme blokke og funktioner - der gemmes den kompilerede og parsede form af en program del i cachen med udgangspunkt i genbrug hvis muligt.

- Kontrol strukturer (latches og låsninger)

indeholdes også i dette område. mere om dette senere.

2. Database Buffer Cache er en anden struktur i SGA'en - og som indikeret i ovenstående benyttes den i stor stil sammen med bla shared pool. Strukturen er opdelt i buffere - deres størrelse angives i Oracle Parameter filen - som jeg vender tilbage til senere.

Formålet med Database Buffer Cachen er at minimere fysisk IO. Når en blok læses af Oracle , Placerer Oracle denne blok i Database Bufferen, udfra at, der er en chance at denne blok skal bruges igen senere. Læsning fra Cachen er effektivt og mindre omkostningsfyldt end at foretage fysiske læsninger fra disk (målt i tid).

Blokke i Database Buffer Cachen er ordnet fra MRU (most recently used) blokke til LRU (least recently used) blokke. Når en blok tilgåes ligges blokken i MRU enden af listen og skifter dermed eksisterende blokke ned med 1 i LRU enden af listen.

Når data læses fra disk og Database Bufferen er fyldt skal der gøres plads til den nye blok - og den blok der må forlade Database Buffer Cachen er den der ligger i LRU enden.

Database bufferen består faktisk også af 3 pools;

- Keep Pool (formål at tage objekter der altid skal caches - lookup_tables f.eks se db_keep_cache_size)

- Recycle Pool (er for større objekter se db_recycle_cache_size)

- Default pool (alt det andet se også x$kcbwbpd)

I forhold til læsninger hvor Ole fra før lavede en ved hjælp af SELECT kunne han også have lavet en opdatering.

F.eks kunne Ole skrive; UPDATE my_table SET godkendt=0 WHERE id=10;

Ved f.eks en UPDATE opdateres Database Buffer Cachen med en Before record og en After Record. I simple ord gemmes hvordan rækken så ud før der blev udført update og efter. Et hvilket somhelst DML udtryk i en Oracle database afsluttes med - en bekræftigelse eller fortrydelse med COMMIT og ROLLBACK.

Det hedder READ CONSISTENSY at Oracle vælger at have en Before record og en after record - og betyder bla at hvis vi forestiller os Ole's kammerat Bjarne, af Ole har fået rettighed til at læse SELECT fra ole.my_table ser Bjarne ikke Ole's UPDATE FØR Ole har lavet en COMMIT. - i Praksis læser Oracle BEFORE RECORD'en.

Database Buffer Cachen Bliver jo fyldt op på et tidspunkt og en anden af Oracle's mekanismer er REDO log bufferen.

3. Redo Log Buffer - er Oracle's svar på en båndoptager. Alt DML, DDL samt DCL optages - Jeg beskriver disse sprog senere - for nu er DML (Insert, Update, Delete) - Hvad så med SELECT ? kan det forekomme i REDO - ja ved dirty buffer cleanout - mere om det senere dog.

Somsagt alle ændringer vil efterhånden som Database Buffer Cachen bliver fyldt op blive gemt over i REDO Buffer Cachen,- men også ved threshold dvs når der er søgt x antal mili sekunder uden at finde en free buffer signaleres der en oprydning. Og som redo log bufferen ligeledes bliver fyldt op skrives indhold herfra til Oracle's Log filer. Et standard Oracle System skal minimum have 2 grupper af logfiler - bestående af minimum 1 fil. Oracle Kan sættes op til at køre med Archiving hvilket er smart - Log filerne som de fyldes op skrives/eller gemmes så på en valgt destination (disk, tape, /dev/null) - det betyder i princippet at et oracle system der kører med archiving der går ned skal man blot indlæse disse logfiler da de jo indeholder alle ændringer siden man begyndte med archiving - og x antal tid senere er man oppe - point in time recovery. Kører men uden archiving overskrives filerne (Robin round) som disse fyldes og muligheden for ved nedbrud at ligge ændringer på databasen via logfiler frafalder..

2. Database filer, Kontrol filer, Parameter filer

Til en Oracle Database hører filer. Når et Oracle system opstartes indlæses Database Parameter filen typisk kaldet INIT.ORA - denne beskriver bla. størrelsen på Shared Pool, Antal Database Buffere samt en helt masse andet.

Centralt i en Oracle database er naturligt nok Database filerne. De indeholder system data, logiske strukturer, programmer og bruger data. En Oracle Database fil er ikke bare en tekst fil - men indeholder et kompleks af logiske Oracle strukturer.

Den største logiske enhed i en Oracle Database fil kaldes et TABLESPACE. Et tablespace kan ved definering indeholde 1 eller flere fysiske filer. Og senere som databasen vokser er der rig mulighed for at udvide med yderligere filer. Enheden er logisk fordi den ikke er synlig på fil systemmet eller på maskinen hvorpå det ligger.

Alle data i en Oracle database tilhører et eller andet tablespace. Et tablespace er den bro der eksisterer mellem logiske enheder i en database som tabeller, indexer m.v og det fysiske fil system.

Der er 3 typer tablespaces; Permanente, UNDO og TEMP. En feature i 10G er tablespace grupper

alter tablespace ts_user tablespace group ts_grp_user;

Typisk vil en Oracle Database som minimum indeholde tabelspaces der hedder SYSTEM, TEMP, UNDO, USERS, TOOLS. Det er frit for arkitekten senere f.eks at oprette et der kunne hedde KUNDEDATA - med hensigt at alt kundedata skal gemmes her. Det er fornuftigt at benytte disse strukturer til logisk at opdele sin database så det er overskueligt at arbejde med den. Som standard SKAL en oracle database indeholde et tablespace der hedder SYSTEM - Dette indeholder data dictionary - stedet hvor objekt managment, rettigheder, sessioner, brugere mv. gemmes og holdes styr på. Der er ikke noget der hindrer at en administrator, gemmer alle sine personlige data i SYSTEM - det er bare svær administration og ligeledes sættes alt manipulation, forespørgsler krav til at der hele tiden forespørges mod samme database fil(r) og det kan give problemmer med performance. Ligeledes er der en masse omkring back/recovery, on- og offline tabelspaces der gør det uhensigtsmæssigt - så lad være med det :)

Tablespaces er igen delt op i SEGMENTER. Segmenter kan være af klassen DATA (tabel og cluster), INDEX, ROLLBACK, TEMPORARY i 10G findes til disse segment klasser - 11 segment typer.

Segmenter er delt op i EXTENTS. Extents er en del af et segment - og består af en eller flere sammenhængende Oracle Database Blokke - der er lagringsenheder bestående af en eller flere OS blokke. EXTENTS tilhører et tablespace. Et eller flere extents udgør et segment.

Extents er opdelt i Oracle Data Blokke. Data Blokke eller deres størrelse defineres i parameter filen - De behøver ikke at være samme størrelse som operativsystemmets størrelse på en blok - således kan en oracle data blok sagtens består af f.eks 2 OS blokke - størrelses mæssigt.

Samlingen af OS blokke udgør din Oracle Database fil(r).

3. Prosessor - Kommunikation mellem Memory og Filer

Prosessor eller baggrundsprosesser i Oracle er en vigtig del af det hele idet de sikrer kommunikationen mellem alle involverede dele. Disse kan illustreres således;

Hvis vi starter med de mest centrale - dem der er default for systemmet er disse;

PMON - Process Monitor - den sørger for;

- Rydde op i terminierede processer, - Foretage ROLLBACK på ucommitede transaktioner,- Frigøre evt. låse der holdes af den terminerede process,- Frigørsel af SGA resourser allokeret af den terminerede process,- genstart af evt. fejlede server prosesser eller dispatcher processor.

SMON - System Monitor - Den sørger for;

- Automatisk instance recovery,- Generhvervelse af plads fra temporere segmenter der ikke benytter pladsen længere,- Merge af fri plads områder i datafiler.

RECO, LCKn, Pnnn, og SNPn processerne;

- Recover processen (RECO) løser fejl hvori distribuerede transaktioner indgår,- LCKn prossesen fortager såkaldt inner-instance låsning i Paraelle Server miljøer,- Parallel query (Pnnn) sørger for parallel query, parallel index oprettelse, parallel data load og parallel CREATE TABLE AS SELECT funktionaliteter.,- SNPn - snapshot prosessen sørger automatisk refresh af snapshots (read-only replikerede tabeller). Den er ligeledes ansvarlig for server job køer og replikations køer.

Bruger- og Server prosesser;

Hertil kommer så bruger og server prosesserne. Hver bruger det forbinder sig til oracle databasen har sin egen bruger prosess - Denne kommunikerer med en server proses så længe bruger prossesen lever.

Så er det så vi kan begynde at kigge lidt på bruger prosesser - somsagt benytter jeg TOAD og for tilfældet benytter jeg min Oracle XE installation.

Når der forbindes til en Oracle database er det typisk at dette gøres udfra en beskrivelse i en fil kaldet TNSNAMES.ORA den er hos mig beliggende i $ORACLE_HOME/network/admin og XE beskrivelse ser sådan ud;

XE =
(DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = MOT-2)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = XE)
    )
)

Som det ses beskrives at databasen ligger på maskinen MOT-2 og der ligger en process og lytter efter indkomne forespørgsler på port 1521. Denne prosess er beskevet i filen LISTENER.ora og ser sådan ud

LISTENER =
(DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC_FOR_XE))
      (ADDRESS = (PROTOCOL = TCP)(HOST = MOT-2)(PORT = 1521))
    )
)

DEFAULT_SERVICE_LISTENER = (XE)

Vi er næsten klar skal TOAD eller andre værktøj benyttes på PC'ere med flere oracle homes - er det en god ide at sætte TNS_ADMIN op i environment

Sluttelig på en ny XE installation ligger også en SQLNET.ora fil så man ved database skal skrive XE.world - rename den til .old og vi er klar.

Herefter kan jeg forbinde mig - listeneren på port 1521 kaldes og den starter en server proses så længe jeg er på. F.eks kan i fra min TOAD se når jeg udfører en select;

Oracle Instance og Oracle Database

Men skelner mellem en instans og database når man taler oracle i bøger og andre steder. En oracle instans er;

Og en Oracle Database er;

Hertil kommer en speciel fil der hedder en kontrol fil som ses i ovenstående;

Kontrol fil(erne)

- Identificerer alle database filer og log filer på systemmet,- Databasens navn er gemt i kontrol filen,- En kontrol fil er nødvendig for at kunne mounte, åbne og tilgå databasen,- Synkroniserings information til recovery er gemt i kontrol filen,- det anbefales at have minimum 2 kontrol filer på et system,- parameteren CONTROL_FILES i parameter filen fortæller hvilke kontrol filer der skal bruges.

Parameterfilen

Parameterfilen er en sidste fil der definerer bla strukturer for SGA'en, kontrol filer som nævnt men også rollback_segments m.v

Det sidste der bør nævnes er ALERT filen samt TRACE filerne - der er en vigtig del af daglig administration idet de indeholder fejl og hændelser rapporteret fra Oracle systemmet. Slutteligt et overblik over et Oracle System i en dedikert server løsning;