 |
|
 |  |
|
|
| |
 | Biologie | Chimie | Didactica | Fizica | Geografie | Informatica |
| Istorie | Literatura | Matematica | Psihologie |
Serverul Informix implementeaza o arhitectura multi-threaded. Asta inseamna ca:
mai putine procese sunt necesare pentru a realiza activitatile DBMS.
un proces poate sa "munceasca" pentru mai mult de o aplicatie prin folosirea threadurilor.
THREAD = secventa de instructiuni executata in interiorul unui proces in paralele cu altele.
PROCES = program aflat in executie
Aceste procese sunt cunoscute sub numele colectiv de "database server" - server de baze de date. Intrucat procesele pot fi alocate dinamic dupa cum serverul de baze de date are nevoie, s-a ajuns la denumirea "Dynamic database server". Arhitectura multithreaded permite o scalabilitate mai mare (adica daca este adaugat un user se aloca destul de putine resurse pentru acesta).
Serverul este format din trei componente majore: procesele, memoria partajata, discul.
OBS:
- VP sunt rulate ca root
- nu se omora niciodata cu kill -9 ! !!!!!
este formata din trei portiuni: rezidenta, virtuala si portiunea de mesaje.
este folosita pentru:
a) ( rezidenta) : este cea mai mare; cache al datelor de pe disc ( reduce timpul de acces ), contine bufferul de loguri (fizice, logice si cozile LRU - Least Recently Used)
b) ( virtuala) : mentinerea si controlarea resurselor necesare proceselor; pentru fiecare sesiune se stocheza inf. referitoare la tabelele folosite, proceduri stocate, date intermediare pentru agregari, sortari,etc.
c) mecanism de comunicare client - server (portiunea de mesaje),
este impartit fizic in:
CHUNK= unitate de spatiu contiguu asignata serverului; este determinat unic dupa (path,offset), organizarea este interna serverului; este cea mai mare unitate fizica. Este o limita de 2048 chunk-uri pe un server Informix. Un chunk este caracterizat prin path, offset si size. Sistemul de Operare Unix pune o limita de marime a unui chunk de 2 GB.
PAGE= unitate de baza pentru operatiile I/O; are in general marimea de 2k - 4k; minimul pe care IDS il scrie/citeste de pe disc; este o structura interna bine-definita; Toate datele de pe disc sunt memorate in pagini. Este formata din HEADER, tabela de sloturi si stampila de timp
Obs: chunk-ul poate fi vazut ca o colectie de pagini.
EXTENT= set de pagini contigue; are rol important in definirea tabelelor; marimea minima a unui extent este de 4 pagini; marimea maxima ca numar de pagini nu este limitata, dar spatiul ocupat trebuie sa fie mai mic de 2 GB. Contine pagini bitmap, pagini de date care memoreaza datele din liniile tabelelor ( fiecare linie este identificata printr-un ROWID, un integer pe 4 Bytes care contine numarul paginii si numarul slotului liniei respective; nr slotului trebuie sa fie <255, adica numarul liniilor de pe o pagina trebuie sa fie <255), pagini reminder ( contin ceea ce depaseste o pagina obisnuita), pagini de indecsi, pagini BLOB (daca tabelele contini campuri de tip BLOB), pagini goale ( care au fost alocate extent-ului dar inca nu contin date). Un extent poate fi sters daca tabela pe care o contine este drop. Marimea unui extent poate fi modificata doar in cazuri speciale si doar prin concatenare ( cu un alt extent nou creat) sau prin dublarea marimii ( la fiecare 16 exetent-e alocate, se face dublarea dimeniunii noului extent alocat). Modificarea sa manuala poate fi facuta doar prin comanda ALTER TABLE pentru tabela pe care o contine. Daca marimea dorita pentru extent este mai mare decat spatiul liber din dbspace, se va aloca doar spatiul care mai este liber in dbspace.
Obs: serverul Informix implementeaza indecsii printr-o structura B-tree adica arbori multicai. (data fiind o valoare, arborele este parcurs pana cand aceasta este gasita)
BLOB PAGE= set de pagini contigue; operatiile de input/output cu blob-uri se fac avand
BLOBPAGE ca unitate de baza (din motive de performanta); este setabil pentru fiecare BLOBSPACE
este impartit logic in:
DBSPACE=o colectie logica de chunk-uri; are cel putin un chunk (numit chunk initial); dbspace-urile pot creste si prin adaugare de chunk-uri; bazele de date si tabelele se pot crea intr-un anumit dbspace; ROOTDBS -este spatiul special ce contine datele sistemului (min.20MB); aici nu se tin tabele sau baze de date ale userilor! Exista o limita logica de 2048 dbspace-uri pe server.
TBLSPACE=o colectie logica de extenturi alocata pentru o anumita tabela intr-un anumit dbspace; contine toate paginile unei tabele (date si index) sau pentru un fragment al acesteia.; spatiul nu este contiguu
BLOBSPACE= colectie logica de chunk-uri dedicata stocarii datelor de tip Text sau Byte; este asemanator dbspace-urilor; contine BLOB-uri din mai multe tabele si chiar din mai multe baze de date; unitatea de I/O este BLOBPAGE ( poate fi setata de DBA). Blob-urile nu sunt trecute prin cache ; ele nu sunt scrise in logurile logice; cand un blob se modifica, originalul ramane pe disc pana cand logul logic ce contine informatia referitoare la modificarea acestui BLOB este salvat. Este deci necesar sa avem destul spatiu pe disc.
Mai pe larg despre ROOTDBS contine 12 pagini cu informatiile sistem. Prima pagina contine informatii generale, a doua parametrii de configurare. Incepand cu cea de-a 3-a se utilizeaza cate 2 pagini(una de rezerva, pentru ca in caz de corupere sa poata fi restaurate) pentru : checkpoints, dbspace-uri si blobspace-uri, chunk-ul primar, chunk-urile mirror-ate, paginile arhiva. Daca este nevoie sa se aloce mai mult spatiu informatiilor de sistem, atunci se vor aloca noi pagini in ROOTDBS. De obicei tabelele temporare se creaza in ROOTDBS; se recomanda desemnarea unui spatiu temporar (DBSPACETEMP) pentru acest lucru.
Fisierele de loguri logice: sunt continute initial in ROOTDBS, dar pot fi mutate ulterior. Nu sunt fisiere in adevaratul sens al cuvantului!. Sunt minim 3 si maxim 32767. Dimensiunea minima este de 200 KB. Pentru orice tip de baza de date se stocheaza aici datele si checkpointurile.
Fisierele de loguri fizice: sunt un set de pagini contigue pe disc, care se afla initial in ROOTDBS. Contine before-image ale paginilor modificate in memorie. Sunt folosite in mecanismul de Fast Recovery si arhivare. Fac parte integranta din server.
Obs: Din motive de performanta, se alege ca atat logurile logice cat si cele fizice sa rezide in spatii diferite, aflate pe discuri diferite.
Exista 3 metode posibile pentru o aplicatie client pentru a se conecta pe serverul de baze de date:
apeluri IPC - mesaje prin memoria shared ;este cea mai preferata metoda in cazul in care clientul si serverul de baze de date sunt pe acelasi host computer
pipes - este o comunicatie locala inter procese
prin TCP/IP folosind socketi sau interfata TLI
Cand o aplicatie vrea sa se conecteze pe un server de baze de date, sunt necesare anumite informatii de baza pentru a realiza conexiunea. Aceste informatii sunt tinute intr-un fisier de care trebuie sa se ocupe administratorul de sistem si care este $INFORMIXDIR/etc/sqlhosts.
Variabilele care trebuie setate in acest fisier sunt:
dbservername - este numele serverului informix
nettype - dd iii ppp unde : dd= on (IDS sau IUS) sau se (Stardard Engine)
iii= ipc(IPC connection), tli (TLI connection), soc( Socket connection)
ppp= shm(shared memory), tcp(TCP/IP protocol), spx ( IPX/SPX protocol), str(Stream pipes)
hostname= numele hostului sau adresa IP
servicename = serviciul (port) pe care se face conexiunea)
Cum se conecteaza clientul:
LOCAL: se seteaza INFORMIXSERVER si INFORMIXDIR
Se cauta o intrare in fisierul de conectivitate (sqlhosts) corespunzatoare INFORMIXSERVER
Se preiau informatiile respective si se realizeaza conexiunea
NETWORK software-ul de comunicatie cu IDS trebuie instalat
Editare in $INFORMIXDIR/etc/sqlhosts pe client
In WIN 95, 98, NT aceste informatii sunt tinute in registri
Software-ul trebuie instalat sub NT ca Administrator
Pasii instalarii:
Sunt:
Offline - serverul nu lucreaza deloc. Nu este alocata memoria shared
Initialization - este un mod intermediar in care se afla serverul cand este initializat si trece din starea Offline in starea Quiescent
Quiescent - apare cand procesul oninit ruleaza, se aloca memoria shared, dar sistemul nu da drept de acces userilor la baza de date. Doar administratorul (informix) poate accesa serverul
On-line - este cand serverul este up si lucreaza. Este modul normal de operare pentru server, permite accesul userilor la bazele de date.
Shutdown - este cand sistemul este up si ruleaza iar userii curenti acceseaza sitemul, dar nu se mai admite accesul a noi useri.
Recovery - este atunci cand sistemul realizeaza operatia de Fast Recovery sau restore. Fast Recovery apare la trecerea din Offline in Quiescent ( trebuie sa fie foarte putin timp). Procedura restore dureaza in functie de marimea sistemului care se restaureaza.
Serverul poate fi trecut dintr-o stare in alte cu ajutorul comenzilor oninit si onmode astfel:
offline -> online: oninit
offline -> questcent: oninit -s
questcent -> online: onmode -m
questcent -> offline: onmode -k
online -> questcent: onmode -s
online -> offline: onmode -k
Starile shutdown si Recovery sunt stari intermediare in care sistemul nu poate fi adus prin comenzi.
Exista mai multe utilitare pentru monitorizarea activitatii serverului:
SMI (System Monitoring Interface)
Onstat
Oncheck
SMI - este o metoda de access read-only pentru a administra informatiile relative la un system Dynamic Server care:
ofera acces SQL la structurile memoriei shared
ofera informatii despre profile pentru sesiunile specifice user
permite administratorului Dynamic Server sa monitorizeze usor si automat procesele sistemului.
Este implementat prin baza de date sysmaster. Exista o baza de date sysmaster pentru fiecare instanta Dynamic Server. Aceasta contine tabelele system si un set de tabele virtuale care servesc ca pointeri la memoria shared. Baza sysmaster se creaza automat la initializarea serverului, contine tabele false si reale folosite de ON-Archive
Restrictii:
nu se pot face lock-uri pe tabelel SMI sau utiliza nivele de izolare
nu se fac insert, update si delete
nu se pot exporta sau importa
select ROWID nu isi are rostul - da rezultate nereale
Tabele importante:
sysdatabases - contine bazele de date de pe server
systabnames - numele tabelelor din baza de date
syslogs - informatii despre logul logil
sysdbspaces - informatii despre dbspace-uri
syschunks - informatii despre chunk-uri
syslocks - informatii despre lock-uri
sysvpprof - informatii despre VP
syssessions - informatii dspre sesiuni
syssesprof - informatii despre profilul nivelului sesiunii
sysextent - informatii despre extent -uri
syschkio - statistici I/O din chunk-uri
sysptprof - informatii despre pofilul dbspace-urilor
sysprofile - informatii despre profilul sistemului
EXEMPLU:
Select chknum,(100*(chksize-nfree)/chksize) from sysmaster:syschunks
Onstat -d
Alte tabele:
sysadtinfo - informatii despre configurarea audit
stysaudit - contine reprezentarea hexazecimala a fiecarei masti audit definite
sysconfig - valori ale parametrilor de configurare
sysdri - informatii despre replicare
sysseswts - timpii de asteptare pentru useri pentru fiecare obiect
Utilitarul onstat
listeaza ceea ce se afla in structurile memoriei shared la momentul cand este rulata comanda
nici o operatie I/O pe disc nu este facuta
nu se fac lock-uri deoarece ar afecta performanta serverului
Optiuni importante:
onstat -i interactiv
onstat -g <sub_option> informatii multithread
onstat -- listeaza toate optiunile
onstat - arata starea serverului
onstat -r <value> repeat/refresh, unde value=nr de secunde
Toate optiunile:
-a : afiseaza toate informatiile
-b : afiseaza buferele
-c : fisierul de configurare
-d : chunck-uri si dbspace-uri
-g : informatii multithread
-i : interactiv
-h : informatii despre hash buffer
-k : lock-uri
-l : informatii despre loguri
-m : logul de mesaje
-p : profile
-s : latch-uri
-t : tblspace-uri
-u : threadurile userilor
-z : contorizeaza pe cei cu profil 0
-B : toate buferurile
-C : cererile clenear-ului btree
-D : starea dbspace-urilor si detalii despre chunk-uri
-F : flusher-urile de pagina
-R : cozile LRU
-x : tranzactiile
-X : intreaga lista de share si asteptari pentru buffere
-r : repeate (default este 5 secunde)
-o : pune memoria shared intr-un fisier specificat ( default este onstat.out)
Detaliere comanda onstat -g <sub_option>
SUB-Optiuni:
ath : toate threadurile
wai : toate threadurile in asteptare
act : threadurile active
rea : threadurile terminate cu succes
sle : threadurile sleeping
sch : statisticile programate ale VP
con : conditiile de asteptare
glo : informatiile globale multithreading
mem <pool name ID> : statisticile pool
seg : statistici ale segmentelor de memorie
rbm : harta blocurilor pentru segmente rezidente
nbm : harta blocurilor pentru segmente ne - rezidente
iov : statistici I/O ale discului pentru VP
iof : statistici I/O ale discului pentru chunk-uri si fisiere
ioq : statistici I/O ale discului pentru cozi
iob : utilizarea buffer-ului de catre clasa VP I/O
ntu : informatii despre profilele thread-urilor user de retea
ntt : timpii de acces ai thread-urilor user de retea
ntm : informatii despre mesajele de pe retea
sts : marimile stivelor curente si maxima
qst : statisticile cozilor
wst : statisticile thread-urilor in asteptare
ses : informatii despre sesiuni
sql : informatii despre sql-urile in realizare
dri : informatii despre replicarea datelor
Utilitarul oncheck
Este folosit pentru:
detectarea/corectarea paginilor de indecsi si date corupte
examinarea structurilor de date de pe disc
afisarea de rapoarte pe diferite structuri de date
unele optiuni ale sale plaseaza lock-uri pe tabelele procesate ( pentru ca alti useri sa nu faca update pe aceste tabele )
Are doua suboptiuni importante : -c (check) si -p (print)
oncheck -c: (verificare)
r : pagini rezervate
e : extent-uri
c : cataloagele de baze de date
i : indecsii tabelelor
I : indecsii tabelelor si rowid-urile
R : verificarea tabelelor de indecsi pe linii ( se utilizeaza cu i sau I)
d : tblspace-uri incluzand paginile bitmap
D : tblspace-uri incluzand pagini bitmap, pagini ramase si blob-uri
oncheck -p: (afisare)
r : pagini rezervate
e : extent-uri
c : cataloagele de baze de date
k : cheile din indecsi
K : cheile si rowid-urile din indecsi
l : doar cheile nodurilor frunza
L : cheile si rowID-urile nodurilor frunza
d : tblspace-uri incluzand paginile bitmap
D : tblspace-uri incluzand pagini bitmap, pagini ramase si blob-uri
t : raportul tblspace
T : raportul utilizarii tblspace-urilor de pe disc
B : utilizarea BLOB-urilor pentru o tabela
-q : afiseaza erorile din modul Quiet
-n : raspunde cu NU la toate intrebarile
-y : raspunde cu DA la toate intrebarile
Exercitii:
- ce inseamna PID? - id-ul procesului UNIX
onstat -g ses
onstat -d
onstat -l
oncheck -pT exemple_database:items
Utilitarul onmonitor:
Meniul DBSPACES contine optiunile necesare administrarii dbspace-urilor si blobspace-urilor. Optiunile accesibile sunt:
Create : permite crearea unui dbspace
Observatii: La crearea unui dbspace trebuie asignata valoarea chunk-ului initial. Pentru adaugarea ulterioara de chunk-uri se fooloseste optiunea Add_chunk . Numele dbspace-ului trebuie sa inceapa cu o litera si sa aiba maxim 18 caractere. Optiunea mirror indica daca dbspace-ul va fi mirrorat sau nu. Daca aceasta optiune este setata, atunci trebuie introdus Full pathname si offset-ul chunk-ului mirror. Daca se seteaza pe campul Temp valoare "Y", atunci in acest dbspace se vor crea doar tabele temporare. Offset indica inceputul fizic al chunk-ului exprimat in KB. Size indica marimea alocata spatiului.
BLOBSPACE : permite crearea de BLOBspace-uri (se creaza analog cu un dbspace)
Mirror : schimba statutul de mirror pentru un dbspace sau blobspace
Drop : permite stergerea unui dbspace sau blobspace cu toate chunk-urile sale.
OBS: Trebuie drop toate bazele de date si tabelele din baze din dbspace inainte de a drop-ui dbspace-ul. Rootdbspace nu poate fi drop-uit. Dupa ce se sterge un dbspace sau un blobspace, se pot reutiliza chunk-urile asignate lui. Daca se sterge un dbspace sau blobspace mirrorat, toate chunk-urile asociate chunk-ului primar si cele mirror se vor sterge.
Info : permite vizualizarea starii dbspace-urilor si blobspace-urilor, precum si chunk-urilor lor asociate
Add_chunk : permite adaugarea unui chunk (sunt necesare aceleasi informatii ca si la crearea unui dbspace sau blobspace)
Status ; permite schimbarea starii de on-line pentru un chunk
Checkpoint: datele din memoria shared sunt sincronizate cu serverul.
Apare cand:
se scurge intervalul de timp specificat de CKPT INTVL
PHYSLOG devine 75% ocupat
Se forteaza un checkpoint cu "onmode -c"
Diferite task-uri administrative
Ce se intampla?
toate threadurile utilizator sunt puse in asteptare; se intra in regiune critica
threadul Page Cleaner scrie PHYSLOG BUFFRS in PHYSLOG
toate bufferele modificate sunt scrise pe disc. Avem 2 metode: SORTED WRITE (se creaza lista de pagini de scris, se sorteaza si apoi se scriu pe disc), BIG BUFFER WRITES ( pentu fiecare 100 de pagini se aloca un asa-zis big-buffer de 8 pagini. Se fac astfel scrieri pe zonele contigue de pe disc.)
se inregistreaza CKPT in logul logic
se goleste logul fizic
se goleste logul logic pe disc
Tipuri de caderi de sistem:
System crash - tot sistemul se defecteaza
Disk crash - se defecteaza un disc ce contine o parte din datele sistemului
System failure - se corup datele de pe server
Mecanisme de recuperare:
fast recovery
disk mirroring
restaurare din arhiva
replicarea datelor
Fast recovery
este un mecanism automat pe care serverul il executa de fiecare data cand trece din modul de operare off-line in quiescent.
Atinge doua tinte: logul fizic este folosit pentru a intoarce serverul in cel mai recent checkpoint; logul logic este utilizat pentru a reface consistenta logica, acceptand toate tranzactiile comise si facand rollback la cele incomplete de la ultimul checkpoint.
Se face in trei pasi:
a) recuperarea before-images din logurile fizice; aceste pagini sunt scrise inapoi pe disc
b) se cauta in logurile logice ultimul checkpoint; se face simularea tranzactiilor respective
c) se face rollback pe tranzactiile neincheiate
Obs:
Dupa Fast Recovery toate tranzactiile incheiate inainte de crash sunt restaurate. Toate tranzactiile incomplete sunt eliminate. Serverul asigura astfel consistenta datelor.
Se restaureaza acele tranzactii care sunt scrise in logurile logice
Pentru bazele de date ce au modul de jurnalizare setat pe LOG sau ANSI, scrierile LOGICAL LOG BUFFERS apar atunci cand se inchide orice tranzactie; asta asigura consistenta ridicata.
Pentru bazele de date ce au mod de jurnalizare BUFFERED LOG, LOGICAL LOG BUFFERS se scriu in fisierele de loguri logice atunci cand devin pline - este mai eficient din punct de vedere al scrierilor, dar este mai putin sigur.
Pentru bazele de date fara jurnalizare, restaurarea din Fast Recovery nu le aduce decat la nivelul ultimului checkpoint
Disk mirroring
reprezinta folosirea unei oglinzi a chunk-urilor
scopul ei este de a preveni disk crash-urile!
Daca o eroare apare la o operatie de I/O pe chunk-ul primar, toate operatiile se vor face cu oglinda acestuia; serverul isi continua activitatea nestingherit
Pentru a determina ce actiune va face serverul cand se detecteaza o eroare I/O, se utilizeaza parametrul de configurare ONDBSPACEDOWN si anume 0 (continue), 1=abort, 2 = wait
Procesele de arhivare si restaurare
Nivele de arhivare:
nivel 0: contine o copie a tuturor datelor dintr-un server Informix sau dbspace-urile specificate, in starea in care exista la momentul in care arhivarea a fost initiata. Este arhiva de baza. Daca discurile sunt complet distruse si trebuie inlocuite, este necesara o arhiva de nivel 0 pentru a restaura datele complet.
nivel 1: contine o copie a tuturor datelor modificate de la ultima arhiva de nivel 0.
nivel 2 : contine o copie a tuturor datelor din server modificate de la ultima arhiva de nivel 0 sau 1.
Obs: este necesara o arhiva de nivel 0 cand: se adauga mirror-ul; se adauga un log logic; se schimba marimea sau locatia logului fizic,se face un drop pentru un chunk sau un dbspace
Backup-ul logurilor logice:
este procesul de copiere al continutului fisierului de loguri logice pe un alt mediu de memorie
in logurile logice se memoreaza checkpointurile, activitatile administrative, activitatea tranzactionala din baza de date
fiecare server are un numar finit de loguri logice
serverul utilizeaza logurile logice circular, inregistrarile fiind scrise serial in loguri (cand se umplu toate logurile, serverul incepe sa scrie din nou pe primul)
se face in doua moduri: automatic (este initiat explicit; se face backup al tuturor jurnalelor logice pline) si continuu (jurnalul logic este salvat de fiecare data cand se umple)
acesta trebuie facut regulat: pentru a preveni logurile logice de a se umple si bloca serverul; pentru a fi pregatiti in cazul caderii discului ce contine informatiile din logurile logice; unele tipuri de restore implica si backup-ul de loguri
Exista 3 utilitare de arhivare si restaurare:
ontape
onarchive
onbar
ontape
este cel mai simplu instrument al IDS ce ofera arhivare fizica, backup de loguri si restaurare.
are doar interfata din linia de comanda
trebuie sa fie executat doar ca login informix
arhivarea se face la nivel de sistem
trebuie folosite device-uri separate pentru backu-urile de dbspace-uri si cele pentru loguri logice, pentru simplificare
daca tape device-ul este lent, logul logic poate fi umplut mai repede decat poate fi copiat pe banda ( atentie ce device-uri se aleg)
Fisierul onconfig contine parametrii de configurare pentru archive/restore:
TAPEDEV - calea spre locul unde se face salvarea fizica
TAPEBLK- marimea unui bloc al arhivei fizice
TAPESIZE - marimea maxima arhivei fizice ce incape pe tape
LTAPEDEV - calea spre locul unde se face salvarea de loguri
LTAPEBLK- marimea unui bloc al arhivei de loguri
LTAPESIZE - marimea maxima arhivei de loguri ce incap pe tape
Optiuni:
-s pentru a realiza o arhiva fizica
-r pentru restore fizic
-a pentru a un backup al logurilor logice
-c pentru backup continuu de loguri logice
-I, -p doar pentru replicare (fac operatii de restore fizic si logic atunci cand se pune serveul in replicare cu un server secundar)
-A, -B,-N, -U sunt folosite pentru a schimba modul logging al bazei de date
Restaurarea se poate realiza in doua moduri:
cold (la rece) serverul este offline (trebuie neaparat sa fie oprit daca restauram ROOTDBS sau spatiul in care se tin logurile
warm ( la cald) serverul este online (dbspace-uri obisnuite)
2.onarchive:
poate arhiva/restaua numai anumite dbspace-uri
arhivarea/restaurarea se face in paralel
ofera criptare si compresie
permite acces sql la informatiile referitoare la arhive
ofera protectie mai buna din punct de vedere al utilizatorilor
are 3 moduri de lucru:
a) operatii supravegheate: se presupune existanta unui operator care interogheaza cu onarchive
b) operatii nesupravegheate: exista un daemon ce actioneaza ca un operator individual pentru onarchive. Daca apar erori acestea sunt transmise prin e-mail
c) situatii de urgenta: cand nu se mai poate accesa catalogul onarchive trebuie folosit un utilitar numit ondatartr
Initial, logurile fizice si logice sunt localizate in ROOTDBS. Din motive de performanta se recomanda ca logul fizic si logul logic sa nu rezide in acelasi dbspace.
La initializare trebuie specificate:
marimea logului fizic (doar un log fizic poate fi creat pe disc; marimea sa minima este de 200KB si trebuie sa fie multiplu de marimi de pagini)
marimea logului logic (minim 200 KB si sa fie multiplu de pagini. Marimea maxima este 1 milion pagini)
numarul de loguri logice ( minim 3 si maxim 32767)
numarul maxim al logurilor logice ce poate fi adaugat la sistem in parametrii memoriei shared.
Optiunea Add_log din meniul Parameters ( cu onmonitor) permite adaugarea de loguri logice la server. Serverul trebuie sa fie in modul Quiescent.
Optiunea Drop_log din meniul Parameters ( cu onmonitor) permite stergerea unui log logic. Serverul trebuie sa fie in modul Quiescent.
Optiunea Physical_log din meniul Parameters ( cu onmonitor) permite modificarea marimii si dbspace-ul de locatie pentru logul fizic.
Putem adauga sau sterge loguri logice cu comanda onparams:
Optiuni:
a). onparams -a [-d <nume_dbspace>] [-s <marime>]: permite adaugarea unui log logic
ex: onparams -a -d logspace -s 5000
b). onparams -d -l <logid> : sterge logul logic logid
c). onmode -l : avanseaza la urmatorul log
d). Onparams -p [-d <nume_dbsapce>] [-s <marime>] : modifica logul fizic
Mecanism prin care se pot lua automat anumite actiuni administrative. In momentul in care un eveniment se produce, se executa un program (poate fi si un shell, script sau un program oarecare). Pentru a specifica ce program se executa trebuie setat parametrul de configurare ALARMPROGRAM din fisierul onconfig. Programul care se executa primeste ca parametri:
Event severity code:
1 - fara importanta, nu siunt raportate catre program
2 - informatie
3 - atentie
4 - urgenta
5 - fatal
OBS: se gasesc in: $INFORMIXDIR/etc/logevent.sh; $INFORMIXDIR/etc/no_log.sh; $INFORMIXDIR/etc/log_full.sh
OBS: in cazul in care event severity code este fatal, se termina toate procesele si serverul devine offline.
In acest capitol vom incerca sa stabilim o procedura generica de rezolvare a problemelor aparute in functionarea server-ului Informix.
In momentul aparitiei unei disfunctionalitati a server-ului Informix se va proceda astfel:
se investigheaza fisierul online.log pentru a verifica aparitia unui mesaj de eroare sau avertisment;
se verifica starea serverului
in functie de mesajul aparut si de starea serverului se fac alte investigatii asupra functionarii serverului cu ajutorul comenzii onstat sau se citesc fisierului generat in momentul aparitiei unei erori critice.
in functiile de informatiile culese in pasii anteriori se stabileste o succesiune de operatii care trebuie executate
se anunta DIT asupra incidentului aparut descriind eroarea aparuta, furnizand informatiile culese in timpul investigatiei, se propune planul operatiilor de remediere a erorii stabilit la pasul 4
se aplica succesiunea operatiilor stabilite in cazul aprobarii din partea DIT, se executa operatiile propuse de DIT in cazul neaprobarii planului propriu. Dupa executarea operatiilor aprobate de DIT se anunta rezultatul obtinut urmand ca in cazul unui esec sa intervina DIT.
Exista cateva situatii in care administratorul de sistem (SA) sau administratorul de baze de date (DBA) trebuie sa intervina in configurarea serverului:
kernel prost configurat (SA)
memorie insuficienta (SA)
permisiuni gresit puse pe chunk-uri (SA)
configurare mediu prost facuta ( spatiul temporar nu a fost alocat sau alocat inadecvat; probleme de conectare la server, inclusiv configurare gresita a fisierului sqlhosts; tranzactii prea lungi; logurile logice pline sau fara permisiune de reutilizare) (DBA)
probleme de disc (SA)
Pentru expertize tehnice: vedeti comanda oncheck, fisierul onconfig si fisierul online.log, variabilele de mediu.
Monitorizarea serverului se face periodic pentru:
identificarea problemelor potentiale
determinarea configuratiei optime
asigurarea consistentei datelor
Ce se urmareste:
memoria partajata (shared memory - SHM)
discul ( dbspaces si chunk-uri)
activitatea in server ( threaduri, locks, useri, comenzi SQL)
reteaua in cazul aplicatiilor client/server
Obs: este intotdeauna important sa se extraga informatii pe o mai mare perioada de timp
Primul lucru ce trebuie inspectat este fisierul de mesaje online.log.
Sunt retinute aici:
modificari ale modului de operare al serverului
informatiile de Fast Recovery
checkpoint-urile
modificarea parametrilor de configurare
alocarea memoriei
erorile de I/O interne, apartinand S.O.
Acest fisier poate creste destul de mult in timp; din cand in cand este necesara golirea lui. Un bun obicei este de a pastra fisierul arhivat undeva.
$ cp online.log online.log.'data'
$ cat /dev/null > online.log
onstat -g seg : listeaza doar segmentele logice. Daca se aloca prea multe segmente se poate modifica fie SHMVIRTSIZE pentru a mari dimensiunea initiala a portiunii virtuale, fie SHMADD pentru a mari dimensiunea noului segment ce va fi alocat. Alocarea poate fi stopata prin setarea parametrului SHMTOTAL.
onstat -g mem: este importanta pentru a monitoriza cata memorie este folosita in portiuni diferite ale memoriei.
onstat -g ses: afiseaza pentru fiecare sesiune a unui utilizator memoria folosita (campul used memory)
onmode -a <size> - adauga un segment la portiunea virtuala
onmode -F - elibereaza segmentele nefolosite din SHM
Daca toate jurnalele logice sunt pline, atunci trebuie sa urmeze o operatie de backup al acestora.
onstat -l - va afisa o linie pentru fiecare log logic. In coloana %used este se afiseaza procentul de umplere a logului.
Flag-uri: F - liber, disponibil
B - backed up
C - curent
U - utilizat
A - adaugat, nu poate fi folosit
L - contine ultimul checkpoint
Obs: Pentru ca un log sa poata fi folosit de system, trebuie sa aiba: F sau U-B----
onstat -d afiseaza informatii despre dbspace-uri si chunk-uri. Pentru chunk-uri exista un camp "free " care afiseaza cat spatiu mai este disponibil din fiecare chunk.
onstat -g iof - prezinta statistici I/O per chunk
onstat -g iov - prezinta statistici I/O per VP
onstat -g ioq - prezinta statistici I/O per coada de I/O
onstat -g iog - prezinta statistici I/O per informatii globale I/O
Activitatile userilor ce pot fi monitorizate sunt:
nr de scriei si citiri pentru o sesiune
nr si tipul de lock-uri mentinute de o sesiune
ce fraze SQL sunt in rulare pe server
nr de thread-uri alocat
dimensiunea tabelelor temporare
tranzactiile
onstat -g ses afiseaza toti userii din sistem cu id-ul sesiunii lor, numele de login si host-name-ul.
onstat -g ses <id> afiseaza informatii specifice pentru sesiunea cu nr - id.
onstat -g sql afiseaza informatii generale despre ultima comanda sql executata de fiecare sesiune.
onstat -g sql <session_id> afiseaza informatii specifice despre ultima comanda sql pentru sesiunea respectiva
onstat -u afiseaza starea thread-urilor utilizator.
Flag-uri
Pozitia 1: S - asteptare dupa un mutex
Y - asteptare dupa o conditie
L - asteptare pe o blocare
B - asteptare pe un buffer
C - asteptare pe un checkpoint
X - curatare tranzactie lunga
G - asteptare pe o scriere in buffer
T -asteptare pe o tranzactie
Pozitia2: tranzactie activa in timp ce o operatie I/O a cazut
Pozitia 3: A - thread de arhivare
B - thread de conectare
P - thread de tranzactii distribuite
X - thread coordonator de tranzactii distribuite
C -commiting
R -rolling back
Pozitia 4: P - thread-ul primar pentru o sesiune
Pozitia 5: X -proces in sectiune critica
Pozitia 7: M - thread specific lansat de utilitarul onmonitor
D - thread daemon
C - thread cleanup
Terminarea unei sesiuni:
onmode -z <session ID>
Onstat -k
Controlul concurentei in server se face prin golirea acestor lock-uri. Pot cauza probleme de performanta destul de serioase. Cea mai comuna cauza este folosirea unei granularitati mai mari decat cea necesara. (granula se defineste in terminologia DBMS-urilor , ca fiind cea mai mica portiune pe care server-ul o poate accesa la un moment dat). Informix ofera (Database,table,page,row).
Exista 4 tipuri de lock-uri
i) Shared locks-cu ajutorul lor se mentine consistenta la citiri(type=S)
ii) Exclusive locks-sementine consistenta la scrieri .Evident un singur thread poate scrie la un moment dat intr-o granula(type=X)
iii) Update locks- se mentine consistenta la folosirea cursoarelor de update(type=U).
iv) Intent lock- lock-uri speciale, nu se supun aceluiasi regim ca celelalte! Sunt asociaote cu lock-uri de granularitate mai mare (pagina sau rand) , ele sunt la nivel de tabela!. Asigura integritatea operatiilor la nivel de tabelapentru operatiile la nivel de pagina sau rand.(type=I)
Sunt 3 tipuri:
- IS -shared locks la nivel de rand sau pagina a tabelei
- SIX shared si exclusive locks la nivel de rand sau pagina
- IX exclusive locks la nivel de rand sau pagina a tabelei
Lock-urile nu se plaseaza numai pe paginile/randurile tabelei.
Alte obiecte care necesita lock-uri sunt:
a) indecsii
b) campurile de lungime variabila
onstat -p - permite administratorului de sistem sa monitorizeze daca o resursa este sau nu suficient folosita.
Sunt trei campuri care necesita atentie:
ovlock - daca acest parametru creste, trebuie marit LOCKS
ovuserthread - daca acest parametru creste, inseamna ca sunt insuficiente thread-uri utilizator
ovbuf - daca acest parametru creste trebuie marit BUFFERS
trebuie ca lockwaits/ lockreqs * 100 < 1%
deadlks - trebuie sa nu creasca - daca da, trebuie revazuta logica aplicatiilor
Administrarea performantei trebuie facuta intr-un mediu controlat si previzibil. Se cere acces exclusiv la toate componentele: hard, soft, retea.
Modelul algoritmului de performanta:
Factorii care afecteaza performantele sunt:
micsorat numarul de citiri/scriei pe disk
maximizarea cantitatii de date citite intr-o singura operatie
fragmentarea discului
maximizat CPU USER
minimizat CPU SYSTEM
minimizata asteptarea la I/O
este memorie libera pe hard?
este serverul configurat sa utilizeze memoria eficient?
4. Reteaua: trebuie rezolvate:
se comunica cu serverul intr-un mod eficient?
sunt mecanismele de comunicare configurate optimal?
cum se pot "gazdui" un nr mai mare de utilizatori
este reteaua ok?
UPDATE STATISTICS - este cea mai importanta comanda SQL pentru imbunatarirea performantelor. Poate fi rulata pe toata baza de date (tabele, proceduri stocate), doar pentru tabelele unei singure baze de date, doar pentru o tabela, doar pentru o coloana dintr-o tabela.
Modurile comenzii:
high
medium
low
distributions only
coloana de inceput din fiecare index
toate coloanele de pe care se fac ECHIJOIN
toate coloanele de pe care se fac interogari cu un semn de egalitate
prima coloana care distinge un index compus pe o tabela de alt index compus pe aceesi tabela
OBS: Comanda update statistics se va rula regulat ( recomandabil este sa se ruleze update statistics medium zilnic)
Serverul Informix ne pune la dispozitie un sistem de procese (numit Enterprise Replication - ER) prin care seturi de date se pot replica (transfera) intre server-e distribuite in locatii diferite.
In continuare vom discuta urmatoarele chestiuni:
Topologii posibile
Exista trei topologii posibile in sistemul de replicare a datelor folosit de server-ul Informix:
a. Topologie cu server-e complet conectate
b. Topologie de tip arbore
c. Topologie de tip padure (mai multi arbori)
Topologia cu servere complet conectate este aceea in care fiecare server este conectat cu toate celelalte servere din sistem. Mesajele folosite de sistemul de replicare sunt trimise direct la server-ul destinatie nefiind necesare transferuri intermediare pentru ca un mesaj sa ajunga la destinatie. Un exemplu este prezentat mai jos:
Topologia de tip arbore este o topologie ierarhica in care exista un singur server radacina iar celelalte servere sun organizate pe nivele subordonate unui alt server. In aceasta topologie mesajele circula de la nodurile subordonate catre parinte si invers, de la nodurile parinte la cele subordonate. Un exemplu de astfel de tehnologie este urmatorul:
Topologie de tip padure consta din mai multi arbori ale caror radacini sunt complet interconectate. Un exemplu de astfel de arhitectura este prezentata mai jos:
Elementele sistemului ER
Elementele unui sistem de replicare sunt urmatoarele:
a. ER server (server de replicare) - este un server de baze de date Informix care participa in procesul de replicare a datelor. Pe acest server trebuie sa existe obligatoriu o baza de date sistem syscdr.
b. Replica - defineste un set de date (prin baza de date, tabela si coloane) pentru a fi replicate. Exista si alte proprietati ale unei replici si anume:
i. optiunile replicii: inregistrarea tranzactiilor abortate in fisiere stocate intr-un director specificat, inregistrarea randurilor abortate in fisiere stocate intr-un director specificat, formatarea canonica al mesajelor, daca se lanseaza sau nu trigger-e pentru tabelele replicate, frecventa replicarii;
ii. starea ei: activa sau inactiva;
iii. scopul: la nivel de rand sau la nivel de tranzactie:
iv. regulile de rezolvare a conflictelor;
v. participantii
c. Participant - este o entitate a sistemului. O replica contine doi sau mai multi participanti care cuprind urmatoarele informatii:
i. serverul de baza de date,
ii. baza de date in care rezida tabela,
iii. numele tabelei, proprietarul tabelei (o replica poate defini date dintr-o singura tabela),
iv. fraza SELECT care produce datele de replicat,
v. tipul participantului (optional): primar sau destinatie.
d. Grup de replici - doua sau mai multe replici grupate care pot fi pornite sau oprite simultan. Exista si un avantaj al gruparii replicilor si anume: acestea sunt executate intr-un proces separat in paralel cu celelalte grupuri. Toate replicile negrupate se executa toate intr-un singur proces.
e. Catalog replicarii - este stocat in baza de date syscdr si contine toate informatiile necesare sistemului de replicare prezentate mai sus.
Tipuri de replicare
Exista doua tipuri de replicare:
a. Sursa-destinatie (primary-target)
b. Update anyware
Replicarea de tip sursa-destinatie este impartita in doua subtipuri: unu la mai multe (folosita pentru diseminarea datelor) si mai multe la unu (pentru consolidarea datelor). In varianta unu la mai multe este specificata o singura sursa si mai multe destinatii in timp ce pentru a doua sunt specificate mai multe surse si o singura destinatie. In acest tip de replicare toate modificarile aparuta in sursa sunt transmise la destinatie iar modifcarile aparute pe server-ele destinatie nu vor fi efectuate si pe surse.
Replicare de tip update-anyware este aceea in care toti participantii sunt echivalentii. Astfel o modificare efectuata pe un participant este automat transmisa tuturor celorlalti. In acest tip pot apare mult mai multe conflicte in timpul replicarii datelor.
Rezolvarea conflictelor
Exista patru reguli de rezolvare a conflictelor aparute in timpul procesului de replicare:
a. Irgnore - se ignora orice conflict aparut
b. time stamp - rezolvarea conflictelor se face in functie de timpul la care sa efectuat operatia la sursa si de timpul modificarii sau inserarii inregistrarii la destinatie.
c. procedura stocata - rezolvarea conflictelor se va face de o procedura utilizator care primeste niste parametri specifici (timpul sursa, timpul destinatie etc.)
d. time stamp si procedura stocata - rezolvarea conflictelor se face intai in functie de cei doi timpi si daca nu se poate atunci este apelata o procedura utilizator care trebuie sa rezolve conflictul
Replicarea datelor
Replicarea datelor foloseste un mecanism de capturare a tranzactiilor pe baza analizei logurilor logice generate de server-ul sursa.
Procesul de replicare consta din trei etape:
a. Capturarea tranzactiilor - se analizeaza log-urile logice generate de server-ul sursa si se determina tranzactiile care trebuie replicate
b. Evaluarea datelor care vor fi replicate - se evalueaza imaginile randurilor care trebuie modificate inainte de inceperea tranzactiei si dupa terminarea tranzactiei si se stabileste o noua tranzactie optima. Aceste tranzactii optime se pun intr-o coada de asteptare de unde urmeaza a fi transmise, de catre procese separate, la serverul destinatie.
c. Transmiterea mesajelor de replicare si aplicarea lor la destinatie - mesajele de replicare sunt transmise la destinatie, atunci cand este posibil, in functie de disponibilitatea retelei. La destinatie aceste mesaje sunt puse de asemenea intr-o coada de asteptare de unde apoi sunt preluate de server si aplicate in baza de date. Dupa comiterea acestor tranzactii este emis un mesaj de confirmare catre server-ul sursa.
Arhitectura de replicare a CEC
Sistemul folosit de CEC este organizat ca un arbore pe doua nivele, avand o singura radacina sco00. Urmatorul nivel este compus din centre regionale, care nu sunt aceleasi cu sucursalele judetene. Pe ultimul nivel sunt toate celelalte server-e din sediile contabile. Se foloseste replicare de tip primary-target
Exista trei tipuri de replici definite:
Replici de nomenclatoare - informatia circula de la sco00 la centrele regionale care o transmit mai departe la frunze.
Replici de balante - informatia circula, in general, pe urmatoarea traiectorie: de la sediile contabile orasenesti la centrele regionale si de acolo mai departe la sediul contabil judetean de care apartine sucursala oraseneasca respectiva; de le sucursalele judetene la centrele regionale si de acolo mai departe la sco00.
Replici de OIS-uri (nu sunt active deocamdata) - informatia circula astfel: de la un sediu contabil la centrul regional de care este legat, de la acesta la sediul contabil partener daca acesta din urma este subordonat aceluiasi centru regional, daca nu informatia ajunge la sco00 si apoi la centrul regional de care apartine sediul contabil destinatie si mai departe catre acesta din urma.
Monitorizarea sistemului de replicare
In monitorizarea sistemului de replicare se urmareste:
Aparitia unor erori in acest sistem
Conectivitatea server-elor
Urmarirea cozilor de transmisie
Urmarirea tranzactiilor abortate
Erorile aparute in sistemul de replicare se pot vizualiza cu ajutorul comenzii cdr err. Orice eroare raportata de aceasta comanda se anunta la DIT, aceasta datorita documentarii insuficiente a acestor erori in manualele Informix.
Conectivitatea server-elor se verifica cu ajutorul comenzii cdr list serv. Aceasta comanda are ca rezultat, pentru server-ele frunza, doua linii una pentru server-ul local si in dreptul ei se specifica Local si una corespunzatoare server-ului regional de care acesta apartine. La aceasta din urma line se specifica starea conexiunii cu server-ul regional care poate fi: Connected, Dropped, Connecting. Starea normala trebuie sa fie Connected. Daca starea acestei conexiuni este Dropped atunci incearca oprirea si repornirea server-ului Informix. Daca nici dupa repornire nu s-a realizat conexiunea atunci se anunta centru regional sa reporneasca server-ul Informix. Daca nici dupa aceasta server-ele nu s-au reconectat se anunta DIT. In cazul in care starea conexiunii este Connecting se repeta verificarea de cateva ori la intervale de 5-10 min. Daca aceasta stare persista si dupa 3-4 verificari consecutive se procedeaza ca mai sus.
Pentru server-ele regionale rezultatul comenzii este o lista cu toate server-ele din sistem. Exista trei categorii de linii care apar: pentru server-ele frunza care tin de acel server si pentru sco00 apar linii care prezinta starea conexiunii si care pot indica cele trei stari prezentate mai sus. Pentru celelalte frunze care nu tin de server-ul respectiv apar linii care nu au nimic inscris in coloana relativa la starea conexiunii iar pentru server-ul respectiv apare o linie in care este inscris Local. In cazul in care pentru unul din server-ele frunza starea conexiunii este Dropped atunci se procedeaza la repornirea server-ului Informix frunza si apoi a celui local. Daca dupa cele doua repornirii starea ramane aceeasi se anunta DIT. In cazul conexiunii pierdute cu server-ul sco00 se reporneste server-ul local si daca conexiunea nu se restabileste atunci se anunta DIT.
Urmarirea cozilor de transmisie se face astfel: folosind dbacces se selecteaza baza de date sysmaster si se executa comanda select servername, sum(bytesqueued) from syscdrqueued group bz 1. Rezultatul acestei interogari este numarul de octeti care a fost pus in coada de transmisie pentru fiecare server cu care server-ul curent este conectat. Daca pentru un anumit server din cele listate apare un numar diferit de 0 de octeti dupa mai multe verificari facute la intervale de timp atunci se verifica conexiunea cu acel server si se incearca restabilirea acesteia. Daca dupa restabilire acea suma ramane sau nu se poate restabili conexiunea se anunta DIT.
Urmarirea tranzactiilor abortate se face prin investigarea fisierelor din directoarele $INFORMIXDIR/ris_dir si $INFORMIXDIR/ats_dir. Aparitia unui fisier nou in aceste directoare se anunta la DIT, in atentia domnului Sorin Simionescu.
Pentru buna functionare si la sa fie parametri optimi a sistemului informatic al CEC, si mai ales a sistemului de server-e de baze de date distribuite, este necesar sa fie respectate unele norme de conduita. Acestea sunt absolut necesare pentru nealterarea bazelor de date aflate pe server-ele Informix. In continuare voi prezenta cele mai importante dintre aceste norme.
Acestea sunt cele mai importante dintre aceste norme. Ca o regula generala mentionam ca alterarea oricarei baze de date destinata unei aplicatii DIT sau crearea de noi obiecte in aceste baze de date este strict interzisa si, in cazul constatarii unei astfel de actiuni, aceasta va fi sanctionata drastic.
Cei care au fost desemnati pentru urmarirea functionarii si administrarea server-elor Informix vor avea de asemenea obligatia sa aduca la cunostinta utilizatorilor aceste norme si, de asemenea, sa urmareasca respectarea lor.
Copyright © 2024 - Toate drepturile rezervate
