Administrarea sistemelor de baze de date Oracle din cadrul S.C. Opcom S.A

Administrarea sistemelor de baze de date Oracle din cadrul S.C. Opcom S.A

Dupa o analiza atenta a sistemelor de baze de date ORACLE si a aplicatiilor din cadrul OPCOM S.A vom face o descriere a sarcinilor de administrare grupate pe operatii de administrare dupa cum urmeaza:

1) Backup si recovery

2)Proceduri periodice

3)Monitorizarea performantei si tuning

Backup si recovery Politicile de backup in sistemele de baze de date Oracle se fac luand in calcul anumiti factori

Dimensiunea bazei de date

Importanta informatiilor din baza de date

Frecventa cu care datele din baza se modifica

Avand in vedere acesti factori se stabileste o politica de backup pentru fiecare baza de date. Politica respectiva trebuie sa cuprinda anumiti parametrii cum ar fi frecventa cu care se realizeaza backupul, tipul backupului, etc.

Intr-un sistem de baze de date Oracle avem urmatoarele optiuni in ceea ce priveste tipul de backup:

Cold backup -acest tip de backup se efectueaza cu baza de date inchisa, deci ridica anumite probleme in sistemele de baze de date unde "availability"-ul trebuie sa fie mare

Hot backup -problema pe care o ridica acest tip de backup este faptul ca nu poate fi realizat pe sistemele care nu se afla in modul arhivare

Export -pentru acest procedeu se foloseste un "tool" oracle EXPDP care exporta informatiile din baza de date intr-un format specific, date care pot fi importate ulterior dupa nevoie.

Daca fisierele bazei de date sunt mari, politica de backup trebuie sa foloseasca un model de tip incremental, adica un backup incremental de tip 0 "full" al bazei de date cu o frecvanta mai redusa plus mai multe backupuri incrementale de tip 1, 2 etc. (backupul incremental de tip 1 salveaza pe disc doar schimbarile survenite dupa efectuarea backupului incremental de tip 0).

In cazul platformei de productie OMX din cadrul Opcom am optat pentru efectuarea unui backup "full" pe casete, o data pe saptamana pe ambele servere de baze de date Trading (dbt) si Clearing (dbc) precum si un export full o data pe zi.

Pentru Clearing am creat un script RMAN rman_command.sql care face backup complet si sterge backupurile care depasesc perioada de retentie (perioada de retentie este de 31 de zile, dupa care backupurile realizate anterior devin expired)

crosscheck backupset;

crosscheck copy;

crosscheck archivelog all;

delete noprompt expired backup ;

delete noprompt obsolete;

Backup database plus archivelog;

-comanda crosscheck verifica care din backupurile facute anterior sunt expirate. Aceste backupuri sunt sterse cu comanda delete. Comanda backup database plus archivelog creaza un backup pe device-ul default care este caseta al bazei de date si al logurilor arhivate

Acest script este exectutat cu un script in bash backup_dbcl1.sh care contine urmatoarele comenzi:

#! /bin/bash

export ORACLE_SID=dbcl1

export ORACLE_HOME=/u02/app/oracle/product/10.2.0/oraHClearing

-aceste doua linii seteaza environmentul sistemului de operare, si anume pe ce baza de date se executa comenzile ce urmeaza a fi date si respectiv locatia pe disc a softului de baze de date.

/u02/app/oracle/product/10.2.0/oraHClearing/bin/rman target / nocatalog < /home/oracle/rman_command.sql >>/home/oracle/log_backup_dbcl1.log

-cu aceasta comanda se apeleaza utilitarul RMAN care va executa comenzile din rman_command.sql (scriptul anterior in care se gasesc efectiv comenzile rman) si va scrie intr-un fisier log_backup_dbcl1.log outputul comenzilor executate.

Acest script se executa saptamanal vineri la ora 19 cu ajutorul utilitarului CRON al sistemului de operare.Pentru setarea lui s-a apelat utilitarul cu comanda

Crontab -e

In urma acestei comenzi se deschide un fisier editabil in care se introduc anumite informatii care ii spun utilitarului fisierul care trebuie executat, precum si cand acesta trebuie executat dupa cum urmeaza: prima informatie reprezinta minutul, a doua ora, a treia ziua din luna in care fisierul trebuie executat, a patra valoare reprezinta luna din an, a cincea ziua din saptamana, ultima informatie este calea fisierului de executat. Facand o combinatie a primelor 5 valori se stabileste o periodicitate a executarii fisierului.

00 19 * * 5 /home/oracle/backup_dbcl1.sh

Pentru exportul zilnic se va folosi urmatoarea metoda:

Se va crea un director pentru export cu drepturile aferente asupra lui

mkdir -p /u03/export

chown -R oracle:dba /u03/export 

chmod -R 775 /u03

Din Sqlplus se va seta directorul proaspat creat ca directorul default de export cu EXPDP

CREATE OR REPLACE DIRECTORY data_pump_dir AS '/u03/export';  si se va folosi urmatorul script in bash:

#! /bin/bash

# export backup

export ORACLE_SID=dbcl1

export ORACLE_HOME=/u02/app/oracle/product/10.2.0/oraHClearing

-la fel ca in cazul scriptului de back-up se seteaza environmentul cu comanda export

rm /u03/export/expfull.`date +%a`.dmp .

-aceasta comanda gaseste in directorul facut anterior, cel folosit pentru export, backupurile mai vechi de 7 zile dupa care le sterge, astfel ca in directorul respectiv va exista un numar constant de exporturi.

/u02/app/oracle/product/10.2.0/bin/expdp system/system FULL=y DUMPFILE=expfull date +%a`.dmp LOGFILE=expfull.log JOB_NAME=expfull

-comanda apeleaza utilitarul expdp care ii spune lui ORACLE sa realizeze un export full al intregii baze de date cu un nume de forma expfull.`date +%a`.dmp unde date+%a reprezinta ziua saptamanii in care se realizeaza exportul. Outputul comenzii este scris in fisierul expfull.log.

echo to: iulian_tote@opcom.ro ; echo Subject:Export ; echo 'exportul facut azi' ; ls -l /u03/export/expfull.`date +%a`.dmp ) | /usr/sbin/sendmail -t

-aceasta comanda ii spune sistemului de operare sa trimita un e-mail cu numele fisierului facut in urma comenzii de export anterioare catre o adresa stabilita.

Proceduri periodice : Pentru buna functionare a platformelor din administrarea OPCOM S.A. trebuie sa indeplinim niste taskuri periodice.

Pe platforma OMX e nevoie de restartarea serverelor de aplicatii si a celor de Web in fiecare zi. Acest lucru se face cu ajutorul unor scripturi care trebuiesc rulate.

Pe platforma AREVA se verifica zilnic dimineata functionarea platformei, se importa lunar xml-uri de la OMEPA pentru decontare etc. Pentru importul XML-urilor se foloseste urmatoarea procedura:

Ne conectam cu TELNET la ROWES2 (10.221.1.22)

Verificam daca fisierele de importat se gasesc in directorul /export/home/metering/d2 cu comanda ls

Daca fisierele exista ne conectam cu FTP la acelasi IP si copiem fisierele cu comanada mget *.xml dupa ce am folosit comanda binary in prealabil

Mutam fisierele din directorul c:Documents and SettingsUser1.ROUI1 in directorul Salvaredate2OmepaPREDate_luna_anVersiunea0 de pe desktop si le copiem in ROMPS1EterraImportOmepaintrare

Ne conectam remote pe ROMPS1(10.221.0.62) si executam programul decodificator.bat din c:EterraImport. Fisierele decodificate le gasim in c:EterraImportOmepa cu extensia .ready.

Fisierele decodificate trebuiesc copiate in ROMPS1EterraImportmometering_local de unde vor fi importate in baza de date. In acest timp urmarim daca importurile se realizeaza cu success din jurnalul de evenimente al aplicatiei

Daca importul s-a realizat cu success realizam 3 rapoarte in Crystal Reports: QrealizatPREparticipanti.rpt, QrealizatPRENCparticipanti.rpt, QrealizatFilialeElectricaPRE.rpt

Monitorizarea performantei si tuning Performanta bazelor de date (respectiv si a aplicatiilor) scade, in timp, din diferite motive. De exemplu: cresterea volumului de date, cresterea numarului de utilizatori ai aplicatiilor.Din punctul de vedere al administratorului bazei de date exista cateva metode pentru a urmari si creste performanta.

Vom da cateva exemple de taskuri pentru a creste perfomanta bazelor de date.

1)crearea si monitorizarea indecsilor de pe tabele:

Odata cu cresterea volumului de date, respectiv a numarului de randuri din tabele, devine necesara prezenta indecsilor pe tabelele respective pentru a spori performanta aplicatiilor in accesarea datelor.

Oracle pune la dispozitie doua tipuri de indecsi foarte folositi:

Indecsii B-tree sunt folositi pentru a evita operatiile de sortare foarte mari. De exemplu un query SQL care cere afisarea a 10000 de randuri intr-o anumita ordine va folosi un index b-tree pentru a evita operatia de sortare care ar dura foarte mult data fiind dimensiunea query-ului.

Indecsii bitmap sunt diferiti de indecsi b-tree prin aceea ca se creeaza o ordonare bidimensionala cu fiecare coloana pentru fiecare rand care va fi indexat. Fiecare coloana reprezinta o valuare distincta intr-un index bitmap.Ordonarile bidimensionale reprezinta fiecare valoare din index inmultita cu numarul de randuri din tabela . La apelarea unui rand, Oracle muta bitmapul in RAM ca sa poata fi scanat mai rapid, pentru a gasi valori corespunzatoare.Aceste valori sunt oferite lui Oracle sub forma de row-id-uri pentru accesarea directa a informatiilor respective.

Oricare tip de indecsi e folosit, acestia trebuiesc urmariti indeaproape cu toolurile puse la dispozitie de ORACLE (Enterprise Manager, Sqlplus) intrucat acestia tind sa se deterioreze o data cu cresterea in dimensiuni a tabelelor de indexat. Indecsi trebuiesc refacuti atunci cand performanta bazei de date scade.

2) arhivarea datelor:

In timp, volumul de date poate ajunge la dimensiuni foarte mari, scazand astfel din performanta bazelor de date.

Pentru a evita acest lucru se poate defini din timp o politica de arhivare la nivelul bazei de date, dupa ce s-a facut o analiza riguruoasa referitoare la necesitatea datelor vechi.

O metoda ar fi sa replicam datele mai vechi pe o alta baza de date (de pe un alt server) si apoi sa le stergem din baza de productie.

Daca dimensiunea fisierului de date nu este o problema se poate opta si pentru o alta solutie si anume: creearea unor tabele identice cu cele de unde vom arhiva datele in aceeasi baza (sau pe acelasi server) si copierea datelor vechi in aceste tabele nou creeate. Dupa ce copierea s-a facut cu succes putem sterge datele vechi din tabelele de productie.

Aceasta operatie trebuie facuta cu mare atentie pentru a asigura integritatea datelor.

Deoarece, in timp, tabelele de arhivare vor creste considerabil, este recomandata refacerea indecsilor intr-un mod corespunzator.

In concluzie se poate spune ca administrarea bazelor de date Oracle din cadrul OPCOM S.A. este o sarcina dificila orientata pe mai multe directii, care trebuie realizata cu multa atentie data fiind importanta datelor pe care le contin.