Skip to Main Content

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, atul.

Asked: March 06, 2002 - 9:40 pm UTC

Last updated: March 10, 2008 - 10:39 am UTC

Version: 8.0.4

Viewed 10K+ times! This question is

You Asked

Sir,

Here is a situation which all DBA's may be facing..

Many developers creates tables for there test purpose and leaves that table or indexes behind without dropping them,and that unwanted thing
remains there for long..

As we r in OLTP,we can't afford Auditing and also analyze tables..

How to deal with that?
Is there any view which will tell us the unwanted table ie not accessed for long time or tables having zero rows in them?

Thanks

and Tom said...

why are your developers creating tables in your production system?

If they are doing this in test -- so what? have them create them in their own test schemas -- something you can drop and recreate at will. If they do this in the "real application" schema -- these tables should never make it to production as they are NOT part of the application and should not be part of the upgrade script.

You CAN afford auditing. You SHOULD use analyze. OTLP or not. But anyway -- neither of these things will fix your underlying problem. If you have developers that can log into production and do stuff like that -- you have a serious problem. You need to stop letting them into production! If it is in test/development, you don't have a problem -- its test after all. Just let them do it in their schema and its easy to clean up.

Sounds like you need a better configuration management environment, documentation, something. Perhaps a "case" tool would be called for to bring some order into your environment.

Rating

  (11 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Dave, March 07, 2002 - 10:00 am UTC

Even if, for some obscure reason, you have to create these tables in the production system, there's about twenty thousand ways of handling this. Try one of these.

i) Dedicate a "sandbox" tablespace to the temporary tables.

ii) Force a naming convention. Initials of developer, date they won't need the table any more etc., such as "JS_0206_WHATEVER" is a table created by John Smith that he'll no longer need from Hune 2002 onwards.

What the developers need, as Tom implies, is a good slapping.

Tom Kyte
March 07, 2002 - 10:44 am UTC

Well, I didn't mean to imply the developers need a good slapping -- people will do what they are allowed to do. This is an environment where it sounds like the necessary controls (rules) where never put into place. This is as much (if not entirely) the fault of the mgmt here.

If someone didn't tell me "use this tablespace, use this naming convention, etc..." -- I wouldn't. I'd just use table names like "test", "t", "xxx", "abc" and let them get created where ever.

If and only if -- after the introduction of some controls, rules, rigor the developers fail to obey the rules should you consider some sort of punitive action

Unwanted Tables

atul, March 07, 2002 - 9:44 pm UTC

Sir,

In ur response u mentioned about devlopment/test...,
But u might get surprised to here that we don't have test/devlopment servers we have straight production server.
This is componies policy so i can't help..

But,one schema in production is assigned to development work.ie in that schema anyone can do there devlopment work..

As u noticed we don't have separate development server.
How much space problem i have to tackle..

Also U r correct in figuring out there r no rules about dev. tables creation ie anyone can create tables with any name...

My concern here is users r creating test tables in there own schema if they found little space in devlopment schema..

and these tables kept there for long..and taking unnecessary
extents and inturn space..

so is there any query to find out tables which r not accessed for a long time...

Tom Kyte
March 08, 2002 - 8:39 am UTC

well, your company might be going under soon if it runs its IT that way.

Very sorry for you, might be time to tune up that resume.

(read about auditing, you can audit select/insert/update/delete on all tables, but that in itself will consume space).

Last date for table and index used

parag jayant patankar, April 19, 2004 - 4:35 am UTC

Hi Tom,

is it possible to find out in Oracle 8.1.7.4

1. in simple way last date of table used ?
2. last date of index getting used ?

In Oracle 9i is it possible to find out above details by using "montioring usage" ?

In our situation if I get this information it will help to pin-point unwanted tables and indexes.

regards & thanks

parag


Tom Kyte
April 19, 2004 - 6:54 am UTC

AUDITING is the way in all releases (9i included) to find out who is using a "table" and how. You have that in 8i.

As for indexes -- if you have my book "Expert one on one Oracle" -- i describe a method using query plan stability (stored outlines) to discover what queries are using which indexes for access.

search for
"query plan stability" monitoring

on this site to read a bit more about that idea.

Tables ???

parag jayant patankar, April 23, 2004 - 1:27 am UTC

Hi Tom,

Thanks for your precise answer for indexes !!!!. Can I find last access date for large no of tables in easy way 8.1.7 ? Can I do "monitoring usage" for tables in Oracle 9i ?

regards & thanks


Tom Kyte
April 23, 2004 - 11:44 am UTC

auditing gives you the last access date for tables.


to monitor a table means to watch it for changes (so we know when to gather stats again).

it is not the same as monitoring usage and there is no monitoring usage really (there are segment statistics in 9i, but auditing is what it sounds like you want)

auditing

Parag J Patankar, May 22, 2007 - 3:29 am UTC

Hi Tom,

I want to know last time of table acess(where successful or not successful ) for few undocumented tables in a legacy system for which data also been migrated to new system which is under TEST.

I have enabled audit for same. Can I enable auditing for a table by putting both statements in 9.2

AUDIT INSERT,SELECT,DELETE,UPDATE on toto
by ACCESS WHENEVER SUCCESSFUL;

AUDIT INSERT,SELECT,DELETE,UPDATE on toto
by ACCESS WHENEVER NOT SUCCESSFUL;

I want to enable successful or unsucessful because I fear that few tables might have been skipped from table creation scripts on a new system and it will create a problem when this system move to production.

thanks & regards
PJP

Tom Kyte
May 22, 2007 - 9:31 am UTC

enable auditing, audit the access to these tables.


if the tables were SKIPPED, that won't trigger "unsuccessful", there will be nothing to audit on - just doing the audit command would "fail"

Any way to track

Parag J Patankar, May 23, 2007 - 12:54 am UTC

Hi Tom,

Thanks for your answer. Is there any way to track down "select * from <nonexisting tables>" ?

thanks & regards
pjp
Tom Kyte
May 23, 2007 - 6:53 am UTC

ops$tkyte%ORA10GR2> create table t( id number, seq number, msg varchar2(4000) );

Table created.

ops$tkyte%ORA10GR2> create sequence s;

Sequence created.

ops$tkyte%ORA10GR2>
ops$tkyte%ORA10GR2>
ops$tkyte%ORA10GR2> create or replace trigger failed_to_extend_temp
  2  after servererror on database
  3  declare
  4      l_sql_text ora_name_list_t;
  5      l_n        number;
  6  begin
  7      if ( is_servererror(942) )
  8      then
  9          insert into t values ( s.nextval, 1, 'ora_sysevent = ' || ora_sysevent );
 10          insert into t values ( s.currval, 2, 'ora_login_user = ' || ora_login_user );
 11          insert into t values ( s.currval, 3, 'ora_server_error = ' || ora_server_error(1) );
 12          l_n := ora_sql_txt( l_sql_text );
 13          for i in 1 .. l_n
 14          loop
 15             insert into t values ( s.currval, 3+i, 'l_sql_text(' || i || ') = ' || l_sql_text(i) );
 16          end loop;
 17      end if;
 18  end;
 19  /

Trigger created.

ops$tkyte%ORA10GR2> select * from does_not_exist;
select * from does_not_exist
              *
ERROR at line 1:
ORA-00942: table or view does not exist


ops$tkyte%ORA10GR2> select * from t;

        ID        SEQ MSG
---------- ---------- ------------------------------
         1          1 ora_sysevent = SERVERERROR
         1          2 ora_login_user = OPS$TKYTE
         1          3 ora_server_error = 942
         1          4 l_sql_text(1) = select * from
                      does_not_exist



ORa-00942

Harel, May 23, 2007 - 4:46 am UTC

"select * from <nonexisting tables>" will raise a "ORA-00942: table or view does not exist" error.

You can catch that with a database trigger or by setting a system event (alter system set events '942 trace name errorstack level 3').

auditing on select on non existing tables

Parag J Patankar, May 23, 2007 - 7:17 am UTC

Hi Tom,

Thanks a lot for your very clear and nice solution. Just want to know where it will trap "select from <nonexisting tables>" in procedure or functions also ? ( Yes, I will start testing it ) but just to know.

Hi Harel,

Thanks for your reply. for 10093 it will nice if you can post an example.

thanks & regards
PJP
Tom Kyte
May 23, 2007 - 8:35 am UTC

it is on servererror, it doesn't really care where the sql comes from - sql is sql is sql.


Snooping errors

Gary, May 23, 2007 - 6:23 pm UTC

"it is on servererror, it doesn't really care where the sql comes from - sql is sql is sql. "
Just a caveat on this last one. If the SQL error occurs in PL/SQL and is trapped by an exception handler and not raised to the application invoking the package, then it won't get picked up by the servererror trigger.
servererror will also pick up PL/SQL errors.

Think of it as 'snooping' on errors reported by the database to the client application(s).

Last Access Date w/ out Auditing

Ken, March 07, 2008 - 2:15 pm UTC

Hello,

There have been a few posts talking about how to get last access date of a table (who is using the table and when). The solution and been Auditing. In my situation I cannot perform an audit. Is there another way??

Tom Kyte
March 10, 2008 - 10:39 am UTC

magic


I hate it when people say "i know the answer but the answer cannot be applied"

that is always wrong
it is never true

If you have a business requirement for something, and there is a documented well know, standard way to do it, it is always an option.


A reader, May 11, 2009 - 6:19 pm UTC