The best bet to [...]]]> Oracle export utility when used to export from a lower version of database may not work due to compatibility issues as the export utility expects a set of views that are not present in the database. Even patchset difference between the exp utility and the database can lead to similar issues.

The best bet to deal with the issue is to use the lowest version available at the source/target database.

If you are using Oracle client, opt for the lowest version available for taking the export.

The errors differ based on the version difference between exp utility and the database, the following errors are possible:

9i client against lower versions of 9i database or 10g clients against 9.2.0.4 database can cause the following messages in the export log:

EXP-00056 Oracle error 942 encountered
ORA-00942 table or view does not exist
EXP-00000 Export terminated unsuccessfully

On some 9i R2 versions, the error may be reported as below:

EXP-00008: ORACLE error 942 encountered
ORA-00942: table or view does not exist
EXP-00024: Export views not installed, please notify your DBA
EXP-00000: Export terminated unsuccessfully

9.2.0.6 export client against a 9.2.0.5 can cause the following messages in the export log during the export of partitioned tables.

EXP-00056: ORACLE error 6550 encountered
ORA-06550: line 1, column 48:
PLS-00302: component ‘CHECK_MATCH_TEMPLATE’ must be declared
ORA-06550: line 1, column 14:
PL/SQL: Statement ignored

10.2.0.4 client against a 10.2.0.3 database can cause the following messages in the export log during the export of operators.

. exporting operators
EXP-00008: ORACLE error 904 encountered
ORA-00904: “OLEVEL”: invalid identifier
EXP-00000: Export terminated unsuccessfully

Usage:

Once you set parameter, the value will be returned when ’sysdate()’ is used in the queries/application. To see [...]]]> Setting this parameter to a specified timestamp will make the time constant for the database engine (the clock will not tick) FIXED_DATE is a dynamic parameter and can be changed using the ALTER SYSTEM command.

SQL> ALTER SYSTEM SET FIXED_DATE='2009-09-22-13:00:00';

Once you set parameter, the value will be returned when ’sysdate()’ is used in the queries/application.
To see the server time, you can use systimestamp.

Eg:

SQL> set lines 100
SQL> select sysdate, systimestamp from dual;

SYSDATE					SYSTIMESTAMP
-------					-------------------------
2009 09 22 13:00:00 	10-DEC-09 03.01.41.142940 AM -06:00

This is usually used for testing/development purposes, when the application logic depends on a specific date/time combination.

To set the date back to the ’system’ clock, set the parameter to ‘none’

SQL> alter system set fixed_date='none';

You can try executing the query/job after some time (to allow the other session to complete) or kill the session that has locked the resource to proceed with this situation, use the below query to [...]]]> The below query helps to identify the session that has locked the resource that your session is trying to lock.

You can try executing the query/job after some time (to allow the other session to complete) or kill the session that has locked the resource to proceed with this situation, use the below query to identify the session.

set linesize 140
set pages 100
col username       format a20
col "SID,SESSION#" format a20
col sess_id        format a10
col object format a30
col mode_held      format a10
select     oracle_username || ' (' || s.osuser || ')' username
  ,  s.sid || ',' || s.serial# "SID,SESSION#"
  ,  owner || '.' || object_name object
  ,  object_type
  ,  decode( l.block
     ,       0, 'Not Blocking'
     ,       1, 'Blocking'
     ,       2, 'Global') status
  ,  decode(v.locked_mode
    ,       0, 'None'
    ,       1, 'Null'
    ,       2, 'Row-S (SS)'
    ,       3, 'Row-X (SX)'
    ,       4, 'Share'
    ,       5, 'S/Row-X (SSX)'
    ,       6, 'Exclusive', TO_CHAR(lmode)) mode_held
 from       v$locked_object v
 ,  dba_objects d
 ,  v$lock l
 ,  v$session s
 where      v.object_id = d.object_id
 and        v.object_id = l.id1
 and        v.session_id = s.sid
 order by oracle_username,session_id;

Sample output:

USERNAME	SID,SESSION#	OBJECT		OBJECT_TYPE	STATUS		MODE_HELD
--------	------------	-------------	-----------	------		---------
SCOTT (oracle)	86,30		SCOTT.LOCK_TEST	TABLE		Not Blocking 	Row-X (SX)

To kill the locking session, do as below:

SQL> alter system kill session '86,30';

To identify the locked rows, use the below query:

set lines 200
col object_name for a30
select do.object_name
, row_wait_obj#
, row_wait_file#
, row_wait_block#
, row_wait_row#
, dbms_rowid.rowid_create (1, ROW_WAIT_OBJ#, ROW_WAIT_FILE#,
				ROW_WAIT_BLOCK#, ROW_WAIT_ROW#) ROW_ID
from	v$session s
,	dba_objects do
where	s.ROW_WAIT_OBJ# = do.OBJECT_ID
and do.object_name=upper('<object_name_from_above_query>')
;

OBJECT_NAME	ROW_WAIT_OBJ#	ROW_WAIT_FILE#	ROW_WAIT_BLOCK#	ROW_WAIT_ROW#	ROW_ID
-----------	-------------	--------------	---------------	-------------	------
LOCK_TEST	41862		4		70		0		AAAKOGAAEAAAABGAAA

To simulate the occurrence of this error for testing/learning purposes, do as below in 2 sessions:

Session 1:

SQL> conn scott/tiger;
Connected.

SQL> create table lock_test (x number);
Table created.

SQL> insert into lock_test values(100);
1 row created.

SQL> commit;
Commit complete.

SQL> update lock_test set x=500;
1 row updated.

-- Do not commit.

Session 2:

SQL> conn scott/tiger;
Connected.
declare
y number;
begin
select x into y from lock_test for update nowait;
end;
/

ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified
ORA-06512: at line 4

In this example, data is exported from the Oracle Database instance named PROD to the [...]]]> In scenarios where there is no disk space to hold the export dumps or when migrating schemas across different versions of Oracle, this script helps to do the export/import over the network or on the same server using the Unix pipe.

In this example, data is exported from the Oracle Database instance named PROD to the instance named DEV. The export utility connects to the PROD database using the Net Service name, writes the export dump to a Unix pipe, which is read by the import process that loads the data to the DEV database.

Create a file exp_imp.sh:

#!/usr/bin/ksh

export ORACLE_SID=DEV
export ORACLE_HOME=/oracle/product/10204

# make a unix pipe
export PIPE=exp_imp_pipe
mknod exp_imp_pipe p

# Start the Export and run it in background  - Dont omit the '&' at the end.
exp scott/tiger@PROD file=exp_imp_pipe log=exp_PROD.log buffer=1024000 consistent=y OWNER=HR,APP direct=y statistics=none compress=n  &

# Start the Import
imp scott/tiger ignore=y full=y file=exp_imp_pipe log=imp_DEV.log commit=y buffer=1024000 RESUMABLE=Y &

For big schemas, CONSISTENT=Y may not work as the export may fail with an ORA-01555 snapshot too old error, so you may need to revist the parameter. RESUMABLE=Y at the import side can help to make the session ‘resumable’ in case the import hits any space issues on the target database. The export/import logs can be monitored to view the progress of the activity.

In this example the user scott has enough privilege to exp/imp the data, make sure that you connect to the databases as a privileged user and needless to say, it is recommended to run the job in nohup mode to avoid issues in case connectivity to the server gets disturbed.

Archivelog generation on a daily basis:

Archive log generation on an hourly basis:

1) Activate Force logging on the primary database

In case of unlogged writes to primary database (NOLOGGING  and DIRECT LOAD operations using SQL*Loader),  redo data is not generated.  As the redo required to synch the changes to the standby is not generated, the standby database will not be consistent with the primary.  To [...]]]> Step by Step

1) Activate Force logging on the primary database

In case of unlogged writes to primary database (NOLOGGING  and DIRECT LOAD operations using SQL*Loader),  redo data is not generated.  As the redo required to synch the changes to the standby is not generated, the standby database will not be consistent with the primary.  To prevent such issues, the primary database is forced to log operations. It may also be noted that it is recommended to take a backup of the database after UNRECOVERABLE/NOLOGGING operations as those operations are not recoverable as the redo data is not generated.Use the below command on the primary database to force logging on the database.

SQL> alter database force logging;

This must be done before building the standby database.

2) Prepare Initialization files for the primary and standby databases

# Initialization file for primary database – initorcl.ora

*.audit_file_dest='/oracle/app/oracle/admin/orcl/adump'
*.audit_trail='db'
*.compatible='11.1.0.0.0'
*.control_files='/oradata/orcl/control01.ctl','/oradata/orcl/control02.ctl'
,'/oradata/orcl/control03.ctl'
*.db_block_size=8192
*.db_name='orcl'
*.diagnostic_dest='/oracle/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)'
*.log_archive_dest_1='LOCATION=/oradata/arch/orcl/'
*.log_archive_format='%t_%s_%r.dbf'
*.open_cursors=300
*.pga_aggregate_target=104857600
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=316669952
*.undo_tablespace='UNDOTBS1'

##### Standby related parameters ######## 

*.db_unique_name='orcl'
*.fal_client='ORCL'
*.fal_server='STBY'
*.DB_FILE_NAME_CONVERT=('/oradata/stby/','/oradata/orcl/')
*.LOG_FILE_NAME_CONVERT=('/oradata/stby/','/oradata/orcl/') *.log_archive_config='dg_config=(orcl,stby)'
*.log_archive_dest_2='SERVICE=STBY valid_for=online_logfiles,primary_role)'
*.db_unique_name='STBY'
*.log_archive_dest_state_2=enable
*.standby_file_management=auto

##### End Standby related parameters #######

# Initialization file for standby database - initstby.ora 

*.audit_file_dest='/oracle/app/oracle/admin/stby/adump'
*.audit_trail='db'
*.compatible='11.1.0.0.0'
*.control_files='/oradata/stby/control01.ctl','/oradata/stby/control02.ctl',
'/oradata/stby/control03.ctl'
*.db_block_size=8192
*.db_name='orcl'
*.diagnostic_dest='/oracle/app/oracle'
*.dispatchers='(PROTOCOL=TCP)(SERVICE=orclXDB)'
*.log_archive_dest_1='LOCATION=/oradata/arch/stby/'
*.log_archive_format='%t_%s_%r.dbf'
*.open_cursors=300
*.pga_aggregate_target=104857600
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=316669952
*.undo_tablespace='UNDOTBS1'

##### Standby related parameters#######

*.db_unique_name='stby'
*.log_archive_dest_2='SERVICE=ORCL valid_for=(online_logfile,primary_role)
*.DB_FILE_NAME_CONVERT=('/oradata/orcl/','/oradata/stby/')
*.LOG_FILE_NAME_CONVERT=('/oradata/orcl/','/oradata/stby/')
*.fal_server='ORCL'
*.fal_client='STBY'
*.log_archive_config='dg_config=(orcl,stby)'
*.standby_file_management=auto

##### End Standby related parameters #######

3) Configure Listener for Static service registration

Static service registrations is requierd for the RMAN active database duplication to work.

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = dbapundits)(PORT = 1521))))  SID_LIST_LISTENER =
(
SID_LIST =
(SID_DESC = (ORACLE_HOME = /oracle/app/oracle/product/11.1.0) (SID_NAME = orcl))
(SID_DESC = (ORACLE_HOME = /oracle/app/oracle/product/11.1.0) (SID_NAME = stby))
)

4) Create service names in tnsnames.ora
Add tnsnames.ora entries for primary and standby databases.

ORCL =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = dbapundits)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl)))
STBY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = dbapundits)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = stby)))

5) Create password file for the standby database

The easiest way to do this is to copy the password file from the primary database and to rename it in proper format on the standby server.

$ pwd
/oracle/app/oracle/product/11.1.0/dbs
$ cp orapworcl orapwstby 

6) Perform Oracle 11g standby creation using RMAN DUPLICATE command

run
{
duplicate target database for standby dorecover from active database;
}

The primary database is duplicated as a standby database on the target server (or on same server in this case) using the datafiles from the active database. There is no need of a backup and the datafiles are copied over the network to the target server and is recovered to the point when the duplication was fired.

7) Logs

11g-standby-database-creation-with-rman-duplicate-command – log