RE: Drop user fails with ORA-01418

  • From: "William B Ferguson" <wbfergus@xxxxxxxx>
  • To: lex.de.haan@xxxxxxxxxxxxxx, chadi@xxxxxxxxxxxxxxxxxx, oracle-l@xxxxxxxxxxxxx
  • Date: Tue, 16 Nov 2004 10:22:19 -0700

Lex,

Thanks for the clarification.

I'm overworked, having to do almost everything to include data cleanup
from an old unstructured flat-file database, and I just get cases of
information overload now and then and get things confused.

Regarding turning off the flashback, when I was just starting off with
10g, I had the recovery settings set for 3 days with a 6GB database. My
flashback area was set for 27GB, and kept filling up and stopping the
database, so I'd manually cleanup some of the old archive logs that were
several weeks old to get the database going again.

But..... By doing that, Oracle lost the pointers to those files (since I
did it wrong) and started giving me errors, and then stopped. So, what I
found out was by doing the following occasionally, I was able to bypass
the errors by doing it the wrong way:
(as sysdba)
startup mount
alter database flashback off;
alter database open;
shutdown immediate
startup mount
alter database flashback on;
alter database open;


Now however, I've found that keeping the recovery settings set for 1 day
eliminates the problems I was having without me doing it the wrong way.
:^)

I'm still confused by the fact the I can still recover for more than a =
day
when the recovery settings are set for 1 day, but oh well, I can live =
with
that. One of these days I'll be caught up enough to take a class or two
and learn the correct ways of doing things in 10g, or maybe I'll be able
to get some insights at OpenWorld.

Thanks again.
------------------------------------------------------------
Bill Ferguson
U.S. Geological Survey - Minerals Information Team
PO Box 25046, MS-750
Denver, Colorado 80225
Voice (303)236-8747 ext. 321 Fax (303)236-4208

~ Think on a grand scale, start to implement on a small scale ~




-----Original Message-----
From: lex.de.haan@xxxxxxxxxxxxxx [mailto:lex.de.haan@xxxxxxxxxxxxxx]=20
Sent: Tuesday, November 16, 2004 6:50 PM
To: William B Ferguson; thomas.mercadante@xxxxxxxxxxxxxxxxx;
chadi@xxxxxxxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: Drop user fails with ORA-01418


Bill, I guess you mean the "flash recovery area" -- and that's a feature =

totally unrelated to the recyclebin. there is an undocumented way to
suppress=20
the recycle bin in 10g, but why would you? it is a convenient feature, =
and

there are various documented purging methods. also, the space allocation =

algorithm will automatically purge recycle bin objects under space
pressure,=20
before e.g. extending a data file.

cheers,
Lex.

> I think you can if you disable the flashback_recovery_area. It appears =

> that the main purpose is for a group like mine, where you have several =

> different people at the beginning stages of Oracle expertise, but they =

> still need (due to managerial and political considerations), full=20
> access to all of the data. If they happen to accidentally drop an=20
> object, or =3D even rows from an object, with the=20
> flashback_recovery_area, you can recover everything they accidentally=20
> did up to whatever point in time without =3D have
> to do a datafile restore and losing other appropriate changes made =
after
> that.
>=20
> It's still new and I'm still learning it, so I could be wrong, but =3D =

> that's my impression so far (and it's actually saved me some grief so=20
> far as
> well) with my limited expertise.
>=20
> ------------------------------------------------------------
> Bill Ferguson
> U.S. Geological Survey - Minerals Information Team
> PO Box 25046, MS-750
> Denver, Colorado 80225
> Voice (303)236-8747 ext. 321 Fax (303)236-4208
>=20
> ~ Think on a grand scale, start to implement on a small scale ~
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: Mercadante, Thomas F=20
> [mailto:thomas.mercadante@xxxxxxxxxxxxxxxxx]=3D20
> Sent: Tuesday, November 16, 2004 9:09 AM
> To: William B Ferguson; chadi@xxxxxxxxxxxxxxxxxx
> Cc: oracle-l@xxxxxxxxxxxxx
> Subject: RE: Drop user fails with ORA-01418
>=20
>=20
> Recycle bin.  OMG.  Has Oracle become Windows?  We don't need no=20
> freekin recycle bin.
>=20
> Can we turn this off????  :)
>=20
>=20
>=20
> -----Original Message-----
> From: William B Ferguson [mailto:wbfergus@xxxxxxxx]=3D20
> Sent: Tuesday, November 16, 2004 11:06 AM
> To: chadi@xxxxxxxxxxxxxxxxxx; thomas.mercadante@xxxxxxxxxxxxxxxxx
> Cc: oracle-l@xxxxxxxxxxxxx
> Subject: RE: Drop user fails with ORA-01418
>=20
>=20
> Chadi,
>=20
> The BIN$... Object is a dropped trigger (it appears to be anyway),=20
> that =3D is in the recycle bin, and apparently the drop user statement =

> seems to be having trouble deleting the user with an associated object =

> in the =3D recycle
> bin.
>=20
> To try and get around it, try going the web-enable enterprise manager, =

> =3D the administration page, then Tables (or actaully any object),=20
> filter for =3D the
> owner of the object, the the recycle bin button appears. Or, from the =
=3D
> sql
> prompt, you can do a "purge dba_recyclebin;" (to empty the recycle bin =
=3D
> for
> all users, or connect as the user and issue a "purge recyclebin;".
>=20
> I think this will get around the problem you are experiencing.
>=20
> ------------------------------------------------------------
> Bill Ferguson
> U.S. Geological Survey - Minerals Information Team
> PO Box 25046, MS-750
> Denver, Colorado 80225
> Voice (303)236-8747 ext. 321 Fax (303)236-4208
>=20
> ~ Think on a grand scale, start to implement on a small scale ~
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx =3D=20
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
> On Behalf Of chadi@xxxxxxxxxxxxxxxxxx
> Sent: Tuesday, November 16, 2004 8:32 AM
> To: 'Mercadante, Thomas F'
> Cc: oracle-l@xxxxxxxxxxxxx
> Subject: RE: Drop user fails with ORA-01418
>=20
>=20
> Actually, this is my problem. I couldn't drop some objects in the=20
> user, =3D so i decided to rebuild the user and still stuck with this:
>=20
> the trace is shwoning that some trigger is causing the ora600:
>=20
> ksedmp: internal or fatal error
> ORA-00600: internal error code, arguments: [15239], [], [], [], [],=20
> [], [], [] Current SQL statement for this session: drop trigger=20
> "CHADI"."BIN$5/+ZaDjf/yjgMIEKQwE88g=3D3D=3D3D$0"
>=20
>=20
> Chadi.
>=20
> -----Original Message-----
> From: Mercadante, Thomas F=20
> [mailto:thomas.mercadante@xxxxxxxxxxxxxxxxx]
> Sent: Tuesday, November 16, 2004 10:24 AM
> To: 'chadi@xxxxxxxxxxxxxxxxxx'; oracle-l@xxxxxxxxxxxxx
> Subject: RE: Drop user fails with ORA-01418
>=20
>=20
> Chadi,
>=20
> Did the user get dropped?
>=20
> If not, can you go through and drop the users objects manually?  And =
=3D=20
> then drop the user?  It is obviously an Oracle problem.  But if you=20
> can find =3D a
> workaround, then you can chalk it up to experience.
>=20
> Personally, I do not drop a user that has a bunch of objects.  I=20
> prefer =3D to drop all the objects first and then the user just for =
this=20
> reason.
>=20
> Hope this helps.
>=20
> Tom Mercadante
> Oracle Certified Professional
>=20
>=20
> -----Original Message-----
> From: Chadi Kassan [mailto:chadi@xxxxxxxxxxxxxxxxxx]=3D20
> Sent: Tuesday, November 16, 2004 10:01 AM
> To: oracle-l@xxxxxxxxxxxxx
> Subject: Drop user fails with ORA-01418
>=20
>=20
> Hi everyone,
>=20
> I'm pretty sure, many had run into this problem before and can provide =

> some help. When I try to drop one of my user, I get the following:
>=20
> SQL> drop user theuser cascade;
>=20
> ORA-00604: error occurred at recursive SQL level 1
> ORA-01418: specified index does not exist
>=20
> What index it's talking about, metalink says this is related to some =
=3D=20
> data corruption in data dictionnary, but doesn't provide a solution.
>=20
>=20
> We run Oracle Database 10g Release 10.1.0.3.0 on Linux.
>=20
> Thank you.
> --
> //www.freelists.org/webpage/oracle-l
> --
> //www.freelists.org/webpage/oracle-l
> --
> //www.freelists.org/webpage/oracle-l
>=20


--
//www.freelists.org/webpage/oracle-l

Other related posts: