"A világ leggyorsabb adatbázisgépe Magyarországra érkezett"

Oracle

Az Oracle nemrég bejelentette, hogy létrehoztak itthon egy Oracle Exadata demóközpontot, ahol a potenciális ügyfelek kipróbálhatják élesben az Oracle leggyorsabb rendszerét:

"Az adatbázisgép ipari szabványú hardverelemekből épül fel, amelyet a Sun FlashFire technológiája, az Oracle Database 11g második kiadása és az Oracle Exadata Storage Server Software 11.2-es kiadása egészít ki. Így az Exadata Database Machine a világ leggyorsabb rendszere Oracle adatbázisok futtatására....[...]"

További részletek az Oracle Exadata Database Machine-ről itt.

( trey | 2010. 11. 09., k – 10:20 )

Így felületesen utánanézve... Intel hardver és Linux OS? Hova tűnt a SPARC meg a Solaris? Vagy rosszul láttam volna?

--
trey @ gépház

Slowaris remélhetőleg lassan eltűnik, bár sajnos nem így lesz.
Ami azt illeti, az Oracle Server 11.2 2-es patchsetben épp slowarisra jelent meg az ACFS támogatás, szóval ezek szerint vannak még terveik vele.

Viszont ez az architektúra attól "olcsó" (sic!), hogy PC-grade alkatrészekből építkezik. Jó, értem SSD, meg InfiniBand, de azért ezek a vezérlők is egy nagyságrenddel olcsóbbak, ha x86 szerverhez veszed, mintha SPARC-hoz vennéd. Hogy miért, az egy másik kérdés, de akkor is így van.

Összességében egyébként még 1-es verziójúnál kiszámolgattam, nem volt rossz üzlet megvenni egy ilyen tornyot, mert gyakorlatilag majdnem vas + DB licensz árra jött ki az ára, és a RAC licenszet így ingyen kaptad, ezek az arányok szerintem nem változtak sokat ma sem.

Gondolom első az összeolvadás levezénylése, ami kb. január-február között kezdődött, utána pótolni kell a kilépett Sun fejlesztőket.

Viccet félretéve, az Oracle baromira nem kommunikál semmi roadmapet, még saját alkalmazottai felé sem, úgyhogy senki nem lehet biztos, hogy valójában mik a terveik. Ahhoz meg nagyon kevés idő telt el az akvizíció óta, hogy a roadmap a releasek alapján sejthető legyen.

A konkrét fejlesztési csapatoknak nyilván kiadják, hogy most ezt és azt a feature-t rakod bele ebbe a cuccba, de ez max 2-3 hónapra előre vetíti az adott részleg feladatait, de nyilván ebből még nem látszik a vállalati stratégia a köv. pár évre... Akiknek meg nagyobb rálátásuk van a dolgokra azokat meg nyilván köti egy csinos kis non-disclosure.

En inkabb a napi valtozasu roadmap-jelleget gondoltam :)

Jo, ha nalatok ennyire rendezett :)

"Everybody knows nothing" - ez a multi eleterzes eddigi tapasztalatok alapjan :)

(Nem, nem buktam meg angolbol, mindenki azt hiszi, hogy tud mindent, aztan kiderul, hogy egyaltalan semmi nem biztos)

(Nem feltetlenul konkret multinal van igy)

"Everybody knows nothing"

Igen, ez igaz. Viszont a(z ex) Sun-hoz képest az Oracle egyáltalán nem veri nagy dobra a terveit. A Sun-os vezetéstől gyakran lehetett hallani, hogy a köv. X évben ez és ez lesz... Az Oracle esetében jóval kevesebb ilyet látni.
Erősítsen meg valaki (ex) Sunos dolgozó, de amennyire én tudom, anno eléggé sok mindent lehetett tudni a céges irányvonalakból, ezzel szemben az Oracle befelé is alig kommunikál valamit.

Errol jut eszembe meg mindig meg van ez a kis idezet egy ugyfeltol:

"Nobody seems to know what exactly is needed, we don't know what
exactly to provide, and none of us have any time to deal with it
properly.

So we're going to do something, and see what happens.

Hope that's OK."

---
return NEVER;

Ubuntu 8.10
HP nx6110
http://java.tszebeni.hu

Viszont a(z ex) Sun-hoz képest az Oracle egyáltalán nem veri nagy dobra a terveit.

Egyrészt látványos a roadmap-jellegű információk csökkenése/hiánya cégen belül is, másrészt explicit megfogalmazták a takeover alkalmából, hogy a jövőre vonatkozóan az Oracle nem tesz közzé állásfoglalásokat, mert az Oracle célja, hogy a vevők a döntéseiket ne a jövőre vonatkozó állásfoglalásokra, hanem a már teljesült múltbéli tényekre, a már meglevő, elérhető termékekre alapozzák. Ellenkező esetben előfordulhatna, hogy az ügyfél csalódott lesz, amikor később mégsem úgy történnek a dolgok, ahogy azt neki megígérték. Sőt, vannak országok, ahol ebből még kártérítési kötelezettsége is lehetne a cégnek, amit Larry nyilván nem szeretne.

Ez jobb.
Őszintén baromi jó cucc, nagyon tetszik az elgondolása, de túl van lőve a magyar igényeken, így itthon max politikai céllal adható el.
Mivel az egész egy RAC, épeszű ember meg ugye nem az éles RAC-án tesztel/fejleszt/patchpróbál, ezért kell belőle kettő. Meg ugye a site-független redundancia miatt 3. Minimum... Mert ugye különböző security zónákba sem lógatjuk ugyanazon RAC-ot.
Namármost mivel egyetlen ilyen torony teljesítménye bőven elég bármely bankunk vagy telkónk alá konszolidációs platformnak, így ha sokat veszel, akkor lötyögni fog és így feleslegesen drága. Jelenleg tudomásom szerint a legkisebb kapható az a "fél rack".
És ugye az alap probléma, ha konszolidációs platformnak használod, akkor bizony az összes rálógatott alkalmazásnak ugyanazon oracle db verzió ugyanazon patch szintjét kell támogatnia. Itthon még nem láttam akkora súlyú ügyfelet aki ezt a beszállítóiból ki tudta verni (pedig az itthoniakat felvásárolta/tönkretette, stb, de a külföldiek túl nagy falatok voltak).

"Ez jobb. "

Csak ASM-el, host oldalon menedzsel mindent, és nem nagyon lehet olyan funkciókat megvalósítani, mint a shadow/flash/stb copy, srdf, remote mirror, ami egyébként ebben a szegmensben valós igény.

Több helyen fut pl. olyan backup megoldás, hogy az éles rendszerekről készül egy storage szintű másolat, amit aztán a backupot végző szerverre csatolnak fel.

Vagy a fejlesztői/teszt/riportoló környezetet generálják storage szinten az élesből -mert a biztonsági szabályozás miatt nem lehet semmilyen más hálózati kapcsolat az éles és a többi rendszer között.

Tudom, ilyeneket tervezek. Sőt a szóhasználatod alapján pont nálatok :-)
Ezért mondtam hogy jelenleg "db only" megoldás. Az ASM nekem sem barátom ezért írtam hogy várom a filesystem-re épülő változatot. Pl vxfs jelenleg full kiváltja az asm-et, támogatottan, csak drága.
Amúgy meg nem probléma ha szemléletet kell váltani, az exadata metodikáját követve is elvileg tervezhető gyors replika: Egyirányú tűzfalazott logshipping egy hagyományos storage-on ülő single db-re, onnan minden megy a régi módon. Az általad említett rendszereknél több teljes környezet fut,úgysem reális mindet exadata környezetre rakni.

Nálunk pont az ASM-mel van megvalósítva a flash copy és nem egy kicsi DB-t "copyzunk" hanem az adattárházzal.És tökéletesen működik.
Nem tudom mi a bajotok az ASM-mel egy file system-nél min. 15%-al gyorsabb, és 11gr2 óta meg van az "extract"-oknak ACFS, ezáltal teljes körű megoldást ad DB szinten.Az hogy a managelése kicsit eltérő a megszokottól azt meg kell szokni de ha megszokod utána aranyat ér.
A legkisebb az exadata amúgy a negyed rack, legalábbis még mikor utoljára néztem az volt.

"Nálunk pont az ASM-mel van megvalósítva a flash copy"

A flash copy (IBM storageok beépített replikációs megoldása) van összeidomítva ASM-el, vagy ASM-el másolsz adatbázist?

Az ASM megoldását nem ismerem, viszont a valódi flash copy-val rendszeresen dolgozom, és kb 5 másodperc alatt készítünk egy 1T+ adattárházról egy teljes értékű (írható olvasható) másolatot , amit kb. 4-5 további másodperc alatt egy másik szerverre mountolunk fel.
Ha ezt ASM-el is meg lehet csinálni, akkor nem szóltam...

"Nem tudom mi a bajotok az ASM-mel "

Nem mondtuk, hogy bajunk van. Sőt, jó termék az.... A beszélgetés onnan indult, hogy hiányoltam az Exadatából az "inteligensebb" storage-ot.

"A flash copy (IBM storageok beépített replikációs megoldása) van összeidomítva ASM-el" így értettem, bocs ha félreérthető volt.
"Az ASM nekem sem barátom ezért írtam hogy várom a filesystem-re épülő változatot." Erre reagáltam, hogy mi bajotok az ASM-mel. Bocs ha félrement :)
Amúgy nagyon megnézném mit tud egy ilyen böhöm Exadata egy 10TB+ adattárházzal :)

11i alatt igaz még nem láttam, de 10g alatt az első nagyobb terhelésre kétszer is lila füstöt csinált az adatokból 2 node-os rac alatt. Őszintén én OS oldalról vagyok jobban képben, ott fs hiba miatt 10% alatt vesztettem anyagot 10 év alatt, 3 eset volt összesen és egyikben sem veszett el minden. ASM-et életemben 3-szor láttam, ebből kétszer a lila füst miatti pánik helyrerakásakor. Ha FS van a db alatt, akkor legalább "kézzelfogható". Vannak FS tool-jaim a javításra, és a mentésből is összemazsolázhatom azaz legalább 2 különböző eszköz áll a rendelkezésemre. Ha az ASM meghúzza a vállát, akkor semmilyen kerülő módszer nincs (állította az akkor ott ülő ora szakértő). Itt ugye a mentés kezelése és az fs kezelése ugyanazon management kezelésében van, azaz ora agyelborulás esetén nehéz tiszta lappal indulni. Ezért hangsúlyoznám, az idegenkedés magánvélemény. Jobban érzem magam ha a megoldás kulcsa nálam van olyan területen amit jól ismerek.

Ezt a lila füstöt plz fejezd ki :)
Az ASM-et 10g -be vezették be, akkor még eléggé kiforratlan technológia volt azóta jelentősen javult.
Ha már a RAC-ot hoztad fel, akkor az asm "ingyenes" megoldás /DB licence mindenképp kell/ ezáltal kiváltottad a méreg drága cluster filesystem megoldásokat (OCFS2 szintén ingyenes de nem véletlen nem ajánlják már).
A failgroupok bevezetése meg megoldja a storage szintű tükrözés problémát (lévén az is baromi drága).

"Ha az ASM meghúzza a vállát, akkor semmilyen kerülő módszer nincs", ez alatt mit is értünk, mert ha csak a lokális diszken tárolt binárisod és instance-aid haltak le attól még a diszkeket be tudod tenni másik ASM instance alá./RAC alatt úgye mindegyik node látja a diszkeket/.
Ha disk szinten nézzük használjál failgroupokat, és egyikbe az 1ik storage-ból teszel !azonos méretű! LUN-okat a másikba a másikból így a storage szintű redundancia is megoldva.
Ha viszont ilyenre nincs lehetőséged és elszállt a shared disk akkor marad a mentésből való helyreállás. Hogy a "row device"-ok adatainak visszanyerésére milyen mód van azt nem tudom sose próbáltam és lehet, hogy ezt tényleg nem lehet, de én úgy vagyok vele ha megsérült valamelyik adatfile-om akkor nem bízom én semmilyen külsős tool-ra a recovery-t hanem majd az rman visszaállítja úgy ahogy kell, hogy az egész DB-t, vagy csak az adott adatfile-t, azt majd eldöntöm, de én mindenképp rmannal csinálnám.
Ha nem rman-os mentésed van akkor én sürgősen átváltanám, de lévén hogy RAC-ról beszéltél kétlem, hogy nagyon más megoldásod lenne, bár sose hallottam róla, hogy valaki RAC-os környezetet user managed backup-os megoldással mentene, de ki tudja akár ez is előfordulhat, ez lehet csak az én idióta felfogásom miatt van így.(flash copy módszer még mindig él, de ahhoz le kell állítani a DB-t, nem tartom túl jó megoldásnak).
Azt nem mondom, hogy az ASM-nek nincsenek hiányosságai, de látszik rajta, hogy 11g óta stabil, a bug-jait messze gyorsabban javítják mint mondjuk a DB-két és jóval kevesebb van, fejlesztés szempontjából úgy veszem észre nagyon is próbálkoznak megvalósítani a méregdrága "storage, clster filesystem és volume manager" megoldásokat (ACFS, failgroup, stb) és szerintem hamarosan az ORACLE egyik zászlós hajója lesz.
Lehet ezzel vitába szállni, ez az én meglátásom.

abban, hogy nagy a "kvantálása" a beszerzésnek, ha több kell és a verziókérdés kényesen érintheti a konszolidációt.

flash copy kérdés meg részedről jogos, bár én úgy fogom fel, hogy ez egy "appliance", ez van, így működik. ha nem ilyen kell, építsd fel hagyományos eszközökkel.

Hi,

Solaris adminkent gyorsan utanakerdeztem a nagyobbaknal, hogy mizu.

Csak annyit mondtak, hogy x86 lesz EXAk eseten, ez van, es hogy "hamarosan" jon a Solarisos verzio is ne parazzak.

Ez persze nem hivatalos igeret. Meglatjuk.

De ha x86, Linux, JBOD, akkor nekem hirtelen egy dolog jut eszembe: "cost effective".

MiszterX -- http://blog.xorp.hu

( STP | 2010. 11. 09., k – 10:26 )

Bár nem gyár a jósda notit, azért a végén az a TP befigyelés nem volt túl profi. :)

( LZ | 2010. 11. 09., k – 10:34 )

"A világ leggyorsabb adatbázisgépe" ebben csak az a bibi, hogy nem egy gép, de még nem is egy rack...

( sz | 2010. 11. 09., k – 11:05 )

Egy random admin mondá:
"Our big Sun servers that seemed so awesome last year now sucketh because they're Oracle servers, and they have eviscerated Sun's support."

( uid_18079 | 2010. 11. 09., k – 12:41 )

Már szóltam a fönöknek, hogy na, akkor ketto" ilyen kellene nekünk. Egy élesbe, egy meg játszani a fejleszto"knek, és adminoknak.

De csak vicsorgott...

( uid_228 | 2010. 11. 09., k – 13:13 )

A két öltönyösnek mondják már meg, hogy

1. kamera elé nyakkendőben illik állni, ha már zakót fölvesz valaki
2. a nyakkendő-ing-zakó hármasból egyszerre legföljebb kettő legyen csíkos (mintás), mert 3 már túl sok.

Mr. Katónak meg innét gratulálok, hogy médiasztár lett. :))

--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.

( x-daemon | 2010. 11. 10., sze – 08:50 )

latom van aki ert a replikaciohoz (egyszeru master-slave), a kerdesem az lenne hogy honnan tudom hogy a replikacio megtortent, van-e erre valami altalanos modszer vagy talaljak ki sajatot?
tehat a program ir a masterbe, majd a kovetkezo utasitasnal mar olvasna a slave-bol. kerdes replikalodott-e mar az adat?
koszi!

Csak alkalmazás oldalról fogható meg a kérdés.
Akár DB, akár storage replika esetén a szinkron belassítja a működést, az utóbbi esetben pedig nem is garantált az eredmény: blokk írási sorrend minden cache rétegen változhat, ezért nem definit, azaz mindenképpen olyan a replikált állapot a leválasztás/lekérdezés pillanatában, mintha a masterből kirúgtad volna a tápot, azaz legalább rollback az utolsó konzisztens állapotra. Ami azt jelenti hogy a master tranzakció a futása pillanatában a replika storage-on még tuti nem konzisztensen kommitolt esemény még szinkron storage replika esetén sem.

azt szerettem volna kerdezni, hogy van-e olyan altalanos - legjobb ha adatbaziskezelo tipustol fuggetlen de ha adatbaziskezelo tipusonkent mas es mas akkor is jo lehet barmelyikre megirt modszer kiindulopontnak - modszer amivel le lehet ellenorizni hogy a replikacio megtortent-e mar vagy sem. az is lehet hogy ez a modszer kozismert csak en nem ismerem.

hát ha tudod, hogy minek kell ott lenni, akkor lekérdezed a replikát, hogy ott van-e már, nem ? :)

fentebb azt írod, a kódban írnál valamit az adatbázisba, pár sorral később meg olvasnád a replikából ugyanazt. szerintem ez több szempontból is hülyeség: 1) benne vagy egy tranzakcióban, hogy viszonyul ez a replikához? sehogy 2) nem számíthatsz arra, hogy a replikáció _ennyire_ gyors

Csak a DB2-nél három különböző módszer jöhet szóba a replikációra. Össze lehet reszelni dolgokat ellenőrizni, hogy elért-e egy bizonyos pontot. Talán ha MySQL-ben gondolkozol, meg tudod nézni, hol tart a binlog és hogy ott jár-e már a slave. De miért kell ez? A replika nem erről szól, ha olyanok az adatok/műveletek, hogy ez szükséges, akkor rossz irányban akarsz skálázni

amúgy ha sorokra vonatkoztatható a dolog, akkor meg tudod fordítani az optimistic locking problémát (upsz már nem érvényes az adatom -> upsz még nem érvényes az az adat) és kb elég általánosan lehet implementálni az alkalmazásban. mondjuk nemtom mennyire azonosak az ezt támogató dolgok (row id, change token, row update timestamp, akármi) replikációban, gyanítom semennyire, bevezetsz hasonló tartalmú extra mezőt.

de mondom ne számíts arra, hogy 2 programsorral alább már ott jár a replika, meg arra se, hogy nem lezárt tranzakcióval bármi történik replika-szinten..

bocs de az ebből a szempontból valamit is érő storage pontosan ezt garantálja - azonos blokk írási sorrendet, és konzisztenciát különböző LUN-ok között (pl. tablespace, log). természetesen ha csak "kitéped" a replika drótot, crash recovery-vel indítasz, nyilvánvaló, de az utolsó beérkezett tranzakcióig (mondjuk ált. fsync()) konzisztens lesz minden és DB szempontból ez bőven elég.