1 Understanding Repository Creation Utility

This chapter introduces you to the concepts and features you should be familiar with before using the repository Creation Utility (RCU).

Many of the Oracle Fusion Middleware components require the existence of schemas in a database prior to installation. These schemas are created and loaded in your database using the Repository Creation Utility (RCU).

This chapter contains the following content:

1.1 Verifying RCU System and Database Requirements

This section contains links to important information about supported platforms for RCU, certified databases, and database configuration information. Read this information carefully before you obtain and run RCU.

1.1.1 Verifying Supported Platforms

To see the platforms on which you can run RCU, review the "RCU Supported Platforms" section in the Oracle Fusion Middleware System Requirements and Specifications document.

1.1.2 Finding a Certified Database

For a list of certified databases that can be used with RCU, refer to the certification document for your release, located on the Oracle Fusion Middleware Supported System Configurations page.

1.1.3 Verifying Your Database Configuration

Before you begin using RCU, review the "Repository Creation Utility (RCU) Requirements" section in the Oracle Fusion Middleware System Requirements and Specifications document.

This section contains important information about general and component-specific database requirements that should be met before you run RCU.

Note that not all schemas are supported on all databases. Make sure you have read the information in this section carefully so that you configure a certified database that supports the schemas you need for your Fusion Middleware components.

1.1.4 Verifying Additional Requirements for IBM DB2 Databases

In addition to the typical space and configuration database requirements, IBM DB2 databases also have the following special requirements:

  • On IBM DB2 databases running on Linux operating systems, there is a limitation with regards to the length of the schema names.

  • One database operating system user must be created for each schema that is created in an IBM DB2 database.

For more information, refer to the "RCU Prerequisites for IBM DB2 Databases" section in the Oracle Fusion Middleware System Requirements and Specifications document.

1.2 Preparing for Schema Creation

This section contains important information and concepts regarding schema creation and organization.

The following topics are covered:

1.2.1 Understanding System Load and Product Load

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 will create the necessary tablespaces and schemas and also the schema_version_registry, if it is not already present. One entry for each component will be created in schema_version_registry, and the entry will have the appropriate access and status set to "LOADED" in the schema_version_registry table.

    These actions must be performed by someone with SYS or SYSDBA privileges; 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 Prepare Scripts for System Load on the Create Repository screen. This will generate a SQL script containing all 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 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 will create procedures, functions, tables, indexes and other objects within schemas and run any action that does not require DBA access. Any non DBA user or the REGISTRYOWNER user can be used for this step.

  • Optional Post-Product Load Phase

    This optional step is needed for components that must execute product load scripts requiring DBA privileges.

1.2.2 Granting Permissions to Users for Querying System Load Objects

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

Note:

This user will be used for connecting to the system for queries, but the generated scripts from the system load phase must be run by someone with DBA privileges.

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;

Note:

You may encounter a "Table or view does not exist" error message when you execute the last command; this can be safely ignored.

After performing the system load, grant the following to the same user in order for them to perform data load:

grant REGISTRYACCESS to user;

1.2.3 Understanding Custom Prefixes

Schemas in your database can be grouped together using custom prefixes.

Note:

For important information regarding custom prefixes in IBM DB2 databases, refer to "Size Limit for Schema Prefixes" in the Oracle Fusion Middleware System Requirements and Specifications document.

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

The default prefix used by RCU is DEV; if DEV has already been used, then RCU will default 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 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 had a version of the Metadata Services schema called DEV_MDS, then you can not 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.

1.2.4 Understanding the Service Table Schema

The Service Table schema is a special schema that is installed automatically whenever RCU is run. 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 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, see "Cross-Component Wiring" in Administering Oracle Fusion Middleware.

1.2.5 Planning Your Schema Creation

This section provides examples to help you understand how schemas can be grouped together and distributed depending on your specific environment. The following examples are provided:

Example 1   Organizing Schemas on a Single Database for a Single Domain

Figure 1-1 shows a set of schemas in a single database being used by a single WebLogic domain. This is the simplest scenario in which all schemas using the DEV prefix are grouped together and used by this single WebLogic domain.

Figure 1-1 Schemas on a Single Database for a Single Domain

Description of Figure 1-1 follows
Description of "Figure 1-1 Schemas on a Single Database for a Single Domain"

Example 2   Organizing Schemas on Multiple Databases for a Single Domain

Figure 1-2 shows a single set of schemas distributed on multiple databases being used by a single WebLogic domain.

Figure 1-2 Schemas on Multiple Databases for a Single Domain

Description of Figure 1-2 follows
Description of "Figure 1-2 Schemas on Multiple Databases for a Single Domain"

Note that the same schema prefix (in this case, DEV) can be used to group these related schemas together, even across multiple databases.

Example 3   Organizing Schemas on a Single Database for Multiple Domains

Figure 1-3 shows how schemas on a single database should be grouped for multiple domains.

Figure 1-3 Schemas on a Single Database for Multiple Domains

Description of Figure 1-3 follows
Description of "Figure 1-3 Schemas on a Single Database for Multiple Domains"

In this example, the prefixes are grouped together by using DEV1 for one set of schemas (used by WebLogic Domain 1), and DEV2 for the second set (used by WebLogic Domain 2).

It is not possible to share a single set of schemas across multiple domains; each domain must have its own set of schemas.

Example 4   Organizing Schemas on Multiple Databases for Multiple Domains

Figure 1-4 shows one way to organize schemas on multiple databases for use with multiple WebLogic domains.

Figure 1-4 Schemas on Multiple Databases for Multiple Domains

Description of Figure 1-4 follows
Description of "Figure 1-4 Schemas on Multiple Databases for Multiple Domains"

Note that in this scenario it is possible to have separate domains on the same host use schemas with the same name and prefix (DEV), since the schemas are located on different databases.

1.2.6 Integrating Components Using Declarative XML

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, refer to Appendix C, "Extending Repository Creation Utility to Configure Custom Application Repositories".

1.3 Using RCU with Java Access Bridge (Windows Only)

Java Access Bridge enables assistive technologies, such as JAWS screen reader, to read Java applications running on the Windows platform. Assistive technologies can read Java-based interfaces, such as Oracle Universal Installer and Oracle Enterprise Manager.

1.3.1 Install Java Access Bridge

To install Java Access Bridge:

  1. Download Java Access Bridge from the following URL:

    http://java.sun.com/javase/technologies/accessibility/accessbridge/

  2. Install Java Access Bridge.

  3. Copy the access-bridge.jar and jaccess-1_4.jar from your installation location to the jre\lib\ext directory.

  4. Copy the WindowsAccessBridge.dll, JavaAccessBridge.dll, and JAWTAccessBridge.dll files from your installation location to the jre\bin directory.

  5. Copy the accessibility.properties file to the jre\lib directory.

1.3.2 Configure RCU to Use Java Access Bridge

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 the New button under 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 to access-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.