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

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_at_MICROS.COM>                                                                                                            |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|


|------------>

| To:        |

  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |"'Laimutis.Nedzinskas_at_seb.lt'" <Laimutis.Nedzinskas_at_seb.lt>, "oracle-l_at_freelists.org" <oracle-l_at_freelists.org>                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|


|------------>

| Cc:        |

  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |"Uzzell, Stephan" <SUzzell_at_MICROS.COM>                                                                                                            |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|


|------------>

| Date:      |

  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |2014.02.05 17:13                                                                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|

  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Laimutis.Nedzinskas_at_seb.lt Sent: Wednesday, 05 February, 2014 02:15 To: oracle-l_at_freelists.org
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

--
http://www.freelists.org/webpage/oracle-l