Blogodak - srpski blogovi na jednom mestu

Evo prođoše nepune 2 godine otkako postoji ovaj blog i ovo je jubilarni 100. tekst, pa bih tim povodom po subjektivnom izboru izvadio 10 kvalitetnih tekstova iz naftalina, odnosno iz arhive. :) SELECT TOP 10 tekst AS ”Odabrani Tekstovi” FROM tekstovi ORDER BY datum_objavljivanja; - Kreiranje uskladistene procedure (How to create MySQL stored procedure) - Spajanje neprekidnih datumskih intervala - Struktura evidencije partnera - Spajanje [...]

Dok sam u više navrata čitao kako pojedini administratori Oracle baze podataka bacaju drvlje i kamenje na CBO (Cost Based Optimizer), mislio sam da oni nisu pravilno konfigurisali bazu ili da imaju neprikladan hardware (premalo RAM-a i slabi CPU resursi), jer zaboga - kako CBO, kojeg Oracle diže u nebesa i sa garancijom stoji iza svog tehnološkog čeda, može POGREŠNO da “naredi” bazi kako da pristupa podacima!? E, pa može! I nisu ti administratori bez razloga kukali na pogrešno funkcionisanje CBO-a …

To tvrdim iz ličnog iskustva, jer sam se iznenadio i iskreno začudio, kako CBO mijenja svoju ćud.

Instalirali mi zadnji 10.2.0.4 patch (zakrpa), u kojem su bili ispravljeni neki bugovi iz prethodnih verzija, ali se ispostavilo da i ova zakrpa ima rupu - i to više njih. Najočiglednije je bilo drastično povećanje vremena potrebnog za izvršavanje pojedinih aplikacija. Npr. jedan batch job, koji normalno bude gotov za pola sata, odjednom treba 6 sati da završi posao. Mnogi SQL upiti su u odnosu na prije trošili nenormalno puno CPU resursa ili su bjesomučno radili Full Table Scan umjesto Index Range Scan.

Provjerili smo hardware, da nije nešto crklo - sve je bilo u redu. System administratori nisu ništa mijenjali na nivou operativnog sistema. Jedino na šta smo sumnjali je bio taj zadnji patch 10.2.0.4, a kako se ispostavilo - tu je i ležao “problem”.

Nakon DETALJNOG čitanja  pratećih informacija vezanih za 10.2.0.4 patch, pronašao sam par zanimljivih stvari vezanih za CBO i nedokumentovane parametre. Slijedi copy-paste sa objašnjenjem:

“To enable a new native full outer join implementation in the database, a user has to set the following underscore parameter:
 
_optimizer_native_full_outer_join =force
 
You can set this parameter for the system or for a specific session.
 
Besides dramatically improving the performance of a full outer join, the new implementation fixes a variety of issues, for examples a variety of ORA-942 (table or view doesn’t exists) and ORA-4331 (unable to allocate string bytes of shared memory) errors.
 
This issue is tracked with Oracle bug 6322672.”

Aha - znači CBO sad drugačije posmatra full outer join. I ne samo to, nego i ostale kompleksne join kombinacije. Npr. za bug 7189447 pod naslovom  “Wrong results when view merging applied to query” predlažu “zavaravanje” CBO-a korištenjem Optimizer Hinta “NO_MERGE“, kako bi Cost Based Optimizeru rekli da ne radi to onako kako on misli da treba, nego malo drugačije:

“Wrong results are possible when the connecting condition of a subquery refers to an aggregating column of a group-by view. The problem is that the column is not recognized as a correlating column and consequently the view is merged when it should not be.

Workaround:
  Add a NO_MERGE hint to the subquery block to prevent it  from being merged or set “_complex_view_merging”=FALSE
at the system level.”

I tako postavim ja te nedokumentovane parametre na nivou baze:

alter system set “_complex_view_merging”=FALSE scope=spfile sid=’*';
alter system set “_optimizer_native_full_outer_join”=FORCE scope=spfile sid=’*';

kad gle čuda!!!!

Onaj batch job odjednom ne treba više 6 sati, nego 20-30 minuta, a killer-SQL upiti se ponašaju kao mirne ovce dok pasu na livadi.

Dakle, postavlja se pitanje - da li uvijek slijepo vjerovati Cost Based Optimizeru ili ga pokušati “prevariti” nedokumentovanim parametrima?

Ko zna kako će se CBO ponašati nakon nove zakrpe i kako će ti parametri uticati na CBO…

Upozorenje za sve, koji rade sa Oracle bazom na Windows platformi i planiraju instalirati zadnji Patchset 10.2.0.4 !

Naime, u prvoj verziji ovog Patchseta postoji Bug (MetaLink Bug: 7139820), koji “overwriteuje” (dajte neki dobar prijevod za ovu riječ!) postojeću sqlnet.ora datoteku! U novoj verziji (dostupna već od 10.07.2008.) je ta greška ispravljena, pa pazite koji Patchset ćete skinuti sa MetaLinka!

Old version Platform File name MD5 Checksum Size (bytes) 10.2.0.4 Microsoft Windows (32-bit) p6810189_10204_Win32.zip 38A59D4A3B902A399119C3AC45F81A41 1034079272 10.2.0.4 Microsoft Windows (AMD64 and EM64T) p6810189_10204_MSWIN-x86-64.zip 7D0BEC8CA58C1848B36C76DA755EF149 1122742981

 

 

 

 

 

New version Platform File name MD5 Checksum Size (bytes) 10.2.0.4 Microsoft Windows (32-bit) p6810189_10204_Win32.zip AF8818947E1903D008973B9F7CF3DF5B 1034621834 10.2.0.4 Microsoft Windows (AMD64 and EM64T) p6810189_10204_MSWIN-x86-64.zip E6992224A07FC00C210140585B0CF226 1123325074

 

 

 

 

 

Što bi se reklo - rupa u zakrpi.

Pošto dobijamo sve kompleksnije projekte, koji se baziraju na više platformi i okruženja, postavilo se pitanje - “Kako sve te podatke iz različitih izvora skupiti i obraditi na jednom mjestu?“.

Npr. imamo problem kako izvući podatke iz SimCorp aplikacije (Oracle na IBM AIX platformi), zatim iz SAP aplikacije (Oracle na Windows platformi) i podatke iz našeg Data Warehousea (Oracle na Windows platformi), te potom sve te podatke obraditi i pohraniti na jednom mjestu…

Gledali smo nekoliko rješenja - Cognos, IBM DataStage, Server Integration Service od Microsofta, Oracle Data Integrator i još par drugih, ali smo se na kraju odlučili upravo za Oracle Data Integrator (ODI) .

Šta je ODI?
ODI je ETL (Extract Transform Load) alat pomoću kojeg je moguće izvući podatke iz različitih izvora (Extract), transformisati ih prema zadanim kriterijima (Transform) i onda ih pohraniti (Load) na željenoj lokaciji (npr. u Oracle bazu). Doduše, ODI se predstavlja i kao E-LT (Extract - Load Transform) alat, ali u osnovi je to ipak ETL alat.

Po meni je ODI veoma kompleksan, glomazan i zahtjevan za korištenje, ali je istovremeno - zbog svih mogućnosti i opcija, koje nudi - fleksibilan i moćan. Pošto je urađen u Javi, moguće ga je koristiti na svakoj platformi, koja podržava Javu.

Sama instalacija nije zahtjevna, ali da biste napravili nešto konkretno sa ODI-om, morate dobro pročitati dokumentaciju i preći par praktičnih primjera. Mi smo imali dvodnevnu prezentaciju i radionicu, na kojoj smo isprobali tek mali dio opcija, koje ODI sadrži, ali tek nakon 10-15 dana svakodnevnog rada sa ODI-om, ulazi se u rutinu i tada ODI postaje “prijateljski” alat.

Okačiću nekoliko screenshotova, na kojima se može vidjeti funkcionalnost ODI-a, a ukoliko želite saznati više informacija, onda morate posjetiti službenu Oracle Data Integrator (ODI) stranicu.

Imam još i .ZIP datoteku (ca. 7.5 MB) sa PowerPoint prezentacijom, na kojoj su prikazani ODI arhitektura, instalacija, transformacija podataka, Metadata navigator i dodatni moduli, pa koga zanima, nek ostavi email adresu u komentaru…

Evo prođe i doba godišnjih odmora - ljeto je pri kraju, napunili smo baterije, odmorili se od kompjutera i baza podataka, pa smo sa svježom energijom spremni za nove radne pobjede i za pisanje novih tekstova.

Ja ću u narednim tekstovima pisati o nekoliko grešaka, koje smo dobijali u zadnje vrijeme koristeći Oracle bazu, kao i o rješenjima tih grešaka, zatim ću pisati o Oracle Data Integratoru i drugim korisnim alatima, a napisaću i par recenzija knjiga sa Oracle tematikom.

Kolege Srđan i Zidar imaju takođe u planu nekoliko tekstova, ali im fali malo motivacije za pisanje i objavljivanje tih tekstova - stoga, ukoliko želite da i dalje čitate korisne i kvalitetne tekstove, onda ostavljajte komentare, pišite nam na naše E-Mail adrese i dajte nam sugestije, prijedloge, kritike, pohvale i sl. !!!

Kada zelimo da uporedimo dve tabeleA i B, i da pokazemo koji su redovi prisutni u A a nema ih u B (Accessov ‘unmatched query’),to generalno mozemo da uradimo na nekoliko nacina. Mozemo da upotrebimo LEFT JOIN, mozemo da upotrebimo NOT IN ili NOT EXISTS.da li sus vi nacini podjednako dobri i pouzdani? Podjednako dobri znaci podjednako brzi, a pouzdani znaci da li daju tacan rezultat. Zanimljivo pitanje, da li daju tacan rezultat.

Pogledajmo primer. Kreirajmo dve jednostavne tabele i napunimo ih test podacima.

CREATE TABLE A (Broj smallint, ime VARCHAR(5))
GO
INSERT INTO A (Broj, ime) VALUES (1,‘Aca’)
INSERT INTO A (Broj, ime) VALUES (2,‘Maca’)
INSERT INTO A (Broj, ime) VALUES (3,‘Caca’)
INSERT INTO A (Broj, ime) VALUES (5,‘Aca’)
INSERT INTO A (Broj, ime) VALUES (6,‘Aca’)
GO
CREATE TABLE B (Broj smallint, ime VARCHAR(5))
GO
INSERT INTO B (Broj, ime) VALUES (1,‘Aca’)
INSERT INTO B (Broj, ime) VALUES (NULL,‘Maca’)
INSERT INTO B (Broj, ime) VALUES (5,‘Caca’)
GO  

Pokusajmo da upotrebimo NOT IN da pokazemo koji brojevi su u tabeli A a nisu u tabeli B:

SELECT A.* FROM A
WHERE Broj NOT IN (SELECT Broj FROM B) 

 

Sledi rezultat:

 

  Broj ime
—— —–
(0 row(s) affected) 

Ocigledno je da rezultat nije tacan. Pokusajmo sa NOT EXISTS:

SELECT A.* FROM A WHERE NOT EXISTS (SELECT Broj FROM B WHERE B.Broj = A.Broj)  

Rezultat ovaj put tacan:

    Broj ime

 —— —–      

2 Maca      

3 Caca      

6 Aca

(3 row(s) affected)

Da probamo i LEFT JOIN:

SELECT A.* FROM A
LEFT JOIN B ON A.Broj = B.Broj
WHERE B.Broj IS NULL

i dobijemo ponovo tacan rezultat:

  Broj ime
—— —–
     2 Maca
     3 Caca
     6 Aca(3 row(s) affected) 

 Zasto je ovo ovako? Primetite da u tabeli B imamo na jednom mestu NULL. E, taj jedan NULL cini da ono sto imamo u IN (SELECT..) vraca NULL. Onda <nesto> IN NULL vraca NULL.

Sta bi bilo kad bi i prva tabela, A, imala neki NULL u koloni Broj? 

UPDATE A SET Broj =  NULL WHERE ime = ‘Caca’

 

 

SELECT * FROM A

  Broj ime
—— —–
     1 Aca
     2 Maca
  NULL 

Caca
     5 Aca
     6 Aca (5 row(s) affected)

  ‘Ajde sve ponovo:

 

SELECT A.* FROM A
WHERE Broj NOT IN (SELECT Broj FROM B)

  Broj ime

—— —– (0 row(s) affected)

SELECT A.* FROM A
WHERE NOT EXISTS (SELECT Broj FROM B WHERE B.Broj = A.Broj)

  Broj ime
—— —–
     2 Maca
  NULL 

Caca
     6 Aca (3 row(s) affected)

SELECT A.*
FROM A
LEFT JOIN B ON A.Broj = B.Broj
WHERE B.Broj IS 

NULL   Broj ime
—— —–
     2 Maca
  NULL 

Caca
     6 Aca (3 row(s) affected)

 

 

Kao sto se moglo ocekivati, NOT IN gresi, NOT EXISTS i LEFT JOIN rade.

Na nesrecu, NOT IN se mnogo lakse pise nego NOT EXISTS ili LEFT JOIN. Da stvar bude gora, u ranijim verzijama MS SQL, NOT EXISTS je radilo znatno brze nego NOT IN. E, MS SQL 2005 je ‘ispravio gresku’ te sada NOT IN radi sito tako brzo kao NOT EXISTS ili LEFT JOIN. I to Microsoft oglasava kao ‘major improvement’, kao lakse se pise kod, zaboravite komplikovane sintakse itd.

Da se razumemo, ako nema NULL, onda sva tri nacina daju tacan rezultat. Znaci, dobar dizajn baze sa izbegavanjem NULL koiko god moze, pomaze da vas neki suptilni bagovi ne udare po glavi.

Ovaj “Write Post” editor me ubija. Dodaje razmake kad mu se prohte, prelama red gde mu padne napamet.Mislio sam da 30 godina od kako su kopjuteri izmisljeni mogu da naprave ljudski editor za web. Izgleda da nema nista od toga. Sve sto nije plain text mozes da zaboravis… Tuga jedna i zalost.

 

 

 

 

 

 

 

 

 

 

 

 

SELECT * FROM A 

 

 

Koliko puta mi se desilo da pokusam da izvrsim nesto ovako:

SELECT * INTO #TempTAble FROM MyTable

da bih dobio poruku

Msg 2714, Level 16, State 6, Line 1 There is already an object named ‘#TempTable’ in the database.

Pokusaj da ordadim ovo:

IF  Object_id(’#TempTable’) IS NOT NULL DROP #TempTable

daje mi ovo:

Msg 102 , Level 15, State 1,  Line 1 Incorrect syntax near ‘#TempTable’

Naravno, Object_ID radi samo sa ‘lokalnim’ tabelama. Medjutim, pametni ljudi nadju reseje za sve. Jedna pametan covek, Itzik Ben-Gan, u knjizi “Inside Microsofr SQL Server 2005: T-SQL programming” dao je ovakvo resenje:

IF Object_id(’tempdb..#TempTable’) IS NOT NULL DROP TABLE #TempTable

Radi bez greske, pa mogu da napisem:

IF Object_id(’tempdb..#TempTable’) IS NOT NULL DROP TABLE #TempTable
SELECT   *  INTO #TempTable FROM dbo.Board
i da me vise ne moram da mislim da li sam dropnuo ili nisam temp tabelu.

U istoj knjizi pise i da se temp tabela moze indeksirati, na primer
– Add some indexing:

CREATE  UNIQUE CLUSTERED INDEX id_tblSIF ON #tblSIF (StudentBarcode, FieldName)

Moja tabela od 500,000 slogova ce sada mnogo brze da odgovara na upite.

 

Ako pokušavate uraditi prebacivanje primarne baze u standby bazu, može se desiti da dobijete ovu grešku:
ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected

Prebacivanje (switchover) primarne baze u standby je moguće bez problema ukoliko u koloni v$database.SWITCHOVER_STATUS stoji vrijednost TO STANDBY. Međutim, ukoliko stoji vrijednost SESSIONS ACTIVE, onda će naredba “alter database commit to switchover to physical standby” javiti gorenavedenu grešku.

SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
SESSIONS ACTIVE

SQL> alter database commit to switchover to physical standby;
alter database commit to switchover to physical standby;
*
ERROR at line 1:
ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected

Listu aktivnih korisnika možete dobiti pomoću ovog upita:

SQL> select sid, process, program from v$session where type = 'USER' and sid <> (select distinct sid from v$mystat);

       SID PROCESS      PROGRAM
---------- ------------ --------------------
       468 2340:3416    racgimon.exe
       469 2340:3392    racgimon.exe
       470 2340:1548    racgimon.exe
       501 2340:3392    racgimon.exe

Rješenje je dodati klauzulu “WITH SESSION SHUTDOWN“, nakon čega će postupak prebacivanja (switchover) biti uspješan:

SQL> alter database commit to switchover to physical standby with session shutdown;

Ova naredba će prvo obustaviti sve korisničke radnje, pa tek potom obaviti prebacivanje primarne baze u standby bazu.

Napomena: U ovom slučaju smo racgimon.exe mogli zaustaviti i naredbom:

racgimon stop <instanca>
ili
racgimon stopd <ime_baze>

Za verziju 6.0, MySQL je najavio mogućnost “online backupa” baze (hot, non-blocking backup MySQL baze), što će obradovati mnoge MySQL administratore (a i nespretne developere ). Prema najavi, ova opcija ipak ne osigurava kompletnu bazu i sve njene pripadajuće elemente.

U backup su uključene sve perzistentne tabele kreirane sa jednim od ovih engine-a: myisam, memory, archive, innodb i falcon. Pored tih tabela, u backup su uključeni i “pogledi” (views), uskladištene procedure, funkcije (izuzev User Defined Functions), okidači (triggers) i “događaji” (events).

Lista elemenata, koji nisu uključeni u backup je poduga, pa da ne koristim copy/paste, pročitajte više o tome u originalnoj najavi (MySQL 6.0 : Online backup - What is not backed up).

MySQL najavljuje da mysqldump neće biti zapostavljen, nego da će se i dalje razvijati, te će služiti prvenstveno za klasični export/import podataka.

Kako napraviti backup baze?
Prema njihovom planu, ovako bi izgledao efektivni backup MySQL baze:
1. mysqld server uvijek pokretati sa opcijom -log-bin da bi sve izmjene bile sačuvane
2. periodično napraviti backup pomoću komande BACKUP DATABASE
3. provjeriti da li je backup uspješan
4. ako jeste, sačuvati kopiju od “backup image-file-a” na nekoj sigurnoj lokaciji

Naravno, povremeno treba testirati da li RESTORE radi kako treba.

Ukoliko vas zanima još više detalja u vezi online backup-a u MySQL bazi, pročitajte originalni tekst, a ja ću za kraj samo navesti njihovu napomenu: “Online Backup is not a completed feature. This document has only said what is actually here today. By the time that the feature is “beta” …“

Smatrate li se stručnjakom u svom poslu?
Da li ste uvijek u koraku sa novim tehnologijama?
Da li aktivno radite na obnavljanju, usavršavanju i unapređivanju svojih vještina?
Da li ste ikad doživjeli da vas mlađi kolega nadmaši u radnim zadacima, odnosno da neke stvari zna i radi bolje od vas, jer ste zahrđali?

Da ne biste došli u neugodnu situaciju…

 … u kojoj bi vaš status stručnjaka bio doveden u pitanje, morate voditi brigu o aktivnom usavršavanju svog znanja. Pošto je IT veoma dinamična branša u kojoj nije lako savladati nešto i potom godinama živjeti od stečenog znanja, usavršavanje i dopunjavanje tog znanja uz svakodnevno sticanje praktičnog iskustva nije nimalo lak zadatak.

Kolega i ja smo našli odlično rješenje - “igramo” se postavljanja zadataka po principu “ti meni - ja tebi“. Imamo nekoliko testnih sistema sa Oracle bazama, pa kad imamo vremena, postavimo jedan drugome određeni zadatak/problem. Ko ne riješi postavljeni zadatak, plaća ručak.

Tako sam ja njemu za početak postavio jedan škakljivi problem - dodao sam TNS_ADMIN varijablu i putanju postavio na C:\TEMP, nakon čega nije bilo moguće spojiti se na bazu, jer nijedan clientski program nije mogao da pronađe SQL*Net datoteke (sqlnet.ora i tnsnames.ora). Greška, koja se dobija prilikom spajanja na bazu, ne ukazuje direktno na pravi problem, pa je nakon par sati izgubljenog vremena i živaca skrušeno rekao - “Šta ćeš za ručak?“. Ne moram vam opisivati njegovu reakciju kad sam mu otkrio u čemu je bio problem. Ni na kraj pameti mu nije palo da bi to moglo biti u pitanju…

Ali već idući dan mi se osvetio. Postavio mi je jedan za’eban problem - napunio je kompletan prostor u Flash Recovery Area (FRA), pa potom ručno obrisao sve archive logove, nakon čega je baza javljala grešku kako u FRA nema slobodnog prostora iako ga je u stvarnosti bilo. Odustao sam nakon sat vremena, jer sam smatrao da je to maksimalno dopušteno vrijeme za pronalazak rješenja i uklanjanje greške. A rješenje je bilo banalno, kojeg sam se ustvari trebao sjetiti, jer sam imao sličan problem prošle godine - trebalo se spojiti RMAN-om na bazu i odraditi CROSSCHECK ARCHIVELOG ALL, pa onda DELETE NOPROMPT EXPIRED ARCHIVELOG ALL.

I tako se mi “igramo”, a usput obnavljamo znanje i stičemo nova praktična iskustva. Planiram mu iduće sedmice postaviti jedan zadatak u vezi PL/SQL programiranja, jer je tu tanak.

Dajte i vi neke prijedloge, kakve zadatke da mu postavim - što teže, to bolje.