[HWSW]

Az Oracle márciusban váratlanul közölte, nem fejleszt többé Itanium processzorra. Az IBM azonban továbbra is kiemelt platformként kezeli az Itaniumot és a HP-UX-ot és a DB2 adatbázis következõ verzióját is portolja rá, ahogy a korábbi verziókkal is tette.
https://www.hwsw.hu/hirek/46762/ibm-db2-hp-ux-itanium-oracle-adatbazis-szerver.html

[thinktura]

Na ugye....
Azt hiszem valami effélét dünnyögtem én is, amikor az Oracle elkezdett emberkedni az IA64-gyel szemben.
És az IBM üzenete is egyértelmû: õk pontos, hosszú távon megbízható szállító, jó fejlesztési technológiával, jó kódbázissal, és ez legalább három dolog, amitõl az Oracle mostanra már messze eltávolodott.
Ja, és ha már az ügyfelet áthozták egy lépésben IA64 -DB2-re akkor a következõ lépés innen vagy az IA64-en maradás lesz, vagy Power migráció. De hogy az Oraclenek ez összességében nem hozni fog a konyhájára, hanem vinni.. azt fixre lehet venni.

[Ytse]

@thinktura: A sok tízmillió dolláros kérdés, hogy mi éri meg jobban az ügyfélnek: maradni az Oracle-nél és átállni mondjuk x86-ra vagy SPARC-ra, vagy maradni az Itaniumnál és átállni DB2-re. Szerintem ilyen és olyan forgatókönyvet is fogunk látni.

[UnA]

@Bodnár Ádám: a migráció nagyon nehéz eset, mert az adatbázist üzemeltetni is kell és egy DB2 és egy Oracle nagyon távol van egymástól (DBA szempontból). Vagyis egy új adatbázis bevezetéséhez képzett munkaerõ is szükséges. Saját tapasztalatom az, hogy a cégek jobban félnek egy új szoftvertõl, mint egy hardveres migrációtól.

[Ytse]

@UnA: de a hardveres migrációval is ki lehet dobni a megszerzett tudást, egy HP-UX admin nem sokat tud kezdeni egy AIX-szel vagy egy Solarissal, persze lehet hogy többet mint egy Oracle-admin a DB2-vel....

[Samott]

Idézet: thinktura - Dátum: 2011. 05. 25. 18:15

Na ugye....
Azt hiszem valami effélét dünnyögtem én is, amikor az Oracle elkezdett emberkedni az IA64-gyel szemben.
És az IBM üzenete is egyértelmû:

Idézet

...de a legjobb megoldás a Nagy Kék szerint, ha a WebSphere-t és a DB2-t egy Power7-alapú szerveren konszolidálja az ügyfél, amivel növelheti a teljesítményt és csökkentheti az adatközpontban elfoglalt helyet is.

Ja, marketing... Ha feladod az oracle-t akkor add fel az Itanicot is...

Samott

[delphijos]

Idézet: UnA - Dátum: 2011. 05. 25. 18:35

@Bodnár Ádám: a migráció nagyon nehéz eset, mert az adatbázist üzemeltetni is kell és egy DB2 és egy Oracle nagyon távol van egymástól (DBA szempontból). Vagyis egy új adatbázis bevezetéséhez képzett munkaerõ is szükséges. Saját tapasztalatom az, hogy a cégek jobban félnek egy új szoftvertõl, mint egy hardveres migrációtól.

Egyetértek. 4 Oracle installunk van, és kizárt hogy vállalnánk a migrációt egy másik DB-re. Viszont egy "hardver" migrációt ( sparc-ról x86-ra) már végignyomtam egy oracle verzió upgraddel együtt és még egy ilyennél is a hardvercsere volt a kisebb gond.

Szerkesztette: delphijos 2011. 05. 25. 19:32 -kor

[thinktura]

Idézet: delphijos - Dátum: 2011. 05. 25. 20:31

Egyetértek. 4 Oracle installunk van, és kizárt hogy vállalnánk a migrációt egy másik DB-re. Viszont egy "hardver" migrációt ( sparc-ról x86-ra) már végignyomtam egy oracle verzió upgraddel együtt és még egy ilyennél is a hardvercsere volt a kisebb gond.

A DB2-vel kapcsolatban még ma is több a hiedelem, mint a tárgyi ismeret.
Az első kérdés nem a migráció önmagában, hanem a migráció és a fenntartási költségek előrevetített pár éves mértéke, amit TCO-ként számolnak.
A DB2 sokkal, mondjuk úgy, "konzervatívabban" licenszelődik, mint az Oracle vadregényes "fizess Oracle licenszet minden szembejövő szerver után, és rögtön a maximumot" típusú politikája. Tehát egy DB2 migráció összességében bőven nyereséges tud lenni, figyelembe véve a migráció egyszeri költségeit, a Deep Compression miatti tárolómegtakarítást és a kedvezőbb licensz és karbantartási feltételeket.

Technológiailag a migrációt az IBM nagyon erősen megalapozta azzal, hogy az Oracle specifikus fejlesztéseket a DB2 Enterprise Edition-ben levő standard, DB2-es SQL/PL mellett az Oracle PL/SQL személyiségével egészítette ki, ami az (IBM szerint) az ismert Oracle fejlesztett kódok 95-99%-ának változtatás nélküli továbbvitelét jelenti, illetve, hogy a migrációt nem saját erőből kell lezavarni, hanem nagyon mély és aktív támogatást tud hozzá adni.

A továbbvitel és az üzem szempontjából is támogatja az IBM a migrációt, elsősorban az adatbázis adminisztrátorok át- és továbbképzésével. Természetsen nem ugyanaz az eszköz adminisztratív szempontból,mint az Oracle, de nagyon komplett menedzsment eszközök járnak a legegyszerűbb DB2 kiadáshoz is.

Ahol a migráció nem jelent alkalmazásmódosítást, mert pl. egy többféle adatbázist is használni tudó nagyvállalati alkalmazásról van szó, ott a migráció költségei még alacsonyabbak.

Végeredményben az Oracle lépésétől függetlenül is nagyon sok esetben bőven nyereséges az átállás (a vállalatnak és az üzemeltetőknek is), ez attól független, hogy az Oracle mostani lépései ezt csak serkentik.
A többi érvet már korábban elmondtam, amik főleg a többplatformos környezetben még jobban kijönnek: egységes ütemezésű verziókibocsájtás, virtualizációs környezetek hivatalos támogatása, virtualizáció-barát licenszelés, azaz nincs kifogáskeresés a virtualizált környezetben támogatással, miközben licenszoldalról a host teljes magszámára licenszelni kéne az Oracle DB-t stb.

(Gyenge lenne a DB2, ha az Oracle pályáról való lelépése lenne az egyetlen, áttérést igazoló érv ) )

[thinktura]

Idézet: Samott - Dátum: 2011. 05. 25. 19:19

Ja, marketing... Ha feladod az oracle-t akkor add fel az Itanicot is...

Samott

Ha az Oracle-t feladod, akkor tény, hogy nagyobb a szabadságod, hogy merre lépsz tovább, akár x86, akár P7 irányban, DB2 oldalról mindenképpen egységes és homogén környezetben találod magad, ahol a platformok közti későbbi váltás problémái szinte eltűnnek.

[thinktura]

Idézet: UnA - Dátum: 2011. 05. 25. 18:35

@Bodnár Ádám: a migráció nagyon nehéz eset, mert az adatbázist üzemeltetni is kell és egy DB2 és egy Oracle nagyon távol van egymástól (DBA szempontból). Vagyis egy új adatbázis bevezetéséhez képzett munkaerõ is szükséges. Saját tapasztalatom az, hogy a cégek jobban félnek egy új szoftvertõl, mint egy hardveres migrációtól.

Biztos vagy benne, hogy nagyon távol van tőle DBA szempontból?
DB2 esetén vannak olyan autonóm funkciók, amik eleve csökkentik a DBA terhelését. Másrészt standard módon is nagyon erős eszközök járnak hozzá.
Amiben nagyon eltér, az pl. a konfiguráció kezelése (pfile szerkesztés nincs, inkább csak az spfile-ra vonatkozó parancsokhoz hasonló megoldás van, amit parancssorból egy db konfiguráló programmal lehet kezelni), itt nincs RAC, hanem pureScale 9.8, ami az Oracle RAC-tól eltérően nem a nodeok közvetlen összebeszélésére, hanem két, kontroller node által összehangolt működésére épül (ez egyelőre x86-on és Poweren-en van meg, Itaniumon még nincs). Ugyanakkor a standard Enterprise licenszben meg benne van a HA-DR funkció is,és ez minden platformra igaz. Az Oracle dinamikus performancia nézetek jó részét megvalósították a PL/SQL personality részeként, sqlplus-nak megfelelő parancsértelmezővel kiegészítve.
Másrészt, az Oracle által annyira kedvelt RMAN helyett más mentési megoldás van, ami hatékonyságában és önállóságában bőven eléri vagy meghaladja az RMAN-t, de kezelni talán egy fokkal egyszerűbb és logikusabb.
Szerintem annyira nincs távol az Oracle-től adminisztrátori nézőpontból, legalábbis annyira nem, hogy ez akadályozná a migrációt, ha már egyszer költségoldalról egyébként alátámasztott, és műszaki oldalról lehetséges.

Szerkesztette: thinktura 2011. 05. 26. 06:19 -kor

[thinktura]

Idézet: Ytse - Dátum: 2011. 05. 25. 18:29

@thinktura: A sok tízmillió dolláros kérdés, hogy mi éri meg jobban az ügyfélnek: maradni az Oracle-nél és átállni mondjuk x86-ra vagy SPARC-ra, vagy maradni az Itaniumnál és átállni DB2-re. Szerintem ilyen és olyan forgatókönyvet is fogunk látni.

Persze, itt nyilván nem arról van szó, hogy csak emiatt lenne váltás, ez pusztán egy újabb löket az eddigiekhez.

[thinktura]

Akit érdekel, az elég sok ingyenes tananyagot találhat a DB2-höz, SAP-ra teljes ingyenes,faltól-falig jellegű online tanfolyam van. Ezekkel együtt a DB2 certifikációkat kifejezetten gazdaságosan meg lehet szerezni.

Oracle adminoknak: mostanában frissült egy hasznos online tananyag:

DB2 9.7: Run Oracle applications on DB2 9.7 for Linux, UNIX, and Windows

A konkrét tartalmán kívül egy érdekesség van benne, nem tudom, hogy ez melyik frissüléssel jött be, de most ezt írja:

Idézet

When will DB2 Express-C support PL/SQL?

Soon (knock on wood).

(Az Express-C az ingyenes, szabadon használható és adatbázis méretkorlát nélküli változat, aminek az eddigi kiadásaiban nem volt PL/SQL támogatás.)

Egy kis demó: SQLPlus helyettesítő CLPPlus:

[Ytse]

@thinktura: miért érzem azt hogy az IBM-nél dolgozol? na nem mintha ez baj lenne, sõt, örülünk neki és welcome!

[thinktura]

Idézet: Ytse - Dátum: 2011. 05. 26. 08:24

@thinktura: miért érzem azt hogy az IBM-nél dolgozol? na nem mintha ez baj lenne, sõt, örülünk neki és welcome!

Megtisztelő feltételezés, de nem: sem rokona, sem ismerőse....

[Samott]

Idézet: thinktura - Dátum: 2011. 05. 26. 08:49

Megtisztelő feltételezés, de nem: sem rokona, sem ismerőse....

Pedig az magyarazat lenne erre az idehanyt PR amokfutasra... Amit ennyire dicsernek az mar gyanus.

Samott

[Foote52]

@Bodnár Ádám: Nem dolgozhat az IBM-nél, mert ezt is õ írta:

"Az Itaniumból nem csak a processzort kell látni, hanem a körülötte levõ "ökoszisztémát", ami ma fõleg a HP új generációs bladejeit és blade-alapú Superdome-ját jelenti, a HP-UX-ot, és a NonStop architektúrát. Ezek ár/teljesítményben messze a korábbi generációk, illetve más gyártók Unix szerver hardver vonalának specifikus eszközei fölött vannak, mert csak ott térnek el a volumen (x86) szerverektõl, ahol muszáj, egyébként nagyon sok közös komponenst használnak, így az árak közelítenek a volumen szerverekéhez." ...

[hkpk]

Van itt igazi HP-UX szaki?
Van nálam 2 flopi, amit valahogy el kellene olvasni PC flopimeghajtóban.
Azaz menteni kellene a tartalmukat HDD-re, CD-re, akármire, oly módon, hogy az szükség esetén
visszaírható legyen. Eddig semmilyen flopimásoló progi nem boldogult a lemezekkel, rawrite,
floima, diskcopy, DOS / WIN /LIn alatt, legtöbb "Sector not found" hibával elszáll. (Igen, a Rawrite is :-O)
A lemezeket õsrégi HP-UX rendszer írja, amirõl semmi közelebbi infó nincs (pl. a lemezkezelésrõl, hogy mégis milyen formátumúak)

[InnerMan]

Valamiért a Sybase mindig kimarad az adatbázisos fikázásból...
DBA szempontból sokkal egyszerûbb átállni Ora-ról Sybase ASE-ra, mint DB2-re. Az értelmesebb Ora üzemeltetõket egy 5-napos térningen átképzik Sybase ASE-ra, és vígan üzemeltetnek tovább. Ráadásul a SAP alatt is mostmár hivatalosan használható az ASE, nem kell az IT vezetõnek vállania a kockázatokat a jobb teljesítmény-eredmény miatt.
DB szempotnból is a legegyszerûbb az Ora-ASE migráció, feltéve hogy az üzleti logika nem plsql-ben íródott teleszemetelve hintelésekkel, stb.
Költségek (TCO) tekintetében pedig lényegesen jobb az ASE mint az OraDB, mert az mûködik akkor is, ha naponta háromszor nem ürítik a logokat, pucolják a memóriát, stb...

[UnA]

@thinktura: "Biztos vagy benne, hogy nagyon távol van tõle DBA szempontból?"

Igazából nem vagyok DBA, de kellett dolgoznom mindkét adatbázissal úgy "mintha" én volnék a DBA - ami persze nem vethetõ össze egy igazi szakember tapasztalataival. A DB2-höz tényleg nagyon jó eszközöket adtak, ezzel egyetértel, de akkor is nagyon távolinak tûnt nekem a két adatbázis logikája.

A migrációt pedig semmi sem akadályozza meg, ha egyszer fõnökség kitalálta

[thinktura]

Idézet: InnerMan - Dátum: 2011. 05. 26. 12:10

Valamiért a Sybase mindig kimarad az adatbázisos fikázásból...
DBA szempontból sokkal egyszerûbb átállni Ora-ról Sybase ASE-ra, mint DB2-re. Az értelmesebb Ora üzemeltetõket egy 5-napos térningen átképzik Sybase ASE-ra, és vígan üzemeltetnek tovább. Ráadásul a SAP alatt is mostmár hivatalosan használható az ASE, nem kell az IT vezetõnek vállania a kockázatokat a jobb teljesítmény-eredmény miatt.
DB szempotnból is a legegyszerûbb az Ora-ASE migráció, feltéve hogy az üzleti logika nem plsql-ben íródott teleszemetelve hintelésekkel, stb.
Költségek (TCO) tekintetében pedig lényegesen jobb az ASE mint az OraDB, mert az mûködik akkor is, ha naponta háromszor nem ürítik a logokat, pucolják a memóriát, stb...

Ez érdekes felvetés,mert ráadásul a Sybase a SAP-nak most már házon belül van, az eddigi SAP MaxDB mellett.

Ezzel együtt az Ora-migráció két legegyszerűbb célplatformja a DB2 EE és az EnterpriseDB (PostgreSQL üzleti változata), mert mindkettőhöz ugyanaz, az EnterpriseDB által fejlesztett Oracle (PL/SQL) personality van.