10:03 received the resource synchronization library of the outage alarm, log in the database to verify that the database is indeed abnormal, the first response to manually restart the library, but still failed.
Look back at the database alarm log, found a large number of 600 and 7445 error
Look at the trace file and discover that it is an update to the same table T_product_addr_6_8_temp_area:
After a continuous error, the database itself has a bad block recover operation
After the successful recovery from the online log, there is still a similar error message, and finally the database directly downtime
"Analysis Process" 1. According to the database error information involved in the two data file number information, in the database boot to mount state, the following script to query the corresponding data file
2. Use the DBV tool to see if there are logical bad blocks
found that the data file Repgx11.dat does have a bad block 3. Check the host log, no IO related error 4. Login Resource Sync library with storage EVA8100 and EVA6400 view, no abnormal error messages 5. The rest is to consider how to recover the problem: from the above error message can be seen due to the existence of a bad block, causing the transaction is different Often but cannot be rolled back, Smon no longer recover dead transaction after setting event= ' 10513 Trace name Context forever,level 2 ' internal event, the database will open normally. The database resumes normally.
6. Although the database open normally, but the bad block problem still exists, through the warning log information file, block 367365 to find the object of the bad block
Consistent with the action object indicated in the trace file, by rebuilding the table and rename interchange to resolve the problem after swapping: 7. Modify Pfile, delete event time, restart database with SPFile, normal, database no similar exception error 8. Verify that the problem file is back to normal by DBV "Subsidiary notes" 1. If the bad block still exists after rebuilding the table, you can delete the original table, and then use the CREATE TABLE command to overwrite the data block of the original logical bad block, to avoid the ORA-600 problem occurring again. CREATE TABLE large_table (t1 int) tablespace Rep_gx;alter table Large_table allocate extent (DataFile '/dsgdata/zydata/re Pgx17.dat ' size 10M); 2. If the database is in archive mode and has a backup, you can recover rman> blockrecover datafile 367365 from Backupset via Rman;
Database bad block triggers ora-00600 and ora-07445