Database thingies

Prije nekoliko godina, dok sam bio pocetnik u podrucju baza podataka, nailazio sam na mnoge probleme - nekad lagane, nekad teze. Vecinu sam ih pokusavao sam rijesiti uz pomoc dokumentacije ili knjiga, a kad nisam uspijevao, trazio sam rjesenje/savjet/pomoc na raznim forumima i preko Googlea.

U nerijetkim slucajevima sam znao izgubiti dosta vremena i zivaca, dok nisam nasao rjesenje ili neki savjet u vezi odredjenog problema.

Da nema Googlea i ljudi kao sto su Tom Kyte, koji nesebicno dijele svoje znanje i pomazu drugima, moj bi posao (a samim tim i zivot) bio mnogo tezi.

Zbog toga sam se i ja odlucio nesebicno pomagati drugim pocetnicima u podrucju baza podataka (tj. ukoliko moje znanje bude bilo dovoljno za pronalazenje rjesenja), konkretnije u vezi MySQL i Oracle baza, tako da mi mozete slati vasa pitanja sa DETALJNIM opisom problema, ocekivanim rezultatom i svim korisnim informacijama.
Pitanje ce biti postavljeno ovdje na sajtu i odgovor cemo pokusati dati svi zajedno, sa ciljem da odredjeni problem rijesimo na najbolji moguci nacin - dakle, ne samo da damo rjesenje, nego da to bude i “best practice” rjesenje.

Pitanja mozete slati na E-Mail dejanAToutsourcing-it.com

Odlucili mi da “zakrpimo” baze najnovijim patch-om, tj. patch-evima (CPU Patch April 2007 i Patch 5 za 10.2.0.3), kadli ono “rupa” u “zakrpi”. Medjutim, fora je sto patch na nekim serverima radi, a na glavnom production serveru ne radi kako treba. Juce i danas smo zakrpili nekoliko lokalnih servera, a potom development i acceptance server - sve je proslo bez ikakvih problema.

Dodje na red i live production server - pomislili smo da ni tu nece biti nikakvih problema, ali smo se zestoko uspanicili i preznojili. Moram priznati da je ovo danas bio jedan od problematicnijih dana u stilu “nocna-mora-za-DBA”.

Naime, nakon sto se baza najnovijim patchom zakrpi i nakon sto se pokusa normalno pokrenuti, pojavljuje se zlocudna ORA-07445 greska:

ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [kcbzfb+346] [PC:0×4E8616] [ADDR:0×251] [UNABLE_TO_READ] []

Na MetaLinku (link za one, koji imaju pristup MetaLinku: DATABASE CAN’T BE STARTED AFTER APPLIED CPU PATCH APR 2007) sam pronasao da je rijec o Bug-u, koji trenutno nije ispravljen, ali postoji jedan workaround za rjesavanje tog problema. Workaround se sastoji od dodavanja jednog parametra u init.ora datoteku:

_enable_numa_optimization=FALSE

Posto ne zelimo da se petljamo sa nekim workaroundima (lose iskustvo sa par prethodnih workaround prijedloga od strane Oracle Support tima), ponistili smo zadnji patch (opatch rollback) i pokrenuli bazu normalno bez tog patcha, pa cemo pricekati sa zakrpom, dok se taj bug ne ispravi.

U zadnje vrijeme manje pisem na blogu, jer sam zatrpan poslom, a u slobodno vrijeme se pripremam za polaganje “upgrade” ispita sa OCP 9i DBA na OCP 10g DBA (1Z0-040 - Oracle 10g: New features for administrators).
Imam vec 2 godine iskustva u radu sa verzijom 10g, ali sam kupio i SelfTestSoftware za ovaj ispit - za svaki slucaj.

Kad rijesim to, nastavljam sa recenzijom nekoliko novih knjiga, koje sam procitao u zadnjih par mjeseci (Mastering SQL; Cost-based Oracle Optimizer i td.). Bice tu i opis koristenja DataPump-a (expdp/impdp), kao i nekoliko rijeci o mijenjanju characterseta u bazi.

Stay tuned.

U petak sam prebacivao kopiju production baze na test-server, ali sam ucinio jedan pogresan korak, zbog kojeg sam kasnije dobijao masu “ORA-00936: missing expression“ gresaka.

Gledam ja tako problematicne SELECT upite, koji uzrokuju exception sa tom greskom i jednostavno ne vidim u cemu je problem. Gledam, testiram rucno, pokrenem debugging u TOAD-u, odradim tracing, grizem se za usne, vrijeme prolazi … - nista sumnjivo.

Stvarno nikad ne bih uspio skontati u cemu je fora, da mi jedan stariji i iskusniji Oracle DBA nije rekao:”To ti je sigurno zbog pogresnih NLS podesavanja!”

I bio je u pravu… Na production bazi su NLS podesavanja postavljena na Ameriku:
   NLS_LANGUAGE=’AMERICAN’
   NLS_TERRITORY=’AMERICA’

a na testnom serveru je postavljeno na Njemacku:
   NLS_LANGUAGE=’GERMAN’
   NLS_TERRITORY=’GERMANY’

tako da upiti sa TO_NUMBER i TO_DATE, koji sadrzavaju masku za formatiranje, nisu radili kako treba i javljali su gorespomenutu gresku.

Pocetnicka greska … Da sam kopirao odgovarajucu init.ora sa ispravnim NLS podesavanjima, ne bih imao ovaj problem…

No dobro, jos jedno iskustvo vise.

Na adresi “Oracle Tehnical Information - High availability” mozete pronaci zaista odlicne tekstove o kreiranju HA (High availability) sistema, a navescu samo neke teme:

- Oracle Database 10g High Availability
- Technical White Paper - Oracle Data Guard: Ensuring Disaster Recovery for the Enterprise
- Oracle Recovery Manager 10g
- Preventing, Detecting, and Repairing Data Corruption
- Oracle Database 10g Online Data Reorganization and Redefinition
- How to Avoid Fragmentation

Tesktova ima jos, a isplati ih se procitati.

Danas smo prebacivali neke PL/SQL pakete sa testnog servera na acceptance server i prilikom provjeravanja da li sve funkcionise, pojavila se “neodredjena” greska:
ORA-29261: bad argument

Malo je reci da smo se smorili trazeci uzrok te greske, dok nisam krenuo rucno debugovati koristene PL/SQL pakete. U jednoj proceduri, koja je sluzila za slanje obavjestenja putem E-Maila (UTL_MAIL.send), debugger mi je stalno skakao u EXCEPTION dio. Skromno cu reci da sam minimalno 20 puta pregledao slovo po slovo, zarez po zarez, kako bih utvrdio da u kôdu sve stima. Kako ce se kasnije utvrditi - sve je i stimalo.

Problem je bio u init parametru SMTP_OUT_SERVER, koji nije bio uopste podesen. Rjesenje spomenute greske je:

ALTER SYSTEM SET SMTP_OUT_SERVER='smtp.domain.com:25' SCOPE=BOTH;

Umjesto smtp.domain.com treba staviti odgovarajuci naziv SMTP servera, a 25 je port SMTP servera, koji se i ne mora zadavati, jer je po defaultu 25.

U zadnje vrijeme primjecujem veliki broj wait eventa u bazi, a veliki broj njih se odnosi na “parallel execution” evente. Konkretno mi je za oko zapao event ”PX Deq Credit: send blkd“, pa sam trazio detaljnije informacije u vezi toga i naisao na izvanredan tekst o paralelnom izvrsavanju upita, koji sadrzi prilicno detaljna objasnjenja zasnovana na testovima obavljenim na razlicitim okruzenjima (bez paralelizma, sa paralelizmom, sa par procesora, sa vise procesora itd.).

Ukratko, ukoliko ste kreirali neku tabelu sa parallel degree vecim od 1 (kod mene je DOP 4; DOP = Degree Of Parallelism) i ukoliko imate OLTP okruzenje sa vise korisnika spojenih istovremeno, onda vam performanse mogu biti gore, nego kad je DOP manji ili kad se upit izvrsava bez paralelizma. Smanjio sam DOP na 2 i vec uocavam manje zauzece resursa u bazi po pitanju PX eventa. Pokusacu kreirati kopije tabela sa NOPARALLEL opcijom, pa cu izvrsiti nekoliko testova, kako bih uocio ima li poboljsanja ili nema.

Iako Oracle Support putem MetaLinka savjetuje da je “PX Deq Credit: send blkd” dobrocudni wait event, on trosi resurse i treba pripaziti na paralelno izvrsavanje zahtjevnih upita u multikorisnickom okruzenju.

Danas sam naletio na jedan zanimljiv PDF dokument u kojem su navedene razlike i slicnosti izmedju MS SQL servera i Oracle-a (”Beginning SQL, Differences between Oracle and Microsoft MS SQL server“).

Pored poredjenja tipova podataka i koristenja DML izraza, tu su jos i poredjenja outer i sub join-a, koristenje aliasa i td.

Isplati se procitati.

Zamislite ovu situaciju…

Prepravili ste jedan veliki paket ili proceduru na testnom serveru, odradili nekoliko testova i odlucili taj paket ili proceduru prebaciti na live production server. Uvjereni ste da bi i na tom serveru sve trebalo raditi bez problema.

Medjutim, nakon sto ste prebacili paket ili proceduru na live server, vec nakon par minuta javljaju se korisnici i kazu kako im program ne radi, kako dobijaju neke greske itd.

“Ali, istestirano je i sve bi trebalo da radi…” - zbunjeno odgovarate.
“Prije par minuta je sve radilo, a sad odjednom ne…” - nestrpljivi i ocajni korisnici s druge strane.

E sad, najelegantnije rjesenje bi bilo vratiti nazad prethodnu verziju paketa ili procedure, dok se ne ustanovi uzrok greske.

Ali avaj - vi niste osigurali sigurnosnu kopiju prethodne verzije tog paketa ili procedure, a u CVS-u ne mozete u kratkom roku izabrati, koja je prava i ispravna verzija!?

Takav scenario sam dozivljavao i u prethodnoj firmi, a i u ovoj. Dzaba govoriti kolegama da uvijek naprave backup trenutno ispravne verzije…

Zbog toga sam odlucio doskociti tom problemu i automatizovati kreiranje sigurnosne kopije (source code backup).

Evo kako sam ja to uradio…

Cilj: Prije nego sto programer ubaci novu verziju nekog paketa ili procedure, kompletan source code aktuelne verzije treba biti sacuvan u slucaju da novija verzija ne funkcionise kako treba.

Realizacija: Napravio sam jedan “ON DATABASE trigger“, koji se okida na database event “BEFORE CREATE“, sto znaci da ce source code aktuelne verzije biti sacuvan PRIJE nego sto se nova verzija ubaci u bazu. U triggeru mozemo odabrati nacin cuvanja source code-a: u datoteku ili u neku tabelu. Ja sam odabrao drugu opciju, jer je optimalnija od prve (brza je, preglednija, ne moram se bakcati sa UTL_FILE_DIR podesavanjima i td.).

Dakle, kreirao sam tabelu pod nazivom TAB_BACKUP_SOURCE i u njoj jedno CLOB polje u koje ce biti smjesten source code aktuelne verzije (download: DDL izraz za kreiranje tabele TAB_BACKUP_SOURCE).

Nakon sto je tabela kreirana, mozemo kreirati i “ON DATABASE” trigger. Za selektovanje source code-a mozemo koristiti dvije metode: DBMS_METADATA.get_ddl ili preko data dictionary “pogleda” DBA_SOURCE. Procedura GET_DDL u paketu DBMS_METADATA nam vraca kompletan DDL izraz (DDL je skracenica od Data Definition Language) potreban za rekreiranje doticnog objekta (paket, procedura, trigger i td.), ali se u njemu nalaze i suvisni podaci, koji nama nisu potrebni, tako da sam ja za “poglede” (views) odabrao metodu DBMS_METADATA.get_ddl, a za ostale objekte (paketi, procedure, funkcije, triggeri) sam odabrao DBA_SOURCE.

Za kreiranje ovog triggera je potrebna DBA privilegija (DBA role), ali niposto nemojte da koristite SYS nalog, nego ukoliko vec nemate jednog pomocnog DBA korisnika, onda kreirajte jednog i dodijelite mu DBA rolu.

Ako je taj uslov ispunjen, kreirajte “ON DATABASE” trigger (download: DDL izraz za kreiranje triggera).

Gotovi ste? Odlicno!
Napravite par testova da se uvjerite, kako je sve u redu.

Nakon ovoga se vise ne morate brinuti zbog nemarnosti ili lijenosti vasih kolega programera.

Nastavljam sa recenzijama Oracle knjiga.

Jedna od rijetkih knjiga, koja nije ispunila moja ocekivanja je knjiga “Oracle SQL Tuning & CBO Internals” autorice Kimberly Floss u izdanju Rampant TechPress.

Ocekivao sam jasan prikaz optimizacije SQL upita, sa poredjenjima kako treba i kako ne treba koristiti odredjene izraze, zatim kako Cost Based Optimizer u stvarnosti interno funkcionise i na sta treba voditi posebnu paznju pri programiranju izuzetno zahtjevnih SQL upita, ali sve sto sam u knjizi nasao je hrpa nabacanih tekstova raznih autora bez ikakvog reda i bez medjusobne povezanosti.

Autorica je prikupila kolekciju svojih tekstova i njoj pridodala tekstove slicne tematike od drugih Oracle strucnjaka (Mike Ault, Don Burlesson i td.), sto i ne bi bilo tako lose da je sve uredno rasporedjeno po cjelinama, ali ovako je stvarno naporno i smarajuce citati razbacane tekstove.

Tekstovi sami po sebi nisu nekvalitetni i ima nekoliko zaista korisnih primjera, npr. uticaj redoslijeda kolona (polja; engl. “columns”) u indexu. To znaci da cemo u zavisnosti od redoslijeda kolona u indexu imati i razlicite performanse - nije isto ako u indexu sa 3 kolone imamo na prvom mjestu NUMBER, pa DATE, pa VARCHAR2 ili drugu varijantu kad je DATE na prvom mjestu, NUMBER na drugom, a VARCHAR2 na trecem ili pak trecu varijantu kad je VARCHAR2 na prvom mjestu, DATE na drugom i NUMBER na trecem. Ovo je objasnjeno na prakticnim primjerima, ali je tako nepregledno, da sam morao 3 puta za redom citati citav tekst u vezi toga, da bih shvatio sta je autor napisao u primjeru.

Ima jos par izuzetno dobrih primjera sa koristenjem Oracle putokaza/smjernica (Oracle hints), kao i objasnjenja koje serverske parametre trebamo podesiti radi dobijanja sto boljih performansi.

Knjiga nije bas citljiva i ne preporucujem ju pocetnicima. Mogla bi jedino koristiti iskusnijim “hardcore” Oracle programerima, koji zele produbiti svoje znanje i koji imaju zivaca i vremena za korisne, ali za citanje naporne tekstove. 

Ocjena: 5/10