1

Oracle datu bāzes servera kopējā arhitektūra

2

Oracle datu bāzes vadības sistēmas eksemplāra (instances) struktūra

1. SGA, System Global Area – izmanto visi Oracle DBS procesi.

2. PGA, Process Global Area – atsevišķo procesu un pavedienu privātā atmiņa.

3. UGA, User Global Area – seansa atmiņa (var būt SGA, ja koplietošanas serveri) un PGA (ja izdalītais serveris).

3

Oracle datu bāzes 18c datu apstrādes pamatprocess1

Oracle datu bāze sastāv vismaz:1) no vienas datu bāzes instances;2) vienas datu bāzes.

Datu bāzes instance apstrādā atmiņu un procesus. Datu bāze sastāv no fiziskiem failiem, ko sauc par datu failiem, un tā var būt datu bāze bez konteinera vai vairāku nomnieku konteineru datu bāze. Oracle datu bāze savas darbības laikā izmanto arī vairākus datu bāzu sistēmas failus.Pastāv relācija “viens pret vienu” starp datu bāzi un datu bāzes instanci. Vienā servera datorā var instalēt vairākas vienas instances datu bāzes. Katrai datu bāzei ir atsevišķas datu bāzes instances. Šī konfigurācija ir noderīga, lai tajā pašā datorā palaistu dažādas Oracle datu bāzes versijas.Oracle Real Application Clusters (Oracle RAC) datu bāzes arhitektūra sastāv no vairākām instancēm, kas tiek palaistas atsevišķos serveru datoros. Visi koplieto vienu datu bāzi. Servera datoru klasteris vienā galā tiek parādīts kā viens serveris, bet otrā galā lietotāji un lietojumprogrammas. Šī konfigurācija ir paredzēta augstas pieejamības, mērogojamības un augstas veiktspējas nodrošināšanai.Klausītājs ir datu bāzes servera process. Tā saņem klienta pieprasījumus, izveido savienojumu ar datu bāzes instanci un pēc tam nodod klienta savienojumu ar servera procesu. Klausītājs var darboties lokāli datu bāzes serverī vai izpildīt attāli. Tipiska Oracle RAC vide tiek palaista attāli.

1 https://www.oracle.com/webfolder/technetwork/tutorials/architecture-diagrams/18/technical-architecture/database-technical-architecture.html

4

SQL komandu apstrāde

SQL apstrāde ir SQL priekšraksta, komandas:1) izskatīšana, iztirzāšana, analīze, parsēšana (parsing);2) optimizēšana;3) rindu avotu ģenerēšana;4) izpilde.

Atkarībā no komandas datu bāze var izlaist dažus no šiem posmiem.

5

SQL analīze (parsēšana)

SQL apstrādes pirmais posms ir komandas analīze. Parsēšanas posms ietver SQL priekšraksta daļu sadalīšanu datu struktūrā, ko var apstrādāt citas rutīnas (Programmas daļa vai instrukciju secība, kas veic kādu specifisku uzdevumu un kam ir biežs lietojums. Parasti lieto attiecībā uz asemblera programmām). Datu bāze atstāj paziņojumu, kad to uzdod lietojumprogramma, kas nozīmē, ka tikai lietojumprogramma, nevis pati datu bāze var samazināt parsējumu skaitu.Ja lietojumprogramma izdod SQL priekšrakstu, tā veic parsēšanas izsaukumu (parse call) uz datu bāzi, lai sagatavotu priekšrakstu izpildei. Parsēšanas izsaukums atver vai izveido kursoru, kas ir ar sesiju saistīta privāta SQL apgabala turis, kurā atrodas parsēts SQL priekšraksts un cita apstrādes informācija. Kursors un privātais SQL apgabals atrodas programmas globālajā apgabalā (PGA).Parsēšanas izsaukuma laikā datu bāze veic pārbaudes, kas identificē kļūdas, kuras var atrast pirms priekšraksta izpildes. Dažas kļūdas nevar noķert parsējot. Piemēram, datu bāze var saskarties ar strupceļu vai kļūdām datu konvertēšanā tikai pārskata izpildes laikā.

Oracle datu bāzei jāpārbauda katra SQL priekšraksta sintaktiskais derīgums.Semantiskā pārbaude nosaka, vai priekšrakstam ir nozīme, piemēram, vai pārskatā ir objekti un kolonnas.

6

Koplietojamā pūla (shared pool) pārbaude

Parsēšanas laikā datu bāze veic koplietojamo pūla pārbaudi, lai noteiktu, vai tā var izlaist resursu ietilpīgas pārskatu apstrādes darbības.Šajā nolūkā datu bāze izmanto jaukšanas (hashing) algoritmu, lai katram SQL priekšrakstam ģenerētu jaukšanas (hash) vērtību. Pārskata jaukšanas vērtība ir SQL ID, kas parādīts V$SQL.SQL_ID. Šī heš vērtība ir noteikta datu bāzes versijā, tāpēc vienam un tam pašam priekšrakstam vienā instancē vai dažādos gadījumos ir vienāds SQL ID.Kad lietotājs iesniedz SQL priekšrakstu, datu bāze meklē koplietojamo SQL apgabalu, lai redzētu, vai esošajam parsētajam priekšrakstam ir tāda pati heš vērtība. SQL priekšraksta heš vērtība atšķiras no šādām vērtībām:

1) priekšraksta atmiņas adrese. Datu bāzes sistēma izmanto SQL ID, lai veiktu meklēšanu meklēšanas tabulā (lookup table). Šādā veidā datu bāze iegūst iespējamās priekšraksta atmiņas adreses.

2) priekšraksta izpildes plāna heš vērtība. Koplietojamā pūlā SQL priekšrakstam var būt vairāki plāni. Parasti katram plānam ir atšķirīga heš vērtība. Ja vienam un tam pašam SQL ID ir vairākas plānu heš vērtības, tad datu bāze zina, ka šim SQL ID pastāv vairāki plāni.

Atkarībā no iesniegtā priekšraksta veida un heš pārbaudes rezultāta parsēšanas darbības iedala šādās kategorijās:

1) cieta jeb grūta (hard parse) parsēšana. Ja datu bāze nevar atkārtoti izmantot esošo kodu, tai ir jāizveido jauna lietojumprogrammas koda izpildāmā versija. Šo operāciju sauc par cieto parsēšanu vai bibliotēkas kešatmiņas nelietošanu. Datu bāze vienmēr veic DDL priekšrakstu cieto parsēšanu. Cietās parsēšanas laikā datu bāze vairākas reizes piekļūst bibliotēkas kešatmiņai un datu vārdnīcas kešatmiņai, lai pārbaudītu datu vārdnīcu. Kad datu bāze piekļūst šiem apgabaliem, tā izmanto serializācijas ierīci, ko sauc par fiksatoru (latch) pieprasītajiem objektiem, lai to definīcija nemainītos. Slēguma sakritība (latch contention) palielina priekšraksta izpildes laiku un samazina konkurenci.

2) mīkstā parsēšana (soft parse). Mīksta parsēšana ir jebkura parsēšana, kas nav cieta parsēšana. Ja iesniegtais priekšraksts ir tāds pats kā atkārtoti izmantojams SQL priekšraksts koplietojamā pūlā, datu bāze atkārtoti izmanto esošo kodu. Šī koda atkārtota izmantošana tiek saukta arī par bibliotēkas kešatmiņas trāpījumu. Mīkstās parsēšanas var atšķirties atkarībā no tā, cik daudz darba tās veic. Piemēram, sesijas koplietotā SQL apgabala konfigurēšana dažkārt var samazināt latingošanas apjomu mīkstajās parēs, padarot tos “mīkstākus”. Parasti mīksta parse ir labāka par cieto parsēšanu, jo datu bāze izlaiž optimizācijas un rindu ģenerēšanas soļus, kas virzās tieši uz izpildi. Attēlā ir vienkāršots koplietojama pūla pārbaudes attēlojums atjauninājuma UPDATE priekšrakstam izdalītā (dedicated) servera arhitektūrā.

7

Koplietošanas servera pārbaude (shared pool check)

Ja pārbaude nosaka, ka priekšrakstam koplietojamā pūlā ir vienāda heš vērtība, tad datu bāze veic semantiskās un vides pārbaudes, lai noteiktu, vai priekšrakstiem ir vienāda jēga. Ar identisku sintaksi nepietiek. Piemēram, pieņemsim, ka datu bāzē piesakās divi dažādi lietotāji un izdod šādus SQL priekšrakstus:

select a.* from TABULA1;select * from TABULA1;

Abu lietotāju select priekšraksti ir sintaktiski identiski, bet divi atsevišķi shēmas objekti ir nosaukti par TABULA1. Šī semantiskā atšķirība nozīmē, ka otrais priekšraksts nevar atkārtoti izmantot kodu pirmajam priekšrakstam.Pat tad, ja divi izteikumi ir semantiski vienādi, vides atšķirība var piespiest kādu cietu parsēšanu. Šajā kontekstā optimizētāja vide ir sesijas iestatījumu kopums, kas var ietekmēt izpildes plāna ģenerēšanu, piemēram, darba apgabala lielums vai optimizētāja iestatījumi (piemēram, optimizētāja režīms).

8

Optimizācijas vides atšķirības

Piemērā viens un tas pats SELECT priekšraksts tiek izpildīts trīs dažādās optimizētāja vidēs. Līdz ar to datu bāze šiem priekšrakstiem izveido trīs atsevišķus koplietotus SQL apgabalus un veido katra priekšraksta cietu parsēšanu.

ALTER SESSION SET OPTIMIZER_MODE=ALL_ROWS;ALTER SYSTEM FLUSH SHARED_POOL; # opt. vide 1SELECT * FROM TABULA1;

ALTER SESSION SET OPTIMIZER_MODE=FIRST_ROWS; # opt. vide 2SELECT * FROM TABULA1;

ALTER SESSION SET SQL_TRACE=true; # opt. vide 3SELECT * FROM TABULA1;

9

SQL optimizācija

Optimizēšanas laikā datu bāzei vismaz vienu reizi jāveic cietā parsēšana katram unikālajam DML priekšrakstam un šīs parsēšanas laikā jāveic optimizācija.Datu bāze neoptimizē DDL. Vienīgais izņēmums ir, ja DDL ietver DML komponentu, piemēram, apakšvaicājumu, kam nepieciešama optimizēšana.

SQL rindu avota ģenerēšana

Rindu avota ģenerators ir programmatūra, kas saņem optimālo izpildes plānu no optimizētāja un izveido iteratīvo izpildes plānu, ko datu bāzes sistēma var izpildīt.Iteratīvais plāns ir bināra programma, kas, izpildot SQL programmu, izveido rezultātu kopu. Plāns notiek etapu kombinācijas veidā. Katrs solis atgriež rindu kopu. Nākamā darbība izmanto rindas šajā kopā vai pēdējā darbība atgriež rindas lietojumprogrammā, kas izdod izpildāmo SQL priekšrakstu.Rindas avots ir rindu kopa, ko atgriež izpildes plāna solis kopā ar kontroles struktūru, kas var atkārtoti apstrādāt rindas. Rindas avots var būt tabula, skats vai savienošanas vai grupēšanas operācijas rezultāts.Rindu avota ģenerators izveido rindu avota koku, kas ir rindu avotu kolekcija. Rindu avota kokā tiek parādīta šāda informācija:

1) to tabulu kopa, uz kurām norādīts priekšrakstā;2) piekļuves metode katrai tabulā, kas minēta priekšrakstā;3) savienošanas (join) metode tabulām, ko izmanto operācijas priekšrakstā;4) datu operācijas, piemēram, filtrs, kārtošana vai apkopošana.

10

Izpildes plāns

Šis piemērs parāda SELECT priekšraksta izpildes plānu, kad AUTOTRACE ir aktivizēta. Priekšraksts atlasa uzvārdu, amatu un nodaļas nosaukumu visiem darbiniekiem, kuru uzvārdi sākas ar burtu A. Šī priekšraksta izpildes plāns ir rindu avota ģeneratora izvade.

SELECT e.last_name, j.job_title, d.department_name FROM hr.employees e, hr.departments d, hr.jobs jWHERE e.department_id = d.department_idAND e.job_id = j.job_idAND e.last_name LIKE 'A%'; Execution Plan----------------------------------------------------------

Plan hash value: 975837011--------------------------------------------------------------------------------| Id| Operation | Name |Rows|Bytes|Cost(%CPU)|Time |--------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 3 | 189 | 7(15)| 00:00:01 ||*1 | HASH JOIN | | 3 | 189 | 7(15)| 00:00:01 ||*2 | HASH JOIN | | 3 | 141 | 5(20)| 00:00:01 || 3 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 3 | 60 | 2 (0)| 00:00:01 ||*4 | INDEX RANGE SCAN | EMP_NAME_IX | 3 | | 1 (0)| 00:00:01 || 5 | TABLE ACCESS FULL | JOBS | 19 | 513 | 2 (0)| 00:00:01 || 6 | TABLE ACCESS FULL | DEPARTMENTS | 27 | 432 | 2 (0)| 00:00:01 |-------------------------------------------------------------------------------- Predicate Information (identified by operation id):--------------------------------------------------- 1 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID") 2 - access("E"."JOB_ID"="J"."JOB_ID") 4 - access("E"."LAST_NAME" LIKE 'A%') filter("E"."LAST_NAME" LIKE 'A%')

11

SQL izpilde

Izpildes laikā SQL dzinējs izpilda katru rindas avotu kokā, ko izveidojis rindu avota ģenerators. Šis solis ir vienīgais obligātais solis DML apstrādē.Attēls ir izpildes koks, ko sauc arī par parsēšanas koku, kas rāda rindu avotu plūsmu no viena soļa uz citu piemērā. Kopumā izpildāmo soļu secība plānā ir apgriezta, tāpēc plānu jālasa no apakšas uz augšu.Katram izpildes plāna solim ir ID numurs. Skaitļi attēlā atbilst ID kolonnai plānā, kas parādīts piemērā. Sākotnējās atstarpes plāna kolonnā Operācija norāda hierarhiskas relācijas. Piemēram, ja pirms operācijas nosaukuma ir divas atstarpes, tad šī operācija ir operācijas bērnelements, kam priekšā ir viena atstarpe. Operācijas, kurām priekšā ir viena atstarpe, ir paša SELECT priekšraksta bērni.

12

Rindu avota koks (row source tree)

Attēlā katrs koka zars darbojas kā rindas avots, kas nozīmē, ka katrs izpildes plāna solis piemērā:

1) vai nu iegūst rindas no datu bāzes;2) vai pieņem rindas no viena vai vairākiem rindu

avotiem kā ievadi. SQL dzinējs izpilda katru rindu avotu šādi:

1) darbības, ko norāda melnie lodziņi, fiziski izgūst datus no datu bāzes objekta. Šīs darbības ir piekļuves ceļi vai paņēmieni datu izgūšanai no datu bāzes;

2) 6. darbībā tiek izmantota pilna tabulas skenēšana, lai izgūtu visas rindas no nodaļu tabulas.

3) 5. darbībā tiek izmantota pilna tabulas skenēšana, lai no darbu tabulas izgūtu visas rindas.

4) 4. solis skenē emp_name_ix indeksu, meklējot katru taustiņu, kas sākas ar burtu A, un ielādējot atbilstošo rowid. Piemēram, Atkinsonam

atbilstošais rowid ir AAAPzRAAFAAAABSAAe.5) 3. soli no darbinieku tabulas iegūst rindas, kuru rowids tika atgrieztas ar 4. soli.

Piemēram, datu bāze izmanto rowid AAAPzRAAFAAAABSAAe, lai izgūtu Atkinson rindu.

6) baltajās kastēs norādītās darbības tiek veiktas rindu avotos. 2. solis veic jaukšanas savienojumu, pieņemot rindu avotus no 3. un 5. soļa, pievienojot katru rindu no 5. soļa rindas avota uz atbilstošo 3. soļa rindu un atgriežot iegūtās rindas 1. darbībā. Piemēram, darbinieka Atkinsona rinda ir saistīta ar darba nosaukumu Stock Clerk.

7) 1. solis veic vēl vienu jaukšanas savienojumu, pieņemot rindu avotus no 2. un 6. soļa, pievienojot katru rindu no 6. soļa avota uz atbilstošo 2. soļa rindu un atdodot rezultātu klientam. Piemēram, darbinieka Atkinsona rinda ir saistīta ar nodaļu ar nosaukumu Nosūtīšana.

Dažos izpildes plānos darbības ir iteratīvas un citos secīgas (virknes). Jaukšanas savienojums, kas parādīts piemērā, ir secīgs. Datu bāze, pamatojoties uz savienošanas pasūtījumu, pilnībā pabeidz šīs darbības. Datu bāze tiek sākta ar emp_name_ix indeksa diapazona skenēšanu. Izmantojot rowids, ko tas iegūst no indeksa, datu bāze nolasa atbilstošās rindas darbinieku tabulā un pēc tam skenē darbu tabulu. Kad tā ir izguvusi rindas no darbu tabulas, datu bāze veic jaukšanas savienojumu.Izpildes laikā datu bāze nolasa datus no diska atmiņā, ja dati nav atmiņā. Datu bāze izņem arī slēdzenes (locks) un slēgus (latches), kas nepieciešami, lai nodrošinātu datu

13

integritāti un reģistrētu visas SQL izpildes laikā veiktās izmaiņas. SQL priekšraksta apstrādes pēdējais posms aizver kursoru.

Efektīvu lietojumu veidošanas vadlīnijas

Sistēmas izstrādes posmā nodrošiniet, lai lietojumprogrammu izstrādātāji izprastu SQL izpildes efektivitāti. Lai sasniegtu šo mērķi, izstrādes videi ir jāatbalsta šādām īpašībām:

1) efektīva datu bāzes savienojuma veidošana. Savienojuma izveide ar datu bāzi ir dārga operācija, kas nav mērogojama. Tāpēc labākā prakse ir samazināt vienlaicīgu savienojumu skaitu ar datu bāzi. Vienkārša sistēma, kurā lietotājs izveido savienojumu lietojumprogrammas inicializācijas laikā, ir ideāla. Tomēr tīmekļa vai daudzpavedienu lietojumprogrammā, kurā lietojumprogrammu serveri apvieno (multiplex) datu bāzu savienojumus ar lietotājiem, šī pieeja var būt sarežģīta. Izmantojot šāda tipa lietojumprogrammas, noformējiet tās, lai apvienotu datu bāzes savienojumus, nevis atkārtoti izveidotu savienojumus katram lietotāja pieprasījumam.

2) laba kursora izmantošana un pārvaldība. Lietotāju savienojumu uzturēšana ir vienlīdz svarīga, lai samazinātu analīzes (parsing, sintaktiskais sadalītājs) darbību sistēmā. Parsēšana ir SQL priekšraksta interpretēšanas un izpildes plāna izveides process. Šim procesam ir vairākas fāzes, tostarp sintakses pārbaude, drošības pārbaude, izpildes plāna izveide un koplietojamo struktūru ievietošana koplietotajā pūlā. Ir divi parsēšanas operāciju veidi:

- grūta (hard) parsēšana. SQL priekšraksts tiek iesniegts pirmo reizi, un koplietotajā pūlā (shared pool) nav atrasta neviena atbilstība. Grūtā parsešana ir visapjomīgākā un nemērogojama, jo tās veic visas parsēšanā iesaistītās operācijas.

- mīksta (soft) parsēšana. Pirmo reizi tiek iesniegts SQL priekšraksts, un koplietotajā pūlā tiek atrasta atbilstība. Šī atbilstība var būt cita lietotāja iepriekšējās izpildes rezultāts. SQL priekšraksts tiek koplietots, kas ir optimāls veiktspējai. Tomēr mīkstā parsēšana nav ideāla, jo tai joprojām ir nepieciešama sintakses un drošības pārbaude, kas patērē sistēmas resursus.

Tā kā parsēšana pēc iespējas jāsamazina, lietojumprogrammu izstrādātājiem ir jāizstrādā savas lietojumprogrammas, lai vienreiz parsētu SQL priekšrakstus un izpildītu tos vairākas reizes. Tas tiek darīts, izmantojot kursorus. Pieredzējušiem SQL programmētājiem jāpārzina kursoru atvēršanas un atkārtotas izpildes koncepcija.

3) efektīvi izmantot saistošos (bind) mainīgos. Lietojumprogrammu izstrādātājiem ir arī jānodrošina, lai koplietotajā pūlā tiktu kopīgoti SQL priekšraksti. Lai sasniegtu šo mērķi, izmantojiet saistījuma mainīgos, lai attēlotu vaicājuma daļas, kas mainās no izpildes uz izpildi. Ja tas netiek izdarīts, SQL priekšraksts, visticamāk, vienreiz tiks parsēts un citi lietotāji to nekad vairs neizmantos. Lai

14

nodrošinātu SQL koplietošanu, izmantojiet saistīšanas mainīgos un neizmantojiet virkni literāļu ar SQL priekšrakstiem. Piemēram:

Priekšraksts ar virkni literāļu:

SELECT * FROM employees WHERE last_name LIKE 'KING';

Priekšraksts ar saites mainīgo::SELECT * FROM employees WHERE last_name LIKE :1;

Test #Users SupportedNo Parsing all statements 270 Soft Parsing all statements 150Hard Parsing all statements 60Re-Connecting for each Transaction 30These tests were performed on a four-CPU computer. The differences increase as the number of CPUs on the system increase.

15

Guideline for deploying in a test environment

The testing process mainly consists of functional and stability testing. At some point in the process, you must perform performance testing.The following list describes simple rules for performance testing an application. If correctly documented, then this list provides important information for the production application and the capacity planning process after the application has gone live. Use the Automatic Database Diagnostic Monitor (ADDM) and SQL Tuning Advisor for design validation. Test with realistic data volumes and distributions.All testing must be done with fully populated tables. The test database should contain data representative of the production system in terms of data volume and cardinality between tables. All the production indexes should be built and the schema statistics should be populated correctly. Use the correct optimizer mode.Perform all testing with the optimizer mode that you plan to use in production. Test a single user performance.Test a single user on an idle or lightly-used database for acceptable performance. If a single user cannot achieve acceptable performance under ideal conditions, then multiple users cannot achieve acceptable performance under real conditions. Obtain and document plans for all SQL statements.Obtain an execution plan for each SQL statement. Use this process to verify that the optimizer is obtaining an optimal execution plan, and that the relative cost of the SQL statement is understood in terms of CPU time and physical I/Os. This process assists in identifying the heavy use transactions that require the most tuning and performance work in the future. Attempt multiuser testing.This process is difficult to perform accurately, because user workload and profiles might not be fully quantified. However, transactions performing DML statements should be tested to ensure that there are no locking conflicts or serialization problems. Test with the correct hardware configuration.Test with a configuration as close to the production system as possible. Using a realistic system is particularly important for network latencies, I/O subsystem bandwidth, and processor type and speed. Failing to use this approach may result in an incorrect analysis of potential performance problems. Measure steady state performance.When benchmarking, it is important to measure the performance under steady state conditions. Each benchmark run should have a ramp-up phase, where users are connected to the application and gradually start performing work on the application. This process allows for frequently cached data to be initialized into the cache and single execution operations such as parsing to be completed before the steady state condition.

16

Likewise, after a benchmark run, a ramp-down period is useful so that the system frees resources, and users cease work and disconnect.