În ultimele articole despre SAP HANA, ( "SAP HANA ca bază de date", "SAP HANA ca Platformă" și "Căutarea și analiza textelor în SAP HANA" ) am vorbit despre cum poate fi programată baza de date HANA. În acest articol vom vorbi despre diverse tooluri care ne ajută să analizăm o aplicație menită să ruleze pe SAP HANA. Mai exact ne vom axa pe folosirea instrumentelor, specifice HANA, în contextul optimizării accesului la baza de date.
Înainte de a discuta despre instrumentele pentru optimizarea performanței, o vom analiza diverse tool-uri importante pentru analiza erorilor.
Dacă execuția unui program se termină brusc, eroarea cunoscută ca Dump, tranzacția ST22 (ABAP Dump Analisys) ne oferă informații valoroase despre eroarea respectivă, figura 1.1. După cum am menționat și în articolele anterioare, tranzacțiile sunt Shortcut-uri pentru anumite programe. În cazul intrucțiunilor SQL, pot să apară diferite tipuri de Dump-uri. Multe dintre aceste erori pot fi "prinse" cu ajutorul claselor de excepții. Vezi tabelul 1.1.
Figura 1. Excepția CX_SQL_EXCEPTION
Alte informații folositoare, oferite de tranzacția ST22, se găsesc în următoarele secțiuni:
Informații despre instrucțiunea care a cauzat eroare;
Extract din codul sursă;
Valoare variabilelor;
Etc. .
În analiza erorilor, din implementarea unei proceduri din baza de date folosind SQL Script,
dorim să vedem anumite rezultate intermediare. Pentru a putea face aceasta folosim operatorul CE ( Calculation Engine ) TRACE, care ne ajută să salvăm conținutul, unei variabile locale de tip tabelă, într-o tabelă temporară din baza de date. Pentru procedura "GET_AGENCIES_FOR_CONNECTIONS" folosirea operatorului TRACE arată în felul următor:
LT\_AGENCIES = SELECT...
LT\_AGENCIES = TRACE(:LT\_AGENCIES);
ET\_AGENCIES = SELECT...
Sistemul creează automat tabela temporară din baza de date când apelează procedura, ea are aceeași structură ca variabila. Din moment ce tabela este temporară, conținutul ei poate fi văzut doar în aceeași conexiune cu baza de date. Trebuie avut grija la folosirea operatorului TRACE, deoarece are un impact negativ asupra timpului de execuție. El nu trebuie folosit în sistemul productiv, doar în cel de test.
Debuggerul de SQL Script este ultimul instrument pe care îl vom aborda în legătură cu analiza erorilor legate de instrucțiunile SQL. Pentru a folosi debuggerul avem nevoie de perspectiva DEBUG și SAP HANA DEVELOPMENT din SAP HANA Studio( vezi Figura 2). Pentru a naviga la următorul breakpoint folosim RUN -> RESUME, iar pentru a termina execuția RUN -> TERMINATE.
Figura 2. Debuggerul SQL Script
Acest instrument ne ajută să identificăm acele părți dintr-un program cu potențial de îmbunătățire. Dispune de o serie de verificări care pot fi făcute. Aceste verificări pot fi grupate în variante. În această secțiune sunt prezentate acele variante create pentru migrarea sau optimizarea pe SAP HANA. Ele au legătură, în principal, cu programarea robustă, securitate și performanță.
Aceste variante pot fi configurate manual cu ajutorul tranzacției ATC, sau ele vin gata configurate de la SAP, cum e varianta "PERFORMANCE_DB", vezi Figura 3.
Figura 3. Varianta PERFORMANCE_DB
Pentru a verifica un program din SAP HANA Studio, se apasă click dreapta pe program RUN AS -> ABAP TEST COCKPIT. Vezi Figura 4.
Figura 4. Verificarea codului în SAP HANA Studio
În această secțiune vom prezenta un instrument menit să analizeze codul ABAP în timpul execuției.
Pentru a crea acest profil se urmează pașii din figura următoare:
Rezultatul arată în felul următor:
Figura 6. Profilul ABAP - prima pagina
Mai multe informații le găsim in HIT LIST. Figura 7.
Monitorul SQL este un instrument menit să colecteze, să agregheze și să stocheze informații legate de execuția instrucțiunilor SQL. Acest monitor trebuie activat în sistemul productiv și lăsat să ruleze pentru o perioadă mai lungă, de obicei 5-6 săptămâni, ca să cuprindă toate procesele dintr-o firmă, cum ar fi procesele legate de sfârșitul de lună fiscală. Pentru a activa acest monitor se rulează tranzacția SQLM ca în Figura 8.
Figura 8. Activarea monitorului SQL
Rezultatele, de după monitorizare, pot fi văzute sub formă de listă și salvate ca un snapshot.
Instrumentul de optimizare a performanțelor SQL, sau SQL Perfomance Tuning Worklist, tranzacția SWLT, combină informațiile din analiza statică a codului , informații generate de ABAP Test Cockpit și informații generate de SQL Monitor. Acest lucru ne permite să identificăm repede locul unde trebuie intervenit pentru a optimiza o aplicație HANA.
Figura 9. Rezultatul treanzacției SWLT
Instrucțiunile SQL pot fi asignate unor anumite programe, iar acele programe pot fi asignate unor procese de business. În acest fel se pot planifica proiecte de optimizare pentru anumite procese.
Aceste tooluri noi, ne permit o analiză detaliată a erorilor din cod și a performanței instrucțiunilor SQL și a accesului la baza de date HANA.