Use the system requirements document to review the supported platforms on which you can run RCU.

If you do not have a database where you can install schemas, you must install and configure a certified database.

Ensure to review the general and component-specific database requirements that must be met before you run RCU.

Schema creation in RCU is performed in multiple phases; each phase requires a different level of access to your database.

• System Load Phase

  During the system load phase, RCU creates the necessary tablespaces and schemas. If it is not already present, RCU also creates the schema_version_registry. One entry for each component is created in schema_version_registry, and the entry will have the appropriate access and status set to LOADED in the schema_version_registry table.

  User with SYS or SYSDBA privileges must perform these actions; authentication credentials must be provided on the Database Connection Details screen when running RCU.

  If you do not have the necessary privileges, you can select the Prepare Scripts for System Load on the Create Repository screen. This option generates a SQL script that contains the same SQL statements and blocks that would have been called if RCU were to execute the actions for the selected components. After the script is generated, a user with the necessary SYS or SYSDBA privileges can execute the script to complete the system load phase.

  After the system load phase is complete, any user with the privileges described in Granting Permissions to Users for Querying System Load Objects can then run RCU again to complete the schema creation by performing the product load phase.

  Note:

  If you need to generate the script for system load, you can only create schemas on Oracle and Oracle EBR databases; the system load script is not supported on any other database.

  If you are performing the system load with full SYS or SYSDBA privileges, then you can create the schemas on any certified database.

• Product Load Phase

  During the product load phase, RCU creates procedures, functions, tables, indexes, and other objects within schemas and runs any action that does not require DBA access. Any non-DBA user or the REGISTRYOWNER user can be used for this step.

  Before performing the product load phase, the user must be granted the following:

  grant REGISTRYACCESS to user;
  grant STBROLE to user;

  After the product load phase is complete, status is changed to VALID, if there is no post -product load for that component.

• Optional Post-Product Load Phase

  This step is only needed for components that generate the script_postDataLoad.sql script that requires DBA privileges during the system load phase. After the product load phase is complete, someone with SYS or SYSDBA privileges should execute the script_postDataLoad.sql script.

  This step is required for the following components:

  • Audit Services (IAU)

  • Oracle Enterprise Scheduler (ESS)

If you want to give a user with limited privileges the ability to query the system load objects, you must grant the user certain permissions before they can query the system load.

grant select_catalog_role to user;
grant select any dictionary to user;
grant create session to user;
grant select on schema_version_registry to user;

grant REGISTRYACCESS to user;
grant STBROLE to user;

Use custom prefixes to organize and group schemas in your database.

The prefix is prepended to and separated from the schema name with an underscore (_) character, as shown below:

prefix_schemaname

Prefixes:

• Can only contain alpha-numeric characters; no spaces or other special characters.

• Must begin with a letter.

• Must not be longer than 12 characters.

  Note:

  The total length of the prefixed schema name (your custom prefix plus the component schema name) must not be longer than 30 characters.

The default prefix used by RCU is DEV; if DEV has already been used, then RCU defaults to DEV1, then DEV2, and so on. Prefixes are used to create and organize logical groups of schemas. For example, you may want to create a test version of the Metadata Services (schema name MDS) called TEST_MDS; then, when you are ready for your production version, you can create a second version of the schema called PROD_MDS. Both TEST_MDS and PROD_MDS may reside on the same or separate databases.

You are only allowed to use a prefix once per schema within a single database. For example, if you have a version of the Metadata Services schema called DEV_MDS, then you cannot use the DEV prefix again to create another version of the Metadata Services schema (for example, DEV_MDS2).

If you want to create another version of the schema using the same prefix, you must first drop the existing schema and then create the schema again.

The mapping between the prefixes and schemas is maintained in schema_version_registry.

The Service Table schema is a special schema that is automatically created once per prefix. The service table stores basic schema configuration information (for example, schema prefixes and passwords) that can then be accessed and used by other Oracle Fusion Middleware components during domain creation.

For example, the Configuration Wizard has screens which you can configure to use the data that is stored in the service table when RCU was run. After you provide the service table schema credentials, the data from the service table is used to populate the fields on the screen, thus saving you the need to manually populate that data yourself.

Once created, service tables are used to wire Oracle Fusion Middleware components together. For more information about wiring various components together, see Wiring Components to Work Together in Administering Oracle Fusion Middleware.

Before you run RCU, make sure that you understand how schemas can be grouped together and distributed depending on your specific environment.

For more information, the following examples are provided:

• Organizing Schemas on a Single Database for a Single Domain
  This example shows a set of schemas in a single database being used by a single WebLogic domain.
• Organizing Schemas on Multiple Databases for a Single Domain
  This example shows a single set of schemas that are distributed on multiple databases being used by a single WebLogic domain.
• Organizing Schemas on a Single Database for Multiple Domains
  This example shows how schemas on a single database should be grouped for multiple domains.
• Organizing Schemas on Multiple Databases for Multiple Domains
  This example shows how to organize schemas on multiple databases for use with multiple WebLogic domains.

RCU provides extensibility with XML DTDs. Using these DTDs, component owners can integrate their components and prerequisites with RCU by providing a configuration file that adheres to the provided DTD.

For more information about integrating various components, see Extending Repository Creation Utility to Configure Custom Application Repositories.

To connect to an Autonomous Transaction Processing database (both Autonomous Transaction Processing - Dedicated and Autonomous Transaction Processing-Shared), modify the wallet settings and set the environment variables as described in this section.

• Settings to connect to an Autonomous Transaction Processing Database for Oracle Internet Directory
  To connect to Autonomous Transaction Processing database (both Autonomous Transaction Processing - Dedicated and Autonomous Transaction Processing-Shared), for Oracle Internet Directory, modify the wallet settings and set the environment variables as described in this section.

You must apply the required patches on the existing ORACLE HOME, before creating schemas using the Repository Creation Utility screens.

Follow these steps to download and install Java Access Bridge.

1. Download Java Access Bridge from the following URL:

   http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136191.html

2. For complete information and procedure about Java Access Bridge installation, see Java Access Bridge Installation procedure.

To configure RCU to use Java Access Bridge after you complete the installation, set the system variable ORACLE_OEM_CLASSPATH to point to the installed Java Access Bridge files.

1. Display System in the Control Panel.
2. Select the Advanced tab.
3. Click New button in the System Variable list. The New System Variable dialog appears.
4. In the Variable Name field, enter ORACLE_OEM_CLASSPATH.
5. In the Variable Value field, enter the full path for theaccess-bridge.jar and jaccess-1_4.jar.

   Use a semicolon to separate the two paths. Do not use quotes or character spaces.

6. Click OK.