Home - Rasfoiesc.com
Educatie Sanatate Inginerie Business Familie Hobby Legal
Doar rabdarea si perseverenta in invatare aduce rezultate bune.stiinta, numere naturale, teoreme, multimi, calcule, ecuatii, sisteme



Biologie Chimie Didactica Fizica Geografie Informatica
Istorie Literatura Matematica Psihologie

Baze de date


Index » educatie » » informatica » Baze de date
» Curs de administrare baze de date


Curs de administrare baze de date




CURS DE ADMINISTRARE BAZE DE DATE

Cap 1.      ARHITECTURA IDS




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.

  1. PROCESELE ( se mai numesc virtual processors- VP) La nivelul sistemului UNIX, aceste procese se numesc oninit. Fiecare proces apartine unei clase care indeplineste sarcini specifice.

OBS:

- VP sunt rulate ca root

- nu se omora niciodata cu kill –9 ! !!!!!

  1. Memoria partajata:

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

  1. Discul – este o colectie de 1 sau mai multe unitati de disc asignate serverului. Toate datele sunt stocate aici.

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.

Cap 2.      CONFIGURATIA CLIENT-SERVER

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

Cap 3.      INSTALARE IDS

Pasii instalarii:

  1. instalare software
  2. examinarea $INFORMIXDIR/release
  3. modificari aduse kernelului SO
  4. pregatirea spatiului
  5. pregatirea mediului
  6. fisierul sqlhosts
  7. fisierul onconfig
  8. initializare

Cap 4. MODURILE IDS

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.

Cap 5.      MONITORIZAREA SERVERULUI - generalitati

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:

  1. selectati din . .(syschunks) . pentru a afla procentul spatiului utilizat in toate chunk-urile de pe server?

Select chknum,(100*(chksize-nfree)/chksize) from sysmaster:syschunks

  1. cu ce comanda putem inlocui acest select?

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:

  1. Cum aflati id-urile sesiunilor Informix si PID ?

- ce inseamna PID? – id-ul procesului UNIX

onstat –g ses

  1. Cum se afla starea dbspace-urilor si chunk-urilor?

onstat -d

  1. Starea logurilor logice?

onstat -l

  1. Utilizand oncheck obtineti un raport asupra utilizarii discului de catre tabela items din baza dvs de date exemple_database

oncheck –pT exemple_database:items

Cap 6.      MANAGEMENTUL SPATIILOR DE DATE

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

Cap 7.      OPERATII PE SERVER

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

Cap 8.      TOLERANTA LA ERORI

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

Cap 9.      MANAGEMENTUL LOGURILOR

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

Cap 10.        EVENT ALARMS

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:

  1. Event severity code (integer)
  2. Event class id (integer)
  3. Event class message (string)
  4. Event specific message (string)
  5. Event file (string)

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.

Cap 11.        TROUBLESHOOTING

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.

Cap 12.        MONITORIZAREA SERVERULUI – IN AMANUNT

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

Monitorizarea shm

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

Monitorizarea logurilor logice

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

Monitorizare dbspace-uri si chunk-uri

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.

Se mai pot folosi comenzile:

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

Monitorizarea activitatii userilor

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>

Monitorizarea lock-urilor

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

Monitorizarea generala a server-ului

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

Cap 13.        PERFORMANTA

Administrarea performantei trebuie facuta intr-un mediu controlat si previzibil. Se cere acces exclusiv la toate componentele: hard, soft, retea.

Modelul algoritmului de performanta:

  1. executie test
  2. analiza informatiilor
  3. este performanta satisfacatoare? Daca nu – se face o singura schimbare; daca da – STOP
  4. goto 1.

Factorii care afecteaza performantele sunt:

  1. discul ( numarul de discuri si viteza lor)
  2. CPU
  3. memoria
  4. reteaua


  1. DISCUL: pentru optimizarea utilizarii discului trebuie:

micsorat numarul de citiri/scriei pe disk

maximizarea cantitatii de date citite intr-o singura operatie

fragmentarea discului

  1. CPU: pentru optimizarea utilizarii discului trebuie:

maximizat CPU USER

minimizat CPU SYSTEM

minimizata asteptarea la I/O

  1. Memorie – trebuie rezolvate 2 probleme:

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

  1. HIGH: creaza distributii pentru fiecare coloana. Se foloseste pentru:

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

  1. MEDIUM : creaza distributii pentru 85 – 99 % dein setul de valori dintr-o coloana. Se foloseste pentru tote coloanele obisnuite din tabela
  2. LOW : modifica SYSTABLES, SYSCOLUMNS, SYSINDEXES si nu creaza distributii. Se foloseste pentru toate coloanele de index pentru care high nu a fost aplicat
  3. Distribution only : nu modifica SYSTABLES, SYSCOLUMNS, SYSINDEXES si creaza distributii.

OBS: Comanda update statistics se va rula regulat ( recomandabil este sa se ruleze update statistics medium zilnic)

Cap 14.        SISTEMUL DE REPLICARE A DATELOR

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:

  1. topologii posibile
  2. elementele sistemului ER
  3. tipuri de replicare
  4. rezolvarea conflictelor
  5. replicarea datelor

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.

Cap 15.        REGULI DE CONDUITA PENTRU DBA

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.

  1. Deoarece sistemul de replicare necesita ca utilizatorul informix sa fie echivalent pe toate server-ele participante la replicare, este strict interzis accesul unui administrator de baze de date dintr-un sediu contabil la server-ele localizate in alte sedii. Este, de asemenea, interzisa realizarea unor programe proprii care acceseaza server-ele localizate in alte sucursale decat cea proprie. Trebuie mentionat aici ca toate accesurile la server-ele de baze de date sunt monitorizate de DIT.
  2. De asemenea este interzis accesul, fara aprobarea DIT, la baza de date destinata sistemului Qbank (baza de date cu numele bd scoXXX)sau a altor sisteme sau programe realizate DIT folosind alt program sau utilitar (ex. dbaccess) decat cel furnizat de DIT.
  3. Este strict interzisa utilizarea comenzii oninit –i. Aceasta comanda initializeaza server-ul informix distrugand toate bazele de date utilizator.
  4. Este de asemenea interzisa folosirea comenzii cdr cu alti parametri decat cei mentionati in acest document.
  5. Este interzisa modificarea, fara acordul DIT, chiar pentru o perioada scurta de timp, a parametrilor server-ului Informix (fisierul onconfig).
  6. Este interzisa stergerea unui dbspace sau a unui chunk pe care nu l-ati creat dumneavoastra, mai ales a dbspace-urilor dbs1 si dbs3 si a chunk-urilor pe care acestea le contin.
  7. Este interzisa modificarea modului de generare a log-urilor unei baze de date destinata unei aplicatii dezvoltata de DIT.
  8. Este interzisa crearea sau modificarea obiectelor (tabele, indecsi, proceduri etc.) dintr-o baza de date destinata unei aplicatii furnizata de DIT.

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.







Politica de confidentialitate


Copyright © 2020 - Toate drepturile rezervate