Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: RMAN fails because of corrupt block in seemingly free space in SYSTEM

Re: RMAN fails because of corrupt block in seemingly free space in SYSTEM

From: Riyaj Shamsudeen <rshamsud_at_jcpenney.com>
Date: Mon, 08 Jan 2007 09:28:26 -0600
Message-ID: <45A2631A.8090109@jcpenney.com>


Uldis

    Block is corrupt and filled with nonsense. I don't know what will fill the block like this, may be somebody in list might be of help. It looks like some sort of initialization to me.   

    But, to fix the corruption, try resize the file. If that doesn't work, transportable tablespace is another viable option. ..

11035B490 00191122 001A1123 001B1124 001C1125  [..."...#...$...%]
11035B4A0 001D1126 001E1127 001F1128 00201129  [...&...'...(. .)]
11035B4B0 0021112A 0022112B 0023112C 0024112D  [.!.*.".+.#.,.$.-]
11035B4C0 0025112E 0026112F 00271130 00281131  [.%...&./.'.0.(.1]
11035B4D0 00291132 002A1133 002B1134 002C1135  [.).2.*.3.+.4.,.5]
11035B4E0 002D1136 002E1137 002F1138 00301139  [.-.6...7./.8.0.9]
11035B4F0 0031113A 0032113B 0033113C 0034113D  [.1.:.2.;.3.<.4.=]
11035B500 0035113E 0036113F 00371140 00381141  [.5.>.6.?.7.@.8.A]
11035B510 00391142 003A1143 003B1144 003C1145  [.9.B.:.C.;.D.<.E]
11035B520 003D1146 003E1147 003F1148 00401149  [.=.F.>.G.?.H.@.I]
11035B530 0041114A 0042114B 0043114C 0044114D  [.A.J.B.K.C.L.D.M]
11035B540 0045114E 0046114F 00471150 00481151  [.E.N.F.O.G.P.H.Q]
11035B550 00491152 004A1153 004B1154 004C1155  [.I.R.J.S.K.T.L.U]
11035B560 004D1156 004E1157 004F1158 00501159  [.M.V.N.W.O.X.P.Y]
11035B570 0051115A 0052115B 0053115C 0054115D  [.Q.Z.R.[.S.\.T.]]
11035B580 0055115E 0056115F 00571160 00581161  [.U.^.V._.W.`.X.a]
11035B590 00591162 005A1163 005B1164 005C1165  [.Y.b.Z.c.[.d.\.e]
11035B5A0 005D1166 005E1167 005F1168 00601169  [.].f.^.g._.h.`.i]
11035B5B0 0061116A 0062116B 0063116C 0064116D  [.a.j.b.k.c.l.d.m]
11035B5C0 0065116E 0066116F 00671170 00681171  [.e.n.f.o.g.p.h.q]
11035B5D0 00691172 006A1173 006B1174 006C1175  [.i.r.j.s.k.t.l.u]
11035B5E0 006D1176 006E1177 006F1178 00701179  [.m.v.n.w.o.x.p.y]
11035B5F0 0071117A 0072117B 0073117C 0074117D  [.q.z.r.{.s.|.t.}]
11035B600 0528110B 4199C6A9 72686469 736B3100  [.(..A...rhdisk1.]
....

Thanks
Riyaj Shamsudeen

Uldis Pavuls wrote:
> Sorry, it seems in previous versions the mail didn't passed the
> antivirus checks for the zipped trace. I'll try to make it gz instead
> and will see.
> Begging pardon and thanks in advance,
> Uldis
> -------------------
>
> Riyai,
> yes, my associate, who helped to install OS and Oracle on-site,
> confirmed that the fix was installed. I attached the zipped dump. (hope
> it's all ok with list rules; just got it and I'm in hurry a bit, so I
> have no time to check the rules; begging pardon if it's wrong ). There
> are several suspicious moments in the history of the instance.
> First, it was made by cloning from the test instance, altogether, AFAIK,
> it wasn't tested by dbv -neither before nor after delivery. Good place
> for an accident, isn't it?
> Then there was an overflow of the storage for archived logs.
> And the last accident was, as i read in the alert-log, the adventure
> with resizing of the undo tablespace - a mistake occured, what resulted
> in dropping and recreating it in not exactly legal way.
>
> TIA,
> Uldis
>
> P.S. The message was thrown back by one of our mail server because of
> the attachement; i'm trying to send it again via another; hope it'd be
> delivered this time :)
>
> P.S. Sorry for sending the first version w/o subject; I tried to recall
> that mail, though I do not know if it'd succeed. Begging pardon!
>
> 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
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org
> [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Riyaj Shamsudeen
> Sent: trešdiena, 2007. gada 3. janvārī 21:33
> To: Bobak, Mark
> Cc: Pavuls Uldis; 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
> 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
>
>


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-l
Received on Mon Jan 08 2007 - 09:28:26 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US