2TB + MSSQL = biztos bukas?

[Törölve]

[quote:4101a4be42="andrej_"]Linux + PGSQL -t te lattal mar 2TB-os adatbazisban turkalni?

Hat 2TB-s DB-t meg spec nem lattam Linux + PGSQL kiszerelesben, a legkisebb az 3.6TB v 3.8TB volt, a legnagyobb 23.3TB. Termeszetesen mainframe-en alapul mindegyik.

[quote:4101a4be42="andrej_"]Azt hiszem magyarorszagon akik egyaltalan 2 TB -os adatbazisok kozelebe jutnak igencsak kevesen vannak.

Ezt nem tudom, en nem Magyarorszagon elek.

Én elsősorban a magyarországi viszonyokra gondoltam.

Az viszont komolyan érdekelne, hogy a Linux + PGSQL (ahol a linux a szukebb keresztmetszet szerintem) hogyan is viszi el ezeket a hatalmas DB-ket. Gondolok a clutering tech-re és a vasakra is, a leginkabb a diszk alrendszer izgat. :) Az más kérdés, hogy valószinuleg 5GB-nal nagyobb DB kozelebe nem jutok a kovetkezo nehany evben sem.

[Törölve]

A linux alá is lehet nagyon nagy adatbázisokat tenni, de a 32-bites architektúra miatt nem nagyon érdemes. Egy 32Bites rendszerben a max címezhető terület kb 3Gb. Ebből 1 Gb autómatikusan foglalt az OS-nek. Azaz marad kb 2 GB az adatbázisod közös buffereinek. (Persze processenként ennyi, de a közös memóriára eből következően áll ez a megkötés.) Namármost egy tiszetességes méretű adatbázisnál ez kevés. Erre megoldás lehet a 64-bites linux, de ehhez meg kell jelennie a 64-bites DB alkalmazásoknak is. (Bár egy 64-bites linuxon egy 32-bites oracle máris nyer plus egy GB memóriát, mert kiesik az OPSystemre jutó rész....)

A másik lehetőség az Oracle vagy a DB2 speciális cluster rendszerei, az Oracle-nél a RAC (Real Application Cluster) a DB2-UDB-nél a EEE (a fene sem tudja kivülről :)). Ezek azt biztosítják, hogy az adatbázisod nem egy, hanem több gépen fut. Elég érdekes mehanizmuson keresztül gyakorlatilag összeadódik a DB Memória. Szóval pl egy Oracle RAC-al szerintem akármekkora adatbázis összehozható, ha lassú, csak föl kell húzni egy új adatbázisszervert. Ráadásul a megbízhatóság is nagyságrendekkel javul, hiszen ha leáll az egyik adatbázisszerver, jó sansza van a felhasználónak, hogy még a futó processe sem szakad meg.

[Törölve]

[quote:25f03580c4="LeoALo"]A linux alá is lehet nagyon nagy adatbázisokat tenni, de a 32-bites architektúra miatt nem nagyon érdemes. Egy 32Bites rendszerben a max címezhető terület kb 3Gb. Ebből 1 Gb autómatikusan foglalt az OS-nek. Azaz marad kb 2 GB az adatbázisod közös buffereinek. (Persze processenként ennyi, de a közös memóriára eből következően áll ez a megkötés.)

Mar a Pentium Pro processzorok is tudtak 16GB memoriat cimezni. Kulcsszo: PAE (az egy masik kerdes, hogy mennyit er, csak a pontossag kedveert)

Namost :)

Tisztazzunk par dolgot :)

Jelen esetben 99% hogy tobbgepes kornyezetrol van szo, ergo van 1 SAP DB host, valamint tobb applikacios host es gw server a loadbalancing miatt. En turkaltam mar hasonlo meretu SAP adatbazisban (tru64 clusteren) nem volt egy leanyalom foleg hogy a meret miatt reorgolhatatlan volt...
Erdekes a winteles megoldas de nem kell elvetni azonnal, bar SAP alatt tapasztalat hogy az MsSQL kicsit belassul 400 giga felett, de gondolom erosen ugy lesz meretezve a vas (dbhost) hogy ne jelentsen gondot.
Ilyen vicces dolgokat hogy mysql, pgsql felejtsunk el, tobb okbol is: a legfontosabb jelenleg a SAP altal supportalt adatbazisok (x86/RISC procikon): Oracle, SapDB, MsSQL, Informix, DB2. pont...egy kis meretu SAPnal is van napi 1-2 millio tranzakcio amelyeket termeszetesen barmikor rollbackelni kellhet...
Amugy nemreg talalkoztam egy kb 500 gigas DB-vel, win2k clusteren, xeon procikkal (igaz SAN-on) de teljesen jo volt a performacia...
Nem kene egybol M$-t frocsogni es a Linuxot isteniteni....
(Linux (RH ES v SuSe) teljesen jo amugy egy kis/kozepes SAP ala, tapasztalat alapjan a nagyokra vmi kereskedelmi unix v win2k kerul...
jah amugy SAP BC lennek...

[quote:0ef4b6f7ee="RoLi"]Namost :)

Tisztazzunk par dolgot :)
....
Ilyen vicces dolgokat hogy mysql, pgsql felejtsunk el, tobb okbol is: a legfontosabb jelenleg a SAP altal supportalt adatbazisok (x86/RISC procikon): Oracle, SapDB, MsSQL, Informix, DB2. pont....

Akkor, a pontosság kedvéért... Hogyan is hívják a 7.5-ös SapDB-t? Nem MySQL MaxDB-nek??? (Az más kérdés, hogy gyakorlatilag semmi köze a MySql-hez, csak a neve ugyebár...)

Ami a memóriaallokációt illeti, annak semmi köze a processzorhoz. Legalábbis amit én mondtam annak nemsok. Nem azt mondtam, hogy a 32Bites processzor és a linux nem lát 3 GB-nál több memóriát, hanem, hogy egy futó process, a rendelkezésre álló memóriából egyszerre nem tud ennél többet lefoglalni. Ez viszont tény, nézz utána. Azaz Pl egy SAP-nál, ha a central instance és a DB egy szerveren fut, minden további nélkül lehet 3 GB-ot a DB-nek adni, és a többit a SAP-nak. De ha megfeszülsz sem fogsz tudni egy user transakcióban 2 Gb-nál több memlóriát allokálni, vagy 3GB-nál nagyobb SGA-t letenni az oraclenek.

Hazudtam. Az egy userre jutó címezhető terület 32-bites környezetben természetesen 4GB. Ebből jön le 1 GB az OS-nek, ebből jön még le a program maga, ami fut, a Heap a Shared Lib-ek, amiket használ és a Stack. Ami ezután marad, az a felhasználható memória a processznek. (free User Space) Ha valakit érdekel, van egy részletes leírásom az SAP kernel memóriakezeléséről linux alatt, és bírom is a szerző (SAP kernel fejlesztő) jóváhagyását, hogy közzétegyem. A baj az, hogy németül van. Ha érdekel valakit, vagy itt föl lehetne tenni, akkor dobjatok mail.... (leo@leoalo.com)

[quote:5bb371d610="LeoALo"]
Ami a memóriaallokációt illeti, annak semmi köze a processzorhoz. Legalábbis amit én mondtam annak nemsok. Nem azt mondtam, hogy a 32Bites processzor és a linux nem lát 3 GB-nál több memóriát, hanem, hogy egy futó process, a rendelkezésre álló memóriából egyszerre nem tud ennél többet lefoglalni. Ez viszont tény, nézz utána. Azaz Pl egy SAP-nál, ha a central instance és a DB egy szerveren fut, minden további nélkül lehet 3 GB-ot a DB-nek adni, és a többit a SAP-nak. De ha megfeszülsz sem fogsz tudni egy user transakcióban 2 Gb-nál több memlóriát allokálni, vagy 3GB-nál nagyobb SGA-t letenni az oraclenek.

Aham, abban a szovegkornyezetben felreertettem.

Very Large Memory (VLM) on systems with up to 64GB of RAM
The Advanced Server 2.1 kernel allows Oracle to allocate and use more than
4GB of memory for the database buffer cache on a 32-bit Intel platform. This
feature is also called VLM (Very Large Memory) in Oracle documents. With
Oracle9iR2 on Red Hat Linux Advanced Server 2.1, the SGA can be increased
to a theoretical limit of about 62GB depending on the available RAM memory
on the system. Current hardware limitations and practical considerations further
limit the actual size of SGA that can be configured, but it is still several times
larger than the size of the SGA without VLM. Running in VLM mode requires
some setup changes to Linux and imposes some limitations on what features and
init.ora parameters can be used.

( http://www.redhat.com/whitepapers/rhel/OracleonLinux.pdf )

Itt ebben az esetben az 62GB SGA-t hogy kell erteni?

ize a titasz a tiszantuli aramszolgaltatot fedi, ami nemreg kerult az eon birtokaba...

:))
ennyi

Nem akarom védeni a PiciPuha oltári hulladék adatbázisnak csúfolt termékét, de egyet meg kell mondanom:
Nálunk alpháról álltak át wintelre az SAP-vel, hasonló méretekben, és döbbenetes, de nem döglött meg, és még viszonylag gyors is. Persze ilyenkor mindig elképzelem, mire lenne képes mondjuk Linux-on Oracle-el ugyanezen a vason, de hát ne legyünk nagyigényűek ugye.... :)

Mindenesetre menni fog a két tera, ha ésszel csinálják, ez tapasztalat...

trey:

Amit írtál nem cáfol meg. Ami benne áll abból az következik (nekem) :
1, Ez nem általános linux tulajdonság, hanem speciális RedHat Advanced Server specialitás.
2, Az áll benne, hogy át kell konfigurálni a linuxot a használatához. Tehát ez a normál memoriaallokálás átvariálása, megtrükközése.
3, A te leírásodban áll:

On systems with upto 4GB of RAM, most Linux distributions allow Oracle to
use about 1.7GB of address space for its SGA. Red Hat Linux Advanced
Server 2.1 is the first Linux distribution to provide an adjustable parameter in
the /proc filesystem to allow more usable address space in processes. To
increase this size, Oracle needs to be relinked with a lower SGA base and Linux
needs to have the mapped base lowered for processes running Oracle.

Namost ez gyakorlatilag azt jelenti amit én is leírtam föllebb. Azzal megspékelve, hogy a RedHat együttműködve az Oracle-el meghackelte a kernelt. Ha kellene tippelnem, hogyan csinálták, aztmondanám, hogy írtak egy kernelmodult, ami nem csinál mást, minthogy indít annyi processt a háttérben, amennyi együtt le tud 62GB memóriát allokálni. Tehát ha 6 Giga kell, akkor két processzt. Az oracle process ezen a modulon keresztül címzi a memóriát, mégpedig úgy, hogy ad egy 4 bites számot, ami a memóriát író processzt azonosítja és egy 32bites memóriacímet, ami a processzen belül az általa lefoglalható memória címe. (Természetesen kell némi overhead, ezért nem 64GB hanem 62GB a foglalható össz memoria) Ehez természetesen spéci bináris kell az oracle oldalon. Nem is csoda, hogy ehet újra kell linkelni. Persze ez csak az én ötletem, lehet, hogy nem pont így csinálják, de hogy hasonlóan az tuti. Ennek csak az a baja, hogy a memóriaelérést mindenképpen lassítja. Hogy mennyivel nem tudom, de gyorsítani nem tudja az biztos. Ez nekem a rendszer megerőszakolása. Továbbrais tartom, hogy bár kitrükközhető, de áll a 32bites arhitektúra memóriaallokálási korlátja. És ez egy nagy adatbázisnál hátrány! És ebben ez a leírás megerősét.

De, minthogy MS-SQLServerről indult a vita idéznék még egy keveset a leírásodból:

On Windows, all these tasks are implemented as threads
within a single process. The thread-based model has limitations on 32-bit Intel
Pentium-based systems because all the threads share the same 3GB address
space for SGA, PGA, and other memory. For example, when large sort areas
are in use, available memory can be an issue since all foreground threads get
their memory from the same 3GB pool.

Üdv
Én

cheeky:

Nem egy cementgyárban történt ez a "gyalázat" véletlenül??? :)

Mindenesetre annak, hogy jól fut a Winen egy rendszer sok oka lenet. Pl az, hogy az SAP gyorsasága döntően az SAP kernel memóriabeállításain múlik. Ezt a UNIX-okon neked kell elvégezni, windowson egy ideje autómatikus. Ez azt jelenti, hogy egy UNIX rendszeren, ha nem egy tuningolásban nagyon tapasztalt ember állítja be, lehet, hogy nagyon lassú lesz a rendszer, függetlenül a vastól. A Winnél, éppen azért, mert a Wines SAP-kat elsősorban olyanok választották és választják, akik nem akarnak költeni túl sokat bázisos szakemberekre megpróbálták ezt is autómatizálni. Ennek az az eredménye, hogy durva hiba nem nagyon van a beállításban alapértelmezésben sem. Ez kis és közepes rendszereknek tökéletesen megfelel. Az MS-Sql Server pedig tökéletesen passzol a koncepcióhoz. Semmi flik-flak, semmi táblaterezés, nincs ezer paraméter, nem kell szöveges paraméterfileokba írogatni. Eredmény: minimális administrációs költség. Hát ezért olyan népszerű.

[quote:a00b2bfd39="LeoALo"]cheeky:
Nem egy cementgyárban történt ez a "gyalázat" véletlenül??? :)

Nem cementgyár volt, bár pár embernek kijárna itt egy kis betonozás... :D

Mindenesetre azért az igazsághoz hozzátartozik, hogy Win2k3 Server Datacenter Edition fut a gépeken, és 8 procis, klaszterbe kötött gépekről van szó...
Aki találkozott már DataCenter "ablakokkal", az tudja, hogy azért annak vajmi kevés köze van stabilitását és skálázhatóságát tekintve egy a pórnép által megszokott gányolmányhoz.

Persze, Datacenter-re könnyű stabil programot fejleszteni a PiciPuhának, elég keményen be van korlátozva, hogy milyen hw eszközökkel hajlandó együttműködni, és nincs mindenféle fusi drivertelepítés, stb...

[quote:94546663b1="LeoALo"]trey:

Amit írtál nem cáfol meg. Ami benne áll abból az következik (nekem) :
1, Ez nem általános linux tulajdonság, hanem speciális RedHat Advanced Server specialitás.
2, Az áll benne, hogy át kell konfigurálni a linuxot a használatához. Tehát ez a normál memoriaallokálás átvariálása, megtrükközése.

...

Namost ez gyakorlatilag azt jelenti amit én is leírtam föllebb. Azzal megspékelve, hogy a RedHat együttműködve az Oracle-el meghackelte a kernelt. Ha kellene tippelnem, hogyan csinálták, aztmondanám, hogy írtak egy kernelmodult, ami nem csinál mást, minthogy indít annyi processt a háttérben, amennyi együtt le tud 62GB memóriát allokálni. Tehát ha 6 Giga kell, akkor két processzt. Az oracle process ezen a modulon keresztül címzi a memóriát, mégpedig úgy, hogy ad egy 4 bites számot, ami a memóriát író processzt azonosítja és egy 32bites memóriacímet, ami a processzen belül az általa lefoglalható memória címe. (Természetesen kell némi overhead, ezért nem 64GB hanem 62GB a foglalható össz memoria) Ehez természetesen spéci bináris kell az oracle oldalon. Nem is csoda, hogy ehet újra kell linkelni. Persze ez csak az én ötletem, lehet, hogy nem pont így csinálják, de hogy hasonlóan az tuti. Ennek csak az a baja, hogy a memóriaelérést mindenképpen lassítja. Hogy mennyivel nem tudom, de gyorsítani nem tudja az biztos. Ez nekem a rendszer megerőszakolása. Továbbrais tartom, hogy bár kitrükközhető, de áll a 32bites arhitektúra memóriaallokálási korlátja. És ez egy nagy adatbázisnál hátrány! És ebben ez a leírás megerősét.

...

trey védelmére kell, hogy keljek, az Oracle-nek semmi köze a kernel hack-eléséhez, legalábbis nem ehhez... ;)
És abszolút nem RedHat specifikus a dolog, hanem sokkal inkább verzióspecifikus, mivel a HugeTLB a 2.6-os szériában elérhető, csak a RedHat backportolta, sok más feature-rel egyetemben. Ahogy egyébként a többi kereskedelmi distro is tette. Az meg, hogy át kell konfigni érte a Linux-ot, igaz, mint ahogy ahhoz is, hogy 2.6-os kernel alatt az adatbázis file-jait tartalmazó diszk-en más legyen az IO ütemező, mint az alapértelmezett. Örülj neki, hogy Linux alatt legalább meg tudod ezt változtatni, nem sok oprendszer van, ahol ezt megteheted.

cheeky:

Ja igen örülök. De ettől függetlenül tartom, hogy egy nagyméretű adatbáziskezelő nem való 32bites platformra, még ha el is fut rajta. (Különösen nem MS-re)

[Törölve]

Termeszetesen mindent lehet esszel meg esz nelkul csinalni - ez itt is fennall. Egyebkent ajanlom figyelmetekbe Jim Gray munkait:

http://research.microsoft.com/~gray/
http://research.microsoft.com/~gray/JimGrayPublications.htm

A windows 2003 -nak van itanium portja is ugye, azzal talan ez megoldhato lesz, szinten epitheto ekkora meretu SCSI diszktomb (FC-AL) egy megfelelo RAID vezerlovel.

Linux + PGSQL -t te lattal mar 2TB-os adatbazisban turkalni? Azt hiszem magyarorszagon akik egyaltalan 2 TB -os adatbazisok kozelebe jutnak igencsak kevesen vannak.

Operacios rendszertol es ABKR -tol fuggetlenul, ez mar nem PC feladat azt lassuk be. Lehet epiteni linux clustert es mindenfele PC csodat, de az nem tul nyero megoldas azt hiszem. Ekkora feladatra mainframe-et sokas venni UltraSPARC-al, Powe4/5, MIPS-el vagy Itaniummal, illetve mostmár Opteront is. Az előzőek ízlés és pénztárca szerintiek. Az összeshez _komoly_ tudás kell, mind telepitesben, mind uzemeltetesben.

Én hallottam már TB-s adatbázisról :) Pl VPOP adatai, amot a kopintdatorg kezel, ez tudtommal vmilyen Unix-on fut egy Oracle... Amúgy Én vagy Oracle-t vagy IBM DB2-t javaslok ekkora adatbázis alá mint adatbázis kezelőt, és természetesen vagy Linux vagy vmelyik unix OS-t... A HW is érdekes kérdés itt, vannak azért elég kifinomult storage megoldások fiberchannel-el, de az is egy külön szakma nállunk, és akkor képbe kerül a mentés is természetesen...

Nem szorosan ehhez a temahoz kapcsolodik, de hasznalta-e mar valaki az sqlite-ot, amit most raktak be php5 ala. Tapasztalat ?
Koszi !

Gabor

Én már láttam nagy adatbázist, mitöbb SAP adatbázist. A kérdés nem az, hogy működik e, hanem az, hogyan. Természetesen lehet ekkora adatbázist építeni MSSQL-Server alatt is, csak az a kérdés, mire akarják használni. A fő gond, hogy MS alatt az SAP csak 32-bites verzióban létezik. Ha jóltudom az MS 64-bites portja is késik még. Ez azt a problémát veti föl, hogy nem lehet tisztességes mennyiségű memóriát allokálni az SAP-nak sem és a DB-nek sem. Tehát a kérdés az, hogy mire is használják ezt az SAP-t. Mert ha relatív kevés felhasználó használja, csak éppen már 10 éve nem arhiváltak semmit, akkor mehet a dolog. Valószínűleg nem áll rendelkezésre csak MS tudás. Mivel egy SAP Bázis szakember nem olcsó, így ennél maradtak.
Akik ilyen dolgokban döntenek gyakran nem szakemberek, hanem olyan gazdasági vezető, aki azért, mert már látott NT-t működni, azthiszi, már ért is hozzá.

Szerintem ekkora adatbázis tisztességesen kizárólag Oracle-el vagy DB2-vel kezelhető.

Ja, ez lemaradt.

Szóval ami rendszerről nekem vannak ismereteim, ott egy Sun Solaris a db server, egy 40TB-os SAN-on csüng, amit most kell lecserélni, mert megtelt :)

Ennél a cégnél is SAP-t használnak. Viszont itt külön csoport foglalkozik az Oracle-el a számtech osztályon belül. Ha valaki új objektumot akar letenni, meg kell mondania a paramétereket és a DB csoport mondja meg mikor, hová teheti. Azthiszem ennek így kell működnie.

A cementgyari SAP pedig koszoni szepen jolerzi magat :)
Wintelen (bar az AS4100-akat sajnalom) ;)