Vlákno názorů k článku Úvaha ohledně zneužívání LIKE v databázích od LENIN POWER! - http://www-03.ibm.com/press/us/en/pressrelease/27279.wss nejsou tam popsany vsechny nove features jen namatkou: -...
-
http://www-03.ibm.com/press/us/en/pressrelease/27279.wss
nejsou tam popsany vsechny nove features jen namatkou:
- Oracle PL/SQL kompatibilita
- Oracle datatype kompatibilita
- SQLplus kompatibilita
- MVCC isolation level ala Oracle - statement level snapshots. Bez pouziti rollback tablespaces nebo vacuum ala pgsql! Jeste ze to nenakodili jako to ma pgsql to vacuum by byl fakt opruz, ten rollback segment by zas tak nevadil
- Oracle builtin packages, oracle style packages a Oracle style temporary tables
- vsechen mozny SQL bordel a paskvil join syntax co podporuje Oracle podporujeme taky.
- Shrnuto - nyni 98% Oracle kompatibilni
- SQL*Loader asi podporovan zatim neni, nic o tom nepisi. Dost skoda, snad kazda
aplikace ho pouziva.
- komprese indexu (3 druhy, automaticky to vybere nejlepsi) jde to i nad XML
- komprese temporary tables
- komprese XML
- inline storage pro LOBs
- online vytvareni indexu nad XML daty
- truncate table na urovni SQL (tezko rict jak moc je to kompatibilni s truncate table v DB2/ZOS).
- statement concetrator - pro mysql like workload. Sdileni access planu mezi podobnymi dynamickymi dotazy. preklada: update X where x = 2 na update X where x = ? aby se zvysila pravdepodobnost trefeni se do statement cache.
- synchronizovane scany dorazili z zOS verze i na operacni systemy pro socky
- online presouvani tabulek mezi tablespaces - nakodili lidi ze SAPu.
Vse se stihlo za pouhe 2 roky vyvoje. V OSS softu by jste se k tomu nedopracovali ani za 10 let. A to jsme se na linuxexpu dozvedeli ze my co delame komercni soft jsme pry desne neefektivni.
ke stazeni http://www.ibm.com/developerworks/data/db2preview/ -
Ksl (neregistrovaný)
- Oracle PL/SQL kompatibilita
Několik let po jedné z komerčních odnoží Firebirdu? :-)"- MVCC isolation level ala Oracle - statement level snapshots. Bez pouziti rollback tablespaces nebo vacuum ala pgsql! Jeste ze to nenakodili jako to ma pgsql to vacuum by byl fakt opruz, ten rollback segment by zas tak nevadil"
Jasně, a můj disk při každém smazání souboru přepisuje uvolněné místo nulami, zatíco OS od IBM tohle dělat nemusí. :-) To je mi ale argumentace."Vse se stihlo za pouhe 2 roky vyvoje. V OSS softu by jste se k tomu nedopracovali ani za 10 let. A to jsme se na linuxexpu dozvedeli ze my co delame komercni soft jsme pry desne neefektivni."
Jste děsně neefektivní co do ceny vývoje každé jednotlivé fíčury. Absolutní čísla nikdo nezpochybňuje. Samozřejmě že vrhnutím dostatečného množství peněz do vývoje produktu X dosáhne firma čehokoli (třeba i Vista se tak dá vyvinout :-)), ale pak hrozí riziko, že ta firma začne připomínat komunistický stát à la Microsoft, kdy ti, co si koupí Windows a Office, subvencují méně úspěšné projekty, o které třeba ani nestojí (IE? XBox?). (Ó ano, tvrdím, že ne FLOSS, ale spíš MS připomíná komunistický stát, nebo přinejmenší vládu socanů. :-)) -
LENIN POWER! (neregistrovaný)- Oracle PL/SQL kompatibilita
Několik let po jedné z komerčních odnoží Firebirdu? :-)
Interbaze jeste zije? Kolik ze ma market share? Pro tu jsme nic nedelali asi uz 9 let. To by si nas zakaznik jako soucast reseni nevzal.
Jasně, a můj disk při každém smazání souboru přepisuje uvolněné místo nulami, zatíco OS od IBM tohle dělat nemusí. :-) To je mi ale argumentace.
DB2 je overwriting db. Stary radek prepisuje novym aby se zachovalo rowid a nemuseli se zbytecne aktualizovat indexy. Dela to dokonce az prilis dusledne a to i kdyz se novy radek nevejde do stejneho bloku tak tam flakne pointer na novou lokaci misto toho aby zaktualizovala indexy na nove umisteni. -
Ksl (neregistrovaný)
DB2 je overwriting db. Stary radek prepisuje novym aby se zachovalo rowid a nemuseli se zbytecne aktualizovat indexy. Dela to dokonce az prilis dusledne a to i kdyz se novy radek nevejde do stejneho bloku tak tam flakne pointer na novou lokaci misto toho aby zaktualizovala indexy na nove umisteni.
No třeba Firebird také řádek při jeho změně přepisuje a na index nehrabe, pokud nemusí. Já měl na mysli hlavně to, že čištění řádků se dá poladit tak, aby se odložilo do doby, kdy se stejně s místem, které řádek zabírá, musí provést nějaká jiná operace. O luxování v PostgreSQL toho moc nevím, ale že by Firebirdí luxování nějak blokovalo provoz, to si moc lidí nestěžuje. -
LENIN POWER! (neregistrovaný)pokud databaze musi luxovat tak neni prepisujiciho typu protoze ma v db bloku ulozeny ruzne verze jednotlivych radek. Dela to treba pgsql.
Oracle, mssql a DB2 tohle nemaji, Oracle si zapisuje kazdy modifikovany blok do rollbacksegmentu. MSSQL si tam zapisuje jen radku. Db2 zapisuje do logu starou i novou hodnotu radky aby mohla v pripade rollbacku tam vratit tu starou.
Proto jsou treba Oracle transakcni logy tak male jelikoz je tam jen nova a ne stara hodnota. Kdyz jsou tam obe dve tak se zase da delat rollbackward recovery, coz taky neni nekdy uplne od veci. Nejnenazranejsi logy ma pgsql ten tam zjevne misto radek flaka hned cely stranky. -
Jestli to není kompatibilita s PostgreSQL - http://www.rttnews.com/Content/TopStories.aspx?Id=920420 -
'33' je uknown konstanta, ktera je přetypovatelná na cokoliv u čehož znám typ, je to adekvátní zápisu
postgres=# insert into foo values(integer '33');
tzv. string literal. Pokud si ovšem vynutím typ - tak se pg ozve:
postgres=# insert into foo values(varchar '33');
ERROR: column "i" is of type integer but expression is of type character varying
LINE 1: insert into foo values(varchar '33');
^
HINT: You will need to rewrite or cast the expression.
postgres=#
něco v apostrofech neznamená automaticky string, viz např. date nebo timestamp. -
Lenine - nevím nezkoušel jsem, ale nějakým způsobem je to přebandlovaná EnterpriseDB. Docela bych se nedivil, kdyby uvnitř bylo něco z Postgresu nebo nějaký můj kód. http://www.rttnews.com/Content/TopStories.aspx?Id=920420
Ty Oracle LIKE věci jsou určitě z EnterpriseDB. Tudíž přišli k hotovému - na EnterpriseDB se už dělá docela dlouho - a já si lámal hlavu, za co EnterpriseDB dostala tučnou finanční injekci od IBM. Tak už teď je to jasné.
Synchronizovaný scan má PostgreSQL od verze 8.3 - jen tak pro úplnost. -
Precetl jsem si u nich na webu ze to fakt ibm strelili za 10Mega. Nevim zda IBM dostala nejake jejich akcie jako soucast dealu. Na miste IBM bych se s tim ale nesral a projistotu koupil celou jejich spolecnost aby se ta technologie nedostala ms do rukou.
http://www.enterprisedb.com/solutions/ibm_db2_license.do#TabLic
Za 10 Mega to je opravdu zadarmo - vzdyt jen podelany MySQL stalo gigo! To byla nejvetsi pitomost co sun kdy udelal. IBM si namasti kapsu a ti co to udelali utrou hubu. Nekdo umi kodovat, jiny delat obchody.
Ja byt MS tak to okamzite za 10 Mega koupim taky i kdyby se to nikdy nepouzilo, tak je to vynikajici investice. Pro Larryho by nastaly tezke casy kdyby byl MSSQL server Oracle kompatibilni jako cobra. Pokud nemaji v MS v hlave slamu tak to okamzite licencuji taky. Ja bych na miste MS to mel koupeny uz hned ten den co to announcnuly ze chteji tu technologii strelit i dalsim db vendorum. 10 Mega, to je krasna cena. -
Když tady tak pořád vyzdvihuješ tu kompatibilitu s Oraclem, jakou má konkrétní výhodu pro zákazníka? Dejme tomu, že mám licence na Oracle 10g – můžu přejít na 11 nebo na DB/2, Oracle se ale bude hodně snažit, abych šel do 11, takže bude mít i konkurenceschopnou cenu, navíc přechod na 11 bude méně bolestný než přechod na DB/2.
Takže to má smysl spíš jen tehdy, když jsem dodavatel, vyvinul jsem soft pro oracle a teď ho chci prodat zákazníkovi, který má DB/2. -
LENIN POWER! (neregistrovaný)U Oraclu se kupuji jednotlive verze db? Ja do tech detailu licenci oraclu moc nevidim. U veskereho ibm softu kdyz mate sw. maint + support tak si tam muzete hodit jakoukoliv podporovanou verzi. Jelikoz u Oraclu miste mit support koupeny povine, tak bych predpokladal ze budou mit to same schema.
Migrace Oracle -> DB2 jsou naprosto v klidu kdyz aplikace podporuje obe db. My jsme takhle premigrovali nas interni SAP s minimalnim downtime. Tyhlety migrace SAPu se naprosto bezne rutine delaji. Beha to tedy o dost rychlejs, hlavne ty velky sestavy. DB2 je primarni db pro sap a kazda verze i fixpak je pred vydanim testovan u SAPu zda tam nejsou nejake regrese. Ten SAP fakt dneska nema cenu behat na necem jinym.
Proc lidi migruji z oraclu -> db2? Je s tou databazi podstatne mene srani s administraci, HADR ~ Oracle Dataguard to ma zdarma v cene, umi velice dobre komprimovat tabulky (30-60%), cobra umi komprimovat i indexy (cca 30-50%), diky tomu ze je rychlejsi tak staci zhruba pulka procesorovych licenci, lepsi shared nothing clustering, multi dimension clustering pro warehouse tablice, vyborna podpora XML, umi staticky SQL, hinting ma taky lepsi - da se tunit bez zasahu do aplikace. Umi ruzne vychytavky jako treba neomezene dlouhe transakce, defered unique key check a tak.
Dalsim duvodem je POWER zelezo, ktere je opravdu s AIXem vynikajici pro databazove servery. To je vyhoda jednoho dodavatele. Mate optimalizovan CPU, HW, OS a databazi.
Pro administraci to nevyzaduje takove bouchace jako oracle, je to mnohem snadnejsi. Adminovat db2 se naucite velmi rychle kdyz uz znate neco lepsiho nez mysql. Ja ji mam radsi, snadneji se pouziva a je stabilnejsi nez oracle. Takovy hovadiny jako ze se v oraclu zase podelaly control filez nebo aby to po shutdown immediate automaticky nenabehlo a chtelo recovery, ty se tam fakt nestavaji.
Taky se mi libi intergrace s TSM, to se pak zalohuje opravdu luxusne. Tezko najdete nekoho kdo ma db2 a nezalohuje pres TSM. Zalohovat tim bastlem v oraclu je dost opruz.
http://www.channeldb2.com/video/db2-is-easy-to-learn
http://www-01.ibm.com/software/data/db2/lowerdatabasecosts/
lidi migruji na db2 zejmena kvuli kompresi, xml a snadnejsimu pouzivani. Jo komprese je fakt dobra na z/OS to meli leta a tam kompresili vsichni vsechno, kdyz to dodelali i do db2 9 na linux tak to byl velky jasot. Zejmena warehouse tablice to znacne smrskne. Celej nas SAP to smrsklo asi na 30% puvodni velikosti v Oraclu, je fakt ze jsme tam meli velky tmp a rollback spaces jinak nam to padalo. -
DK (neregistrovaný)Kdyz si tak ctu vsechny funkce, kteryma se DB2 snazi predstirat, ze je Oracle, tak si tak rikam, jestli neni jednodussi zustat na skutecnem Oracle :-).
Pokud jde o support Oracle, tak v cene je samozrejme i upgrade na libovolnou jinou verzi (vc. prechodu mezi velkymi verzemi tj. 9i->10g->11g) nebo migrace mezi platformami.
O tom, ze by se support na Oracle MUSEL platit nic nevim. Je ale pravda, ze si ho vetsina zakazniku plati. Mit pristup k patchsetum, patchum a prave upgrade se proste hodi. Jedine co nejde, je aby si zakaznik platil support na jeden server a na druhy ne.
Pokud jde o migrace, pochybuji, ze podpora Oracle funkci v DB2 IBMce nejak pomuze.
Je to otazka podpory vyrobcu aplikaci. Zmigrovat SAP z Oracle na DB2 (nebo zpatky) je trifka - kdyz vyrobce aplikace podporuje obe databaze. (Uznavam, na SAP neni nic trifka :-) ).
Jenze zmigrovat aplikaci, kterou vyrobce podporuje jen na Oracle, to znamena, ze zakaznik prijde o podporu od vyrobce aplikace. A IBM muze stokrat slibovat, ze DB2 bude fungovat stejne jako Oracle. A podporovat aplikaci na obou databazich, to zas pro vyrobce znamena mit lidi na oboji a testovat vse na obou databazich. Sam uznate, ze to neni tak jednoduche.
Navic si myslim, ze zakladni problem proc DB2 neni tak pouzivana je jednoduchy - nejsou lidi. Administratora Oracle sice taky nepotkate na kazdy stanici tramvaje, ale administratoru DB2 je jeste radove mene.
Jinak stejne tak jako SAP testuje vse na DB2, tak podobne uz pres 10 let testuje totez i na Oracle. Dokonce udajne primo v SAPu ve Waldorfu sedi lidi z Oracle a delaj support. Uznavam, ze SAP nema posledni dobou moc duvodu se tim chlubit, ale tech 60% SAPich zakazniku, kteri pouzivaji Oracle je dobrym duvodem, aby se SAP snazil na Oracle behat spravne. :-)
Jinak se nechci hadat - urcite najdete spoustu dilcich rozdilu mezi obema databazemi, ktere vas vedou k preferenci DB2, ja jen doplnim pro ostatni to vase srovnani:
- Komprese - v Oracle od 9i, od 11g i pro OLTP aplikace, taky 1:2-1:3 nekdy ale i vyrazne lepsi. Pravda, jen v EE.
- Komprese indexu- pokud vim tak taky
- DataGuard - v cene EE
- Pro zmenu zas lepsi shared disk clustering :-)
- podpora XML - taky
- i Oracle se da ladit bez zasahu do aplikace - Profiles, stored outlines, SQL Plan Management.
- deferred constraints - taky, vc. unique key
- Power servery - uznavam argument jednoho dodavatele, ale i na IBM Power tech Oracle bezi docela dost
- Integrace s TSM -pokud vim, tak do TSM existuje modul i pro Oracle, ale uznavam, ze ho neznam.
Jak jsem rekl, nechci se hadat. Respektuji vasi preferenci a jak tak ctu vase drivejsi komentare vim, ze mate zkusenosti s obojim. Jen jsem si rikal, ze doplnim vas prispevek aby nahodou nevznikl u ostatnich nejaky omyl. -
LENIN POWER! (neregistrovaný)oracle kompresi cele bloky, db2 dela cele tabulky. Kompresovani celych tabulek dava znatelne lepsi kompresni pomer, proto se treba delaji tzv. solid archivy.
pokud se tyka komprese indexu oracle umi jen prefix kompresi a jeste ma fixed length prefix. db2 umi navic rowid delta kompresi v indexu a pripadne block level dictionary pro ty zakomprimovane prefixy. V oraclu se musi nastavovat jaky sloupecky v indexu to ma kompresit, v db2 pozna sama ktere indexy a jak komprimovat pokud je komprimovana tabulka tak default zakomprimuje i indexy.
XML ala oracle (shred nebo C/B LOB) mela db2 ve verzich 7 a 8. V db2 devitce maji pro ukladani xml stejny engine ktery pouzivaji XMLdatabaze. To je o generaci lepsi technologie. Proto se taky xml databaze pouzivali, cpat xml do relacni db byl dost opruz.
ty aplikace do db2 bude prevadet jejich vyrobce, ne koncovy zakaznik. To da rozum.
Ne vsechny databaze jsou tak tezke na spravu jako oracle, podivejte se na mssql - pouzivaji to male firmy kde maji lidi s minimalnimy znalostmi a zvladaji to. Oracle by nezvladli. Kdyz vezmete cloveka co umi pgsql nebo firebird tak ten po kratkem zauceni db2 adminovat zvladne stejne jako by zvladnul mssql. Podivejte se na to video.
Hlavni duvod proc mam db2 radsi je ze se muzu starat o svuj byznis a nemusim porad hopsat okolo databaze, ktera se seka s naprosto mimo misu chybovyma hlaskama, ke ktery je oficialni dokumentace tak mizerna ze bez knizek se s ni neda rozumne pracovat a Oracle Support? To je kapitola sama pro sebe.
DB2 na nemainframe platformach pred zakazniky tajime. pro nas byznis je lepsi kdyz pojedou na oraclu. Zvlast pro ten data mining co dodavame, tam se Oracle rozhodne nepredre a tak musi mit vice licenci na CPU priblizne dvojnasobek, radsi hned cely cluster, to je pak oslicku otres se. Dobrej for je dodavat jim to na HP-UX a machrovat s TPC-H vysledkama. Je to pomaly jak prase a drahy jak svine. Jo Oracle, ten uz nam vydelal peknejch par mega $$. Licence, skoleni, tuning - to jsou penize co doslova prsi z nebe. Larry vi jak delat byznis.
