Re: FW: idl_ub2$ and utlip.sql

mark,

db is 9.2.0.4 on linux x86
yesterday i was fixed it by
- changing init prameter,
- truncate idl_ub2$ drop storage
- execute utlirp twice
- then utlrp,
- to make sure..... then change parameter to original what oracle apps
required,
- and rerun utlrp, so far it is OK,

but got 69 packages from APPS invalidated.

checking the corruption, is OK, it seem physical corrupt. and now
IDL_UB2$ has no corruption issue.

btw, does anyone have the experience the same and in Oracle Apps environment?
if I export import Full database, is it any issues (due to oracle Apps
environment).

regrds
ujang


On 7/25/07, Mark W. Farnham <mwf@xxxxxxxx> wrote:

I'm curious about your storage allocations for the broken object(s).

These are originally built based on sql.bsq but also depend on your block
size and other choices about your storage.

What is your Oracle release, block size, choices about local versus
dictionary managed system and sysaux tablespaces, and file storage (file
system, raw volumes, or ASM)?

While unlikely, it is possible that you have a combination of space required
from the construction of your total of PL/SQL that makes it impossible to
store within the configuration constraints. If the bulk of your objects in
SYSTEM still function correctly it certainly makes one wonder why idl_ub2$
would be broken and whether it is the underlying storage or a logical
corruption.

Regards,

mwf

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Ujang Jaenudin
Sent: Wednesday, July 25, 2007 5:13 AM
To: Hallas, John (EXP N-ARM)
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: idl_ub2$ and utlip.sql

ya i tried also dbms_repair, check_object, fix and skip procedures
but it seem realy physical corruption.

oracle support told me to export import full database.
is there any other shortcut way?

regards
ujang

On 7/25/07, Hallas, John (EXP N-ARM) <john.hallas@xxxxxxxx> wrote:
> DESCRIPTION
> Rem     This script can be used to invalidate all existing PL/SQL
> modules
> Rem     (procedures, functions, packages, types, triggers, views) in a
> Rem     database so that they will be forced to be recompiled later on
> Rem     either automatically or deliberately.
> Rem
> Rem     This script must be run when it is necessary to regenerate the
> Rem     compiled code because an action was taken that caused the old
> code's
> Rem     format to be inconsistent with what it's supposed to be, e.g.,
> when
> Rem     migrating a 32 bit database to a 64 bit database or vice-versa.
> Rem
> Rem     STEPS:
> Rem
> Rem     (I) Invalidate all stored PL/SQL units (procedures, functions,
> Rem           packages, types, triggers).
> Rem
> Rem     (II) Reload PL/SQL package STANDARD and package DBMS_STANDARD.
> Rem
> Rem     (III) Selectively invalidate views and synonyms
> Rem
>
> Doesn't seem high risk as long as you recompile everything afterwards.
> Use utlrp for that
> Why not log a SR
>
> You could try and fix the corrupt blocks with dbms_repair.check_object
> procedure and dbms_repair.fix_corrupt_blocks
>
> More importantly, how has the corruption occurred
>
> John
>
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Ujang Jaenudin
> Sent: 25 July 2007 04:15
> To: oracle-l@xxxxxxxxxxxxx
> Subject: idl_ub2$ and utlip.sql
>
> folks,
>
> I have problem on system tablespace, corruption on object idl_ub2$,
> searching google that idl_ub2$ can rebuild by utlip.sql, is it true?
>
>


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








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

Other related posts: