Database thingies

Nakon uspjesnih beta testiranja, dolazi i sluzbeni “launch”:
Oracle Database 11g Launch

Aj’ da vidimo konacno, sta su sve ubacili/izmijenili u novoj verziji…

Konacno! Danas polozih ovaj upgrade ispit 1Z0-040 (1Z0-040 - Oracle 10g: New features for administrators)  sa OCP 9i DBA na OCP 10g DBA. Bilo je par tricky pitanja, koji su me totalno zbunili, pa sam odgovor takoreci morao blefirati, ali sve u svemu ispit nije bio tezak.

Posto vise ne trebam ovaj SelfTestSoftware, dajem ga u zamjenu za nesto sa ove liste:
- Oracle knjiga,
-  2 GB RAM-a
- 1 Hard disk od oko 200 GB prostora 

Ko se prvi javi, njemu ide STS, a ja cekam 11g.

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.

Prelistavah sajtove u svojoj bookmark listi, pa naidjoh na jedan odlican clanak o naprednoj replikaciji u MySQL-u. Ako se smatrate naprednim MySQL korisnikom ili administratorom, ovaj tekst morate obavezno procitati.

Link: MySQL advanced replication