RE: ora-1555 on physical standby (no active data guard)

  • From: Laimutis.Nedzinskas@xxxxxx
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Thu, 6 Feb 2014 14:33:49 +0200

Thanks Stephan

Unfortunately, the note reassures that Oracle does not have the answer what
causes the corruption in the first place.
Imagine healing 5000+ blocks as in my case: the potential number of trace
files alone can become quite an issue.

Currently we have a hypothesis that the corruption is caused by 11g standby
software failing on migrated 10g blocks. The indexes we've rebuilt stop
failing.
It's an interesting prospect of having to rebuild all database indexes
after migration: with some luck we might be able to do that without
downtime.


Brgds, laimis N





---------------------------------------------------------------------------------

Please consider the environment before printing this e-mail


|------------>
| From:      |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |"Uzzell, Stephan" <SUzzell@xxxxxxxxxx>                                       
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |"'Laimutis.Nedzinskas@xxxxxx'" <Laimutis.Nedzinskas@xxxxxx>, 
"oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>                               
     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |"Uzzell, Stephan" <SUzzell@xxxxxxxxxx>                                       
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |2014.02.05 17:13                                                             
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |RE: ora-1555 on physical standby (no active data guard)                      
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|





Hi Laimis,

Have you seen this note On Standby, DBV Shows Pages Failing With Check Code
6056 (Doc ID 1523623.1)?

Stephan Uzzell

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Laimutis.Nedzinskas@xxxxxx
Sent: Wednesday, 05 February, 2014 02:15
To: oracle-l@xxxxxxxxxxxxx
Subject: ora-1555 on physical standby (no active data guard)



Hi,

Might be someone have delt with ora-1555 on Physical Standby. No active
data guard is involved. Bug 8895202.

Oracle fix a per note 8895202 heals the blocks but it does not fix the root
cause.

dbv detected 5000+ corrupted index blocks on standby which are causing this
ora-1555. Error code is "Page 385337 failed with check code 6056"
About 21 indexes are involved.

Does anyone has an idea what could be the root cause ? How can be this
corruption stopped ?
Our best guess so far is that index rebuild helps but does it prevents
future errors ?

Our version is 11.2.0.4 but (we think it is important) we migrated from
10.2.0.4 and kept compatible=10.2.0.4 as escape route.

Our next rather wishfull guess is that something in 10.2.0.4 blocks is
breaking 11.2 data guard apply redo process.
The error was first detected after migration into 11g. Analysis of SCNs
reported by dbv shows that all corrupted blocks have SCN's after migration.

So far the corruptions do not reapper on indexes which we have already
rebuilt.


Brgds, Laimis N







GIF image

GIF image

Other related posts: