Adatbázis rendszerek III

Jegyzet

Készítette: dr. Kovács László
Miskolci Egyetem
Általános Informatikai Tanszék

1. témakör
Az Oracle adatbázis szerkezete

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
-	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 
-	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

PCTICREASE : a soron következő extent méretének százalékos növekedése az előző extent-hez viszonyítva
	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: 	exe állományok
	 	control file
		redo log
		SYSTEM tablespace
	D2:	data file
		TEMPORARY data
		control file
	D3:	index data
		control file
	D4:	rolback szegmens
		export files
	D5:	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:

-	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  felhaszná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 az 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ás és kuror adatokat tárol
-	data buffer
feldolgozás alatt álló adatelemek
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:

-	DBWR
a módosult adatelemek í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

2. témakör
Adatbázis létrehozás, paraméterek

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
-	NLS_LANGUAGE		nyelv megadása
-	NLS_DATE_FORMAT		dátum formátum
-	OPTIMIZER_MODE		optimalizálási mód
-	OS_ROLES			engedély az OS autentikációra
-	PROCESSES			processzek száma
-	OPEN_CURSORS		feldolgozás alatt álló SQL-ek száma
-	SQL_TRACE			nyomkövetési mód

Adatbázis könyvtár struktúra

	ORACLE_HOME				induló, gyökér könyvtár
		BIN					exe programok
		
		ORADATA				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/…				termékek kataklógusa
		SQLPLUS-…

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

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:
-	hatékonyság kulcseleme
-	integritási elem is egyben

indexek típusai:
-	B-fa normál
-	B-fga 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

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  tabla (mezo1 ASC| DESC,…) tárolási paraméterek;

Fordított kulcsú indexek

Az indexek felépítésénél az az előnyös, ha egyenletes 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 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

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ás 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 hiogh 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 van, mint az index

Az indexbejegyzés az 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 ….

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                                                       # INITIAL
# db_files = 80                                                       # SMALL
# db_files = 400                                                      # MEDIUM
# db_files = 1500                                                     # LARGE

control_files = ("/u01/oracle/rbdb1/control01.ctl", "/u01/oracle/rbdb1/control02.ctl")

db_file_multiblock_read_count = 8                                     # INITIAL

db_block_buffers = 8192                                               # INITIAL

shared_pool_size = 15728640                                           # INITIAL

log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800

processes = 59                                                        # INITIAL

parallel_max_servers = 5                                              # SMALL

log_buffer = 32768                                                    # 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

3. témakör
Adatok védelme, felhasználók karbantartása

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

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 mub 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
-	session szintű naplózás
-	parancs szintű naplózás

le lehet szűkíteni a figyelt objektumok és figyelt felhasználó körét

parancsa:
AUDIT sql ON obj 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_*	DBA szintű
	USER_*	felhasználó szintű
	ALL_*		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

	- 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

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 

	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;

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	instance indítás, leállítás, DB adminisztráció
	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_BASE\ORADATA\DB_NAME\*.DBF
	Paraméter állomány helye:	ORACLE_BASE\ADM\DB_NAME\PFILE\INIT.ORA
	LOG állomány		ORACLE_BASE\ORADATA\DB_NAME\REDO01.LOG
Controll állomány
		ORACLE_BASE\ORADATA\DB_NAME\CONTROL01.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

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

-	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 Agent-ekhez
			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
-	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

A csomaghoz számos kiegészítő segédprogram is kapcsolódik:

	Oracle Diagnostic Pack
	Oracle Tuning Pack
	Oracle Expert
	Oracle SQL Analyze

5. témakör
PL/SQL gyári csomagok

Package (csomag) használata

	Tárolt eljárás és függvény
		CREATE OR REPLACE PROCEDURE enev (p1 IN|OUT tip,..) AS
			PL\SQL-blokk

		CREATE OR REPLACE FUNCTION enev (p1 IN|OUT tip,..) RETURN tip AS
			PL\SQL-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

	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:

-	DBMS_ALERT		események, riasztások kezelése
-	DBMS_DDL		DDL funkciók meghívását teszi lehetővé
-	DBMS_DEBUG		debug kezelő
-	DBMS_DEFER		replicated transactional deferred remote procedure 
call
-	DBMS_IOT		segédtábla létrehozása a láncolt rekordok
 lekérdezéséhez
-	DBMS_JOB		munkaköteg kezelő rutinok
-	DBMS_LOB		LOB kezelő rutinok
-	DBMS_LOCK		zárolás kezelés
-	DBMS_LOGMNR	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_ddl.analyze_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
	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_record.comm, 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		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	ez sor olvasása 

PUT Procedure		egy sor kiírása 

NEW_LINE Procedure	sorvégjel kiírása 

PUT_LINE Procedure	sor kiírás sorvéggel

FFLUSH Procedure		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

OPEN_CURSOR Function		új kurzor nyitása SQL parancshoz

PARSE Procedure			az SQL  parancs értelmezése

BIND_VARIABLE and BIND_ARRAY Procedures	változó kötése (input)

DEFINE_ARRAY Procedure	fogadó tömb definiálás a változóhoz (output)

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

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.CLOIE_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
c       number;
d       number;
n_tab   dbms_sql.Number_Table;
indx    number := -10;
begin
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;
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;
/

6. témakör
Az Oracle speciális objektumai

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éka 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 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)
( 
      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ú

LOB mező típusok:
	BLOB		binary data
	CLOB		character data
	NCLOB	national character data
	BFILE		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()  		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_lob.file_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
SELECT b_col INTO lob_1 FROM lob_table WHERE key_value = 45;
SELECT b_col INTO lob_2 FROM lob_table WHERE key_value = 54;
retval := dbms_lob.compare(lob_1, lob_2, 5600, 33482, 128);
IF retval = 0 THEN
	….
ELSE
	…
END IF;
END;

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:
	-     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

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;

7. témakör
Oracle teljesítménynövelés és segédrutinok

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

	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(B.rowid) FROM tabla B WHERE A.id = B.id) 

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	megadott táblák
		- USER	megadott felhasználók adatai
		- FULL 	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)

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
		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

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.

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ó

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.

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 --		sales= 
(description=  
host address --		(address=(protocol=tcp)(host=sales-server)(port=1521))
service name --	 (connect_data=(service_name=sales.us.acme.com))
)

A global database name két részből áll : adatbázis név + a domain név

Hivatkozás:
Teljes paraméter megadás:
     		CONNECT 
scott/tiger@(description=(address=(protocol=tcp)(host=sales-server1)(port=1521))
     	(connect_data=(service_name=sales.us.acme.com))

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 
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
-	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. kuka.mosoda.com)
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.

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:

-	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)  		
	    )   
	  )    

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
-	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

A LISTENER.ORA állomány általános szerkezete egy TPC/IP kapcsolat esetén:

	LISTENERNAME =   
	  (ADDRESS_LIST =   
	        (ADDRESS=   
	          (PROTOCOL= )
	            (KEY= service_name) 
	        )                              
	        (ADDRESS =   
	          (PROTOCOL = TCP)   
	          (HOST = host_name) 
	          (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 (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.

9. témakör
Kliens – szerver struktúrák, tranzakció managerek

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:

	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 része)

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

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

-	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.

TUXEDO

Alkalmazás kliens

Alkalmazás kliens

Alkalmazás kliens

Funkció szerver

Funkció szerver

Funkció szerver

System/T

System/D

System/Q

System/HOST

System/WS

System/
DOMAINS

	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 fenti 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.
.

Alkalmazás szerver

Szerver

? X,Y,Z

X=3,Y=5,Z=4

Q = X + Z - Y

GET(X,Y,Z)

Q=2

PUT(Q)

Cmp

Kliens

TUXEDO

Cmp

Cmp

	A System/T modul komponensei:

-	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 kliensek és szerverek is a kódjukba beépíthetik a System/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 kapcsoló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.

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 kliens 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 kliens és a szerver 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

h1=tpacall(SERV1)

üzenet olvasás

végrehajtás (SERV1)

tpreturn()

Üzenet várakozó sorok

Alkalmazás szerver

üzenet olvasás

végrehajtás (SERV2)

tpreturn()

h2=tpacall(SERV2)

tpgetrply(h2,…)

tpgetrply(h1,…)

Alkalmazás kliens

Alkalmazás szerver

id=tpconnect(SERV1,SND)

Kapcsolódás a klienshez

tprecv(id,data)

tpsend(cd,data)

tpsend(id,data,RCV)

tprecv(id,data)

tprecv(id,data)

id

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.

10. témakör
Elosztott adatbázis kezelő rendszerek

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
	
-	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:

-	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:

-	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

	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

-	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

11. témakör
Művelet végrehajtás elosztott és párhuzamos adatbázisokban

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: 
-	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:
						R1	R2
					R3	 |           |
				R4	 |               |
				   |	        |
					|
		a jobb oldali részek csoportosításával hajtja végre join meghatározást

	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		R1	R2
			|	|	R3	 |           |
			       |		 |               |
				   |	        |
					|

		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:

-	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

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:

-	a megfelelő replikációs helyek kijelölése

-	join algoritmus kiválasztása

-	művelet végrehajtási  csomópontok kijelölése

 

12. témakör
Tranzakció kezelés elosztott adatbázisokban

	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

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
	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:

-	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
-	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

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.

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: 		nagyobb rugalmasság és hibatűrés
		Nagyobb autonómia
Hátrány: 	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.