Friday, 27 September 2013

Cloning 11gR2

In general it seems to be a simple operation.
First one needs to copy ORACLE_HOME content to the new location (local or remote). The documentation suggests the zip utility, but I think rsync is also a right tool (for a local copy switches -av, for a remote -avz).
Second call runInstaller
$ORACLE_HOME/oui/bin/runInstaller -silent -clone ORACLE_HOME="[the new home]" ORACLE_HOME_NAME="[the new home id]" ORACLE_BASE="/oracle"
The docs do not mention the ORACLE_BASE specification, yet this is inevitable as without it the cloning process exits with information about lack of ORACLE_BASE value.

Wednesday, 18 September 2013

Ora-30372 and what to do further

The error emerges at an mview creation. In my particular case this was an mview on a synonym, which indicated a remote view. The remote view is a subject of an access policy.
The whole issue is described on Oracle Support in the article Ora-30372: Fine Grain Access Policy Conflicts With Materialized View (Doc ID 604046.1).

Wednesday, 11 September 2013

Small tip: moving statistics

Here there is a small experiment. A colleague of mine stated that loading statistics through impdp is a horrible thing in comparison to simple export and import with the dbms_stats package.
begin
-- on the source
dbms_stats.create_stat_table('','','');
dbms_stats.export_database_stats('','','');

-- on the target
-- first impdp stats table
dbms_stats.import_database_stats('','','');
end;
/

I give it a try and I am very glad of the results. The main problem with exporting and importing the statistics with the Data Pump is the operation duration - using dbms_stats will take a fraction of time spent on the export and import with the Data Pump technology.

Monday, 12 August 2013

11g and sys.aud$

A short and relevant article on the maintenence of the audit structures (SYS.AUD$).
Also important news on usage of DBMS_AUDIT_MGMT, which may be used instead of the procedure from the previous link.