| DBVerify issue [message #592450] |
Thu, 08 August 2013 08:54  |
8939513598$
Messages: 103
Registered: July 2013
Location: chennai
|
Senior Member |
|
|
how to repair the blocks that gets corrupted found in dbverify, what usually happens in the real-time scenario?
|
|
|
|
|
|
| Re: DBVerify issue [message #592454 is a reply to message #592450] |
Thu, 08 August 2013 09:18  |
John Watson
Messages: 8960
Registered: January 2010
Location: Global Village
|
Senior Member |
|
|
|
What's going on, man? It is hard to believe that you have suddenly been faced with all the errors that you have reported today. Specially not on an ancient release of Oracle that is in sustaining support as of last week.
|
|
|
|
|
|
| Re: DBVerify issue [message #592562 is a reply to message #592450] |
Fri, 09 August 2013 11:36 |
 |
LKBrwn_DBA
Messages: 487
Registered: July 2003
Location: WPB, FL
|
Senior Member |
|
|
If you cannot recover as suggested by Michel or BlackSwan, try using DBMS_REPAIR.FIX_CORRUPT_BLOCKS Procedure to fix it. If that does not work either, you can use the DBMS_REPAIR.SKIP_CORRUPT_BLOCKS Procedure temporarily while you export/import/rebuild the affected object (you will loose the rows from that block).
Good luck!
PS: I agree with Mr Watson, all these errors seem to indicate you did/are doing something wrong like suddenly re-booting the server without closing the database and/or killing the oracle process in the middle of executing a ddl statement or whatever unconventional method that stops the database.
[Updated on: Fri, 09 August 2013 11:45] by Moderator Report message to a moderator |
|
|
|
|
|
| Re: DBVerify issue [message #592578 is a reply to message #592568] |
Fri, 09 August 2013 13:33 |
|
LKBrwn_DBA
Messages: 487
Registered: July 2003
Location: WPB, FL
|
Senior Member |
|
|
Oracle® Database PL/SQL Packages and Types Reference
FIX_CORRUPT_BLOCKS Procedure
This procedure fixes the corrupt blocks in specified objects based on information in the repair table that was previously generated by the CHECK_OBJECT Procedure.
Prior to effecting any change to a block, the block is checked to ensure the block is still corrupt. Corrupt blocks are repaired by marking the block software corrupt. When a repair is effected, the associated row in the repair table is updated with a fix timestamp.
[Updated on: Fri, 09 August 2013 13:48] by Moderator Report message to a moderator |
|
|
|
| Re: DBVerify issue [message #592579 is a reply to message #592578] |
Fri, 09 August 2013 13:40 |
John Watson
Messages: 8960
Registered: January 2010
Location: Global Village
|
Senior Member |
|
|
You can get some pretty weird results if you use this. The fact that the "fixed" blocks are simply skipped means that a query that actually reads the table will not return the rows in the fixed blocks. But another query (such as a count) that can be satisfied by reading an index returns all the rows. I did once go through the process of identifying the missing rows by looking at the indexes, and re-creating them from the column values in the indexes. It is not easy and of course you lose all the data in non-indexed columns, but if you really can't lose a row, OK.
If you ever have to do this, good luck!
|
|
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
