Analiza Workload cu Oracle

Capitolul I. Introducere

Prezentare SAP

Compania SAP a fost fondată în 1972, de cinci foști salariați IBM, în Mannheim, Germania. SAP AG este a treia companie de software din lume, după Microsoft și Oracle. SAP furnizează soluții software destinate planificării resurselor în companii, corporații și organizații.Numele SAP este un acronim și a provenit inițial din Systeme, Anwendungen, Produkte. Intretimp SAP a devenit cel mai mare producător software în domeniul ERP (Enterprise Resource Planning) și acronimul SAP provine din Systems, Applications and Products . Ideea care a stat la baza acestui program e fost aceea de a asigura clienților posibilitatea de a interacționa cu o bază de date corporativă, comună dedicată unei întregi game de aplicații software (de regulă aplicații business). Cu timpul aplicațiile oferite s-au diversificat, s-au perfecționat și astăzi multe companii, incluzând IBM și Microsoft, folosesc produsele SAP pentru a-și gestiona propriile afaceri. Ceea ce SAP propune este un sistem informațional unic într-o companie, care cuprinde toată gama de aplicații necesare și folosește o bază de date comună.

Aplicațiile SAP, dezvolvate în jurul sistemului R/3, oferă capacitatea de a gestiona finanțele, contabilitatea, operațiunile de producție, materialele, vânzările, personalul și arhiva de documente a unei companii. Sistemul R/3 poate rula pe o varietate de sisteme de operare (Windows, Unix, Solaris, etc) și folosește modelul client/server. Începând din versiunea R/3 sunt introduse și pachete orientate Internet. Astfel s-au adăugat aplicații e-business ce includ CRM și SCM (customer relationship management și supply chain management).

În ianuarie 2007 SAP AG avea 38.400 de angajați și peste 50 de țări și în jur de 36.200 de clienți în toată lumea.

Cel mai recent produs al companiei este SAP ERP. Numele predecesorului lui SAP R/3 este în strânsă legătură cu funcționalitatea să: "R" înseamnă realtime și numărul 3 se referă la o arhitectură pe trei nivele: baza de date, serever-ul de aplicații și clientul (SAPgui). SAP ERP este unul din cele cinci aplicații majore înglobate în SAP’s Business Suite.

Celelalte patru aplicații sunt:

Customer relantionship management (CRM) – ajută companiile în a-și atrage și apoi a-și păstra clienții, oferă informații detaliate de marketing și aliniază strategiile concentrate pe clienți.

Product lifecycle management (PLM) – ajută companiile producătoare oferind o sursă centralizată de informații orientate produs pentru colaborarea cu parteneri business.

Supply chain management (SCM) – ajută companiile să-și îmbunătățească flexibilitatea operațională la nivel global și asigură vizibilitate în timp real pentru clienți și furnizori.

Supplier relationship management (SRM) – clienții pot colabora apropiat cu furnizorii și pot să își integreze procesele în aplicații pentru a îmbunătăți transparența și a scădea costurile.

Alte produse importante: platforma NetWeaver și solutia Governance, Risk and Compliance (GRC).

Tema proiectultui

În acest proiect se realizează o analiză mai profundă a sistemului SAP, în scopul optimizării sistemului, și se prezintă diferite metode și tehnici de backup,restore și recovery. Arhitectura sistemului SAP descris în acest proiect folosește o bază de date Oracle 10g. Noțiunile toretice prezentate sunt însoțite îndeaproape de exemple practice și de ghiduri de aplicare a acestor noțiuni.

Proiectul este alcătuit din două capitole strict teoretice și alte două capitole cu aplicare practică. În primele două capitole se prezintă noțiuni elementare pe baza cărora se poate trece la celelalte două capitole care urmăresc, pe lângă însușirea unor concepte de administrare, însușirea deprinderilor practice necesare la optimizarea sistemului SAP.

În primul capitol se prezintă diferite arhitecturi ale sistemului SAP , precum și modul de comunicare cu baza de date.

În al doilea capitol se prezintă noțiuni de bază ale serverului Oracle însoțite de arhitectura acestuia.

În al treilea capitol se prezintă noțiunile de backup, restore și recovery. După fiecare prezentare urmează și o aplicare practică a acestor noțiuni.

În al patrulea capitol, și ultimul, se prezintă noțiuni legate de performanța sistemului, metode de optimizare și realizarea ei.

Capitolul II. Arhitectura sistemului SAP

2.1 SAP Web Application Server (SAP Web AS)

SAP Web AS oferă un mediu comun atât pentru programele ABAP cât și pentru programele Java. Împreună cu baza de date SAP Web AS formează platforma de aplicație numita și SAP NetWeaver.

Figura 2.1 SAP Web AS

SAP Web AS este rezultatul logic al dezvoltării ulterioare a SAP Application Server Technology ( cunoscută în trecut ca și SAP Basis), cu o atenție deosebită catre aplicatiile web.

SAP Web Application Server oferă:

Un mediu stabil și îndelung testat, evoluat pe parcursul a 10 ani.

Un cadru pentru execuția proceselor de tip business care necesită cele mai înalte standarde de securitate a datelor.

Un mediu user-friendly de dezvoltare al programelor (ABAP sau Java).

Compatibilitate cu standarde ca : HTTP, HTTPS, SMTP, WebDAV, SOAP, SSL, SSO, X.509, Unicode, HTML, XML, și WML.

2.2 Procesele SAP Web Application Server

Sistemul SAP constă dintr-un număr de procese paralele care lucrează împreună. În fiecare sistem aceste procese includ atât dispecerul cât și procesele de lucru SAP (work process). Numărul acestora depinde de resursele fizice disponibile ale sistemului.

Figura 2.2 Procese și servicii SAP

Tipuri de procese:

Proces de dialog. El satisface toate cererile primite de la un utilizaotr activ pentru execuția pașilor de dialog. Fiecare dispecer are nevoie de cel puțin două procese de dialog.

Proces spool. Acesta trimite secvențial datele către imprimare. Trebuie să existe cel puțin un proces spool în sistem.

Proces update. El execută cererile de reactualizare.Trebuie să existe cel puțin un proces update în sistem.

Proces background. Acesta execută programele care pot rula fără interacțiune din partea utilizatorului. Trebuie să existe cel puțin două procese background în sistem.

Proces enque. Blochează accesul la anumite obiecte ale bazei de date (tabele, vederi). Numai un singur proces de acest tip trebuie să existe în sistem.

În plus față de aceste procese mai sunt disponibile încă trei servicii care sunt folosite la comunicarea internă și externă:

Message server (MS) realizează comunicarea între dispecerele existente în sistemul SAP. Acesta este prezent doar o singură data în sistemul SAP.

Gateway server (GW) realizează comunicarea între diferite sisteme SAP sau între sisteme SAP și alte aplicații externe. Numai un singur server în sistem.

Internet Communication Manager (ICM) este un proces introdus din SAP Web AS 6.10. Acest manager permite sistemului SAP să comunice direct cu internetul. Maxim un ICM configurat pe un dispecer.

2.3 Instanța SAP

Instanță este o unitate administrativă care combină componentele sistemului SAP, furnizând unul sau mai multe servicii. Serviciile furnizate de o instanță sunt pornite sau oprite împreună. Fiecare instanță are zona ei proprie de memorie buffer.

Figura 2.3 Instanța SAP

Nivelul aplicație al sistemului SAP constă în general din mai multe instanțe; dispecerul, procesele și serviciile enumerate mai sus sunt configurate pe fiecare din aceste instanțe. Instanța în care sunt prezente atât procesul enque cât și MS (message server) se numește instanță centrală și există o singură dată într-un sistem. MS este folosit în general pentru comunicarea în interiorul sistemului (de exemplu pornirea procesului update, declanșarea proceselor background). Dispecerul unei instanțe comunică via MS cu alte instanțe, atunci când un utilizator dorește conectarea în sistem, pentru a decide care instanță este disponibilă pentru conectare.

2.4 Procesarea cererilor utilizator

Cererile utilizatorilor sunt preluate de diferite procese la fiecare dintre cele trei nivele (prezentare, aplicație, baza de date).

Datele utilizatorului sunt acceptate de SAP GUI (SAP Graphical Ușer Interface), convertite într-un format intern și înaintate către SAP Web Application Server. Procesul central al sistemului este dispecerul. Dispecerul împreună cu sistemul de operare gestionează resursele aplicațiilor scrise în ABAP. Printre principalele task-uri ale dispecerului se numără distribuirea tranzacțiilor către procese, conectarea la nivelul de prezentare și organizarea comunicării.Cererile de procesare sunt salvate într-o coadă și sunt procesate după principiul first in-first out. Dispecerul distribuie cererile către procesele de lucru disponibile. Procesarea cererilor venite din partea utilizatorilor necesită ca datele să fie citite din baza de date. Pentru acest lucru să fie posibil fiecare proces de lucru este conectat direct la baza de date.

Figura 2.4 Procesarea cererilor

Odată ce procesul returneza informațiile cerute către dispecer, care la rândul lui le trimite către SAP GUI. Acesta din urmă interpretează datele primite și generează ecranele grafice cu ajutorul sistemului de operare.

Buffer-ele duc la creșterea vitezei de procesare a cererilor. Datele care sunt citite des dar rareori schimbate sunt reținute la nivelul server-ului de aplicații în shared memory.

2.5 Interfața SAP Web Application Server cu baza de date

În cadrul ABAP (limbajul de programare specific SAP), se poate folosi SAP Open SQL (SQL = Structured Query Language, database query language) pentru a accesa datele din baza de date, indiferent de server-ul de baze folosit (Oracle,Mssql, Maxdb, DB2). Interfața cu baza de date, care face parte din fiecare proces SAP, traduce instrucțiunile Open SQL din programul ABAP în instrucțiuni SQL specifice bazei de date folosite (SQL nativ). Această procedura permite programelor ABAP să fie independente de baza de date. Când instrucțiunile Open SQL sunt interpretate interfața SAP cu baza de date verifică sintaxa instrucțiunilor și se asigură că buffer-ele SAP sunt folosite optim. Datele stocate în aceste buffer-e sunt frecvent folosite de aplicații astfel încât sistemul nu trebuie să acceseze de fiecare dată baza de date. Programele ABAP, ecranele, informațiile despre ABAP Dictionary precum și un număr de parametrii de tip business de obicei rămân neschimbați și de aceea sunt candidații ideali pentru a fi stocați în buffer. Instrucțiunile SQL native pot fi folosite direct în ABAP, dar în acest caz nu se folosesc buffer-ele locale.

Figura 2.5 Interfața SAP-Oracle

Capitolul III. Arhitectura bazei de date Oracle

Un server Oracle este un sistem de gestionare a bazei de date care asigură o platformă deschisă în accesarea informației.și constă dintr-o instanță Oracle și o bază de date Oracle.

3.1 Structura bazei de date

Fiecărei baze de date Oracle îi este asociată o instanță Oracle. Când baza de date se pornește pe un server, software-ul Oracle alocă o zonă de memorie numită System Global Area (SGA) și pornește procesele de background Oracle. Această combinație formată din SGA și procese se numește instanță Oracle. După pornirea instanței software-ul Oracle îi ascociaza acesteia o anumită bază de date. Bază de date e gata să fie deschisă, fapt ce o face accesibilă tuturor utilizatorilor autorizați. Mai multe instanțe pot rula pe același computer , fiecare accesandu-și propria bază de date.O bază de date Oracle folosește strucutri de memorie și procese pentru a gestiona și accesa baza de date. Procesele lucrează în memoria acestor computere.

Figura 3.1 Structura bazei de date Oracle

3.2 Structuri de memorie Oracle

Principalele structuri de memorie asociate unei instanțe conțin următoarele:

System Global Area (SGA) : Comună tuturor proceselor (server sau de background).

Program Global Area (PGA): Proprie fiecărui proces server și de background. Există un PGA pentru fiecare process.

SGA e o zonă de memorie care conține datele și informațiile de control ale instanței. Cuprinde următoarele strucutri de date :

Buffer cache : conține blocurile de date citite din fișierele fizice ale bazei de date.

Redo log Buffer : conține informația de redo (folosită la recovery) până când aceasta este scrisă în online redo log files (fișiere stocate pe disk).

Shared Pool : conține anumite date care sunt comune pentru toți utilizatorii.

Large pool : este o structură optională care se alocă în general pentru procese mai mari (ex în cazul operațiunilor de backup și recovery).

Java pool : e folosită pentru a stoca coduri Java și date din Java Virtual Machine (JVM).

Streams pool : folosită de Oracle Streams

La pornirea instanței cu SQL*Plus dimensiunea memoriei alocate pentru SGA este afișată. Program Global Area (PGA) este o zonă de memorie care conține datele și controlul asupra fiecărui proces de tip server.

Figura 3.2.1 Structura memoriei Oracle

Acest tip de proces deservește cererile clienților (ex utilizatori, 3rd party software). Fiecare proces server are propriul său PGA care este creat la pornirea procesului. Accesul la PGA este exclusiv fiecărui proces. Folosind structura dinamică a SGA dimensiunile pentru database buffer cache, shared pool, large pool, Java pool și Streams pool pot fi schimbate fără a opri instanța. Cele mai importante procese de background existente în Oracle sunt:

• System Monitor (SMON): Pornește procedura de recovery după ce instanța a fost repornită în urma unei erori.

• Process Monitor (PMON): Eliberează din PGA zona rezervată unui anumit proces după ce acesta s-a oprit ca urmare a unei erori.

• Database Writer (DBWn): Scrie blocurile de memorie modificate din SGA (după un commit) în data files , pe disk.

• Checkpoint (CKPT): Reactualizeaza toate data files și control files pentru a indica ultima stare validă a bazei de date.

• LogWriter (LGWR): Scrie informația din redo buffer în online redol logs existente pe disk.

• Archiver (ARCn): Crează offline redo log files din online redo log files atunci când are loc un log switch (se schimbă grupul de fișiere online redo log files în care LGWR scrie).

Figura 3.2.2 Gestiunea memoriei

3.3 Structura fizică a bazei de date. Structura logică a bazei de date

Fișierele care constituie baza de date Oracle sunt :

• Control files: Conțin date despre baza de date înseși (structura fizică a bazei). Aceste fișiere sunt critice, fără ele baza de date nu funcționează. Oracle recomandă folosirea a trei copii pentru aceste fișiere (mirror).

• Data files: Conțin informația propriuzisa care este stocată în baza de date.

• Online redo log files: Fac posibilă procedura de recovery. Dacă o eroare a bazei de date rezultă într-o pierdere de informație dar nu și o pierdere a data files atunci informația poate fi recuperată (informația care nu a fost salvată în urma instructiunii commit).

Următoarele fișiere sunt importante la funcționarea corectă a bazei de date.

Parameter file: E folosit pentru a defini configurarea instanței la pornire.Conține parametrii și valorile lor.

Password file: Permite administratorilor să se conecteze la baza de date fără ca aceasta să fie pornită, pentru a putea efectua anumite sarcini administrative.

Backup files: Sunt folosite la procedura de recovery.Din aceste fișiere se recuperează data files.

Figura 3.3.1 Structura de fișiere a bazei de date

• Archive log files: Conțin toată informația de redo generată de instanță. Ele sunt create de procesul Archiver (ARCn) din online redo log files. Sunt folosite la recovery.

• Trace files: Fiecare proces are ascociat un trace file.Când o eroare internă este detectată de proces, acesta descrie eroarea în acest tip de fișier. Informația existentă aici îi este de folos administratorului în rezolvarea acestor erori.

• Alert log files: Sunt fișiere trace speciale. Este un log cronologic al mesajelor și erorilor. Oracle recomandă consultarea periodică a acestor fișiere.

Data File și Tablespace

O bază de date este împărțită, din punct de vedere logic, în tablespace-uri.Fiecare bază de date Oracle conține SYSTEM tablespace și SYSAUX tablespace. SYSTEM conține tabele care susțin functionabilitatea bazei de date, de exemplu tabelele data dictionary. SYSAUX e un tablespace auxiliar, conține mai multe componente ale bazei de date. Pentru ca baza de date să funcționeze corect ambele trebuie să fie online.Fiecărui tablespace îi aparțin la rândul lui una sau mai multe data files.

Segmente, Extente, si Block-uri

Obiectele logice ale bazei de date cum ar fi tabelele și indecșii sunt stocate ca segmente în tablespace.Fiecare segment conține unul sau mai multe extente.

Figura 3.3.2 Structura fizică și logică a bazei de date

Un extent constă din blocuri continue de date, de accea un extent poate fi conținut în numai un data files. Block-urile de date sunt cea mai mică unitate I/O (input/output) din întreaga baza de date.Fiecărui block de date îi corespunde la nivel fizic un block al sistemlui de operare.Dimensiunea block-ului de date este configurată la instalarea Oracle, trebuie să fie multiplu de 2 KB, cea mai utilizată valoare fiind de 8 KB.

Schema e o colecție de obiecte logice care aparțin unui utilizator sau unui grup de utilizatori. Cuprinde tabele, vederi, proceduri stocate, indecși, etc.

3.4 Oracle în sistemul SAP

Fiecare bază de date este identificată în mod unic într-o rețea prin DBSID (Database System Identifier) .În sistemele SAP, DBSID trebuie să fie format din exact trei caractere. Ca și baza de date fiecare sistem SAP este unic identificat prin SAPSID (SAP System Identifier). Când instanța Oracle pornește, un proces special numit listener este pornit. Rolul acestuia este de a stabili o cale de comunicare între clienții care se conectează la baza de date și instanță. Listener-ul nu face parte din instanța Oracle. În sistemele SAP se folosesc conexiuni dedicate.Când un work process SAP solicita o conexiune listener-ul crează un proces server dedicat în instanța Oracle și stabilește conexiunea între cele două procese. Procesul server este numit și shadow process.

Figura 3.4 Conexiunea SAP – Oracle

3.4.1 NETServices

Dacă un client Oracle (ex instanță SAP) rulează pe alt server decât cel al bazei de date, comunicarea dintre procesul shadow și procesul server se realizează prin protocolul TCP/IP. Deasupra de acest protocol se află un strat software numit Oracle Net (Oracle Network Services).Work process-ul din instanța SAP configurat pe serverul bazei de date folosește protocolul IPC pentru a comunica cu procesul shadow, care rulează pe același server.Oracle Net se află atât la nivelul clientului cât și la nivelul Oracle. Pentru a putea configura conexiunile dintre SAP și Oracle există trei fișiere în directorul $ORACLE_HOME/network/admin unde $ORACLE_HOME= /oracle/<DBISD>/<release>.

EX: /oracle/PRD/10.2 /network/admin

listener.ora

Aici se configurează listener-ul. Se specifică protocolul folosit, host name, port. Trebuie să conțină toate DBSID-urile și adresele de protocol pentru care listener-ul trebuie să accepte conexiuni. Este citit ori de câte ori pornește listener-ul.

tnsnames.ora

Conține o listă de servicii disponibile pentru toate bazele de date care trebuiesc acesate din rețea.

sqlnet.ora

Poate conține informații ce țin de client: domeniul clientului, numele serviciilor sau parametrii opționali de diagnostic.

Pentru listener există un tool special cu ajutorul căruia se poate porni, opri și verifica starea acestuia. La pornirea lui procesul tnslsnr apare ,în cazul platformai UNIX, iar în cazul platformei WINDOWS apare serviciul Oracle<DBSID><Release>TNSListener. Listener-ul poate deservi mai multe servere Oracle instalate pe același computer. Pentru a apela acest tool se rulează în linia de comandă LSNRCTL.

3.4.2 Structura Directoarelor Oracle în SAP

Directoarele Oracle sunt standardizate în sistemul SAP, întotdeauna vom găsi aceeași structură. Ea este creată la instalarea sistemului SAP și nu trebuie schimbată ulterior.

dbs (sub UNIX) sau database (sub Windows) : Aici se află fișierele de profil init<DBSID>.ora sau spfile<DBSID>.ora pentru Oracle, precum și init<DBSID>.sap profilul de configurare pentru BR*Tools.

sapdata<n> : Conține toate data files-urile .

origlogA/B, mirrlogA/B :Online redo log files și copiile lor (mirror) se află aici.

oraarch : Aici se află offline redo log files. (ex <DBSID>arch1_<LSN>.dbf)

saptrace : E folosit pentru stocarea fișierelor de tip trace în saptrace/usertrace și a fișierului alert log (alert_<DBSID>.log) în saptrace/background.

Figura 3.4.2 Structura Directoarelor Oracle

saparch : Stochează log-urile scrise de BRARCHIVE.

sapbackup : Stochează log-urile scrise de BRBACKUP, BRRESTORE și BRRECOVER.

sapreorg : Stocheaăa log-urile scrise de BRSPACE.

sapcheck : Stochează log-urile scrise de BRCONNECT.

3.4.3 Variabile de mediu

Pe serverul bazei de date variabilele ORACLE_SID, ORACLE_HOME și SAPDATA_HOME trebuie întotdeauna configurate pentru utilizatorii <sapsid>adm și ora<dbsid>.

ORACLE_SID

Este ID-ul sistemului corespunzător instanței bazei de date (DBSID).

ORACLE_HOME

Este directorul principal al software-ului Oracle. Mai precis ORACLE_HOME indică directorul care conține subdirectoarele bin, dbs si network. Asta inseamnă ca întotdeauna fișierul de profil ORACLE init<DBSID>.ora sau spfile<DBSID>.ora e întotdeauna localizat în ORACLE_HOME/dbs (in %ORACLE_HOME%\database pe Windows).

SAPDATA_HOME

Este directorul care conține fișierele bazei de date. E în principal folosit de BR*Tools

Figura 3.4.3 Variabile de mediu

3.4.4 Utilizatori speciali

SYS

Este cel mai puternic utilizator din baza de date. Toate tabelele si vederile dinamice aparțin schemei SYS. El poate accesa și modifica toate informațiile din baza de date.

SYSTEM

Deși el poate accesa toate tabelele nu poate modifica tabelele data dictionary. Când se apelează un tool Sap pentru administrarea Oracle de obicei acesta se conectează la baza de date cu userul SYSTEM.

În sisteme SAP bazate pe Oracle, utilizatori speciali ai sistemului de operare sunt creați. Acești utilizatori pot accesa fișierele bazei de date, pot apela tool-uri de administrare de la nivelul sistemului de operare,se pot conecta la instanța bazei de date, etc. Acest lucru e posibil doarece Oracle și-a extins mecanismul de securitate la nivelul sistemului de operare folosind corespondențe între utilizatorii de la nivelul sistemului de operare și utilizatorii de la nivelul bazei de date, sau între grupurile sistemului de operare și autorizațiile sistemului.

Figura 3.4.4 Utilizatori speciali

Membrii grupului dba (UNIX) sau ORA_DBA (Windows) se pot conecta la baza de date având privilegiile utilizatorului SYS.

Membrii grupului oper (UNIX) sau ORA_DBA (Windows) se pot conecta la baza de date având privilegiile utilizatorului SYSTEM.

Pentru utilizatorii ora<dbsid> și <sapsid>adm (la nivel UNIX) SAP crează în baza de date Oracle utilizatorii corespunzători : OPS$ora<dbsid> și OPS$<sapsid>adm. La fel se intamplă și în cazul platformei Windows, aplicându-se prefixul OPS$<OSUSER>.

La instalare SAP crează utilizatorul SAP<SCHEMA-ID> la nivel Oracle, unde de obicei SCHEMA-ID este identic cu SAP SID. Toate tabelele și indecșii proprii SAP aparțin schemei acestui utilizator. Totuși SAP<SCHEMA-ID> nu are privilegiile necesare pentru a executa sarcini administrative asupra bazei de date. Acest utilizator este folosit de SAP pentru a scrie și a citi informații din baza de date.

Capitolul IV. Backup și Recovery

4.1 Strategii de Backup

Înainte de a efectua un backup trebuie planificată o strategie bine pregătită și necesară.În comparație cu un backup normal al unor fișiere, baza de date e o colecție de fișiere care sunt dependente unele de altele.Când se pierde un fișier al bazei de date numai recuperea lui nu e suficientă.Datele aplicației business ale sistemului SAP, stocate într-o bază de date, sunt de obicei foarte dinamce și necesită o strategie coerentă de securitate.Altfel factori externi, erori fizice și logice pot conduce la pierdei de informație.Dacă datele sunt pierdute datorită unor factori externi (calamități naturale) sau al unor erori fizice (defectarea hardware) baza de date trebuie recuperată până la momentul de timp de dinaintea producerii acestor evenimente.Dacă recuperarea este completă se pierd numai datele corespunzătoare tranzacțiilor care nu s-au încheiat cu commit la momentul producerii evenimentului.

Figura 4.1 Exemplu backup și recovery

Pentru a putea efecuta o recuperare completă a bazei de date este nevoie de toate fișierele redo log (offline și online) create de la ultimul bacukp și până în momentul apariției erorii.Dacă un fișier din lanțul de fișiere redo log lipsește sau este corupt o recuperare, folosind fișierele ce-i urmează acestuia în lanț, nu este posibilă.Astfel se face o restaurare a datelor până la primul fișier invalid din lanțul de fișiere redo log. De aceea este recomandat a se salva cel puțin două copii ale offline redo log files.

4.2 Ciclu de Backup

Un ciclu e o perioada de timp pe parcursul căreia se păstrează toate backup-urile create.De obicei in sistemele mari de producție se folosesc casete (tape). Lungimea unui ciclu e dată de perioada de retenție aplicată casetelor. Astfel o caseta nu e refolosită daca backup-ul care este salvat pe ea are o perioadă de viață mai mică decât perioada de retenție.

Figura 4.2 Ciclu de Backup

SAP recomandă un ciclu de backup de patru săptămani. El trebuie sa aibă aceeași durată atât pentru backup-ul bazei de date cât și pentru offline redo log.

Un backup online complet în fiecare zi.

Un backup offline complet cel puțin odată pe ciclu.

Un backup al fișierelor offline redo log în fiecare zi cât și după fiecare backup online sau offline.Se recomandă două copii pe casete diferite.

Pentru verificarea unui backup se efectuează un o verificare logică a bazei de date înainte sau după fiecare backup, precum și o verificare a backup-ului pentru erori fizice.Aceste verficări se fac cel puțin o dată pe durata ciclului.

Păstrarea ultimului backup offline complet al fiecărui ciclu pentru o durată mai mare de timp.

Se mai efectuează un backup după fiecare modificare a structurii bazei de date precum și după fiecare upgrade al sistemului efectuat cu succes.

4.3 Tipuri de Backup

Figura 4.3.1 Tipuri de Backup

Offline Backup

Bază de date trebuie oprită înainte ca backup-ul să pornească.Dacă baza de date a fost oprită în condiții normale (folosind SAP tools), atunci ea se află în stare consistentă, backup-ul fiind ca atare.Astfel ea poate fi restaurată fără a folosii fișierele redo log.

Online Backup

Bază de date rămâne deschisă (operațională) în timpul rulării backup-ului, se poate lucra în sistem. Bineînțeles blocurile de date copiate la începutul procesului de backup corespund unui SCN mai vechi față de cele copiate spre sfârșitul backup-ului. Pentru a restaura consistent o baza de date folosind un astfel de backup avem nevoie de cel puțin informația redo creeata în timpul procedurii de backup astfel încât toate blocurile de date din baza restaurată să se afle în starea corespunzătoare timpului la care s-a sfârșit backup-ul.Performanța sistemului scade în timpul efectuării backup-ului, se recomandă efectuarea lui în perioada cu activitate redusă (ex weekend).

Backup Complet

Este de două tipuri. Un Full backup salvează toate datele din baza de date .După terminarea backup-ului în control file sunt scrise informații suplimentare de către RMAN. Devine astfel posibilă crearea de backup-uri incrementale pe baza acestui backup.

Un whole backup salvează datele fără a scrie informația în control file. Un backup incremental ulterior nu este posibil. Din punct de vedere al datelor salvate nu este nici o diferență între cele două tipuri de backup.

Backup Incremental

Dacă există un backup complet se salvează numai blocurile de date care s-au schimbat.Se reduce cantitatea de informație ce trebuie salvată, dar nu se scurtează semnificativ timpul în care se efectuează backup-ul deoarece fiecare bloc de date trebuie verificat pentru a detecta schimbările survenite. Se poate efectua numai dacă există un backup complet efectuat în prealabil. Backup-ul incremental este efectuat de RMAN, acesta citind din control file informația necesară.SAP suportă numai backup incremental cumulativ, adică sunt salvate schimbările în raport cu ultimul backup complet și nu în raport cu ultimul backup incremental.

Backup Parțial

Dacă un backup complet durează prea mult se poate salva baza de date în părți mai mici (de exemplu numai o parte a tablespace-urilor). Suma backup-urilor parțiale trebuie să acopere toată baza de date.În cazul folosirii unui acest tip de backup timpul necesar recuperării bazei de date este mult mai mare.

Exemple

Aceste strategii depind de diferiți factori cum ar fi mărimea bazei de date, tipul casetelor, performanță hardware, etc.

Exemplul 1

Se poate folosi o strategie de backup simplă care constă în backup-uri complete

Ale bazei de date cât și din backup-uri ale offline redo log files.Pentru a recupera baza de date se restaurează fișierele din cadrul unui backup complet (de preferat cel mai recent), și apoi se aplică offline redo log files scrise în timpul și după acest backup.

Figura 4.3.2 Exemplul 1

Exemplul 2

Într-un sistem în care backup-urile incrementale pot duce la o economie de timp se pot efectua backup-uri complete mai rar și apoi pe baza lor backup-uri incrementale. Pentru a recupera baza de date se restaurează fișierele din cadrul unui backup complet se actualizează cu un backup incremental (ultimul) și apoi se aplică informația redo scrisă în timpul efectuării și după efectuarea acestui backup.De exemplu dacă o eroare apare joi se restaurează backup-ul complet de luni și apoi cel incremental de miercuri, apoi se aplică toată informația de redo existentă.

Figura 4.3.3 Exemplul 2

Exemplul 3

Dacă se folosesc backup-uri complete create odată pe săptămâna atunci se pot efectua backup-uri parțiale în zilele rămase ale săptămânii. Timpul necesar recuperării datelor este mai mare. Astfel dacă o eroare apare în ziua de joi atunci se restaurează backup-ul de luni și apoi se aplică toată informația de redo creată de luni până joi, de aici rezultă și timpul necesar foarte mare.

Figura 4.3.4 Exemplul 3

4.4 Instrumente SAP pentru Backup, Restore si Recovery

Instrumentele dezvoltate de SAP pentru administrarea Oracle include programe pentru backup-ul bazei de date și al altor fisiere aparținând sistemului SAP, cât și programe pentru restaurarea fișierelor lipsă și aducerea lor la stări consistente.

Programul BRBACKUP efectuează backup pentru data files,control file și redo log files atunci când e necesar.Mai poate fi folosit și pentru backup-ul directoarelor Oracle și a directoarelor de sistem ale SAP.

Programul BRARCHIVE efectuează backup pentru offline redo files.

Programul BRRESTORE restaurează toate fisierele care aparțin sistemului bazei de date, data files și offline redo log files, din backup-uri existente.

Programul interactiv BRRECOVER verifică lipsa fișierelor din baza de date, apelează BRRESTORE pentru restaurarea lor și apoi recuperează datele folosind offline redo files si pornește baza de date.

Atât BRBACKUP cât și BRARCHIVE inregistrează acțiunile efectuate în fișiere log.Acestea sunt apoi analizate și folosite de BRRESTORE pentru a restaura fișierele lipsă. BRBACKUP și BRARCHIVE suportă efectuarea backup-urilor pe casetă și HDD cât și prin interfața cu alte programe specializate de backup (third party tool).

Figura 4.4.1 Instrumente de Backup

4.4.1 Configurarea instrumentelor SAP pentru Backup si Restore

Profilul de inițializare init<DBSID>.sap conține parametrii care determină modul în care BRBACKUP, BRARCHIVE, BRRESTORE realizează diferite funcții.Se gaseste de obicei în directorul $ORACLE_HOME/dbs (UNIX) sau %ORACLE_HOME%\database (Windows). Pentru a configura comportamentul instrumentelor SAP se editează acest fișier cu un editor text. Dacă apoi se pornește un instrument din linia de comandă fără opțiuni suplimentare valorile din fișier sunt folosite.Dacă valoarea unui parametru nu e specificată în fișier se folosește o valoare default. Dacă se pornesc BRBACKUP, BRARCHIVE din linia de comandă cu opțiuni acestea suprascriu valorile aferență din profilul de inițializare. Următorii parametrii sunt cei mai importanți pentru configurarea BRBACKUPsi BRARCHIVE:

backup_mode

Determină tipul de backup efectuat. Pentru valoarea all se realizează un whole backup iar pentru valoarea full se realizează un backup complet (full backup).Pe baza acestuia se poate efectua mai târziu backup-uri incrementale.Acestea se realizează specificând valoarea incr. Dacă se specifică numele unui tablespace al unui director sau ID-ul unui fișier se va efectua un backup parțial. Pentru valorile ora_dir și sap_dir se realizează bacup pentru directorul software al Oracle respectiv directorul sistem al SAP.

backup_type

Cu acest parametru se poate alege între online sau offline backup.

backup_dev_type

Acest parametru specifică mediul de salvare al backup-ului.Se pot specifica valorile tape, disk sau util_file/ util_file_online dacă se folosește un program extern de backup ce comunică prin interfata BACKINT.

tape_copy_cmd

Specifică tipul comenzii folosite pentru a copia fișierele de pe disk pe casetă (cpio,dd,rman).Acest parametru nu afectează dispozitivele raw (întotdeauna sunt copiate cu DD) și nici directoarele (întotdeauna sunt copiate cu CPIO).Fișierele de tip log cât și init<DBSID>.ora, init<DBSID>.sap sunt mereu scrise cu CPIO.

disk_copy_cmd

Specfică tipul comenzii folosite la copierea fișierelor pe un disk local. Valoarea copy corespunde valorii cp sub Unix și valorii copy sub Windows.

expir_period, tape_use_count

Sunt folosiți la gestionarea casetelor și precizează perioada de retenție respectiv de câte ori se recomandă scrierea pe un volum de casete.

volume_backup, volume_archive

Precizează numele volumelor ce urmează a fii folosite pentru backup utilizând comanda BRBACKUP, respectiv numele volumelor ce urmează a fii folosite pentru backup-ul offline redo log files utilizând comanda BRARCHIVE. Dacă se specifică mai multe volume acestea trebuie separate prin virgulă și incluse intr-o paranteză.

tape_address, tape_address_rew

Valorile acestor parametrii identifică adresele dispozitivelor care gestionează casetele folosite la backup cu opțiunea no rewind respectiv rewind.

Figura 4.4.2 Profile de Backup

E recomandat sa se folosească DD în loc de CPIO pentru copierea data files pe casete deoarece DD e mult mai rapidă și astfel timpul necesar efectuării backup-ului poate fi redus semnificativ. Pentru cea mai bună performanță se specifică block size (la copierea între disk și casete) la cel puțin 64 KB folosind parametrii dd_flags si dd_in_flags.

4.4.2 Integrarea RMAN (Oracle Recovery Manager) in SAP Tools

RMAN este instrumentul folosit de Oracle pentru backup și restore.Executabilul rulează într-un proces client și se conectează la baza de date la fel cum face și SQL*Plus. Prin integrarea acestui instrument în BRBACKUP și BRARCHIVE SAP a adăugat mai multă flexibilitate. BRBACKUP utilizează RMAN la backup-ul bazei de date în două moduri diferite:

RMAN e capabil să clasifice un backup complet ca un așa zis backup de nivel 0 (full backup) care poate servi că baza pentru backup-urile de nivel 1 (incremental backup).

Datele pot fi scrise pe casete (sau alte medii de backup) cu RMAN, în locul metodelor CPIO și DD specifice sistemelor de operare.

RMAN poate efectua backup direct pe disk dar nu direct pe casetă. Pentru backup pe casetă RMAN folosește interfața SBT (SystemBackup to Tape) dezvoltată de Oracle.Înainte de a folosi RMAN pentru backup trebuie instalate următoarele librării:

Când nu se folosește un utilitar extern de backup se instalează librăria SBT dezvoltată de SAP. Aceasta se găsește în folderul /usr/sap/<SAPSID>/SYS/exe/run și este copiată la instalarea sistemului SAP. Pentru a fi folosită se configurează parametrii backup_dev_type = tape/tape_auto/tape_box și tape_copy_command = rman.

Când se folosește un utilitar extern de backup trebuie instalată librăria SBT proprie utilitarului.

Avantaje la folosirea RMAN la backup:

Toate blocurile de date sunt verificate. Aceasta asigură că fiecare backup efectuat cu succes conține baza de date într-o stare consistentă astfel verificări ulterioare ale backup-ului devin inutile.

Numai blocurile de date folosite sunt copiate pe mediul de backup. Totuși blocurile care sunt goale dar au fost folosite în prealabil sunt copiate.

În cazul unui backup online tablespace-urile sunt trecute în modul back-up (back-up mode) pentru a putea fi evitate inconsistențele (se evită scrierea unui bloc de date în timp ce acesta e copiat).

Un backup complet (whole backup) sau parțial sunt posibile cu RMAN folosind următoarele valori pentru parametrii: tape_copy_cmd = rman sau disk_copy_cmd = rman, backup_mode = all sau backup_mode = <object_list> .

4.5 Efectuarea Backup-urilor

In afară de data files BRBACKUP mai salvează și control file și profilele de configurare cât și anumite fișiere de log. Un backup complet offline salvează și online redo log files. BRARCHIVE are ca principală activitate salvarea offline redo log files pe mediul de backup și în plus salvează profilele si alte fișiere de log.

Figura 4.5.1 Efectuarea backup-urilor

4.5.1 Faze ale procesului de Backup

Anumiți pași ai backup-ului online și offline sunt identici.Ambele tipuri de backup scriu un header (etichetă) pe casete, la începutul backup-ului și citesc această etichetă atunci când backup-ul se sfârșește. Prin această citire BRBACKUP verifică dacă scrie pe caseta corectă.Când se rulează un backup online control file nu poate fi salvată, de aceea la începutul backup-ului se realizează o copie consistentă a acestui fișier pe disk. Această copie e salvată pe casetă după ce toate data files au fost scrise. Într-un backup online standard fără a se folosi RMAN și o librărie SBT, fiecare tablespace este trecut în așa zisul mod backup (ALTER TABLESPACE BEGIN BACKUP) .Procedura este dupa cum urmează:

E declanșat un checkpoint la nivel de tablespace înainte ca backup-ul să înceapă.

și DBWR copiază toate dirty blocks corespunzătoare acestui tablespace în datafiles.

SCN tablespace-ului aflat în mod backup rămane neschimbat până la sfarșitul procedurii.

Toate datele care se introduc în acest timp (user data) nu mai sunt salvate la nivel de data files (din cauza că SCN ramane blocat;backup-ul trebuie să fie consistent) ci sunt salvate în redo log files. Când ultimul data block a fost salvat cu success, modul backup se sfârșește și tablespace-ul este resetat (ALTER TABLESPACE END BACKUP).

Figura 4.5.1.1 Online vs. Offline backup

Un backup online efectuat cu RMAN nu trece tablespace-urile în mod backup deoarece RMAN garantează că fiecare data block este copiat pe mediul de backup într-o stare consistentă.La sfârșitul unui backup online Oracle efectuează un log switch.Acum se trece la backup-ul offline redo log files și astfel se asigură că toată informația scrisă în baza de date în timpul backup-ului este salvată pe mediu.Acest lucru devine foarte folositor în cazul unei restaurări a bazei de date, deoarece toată informația necesară este disponibilă.

Sunt mai multe interfețe prin care se poate porni sau programa un backup. Indiferent de cea care este folosită în cele din urmă mereu vor fi folosite BRBACKUP și BRARCHIVE la nivelul sistemului de operare. La apelarea acestor programe valorile parametrilor specificate în linia de comandă au cea mai mare prioritate.La nivelul SAP se poate folosi tranzacția DB13 (Calendar DBA). Aici se pot programa diferite tipuri de backup, și este metoda recomandata.Sarcinile create aici sunt defapt sarcini la nivel SAP care apelează BRBACKUP ȘI BRARCHIVE și pot fi monitorizate cu tranzacția SM37.O altă metodă de a programa backup-urile este folosirea calendarului la nivel de system de operare (ex: UNIX: Cron, WINDOWS: Task Scheduler).

Figura 4.5.1.2 Instrumente backup

4.5.2 Efectuarea Backup-urilor folosind BR*Tools

La rularea din linia de comandă a BRTOOLS apare următorul meniu:

BRBACKUP main options for backup and database copy

1 – BRBACKUP profile (profile) ……. [initT00.sap]

2 – Backup device type (device) …… [tape]

3 ~ Tape volumes for backup (volume) . []

4 # BACKINT/Mount profile (parfile) .. []

5 – Database user/password (user) …. [/]

6 – Backup type (type) …………… [offline]

7 – Back up disk backup (backup) ….. [no]

8 # Delete disk backup (delete) …… [no]

9 ~ Files for backup (mode) ………. [all]

Standard keys: c – cont, b – back, s – stop, r – refr, h – help

–––––––––––––––––––––-

BR0662I Enter your choice:

Valorile prestabilite sunt citite din fișierul de inițializare init<SAPSID>.sap):

Backup device type (device)

Specifică dispozitivul pe care backup-ul va fi realizat.Principalele tipuri de dispozitive sunt:

tape pentru un backup pe casete;tape_auto și tape_box suportă roboții de casete.

disk pentru un backup pe un director local specificat prin parametrul backup_root_dir din fișierul init<DBSID>.sap.

util_file și util_file_online pentru backup-uri ce folosesc instrumente externe prin BACKINT

rman_disk pentru a folosi RMAN și libraria externa SBT.Sunt salvate pe disk profilele, control file și log files; rman_util pentru a folosi RMAN și libraria externă SBT.Sunt salvate profilele, control file și log files cu BACKINT.

Tape volumes for backup (volume)

Dacă dispozitivul este tape, tape_auto sau tape_box, se poate specifica opțional volumul.

Backup type (type)

Cu acest parametru se poate alege între online sau offline backup.Pentru a forța baza de date să se oprească chiar și cand SAP e pornit se folosește offline_force.

Back up disk backup (backup)

BRBACKUP asigură o strategie backup în două faze. Prima faza constă în efectuarea backup-ului pe disk și a doua faza constă în salvarea backup-ului pe casetă. Se selecteaza yes pentru a salva un backup precedent de pe disk pe casetă și cu ajutorul opțiunii Delete disk backup (delete) dacă se dorește stergerea backup-ului de pe disk după ce a fost salvat cu success pe caseta.

Files for backup (mode)

Se pot specifica tipurile de backup prin valorile (all|full|incr).Pentru un backup parțial se specifică tablespace-urile care se doresc a fi salvate pe mediul de backup.

Backup-uri partiale

În cazul unor backup-uri partiale suma individuală a lor trebuie să acopere întreagă bază de date într-un interval de timp în care în mod normal s-ar efectua un backup complet.Atât Oracle cât și SAP asigură restaurarea bazei de date din diferite seturi parțiale de backup.Pentru această e nevoie și de offline și online redo log files generate de la cel mai vechi backup parțial.Pentru a ne asigură că toată bază de date e cuprinsă în procesul de backup se folosetse opțiunea -f|-fill <days> pentru BRBACKUP.Astfel într- un număr de zile (<days>) întregul set de backup este complet.Această opțiune nu e disponibilă în tranzacția DB13.

Figura 4.5.2.1 Backup parțial

4.5.3 Offline Redo log file Backup

După fiecare log switch procesul Oracle ARC0 copiază online redo log file precedent (cel folosit înainte de switch) în directorul oraarch și crează offline redo log file corespunzător.BRARCHIVE copiază acest fișier nou creat din acest director pe mediul de backup.Offline redo log file poate avea mai multe stări în BRARCHIVE. Aceste stări sunt reactualizate în fișierul de log arch<DBSID>.log după rularea BRARCHIVE:

În timpul unui backup pe casetă, offline redo log file are starea ARCHIVE. La prima salvare starea fișierului devine SAVED; la a doua salvare starea se schimbă în COPIED; după stargere starea devine DELETED.

În timpul unui backup pe disk, offline redo log file are starea DISK. O a doua copie nu e disponibilă. Singurele stări valabile aici sunt DISKSAV (prima salvare pe disk) și DISKDEL (ștergere după o salvare pe disk).

BRARCHIVE are mai multe opțiuni de apelare care determină cum offline redo log file sunt procesate.SAP recomanda opțiunea -cds (copy_delete_șave), care e valoarea predefinita când se apelează BRARCHIVE din tranzacția DB13:

La început toate offline redo log files care au starea SAVED sunt salvate pe casetă pentru a doua oară și apoi șterse de pe disk.

Apoi toate offline redo log files cu starea ARCHIVE sunt salvate pe casetă pentru prima data și starea este schimbată în SAVED.

Figura 4.5.3.1 Offline Redo log file Backup

După backup toate offline redo log files se află în două locații: fie în directorul oraarch și pe casetă sau pe două casete diferite. Pentru a realiza un backup al offline redo log files se pornește BRTOOLS sau BRGUI și se selectează Backup and database copy -> Archivelog backup.

Următorul meniu apare:

BR0657I Input menu 17 – please check/enter input values

–––––––––––––––––––––

BRARCHIVE main options for archivelog backup

1 – BRARCHIVE profile (profile) …… [initT00.sap]

2 – BRARCHIVE function (function) …. [save]

3 – Backup device type (device) …… [tape]

4 ~ Tape volumes for backup (volume) . []

5 # BACKINT/Mount profile (parfile) .. []

6 – Database user/password (user) …. [/]

7 – Maximum number of files (number) . [100000]

8 – Back up disk backup (archive) …. [no]

Standard keys: c – cont, b – back, s – stop, r – refr, h – help

–––––––––––––––––––––

BR0662I Enter your choice:

Se selectează functia BRARCHIVE din meniu.Aproape orice combinație save, copy și delete e posibilă. Folosind funcții diferite rezultă:

Implementarea unei strategii în două faze: prima rulare salvează noile offline redo log files (save), a doua rulare crează o a doua copie și șterge fișierele copiate cu success a doua oară (second_copy_delete)

Crearea unui backup paralel pe două stații de casete diferite (double_save) și ștergerea ulterioară (delete_copied).

Indiferent de strategia aleasă trebuie să existe cel puțin două copii ale offline redo log files în orice moment.

4.5.4 BRBACKUP și BRARCHIVE: Strategia unei singure rulări

Avantajul acestei strategii e acela că se poate crea un backup complet al bazei de date și al offline redo log files într-o singură rulare.BRBACKUP și BRARCHIVE sunt apelate simultan. Numai un singur set de casete e folosit (specificat prin parametrul volume_backup). Offline redo log files sunt salvate pe aceleași casete pe care sunt salvate și data files.Pentru a putea defini această strategie se folosește opțiunea -a|-archive, iar după aceasta urmează opțiunile pentru BRARCHIVE. O sarcină corespunzătoare poate fi definită în tranzacția DB13. Cu această procedură BRBACKUP salvează datele în mod normal și apoi apelează BRARCHIVE pasându-i opțiunile introduse după -a|-archive. BRARCHIVE mai intâi salvează redo log files (ca de obicei) și apoi toate log-urile inclusiv pe cele ale BRBACKUP.

Figura 4.5.4 BRBACKUP și BRARCHIVE strategia unei singure rulări

4.5.5 Backup online consistent

Un astfel de tip de backup conține date consistente. Asta înseamnă că offline redo log files generate în timpul backup-ului sunt salvate pe același volum ca și data files. După ce salvează toate data files BRBACKUP efectuează un log switch, așteaptă până când ARC0 (archiver process) a terminat de copiat toate fișierele în direcotrul oraarch, și apoi copiază pe casetă fișierele din acest director. Ultimele fișiere scrise pe casetă sunt log-urile corespunzătoare lui (ex summary log)..

Backup-ul offline redo log files într-un backup online consistent e controlat în toatalitate de BRBACKUP. De aceea această rulare e independentă de backup-urile efectuate de BRARCHIVE și nici nu le afectează pe acestea. În mod special nici o linie nu e modificată în arch<DBSID>.log.

Acest backup poate fi efectuat ori ca un backup de tip whole, de tip full sau de tip incremental.Nu poate fi programat în tranzacția DB13. Poate fii de altfel folosit pentru a reseta baza de date la starea de la sfârșitul ultimului backup. Acest lucru se realizează prin restaurarea data files, a offline redo log files și prin recuperarea bazei de data la un anumit moment de timp (point-in-time recovery).

Un astfel de backup se realizează de obicei odată pe luna și se păstrează pe o perioadă lungă de timp.E recomandat să fie făcut și înainte de un upgrade al sistemului SAP sau al bazei de date.

Figura 4.5.5 Backup online consistent

4.6 Monitorizarea Backup-urilor

Se recomandă verficarea periodică a rezultetelor tuturor backup-urilor. Pentru aceasta se poate folosi:

Tranzacția DB14 (The log viewer) e principalul instrument de verificare, de aici se pot vedea toate log-urile tuturor activităților de administrare a bazei de date

Tranzacția DB13 (DBA planning calendar). Aici se pot vedea activitățile impreună cu avertizările sau erorile associate.

Tranzactia DB12 (Backup logs) e folosită numai pentru verificarea log-urilor de backup.De aici se mai poate crea un raport de recuperare, se poate vedea starea directorului oraarch împreună cu offline redo log files.

4.7 Programarea backupurilor (DB13)

Pentru backup-uri în situații normale se folosește această tranzacție.De aici se poate programa (planifica) orice combinație folositoare compusă din:

Whole backup

Online backup

Offline backup

Partial backup

Full backup

Incremental backup

Redo log backup

Dacă se oferă și opțiunea de a adăuga fiecărui tip de backup ales din cele de mai sus și un redo log backup atunci BRBACKUP și BRARCHIVE vor fi executate într-o singură rulare. Activități ce pregătesc backup-urile (ex: inițializarea casetelor, pregătirea RMAN) pot fi deasemenea programate de aici. Pentru a putea folosi in mod corect DB13 se verifică dacă parametrii din init<DBISD>.sap au valorile necesare. Deși unii parametrii pot fi specificați din DB13 alții ca device_type sau tape_adress nu se regăsesc aici.

4.8 Restore și Recovery

Exemplul din figură descrie o bază de date care a fost salvată cu success la SCN=10. La SCN=38 o eroare are loc care conduce la oprirea instanței bazei de date. Oflline și online redo log files ,care au fost create în perioada dintre începutul backup-ului și apariția erorii, sunt disponibile și absolute necesare pentru recrearea bazei de date așa cum era înainte de eroare. Într-o astfel de situație se recomandă:

Pentru analiza problemei se verifică alert log și trace files proprii bazei de date; se găsesc în directorul $ORACLE_HOME/saptrace/background.

Detectarea tipurilor de fișiere care sunt afectate (data files, control files, online redo log files).

Folosind strategiile de backup recomandate de SAP sunt disponibile mai multe backup-uri ale bazei de date care pot fi folosite pentru a putea recupera datele.

Figura 4.8 Restore și Recovery

4.8.1 Concepte: Recovery complet al bazei de date

O problemă tipică: Apariția unei erori (ex ștergerea unui data file) conduce la pierderi de date. Baza de date e inconsistentă și nu mai funcționează corect. Un recovery complet al bazei de date este efectuat pentru a restaura data files lipsă și pentru a recupera baza de date și a o aduce la starea ei de dinaintea erorii.

În timpul restaurării fișierele sunt copiate de pe mediul de backup înapoi pe disk. Folosind această metodă minimul necesar de date este copiat. Fișierele necesare pot fi copiate din backup-uri diferite.După terminarea acestei etape baza de date nu este în stare consistentă, se trece la pasul următor.

Pentru a sincroniza fișierele (a le aduce pe toate la același SCN cât mai recent posibil) baza de date evaluează header-ele acestor fișiere.Apoi solicită toate offline redo log files ,care s-au acumulat de la cel mai mic SCN al fișierelor deja restaurate, într-un șir neîntrerupt. Toate schimbările înregistrate de offline redo log files sunt replicate în fișierele restaurate. Astfel toate fișierele sunt aduse la același SCN. Acest process se numește recovery (restaurare). După aceasta baza de date se află într-o stare consistentă, capabilă să ruleze și la SCN-ul de dinainte de apariția erori.

Figura 4.8.1 Recovery complet

4.8.2 Concepte: Point-in-time Recovery

O problemă tipică: În timpul unui upgrade, un utilizator șterge din greșeală un tabel. Ca și rezultat upgrade-ul trebuie oprit. Un backup complet este disponibil, dar nu a fost creat exact înainte de incepera upgrade-ului. Acest tip de restaurare trebuie efectuată pentru a reseta baza de date la un anumit moment de timp de dinaintea upgrade-ului și apoi aplicând offline redo log files se adduce baza de date exact la momentul de înaintea începerii upgrade-ului sau înainte de stregerea tabelului.

Inițial toate data files sunt înlocuite cu copii dintr-un backup offline/online complet sau un grup de backup-uri parțiale care acoperă toată bază de date. La terminarea restaurării se înlocuiesc control files numai dacă este necesar. Acestea trebuie să reproducă structura fișierelor la nivelul sistemului de operare în raport cu starea și structura de la finalul procesului de recovery.

Punctul de final al procesului de recovery poate fii definit de SCN sau prin specificarea exactă a timpului (ora, data).

O astfel de metodă cauzează întotdeauna pierderi de date (pierderi controlate). Se pierd datele dintre momentul de timp la care a fost readusa bază de date și ultima oprire a sistemului.

Figura 4.8.2 Point-in-time recovery

După point-in-time recovery BRRECOVER rulează comanda ALTER DATABASE OPEN RESETLOGS. Aceasta are ca efect resetarea online redo log file și a SCN. Un backup complet trebuie rulat imediat deoarece offline redo log file deja existențe numai pot fi aplicate în caz de nevoie. Această metodă poate fi aplicată întregii baze de date sau numai anumitor tablespace-uri.

4.8.3 Concepte: Resetarea bazei de date

O problemă tipică: În timpul unui upgrade apar probleme software sau hardware, astfel upgrade-ul trebuie oprit. Baza de date e inconsistentă și nu mai funcționează corect. Un backup complet (offline sau online consistent) este disponibil fiind creat imediat înainte de upgrade. Aceasta metodă e aplicată pentru a reseta baza de date la starea corespunzătoare de înaintea backup-ului.

Când baza de date e resetata, data files, online redo log files și control files sunt copiate de pe mediul de backup înapoi pe disk. Dacă toate fișierele sunt din cadrul aceluiași backup offline, baza de date e consistență și gata de rulare după ce procedura de copiere s-a încheiat (un proces de recovery nu e necesar). Dacă se folosește un backup online, procesul de recovery (recuperare) e efectuat in mod automat.Ca și în cazul poin-in-time recovery întotdeauna rezultă pierderi de date. Informația care a fost generată după backup-ul folosit se pierde.Bineînțeles că baza de date se află la finalul acestei procedure în stare consistentă.

Figura 4.8.3 Resetarea bazei de date

4.8.4 Recovery complet al bazei de date cu BR*Tools

Când se efectuează un recovery complet BRRECOVER înlocuiește fișierele pierdute folosind backup-urile corespunzătoare și apoi aplică redo log files.Pentru a putea folosi această funcție online redo log files și control file tre să fie valide.

Pentru un recovery complet se pornesc BRTOOLS sau BRGUI și se selectează Restore and recovery -> Complete database recovery. În următorul meniu se pot specifica parametrii necesari. Procesul de recovery constă în mai multe etape afișate de BRRECOVER în meniul principal și care apoi vor fi executate într-o ordine prestabilită.

BR0655I Control menu 101 – please decide how to proceed

–––––––––––––––––––––

Complete database recovery main menu

1 = Check the status of database files

2 * Select database backup

3 * Restore data files

4 * Restore and apply incremental backup

5 * Restore and apply archivelog files

6 * Open database

7 * Exit program

8 – Reset input values

Standard keys: c – cont, b – back, s – stop, r – refr, h – help

–––––––––––––––––––––

BR0662I Enter your choice:

BRRECOVER verifică starea tuturor fișierelor (control files, online redo log files, și data files).BRRECOVER urmează pașii:

Pentru a reactualiza V$ views care sunt recitite în timpul trecerii de la NOMOUNT la MOUNT, BRRECOVER oprește instanța bazei de date

BRRECOVER interoghează V$DATAFILE și V$RECOVER_FILE pentru a determina starea fisierelor.

BRRECOVER înregistrează orice eroare ce privește data files intr-un fișier de log din folderul sapbackup.

Select database backup

BRRECOVER determină backup-urile valide folosind înregistrările din fișierul back<DBISD>.log (cele valide au cod 0 sau 1). Din acest log se determină dacă fișierele necesare sunt sau nu în backup. Pentru a minimiza timpul destinat pentru recovery BRRECOVER sugerează întotdeauna folosirea celui mai recent backup. Se poate selecta și un backup incremental pentru a putea fi folosit, înainte de aplicarea offline redo log files. În acest caz BRRECOVER selectează automat backup-ul full corespunzător.

Restore data files

BRRECOVER apelează BRRESTORE pentru a copia fișierele necesare de pe mediul de backup înapoi pe disk.

Restore and apply incremental backup

Dacă se selectează un backup incremental BRRECOVER apelează BRRESTORE pentru a folosi backup-ul incremental.

Restore and apply archivelog files

BRRECOVER determină care offline redo log files sunt necesare pentru a îndeplini procesul de recovery. Fișierul log folosit de BRARCHIVE arch<DBSID>.log conține lista tuturor backup-urilor effectuate pt offline redo log files. BRRECOVER ia în considerare atât fișierele din oraarch cât și online redo log files. BRRECOVER apelează BRRESTORE pentru a copia offline redo log files, găsite pe mediul de backup, înapoi în directorul oraarch. În acest pas BRRECOVER apelează SQL*Plus pentru a aplica offline redo log files (comanda RECOVER DATABASE) .

Open database

In ultima fază BRRECOVER pornește baza de date și verifică starea fișierelor și a tablespace-urilor.

Figura 4.8.4 Recovery complet cu BR*Tools

4.8.5 Point in time Recovery cu BR*Tools

Se pornețte BRTOOLS sau BRGUi și se selectează Restore and recovery -> Database point-in-time recovery. Procesul constă din mai mulți pași pe care BRRECOVER îi prezintă în meniul principal și care trebuie executați într-o ordine prestabilită.Un pas poate fi selectat numai daca cel precedent s-a incheiat.

BR0655I Control menu 103 – please decide how to proceed

Database point-in-time recovery main menu

1 = Set point-in-time for recovery

2 * Select database backup

3 * Check the status of database files

4 * Restore control files

5 * Restore data files

6 * Restore and apply incremental backup

7 * Restore and apply archivelog files

8 * Open database

9 * Exit program

10 – Reset input values

Standard keys: c – cont, b – back, s – stop, r – refr, h – help

–––––––––––––––––––––

BR0662I Enter your choice:

Set point-in-time for recovery

BRRECOVER citește valoarea introdusă.Ea poate fi specificată ca:

Redo log sequence number (LSN)

System change number (SCN)

Data

Select database backup

BRRECOVER determină backup-urile valide folosind înregistrările din fișierul back<DBISD>.log (cele valide au cod 0 sau 1). Detaliile din aceste fișier arată ce fișiere au fost salvate în backup-uri. Pentru a minimiza timpul necesar pentru a efectua un point-in-time recovery, BRRECOVER sugerează folosirea celui mai recent backup și verifică prezența offline redo logs. Se poate selectă și un backup incremental pentru a putea fi folosit, înainte de aplicarea offline redo log files. În acest caz BRRECOVER selectează automat backup-ul full corespunzător.

Check the status of database files BRRECOVER verifică starea tuturor fișierelor (control files, online redo log files, și data files) pentru a determina care vor fi suprascrise și care vor fi recreate. Pentru a reactualiza V$ BRRECOVER oprește instanța bazei de date și o pornește apoi în starea MOUNT.

Restore control files

BRRECOVER apeleaza BRRESTORE pentru a copia control file necesar de pe mediul de backup.

Restore data files

BRRECOVER apelează BRRESTORE pentru a copia data files necesare de pe mediul de backup.

Restore and apply incremental backup

Dacă se selectează un backup incremental BRRECOVER apelează BRRESTORE pentru a folosi backup-ul incremental

Restore and apply archivelog files

BRRECOVER determină care offline redo log files sunt necesare pentru a îndeplini proceseul de recovery. Fișierul log folosit de BRARCHIVE arch<DBSID>.log conține lista tuturor backup-urilor effectuate pt offline redo log files. BRRECOVER ia în considerare atât fișierele din oraarch cât și online redo log files. BRRECOVER apelează BRRESTORE pentru a copia offline redo log files, găsite pe mediul de backup, înapoi în directorul oraarch. În acest pas BRRECOVER apelează SQL*Plus pentru a aplica offline redo log files (comanda RECOVER DATABASE UNTIL).

Open database

In ultima fază BRRECOVER:

Pornește baza de date cu opțiunea RESETLOGS (e necesară pentru că avem de-a face cu un recovery incomplet).

Creaza fișierele temporare lipsă.

Verifica starea fișierelor și a tablespace-urilor.

Sterge fișierele care numai sunt folosite de baza de date.

Figura 4.8.5 Point-in-time recovery cu BR*Tools

4.8.6 Resetarea bazei de date cu BR*Tools

Se pornește BRTOOLS sau BRGUi și se selectează Restore and recovery -> Whole database reset. Procesul constă din mai mulți pași pe care BRRECOVER îi prezintă în meniul principal și care trebuie executați într-o ordine prestabilită.Un pas poate fi selectat numai daca cel precedent s-a incheiat.

BR0655I Control menu 109 – please decide how to proceed

–––––––––––––––––––––

Whole database reset main menu

1 = Select consistent database backup

2 * Check the status of database files

3 * Restore control files and redolog files

4 * Restore data files

5 * Restore and apply incremental backup

6 * Apply archivelog files

7 * Open database

8 * Exit program

9 – Reset input values

Standard keys: c – cont, b – back, s – stop, r – refr, h – help

–––––––––––––––––––––

BR0662I Enter your choice:

Select consistent database backup

BRRECOVER determină backup-urile valide folosind înregistrările din fișierul back<DBISD>.log (cele valide au cod 0 sau 1). Se poate alege :

backup offline complet

backup online complet și consistent

backup incremental offline

backup incremental consistent online

Se poate selecta și un backup incremental pentru a putea fi folosit, înainte de aplicarea offline redo log files. În acest caz BRRECOVER selectează automat backup-ul full corespunzător.

Restore control files and redolog files

BRRECOVER apelează BRRESTORE pentru a copia control file necesar de pe mediul de backup. Deasemenea și offline redo log files dacă s-a selectat un backup online consistent.

Restore data files

BRRECOVER apelează BRRESTORE pentru a copia data files de pe mediul de backup.

Apply incremental backup

Dacă se selectează un backup incremental BRRECOVER apelează BRRESTORE pentru a folosi backup-ul incremental.

Apply archivelog files

Daca s-a ales un online backup consistent BRRECOVER apelează SQL*Plus pentru a aplica offline redo log files.

Figura 4.8.6 Resetarea bazei de date cu BR*Tools

Open database

In ultima fază BRRECOVER:

Pornește baza de date cu optiunea RESETLOGS (dacă e necesară).

Crează fișierele temporare lipsă.

Verifică starea fișierelor și a tablespace-urilor.

Șterge fișierele care numai sunt folosite de baza de date.

Capitolul V. Analiza Workload.Optimizare

5.1 Introducere

Sistemele SAP sunt complexe; mai multe componente contribuie la performanța generală a sistemului. Rețeaua, sistemul de operare, baza de date precum și distribuția resureselor în sistem sunt factori cheie. Asfel la optimizarea sistemului de acești facori se ține cont. SAP oferă tool-uri pentru monitorizarea rețelei, a sistemului de operare, și a bazei de date. Workload-ul în sistemul SAP este crucial. Distribuția utilizatorilor, a sarcinilor de fundal, RFC, a reactualizarilor și cererilor de tipărire pe mai multe instanțe contribuie deasemenea la workload, la alocarea memoriei și la folosirea CPU. Toate acesteau au impact asupra performanțelor sistemului SAP.

Factorii care conduc la probleme de performanță sunt numeroși. Proasta configurare și hardware bottlenecks pot fi unele dintre probleme. Hardware-ul necorespunzător cum ar fi CPU lent sau memorie insuficientă pot face ca sistemul să devină neutilizabil. Configurarea sistemului SAP este foarte importantă. Memoria insuficientă și dimensiunea buffer-ului prea mică sau procese de lucru (work process) insuficiente pot duce la probleme. Programe care rulează prea mult, cauzate de instrucțiuni costisitoare și neoptime consumă mult din timpul procesorului, și ocupă părți mari din memorie.

Îmbunătățirea performanțelor sistemului SAP necesită cunoștințe în multe domenii. La prima vedere motivul unor probleme de performanță nu este clar. De aceea administratorii trebuie să acționeze rapid și cât mai eficient cu putință. Totuși evitarea aparițiilor acestor probleme este cea mai bună strategie.

5.2 Componentele unui pas de dialog

Indiferent de sursa problemei, inotdeauna aceasta este indicate de un timp foarte mare de răspuns. O analiză în detaliu poate dura mult timp dar analizarea timpului de răspuns în unele cazuri poate duce rapid către rezolvarea problemei. De aceea cunoștințele amănunțite despre timpul de răspuns al pasului de dialog sunt esențiale.

Timpul de răspuns al unui pas de dialog este măsurat la nivelul instanței. El începe să fie măsurat de la momentul în care dispecerul primește cererea de la utilizator și până când răspunsul ajunge înapoi la utilizator. Timpul necesar parcurgerii informației între utilizator și instanță nu este luat în considerare.

Figura 5.2 Componentele pasului de dialog

Prima dată dispecerul primește cererea de la un utilizator. Timpul petrecut de dispecer în căutarea unui proces de dialog liber se numește timp de așteptare (wait time). Este prima componentă a timpului de răspuns. În mod normal ar trebui să dureze câteva milisecunde.

Roll-In Time

După aceea un proces de dialog liber a preluat cererea. Pe durata acestui timp de roll-in contextul utilizatorului este copiat din roll buffer în memoria roll, gestionată de fiecare process în parte. Contextul utilizatorului conține autorizațiile, variabilele și pointeri către datele aplicației stocate în memoria extended.

Load and Genaration Time

Pe durata acestui timp codul de program necesar este încărcat. Procesul încearcă să execute programul din buffer-ul de program, o metodă foarte rapidă. Dacă programul nu este găsit acolo atunci se caută codul acestuia in baza de date și apoi dacă este necesar, e generat. În concluzie s-ar putea ca acest timp să conțină și un timp de acces la baza de date.

Processing Time

Execuția programului urmează. Timpul nu e măsurat direct ci derivat dintr-o formulă care va fi prezentată ulterior.

Database Request Time

Execuția programului necesită și un acces la baza de date. În acest caz timpul de rețea necesar comunicării între baza de date și instanța SAP este inclus, numai in cazul în care baza de date și instanță SAP se află pe computer diferite. Măsurarea timpului începe atunci când procesul de dialog trimite cererea către baza de date și se termină când răspunsul ajunge înapoi la process.

Buffer Access Time

Înainte de accesul la baza de date procesul de dialog încearcă să încarce datele din buffer-ul de tabele SAP. Acest timp e foarte mic de obicei deoarece citirea din buffer este foarte rapidă.

Lock Time

Cunoscut și sub numele de enqueue time el este folosit pentru cererea și aplicarea de SAP locks cu ajutorul procesului de enqueue. Această componentă de dialog are de obicei un timp de răspuns mic (< 5ms).

Roll-out Time

La finalul pasului de dialog procesul scrie contextul utilizatorului înapoi în roll buffer. În paralel cu această acțiune, dispecerul trimite răspunsul către utilizator. De aceea deși este măsurat el nu face parte din timpul de răspuns.

CPU Time

CPU time și processing time sunt legate între ele. Processing time este o parte foarte importantă a timpului de răspuns, dar nu măsurat independent. Timpul în care este procesat programul constituie CPU time.

Wait time, roll-in time, load and generation time, enqueue time, database request, și (optional) roll-wait time contribuie la timpul de dialog. Astfel processing time este calculat prin scăderea tuturor acestor componente din timpul de răspuns la dialog .

5.3 Monitoare de performanță

5.3.1 Statistici workload: ST03N

Acest monitor este un instrument foarte puternic, și este recomandat întotdeauna când se vrea verificarea performanțelor sistemului, și se accesează rulând tranzacția ST03N. Este folosit la analiza datelor statistice disponibile din kernelul SAP. Când se examinează performanța sistemului in detaliu se recomandă folosirea vederii workload. Se poate detecta destul de rapid sursa posibilelor probleme de performanță folosind numărul mare de vederi de analiză (analysis view). Vederea workload afișează în mod obișnuit datele disponibile pentru ziua curentă. Sub Analysis views se poate accesa spre exemplu vederi referitoare la profilul tranzacțiilor, timp de răspuns, utilizatori. Response time, CPU, DB request time, wait, roll-in și roll-wait time, load and generation time, și lock time sunt afișate în milisecunde.

Cele mai importante vederi disponibile în Workload Monitor ( ST03N )

Workload Overview pentru o analiză a instanței SAP în ziua curentă

Workload Overview pentru o analiză a instanței SAP în ultimile minute (Last Minute.s load )

Transaction profile și Response Time Distribution pentru perioadele de timp selectate.

Total pentru a obține date despre tot sistemul.

Figura 5.3.1 Tranzacția ST03N

În stânga putem alege următoarele submonitoare:

Workload

Aici sunt afișate statistici ale tuturor instanțelor configurate. Se poate studia o instanță individual sau la valorile medii pe întregul sistem. Informațiile despre o anumită instanță sunt afișate chiar dacă aceasta este temporar oprită.

Detailed Analysis

Alegând Business Transaction Analysis suntem redirectionați către tranzacția STAD. O altă opțiune este Last Minute.s Load, iar în cadrul ei se găsesc sectiunile:

Analysis Interval: se specifică data și ora.

Data restriction: clientul, utilizatorul, și numărul procesului pot fi selectate.

Analysis Parameter: granularitatea intervalului de timp este specificată.

Load History and Distribution

Aici găsim informații ce se întind pe o anumită perioadă de timp selectată. Valoarea afișată în mod normal este timpul de răspuns al procesului de dialog, dar se pot alege și alte tipuri. Deasemenea se mai poate vedea distribuția utilizatorilor în sistem.

BW System Load

Această opțiune oferă informații, statistici despre anumite activități de raportare ce privesc SAP Businesss Information Warehouse 3.5 (SAP BW).

Collector and Performance DB

Informații despre mecanismul de selectie a datelor.

Performance database: oferă informații despre performanța bazei de date.

Performance monitor collector: oferă acces la fișierele log și o prezentare generală a programelor de colectare a informațiilor și intervalul orar în care acestea rulează.

Workload collector: aici se poate configura colectorul de informații, de exemplu câte inregistrări sa parcurgă in timpul colectării informațiilor.

Statistics records & files: aici se pot schimba parametrii sistemului relevanți in colectarea datelor statistice.

Analysis Views

După alegerea instanței care se dorește a fi studiată mai multe informații devin disponibile. Astfel sunt puse la dispoziție informații mai detaliate, mai amănunțite.

Workload overview: este afișată performanța pe ziua curentă, dacă nu este aleasă altă valoare.

Transaction Profile: sunt afișate date despre procesul de dialog. Aici se identifică acele tranzacții care conduc la o funcționare necorespunzătoare a sistemului.

Time Profile: date statistice despre procesul ales sunt segmentate în concordanță cu granularitatea și intervalul de timp specificate.

Ranking Lists: tipurile unor procese (ex pași de dialog) pot fi vizualizate în ordinea descrescătoare a timpului de dialog și a numărului de accesări al bazei de date.

Memory Use Statistics

RFC Profiles: statistici separate pentru client și server. Se pot vizualiza și statistici despre destinații, utilizatori, funcții apelate, etc.

User and Settlement Statistics: statistici raportate la utilizatori si clienți.

Frontend Statistics

Response Time Distribution: informații foarte folositoare despre cum este distribuit în sistem timpul de răspuns, se pot face medii, etc.

În figura de mai jos putem exemplifica folosirea monitorului. Astfel dacă se vrea aflarea tranzacției cu timpul de raspuns cel mai mare se alege Transaction Profile (sub Analysis Views). Aici se găsesc:

Cele mai utilizate tranzacții: se sortează coloana Total Response Time și se ține cont și de numarul de pași. Ne concentrăm pe tranzacțiile care au cel mai mare timp de răspuns pentru că acestea au cel mai mare impact asupra performanței sistemului.

Figura 5.3.1.1 Tranzacția ST03N:Transaction profile

5.3.2 Analiza tranzactiilor : STAD

Cu ajutorul tranzacției STAD se pot vizualiza informații statistice despre procesele business (tranzacții business) care rulează în sistem. Sunt disponibile informații despre când a fost pornită tranzacția, când s-a oprit, ce utilizator a rulat-o, etc. Sunt oferite trei opțiuni de analiză. Pentru a afișa statisticile despre toate tranzacțiile se alege Show business transaction totals. Pentru a afișa inregistrări din statistică, grupate după tranzacțiile business se alege Show all records, grouped by business transaction.Pemtru a afișa toate statisticile sortate după timpul de start se alege Show all statistic records, sorted by start time.

Figura 5.3.2 Tranzacția STAD

Jos se poate selecta modul de achiziție a datelor statistice, din memoria (buffer) sau din fișierele de statistici scrise la nivelul sistemului de operare.Odată ales intervalul și restricționată selecția datelor statisticile corespunzătoare sunt afișate. Informații mai detaliate despre o înregistrare se pot obține selectând linia dorită.

5.3.3 Monitorul Proceselor SAP : SM50/SM66

Acest monitor oferă informații despre task-urile curente ale proceselor din instanță pe care se rulează tranzacția. Următoarele informații pot fi vizualizate aici:

No.

Această coloană identifică numărul procesului. Acesta pornește de la 0 și poate fi folosit la identificarea lui în fișierele trace.

Ty.

Specifică tipul procesului. DIA pentru procesele de dialog, UPD pentru cele de update, BGD pentru procesele de fundal, etc.

PID

Identificatorul procesului așa cum apare și la nivelul sistemului de operare (valabil pentru UNIX). Sistemul de operare Windows nu este transparent în această privință.

Status

Afișează starea curantă a fiecărui proces (ex running, waiting).

Figura 5.3.3 Tranzacția SM50

Reasn

Afișează posibile explicații pentru procesele aflate în starea holding.

Start

Afișează dacă un proces este automat repornit de către dispecer în cazul unei opriri bruște (cauzate de o eroare). Repornirile fără un astfel de motiv vor fi adunte și afișate în coloană Err.

Err

Afișează numărul de reporniri (fără un motiv clar) ale procesului.

Sem

Oferă informații despre semafoarele folosite să gestioneze accesul la resurse.

CPU

Afișează informații despre timpul petrecut la CPU de la pornire,de fiecare proces în parte.

Time

Afișează durata de execuție a unui task. Această linie devine colorată în roșu dacă durata depășește valoarea parametrului rdisp/max_wprun_time.

Report

Aici se găsește numele raportului executat de către process.

Cl.

Afișează clientul de pe care se execută activitatea.

User

Afisează utilizatorul care a pornit task-ul.

Action

Afisează activitatea derulată de către proces (ex Load Program )

Table

Afisează numele tabelului accesat de către process.

Figura 5.3.3.1 Tranzacția SM66

Cu ajutorul tranzacției SM66 se pot vizualiza procesele care rulează pe întreg sistemul.

5.3.4 Monitorul sistemului de operare : ST06/OS06/OS07

Acest monitor folosește programul SAPOSCOL (SAP Operating System COLlector), pentru a obține toate informațiile necesare despre hardware-ul pe care rulează. SAPOSCOL are o singură instanță pentru sistemul de operare pe care rulează, și poate fi folosit de mai multe instanțe SAP. Putem descrie următoarele scenarii:

Un singur dispecer SAP pe un singur server.

Un singur program SAPOSCOL care rulează pe acest server.

Două sau mai multe dispecere pe un singur server

Un singur program SAPOSCOL care rulează. Toate instanțele vor folosi informația colectată de acesta.

SAPOSCOL ar trebui să fie activ cât timp rulează și sistemul de operare. Acest lucru presupune instalarea SAPOSCOL că și serviciu pe sistemul Windows

Pentru a accesa informația colectată de SAPOSCOL din sistemul SAP se rulează una din tranzacțiile:

ST06 sau OS06 (identice). Oferă informații numai despre sistemul pe care rulează instanța.

OS07 oferă informații despre toate sistemele de operare pe care rulează sistemul SAP.

În tranzacțiile ST06, OS06, si OS07 următoarele informații apar în ecranul principal.

Figura 5.3.4 Tranzacția ST06/OS06/OS07

CPU Utilization

User utilization are trebui să se situeze în intervalul 50%-60%.

System utilization ar trebui să fie sub 20%.

Idle time ar trebui să fie peste 20%. Dacă este sub această valoare conduce la CPU bottleneck.

I/O wait

Descrie timpul în care procesele aflate la procesor așteaptă după resurse I/O. De aceea o valoare de sub 10% este una normală. Dacă aceasta crește se recomandă verificarea capacităților I/O, a rețelei, etc.

Average CPU Load

Medii pe intervale de 1, 5 și 15 minute. Afișează numărul mediu de procese gata de execuție dar care trebuie să aștepte pentru CPU. Dacă aceste medii sunt mai mari decât numărul de CPU din sistem atunci acest lucru conduce la o scădere a performanței sistemului. O valoare mare aici însoțită de o valoare mică la CPU utilization indică o memorie prea mică.

Count

Numărul de CPU disponibile în sistem.

Memory: Physical mem avail

Dimensiunea RAM a server-ului.

Swap: Maximum swap space

Cantitatea de memorie swap sau page disponibilă la nivelul sistemului de operare. În sistemele Windows nu trebuie să depășească 4*RAM iar în sistemele UNIX 32 de biți 3*RAM. Cu cât această cantitate este mai mare cu atât scade performanța sistemului.

Swap: Commit charge limit (Windows OS)

Suma dintre RAM și swap/page. Această sumă se mai numește și virtual memory.

Funcții suplimentare oferite de ST06/OS06/OS07

Operating System collector

Funcții pentru pornirea sau oprirea SAPOSCOL din sistemul SAP, precum și informații despre starea sa, fișiere de log.

Detail analysis menu: Analyze operating system → Snapshot Analysis → Top CPU

Un top al celor mai solicitante procese sortate după consumul de CPU și memoria curentă consumată.

Detail analysis menu: Analyze operating system → Previous hours→ Memory

Activitatea swap/page pe oră nu trebuie sa depășească un sfert din RAM sub Windows, sau o cincime din RAM sub UNIX. Altfel apare o utilizare excesivă a CPU si a I/O.

Figura 5.3.4.1 Tranzacția ST06/OS06/OS07: Top CPU

5.3.5 Monitor pentru buffer-e : ST02

Tranzacția ST02 oferă informații bogate despre anumite subiecte cum ar fi:

Starea diferitelor buffer-e din instanța SAP.

Informații despre consumul de memorie al instanței.

Informații despre table buffering la nivelul instanței.

Reguli generale privind buffer-ele în sistemele SAP

Toate trebuie sa aibe valori mai mari de 95%, cu anumite excepții descrise mai jos.

Consumul de swap/page are loc datorită inexistenței de spațiu în buffer pentru un nou obiect. El trebuie evitat altfel apar avertizări în ecranul principal al tranzacției.

Se pot găsii toți parametrii care ajută la configurarea buffer-elor alegând butonul

Current Parameters. Daca se alege Profile maintenance se ajunge în tranzacția RZ10.

Dacă se alege Change Profile parameter se ajunge la tranzacția RZ11.

Figura 5.3.5 Tranzacția ST02

Următoarele informații apar în meniul principal al tranzacției ST02:

Nametab (NTAB) buffer

Conține date prelucrate din tabelele DDNT (definițiile tabelelor SAP) și DDNTF (descrierea câmpurilor), stocate în patru zone de buffer . Aceste patru buffer-e mai sunt numite și Repository buffer sau ABAP Dictionary buffer.

Table definitions

Buffer-ul TTAB conține date din tabelul DDNT

Field descriptions

Buffer-ul FTAB (field descriptions buffer ) conține date din tabelul DDNTF.

Initial record layouts

Conține arhitectura înregistrărilor, inițializate în raport cu tipul câmpului.

Short Nametab

Buffer-ul SNTAB conține un scurt sumar al TTAB și FTAB. Ar trebui să aibă o calitate (hit ratio) de aproape 99.5%, sau chiar mai mare după câteva zile de funcționare intensivă a sistemului SAP. Situațiile care duc la scăderea sub 95% (ignorând repornirea sistemului) trebuie evitate, au o influența majoră asupra sistemului.

Program Buffer (PXA)

Este folosit pentru a stoca programele ABAP înainte a fi executate de către un process. Mai este cunoscut și sub numele de ABAP buffer. Când un program este cerut de către un proces, și acesta există deja în PXA timpul de acces este foarte bun. Dacă nu mai există spațiu disponibil atunci un algortim specializat determină ce poate fi șters din PXA pentru a face loc programului respectiv. Aceaste ștergere va apărea ca swap. PXA trebuie să aibă o calitate mai mare de 95%, și scăderea lui poate fi cauzată de importul unor noi prgrame în sistem. De obicei jumătate din programele din PXA sunt mai mici de 4kB.

CUA Buffer

Stochează obiectele folosite de SAP GUI (meniuri, butoane, etc). De obicei calitatea acestuia nu influențează în mod important performatele sistemului.

Screen Buffer

Stochează ecranele generate în timpul dialogului (numite și Dynpro load). Nici acest buffer nu joacă un rol important.

Calender Buffer

Stochează toate calendarele definite în sistem.

OTR Buffer

Buffer-ul OTR (Online Text Repository) conține textele folosite de BSP (Business server pages) servicii HTTP.

Generic Table Buffer

Acest buffer stochează o serie de înregistrări sau tabele întregi așa cum sunt configurate în tranzacția SE13 (SAP table buffering). Calitatea acestui buffer trebuie să fie mai mare de 95%.

Single Record Table Buffer

Stochează numai o singură linie corespunzătoare fiecărui tabel, astfel este umplut cu greutate și se așteaptă ca în cazul lui calitatea să fie mai mică.

Export/Import Buffer

Este folosit la stocarea informațiilor care trebuie să fie disponibile câtorva procese. Sistemul scrie sau citește buffer-ul folosind comandă ABAP : EXPORT TO/IMPORT FROM SHARED BUFFER.

Exp./Imp. SHM

Conține date scrise prin instrucțiunea ABAP : EXPORT TO SHARED MEMORY. Dacă o importantă activitate swap are loc pe acest buffer atunci acesta produce o scădere a performanței. O funcționare corectă nu conduce la utilizarea swap.

5.3.6 Monitorul bazei de date Oracle : ST04N

Acest monitor este folosit la analiza bazei de date Oracle. Tranzacția ST04N are ca sursă de informație vederile de performanță (performance views) V$*, GV$* și tabelele DBA_* . (ex GV$FILESTAT, V$SYSSTAT, DBA_INDEXES). Monitorul principal afișat la rularea tranzacției oferă informații structurale și de eficiență privind următoarele:

Informații generale despre baza de date

Data buffer

Shared pool

Log buffer

Calls

Time Statistics

Redo logging

Table scans

Sortări

Eficiența instanței bazei de date

Figura 5.3.6 Tranzacția ST04N

Următoarele valori sunt recomandate pentru o funcționare optimă a bazei de date Oracle.

Data buffer quality

Se bazează pe raportul dintre citirile fizice și totalul citirilor (logice din buffer + fizice de pe disk). Calitatea acestui buffer trebuie să fie mai mare de 95% iar statisticile trebuie să se bazeze pe un nr total de 15 milioane de citiri.

Ratio of user and recursive calls.

O performanță bună este indicată de valori mai mari de 2. Altfel numărul de apeluri recursive este prea mare. Apel recursiv atunci când o instrucțiune SQL nu este citită din buffer ci direct de pe disk.

Number of reads per user call

Dacă acest număr depășește 30 de blocuri/user call, atunci acesta poate indica o instrucțiune sql costisitoare.

Time/User call

Nu trebuie să existe valori mai mari de 15 ms, altfel există o problemă de optimizare.

Busy wait time versus CPU time

Între ele trebuie să existe un raport 60:40, un indiciu care arată că sistemul funcționează optim.

DD-cache quality

Trebuie să aibe o valoare de peste 80%.

ST04N este un instrument complet pentru monitorizarea bazei de date.

5.4 Hardware Bottlenecks

Există mai multe moduri în care acestea se manifestă:

Utilizarea CPU este foarte mare (aproape 100%)

Un număr mare de procese care așteaptă pentru CPU

Swap folosit în cantități semnificative

Timpuri de răspuns I/O mari

Timpuri de răspuns rețea mari

Aceste simptome pot fi găsite folosind tranzacțiile ST03N sau ST06. În acest subcapitol ne vom concentra pe utilizarea CPU și folosirea swap.

In ST06 CPU idle time trebuie să fie peste 20%, altfel vor apărea situații de așteptare pentru CPU. O valoare optimă se situează în jurul a 30%. Dacă apare un bottleneck la nivelul CPU se pot urma pașii:

ST06 → Detail analysis menu → Top CPU processes pentru a identifica procesele care utilizează cel mai mult CPU .

Dacă un process găsit în pasul 1 este un process SAP se notează PID și se compară cu lista obținută în tranzacția SM50 pentru a găsi ce activitate îngreunează sistemul SAP.

Dacă procesul găsit în pasul 1 face parte din arhitectura bazei de date se încearcă găsirea unei cauze care provoacă această activitate. Tranzacția ST04 trebuie folosită pentru a decide dacă această activitate poate fi îmbunătățită sau mutată la alt interval orar pentru a nu interfera cu orarul în care sistemul trebuie să funcționeze la parametrii optimi.

Dacă procesul găsit la pasul 1 nu face parte din sistemul SAP trebuie luată în considerare mutarea acestuia pe alt hardware.

Pentru a verifica activitatea swap/page în ST06→Detail analysis menu→Previous hours → Memory.

Dacă cantități mari de swap/page sunt folosite atunci apare un bottleneck al memoriei. Pași de urmat:

Distribuirea proceselor, care nu necesită rularea pe o instanță anume, pe alte hardware.

Dacă e necesar se reduce file system cache la mai puțin de 10% din RAM.

Identificarea utilizatorilor/programelor care cauzează un consum de memorie prin analiza ST02 → Detail analysis menu → SAP memory →Mode list. Se detectează existența unor instrucțiuni sql costisitoare sau a unor programe suboptime.

Cu ajutorul tranzacției ST03N se pot găsii indicii despre hardware bottlenecks, prin analiză wait time, average load and generation time, roll time, sau database request time.Dacă processing time este de doua ori mai mare ca CPU time este un indiciu că avem de a face cu un CPU bottleneck.

Recomandări pentru configurarea memoriei

Bazei de date trebuie sa îi fie alocate 20% din memoria RAM a tuturor server-elor folosite în sistemul SAP.

Buffer-ele SAP trebuie sa aibă o valoare de 1000 MB/instanță.

50 MB până la 60 MB pentru fiecare proces, în funcție de versiunea SAP și sistemul de operare.

15 MB până la 20 MB pentru extended memory/utilizator din sistem.

Dimensiunea inițială a memoriei virtuale a instanței SAP nu trebuie să depașească 2 * dimensiunea RAM.

Dimensiunea swap (UNIX) trebuie să fie 3 * RAM sau cel puțin 5 GB ; sistemele de 64 de biți trebuie sa aibă dimensiunea swap 20 GB.

Dimensiunea page (Windows) trebuie să fie 4 * RAM

Se pot verifica valorile curente ale memoriei virtuale specifice instanței prin ST02→Detail Analysis Menu→SAP Memory. Valorile afișate aici sunt specifice instanței pe care utilizatorul este logat.

Recomandări pentru configurarea CPU

Factori ce influențează gradul de folosire:

Aplicațiile folosite

Numărul utilizatorilor conectați la sistem

Tipul de hardware folosit

Tipul sistemului de operare folosit

Versiunea de SAP instalată (mySAP ERP, mySAP CRM, etc)

Chiar dacă se iau în considerare toți acești factori se obține numai o estimare a dimensiunii CPU. Mai pot fi enumerate două recomandări:

Baza de date trebuie să aibe la dispoziție între 10% și 30% din CPU disponibil în tot sistemul

Procesarea reactulizărilor pot folosi între 10% și 20% din puterea CPU.

5.5 Sintaxe SQL Costisitoare

Sintaxele SQL costisitoare sunt considerate toate sintaxele care determină ca baza de date să citească multe blocuri de date (de pe disk sau din buffer). Aceste sintaxe pot avea consecințe negative asupra întregului sistem SAP.

Consecințe

Baza de date este ocupată să citească multe blocuri, alte cereri pot fi întârziate.

O utilizare ridicată a CPU are ca rezultat scăderea performanței sistemului.

Un process SAP este blocat (așteptând răspunsul de la baza de date) și nu este disponibil pentru alte cereri.

Multe blocuri din buffer pot fi înlocuite de informații inutile, calitatea buffer-ului scade.

Criterii de relevanță

Cât de des este executată instrucțiunea

Când este executată

Care sunt urmările asupra timpului de răspuns.

Figura 5.5 Sintaxe SQL costisitoare: Consecințe

Instrumente necesare pentru detectarea sintaxelor costisitoare

5.5.1 Tipuri de instrucțiuni sql costisitoare

Nu toate instrucțiunile sql pot fi optimizate.O scurtă descriere a tipurilor după cum urmează:

Instrucțiuni SQL folosite de programele ABAP

Aceste instrucțiuni sunt afișate (în ST04N) cu majuscule și în ghilimele, și sunt singurele care pot fi optimizate.

Instrucțiuni SQL folosite de instrumentele de administrare ale bazei de date

Acestea sunt afișate în majuscule fără ghilimele și nu pot fi optimizate de către un administrator SAP. Ele sunt generate de instrumentele de administrare ale bazei de date. Dacă aceste instrucțiuni scad performanța sistemului atunci se încearcă să fie rulate după un alt orar. Trebuie consultate notele SAP pentru soluții.

Instrucțiuni SQL care folosesc tabelele SAP Basis

Sunt identificate după tabelele pe care le accesează: DDNTT, DDNTF, D010L, și D010INF. Nici acestea nu pot fi optimizate. Dacă ele scad performanța sistemului se recomanada verificarea buffer-elor SAP prin tranzacția ST02.

Instrucțiuni SQL recursive (Oracle)

Sunt afișate în litere mici și nu pot fi optimizate. Acest tip de instrucțiune este executat când se accesează data-dictionary din Oracle, precum și pentru sarcini interne ale bazei de date Oracle (cele folosite pentru gestionarea spațiului).

5.5.2 Detectarea instrucțiunilor SQL costisitoare folosind monitorul proceselor SAP (SM50)

Deși acest monitor este foarte folositor el nu poate analiza situații petrecute în trecut (situații istorice).

Pași pentru folosire.

Se identifică acțiunile care rulează de o perioadă mare de timp (de exemplu Sequential Read, Insert, sau Update).

Se notează numele raportului/tranzacției pentru o analiză ulterioară.

Se notează numele tabelului pentru care acțiunea este executată.

Dacă se dă dublu click pe o linie se poate vizualiza instrucțiunea sql curent executată.

Figura 5.5.2 Sintaxe SQL costisitoare: SM50

5.5.3 Detectarea instrucțiunilor SQL costisitoare cu Transaction Profile și Statistical Records (ST03N)

Folosind submonitorul transaction profile din monitorul ST03N se pot identifica tranzacțiile care contribuie în mare măsură la creșterea timpului total de răspuns și deasemenea tranzacțiile cu timp mare de răspuns din partea bazei de date.

Figura 5.5.3 Sintaxe SQL costisitoare: ST03N

Folosind statistical records se restricționează afișarea numai pașilor de dialog care depășesc mai mult de 2000 ms. Această valoare depinde de cerințele de funcționare a sistemului.

Se alege Standard Transaction Profile în tranzacția ST03N și se restricționează afișarea numai a proceselor de tip Dialog.

Folosirea Transaction Profile

Se sortează coloana Average DB time (ms) în ordine descrescătoare. Tranzacțiile cu timp mediu de răspuns al bazei de date (Ф DB Time) pot fi cauzate de instrucțiuni sql costisitoare in ordine descrescatoare.

Se sortează coloana Total Database Time în ordine descrescătoare. Apoi se face o sumă a acestei coloane. Tranzacțiile care depășesc cu mai mult de 5% din timpul total al bazei de date trebuie luate în calcul pentru optimizare.

Se sortează coloana Total Response Time în ordine crescătoare, și se face o sumă a tuturor valorilor. Tranzacțiile care depășesc cu mai mult de 5% din timpul total de răspuns sunt de luat în calcul pentru optimizare.

5.5.4 Detectarea instrucțiunilor SQL costisitoare prin Statistical Records (STAD)

În ecranul principal al tranzacției STAD se întroduc următoarele restricții:

Se alege un interval de timp (nu trebuie sa depașească durata de viața a statisticilor).

Se alege Task Type D (dialog).

Se introduce o valoare relevantă pentru DB request time, de exemplu 1000 ms.

Figura 5.5.4 Sintaxe SQL costisitoare: STAD

În ecranul următor apare lista cu toate tranzacțiile care se potrivesc profilului descris mai sus. Se notează numele tranzacției, pentru a fi optimizată sau pentru o analiză mai amănunțită.

5.5.5 Detectarea instrucțiunilor SQL costisitoare din Monitorul bazei de date (ST04N)

Se execută tranzacția ST04N și se alege Detailed Analysis Menu → Oracle Session.

Se identifică task-urile care au timpi de rulare mari folosind PID obținute din SM50. Se poate alege alternativ opțiunea Process (informații suplimentare despre procesul SAP) după ce s-a selectat linia dorită.

Se alege acțiunea curentă a bazei de date selectând instrucțiunea din coloană SQL statement. În următoarea fereastră se pot vedea următoarele opțiuni:

Informații Dictionar despre obiectul accesat

Afișarea planului de exacuție pentru instrucțiunea SQL, denumit și Explain.

O referință către programul ABAP care apelează instrucțiunea.

Se analizează în detaliu informațiile livrate de funcția Explain.

Tot din acest monitor se pot folosii și informațiile despre buffer gets pentru identificarea instrcutiunilor costisitoare. Următoarele noțiuni trebuie explicate pentru a putea folosi această funcție.

Buffer Gets

Numărul de blocuri citite din data buffer pentru instrucțiunea rulată.

Physical Reads/Disk Reads

Numărul de blocuri citite de pe disk pentru instrucțiunea rulată.Folosind procedura descrisă mai jos se pot identifica instrucțiunile sql costisitoare care au un impact important asupra performanței bazei de date.

Pasi de urmat:

Se apelează ST04 și se alege Detailed Analysis Menu→SQL Request:Analysis of Shared Cursor Cache.

În ecranul urmator se introduc următoarele valori:

Pentru Buffer gets se introduce un numar egal cu 5% din totalul de citiri (reads) afișate pe ecranul de început al ST04. Se alege List sort pentru Buffer gets.

În ecranul urmator se poate analiza:

Sortând numarul de Disk Reads cererile SQL care cauzeaza o încărcare semnificativă a dispozotivelor fizice (hard disks).

Sortând instrucțiunile care au mai mult de 5 Bgets/row se obțin acelea care sunt costisitoare.În coloana SQL statement se găsesc instrucțiunile care cauzează aceste valori ale buffer gets.

Se selectează instrucțiunea SQL și se analizează după cum s-a descris mai sus.

Figura 5.5.5 Sintaxe SQL costisitoare: ST04N

5.5.6 Detectarea instrucțiunilor SQL costisitoare folosind SQL Trace (ST05)

Este un instrument foarte puternic pentru analiza acceselor la baza de date. Deși oferă numai funcția Explain totuși afișează o listă foarte bogată a timpilor de acces la baza de date pentru diverși pași executați la nivelul bazei de date. Informația captată de acest instrument este scrisă într-un fișier de la nivelul sistemului de operare. Deoarece o cantitate importantă de informație este scrisă în acest fișier la activarea captării, dacă dimensiunea fișierului, specificată prin parametrul rstr/max_filesize_MB, este depășită atunci fișierul este rescris.

Utilizarea acestui instrument este destul de simplă. Pentru a-l folosii se urmăresc pașii:

Se rulează raportul/tranzacția care se dorește să fie studiată pentru a umple buffer-ele.

Se apelează ST05.

Se selectează SQL Trace de sub Select Trace.

Se alege Activate Trace.

Se pornește din altă sesiune raportul/tranzacția/funcția dorită.

Dupa ce execuția acesteia a luat sfarsit, din ST05 se alege Deactivate Trace.

Se alege Display Trace pentru a afișa captura.Se pot specifica și capturi mai vechi.

Apare un ecran cu lista instrucțiunilor SQL captate.

Figura 5.5.6 Sintaxe SQL costisitoare: ST05

Interpretarea listei

În primă coloană esta afișat timpul consumat de operația desfășurată pe baza de date. Unitatea de măsură este microsecundă. Valorile mai mari de 100,000 µs sunt marcate în roșu.

A doua coloană afișează numele obiectului accesat din baza de date.

A treia coloana afișează tipul operației desfășurate la nivelul bazei de date.

Următoarea coloana Recs. afișează numărul înregistrărilor returnate.

Coloana 5 RC, codul returnat de baza de date.

Coloana 6 Statement, afișează instrucțiunea SQL executată, în format prescurtat.

Se poate alege Perform Explain for SQL statement (F9) pentru un rând care conține operațiile reopen sau open.

5.5.7 Folosirea funcției Explain

Oferă mai multe detalii de procesare a instrucțiunilor SQL.

Estimated costs

Acest număr este rezultatul optimizării accesului. Optimizarea este realizată de cost-based optimizer (CBO). Costul accesului propriuzis poate fi diferit de estimarea CBO. Totuși costurile sunt proporționale cu numărul de blocuri care trebuie citite pentru a îndeplini cererea.

Figura 5.5.7 Sintaxe SQL costisitoare: Funcția Explain

Estimated rows

Câte rânduri pot fi returnate ca rezultate ale instructiunii.

Activități

Tipuri de activități executate asupra bazei de date.

Activități de tip tabel: TABLE ACCESS BY INDEX ROWID

Activități de tip index: INDEX UNIQUE SCAN

Selectând un nume de tabel sau un index se pot obține informații detaliate despre tabele și indecși, date despre ultima analiză și statistici colectate pentru acest obiect.

5.5.8 Metode de detecție

În continuare vom prezenta trei metode prin care se detectează instrucțiunile SQL costisitoare și care apoi vor conduce la optimizarea lor. Modurile de folosire ale tranzacțiilor prezentate în cadrul acestor metode, sunt cele descrise mai sus.

Metoda I

Se folosește tranzacția SM50 și după o analiză atentă se notează tabelul, tranzacția și raportul care se consideră a fi cu probleme.

Aici avem doua căi posibile de urmat :

Se folosește tranzacția ST04N și se identifică instrucțiunea SQL care trebuie optimizată.

Se folosește tranzacția ST05.

Se folosește funcția Explain, disponibilă în cazul ambelor metode și în final se identifică instrucțiunea SQL precum și metoda de optimizare (daca e posibil) folosită.

Aceasta metodă este recomandata când instrucțiunea care cauzează probleme încă rulează, astfel nu folosim statistici (nu sunt accesibile prin SM50).

Metoda II

Se folosește tranzacția ST03N cu opțiunea Transaction Profile. Se notează codul tranzacției, wait time și db time.

Se folosește tranzactia ST05.

Se folosește funcția Explain și în final se identifică instrucțiunea SQL precum și metoda de optimizare (daca e posibil) folosită.

Aceasta metoda se folosește când instrucțiunea SQL nu se mai află în execuție, și astfel prin accesarea statisticilor (disponibile din ST03N) se identifică problema.

Metoda III

Se folosește ST04 cu metoda descrisă la Detailed Analysis Menu→SQL Request:Analysis of Shared Cursor Cache.

Din ST04N se folosește funcția Explain, se identifică instrucțiunea SQL precum și metoda de optimizare (daca e posibil) folosită.

Această metodă studiază instrucțiunile care au o valoare foarte mică pentru bgets/exec. Recomandata atunci când deși timpul de răspuns e bun totuși performanța sistemului scade deoarece data buffer este umpult cu informații inutile și implicit calitatea scade sub 95%.

Figura 5.5.8 Sintaxe SQL costisitoare: Ghid

Observăm că oricare dintre metode este folosită întotdeauna se ajunge la folosirea funcției Explain. Aceasta oferă informațiile necesare pentru a decide metoda de optimizare folosită. Din această funcție se poate vedea :

Dacă este folosit un index.

Dacă este efectuată un scanare completă a tabelului (index inexistent sau nefolosit).

Dacă statisticile folosite sunt actualizate.

În funcție de informațiile culese de aici se decide asupra metodei de optimizare a instrucțiunilor SQL.

Dacă prea multe înregistrări sunt returnate atunci trebuie optimizat codul ABAP (scrierea corectă a clauzei where implică folosirea corectă a unui index existent).

După folosirea funcției Explain se poate decide:

Dacă este folosit indexul optimal atunci se optimizează procesele bazei de date Oracle.

Daca indexul există și nu este folosit atunci se reactualizează statisticile (prin tranzacția DB13 se programează Update Statistics) sau se rescrie clauza where.

Dacă sunt indecși lipsă aceștia se recrează în baza de date (prin tranzacția DB02 Database Performance: Tables and indexes monitor).

Figura 5.5.9 Sintaxe SQL costisitoare: Recreare indecși (DB02)

Capitolul VI. Concluzii

Datele de tip business dintr-un sistem SAP, stocate într-o bază de date, sunt de obicei foarte dinamice si necesită o strategie bine pusă la punct. Daca administratorul SAP nu are definită o strategie adecvată, factori externi, erori fizice și erori logice pot duce la oprirea sistemului și chiar la pierderi de date. Strategia backup trebuie definită în raport cu nevoile sistemului. Pentru a asigura buna funcționare a sistemului, strategia trebuie atent testată înainte ca sistemul sa fie productiv, și apoi după orice schimbare intervenită pe parcurs. Când se stabileste o strategie backup, trebuie luată în considerare durata de timp în care e permisă oprirea sistemului pentru fiecare din scenariile prezentate în lucrare. Pentru a se asigura că se iau masurile corecte pentru fiecare scenariu, administratorul de sistem SAP, trebuie să întocmească un document ce conține descrierea sistemului și procedurile de urmat. Trebuie evaluată și apoi implementată cea mai potrivita metoda de backup. După cum am prezentat, SAP oferă instrumente care suportă diferite tipuri de back-up, fiecare cu avantajele și dezantajele ei.

Multe din monitoarele pentru analiza performanței prezentate în lucrare există de mult timp în sistemul SAP, începând cu versiunea SAP R/3 3.0. Totuși interfața acestor instrumente și capabilitățile lor au evoluat de-alungul timpului, noi funcții au fost introduse pentru a monitoriza componentele sistemului SAP.

Ultima parte a acestei lucrări insistă pe înțelegerea detaliată a problemelor de performață în sistemele SAP și permite administratorului aplicarea metodelor prezentate în lucrare într-o gamă largă a produselor SAP. Optimizarea este necesară, în mod normal, după trecerea în producție, uneori chiar și după mai mulți ani. Este o metodă de îmbunătățire a performanțelor sistemului foarte eficientă din punct de vedere al raportului cost/rezultate, de obicei având un cost mult mai mic decât al unui upgrade hardware, iar rezultatele obținute sunt, în majoritatea cazurilor, foarte bune. Optimizare reprezintă una sau mai multe din următoarele operații:

creșterea vitezei de răspuns a întregului sistem SAP R/3 (așa-numitul Timp mediu de răspuns).

creșterea vitezei de răspuns a unor tranzacții, programe sau procese SAP.

Timpul de răspuns al procesului de dialog este de obicei crucial în aprecierea performanțelor de către utilizator. S-au prezentat componentele de timp care contribuie la timpul de răspuns și instrumentele ce trebuie folosite pentru a afișa valorile acestor componente. Monitoarele din sistemul SAP sunt foarte apropiate între ele, de obicei legate între ele. Un exemplu bun este tranzacția ST03N.

Hardware-ul, la fel ca și configurarea sistemului, joacă un rol important în performanța sistemului. În lucrare s-au prezentat dimensionări de bază ale memoriei și CPU.

Instrucțiunile SQL costisitoare pot trece nedetectate si pot cauza probleme doar pentru perioade scurte de timp. Totuși niște instrucțiuni ineficiente pot determina ca anumite tranzacții să dureze perioade de timp inacceptabil de mari sau chiar sa încetinească întreg sistemul.De aceea este foarte importantă înțelegerea instrucțiunilor SQL costisitoare pentru a putea fi identificate și a lua măsurile necesare, pentru a face recomandări programatorilor ABAP în scopul optimizării întregului sistem.

Capitolul VII. Bibliografie

1. [ADM505,03] SAP A.G. ( 2003 ) Database Administration Oracle (ADM505 );

2. [ADM506,05] SAP A.G. ( 2005 ) Database Administration Oracle II (ADM506);

3. [ADM315,04] SAP A.G. ( 2004 ) Workload Analysis (ADM315;)

4. [SAPTEC,05] SAP A.G. ( 2005 ) Fundamentals of the SAP Web Application

Server (SAPTEC);

5. [***08,a] ( 2008 ) http://service.sap.com;

6. [***08,b] ( 2008 ) http://www.sap.com;

7. [***08,c] ( 2008 ) http://help.sap.com.

Capitolul VII. Bibliografie

1. [ADM505,03] SAP A.G. ( 2003 ) Database Administration Oracle (ADM505 );

2. [ADM506,05] SAP A.G. ( 2005 ) Database Administration Oracle II (ADM506);

3. [ADM315,04] SAP A.G. ( 2004 ) Workload Analysis (ADM315;)

4. [SAPTEC,05] SAP A.G. ( 2005 ) Fundamentals of the SAP Web Application

Server (SAPTEC);

5. [***08,a] ( 2008 ) http://service.sap.com;

6. [***08,b] ( 2008 ) http://www.sap.com;

7. [***08,c] ( 2008 ) http://help.sap.com.