This tutorial shows you how to migrate the runtime metadata, existing due to deployments and executions of Warehouse Builder objects in the OWB 10gR1 repository, to the OWB 10gR2 unified repository.
Approximately 30 minutes
This tutorial covers the following topics:
![]() |
Overview | |
![]() |
Prerequisites | |
![]() |
Upgrading Runtime Metadata Using the Control Center Upgrade Assistant | |
![]() |
||
![]() |
Activate the Upgraded Control Center | |
![]() |
Examine the Objects in the Control Center | |
![]() |
Summary |
Place the cursor over this icon to load and view all
the screenshots for this tutorial. (Caution: This action loads all screenshots
simultaneously, so response time may be slow depending on your Internet connection.)
Note: Alternatively, you can place the cursor over each individual icon in the following steps to load and view only the screenshot associated with that step.
After you have migrated the design metadata of the data warehouse project implemented using OWB 10gR1, you also need to migrate the runtime metadata associated with the project. Runtime metadata migration includes steps such as upgrading the previous runtime repository to a control center in the new unified repository and upgrading the locations so that they are owned by the new unified repository.
In OWB 10gR1, runtime repositories were managed by the interface known as the Deployment Manager. In tutorial, "Setting Up the Environment for Migration", you used the Deployment Manager to deploy the objects. Starting from this release, the Control Center Manager replaces the Deployment Manager. The term runtime repository is replaced by the term control center.
If you do not migrate the runtime metadata associated with your warehouse implementation, you will not get the deployment and execution details of the objects in the new repository, and, therefore, you may end up rebuilding your warehouse by redeploying the objects and re-executing the mappings and process flows. Apart from this, you may have issues with precreated locations and connectors. Therefore, you need to perform runtime metadata migration to successfully and completely migrate your warehouse from OWB 10gR1 to OWB 10gR2.
Before starting this tutorial, you should:
1. |
Have completed tutorial "Setting Up the Environment for Migration" |
2. |
Have completed tutorial "Migrating Design Metadata to OWB 10gR2" |
The Control Center Upgrade Assistant performs the following operations to accomplish the majority of runtime metadata migration process:
![]() |
Move Audit Data from a Previous Runtime Repository into a new Unified Repository | |
![]() |
Upgrade the Locations | |
![]() |
Generate TCL script to seed Design Metadata in the Repository |
To move audit data from a previous runtime repository into a new unified repository, perform the following steps:
1. |
To launch the Control Center Upgrade Assistant, from
the [Oracle - OWB10gR2clientHome]\owb\bin\win32 folder, double-click
cc_migrate.bat batch file. The Welcome Page displays.
Click Next.
|
||||||||||||
2. |
In the Connection Information page, specify the connection details of the new unified repository. Enter the following details:
Note: You need to connect to the new unified repository as the repository owner. Click Next.
|
||||||||||||
3. |
In the Choose Operation page, click Move. Observe that the other two buttons, Upgrade and Generate, are disabled. Note: The Move operation transfers location registration information and audit data from the pre-existing runtime repository to the new unified repository. The target unified repository to which you are migrating must be a new one. That means, there must not be any locations registered or deployments or executions performed on this unified repository.
|
||||||||||||
4. |
On clicking Move, another Connection Information window displays. In this window, you specify the connection details of the original repository. Specify the Owner User Name/password of the original runtime repository, as rtrep_101/rtrep_101. The Host Name/Port Number/Oracle Service Name fields default to the host/port/servicename of the target Control Center but can be overwritten. Note: A local migration (i.e. within the same database) does not require the target schemas to be moved; a remote migration (i.e. from one database to another different one) requires that each target schema is moved using database export/import. Click Next. In the Summary page, verify the details and click Finish.
|
||||||||||||
5. |
The Move Audit Data progress bar displays. On successful completion, click OK.
|
1. |
Observe that the Control Center Upgrade Assistant has not exited. After the Move operation is successfully completed, you get back to the Choose Operation window. Click Upgrade. Note: As part of the migration step, locations need to be upgraded so that they can be used against the new unified repository. This means that any audit data created at execution time should now be stored in the new unified repository instead of the previous runtime repository, so that the user does not have to redeploy the executable objects (PL/SQL Maps, Process Flows). The executable objects should be immediately executable after the migration step. A migration should be considered successful only when all registered locations are valid.
|
2. |
The Upgrade Registered Locations window displays. Observe that some of the locations may be shown as Invalid. This is expected behavior after location details have been moved from the original runtime repository. Change the Upgrade status to Valid by individually selecting each location and clicking Upgrade. Select Location Name, LOC_SRC_FILES and click Upgrade. On clicking Upgrade, the Registered Location Details dialog box displays. Enter the password of your local machine and click Get Status. Note: Various checks will be performed against the location details
and the Current Status field will show For example, the screenshot shows that there is 1 error with this location because the password moved during the migration is not the same as the one you entered in this dialog. This is a normal occurrence when migrating from OWB 10gR1 because passwords are handled slightly differently in OWB 10gR2. The Current Status field shows an error and recommends clicking Upgrade to fix the error. Click Upgrade. You get a "Location upgraded successfully" message. Click OK. Observe that the Upgrade Status of LOC_SRC_FILES has changed to Valid.
|
3. |
Similarly, upgrade the other two locations. Select LOC_TGT and click Upgrade. Note that besides each location the type of the location and its connection information is displayed. In Registered Location Details window, enter the password owbtgt, for the owbtgt target schema. Click Get Status. Scroll in the Current Status field to examine the errors. The Current Status field shows 2 errors and recommends clicking Upgrade to fix the error. Click Upgrade. You get a "Location upgraded successfully" message. Click OK. Observe that the Upgrade Status has changed to Valid.
|
4. |
Similarly, you upgrade the Workflow location, PROC_LOC. Select PROC_LOC and click Upgrade. Note: When an Oracle Workflow is being upgraded you may see an error message that indicates that some database links are invalid. These are database links between the Oracle Workflow instance and the Control Center where activities will be executed. In a migration scenario, this probably means that the links are still pointing to the original runtime repository and the upgrade button will update them. In Registered Location Details window, enter the password owf_mgr for the OWF_MGR Workflow schema. Click Get Status. The Current Status field shows errors and recommends clicking Upgrade to fix the error. Click Upgrade. You get a "Location upgraded successfully" message. Click OK.
|
5. |
Note that all the locations are now valid in the new repository. Click OK. Note that the Control Center Upgrade Assistant does not exit and you get back to the Choose Operation window. Now, you generate a tcl script to seed design metadata in the Repository. |
To generate a tcl script that you will run later to seed design metadata in the new repository, perform the following steps:
1. |
In Choose Operation window, click Generate. Note: In OWB 10gR1, location credentials were only stored in the runtime repository, whereas, in OWB 10gR2, location credentials are also stored as design metadata in the unified repository. This wizard generates a tcl script that transfers the following metadata into the new unified repository:
|
2. |
In the Generate Upgrade Script window, view the auto-generated code.
To use this script you need to provide In this scenario, you used OWB_RT as the runtime repository connection to deploy OWB_DEMO objects in OWB 10gR1 repository. Locate the statement : set CC_NAME cc_name and change it to set CC_NAME OWB_RT as shown in the screenshot.
Click Save. In the Save dialog box, select the c:\owb_demo_setup folder and click Open. In the File Name field, enter seed_design.tcl as the filename and Click Save. In the Generate Upgrade Script window, click OK. Again, you get back to the Choose Operation window. Because you have already performed all the three operations, click Next. In the Summary page, examine the details and click Finish. The Control Center Upgrade Assistant exits.
|
When you run the script, the location address details are seeded into the repository. The registration details are added to the logical locations.
1. |
Select Start > Programs > {your Oracle - OWB10gR2clientHome} > Warehouse Builder > OMB Plus. The OMB Plus window displays.
|
2. |
To change your working directory to the path where you saved the seed_design.tcl script, enter the following command at the OMB+> prompt: cd c:\\owb_demo_setup
|
3. |
You need to connect to the repository before you execute the tcl script. To connect to the repository, enter the following command at the OMB+> prompt: OMBCONNECT rep_owner/rep_owner@localhost:1521:orcl10g Note: You will connect to the new repository using the repository owner credentials.
|
4. |
After you are connected, execute the tcl script, seed_design.tcl. Enter the following command at the OMB+> prompt: source seed_design.tcl Note: Observe that the tcl script associates all the locations with the migrated control center and adds credentials for each location in the repository.
|
5. |
To disconnect from the repository, enter the following command at the OMB+> prompt: OMBDISCONNECT Enter exit at the command prompt to exit OMB Plus. |
As explained in tutorial 1, OWB 10gR2 has introduced the concept of Configurations and Control Centers. Each project comes with a default configuration (DEFAULT_CONFIGURATION) that is assigned a default control center (DEFAULT_CONTROL_CENTER).
In previous steps, you upgraded a runtime repository connection, OWB_RT from the OWB 10gR1 repository, to a control center in OWB 10gR2. Now, you will assign the migrated control center, OWB_RT, as an active control center for DEFAULT_CONFIGURATION.
1. |
To start the OWB Design Center, select Start > Programs > [Oracle - OWB10gR2clientHome] > Warehouse Builder > Design Center. The Design Center Logon window displays. Enter rep_owner as username and password.
|
2. |
In the Design Center, from the Tools menu, select Control Center Manager. The Control Center UI displays. Observe that the project OWB_DEMO does not show any objects. This explains why you need to set OWB_RT as the active control center.
|
3. |
In the Design Center, in the project explorer panel, expand Configurations. Right-click DEFAULT_CONFIGURATION and select Open Editor.
|
4. |
In the Edit Configuration window, click the Details tab. Notice that DEFAULT_CONTROL_CENTER is the active Control center for this configuration.
|
5. |
From the Select Control Center list, select OWB_RT. Click OK. OWB_RT is now the active control center for DEFAULT_CONFIGURATION.
|
Now you will examine the objects in the active control center, OWB_RT.
1. |
Now, start the Control Center Manager again. In the Design Center, from the Tools menu, select Control Center Manager. A Connection Information dialog box displays. Enter the username and password for a user who has got the privilege to access the control center, OWB_RT. For example, you could use one of the runtime access users that had the privilege to access the original runtime repository. As part of migration, these users will have been given privilege to access the new control center. Notice that the schema name is changed to that of the new repository owner, rep_owner. Enter the password, rta_101, of the runtime access user, rta_101. Click OK. The Control Center Manager displays.
|
2. |
In the Control Center, notice that all the migrated locations along with the objects they are referencing, are now included.
|
3. |
In LOC_TGT, expand and select TGT. In the Object Details panel on the right, examine the deploy status of all the objects. You will notice that all the objects are shown as successfully deployed except for the dimensions and the cube.
|
4. |
Expand PROC_LOC. Notice that even the process flow is shown as successfully deployed. In a most common scenario, you don't need to re-deploy your process flow packages after migration. Note: If you have upgraded the Oracle database to Oracle 10g and created a new database instance, you also need to upgrade Oracle Workflow on the new Oracle database instance, by using the Oracle Workflow Assistant in Upgrade mode. You should do this before running the Control Center Upgrade Assistant. It will ensure that the registered Oracle Workflow location details are made valid. From the File menu, select Close to exit the Control Center Manager.
|
In this lesson, you learned how to:
![]() |
Upgrade the runtime repository connection to a control center using the Control Center Upgrade Assistant | |
![]() |
Select the new control center as the active control center for the DEFAULT CONFIGURATION | |
![]() |
Examine the migrated objects in the control center |
Place the cursor over this icon
to hide all screenshots.