Hali,
volna egy adatbazisom oracle alatt. Van jopar dbf file, meretben ugy ~30GB. Ezek 3 konyvtar alatt helyezkednek el.
Van egy uj VG, ahova at akarom helyezni az egeszet.
Az en elmeletem:
- uj archive log allomanyok az uj VG-ben (sok hely miatt) - alter database ....
- oracle online backup mode-ba rakasa
- dbf allomanyok atmasolasa az uj konyvtarba
- oracle leaallitasa
- oracle inditasa nomount parameterrel
- dbf allomanyok atirasa az oracle alatt (alter database) - akar scripttel
- oracle elinditasa (mount, ragorgetes, ...)
Az adatbazis csak minimalis ideig allhat.
Ez igy mukodhet?
Udv,
battila
- 1118 megtekintés
Hozzászólások
A jó rendszergazd mv segítségével átmozgatja, a többit oldja meg a DBA. :D
--
2e845cb4c3a5b5bd6508455b1739a8a2
- A hozzászóláshoz be kell jelentkezni
Bár a verziót nem írtad, de nagyjából működőképesnek tűnik a koncepció.
Mondjuk backup módban shutdown abort-ot kell szerintem mondanod, hogy utána a következő induláskor media recovery-vel kezdjen, ha jól emlékszem.
- A hozzászóláshoz be kell jelentkezni
Nem. Abortalni ilyenkor kivaltkepp nem erdemes. Sot, a backup modeot is ki kell kapcsolni a tiszta (immediate) leallas elott, a kulonbseg majd az achivelogokbol helyreallithato. A cel oldalon majd ugy is manualisan indit recovery-t, mount allapotbol. Hogy biztosan ne legyen elveszett tranzakcio, listener leallit, user folyamatok kilo, utolso redolog manualisan archival.
- A hozzászóláshoz be kell jelentkezni
Szoval backup modban nem lehet leallitani az oracle-t? Minel kevesebb problemat szeretnek a dba-ra hagyni.
- A hozzászóláshoz be kell jelentkezni
Backup módban nem lehet leállítani az oracle-t, csak a shutdown abort megy.
A korrekt eljárásmód, hogy normál leállítás előtt ki kell venni backup módból (különben örökké várni fogja, hogy a backup mód véget érjen).
- A hozzászóláshoz be kell jelentkezni
Jó, igaz, az épp tranzaktáló kliensekkel nem számoltam.
De az én fejemben is az volt, hogy listener le, userek kilő, és utána a bármit is, ez megnyugtatóbb.
- A hozzászóláshoz be kell jelentkezni
OS-t nem irtal. Ez azert lenne fontos, mert van par olyan LVM amivel ezt leallas nelkul, storage szinten is meg lehet oldani DBA ismeret/beavatkozas nelkul. AIX (4.3+) alatt pl sokszor csinaltam hasonlot.
Amit leirsz, az mukodhet, de az ordog mindig a reszletekben bujik meg. Ha az adatbazis nem allhat sokaig, akkor legyen melletted egy legalabb kozepesen kepzett es magabiztos DBA a varatlan helyzetekre.
Storage szitntu koltoztetesi modszer tomoren:
Az osszes uj disk atrakasa a regi VG-be, sync, majd a regi diskek felszabaditasa es szabad ujrafelhasznalasa.
- A hozzászóláshoz be kell jelentkezni
A regi VG-t nem tudom/akarom hasznalni. Sajnos a letrehozasakor olyan parameterek lettek beallitva:
Max PV 16
Max PE per PV 4342
es most van benne 16 disk. Ezt nem akarom/tudom vinni magammal a jovoben. Ha akarnam vinni, akkor hasznalnam a pvmove-ot. De ez nem opcio most. Erdekes meg az OS?
Az akciot nem en csinalnam. En csak kitalaltam, es tudni szeretnem, hogy mi a bokkeno? Az en reszem termeszetesen a unix resze, az db reszt dba fogja csinalni. Most nem szeretnek kiterni ra, hogy miert nem oket kerdezem meg rola.
Koszi
- A hozzászóláshoz be kell jelentkezni
Ha a DBA-val egyeztettel es o is jelen lesz, akkor semmi gond.
Backup modban ne allj le, elotte vedd ki az adatbazist backup modebol. A masolas utani tranzakciokat tartalmazo archivelogokat pedig majd a recovery folyamat applikalja.
- A hozzászóláshoz be kell jelentkezni
Ha meglesznek az uj diszkek, akkor tudok majd csinalni teljesitmenytesztet a masolasrol.
Felmerult, hogy esetleg tovabb tart ratolni a trancakciologokat, mint ha leallitom es kis darabokban, tobb lepesben atmasolom a a fileket.
Van 51 db file, osszesen ugy 18 GB (ujraszamoltam:)). Felosztom 5 reszletre, akkor leallas+elinditas+copy darabonkent 4-8 perc. Megcsinalom 5 nap alatt es mindenki boldog. Persze, ha gyorsak a diszkek, akkor lehet kevesebb reszletben is.
- A hozzászóláshoz be kell jelentkezni