Rozdíl mezi SQL a MySQL

Re: Rozdíl mezi SQL a MySQL
« Odpověď #30 kdy: 29. 11. 2010, 12:28:02 »
Souhlasim s tim, ze ma odpoved je hodne zjednodusena, ale predpokladam, ze jako odpoved na dotaz zacatecnika postacuje.

Toto je ale uplna blbost. Prave koli takymto odpovediam potom vznikaju pseudo odbornici, ktori to vycitali niekde v diskusii ako jedno jedine super riesenie. Takato odpoved akurat zaciatocnika zmatie a prinajhorsom to zacne chudak dalej rozsirovat. Co uz len co za hovadinu takto skatulkovat databazy.


DBA

Re: Rozdíl mezi SQL a MySQL
« Odpověď #31 kdy: 29. 11. 2010, 16:06:12 »
Nicmene by me zajimalo, proc s tim nesouhlasis.

Nesuhlasim s tym z viacerych dovodov, ale ten najhlavnejsi, je ta veta znela prilis generalizovane. A tu je problem. TD vzhladom na to ako funguje je urcena primarne pre DSS.
Dalsia vec je, ze tvoj general statement vyznel ako keby Oracle a MSSQL su nevyhovujuce, pricom prave tieto dva spomenute maju najvacsi trhovy podiel v tejto oblasti.

DBA

Re: Rozdíl mezi SQL a MySQL
« Odpověď #32 kdy: 29. 11. 2010, 16:36:41 »
Mierne ta poopravim.

Okrem toho, zo stranky Oracle,com je mozne oproti bezplatnej registracii stiahnut plna verzia DBS, takze ani vyhovorky typu zadarmo/za peniaze nie su na mieste.

1. Pre tieto ucely bola spravena edicia XE, cize Oracle XE, takze nie je dovod tahat plnu DB, lebo az na par limitacii (ktore s prepacenim vysokoskolsky student potrebovat nebude) je v plnej verzii. Cize na tento ucel ako stvorene. Mimochodom taketo iste ponuka aj MS.
2. Ano, stiahnut to mozes zdarma, ale podla licencnych podmienok, to mozes pouzivat bez zaplatenia licencie iba 30 dni, to si zabudol povedat.
3. Ak sa nemylim tak este stale mas skola vlastny repozitar, z ktoreho je mozne potrebny SW stiahnut (nakolko skola ma tieto veci licencovane pre vyuku) aspon.

Naucil som sa co najviac vyuzivat standardne riesenia, pricom viac-menej poznam zakladne crty a odlisnosti jednotlivych DBS a imho, tak to ma byt. Samozrejme, obcas sa vyskytne situacia, ked je vyhodnejsie pouzit nejaku specialnu vlastnost danej databazy, ale vacsina veci sa da riesit univerzalne.

Na jednej strane chvalim tvoj postoj ohladne standardnych rieseni a na druhej strane nesuhlasim. Co je dolezite, ze si nespomenul co je podla teba standardne riesenie.
Nevadi, nacrtol si najvacsi problem dnesnych aplikacii a preco ludia, ktori su zodpovedni za spravu DB nadavaju na aplikacie a hlavne ludi, co ich pisali.
Pretoze ta univerzalnost je prave problem. Kazda DB ponuka nejaku vlastnost, ktora vyuzije potencial (povedzme signifikantne urychli vykonanie dotazu) DB. Ale developer ju nepouzije. Preco?
a) lebo o nej nevie - dost casty jav
b) lebo taka vlastnost nie je povedzme na Sybase alebo Firebird (priklad), pre ktoru ma aplikacia tiez fungovat

Takze miesto toho aby som vyuzil vsetok potencial z mojho Mercedesu E, za ktory som zaplatil velke prachy pri nakupe a platim velke prachy za support, tak mam klasicky ludovy Peugeot 307. Naopak toto je najrozsirenejsi a hodne zauzivany omyl. Prave naopak, je velmi dolezite pisat pre konkretnu DB, vyuzit vsetky jej prednosti (pre ktore bola vybrata a pre ktore je platena). Ak chces pisat naozaj univerzalne, tak prosim, ale v tom pripade pouzivaj prislusne query v zavislosti od pouzivanej DB, cize inymi slovami od konfiguracie bude zavisiet sada query, ktore sa budu nad DB spustat. Ze to je prilis zdlhave? Ano je, ale ovela lahsie Ti to umoznuje prave specificke zmeny pre konkretnu DB bez toho, aby si nejakym sposobom ovplyvnoval iny typ DB alebo este horsie zavadzal nejaku nechutnu barlu (rozumej workaround) do aplikacie. A zaroven nepouzivas viazaci drat, tam kde su potrebne hmozdinky a skrutky.

DBA

Re: Rozdíl mezi SQL a MySQL
« Odpověď #33 kdy: 29. 11. 2010, 16:50:00 »
Mysql možná ne. Ale postgresql (pokud není potřeba replikace, jak je to ve verzi 9.0 popř. postgresql cluster) nabízí v podstatě skoro stejný možnosti jako Oracle.
Navíc - webhosting s postgresql je všude, na oracle potřebuješ VPS.

Prostě je tu oracle a je tu postgresql, oba maj jiný náklady a jiný přednosti. Preferovat pouze oracle je postoj vhodnej tak do státní správy.

Zaujimavy pohlad, ale skusim to takto. (Cisto hypoteticky)  Povedzme, ze dostanete ulohu vybrat DB, kde hlavnym kriteriom vyberu vo vyberovej matici by bola "maximalna eliminacia moznosti straty dat" a az potom vsetko ostatne vratane ceny. Ktoru DB by ste preferovali? Ja Oracle, co vy?

Lenin POWER!

  • ****
  • 434
  • Nekecat a delat!
    • Zobrazit profil
    • Tribut Leninovi
    • E-mail
trzni podil RDBMS
« Odpověď #34 kdy: 29. 11. 2010, 18:28:52 »
Dalsia vec je, ze tvoj general statement vyznel ako keby Oracle a MSSQL su nevyhovujuce, pricom prave tieto dva spomenute maju najvacsi trhovy podiel v tejto oblasti.
Trojka Oracle, DB2 a MSSQL zabira dohromady 85% trhu. Na ostatni databaze toho moc nezbyde. Navic Oracle ma asi dvojnasobny naskok oproti DB2 ktera je druha.
Skoda jen je, ze z techto srovnani je vynechan IMS (aka DB1) neb neni RDBMS. Ten ve sve kategorii po 40 let vpodstate nema konkurenci kdyz nepocitame TPF. IMS neni vubec levny software, vyrazne drazsi nez Oracle/DB2, dival jsem se do ShopZ a projistotu tam nemaji IMS cenu ani uvedenou.


Ivan

Re: Rozdíl mezi SQL a MySQL
« Odpověď #35 kdy: 29. 11. 2010, 19:04:49 »
Dalsia vec je, ze tvoj general statement vyznel ako keby Oracle a MSSQL su nevyhovujuce, pricom prave tieto dva spomenute maju najvacsi trhovy podiel v tejto oblasti.

1. Trzni podil nevypovida o kvalite/vhodnosti produktu, ale o tom, jak byl zvladnut marketing jeho vyrobce. To nam uz snad historie nekolik krat dokazala a porad dokazuje.

2. muj "general statement", jak jsi to nazval, nemuzes vytrhnout z kontextu! Ja jsem pred jeho vyhlasenim psal o tom, ze kazda DB je vhodna na neco jineho a je potreba udelat SWOT analyzu pro spravny vyber dle parametru, ktere nas zajimaji. Ale zacatenik ji delat jiste nebude a je nesmysl aby zacal na Oraclu.

3. Taky urcit market share DB neni zadna legrace a temer nikdo nevi jak se dobrat k rozumnym cislum. Napriklad:
http://www.mysql.com/why-mysql/marketshare/
http://www.informationweek.com/news/software/database_apps/showArticle.jhtml?articleID=207402230
http://www.gartner.com/it/page.jsp?id=507466
Ovsem docela zajimave jsou vysledky vyhledavani dle klicovych slov DB serveru.
http://www.citrustechnology.com/blog/database-market-share
Docela me prekvapilo, ze nevede Oracle, vzhledem k poctu pruseru, ktere se s tym serverem musi resit. ;-)

Lenin POWER!

  • ****
  • 434
  • Nekecat a delat!
    • Zobrazit profil
    • Tribut Leninovi
    • E-mail
Re: Rozdíl mezi SQL a MySQL
« Odpověď #36 kdy: 29. 11. 2010, 19:38:23 »
Povedzme, ze dostanete ulohu vybrat DB, kde hlavnym kriteriom vyberu vo vyberovej matici by bola "maximalna eliminacia moznosti straty dat" a az potom vsetko ostatne vratane ceny. Ktoru DB by ste preferovali? Ja Oracle, co vy?
DB2 pro zOS. Ta se da provozovat s nulovym downtimem klidne po deset let, umi i major upgrady i vymenu HW bez zastaveni DB, Oracle neumi ani vsechny minor. Neni ani tak draha (asi jen 4x drazsi nez Oracle) a ten mainframe HW taky neni nijak vyjimecne drahy i kdyz pravda oni si to vynahradi na doplnkach. $6k za 1GB RAM. Rozhodne je to idealni prostredi pro 24x7 provoz.
Oracle neni nic moc, toho rozhodi i to ze disk ma write cache zapnutou a keca o tom ze zapsal data na disk do logu. Zapnout write cache u disku a mackat reset, po restartu project db na zmrsene bloky. I kdyz tohle rozhodi vetsinu databazi pokud nejsou specialne napsane tak aby se s timhle pripadem umely vyporadat (vsechen DB soft od IBM a MQ series to umi. IMS taky, TPF nevim.) Pravda porad je Oracle lepsi nez PGSQL, kde se nedopracovali jeste ani k checksumum u stranek, pokud jsem neco neprehlednul u devitky.
Pokud bych se rozhodoval co nacpat zakaznikovi tak to bude mainframova DB2, pripadne Oracle na Sun SPARC Enterprise M9000. DB2 na POWER7 bych mu necpal protoze na tom Oraclu se vyrazne vic vydela za licence a HW. Navic ma Oracle vyrazne obtiznejsi administraci nez Unixova DB2 a proto vydelate i na skolenich, instalaci, supportu a podobne.
Ja unixovej oracle nemam moc rad (nevim zda jeste delaji ten mainframovej) sam bych ho pro inhouse aplikaci nepouzil, porad se v nem neco sere. Potrebuju aby to jelo a mohli jsme delat a vydelavat. To snad uz i ten informix je lepsi protoze se do nej nemusi neustale vrtat.
Naprotitomu unixovou DB2 lidi provozuji pod SAPem bez toho aniz by meli vyhrazeneho db administratora, jen si nechaji delat upgrady od servisnich firem. To by si nikdo s Oraclem nedovolil, tam se porad resi problemy typu dohaje proc to zase jede tak pomalu, to zase jsou statistiky v hajzlu nebo co?
Koncim flamewar, jdu vydelavat USD.

DBA

Re: Rozdíl mezi SQL a MySQL
« Odpověď #37 kdy: 29. 11. 2010, 23:06:28 »
Nehnevajte sa ale takmer cokolvek co bezi na mainframe dokaze mat takmer nulovy downtime, pretoze to je uloha mainframeu. Ale zabudli ste na jednu podstatnu vec, napr. na ludsky faktor, chyba v aplikacii, tieto veci vam mozu sposobit stratu dat a tu vam mainframe vobec nepomoze.

"Oracle neni nic moc, toho rozhodi i to ze disk ma write cache zapnutou a keca o tom ze zapsal data na disk do logu."

Opravim vas, prv nez Oracle zapise do datafileu, tak pred tym zapise do logu (konkretne do online redo logu) je to prave kvoli tomu, ze ak by doslo k vypadku, urobi takzvane Instance (alebo crash) recovery, kde v ramci rollforward fazy aplikuje vsetky zmeny a potom vramci rollback fazy tie necommitnute odroluje (to uz pri otvorenej DB). Vidite, ziadna strata. Ak mate zmrsene bloky a teda je potrebne media recovery, tak to taktiez nie je problem, na to mame dost opominanu funkcionalitu Blockrecover (na to mame fullbackupy, inkrementaly a koniec koncov archivne redology) cize vieme urobit kokretne bloky.

Ano, Oracle si opravnene mysli, ze zapisal na disk (aj ked zapisal do cache) pretoze dostal ACK o zapise. Chcete snad povedat, ze IBM DB2 kona inak, resp. ze nepise do cache na urovni storage? Za prve to nevie ovplyvnit a za druhe sa riadi tym co jej povie OS. Mimochodom crash recovery u DB2 je velmi podobna ako u Oracle, je tu par specifickych rozdielov, ale princip je ten isty.

Ano, Oracle vydava DB aj pre mainframe.

"Ja unixovej oracle nemam moc rad (nevim zda jeste delaji ten mainframovej) sam bych ho pro inhouse aplikaci nepouzil, porad se v nem neco sere. Potrebuju aby to jelo a mohli jsme delat a vydelavat. To snad uz i ten informix je lepsi protoze se do nej nemusi neustale vrtat.
Naprotitomu unixovou DB2 lidi provozuji pod SAPem bez toho aniz by meli vyhrazeneho db administratora, jen si nechaji delat upgrady od servisnich firem. To by si nikdo s Oraclem nedovolil, tam se porad resi problemy typu dohaje proc to zase jede tak pomalu, to zase jsou statistiky v hajzlu nebo co?
Koncim flamewar, jdu vydelavat USD."


Ak dovolite, toto necham bez komentara, pretoze evidentne "rozumiete problematike" a nechcem pouzivat invektivy.
Mimochodom od Oracle 10g je zber databazovych statistik automaticky vykonavany (pokial to niekto nezrusil alebo neprestavil) tak a) vzdy od 22:00-06:00. b) cez vikend.

Takze moznosti je 5:
1. Mate Oracle starsi ako 10g a neratate statistiky vobec alebo len v pripade problemov = zly DBA, pretoze ide o fundamentalne zaklady
2. Ak mate 10g tak niekto zrusil job na zber statistik. Ak to nenahradil inym zberom = zly DBA, pretoze ide o fundamentalne zaklady
3. Ak job zbieha, mate, tak zrejme mate dost velku DB a tum padom, zber statistik nie je dostatocne rychly, resp. default job nestihne v potrebnej dobe dostatocne frekventovane uskutocnit zber. = DBA musi identifikovat tieto objekty a ratat explicitne statistiky s vacsou frekevenciou. Ak nevie ako to identifikovat alebo ako to nastavit = zly DBA, pretoze ide o fundamentalne zaklady
4. Statistiky mozu mat nespravne parametre (granularita, histogramy atd.) ktore zapricinia ze Cost Based Optimizer zvoli nespravny exekucny plan.
5. Nie je to vobec problem statistik

Mozno sa to zda prilis komplikovane, ale presne tak je to komplikovane aj pri inych DB, niekde menej a niekde viacej a prave preto tu mame poziciu DBA a DBA musi mat tieto znalosti, minimalne preto aby vedel poskytovat poradenstvo architektom resp. designerom a programatorom DB aplikacii. Zial dnes vela ludi do databaz viac keca ako im rozumie.
Nie som zaslepeny obhajcom Oracle, robim s viacerymi DB od viacerych vendorov a mam viac ako 10 rokov denno dennej skusenosti s tymito DB, preto mi pride vela vyrokov velmi smiesnych resp. mam pocit, ze niektore je potrebne konfrontovat.
Napriklad ten, ze s Oracle su sustavne problemy... tu mozem povedat len jedno, zamyslite sa nad kvalitou vasich DBA.

Ivan

Re: Rozdíl mezi SQL a MySQL
« Odpověď #38 kdy: 01. 12. 2010, 00:06:34 »
Nie som zaslepeny obhajcom Oracle, robim s viacerymi DB od viacerych vendorov a mam viac ako 10 rokov denno dennej skusenosti s tymito DB, preto mi pride vela vyrokov velmi smiesnych resp. mam pocit, ze niektore je potrebne konfrontovat.
Napriklad ten, ze s Oracle su sustavne problemy... tu mozem povedat len jedno, zamyslite sa nad kvalitou vasich DBA.

No, kdyz napises dotaz a on polozi Oracle, nebo bezi 100x dele nez na jine DB a jeste k tomu bez optimalizace, nebo nedobehne vubec, tak je spatny Oracle a ani super admin tomu proste nemuze pomoct. Taky spatna volba planu, spatny rebuild indexu a podobny veci jsou proste spatnym navrhem DB a ne spatnym Adminem. Oracle je docela hodne zabugovana DB a kdyz ohlasis chybu na Oracle i s testcase tak na Tebe support Oracle prdi dokud jim nedelas mnohamilionove obraty mesicne. A doba kym vydaji opravu ... skoda mluvit. A kdyz vydaji opravu na bug A, tak rozkopou 10 jinych veci, ktere pred tim jiz byly 2x opraveny, jako kdyby ani nepouzivali unittesty.

DBA

Re: Rozdíl mezi SQL a MySQL
« Odpověď #39 kdy: 01. 12. 2010, 02:29:04 »
No, kdyz napises dotaz a on polozi Oracle, nebo bezi 100x dele nez na jine DB a jeste k tomu bez optimalizace, nebo nedobehne vubec, tak je spatny Oracle a ani super admin tomu proste nemuze pomoct. Taky spatna volba planu, spatny rebuild indexu a podobny veci jsou proste spatnym navrhem DB a ne spatnym Adminem. Oracle je docela hodne zabugovana DB a kdyz ohlasis chybu na Oracle i s testcase tak na Tebe support Oracle prdi dokud jim nedelas mnohamilionove obraty mesicne. A doba kym vydaji opravu ... skoda mluvit. A kdyz vydaji opravu na bug A, tak rozkopou 10 jinych veci, ktere pred tim jiz byly 2x opraveny, jako kdyby ani nepouzivali unittesty.

Prosim Vas nehovorte hluposti.
Co je bugove na tom, ze sa zmenila kardinalita dat, resp. selektivita indexu a CBO sa opiera o povodne statistiky, kde prave vykonavany plan bol optimalny? Alebo na to urobil DBA SQL profile alebo nedajboze stored outline, ktory tento plan forsiruje. To je na vine databaza? Alebo design databazy?
Prosim definujte co myslite pod pojmom "spatny rebuild indexu"?
Zaujimave je, ze Ste vobec nespomenuli moznost spatne navrhnuteho SQL dotazu.
Taktie je zaujimave, ze Ste vobec nespomenuli moznost spatneho navrhu datoveho modelu.

Viete co. Mam navrh. Ak na taketo nieco narazite ze sa bude query chovat tak ako ste popisali. A vy vulucite, ze ide o chybne napisane SQL query, ze vas DBA urobil vsetko co mal a ze vasa aplikacia je postavena na dobrom datovom modeli, skratka budete mat pocit, ze to je problem zlej DB, tak poslite mi e-mail na adresu: rotdba(nespamuj)orangemail(bodka)sk, prilozte relevantny trace z SQL urovne 12 a v surovej forme a taktiez CBO trace z uvedeneho SQL.
Tuto schranku dohladujem, takze vam urcite odpoviem a rad obetujem par minut svojho casu na takyto problem. Zaroven si ale vyhradzujem pravo zverejnit analyzu a jej vysledok (samozrejme hodnoty v query sa budu lisit) na svojej stranke.
Dovtedy prosim vo vlastnom zaujme nerozirujte taketo bludy.

DBA

Re: Rozdíl mezi SQL a MySQL
« Odpověď #40 kdy: 01. 12. 2010, 02:36:25 »
Zaroven si ale vyhradzujem pravo zverejnit analyzu a jej vysledok (samozrejme hodnoty v query sa budu lisit) na svojej stranke.

Len dodam, ze vysledok analyzy uverejnim aj na root.cz ak o to bude zaujem, resp. ak to bude mozne.

Ivan

Re: Rozdíl mezi SQL a MySQL
« Odpověď #41 kdy: 01. 12. 2010, 20:04:46 »
Prosim Vas nehovorte hluposti.
Zaujimave je, ze Ste vobec nespomenuli moznost spatne navrhnuteho SQL dotazu.

Dotaz ani DB struktura nemuze byt navrzen spatne, protoze bezi na dalsich 4 serverech bez probelmu. (coz jsem psal)

Lenin POWER!

  • ****
  • 434
  • Nekecat a delat!
    • Zobrazit profil
    • Tribut Leninovi
    • E-mail
ora vs db2
« Odpověď #42 kdy: 01. 12. 2010, 21:39:30 »
Nehnevajte sa ale takmer cokolvek co bezi na mainframe dokaze mat takmer nulovy downtime, pretoze to je uloha mainframeu.
Mainframe neni jenom HW. Pro vysokou dostupnost je potreba aby tuto funkcionalitu podporoval operacni system a aplikace. Je nutna soucinost vsech techto slozek. Pokud na mainframe jedete linux, tak to ho pak pouzivate jen jako nastroj pro virtualizaci.

Takze kdyz na mainframe nainstalujete oracle, tak ty veci co neumeli delat bez downtime na unixu nebude umet delat ani na mainframu. Mainframova DB2 a unixova DB2 jsou dva odlisne produkty, ktere maji jednak uplne rozdilnou administraci a nemaji ani 100% kompatibilni user mode SQL statementy. Mainframova DB2 toho umi vic nez unixova DB2. Kuprikladu unixova neumi index nad vyrazem bez toho aniz by se vytvoril v tabulce generated always sloupecek. Unixova DB2 je slabsi odvar te mainframove, ackoliv to neplati vzdy par drobnosti ma ta unixova zase navic. Mainframovej oracle je ale klasickej oracle jaky zname z unixu.

My mame na mainframu za poslednich 8 let nulovy downtime (planovany i neplanovany). Srovnejte si to s oraclem, ktery donedavna (neco okolo 10 nebo 11) neumel ani tak zakladni vec jako online index build. DB2 podporuje jenom online index build uz od svych ranych verzi pred 25 lety. Proto taky oracle na mainframech prakticky nikdo nepouziva (linuxovou verzi nepocitam to spis pouzivaj zVM virtualizaci).

Ale zabudli ste na jednu podstatnu vec, napr. na ludsky faktor, chyba v aplikacii, tieto veci vam mozu sposobit stratu dat a tu vam mainframe vobec nepomoze.
Ale pomuze, vzdyt u DB2 kdyz mate jeden z toolu co k tomu dodavaji - tusim snad recovery expert tak muzete selektivne vracet jednotlive transakce nebo vratit databazi par minut zpet. Nejsou k tomu zapotrebi zadne specialni upravy aplikace, staci klasicke transakcni logy.

Opravim vas, prv nez Oracle zapise do datafileu, tak pred tym zapise do logu (konkretne do online redo logu) je to prave kvoli tomu, ze ak by doslo k vypadku, urobi takzvane Instance (alebo crash) recovery, kde v ramci rollforward fazy aplikuje vsetky zmeny a potom vramci rollback fazy tie necommitnute odroluje (to uz pri otvorenej DB).
Vidite, ziadna strata.

1. oracle ma spoustu bugu. uz nekolikrat se mi stalo ze mi shutdown immediate zmrsilo databazi tak ze pak nesla nastartovat bez recovery. shutdown abort jsem nekolikrat pouzil a to mi zrovna databazi nezmrsilo, nicmene jsem mel dost vitr ze prijdu o data.

Naproti tomu u db2 shutdowny nedelam nikdy a to asi uz 10 let a nikdy jsem o zadna data neprisel. udelam power off na cely virtualni stroj, je to rychlejsi. Taky delam misto cekani na rollback reset virtualniho stroje. Recovery probiha v nekolika procesech soucasne, tak vyjde rychleji nez uzivatelsky rollback ktery dela jen jeden agent. Pravda, odpraskne to transakce i vsem ostatnim uzivatelum, ale websphere je umi zopakovat na novem pripojeni do db, ktere si automaticky vezme dalsi db2 image ktery je up.

U oracle jsem chtel taky praktikovat resetem delane rollbacky nicmene asi 3 ti den jsem prisel o data a tak jsem toho uz pak nechal. Misti oracle admini mi to nedoporucovali.

Ano, Oracle si opravnene mysli, ze zapisal na disk (aj ked zapisal do cache) pretoze dostal ACK o zapise.
Oracle je kriticky zavisly na tom ze kdyz zapise do logu checkpoint rekord ze musi mit datove stranky opravdu zapsane na disk. Pokud je nema poskodi to databazi pri recovery, nabouraji se mu bloky. Vzhledem k tomu ze tento jev nenastava zrovna malo casto (disky maji casto interni cache a kecaji o zapisu) tak ma oracle funkci block recover. DB2 ji nema nebyl k jejimu napsani duvod, protoze tento jev u ni nenastava, tam bloky zarvou jen v pripade hw chyb.

Chcete snad povedat, ze IBM DB2 kona inak, resp. ze nepise do cache na urovni storage? Za prve to nevie ovplyvnit a za druhe sa riadi tym co jej povie OS.
DB2 nedela nikdy checkpointy, takze jeji suma fuk zda ji ty disky kecaji nebo ne. dokaze se s tim pri recovery vyrovnat. Takove algoritmy existuji. ZFS to umi taky. Oracle by si mel tuto patentovanou technologii koupit.

Mimochodom crash recovery u DB2 je velmi podobna ako u Oracle, je tu par specifickych rozdielov, ale princip je ten isty.
neni. Oracle pouziva checkpoint based system - tedy klasiku. DB2 ma ARIES, coz je checkpoint free algoritmus pro obnovu dat pri vypadku. Z pohledu admina to sice muze vypadat velmi podobne, ale uvitr je to velmi jine. ARIES taky pracuje s tim ktere transakce jsou a ktere nejsou na disku, ale nepotrebuje tuto informaci pro obnovu. ARIES se umi vyporadat se stavem ze ma sice v logu napsano ze tato transakce by mela byt zapsana i v datovych souborech a on kontrolou hlavicek stranek zjisti ze se tam nezapsala tak umi transakci vratit zpet, naproti tomu oracke rozbije ty inkriminovane bloky. Oracle by mohl udelat to same pokud by mel konzistentni rollback segment ale to mit nebude protoze pri tehlech pruserech zarve rollback segment jako prvni.
DB2 pri prvnim startu po rebootu projede cely transakcni log bez ohledu na znacku kam az se to udajne stihlo zapsat na disk a porovna hlavicky logu s hlavickama datovych stranek zda jsou vuci sobe konzistentni. Vetsinou si lidi nechavaji tak 10GB online logu aby to nedelalo dlouhe starty, ty to projede maximalne za 5 minut, vetsinou neco pres minutu.

Ak dovolite, toto necham bez komentara, pretoze evidentne "rozumiete problematike" a nechcem pouzivat invektivy.
Ja problematice databazi rozumim rozhodne lepe nez vy. Mam cerifikaty jak od oraclu tak od ibm a to na unix i mainframe platformu. Jsem v data warehousingu dost dobrej a navic vyrazne vic vydelavam. Za 1 den vydelam asi tolik co vy za rok, kdybyste byl tak dobrej jak tady machrujete tak proc by jste si uz nekoupil nejakou IT firmu. Banky dneska pujcuji na cokoliv levne.

Mozno sa to zda prilis komplikovane, ale presne tak je to komplikovane aj pri inych DB, niekde menej a niekde viacej a prave preto tu mame poziciu DBA.
DBA pozice by mela delat tvurci praci a ne rutini ukoly. Znalosti dba by se meli vlozit do db enginu a nechat ho delat tyto veci automaticky.
1.
DB2 umi jednak automaticky spoustet statistiky kdy jsou potreba (synchrone - necha dotaz cekat nez dojedou nebo asynchrone). To je vyrazne zlepseni vuci oracle, ktery dela statistiky pres pouhy job scheduler.
2.
Umi trasovat dotazy a zjistovat nad kterymi sloupecky jsou potreba podrobnejsi a jak moc podrobne statistiky.
3.
DB2 Executor (technologie LEO) umi kompenzovat statistiky neodpovidajici datum. V pripade ze admin + 1 + 2 selze. Dela si krivku kterou aplikuje na statistiky tak aby odpovidaly skutecnemu stavu. Dokaze pri zjisteni neschody - statistiky vs real v prubehu dotazu spustit novou optimalizaci dotazu a pouzit jiz ty casti ktere se vykonaly aby se nemuseli v novem planu opakovat. Vynikajici vec pro dlouhe warehouse dotazy.
4.
i5/os DB2 umi dokonce sama vytvaret i chybejici a likvidovat nadbytecne indexy. Vynikajici vec. Tahleta edice se povedla a ma MYSQL kompatibilni modul! Proto si LAMP patlalove v bankach oblibili i5/os.

5.
automatickou reorganizaci dat a indexu umi vsechny

6.
taky ma db2 (i unixova) vynikajici vec - workload manager. To je naprosta nutnost, krasne si nadefinujete classy dotazu a muzete pak OLTP dotazy uprednostnovat pred OLAP. Workload managing v zOS je uzasna technologie a hezky to spolupracuje i s websphere.

Shrnuto. DB2 nema neustale srani se se statistikama. V pripade ze to dotaz na zaklade chybnych statistik podela, tak ho to podela jen 1x, pri dalsim vykonavani jiz pojede optimalni trasou. Proto se taky v DB2 manualni hinting prakticky nepouziva, zato v oracle se hintuje fest.

Napriklad ten, ze s Oracle su sustavne problemy... tu mozem povedat len jedno, zamyslite sa nad kvalitou vasich DBA.

Vemte si to tak, mam asi 90+ databazi (instanci v terminologii ora) DB2 a to mi spravuji 2 fulltime lidi. Kdybych mel 90 oraclu tak bych na to potreboval aspon 10 lidi.

Vemte si jaka je poptavka po oracle a db2 adminech. Odpovida trznimu podilu databazi t.j. 2:1 pro oracle? Ne, je zhruba 10:1 pro oracle adminy. Proc tomu asi tak je?

Znate nekoho kdo by mel 200k zamestancu a SAP pod oraclem a nemel na ten Oracle admina? Ja takovy instalace mainframove DB2 znam. Pravda maji tam asi jen 2 TB dat.

Jdu vydelavat. Nemam cas na dlouhe flamewars.

DBA

Re: Rozdíl mezi SQL a MySQL
« Odpověď #43 kdy: 01. 12. 2010, 21:40:12 »
No to este nic nemusi znamenat. Infromatika je exaktna veda a ja sa zoberam faktami, nie domnienkami.
Kazdopadne moj mail mate, ak si stojite za svojim tvrdenim, vyuzijete to.

DBA

Re: ora vs db2
« Odpověď #44 kdy: 01. 12. 2010, 23:56:43 »
Niektori to zrejme nechapu, a tak to skusim este raz. Nie som zatazeny na Oracle, ale zial objavuju sa tu nazory, ktore nekoresponduju s realitou.

My mame na mainframu za poslednich 8 let nulovy downtime (planovany i neplanovany).
Gratulujem, ale nachapem cim sa tu chvalite, ved na to ste si zadovazili mainframe.

Srovnejte si to s oraclem, ktery donedavna (neco okolo 10 nebo 11) neumel ani tak zakladni vec jako online index build.

Blud c.1 Online Index Rebuild prisiel v Oracle 8i. Hovorime o roku 1999.


Ale pomuze, vzdyt u DB2 kdyz mate jeden z toolu co k tomu dodavaji - tusim snad recovery expert tak muzete selektivne vracet jednotlive transakce nebo vratit databazi par minut zpet. Nejsou k tomu zapotrebi zadne specialni upravy aplikace, staci klasicke transakcni logy.


Tak ako u Oracle Logminer, Flashback (pozor je ich niekolko a funkcionalita sa rozsiruje v kazdom release) toto mate v baliku.

1. oracle ma spoustu bugu. uz nekolikrat se mi stalo ze mi shutdown immediate zmrsilo databazi tak ze pak nesla nastartovat bez recovery. shutdown abort jsem nekolikrat pouzil a to mi zrovna databazi nezmrsilo, nicmene jsem mel dost vitr ze prijdu o data.

Blud c. 2, ani sa nejdem rozpisovat. Nema to zmyslel.

Naproti tomu u db2 shutdowny nedelam nikdy a to asi uz 10 let a nikdy jsem o zadna data neprisel. udelam power off na cely virtualni stroj, je to rychlejsi. Taky delam misto cekani na rollback reset virtualniho stroje. Recovery probiha v nekolika procesech soucasne, tak vyjde rychleji nez uzivatelsky rollback ktery dela jen jeden agent. Pravda, odpraskne to transakce i vsem ostatnim uzivatelum, ale websphere je umi zopakovat na novem pripojeni do db, ktere si automaticky vezme dalsi db2 image ktery je up.

Bavme sa iba o DB2, Websphere vynechajme, ibaco by sme to zbytocne vetvili. Poznamka pre nadejnych DB2 DBA z tohto si rozhodne priklad neberte.

U oracle jsem chtel taky praktikovat resetem delane rollbacky nicmene asi 3 ti den jsem prisel o data a tak jsem toho uz pak nechal. Misti oracle admini mi to nedoporucovali.

Toto hodne vypoveda o vasich skusenostiach a hlavne vedomostiach o Oracle a ani certifikaty vam nepomozu tento obraz zmenit.

Oracle je kriticky zavisly na tom ze kdyz zapise do logu checkpoint rekord ze musi mit datove stranky opravdu zapsane na disk. Pokud je nema poskodi to databazi pri recovery, nabouraji se mu bloky. Vzhledem k tomu ze tento jev nenastava zrovna malo casto (disky maji casto interni cache a kecaji o zapisu) tak ma oracle funkci block recover. DB2 ji nema nebyl k jejimu napsani duvod, protoze tento jev u ni nenastava, tam bloky zarvou jen v pripade hw chyb.

Blud c.3 okrem jedineho, DB2 naozaj nema blockrecover funkciu.


DB2 nedela nikdy checkpointy, takze jeji suma fuk zda ji ty disky kecaji nebo ne. dokaze se s tim pri recovery vyrovnat.

Blud c. 4. alias nikdy nehovor nikdy napriklad: (mimochodm linka je na vasu oblubeny mainframeovu verziu): http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db29.doc.admin/db2z_checkpointlogrecord.htm


Oracle pouziva checkpoint based system - tedy klasiku. DB2 ma ARIES, coz je checkpoint free algoritmus pro obnovu dat pri vypadku. Z pohledu admina to sice muze vypadat velmi podobne, ale uvitr je to velmi jine. ARIES taky pracuje s tim ktere transakce jsou a ktere nejsou na disku, ale nepotrebuje tuto informaci pro obnovu. ARIES se umi vyporadat se stavem ze ma sice v logu napsano ze tato transakce by mela byt zapsana i v datovych souborech a on kontrolou hlavicek stranek zjisti ze se tam nezapsala tak umi transakci vratit zpet, naproti tomu oracke rozbije ty inkriminovane bloky. Oracle by mohl udelat to same pokud by mel konzistentni rollback segment ale to mit nebude protoze pri tehlech pruserech zarve rollback segment jako prvni.
DB2 pri prvnim startu po rebootu projede cely transakcni log bez ohledu na znacku kam az se to udajne stihlo zapsat na disk a porovna hlavicky logu s hlavickama datovych stranek zda jsou vuci sobe konzistentni. Vetsinou si lidi nechavaji tak 10GB online logu aby to nedelalo dlouhe starty, ty to projede maximalne za 5 minut, vetsinou neco pres minutu.


Ak pod pojmom ARIES mate na mysli Algorithms for Recovery and Isolation Exploiting Semantics, tak si najskor prosim vas aspon nieco o tom precitajte nieco a potom skuste pisat do diskusii.

Ja problematice databazi rozumim rozhodne lepe nez vy. Mam cerifikaty jak od oraclu tak od ibm a to na unix i mainframe platformu.
Stavim sa, ze ste aj dokonca vyssi ako ja, aspon minimalne o hlavu.

Jsem v data warehousingu dost dobrej a navic vyrazne vic vydelavam.
To ze ste dost dobry v datawarehousingu o vas musia povedat ini ludia, nie vy sam. Ja zatial o vas viem, ze sirite akurat FUD a to na zaklade vlastnej neznalosti. Zaroven lutujem toho, kto vas plati ak vasa praca je podobne kvalitna ako vase prispevky.

Za 1 den vydelam asi tolik co vy za rok, kdybyste byl tak dobrej jak tady machrujete tak proc by jste si uz nekoupil nejakou IT firmu. Banky dneska pujcuji na cokoliv levne.
Prepacte ale merat sa s vami nebudem. Z detinskych veci som vyrastol. Mimochodom, kde beriete to presvedcenie o mojom zarobku alebo o firme? Ale pravdepodobne, to bude z toho isteho pramena ako vase "mudrosti", ktore tu pisete. Ale uzivajte si vase peniaze v zdravi, ja Vam to doprajem.


DBA pozice by mela delat tvurci praci a ne rutini ukoly.
Neverim, prva normalna veta od Vas a dokonca s nou aj suhlasim. A dokonca aj za beznych okolnosti to tak aj je. Zial obcas su potrebne aj rutinne ulohy.

Znalosti dba by se meli vlozit do db enginu a nechat ho delat tyto veci automaticky.
Potom by neboli potrebny DBA, neboli by potrebne skolenia, state v dokumentacii, clanky na internete a techniky ladenia vykonnosti, napriklad.

1.
DB2 umi jednak automaticky spoustet statistiky kdy jsou potreba (synchrone - necha dotaz cekat nez dojedou nebo asynchrone). To je vyrazne zlepseni vuci oracle, ktery dela statistiky pres pouhy job scheduler.


To cez co je spustane je jedno. Zalezi co je  vykonavane a vy podla toho ako ste to napisal, nemate ani paru o tom ako su tieto statistiky zbierane. Iba spekulujete a tym vytvarate FUD. Pre vasu informaciu, ta default procedura pre kazdy objekt stanovi automaticky ako nad nou budu ratane statistiky, aku bude mat prioritu pri zbere statistik, paralelizmus, ci s histogramami alebo bez a s akymi. a podobne. A prepacte synchronne tu nema cenu, pretoze so zozbieranymu statistikami viete nadalej pracovat. Nehovoriac, ze ich viete zbierat aj manualne a samozrejme aj modifikovat. Taktiez viete rozhodnut o sposobe ich aplikacie.
Nic len dalsi blud z vase strany.

2.
Umi trasovat dotazy a zjistovat nad kterymi sloupecky jsou potreba podrobnejsi a jak moc podrobne statistiky.

Ano, to i Oracle.

3.
DB2 Executor (technologie LEO) umi kompenzovat statistiky neodpovidajici datum. V pripade ze admin + 1 + 2 selze. Dela si krivku kterou aplikuje na statistiky tak aby odpovidaly skutecnemu stavu. Dokaze pri zjisteni neschody - statistiky vs real v prubehu dotazu spustit novou optimalizaci dotazu a pouzit jiz ty casti ktere se vykonaly aby se nemuseli v novem planu opakovat. Vynikajici vec pro dlouhe warehouse dotazy.


V tomto bode by to bolo na dlho. Boli by ste totiz prekvapeny ako casto bojujem s LEOm a ze bezchybny teda rozhodne nie je.

6.
taky ma db2 (i unixova) vynikajici vec - workload manager. To je naprosta nutnost, krasne si nadefinujete classy dotazu a muzete pak OLTP dotazy uprednostnovat pred OLAP. Workload managing v zOS je uzasna technologie a hezky to spolupracuje i s websphere.


Oracle ma tiez podobne zalezitosti, nic nove a prevratne.

Shrnuto. DB2 nema neustale srani se se statistikama. V pripade ze to dotaz na zaklade chybnych statistik podela, tak ho to podela jen 1x, pri dalsim vykonavani jiz pojede optimalni trasou. Proto se taky v DB2 manualni hinting prakticky nepouziva, zato v oracle se hintuje fest.

Hinty su posledna moznost, ktoru ma vyvojar zvazit. To ze niekto hintuje fest, este neznamena, ze naozaj musi, resp. musel.

Vemte si jaka je poptavka po oracle a db2 adminech. Odpovida trznimu podilu databazi t.j. 2:1 pro oracle? Ne, je zhruba 10:1 pro oracle adminy. Proc tomu asi tak je?
Prepacte moj obor je IT, nie HR. Ale je potrebne rozlisovat napr. Oracle App. Administrator a DB Administrator.

Znate nekoho kdo by mel 200k zamestancu a SAP pod oraclem a nemel na ten Oracle admina? Ja takovy instalace mainframove DB2 znam. Pravda maji tam asi jen 2 TB dat.
SAP je nad Oraclom, nie opacne. A ked hovorime o SAPe na Oracle DB, tak uz nehovorime o Oracle DB ale o mutantovi. To uz s Oracle uz ma pramalo spolocne. Ale to uz zial mimo vase chapanie.

Jdu vydelavat. Nemam cas na dlouhe flamewars.
Kludne chodte. Tak ich nevtvarajte a hlavne nespravnymi informaciami, lebo sa mi zda ze mate silne nutkanie nieco povedat alebo si honit ego, nic viac.