Proalpha ERP Alkamzasas adatbazis (OpenEdge) BAckup ötletek

Sziasztok

szeretnek egy kis tapasztalatra szert tenni, hogy ki milyen Backup megoldasokat hasznalna/hasznal egy Proalpha ERP alkalmazas mentesehez. Az alkalmazas alatt OpenEdge adatbazis fut.
Mivel eddig meg nem volt dolgom OpenEdge-el,ezert szeretnek elotte informaciokat,tanacsokat gyujteni..

Hozzászólások

Egyreszt ugy, ahogy az openedge alapbol javasolja, masreszt VM-be az egeszet es atan lehet azt menteni.

a kerdes szamomra igazabol az,hogy hasznaljak-e .ai file-t vagy eleg a heti egy online full backup+napi inkrement delta. A restore ideje sem mindegy. Gondolok itt arra,hogy mig az ai file teljes tranzakciokat tartalmaz addig az inkrement csak adatbazis blokkokat...Egyelore sajnos a VM kornyezet nem megoldhato.

"Jede Loesung eines Problems ist ein neues Problem"

Attól függ, hogy mi a célod, milyen időpontokra akarod tudni visszaállítani az adatbázist. Az blokkszintű inkrementális mentés és az AI mentés között az a különbség, hogy az előbbit csak a mentés megkezdésének pillanatára, az utóbbit pedig bármely tranzakció végrehajtása előtti állapotra vissza lehet állítani. Cserébe a blokkszintű mentés nagyon gyorsan, az AI mentés pedig ennél lassabban állítható vissza (az utóbbi esetben ténylegesen végrehajtásra kerül minden rögzített tranzakció, amihez kellhet egy rakás erőforrás).

Egyébként ha Progress-t látnék és tehetném, én futnék :-D

Nem túl jók a tapasztalataim vele.

Viszonylag sok és sokféle adatbázis üzemeltetésében veszek részt (Progress/OpenEdge, Firebird, MySQL, PostgreSQL, MSSQL, Oracle - összesen ~200 instance és ~1000 adatbázis) és a felsoroltak közül a Progress a legrosszabban működő adatbázismotor. Néhány érv, hogy miért:

- Teljesítményben elmarad a többiektől. Ennek szerintem az az elsődleges oka, hogy a Progress 4GL nyelven megírt programok nem annyira optimalizáltak/optimalizálhatóak, kevesebb figyelmet kaptak az elmúlt 10-20 évben, mint az SQL nyelvet használó programok. Emiatt kevésbé optimálisak a lekérdezések végrehajtásai az adatbázison.
- A kevésbé optimális működéssel összefügg, hogy a Progress-nek jóval magasabb az IO-igénye, mint a többi adatbáziskezelőnek. Volt egy összehasonlításom nemrég Progress és PostgreSQL között, az előbbinek kb. 3x annyi blokkműveletre volt szüksége az adott workload kiszolgálásához, mint az utóbbinak.
- Menedzsment szempontból sokminden nem optimális a Progress-ben. Például ha a tompos által emlegetett módon a VM-et akarod elmenteni, akkor 1) szólni kell az adatbázisnak, hogy most mentve leszel, ennek hatására az adatbázisba nem lehet írni semmilyen módon (!), 2) el kell snapshotolni a VM-et, 3) szólni kell az adatbázisnak, hogy el vagy mentve, mehetsz tovább. Más adatbáziskezelők ilyenkor nem feltétlenül tiltják az írást, inkább csinálnak pl. delta fájlokat, amelyeket később rá lehet görgetni az adatbázisra. A Progress-nél nem.
- A menedzsment tooljai nagyon kézzel való futtatásra vannak kihegyezve és kevéssé scriptelhetőek. Egyik példám, hogy a probkup, amivel mentést lehet készíteni nem tud az STDOUT-ra írni, kizárólag fájlba, így nem tudod a mentést keresztülnyomni mondjuk egy gzip filteren. Persze meg lehet kerülni, írhatsz egy named pipe-ba, de ez egyrészt elég tré, másrészt meg a 9-es Progressben egy hiba miatt néha nem működik.
- A másik példám a menedzsmentre az AI fájlok kezelése, ami egyrészt kényelmetlen, másrészt pedig nagyon sok hibalehetőséget rejt magában. Pl. mi van, ha a mentés közben körbeírja valaki a fájlokat? Mégcsak elvileg sem lehet észre sem venni. Pl. egy Oracle esetében ez meg van oldva a redo log/archive log mechanizmussal okosan.
- Mindezek mellett viszonylag rossz a supportjuk, pl. a Firebird magasan veri ebben a tekintetben.

Szóval ezekért.

YMMV

Koszi az infot. Most huzok fel eppen egy teszt kornyezetet, ahol kicsit megismerjuk egymast a Progress-el..:-) Ami mar biztosnak tunik az az,hogy az .ai file-t kell hasznaljak..Kovetelmeny,hogy a tranzakciok fugvenyeben lehessen kezelni a BAckup-ot. Sajnos a futas nem opcio,igy maradt a Progress megszeliditese..:-)

"Jede Loesung eines Problems ist ein neues Problem"