A böngészőháború tovább zajlik

Ez a helyzet manapság. Látványos előretörés a bugróka irányából nem tapasztalható.

 

"Az Internet Explorer 85,82 százalékos részesedéssel bírt a Föld internetezői körében, a Onestat felmérése alapján, 2006 januárjában. Ez a nyár közepére 83,05 százalékra csökkent, aminek okára a következő bekezdésben világítunk rá. Itt érte el egyébként a redmondi böngésző népszerűsége mélypontját, mert ezt követően már emelkedett a felhasználók részaránya – az idei év első hónapjára gyakorlatilag ugyanoda (85,81 százalék) jutott, ahonnan tavaly elindult.

 

Hasonló, de ellentétes hullámzás volt megfigyelhető a Firefoxnál. A tavaly januári adathoz (11,23 százalék) képest a Tűzróka rajongótábora nyárra nőtt meg a legjobban (12,93 százalék), azaz az Internet Explorert használók egy jelentős része eddigre cserélte le a browserét. Ezzel ellentétes folyamat zajlott le ősszel: októberig esett a felhasználók száma (11,49 százalék), majd januárra – vélhetően az új böngészőváltozat kiadása miatt – ismét emelkedésnek indult; ekkorra 11,69 százalékot mértek a Onestat kutatói. A teljes évre kivetítve ez mintegy 4,1 százalékos emelkedést jelent."

 

Részletek itt.

Tilos idézni a Wikipediát

Milyen igaz. Próbálok én is leszokni róla, de nem mindig sikerül. Az a baj, hogy a Wikipedia-ban csábítóan sok adat van, mely könnyen elérhető, viszont nem tudni, hogy mennyire hiteles. Nagyon kényelmes idézni belőle, de az életemet meg a jövőmet nem bíznám rájuk az biztos.

 

"Tilos idézni a Wikipedia nevű internetes enciklopédia szócikkeit – határoztak egy amerikai főiskola oktatói, miután egyre több hibát találtak vizsgatesztekben és házi dolgozatokban, a diákok pedig a rendkívül népszerű enciklopédiában talált adatokra hivatkoztak.
 
A Vermont állami Middlebury főiskola történelem tanszékén úgy határoztak, hogy a diákok a jövőben nem használhatják forrásként a Wikipédiát vagy bármilyen hasonló kiadványt.

 

Továbbra is szabad olvasni, mert linkjei megbízható szakirodalomhoz vezethetnek, "elsődleges forrásként azonban a Wikipedia elfogadhatatlan" – áll a diákokhoz eljuttatott tanszéki utasításban.

 

Az International Herald Tribune című, Párizsban szerkesztett amerikai napilap csütörtöki számában megjelent cikk szerint a főiskola a lépéssel egyben állást foglalt a Wikipedia megbízhatósága és hitelessége körül zajló egyre hevesebb vitában.

 

A Wikipedia szócikkeit bárki tovább írhatja, vagy módosíthatja, az internetes enciklopédiát működtető nonprofit alapítvány pedig nem ellenőrzi a beírások valóságtartalmát, helyességét. Esetenként önkéntesek százai írják közösen a szócikkeket. Előfordul, hogy az adatok pontatlanok, és szándékos félrevezetésre is akadt már példa."

 

Eredeti hír itt.

Contig

Na mi az a contig? Eddig én se tudtam, de ma eljött a megvilágosodás. A Soci webnaplójában olvastam, hogy a "Contig" a Windows töredezettségmentesítő API-ját kihasználva (jé, ilyen is van?) képes egy-egy fájl (tehát nem az egész diszk) mentesítésére, felgyorsítására.

 

Contig a Sysinternals-tól itt. (Mark Russinowich által fémjelzett cucc)

 

Milliós email-ek

E szerint én egész nap nem csinálok semmit. Hmm.

 

"Munka közben, iskolában, otthon – gyakorlatilag a legtöbb helyen lehetőségünk van bekukkantani postafiókunkba, és rendre meg is tesszük. Az elektronikus levelek amellett, hogy nagyon fontosak, függőséggel is járnak – és akár jó, akár nem, legtöbbünk naponta többször is megnézi beérkezett leveleit.

 

Marsha Egan, az Egan Group Inc. igazgatója, aki tervei szerint segítséget nyújt majd a függőknek, szerint a jelenség igen nagy problémát jelent. A túlzott email használat ugyanis a vállalatok produktivitásának vesztésével jár, amely akár több millió dollár kárt is jelenthet. A szakember kidolgozott egy tizenkét pontból álló mintatervet, amely segít kiküszöbölni az inbox-szenvedélyt.

 

Egan szerint a munkafolyamat megszakítása után legalább négy perc kell ahhoz, hogy a dolgozó visszazökkenjen a kerékvágásba, így napi 30 levél már kifejezetten rossz hatással van a tevékenység mennyiségére és minőségére.

 

A szakember szerint az első lépés az volna, hogy felismerjük: az email mire is való valójában."

 

Eredeti hír itt.

Visual Basic linuxon

Pár éve próbálkoztam már C#-os program változtatás nélküli használatával linuxon. Sikerült is (no persze nem kell mindjárt egy atommaghasító programra gondolni, mert nem az volt).

 

"A Mono Project egy olyan compilert jelentett be, mely segítségével a forráskód módosítása nélkül lehetővé válik a Microsoft Visual Basic programok futtatása a támogatott operációs rendszereken — legfőképpen Linuxon. Felmérések szerint a Visual Basic továbbra is az egyik legelterjedtebb programozási nyelv, a kód jelentős módosítása nélkül eddig azonban kizárólag Windows platformon futott hibátlanul. A Mono Visual Basic compiler azonban a forráskód tökéletes multi-platform hordozhatóságát ígéri."

 

Részletek itt.

Adatbázis-piac

Megjelent a Microsoft SQL Server 2005 SP2. Ennek kapcsán idéztem itten a 2005-ös adatbázis-piaci helyzetképet.

 

"A kiadás számos újítást, fejlesztést hozott magával, melyek főként az üzleti intelligenciára, jobb együttműködésre más szállítok adatbáziskezelőivel, valamint a teljesítményre és a menedzsmentfunkciókra koncentrálódnak. A technikai fejlesztéseken túlmenően a szoftver licence is változásokat hoz magával a virtualizációval kapcsolatban.
[…]

A piackutatók 2005-ös adatai alapján (a 2006-osak egyelőre nem publikusak) a Microsoft a világ harmadik legnagyobb relációs adatbázis-kezelő szállítója az Oracle és az IBM mögött, a részesedés pedig a sorrendnek megfelelően 45-49, 21-22 és 15-17 százalék között alakul, az IDC és a Gartner becslése szerint. A három legnagyobb így a 15 milliárd dolláros piac 83-86 százalékát uralja, árbevétel alapján."

 

Részletek itt.

Megbízható NTFS-driver linuxhoz

Hurrá, hurrá. Már nagyon itt volt az ideje.

 

"Elérte az 1.0-s verziószámot az NTFS-3G, melynek segítségével Linux-alapú operációs rendszerek is képesek megbízhatóan írni és olvasni a Windows NTFS-partícióit.

[…]

Az NTFS-3G elsődleges célja, hogy megbízható NTFS-drivert hozzon létre, amely megpróbálja kizárni a saját működéséből fakadó adatvesztés lehetőségét. Minden egyes kiadást kimerítő tesztelés előz meg, hogy felfedezzék az esetleges hibákat. A fejlesztések fókusza a bugok folyamatos irtása, és a funkciók bővítése mellett jelenleg elsősorban a teljesítménynövelés, mivel a kód optimalizálatlansága következtében a driver processzorhasználata néha drasztikusan megugrik."

 

Részletek itt.

Torvalds kontra Gnome

Hát én ilyent még nem is hallottam. Ismét egymásnak esett Linus "linux" Torvalds meg a Gnome fejlesztői közössége. Az interfész-nácitól a kernel-komcsiig van itt minden, és akkor még ezek voltak a legfinomabb jelzők. Mindezt nyilvánosan, folyamatosan.
 
Nem hinném, hogy jót tenne az ügyüknek az ha, ha örökké gyepálják egymást. Az meg főleg furcsa, hogy Torvalds, akit sokan példaképüknek tekintenek, hogy vetemedhet ekkora arroganciára még akkor is, ha a Gnome esetleg tényleg pocsék (én se szeretem) és nem fejlődik úgy, ahogy sokan szeretnék. Érdemes majd a hazai hozzászólásokat is végigolvasni.

 

"2005. decemberében Linus arra buzdította az embereket, hogy azok használjanak GNOME helyett inkább KDE-t, mert nem volt elégedett a GNOME fejlesztők hozzáállásával. Úgy fest, hogy a béke továbbra sem állt helyre. A héten a Linux Foundation (korábban OSDL) Desktop Architects levlistáján ismét fellángolt a vita, aminek az lett a vége, hogy Christian F.K. Schaller "ledobta a kesztyűt" és megpróbálta válaszlépésre késztetni Torvalds-ot.

 

Azt mondta neki, hogy ha kész a kihívásra, akkor miért nem használ egy hónapon keresztül GNOME-ot, és megy el beszámolni a tapasztalatairól a nemsokára Angliában megrendezésre kerülő GUADEC-re? Ez jó lépés lenne a konstruktív vita indítása felé a hasztalan sárdobálás helyett.

 

Linus felvette a kesztyűt, és válaszolt a kihívásra, de nem abban a formában, ahogy a kihívó azt várta. Linus patch-eket küldött a GNOME-hoz és azt mondta a listának, hogy a patch-ek után a kód tisztább és használhatóbb lesz. "Lássuk mi történik. Ez konstruktív. – írta."

 

A Linux.com cikke az afférról itt.
Az eredeti, angol thread itt kezdődik"

 

Valamelyik hazai hozzászóló ezt írja: "…a hiba az, hogy a kde-sek is (mint a kernelfejlesztők is), rohannak előre új verzió, új szolgáltatás és közben még valamennyi hibajavítás. Egy új verzióban kijavítanak egy nagy rakás hibát ami a korábbi verzióban volt, de közben új dolgokat is fejlesztenek belé, amik újabb rakás hibát hoznak."

 

Nos, elgondolkodtató, de igaz lehet. Sokszor pont az ilyenekért becsmérlik a zárt forráskódú fejlesztőket, holott maguk is ugyanebbe a helyzetbe kerülnek. Emberek, ébresztő! Nyílt forráskód ide vagy oda, a linux se csodafegyver! Mikor jöttök rá végre, hogy ez az egész csak szemfényvesztés?

További hozzászólások (magyarul) itt. 

.NET Micro

Most olvastam. Vajon mennyire lesz sikeres?

 

"A Microsoft a napokban bejelentette .NET platformjának legújabb, egyben legkisebb kiadását. Az új .NET "Micro" változatot a cég a számítógépek gyakorlatilag legegyszerűbb formáját hasznosító eszközökbe szánja, mint például a mikrohullámú sütőkbe, és a távirányítókba."

 

Részletek itt.

MS Research “végtermékek”

X-COM naplójában olvastam, hogy 15 éves a Microsoft kutatóközpont. Ebbéli örömükben közzétették, hogy milyen termékekben öltött testet az, amit ők valamikor kitaláltak. Itt egy rövid, de korántsem teljes felsorolás:

 

 – Source code analysis tool
 – Kernel optimization tools
 – Performance optimization tools
 – Junk-mail filter
 – Enhancements for using multiple monitors
 – Smart tags technology
 – Sequential Clustering
 – Multiple storage organizations

 

Részletek: Product Contributions

A Windows Vista felpörgette a PC-piacot

Sokan nyavalyogtak, hogy úgyse fog menni a Vista, erre tessék. Pénzbe kerül mégis fogy (nyilván új PC-vel). Ráadásul piacot generál, ami másnak is jó.

 

"A Current Analysis elemzőcég csütörtöki jelentése szerint az ünnepi szezon utáni szokásos stagnálásra beállt PC-piacot robbanásszerűen élénkítette meg a Microsoft új operációs rendszerének, a Vistának január végi megjelenése."

 

Részletek itt.

A következő Windowst 2009-re ígérik

Ezzel kapcsolatban ismét eszembe jutott valami, amit már korábban is írtam. Nevezetesen az, hogy sokan úgy vélik hátrányos a Vista késése, meg hogy 5 évet kellett várni rá, és emiatt a pingvines majd jól kenterbe veri az ablakost. Merthogy egy-egy új linux verzió között általában véve csak 1,5 – 2 év várakozási idő telik el. Szóval emiatt többen úgy vélik hátrány, ha sok idő telik el két Windows változat között. Nos, ez is egy vélemény. Én viszont olyanokat is hallottam (többek között a saját főnökömtől), hogy "épp ez a jó". Mármint, hogy ha sok idő telik el két Windows között. Emiatt nem kell állandóan a verzióváltásra gondolni, nem kell újabb problémákkal megküzdeni, meg hogy a több idő nagyobb használati biztonságot nyújt. Ebben is van valami. Azt hiszem úgyis az üzleti érdek dönti el majd, hogy végül mi is lesz, és ez így helyes.

 

"Épphogy a piacra került a rég várt Windows Vista, a Microsoft fejlesztői már a következő operációs rendszerről beszélnek.

Ben Fathi, a Windows-rendszerek alapkutatási és -fejlesztési osztályának alelnöke a San Franciscóban rendezett RSA konferencián arról számolt be, hogy az új fejlesztés már sokkal gyorsabb lesz, mint a Vistáé, mely – hivatalosan – öt évig tartott. Fathi ezt az időtartamot kivételesnek minősítette, s elmondta, hogy az új OS már 2009-re kész lesz."

 

Részletek itt.

Adatbázis pillanatok – VI.

Előzőleg már többször is, méghozá jó alaposan fejest ugrottunk az adatbázis naplózási és helyreállítási tevékenységeibe, úgyhogy van aki biztos nagyon unja már. Megigérem, hogy e témában most fogok utoljára szólni.

 

Hibakezelés és naplózás (3. rész)

 

Ezidáig beszéltünk már sokmindenről, például alapfogalmakról, aztán az úgynevezett "semmiségi" (undo) és "helyreállító" (redo) naplózásokról, illetve a hozzájuk társuló helyreállítási tevékenységekről is. Azt is láthattuk, hogy a naplózás két megközelítése abban mutat eltérést, hogy a napló az adatbázis-elemek értékének módosítása esetén a régi (módosítás előtti) vagy az új (módosítás utáni) értékeket tartalmazza.

 

Persze mindkét módszernek vannak bizonyos hátrányai:

• A "semmisségi" (undo) naplózás megköveteli, hogy az adatok a tranzakció befejezésekor nyomban a lemezre íródjanak,
  ezzel (esetleg jelentősen) növelve a végrehajtandó lemezműveletek számát.
• Másik oldalról a "helyrehozó" (redo) naplózás, minden módosított adatbázis-blokk pufferben tartását igényli, egészen
  a tranzakció rendes és teljes befejezéséig (COMMIT), a napló kezelésével együtt, ami (esetleg jelentősen) növeli
  a tranzakciók átlagos pufferigényét.
• Mindkét naplózási módszer az ellenőrzőpont-képzése közben ellentétes igényeket támaszt a pufferek lemezre írása szempontjából, kivéve ha az adatbázis-elemek teljes blokkok vagy blokkok sokasága.

Van azonban egy harmadik módszer is, amely a tevékenységek elvégzési sorrendjének rugalmasságát növeli azáltal, hogy bővíti a naplózott információk körét. Ezt a módszert "semmisségi/helyrehozó" (undo/redo) naplózásnak nevezik, amely ugyanolyan típusú naplóbejegyzéseket használ, mint a korábban említettek. E módszerben az adatbázis-elem értékének módosítását leíró naplóbejegyzés négy részből áll: <T,X,v,w> . Ez a <T,X,v,w> bejegyzés azt jelenti, hogy a "T" tranzakció az "X" adatbázis-elemének korábbi "v" értékét "w"-re módosította.

Van azonban egy előírás, melyet mindenképp be kell tartani: Mielőtt az adatbázis bármely "X" elemének értéke (valamely "T" tranzakció által végzett módosítás miatt) a lemezen átíródna, ezt megfelőzően a <T,X,v,w> módosítást leíró naplóbejegyzésnek a lemezre kell kerülnie. A "semmisségi/helyrehozó" naplózás eme szabálya csak azokat a feltételeket kényszeríti ki, amelyek a semmisségi és a helyrehozó neplózási szabályok mindegyikében szerepelnek. Speciálisan a <COMMIT T> bejegyzés megelőzheti és követheti is az adatbázis-elemek lemezen történő bármilyen megváltoztatását.

Helyreállítás során a módosítást leíró naplóbejegyzésben megtalálható a "T" tranzakció hatásainak semmisségéhez szükséges régi (v), és a helyrehozásához szükséges új (w) adatbázis-elem értékek is. 

A "semmisségi/helyrehozó" módszer helyreállítási alapelvei:

• a legkorábbitól kezdve kell helyreállítani minden befejezett tranzakció hatását,
• a legutolsótól kezdve kell semmissé tenni minden be nem fejezett tranzakció tevékenységeit.

Természetesen mindkét eljárásra szükség lehet. A rugalmasság lehetővé teszi, hogy a COMMIT bejegyzés és a lemezen végrehajtott adatbázis-módosítások egymáshoz viszonyított sorrendje kötetlen legyen, így előfordulhat az is, hogy egy befejezett tranzakció néhány vagy összes változtatása még nem került a lemezre, és az is, hogy egy be nem fejezett tranzakció néhány vagy összes módosítása már a lemezen is megtörtént.

Nyilvánvalóan az se okozhat már túl sok meglepetést, hogy a korábbiakhoz képest a "semmisségi/helyrehozó"  naplózás is alkalmaz ellenőrzőpontokat (check point), csak egy picit egyszerűbben, mint ahogy az eddig megismert módszereknél ez látható volt:

• a naplóba <START CKPT (T1,…Tk)> naplóbejegyzés kerül, ahol a ‘T1,…Tk" az összes, éppen aktív tranzakciók száma,
• ezután a naplóbejegyzés tartalma a lemezre kerül (FLUSH),
• valamint lemezre kerül még az összes úgynevezett "piszkos" puffer is, tehát azok, melyek egy vagy több módosított
  adatbázis-elemet tartalmaznak (a helyrehozó naplózástól eltérően itt az összes "piszkos" puffer a lemezre íródik,
  nem csak a már befejezett tranzakciók által módosított),
• végül egy <END CKPT> bejegyzés kerül a naplóba, majd a napló tartalma ismét a lemezre kerül (FLUSH).

A "semmisségi/helyrehozó" naplózás által, a merevlemezre való írások sorrendjének rugalmassága végett megengedhető, a még be nem fejezett tranzakciók adatainak lemezre való kiírása. Ez egyben azt is jelenti, hogy lehetséges az olyan, teljes blokknál kisebb adatbázis-elemek használata, melyek közös memóriapufferbe kerülnek. Egyetlen szabályt kell csak betartani, mégpedig azt, hogy: a tranzakció semmilyen értéket nem írhat (még a memóriapufferbe se), amíg nem válik biztossá, hogy az nem fog abortálni.

Úgy vélem a naplózás témakörét a lehetőségeinkkhez képest alaposan kimerítettük. Az eddig említett módszerek a leginkább használatosak, de nem kizárt, hogy vannak más megoldások is.

Mint ahogy a sorozat legelején is írtam, ezekkel a témákkal én csak a felszínt kapirgálom. Valójában ott lent a mélyben, hatalmas, szunnyadó anyagrészek megismerésére volna még szükség (pl.: indexek kezelése, lekérdezésfordító, lekérdezésvégrehajtó, konkurenciavezérlés). Jó lenne, ha más is egyszerű, de közérthető módon ismerkedhetne meg velük. Manapság nem elég csépelni a billentyűt meg közben szörnyű okosságokat mondani különböző fórumokon, mert valljuk be, azt egy középiskolás informatikus is tud. Az se elég, ha valaki tud SQL-utasításokat írni, melyek működnek valahogy. Ahhoz azonban, hogy valaki igazán hatékony, gyors és jól működő, több ezer ember igényeit kiszolgáló adatkezelő rendszereket készítsen fontos, hogy értse mi miért zajlik a háttérben. Ehhez pedig sokat kell tanulni, olvasni, tapasztalni.

Mindig is mondtam, hogy természetesen én nem magamtól vagyok ilyen tudálékos, hanem gyakran forgatom a hazai és külföldről származó szakirodalmat. Ilyen pl. Molina-Ullmann-Widom: "Adatbázis-rendszerek" című kötete, mely két részből áll: ALAPVETÉS, MEGVALÓSÍTÁS, és amelyek nélkül félkarú óriásnak (se) érezheti magát az ember.

Windows 7

Billi bátyó ismét vízionál, mint már annyiszor. Nem baj, ez a dolga (többek között).

 

A minap feltették a nagy kérdést, hogy vajon mit akarnak a felhasználók következő Windowstól? A válasz igen egyszerű: "A nem hivatalos felmérések szerint apróságokat: gyorsabb ki- és bekapcsolást, és még nagyobb megbízhatóságot. Azt, hogy a lehető legjobban tűnjön el a felhasználó szeme elől, és ne zavarja hétköznapi munkájában, szórakozásában."

 

De nekem a legjobban mégis az egyik szemléltető példa tetszett (olvasói vélemény): "Az ember nem kíváncsi arra, hogy miből készült a hűtő, csak használja fagyasztási funkcióját."

 

Na, kéremszépen ez itten a dolgok sava-borsa. Szeretném, ha a mélyen tisztelt tuxosok (főleg akiknek altájéki bizsergést okoz egy kernelforgatás vagy bármely más configure; make; make install jellegű művelet) jól megcsócsálnák, aztán magukévá tennék ezt a fenti rövidke kis mondatot.

 

Sikerült? Biztoooooos? Na, ha tényleg megvan, akkor talán a kedvenc játékszerük és az olyannyira imádott filozófiájuk is helyes útra térhet. Amennyiben így lesz, vagyis ha már nem kell tudni mi az a mount,  eszik vagy isszák-e a kernelt, hogy is néz ki a KDE, esetleg a Gnome-e a királyabb, vagy hogy letöltöttem-e az eheti patch adagomat, vagy hogy is van az az apt-get, meg mi fán terem a függőség-kezelés… és még sorolhatnám akkor, de csakis akkor valóban eljön majd az az év, amire annyira vágynak. Addig viszont be kell éri a sátán e téren némileg jobb filozófiájával. Vagy ha nem is jobb, de a felhasználók körében lényegesen sikeresebb. A felhasználók, pontosabban az egyszerű felhasználók nélkül pedig úgyse fog menni. Csakis az ő hátukon lehet feljutni a csúcsra. A birodalom és a Windows is nekik köszönhet mindent (na meg a jó vállalati stratégiának).

 

Tudom, hogy van akinek az anyukája, nővére, vagy a szomszéd Pistikéje már eljutott idáig (mármint a linux zökkenőmentes használatáig). Na és? Mi van a maradékkal? Azzal a mintegy 800 millió emberrel?

 

Nem kell egyetérteni velem, de a helyzet attól még jottányit se fog változni. Uff.

 

Pár szó az Oracle optimalizálóról

Örök probléma lehet az SQL-utasítások (elsősorban a  SELECT-ek) teljesítménye. Néhányan azt hiszik, hogy értik, aztán kiderül, hogy mégsem. Jelen esetben a leginkább elterjedt Oracle adatbázis-kezelő rendszer optimalizálójáról csevegünk könnyed, nem túl mélyenszántó formában (úgy értem csevegek, de csak magammal).

 

Minden adatbázis-kezelő rendszer tartalmaz egy olyan beépített, automatikusan működő komponenst, amelynek az a feladata, hogy a SELECT SQL-utasítás végrehajtásának pillanatában (pontosabban előtte) megtervezze azt, hogy milyen módon fogja elérni és szolgáltatni a kívánt adatokat. Ezt a komponenst "lekérdezés optimalizálónak" (query optimizer) nevezik.

 

Egy SELECT-et többféleképpen is végre lehet hajtani, de a legjobb persze az, ha minél gyorsabban. Elsőként, annak ízekre boncolása és ellenőrzése után, ha minden helyesnek bizonyult, akkor maga a lekérdezés-elemző hamar átadja azt a reá várakozó optimalizáló szomszédjának. Akinek nincs más dolga, mint a lehető legrövidebb időn belül (néhány századmásodperc alatt) olyan tervvel rukkoljon elő, amelyet a lekérdezés végrehajtó komponens majd végre is tud hajtani. Ettől a tervtől (meg mástól is) nagymértékben függ majd a végrehajtás sebessége (villámgyors, normális, lassú vagy kivárhatatlan).

 

Az Oracle adatbázis-kezelő rendszerben jelenleg kétféle optimalizálási módszer működik:

• szabály alapú, vagy más néven RBO (Rule Base Optimizer), illetve
• költség alapú, vagy más néven CBO (Cost Base Optimizer).

Oracle verziótól és a telepítést végző személytől függően más-más az alapértelmezett beállítás. Az Oracle maga a CBO (költség alapú) optimalizálást részesíti előnybe, emiatt RBO (szabály alapú) módszert már nagyon régóta nem fejleszti tovább, mivel nem használja benne a 8-as verzió óta keletkezett fejlesztéseket (pl.: bitmap index, partícionált táblák, stb).

 

Mégis mi a különbség a kettő között?

 

RBO esetén a lekérdezés optimalizáló a lekérdezési terv meghatározásához mindig, mindenkor nagyjából ugyanazt az algoritmust használja többnyire indexek alapján) , és nem veszi figyelembe az adatbázis aktuális állapotát (vagyis inkább statikus).

 

CBO esetén a lekérdezés optimalizáló mindig az aktuális adatbázis állapot (táblaméret, sorok száma, indexek megléte, stb), alapján dönti el dinamikusan, hogy melyik lekérdezési tervet válassza a végrehajtáshoz. Igen, nem elírás volt, a CBO valóban több tervet is készít egyszerre (néhány századmásodperc alatt, vagy kicsit tovább…), és ezek közül azt fogja kiválasztani végrehajtásra, amelyik a legkevesebb erőforrás felhasználásával (memória, processzor, merevlemez írás/olvasás szükségletek) éri el a célját.

 

A fentiekben olvashattuk, hogy az RBO inkább statikusan, a CBO inkább dinamikusan dolgozik. Ennek a dinamizmusnak azonban ára van. Ahhoz, hogy a CBO ismerje az adatbázis aktuális állapotát (táblaméret, sorok száma, indexek megléte, szelektivitás/egyediség hisztogrammok, stb) szüksége van úgynevezett "statisztikai adatokra".

 

Ezek a statisztikák tartalmazzák mindazokat az információkat, melyek a helyes döntésehez szükségesek. Mivel az adatbázis állandóan változik (legalábbis egy része), így a statisztikai adatoknak is változniuk kell. Vagyis nem elegendő őket egyszer létrehozni, hanem folyamatosan frissíteni is kell (a virágot is locsolni kell, különben elhervad). Naprakész statisztikai adatok nélkül a CBO optimalizáló téves döntéseket hozhat, ami viszont katasztrófális teljesítményhez vezethet. Tehát a CBO (költség alapú) alapú optimalizálási mód használatakor gondoskodni kell a statisztikai adatok frissítéséről is. Ez történhet éjszaka egy beépített és időzítve végrehajtható Oracle eljárás (job) segítségével, de akár történhet napközben, kézi frissítéssel is ("DBMS_STATS.Gather_Schema_Stats" tárolt eljárás).

 

A statisztikafrissítés kellemes, ám roppant erőforrás és időigényes munka. Emiatt, valamint a CBO-alapú algoritmusok (végrehajtási tervek) tartós működtetése miatt olyan Oracle szerveren, melynek a fizikai memóriája 3 GB alatti, nem is lehet ezt normálisan beüzemelni (pl.: a régi ügyfeleinknél gyakorlatilag használhatatlan, ezért be sincs kapcsolva, és az erre utaló erőfeszítések is hiába valóak és feleslegesek).

 

FONTOS!
A fentiek tudatában nem lehet elégszer ismételni a következőket: CBO alkalmazása mellett, attól, hogy valaki, valamelyik szerver akármelyik sémáján(adatbázisán), a saját SELECT-jének gyorsítása érdekében létrehozott statisztikákat, és az hiperűrsebességgel dolgozik, még nem biztos, hogy egy másik sémán, egy másik szerveren is ugyanolyan gyorsan fog működni, sőt. Majdnem biztos, hogy máshol tetűlassú lesz (vagy legalábbis megbízhatatlan) akkor, ha az optimalizálási mód és a statisztikák nem állnak megfelelően. Tehát csak óvatosan a CBO-val!

 

A CBO optimalizáló működését befolyásoló statisztikai adatokat lehet exportálni és importálni akkor, ha valaki ismeri az erre vonatkozó szabályokat és paramétereket. Ha valahol letöltünk egy sémát (adatbázist), máshol meg feltöltjük, akkor egyáltalán nem biztos, hogy a statisztikai adatok is átkerülnek az új helyre (vagyis egyáltalán nem biztos, hogy az új sémán is ugyanolyan gyors lesz a lekérdező SELECT). Az optimalizáló működési módját Oracle konfigurációban, vagy munkamenet (session) szinten, esetleg magában a SELECT utasításban lehet előírni (ha valaki a központilag beállítottól eltérőt szeretne). Rendszerint azonban mindez a telepítéskor, a szerver oldali konfigurációs fájlban ("init.ora" vagy "spfile") dől el.

 

Az RBO mindig, mindenhol többé-kevésbé ugyanúgy (ugyanolyan jól vagy rosszul) működik, és kevésbé függ az  adott környezet, illetve az adminisztrációs tényezőktől (pl.: rendszergazdai lustaság, vagy elegendő hardverkapacitás hiánya). A tapasztalataink szerint bizonyos helyzetekben az elavult RBO sokkal megbízhatóbb, egyenletesebb teljesítményt nyújt, a korszerű CBO-val szemben. A régi RBO (szabály alapú) optimalizáló működését, azaz a lekérdezés sebességét rendszerint indexek létrehozásával vagy törlésével tudjuk befolyásolni (persze ez se mindig sikerül úgy, ahogy várnánk).

 

A CBO (költség alapú) optimalizálónak is van az RBO működését megközelítő állapota (nagyjából a "FIRST_ROW", bár nem teljesen).

 

Mivel az Oracle előbb-utóbb megszűnteti az RBO-t, így az ilyent használó üzemeltető válallatok, intézmények kénytelenek lesznek erősebb hardverre váltani. A jobb hardverre a CBO statisztikák és a hozzá tartozó működtetés erőforrásigényének a kiszolgálása miatt lesz szükség.

 

Az Oracle optimalizáló működésének további boncolgatása már meghaladja ezen írás kereteit, úgyhogy egyelőre legyen elég ennyi. Később írok többet is, sőt példákat is fogok hozni. De nem most…