Re: Question: ONE corrupted tablespace in standby db???

BD wrote:
> Hey all.
>
> I'm on 8.1.7.4 on AIX 5.2.0.2.
>
> I have a standby database which is being used for reporting. It is
> unmanaged; I apply the redo from the master a couple of times a day,
> more often on weekends.
>
> I have not made this db available for use yet; it's still a POC for us.

Does that mean you haven't tried to bring it up in read-only mode? I think you must have since you say "is being used," but I have to ask. Have you read from the affected datafiles?

When you created the standby, did you use RMAN or a manual procedure? Did you follow a particular cookbook?

>
> But I ran dbv against the standby's datafiles today, and see a whole
> WHACK of errors - for example:
>
> Block Checking: DBA = 369100613, Block Type =
> Found block already marked corrupted
> Block Checking: DBA = 369100614, Block Type =
> Found block already marked corrupted
>
> The datafiles affected only belong to one tablespace, and _all_ of this
> tablespace's files are affected.

See metalink Note:139425.1:

"You can usually ignore "Block found already corrupt" messages, because these
are reporting a soft corruption in unused blocks. There is NO corruption in CURRENTLY used blocks.

Blocks found already corrupt do NOT contribute to the dbv report statistics.
This is why you get this informational message instead."

>
> The master database's files are fine.
>
> I am currently running dbv against all the files in this reporting
> database, and so far, only the six files in this one tablespace are
> broken. My db has 230 files, and so far it's verified just over half of
> them; no additional errors.
>
> I have already done some digging into this, and have found one
> discussion concerning whether the standby is set to NOLOGGING or not -
> that discussion was concerning DataGuard, so likely isn't directly
> relevant to 8i.
>
> I tried to analyze one of the indexes in this affected tablespace, and
> (predictably) got a 'data block corrupted' message.
>
> Can anyone suggest what might have happened here??

See Note:283787.1 - you perhaps recovered a nologged table, doesn't have to have dataguard involved. I think there was a discussion about this here not long ago but don't feel like looking for it, have a vague memory that someone finally fessed up to nologging.

There also may be bugs prowling about.

>
> Thanks for all suggestions!
>
> BD

jg

--
@home.com is bogus.
http://www.workingforchange.com/comic.cfm?itemid=20845