For this example all oracle files of interest were under directory “/ora” – that would need to be changed to suit other sites.

# 1) Remove old oracle-owned aud, trc, trw, core files
#    Also remove old recv error files (these have format ".err_[0-9]")
#    Also remove access_log., error_log., emoms.log. files - which are generated in large numbers
#    Only core files named "core." are removed: because many other files with "core" in their name are not core dumps, are used by oracle.

echo "*** REMOVE OLD ORACLE AUDIT FILES and OLD RECV Error Files and OLD TRACE FILES ***"
find /ora -mtime +7 -user oracle \( \
  -name '*.aud' -o \
  -name '*.trc*' -o \
  -name '*.trw' -o \
  -name 'core.[0-9]*' -o \
  -name '*.err_[0-9]*' -o \
  -name 'access_log.[0-9]*' -o \
  -name 'error_log.[0-9]*' -o \
  -name 'emoms.log.[0-9]*' \) -exec rm {} \;

# 2) Cut down alert logs and listener logs, and also access_log and event_log (webcache/portal/etc.)
#    Old log files are ignored - only log files modified in the last 7 days are worked on.
#    Small log files are ignored - only files bigger than 3mb (=6144*512 byte blocks) are worked on. 3mb is approximately 30,000 lines of text.

echo "*** CUT DOWN THE ALERT LOGS and ORACLE LISTENER.LOG FILE ***"
for FILE in `find /ora -mtime -7 -size +6144 -user oracle \( \
  -name 'alert_*.log' -o \
  -name 'listener*.log' -o \
  -name 'access_log' -o \
  -name 'event_log' -o \
  -name 'http-web-access.log' -o \
  -name 'server.log' \)`
do
  echo "*** cutting $FILE ***"
  cp $FILE $FILE.tmp
  tail -10000 $FILE.tmp > $FILE
  rm $FILE.tmp
done

echo "*** CUT DOWN MESSAGES and WARN FILES  ***"
for FILE in `find /var/log/ -mtime -7 -size +6144 \( \
  -name 'messages' -o \
  -name 'warn'  \)`
do
  echo "*** cutting $FILE ***"
  cp $FILE $FILE.tmp
  tail -10000 $FILE.tmp > $FILE
  rm $FILE.tmp
done

#End of file.

SQL> alter database datafile '/ora1data/TEST/TEST_ts_data1_f1.dbf' resize 2g ;

ORA-03297: file contains used data beyond requested RESIZE value

Provided you can get an outage, one fix for this is to temporarily move segments to another tablespace using a scripts like this. (Note that this script includes the commands to move LOBs).

set pages 9999 lines 132
spool go.tmp
select 'alter table '||owner||'.'||table_name||' move tablespace ts_data2 ;'
from dba_tables
where tablespace_name = 'TS_DATA1'
order by 1
/
select 'alter index '||owner||'.'||index_name||' rebuild tablespace ts_data2 ;'
from dba_indexes
where tablespace_name = 'TS_DATA1'
and index_type != 'LOB'
order by 1
/
select 'alter table '||owner||'.'||table_name||' move tablespace ts_data2 lob ('||column_name||') store as (tablespace ts_data2) ;'
from dba_lobs
where tablespace_name = 'TS_DATA1'
order by 1
/
spool off
ed go.tmp

They can be moved back afterwards, once the original tablespace has been shrunk, if desired.

One thing to watch out for is user tablespace quotas during the moves. If you get errors like this:

ORA-01950: no privileges on tablespace 'TS_DATA2'

You either need to temporarily grant unlimited tablespace privilege to the user affected, or grant them a quota on the new tablespace.

tar cvfp - file1 file2 file3 > tarfile.tar

And to untar:

tar xvfp tarfile.tar

2) Now, same thing but with compress added in:

tar cvfp - file1 file2 file3 | compress > tarfile.tar.Z
zcat tarfile.tar.Z | tar xvfp -

3) And, the same thing using gzip rather than compress:

tar cvfp - file1 file2 file3 | gzip > tarfile.tar.gz
gunzip -c tarfile.tar.gz | tar xvfp -

(Or, if you prefer, “gzip -cd” is the same as “gunzip -c”)

Gzip compresses down in size slightly better than compress, but tends to take slightly longer to do so.

conn / as sysdba
@?/rdbms/admin/profload.sql
conn system/password
alter user system default tablespace users ;
-- [or any other reasonable tablespace]
@?/rdbms/admin/proftab.sql
GRANT all ON plsql_profiler_runnumber TO PUBLIC;
GRANT all ON plsql_profiler_data TO PUBLIC;
GRANT all ON plsql_profiler_units TO PUBLIC;
GRANT all ON plsql_profiler_runs TO PUBLIC;
CREATE PUBLIC SYNONYM plsql_profiler_runs FOR plsql_profiler_runs;
CREATE PUBLIC SYNONYM plsql_profiler_units FOR plsql_profiler_units;
CREATE PUBLIC SYNONYM plsql_profiler_data FOR plsql_profiler_data;
CREATE PUBLIC SYNONYM plsql_profiler_runnumber FOR plsql_profiler_runnumber;
alter user system default tablespace system  ;

Based on Tim Hall’s post.

set pages 9999 lines 132
col username form a20
col osuser form a20
col program form a50
col minutes form 999
alter session set nls_date_format = 'Dy DD-Mon-YYYY HH24:MI:SS'
/
select distinct
s.sid, s.username, s.osuser, s.program||' '||s.module program,
s.status, s.last_call_Et/60 minutes, s.logon_time, w.state, w.event, w.seconds_in_wait ,
q.sql_text
from v$session s, v$sql q, v$session_wait w
where ( s.status = 'ACTIVE' or last_call_et < 60 )
and s.sql_hash_value = q.hash_value
and s.sql_address = q.address
and s.sid = w.sid
order by s.sid
/
set pages 9999 lines 80 head on feed 6

Run this code to see the anomaly for yourself:

set serverout on
declare
  var1 number ;
begin
  select count(*) into var1 from all_objects ;
  dbms_output.put_line('all_objects: '||var1) ;
end ;
/
create or replace procedure af_temp as
  var1 number ;
begin
  select count(*) into var1 from all_objects ;
  dbms_output.put_line('all_objects: '||var1) ;
end ;
/
exec af_temp ;
drop procedure af_temp ;

It’s the exact same plsql each time, but very different results reported. For example:

all_objects: 13501

PL/SQL procedure successfully completed.

Procedure created.

all_objects: 4929

PL/SQL procedure successfully completed.

Procedure dropped.

This behaviour appears to occur on all versions – I tested from 7.3 through 10gR2. The biggest discrepancies in results seem to be with DBA users other than SYS, but all users show some discrepancy.

This issue doesn’t occur with the dba_ views, so best to use them instead in stored plsql objects. That does mean explicitly granting select privileges on the dba_ views being used in stored procedures, which isn’t necessary for the all_ views.

So, is this a bug? I can’t see any mention of it all in metalink.

It’s not just an academic issue either: it caused this code of mine to fail to find and drop the objects it was meant to drop.

set pages 9999 verify off
col serial new_value serial noprint
select serial# serial from v$session where sid = &1 ;
exec sys.dbms_system.set_bool_param_in_session(&1,&serial,'timed_statistics',true)
exec sys.dbms_system.set_int_param_in_session(&1,&serial,'max_dump_file_size',999999999)
exec sys.dbms_system.set_ev(&1,&serial,10046,8,'')

And to switch it off:

set pages 9999 verify off
col serial new_value serial noprint
select serial# serial from v$session where sid = &1 ;
exec sys.dbms_system.set_ev(&1,&serial,10046,0,'')

Note that you can run new (9i+) tkprof against old (8i and below) 10046 trace files in order to report the wait information. It is also possible to cat multiple trace files together before tkprof’ing.

Based on Alexander Bubernak’s post at http://www.dbasupport.com/oracle/ora10g/10046event.shtml

Database clones can also be done with rman, which has the advantage of avoiding the performance draining hot backup mode.

set pages 9999 lines 132 serverout on size 99999
BEGIN
  FOR t IN ( select distinct tablespace_name from dba_data_files )
  LOOP
    dbms_output.put_line('alter tablespace '||t.tablespace_name||' begin backup ;') ;
    FOR f IN ( select file_name from dba_data_files where tablespace_name = t.tablespace_name )
    LOOP
      dbms_output.put_line('host cp '||f.file_name||' '||f.file_name ) ;
    END LOOP ;
    dbms_output.put_line('alter tablespace '||t.tablespace_name||' end backup ;') ;
  END LOOP ;
END ;
/
set lines 80
select 'alter tablespace '||tablespace_name||' add tempfile '||file_name||' size '||bytes/1024/1024||' m ;'
from dba_temp_files
/
prompt alter system switch logfile ;;
prompt alter system backup controlfile to trace ;;

set pages 9999
spool c.lst
select elapsed_time/1000000 secs, executions,
  elapsed_time/1000000/greatest(executions,1) secs_per_exec,
sql_text from v$sql
where executions > 50
and elapsed_time/1000000/greatest(executions,1) > 1
order by 3 desc
/
spool off
ed c.lst

For older versions of oracle, use buffer_gets or disk_reads in place of elapsed_time.

Update 02-Mar-07: dba_ views rather than all_ views have to be used to identify what objects to drop prior to datapump, for reasons explained in this post.

For a nightly process to copy small schemas from one database to another, the normal, or old style, way to do that is with export/import in a cron controlled shell script, which would include a sql-from-sql script to drop all the target schema objects before doing the import.

But that presents problems in RAC, which is what I was working on – which node does the cron script reside on? What happens if that node is down?

An option would be to have the script run on another machine, one unrelated to the RAC cluster, but that introduces more points of failure, and means sending data back and forward over sql*net.

So instead I used the oracle’s 10g scheduler and datapump, as below. This data pumps straight over a database link, without having to write to a dump file in between, which is nice. And because it is all in the database, it ought to be unaffected by particular RAC nodes being down.

Some gotchas:

• The documentation for dbms_datapump isn’t at all clear on what the syntax for SCHEMA_LISTS’s should be. It should be this type of format:

  name => 'SCHEMA_LIST' , value => '''SCHEMA1'',''SCHEMA2'''

  which is a lot of quotes. Thanks to Sunit Joshi for that tip in http://www.webservertalk.com/message1791234.html

• The dbms_datapump documentation has a bug: dbms_datapump.open does not have a parameter called “mode“, it has one called “job_mode” instead.
• When calling dbms_datapump from within a stored procedure, as opposed to an anonymous pl/sql block, the owner of the stored procedure has to have had “create table” privilege granted to them explicitly, rather than through a role. That’s detailed in metalink note 315488.1, but I wasted a lot of time trying to debug that before I went on to metalink. The error reported doesn’t help much:

  ERROR at line 1:
  ORA-31626: job does not exist
  ORA-06512: at "SYS.DBMS_SYS_ERROR", line 79
  ORA-06512: at "SYS.DBMS_DATAPUMP", line 911
  ORA-06512: at "SYS.DBMS_DATAPUMP", line 4330
  ORA-06512: at "NIGHTLY_IMPORT", line 4
  ORA-06512: at line 1

• Jobs are created disabled by default with dbms_scheduler, you have to specify “enabled => TRUE” to get them to run.
• new 13-Feb-07 Setting table_exists_action to ‘replace’ overwrites any existing tables ok, but does not replace view definitions, plsql objects, sequences, and so on. They all have to be explicitly dropped before datapump is called. That is quite a tricky counterintuitive limitation of the table_exists_action replace functionality – why would you want new tables copied over but old sequences left in place? It is suprises like this that make old fashioned (but well understood) exp/imp still worth using.
• new 13-Feb-07 Be aware that the dropped tables will stay on in the recyclebin. There is a good recyclebin article at http://orafaq.com/node/968.

Good information on this is at http://orafaq.com/wiki/Datapump and http://orafaq.com/node/862.

Here’s my code. I included a check against a flag table which allows developers to switch the job on and off:

create table run_copy ( run_copy varchar2(3) ) tablespace users ;
grant select, insert, update, delete, references on run_copy to public ;
create public synonym run_copy for run_copy ;
insert into run_copy ( run_copy ) values ( 'Yes' ) ;
create database link nightly_import_sourcedb connect to username identified by password using 'sourcedb' ;
-- procedure owner needs explicit create table
grant create table to username ;

CREATE OR REPLACE PROCEDURE nightly_import AS
  -- Andrew Fraser 30 January 2007
  run_import NUMBER ;
  hand NUMBER ;
BEGIN
  run_import := 0 ;
  SELECT COUNT(*) INTO run_import FROM run_copy WHERE UPPER(run_copy) IN ('N','NO') ;
  IF run_import > 0
  THEN
    -- dont run import if someone has set NO flag in run_copy table
    NULL ;
  ELSE
    -- first have to drop plsql and other objects that table_exists_action does not deal with
    FOR d1 IN ( select object_type, owner, object_name from all_objects
      where object_type in ('FUNCTION','PACKAGE','PROCEDURE','SEQUENCE','SYNONYM','VIEW')
      and owner in ('BACKUP','GATEKEEPER','REFDATA','TRANSDATA','WHSUSR','WHS_VIEWER') )
    LOOP
      execute immediate 'drop '||d1.object_type||' '||d1.owner||'.'||d1.object_name ;
    END LOOP ;
    -- then run datapump import itself
    hand := dbms_datapump.open (
      operation    => 'IMPORT' ,
      job_mode     => 'SCHEMA' ,
      remote_link  => 'nightly_import_sourcedb' ) ;
    dbms_datapump.metadata_filter (
      handle       => hand ,
      name         => 'SCHEMA_LIST' ,
      value        => '''BACKUP'',''GATEKEEPER'',''REFDATA'',''TRANSDATA'',''WHSUSR'',''WHS_VIEWER''' ) ;
    dbms_datapump.set_parameter (
      handle       => hand ,
      name         => 'TABLE_EXISTS_ACTION' ,
      value        => 'REPLACE' ) ;
    dbms_datapump.start_job(hand) ;
  END IF ;
END ;
/

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
   job_name           =>  'run_nightly_import' ,
   job_type           =>  'STORED_PROCEDURE' ,
   job_action         =>  'nightly_import' ,
   start_date         =>  TRUNC(sysdate+1)+4/24 , /* start 4am tomorrow */
   repeat_interval    =>  'FREQ=DAILY; INTERVAL=1', /* run every night */
   enabled            =>  TRUE ,
   comments           =>  'Andrew Fraser 30 January 2007');
END;
/

Even with the code for this method so short, I’m not sure I would always want to use it over cron and old fashioned export/import. But for RAC, and also for Windows servers (because they lack a decent shell scripting language), this is the way to go.