Tyto stránky jsou nezávislé. Účelem je snaha rozšířit povědomí o Oracle databázi v České republice, vytvořit sadu návodů, rad apod.

17.
LIS

Schéma databáze aneb jak funguje příkaz select v databázi

Napsal admin, kategorie Všeobecné

V tomto článku, mimochodem v mém prvním, se Vám budu snažit vysvětlit, jak funguje databáze, pokud se ji na něco zeptáte a pokud dále budete chtit udělat nějakou změnu.

na obrázku, který můžete vidět dole, je znázorněno schéma funkce Oracle databáze.

Čísla na obrazku odpovídají bodům níže:
1. Uživatel zádá DML příkaz do svého programu (SQL*Plus či jiné alternativy). V našem případě SELECT.
2. Server začne zpracovávat příkaz (dotaz) tak, že se nejprve podívá do Shared pool, zda-li tam není nějaký podobný dotaz. Pokud tam dotaz není, začne ho Oracle takzvaně „parsovat“
a pak dotaz vloží do shared poolu. Parsování SQL příkazu vyžaduje CPU čas. Vložení nového příkazu do shared poolu vyžaduje latch.
3. Poté server proces hledá v buffer cache požadovaný data blok. Nalezeno? V tom případě se data block přesune do sekce naposledy použitých – tzn. LRU list.
4. V případě, že data blok nebyl nalezen, server proces vytahne data ze souboru na disku. Tato akce bude vyzadovat tzn. disk I/O a latch.
5. Když konečně má Oracle veškeré informace, posílá vysledek dotazu uživateli.
6. Klient zadává příkaz UPDATE. Stejně jako v prechozím příkladu probíhá parse SQL příkazu a nasledné ziskání změněných řádek. Změněné řádky se změní v shared memory a také undo tablespace.
7. Změna se projeví v redo logs souborech, kde se zapíše detail transakce.
8. Proces DBWr zapíše změněné data z buffer cache do OS souborů. Mimochodem, uživatel, který provedl update nemusí čekat až se tak stane. Chci tim říct, že tento proces je nezávislí na něm, takže se klidně může odlogovat.
9. Ve chvílí potvrzení změn pomocí COMMIT příkazu se logwriter pokusí zkopírovat obsah redo log bufferu do redo log souborů. COMMIT complete se neukáže pokud nebude tato akce kompletní.
10. V případě, že databáze je v ARCHIVELOG modu, archiver proces zapíše redo logy do archívní lokace (archive destination). Do té doby není možne znovu použíit redo log – dokud není archívován.
11. Každé 3 vteřiny nebo v případe, že nastane „switch“ redo logů nastane chechpoint. Checkpoint vyžaduje zapásání všech změněných bloků v buffer cache na disk. Redo log se nedá znovu použít do té doby, nže checkpoint skončí svou práci.

Když si to pořádně přečtete, zjistíte, že některé aktivity nejsou nutné a zbytečně tak způsobují nároky na systém.

V dalším článku podrobně popíšu potřebné kroky, tak aby jste mohli nainstalovat „svůj“ virtualní linux Oracle 10g.