06 Move OMR
05 Disable Firewall
07 Move OMR - Second Attempt

Contents

  1. 1 Overview
  2. 2 References
  3. 3 Preparation
    1. 3.1 Get Platform of Target Database
    2. 3.2 Verify that Platforms are Compatible
    3. 3.3 Check for External Dependencies
    4. 3.4 Check that Database is Transportable
  4. 4 Procedure
    1. 4.1 Stop OMS
    2. 4.2 Prepare Source Database for Transport
      1. 4.2.1 Create PDB for Repository
      2. 4.2.2 Make Tablespaces Read-Only
      3. 4.2.3 Create Export Dump File for Transportable Database

Overview

Now that I set up the EMREPOS database on GORDON , I am ready to move the OEM repository from the REPOS database on GRIDCTRL .

The primary reason for this move is that the 13c version of OEM does not support 11.2.0.4 databases for the repository.

References

Preparation

I need to check if I can transport the REPOS database from GRIDCTRL to the EMREPOS database on GORDON .

This procedure is based on 15.5 Cross Platform Enterprise Manager Repository Migration .

Get Platform of Target Database

On GORDON , the platform for the EMREPOS database is determined as follows: 

SELECT platform_name FROM v$database;

The output was: 

PLATFORM_NAME
----------------
Linux x86 64-bit

Verify that Platforms are Compatible

In the REPOS database on GRIDCTRL , the destination platform of Linux x86 64-bit is checked for database transport compatibility as follows: 

SELECT platform_name FROM v$db_transportable_platform WHERE platform_name = 'Linux x86 64-bit';

The output was: 

PLATFORM_NAME
----------------
Linux x86 64-bit

This means that I can use transportable database to move the REPOS database on GRIDCTRL to the EMREPOS database on GORDON .

Check for External Dependencies

In the REPOS database on GRIDCTRL , the dbms_tdb.check_external function is called as follows to find what external dependencies there are for this database as follows: 

set serveroutput on
declare x boolean;
begin
  x := dbms_tdb.check_external;
end;
/

The output was: 

The following directories exist in the database:
SYS.XMLDIR, SYS.ORACLE_OCM_CONFIG_DIR2, SYS.ORACLE_OCM_CONFIG_DIR,
SYS.DATA_PUMP_DIR

PL/SQL procedure successfully completed.

The good news is that there are no:

  • External tables, or
  • BFILE entries

Check that Database is Transportable

In the REPOS database on GRIDCTRL , the dbms_tdb.check_db function is called as follows to find if this database can be transported to a Linux x86 64-bit platform as follows: 

SET SERVEROUTPUT ON
DECLARE
  retcode BOOLEAN;
BEGIN
  retcode := dbms_tdb.check_db('Linux x86 64-bit', dbms_tdb.skip_none);
END;
/

The following output indicates that there were no errors. 

PL/SQL procedure successfully completed.

Procedure

Stop OMS

This procedure is based on 15.5 Cross Platform Enterprise Manager Repository Migration .

On CRONULLA , the OEM Management Server (OMS) is stopped: 

/opt/app/oracle/middleware/oms/bin/emctl stop oms

The output was: 

Oracle Enterprise Manager Cloud Control 12c Release 4  
Copyright (c) 1996, 2014 Oracle Corporation.  All rights reserved.
Stopping WebTier...
WebTier Successfully Stopped
Stopping Oracle Management Server...
Oracle Management Server Successfully Stopped
Oracle Management Server is Down

Prepare Source Database for Transport

This procedure is based on Transporting a Database Using an Export Dump File . I could not use the RMAN procedure described in 15.5 Cross Platform Enterprise Manager Repository Migration because the source and target are at different Oracle RDBMS versions.

Create PDB for Repository

In the EMREPOS database on GORDON , I followed the procedure in Create a PDB from the SEED PDB to create a PDB called EMREPOSP as follows: 

create pluggable database emreposp
  admin user oem_admin identified by oem_admin
/

The result was: 

Pluggable database created.

Open the PDB as read-write: 

alter pluggable database emreposp open read write;

The result was: 

Pluggable database altered.

Make Tablespaces Read-Only

In the REPOS database on GRIDCTRL , the non-administrative tablespaces should be in READ-ONLY mode. This is accomplished by the following SQL statements: 

ALTER TABLESPACE USERS READ ONLY;
ALTER TABLESPACE MGMT_ECM_DEPOT_TS READ ONLY;
ALTER TABLESPACE MGMT_TABLESPACE READ ONLY;
ALTER TABLESPACE MGMT_AD4J_TS READ ONLY;
ALTER TABLESPACE RMAN_CATALOG READ ONLY;

Create Export Dump File for Transportable Database

In the REPOS database on GRIDCTRL , the following export data-pump command was run to create a export dump file for transporting the database: 

expdp system full=y dumpfile=move_omr.dmp directory=data_pump_dir transportable=always version=12 logfile=move_omr.log

Unfortunately, this failed with the following error messages: 

. . exported "SYSTEM"."SQLPLUS_PRODUCT_PROFILE"              0 KB       0 rows
ORA-39097: Data Pump job encountered unexpected error -920
ORA-39065: unexpected master process exception in DISPATCH
ORA-00920: invalid relational operator

Job "SYSTEM"."SYS_EXPORT_FULL_01" stopped due to fatal error at Sat Sep 17 20:46:42 2016 elapsed 0 00:16:35

Looks like I hit bug 17583185 as described in EXPDP - ORA-39097 ORA-39065 ORA-00911 (invalid Character) With FULL=Y TRANSPORTABLE=Y (Doc ID 1951858.1) .