3        Appendix A

Manually modify the occurrences of the Source database user name with a new Target database user name (see the REMAP_SCHEMA attribute mentioned in the Restore the Complete Exported Dumps Into the Target Environment Database section).

1.     Log in to the newly imported Config Schema and update the column values as mentioned in the following table (ignore if there are no rows found).

NOTE:   

V_DB_NAME and DBNAME column name values are TNS aliases for Atomic Schema and must not contain underscores.

For example, if the Target Schema Name is PROD_OFSAAATMNEW, then the value for V_DB_NAME must be entered as PRODOFSAAATMNEW.

2.     Manually modify the occurrences of the Source Config database user name with the new Target Config database user name. See the following table for details.

NOTE:   

Based on the Web Application Server, choose the relevant directory path from Sl. No. 7, 8, or 9 from the above table.

The file mentioned in Sl. No. 10 is not applicable for new installations (that are not upgrade installations from previous versions) of the OFS AAI versions 8.1.0 and higher.

3.     Execute scripts on the Atomic Schemas to update the new Target Config database user name as mentioned in the following steps:

NOTE:   

This step is not applicable for new installations (that are not upgrade installations from previous versions) of the OFS AAI versions 8.1.0 and higher.

a.     Navigate to the $FIC_HOME/commonscripts/ directory on the OFS AAI server.

b.     Create a copy of the ofs_aai_create_atomic.ora file as ofs_aai_create_atomic_<INFODOM>.ora.

c.     Replace the $INFODOM placeholder with the actual infodom name in the ofs_aai_create_atomic_<INFODOM>.ora file.

NOTE:   

Enclose the actual infodom name within a single quote.

INFODOM is associated with each Atomic Schema. Therefore, you must create individual files for each Atomic Schema.

You can fetch the INFODOM value associated with each Atomic Schema by executing the following query in the newly modified Config Schema:

SQL> select h.dbuserid, g.dsnid from dsnmaster g, db_master h where g.dbname = h.dbname and h.dbname <> 'CONFIG';

d.     Connect to the Atomic Schemas using the sqlplus utility present in the $ORACLE_HOME/bin directory.

e.     Execute the ofs_aai_create_atomic_<INFODOM>.ora file and ignore the ORA-00001 and ORA-02292 errors in the log file. If there are other errors, contact My Oracle Support (MOS).

SQL> spool aai_create_<INFODOM>.log

SQL> @ofs_aai_create_atomic_<INFODOM>.ora

SQL> spool off

SQL> exit;

NOTE:   

Repeat this step for all the Atomic Schemas.

After the execution, delete all the files created as ofs_aai_create_atomic_<INFODOM>.ora.

f.       Log in to the newly imported Atomic Schemas. Perform the following steps on each Atomic Schema to modify the interdependent object:

Execute the following query to verify invalid object status:

select object_type, object_name from user_objects
where object_type in ('FUNCTION','PACKAGE','PACKAGE BODY','PROCEDURE','TRIGGER','VIEW') and status = 'INVALID'
order by object_type , object_name;

If the preceding query lists out the objects, then you can compile the invalid objects and enable the object registration elements by following these steps:

i.       Run the following anonymous block to compile the invalid objects:

BEGIN

  FOR cur_rec IN ( select object_type, object_name from user_objects

where object_type in ('FUNCTION','PACKAGE','PACKAGE BODY','PROCEDURE','TRIGGER','VIEW') and status = 'INVALID'

order by object_type , object_name )

  LOOP

    BEGIN

IF cur_rec.object_type = 'PACKAGE BODY' THEN

EXECUTE IMMEDIATE 'ALTER PACKAGE ' || ' "' || cur_rec.object_name || '" COMPILE BODY';

              COMMIT;

              ELSE

EXECUTE IMMEDIATE 'ALTER ' || cur_rec.object_type || ' "' || cur_rec.object_name || '" COMPILE';

              COMMIT;

    END IF;

    EXCEPTION

      WHEN OTHERS THEN NULL;

    END;

  END LOOP;

END;

ii.     Run the following scripts to enable the object registration elements:

spool <Validpath>/restore_owner.log

alter table REV_TABLES_TL disable constraint FK_REV_TABLES_TL_1

/

alter table REV_TABLE_CLASS_ASSIGNMENT disable constraint FK_V_TABLE_CLASS_ASSIGNMENT_2

/

alter table REV_TAB_COLUMNS disable constraint FK_REV_TAB_COLUMNS_1

/

alter table REV_TABLE_LOG_CLASS_ASMNT disable constraint FK_V_TABLE_CLASS_LOG_ASMNT_2

/

alter table REV_TAB_CONSTRAINTS disable constraint FK_REV_TAB_CONSTRAINTS

/

alter table REV_TAB_CONSTRAINT_COLUMNS disable constraint FK_REV_TAB_CONST_COLUMNS

/

alter table REV_TAB_INDEXES disable constraint FK_REV_TAB_INDEXES

/

update FSI_DB_INFO set owner=USER

/

update REV_COLUMN_PROPERTIES set owner=USER

/

update REV_DESCRIPTION_TABLES set owner=USER , DESCRIPTION_TABLE_OWNER=USER

/

update REV_TABLES_B set owner=USER

/

update REV_TABLES_TL set owner=USER

/

update REV_TABLE_CLASS_ASSIGNMENT set owner=USER

/

update REV_TAB_COLUMNS set owner=USER

/

update REV_TAB_COLUMNS_MLS set owner=USER

/

update REV_VIRTUAL_TABLES set owner=USER

/

update REV_VIRTUAL_TABLES_MLS set owner=USER

/

update REV_VIRTUAL_TABLES_TL  set owner=USER

/

update REV_TAB_CONSTRAINTS set owner=USER

/

update REV_SYNONYMS set table_owner=USER

/

update REV_TABLE_LOG_CLASS_ASMNT set owner=USER

/

update REV_TAB_CONSTRAINT_COLUMNS set owner=USER

/

update REV_TAB_INDEXES set owner=USER

/

update REV_TAB_REF_CONSTRAINTS set owner=USER

/

alter table REV_TABLE_LOG_CLASS_ASMNT enable constraint FK_V_TABLE_CLASS_LOG_ASMNT_2

/

alter table REV_TAB_CONSTRAINTS enable constraint FK_REV_TAB_CONSTRAINTS

/

alter table REV_TAB_CONSTRAINT_COLUMNS enable constraint FK_REV_TAB_CONST_COLUMNS

/

alter table REV_TAB_INDEXES enable constraint FK_REV_TAB_INDEXES

/

alter table REV_TAB_COLUMNS enable constraint FK_REV_TAB_COLUMNS_1

/

alter table REV_TABLE_CLASS_ASSIGNMENT enable constraint FK_V_TABLE_CLASS_ASSIGNMENT_2

/

alter table REV_TABLES_TL enable constraint FK_REV_TABLES_TL_1

/

commit

/

spool off

exit;