| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: RMAN fails because of corrupt block in seemingly free space in SYSTEM
('binary' encoding is not supported, stored as-is)
Uldis
Can you please dump those 10 blocks and confirm those blocks are indeed corrupted ? Not falsely reported as corrupt by rman ? I am not pre-judging rman, but just wanted to be sure.
If all these 10 blocks are corrupted, then I wouldn't think that skgfrsiz issue (as Robert Freeman pointed ) would have caused this corruption. From the bug reports, it looks like only the last block will be corrupted. Further, as per your posting, this block is at 512M of 2000M.
Can you check with sysadmin to see what is so special about this 512M boundary ? May be AIX has some kind of extent or partition management ? That would give out some clues.
Also, do you use concurrent IO in AIX ? If yes, do you have fix for APAR IY70031 installed ?
Refer:
http://www-1.ibm.com/support/docview.wss?rs=118&uid=isg1IY70031
If there are no blocks after the 512M boundary, then you could potentially resize down and resize it back. That should remove this corruption.
If not, you could use transportable tablespace method. Still, it's probably better to open a case with Oracle support and IBM, at this point, so that you could avoid this problem in future.
Thanks
Riyaj Shamsudeen
Bobak, Mark wrote:
> I've seen similar looking corruptions on a few of my databases as
> well. I never did get to the bottom of the problem. However, in
> terms of solving the problem and moving on, you ought to be able to
> set MAXCORRUPT greater than then number of corrupt blocks you have,
> backup the datafile(s) affected, and then, restore datafile(s) from
> backup. Since they were corrupt on backup, Oracle will format the
> block at restore time. As long as the block is not part of any
> segment, that's ok. Note that if any corrupted block is part of any
> segment, the above is a bad idea.
>
> -Mark
>
>
> *--*
>
> *Mark J. Bobak*
>
> *Senior Oracle Architect*
>
> *P**ro**Q**uest Information & Learning*
>
> There is nothing so useless as doing efficiently that which shouldn’t
> be done at all. –Peter F. Drucker, 1909-2005
>
>
>
> ------------------------------------------------------------------------
> *From:* oracle-l-bounce_at_freelists.org
> [mailto:oracle-l-bounce_at_freelists.org] *On Behalf Of
> *Uldis.Pavuls_at_tietoenator.com
> *Sent:* Wednesday, January 03, 2007 12:35 PM
> *To:* rshamsud_at_jcpenney.com
> *Cc:* oracledba.williams_at_gmail.com; oracle-l_at_freelists.org
> *Subject:* RE: RMAN fails because of corrupt block in seemingly free
> space in SYSTEM
>
> Riyai,
> it's quite possible the OS partition has been resized, i do not know,
> my role is rather consulting at need. I'm not on-site, it makes things
> a bit difficult. However, I did not find any tracs of resizing in the
> alert-log, at least not for the system tablespace (they certainly had
> had some difficulties with undo resizing, however).
> In fact there is account for 10 blocks in row corrupted in similar
> way, all fractured and with CORRUPTION_CHANGE#=0, rman just falls back
> on the first, although, it seems, have recorded other piece of 9
> blocks - next to the first one - in v_$database_block_corruption.Citation:
> select T.NAME "T-space", D.NAME "Filename", C."FILE#" "FileId",
> C."BLOCK#" "BlockId", C.BLOCKS,
> C."CORRUPTION_CHANGE#" "Corr.SCN", C.CORRUPTION_TYPE
> from SYS."V_$DATABASE_BLOCK_CORRUPTION" C, SYS."V_$DATAFILE" D,
> SYS."V_$TABLESPACE" T
> where C."FILE#" = D."FILE#" and D."TS#" = T."TS#" order by 1, 2, 3, 4 ;
> <Output as CSV>:
> SYSTEM;/dev/rcmssystem;1;65535;1;0;FRACTURED
> SYSTEM;/dev/rcmssystem;1;65536;9;0;FRACTURED
> <end of output>
> All datafiles are locally managed and on raw devices (under VLM on AIX
> 5.3, so they are partitions in fact); there should be my first post
> (2 January, 2007) with a bit more info.
> Thanks for the idea of use of transportable tablespaces, it didn't
> occur to me. I'll certainly consider that. I was rather thinking about
> shrinking that file and then re-expanding it, that should clear the
> corruption on success - how do you think? It would be faster if
> succeeded. Altogether on the second thought CORRUPTION_CHANGE#=0
> should mean media corruption, so your approach may be safer in long run.
> Best regards,
> 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_at_tietoenator.com
> http://www.tietoenator.com <http://www.tietoenator.com/>
>
> -----Original Message-----
> *From:* oracle-l-bounce_at_freelists.org
> [mailto:oracle-l-bounce_at_freelists.org] *On Behalf Of *Riyaj Shamsudeen
> *Sent:* otrdiena, 2007. gada 2. janvârî 23:50
> *To:* Pavuls Uldis
> *Cc:* oracledba.williams_at_gmail.com; oracle-l_at_freelists.org
> *Subject:* Re: RMAN fails because of corrupt block in seemingly
> free space in SYSTEM
>
> 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
>
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.
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Jan 03 2007 - 13:32:55 CST
 |
 |