Oracle hianyzo Offline Redolog File

Adatbázis: SQL, XML DB

Sziasztok,

van valakinek otlete hogy Oracle-nel hogy tudnek csak egyetlen egy Offline Redolog File-t (archive log) egy meghatarozott Szekvenciaval megint letrehozni?
Az adatbazis Archive Modus-ban uzemel. Szepen irja ki az Offline log-okat. Valamilyen okbol eltunt egy szekvenciam amire szuksegem lenne,mert ezekkel az offline logokkal frissitem a helyi teszt adatbazisunkat. Az eles szerverunk es a teszt szerverunk kozott eleg gyer a berelt vonal halozati sebessege,ezert nem szeretnek az eles szerverrol megint egy full RMAN backup-ot kesziteni. Emiatt mindig csak a valtozasokat szinkronizalom offline redologs formaban.
Lehet egyaltalan csak egyetlen egy offile redolog-ot visszaallitani?
Oracle 11g-t hasznalok Standard One intallation-al.
Koszonom elore is a valaszokat.

  • 4433 megtekintés

( asdPro | 2014. 03. 26., sze – 13:14 )

Szia, van backupod az archive logokról? Ha igen, RMAN-nal restore.

Sajnos a backup Script valamiert pont ezt az egy log-ot nem szinkronizalta a Backup Szerverre. Persze hibauzenetet nem latok. (ennek meg utana kell jarjak mi lehetett a hiba. Ez egy sajat shell script..)
A problemara nem figyeltem fel csak hetekkel kesobb amikor eszleltem,hogy nem aktualizalja magat a teszt adatbazis. Ekkor mar viszont keso volt,mert a takarito Script letorolte az elavultnak velt Offline Redologokat.

"Jede Loesung eines Problems ist ein neues Problem"

Teljesen biztos, hogy ahova menti a logokat, onnan kitörölte a kérdéses szekvenciát? (A törlő script logjában is szerepel, hogy törölve lett? ) Továbbá biztos, hogy nem készült backup róla?

LIST BACKUP OF ARCHIVELOG SEQUENCE xxxx;

A scriptre / logra azért vetnék egy pillantást, hátha kiderülne, mi történt. Ha gondolod, elküldheted PM-ben.

A Katalogban szerepel. A fajl letrejott:

132586 1 132777 A 14-FEB-14
Name: /dmp/archive/1_132777_653231184.dbf

SCP Script Log:

15.02 01:44:00 EXEC: scp -p /opt/oracle/bin/push_archive_log_001.sh.CGaVg24895/1_132777_653231184.dbf.gz "backup@172.16.31.1:oracle/archive"
15.02 02:30:01 START: RESETLOGS_ID:653231184 SRC_DIR:/dmp/archive SSH_URL:backup@172.16.31.1 DEST_DIR:oracle/archive
15.02 02:30:01 ABBRUCH - Eine weitere Instanz des Scripts laeuft schon
TERM environment variable not set.
15.02 03:30:01 START: RESETLOGS_ID:653231184 SRC_DIR:/dmp/archive SSH_URL:backup@172.16.31.1 DEST_DIR:oracle/archive
15.02 03:30:01 ABBRUCH - Eine weitere Instanz des Scripts laeuft schon
TERM environment variable not set.
ssh_exchange_identification: read: Connection reset by peer
lost connection
15.02 03:44:00 EXEC: rm -v /opt/oracle/bin/push_archive_log_001.sh.CGaVg24895/1_132777_653231184.dbf.gz
15.02 03:44:00 /opt/oracle/bin/push_archive_log_001.sh.CGaVg24895/1_132777_653231184.dbf.gz entfernt


Az atvitel soran hiba tortent "lost connection" amit ez a szkript nem kezel le..( nem en irtam...),sikeresnek veszi a kuldest,ergo tobbszor nem probalkozik a kuldessel..
Nem vettem idoben eszre,hogy a teszt adatbazis nem frissiti magat igy ez a szekvencia sem lokal sem pedig backupban nincs meg. Enelkul meg nem tudom frissiteni az adatokat a teszt szerveren. Ki kellene hagynom ezt a szekvencia szakaszt. Vagy kellene csinalnom megint egy RMAN Full Sicherungot ami kb. 3 nap lenne mig bejon a berelt vonal lassusaga miatt..ezert kerdeztem,hogy ismertek-e valami lehetoseget csak ennek az egy szekvencianak az ujboli letrehozasara..en nem igazan talaltam ra megoldast a neten.

"Jede Loesung eines Problems ist ein neues Problem"

Most elgondolkoztam, hogy mit is szeretnél vajon:
Az Oracle írja ki neked a logba, hogy mit csinált egyszer valamikor régen?

Feltételezem, már nem emlékszik rá :-)

Vagy csak létrehozni egy üres logfájlt, a jó ID-val?
De ha ez sikerülne, akkor azok a változások, amik az elveszett fájlban vannak, nem kerülnének bele a második adatbázisodba, szóval nem lenne szinkronban a kettő.
Szóval ez nem tűnik jó iránynak.

Hogy nem lenne szinkronban a kettő, az a kisebb gond.
De egyrészt az üres logfájlon úgy elhasal a recover, hogy öröm nézni (tapasztalat :DDD), másrészt, miután nem az utolsó hiányzik, ez nem egyszerűen inkonzisztens állapotot idézne elő, hanem egy fizikailag sérült adatbázist, ha az eredetitől eltérő tartalmút tennél a hiányzó helyére.
Ezek ugyanis az adatblokkok módosításait rögzítik, ami akár a rendszertáblákhoz vagy egyéb állományokhoz is tartozhatnak.

Leggyorsabb megoldás jelen esetben az lenne, ha kiraknák az egész backupot egy külső vinyóra (ha van olyan, amire ráfér), azt egy futár elvinné a másik telephelyre és ott betöltenék, majd ráküldenék az azóta keletkezett archív logokat. (bár az nem teljesen világos, hogy hogyan használják a másik adatbázist, mert abban a pillanatban, ahogy leállítja a recovert és használni kezdi, többé az eredeti archív logokat nem lehet rátölteni...)

A teszt adatbazis egy KVM virtual installacio. Az oracle Instance RMAN Restore Database-el van visszatoltve aztan csinalunk egy KVM snapshot-ot. Napi frissitesnel visszajatszuk az elozo KVM Snapshot-ot,ilyenkor MOUNTED Stand-ban van az adatbazis. Aktualizaljuk az offline redologokat,majd recover database, aztan alter database open resetlogs. Majd masnap kezdodik az egesz elorol. A kvm snapshot-ok Script altal rotalodnak.

"Jede Loesung eines Problems ist ein neues Problem"

Ja, így már nagyjából értem. (sajnos nagyon rég kiestem az oracle témából és azt a többi dologtól eltérően igyekeztem is elfelejteni :( )

---
Reset logs: két-három hétig szopatott az indiai oracle support, mert nem akart elindulni az incomplete recover után az adatbázis... végül magamtól jöttem rá, hogy a szkriptemből kimaradt a reset logs. Az indiainak sem tűnt fel. :D
Felejthetetlen élmény volt, hogy mennyit ér a fizetős support is. :(

Mi is most gondolkozunk egy cseren,mert egy teljes embert igenyelne csak az oracle adminisztracio..igazabol magat az adatbazist at tudnank ultetni postgres ala. a baj azzal van hogy hasznalunk Oracle Forms-t is. Igy az atultetes egy uj valalat iranyitasi szoftver fejöesztessel jarna. Amig ez nem tortenik meg,addig egy standard One Oracle verziobol kell kihoznunk a maximumot:-)

"Jede Loesung eines Problems ist ein neues Problem"

Mondjuk nem teljesen értem, hogy ez miért kizárólag a support meg az Oracle sara, mivel szó szerint az első találat google-n az incomplete recovery-re azt mondja, hogy kell resetlogs :) A support meg egyébként teljesen felemás, volt az, amit te is említettél, hogy inkompetesek (ezek elsősorban azok voltak, akikhez beestek a kérések, de eszkaláció után már jobb volt a helyzet), viszont olyan is volt, hogy fél órán belül(!) válaszoltak, összerittyentettek egy teszt környezetet, és azon nyomban reprodukálták a dolgot, és nem is volt kritikus a hiba. Szóval értem én a felháborodást, de azért na :)

( uid_7086 | 2014. 03. 26., sze – 14:22 )

Az eltűnés okára lenne tippem, de ezt javítani... szerintem esélytelen.

( frottirtigris | 2014. 03. 27., cs – 09:01 )

Az offline redo log elvesztese azt jelenti, hogy restore csak addig a pontig lehetseges.
A megoldas egy azonnali full (online/offline ez mar vegeredmenyben mindegy) backup.
Ha nincs eredeti full backupod, akkor meg ugyis mindegy, hogy hova koltozott az offline redo log.
Masreszt sulyos hianyossag, hogy a masolas sikeresseget nem ellenorzi a script.

Hat rendesen lefaragta az idegrendszerem amikor szembesultem a dolgokkal. Az elottem levo rendszergazdak egyikenek az oroksege ez. Idaig jol mukodott, nekem meg nincs idom az osszes orokolt Script atnezesere. Vagyis nem adnak ra idot. KB azokat a reszeket neztem csak at amik esetleg veszelyesek lehetnek a termelesre. Most meg kicsit varnuk kell majd a fejlesztoknek az aktualis adatokra mig bejon a Full backup...
"Jede Loesung eines Problems ist ein neues Problem"