| ORA-00368,00353,00312. [message #379593] |
Wed, 07 January 2009 04:03  |
abdulaziz
Messages: 102
Registered: May 2008
Location: Douala
|
Senior Member |
|
|
Hello,
Here's an usual behvior that my database presented to me yesterday at startup:
C:\Documents and Settings\Administrateur>sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 - Production on Mar. Janv. 6 18:47:40 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn / as sysdba
ConnectÚ Ó une instance inactive.
SQL> startup
Instance ORACLE lancÚe.
Total System Global Area 167772160 bytes
Fixed Size 1247900 bytes
Variable Size 75498852 bytes
Database Buffers 88080384 bytes
Redo Buffers 2945024 bytes
Base de donnÚes montÚe.
ORA-00368: erreur de total de contr¶le dans le bloc du journal redo
ORA-00353: journal endommagÚ prÞs du bloc 56436, modification 34359662,
horodatage 01/06/2009 06:28:29
ORA-00312: journal en ligne 1 thread 1 :
'D:\ORACLE\PRODUCT\10.2.0\ORADATA\META4\TEST\REDO01.LOG'
SQL>
Can anyone please help me fix that?
I went through some solutions over the net such as setting an undocumented parameter -allow_resetlogs_corruption=true or performing an incomplete recovery or a recovery until a SCN, but I would rather check with you guys what can be the best set actions in such case.
This is a database in which I perform tests before going to prod. It runs in ARCHIVELOG mode but I have never taken a backup of it. I hope my case isn't hopeless.
Thanks in advance.
|
|
|
|
|
|
|
|
| Re: ORA-00368,00353,00312. [message #379672 is a reply to message #379670] |
Wed, 07 January 2009 10:04  |
Frank Naude
Messages: 4579
Registered: April 1998
|
Senior Member |
|
|
00368, 00000, "checksum error in redo log block"
// *Cause: The redo block indicated by the accompanying error, is not
// vaild. It has a checksum that does not match the block contents.
// *Action: Do recovery with a good version of the log or do time based
// recovery up to the indicated time. If this happens when archiving,
// archiving of the problem log can be skipped by clearing the log
// with the UNARCHIVED option. This must be followed by a backup of
// every datafile to insure recoverability of the database.
// *Action: Restore correct file or reset logs.
00353, 00000, "log corruption near block %s change %s time %s"
// *Cause: Some type of redo log corruption has been discovered. This error
// describes the location of the corruption. Accompanying errors
// describe the type of corruption.
// *Action: Do recovery with a good version of the log or do incomplete
// recovery up to the indicated change or time.
Next steps:
1. As the OS guys to check the system's disks for problems that can cause file corruption.
2. Perform incomplete recovery on the DB.
|
|
|
|
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
. I haven't added other members to those group, neither did I create other groups. 
