If you import specifying option ‘rows=n’, then statistics for all imported tables will be locked after the import operation is finished.

That is only for import – an export with ‘rows=n’ is fine, doesn’t lock anything.

That’s probably not what you want to happen – it means that ‘dbms_stats gather’ operations and ‘analyze’ operations will not update optimizer statistics on those tables.

Avoid this by either:

• Specifying option ‘rows=n’ on the export only, not on the import (what I always do anyway); or
• Using DBMS_STATS.UNLOCK_[SCHEMA|TABLE]_STATS to correct after the import is finished.

This is true for all versions from 10gR2 onwards, and it is documented:

• 11gR2 Utilities Manual
• 11gR1 Utilities Manual
• 10gR2 Database Readme

It’s not just old style import – data pump import behaves similarly.

You can see what optimizer statistics are locked in your database with:

select owner, table_name, stattype_locked
from dba_tab_statistics
where stattype_locked is not NULL
order by 1,2 ;

Use DBMS_STATS.UNLOCK_[SCHEMA|TABLE]_STATS and DBMS_STATS.LOCK_[SCHEMA|TABLE]_STATS to switch on and off outside import.

Shell script to demonstrate this:

echo Create table
sqlplus -s "/ as sysdba" <<END_SQL
create table myschema.demo1 ( x number) ;
select stattype_locked from dba_tab_statistics where owner = 'MYSCHEMA' and table_name = 'DEMO1' ;
END_SQL

echo Export
exp \"/ as sysdba\" tables=myschema.demo1 rows=n

echo Drop table
sqlplus -s "/ as sysdba" <<END_SQL
drop table myschema.demo1 ;
END_SQL

echo Import - stats ok
imp \"/ as sysdba\" full=y rows=n
sqlplus -s "/ as sysdba" <<END_SQL
select stattype_locked from dba_tab_statistics where owner = 'MYSCHEMA' and table_name = 'DEMO1' ;
END_SQL

echo Drop table again
sqlplus -s "/ as sysdba" <<END_SQL
drop table myschema.demo1 ;
END_SQL

echo Import this time with rows=n - now stats are locked
imp \"/ as sysdba\" full=y
sqlplus -s "/ as sysdba" <<END_SQL
select stattype_locked from dba_tab_statistics where owner = 'MYSCHEMA' and table_name = 'DEMO1' ;
END_SQL

echo Tidy up
sqlplus -s "/ as sysdba" <<END_SQL
drop table myschema.demo1 ;
END_SQL

exec dbms_stats.delete_database_stats
exec dbms_stats.delete_system_stats
exec dbms_scheduler.run_job('GATHER_STATS_JOB')

That works provided statistics level has not been changed to none

show parameter statistics_level

You can gather more detailed system stats with:

exec dbms_stats.gather_system_stats('START')
exec dbms_stats.gather_system_stats('STOP')

You can see the system stats with:

set pages 9999 lines 112
col pval2 form a20
select * from sys.aux_stats$;

You can check automatic stats gathering job is scheduled with:

select state, last_start_date from dba_scheduler_jobs where job_name = 'GATHER_STATS_JOB';

This has changed for 11g.
To check if it is scheduled in 11g:

select status, max_duration_last_7_days from dba_autotask_client where client_name = 'auto optimizer stats collection' ;

And to run it in 11g:

exec dbms_stats.gather_database_stats_job_proc

exec dbms_stats.create_stat_table ( ownname => user , stattab => 'temp_stats' ) ;
exec dbms_stats.export_table_stats ( ownname => user , stattab => 'temp_stats', tabname => 'mytable', statid => 'Taken_7Apr2010') ;
exec dbms_stats.import_table_stats ( ownname => user , stattab => 'temp_stats', tabname => 'adm_fact' )

Similarly for schema:

exec DBMS_STATS.EXPORT_SCHEMA_STATS ( ownname => 'myowner' , stattab => 'temp_stats', statown => user )

A bug in 10g prevents spaces being passed into the “statid” variable, hence the underscores in the above example.

select state, last_start_date from dba_scheduler_jobs where job_name = 'GATHER_STATS_JOB' ;

Switch it on and off with:

exec dbms_scheduler.disable('GATHER_STATS_JOB')
exec dbms_scheduler.enable('GATHER_STATS_JOB')