Re: RMAN fails because of corrupt block in seemingly free space in SYSTEM
- From: Riyaj Shamsudeen <rshamsud@xxxxxxxxxxxx>
- To: Uldis.Pavuls@xxxxxxxxxxxxxxx
- Date: Tue, 02 Jan 2007 15:49:55 -0600
Uldis
rman does not backup "never used" blocks, not "free" blocks. It is
quite possible that this block was previously used and rman will back
this block also.
Looking at the following lines, clearly even rdba in the block is
corrupted. Many other fields are corrupted too. Weird thing is that
block is corrupted exactly at 65535 block, which happened to be a binary
power of 16. Was this raw device extended using OS tools in the past ?
If yes, from what size ? What is your db_block_size ?
***
Corrupt block relative dba: 0x0040ffff (file 1, block 65535)
Fractured block found during backing up datafile
Data in bad block -
type: 0 format: 2 rdba: 0x0000ffff
last change scn: 0x0000.00000000 seq: 0x1 flg: 0x05
consistency value in tail: 0x0074117a
check value in block header: 0xfef9, computed block checksum: 0x9
spare1: 0x0, spare2: 0x0, spare3: 0x0
***
Can you dump the block itself and print trace lines ? alter system
dump datafile 1 block min 65535 block max 65535
Also, in your SQL, can you select block_id too ?
select TABLESPACE_NAME,FILE_ID,BLOCKS, BLOCK_ID
from SYS.DBA_FREE_SPACE where FILE_ID=1
and BLOCK_ID <=65535 and (BLOCK_ID+BLOCKS-1)>=65535;
Is system locally managed or dictionary managed, in your database ?
I am not sure why Oracle support would say that it is okay to have
corrupt block, that too in a system tablespace. If I were you, I would
be looking at creating a new database and transporting non-system
tablespaces from current database to new database, urgently.
Thanks
Riyaj Shamsudeen
Uldis.Pavuls@xxxxxxxxxxxxxxx wrote:
Thanks, Dennis, it was very informative... :)
Well, in fact I’ve put a similar message on Metalink forum, too. As
for support call, there are some technical difficulties I’d rather
avoid - I said already that they licence is "application use only", so
all the support goes through us, I’d have to cover a few hundreds km
just to place a SR and then go through all that procedure... sure you
know, what i mean.
In fact I advised the local staff to make a manual online database
copy (instead of RMAN's). The instance does startup all OK, so it
seems safe enough (though I'm not entirely sure, it's why I'm here).
Actually they have experienced this problem quite a some time before
calling on us and have restarted the instance several times already.
Instance is supposed to work in 24x7 with all what's involved (just
customer access to the system is limited), so export just won't do.
I usually can manage - more or less - block corruption and wouldn't
care much if, in the first place, it wasn't the SYSTEM tablespace. On
the other hand, I just do not understand why RMAN ever cares about
this block and why it's fractal, it's in the free space list after
all. Usually corrupted blocks belong to some certain object, most
often an index segment, but it's first time on my experience that
causes a problem being in free space. I seldom use raw devices myself,
though, that's true, and so there could be some difference.
I've found few notes in the Metalink with similar symptoms, but, on
closer look, none of them match the case, neither any of them gives a
clue. I.e., the mechanics are explainied alright, altogether not in
the case of a block in a segment in the free segments list.
Best regards and happy New Year!
Uldis
Uldis Pavuls
DBA, TietoEnator
41 Lacplesa Str., Riga, Latvia, LV 1011
phone +371 7 286 660, fax +371 7 771 313
mailto:Uldis.Pavuls@xxxxxxxxxxxxxxx
http://www.tietoenator.com <http://www.tietoenator.com/>
-----Original Message-----
*From:* Dennis Williams [mailto:oracledba.williams@xxxxxxxxx]
*Sent:* otrdiena, 2007. gada 2. janvārī 16:36
*To:* Pavuls Uldis
*Cc:* oracle-l@xxxxxxxxxxxxx
*Subject:* Re: RMAN fails because of corrupt block in seemingly
free space in SYSTEM
Uldis,
Hmmm. . . time to place that call to Oracle Support? I think I'd
try to export my data . . . quickly.
Dennis Williams
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. If the reader of this message is not the intended recipient,
you are hereby notified that your access is unauthorized, and any review,
dissemination, distribution or copying of this message including any
attachments is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete the material from any
computer.
Other related posts:
