How to Setup Separate Design and Control Center Repositories (Doc ID 558083.1)

Last updated on FEBRUARY 22, 2023

Applies to:

Goal

This note describes how to setup the OWB environment as described in the following Case Study. Sample database is used in this example.

How do I Manage Multiple Versions of my BI Implementation.

This case study covers two approaches for managing individually changing versions of your BI system once you have implemented in production. The setup in this note can be used as infrastructure for the so called Mature Phase.

In the Mature Phase the Unified Repository has one separate Design Repository and three Control Center Repositories (also known as Runtime Repository). 

In OWB 10.1 Design and Runtime repository objects have their own database schema (Design Repository Owner and Runtime Repository Owner). In the Design repository, developers save the metadata of the projects they create. And the Runtime repository stores all execution statistics when mappings and process flows are executed. A database can host multiple Design and Runtime repositories, each in a separate database schema. Design and Runtime repository can exist in the same database but also in separate databases.

in OWB 10.2 the architecture changed. Both Design and Runtime repository objects are stored into one and the same "Unified Repository". The schema containing the Unified Repository is called (Unified) Repository Owner. A database can store multiple Unified Repositories, each in a separate (Unified) Repository Owner database schema. Users can still create a Unified Repository to store the metadata for the developers of the mappings and process flows, and a separate Unified Repository to store all execution statistics when mappings and process flows are executed. When a Unified Repository is used by OWB developers only for storing metadata of mappings and process flows, the terminology Design Repository is still commonly used. When a Unified Repository is used for runtime statistics only, the terminology Runtime Repository or Control Center Repository is still commonly used. When a Unified Repository is used as a Design Repository only, the Runtime/Control Center repository tables will be empty. When a Unified Repository is used as a Runtime/Control Center Repository only, the Design repository tables will be empty. This is as designed. Users might decide at some point in time to use a Design Repository also as Runtime/Control Center repository so that also the Runtime/Control Center repository tables wil be in use. And the other way around, a Runtime/Control Center Repository might be used later on as a Design repository, so that also the Design tables in the Unified Repository will be in use.

In OWB 11.1 and 11.2 another change in the architecture was introduced. In OWB 10.2 users can have multiple Unified Repositories in the database. Each schema contains all the repository tables. Starting OWB 11g, the Unified Repository tables are stored in one single schema OWBSYS. The repository tables in schema OWBSYS can store multiple Unified Repositories - In OWB 11g known as "Workspaces". Each Workspace has a "Workspace Owner". This is a database schema that has no objects. It has only privileges assigned to get access to its workspace in OWBSYS. OWB Developers start OWB Client and login as the Workspace Owner to connect to a workspace in OWBSYS. Workspace is also called "OWB Repository" and Workspace Owner is also called "OWB Repository Owner".

In this note the following repositories are created:

• Design Repository DESREP

• Runtime Repository DEVCC for Development
• Runtime Repository QA, for Quality Assurance / Test
• Runtime Repository PRODCC for Production

Solution

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.