Svi postovi sa bloga: Baze podataka

Nakon što je nedavno Michael “Monty” Widenius, jedan od osnivača i autora MySQL-a, napustio Sun, a samim tim i MySQL, isti korak je napravio i njegov kolega i suosnivač MySQL-a David Axmark. Neizbježno je pitanje - kuda plovi MySQL brod? Šta će se desiti sa ovom popularnom open source bazom, sada kada su ključni ljudi napustili [...]
Problemi sa patchom 10.2.0.4 se nastavljaju… Jedna aplikacija nije mogla da funkcioniše, jer se konekcija sa bazom uvijek prekidala nakon pokretanja određene procedure. Dobijali smo grešku: ORA-3113: end of file on communication channel ili na njemačkom ORA-03113: Unerwartetes Übertragungsende in Kommunikation Pošto mi ta greška nije jasno davala do znanja u čemu je problem, morao sam tražiti dalje u čemu je [...]
Ovaj link mi pomaze da prenesem SQL kod u blog: http://www.simple-talk.com/prettifier/default.php Unse se kod iz SQL u Source code prozor (Cut/Paste). Onda se klikne dugme Prettify! u donjem levom uglu. Onda sve sto vidim u prozoru “Rendered SQL” iskopiram u prozor gde pisem tekst. Onda izaberem formatiranje “preformatted” za novi tekst, ako sam u Visual rezimu. U [...]
 Automatska obrada podataka pocela je kada je gospodin po imenu Herman Hollerith za potrebe americke vlade obradilo prikupljejne podatke o popisu stanovnistva. Tada jos nije bilo kompjutera, sve se dasava davne 1890. godine.  Gospodin Hollerith je zatim osnovao firmu, pod imenom Inetrnational Business Machines, dobro nam poznati IBM. Za ljubitelje istorje, evo interesantan link;  http://wiki.answers.com/Q/When_did_herman_hollerit_invented_the_tabulating_machine I naravno wikipedia [...]
Ovo sam vidio davno već, ali sam zaboravio da postoji još. Ukoliko vam radi preglednosti zatreba brzinsko formatiranje nekog SQL izraza, onda pravac na Instant SQL Formatter !
Pošto aktivno nadgledam bazu (RAC baza sa dvije instance), primijetio sam u određenim situacijama učestala “usporenja“, odnosno “wait events“, koja su se odnosila isključivo na RAC i interkonekciju između RAC instanci. Prvo da vas smorim suhoparnom teorijom, pa ću detaljno pojasniti “problem” i dati rješenje… Radi održavanja skalabilnosti i konzistentnosti podataka u bazi, obe instance šalju [...]
Pronasao sam kod za izracunavanje Uskrsa, po pravoslavnom i po katolickom kalendaru. Izvor: http://www.tek-tips.com/faqs.cfm?fid=5075 Pravoslavni: CREATE FUNCTION dbo.OEaster (@Yr as int) RETURNS datetime AS  -- SELECT dbo.OEaster(2007) BEGIN    Declare @I int, @J int, @Metonic int, @EMo int, @EDay int, @LeapAdj int    Set @LeapAdj=@Yr/100-@Yr/400-2    Set @Metonic=@Yr % 19    Set @I=(19*@Metonic+15) % 30    Set @J=(@Yr+@Yr/4+@I) % 7    Set @EMo=3+(@I-@J+40)/44    Set @EDay=@I-@J+28-31*(@EMo/4)    Return DateAdd(dd,@LeapAdj,cast(str(@EMo)+'/'+str(@EDay)+'/'+str(@Yr) as [...]
Nesto sto sam nedavno otkrio i opekao se: kada navodite listu kolona u SELECT izrazu, pa zaboravite zarez, MS SQL se ne buni, nego jednostavno ignorise deo naredbe. Na primer: SELECT Artikl, cena, Kolicina FROM Roba treba da ispise tri kolone. Ako napisete SELECT Artikl, cena Kolicina FROM Roba (nema vise zareza iz kolone Cena), MS SQL se nece [...]
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…

blogodak blog

Blogodak?

Blogodak je vaš pogled na domaću blogosferu. Prijavite se i napravite sopstvenu listu blogova koje pratite.

O projektu

Podrška

MyCity.co.yu

DevProTalk