Informatika | Adatbázisok » Dr. Kovács László - Oracle adatbázis rendszerek

Adatbázis rendszerek III Jegyzet Készítette: dr. Kovács László Miskolci Egyetem Általános Informatikai Tanszék 1 Az Oracle adatbázis szerkezete 1. témakör Az adatbázis fizikai szerkezete: állományok - adatállományok (táblák, indexek, objektumok,) csak egy táblatérhez tartozhat normál és vezérlő, metaadatok - napló állomány elvégzett tevékenységek listája - vezérlő adatok (leíró adatok az adatbázis elemiről ,eléréséről) - paraméter állományok (működési, futási paraméterek,) - jelszó állomány (user név, jelszó) - mentési állományok Az adatbázis logikai szerkezete: egy adatbázis több táblatérből állhat (tablespace) legnagyobb tárolási egység (azonosító neve van) logikailag összetartozó adatelemeket tartalmaz egy vagy több állományból állhat, de egy állomány csak egy tablespace része Állapota lehet: on-line vagy off-line (kivéve a SYSTEM tablespace) illetve: read-write vagy read-only egy táblatér

több szegmensből állhat azonos tárolási szerkezetű adatok tárolása különböző típusai vannak (a tárolt objektum jellegétől függően) szegmenstípusok: - tábla (nem clusterezett) - cluster tábla - tábla partíció (a particionált tábla esetén minden partíció egy önálló szegmens saját tárolási paraméterekkel) - beágyazott tábla (az N1NF táblák esetén egy mező lehet egy tábla, minden ilyen beágyazott tábla külön szegmens) - LOB (nagy objektum), a LOB értékek külön szegmensben helyezkednek el, a tábla csak egy pointert tartalmaz - LOB index, a LOB adatok gyors eléréséhez - index (normál) - index partíció (particionált index esetén) - index szervezett tábla (IOT), az adatok az index struktúrában, a kulcs mellett foglalnak helyet, nincs szükség alaptáblára. - index szervezett tábla túlcsordulási szegmens, az alapterületen túlcsorduló, hosszú rekordok tárolása 2 - - rollback szegmens temporary szegmens a

részeredmények tárolása (rendezés): ORDER BY CREATE INDEX GROUP BY UNION, INTERSECT, MINUS cache szegmens (adatszótárak, paraméterek) egy szegmens több kiterjesztésből áll (extent) több, egymásután folyamatosan elhelyezkedő blokk együttese folytonos tárterület allokációs egység túl sok extent fregmentációt jelent megadható a maximális darabszáma a megkapott extent nem kerül vissza automatikusan a rendszerhez szegmensek és objektum típusok: table adatszegmens constraint adatszótár index index szegmens index cluster adatszegmens hash cluster adatszegmens view adatszótár sequence adatszótár synonym adatszótár database link adatszótár procedure adatszótár function adatszótár trigger adatszótár snapshot adatszegmens snapshot log adatszegmens egy szegmens több blokkból állhat egy blokk az adatok IO, olvasási, írási egysége rendszerint nagyobb, mint a lemez blokk több objektum adatait is tárolhatja egy blokk blokk szerkezete: - header

(szegmens típusa) - table directory - row directory - free space - row data egy blokk több rekordot is tartalmazhat egy rekord szerkezete: - row header (oszlopok száma, láncolás) - row data: - mező hossza majd 3 - a mező értéke ROWID : rekord helyének azonosítója, közvetett pointere kiterjesztett ROWID alakja: objektumkód:állománykód:blokk-kód:rekord-azonosító 18 karakter hosszú (5:3:5:3) SELECT ROWID FROM tabla . UPDATE tabla WHERE ROWID = . a ROWID tárolódik az indexben is Blokk paraméterek: PCTFREE : blokk területének hány százaléka maradjon üresen módosításkor megnőhetnek a rekordok helyigényei nem szerencsés a rekordokat több blokkra szétosztani ide kerülhetnek a fellépő új adatelemek mérete a tábla dinamikájának jellegétől függ túl nagy : sok felesleges hely túl kicsi : sok töredezett, túlcsordult rekord PCTUSED : a blokk területének hány százalékának betöltése esetén tekinthető a blokk foglaltnak (nem vihető

fel új rekord) nem célszerű kis szabad hely esetén még a szabad blokkok listáján tárolni, mert sok lesz a sikertelen próbálkozás túl kicsi: sok felesleges hely túl nagy : sok felesleges beszúrási próbálkozás INITRANS : a blokkot párhuzamosan kezelhető tranzakciók kezdeti száma a header-ben a tranzakció leíró rész méretét is megszabja MAXTRANS : a blokkot párhuzamosan kezelhető tranzakciók maximális száma a header-ben a tranzakció leíró rész méretét is megszabja Szegmensek tárolási paraméterei: a szegmens első blokkja nem tartalmaz normál adatokat INITIAL : az első extent méretét adja meg adatblokk egységekben adjuk meg túl nagy : felesleges hely maradhat túl kicsi : gyakori extent allokáció, töredezettség NEXT : a későbbi extent-ek méretének kiszámításánál alapul szolgáló méret PCTINCREASE : a soron következő extent méretének százalékos növekedése az előző extent-hez viszonyítva 4 aktuális extent

méretét megadó összefüggés: meret = NEXT * (1 + 0.01 * PCTINCREASE) n-2 célszerű 0-ra állítani MINEXTENTS : kezdetben lefoglalandó extent-ek darabszáma MAXEXTENT: extent-ek maximális száma Adatok optimáliselrendezése (OFA elvek) OFA : Optimal Flexible Architecture alapszabályok: - áttekinthető, rugalmas könyvtár struktúra különböző viselkedésű objektumok külön szegmensbe adatok több eszközre való szétosztása adat szétosztási minta: D1: D2: D3: D4: D5: exe állományok control file redo log SYSTEM tablespace data file TEMPORARY data control file index data control file rolback szegmens export files archive log files Oracle folyamatok struktúrája Folyamatok, programok típusai: - felhasználói folyamat a felhasználó alkalmazása, az SQL kérést elküldő Oracle server folyamat a felhasználó kérést feldolgozó Oracle instance, background folyamatok az általános, közös adatbázis feldolgozó műveletek A folyamatok kapcsolódási

struktúrái: - 5 kombinált felhasználó / server folyamat egy program végzi az el felhasználói interface és SQL feldolgozást - dedikált server minden felhasználóhoz tartozik egy saját Oracle server processz - többszálú szerver (MTS) egy Oracle server processz többfelhasználói programot is kiszolgál - párhuzamos server (OPS) több csomóponton fut egy –egy instance egy közös adatbázis keretében A f elhasználói és server folyamatok rendszerint hálózati szoftveren keresztül kapcsolódnak ORANET, SQLNET külön kliens és szerver oldali komponens létezik verzió függő megoldások lehet lokális és hálózati (központi) név feloldás is A server folyamat jellemzése élete a felhasználói folyamatokhoz kapcsolódik az SQL utasítások feldolgozását végzi munkaterülete a PGA A PGA (Program Global Area) jellemzése osztott memória terület elemei: - rendezési terület az SQL végrehajtáshoz szükséges rendezéseket, segéd

számításokat végzi itt el - session leíró a felhasználói munkakörnyezet paramétereit tárolja - kurzor terület az SQL utasítások adati, műveleti fái - verem terület egyéb adatok tárolása kurzor: egy SQL feldolgozó kontextus Az instance folyamat jellemzése a közös adatkezelési funkciókat végzi el munkaterülete az SGA az SGA és adatbázis adatkapcsolatát a háttérfolyamatokon keresztül végzi Az SGA jellemzése: osztott memória terület elemei: - shared pool SQL utasítások nyilvántartása adatszótár és kurzor adatokat tárol - data buffer feldolgozás alatt álló adatelemek 6 - a blokkok kezelésének alapja az LRU ütemezés redo log area elvégzett műveletek naplója rollback area induló adatállapotok értékei A háttér processzek típusai: 7 - DBWR a módosult adatelemeket írja vissza az adatbázisba aszinkron visszaírás checkpoint : visszaírás indítása - LGWR a napló terület kiírása a napló állományba szinkron a

COMMIT-tal - SMON instance állapot figyelése helyreállítás indítása szükség esetén - PMON server folyamtok figyelése erőforrás felszabadítás szükség esetén - ARCH módosult adatok másolatainak elkészítése naplót is másol - CKPT checkpoint esetén elvégzi az adatbázis elemek adminisztrálását - RECO osztott tranzakciók esetén elvégzi a távoli folyamatok lezárás vezérlését - LOCK osztott használatú adatbázisoknál a zárolások vezérlését végzi - SNP snapshot-ok frissítését végzi Adatbázis létrehozás, paraméterek 2. témakör csak DBA végezheti el - INTERNAL: speciális DBA felhasználó adatbázis létrehozás: CREATE DATABASE anev LOGFILE filenev MAXLOGFILES n DATAFILE filenev MAXDATAFILES n CHARCTER SET t adatbázis indítása: STARTUP módjai: - csak instance : NOMOUNT - karbantartás: MOUNT - normál használat: OPEN dbname PFILE = parameterfile adatbázis leállítás: SHUTDOWN módjai: - normál: NORMAL -

rögtön: IMMEDIATE - azonnali. ABORT konfigurációs állományok: INITnnn.ORA az adatbázis indításához szükséges egy paraméter állomány, mely megadja az aktuális működési paramétereket belső konfigurációs paraméterek is beállíthatók működési paraméterek: - AUDIT TRAIL esemény naplózás engedélye - CONTROL FILES vezérlő állományok megadása - DB BLOCK;BUFFERS data buffer méret - DB BLOCK SIZE data block méret - DB FILES megnyitható file-ok max. száma - DML LOCKS DML zárolások max. száma - DB NAME adatbázis neve - LICENSE MAX USERS max. létrehozható user szám - LICENSE MAX SESSIONS max. élő session darabszám - LOG BUFFER log buffer méret - LOG CHECKPOINT INTERVAL log mentés időintervallum - MAX ROLLBACK SEGMENT rollback szegmens méret - LOG FILES napló állományok 8 - NLS LANGUAGE NLS DATE FORMAT OPTIMIZER MODE OS ROLES PROCESSES OPEN CURSORS száma SQL TRACE nyelv megadása dátum formátum optimalizálási mód engedély az

OS autentikációra processzek száma feldolgozás alatt álló SQL-ek nyomkövetési mód Adatbázis könyvtár struktúra ORACLE HOME BIN ORADATA induló, gyökér könyvtár exe programok adatbázis állományok 2,990,080 CONTROL01.CTL 2,990,080 CONTROL02.CTL 2,990,080 CONTROL03.CTL 20,979,712 DR01.DBF 15,736,832 HINF.ORA 20,979,712 INDX01.DBF 31,473,664 OEM REPOSITORY.ORA 52,436,992 RBS01.DBF 1,049,088 REDO01.LOG 1,049,088 REDO02.LOG 1,049,088 REDO03.LOG 287,318,016 SYSTEM01.DBF 20,979,712 TEMP01.DBF 10,493,952 TOOLS01.DBF 20,979,712 USERS01.DBF tablespace név + SID NETWORK/ADMIN hálózati elemek 861 listener.ora 733 listener0111161PM1105.bak 807 snmp ro.ora 118 snmp rw.ora 224 sqlnet.ora 799 tnsnames.ora DOC dokumentációk RDBMS/ADMIN DBA SQL scriptek több száz sql script, pl . adatbázis létrehozás, PLSQL/ SQLPLUS- 9 termékek kataklógusa Adatbázis objektumok kezelése Tábla Kiterjesztések (extent) lefoglalásának módjai: automatikus : az objektum szabad

helyének betelése esetén manuális: ALTER TABLE tnev ALLOCATE EXTENT (SIZE meret DATAFILE filenv) ha a SIZE paraméter elmarad, a rendszer számolja ki a méretet High Water Mark: jelző, mely megadja, hogy mely a legnagyobb blokksorszám, ahova már valaha került adat értéke INSERT-nél növekedhet értéke DELETE-nél nem csökken Nem használt terület felszabadítása: ALTER TABLE tnev DEALLOCATE UNUSED csak a high water mark feletti területek szabadulhatnak fel figyelembe veszi a MINEXTENTS értéket is maradnak szabad területek a tábla területén Tábla csonkolása törli a tábla összes sorát és felszabadítja a területét TRUNCATE TABLE tnev nem naplózott művelet, nem vonható vissza Több blokkra átnyúló rekordok Migration (sorvándorlás) egy UPDATE parancs megnöveli úgy a rekord méretét, hogy már nem fér el a blokkban a rekord teljes egészében átkerül egy másik blokkba a rekord ROWID-je nem változik a rekordra vonatkozó index bejegyzések is a

régi helyre mutatnak a régi helyen található egy pointer az új helyre nagyon lassítja a DML, DQL utasításokat Chaining (sorláncolás) a rekord eleve nagyon hosszú (LONG mező) a rekord darabok láncolódnak az index az első darabra mutat A sorvándorlás felderítése: ANALYZE TABLE tabla LIST CHAINED ROWS SELECT . FROM chained rows utlchain.sql a tábla generáló script 10 A rekordok kitörlésével, majd újbóli felvitelével szüntethető meg a sorvándorlás Tábla létrehozás parancsa: CREATE TABLE tnev (séma mezőlista) TABLESPACE t1 PCTFREE f1 PCTUSED f2 INITRANS f3 MAXTRANS f4 STORAGE (INITIAL s1 NEXT s2 MINEXETNT s3 MAXEXTENT s4 PCTINCREASE s5) CLUSTER cn (mezo) AS SELECT .; CLUSTER struktúra: az azonos kulcsú rekordok azonos blokkban helyezkednek el 1: CREATE CLUSTER cn1 (kulcstípus) ; 2: CREATE TABLE CLUSTER Cluster típusok: - indexelt - hash Hash cluster: egy hash függvény alapján kerülnek a rekordok szétosztásra létrehozás parancsa: CREATE

CLUSTER knev . HASHKEYS n SIZE m - a HASHKEYS érték adja meg a hash értékek (bucket-ek) darabszámát - a SIZE adja meg az egy bucket-hez tartozó helyigényt Index fontossága: - indexek típusai: - hatékonyság kulcseleme integritási elem is egyben B-fa normál B-fa fordított kulcsú bittérképes a rekord poziciót a ROWID adja meg az index lehet elemi és összetett elemi: egy mező alkotja az indexkulcsot összetett : több mező alkotja az indexkulcsot 11 A B-fa index előnyei: - hatékony - egyenletes elérési idő - jó helykihasználás szülő – gyerek láncolás mindkét irányba csak megfelelő szelektivitás esetén célszerű indexelni nem célszerű túl sok index (DML műveletek lassulnak) indexbejegyzés alakja: mezők száma - mezőhosz1 – érték1 - - értékn - ROWID index létrehozás művelete: CREATE INDEX inev ON paraméterek; t abla (mezo1 ASC| DESC,) tárolási Fordított kulcsú indexek Az indexek felépítésénél az az előnyös, ha

egyenletesen szétszórva helyezkednek el a kulcs értékek. Az Autoincrement mezőknél ez az igény nem teljesül, egymáshoz közeli index értékek jelennek meg az indexértékek szétszórásának ötlete: megfordítani a kulcs értéket nagyobb szórás az intervallumban nem alkalmas intervallum keresésre a tárolási struktúra megegyezik a B-fa szerkezettel létrehozás parancsa: CREATE INDEX inev ON tabla(mezo,,) REVERSE paraméterek; Bittérképes index itt is egy fa épül fel, hasonlóan a B-fához itt a ROWID helyett egy bit sorozat tárolódik a bitsorozat minden bitje egy rekordnak felel meg a bit 1 érteke mutatja, ha a rekordban a mező értéke megegyezik a kulccsal, s a bit 0 értéke esetén a kulcsérték nincs benne a rekordban 12 akkor előnyös, ha - kevés kulcsérték - egy kulcsértékhez sok rekord is társítható - összetett logikai feltétel lehet az egyes kulcsértékekre vonatkozóan pl. WHERE kod = 5 OR kod = 7 Index bejegyzés alakja: mezők

száma, hosz1, érték1, .,értékn, első ROWID, utolsó ROWID, bitlánc csak a szükséges intervallumra korlátozott a bitlánc a kulcsok módosítása igen költség igényes intervallum keresésre nem hatékony létrehozás parancsa: CREATE BITMAP INDEX inev ON tabla(mezo,,) paraméterek; index terület kézi lefoglalása: ALTER INDEX inev ALLOCATE EXTENT () index terület kézi felszbadítása: ALTER INDEX inev DEALLOCATE UNUSED itt is csak high water level feletti területek szabadulnak fel index újra építése: régi indexet felhasználja, gyorsabb művelet, mint újat létrehozni új tárolási paraméterek adhatók meg parancsa: ALTER INDEX inev REBUILD paraméterek Index szervezésű táblák Az adatok ugyanabban a szegmensben vannak, mint az index Az indexbejegyzés a kulcs mellett a rekord többi mezőjét is tartalmazza, s így nincs szükség ROWID értékre sem. Az index objektumhoz kapcsolódik egy túlcsordulási objektum is, mely egy tábla típusú objektum.

létrehozás parancsa: CREATE TABLE tnev () ORGANIZATION INDEX . 13 Minta paraméter állomány ############################################################################## # Example INIT.ORA file # # Use the following table to approximate the SGA size needed for the three scenarious provided in this file: # # -------Installation/Database Size-----# SMALL MEDIUM LARGE # Block 2K 4500K 6800K 17000K # Size 4K 5500K 8800K 21000K # ############################################################################### db name = RBDB1 db files = 1024 # db files = 80 # db files = 400 # db files = 1500 # INITIAL # SMALL # MEDIUM # LARGE control files = ("/u01/oracle/rbdb1/control01.ctl", "/u01/oracle/rbdb1/control02ctl") db file multiblock read count = 8 db block buffers = 8192 shared pool size = 15728640 # INITIAL # INITIAL # INITIAL log checkpoint interval = 10000 log checkpoint timeout = 1800 processes = 59 parallel max servers = 5 log buffer = 32768 # INITIAL #

SMALL # INITIAL audit trail = true # if you want auditing timed statistics = true # if you want timed statistics max dump file size = 10240 # limit trace file size to 5M each log archive start = true # log archive dest 1 = "location=/u01/oracle/rbdb1/archive" # log archive format = "%%RBDB1%%T%TS%S.ARC" # If using private rollback segments, place lines of the following # form in each of your instance-specific init.ora files: rollback segments = (rb1, rb2, rb3, rb4) # transactions = 40 # transactions per rollback segment = 5 # Global Naming -- enforce that a dblink has same name as the db it connects to global names = true 14 Adatok védelme, felhasználók karbantartása 3. témakör DAC alapú védelmi modell felhasználók és objektumok szerepkörökkel kibővített Felhasználó karbantartása: CREATE USER unev IDENTIFIED BY pwd | EXTERNALLY DEFAULT TABLESPACE ff TEMPORARY TABLESPACE ff QUOTA xx ON ff PROFILE ff ALTER USER . DROP USER A felhasználó

azonosítása: - belső - OS objektumok alapértelmezési helye: DEFAULT TABLESPACE munkaterület: TEMPORARY TABLESPACE használható hely mérete: QUOTA lehet UNLIMITED is A felhasználóhoz tartozó erőforrások korlátjait legjobban a PROFILE mechanizmus fogja össze Profile erőforrás használati limitek együttese elemei: - SESSION PER USER max session szám - CPU PER SESSION egy kapcsolat max. CPU - CPU PER CALL egy parancs max CPU - CONNECT TIME kapcsolat max ideje - IDLE TIME max. üresjárati idő - LOGICAL READ PER SESSION max IO blokk kapcsolatra - LOGICAL READ PER CALL max IO blokk parancsra - COMPOSIT LIMIT max műveleti összköltség létrehozása: CREATE PROFILE pnev LIMIT paraméterek módosítása: ALTER PROFILE pnev LIMIT paraméterek 15 Létezik egy default PROFILE objektum is A felhasználók a létrehozás után semmilyen joggal nem rendelkeznek. Egyedi jogosultság adása: GRANT muv ON obj TO felh WITH GRANT OPTION REVOKE muv ON obj FROM felh jog: -

objektum jog rendszer privilégium GRANT jog TO felh WITH ADMIN OPTION GRANT RESOURCE meret ON tablaspace TO felh Szerepkörök használata: CREATE ROLE rnev IDENTIFIED BY pwd típusa: - default nem default SET ROLE TO IDENTIFIED BY pwd ALTER USER DEFAULT ROLE . Előre definiált szerepkörök. - CONNECT RESOURCE DBA EXP FULL DATABASE IMP FULL DATABASE Felhasználók tevékenységeinek nyomon követése AUDIT funkció, célja: - gyanús események figyelése - statisztikák készítése típusai: - utasítás szintű: SQL parancsok figyelése privilégium: privilégiumok figyelése objektum: objektumok használatának figyelése lehetőségek: - sikeres hozzáférések naplózása - sikertelen hozzáférések naplózása 16 - session szintű naplózás parancs szintű naplózás le lehet szűkíteni a figyelt objektumok és figyelt felhasználók körét parancsa: AUDIT sql ON o bj BY SESSION | ACCESS WHENEVER NOT SUCCESFUL AUDIT privilégium BY SESSION | ACCESS WHENEVER

NOT SUCCESFUL NOAUDIT . Ügyelni kell az AUDIT TRAIL paraméter beállítására A működése igen erőforrás, helyigényes Lista olvasása: AUD$ tábla és arra épülő nézeti táblák Fontosabb információs táblák Az adatok SYS tulajdonú rejtett táblákban foglalnak helyet még a DBA sem érintheti őket (kivéve AUD) A külvilág nézeti táblákon keresztül láthatja: CREATE VIEW CREATE GLOBAL SYNONYM százas nagyságrendű nézeti táblaszám DBA * USER * ALL * DBA szintű felhasználó szintű felhasználói nézetek egyesítése Védelemhez kapcsolódó táblák - DBA USERS - DBA TAB GRANTS - DBA COL PRIVS - DBA AUDIT CONNECT - DBA AUDIT SESSION 17 - DBA AUDIT OBJECTS - DBA AUDIT TRAIL - DBA TS QUOTAS - DBA PROFILES - DBA PROFILES - DBA ROLES - DBA ROLE PRIVES - DBA SYS PRIVES Adatbázis objektumok - DBA TABLES - DBA TAB COLUMS - DBA VIEWS - DBA CONSTRAINTS - DBA OBJECTS - DBA SOURCE - DBA TRIGGERS - DBA CLUSTERS - DBA INDEXES Állomány kezelés - DBA DATA

FILES - DBA TABLESPACES - DBA FREE SPACE - DBA EXTENTS -DBA TS QUOTAS - DBA SEGMENTS 18 Egyéb információk - DBA DDL LOCKS - DBA DML LOCKS - DBA LOCKS - DBA WAITERS Dinamikus információk: - V$SQLAREA - V$SGASTAT - V$SESSION - V$PARAMETER - V$OPEN CURSOR - V$LOG - V$FILESTAT - V$LOCK Speciális SQLPlus elemek DEFINE var = szöveg VARIABLE var NUMBER | CHAR(n) ACCEPT var PROMPT szöveg HIDE &var &1 SPOOL filenév SPOOL OFF COLUMN oszlop FORMAT fff HEADING szöveg WRAPPED TRUNCATED PRINT | NOPRINT NEW VALUE valt BREAK ON exp SKIP n | PAGE 19 | COMPUTE AVG | COU OF mező ON exp TITLE LEFT|CENTRE szöveg SET PAGESIZE nn SET HEADING ON | OFF SET VERIFY ON | OFF SET FEEDBACK ON | OFF minta set verify off set feedback off set heading off set pagesize 0 def uname = &&1 def fname = &&2 spool &fname select ‘set echo on’ from dual; select ‘drop ‘|| object type || ‘ ‘ || owner || ‘.’ || object name || ‘;’ from dba objects where object

type not in (‘INDEX’)) and (owner = upper(‘&uname’)); select ‘set echo off’ from dual; spool off set newpage 1 select ‘Objektumok torlese: ‘ from dual; select ‘1. ellenorizze a &fname filet’ from dual; select ‘2. SQL> start &fname’ from dual; select ‘3. torolje &fname-t’ from dual; 20 4. témakör Oracle 8 – NT kezelő felület Installáció menete Beépített extra elemek: Java VM SQLJ CORBA COM Platform: Win95 és 98 csak kliens, többi lehet szerver is Installációs eszköz: Oracle Universal Installer GUI WEB-es installáció Választható konfigurációk: Oracle8i Enterprise Edition (starter database, networking services, Oracle Utilities, Oracle Intelligent Agent, Oracle Enterprise Manager Console, Oracle Management Server, Oracle HTTP Server Apache) Oracle8i Personal Edition Oracle8i Client Orcale8i Management Hardware követelmények: 96 MB RAM (256 MB ajánlott) Pentium 233 processzor 1.9 GB hard disk Installációs

lépések 1. ablak: installáció forráshelye ORACLE HOME logikai név ORACLE HOME elérési útvonal 2. ablak: konfiguráció kiválasztás Enterprise, Personal, client 3. ablak: installáció típusa typical, minimal, custom Default felhasználók az adatbázisban: INTERNAL / ORACLE adminisztráció 21 instance indítás, leállítás, DB SYTEM/ MANAGER DBA feladatok SYS / CHANGE ON INSTALL DB tulajdonos SCOTT / TIGER minta felhasználó OUTLN / OUTLN QEP manager, karbantartó DBSNMP / DBSNMP SNMP manager MDSYS / MDSYS interMedia adminisztrátor Globális adatbázis azonosító = DB név. Domain név = DB NAME.DB DOMAIN (init.ora) SID = instance azonosító DB állományok helye: ORACLE BASEORADATADB NAME*.DBF Paraméter állomány helye: ORACLE BASEADMDB NAMEPFILEINIT.ORA LOG állomány ORACLE BASEORADATADB NAMEREDO01.LOG Controll állomány ORACLE BASEORADATADB NAMECONTROL01.CTL Default tablespace elemek: SYSTEM SYSTEM01.DBF USERS USERS01.DBF TEMP TEMP01.DBF RBS

RBS01.DBF INDX INDX01.DBF TOOLS TOOLS01.DBF Enterprise Manager Modul Az EMM egy 3-rétegű struktúrán működik Megjelenítés – alkalmazási logika - adatbázisok EMM felületei: Console Management Server Common Service DBA Management Pack Console GUI felület DBA Adminsztrátori funkciók biztosítása Események, job, alert kezelés 22 Management Server Közbenső réteg, a consol igényeit közvetíti, dolgozza fel Common Services: A biztosított szolgáltatások rendszere - Repository : adatszótár, a DB objektumok paraméterei, beállításai - Service Discovery : szolgáltatások, DB helyek automatikus felismerése 23 - Job Scheduling System : munkakötegek kezelése - Event Management System : események kezelése - Notification System and Filtering : üzenetek küldése - Paging/Email Blackouts : üzenetküldési funkciók karbantartása - Security : védelem - Generate an Enterprise Report : jelentés generálás - Font Control : betűkészlet

kezelő DBA Management Pack : napi DBA munkát segítő rutinok gyűjteménye A Console modul paneljai - Navigator Group Jobs Events Navigator: Objektum hierarchia az objektumhoz kapcsolódó kezelő funkciók megvalósítására Group: objektumok csoportba foglalása azonos DBA műveletekhez Jobs: a munkakötegek ütemezési ablaka Működési lépések: Job létrehozás (submit) A job elküldésre kerül a végrehajtó Intelligent Agentekhez Az Intelligent Agent a megadott időben lefuttatja a jobot Az Agent értesítést küld vissza a végrehajtás státuszáról Job lépések: - Anaylize - Backup - Export - Import - Load - Recovery 24 - Dba script futtatás Sqlplus scrip futtatás Shutdown database Startup database Events: adatbázis események kezelése Működési lépések: Események definiálása (tesztek, határértékek) Az események elküldése az ellenőrző Intelligent Agent-hez Az Intelligent Agent futtatja a tesztet végző szolgáltatást, s ellenőrzi az

eredményt Események (potenciális hibák) észlelése Az Intelligent Agent riasztja az Oracle Management Server-t Az eseményhez kötött kezelők értesítése A probléma kijavításának elkezdése A DBA Management Pack elemei - Instance Management Schema Management Security Management Storage Management Replication Management JServer Management Cache Management SQL*Plus Worksheet Instance Management funkciók: - Adatbázis indítás, leállítás - Inicializációs paraméterek kezelése (beállítás, lekérdezés) - aktuális SQL parancsok és QEP terveik lekérdezése - erőforrások allokációjának kezelése - Bejelentkezések kezelése - Tranzakciók kezelése Schema Management funkciók Adatbázis objektumok kezelése - Létrehozás - Megszüntetés - Lekérdezés - Módosítás 25 A csomaghoz számos kiegészítő segédprogram is kapcsolódik: Oracle Diagnostic Pack Oracle Tuning Pack Oracle Expert Oracle SQL Analyze 26 PL/SQL gyári csomagok 5. témakör

Package (csomag) használata Tárolt eljárás és függvény CREATE OR REPLACE PROCEDURE enev (p1 IN|OUT tip,.) AS PLSQL-blokk CREATE OR REPLACE FUNCTION enev (p1 IN|OUT tip,.) RETURN tip AS PLSQL-blokk Előnyei: - központilag tárolt az adatbázisban, de többen is használhatják egységességet biztosít nagyobb hatékonyság, mint az alkalmazásbeli SQL gyorsabb alkalmazás fejlesztés nagyobb védelem, szabályozható hozzáférés Egyéb kezelő elemek: DROP PROCEDURE / FUNCTION DBA SOURCE információs view Csomag (package) Logikailag összetartozó tárolt eljárások, függvények és változók együttese Egységként töltődik be a memóriába Egyidejűleg többen is használhatják A csomagok LRU stratégiával tárolódnak Package szerkezete: - definiciós rész (interface megadása) - törzs rész (elemek részletes leírása) Private elemek: olyan eleme, mely csak a törzs részben szerepel, a definíciós részben nem Public elemek: szerepel a definíciós,

interface részben Package létrehozása: 1. definíciós rész megadása 2. törzs megadása Kezelő parancsok: CREATE PACKAGE csnev AS PL-SQL definíciók END csnev 27 CREATE PACKAGE BODY csnev AS PL/SQL törzs END csnev DROP PACKAGE csnev CREATE PACKAGE proba AS FUNCTION f1 (a IN CHAR) RETURN NUMBER; PROCEDURE p1 (a IN NUMBER, b OUT NUMBER) END proba; CREATE PACKAGE BODY proba AS FUNCTION f1 (a IN CHAR) RETURN NUMBER AS BEGIN RETURN a + 1; END; PROCEDURE p1 (a IN NUMBER, b OUT NUMBER) BEGIN . END; END proba; Lehet változót is megadni csomag elemként Hivatkozás az elemekre: Package név.elem nev Gyári csomagok alkalmazása A gyári csomagok adatbázisba való elkészítésére gyárilag adott SQL scriptek szolgálnak Ezeket rendszerint a SYS usernek kell elindítani Több tucat gyári package létezik A legfontosabb package-ek: 28 - DBMS ALERT DBMS DDL DBMS DEBUG DBMS DEFER procedure - DBMS IOT - DBMS JOB DBMS LOB DBMS LOCK DBMS LOGMNR események, riasztások

kezelése DDL funkciók meghívását teszi lehetővé debug kezelő replicated transactional deferred remote call segédtábla létrehozása a láncolt rekordok lekérdezéséhez munkaköteg kezelő rutinok LOB kezelő rutinok zárolás kezelés napló kelezés - DBMS OLAP OLAP funkció kezelés DBMS OUTPUT üzenet bufferelés, kiírás DBMS PIPE pipe kezelő DBMS RANDOM véletlen szám generátor DBMS RESOURCE MANAGER erőforrás, QEP kezelő DBMS ROWID ROWID kezelő DBMS SESSION bejelentkezések kezelése DBMS SNAPSHOT snapshot kezelő DBMS SPACE segment kezelő DBMS SQL dinamikus SQL DBMS TRACE PL/SQL trace kezelő DBMS UTILITY segéd rutinok UTL FILE állomány kezelő rutinok UTL HTTP http hívások kezelése UTL SMTP levél küldés kezelése UTL TCP alap TCP szolgáltatások köre Néhány csomag elemeinek ismertetése DBMS JOB SUBMIT Procedure új munkaköteg létrehozása REMOVE Procedure munkaköteg megszüntetése CHANGE Procedure munkaköteg paraméterek

változtatása NEXT DATE Procedure következő futtatási időpont beállítása INTERVAL Procedure futtatások közötti időpont beállítása BROKEN Procedure munkaköteg letiltása RUN Procedure munkaköteg futtatása VARIABLE jobno number; BEGIN DBMS JOB.SUBMIT(:jobno, dbms ddlanalyze object(TABLE, DQUON, ACCOUNTS, ESTIMATE, NULL, 50); SYSDATE, SYSDATE + 1); commit; END; DBMS OUTPUT Az eljárás végén írja ki az üzenetet a képernyőre 29 PLSQL: SET SERVEROUTPUT ON ENABLE Procedure üzenet kiírás engedélyezés DISABLE Procedure üzenet kiírás letiltás PUT and PUT LINE Procedures sor kiírása a bufferbe NEW LINE Procedure sor lezására GET LINE and GET LINES Procedures sorok kiolvasása a bufferből Példa CREATE FUNCTION dept salary (dnum NUMBER) RETURN NUMBER IS CURSOR emp cursor IS SELECT sal, comm FROM emp WHERE deptno = dnum; total wages NUMBER(11, 2) := 0; counter NUMBER(10) := 1; BEGIN FOR emp record IN emp cursor LOOP emp record.comm :=

NVL(emp recordcomm, 0); total wages := total wages + emp record.sal + emp record.comm; DBMS OUTPUT.PUT LINE(Loop number = || counter || ; Wages = || TO CHAR(total wages)); /* Debug line / counter := counter + 1; /* Increment debug counter / END LOOP; DBMS OUTPUT.PUT LINE(Total wages = || TO CHAR(total wages)); RETURN total wages; END dept salary; futtatás SET SERVEROUTPUT ON VARIABLE salary NUMBER; EXECUTE :salary := dept salary(20); Eredmény Loop number = 1; Wages = 2000 Loop number = 2; Wages = 3250 Total wages = 3250 PL/SQL procedure successfully executed. UTL FILE FOPEN Function 30 file megnyitása IS OPEN Function nyitott-e a file? FCLOSE Procedure file lezására FCLOSE ALL Procedure minden file zására GET LINE Procedure sor olvasása PUT Procedure egy sor kiírása NEW LINE Procedure sorvégjel kiírása PUT LINE Procedure FFLUSH Procedure sor kiírás sorvéggel buffer ürítése kiírással FOPEN Function A megnyitandó állománynak csak előre

megadott könyvtárban szabad elhelyezkednie védelmi okok miatt, máshol lévő állományok nem elérhetők Az elérhető könyvtár megadása az INIT.ORA állományban: UTL FILE DIR = <directory name> DBMS SQL (input) OPEN CURSOR Function új kurzor nyitása SQL parancshoz PARSE Procedure az SQL parancs értelmezése BIND VARIABLE and BIND ARRAY Procedures DEFINE ARRAY Procedure (output) fogadó tömb definiálás a változóhoz EXECUTE Function kurzor futtatása FETCH ROWS Function sor beolvasása a kurzorból COLUMN VALUE Procedure beilvasott sor mező értékének lekérdezése CLOSE CURSOR Procedure kurzor lezárás LAST ROW COUNT Function beolvasott sorok száma Példa 31 változó kötése CREATE OR REPLACE PROCEDURE demo(salary IN NUMBER) AS cursor name INTEGER; rows processed INTEGER; BEGIN cursor name := DBMS SQL.OPEN CURSOR; DBMS SQL.PARSE(cursor name, DELETE FROM emp WHERE sal > :x, dbms sql.native); DBMS SQL.BIND VARIABLE(cursor name,

:x, salary); rows processed := DBMS SQL.EXECUTE(cursor name); DBMS SQL.CLOSE CURSOR(cursor name); EXCEPTION WHEN OTHERS THEN DBMS SQL.CLOSE CURSOR(cursor name); END; create or replace procedure single Row update (c1 number, c2 number, r out number) is c number; n number; begin c := dbms sql.open cursor; dbms sql.parse(c, update tab set c1 = :bnd1, c2 = :bnd2 ||where rownum < 2 || returning c1*c2 into :bnd3, 2); dbms sql.bind variable(c, bnd1, c1); dbms sql.bind variable(c, bnd2, c2); dbms sql.bind variable(c, bnd3, r); n := dbms sql.execute(c); dbms sql.variable value(c, bnd3, r);-- get value of outbind variable dbms Sql.close Cursor(c); end; declare begin 32 c number; d number; n tab dbms sql.Number Table; indx number := -10; c := dbms sql.open cursor; dbms sql.parse(c, select n from t order by 1, dbms sql); dbms sql.define array(c, 1, n tab, 10, indx); d := dbms sql.execute(c); loop d := dbms sql.fetch rows(c); dbms sql.column value(c, 1, n tab); exit when d != 10; / 33

end loop; dbms sql.close cursor(c); exception when others then if dbms sql.is open(c) then dbms sql.close cursor(c); end if; raise; end; Az Oracle speciális objektumai 6. témakör Particionált táblák / indexek Particionálás: a tábla / index rekordjainak szétbontása csoportokra Típusai: Tartomány alapú (range) : a rekordokat a kulcs alapján ossza szét. Az egyes kulcs érték tartományok külön partícióba kerülnek Hash alapú: egy egyenletesebb elosztást biztosító hash függvény alapján rendel a különböző kulcs értékekhez egy partíciót a rendszer Vegyes módszer (composite partitioning) : előbb tartomány alapú szétválogatás, majd egy hash alapú finomabb szétbontás Az egyes partíciók azonos logikai paraméterűek (pl. azonos kulcs mező, azonos indexmező), de különböző fizikai tárolási paraméterrel rendelkezhetnek. A különböző partíciók különböző szegmensekben helyezkednek el A különböző partíciókat igény szerint

különböző tablespace egységekbe is el lehet helyezni. Ennek előnyei: - nagyobb védelem az adatvesztés ellen - külön lementhetők az egyes partíciók - különböző lemez egységekhez rendelhetők, hatékonyság növelést hozva Particionálás előnyei: - az egyes partíciók bizonyos esetekben kihagyhatók a feldolgozásból pl. SELECT FROM T WHERE m > 4 AND m < 8 ha a particiók az m értéke alapján készültek és tartomány alapú, egyes partíciók kihagyhatók a kereséséből, mert az ott lévő elemekre biztos nem teljesül a feltétel. Speciális esete a szelekció gyorsításnak az, amikor egy VLDB-ben historical (történeti) adatokat kell tárolni Az egy nagy normál tábla helyett a partícionált táblákban a különböző időszakokhoz tartozó adatokat külön lehet választani. Ez hatékonyabb tábla kezelést jelent főleg ha csak bizonyos időszak adatait kell érinteni. - meggyorsíthatja a join végrehajtását ha mindkét tábla azonos módon

partícionált, akkor egy equi-join esetében az összehasonlítást nem kell minden rekord párra elvégezni, hanem csak az azonos partícióban elhelyezkedő párokra - karbantartási munkák gyorsítása: ha az egyes tábla karbantartó feladatok (load, indexelés, mentés) nem a teljes táblára, ha külön az egyes partíciókra is értelmezhetők, akkor 34 elegendő csak bizonyos partíciók kezelése esetleg párhuzamos végrehajtása (partíciók függetlenségének elve) Disk striping és partioning: Hatékonyság és rendelkezésre állás egyensúlya kell Ha minden partíció ugyanazon diszkekre szétosztott (striping) : gyors de sérülékeny Partitioning View: Kézi megoldás, több önálló tábla létrehozása (mintha ezek lennének a partíciók, majd egy view ezen táblák UNION-jával adja az eredő táblát) A hash partícionálás akkor jó, ha - nem ismert előre a kulcs eloszlás - fontos a particonált join hatékony végrehajtása Leíró táblák: DBA TAB

PARTITIONS DBA TAB SUBPARTITIONS DBA IND PARTITIONS DBA IND SUBPARTITIONS DBA PART COL STATISTICS A partícionált táblák esetében csak költség alapú művelet optimalizálás él. Utasítás: CREATE TABLE sales ( invoice no NUMBER, sale year INT NOT NULL, sale month INT NOT NULL, sale day INT NOT NULL ) PARTITION BY RANGE (sale year, sale month, sale day) ( PARTITION sales q1 VALUES LESS THAN (1997, 04, 01) TABLESPACE tsa, PARTITION sales q2 VALUES LESS THAN (1997, 07, 01) TABLESPACE tsb, PARTITION sales q3 VALUES LESS THAN (1997, 10, 01) TABLESPACE tsc, PARTITION sales q4 VALUES LESS THAN (1998, 01, 01) TABLESPACE tsd ); CREATE TABLE product( . ) STORAGE (INITIAL 10M) PARTITION BY HASH(column list) ( 35 ); PARTITION p1 TABLESPACE h1, PARTITION p2 TABLESPACE h2 CREATE TABLE orders( ordid NUMBER, orderdate DATE, productid NUMBER, quantity NUMBER) PARTITION BY RANGE(orderdate) SUBPARTITION BY HASH(productid) SUBPARTITIONS 8 STORE IN(ts1,ts2,ts3,ts4,ts5,ts6,ts7,ts8) (

PARTITION q1 VALUES LESS THAN(01-APR-1998), PARTITION q2 VALUES LESS THAN(01-JUL-1998), PARTITION q3 VALUES LESS THAN(01-OCT-1998), PARTITION q4 VALUES LESS THAN(MAXVALUE) ); A partíciókra való közvetlen hivatkozás formátuma: ALTER TABLE admin.patient visits DROP PARTITION pv dec92; SELECT * FROM sales PARTITION (s nov97) s WHERE s.amount of sale > 1000; Egy tábla csak akkor partícionálható, ha nincs cluster-ben és nincs LONG mezője A DBMS külön zárolási szintet hoz létre: Row lock Partition lock Table lock LOB LOB : Large Objects A nem strukturált adatok (zene, kép, hang, ) tárolására szolgál. Típusai: - adatbázisban tárolt külső állományban tárolt (BFILE) a 4K alatti LOB értékek a táblában tárolódnak, felette pedig egy külön tablespace-be, segment-be kerülnek LOB előnyei: - nagy méret (4GB) - egy táblában több mező is lehet LOB típusú 36 LOB mező típusok: BLOB CLOB NCLOB BFILE binary data character data national character

data külső file-ban tárolt adat (csak olvasható) A CLOB/NCLOB mezők tartalma UNICODE-ban tárolódik LOB locator: a LOB objektum tárolási helyét megadó érték Lehet external és internal A LOB objektumok kezelését függvények, csomagok segítik: INSERT INTO Multimedia tab VALUES (101, JFK interview, EMPTY CLOB(), NULL, EMPTY BLOB(), EMPTY BLOB(), NULL, NULL, BFILENAME(AUDIO DIR, JFK interview), NULL); DECLARE Image1 BLOB; ImageNum INTEGER := 101; BEGIN SELECT story INTO Image1 FROM Multimedia tab WHERE clip id = ImageNum; DBMS OUTPUT.PUT LINE(Size of the Image is: || DBMS LOB.GETLENGTH(Image1)); END; A LOB induló értéke lehet: - NULL: nincs locator - Empty (üres): van locator - érték INSERT INTO Multimedia tab VALUES (1001, EMPTY CLOB(), EMPTY CLOB(), NULL, EMPTY BLOB(), EMPTY BLOB(), NULL, NULL, NULL, NULL); PL/SQL interface a LOB kezelésére A DBMS LOB csomag rutinjait kell használni Csak a szerver oldali rutinok használhatják A hivatkozott elemekhez kell

létezni LOB locator elemnek Kezelő függvények: OPEN() 37 megnyitja a LOB elemet DBMS LOB.OPEN(locator, mód) A mód lehet írás vagy csak olvasás CLOSE() lezárja a LOB elemet COMPARE() két LOB elem összehasonlítása DBMS LOB.COMPARE(locator1, locator2, meret, offset1, offset2) GETLENGTH() LOB elem hosszát adja vissza INSTR() mintát keres a LOB-ban READ() LOB elem beolvasása DBMS LOB.READ(locator, meret, offset, buffer) SUBSTR() LOB részlet beolvasása APPEND() egyik LOB elem hozzáfűzése másik LOB elemhez ERASE() LOB elemből törlés LOADFROMFILE() BFILE tartalmát betölti belső LOB-ba DBMS LOB.LOADFROMFILE(céllocator, forráslocator,meret, offset1, offset2) WRITE() LOB tartalom írása DBMS LOB.WRITE(locator, meret, offset, buffer) FILEOPEN() BFILE nyitása FILECLOSE() BFILE zárása CREATE OR REPLACE PROCEDURE Example l2f IS lobd BLOB; fils BFILE := BFILENAME(SOME DIR OBJ,file specifikáció); amt INTEGER := 4000; BEGIN SELECT b lob

INTO lobd FROM lob table WHERE key value = 42 FOR UPDATE; dbms lob.fileopen(fils, dbms lobfile readonly); dbms lob.loadfromfile(lobd, fils, amt); COMMIT; dbms lob.fileclose(fils); END; CREATE OR REPLACE PROCEDURE Example2a IS lob 1, lob 2 BLOB; retval INTEGER; BEGIN 38 45; 54; END; SELECT b col INTO lob 1 FROM lob table WHERE key value = SELECT b col INTO lob 2 FROM lob table WHERE key value = retval := dbms lob.compare(lob 1, lob 2, 5600, 33482, 128); IF retval = 0 THEN . ELSE END IF; CREATE OR REPLACE PROCEDURE Example 13a IS src lob BLOB; buffer RAW(32767); amt BINARY INTEGER := 32767; pos INTEGER := 2147483647; BEGIN SELECT b col INTO src lob FROM lob table WHERE key value = 21; LOOP dbms lob.read (src lob, amt, pos, buffer); pos := pos + amt; END LOOP; EXCEPTION WHEN NO DATA FOUND THEN dbms output.put line(End of data); END; OO alapú kiegészítések Az Oracle ORDBMS lehetőséget ad objektumok definiálására (oracle objects) Új adatbázis elemek: Objektum Objektum =

név + tulajdonságok + metódusok Konstruktor: az a metódus, melynek neve megegyezik az objektumtípus nevével Objektum tábla: olyan tábla, melynek egy sora egy objektumot reprezentál Objektum view: relációs táblák feletti OO nézetet szolgáltató view REF: pointer adattípus, mely objektumra mutat - scopped: csak ez típusra mutathat - dangling : nem élő Kollekciók : új, összetett szerkezetű struktúrák: 39 - VARRAY tömb struktúra NESTED TABLE : N1NF tábla Öröklés: az objektum típusok között értelmezett Parancsok: Objektum létrehozás: CREATE TYPE tnev AS OBJECT (szerkezet); CREAT TYPE BODY tnev AS ( MEMBER PROCEDURE pnev IS PL/SQL törzs MEMBER FUNCTION fnev RETURN tip IS PL/SQL törzs END; CREATE TYPE person AS OBJECT ( name VARCHAR2(30), phone VARCHAR2(20) ); CREATE TYPE xx AS OBJECT ( id NUMBER, contact person, lineitems lineitem table, MEMBER FUNCTION yy RETURN NUMBER ); CREATE TYPE BODY xx AS MEMBER PROCEDURE yy IS gcd NUMBER; BEGIN numerator

:= numerator/gcd; denominator := denominator/gcd; END; END; Objektum tábla létrehozás CREATE TABLE tnev OF otip; CREATE TABLE person table OF person; INSERT INTO person table VALUES ("John Smith","1-800-555" ); SELECT VALUE(p) FROM person table p WHERE p.name = "John Smith"; Hivatkozás típusa: REF 40 CREATE TYPE person AS OBJECT ( name VARCHAR2(30), manager REF person ); SELECT REF(po) INTO OrderRef FROM purchase order table po WHERE po.id = 1000376; Tömb létrehozás CREATE TYPE tnev AS VARRAY OF tipus CREATE TYPE prices AS VARRAY(10) OF NUMBER(12,2); N1NF tábla létrehozás CREATE TYPE tnev AS TABLE OF tipus CREATE TABLE purchase order table OF purchase order NESTED TABLE lineitems STORE AS lineitems table; 41 Oracle teljesítménynövelés és segédrutinok 7. témakör Teljesítmény növelés A felmérések alapján a gyenge teljesítmény okai: OS 2.5% RDBMS 17.5% Alkalmazás 60% DB Tervezés 20% A helyreállítási költségek: OS

5% RDBMS 15% Alkalmazás 15% DB tervezés 65% Biztosítani kell már a tervezés során azt, hogy az alkalmazásoknál a válaszidők OLTP esetében az elvárt 2 sec-on belül legyenek Szokásos hatékonyság javító lépések: 1. adatmodell de-normalizáció - több értékű mezők bevonása a táblába - kódok helyet teljes érték - részösszegek tárolása - mesterséges kulcsok alkalmazása 2. FOREIGN KEY használata készítsünk index-et az idegen kulcs mezőhöz is a kulcs megszűnése zárolja a hivatkozást 3. SQL parancsok szabványos formában adjuk meg a parancsokat, hogy az RDBMS fel tudja ismerni őket. kétfázisú végrehajtás beágyazott SQL-ben használjuk a COST alapú optimalizálást, futtassuk az ANALYZE TABLE tnev COMPUTE STATISTIC ANALYZE TABLE tnev ESTIMATE STATISTIC ANALYZE TABLE tnev DELETE STATISTIC ANALYZE TABLE tnev VALIDATE ANALYZE INDEX ANALYZE CLUSTER parancsot ALTER SESSION SET OPTIMIZER MODE = RULE | ALL ROWS | FIRST ROWS 4. join-nál

ügyeljünk a táblák megadási sorrendjére: FROM A,B nem ugyanaz mint FROM B.,A 42 tábla alias használata javasolt a nagyobb méretű tábla neve szerepeljen előbb az AND –nél a legutolsó feltételt értékeli ki elsőként az OR –nál a legelső feltételt értékeli ki elsőként ha lehet használjunk ROWID-t he lehet használjunk DECODE DECODE (kif, e1, k1, e2,k2,, kv) indexet csak a teljes mezőre vonatkozó feltételnél tud használni 5. optimalizálás kézi szabályozása: SELECT /* direktíva / . FROM Ismétlődő rekordok törlése: DELET FROM tabla A WHERE A.rowid > (SELECT MIN(Browid) FROM tabla B WHERE A.id = Bid) Export / Import segédprogram export: adatbázis egyes szeleteinek kiemelése más formátumú leírásba import: más forrásból adatok beépítése az adatbázisba Saját specifikus Oracle formátumot használ célja Oracle RDBMS-ek közötti adatmozgatás megvalósítása export módok: - TABLE - USER - FULL megadott táblák megadott

felhasználók adatai teljes adatbázis EXP user/passwd PARFILE=pfile Az export paraméterei egy szöveges paraméterfile-ban adottak paraméterek: - FILE= eredmény file - FULL = Y/N - TABLES = lista - OWNER = lista - ROWS = Y/N (adatokat is átvigye-e) - INDEXES = Y/N (indexek is átvigye-e) - GRANTS = Y/N (jogokat is átvigye-e) - CONSTRAINTS = Y/N (megkötéseket is átvigye-e) 43 Importálás: IMP user/passwd PARFILE=pfile paraméterek: - FILE = forrás file - SHOW = Y/N csak megjeleníti a tartalmat, de nem végez átirást - TABLES = lista - ROWS = Y/N - TOUSER = felhasználó - . Backup és recovery Backup: A DB állapot lementése Recovery: DB hibák helyrehozása, a DB korábbi lementésének viszatöltése DBS hibák típusai - felhasználói (rossz parancs) - parancs feldolgozási hiba - user processz hiba - instance hiba - disk hiba Helyreállításhoz használt adatforrások: - REDO LOG állomány (az on-line redo log állományokat az LGWR folyamatosan írja,

használatuk ciklikusan történik) - Archivált állományok - Control file - Rolback szegmensek Helyreállítás alatt lehet - rolling back - rolling forward A backup a disk tartalmát menti le Mentés típusai: - teljes (az adatbázis lezárt, nem használható) - részleges - inkrementális (csak az utolsó módosítás utáni adatok íródnak ki) - kommulatív - nyitott (nyitott adatbázis melletti) - konzisztens - inkonzisztens A kommulatív módban az előző inkrementális mentések együttes hatása fog letárolódni, így egyszerűbb lesz a mentések kezelése Recovery Manager 44 A mentések és helyreállítások karbantartását végzi A ide vonatkozó információkat egy recovery catalog-ban tárolja. A katalógus tartalma: - mikor, mi és hogyan lett lementve - hol vannak a másolatok - a log mentések adatai - lementett adatbázis sémája - mentési rutinok Adatbázis archiválási mód: - NOARCHIVELOG : nem végez lezárt napló mentéseket, a betelt log file

rögtön felülíródik. Csak az instance helyreállításában használható, disk hiba ellen nem véd - ARCHIVELOG : naplók folyamatos mentése is megtörténik, az aktuális log file lementésre kerül mielőtt felülíródna ARCn : háttér processz a naplók mentésére Részleges mentési módok: - datafile mentés - control file mentés - tablespace mentés konzisztens mentés: minden adatfile egy időponra (SCN) igazított inkonzisztens mentés: az egyes adatfileok különböző időpontokra (SCN) igazítottak 45 Backup parancsok Az RMAN programmon keresztül: BACKUP FULL | INCREMENTAL FORMAT . | CUMULATIVE specifikáció példák: allocate channel dev1 type SBT TAPE; backup database; backup current controlfile; allocate channel dev1 type disk; allocate channel dev2 type disk; backup (tablespace system,sales1,sales2,sales3 filesperset 20 skip readonly) (datafile 12, 14, 15); allocate channel dev1 type sbt tape; backup incremental level 2 cumulative skip inaccessible

database; A helyreállításnál megadott időpontra vonatkozólag is lehet helyreállítani az adatbázist RECOVER DATABASE RECOVER TABLESPACE. RECOVER DATAFILE UNTIL időpont Standby database: Készenléti adatbázis. A fő adatbázis sérülése esetén venné át a fő adatbázis szerepet. A fő adatbázis minden módosítását átvezetik a standby adatbázisba is. Replikáció Osztott adatbázisok esetén, az adatok több adatbázisban szétosztottan helyezkednek el. 46 Egyes adatok több helyen is ismétlődve megtalálható Replikáicó előnyei: - rendelkezésre állás - megbízhatóság - kisebb hálózati forgalom - leválasztott műveletek megvalósítása replikálható objektumok: - Tables - Indexes - Views - Packages and Package Bodies - Procedures and Functions - Triggers - Sequences - Synonyms Replikációs csoport: logikailag összetartozó objektumok, azonos replikációs paraméterekkel Replikációs csomópont lehet: Master site: minden adat pontos

másolata rajta van Snapshot site: csak bizonyos adatok, bizonyos időpontbeli képe van rajta Replikációs stratégiák: - Multimaster : minden csomóponton teljes másolat helyezkedik el, az alkalmazásnak elegendő csak egy helyen elvégezni a módosítást snapshot vegyes A snapshot replikációnál a teljes adatoknak csak egy időszakosan frissített, szűkített képe van jelen a csomóponton. A snapshot replikáció lehet: - csakolvasható - írható és olvasható 47 a snapshot –on végzett módosítás automatikusan elmegy a master helyekre snapshot frissítés módjai: - fast (napló alapú) - complete (teljes) - force (megpróbál előbb gyors frissítést tenni) Replikáció típusai: - szinkron replikáció: a változások egy master helyen rögtön továbbítódnak a többi helyre. Minden master hely módosítása egy tranzakción belül megy végbe, ezért, ha valahol nem sikerül a módosítás, akkor a többi master helyen is visszagörgetődik a tranzakció.

- Aszinkron replikáció: a master helyen elvégzett módosítások egy későbbi időben, külön tranzakcióban hajtódnak végre - Procedurális replikáció: nagy adatmennyiségek módosítása esetén hasznos. Ekkor csak a módosító eljárás kerül át a többi helyre, az adatok nem mozognak a hálózaton. Minden helyen lefut a módosító eljárás 48 8. témakör Net8 használata A Net8 alapok A Net8 rendszer az Oracle kommunikációs program modulja. Feladata az adatátvitel megvalósítása - kliens és szerver - szerver és szerver viszonylatban. Főbb funkciói: - kapcsolat kiépítés - adatok továbbítása - kivételek, hibák kezelése Client/Sever mechanizmus főbb komponensei: - A kliens oldali alkalmazás - Kliens oldali hálózati komponensek - Hálózat - A szerver oldalon egy figyelő (listener), mely fogadja majd továbbítja a beérkező kéréseket. - Adatbázis szerver Net8 előnyei: - hálózat függetlenség - protokoll függetlenség - homogén

rendszerek támogatása Kapcsolati paraméterek (connect identifier): - egy hálózati szolgáltatás azonosító (net service name) A hálózati szolgáltatás azonosító tartalma: - hálózati elérési cím (host) - adatbázis szolgáltatás azonosító (service name), ez a régi SID-nek felel meg (a SID egy DB instance, míg a service name több DB instance együttesét írja le) net sevice name -host address -service name -- sales= (description= (address=(protocol=tcp)(host=sales-server)(port=1521)) (connect data=(service name=sales.usacmecom)) ) A global database name két részből áll : adatbázis név + a domain név 49 Hivatkozás: Teljes paraméter megadás: CONNECT scott/tiger@(description=(address=(protocol=tcp)(host=salesserver1)(port=1521)) (connect data=(service name=sales.usacmecom)) Net service name használat: CONNECT scott/tiger@sales Net8 struktúra áttekintés Oracle hálózati struktúra Az alkalmazások az OCI rutinokon keresztül, task-task

kommunikációval tartják a kapcsolatot a Net8 modullal. A Net8 modul komponensei: - NI: általános interface a kliens – Net8 kapcsolathoz - NR/NN/NA: hálózati forgalom, név feloldás, jogosultság ellenőrzése - TNS: alsóbb hálózati protokollok felé kapcsolódás A Net8 szoftver réteg végzi az adatkapcsolat megvalósítását. A Net8 egyik fő komponense a 50 TNS réteg. A TNS = Transparent Netwok Substrate, egy rutin gyüjtemény, mely általános adatkapcsolati unkciókat biztosít, mint kapcsolat felvétel, adat továbbítás, kapcsolat zárás. A TNS-beli rutinok még hálózat protokoll függetlnek. Az alkalmazások TNS rutinokat hívnak meg a kapcsolatok megvalósítására. A TNS rutinok a kéréseket továbbítják az Oracle Protocol Adapters rétegnek, ahol protokoll függő rutinok aktivizálódnak. Az Oracle Protocol Adapter réteg végzi a leképzést az általános TNS téteg eljárások és a szabvány hálózati protokolnak megfelelő rutinok

között. Egy ilyen szabványos ipari protokoll például a TCP/IP. Az OPA a TNS hívásokat konvertálja hálózati protokoll specifikus hívásokká oda és vissza is. A Protcol Stack az alkalmazott hálózati protokoll (mint pl. A TCP/IP ) rutingyüjteménye. Az Oracle8 által támogatott protokolok NT környezetben: - TCP/IP - SPX (Novell) - Named Pipes (PC LAN) - LU6.2 - Bequeath Protocol Adapter (lokális kapcsolat, listener nélküli kapcsolódás) A Host Naming Adapter egy olyan modul, melynek segítségével a szerver adatbázisokat a gazda gép domain nevével érhetjük el, címzhetjük meg. A Host Name Adapter használatának előfeltétlei: - TCP/IP protokoll alkalmazása - A host nevek IP címre konvertálása egy központi DNS vagy lokális host állomány alapján történik - Nincs szükség Oracle Connection Manager szolgáltatásokra - A Global Database Name és a host gép neve megegyezik, vagy a host gép nevének egy alias neve egyenlő a Global Database Name

értékkel. Windows NT Authentication Adapter lehetővé teszi az NT OS user autentikáció alkalmazását a kliens – Oracle szerver kapcsolatban is. Az Oracle Names egy transzparens név feloldás kezelő mechanizmus, mely segítségével heterogén hálózati környezetben is transzparens módon, egyszerűen lehet szervereket azonosítani. Két fő komponense van: - DDO : Dynamic Discovery Option, az Oracle szerver regisztrálni tudja magát az ismert Name Server-eknél. CCS: Client Cache Service: a kliens letöltheti az információkat az ismert Name Serverekről a lokális memóriába Hálózat konfigurálása A hálózat alapvetően kétféle üzemmódban működhet: - lokális adminisztráció: minden kliensnél helyileg parametrizáljuk a hálózati elérést 51 - központi adminisztráció: egy Oracle Names Server-ben, központi helyen tárolódnak a szerver elérési paraméterek Az alkalmazható név feloldási módszerek: - lokális adminisztráció esetén: o

Host Naming o Local Naming o External Naming - központi adminisztráció: o Oracle Names Konfigurációs segédeszközök: - adminisztráció: o Oracle Net8 Assistant Lokális konfigurációs állományok: TNSNAMES.ORA A hálózaton elérhető szerverek nvét és címét tartalmazza SQLNET.ORA Kliens profile információk tárolása Net8 Assistant használata A Net8 programmal lehet új kapcsolatot definiálni, létező kapcsolatokat módosítani, törölni. Az elindítás után ki kell választani a kezelendő szolgáltatás típusát. Új kapcsolat létrehozásának lépései a. Service név megadása (tetszőlegs név) b. alkalmazott hálózati protokoll kijelölése c. szerver elérési paraméterek megadása: i. host gép neve (pl kukamosodacom) ii. a listenerhez kapcsoldó port szám (p 1521) d. adatbázis service name kijelölés e. kapcsolat tesztelése A beállításoknál még a local naming method opciót is be kell állítani. 52 Net8 Configuration Assistance

Névfeloldási módszer meghatározása A névfeloldási módszer beállításához a Net8 Assistance segédprogramot kell használni. Az induló képernyőn válasszuk ki a Profile – Naming funkciót A választható névfeloldási lehetőségek: 53 TNSNAMES : lokális elérés adminisztráció, a TNSNAMES.ORA alapján - ONAMES : központi, Name Server által végzett adminisztráció HOSTNAME : Host Naming Adapter alkalmazása NDS : Netware Directory Service A TNSNAMES.ORA állomány szerkezete A TNSNAMES.ORA konfigurációs állomány logikai azonosító neveket összerendeli a fizikai elérési leírásokkal. A logiai név egy service név vagy más néven egy logikai adatbázis név (alias). Az állomány több összerendelést is tartalmaz. Egy összrendelési egység általános szerkezete: <service name>.world = (DESCRIPTION = (ADDRESS LIST = (ADDRESS = (protocol adapter information) ) ) (CONNECT DATA = (SID = SID) ) ) A service név tetszőleges azonosító

lehet, de ha a névfeloldásra az Oracle Names Server lett kijelölve, akkor a service névnek mg kell egyezni a globális adatbázis aonosító névvel (Global Database Name). A név első része a DB NAME, míg a második része a DB DOMAIN. A második részben protokoll specifikus információk kerülnek lárolásra. A TCP/IP protokoll esetében az alábbi paramétereket lehet megadni: - PROTOCOL : a protokoll tipusának megadása, most TCP/IP szerepl - HOST : szerver csomópont azonosítás - PORT: : portszám azonosítás - GLOBAL DBNAME: adatbázis instance azonosítás - SID : adatbázis SID Az alábbi lista egy mint aTCP/IP kapcsolat leírását mutatja be. GREEN.world = (DESCRIPTION = (ADDRESS LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = GREENWOOD) (PORT = 1521) ) ) (CONNECT DATA = (SID = ORCL) ) ) 54 A LISTENER modul felelős a kliensektől bejövő kérések fogadásáért és továbbításáért a szerver felé. Az elindított kliens a paraméter állomány alapján

határozza meg, hogy mely portot kell figyelnie, s hova kell a kéréseket továbbítania. A Listener elindíthat egy új dedikált Oracle szerver proceszt, s csatlakozhat létező szerver processzhez is. A dedikált processz a Listener kérésére jön létre, s a kapcsolat idejéig él csak. Ebben az esetben minden szerverhez egy kliens kapcsolódik. Dispatcher alkalmazása esetén több szerver procesz fut párhuzamosan, s a bejövő kéréseket a dispatcher irányítja a megfelelő, szabad szerverhez. Kliens oldali leterhelés kiegyensúlyozás azt jelenti, hogy a kliens több listenerhez is kapcsolódhat, s az egyenletes leterhelés biztosítása érdekében változtatja a kiválasztott listener elemet. Mivel a kliens több hostról is kap információt listenerek tekintettében a célhely kiválasztás taktikája a következő: - legkevésbé leterhelt host - legkevésbé leterhelt instance - 55 legkevésbé leterhelt dispatcher Dispatcher kapcsolati konfiguráció

Dedikált kapcsolati konfiguráció A szerverek működéséről, állapotukról, leterheltségükről a listener elemek a szerver regisztráció révén értesülnek. Ekkor a PMON felkeresi, megszólítja a futó listener processzeket, s közli velük az elérési adatokat, SID-et, leterheltséget. A LISTENER.ORA állomány szerkezete A LISTENER.ORA állomány megadja minden egyes listener processz paraméter beállítását, kijelölve az - azonosító nevet, - elérési címet - kapcsolódó adatbázist - működési paramétereket esetén: A LISTENER.ORA állomány általános szerkezete egy TPC/IP kapcsolat LISTENERNAME = (ADDRESS LIST = (ADDRESS= (PROTOCOL= ) (KEY= service name) ) (ADDRESS = (PROTOCOL = TCP) (HOST = host name) 56 (PORT = 1521) ) ) STARTUP WAIT TIME LISTENER = CONNECT TIMEOUT LISTENER = TRACE LEVEL LISTENER = SID LIST LISTENER = (SID LIST = (SID DESC = (SID NAME = ) ) ) PASSWORDS LISTENER = A kliensnél nincs szükség TNSNAMES.ORA állományra, ha a Host

Naming Adapter modulon keresztül megy a névfeloldás. Ebben az esetben a paraméterek között a SID NAME után szerepeltetni kell egy (GLOBAL DBNAME= ) paramétert is. A névfeloldási mód beállítása a kliens oldalon. - TNSNAMES : lokális elérés adminisztráció, a TNSNAMES.ORA alapján Minden kliesnél kell lennie egy TNSNAMES.ORA állománynak, melyben a kapcsolat leíró adatok vannak. ONAMES : központi, Name Server által végzett adminisztráció HOSTNAME : Host Naming Adapter alkalmazása Csak TCP/IP környetben használható. Nincs szükség semmilyen kliens oldali konigurációra. Az üzemmdó a Net8 Assistance segítségével állítható be vagy tiltható. A Listener-nek a 1521-es porton kell futnia kötelezően A LISTENER.ORA állományban kell szerepelni egy GLOBAL DBNAME = hostnév paraméternek, ahol a hostnév a szerver csomópopont domain neve. A kapcsolat felvételéhez a kliensnek a szerver csomópont domain vagy alias nevét kell megadnia. Oracle Names

Az Oracle Names a nagyobb hálózatokban való egyszerűbb, centralizáltabb név feldoldási mechanizmus megvalósítására lett kidolgozva. Az Oracle Names rendszer több Names Server-ből álló rendszer létrehozását, karbantartását teszi lehetővé. A Name Server nyilvántartja a hálózatban lévő szervereket és elérésüket. Az összegyűjtött információk tárolhatók: - adatbázisban - lokalis cahce-bn Az Oracle Name Server használata esetén is a kliens egy service nevet ad meg adatbázis célhelyként. Ezután a kérés elkerül egy Oracle Name Server-hez 57 (vagy a well-know hostra, mint pl. ORANAMESRVR0, vagy a beállított Prefered Oracle Name Server hostra), s onnan visszakapja a service névhez tartozó IP címet, listener adatot. A Listenerek pedig automatikusan elküldik saját elérési adtaikat a Name Servereknek. Az optimális, legközelbbi Name Server kiválasztása a kliensen egy NAMESCTL80 rutinnal történik. A nyilvántartásban tárolt adatok:

- Names Serverek adatai nevei és elérési adatai - Adatbázis service azonosítók - Database Links - Service név aliasok Az elnevezéskre vonatkozó megvalósítási tipusok: - sima elnevezések, kis hálók esetében, nincs külön domian név, a default domain név a word lesz. - Hierarchikus elnevezések, több, egymásba is ágyazott domain-ek Az Oracle Network domain nevei függetlenek lehetnek a DNS domian nevektől, de célszerű az Oracle-be is átvenni a DNS neveket. A default domain-ben az adatbázis hivatkozás a domain megadása nélkül is történhet. Az Oracle Names rendszert a Net8 Assistance segítségével lehet konfigurálni. A koniguráció után, a használat előtt el kell indítani az Oracle Names service-t az adott gépen. A TNSNAMES.ORA állományra ilyenkor nincs szükség Ha a DDO opció be van kapcsolva, az SQLNET.ORA állományra sincs szükség a kliens gépen A DDO használatakor automatikusan regisztrálódnak az ismert Name Serverek az Oracle Names

rendszerben, s nincs szükség a Net8 Assistance általi konigurációra sem. 58 Kliens – szerver struktúrák, tranzakció managerek 9. témakör Kliens-szerver architektúrák: Kétrétegű modell Kliens: szolgáltatást kérő Szerver: szolgáltatást nyújtó egység Egy szerver több klienst kiszolgálhat és egy kliens több szervertől is kérhet szolgáltatást Alkalmazások funkció rétegei: - prezentációs szolgáltatás - megjelenítési logika - működési logika (végrehajtandó feladatok) - hálózati szolgáltatások - adatbázis logika - adatbázis kezelés - állomány kezelés A funkciók tipikus szétosztási sémája: része) Kövér kliens: több funkciót is végrehajt a kliens (megjelenítés, működési logika, adatbázis logika) Vékony kliens: (csak megjelenítés) Osztott (a kliens megjelenítés és működési logika egy A működési logika elhelyezési alternatívái: - kliens - szerver (adatbázis tárolt eljárások, triggerek)

Célszerű speciális csomópontot használni minden funkcióra Három rétegű struktúra modellek A normál kliens és adatszerver mellé egy alkalmazás szerver is kapcsolódik: - kliens - alkalmazás szerver (működési logika és az adatbázis logika egy része) - adatbázis szerver Több erőforrás bevonása a feladathoz számos előnnyel jár: - megbízhatóság növekedés - teljesítmény növekedés a feladatok szétosztásával - hálózati terhelés csökkenés - rugalmasabb struktúra - olcsóbb bővítési lehetőségek Az adatbázisok területén is felmerült az igény az erőforrások megosztására 59 Tranzakció menedzser, TUXEDO Middleware : köztes komponens a kliens és a szerverek között Főleg terhelés kiosztást, konverziót, védelem ellenőrzést végeznek TUXEDO: tranzakció monitor, Transaction for UniX Extended for Distributed Operations TUXEDO nem kizárólagoson az adatbázis kezelési értelemben vett tranzakció kezeléshez kötődik, hanem

egy általánosabb osztott erőforrásokkal, osztott környezetben működő rendszer Célja az egyes alkalmazások számára megkönnyíteni és gyorsabbá tenni a megosztott környezetben való működést. A TUXEDO rendszer a kliens – szerver struktúrán alapszik Fontosabb szolgáltatások: - nem kell az alkalmazásnak pontosan ismerni, hogy hol is helyezkedik el az igényelt szolgáltatást végző szerver, a TUXEDO automatikusan megkeresi az igényt teljesíteni tudó erőforrásokat; - gondoskodik arról, hogy a különböző alternatív erőforrások leterhelése egyenletes, optimális legyen - az alkalmazások függetleníthetik magukat a konkrét szerver háttértől, vagyis az alkalmazások kódjába nem kell beépíteni, hogy pontosan hol és milyen szerverek vannak. Az alkalmazások csak az igényt jelzik a TUXEDO felé, így különböző szerver háttérrel is futhat az alkalmazás; - a TUXEDO nyílt a különböző szerverekhez való kapcsolódás terén; - a

heterogén szerver környezetben különböző konverziós lépéseket is elvégez, az alkalmazások egy egységes kezelő felületet használhatnak, s - védelmi funkciókat is beépítettek a TUXEDO szolgáltatásai közé. Főbb komponensek - 60 System/T : a TUXEDO rendszer magja, ez a komponens végzi az szolgáltatások kiosztását, az erőforrások leterhelésének optimalizálását, konverziókat, stb.; System/D : a TUXEDO saját adatbázis komponense, de emellett természetesen más ismert adatbázis kezelő rendszerrel (pl. Oracle, DB2,) is együtt tud működni; System/Q : a kötegelt feladatok ellátását, előkészítését végző modul; System/WS : a munkaállomások, PC-k felé irányuló kapcsolati elem; System/HOST : külső szolgáltató szerverek felé történő kapcsolatért felelős modul; System/DOMAIN : a különböző TUXEDO alkalmazási tartományok egymás közötti kommunikációját végző komponens. Alkalmazás kliens TUXEDO System/WS

Alkalmazás kliens System/T System/ DOMAINS System/Q Funkció szerver System/D Funkció szerver System/HOST Funkció szerver Alkalmazás kliens TUXEDO működési változatai: - nem tranzakció orientált alkalmazások (pl. számítások végzése) - csak egy erőforrást, adatbázist kezelő OLTP alkalmazások - több adatbázist kezelő OLTP alkalmazások Elvégzendő feladatok: - más és más lehet az adatok tárolási formátuma a különböző gépeken - különböző megjelenési formátumok lehetnek az egyes klienseknél - különböző hálózati protokollokkal kell dolgozni és osztott erőforrás kiosztásra van ezért itt is szükség: - az erőforrások köre, pozíciója változhat (pl. hálózati hiba miatt kiesnek egyes gépek) - gondoskodni kell a feladat szétosztásról, az eredmények illesztéséről - a végrehajtás szinkronizálásáról. - időbeli végrehajtás, erőforrás lekötést minimalizálja - rugalmas, hatékony alkalmazásfejlesztési

környezetet biztosítson. Mindezen feladatokat ellátó modult DP monitornak, azaz Osztott Végrehajtás monitornak nevezik. Az osztott tranzakció kezelés esetében a f enti követelmények mellé még hozzájönnek az osztott adatbázis kezelésből származó feladatok: - különböző adatbázisok bevonása egy tranzakción belül - a különböző adatbázis kapcsolati módok megvalósítása - az elvégzendő művelet lefordítása különböző adatbázis modellhez tartozó parancsnyelvekre, műveleti elemekre - az ACID elvek betartásáról gondoskodni kell Ez a rész a TP monitor A System/T monitor fogja eldönteni, hová is irányítsa a beérkező kéréseket. . 61 Kliens TUXEDO Cmp Cmp Alkalmazás szerver GET(X,Y,Z) Cmp Q=X+Z-Y PUT(Q) ? X,Y,Z Szerver X=3,Y=5,Z=4 Q=2 A System/T modul komponensei: - - - - - 62 Bulletin Board : ez egy repository jellegű struktúra, amely a TEXUDO-hoz kapcsolódó kliensek és szerverek, szolgáltatások és egyéb

rendszer elemek leírását tárolja. Ezen elemek közé tartozik az egyes szerverek elérhetősége is, amiből kideríthető a szerverek elérése, ezért a Bulletin Board egy név szerver jellegű funkciót is betölt. Message Queue: ebben a várakozósorban foglalnak helyet az elküldött de még fel nem dolgozott üzenetek. A üzenet várakozó sor lehet egy taghoz között, azaz privát, vagy lehet megosztott is, amikor például több szerver is egyazon várakozósorból kapja az üzeneteket. Mind a szerver mind a kliens oldali elemek rendelkeznek hozzájuk kapcsolódó üzenetsorral. Bridge : a párhuzamos futó System/T modulok egymás közötti kommunikációját végző egység. BBL : a Bulletin Board menedzser egysége, amely ügyel arra, hogy mindig aktuális állapotban legyen a Bulletin Board struktúra. Ez mindegy démon folyamatként időnként feléled és elvégzi a szükséges ellenőrzési feladatokat. DBBL : a Bulletin Board –ot szétküldő almodul. A több

példányú System/T moduloknál a modul indulásakor, vagy ha változik a Bulletin Board tartalma, akkor ezen almodul elküldi mindegyik társ modulnak a Bulletin Board tartalmát, hogy azok is tudják milyen szolgáltatások élnek a csomópontján. A TUXEDO a logikai név hivatkozások feloldására ezt az utat választotta a centralizált Bulletin Board ellenében. Ugyanis a centralizált esetben minden kéréskor a szolgáltatás lokalizálásra a centrumhoz kellene fordulni a Bulletin Board olvasására. Ez azonban jelentős hálózati leterheléssel, s lassabb hivatkozás feloldással járna. Emiatt minden helyen megvan az összes többi Bulletin Board tartalmi is, s helyileg lehet információt szerezni a teljes rendszerről. Viszont ekkor az egyes csomópontok szinkronizálását kell biztosítani. Ezt végzi el a DBBL almodul. ATMI : ez a r övidítés egy API felületet takar, jelentése: alkalmazás és tranzakció menedzser közötti interfész (Application to Transaction

Manager Interface). E mögött egy olyan függvény könyvtár áll, melyek elemeit a k liensek és szerverek is a k ódjukba beépíthetik a S ystem/T-vel történő kommunikáció megvalósítására. A TUXEDO keretében az adatforgalom kezelésére létre kell hozni egy kommunikációs buffernek nevezett struktúrát, amely alkalmas lesz az üzenethez kapcsolódó adatok tárolására. A működés során a kliensnek regisztráltatni kell magát a TUXEDO rendszerrel. Ennek során a következő lépések zajlanak le: - bekerül a kliens a Bulletin Board-ba - egy saját üzenet várakozósor fog allokálódni a klienshez ellenőrzésre kerül a kliens hozzáférési jogosultsága A kliens a k apcsolódás után már igényelheti a különböző, számára engedélyezett szolgáltatások végrehajtását. Ehhez egy ATMI függvényhívással a TEXUDO felé fordul. Ennél a hívásnál paraméterként az alábbi fontosabb információkat adja majd át: - igényelt szolgáltatás

logikai neve - átküldött adatelemek leírása (cím, méret,.) Az igény elküldése után a kliens kétféle továbblépést választhat. Egyrészt várakozik, vagyis addig nem fut tovább még meg nem jön a válasz a szervertől. Ezt nevezzük szinkron végrehajtásnak A másik lehetőség, hogy a kliens továbbfut, s majd csak később fog visszatérni a kérésére adott válaszra. Ez az aszinkron végrehajtási mód Egy kliensnek több kérése is feldolgozás alatt állhat párhuzamosan. . A visszatérési üzenet is fog adatérték leírást tartalmazni, hiszen a visszajelzésnél megadják a végrehajtás sikerességi státuszát, s lekérdezésnél az eredmény adatokat A előbb felvázolt kliens – szerver kapcsolati séma mellett, amely tehát a szolgáltatás kérés egyszeri kérésén alapszik, s ezután már csak a válaszra fog várni a kliens, létezik egy másfajta kapcsolati modell is, melyben a szerver és a kliens a szolgáltatás végrehajtása közben is

kommunikálhat egymással. A szerver regisztráció során a következő lépések hajtódnak végre: - bekerül a szerver azonosító, elérés a Bulletin Board-ba - egy saját üzenet várakozósor fog allokálódni a szerverhez - elküldésre kerül a szerver által kezelt szolgáltatások köre, hogy minden System/T modul ide tudja irányítani szükség esetén a bejövő kéréseket Ezt követően a szerver az üzenet várakozósort figyeli, hogy kapott e szolgáltatási kérést. Ha igen akkor kiveszi azt a sorból, s feldolgozza Csak a feldolgozás után fog újabb kérésekkel foglalkozni. A végrehajtás közben a szerver más szerverek szolgáltatásait is igénybe veheti, azaz továbbíthatja a hozzá bejövő üzenetet más szerverhez. 63 ATMI felület A kliensek kapcsolódási felülete a TUXEDO felé Az ATMI is a CLI a formalizmusra épül, a hívások szintaktikája illeszkedik a gazdanyelvi környezethez. Így például a C gazdanyelvet véve az üzenet küldés

függvénye az alábbi alakot ölti: V = tpcall (char *) service,(char ) ibuf, ilen, (char ) &obuf, &olen, flag); A TUXEDO rendszer a két oldal közötti kommunikáció megvalósítására kétféle lehetőséget kínál fel. A kétféle a kommunikációs lehetőség a következő: - RPC, azaz távoli eljárás hívás elvén alapuló kommunikáció és - Message, azaz üzenetváltás elvén alapuló kommunikáció. Az RPC alapú megoldásnál egyszer meg kell hívni a szolgáltatást átadva a feldolgozáshoz szükséges adatokat, s utána már csak az eredményt kell figyelnünk, hogy megjött-e már. Közben nincs kapcsolatunk a szerverrel, nem pillanthatunk bele a végrehajtás közbenső állapotaiba. E megoldásnál tehát - kisebb a hálózati forgalom - nagyobb a szerver önállósága a végrehajtás során. Az üzenetváltáson alapuló megoldásnál a k liens a szolgáltatási igény átadása után nem szakítja meg a kapcsolatot a szerverrel, hanem egy üzeneti

vonal jön létre a k liens és a s zerver között. Ezen üzeneti vonalon a k ét fél egy folyamatos üzenet küldési és fogadási párbeszédet folytat, lehetővé a kliensnek, hogy a szolgáltatás végrehajtás közben is beavatkozhasson a szerver működésébe. Így tehát - nagyobb lehet a hálózati forgalom, de rugalmasabb, kliens függő a szolgáltatás teljesítése. Alkalmazás kliens Alkalmazás szerver üzenet olvasás h1=tpacall(SERV1) h2=tpacall(SERV2) végrehajtás (SERV1) Üzenet várakozó sorok tpreturn() tpgetrply(h2,) tpgetrply(h1,) Alkalmazás szerver üzenet olvasás végrehajtás (SERV2) tpreturn() 64 Alkalmazás kliens id=tpconnect(SERV1,SND) Alkalmazás szerver id Kapcsolódás a klienshez tpsend(id,data,RCV) tprecv(id,data) tprecv(id,data) tpsend(cd,data) tprecv(id,data) tpreturn(SUCC,data) Az egyenletes leterheltség biztosításához az új feladat kiosztásánál ismerni kell az egyes szerverek foglaltságát. Ezt a foglaltsági

érték azt fogja mutatni, hogy körülbelül mikor fog a szerver végezni a rá kiosztott munkákkal. Ezen érték a rá várakozó (és a feldolgozás alatt álló) feladatokkal jellemezhető. A szerverre váró műveleti igények a System/T modulban a Bulletin Board-ban kerülnek nyilvántartásra. A TUXEDO-ban, mivel e mechanizmus elsődleges célja, hogy ne egyenlőtlenül kapják meg a feladatokat a szerverek és ehhez még feltesszük , hogy egy feladat végrehajtási ideje nem hosszú (hiszen OLTP rendszerekről van szó), akkor mér él a rendszer azzal az egyszerűsítéssel, hogy a leterhelésbe nem veszi bele az éppen feldolgozás alatt álló feladatokat. Ezen egyszerűsítés mellett, ugyanis maximum egy feladat végrehajtási időt tévedhetünk a tényleges és becsült időszükséglet között (az első helyen álló épp most kezdte el, a második helyen álló épp most be fogja befejezni a feldolgozás alatt álló feladatot). Ezért csak a még feldolgozásra

várakozó feladatokat veszik be a leterhelés becslésébe. A terhelés becslésére kétféle módszert alkalmaznak System/T modulban: - real-time, azaz a tényleges, valós idejű leterhelés kiegyenlítés módszerét és a - round-robin, azaz körbeforgásos leterhelés kiegyenlítés módszerét. Az egyes módszerek eltérő TUXEDO konfigurációkhoz tartoznak. A real-time módszer egy pontosabb megoldást ad, viszont csak akkor alkalmazható, ha a rendszerben egyetlen Bulletin Board található, mely tartalmazza az összes szerver leterhelési adatát. Ha viszont több System/T modul él párhuzamosan, mind saját Bulletin Board struktúrával, akkor a közelítő leterhelésen alapuló round-robin módszert alkalmazza a rendszer. 65 Elosztott adatbázis kezelő rendszerek 10. témakör Elosztott adatbázis Elosztott adatbázis: Több, a hálózat különböző csomópontjain elhelyezkedő, logikailag egységet alkotó adatbázisok rendszere Az több különböző helyi

adatbázis a nagy közös logikai adatbázis egy-egy szeletét tartalmazza. Megvalósítás főbb elemei: - az együttműködést irányító funkció - adatok mozgatása - konverzió - részletek elrejtése A lokális adatbázisok együttműködésének több különböző vetülete van: - autonómia (mennyire önálló egy lokális elem) (A) - heterogenitás (H) - funkció és adat szétosztás (D) DDBMS típusok (A,H,D) - Osztott homogén DBMS (0,0,1) - Osztott federatív DBMS (.5,0,1) - Osztott multi-DBMS (1,0,1) - Heterogén multi-DBMS (1,1,1) - Osztott heterogén DBMS (0,1,1) Multi-DBMS: nagy autonómia Federatív DBMS : közepes autonómia Speciális feladatok: - replikáció : adatok megismétlése - fregmentáció: objektumok feldarabolása A DDBMS-nek több függetlenséget és transzparenciát (elrejtést) kell nyújtania - 66 Fizikai adatfüggetlenség Logikai adatfüggetlenség Elhelyezkedés transzparencia Elnevezési transzparencia Replikációs transzparencia

Fregmentációs transzparencia Date szabályai az elosztott adatbázisokhoz: 67 - az egyes lokális adatbázisoknak minél nagyobb autonómiával kell rendelkeznie a helyi adatok kezelése helyi szinten történik, csak a helyi DBMS felügyeli a helyi folyamatokat - ne legyen szükség egy megadott központi egységre az egyes lokális elemek szétosztva is tudják irányítani az együttműködést demokratikus irányítás - a rendszer folyamatosan tudjon működni egyes tagjainak kiesése esetén is új tagok felvétele se igényeljen leállást - elhelyezési transzparencia és függetlenség biztosítása a felhasználó úgy láthassa, mintha minden adat a helyi gépén lenne ne kelljen semmi paramétert módosítani az alkalmazás szinten az adatok átrendezése esetén sem - fregmentáció függetlenség, transzparencia a felhasználónak ne kelljen törődnie az objektum feldarabolásának tényével a fregmentáció menet közben rugalmasan változtatható

legyen - replikáció függetlenség, transzparencia a felhasználónak ne kelljen törődnie az adatismétlések tényével a replikáció menet közben rugalmasan változtatható legyen - optimalizált query kezelő rendszer biztosítása a parancs végrehajtó rendszer ki tudja használni az replikáció, fregmentáció adta előnyöket egy hatékony végrehajtási terv előállításánál - biztosítani kell az elosztott tranzakciók megfelelő végrehajtását meg kell oldani a több helyen futó tranzakció részletek összehangolását, s a megfelelő recovery mechanizmust - Hardver függetlenség Az adatkezelő felület független a konfigurációban megvalósított hardver elemektől - Operációs rendszer függetlenség A felhasználói adatkezelő felület független a konfigurációban megvalósított OS elemektől - Hálózat függetlenség A felhasználói adatkezelő felület független a konfigurációban megvalósított hálózati elemektől - DBMS

függetlenség A rendszer több különböző DBMS elemet is tartalmazhat, az együttműködés a szabványos kapcsolati felületen alapuljon. Fregmentáció típusai: - horizontális (rekordok) - vertikális (mezők) - vegyes helyes fregmentáció szabályai: - teljesség, ne vesszen el egyetlen egy adatelem sem - veszteség mentesség, alapadat újra előállítható - ne legyen szabályozatlan redundancia fregmentáció megvalósítás szabályai: - a felhasználás és tárolás helyének közelsége - logikai összetartozás DDB rendszerek kiterjesztett sémája Külső séma (felhasználói) Globális fogalmi séma (a teljes adatbázis logikai sémája) Globális elosztási séma (mely rész hol található meg) Lokális fogalmi séma (a helyi adatbázis logikai képe) Lokális belső séma (a fizikai megvalósítás) A felhasználói műveletek csak a globális logikai sémára vonatkoznak Adatszótár karbantartás Elemei: - séma leírás hozzáférési jogok statisztikák

globális logikai nevek leképzése lokális, fizikai címekre Globális adatszótár tárolása: - 68 centralizált (csak egy csomóponton) teljes replikáció (minden csomóponton) többszörözött (több helyen) - particionált (egyes részei más-más helyen) problémák: a különböző példányok szinkronban tartása hálózati forgalom csökkentése Federatív adatbázisok Autonóm, rendszerint különböző adatmodelleken alapuló, heterogén lokális adatbázisok együttese, melyben korlátozott együttműködés valósul meg az egyes tagok között, hogy egy szabályozott hozzáférést lehessen biztosítani a lokális adatbázisok megadott elemeihez. A külső felhasználó egy parancson belül több adatbázis adatait is elérheti. Az egyes adatbázisoknak csak megadott részei érhetők el a külső felületről. Követelmények: - elhelyezési transzparencia - heterogenitás elrejtése - több adatbázisra kiterjedő műveletek támogatása - elosztott

tranzakciók megvalósítása A fenti funkciók megvalósítására egy külön szoftver réteg szükséges E réteg feladatai: - globális SQL parancs feldolgozás irányítása, végrehajtása - tag DBMS-ek vezérlése, feladat kiosztás, eredmény összesítés - globális tranzakció kezelés - objektum hozzáférések biztosítása Tag DBMS integráció szintjei: - szoros kapcsolás: globális adatbázis séma biztosítása - laza kapcsolás: nincs globális adatbázis séma Federativ DBS séma architektúra - lokális adatbázisok lokális fizikai szint (ANSI SPARC analógia) lokális fogalmi, logikai szint lokális komponens séma lokális export séma globális federativ séma külső, felhasználói séma komponens séma szerepe: ez a réteg feladata a tagok közötti heterogenitás feloldása egy közös adatmodellen formalizmust használ 69 CDM: Common Data Model Jelöltek: relációs ER OO modellek Séma transzláció szükséges Export séma: A lokális komponens

sémán alapszik Feladata azon adatelemek kijelölése, melyek a külső, globális szinten is elérhetők lesznek Az adatelemek kijelölése mellett konverziót és védelmi adatokat is tartalmazhat Nem szükséges, hogy minden lokális adat külsőleg is látható legyen Az elnevezések globális megvalósítását is biztosítja Federatív séma: A lokális export sémák egyesítése Adatokat tartalmaz az adat elhelyezkedésekre, a globális és lokális adatok közötti leképzések lépéseire Heterogenitások kezelési is szükséges lehet ezen a szinten is A laza csatolás esetén nincs igazi séma integráció adatbázis integráció A lokális adatbázisokban tárolt adatoknál az egyes tagok, csomópontok között szemantikai különbségek léphetnek fel Tipikus eltérési okok: Van elnevezési konfliktus és szerkezeti konfliktus - 70 szinonimák az elnevezésben (eltérő elnevezés azonos dolgokra) homonima az elnevezésekben (azonos elnevezés különböző dolgokra)

eltérő szerkezeti megoldások egyazon dologra (egy fogalom lehet pl. mező vagy reláció) eltérő statikus integritási feltételek (más kulcsmezők, érték megkötések) - eltérő dinamikus elemek és integritási feltételek (triggerek, eljárások) adat típus eltérés (eltérő adattípus) adat ábrázolás eltérés (eltérő mértékegység) Cél az eltérő sémákból egy konzisztens összesítő kép előállítása A séma integráció főleg manuális tevékenységeket igényel, mert sok olyan lépése van, mely igen sok és komplex háttér ismeretet igényel Adatbázis integráció = séma transzláció + séma integráció A séma transzláció során a lokális sémát konvertálják a közös formátumra A séma integráció során a különböző lokális sémákból egy eredő séma előállítása Módszerek: - egyenkénti (mindig egy rész bevonása az összesítőbe) - csoportosított (csoportok alkotása, majd összevonása) Integrációs lépések:

- előintegráció konfliktusok feltárása konfliktusok feloldása lokálisan modellek egyesítése eredő modell kialakítása Az előintegráció során az egyes tagok fontossága, az integráció stratégiája, a célok kijelölése történik Az integráció során nem szabad információt elveszíteni (teljesség) Lehetőleg minél tömörebb sémát kell megvalósítani Legyen redundancia mentes Legyenek a nevek egyértelműek A megadott konverziós szabályokat a federatív réteg használja fel 71 Művelet végrehajtás elosztott és párhuzamos adatbázisokban 11. témakör Párhuzamos adatbázis: Több processzor egyidejűleg, párhuzamosan hajtja végre az adatkezelő utasításokat Szorosan kapcsolt multi-processzor rendszeren futó adatbázis A végrehajtandó feladat szétosztható több processzorra Művelet optimalizálás célja: - minimális végrehajtási idő (átfutási idő) - minimális erőforrás felhasználás (hálózat, CPU) Művelet

optimalizálás szekvenciális feldolgozásnál SQL szintaktikai és szemantikai ellenőrzés Algebrai kifejezés gráf előállítása Algebrai fa optimalizálás QEP generálás QEP optimalizálás QEP végrehajtás Párhuzamos végrehajtás struktúrája: - piplined: a QEP fa különböző csomópontjait más és más processzorok hajtják végre. A k processzor kimenetét a (k+1) dolgozza tovább. A processzorok párhuzamosan dolgoznak Minden adatelem ugyanazon egységeken megy keresztül. - partitioned: A művelet egy lépését is több egység hajthatja végre. Az adatokat particionáljuk, s a különböző részek más és más egységeken keresztül futnak át. A végén a részeredmények egyesítésével áll elő az eredmény. Párhuzamosság szintjei: - műveletek közötti (inter operator) egy SQL utasítást csak egy egység dolgoz fel, de párhuzamosan több SQL utasítás is végrehajtásra kerülhet műveleten belüli (intra operator) egy SQL utasítás

végrehajtásán több egység is dolgozik párhuzamosan, s a részeredmények integrálásából adódik az eredő eredmény Ideális párhuzamos DBMS jellemzői: - lineáris teljesítmény: - kétszer nagyobb hardver fele annyi idő - kétszer nagyobb hardver kétszer nagyobb feladat korlátok: 72 - startup szakasz interferencia skew Kétfázisú párhuzamos-művelet optimalizálás - első fázis: optimális végrehajtási módszer(ek) kiválasztása soros végrehajtású környezetre második fázis: a soros módszerek adaptálása a párhuzamos végrehajtásra A második fázisban a végrehajtási fa felbontásra kerül olyan részekre, melyek párhuzamosan lefuttathatók Az egyes részek kiosztása a végrehajtási egységekhez dinamikusan történik Háromfázisú párhuzamos-művelet optimalizálás - első fázis: optimális végrehajtási módszer(ek) kiválasztása soros végrehajtású környezetre második fázis: alternatív párhuzamos módszerek kidolgozása

a soros végrehajtási terven alapulva harmadik fázis: az aktuális erőforrás leterheltségek függvényében kiválasztásra kerül a legkisebb költségű párhuzamos algoritmus Egyfázisú párhuzamos-művelet optimalizálás Egy fázisban kerül végrehajtásra minden lépés Heurisztikus optimalizálási módszeren alapszik Művelet optimalizálási módszer - lépésenkéti javítás, a teljes kereső térben dolgozik - split and prune: kisebb darabokra bontva a kereső teret, a láthatóan rossz részek levágásra kerülnek Join végrehajtás Mindhárom alapmódszer párhuzamosítható: - párhuzamos nested loop egyik tábla minden processzorhoz elkerül, a másik particionálódik - párhuzamos sorted merge (rendezés + rendezett táblák darabolása) - párhuzamos hash join (bucketek kiosztása) Alap right-deep fa: R4 | R3 | R1 | | | R2 | | a jobb oldali részek csoportosításával hajtja végre join meghatározást 73 Szegmentált right-deep fa: A join-nál a

bal oldali operandus is egy eredmény tábla, melynek előállító műveletsorát nevezzük szegmensnek R5 | | R6 | | R3 | | R1 | | | R2 | Előnyei: Nem kell minden esetben az eddigi műveletek eredményét bevonni, Az egyes szegmensek kisebb tartalmúak lehetnek, s több kisebb műveletet lehet végrehajtani Serialized bushy-tree: A műveleti csomópontba mindkét oldalról komplex részeredmény jöhet be. Az egyes bemenő műveleti csomópontok között egy precedencia, prioritási szabály él, hogy egyértelmű sorossá tegyék a végrehajtást Elosztott adatbázis: Művelet végrehajtás optimalizálása elosztott adatbázisban Költségelemek: - hálózati forgalom - disk I/O - CPU - memória Query optimalizálás fázisai: - 74 szintaktikai ellenőrzés (globális séma alapján) név feloldás (globális elosztási séma lapján) szemantikai ellenőrzés (globális séma alapján) globális optimalizálás (algebrai + statisztikák) részfeladatok elküldése a

csomópontokra - lokális optimalizálás (lokális séma) végrehajtás (lokális statisztikák) A szokásos algebrai műveleti ekvivalencia szabályok alkalmazhatók Pl. projekció és szelekció sorrendje Heurisztikus irányelvek: - szelekció minél korábban - projekció minél korábban - azonos objektumot minél kevesebbszer érinteni Az előállított globális algebrai műveleti gráf felbontása részekre, fregmentekre Felbontási módszerek: - horizontális (rekordok felbontása csoportokra pl. szelekció esetén) az szelekciós join esetén is alkalmazható, konzisztens intervallumokra kell bontani az alaphalmazt A felbontás lehet fix vagy parancs függő - vertikális felbontás a mezők szerinti szétválogatás, a szelekciós feltétel mezőlistája és a projekció alapján vegyes felbontás Az optimalizálás kevésbé hatékony, ha külön van globális és lokális optimalizálás A költségfüggvények kiértékelése számos statisztikai adatot igényel A

részadatok költség értékének becsléséhez a szelektivitási faktort is becsülni kell Join végrehajtási alternatívák Három csomópont: R1, R2 és OR A két tábla R1 és R2-n foglal helyet - teljes táblák áthozatala egy csomópontra nagy a mozgatott adatmennyiség nincs párhuzamosság csak az illeszkedő rekordok áthozatala sok apró üzenet a hálózaton résztáblák illesztése sok apró üzenet párhuzamos végrehajtás lehetséges A különböző alternatívák különböző költség függvényei miatt eltérő lehet az alkalmazási intervallum 75 Szemi-join alapú végrehajtás: - egyik csomópontok az illeszkedő rekordok kiválogatása - az illeszkedő rekordok átküldése a másik tábla csomópontjára - lokális join végrehajtása A fregmentált párhuzamos végrehajtás jól illeszkedik az elosztott adatbázisokra is Minden csomópont elvégzi a megfelelő fregmensek join műveletét, s az eredményhez ezek összefűzésére kerül sor. Költség

függvény általános alakja: DiskIO költség + CPU költség + Hálózati költség Komplex költségelemek lehetnek, hiszen a költség függ többek között az alábbi elemektől: - kliens csomópont helye - adat tároló csomópontok helye - replikáció módja - fregmentáció módja - join megvalósítás módja Legfontosabb választási alternatívák: 76 - a megfelelő replikációs helyek kijelölése - join algoritmus kiválasztása - művelet végrehajtási csomópontok kijelölése Tranzakció kezelés elosztott adatbázisokban 12. témakör Tranzakció: logikailag összetartozó műveletsor ACID elvek Típusai: - normál, flat egymásba ágyazott lokális elosztott Egymásba ágyazott, hierarchikus tranzakció: Egy tranzakció futása alatt, annak keretében egy másik tranzakció is lefut. Az al és fő tranzakció logikailag nem független egymástól Az al-tranzakció függetlenül dönthet a sorsáról Többszintű beágyazás is lehetséges

Megoldandó problémák: - naplózás, recovery - szinkronizáció - integritás őrzés Elosztott tranzakció: Több csomópont is érintett a tranzakcióban Új problémák: - komponensek működésének szinkronizálása - hálózati hibák kezelése - automiság biztosítása A tranzakcióban több csomópont is részt vehet Home-node: a tranzakciót indító csomópont Gyökér tranzakció: Egymásba ágyazott tranzakciók esetén az indító tranzakció Egy csomópontra többször egymásután is újabb al-tranzakció kérés érkezhet A tranzakciók kapcsolata egy hierarchiával, fával jellemezhető. Nem kiegyensúlyozott a fa Az egyes rész tranzakciók párhuzamosan is lefuttathatók 77 Fontos elv: A teljes tranzakció hierarchia alkot egy egységet így Egy al-tranzakció visszagörgetése a teljes hierarchikus tranzakció visszagörgetését jelenti. Commit végrehajtás általános lépései - az elvégzett módosítások naplóját kiírni a REDOLOG állományba -

ROLLBACK bejegyzések törlése - Zárolások felengedése A commit kezelése az elosztott adatázisokban Vagy mindegyik csomópont véglegesíti a saját tranzakcióját vagy egyik sem Mindezt lehetőleg minimális hálózati forgalom mellett Ügyelni a fellépő hibákra is (csomópont, hálózat kiesése) Mindegyik csomópont jelezhet rollback igényt A lokális tranzakció kezelő egységnek a saját tranzakció vezérlése mellett ügyelni kell a többi csomóponton futó tranzakció kezelők jelzéseire, állapotára is. Commit-koordinátor: az csomópont, amely felelős a globális tranzakció elfogadásért vagy elvetésért a többi tagtól kapott jelzések alapján Ágens: a tagokon futó tranzakció kezelők A lehetséges commit protokollok - centralizált struktúra lineáris struktúra hierarchikus struktúra rugalmas struktúra Centralizált struktúra: A centralizált struktúrában egy kitüntetett koordinátor van. Az ágensek csak vele állnak kapcsolatban. Ágensek

között nincs kapcsolat Előny: egyszerű , az ágensek egymástól függetlenül, párhuzamosan futhatnak Hátrány: sérülékeny, nem rugalmas Lineáris struktúra: Szekvenciális commit feldolgozás 78 A lánc megszakad, ha valamely ágensnél nem sikerült a végrehajtás Előnye: kis hálózati forgalom Hátrány: sérülékeny, nem rugalmas Hierarchikus struktúra: Az ágensek között szülő-gyerek kapcsolat van Egy ágensnél az elfogadás csak akkor, ha minden gyereknél is sikeres a lezárás Továbbra is kijelölt a koordinátor Előnye: kis hálózati forgalom, gyorsabb Hátrány: sérülékeny Rugalmas struktúra: A koordinátor ágens nem fix, menet közben változhat Előnye: rugalmas Hátrány: bonyolult, nagyobb hálózati forgalom Alap kétfázisú Commit protokoll (2PC) Két fázisban történik a globális döntés meghozatala - rész eredmények begyűjtése globális döntési eredmény szétküldése Lépések: - 79 a gyökér tranzakció végénél a

gyökér a koordinátor kiküld egy PREPARE jelet minden ágensnek Az ágens fogadja a PREPARE jelet, majd lementi a REDO naplót az állományba, s bejegyzi a jel érkezését is Sikeresség esetén elküld egy READY jelet a koordinátornak, majd várakozik Sikertelenség esetén visszagörgeti a lokális tranzakciót, s küld egy FAILED jelet a koordinátornak, s felszabadítja a helyi zárolásokat A koordinátor megvárja az ágensektől küldött jelek beérkezését. Ha minden bejövő üzenet READY, akkor lezárja a helyi tranzakciót, s kiküld egy COMMIT jelet az összes ágensnek Ha legalább egy FAILED jelbejött, akkor a koordinátor visszagörgeti a helyi tranzakciót, felszabadítja az erőforrásokat. Ezután egy ABORT üzenetet küld minden ágensnek. Ha az ágens COMMIT jelet kap, akkor véglegesíti a lokális tranzakciót, majd felszabadítja az erőforrásokat Ha ABORT jelet kap az ágens, akkor visszagörgeti a helyi tranzakciót, felszabadítja az erőforrásokat,

s egy OK jelet küld vissza a koordinátornak minden ágens - Ha a koordinátor minden helyről megkapja az OK jelet, akkor lezárja a globális tranzakciót Az ágensek a READY jel elküldéséig szabadon dönthetnek a tranzakció visszagörgetéséről, utána már nem tehetik meg a visszagörgetést. A 2PC protokoll fő problémája: A koordinátor csomópont kiesése esetén a többi ágensnek várakoznia kell az igényelt szinkronizációs jelig. Az igényelt jel megérkezéséig a lokális tranzakciók foglalják, zárolják a helyi erőforrásokat. A 2PC állapot átmenetei a koordinátornál: INITIAL | WAIT | ABORTING | COMMITING | TERMINATED A 2PC állapot átmenetei az ágensnél: WAIT | | | PREPARED | | ABORTED COMMITTED A hibatűrő működéshez még egy állapot szükséges: TIMEOUT Ha a koordinátor nem kapja meg az ACK jelet minden ágenstől Az ágensnél, ha nem kap választ a PREPARED állapotban, akkor blokkolás léphet fel Megoldási javaslatok: -

többszöri próbálkozás a koordinátornál - többszöri próbálkozás a többi ágensnél ehhez ismerni kell a többi ágens címét is Recovery folyamat a csomópont összeomlása esetén Ágens helyen - ha COMMIT van a naplóban, a tranzakció sikeresen lezáródott 80 - ha ABORT van a naplóban, a globális tranzakció is sikertelen ha PREPARED a naplóban, ismeretlen a végeredmény, megpróbálja megnézni az eredményt a koordinátornál nincs bejegyzés a naplóban, visszagörgetés, még nem kezdődött el a lezárás sem Koordinátor helyen - ha COMMIT van a naplóban, a tranzakció sikeresen lezáródott, COMMIT jel küldése minden ágensnek - ha ABORT van a naplóban, a globális tranzakció is sikertelen, ABORT jel az ágenseknek - ha TERMINATED a naplóban, a helyi tranzakciók eredményeit kell lekérdezni - ha INITIAL, WAIT a naplóban, visszagörgetés Egyfázisú Commit Protokoll (1PC) Egy üzenetben megy az ágenstől a DONE és READY jel - WORK és

PREPARE az ágenshez DONE és READY a koordinátorhoz COMMIT az ágenshez ACK a koordinátorhoz Háromfázisú Commit Protokoll (3PC) A koordinátortól való függés csökkentése Lépéssorozat: - PREPARE az ágenshez READY a koordinátorhoz PRECOMMIT az ágenshez PC ACK a koordinátorhoz COMMIT az ágenshez ACK a koordinátorhoz Tulajdonsága: ha valamelyik csomópont bizonytalan az eredő eredményben, akkor egyetlen egy csomópont sem fog COMMIT lezárást választani Hálózati hibák esetén ez a protokoll is hibás eredményhez vezethet Ha koordinátor nem kap meg egy PC ACK üzenetet, akkor time-out lép fel, melynél a koordinátor tudja, hogy minden ágens igennel szavazott már, ezért elküld egy COMMIT jelet is a tagokhoz 81 Ha az ágens a COMMIT jelet nem kapja meg időben, akkor sem dönthet ő a COMMIT mellet. Ha ugyanis a koordinátor akkor állt le miután neki elküldte a PRECOMMIT jelet, amit így más ágensek még nem kaphattak meg, ezért ez a másik

ágens még bizonytalan állapotban maradt, s ekkor senki nem dönthet a COMMIT mellett. Termination protokoll (leállási protokoll) - A time-out állapotba kerülő ágens elindít egy szavazási folyamatot. A szavazás eredménye egy új koordinátor kiválasztása. Az új koordinátor elküld egy állapot lekérdező kérdést minden ágenshez Az ágensek megadják állapotukat A új koordinátor döntése: - Ha van ABORT akkor globális ABORT - Ha van COMMITTED, akkor globális COMMIT - Ha mindegyik ágens bizonytalan (PRECOMMIT előtt van még), akkor globális ABORT - Ha van commit-ra kész állapot, a koordinátor kiküld egy PRECOMMIT jelet és vár a válaszokra. Az új koordinátor csak az elérhető ágenseket veszi figyelembe a döntésnél A leálló ágenseknek maguknak kell befejezni a lezárást miután újra működő képesek Ha menetközben az új koordinátor áll le, akkor újabb szavazás következik Zárolások Követelmények: - a lokális sorossal ekvivalens

mód mellett a globális sorossal ekvivalencia is szükséges - lehetőleg kis hálózati költség - lehetőleg kevés blokkolás legyen - hibatűrés - konzisztencia a másolatok között Megoldási módok: - centralizált zárolás menedzser - particionált zárolás menedzser - elosztott zárolás menedzser A centralizált zárolás menedzser esetén egy csomópont tárolja az összes elérhető adatelem zárolási információit, ez engedélyezi a hozzáféréseket Minden zárolással kapcsolatos kérést (igény, engedély, felengedés,.) erre a csomópontra kell küldeni. 82 Előny: áttekinthető, konzisztens, ugyanolyan elv, mint a normál DBMS-nél Hátrány: nagy hálózati költség Szűk keresztmetszet a koordinátor csomópont Nincs autonómiája a tagoknak A partícionált esetben több csomópont is koordinátor, de mindegyik csak a csomópontok egy partíciójáért felelős. Előny: áttekinthető, konzisztens Továbbra is csak egy csomópont adminisztrál egy

adatelemet Hátrány: továbbra is jelentős a hálózati költség A koordinátor csomópontok között szinkronizáció szükséges Alacsony az autonómiája a tagoknak Az elosztott esetben több koordinátor csomópont van, melyek között átfedés is lehet a kezelt objektumokat tekintve Itt is a felelős koordinátort kell értesíteni a zárolással kapcsolatos eseményekről Itt nagyobb a koordinátorok közötti szinkronizációs adatforgalom Előny: Hátrány: nagyobb rugalmasság és hibatűrés Nagyobb autonómia A koordinátor csomópontok között jelentős szinkronizáció szükséges A deadlock is több csomópontra kiterjedten jelentkezhet Minden normál koordinátor csomópont csak az általa felügyelt adatrész zárolásait ismeri A zárolási adatok gyorsan változhatnak, nagy a szinkronizációs hálózati forgalom igény Megoldások: - Minden csomóponton egy globális várakozási tábla van, melyet ciklikusan körbefutó üzenetben frissít a rendszer -

Obermark algoritmus: minden csomóponton egy várakozási gráf, mely a lokális adatelemek mellett egy EXTERNAL csomópontot is tartalmaz, a más helyről jövő vagy menő zárolások részére. Ellenőrzi, s ha van ciklus a gráfban az EXTERNAL-t is beleértve, rákérdez a többieknél, hogy tényleg ciklus van-e. 83