Kezdd azzal, hogy a dbverify-t rázavarod a kérdéses táblatér kérdéses állományaira. Nyugodtan online állapotban mehet, mert az ellenőrzést nem direktben, hanem az adatbázison keresztül végzi.
Amelyiknél hibát jelez (ami lehet egy megtévesztő IO error is!), akkor próbáld meg OS szinten másolni, mindegy hová, csak teszt képpen.
Ha sikerül, akkor egyértelmű, hogy az állomány fizikailag nem sérült, vagyis a diszk-hiba kizárható.
Ebben az esetben, ugye logikai hibákról beszélhetünk, mert egy adatbázis blokk nem egyenlő egy diszk-blokkal!
Mivel igen sok rendszert ismerek ami oracle alapon hosszútávon megbízhatóan üzemel, igen valószínű, hogy nem az Oracle hibázik. Tehát, ha mégis hülyeségek kerülnek fizikailag az adatfile-okba, annak több oka is lehet.
Ha az előbb kizártuk a disk hibát, akkor még mindig lehet az IDE, vagy SCSI vezérlő döglődése (bár akkor fognál más hibákat is), vagy akár egy RAM modul is halódhat. Ez utóbbi még okozhatja is a dolgot, mivel az adatbázis műveletek zöme egy nagy, lefoglalt memória tartományban zajlik, s csak adott időközönként, vagy események hatására íródik ki az adatfile-okba. Az adatbázis írásakor a dbwriter process adatblokk szinten dolgozik, igazából logikai ellenőrzést nem végez. Ha az előző műveletek során az ellenőrzések rendben is találják a dolgokat, mire a dbw megkapja, addigra hülyeséggé alakulhat.
Hirtelen ennyi jut eszembe, szerény tapasztalataim alapján.
Ha van a HUP közelében oracle guru, akkor lécci javítson ki, ha valami nagy marhaságot mondtam volna! :-)
Annyit meg, hogy az egyik dbt nem tudom abszulte exportalni...
annak nem tudom eldonteni, hogy melyik tabla tere serult.
Lecsekkolom a teszt rendszert memtest -el + fsck .... a biztonsag kedveert aztan kiprobalom rajta hogy ez hatha segit
Kosz
Még annyit hozzátennék, hogy attól függetlenül, hogy megvan-e a hiba forrása vagy nincs, a hibás fejlécű adatfile gyógyításához nem kell feltétlenül visszaállítást csinálni.
Mi úgy szoktuk az ilyet megoldani, hogy egy kicsit megnöveljük az adatállomány méretét, ennek hatására újraszervezi a fejlécet és voila!
A pontos szintaxis most nem jut eszembe, mert lusta sysadmin lévén néhány segédprogram tudja ezt helyettem, de a doksikban valahol az ALTER DATABASE DATAFILE '<data_file_name>' RESIZE <n> K|M; környékén keresd!
Tobszor előfordult hogy az adatbázis partició megtelt ez okozhat problémát?
ext3 fs en van.
Lecsekkoltuk gyari dell memoriateszterrel azzal nem jelzet hibát.
[quote:5c2f0b6427="foci"]Tobszor előfordult hogy az adatbázis partició megtelt ez okozhat problémát?
ext3 fs en van.
Lecsekkoltuk gyari dell memoriateszterrel azzal nem jelzet hibát.
Sajnos memoria probléma volt!:((( (Az éles db szerverünkön)
A memtest a 6 GBRam ból 4 et tudod vizsgalni annak is a 12 % korul lefagyott....
Sajnos igy meg arra is szamitani lehet hogy a proci is megfott valamikor....
Mert hogy a memtest fagyott rajta....
A durvan 400 Mb rambol 1 Mb nyi hibas volt!!!
tobszor le se futtatom ...
Most mar csak az a gazom hogy nincs kozisztens db mentesem... merthogy amiket eddig neztem egyik sem jo:((
Na ez mar egy masik tortenet lesz....:(((
[quote:8ca9d9366e="zolix"]Remélem, sikerrel jársz!
Még annyit hozzátennék, hogy attól függetlenül, hogy megvan-e a hiba forrása vagy nincs, a hibás fejlécű adatfile gyógyításához nem kell feltétlenül visszaállítást csinálni.
Mi úgy szoktuk az ilyet megoldani, hogy egy kicsit megnöveljük az adatállomány méretét, ennek hatására újraszervezi a fejlécet és voila!
A pontos szintaxis most nem jut eszembe, mert lusta sysadmin lévén néhány segédprogram tudja ezt helyettem, de a doksikban valahol az ALTER DATABASE DATAFILE '<data_file_name>' RESIZE <n> K|M; környékén keresd!
Üdv, és sok sikert!
Én még nem voltam a cégnél mikor ezt telepitették, de amit lehetett elsz* tak rajta...
Az adatfilok méretét nem lehet megnovelni mert az maximumon van:)
Voltak kint a szervizbol memoriara a dell memtesztje azt mondta hogy patent!
Lecsekkoltuk az egész rendszert elvileg minden siraj rajta....
Most mar csak azt kellene kideritenem ha nem memoria/raid/hw akkor mi a halal van vele.
Tényleg lassan kizárásos alapon csak az lehet hogy elfogy a hely a particion akkor az beteszi neki az ajtot....
Ez is **** egy kicsit alul méretezték a helyet a gepen.... hat vegulis nem nagy szivatas.... de a ***** szivassák...
Hy!
Ven egy oracle 9i db szerverunk 3 dbvel.
Egy Dell PowerEdge 2600 szerveren 5 db scsi winyo hw raid 5 a disk alrendszer!
RedHat Ep. 3 OS.
Es 1 honapon belül másodszor sikerul corrupt blockot produkálnia a dbk ben!
Az elso alkalommal az egyik winyot ki kellet cserélni és utánna jelenkezet az első probléma most a visszajelzés szerint minden winyo oks.
A winyo cserekor elvileg elindult a rebuild - legalábbis a scsi bios szerint.
utánna kicsivel kiderült hogy korrupt blokkok vannak a dbkben....
volt egy helyreállitás a mult honap kozepén
aztan most megint sz* kerult a palacsintába.
Esetleg agonizálhat a raid tomb? valaki használ ilyet ??
....
vagy hogyan lehet ilyenkor elindulni debugolásban???
Mindenképp valahol az alaprendszerrel lehet bug (hw, os)
Sajna a cégem sporol az oracle tanfolyamon (egyenlore).... ahoz annyira nem értek.
esetleg erdemes bekapcsolni a DB_BLOCK_CHECKING opciot
google kw: "corrupt block oracle"
OS:
Ha az elozoek alapjan kiderult melyik page serult meg az adatfajlban, akkor lehet kezdeni hogy az filerendszeren ez melyik blokk(ok)ban talalhatok.
Nagyon szépen köszönöm a segítséget!
Legalább már nagyából azt tudom hogy milyen irányba induljak el!
1.Valszeg megnézem hogy IO error van e masoláskor(bar ezt a mentésekkor észre kellet volna venni).
2. Megprobálok memtestet futatni a szerveren
Memoria tesztre valami online dolog(???) mert valahogy mindig halál félelmem van ha le kell állitani a szervert...
Elvégre ez nem egy windows..
Csinaltam egy 'ls -r /' -t volt benne io error, de nem db fileok listázása közt:(((
Hozzászólások
Hi!
Kezdd azzal, hogy a dbverify-t rázavarod a kérdéses táblatér kérdéses állományaira. Nyugodtan online állapotban mehet, mert az ellenőrzést nem direktben, hanem az adatbázison keresztül végzi.
Amelyiknél hibát jelez (ami lehet egy megtévesztő IO error is!), akkor próbáld meg OS szinten másolni, mindegy hová, csak teszt képpen.
Ha sikerül, akkor egyértelmű, hogy az állomány fizikailag nem sérült, vagyis a diszk-hiba kizárható.
Ebben az esetben, ugye logikai hibákról beszélhetünk, mert egy adatbázis blokk nem egyenlő egy diszk-blokkal!
Mivel igen sok rendszert ismerek ami oracle alapon hosszútávon megbízhatóan üzemel, igen valószínű, hogy nem az Oracle hibázik. Tehát, ha mégis hülyeségek kerülnek fizikailag az adatfile-okba, annak több oka is lehet.
Ha az előbb kizártuk a disk hibát, akkor még mindig lehet az IDE, vagy SCSI vezérlő döglődése (bár akkor fognál más hibákat is), vagy akár egy RAM modul is halódhat. Ez utóbbi még okozhatja is a dolgot, mivel az adatbázis műveletek zöme egy nagy, lefoglalt memória tartományban zajlik, s csak adott időközönként, vagy események hatására íródik ki az adatfile-okba. Az adatbázis írásakor a dbwriter process adatblokk szinten dolgozik, igazából logikai ellenőrzést nem végez. Ha az előző műveletek során az ellenőrzések rendben is találják a dolgokat, mire a dbw megkapja, addigra hülyeséggé alakulhat.
Hirtelen ennyi jut eszembe, szerény tapasztalataim alapján.
Ha van a HUP közelében oracle guru, akkor lécci javítson ki, ha valami nagy marhaságot mondtam volna! :-)
Annyit meg, hogy az egyik dbt nem tudom abszulte exportalni...
annak nem tudom eldonteni, hogy melyik tabla tere serult.
Lecsekkolom a teszt rendszert memtest -el + fsck .... a biztonsag kedveert aztan kiprobalom rajta hogy ez hatha segit
Kosz
Remélem, sikerrel jársz!
Még annyit hozzátennék, hogy attól függetlenül, hogy megvan-e a hiba forrása vagy nincs, a hibás fejlécű adatfile gyógyításához nem kell feltétlenül visszaállítást csinálni.
Mi úgy szoktuk az ilyet megoldani, hogy egy kicsit megnöveljük az adatállomány méretét, ennek hatására újraszervezi a fejlécet és voila!
A pontos szintaxis most nem jut eszembe, mert lusta sysadmin lévén néhány segédprogram tudja ezt helyettem, de a doksikban valahol az ALTER DATABASE DATAFILE '<data_file_name>' RESIZE <n> K|M; környékén keresd!
Üdv, és sok sikert!
Tobszor előfordult hogy az adatbázis partició megtelt ez okozhat problémát?
ext3 fs en van.
Lecsekkoltuk gyari dell memoriateszterrel azzal nem jelzet hibát.
[quote:5c2f0b6427="foci"]Tobszor előfordult hogy az adatbázis partició megtelt ez okozhat problémát?
ext3 fs en van.
Lecsekkoltuk gyari dell memoriateszterrel azzal nem jelzet hibát.
A gyari memtest hazudik... :evil:
Ja de ezert mert nem garis probléma volt most perkalhatunk, hogy false volt a memoria problem.. :((
Sajnos memoria probléma volt!:((( (Az éles db szerverünkön)
A memtest a 6 GBRam ból 4 et tudod vizsgalni annak is a 12 % korul lefagyott....
Sajnos igy meg arra is szamitani lehet hogy a proci is megfott valamikor....
Mert hogy a memtest fagyott rajta....
A durvan 400 Mb rambol 1 Mb nyi hibas volt!!!
tobszor le se futtatom ...
Most mar csak az a gazom hogy nincs kozisztens db mentesem... merthogy amiket eddig neztem egyik sem jo:((
Na ez mar egy masik tortenet lesz....:(((
[quote:8ca9d9366e="zolix"]Remélem, sikerrel jársz!
Még annyit hozzátennék, hogy attól függetlenül, hogy megvan-e a hiba forrása vagy nincs, a hibás fejlécű adatfile gyógyításához nem kell feltétlenül visszaállítást csinálni.
Mi úgy szoktuk az ilyet megoldani, hogy egy kicsit megnöveljük az adatállomány méretét, ennek hatására újraszervezi a fejlécet és voila!
A pontos szintaxis most nem jut eszembe, mert lusta sysadmin lévén néhány segédprogram tudja ezt helyettem, de a doksikban valahol az ALTER DATABASE DATAFILE '<data_file_name>' RESIZE <n> K|M; környékén keresd!
Üdv, és sok sikert!
Én még nem voltam a cégnél mikor ezt telepitették, de amit lehetett elsz* tak rajta...
Az adatfilok méretét nem lehet megnovelni mert az maximumon van:)
Voltak kint a szervizbol memoriara a dell memtesztje azt mondta hogy patent!
Lecsekkoltuk az egész rendszert elvileg minden siraj rajta....
Most mar csak azt kellene kideritenem ha nem memoria/raid/hw akkor mi a halal van vele.
Tényleg lassan kizárásos alapon csak az lehet hogy elfogy a hely a particion akkor az beteszi neki az ajtot....
Ez is **** egy kicsit alul méretezték a helyet a gepen.... hat vegulis nem nagy szivatas.... de a ***** szivassák...
Hy!
Ven egy oracle 9i db szerverunk 3 dbvel.
Egy Dell PowerEdge 2600 szerveren 5 db scsi winyo hw raid 5 a disk alrendszer!
RedHat Ep. 3 OS.
Es 1 honapon belül másodszor sikerul corrupt blockot produkálnia a dbk ben!
Az elso alkalommal az egyik winyot ki kellet cserélni és utánna jelenkezet az első probléma most a visszajelzés szerint minden winyo oks.
A winyo cserekor elvileg elindult a rebuild - legalábbis a scsi bios szerint.
utánna kicsivel kiderült hogy korrupt blokkok vannak a dbkben....
volt egy helyreállitás a mult honap kozepén
aztan most megint sz* kerult a palacsintába.
Esetleg agonizálhat a raid tomb? valaki használ ilyet ??
....
vagy hogyan lehet ilyenkor elindulni debugolásban???
Mindenképp valahol az alaprendszerrel lehet bug (hw, os)
Sajna a cégem sporol az oracle tanfolyamon (egyenlore).... ahoz annyira nem értek.
Oracle javitas:
1) dbv (dbverify): offline datafajlokat tudsz vele ellenorizni
2) utlverify.sql beolt, majd:
analyze table mytable validate structure
analyze index myindex validate structure
3) dbms_repair csomag
4) visszaallitas mentesbol
esetleg erdemes bekapcsolni a DB_BLOCK_CHECKING opciot
google kw: "corrupt block oracle"
OS:
Ha az elozoek alapjan kiderult melyik page serult meg az adatfajlban, akkor lehet kezdeni hogy az filerendszeren ez melyik blokk(ok)ban talalhatok.
Bovebben ext2/ext3 eseten:
http://smartmontools.sourceforge.net/BadBlockHowTo.txt
Nagyon szépen köszönöm a segítséget!
Legalább már nagyából azt tudom hogy milyen irányba induljak el!
1.Valszeg megnézem hogy IO error van e masoláskor(bar ezt a mentésekkor észre kellet volna venni).
2. Megprobálok memtestet futatni a szerveren
Memoria tesztre valami online dolog(???) mert valahogy mindig halál félelmem van ha le kell állitani a szervert...
Elvégre ez nem egy windows..
Csinaltam egy 'ls -r /' -t volt benne io error, de nem db fileok listázása közt:(((
masolás később....
Kösz a tippeket