[quote:973920f6c2="LeoALo"][quote:973920f6c2="zeller"]MaxDB-ben van flashback? De ne menjünk ennyire bele... Az Oracle esetén is megvannak azok az eszközök, amelyek az adatbázis _egy részének (táblatér, de van ilyenje sémára is...)_ teljes és online mentését/visszaállítását támogatják, csak használni köll tudni azokat. Egy recovery esetén meg gyakorlatilag mindegy, hogy 23 vagy 98 fájlt kell visszatölteni, max a kazettacserélő technikus fog anyázni esteleg... Ha meg jó SAN-od van az adatbázis alatt, akkor a táblaterenkénti onlány backup idejét -a storage megfelelő funkciójával- naggyon minimálisra le lehet szorítani, és az itt repkedő sokszáz GB-TB méretű adatbázisok esetén a SAN elég gyakori vendég...ű
Ez így ebben a formában igaz. Nem is állítottam az ellenkezőjét. Ellenben jártam már olyan ügyfélnél, ahol két hetes volt a legújabb online mentés és egy kicsinke archivelog file-ocska sérülten lett kimentve...
Néha jól jöhet, ha a mentés önmagában logok nélkül konzisztens.
Ebben igazad van. Az archive logokat is illik csekkolni (jó, el lehet menni odáig, hogy a fájlt kitolom kazira, utána visszaolvastatom és betolom egy standby-adatbázisba...), illetve sokhelyütt ezért marad a diszken az archivelog, etc. A vázolt esetben hivatalos látogatásra megérkezett Szopkovics elvtárs... A mentési/visszaállítási folyamatot én mindenképp átnézném, és az onlány backup-ok közötti időszakokat rövidebbre venném (havi coldbackup-pal spékelve!) plusz az archivelogok kezelésénél sem bíznék meg vakon a mentőeszközben, azaz legalább két plédányt (diszk plusz szalag) őriznék meg belőle...
1., Mit állítottam? Hogy nem csinál konziszetns online mentést. Mit jelent ez? Hogy tudsz menteni, tudsz online menteni, csak kell hozzá a mentés kezdete és vége között készült összes logfile. A recovery végén a mentés végének állapota visszaállíthato. Ugyanez a MaxDB-nél úgy megy, hogy a mentés kezdetének pillanatában meglévő konzisztens állapotot tudod az online mentésből visszaállítani mineden log nélkül. Ki beszélt itt exportról? Az export nem mentés!!!! ( nem is egyenértékű. Érdekelne pl, hogyan "mentesz" le egy SAP adatbázist online konzisztensen exp-el figyelembe véve a maga kb 40000 adatbázisobjektumát.)
2. én nem, szerintem nem tudjuk eldönteni. Ha bebizonyítod hogy lehet készséggel elfogadom.
3. Igen, RMAN-al lehet, de ez nem más, mint egy recovery. Egyanúgy sokáig tart mint a sima visszatöltés.
1. Mi az hogy az export nem mentés? akkor hogyhogy mindig vissza lehetett állítani a rendszert akár egy üres adatbázisba (bevallhatjuk, hogy nem mindig egyszerűen csak egy imp oszt csók, tökölni kell vele) Szerinted mégis mire szolgál a full export?
2. Nem akarom, mert mint irtam én sem vagyok benne biztos. Megpróbálom kikeresni a leírást.
3. Megint részletek, van vagy nincs?
Az erős flame-hez csak az a hozzátennivalóm, hogy kicsit talán pontosítanom kell. Én az SAP világot ismerem részletesebben. Itt meg nincs MySQL, meg Postgres. Itt Oracle, DB2, Informix, SQL Server és MaxDB van. Ezek közül a MaxDB az egyetlen GPL-es. És az SAP installációk 95%-ára értettem a mondanivalómat.
[quote:5fe10a6b27="mocsi"]1. Mi az hogy az export nem mentés? akkor hogyhogy mindig vissza lehetett állítani a rendszert akár egy üres adatbázisba (bevallhatjuk, hogy nem mindig egyszerűen csak egy imp oszt csók, tökölni kell vele) Szerinted mégis mire szolgál a full export?
egy tetszoleges pillanatban torteno export max mesebeli szerencsevel ad neked konzisztens adatmentest
[quote:286db5ca1f="snq-"][quote:286db5ca1f="mocsi"]1. Mi az hogy az export nem mentés? akkor hogyhogy mindig vissza lehetett állítani a rendszert akár egy üres adatbázisba (bevallhatjuk, hogy nem mindig egyszerűen csak egy imp oszt csók, tökölni kell vele) Szerinted mégis mire szolgál a full export?
egy tetszoleges pillanatban torteno export max mesebeli szerencsevel ad neked konzisztens adatmentest
Akkor az a consistent kapcsoló csak egy marketing fogás.
1. Mi az hogy az export nem mentés? akkor hogyhogy mindig vissza lehetett állítani a rendszert akár egy üres adatbázisba (bevallhatjuk, hogy nem mindig egyszerűen csak egy imp oszt csók, tökölni kell vele) Szerinted mégis mire szolgál a full export?
2. Nem akarom, mert mint irtam én sem vagyok benne biztos. Megpróbálom kikeresni a leírást.
3. Megint részletek, van vagy nincs?
1a, Van pl 5000 táblád (Pl SAP R3. több is van benne de most mind1). elkezded menet közben exportálni az elsőt. Aztán a másodikat, satubbi. Mire az ötezredikhez érsz biztos, hogy már legalább egy korábban már kiexportált tábla megváltozik. Ergó: Ha nem változott semmi, akkor nem is dolgozott senki. Ha valaki mégis dolgozott, akkor ugyan vissza tudsz tölteni egy üres adatbázisba valamit, de az nem lesz konzisztens.
1b, hogy mentesz egy néhány TB-s rendszert? Export tart kb két hétig.
3, Ez a vita abból indult, hogy valaki megkérdezte mi az, ami nincs Oracle-ben.
Online backup: Oracle : van. MaxDB: van
DBSnapshot: Oracle: nincs, MaxDB: van.
[quote:3b38d01a80="LeoALo"]
1a, Van pl 5000 táblád (Pl SAP R3. több is van benne de most mind1). elkezded menet közben exportálni az elsőt. Aztán a másodikat, satubbi. Mire az ötezredikhez érsz biztos, hogy már legalább egy korábban már kiexportált tábla megváltozik. Ergó: Ha nem változott semmi, akkor nem is dolgozott senki. Ha valaki mégis dolgozott, akkor ugyan vissza tudsz tölteni egy üres adatbázisba valamit, de az nem lesz konzisztens.
1b, hogy mentesz egy néhány TB-s rendszert? Export tart kb két hétig.
3, Ez a vita abból indult, hogy valaki megkérdezte mi az, ami nincs Oracle-ben.
Online backup: Oracle : van. MaxDB: van
DBSnapshot: Oracle: nincs, MaxDB: van.
Ennyi. Egy példa.
ok.
1. a. erre szolgálnak az általam emlegetett kapcsolók (mindent kimentődik, kivéve a user és táblaterület létrehozási definiciók). Konzisztens marad, mert figyeli a változásokat a mentés alatt és utólag "kiigazítja'. Itt valószínűleg sokkal jobb a MaxDB, mert nagy változásokat is biztonságosan eltárol, míg az Oracle-nál ha kifogy a RBS, akkor lőttek az egész mentésnek (vagy mint a 8.0.6-os Oracle-ben az egész adatbázisnak :D ha a RBS megtelt és nem tudott hova nyújtózkodni)
1.b. A két hét pici túlzás, ha nincs benne nagy mozgás és normális az I/O throughoutput, akkor egy nap alatt meg kell lennie. De itt már eleve más mentési technológiát kell alkalmazni a nagy hely és igénybevétel miatt.
3. DBSnapshot Oracle: kínlódás szintjén lehetséges, MaxDB: praktikusan megvalósítva és működik.
Mielőtt félre értitek, a Postgres-re szavaztam mint kedvenc DB motor. :lol:
[quote:3355525e6a="mocsi"]
1. Ácsi, azt állítottad nincs benne, mármint az Oracle-ben most akkor ne térj el a tárgytól. Benne van, és az hogy mentesz vagy exportálsz adatok szempontjából tökmindegy, mindkettő visszaállít egy (konzisztens/nem konzisztens) állapotot, a többi kérdés technikai és management kérdés. Amúgy ami nekem max full export Oracle-el volt az egy 500GB, de 1 óra 12 perc alatt megvolt.
Egyaltalan nem mindegy. A visszaallitasnal a meglevo objektumokat hasznalod, mig importnal uj objektumok keletkeznek.
[quote:3355525e6a="mocsi"]
2. erről valamikor olvastam valamit, állítólag lehet, csak hivatalosan nem támogatott persze.
A backup attol online, hogy futas kozben (nem allitod le az adatbazist, nem fagyasztod be a fajlrendszert) lehet konzisztens backup-ot csinalni. Az adatfajlok mentes kozben nyugodtan modosulhatnak, a mentes alatt a *modosult* blokkok keszult logot kell csak ragorgetni.
A snapshot ami elokerult nem mas, mint az adatterulet befagyasztasa es redo log, ami nem backup megoldas.
Lasd MaxDB doksi, Freezing the Data Area (Snapshot):
*A snapshot is not a data backup.* To be able to restore your data after damages in the data area, you have to perform regular data and log backups.
[quote:3355525e6a="mocsi"]
Amit a végén írsz egy nagyon erős flame, ugyanis az átlag 95% felhasználó/programozó egy sqlite/mysql 3.23-al is tökéletesen el lenne, nem beszélve hogy jóval kezelhetőbb és átláthatóbbak a számukra. Ezután jönnek a különleges igények, melyek figyelembe vételével kell a db technológiát kiválasztani, ami lehet pgsql, oracle, db2 sőt MaxDB is ;)
Es az az atlag 95% nem csinal mast, csak a hianyzo adatbazisfunkciokat probalja alkalmazasszinten potolni (=takolni).
[quote:d3848c00a5="LeoALo"]Ez így ebben a formában igaz. Nem is állítottam az ellenkezőjét. Ellenben jártam már olyan ügyfélnél, ahol két hetes volt a legújabb online mentés és egy kicsinke archivelog file-ocska sérülten lett kimentve...
Néha jól jöhet, ha a mentés önmagában logok nélkül konzisztens.
Hát, ez a fránya Oracle is olyan, hogy érteni kell hozzá. Ha az adatbázis visszaállíthatóságának az archive log az egyik kulcspontja, akkor azt talán rendszeresen kellene menteni, nem?
Egy ügyfelünknél olyan mentést építettünk ki, ahol naponta éjjel történik meg az adatbázis online mentése és napközben kétszer - bár gondolkoztunk a négy alkalmon is - az archive log-oké.
Egy archive log-ot négyszer mentünk, garantáltan legalább két különböző szalagra, de csak egy hónap elteltével töröljük, így egy esetleges visszaállításnál nem feltétlen kell a szalagokat birizgálni.
Így jó eséllyel elkerülhetjük az archive log vesztést, bár azért a felhasználok és/vagy a fejlesztők olykor megtréfálnak és egy hét alatt megtelítik a logoknak fenntartott 100G-s területet. :-)
[quote:c097ee8021="noss"]Köszi mindenkinek, aki válaszolt a kérdéseimre!
[quote:c097ee8021="zeller"]
Az Oracle igényli, vagy az alkalmazások a karbantartást/masszázst? Elég naaaaaaaagy Oracle adatbázisokhoz is volt szerencsém, amikbe garantáltan belerokkant volna fejlesztő is, dba is, felhasználó is, ha Postgres, mySQL, vagy hasonló szoftver kezelte volna azokat az adatokat...
Miért rokkantak volna bele? A karbantartás nehézsége miatt?
A fejlesztő a fejlesztőeszközök khm. gyengeségei, a dba a monitorozóeszközök híjján, (tényleg, vannak SpotLight-szerű vackok My/PgSQl-hez?) a felhasználók meg a "kissé mást kissé hosszabb fejlesztési idő alatt kaptam" miatt... Az Oracle már régóta nem csak egy RDBMS a sok közül, hanem igen-igen sok "körítés" is van mellette, ami a MY/PgSQL-lel nem összemérhetővé emeli.
Én kicsit meg vagyok döbbenve.
Ugyan semmi nem áll tőlem távolabb, mint hogy a magam izlését akarjam másokra eröltetni, de azthittem a MaxDB sokkal népszerűbb lesz. Adott egy adatbáziskezelő, amely bizonyos dolgokban és bizonyos feladatokra felülmúlja még az oracle képességeit is, GPL licensz alatt használható, 7*24 órás supportot vehetsz hozzá az SAP-tól és alig ismeri valaki. Mindenki epekedve várja, hogy a MySql végre átugorja a saját árnyékát, megrakja az amúgy szimpatikus kis adatbáziskáját olyan funkciókkal, amik már hasonlítanak a nagyokra, közben meg két füllel odébb van egy termék, ami mindezt profin tudja és senki még rá sem kattint.
Egyszerűen döbbenet.
A MaxDB-t több programozó fejleszti főállásban, mint ahány alkalmazottja a MySQL-nek van főnököstül, kereskedőstül, grafikustol, takarítónénistül, mindenestül szor kettő. Nehogy félreértsen valaki! Nem fikázni akarom a MySQL-t. Csak nem értem miért nem használ szinte senki MaxDB-t.
[quote:4ebe1b14b8="saabi"][quote:4ebe1b14b8="LeoALo"]Ez így ebben a formában igaz. Nem is állítottam az ellenkezőjét. Ellenben jártam már olyan ügyfélnél, ahol két hetes volt a legújabb online mentés és egy kicsinke archivelog file-ocska sérülten lett kimentve...
Néha jól jöhet, ha a mentés önmagában logok nélkül konzisztens.
Hát, ez a fránya Oracle is olyan, hogy érteni kell hozzá. Ha az adatbázis visszaállíthatóságának az archive log az egyik kulcspontja, akkor azt talán rendszeresen kellene menteni, nem?
Ave, Saabi.
Egy vita végéhez szóltál hozzá. Az egész úgy kezdődött, hogy nem átallottam azt állítani, hogy mindamellett, hogy szeretem az Oracle-t és az egyik legjobb adatbáziskezelőnek tartom, mégiscsak vannak olyan funkciók, amik egy "ingyenes" (GPL...tudom nem ingyen, de most nem is ez a téma) adatbáziskezelőben megvannak de a drága Oracle-ben nem.
Erre volt egy példa a konzisztens online mentés, az adatbázis szintű snapshot stb...
Az említett ügyfélnél pedig nem én állítottam be a mentést, nem is kérdeztek meg. Amikor már egy napja ált 2 gyár, akkor hívtak ki minket. És ekkor már mind1 hogy én mit gondolog arról aki ilyen mentést csinál. Egy ilyen (félig sem hozzáértő, de nagyarcú) ügyfélnek jobb választás a MaxDB (még ha ugyanannyit kellene is fizetni érte mint az Oracle-ért) . Ezt állítom. És ez nem von le semmit az Oracle értékéből.
egy _picit_ tudományosabban elmondanátok, hogy _komolyabb_ feladatra miért kell kereskedelmi db és miért nem jó, miben marad el pl egy postgre?? lehet hosszan is válaszolni!
[quote:50ce763d19="LeoALo"]Én kicsit meg vagyok döbbenve.
Ugyan semmi nem áll tőlem távolabb, mint hogy a magam izlését akarjam másokra eröltetni, de azthittem a MaxDB sokkal népszerűbb lesz. Adott egy adatbáziskezelő, amely bizonyos dolgokban és bizonyos feladatokra felülmúlja még az oracle képességeit is, GPL licensz alatt használható, 7*24 órás supportot vehetsz hozzá az SAP-tól és alig ismeri valaki. Mindenki epekedve várja, hogy a MySql végre átugorja a saját árnyékát, megrakja az amúgy szimpatikus kis adatbáziskáját olyan funkciókkal, amik már hasonlítanak a nagyokra, közben meg két füllel odébb van egy termék, ami mindezt profin tudja és senki még rá sem kattint.
Egyszerűen döbbenet.
A MaxDB-t több programozó fejleszti főállásban, mint ahány alkalmazottja a MySQL-nek van főnököstül, kereskedőstül, grafikustol, takarítónénistül, mindenestül szor kettő. Nehogy félreértsen valaki! Nem fikázni akarom a MySQL-t. Csak nem értem miért nem használ szinte senki MaxDB-t.
Részemről PostreSQL-t használunk ahol engedik. Általában nem engedik, mert Oracle az isten. Az általad említett MaxDB-vel az a baj, hogy soha nem hallottam róla. Ha pedig elkezdem alternatívákért feltúrni a netet, nem tudok mit kezdeni a több száz "jelentkezővel". És ezen jelentkezők többsége hullaék (elnézést: nem elégíti ki az igényeimet). Ezek közül kiválasztani a MaxDB-t, mely igaziból egy gyöngyszem (mint írod), lehetetlen. A PostgreSQL-nek viszont van 2neve" (értsd: kellő mértékben elterjedt), és mint választás nálunk nagyon bevált.
Hát ezért nem MaxDB.
És még valami. Lehet, hogy semmi köze hozzá, de engem az SAP Hungary 200.000 Ft-os szakember _napidíja_ kissé riaszt. Úgy értem kizárt, hog yén bármit vásároljak tőlük, olyan drágák. Nem az én súlycsoportom...
[quote:aba7daaaa6="noss"]egy _picit_ tudományosabban elmondanátok, hogy _komolyabb_ feladatra miért kell kereskedelmi db és miért nem jó, miben marad el pl egy postgre?? lehet hosszan is válaszolni!
Csak a főbb előnyök:
1. Véded s@gged, hogy adnak hozzá szápportot
2. Ha gondod van, akkor rájuk hárítod, hogy nézzenek utána
3. Más termék gyártónál tudod verni a melled, hogy erre alapozzon, mert ez, papírra alapozva, ki van tesztelve.
Azért azt el kell ismerni a fizetős adatbázis kezelőkben jó sokáig bent lehet egy lyuk, mert ha a gyártó nem javítja ki és nincs semmi workaround rá, akkor csak reménykedhetsz, hogy nem fogja senki kihasználni.
Meg érdekes módon mehet a fejlesztés, mert a Larry bácsi termékébe időnként becsúsznak olyan bugok, hogy egy sima selectet nem képes végrehajtani. Nem beszélve arról, hogy a legelső 9-es verzió kb. használhatatlan volt.
[quote:335c2d45b5="LeoALo"]Adott egy adatbáziskezelő, amely bizonyos dolgokban és bizonyos feladatokra felülmúlja még az oracle képességeit is
Ez érdekel: miben múlja felül az Oracle-t?
[quote:335c2d45b5="LeoALo"], GPL licensz alatt használható, 7*24 órás supportot
Nem. Ugyan az a licensze, mint a mysql-nek, vagyis csak open source programok mellé ingyenes, egyébként fizetős (50$ userenként vagy 1500$).
Értem a "döbbenetedet", csak kicsit későn érkezett a maxdb, kevesen ismerik, és elég komoly mennyiségű ismeretet igényel az üzemeltetése (önálló állatfaj, mint a többi "nagy" is). Majd meglátjuk mi lesz vele 3-5 év múlva.
[quote:a59b27a67c="noss"]egy _picit_ tudományosabban elmondanátok, hogy _komolyabb_ feladatra miért kell kereskedelmi db és miért nem jó, miben marad el pl egy postgre?? lehet hosszan is válaszolni!
1. Támogatás
2. SQL szabványnak megfelelő implementáció
3. Ezt ismerik a fejlesztők
4. Az támogatott az adott környezetben. pl.: van hozzá natív backup szoftver kliens, SAN integrált mentés támogatottsága, mondjuk ha SAP-ot akarsz használni az sem fut mindenen (még)
1. azért fontos mert nem téged vesznek elő, hogy korrupt az adatbázis, áll a rendszer, tessék már megoldani, vagy fizetni az állásidőt.
3. idő pénz kitanulni egy rendszert, ha már van tudás akkor azt használják
4. kész megoldás esetén nem kell hegeszteni (annyit :) )
Egyébként a PostgreSQL 8.x új szolgáltatásait figyelve nagyon szépen fejlesztik.
[quote:01b126d210="noss"]egy _picit_ tudományosabban elmondanátok, hogy _komolyabb_ feladatra miért kell kereskedelmi db és miért nem jó, miben marad el pl egy postgre?? lehet hosszan is válaszolni!
Az Oracle Tech Net (otn.oracle.com) -en kint van fejlsztői célra gyakorlatilag valamennyi termék, ezeket devel környezetben gyakorlatilag ingyen használhatod -- Az Oracle tudja, hogy segítséget, képzést, doksit, etc. úgy is fogsz venni hozzá, és a production rendszerre a megrendelő meg kell, hogy vegye, ergo azzal, hogy a fejlesztőt ezzel támogatja, azzal eladásokat generál.
ha pedig fejlesztés, akkor fejlesztőeszköz (TOAD), ha meg üzemeltetés, akkor monitorozó eszköz (Quest SpotLight) is kell -- no ez mind van Oracle-höz.
De akár egy olyan egyszerű dologra is gondolhatnánk, mint online backup...
[quote:807cde0c04="mocsi"]Izéé szerintem SAPdb != SAP ERP
Ott a pont!
Mint már elhangzott párszor SAPDB már MaxDB néven fut és egy adatbázis-kezelő.
A SAP ERP meg egy alkalmazás ami akár a fenti adatbázis-kezelőt is használhatja.
[quote:4083b132ec="Ago"]
Mert nem a .org-on kell keresni :) Van több cég is, akik hivatlosan árulják a postgrest, pl. a CommandPrompt. Mondjuk velük lehet kötni háttérszerződést illetve backend supportra.
Egyébként mintha először nem kötötted volna ki, hogy csak Mo-n lehet a backend support :)
Addig amíg itthon nem kínlja egy magyar cég addig ez nem realitás. Egyrészt tipikusan árérzékeny szegmens a megcélzott ezért még egy külföldi alap támogatást sem nagyon tudsz eladni a pgsql mellé. Kell egy közvetitő a nyelvi, technikai áthidalásra.
Magyar embernek magyar supportot! :) :) :)
A backend lehet bárhol, csak vezessen oda könnyű út.
[quote:4083b132ec="Ago"]
Azt meg mindannyian tudjuk, hogy legtöbb cég termékénél itthon is csak forwardolják a bonyolult support kérdéseket, tisztelet a kivételnek, azért abból is van jó pár.
Igen mert támogató központ nincs a világ minden szegletében, nincs is annyi specialista, meg nem is érné meg. De van amit kis hazánkba forwardolnak, pl. SAP. :)
[quote:4083b132ec="Ago"]
Ha jól értem, akkor Te az olyan alkalmazásokat hiányolod, mint az SAP Postgresql alapon Oracle helyett vagy ha nem is ekkorát, akkor is valamilyen "fajsúlyosabbat".
Pontosan, legalább valamit ami az üzletmenet szempontjából kritikus. Amíg ilyen nincs addig, lehet, hogy a webes telefonkönyv alatt pgsql van, de meg is marad azon a szinten. Szerintem alkalmazással együtt van esélye a terjedésre. A cégek általában nem technológiát - az csak nekünk fontos mert ezt vagy azt szeretjük - hanem megoldást vesznek.
[quote:85213c0c96="szekelyk"][quote:85213c0c96="mocsi"]Izéé szerintem SAPdb != SAP ERP
Ott a pont!
Mint már elhangzott párszor SAPDB már MaxDB néven fut és egy adatbázis-kezelő.
A SAP ERP meg egy alkalmazás ami akár a fenti adatbázis-kezelőt is használhatja.
Sőt én úgy tudtam, hogy több SAP (ERP) fur Oracle DB-n, mint MaxDB alatt.
[quote:b6908a7c90="whitehorze"]
-párszáz megás adatbázis.. ok leállállítod a szervert és backupolsz nemde?
csináld meg ezt egy banki rendszerrel. Oracle nem is tud menet közben backupolni!!!
Oracle pl. rettenetesen igényli hogy karbantartsák, és még így is rengeteg gond van vele. Bárki megnézheti, hogy hányszor állnak le az Oracle-es szerverek. Ja bocsánat, ezek a statisztikák persze nem publikusak, istenem...
Höm... Már megbocsáss, de mikor láttál te utoljára Oracle-t? az alter tablespace xxxx begin backup, illetve alter tablespace xxxx end backup, közben pedig fizikai fájlmásolás, vagy storage-szintű FS-snapshot mindent táblatérre meg, majd a controlfile-t is bekapod :) (alter database backup controlfile to '/some/arbitrary/path';) de bővebben pl. http://www.adp-gmbh.ch/ora/admin/backup_recovery/hot_backup.html
Az Oracle igényli, vagy az alkalmazások a karbantartást/masszázst? Elég naaaaaaaagy Oracle adatbázisokhoz is volt szerencsém, amikbe garantáltan belerokkant volna fejlesztő is, dba is, felhasználó is, ha Postgres, mySQL, vagy hasonló szoftver kezelte volna azokat az adatokat...
[quote:2227061938="KAMI911"]Nekem a FirebirdSQL a kedvencem, ígyhát arra szavaztam...
Linux-on futtatod?
Bevallom én egyszer megpróbáltam feltenni debian alá, de valamitől..
.. már nem emlékszem mitől felment az agyvizem és rm -fr${k*anyad} firebird
lett a vége.. persze ez ugy 2-3 éve volt.
Fri
[quote:d460957655="whitehorze"]
csináld meg ezt egy banki rendszerrel. Oracle nem is tud menet közben backupolni!!!
Oracle pl. rettenetesen igényli hogy karbantartsák, és még így is rengeteg gond van vele. Bárki megnézheti, hogy hányszor állnak le az Oracle-es szerverek. Ja bocsánat, ezek a statisztikák persze nem publikusak, istenem...
Az itt szavazók 99% százaléka szerintem laikus..
Lefogadom "bankos" vagy.. azok szoktak ennyi marhaságot összehordani.:))
Az oracle nem tud menet közben bakuplni.. ez igy van, sőt! A monitorrol kell
lolvasni a kilistázott táblák tartalmát és felirni egy füzetbe, amit nyugdidjjas nénik
utána felvisznek egy access adatbázisba.. ez a mentés.:))
Az Oracle-vel rengeteg gond van.. tyja.. valóban kevés hozzáértő van aki
rendesen be tud hangolni, konfigurálni egy Oracle szervert.. annál több okoska,
mint Te. Én már "láttam" egy hozzáértő hangolását.. mit ne mondjak.. akkora
volt a különbség, mint egy csiga és egy F1 között van.
Szóval.. én csak azt nem értem, hogy jössz ennyi hülyeség után ahhoz, hogy lelaikusozd a szavazókat.
Fri
[quote:629025800a="tolmi"][quote:629025800a="dejo"]Régebben egyértelműen a magukat profinak vallók használtak PostgreSQL-t és a MySQL-eseket leamatőrözték.
Hál'Istennek ez kezd felszámolódni. Jónéhány intelligens kollega gyepálása végre beérni látszik és befejeződik ez a világméretű hülyeség, amiről írsz. :)
Pedig egyértelmű és hülyeség is ilyenen vitatkozni, mert mindenki
tudja, hogy aki MySQL-t használ az amatör.. aki PostgreSQL-t az profi.:-)
Fri
Elég agresszív véleményt alkottam ide rólad, kedves Frimen. De tudod mit? Nem érsz meg annyit, hogy kint hagyjam. De baromi jól mulattam rajtad. Szánalmas.hu színvonal...
[quote:b3516d6d9a="ssikiss"][quote:b3516d6d9a="LeoALo"]Adott egy adatbáziskezelő, amely bizonyos dolgokban és bizonyos feladatokra felülmúlja még az oracle képességeit is
Ez érdekel: miben múlja felül az Oracle-t?
Akkor tisztázzuk. Azt írtam bizonyos esetekben, bizonyos alkalmazásokra.
Pl egy nagyságrendel egyszerűbb kezelni, karbantartani. Nem igényel reorganizációt mint az Oracle (Bár a localy managed tablespace és az új segment management-el az Oracle deklarálta, hogy nem kell már reorgozni, valahogy mégis minimum 10% sebességnövekedést sikerült bizonyítani legutóbb),
egy "táblatered van",
tudsz konzisztens online mentést csinálni. (mitöbb csak olyat tudsz :) ) Az Oracle-el archive logok nélkül semmit nem érsz, még akkor sem, ha nem akarod előregörgetni a adatbázisodat az utolsó pillanatig. (Online mentés esetén persze),
Ugyanazon adatmennyiség tárolásához sokkal kevesebb (20-40%) hely kell mint Oracle alatt,
Van adatbázis snapshot lehetőség, ami Oracle-ben tudtommal nincsen.
Pár kiegészítés: a Postgresql-hez is tudsz venni kereskedelmi támogatást, plusz szolgáltatásokat, modulokat.
Magyarországon? Hol? A postgresql.org oldalán nem találtam magyar bejegyzést.
Google sem segített.
Nagy cégek nem a telefonkönyvből választanak informatikai bt.-t beszállítónak. Olyan alkalmazások kellenek PSQL-re (vagy x-re) amit ezek a nagyok használnak. Aztán már jöhetnek a bt.-k a specialistákkal, akik támogatnak, fejlesztenek. De elterjeszteni nem ők fogják. Túl kicsik, nincs súlyuk, ilyen téren.
Ha szállítasz rendszert, akkor tudsz mutogatni a gyártóra, de a rendszert akkor is Te választottad, végső soron a Te seggedet rúgják szét.
Nem arra gondoltam ha elbénázod vagy rossz a termék és tényleg használhatatlan. Szerintem itt már mindenki látott karón varjút. Tehát ha összejön valami fura hiba, akkor nem neked kell kiderítened, amire adott esetben sem tudásod, sem erőforrásod nincs.
[quote:9c6640f54c="ssikiss"][quote:9c6640f54c="LeoALo"], GPL licensz alatt használható, 7*24 órás supportot
Nem. Ugyan az a licensze, mint a mysql-nek, vagyis csak open source programok mellé ingyenes, egyébként fizetős (50$ userenként vagy 1500$).
Értem a "döbbenetedet", csak kicsit későn érkezett a maxdb, kevesen ismerik, és elég komoly mennyiségű ismeretet igényel az üzemeltetése (önálló állatfaj, mint a többi "nagy" is). Majd meglátjuk mi lesz vele 3-5 év múlva.
Akkor kissé férreértetted. A következő áll az oldalon:
MySQL AB offers MaxDB under the MySQL AB "dual licensing" model. The complete MaxDB offering is provided free of charge under the Free Software/Open Source GNU General Public License (GPL) and also a commercial license with no open source restrictions.
Mit jelent ez? Egyrészt lehetőséged van a terméket GPL licensz alatt használni. Mit jelent ez? Letöltheted és használhatod. De ha fejlesztesz valami, amibe befordítod pl a kliensét, vagy ha fölteszed a terméked CD-jére, akkor a termékedet is GPL alatt ki kell adnod.
Ez egyrészt jó a felhasználónak, de rossz annak a fejlesztőnek, aki fizetős progit akar eladni és nem GPL alá fejleszteni. Ezért lehetőség van üzleti licenset venned, ezesetben mentesülsz a GPL kötelmei alól, azaz eladhatod a progidat zárt kóddal.
[quote:29b65663c6="Ago"]Pár kiegészítés: a Postgresql-hez is tudsz venni kereskedelmi támogatást, plusz szolgáltatásokat, modulokat. Ha szállítasz rendszert, akkor tudsz mutogatni a gyártóra, de a rendszert akkor is Te választottad, végső soron a Te seggedet rúgják szét.
A MySQL-hez ragaszkodók tényleg sokszor mondják még mindig, hogy "ez csak postgreses hülyeség". Talán nézzük meg, ha ragaszkodunk az ACIDhoz, akkor mire is képes a MySQL. A MySQL5-ben jelent csak meg, most a tárolt eljárás, a trigger, a _rendesen_ működő constraint és foreign key támogatás - volt benne constraint persze, mondjuk a check null :) és hasonló komoly featureok. Szóval rendesen nem volt implementálva vállalati felhasználásra mondjuk egy ügyviteli rendszerhez. Ugyanakkor nagyon jó volt portálmotorhoz ahol nem volt szükséges egy ROLLBACK, ha mondjuk mégsem sikerült volna a teljes tranzkció, azaz nem volt rendes tranzakció kezelés. Folytassam? Másra jó. Sok mindenre még mindig használhatóbb a postgresql.
idézet mysql doksiból : "Starting from MySQL 3.23.44, InnoDB features foreign key constraints." ami annyit jelent, hogy a mysql adatbázisban az innodb típusú tábla már a 3.23.44-es verziótól kezdve támogatja a külsőkulcs kényszerítést. ez a verzió pedig 2001. október 31-én jött ki.
továbbá az innodb táblatípust főleg arra találták ki, hogy tranzakciókat is tudjon kezelni, ez pedig már elég régóta része alapból a mysql-nek!
továbbá csak halkan jegyzem meg, hogy valamiért pont most az oracle vette meg az innobase -t ;) (az innodb táblatípus "gyártóját")
[quote:f32fe8a49a="LeoALo"]***
tudsz konzisztens online mentést csinálni. (mitöbb csak olyat tudsz :) ) Az Oracle-el archive logok nélkül semmit nem érsz, még akkor sem, ha nem akarod előregörgetni a adatbázisodat az utolsó pillanatig. (Online mentés esetén persze),
***
Van adatbázis snapshot lehetőség, ami Oracle-ben tudtommal nincsen.
Nem vagyok SQL használó, de kacérkodom vele, mert szükségem lesz rá.
Azért jó ideje figyelem a MySQL kontra PostgreSQL vitát. Régebben egyértelműen a magukat profinak vallók használtak PostgreSQL-t és a MySQL-eseket leamatőrözték. Talán te is ebben az állapotban vagy?
Mostanában, mintha a MySQL is elismertebb lenne. A legyek meg lehet, hogy inteligens lények!
Ja igen és akkor jönnek még a meg nem alkuvók, akik csak "márkás" cuccal dolgoznak, még akkor is, ha a feleség receptgyűjteményét kell tárolni, mert fő a biztonság! (Ez utóbbi erősen túlzás akart lenni, de a lényegre kellőképpen rávilágít.)
[quote:5f23a2a16e="mocsi"][quote:5f23a2a16e="szekelyk"][quote:5f23a2a16e="mocsi"]Izéé szerintem SAPdb != SAP ERP
Ott a pont!
Mint már elhangzott párszor SAPDB már MaxDB néven fut és egy adatbázis-kezelő.
A SAP ERP meg egy alkalmazás ami akár a fenti adatbázis-kezelőt is használhatja.
Sőt én úgy tudtam, hogy több SAP (ERP) fur Oracle DB-n, mint MaxDB alatt.
Az R3 eredetileg Oracle-re készült. A SAPDB-MaxDB egy új dolog. Igazából Objektumorientált adatbázisnak vették és fejlesztgették. Nem is volt a klasszikus R3-hoz elérhető, csak az APO LiveCache-e volt. (Ez már hardcore SAP. Elég az, hogy egy spciális rendszer egy speciális alkotórésze) Csak miután az oracle szőrözni kezdett, az SAP kissebb ügyfelek felé nyitott, és mivel lassan használható adatbáziskezelő lett hagyták jóva az ERP rendszerekhez.
Azontúl az SAP többet keres egy Oracle-el futó rendszeren, mint egy MaxDB-sel. Ezt sem felejtik el soha.
Szerintem alapvető probléma, hogy nincs ponotsan definiálva hogy miről is kell szavazni. Mit fog jelenteni a végeredmény? Kinek a kedvence? Programozóé, vagy neadj isten a dba-é? Kisbolt árukészletét, vagy egy banki rendszert kell elvinnie?
Lehet (pl mysql) nagyon felhasználóbarát: a nagymamám is összedob egy adatbázist a varázslókkal; A programozók imádni fogják, mert irogathatnak mindenféle kényelmes függvényeket, meg ilyesmik, de nem örülnék neki ha a bankszámlámat egy ilyen rendszer kezelné.
Mekkora adatot kezelsz vele?
-párszáz megás adatbázis.. ok leállállítod a szervert és backupolsz nemde?
csináld meg ezt egy banki rendszerrel. Oracle nem is tud menet közben backupolni!!!
Melyik a fontosabb:
Több pénzt és időt áldozni olyan programozókra - akik több pénzért persze - de megizzadnak egy komolyabb, de kevésbé "popókinyalós" adatbázissal, és cserébe kisebb a hardverigény mellet és kevesebb adminisztrációt igénylő adatbázist jelent, vagy összedobni "két nap alatt" egy adatbázist "mikroszoftos varázslókkal", aztán izzadjon a dba - meg persze aki fizeti a dba-t ;).
Oracle pl. rettenetesen igényli hogy karbantartsák, és még így is rengeteg gond van vele. Bárki megnézheti, hogy hányszor állnak le az Oracle-es szerverek. Ja bocsánat, ezek a statisztikák persze nem publikusak, istenem...
Rengeteg szempont van, ez a szavazás pedig csak egy valamivel foglalkozik: "Neked melyik szimpi?"
Az itt szavazók 99% százaléka szerintem laikus, de legalábbis soha nem dolgozott mondjuk komolyabb rendszereken. (mondjuk közigazgatási, vagy banki rendszereken)
Szóval szerintem tegyétek be az Access-t, és ha elég nagymama látogatja meg az oldalt, akkor az lesz az év kedvenc adatbáziskezelője.
[quote:54aea7c869="mocsi"][quote:54aea7c869="LeoALo"]***
tudsz konzisztens online mentést csinálni. (mitöbb csak olyat tudsz :) ) Az Oracle-el archive logok nélkül semmit nem érsz, még akkor sem, ha nem akarod előregörgetni a adatbázisodat az utolsó pillanatig. (Online mentés esetén persze),
***
Van adatbázis snapshot lehetőség, ami Oracle-ben tudtommal nincsen.
Ezekben nagyon biztos vagy? :wink:
Meglehetősen. A snapshot-ban egészen. A normál mentésnél is. Max az RMAN-al lehet valamit bűvészkedni. De a normál oracle online mentés bizony csak "recover database" -el lesz konzisztens. Ebben akár fogadhatunk is :D
[quote:3c7f559950="szekelyk"][quote:3c7f559950="noss"]egy _picit_ tudományosabban elmondanátok, hogy _komolyabb_ feladatra miért kell kereskedelmi db és miért nem jó, miben marad el pl egy postgre?? lehet hosszan is válaszolni!
1. Támogatás
2. SQL szabványnak megfelelő implementáció
3. Ezt ismerik a fejlesztők
4. Az támogatott az adott környezetben. pl.: van hozzá natív backup szoftver kliens, SAN integrált mentés támogatottsága, mondjuk ha SAP-ot akarsz használni az sem fut mindenen (még)
1. azért fontos mert nem téged vesznek elő, hogy korrupt az adatbázis, áll a rendszer, tessék már megoldani, vagy fizetni az állásidőt.
3. idő pénz kitanulni egy rendszert, ha már van tudás akkor azt használják
4. kész megoldás esetén nem kell hegeszteni (annyit :) )
Egyébként a PostgreSQL 8.x új szolgáltatásait figyelve nagyon szépen fejlesztik.
MySQL-hez nincs támogatás (mert GPL licenszű) kiv, ha fizetsz érte
SQL'92 - no comment. A PostgreSQL sokkal közelebb van hozzá, a MySQL 5 már kezd arrafele mászkáni
Pár kiegészítés: a Postgresql-hez is tudsz venni kereskedelmi támogatást, plusz szolgáltatásokat, modulokat.
Magyarországon? Hol? A postgresql.org oldalán nem találtam magyar bejegyzést.
Mert nem a .org-on kell keresni :) Van több cég is, akik hivatlosan árulják a postgrest, pl. a CommandPrompt. Mondjuk velük lehet kötni háttérszerződést illetve backend supportra.
Egyébként mintha először nem kötötted volna ki, hogy csak Mo-n lehet a backend support :)
Azt meg mindannyian tudjuk, hogy legtöbb cég termékénél itthon is csak forwardolják a bonyolult support kérdéseket, tisztelet a kivételnek, azért abból is van jó pár. De be kell látni, hogy világszinten több probéma van, a közös tapasztalat ezért nagyobb.
[quote:6525e97b22="szekelyk"]
Google sem segített.
Nagy cégek nem a telefonkönyvből választanak informatikai bt.-t beszállítónak. Olyan alkalmazások kellenek PSQL-re (vagy x-re) amit ezek a nagyok használnak. Aztán már jöhetnek a bt.-k a specialistákkal, akik támogatnak, fejlesztenek. De elterjeszteni nem ők fogják. Túl kicsik, nincs súlyuk, ilyen téren.
Ha jól értem, akkor Te az olyan alkalmazásokat hiányolod, mint az SAP Postgresql alapon Oracle helyett vagy ha nem is ekkorát, akkor is valamilyen "fajsúlyosabbat".
Akkor kissé férreértetted. A következő áll az oldalon:
MySQL AB offers MaxDB under the MySQL AB "dual licensing" model. The complete MaxDB offering is provided free of charge under the Free Software/Open Source GNU General Public License (GPL) and also a commercial license with no open source restrictions.
Mit jelent ez? Egyrészt lehetőséged van a terméket GPL licensz alatt használni. Mit jelent ez? Letöltheted és használhatod. De ha fejlesztesz valami, amibe befordítod pl a kliensét, vagy ha fölteszed a terméked CD-jére, akkor a termékedet is GPL alatt ki kell adnod.
Ez egyrészt jó a felhasználónak, de rossz annak a fejlesztőnek, aki fizetős progit akar eladni és nem GPL alá fejleszteni. Ezért lehetőség van üzleti licenset venned, ezesetben mentesülsz a GPL kötelmei alól, azaz eladhatod a progidat zárt kóddal.
Tényleg. A GPL alatti kereskedelmi termék forgalmazást nem vettem számításba (nem véletlenül).
Egyébként van egy un. Free/Libre and Open Source Software kivétel is, ami azt mondja, hogy a GPL-el nem kompatibils de free és opensource alkalmazásokra is ingyenes a mysql. Szóval nincsen a fejlesztő beszorítva a GPL korlátai közé. :)
[quote:3675ad8e98="suti"]
idézet mysql doksiból : "Starting from MySQL 3.23.44, InnoDB features foreign key constraints." ami annyit jelent, hogy a mysql adatbázisban az innodb típusú tábla már a 3.23.44-es verziótól kezdve támogatja a külsőkulcs kényszerítést. ez a verzió pedig 2001. október 31-én jött ki.
továbbá az innodb táblatípust főleg arra találták ki, hogy tranzakciókat is tudjon kezelni, ez pedig már elég régóta része alapból a mysql-nek!
Csak egy dologra mutatnék rá:InnoDB megállpodás alapján van benne ugye, nem konzisztensen fejlesztik a MySQL-lel, amit a hírekben láttam. A postgresql egy és oszthatatlan. Kb annyi a különbség a, mintha a Linux-ban egy filerendszer már része a kernelnek, a másik pedig nem. Arról nem beszélve, hogy mire is lehet használni: nem használhatod saját termék fejlesztéséhez ingyen. Ami persze nem feltétlenül baj, ha pénzt csináltál a munkájukból vissza is adhatsz valamit igazán.
Azért idéznék a roadmap-ből:
Add some missing FOREIGN KEY functionality to InnoDB. For example, columnname typename FOREIGN KEY REFERENCES tablename(columnname).
Azért az sem teljes, ahogyan látom :)
[quote:3675ad8e98="suti"]
továbbá csak halkan jegyzem meg, hogy valamiért pont most az oracle vette meg az innobase -t ;) (az innodb táblatípus "gyártóját")
erre most mondhatnám, hogy azért, mert a kisvállalati szegmensbe is be akar törni. De mondhatnám, hogy az SAP azért adta oda "kincsét" a MaxDB-t a MySQL-nek, mert a MySQL-nél sokkal jobb fejlesztők vannak :)
IMHO inkább profilbővítés, ak isebb cégek felé történő nyitás miatt vette meg az Oracle az InnoDB-t, mert lehet, hogy vannak olyan eljárások kódok a szoftverben amihez neki USA-ban van szabadalma és itt is gyorsan levédette. De gyanakodhatnék arra is, hogy csak kontrollálni akarja a MySQL-t. Valszeg mindegyik hozzátesz valamit az igazsághoz.
Azt hiszem le lehet zárni, hogy mindenki más miatt szereti a postgrest vagy a mysql-t. A NASA-s adatbázis az egy dolog. LEhet, hogy feltöltötték egyszer, aztán meg mindig csak beszúrnak naponta egy adatot esetleg objektumokat stb. A mérete nem minden egy adatbázisnak. A mérettel mit akarsz kezdeni, imho ez a lényeg. Pl állandó lekérdezés, eredmény visszaírás eléggé szét tudja szedni a gépet.
Egyébként a postgresql-t úgy kezdték alapból fejleszteni, hogy az Oraclet vették alapul. Röviden ennyi :) Utóbbi Oracle hívőknek szólt :)
[quote:2de44beb02="tolmi"]
Elég agresszív véleményt alkottam ide rólad, kedves Frimen. De tudod mit? Nem érsz meg annyit, hogy kint hagyjam. De baromi jól mulattam rajtad. Szánalmas.hu színvonal...
Semmi baj.
Speciel én csak viccnek szántam.. a nem lehet kihagyni kategoriába tartozott.:)
Máskor, mikor átmész agresszivbe, nézd meg a másikat, hogy van-e rajta sapka!:)
Fri
[quote:b681b7a7b5="szekelyk"][quote:b681b7a7b5="noss"]egy _picit_ tudományosabban elmondanátok, hogy _komolyabb_ feladatra miért kell kereskedelmi db és miért nem jó, miben marad el pl egy postgre?? lehet hosszan is válaszolni!
1. Támogatás
2. SQL szabványnak megfelelő implementáció
3. Ezt ismerik a fejlesztők
4. Az támogatott az adott környezetben. pl.: van hozzá natív backup szoftver kliens, SAN integrált mentés támogatottsága, mondjuk ha SAP-ot akarsz használni az sem fut mindenen (még)
1. azért fontos mert nem téged vesznek elő, hogy korrupt az adatbázis, áll a rendszer, tessék már megoldani, vagy fizetni az állásidőt.
3. idő pénz kitanulni egy rendszert, ha már van tudás akkor azt használják
4. kész megoldás esetén nem kell hegeszteni (annyit :) )
Egyébként a PostgreSQL 8.x új szolgáltatásait figyelve nagyon szépen fejlesztik.
Pár kiegészítés: a Postgresql-hez is tudsz venni kereskedelmi támogatást, plusz szolgáltatásokat, modulokat. Ha szállítasz rendszert, akkor tudsz mutogatni a gyártóra, de a rendszert akkor is Te választottad, végső soron a Te seggedet rúgják szét.
A MySQL-hez ragaszkodók tényleg sokszor mondják még mindig, hogy "ez csak postgreses hülyeség". Talán nézzük meg, ha ragaszkodunk az ACIDhoz, akkor mire is képes a MySQL. A MySQL5-ben jelent csak meg, most a tárolt eljárás, a trigger, a _rendesen_ működő constraint és foreign key támogatás - volt benne constraint persze, mondjuk a check null :) és hasonló komoly featureok. Szóval rendesen nem volt implementálva vállalati felhasználásra mondjuk egy ügyviteli rendszerhez. Ugyanakkor nagyon jó volt portálmotorhoz ahol nem volt szükséges egy ROLLBACK, ha mondjuk mégsem sikerült volna a teljes tranzkció, azaz nem volt rendes tranzakció kezelés. Folytassam? Másra jó. Sok mindenre még mindig használhatóbb a postgresql.
[quote:c073db9e69="whitehorze"]Szerintem alapvető probléma, hogy nincs ponotsan definiálva hogy miről is kell szavazni.
dehogynem. kedvenc. amit szeretsz.
Mit fog jelenteni a végeredmény? Kinek a kedvence? Programozóé, vagy neadj isten a dba-é?
az átlagét.
Kisbolt árukészletét, vagy egy banki rendszert kell elvinnie?
ez nem volt kérdés.
Mekkora adatot kezelsz vele?
Case Studies: Los Alamos National Labs Relies on MySQL to Scale with 7 Terabytes of Data
http://www.mysql.com/it-resources/case-studies/mysql-losalamos-casestudy.pdf
csak példának. engem meggyőzött.
csináld meg ezt egy banki rendszerrel. Oracle nem is tud menet közben backupolni!!!
már leírták néhányan. láttál-e már oracle-t?
Oracle pl. rettenetesen igényli hogy karbantartsák, és még így is rengeteg gond van vele.
általánosítások. adminolok egy ~100GB adatbázist. tele bináris adatokkal. semmi gondom nincs vele. (BTW, a fejlesztők meg szívnak a BDE-vel, de ez az ő bajuk.)
Rengeteg szempont van, ez a szavazás pedig csak egy valamivel foglalkozik: "Neked melyik szimpi?"
na végre, rájöttél.
Az itt szavazók 99% százaléka szerintem laikus, de legalábbis soha nem dolgozott mondjuk komolyabb rendszereken. (mondjuk közigazgatási, vagy banki rendszereken)
lehet. és?
ha már itt tartunk: Dolgozok oracle-vel, mysql-lel, ms-sql-lel, access-el is.
attól még lehet a mysql is a kedvencem, az otthoni recept/bor/könyv/cd/akármi kategorizálására pl, nemde?
[quote:f26ae27952="snq-"]
nem, a legjobb az ms sql 2k5, de itt most olyan kereskedelmi/egyeb rendszerek vannak, amik elfutnak unix-szeru rendszereken is
Mindenféle támadási szándék nélkül kérdezem:
Tudsz mondani néhány érvet az MS SQL 2k5 mellett? Amitől, úgy értem, a mezőny fölé magasodhat. Akár ár/érték viszonylatban is. Köszi!
[quote:2dc4efc6fa="dejo"]Régebben egyértelműen a magukat profinak vallók használtak PostgreSQL-t és a MySQL-eseket leamatőrözték.
Hál'Istennek ez kezd felszámolódni. Jónéhány intelligens kollega gyepálása végre beérni látszik és befejeződik ez a világméretű hülyeség, amiről írsz. :)
[quote:2dc4efc6fa="dejo"]
Mostanában, mintha a MySQL is elismertebb lenne. A legyek meg lehet, hogy inteligens lények!
Nem az számít hogy mennyire elismert, hanem hogy mennyire sikeresen teljesíti a közönség által kitűzött célokat. A MySQL mai sikere azért elég nagy mértékben támaszkodott a SAP-ra. Szerintem. A PostgreSQL pedig egy kicsit próbál kitörni a konvencionális adatbázisok közül és olyan utakon járni, mint OO-database, vagy nagymennyiségű bináris adat kezelése. Pont amerre az Oracle is veszi mostanában az irányt. Ráadásul most, hogy a Sun kereskedelmi termékként fogja támogatni Sol10-zel, én nem hinném hogy nem lesz kiélezett verseny a MySQL és a PostgreSQl között:) De a versennyel mi, felhasználók csak nyerhetünk. :)
[quote:2dc4efc6fa="dejo"]
Ja igen és akkor jönnek még a meg nem alkuvók, akik csak "márkás" cuccal dolgoznak, még akkor is, ha a feleség receptgyűjteményét kell tárolni, mert fő a biztonság! (Ez utóbbi erősen túlzás akart lenni, de a lényegre kellőképpen rávilágít.)
A bigottság drága hep. :) De mi egész jól keresünk rajta :P
Mellesleg hogyha nagyon sok recepted(100milliárd körül :) ) van és szeretnél irtógyorsan sokadrangú metainformációkat kiszelektálni a tudásbázisodból, akkor már nélkülözhetetlen lesz egy kereskedelmi termék. :D
Vagy pontazhogy nem bankos. Eddigi leírása alapján nem nagyon volt még közel komoly banki rendszerekhez, vagy nem engedték neki hogy eltérjen az előírástól amit egy programozó írt azon okból hogy le tudja fedezni a hátsóját...
Amúgy meg bírom azokat a nagyképű dumákat, hogy így komoly a banki rendszer, meg "bezzek a BANKI renszerek", nos ezt addig el is hittem én is, amíg bele nem csöppentem. Hát olyan példák vannak, hogy minősítő szoftvare VB alapokon (OTP), vagy nemzetközi banki átutalás Tuxedo, pgsql, LDAP, PKI, JBOSS meg egy csomó más alkalmazás egybegyúrásával (SWIFT rendszer), úgy hogy bizony néha egyes elemek elröppenek, vagy mondhatom a jó öreg MIDAS-t (igaz az AEB most állt át Symobls-ra, de mint a torkosborz...), ami még lockolást sem ismer, vagy még pár helyen futnak file alapú adatbázisnak csúfolt rendszerek (OTP, Budapest bank IBS-ei), melyek egy sima stornót nem engedélyeznek stb.stb. Naponta látom a rendszerünk működésében hogy: "Exception occured no XXXX, Transaction upload successfull" amit úgy oldottak meg, hogy beraktak egy if elágazást, hogy elrejtse a problémát. :D Nagy humbug az egész.
Két apró megjegyzés.
[quote:89b903e9ad="dejo"]Nem vagyok SQL használó, de kacérkodom vele, mert szükségem lesz rá.
Azért jó ideje figyelem a MySQL kontra PostgreSQL vitát. Régebben egyértelműen a magukat profinak vallók használtak PostgreSQL-t és a MySQL-eseket leamatőrözték. Talán te is ebben az állapotban vagy?
Mostanában, mintha a MySQL is elismertebb lenne. A legyek meg lehet, hogy inteligens lények!
Másik témában már volt erre vonatkozólag kiemelés: nem a legjobb, vagy legjobbnak tartott foobart kérdezte Trey, hanem a kedvencet. Tisztában vagyok vele, hogy az általam használt célra _nem_ a MySQL a legjobb, mégis azt jelöltem be: a legtöbb disztróban még mindig sokkal egyszerűbb telepíteni, mint egy Oracle-t.
[quote:89b903e9ad="dejo"]Ja igen és akkor jönnek még a meg nem alkuvók, akik csak "márkás" cuccal dolgoznak, még akkor is, ha a feleség receptgyűjteményét kell tárolni, mert fő a biztonság! (Ez utóbbi erősen túlzás akart lenni, de a lényegre kellőképpen rávilágít.)
Ajánlom szíves figyelmedbe az Oracle (fejlesztési/saját célra, nem tudom pontosan) ingyen elérhető változatát, ami állítólag nem sokban különbözik a "fizetős" változattól.
Csak hogy ugyanarról beszéljünk. A snapshot alatt azt értem, amikor befagyasztasz egy állapotot az adatbázisban. Utána mondjuk csinálsz egy nagyobb változtatást, kitörölsz táblákat, beszúrsz másik táblákba pár millió sort, másikakat megváltoztatsz. Két nap mulva úgydöntesz, hogy vissza az egész... Ez MaxDB alatt pár másodperc. Semmi restore, vagy file csiki-csuki. Egy recover snapshot...
Meglehetősen. A snapshot-ban egészen. A normál mentésnél is. Max az RMAN-al lehet valamit bűvészkedni. De a normál oracle online mentés bizony csak "recover database" -el lesz konzisztens. Ebben akár fogadhatunk is :D
Akkor már csak egy kérdésem volna, melyik verziónál?
Meglehetősen. A snapshot-ban egészen. A normál mentésnél is. Max az RMAN-al lehet valamit bűvészkedni. De a normál oracle online mentés bizony csak "recover database" -el lesz konzisztens. Ebben akár fogadhatunk is :D
Akkor már csak egy kérdésem volna, melyik verziónál?
Meglehetősen. A snapshot-ban egészen. A normál mentésnél is. Max az RMAN-al lehet valamit bűvészkedni. De a normál oracle online mentés bizony csak "recover database" -el lesz konzisztens. Ebben akár fogadhatunk is :D
Akkor már csak egy kérdésem volna, melyik verziónál?
Melyik verziónál igen?
9.2 és felette ott van az exp-ben a consistent=Y/N, yól le is fogja a mentést, mert mindig behoza a lemaradást, de a snpashot úgy ahogy te gondolod nem működik, esetleg valami SCN trükközéssel, vagy RMAN tökörészéssel, de ezt én sem szeretném kipróbálni éles rendszeren.
Meglehetősen. A snapshot-ban egészen. A normál mentésnél is. Max az RMAN-al lehet valamit bűvészkedni. De a normál oracle online mentés bizony csak "recover database" -el lesz konzisztens. Ebben akár fogadhatunk is :D
Akkor már csak egy kérdésem volna, melyik verziónál?
Melyik verziónál igen?
9.2 és felette ott van az exp-ben a consistent=Y/N, yól le is fogja a mentést, mert mindig behoza a lemaradást, de a snpashot úgy ahogy te gondolod nem működik, esetleg valami SCN trükközéssel, vagy RMAN tökörészéssel, de ezt én sem szeretném kipróbálni éles rendszeren.
1, Úgyhiszem mentésről és nem exportról beszéltünk. Próbáltál már egy több TB-s rendszert exportálni??? Nalátod.
2, SCN-el sem lehet....
3, Én már próbáltam az RMAN-t. Az is mentő rendszer. Az adatok elhelyezésének logikája miatt nem tudod ezt a snapshotot oracle alatt megcsinálni. Ez a logika másra jóbb. Erre nem.
Összefoglalva. Ne essünk át a ló túloldalára. Az Oracle jobb adatbáziskezelő mint a MaxDB. De amivel jobb, az valahol a TB-s tartományban és egészen speciális területeken jelentkezik. PL a RAC egyedülálló és nagyon jó dolog. De az oracle adatbázisokat használó felhasználók 95%-a simán elfutkosna MaxDB-vel, úgy, hogy néha még kényelmesebb is lenne.
9.2 és felette ott van az exp-ben a consistent=Y/N, yól le is fogja a mentést, mert mindig behoza a lemaradást, de a snpashot úgy ahogy te gondolod nem működik, esetleg valami SCN trükközéssel, vagy RMAN tökörészéssel, de ezt én sem szeretném kipróbálni éles rendszeren.
MaxDB alatt viszont működik. Annyira, hogy egy ügyfél, tanulatlan alkalmazott jóvoltából, aki rákattint minden gombra, amit nem ismer éppen két hét fejlesztés veszett el.... :lol:
1, Úgyhiszem mentésről és nem exportról beszéltünk. Próbáltál már egy több TB-s rendszert exportálni??? Nalátod.
2, SCN-el sem lehet....
3, Én már próbáltam az RMAN-t. Az is mentő rendszer. Az adatok elhelyezésének logikája miatt nem tudod ezt a snapshotot oracle alatt megcsinálni. Ez a logika másra jóbb. Erre nem.
Összefoglalva. Ne essünk át a ló túloldalára. Az Oracle jobb adatbáziskezelő mint a MaxDB. De amivel jobb, az valahol a TB-s tartományban és egészen speciális területeken jelentkezik. PL a RAC egyedülálló és nagyon jó dolog. De az oracle adatbázisokat használó felhasználók 95%-a simán elfutkosna MaxDB-vel, úgy, hogy néha még kényelmesebb is lenne.
1. Ácsi, azt állítottad nincs benne, mármint az Oracle-ben most akkor ne térj el a tárgytól. Benne van, és az hogy mentesz vagy exportálsz adatok szempontjából tökmindegy, mindkettő visszaállít egy (konzisztens/nem konzisztens) állapotot, a többi kérdés technikai és management kérdés. Amúgy ami nekem max full export Oracle-el volt az egy 500GB, de 1 óra 12 perc alatt megvolt.
2. erről valamikor olvastam valamit, állítólag lehet, csak hivatalosan nem támogatott persze.
3. RMAN-al vissza lehet pörgetni állapotot, bár kell neki egy off-line recovery.
Amit a végén írsz egy nagyon erős flame, ugyanis az átlag 95% felhasználó/programozó egy sqlite/mysql 3.23-al is tökéletesen el lenne, nem beszélve hogy jóval kezelhetőbb és átláthatóbbak a számukra. Ezután jönnek a különleges igények, melyek figyelembe vételével kell a db technológiát kiválasztani, ami lehet pgsql, oracle, db2 sőt MaxDB is ;)
[quote:0da8252ed5="zeller"]
Az Oracle igényli, vagy az alkalmazások a karbantartást/masszázst? Elég naaaaaaaagy Oracle adatbázisokhoz is volt szerencsém, amikbe garantáltan belerokkant volna fejlesztő is, dba is, felhasználó is, ha Postgres, mySQL, vagy hasonló szoftver kezelte volna azokat az adatokat...
Miért rokkantak volna bele? A karbantartás nehézsége miatt?
9.2 és felette ott van az exp-ben a consistent=Y/N, yól le is fogja a mentést, mert mindig behoza a lemaradást, de a snpashot úgy ahogy te gondolod nem működik, esetleg valami SCN trükközéssel, vagy RMAN tökörészéssel, de ezt én sem szeretném kipróbálni éles rendszeren.
MaxDB alatt viszont működik. Annyira, hogy egy ügyfél, tanulatlan alkalmazott jóvoltából, aki rákattint minden gombra, amit nem ismer éppen két hét fejlesztés veszett el.... :lol:
Hm viszont ez a verzió kezelés szerűsége érdekel, kimondottan felkeltetted az érdeklődésemet a MaxDB felé. :D :lol:
Én csak programozó szemszögből tudok beleszólni: nekem jávából teljesen mindegy, hogy mibe túrok bele. Amivel dolgoznom kell, az oracle meg mssql 2000. Namost szemléletileg nem szeretem az ms termékeket, ez ilyen dili, ez van :) Az oracle-ben meg az nem tetszik, hogy telepítettem már párat. Az még hagyján, de amíg a szükséges patch-ek felmennek, az nekem kínszenvedés :)
Otthonra csináltam tesztkörnyezetet, mysql-el szívtam egy csomót, ilyen-olyan jogosultságokat hogy állítsak be, leginkább ezzel. Aztán felraktam postgre-t, ott minden pikk-pakk működött.
De ez nem olyan komoly cucc, végül is csak napi pár Gb txt-ből kell pakolni adatbázisba :) Nem hinném, hogy ne lehetne ezt bármelyik rendszerrel megoldani.
MaxDB-ben van flashback? De ne menjünk ennyire bele... Az Oracle esetén is megvannak azok az eszközök, amelyek az adatbázis _egy részének (táblatér, de van ilyenje sémára is...)_ teljes és online mentését/visszaállítását támogatják, csak használni köll tudni azokat. Egy recovery esetén meg gyakorlatilag mindegy, hogy 23 vagy 98 fájlt kell visszatölteni, max a kazettacserélő technikus fog anyázni esteleg... Ha meg jó SAN-od van az adatbázis alatt, akkor a táblaterenkénti onlány backup idejét -a storage megfelelő funkciójával- naggyon minimálisra le lehet szorítani, és az itt repkedő sokszáz GB-TB méretű adatbázisok esetén a SAN elég gyakori vendég...ű
[quote:2c95521368="mrbond"]én is a postgreSQLre szavaztam, mert:
bár az orákulum az jó, de ha licenszeled akkor k. drága.
és szvsz nem csak a mysql / postgresqlhez képest.
Nálunk drága, tegyük hozzá. Ahol a fejlesztői ill. üzemeltetői mukaidő drága, azaz egy-egy feladatra mondjuk harmad/negyed annyi időt lehet szánni, mint itt, ott általában megtérül a magasabb licenszdíj a megtakarított mukaerő (fejlesztő és dba) árából.
Az Oracle licenszben azért elég sok "egyéb" cucc is bennefoglaltatik, nem csak egy sima sql+ és a mögötte lévő rdbms, ha mindezt össze akarod rakni (pl. Apache-PHP-MySQL), és megfelelő fejlesztés- és üzemeltetéstámogató eszközre is szükséged van, nos... akkor szerintem bajban vagy, illetve sok-sok mérnök/fejlesztői órád rá fog menni, és még csak az eszköz van a kezedben, egy alkalmazást sem írtál meg -- ha meg nekiálsz fejleszteni, akkor szintén beleütközöl az eszközhiányba.
Fejlesztőként gyakorlatilag semmiben sem kerül többe, ha Oracle vagy ha Postgres alá fejleszt az ember, eszközökben viszont egyértelmű az Oracle előnye.
Akit érdekel, jövőre miért lehet a Firebird a kedvence, az amúgy egyszerű kezelhetőségével, puritánságával, az kukkantson ide.
[:6b4154cd4a]Asynchronous statement cancellation / timeouts
Monitoring via API and/or special tables
Detailed SQL tracing/profiling
Detailed logging/audit
DDL level and global triggers
PSQL debugging extensions/hooks
Reliable logical backup Point-in-time recovery
Embedded users / SQL users management
User permissions for metadata
Pluggable authentication modules
Security groups
Database encryption
Faster outer joins
Optimizer improvements
More effective sorting
Optimized network protocol
More access paths
Temporary tables / transient datasets
More built-in functions
Schemas/namespaces
Native long numeric data type
Recursive queries
Regular expressions
TEXT BLOB compatible with [VAR]CHAR
Domains everywhere
Longer metadata names
Deferred constraints
SMP support in SS
Compiled statements cache
External functions/procedures
External data sources / database links / cross-database SQL
Statement/transaction consistency
Bi-directional indices
Bulk load/import
Referential integrity without indices
Full-text search Clustering
Bi-directional cursors
XML integration
[/:u:6b4154cd4a][/b][/]
Az Oracle a végletekig konfigurálható, mindenfélét állíthatsz rajta. Ezért kell hozzáértő ember a beállításhoz, mert amennyit javítani lehet, annál többet tudsz rontani a teljesítményen. Az új verziókban (9 és 10) egyre több automatizmust, DBA munkát segítő szolgáltatást pakoltak bele.
A 10-ben akár már működnek is.
[quote:fb7e381194="LeoALo"][quote:fb7e381194="saabi"][quote:fb7e381194="LeoALo"]Ez így ebben a formában igaz. Nem is állítottam az ellenkezőjét. Ellenben jártam már olyan ügyfélnél, ahol két hetes volt a legújabb online mentés és egy kicsinke archivelog file-ocska sérülten lett kimentve...
Néha jól jöhet, ha a mentés önmagában logok nélkül konzisztens.
Hát, ez a fránya Oracle is olyan, hogy érteni kell hozzá. Ha az adatbázis visszaállíthatóságának az archive log az egyik kulcspontja, akkor azt talán rendszeresen kellene menteni, nem?
Ave, Saabi.
Egy vita végéhez szóltál hozzá. Az egész úgy kezdődött, hogy nem átallottam azt állítani, hogy mindamellett, hogy szeretem az Oracle-t és az egyik legjobb adatbáziskezelőnek tartom, mégiscsak vannak olyan funkciók, amik egy "ingyenes" (GPL...tudom nem ingyen, de most nem is ez a téma) adatbáziskezelőben megvannak de a drága Oracle-ben nem.
Erre volt egy példa a konzisztens online mentés, az adatbázis szintű snapshot stb...
Ha a konzisztens online mentés számodra azt jelenti, hogy adott pillanatban commit-tal lezárt tranzakciókat tartalmazó állapot lementése egy fájlba (és ezt az időpontot te tudod meghatározni), akkor igazad lehet (bár attól, hogy én nem tudok ilyenről, az Oracle lehet, hogy tudja...).
Ha a meghatározott t_null időpontra történő visszaállást lehetővé tévő mentésre gondolsz, akkor viszont nem kérdés, hogy van, sőt ennél messzebre is mentek Oracle-ék (flashback...)
Oracle esetén a mentésnek _része_ a log, tehát ha a log sérül a mentésed sérül. Más rdbms-nél is, ha sérül az adott snapshot-ot tartalmazó fájl(készlet), akkor szintén kenheted a hajadra...
[quote:dc131e26c4="mocsi"][quote:dc131e26c4="noss"]egy _picit_ tudományosabban elmondanátok, hogy _komolyabb_ feladatra miért kell kereskedelmi db és miért nem jó, miben marad el pl egy postgre?? lehet hosszan is válaszolni!
Csak a főbb előnyök:
1. Véded s@gged, hogy adnak hozzá szápportot
2. Ha gondod van, akkor rájuk hárítod, hogy nézzenek utána
3. Más termék gyártónál tudod verni a melled, hogy erre alapozzon, mert ez, papírra alapozva, ki van tesztelve.
csak csendben megjegyeznem,hogy a postgrest meg is lehet venni,es a postgresql inc ad hozza supportot is.
<szerk> oops. bocsi csak most latom ezt mar ellottek elottem </szerk>
Vagy pontazhogy nem bankos. Eddigi leírása alapján nem nagyon volt még közel komoly banki rendszerekhez, vagy nem engedték neki hogy eltérjen az előírástól amit egy programozó írt azon okból hogy le tudja fedezni a hátsóját...
Amúgy meg bírom azokat a nagyképű dumákat, hogy így komoly a banki rendszer, meg "bezzek a BANKI renszerek", nos ezt addig el is hittem én is, amíg bele nem csöppentem. Hát olyan példák vannak, hogy minősítő szoftvare VB alapokon (OTP), vagy nemzetközi banki átutalás Tuxedo, pgsql, LDAP, PKI, JBOSS meg egy csomó más alkalmazás egybegyúrásával (SWIFT rendszer), úgy hogy bizony néha egyes elemek elröppenek, vagy mondhatom a jó öreg MIDAS-t (igaz az AEB most állt át Symobls-ra, de mint a torkosborz...), ami még lockolást sem ismer, vagy még pár helyen futnak file alapú adatbázisnak csúfolt rendszerek (OTP, Budapest bank IBS-ei), melyek egy sima stornót nem engedélyeznek stb.stb. Naponta látom a rendszerünk működésében hogy: "Exception occured no XXXX, Transaction upload successfull" amit úgy oldottak meg, hogy beraktak egy if elágazást, hogy elrejtse a problémát. :D Nagy humbug az egész.
hadd ne mondjam a bankmaster/branchpower kliensoldalan meg a btrieve altal nyujtott tranzakciokezelesi kepessegeket sem aknazzak ki.
[quote:2ac3a8e893="zeller"]MaxDB-ben van flashback? De ne menjünk ennyire bele... Az Oracle esetén is megvannak azok az eszközök, amelyek az adatbázis _egy részének (táblatér, de van ilyenje sémára is...)_ teljes és online mentését/visszaállítását támogatják, csak használni köll tudni azokat. Egy recovery esetén meg gyakorlatilag mindegy, hogy 23 vagy 98 fájlt kell visszatölteni, max a kazettacserélő technikus fog anyázni esteleg... Ha meg jó SAN-od van az adatbázis alatt, akkor a táblaterenkénti onlány backup idejét -a storage megfelelő funkciójával- naggyon minimálisra le lehet szorítani, és az itt repkedő sokszáz GB-TB méretű adatbázisok esetén a SAN elég gyakori vendég...ű
Ez így ebben a formában igaz. Nem is állítottam az ellenkezőjét. Ellenben jártam már olyan ügyfélnél, ahol két hetes volt a legújabb online mentés és egy kicsinke archivelog file-ocska sérülten lett kimentve...
Néha jól jöhet, ha a mentés önmagában logok nélkül konzisztens.
csak csendben megjegyeznem,hogy a postgrest meg is lehet venni,es a postgresql inc ad hozza supportot is.
<szerk> oops. bocsi csak most latom ezt mar ellottek elottem </szerk>
1. Ácsi, azt állítottad nincs benne, mármint az Oracle-ben most akkor ne térj el a tárgytól. Benne van, és az hogy mentesz vagy exportálsz adatok szempontjából tökmindegy, mindkettő visszaállít egy (konzisztens/nem konzisztens) állapotot, a többi kérdés technikai és management kérdés. Amúgy ami nekem max full export Oracle-el volt az egy 500GB, de 1 óra 12 perc alatt megvolt.
2. erről valamikor olvastam valamit, állítólag lehet, csak hivatalosan nem támogatott persze.
3. RMAN-al vissza lehet pörgetni állapotot, bár kell neki egy off-line recovery.
Amit a végén írsz egy nagyon erős flame, ugyanis az átlag 95% felhasználó/programozó egy sqlite/mysql 3.23-al is tökéletesen el lenne, nem beszélve hogy jóval kezelhetőbb és átláthatóbbak a számukra. Ezután jönnek a különleges igények, melyek figyelembe vételével kell a db technológiát kiválasztani, ami lehet pgsql, oracle, db2 sőt MaxDB is ;)
1., Mit állítottam? Hogy nem csinál konziszetns online mentést. Mit jelent ez? Hogy tudsz menteni, tudsz online menteni, csak kell hozzá a mentés kezdete és vége között készült összes logfile. A recovery végén a mentés végének állapota visszaállíthato. Ugyanez a MaxDB-nél úgy megy, hogy a mentés kezdetének pillanatában meglévő konzisztens állapotot tudod az online mentésből visszaállítani mineden log nélkül. Ki beszélt itt exportról? Az export nem mentés!!!! ( nem is egyenértékű. Érdekelne pl, hogyan "mentesz" le egy SAP adatbázist online konzisztensen exp-el figyelembe véve a maga kb 40000 adatbázisobjektumát.)
2. én nem, szerintem nem tudjuk eldönteni. Ha bebizonyítod hogy lehet készséggel elfogadom.
3. Igen, RMAN-al lehet, de ez nem más, mint egy recovery. Egyanúgy sokáig tart mint a sima visszatöltés.
Az erős flame-hez csak az a hozzátennivalóm, hogy kicsit talán pontosítanom kell. Én az SAP világot ismerem részletesebben. Itt meg nincs MySQL, meg Postgres. Itt Oracle, DB2, Informix, SQL Server és MaxDB van. Ezek közül a MaxDB az egyetlen GPL-es. És az SAP installációk 95%-ára értettem a mondanivalómat.
Hozzászólások
[quote:973920f6c2="LeoALo"][quote:973920f6c2="zeller"]MaxDB-ben van flashback? De ne menjünk ennyire bele... Az Oracle esetén is megvannak azok az eszközök, amelyek az adatbázis _egy részének (táblatér, de van ilyenje sémára is...)_ teljes és online mentését/visszaállítását támogatják, csak használni köll tudni azokat. Egy recovery esetén meg gyakorlatilag mindegy, hogy 23 vagy 98 fájlt kell visszatölteni, max a kazettacserélő technikus fog anyázni esteleg... Ha meg jó SAN-od van az adatbázis alatt, akkor a táblaterenkénti onlány backup idejét -a storage megfelelő funkciójával- naggyon minimálisra le lehet szorítani, és az itt repkedő sokszáz GB-TB méretű adatbázisok esetén a SAN elég gyakori vendég...ű
Ez így ebben a formában igaz. Nem is állítottam az ellenkezőjét. Ellenben jártam már olyan ügyfélnél, ahol két hetes volt a legújabb online mentés és egy kicsinke archivelog file-ocska sérülten lett kimentve...
Néha jól jöhet, ha a mentés önmagában logok nélkül konzisztens.
Ebben igazad van. Az archive logokat is illik csekkolni (jó, el lehet menni odáig, hogy a fájlt kitolom kazira, utána visszaolvastatom és betolom egy standby-adatbázisba...), illetve sokhelyütt ezért marad a diszken az archivelog, etc. A vázolt esetben hivatalos látogatásra megérkezett Szopkovics elvtárs... A mentési/visszaállítási folyamatot én mindenképp átnézném, és az onlány backup-ok közötti időszakokat rövidebbre venném (havi coldbackup-pal spékelve!) plusz az archivelogok kezelésénél sem bíznék meg vakon a mentőeszközben, azaz legalább két plédányt (diszk plusz szalag) őriznék meg belőle...
[quote:82bc648247="LeoALo"]
1., Mit állítottam? Hogy nem csinál konziszetns online mentést. Mit jelent ez? Hogy tudsz menteni, tudsz online menteni, csak kell hozzá a mentés kezdete és vége között készült összes logfile. A recovery végén a mentés végének állapota visszaállíthato. Ugyanez a MaxDB-nél úgy megy, hogy a mentés kezdetének pillanatában meglévő konzisztens állapotot tudod az online mentésből visszaállítani mineden log nélkül. Ki beszélt itt exportról? Az export nem mentés!!!! ( nem is egyenértékű. Érdekelne pl, hogyan "mentesz" le egy SAP adatbázist online konzisztensen exp-el figyelembe véve a maga kb 40000 adatbázisobjektumát.)
2. én nem, szerintem nem tudjuk eldönteni. Ha bebizonyítod hogy lehet készséggel elfogadom.
3. Igen, RMAN-al lehet, de ez nem más, mint egy recovery. Egyanúgy sokáig tart mint a sima visszatöltés.
1. Mi az hogy az export nem mentés? akkor hogyhogy mindig vissza lehetett állítani a rendszert akár egy üres adatbázisba (bevallhatjuk, hogy nem mindig egyszerűen csak egy imp oszt csók, tökölni kell vele) Szerinted mégis mire szolgál a full export?
2. Nem akarom, mert mint irtam én sem vagyok benne biztos. Megpróbálom kikeresni a leírást.
3. Megint részletek, van vagy nincs?
true, true.
[quote:5fe10a6b27="mocsi"]1. Mi az hogy az export nem mentés? akkor hogyhogy mindig vissza lehetett állítani a rendszert akár egy üres adatbázisba (bevallhatjuk, hogy nem mindig egyszerűen csak egy imp oszt csók, tökölni kell vele) Szerinted mégis mire szolgál a full export?
egy tetszoleges pillanatban torteno export max mesebeli szerencsevel ad neked konzisztens adatmentest
[quote:286db5ca1f="snq-"][quote:286db5ca1f="mocsi"]1. Mi az hogy az export nem mentés? akkor hogyhogy mindig vissza lehetett állítani a rendszert akár egy üres adatbázisba (bevallhatjuk, hogy nem mindig egyszerűen csak egy imp oszt csók, tökölni kell vele) Szerinted mégis mire szolgál a full export?
egy tetszoleges pillanatban torteno export max mesebeli szerencsevel ad neked konzisztens adatmentest
Akkor az a consistent kapcsoló csak egy marketing fogás.
1a, Van pl 5000 táblád (Pl SAP R3. több is van benne de most mind1). elkezded menet közben exportálni az elsőt. Aztán a másodikat, satubbi. Mire az ötezredikhez érsz biztos, hogy már legalább egy korábban már kiexportált tábla megváltozik. Ergó: Ha nem változott semmi, akkor nem is dolgozott senki. Ha valaki mégis dolgozott, akkor ugyan vissza tudsz tölteni egy üres adatbázisba valamit, de az nem lesz konzisztens.
1b, hogy mentesz egy néhány TB-s rendszert? Export tart kb két hétig.
3, Ez a vita abból indult, hogy valaki megkérdezte mi az, ami nincs Oracle-ben.
Online backup: Oracle : van. MaxDB: van
DBSnapshot: Oracle: nincs, MaxDB: van.
Ennyi. Egy példa.
[quote:3b38d01a80="LeoALo"]
1a, Van pl 5000 táblád (Pl SAP R3. több is van benne de most mind1). elkezded menet közben exportálni az elsőt. Aztán a másodikat, satubbi. Mire az ötezredikhez érsz biztos, hogy már legalább egy korábban már kiexportált tábla megváltozik. Ergó: Ha nem változott semmi, akkor nem is dolgozott senki. Ha valaki mégis dolgozott, akkor ugyan vissza tudsz tölteni egy üres adatbázisba valamit, de az nem lesz konzisztens.
1b, hogy mentesz egy néhány TB-s rendszert? Export tart kb két hétig.
3, Ez a vita abból indult, hogy valaki megkérdezte mi az, ami nincs Oracle-ben.
Online backup: Oracle : van. MaxDB: van
DBSnapshot: Oracle: nincs, MaxDB: van.
Ennyi. Egy példa.
ok.
1. a. erre szolgálnak az általam emlegetett kapcsolók (mindent kimentődik, kivéve a user és táblaterület létrehozási definiciók). Konzisztens marad, mert figyeli a változásokat a mentés alatt és utólag "kiigazítja'. Itt valószínűleg sokkal jobb a MaxDB, mert nagy változásokat is biztonságosan eltárol, míg az Oracle-nál ha kifogy a RBS, akkor lőttek az egész mentésnek (vagy mint a 8.0.6-os Oracle-ben az egész adatbázisnak :D ha a RBS megtelt és nem tudott hova nyújtózkodni)
1.b. A két hét pici túlzás, ha nincs benne nagy mozgás és normális az I/O throughoutput, akkor egy nap alatt meg kell lennie. De itt már eleve más mentési technológiát kell alkalmazni a nagy hely és igénybevétel miatt.
3. DBSnapshot Oracle: kínlódás szintjén lehetséges, MaxDB: praktikusan megvalósítva és működik.
Mielőtt félre értitek, a Postgres-re szavaztam mint kedvenc DB motor. :lol:
[quote:3fc7d34471="whitehorze"]Oracle nem is tud menet közben backupolni!!!
Ezt a mondatot köszönöm neked, megalapozta a mai napom hangulatát. Ilyen jót régen röhögtem.
Ave, Saabi.
ps: feltételezem azért túl sok közöd nincs az Oracle-höz, ugye?
[quote:b007bb4a90="Panther"]MySQL-hez nincs támogatás (mert GPL licenszű) kiv, ha fizetsz érte
Hmm... és mihez _van_ támogatás anélkül hogy fizetnél érte?
Ave, Saabi.
[quote:3355525e6a="mocsi"]
1. Ácsi, azt állítottad nincs benne, mármint az Oracle-ben most akkor ne térj el a tárgytól. Benne van, és az hogy mentesz vagy exportálsz adatok szempontjából tökmindegy, mindkettő visszaállít egy (konzisztens/nem konzisztens) állapotot, a többi kérdés technikai és management kérdés. Amúgy ami nekem max full export Oracle-el volt az egy 500GB, de 1 óra 12 perc alatt megvolt.
Egyaltalan nem mindegy. A visszaallitasnal a meglevo objektumokat hasznalod, mig importnal uj objektumok keletkeznek.
[quote:3355525e6a="mocsi"]
2. erről valamikor olvastam valamit, állítólag lehet, csak hivatalosan nem támogatott persze.
A backup attol online, hogy futas kozben (nem allitod le az adatbazist, nem fagyasztod be a fajlrendszert) lehet konzisztens backup-ot csinalni. Az adatfajlok mentes kozben nyugodtan modosulhatnak, a mentes alatt a *modosult* blokkok keszult logot kell csak ragorgetni.
A snapshot ami elokerult nem mas, mint az adatterulet befagyasztasa es redo log, ami nem backup megoldas.
Lasd MaxDB doksi, Freezing the Data Area (Snapshot):
*A snapshot is not a data backup.* To be able to restore your data after damages in the data area, you have to perform regular data and log backups.
[quote:3355525e6a="mocsi"]
Amit a végén írsz egy nagyon erős flame, ugyanis az átlag 95% felhasználó/programozó egy sqlite/mysql 3.23-al is tökéletesen el lenne, nem beszélve hogy jóval kezelhetőbb és átláthatóbbak a számukra. Ezután jönnek a különleges igények, melyek figyelembe vételével kell a db technológiát kiválasztani, ami lehet pgsql, oracle, db2 sőt MaxDB is ;)
Es az az atlag 95% nem csinal mast, csak a hianyzo adatbazisfunkciokat probalja alkalmazasszinten potolni (=takolni).
Egyebkent mysql-bol is lehet konzisztens exportot kesziteni az innodb backup toolja nelkul. Persze ehhez lockol mindent ...
[quote:d3848c00a5="LeoALo"]Ez így ebben a formában igaz. Nem is állítottam az ellenkezőjét. Ellenben jártam már olyan ügyfélnél, ahol két hetes volt a legújabb online mentés és egy kicsinke archivelog file-ocska sérülten lett kimentve...
Néha jól jöhet, ha a mentés önmagában logok nélkül konzisztens.
Hát, ez a fránya Oracle is olyan, hogy érteni kell hozzá. Ha az adatbázis visszaállíthatóságának az archive log az egyik kulcspontja, akkor azt talán rendszeresen kellene menteni, nem?
Egy ügyfelünknél olyan mentést építettünk ki, ahol naponta éjjel történik meg az adatbázis online mentése és napközben kétszer - bár gondolkoztunk a négy alkalmon is - az archive log-oké.
Egy archive log-ot négyszer mentünk, garantáltan legalább két különböző szalagra, de csak egy hónap elteltével töröljük, így egy esetleges visszaállításnál nem feltétlen kell a szalagokat birizgálni.
Így jó eséllyel elkerülhetjük az archive log vesztést, bár azért a felhasználok és/vagy a fejlesztők olykor megtréfálnak és egy hét alatt megtelítik a logoknak fenntartott 100G-s területet. :-)
Ave, Saabi.
[quote:c097ee8021="noss"]Köszi mindenkinek, aki válaszolt a kérdéseimre!
[quote:c097ee8021="zeller"]
Az Oracle igényli, vagy az alkalmazások a karbantartást/masszázst? Elég naaaaaaaagy Oracle adatbázisokhoz is volt szerencsém, amikbe garantáltan belerokkant volna fejlesztő is, dba is, felhasználó is, ha Postgres, mySQL, vagy hasonló szoftver kezelte volna azokat az adatokat...
Miért rokkantak volna bele? A karbantartás nehézsége miatt?
A fejlesztő a fejlesztőeszközök khm. gyengeségei, a dba a monitorozóeszközök híjján, (tényleg, vannak SpotLight-szerű vackok My/PgSQl-hez?) a felhasználók meg a "kissé mást kissé hosszabb fejlesztési idő alatt kaptam" miatt... Az Oracle már régóta nem csak egy RDBMS a sok közül, hanem igen-igen sok "körítés" is van mellette, ami a MY/PgSQL-lel nem összemérhetővé emeli.
Én kicsit meg vagyok döbbenve.
Ugyan semmi nem áll tőlem távolabb, mint hogy a magam izlését akarjam másokra eröltetni, de azthittem a MaxDB sokkal népszerűbb lesz. Adott egy adatbáziskezelő, amely bizonyos dolgokban és bizonyos feladatokra felülmúlja még az oracle képességeit is, GPL licensz alatt használható, 7*24 órás supportot vehetsz hozzá az SAP-tól és alig ismeri valaki. Mindenki epekedve várja, hogy a MySql végre átugorja a saját árnyékát, megrakja az amúgy szimpatikus kis adatbáziskáját olyan funkciókkal, amik már hasonlítanak a nagyokra, közben meg két füllel odébb van egy termék, ami mindezt profin tudja és senki még rá sem kattint.
Egyszerűen döbbenet.
A MaxDB-t több programozó fejleszti főállásban, mint ahány alkalmazottja a MySQL-nek van főnököstül, kereskedőstül, grafikustol, takarítónénistül, mindenestül szor kettő. Nehogy félreértsen valaki! Nem fikázni akarom a MySQL-t. Csak nem értem miért nem használ szinte senki MaxDB-t.
[quote:4ebe1b14b8="saabi"][quote:4ebe1b14b8="LeoALo"]Ez így ebben a formában igaz. Nem is állítottam az ellenkezőjét. Ellenben jártam már olyan ügyfélnél, ahol két hetes volt a legújabb online mentés és egy kicsinke archivelog file-ocska sérülten lett kimentve...
Néha jól jöhet, ha a mentés önmagában logok nélkül konzisztens.
Hát, ez a fránya Oracle is olyan, hogy érteni kell hozzá. Ha az adatbázis visszaállíthatóságának az archive log az egyik kulcspontja, akkor azt talán rendszeresen kellene menteni, nem?
Ave, Saabi.
Egy vita végéhez szóltál hozzá. Az egész úgy kezdődött, hogy nem átallottam azt állítani, hogy mindamellett, hogy szeretem az Oracle-t és az egyik legjobb adatbáziskezelőnek tartom, mégiscsak vannak olyan funkciók, amik egy "ingyenes" (GPL...tudom nem ingyen, de most nem is ez a téma) adatbáziskezelőben megvannak de a drága Oracle-ben nem.
Erre volt egy példa a konzisztens online mentés, az adatbázis szintű snapshot stb...
Az említett ügyfélnél pedig nem én állítottam be a mentést, nem is kérdeztek meg. Amikor már egy napja ált 2 gyár, akkor hívtak ki minket. És ekkor már mind1 hogy én mit gondolog arról aki ilyen mentést csinál. Egy ilyen (félig sem hozzáértő, de nagyarcú) ügyfélnek jobb választás a MaxDB (még ha ugyanannyit kellene is fizetni érte mint az Oracle-ért) . Ezt állítom. És ez nem von le semmit az Oracle értékéből.
egy _picit_ tudományosabban elmondanátok, hogy _komolyabb_ feladatra miért kell kereskedelmi db és miért nem jó, miben marad el pl egy postgre?? lehet hosszan is válaszolni!
én is a postgreSQLre szavaztam, mert:
bár az orákulum az jó, de ha licenszeled akkor k. drága.
és szvsz nem csak a mysql / postgresqlhez képest.
szerintem a szabad rdbmsek közül magasan a legjobb. és a fejlesztési iránya gyak. megegyezik az orákuluméval.
persze minden szavam szvsz.
[quote:50ce763d19="LeoALo"]Én kicsit meg vagyok döbbenve.
Ugyan semmi nem áll tőlem távolabb, mint hogy a magam izlését akarjam másokra eröltetni, de azthittem a MaxDB sokkal népszerűbb lesz. Adott egy adatbáziskezelő, amely bizonyos dolgokban és bizonyos feladatokra felülmúlja még az oracle képességeit is, GPL licensz alatt használható, 7*24 órás supportot vehetsz hozzá az SAP-tól és alig ismeri valaki. Mindenki epekedve várja, hogy a MySql végre átugorja a saját árnyékát, megrakja az amúgy szimpatikus kis adatbáziskáját olyan funkciókkal, amik már hasonlítanak a nagyokra, közben meg két füllel odébb van egy termék, ami mindezt profin tudja és senki még rá sem kattint.
Egyszerűen döbbenet.
A MaxDB-t több programozó fejleszti főállásban, mint ahány alkalmazottja a MySQL-nek van főnököstül, kereskedőstül, grafikustol, takarítónénistül, mindenestül szor kettő. Nehogy félreértsen valaki! Nem fikázni akarom a MySQL-t. Csak nem értem miért nem használ szinte senki MaxDB-t.
Részemről PostreSQL-t használunk ahol engedik. Általában nem engedik, mert Oracle az isten. Az általad említett MaxDB-vel az a baj, hogy soha nem hallottam róla. Ha pedig elkezdem alternatívákért feltúrni a netet, nem tudok mit kezdeni a több száz "jelentkezővel". És ezen jelentkezők többsége hullaék (elnézést: nem elégíti ki az igényeimet). Ezek közül kiválasztani a MaxDB-t, mely igaziból egy gyöngyszem (mint írod), lehetetlen. A PostgreSQL-nek viszont van 2neve" (értsd: kellő mértékben elterjedt), és mint választás nálunk nagyon bevált.
Hát ezért nem MaxDB.
És még valami. Lehet, hogy semmi köze hozzá, de engem az SAP Hungary 200.000 Ft-os szakember _napidíja_ kissé riaszt. Úgy értem kizárt, hog yén bármit vásároljak tőlük, olyan drágák. Nem az én súlycsoportom...
[quote:aba7daaaa6="noss"]egy _picit_ tudományosabban elmondanátok, hogy _komolyabb_ feladatra miért kell kereskedelmi db és miért nem jó, miben marad el pl egy postgre?? lehet hosszan is válaszolni!
Csak a főbb előnyök:
1. Véded s@gged, hogy adnak hozzá szápportot
2. Ha gondod van, akkor rájuk hárítod, hogy nézzenek utána
3. Más termék gyártónál tudod verni a melled, hogy erre alapozzon, mert ez, papírra alapozva, ki van tesztelve.
Azért azt el kell ismerni a fizetős adatbázis kezelőkben jó sokáig bent lehet egy lyuk, mert ha a gyártó nem javítja ki és nincs semmi workaround rá, akkor csak reménykedhetsz, hogy nem fogja senki kihasználni.
Meg érdekes módon mehet a fejlesztés, mert a Larry bácsi termékébe időnként becsúsznak olyan bugok, hogy egy sima selectet nem képes végrehajtani. Nem beszélve arról, hogy a legelső 9-es verzió kb. használhatatlan volt.
Amikor működik akkor viszont jó.
[quote:335c2d45b5="LeoALo"]Adott egy adatbáziskezelő, amely bizonyos dolgokban és bizonyos feladatokra felülmúlja még az oracle képességeit is
Ez érdekel: miben múlja felül az Oracle-t?
[quote:335c2d45b5="LeoALo"], GPL licensz alatt használható, 7*24 órás supportot
Nem. Ugyan az a licensze, mint a mysql-nek, vagyis csak open source programok mellé ingyenes, egyébként fizetős (50$ userenként vagy 1500$).
Értem a "döbbenetedet", csak kicsit későn érkezett a maxdb, kevesen ismerik, és elég komoly mennyiségű ismeretet igényel az üzemeltetése (önálló állatfaj, mint a többi "nagy" is). Majd meglátjuk mi lesz vele 3-5 év múlva.
Mindenesetre tanulságos az eredméynek eddigi alakulása. A sok légy jut eszembe...
U.I.: Access miért nincs?!? Azt hittem az a legjobb...
[quote:a59b27a67c="noss"]egy _picit_ tudományosabban elmondanátok, hogy _komolyabb_ feladatra miért kell kereskedelmi db és miért nem jó, miben marad el pl egy postgre?? lehet hosszan is válaszolni!
1. Támogatás
2. SQL szabványnak megfelelő implementáció
3. Ezt ismerik a fejlesztők
4. Az támogatott az adott környezetben. pl.: van hozzá natív backup szoftver kliens, SAN integrált mentés támogatottsága, mondjuk ha SAP-ot akarsz használni az sem fut mindenen (még)
1. azért fontos mert nem téged vesznek elő, hogy korrupt az adatbázis, áll a rendszer, tessék már megoldani, vagy fizetni az állásidőt.
3. idő pénz kitanulni egy rendszert, ha már van tudás akkor azt használják
4. kész megoldás esetén nem kell hegeszteni (annyit :) )
Egyébként a PostgreSQL 8.x új szolgáltatásait figyelve nagyon szépen fejlesztik.
Izéé szerintem SAPdb != SAP ERP
[quote:01b126d210="noss"]egy _picit_ tudományosabban elmondanátok, hogy _komolyabb_ feladatra miért kell kereskedelmi db és miért nem jó, miben marad el pl egy postgre?? lehet hosszan is válaszolni!
Az Oracle Tech Net (otn.oracle.com) -en kint van fejlsztői célra gyakorlatilag valamennyi termék, ezeket devel környezetben gyakorlatilag ingyen használhatod -- Az Oracle tudja, hogy segítséget, képzést, doksit, etc. úgy is fogsz venni hozzá, és a production rendszerre a megrendelő meg kell, hogy vegye, ergo azzal, hogy a fejlesztőt ezzel támogatja, azzal eladásokat generál.
ha pedig fejlesztés, akkor fejlesztőeszköz (TOAD), ha meg üzemeltetés, akkor monitorozó eszköz (Quest SpotLight) is kell -- no ez mind van Oracle-höz.
De akár egy olyan egyszerű dologra is gondolhatnánk, mint online backup...
[quote:807cde0c04="mocsi"]Izéé szerintem SAPdb != SAP ERP
Ott a pont!
Mint már elhangzott párszor SAPDB már MaxDB néven fut és egy adatbázis-kezelő.
A SAP ERP meg egy alkalmazás ami akár a fenti adatbázis-kezelőt is használhatja.
Ja. Vagy pl online backup write once médiára:)
Kimaradt az én kedvenc adatbáziskezelőm is. :-(
a grep és a sed páros.
[quote:4083b132ec="Ago"]
Mert nem a .org-on kell keresni :) Van több cég is, akik hivatlosan árulják a postgrest, pl. a CommandPrompt. Mondjuk velük lehet kötni háttérszerződést illetve backend supportra.
Egyébként mintha először nem kötötted volna ki, hogy csak Mo-n lehet a backend support :)
Addig amíg itthon nem kínlja egy magyar cég addig ez nem realitás. Egyrészt tipikusan árérzékeny szegmens a megcélzott ezért még egy külföldi alap támogatást sem nagyon tudsz eladni a pgsql mellé. Kell egy közvetitő a nyelvi, technikai áthidalásra.
Magyar embernek magyar supportot! :) :) :)
A backend lehet bárhol, csak vezessen oda könnyű út.
[quote:4083b132ec="Ago"]
Azt meg mindannyian tudjuk, hogy legtöbb cég termékénél itthon is csak forwardolják a bonyolult support kérdéseket, tisztelet a kivételnek, azért abból is van jó pár.
Igen mert támogató központ nincs a világ minden szegletében, nincs is annyi specialista, meg nem is érné meg. De van amit kis hazánkba forwardolnak, pl. SAP. :)
[quote:4083b132ec="Ago"]
Ha jól értem, akkor Te az olyan alkalmazásokat hiányolod, mint az SAP Postgresql alapon Oracle helyett vagy ha nem is ekkorát, akkor is valamilyen "fajsúlyosabbat".
Pontosan, legalább valamit ami az üzletmenet szempontjából kritikus. Amíg ilyen nincs addig, lehet, hogy a webes telefonkönyv alatt pgsql van, de meg is marad azon a szinten. Szerintem alkalmazással együtt van esélye a terjedésre. A cégek általában nem technológiát - az csak nekünk fontos mert ezt vagy azt szeretjük - hanem megoldást vesznek.
informix sincs 8O
tudom, szolhattam volna elobb is. :(
[quote:85213c0c96="szekelyk"][quote:85213c0c96="mocsi"]Izéé szerintem SAPdb != SAP ERP
Ott a pont!
Mint már elhangzott párszor SAPDB már MaxDB néven fut és egy adatbázis-kezelő.
A SAP ERP meg egy alkalmazás ami akár a fenti adatbázis-kezelőt is használhatja.
Sőt én úgy tudtam, hogy több SAP (ERP) fur Oracle DB-n, mint MaxDB alatt.
[quote:b6908a7c90="whitehorze"]
-párszáz megás adatbázis.. ok leállállítod a szervert és backupolsz nemde?
csináld meg ezt egy banki rendszerrel. Oracle nem is tud menet közben backupolni!!!
Oracle pl. rettenetesen igényli hogy karbantartsák, és még így is rengeteg gond van vele. Bárki megnézheti, hogy hányszor állnak le az Oracle-es szerverek. Ja bocsánat, ezek a statisztikák persze nem publikusak, istenem...
Höm... Már megbocsáss, de mikor láttál te utoljára Oracle-t? az alter tablespace xxxx begin backup, illetve alter tablespace xxxx end backup, közben pedig fizikai fájlmásolás, vagy storage-szintű FS-snapshot mindent táblatérre meg, majd a controlfile-t is bekapod :) (alter database backup controlfile to '/some/arbitrary/path';) de bővebben pl. http://www.adp-gmbh.ch/ora/admin/backup_recovery/hot_backup.html
Az Oracle igényli, vagy az alkalmazások a karbantartást/masszázst? Elég naaaaaaaagy Oracle adatbázisokhoz is volt szerencsém, amikbe garantáltan belerokkant volna fejlesztő is, dba is, felhasználó is, ha Postgres, mySQL, vagy hasonló szoftver kezelte volna azokat az adatokat...
[quote:2227061938="KAMI911"]Nekem a FirebirdSQL a kedvencem, ígyhát arra szavaztam...
Linux-on futtatod?
Bevallom én egyszer megpróbáltam feltenni debian alá, de valamitől..
.. már nem emlékszem mitől felment az agyvizem és rm -fr${k*anyad} firebird
lett a vége.. persze ez ugy 2-3 éve volt.
Fri
[quote:41f872409c="KAMI911"]Szépen lassan itt a 2.0-ás verzió...
... végre normális indexelhető kulcsmérettel ...
(25x b-> 1024b max.)
[quote:d460957655="whitehorze"]
csináld meg ezt egy banki rendszerrel. Oracle nem is tud menet közben backupolni!!!
Oracle pl. rettenetesen igényli hogy karbantartsák, és még így is rengeteg gond van vele. Bárki megnézheti, hogy hányszor állnak le az Oracle-es szerverek. Ja bocsánat, ezek a statisztikák persze nem publikusak, istenem...
Az itt szavazók 99% százaléka szerintem laikus..
Lefogadom "bankos" vagy.. azok szoktak ennyi marhaságot összehordani.:))
Az oracle nem tud menet közben bakuplni.. ez igy van, sőt! A monitorrol kell
lolvasni a kilistázott táblák tartalmát és felirni egy füzetbe, amit nyugdidjjas nénik
utána felvisznek egy access adatbázisba.. ez a mentés.:))
Az Oracle-vel rengeteg gond van.. tyja.. valóban kevés hozzáértő van aki
rendesen be tud hangolni, konfigurálni egy Oracle szervert.. annál több okoska,
mint Te. Én már "láttam" egy hozzáértő hangolását.. mit ne mondjak.. akkora
volt a különbség, mint egy csiga és egy F1 között van.
Szóval.. én csak azt nem értem, hogy jössz ennyi hülyeség után ahhoz, hogy lelaikusozd a szavazókat.
Fri
[quote:629025800a="tolmi"][quote:629025800a="dejo"]Régebben egyértelműen a magukat profinak vallók használtak PostgreSQL-t és a MySQL-eseket leamatőrözték.
Hál'Istennek ez kezd felszámolódni. Jónéhány intelligens kollega gyepálása végre beérni látszik és befejeződik ez a világméretű hülyeség, amiről írsz. :)
Pedig egyértelmű és hülyeség is ilyenen vitatkozni, mert mindenki
tudja, hogy aki MySQL-t használ az amatör.. aki PostgreSQL-t az profi.:-)
Fri
[quote:2793510445="Frimen"]
...
Fri
Elég agresszív véleményt alkottam ide rólad, kedves Frimen. De tudod mit? Nem érsz meg annyit, hogy kint hagyjam. De baromi jól mulattam rajtad. Szánalmas.hu színvonal...
[quote:b3516d6d9a="ssikiss"][quote:b3516d6d9a="LeoALo"]Adott egy adatbáziskezelő, amely bizonyos dolgokban és bizonyos feladatokra felülmúlja még az oracle képességeit is
Ez érdekel: miben múlja felül az Oracle-t?
Akkor tisztázzuk. Azt írtam bizonyos esetekben, bizonyos alkalmazásokra.
Pl egy nagyságrendel egyszerűbb kezelni, karbantartani. Nem igényel reorganizációt mint az Oracle (Bár a localy managed tablespace és az új segment management-el az Oracle deklarálta, hogy nem kell már reorgozni, valahogy mégis minimum 10% sebességnövekedést sikerült bizonyítani legutóbb),
egy "táblatered van",
tudsz konzisztens online mentést csinálni. (mitöbb csak olyat tudsz :) ) Az Oracle-el archive logok nélkül semmit nem érsz, még akkor sem, ha nem akarod előregörgetni a adatbázisodat az utolsó pillanatig. (Online mentés esetén persze),
Ugyanazon adatmennyiség tárolásához sokkal kevesebb (20-40%) hely kell mint Oracle alatt,
Van adatbázis snapshot lehetőség, ami Oracle-ben tudtommal nincsen.
Hirtelen ennyi.
Magyarországon? Hol? A postgresql.org oldalán nem találtam magyar bejegyzést.
Google sem segített.
Nagy cégek nem a telefonkönyvből választanak informatikai bt.-t beszállítónak. Olyan alkalmazások kellenek PSQL-re (vagy x-re) amit ezek a nagyok használnak. Aztán már jöhetnek a bt.-k a specialistákkal, akik támogatnak, fejlesztenek. De elterjeszteni nem ők fogják. Túl kicsik, nincs súlyuk, ilyen téren.
Nem arra gondoltam ha elbénázod vagy rossz a termék és tényleg használhatatlan. Szerintem itt már mindenki látott karón varjút. Tehát ha összejön valami fura hiba, akkor nem neked kell kiderítened, amire adott esetben sem tudásod, sem erőforrásod nincs.
[quote:9c6640f54c="ssikiss"][quote:9c6640f54c="LeoALo"], GPL licensz alatt használható, 7*24 órás supportot
Nem. Ugyan az a licensze, mint a mysql-nek, vagyis csak open source programok mellé ingyenes, egyébként fizetős (50$ userenként vagy 1500$).
Értem a "döbbenetedet", csak kicsit későn érkezett a maxdb, kevesen ismerik, és elég komoly mennyiségű ismeretet igényel az üzemeltetése (önálló állatfaj, mint a többi "nagy" is). Majd meglátjuk mi lesz vele 3-5 év múlva.
Akkor kissé férreértetted. A következő áll az oldalon:
Mit jelent ez? Egyrészt lehetőséged van a terméket GPL licensz alatt használni. Mit jelent ez? Letöltheted és használhatod. De ha fejlesztesz valami, amibe befordítod pl a kliensét, vagy ha fölteszed a terméked CD-jére, akkor a termékedet is GPL alatt ki kell adnod.
Ez egyrészt jó a felhasználónak, de rossz annak a fejlesztőnek, aki fizetős progit akar eladni és nem GPL alá fejleszteni. Ezért lehetőség van üzleti licenset venned, ezesetben mentesülsz a GPL kötelmei alól, azaz eladhatod a progidat zárt kóddal.
[quote:116ce5ac1d="whitehorze"]Azt hittem az a legjobb...
nem, a legjobb az ms sql 2k5, de itt most olyan kereskedelmi/egyeb rendszerek vannak, amik elfutnak unix-szeru rendszereken is
[quote:29b65663c6="Ago"]Pár kiegészítés: a Postgresql-hez is tudsz venni kereskedelmi támogatást, plusz szolgáltatásokat, modulokat. Ha szállítasz rendszert, akkor tudsz mutogatni a gyártóra, de a rendszert akkor is Te választottad, végső soron a Te seggedet rúgják szét.
A MySQL-hez ragaszkodók tényleg sokszor mondják még mindig, hogy "ez csak postgreses hülyeség". Talán nézzük meg, ha ragaszkodunk az ACIDhoz, akkor mire is képes a MySQL. A MySQL5-ben jelent csak meg, most a tárolt eljárás, a trigger, a _rendesen_ működő constraint és foreign key támogatás - volt benne constraint persze, mondjuk a check null :) és hasonló komoly featureok. Szóval rendesen nem volt implementálva vállalati felhasználásra mondjuk egy ügyviteli rendszerhez. Ugyanakkor nagyon jó volt portálmotorhoz ahol nem volt szükséges egy ROLLBACK, ha mondjuk mégsem sikerült volna a teljes tranzkció, azaz nem volt rendes tranzakció kezelés. Folytassam? Másra jó. Sok mindenre még mindig használhatóbb a postgresql.
idézet mysql doksiból : "Starting from MySQL 3.23.44, InnoDB features foreign key constraints." ami annyit jelent, hogy a mysql adatbázisban az innodb típusú tábla már a 3.23.44-es verziótól kezdve támogatja a külsőkulcs kényszerítést. ez a verzió pedig 2001. október 31-én jött ki.
továbbá az innodb táblatípust főleg arra találták ki, hogy tranzakciókat is tudjon kezelni, ez pedig már elég régóta része alapból a mysql-nek!
továbbá csak halkan jegyzem meg, hogy valamiért pont most az oracle vette meg az innobase -t ;) (az innodb táblatípus "gyártóját")
[quote:f32fe8a49a="LeoALo"]***
tudsz konzisztens online mentést csinálni. (mitöbb csak olyat tudsz :) ) Az Oracle-el archive logok nélkül semmit nem érsz, még akkor sem, ha nem akarod előregörgetni a adatbázisodat az utolsó pillanatig. (Online mentés esetén persze),
***
Van adatbázis snapshot lehetőség, ami Oracle-ben tudtommal nincsen.
Ezekben nagyon biztos vagy? :wink:
Nem vagyok SQL használó, de kacérkodom vele, mert szükségem lesz rá.
Azért jó ideje figyelem a MySQL kontra PostgreSQL vitát. Régebben egyértelműen a magukat profinak vallók használtak PostgreSQL-t és a MySQL-eseket leamatőrözték. Talán te is ebben az állapotban vagy?
Mostanában, mintha a MySQL is elismertebb lenne. A legyek meg lehet, hogy inteligens lények!
Ja igen és akkor jönnek még a meg nem alkuvók, akik csak "márkás" cuccal dolgoznak, még akkor is, ha a feleség receptgyűjteményét kell tárolni, mert fő a biztonság! (Ez utóbbi erősen túlzás akart lenni, de a lényegre kellőképpen rávilágít.)
[quote:5f23a2a16e="mocsi"][quote:5f23a2a16e="szekelyk"][quote:5f23a2a16e="mocsi"]Izéé szerintem SAPdb != SAP ERP
Ott a pont!
Mint már elhangzott párszor SAPDB már MaxDB néven fut és egy adatbázis-kezelő.
A SAP ERP meg egy alkalmazás ami akár a fenti adatbázis-kezelőt is használhatja.
Sőt én úgy tudtam, hogy több SAP (ERP) fur Oracle DB-n, mint MaxDB alatt.
Az R3 eredetileg Oracle-re készült. A SAPDB-MaxDB egy új dolog. Igazából Objektumorientált adatbázisnak vették és fejlesztgették. Nem is volt a klasszikus R3-hoz elérhető, csak az APO LiveCache-e volt. (Ez már hardcore SAP. Elég az, hogy egy spciális rendszer egy speciális alkotórésze) Csak miután az oracle szőrözni kezdett, az SAP kissebb ügyfelek felé nyitott, és mivel lassan használható adatbáziskezelő lett hagyták jóva az ERP rendszerekhez.
Azontúl az SAP többet keres egy Oracle-el futó rendszeren, mint egy MaxDB-sel. Ezt sem felejtik el soha.
Szerintem alapvető probléma, hogy nincs ponotsan definiálva hogy miről is kell szavazni. Mit fog jelenteni a végeredmény? Kinek a kedvence? Programozóé, vagy neadj isten a dba-é? Kisbolt árukészletét, vagy egy banki rendszert kell elvinnie?
Lehet (pl mysql) nagyon felhasználóbarát: a nagymamám is összedob egy adatbázist a varázslókkal; A programozók imádni fogják, mert irogathatnak mindenféle kényelmes függvényeket, meg ilyesmik, de nem örülnék neki ha a bankszámlámat egy ilyen rendszer kezelné.
Mekkora adatot kezelsz vele?
-párszáz megás adatbázis.. ok leállállítod a szervert és backupolsz nemde?
csináld meg ezt egy banki rendszerrel. Oracle nem is tud menet közben backupolni!!!
Melyik a fontosabb:
Több pénzt és időt áldozni olyan programozókra - akik több pénzért persze - de megizzadnak egy komolyabb, de kevésbé "popókinyalós" adatbázissal, és cserébe kisebb a hardverigény mellet és kevesebb adminisztrációt igénylő adatbázist jelent, vagy összedobni "két nap alatt" egy adatbázist "mikroszoftos varázslókkal", aztán izzadjon a dba - meg persze aki fizeti a dba-t ;).
Oracle pl. rettenetesen igényli hogy karbantartsák, és még így is rengeteg gond van vele. Bárki megnézheti, hogy hányszor állnak le az Oracle-es szerverek. Ja bocsánat, ezek a statisztikák persze nem publikusak, istenem...
Rengeteg szempont van, ez a szavazás pedig csak egy valamivel foglalkozik: "Neked melyik szimpi?"
Az itt szavazók 99% százaléka szerintem laikus, de legalábbis soha nem dolgozott mondjuk komolyabb rendszereken. (mondjuk közigazgatási, vagy banki rendszereken)
Szóval szerintem tegyétek be az Access-t, és ha elég nagymama látogatja meg az oldalt, akkor az lesz az év kedvenc adatbáziskezelője.
[quote:54aea7c869="mocsi"][quote:54aea7c869="LeoALo"]***
tudsz konzisztens online mentést csinálni. (mitöbb csak olyat tudsz :) ) Az Oracle-el archive logok nélkül semmit nem érsz, még akkor sem, ha nem akarod előregörgetni a adatbázisodat az utolsó pillanatig. (Online mentés esetén persze),
***
Van adatbázis snapshot lehetőség, ami Oracle-ben tudtommal nincsen.
Ezekben nagyon biztos vagy? :wink:
Meglehetősen. A snapshot-ban egészen. A normál mentésnél is. Max az RMAN-al lehet valamit bűvészkedni. De a normál oracle online mentés bizony csak "recover database" -el lesz konzisztens. Ebben akár fogadhatunk is :D
[quote:3c7f559950="szekelyk"][quote:3c7f559950="noss"]egy _picit_ tudományosabban elmondanátok, hogy _komolyabb_ feladatra miért kell kereskedelmi db és miért nem jó, miben marad el pl egy postgre?? lehet hosszan is válaszolni!
1. Támogatás
2. SQL szabványnak megfelelő implementáció
3. Ezt ismerik a fejlesztők
4. Az támogatott az adott környezetben. pl.: van hozzá natív backup szoftver kliens, SAN integrált mentés támogatottsága, mondjuk ha SAP-ot akarsz használni az sem fut mindenen (még)
1. azért fontos mert nem téged vesznek elő, hogy korrupt az adatbázis, áll a rendszer, tessék már megoldani, vagy fizetni az állásidőt.
3. idő pénz kitanulni egy rendszert, ha már van tudás akkor azt használják
4. kész megoldás esetén nem kell hegeszteni (annyit :) )
Egyébként a PostgreSQL 8.x új szolgáltatásait figyelve nagyon szépen fejlesztik.
MySQL-hez nincs támogatás (mert GPL licenszű) kiv, ha fizetsz érte
SQL'92 - no comment. A PostgreSQL sokkal közelebb van hozzá, a MySQL 5 már kezd arrafele mászkáni
[quote:6525e97b22="szekelyk"]
Magyarországon? Hol? A postgresql.org oldalán nem találtam magyar bejegyzést.
Mert nem a .org-on kell keresni :) Van több cég is, akik hivatlosan árulják a postgrest, pl. a CommandPrompt. Mondjuk velük lehet kötni háttérszerződést illetve backend supportra.
Egyébként mintha először nem kötötted volna ki, hogy csak Mo-n lehet a backend support :)
Azt meg mindannyian tudjuk, hogy legtöbb cég termékénél itthon is csak forwardolják a bonyolult support kérdéseket, tisztelet a kivételnek, azért abból is van jó pár. De be kell látni, hogy világszinten több probéma van, a közös tapasztalat ezért nagyobb.
[quote:6525e97b22="szekelyk"]
Google sem segített.
Nagy cégek nem a telefonkönyvből választanak informatikai bt.-t beszállítónak. Olyan alkalmazások kellenek PSQL-re (vagy x-re) amit ezek a nagyok használnak. Aztán már jöhetnek a bt.-k a specialistákkal, akik támogatnak, fejlesztenek. De elterjeszteni nem ők fogják. Túl kicsik, nincs súlyuk, ilyen téren.
Ha jól értem, akkor Te az olyan alkalmazásokat hiányolod, mint az SAP Postgresql alapon Oracle helyett vagy ha nem is ekkorát, akkor is valamilyen "fajsúlyosabbat".
[quote:3675ad8e98="suti"]
idézet mysql doksiból : "Starting from MySQL 3.23.44, InnoDB features foreign key constraints." ami annyit jelent, hogy a mysql adatbázisban az innodb típusú tábla már a 3.23.44-es verziótól kezdve támogatja a külsőkulcs kényszerítést. ez a verzió pedig 2001. október 31-én jött ki.
továbbá az innodb táblatípust főleg arra találták ki, hogy tranzakciókat is tudjon kezelni, ez pedig már elég régóta része alapból a mysql-nek!
Csak egy dologra mutatnék rá:InnoDB megállpodás alapján van benne ugye, nem konzisztensen fejlesztik a MySQL-lel, amit a hírekben láttam. A postgresql egy és oszthatatlan. Kb annyi a különbség a, mintha a Linux-ban egy filerendszer már része a kernelnek, a másik pedig nem. Arról nem beszélve, hogy mire is lehet használni: nem használhatod saját termék fejlesztéséhez ingyen. Ami persze nem feltétlenül baj, ha pénzt csináltál a munkájukból vissza is adhatsz valamit igazán.
Azért idéznék a roadmap-ből:
Add some missing FOREIGN KEY functionality to InnoDB. For example, columnname typename FOREIGN KEY REFERENCES tablename(columnname).
Azért az sem teljes, ahogyan látom :)
[quote:3675ad8e98="suti"]
továbbá csak halkan jegyzem meg, hogy valamiért pont most az oracle vette meg az innobase -t ;) (az innodb táblatípus "gyártóját")
erre most mondhatnám, hogy azért, mert a kisvállalati szegmensbe is be akar törni. De mondhatnám, hogy az SAP azért adta oda "kincsét" a MaxDB-t a MySQL-nek, mert a MySQL-nél sokkal jobb fejlesztők vannak :)
IMHO inkább profilbővítés, ak isebb cégek felé történő nyitás miatt vette meg az Oracle az InnoDB-t, mert lehet, hogy vannak olyan eljárások kódok a szoftverben amihez neki USA-ban van szabadalma és itt is gyorsan levédette. De gyanakodhatnék arra is, hogy csak kontrollálni akarja a MySQL-t. Valszeg mindegyik hozzátesz valamit az igazsághoz.
Azt hiszem le lehet zárni, hogy mindenki más miatt szereti a postgrest vagy a mysql-t. A NASA-s adatbázis az egy dolog. LEhet, hogy feltöltötték egyszer, aztán meg mindig csak beszúrnak naponta egy adatot esetleg objektumokat stb. A mérete nem minden egy adatbázisnak. A mérettel mit akarsz kezdeni, imho ez a lényeg. Pl állandó lekérdezés, eredmény visszaírás eléggé szét tudja szedni a gépet.
Egyébként a postgresql-t úgy kezdték alapból fejleszteni, hogy az Oraclet vették alapul. Röviden ennyi :) Utóbbi Oracle hívőknek szólt :)
[quote:2de44beb02="tolmi"]
Elég agresszív véleményt alkottam ide rólad, kedves Frimen. De tudod mit? Nem érsz meg annyit, hogy kint hagyjam. De baromi jól mulattam rajtad. Szánalmas.hu színvonal...
Semmi baj.
Speciel én csak viccnek szántam.. a nem lehet kihagyni kategoriába tartozott.:)
Máskor, mikor átmész agresszivbe, nézd meg a másikat, hogy van-e rajta sapka!:)
Fri
[quote:b681b7a7b5="szekelyk"][quote:b681b7a7b5="noss"]egy _picit_ tudományosabban elmondanátok, hogy _komolyabb_ feladatra miért kell kereskedelmi db és miért nem jó, miben marad el pl egy postgre?? lehet hosszan is válaszolni!
1. Támogatás
2. SQL szabványnak megfelelő implementáció
3. Ezt ismerik a fejlesztők
4. Az támogatott az adott környezetben. pl.: van hozzá natív backup szoftver kliens, SAN integrált mentés támogatottsága, mondjuk ha SAP-ot akarsz használni az sem fut mindenen (még)
1. azért fontos mert nem téged vesznek elő, hogy korrupt az adatbázis, áll a rendszer, tessék már megoldani, vagy fizetni az állásidőt.
3. idő pénz kitanulni egy rendszert, ha már van tudás akkor azt használják
4. kész megoldás esetén nem kell hegeszteni (annyit :) )
Egyébként a PostgreSQL 8.x új szolgáltatásait figyelve nagyon szépen fejlesztik.
Pár kiegészítés: a Postgresql-hez is tudsz venni kereskedelmi támogatást, plusz szolgáltatásokat, modulokat. Ha szállítasz rendszert, akkor tudsz mutogatni a gyártóra, de a rendszert akkor is Te választottad, végső soron a Te seggedet rúgják szét.
A MySQL-hez ragaszkodók tényleg sokszor mondják még mindig, hogy "ez csak postgreses hülyeség". Talán nézzük meg, ha ragaszkodunk az ACIDhoz, akkor mire is képes a MySQL. A MySQL5-ben jelent csak meg, most a tárolt eljárás, a trigger, a _rendesen_ működő constraint és foreign key támogatás - volt benne constraint persze, mondjuk a check null :) és hasonló komoly featureok. Szóval rendesen nem volt implementálva vállalati felhasználásra mondjuk egy ügyviteli rendszerhez. Ugyanakkor nagyon jó volt portálmotorhoz ahol nem volt szükséges egy ROLLBACK, ha mondjuk mégsem sikerült volna a teljes tranzkció, azaz nem volt rendes tranzakció kezelés. Folytassam? Másra jó. Sok mindenre még mindig használhatóbb a postgresql.
[quote:c073db9e69="whitehorze"]Szerintem alapvető probléma, hogy nincs ponotsan definiálva hogy miről is kell szavazni.
dehogynem. kedvenc. amit szeretsz.
az átlagét.
ez nem volt kérdés.
Case Studies: Los Alamos National Labs Relies on MySQL to Scale with 7 Terabytes of Data
http://www.mysql.com/it-resources/case-studies/mysql-losalamos-casestudy.pdf
csak példának. engem meggyőzött.
már leírták néhányan. láttál-e már oracle-t?
általánosítások. adminolok egy ~100GB adatbázist. tele bináris adatokkal. semmi gondom nincs vele. (BTW, a fejlesztők meg szívnak a BDE-vel, de ez az ő bajuk.)
na végre, rájöttél.
lehet. és?
ha már itt tartunk: Dolgozok oracle-vel, mysql-lel, ms-sql-lel, access-el is.
attól még lehet a mysql is a kedvencem, az otthoni recept/bor/könyv/cd/akármi kategorizálására pl, nemde?
[quote:f26ae27952="snq-"]
nem, a legjobb az ms sql 2k5, de itt most olyan kereskedelmi/egyeb rendszerek vannak, amik elfutnak unix-szeru rendszereken is
Mindenféle támadási szándék nélkül kérdezem:
Tudsz mondani néhány érvet az MS SQL 2k5 mellett? Amitől, úgy értem, a mezőny fölé magasodhat. Akár ár/érték viszonylatban is. Köszi!
[quote:2dc4efc6fa="dejo"]Régebben egyértelműen a magukat profinak vallók használtak PostgreSQL-t és a MySQL-eseket leamatőrözték.
Hál'Istennek ez kezd felszámolódni. Jónéhány intelligens kollega gyepálása végre beérni látszik és befejeződik ez a világméretű hülyeség, amiről írsz. :)
[quote:2dc4efc6fa="dejo"]
Mostanában, mintha a MySQL is elismertebb lenne. A legyek meg lehet, hogy inteligens lények!
Nem az számít hogy mennyire elismert, hanem hogy mennyire sikeresen teljesíti a közönség által kitűzött célokat. A MySQL mai sikere azért elég nagy mértékben támaszkodott a SAP-ra. Szerintem. A PostgreSQL pedig egy kicsit próbál kitörni a konvencionális adatbázisok közül és olyan utakon járni, mint OO-database, vagy nagymennyiségű bináris adat kezelése. Pont amerre az Oracle is veszi mostanában az irányt. Ráadásul most, hogy a Sun kereskedelmi termékként fogja támogatni Sol10-zel, én nem hinném hogy nem lesz kiélezett verseny a MySQL és a PostgreSQl között:) De a versennyel mi, felhasználók csak nyerhetünk. :)
[quote:2dc4efc6fa="dejo"]
Ja igen és akkor jönnek még a meg nem alkuvók, akik csak "márkás" cuccal dolgoznak, még akkor is, ha a feleség receptgyűjteményét kell tárolni, mert fő a biztonság! (Ez utóbbi erősen túlzás akart lenni, de a lényegre kellőképpen rávilágít.)
A bigottság drága hep. :) De mi egész jól keresünk rajta :P
Mellesleg hogyha nagyon sok recepted(100milliárd körül :) ) van és szeretnél irtógyorsan sokadrangú metainformációkat kiszelektálni a tudásbázisodból, akkor már nélkülözhetetlen lesz egy kereskedelmi termék. :D
[quote:33263f3b13="Frimen"]***
Lefogadom "bankos" vagy.. azok szoktak ennyi marhaságot összehordani.:))
***
Fri
Vagy pontazhogy nem bankos. Eddigi leírása alapján nem nagyon volt még közel komoly banki rendszerekhez, vagy nem engedték neki hogy eltérjen az előírástól amit egy programozó írt azon okból hogy le tudja fedezni a hátsóját...
Amúgy meg bírom azokat a nagyképű dumákat, hogy így komoly a banki rendszer, meg "bezzek a BANKI renszerek", nos ezt addig el is hittem én is, amíg bele nem csöppentem. Hát olyan példák vannak, hogy minősítő szoftvare VB alapokon (OTP), vagy nemzetközi banki átutalás Tuxedo, pgsql, LDAP, PKI, JBOSS meg egy csomó más alkalmazás egybegyúrásával (SWIFT rendszer), úgy hogy bizony néha egyes elemek elröppenek, vagy mondhatom a jó öreg MIDAS-t (igaz az AEB most állt át Symobls-ra, de mint a torkosborz...), ami még lockolást sem ismer, vagy még pár helyen futnak file alapú adatbázisnak csúfolt rendszerek (OTP, Budapest bank IBS-ei), melyek egy sima stornót nem engedélyeznek stb.stb. Naponta látom a rendszerünk működésében hogy: "Exception occured no XXXX, Transaction upload successfull" amit úgy oldottak meg, hogy beraktak egy if elágazást, hogy elrejtse a problémát. :D Nagy humbug az egész.
Nekem a FirebirdSQL a kedvencem, ígyhát arra szavaztam...
Szépen lassan itt a 2.0-ás verzió...
Két apró megjegyzés.
[quote:89b903e9ad="dejo"]Nem vagyok SQL használó, de kacérkodom vele, mert szükségem lesz rá.
Azért jó ideje figyelem a MySQL kontra PostgreSQL vitát. Régebben egyértelműen a magukat profinak vallók használtak PostgreSQL-t és a MySQL-eseket leamatőrözték. Talán te is ebben az állapotban vagy?
Mostanában, mintha a MySQL is elismertebb lenne. A legyek meg lehet, hogy inteligens lények!
Másik témában már volt erre vonatkozólag kiemelés: nem a legjobb, vagy legjobbnak tartott foobart kérdezte Trey, hanem a kedvencet. Tisztában vagyok vele, hogy az általam használt célra _nem_ a MySQL a legjobb, mégis azt jelöltem be: a legtöbb disztróban még mindig sokkal egyszerűbb telepíteni, mint egy Oracle-t.
[quote:89b903e9ad="dejo"]Ja igen és akkor jönnek még a meg nem alkuvók, akik csak "márkás" cuccal dolgoznak, még akkor is, ha a feleség receptgyűjteményét kell tárolni, mert fő a biztonság! (Ez utóbbi erősen túlzás akart lenni, de a lényegre kellőképpen rávilágít.)
Ajánlom szíves figyelmedbe az Oracle (fejlesztési/saját célra, nem tudom pontosan) ingyen elérhető változatát, ami állítólag nem sokban különbözik a "fizetős" változattól.
Ajanlanam figyelmedben, hogy a szavazas nem a "LEGJOBB"-at keresi, hanem a "KEDVENC"-et. A kettonek nem kell szuksegszeruen egybeesnie.
[quote:d16a562ac0="whitehorze"]Mindenesetre tanulságos az eredméynek eddigi alakulása. A sok légy jut eszembe...
U.I.: Access miért nincs?!? Azt hittem az a legjobb...
Csak hogy ugyanarról beszéljünk. A snapshot alatt azt értem, amikor befagyasztasz egy állapotot az adatbázisban. Utána mondjuk csinálsz egy nagyobb változtatást, kitörölsz táblákat, beszúrsz másik táblákba pár millió sort, másikakat megváltoztatsz. Két nap mulva úgydöntesz, hogy vissza az egész... Ez MaxDB alatt pár másodperc. Semmi restore, vagy file csiki-csuki. Egy recover snapshot...
[quote:9ddddea814="LeoALo"]
Meglehetősen. A snapshot-ban egészen. A normál mentésnél is. Max az RMAN-al lehet valamit bűvészkedni. De a normál oracle online mentés bizony csak "recover database" -el lesz konzisztens. Ebben akár fogadhatunk is :D
Akkor már csak egy kérdésem volna, melyik verziónál?
[quote:19c4c8f927="mocsi"][quote:19c4c8f927="LeoALo"]
Meglehetősen. A snapshot-ban egészen. A normál mentésnél is. Max az RMAN-al lehet valamit bűvészkedni. De a normál oracle online mentés bizony csak "recover database" -el lesz konzisztens. Ebben akár fogadhatunk is :D
Akkor már csak egy kérdésem volna, melyik verziónál?
Melyik verziónál igen?
[quote:8f614ca94d="LeoALo"][quote:8f614ca94d="mocsi"][quote:8f614ca94d="LeoALo"]
Meglehetősen. A snapshot-ban egészen. A normál mentésnél is. Max az RMAN-al lehet valamit bűvészkedni. De a normál oracle online mentés bizony csak "recover database" -el lesz konzisztens. Ebben akár fogadhatunk is :D
Akkor már csak egy kérdésem volna, melyik verziónál?
Melyik verziónál igen?
9.2 és felette ott van az exp-ben a consistent=Y/N, yól le is fogja a mentést, mert mindig behoza a lemaradást, de a snpashot úgy ahogy te gondolod nem működik, esetleg valami SCN trükközéssel, vagy RMAN tökörészéssel, de ezt én sem szeretném kipróbálni éles rendszeren.
[quote:9408d809d1="mocsi"][quote:9408d809d1="LeoALo"][quote:9408d809d1="mocsi"][quote:9408d809d1="LeoALo"]
Meglehetősen. A snapshot-ban egészen. A normál mentésnél is. Max az RMAN-al lehet valamit bűvészkedni. De a normál oracle online mentés bizony csak "recover database" -el lesz konzisztens. Ebben akár fogadhatunk is :D
Akkor már csak egy kérdésem volna, melyik verziónál?
Melyik verziónál igen?
9.2 és felette ott van az exp-ben a consistent=Y/N, yól le is fogja a mentést, mert mindig behoza a lemaradást, de a snpashot úgy ahogy te gondolod nem működik, esetleg valami SCN trükközéssel, vagy RMAN tökörészéssel, de ezt én sem szeretném kipróbálni éles rendszeren.
1, Úgyhiszem mentésről és nem exportról beszéltünk. Próbáltál már egy több TB-s rendszert exportálni??? Nalátod.
2, SCN-el sem lehet....
3, Én már próbáltam az RMAN-t. Az is mentő rendszer. Az adatok elhelyezésének logikája miatt nem tudod ezt a snapshotot oracle alatt megcsinálni. Ez a logika másra jóbb. Erre nem.
Összefoglalva. Ne essünk át a ló túloldalára. Az Oracle jobb adatbáziskezelő mint a MaxDB. De amivel jobb, az valahol a TB-s tartományban és egészen speciális területeken jelentkezik. PL a RAC egyedülálló és nagyon jó dolog. De az oracle adatbázisokat használó felhasználók 95%-a simán elfutkosna MaxDB-vel, úgy, hogy néha még kényelmesebb is lenne.
MaxDB alatt viszont működik. Annyira, hogy egy ügyfél, tanulatlan alkalmazott jóvoltából, aki rákattint minden gombra, amit nem ismer éppen két hét fejlesztés veszett el.... :lol:
[quote:7fffc813d8="LeoALo"]
1, Úgyhiszem mentésről és nem exportról beszéltünk. Próbáltál már egy több TB-s rendszert exportálni??? Nalátod.
2, SCN-el sem lehet....
3, Én már próbáltam az RMAN-t. Az is mentő rendszer. Az adatok elhelyezésének logikája miatt nem tudod ezt a snapshotot oracle alatt megcsinálni. Ez a logika másra jóbb. Erre nem.
Összefoglalva. Ne essünk át a ló túloldalára. Az Oracle jobb adatbáziskezelő mint a MaxDB. De amivel jobb, az valahol a TB-s tartományban és egészen speciális területeken jelentkezik. PL a RAC egyedülálló és nagyon jó dolog. De az oracle adatbázisokat használó felhasználók 95%-a simán elfutkosna MaxDB-vel, úgy, hogy néha még kényelmesebb is lenne.
1. Ácsi, azt állítottad nincs benne, mármint az Oracle-ben most akkor ne térj el a tárgytól. Benne van, és az hogy mentesz vagy exportálsz adatok szempontjából tökmindegy, mindkettő visszaállít egy (konzisztens/nem konzisztens) állapotot, a többi kérdés technikai és management kérdés. Amúgy ami nekem max full export Oracle-el volt az egy 500GB, de 1 óra 12 perc alatt megvolt.
2. erről valamikor olvastam valamit, állítólag lehet, csak hivatalosan nem támogatott persze.
3. RMAN-al vissza lehet pörgetni állapotot, bár kell neki egy off-line recovery.
Amit a végén írsz egy nagyon erős flame, ugyanis az átlag 95% felhasználó/programozó egy sqlite/mysql 3.23-al is tökéletesen el lenne, nem beszélve hogy jóval kezelhetőbb és átláthatóbbak a számukra. Ezután jönnek a különleges igények, melyek figyelembe vételével kell a db technológiát kiválasztani, ami lehet pgsql, oracle, db2 sőt MaxDB is ;)
A 2005-ös év kedvenc adatbázis-kezelője.
Köszi mindenkinek, aki válaszolt a kérdéseimre!
[quote:0da8252ed5="zeller"]
Az Oracle igényli, vagy az alkalmazások a karbantartást/masszázst? Elég naaaaaaaagy Oracle adatbázisokhoz is volt szerencsém, amikbe garantáltan belerokkant volna fejlesztő is, dba is, felhasználó is, ha Postgres, mySQL, vagy hasonló szoftver kezelte volna azokat az adatokat...
Miért rokkantak volna bele? A karbantartás nehézsége miatt?
[quote:421668c488="LeoALo"]
MaxDB alatt viszont működik. Annyira, hogy egy ügyfél, tanulatlan alkalmazott jóvoltából, aki rákattint minden gombra, amit nem ismer éppen két hét fejlesztés veszett el.... :lol:
Hm viszont ez a verzió kezelés szerűsége érdekel, kimondottan felkeltetted az érdeklődésemet a MaxDB felé. :D :lol:
Hali :)
Én csak programozó szemszögből tudok beleszólni: nekem jávából teljesen mindegy, hogy mibe túrok bele. Amivel dolgoznom kell, az oracle meg mssql 2000. Namost szemléletileg nem szeretem az ms termékeket, ez ilyen dili, ez van :) Az oracle-ben meg az nem tetszik, hogy telepítettem már párat. Az még hagyján, de amíg a szükséges patch-ek felmennek, az nekem kínszenvedés :)
Otthonra csináltam tesztkörnyezetet, mysql-el szívtam egy csomót, ilyen-olyan jogosultságokat hogy állítsak be, leginkább ezzel. Aztán felraktam postgre-t, ott minden pikk-pakk működött.
De ez nem olyan komoly cucc, végül is csak napi pár Gb txt-ből kell pakolni adatbázisba :) Nem hinném, hogy ne lehetne ezt bármelyik rendszerrel megoldani.
szóval nálam a kedvenc a postgre :)
MaxDB-ben van flashback? De ne menjünk ennyire bele... Az Oracle esetén is megvannak azok az eszközök, amelyek az adatbázis _egy részének (táblatér, de van ilyenje sémára is...)_ teljes és online mentését/visszaállítását támogatják, csak használni köll tudni azokat. Egy recovery esetén meg gyakorlatilag mindegy, hogy 23 vagy 98 fájlt kell visszatölteni, max a kazettacserélő technikus fog anyázni esteleg... Ha meg jó SAN-od van az adatbázis alatt, akkor a táblaterenkénti onlány backup idejét -a storage megfelelő funkciójával- naggyon minimálisra le lehet szorítani, és az itt repkedő sokszáz GB-TB méretű adatbázisok esetén a SAN elég gyakori vendég...ű
[quote:2c95521368="mrbond"]én is a postgreSQLre szavaztam, mert:
bár az orákulum az jó, de ha licenszeled akkor k. drága.
és szvsz nem csak a mysql / postgresqlhez képest.
Nálunk drága, tegyük hozzá. Ahol a fejlesztői ill. üzemeltetői mukaidő drága, azaz egy-egy feladatra mondjuk harmad/negyed annyi időt lehet szánni, mint itt, ott általában megtérül a magasabb licenszdíj a megtakarított mukaerő (fejlesztő és dba) árából.
Az Oracle licenszben azért elég sok "egyéb" cucc is bennefoglaltatik, nem csak egy sima sql+ és a mögötte lévő rdbms, ha mindezt össze akarod rakni (pl. Apache-PHP-MySQL), és megfelelő fejlesztés- és üzemeltetéstámogató eszközre is szükséged van, nos... akkor szerintem bajban vagy, illetve sok-sok mérnök/fejlesztői órád rá fog menni, és még csak az eszköz van a kezedben, egy alkalmazást sem írtál meg -- ha meg nekiálsz fejleszteni, akkor szintén beleütközöl az eszközhiányba.
Fejlesztőként gyakorlatilag semmiben sem kerül többe, ha Oracle vagy ha Postgres alá fejleszt az ember, eszközökben viszont egyértelmű az Oracle előnye.
Akit érdekel, jövőre miért lehet a Firebird a kedvence, az amúgy egyszerű kezelhetőségével, puritánságával, az kukkantson
ide.
[:6b4154cd4a]Asynchronous statement cancellation / timeouts
Monitoring via API and/or special tables
Detailed SQL tracing/profiling
Detailed logging/audit
DDL level and global triggers
PSQL debugging extensions/hooks
Reliable logical backup
Point-in-time recovery
Embedded users / SQL users management
User permissions for metadata
Pluggable authentication modules
Security groups
Database encryption
Faster outer joins
Optimizer improvements
More effective sorting
Optimized network protocol
More access paths
Temporary tables / transient datasets
More built-in functions
Schemas/namespaces
Native long numeric data type
Recursive queries
Regular expressions
TEXT BLOB compatible with [VAR]CHAR
Domains everywhere
Longer metadata names
Deferred constraints
SMP support in SS
Compiled statements cache
External functions/procedures
External data sources / database links / cross-database SQL
Statement/transaction consistency
Bi-directional indices
Bulk load/import
Referential integrity without indices
Full-text search
Clustering
Bi-directional cursors
XML integration
[/:u:6b4154cd4a][/b][/]
Az Oracle a végletekig konfigurálható, mindenfélét állíthatsz rajta. Ezért kell hozzáértő ember a beállításhoz, mert amennyit javítani lehet, annál többet tudsz rontani a teljesítményen. Az új verziókban (9 és 10) egyre több automatizmust, DBA munkát segítő szolgáltatást pakoltak bele.
A 10-ben akár már működnek is.
[quote:fb7e381194="LeoALo"][quote:fb7e381194="saabi"][quote:fb7e381194="LeoALo"]Ez így ebben a formában igaz. Nem is állítottam az ellenkezőjét. Ellenben jártam már olyan ügyfélnél, ahol két hetes volt a legújabb online mentés és egy kicsinke archivelog file-ocska sérülten lett kimentve...
Néha jól jöhet, ha a mentés önmagában logok nélkül konzisztens.
Hát, ez a fránya Oracle is olyan, hogy érteni kell hozzá. Ha az adatbázis visszaállíthatóságának az archive log az egyik kulcspontja, akkor azt talán rendszeresen kellene menteni, nem?
Ave, Saabi.
Egy vita végéhez szóltál hozzá. Az egész úgy kezdődött, hogy nem átallottam azt állítani, hogy mindamellett, hogy szeretem az Oracle-t és az egyik legjobb adatbáziskezelőnek tartom, mégiscsak vannak olyan funkciók, amik egy "ingyenes" (GPL...tudom nem ingyen, de most nem is ez a téma) adatbáziskezelőben megvannak de a drága Oracle-ben nem.
Erre volt egy példa a konzisztens online mentés, az adatbázis szintű snapshot stb...
Ha a konzisztens online mentés számodra azt jelenti, hogy adott pillanatban commit-tal lezárt tranzakciókat tartalmazó állapot lementése egy fájlba (és ezt az időpontot te tudod meghatározni), akkor igazad lehet (bár attól, hogy én nem tudok ilyenről, az Oracle lehet, hogy tudja...).
Ha a meghatározott t_null időpontra történő visszaállást lehetővé tévő mentésre gondolsz, akkor viszont nem kérdés, hogy van, sőt ennél messzebre is mentek Oracle-ék (flashback...)
Oracle esetén a mentésnek _része_ a log, tehát ha a log sérül a mentésed sérül. Más rdbms-nél is, ha sérül az adott snapshot-ot tartalmazó fájl(készlet), akkor szintén kenheted a hajadra...
[quote:dc131e26c4="mocsi"][quote:dc131e26c4="noss"]egy _picit_ tudományosabban elmondanátok, hogy _komolyabb_ feladatra miért kell kereskedelmi db és miért nem jó, miben marad el pl egy postgre?? lehet hosszan is válaszolni!
Csak a főbb előnyök:
1. Véded s@gged, hogy adnak hozzá szápportot
2. Ha gondod van, akkor rájuk hárítod, hogy nézzenek utána
3. Más termék gyártónál tudod verni a melled, hogy erre alapozzon, mert ez, papírra alapozva, ki van tesztelve.
csak csendben megjegyeznem,hogy a postgrest meg is lehet venni,es a postgresql inc ad hozza supportot is.
<szerk> oops. bocsi csak most latom ezt mar ellottek elottem </szerk>
[quote:b9b5babc44="mocsi"][quote:b9b5babc44="Frimen"]***
Lefogadom "bankos" vagy.. azok szoktak ennyi marhaságot összehordani.:))
***
Fri
Vagy pontazhogy nem bankos. Eddigi leírása alapján nem nagyon volt még közel komoly banki rendszerekhez, vagy nem engedték neki hogy eltérjen az előírástól amit egy programozó írt azon okból hogy le tudja fedezni a hátsóját...
Amúgy meg bírom azokat a nagyképű dumákat, hogy így komoly a banki rendszer, meg "bezzek a BANKI renszerek", nos ezt addig el is hittem én is, amíg bele nem csöppentem. Hát olyan példák vannak, hogy minősítő szoftvare VB alapokon (OTP), vagy nemzetközi banki átutalás Tuxedo, pgsql, LDAP, PKI, JBOSS meg egy csomó más alkalmazás egybegyúrásával (SWIFT rendszer), úgy hogy bizony néha egyes elemek elröppenek, vagy mondhatom a jó öreg MIDAS-t (igaz az AEB most állt át Symobls-ra, de mint a torkosborz...), ami még lockolást sem ismer, vagy még pár helyen futnak file alapú adatbázisnak csúfolt rendszerek (OTP, Budapest bank IBS-ei), melyek egy sima stornót nem engedélyeznek stb.stb. Naponta látom a rendszerünk működésében hogy: "Exception occured no XXXX, Transaction upload successfull" amit úgy oldottak meg, hogy beraktak egy if elágazást, hogy elrejtse a problémát. :D Nagy humbug az egész.
hadd ne mondjam a bankmaster/branchpower kliensoldalan meg a btrieve altal nyujtott tranzakciokezelesi kepessegeket sem aknazzak ki.
[quote:2ac3a8e893="zeller"]MaxDB-ben van flashback? De ne menjünk ennyire bele... Az Oracle esetén is megvannak azok az eszközök, amelyek az adatbázis _egy részének (táblatér, de van ilyenje sémára is...)_ teljes és online mentését/visszaállítását támogatják, csak használni köll tudni azokat. Egy recovery esetén meg gyakorlatilag mindegy, hogy 23 vagy 98 fájlt kell visszatölteni, max a kazettacserélő technikus fog anyázni esteleg... Ha meg jó SAN-od van az adatbázis alatt, akkor a táblaterenkénti onlány backup idejét -a storage megfelelő funkciójával- naggyon minimálisra le lehet szorítani, és az itt repkedő sokszáz GB-TB méretű adatbázisok esetén a SAN elég gyakori vendég...ű
Ez így ebben a formában igaz. Nem is állítottam az ellenkezőjét. Ellenben jártam már olyan ügyfélnél, ahol két hetes volt a legújabb online mentés és egy kicsinke archivelog file-ocska sérülten lett kimentve...
Néha jól jöhet, ha a mentés önmagában logok nélkül konzisztens.
[quote:8bd909debd="hokuszpk"]
csak csendben megjegyeznem,hogy a postgrest meg is lehet venni,es a postgresql inc ad hozza supportot is.
<szerk> oops. bocsi csak most latom ezt mar ellottek elottem </szerk>
(pici) Hazánkban is?
[quote:8fe46cbf84="mocsi"]
1. Ácsi, azt állítottad nincs benne, mármint az Oracle-ben most akkor ne térj el a tárgytól. Benne van, és az hogy mentesz vagy exportálsz adatok szempontjából tökmindegy, mindkettő visszaállít egy (konzisztens/nem konzisztens) állapotot, a többi kérdés technikai és management kérdés. Amúgy ami nekem max full export Oracle-el volt az egy 500GB, de 1 óra 12 perc alatt megvolt.
2. erről valamikor olvastam valamit, állítólag lehet, csak hivatalosan nem támogatott persze.
3. RMAN-al vissza lehet pörgetni állapotot, bár kell neki egy off-line recovery.
Amit a végén írsz egy nagyon erős flame, ugyanis az átlag 95% felhasználó/programozó egy sqlite/mysql 3.23-al is tökéletesen el lenne, nem beszélve hogy jóval kezelhetőbb és átláthatóbbak a számukra. Ezután jönnek a különleges igények, melyek figyelembe vételével kell a db technológiát kiválasztani, ami lehet pgsql, oracle, db2 sőt MaxDB is ;)
1., Mit állítottam? Hogy nem csinál konziszetns online mentést. Mit jelent ez? Hogy tudsz menteni, tudsz online menteni, csak kell hozzá a mentés kezdete és vége között készült összes logfile. A recovery végén a mentés végének állapota visszaállíthato. Ugyanez a MaxDB-nél úgy megy, hogy a mentés kezdetének pillanatában meglévő konzisztens állapotot tudod az online mentésből visszaállítani mineden log nélkül. Ki beszélt itt exportról? Az export nem mentés!!!! ( nem is egyenértékű. Érdekelne pl, hogyan "mentesz" le egy SAP adatbázist online konzisztensen exp-el figyelembe véve a maga kb 40000 adatbázisobjektumát.)
2. én nem, szerintem nem tudjuk eldönteni. Ha bebizonyítod hogy lehet készséggel elfogadom.
3. Igen, RMAN-al lehet, de ez nem más, mint egy recovery. Egyanúgy sokáig tart mint a sima visszatöltés.
Az erős flame-hez csak az a hozzátennivalóm, hogy kicsit talán pontosítanom kell. Én az SAP világot ismerem részletesebben. Itt meg nincs MySQL, meg Postgres. Itt Oracle, DB2, Informix, SQL Server és MaxDB van. Ezek közül a MaxDB az egyetlen GPL-es. És az SAP installációk 95%-ára értettem a mondanivalómat.
[quote:117ed435a9="hokuszpk"]
hadd ne mondjam a bankmaster/branchpower kliensoldalan meg a btrieve altal nyujtott tranzakciokezelesi kepessegeket sem aknazzak ki.
Hűhha, pedig eddig úgy tudtam a BMaster még egész jó a Symbols (pl. kötött termékmatrix nagyság) meg a SAP FI -hez képest.