17 Managing Oracle BI Repository Files

This chapter describes tasks related to managing your Oracle BI repository files, including comparing and merging repositories, equalizing objects, querying and managing metadata, and changing the repository password.

This chapter contains the following topics:

Comparing Repositories

Learn how to compare all repository objects in two different repositories.

If you are using an Oracle BI Applications repository and have customized its content, you can use this feature to compare your customized repository to a new version of the repository received with Oracle BI Applications.

See Merging Repositories.

This section contains the following topics:

Comparing Repositories Using the Compare Dialog

Use this task to compare repositories in the Oracle BI Administration Tool.

The repository that you open is referred to as the current repository. See Using Online and Offline Repository Modes for instructions on opening a repository.

  1. In the Administration Tool, open a repository in offline mode.
  2. From the File menu, select Compare.
  3. In the Select Original Repository dialog, select the repository you want to compare to the open repository. Select Repository from the submenu to select a binary repository file in RPD format, or select XML to select a set of MDS XML documents.
  4. In the Open Offline dialog, enter the repository password and click OK.
  5. Use the Compare repositories dialog to review the differences between repositories.

Comparing Repositories Using comparerpd

You can compare repositories and create patch files using the comparerpd utility.

Use comparerpd on Linux and UNIX systems when the Administration Tool is not available.

When you run the comparerpd utility, the system equalizes the repository objects. The equalizing process outputs the my_current_rpd_equalized.rpd file, an informational file containing the output of the equalization done between the compared repositories. Equalizing ensures that objects with the same qualified names have the same unique identifiers (UIDs). Objects with the same name but different UIDs are automatically updated to use the same UID or equalized. Including when equalization is not needed, the my_current_rpd_equalized.rpd file is generated. The my_current_rpd_equalized.rpd file is saved to the original repository's location.

The location of the comparerpd utility is:

BI_DOMAIN/bitools/bin

Syntax

The comparerpd utility takes the following parameters:

comparerpd [-P modified_rpd_password] -C modified_rpd_pathname 
[-W original_rpd_password] -G original_rpd_pathname {-O output_csv_file_name | 
-D output_patch_file_name | -M output_mds_xml_directory_name} -A -E -8

Where:

-P modified_rpd_password is the repository password for the modified repository, also called the customer or customized repository.

-C modified_rpd_pathname is the name and location of the modified repository.

-W original_rpd_password is the repository password for the original repository.

-G original_rpd_pathname is the name and location of the original repository.

-O output_csv_file_name is the name and location of a csv file where you want to store the repository object comparison output.

-D output_patch_file_name is the name and location of an XML patch file where you want to store the differences between the two repositories.

-M output_mds_xml_directory_name is the top-level directory where you want to store diff information in MDS XML format. A list of removed XML files is stored in the directory tree under the top-level directory at:

oracle\bi\server\base\DeletedFiles.txt

You can specify an output CSV file using -O, an XML patch file using -D, or an MDS XML directory tree using -M. You cannot specify more than one output type at the same time.

If the patch contains passwords, such as connection pool passwords, the patch file is encrypted using the repository password from the current repository. The current repository password effectively becomes the patch file password. You might need to supply this patch file password when applying the patch, if it is different from the repository password for the original repository.

-A is an optional argument that ensures the XML patch file does not contain encrypted passwords for the connection pools. This parameter is used in conjunction with the -D parameter.

-E is an optional argument that causes UIDs to be used to compare expression text. Using this parameter ensures objects that have the same name but different UIDs are given the same UID. This action makes sure that objects are compared as modified instead of being reported as created and deleted. If -E is not specified, strings are used.

-8 specifies UTF-8 encoding.

Note:

The arguments for the modified_rpd_password and original_rpd_password are optional. If you do not provide password arguments, you are prompted to enter any required passwords when you run the command. To minimize the risk of security breaches, Oracle recommends that you do not provide password arguments either on the command line or in scripts. The password arguments are supported for backward compatibility only. For scripting purposes, you can pass the password through standard input.

For example:

comparerpd -C customer.rpd -G original.rpd -O diff.csv
Give password for customer repository: my_cust_password
Give password for original repository: my_orig_password

This example generates a comparison diff file in CSV format called diff.csv from the customer.rpd and original.rpd repositories.

comparerpd -C customer.rpd -G original.rpd -D my_patch.xml
Give password for customer repository: my_cust_password
Give password for original repository: my_orig_password

This example generates an XML patch file called my_patch.xml from the customer.rpd and original.rpd repositories.

Turning Off Compare Mode

You can remove marks applied to objects while using the Compare Repositories and Merge Repositories options.

The Turn off Compare Mode option is only available after you have clicked Mark during the Compare action. If no repository object is marked, this option is not available.

  • In the Administration Tool, select File, then select Turn off Compare Mode.

Equalizing Objects

If you have objects in two repositories that have the same name but different Upgrade IDs, you may want to treat them as the same object.

Use the equalizerpds utility to give the objects in the repositories the same Upgrade ID. You can equalize objects as part of the merge process.

You can also use the Equalize Objects dialog, available from the Compare repositories dialog, to preview the repository after you run the equalizerpds utility.

This section contains the following topics:

About Equalizing Objects

You might need to equalize objects because the Oracle BI Administration Tool tracks the history of each repository object using the Upgrade ID of the object.

The Upgrade ID is a unique identifier for each object.

Sometimes, the Upgrade ID can change because of user actions or during merge. When this occurs, and a subsequent comparison is done, the Oracle BI Administration Tool treats the new Upgrade ID as a new object, and the missing original Upgrade ID as a deleted object.

For example, assume you have two identical repositories. In one repository, delete a presentation column, then re-create it again. When you compare the two repositories using the Compare repositories dialog, there are two entries for the presentation column: one that shows the old object as deleted, and one that shows the new object as created. Without using the Compare repositories dialog, it is hard to tell that this action occurred, because the Administration Tool typically shows only the object name and properties, not the underlying Upgrade ID.

The Upgrade IDs are not unique, in rare cases the repositories that you want to merge might contain the same Upgrade ID. Running the equalizerpds utility on the repositories corrects the duplicate Upgrade ID issue and prevents an error while performing the merge.

Run the equalizerpds utility on your repositories before merging them to equalize your changes. Equalizing any opposing changes such as a column that has been duplicated and then renamed, cleans up the underlying Upgrade IDs, and prevents unintended renaming during the merge.

When you equalize objects, you can lose track of object renames because legitimate object renames become different objects. Intentional renames you did in the repository might change to different Upgrade IDs, so subsequent merges erroneously treat the renamed object as a new object. To avoid the renaming and new object situation, enter the before and after names of intentionally renamed objects in a rename map file that you then pass to the utility. The equalizerpds utility uses the information in the file to ensure that the original IDs are used in the renamed current objects.

You can view the Upgrade ID for repository objects using the Query Repository dialog. See Viewing the Upgrade ID for Repository Objects.

Viewing the Upgrade ID for Repository Objects

You can view the Upgrade ID for repository objects using the Query Repository dialog. When you use this task, a new column showing the Upgrade IDs displays in the Results list.

The Upgrade ID is not available as a column option unless you have selected Show Upgrade ID in Query Repository in the General tab of the Options dialog. See Setting Administration Tool Options.

  1. In the Oracle BI Administration Tool, open a repository in offline mode.
  2. Select Tools, then select Query Repository.
  3. In Query Repository, click Columns.
  4. In Select columns, select Upgrade ID from the list or use Find to help locate the Upgrade ID.
  5. Click Query.

Using the Equalize Objects Dialog

The Equalize Objects dialog provides a preview of what your repository looks like if you run the equalizerpds utility on it.

The Equalize Objects dialog provides a convenient way to compare changes related to objects that have the same name, but it does not persist any of the changes.

Note:

Using the Equalize Objects dialog can be a very slow process for larger repositories.

  1. In the Administration Tool, open your repository in offline mode.
  2. From the File menu, select Compare.
  3. In the Select Original Repository dialog, click Repository from the submenu to select a binary repository file in RPD format, or select XML to select a set of MDS XML documents.
  4. In the Open Offline dialog, enter the repository password and click OK.
  5. In the Compare repositories dialog, click Equalize.
  6. The Equalize Objects dialog shows a list of changes to consider objects with different Upgrade IDs to the same object. You can use the following options to model how the changes might get equalized:
    • Click Automatic to automatically equalize changes related to objects that have the same name. The changes appear in the Equated table.

      If no changes can be automatically equalized, nothing appears in the table, and the OK button remains disabled.

    • Select an object in the Deleted list, then select the equivalent object in the Created list and click Add or Add Plus to equate the objects. Add Plus adds the object along with its child objects to the Equated table, while Add simply adds the selected object. For example, if you select a Subject Area and click Add Plus, the underlying Presentation Tables and Presentation Columns are added as well.

      After you make a manual selection, the Automatic button is disabled.

    • Select a row in the Equated table and select Remove or Remove All to remove objects from the Equated table. Remove All removes the object along with its child objects, while Remove simply removes the selected object

      The Automatic button is enabled after all manual selections are removed.

  7. When you are finished modeling the changes, click OK. The changes appear in the Compare Repositories dialog, but the changes do not persist after you close the dialog.

Using the equalizerpds Utility

You can use the equalizerpds utility to equalize the Upgrade ID of objects in two separate repositories. If objects have the same Upgrade ID, they are considered to be the same object. The utility compares Upgrade IDs from the first repository (the original repository) with Upgrade IDs from the second repository (the modified repository). Then, the utility equalizes the Upgrade IDs of objects with the same name, using the Upgrade ID from the original repository.

The equalizerpds utility is available on both Windows and UNIX systems. You can only use equalizerpds with binary repositories in RPD format.

The location of the equalizerpds utility is:

BI_DOMAIN/bitools/bin

Syntax

The equalizerpds utility takes the following parameters:

equalizerpds [-B original_repository_password] -C original_repository_name
{-E modified_repository_password]|-G} -F modified_repository_name [-I input_UDML_script_name][-J rename_map_file]
[-O output_repository_name] [-R output_apply_result_file] [-U output_id_map_file][-Y equalStringSet]

Where:

G specifies to use the original repository password for the modified repository password.

rename_map_file is a text file containing a list of objects that were renamed and that you want to equalize. The format is a tab-separated file with the following columns:

TypeName     Name1     Name2

For example, to include a logical column in the map file that was renamed from Name1 to Name2, provide the following:

ATTRIBUTE "BusinessModel"."Table"."Name1"     "BusinessModel"."Table"."Name2"

Do not cut and paste this example as the foundation for your own file, because the tab separators might not get copied properly. Create a new file with proper tabs.

See About Values for TypeName.

equalStringSet is a set of characters that you want to treat as equal.

The original_repository_password and modified_repository_password arguments are optional. If you do not provide these password arguments, you are prompted to enter the passwords when you run the command (password1 and password2). To minimize the risk of security breaches, Oracle recommends that you do not provide password arguments on the command line or in scripts. The password arguments are supported for backward compatibility only. For scripting purposes, you can pass the password through standard input.

For example:

equalizedrpds -C original.rpd -F modified.rpd -O modified_equalized.rpd
password1: my_original_rpd_password
password2: my_modified_rpd_password

In this example, original.rpd is compared with modified.rpd, the Upgrade IDs are equalized using the Upgrade IDs from original.rpd, and the final result is written to modified_equalized.rpd.

Note:

Provide the full path names to your repository files, both the input files and the output file, if they are located in a different directory.

About Values for TypeName

Learn about the available object types and their corresponding values for TypeName.

The table shows the available object types and their corresponding values for TypeName.

Object Type Value for TypeName

Database

DATABASE

Connection Pool

CONNECTION POOL

Physical Catalog

CATALOG

Physical Schema

SCHEMA

Physical Display Folder

PHYSICAL DISPLAY FOLDER

Physical Table

TABLE

Physical Key

TABLE KEY

Physical Foreign Key

FOREIGN KEY

Physical Column

COLUMN

Physical Complex Join

JOIN

Physical Hierarchy

HIERARCHY

Physical Level

PHYSICAL LEVEL

Cube Column

COLUMN

Cube Table

CUBE TABLE

LDAP Server

LDAP SERVER

Custom Authenticator

CUSTOM AUTHENTICATOR

Variable

VARIABLE

Application Role

SECURITY ROLE

User

USER

User Database Signon

USER DATABASE SIGNON

Project

PROJECT

Business Model

SUBJECT AREA

Logical Dimension

DIMENSION

Logical Level

LEVEL

Logical Display Folder

LOGICAL DISPLAY FOLDER

Logical Table

LOGICAL TABLE

Logical Source Folder

LOGICAL SOURCE FOLDER

Logical Table Source

LOGICAL TABLE SOURCE

Logical Column

ATTRIBUTE

Logical Join

ROLE RELATIONSHIP

Logical Key

LOGICAL KEY

Logical Foreign Key

LOGICAL FOREIGN KEY

Presentation Catalog

CATALOG FOLDER

Presentation Table

ENTITY FOLDER

Presentation Column

FOLDER ATTRIBUTE

Presentation Hierarchy

PRESENTATION HIERARCHY

Presentation Level

PRESENTATION LEVEL

Catalog Link

CATALOG LINK

Target Level

CUSTOMER TYPE

List Catalog

LIST CATALOG

Qualified Item

QUALIFIED ITEM

Qualifying Key

QUALIFYING KEY

Sampling Table

SAMPLING TABLE

Segmentation Catalog

SEGMENTATION CATALOG

Merging Repositories

You can use the Merge Repository Wizard in the Administration Tool to merge Oracle BI repositories.

You can merge repositories in binary (RPD) format, or MDS XML format. There are three types of merges:

  • Full merges are typically used during development processes, when there are two different repositories that need to be merged. The Administration Tool provides a three-way merge feature that lets you merge two repositories that have both been derived from a third, original repository. Full merges can also be used to import objects from one repository into another.

  • Patch merges are used when you are applying the differential between two versions of the same repository. For example, you might want to use a patch merge to apply changes from the development version of a repository to your production repository, or to upgrade your Oracle BI Applications repository.

    By default, the patchrpd utility's merge functionality uses patch mode. If you want to set up the Merge Repository Wizard to match the patchrpd utility's default merge functionality, then you must set up the Merge Repository Wizard to run in patch mode.

  • Multiuser development merges are used when you are publishing changes to projects using a multiuser development environment, see About the Multiuser Development Merge Process .

See Merge Rules to learn how repository objects are merged.

This section contains the following topics:

Performing Full Repository Merges

You can use the Oracle BI Administration Tool to merge different repositories.

This section describes how to use the full (standard) repository merge feature in the Administration Tool.

This section contains the following topics:

About Full Repository Merges

The merge process typically involves three versions of an Oracle BI Repository: the original repository, modified repository, and current repository.

The original repository is the original repository (the parent repository), while the modified and current repository are the two repositories to merge. The current repository is the one open in the Administration Tool.

During the merge process, the Administration Tool compares the original repository with the modified repository and the original repository with the current repository. Conflicts occur when there are unresolved changes resulting from the two comparisons. For example, a conflict occurs if you rename object A to B in the modified repository, but you rename object A to C in the current repository.

The Merge Repository feature lets you decide on an object-by-object basis which changes you want to keep in the final merged repository. If there are no conflicts, merging is automatic.

There are two types of full merge:

  • Common Parent. This merge, also called a three-way merge, is useful when you have a common parent repository and two derived repositories. There is a parent (original) repository, and two derived repositories. After the merge, a fourth merged repository is created.

    The example shown in the figure below assumes you are merging binary (RPD) repositories, but you can also perform this type of merge with MDS XML repositories.

  • No Common Parent

    A merge when the objects do not have a common parent is also called a two-way merge. Use a two-way merge when to import objects from one repository to another repository. To perform a merge of objects with no common parent use a three-way merge in the Administration Tool with a blank repository as the original repository.

    The example shown in the image below, you are merging binary (RPD) repositories. You can also perform this type of merge with MDS XML repositories.

Performing Full Repository Merges With a Common Parent

Learn how to use the Oracle BI Administration Tool to perform a full repository merge with a common parent.

Use this approach when you have an original parent repository and would like to merge the changes made to objects in two modified repository versions, current and modified. Objects that do not exist in the current repository are created as new objects.

See Equalizing Objects and Merge Strategies Reference.

  1. In the Administration Tool, open the current repository in offline mode.
  2. From the Administration Tool menu, select File, then select Merge.
  3. In the Select Input Files screen, for Merge Type, select Full Repository Merge.
  4. Select the original parent repository by clicking Select next to Original Master Repository. Select Repository from the submenu to select a binary repository file in RPD format, or select XML to select a set of MDS XML documents.

    For binary repositories, browse to select the original repository, and then click Open. For MDS XML format repositories, use the Browse For Folder dialog to select the root folder location of the MDS XML documents, and then click OK.

  5. Provide the password for the original repository in the appropriate Repository Password field.
  6. Select the modified repository by clicking Select next to the Modified Repository field. Select Repository from the submenu to select a binary repository file in RPD format, or select XML to select a set of MDS XML documents.

    For binary repositories, browse to select the modified repository, and then click Open. For MDS XML format repositories, use the Browse For Folder dialog to select the root folder location of the MDS XML documents, and then click OK.

  7. Provide the password for the modified repository in the appropriate Repository Password field.
  8. Optionally, you can change the default name and location of the saved (merged) repository by clicking Select next to the Save Merged Repository as field. Select Repository from the submenu to save the merged repository as a binary repository file in RPD format, or select XML to save the merged repository as a set of MDS XML documents.

    For binary repositories, provide a new name and location, and then click Save. For MDS XML format repositories, use the Browse For Folder dialog to select the root folder location of the MDS XML documents, and then click OK.

  9. It is a good practice to equalize your changes to clean up underlying object IDs before merging. If you have not yet equalized your changes, select Equalize during merge to equalize objects as part of the merge process. Selecting this option may affect merge performance.
  10. Click Next. If there are any conflicts, the Define Merge Strategy screen of the Merge Repository Wizard appears. If there are no conflicts, the Merge Repository Wizard closes.
  11. The Define Merge Strategy screen displays a decision table that shows conflicts for this merge.

    To make decisions about whether to include or exclude objects from the merged repository, choose Current or Modified from the Decision list. Choose Current to keep the change for the selected object in the current repository, or choose Modified to keep the change for the selected object in the modified repository.

    When you select an object in the decision table, the read-only text box below the decision table describes what changes were made to that object in the current repository. In addition, the tree panels at the bottom of the dialog show the affected objects for the selected row. Alternatively, you can select an object in one of the tree views to automatically highlight the corresponding row in the decision table.

    The Modified option in the Decision list displays a suffix that indicates whether the object is added to or deleted from the merged repository. Modified (A) indicates that the object is added, and Modified (D) indicates that the object is deleted.

    The type of conflict is displayed in the Description column of the Conflicts table. The decision choices you can make depend on the type of conflict shown in this column. The following list shows example results for different types of conflicts:

    • Added to Current: Choosing Current keeps the new object in the merged repository. Choosing Modified (D) deletes the new object from the merged repository.

    • Deleted from Current: Choosing Current keeps the repository as it is without adding the object to the merged repository. Choosing Modified (A) adds the object back into the merged repository.

    • Changed in both (different): The object was not added or deleted, but at least one of its properties was modified. Click the plus sign (+) to the left of the row to view the property that was changed, as well as its value in the original, current, and modified versions of the repository. Property values are only shown for small-length strings. Longer-length strings like descriptions, features, and init strings are not shown.

      Click the option for the value you want to retain in the merged version of the repository. For some properties, such as aliases, you can choose the Merge Choices option to merge the properties rather than choose one over the other. This option is only available if the properties can be merged.

      Note:

      You typically do not need to make merge decisions regarding objects that have been added to or deleted from the Modified repository. However, you can view change statistics for this merge to see a summary of changes, including objects that have been added to or deleted from Modified.

    After you make a merge decision, the row for that decision in the table changes from red to black. When all rows have a value in the Decision field, the Finish button is enabled.

  12. In addition to making merge decisions, you can perform other operations in the Define Merge Strategies screen.
  13. Click Finish.
Merge Strategies Reference

Use the table to help with merge decisions when merging repositories with a common parent.

The table lists and describes the elements in the Define Merge Strategies screen.

Element Description

Conflicts table

The Conflicts table includes the following columns:

  • Type: The type of object for which there is a conflict, for example, Presentation Column.

  • Name: The name of the object for which there is a conflict.

  • Description: The reason for the conflict, such as Added to Current. See the previous step for a description of different conflict types.

  • Decision: Select the decision according to what change you want to keep in the merged repository, such as Current, Modified (A), Modified (D), or By Property. See the previous step for a description of the results of different decisions.

For objects with properties that are modified in each repository, a sub-table (grid) is displayed with details of the changed properties. The grid includes the following columns:

  • Property: The name of the property that has been modified in each repository.

  • Original: The value of the property in the original repository.

  • Modified: The value of the property in the modified repository. Select this option to keep this value.

  • Current: The value of the property in the current repository. Select this option to keep this value.

  • Merge Choices: For some properties, like aliases, you can choose this option to merge the property values rather than choose one or the other.

Show qualified names

When selected, shows fully qualified names for objects in the decision table, for example, "Paint"..."Month Year Ago fact".

When the Show qualified names option is selected, some of the object names can be too long to fit into the cells of the decision table. Use the mouse to hover over the truncated name to see the full name of the object or property. Alternatively, you can manually resize columns, or double click the column separator to expand the column to the width of the object name.

Set Default Decisions

When clicked, allows you to choose how the Administration Tool resolves conflicts. Use this option when you do not want to set each conflict's decision manually.

Select All if you want the Administration Tool to resolve all unresolved and resolved conflicts, that is conflicts for which you have already specified decisions. If you choose this option, then the Administration Tool checks the conflict decisions that you have already specified and changes them if necessary.

Select Only undecided if you want the Administration Tool to resolve only the unresolved conflicts. That is, to assign decisions to all conflicts for which you have not specified decisions. When you select this option, the Administration Tool preserves the conflict decisions that you have already specified.

Check consistency of the merged RPD

When selected, runs a consistency check before saving the merged file.

Hide object views

Select this option to hide the tree panels in the dialog. The tree panels show the affected objects for the row selected in the conflicts decision table.

Hiding the tree panels can improve the performance of the Define Merge Strategies screen.

Save Decisions to File

Saves a file containing interim changes in the Repository subdirectory so that you can stop work on the merge and continue it later. After saving the changes (decisions), close the Merge repositories dialog by clicking Cancel.

If there are a large number of decisions, you can save time by saving the merge decisions to a CSV file, opening the file in Excel or a text editor, and then modifying the merge decisions manually. Then, you can load the updated merge decisions file in the Define Merge Strategies screen, or include the decision file as an argument in patchrpd.

Load Decision File

Loads the saved decisions file from the Repository subdirectory so that you can continue processing a repository merge.

This option is especially useful for resolving conflicts after running an automated patch merge using patchrpd. See Using patchrpd to Apply a Patch.

Find by Name or Type

Searches by an object Name and Type such as Initialization Block.

Find Again

Searches again for the most recent Find value.

View Change Statistics

Shows statistics for this merge, such as the number of objects deleted from the Modified repository, the number of objects that were changed in both repositories, and so on.

Details

Shows the text in the read-only text box below the decision table in a separate window.

View Original/Modified/ Current repository

Shows properties for the affected object in the selected repository.

Performing Full Repository Merges Without a Common Parent

Learn how to use the Oracle BI Administration Tool to perform a full repository merge without a common parent.

Use this method when you want to import objects from one repository, the modified repository, into another, the current repository.

Note:

In the repository you choose to define as current, make sure that the Presentation layer references any Physical layer or Business Model and Mapping layer objects that you want to keep. Objects like business models, databases, and connection pools in the current repository that are not referenced by any Presentation layer objects are discarded during the merge. If necessary, you might want to add a placeholder subject area that references the objects before you perform the merge to ensure the desired objects are kept.

See Merge Rules to learn which objects are retained or discarded during the merge process.

  1. In the Administration Tool, select File, then select New Repository to serve as the original repository in the merge.
  2. In the Create New Repository Wizard, provide a name for the repository, for example, blank.rpd.
  3. In Import Metadata, choose No.
  4. Enter and confirm the repository password you want to use for this repository.
  5. Click Finish.
  6. Close the blank repository.
  7. Open the current repository containing the objects you want to import, in offline mode.
  8. From the Administration Tool menu, choose File, then select Merge.
  9. In Select Input Files, for Merge Type, select Full Repository Merge.
  10. Click Select next to Original Master Repository, then click Repository.
  11. Navigate to your blank repository file and click Open and leave the password field blank.
  12. Next to the Modified Repository field, click Select to choose the destination repository.
    1. Select Repository from the submenu to select a binary repository file in RPD format, or select XML to select a set of MDS XML documents.
    2. For binary repositories, browse to select the modified repository, and then click Open.
    3. For MDS XML format repositories, use the Browse For Folder dialog to select the root folder location of the MDS XML documents, and then click OK.
  13. Provide a password for the modified repository in the appropriate Password field.
  14. Click Next.

    If there are any conflicts, the Merge Repository Wizard’s Define Merge Strategy displays a message.

  15. In Define Merge Strategy, choose Current or Modified from the Decision list.

    When you select an object in the decision table, the read-only text box below the decision table describes what changes were made to that object in the current repository. Refer to the table for information about additional options in Define Merge Strategy such as saving merge decisions to a comma-separated values (.csv) file.

    After you make a merge decision, the row for that decision in the table changes from red to black.

  16. Click Finish.

Performing Patch Merges

You can use the patch merge to generate an XML patch file that contains only the changes made to a repository.

This patch can be then applied to the old (original) version of the repository to create the new version.

This merge method is very useful for development-to-production scenarios, and can also be used for Oracle BI Applications customers to upgrade their repository.

This section explains how to generate a patch that contains the differences between two repositories, and then apply the patch to a repository file.

This section contains the following topics:

About Patch Merges

In a patch merge, you create a patch that contains the differences between the current repository and the original repository.

You apply the patch file to the modified repository. Differences between the current and original repository must exist in matching existing projects in both repositories.

In a development-to-production scenario, you have an original parent repository, a current repository that contains the latest development changes, and a modified repository that is the deployed copy of the original repository.

To generate a patch, you open the current repository and select the original repository, then create the patch.

To apply the patch, you open the modified repository and select the original repository, then apply the patch.

In an Oracle BI Applications repository upgrade scenario, the current repository is the latest version of the repository shipped by Oracle, and the original repository is the original repository shipped by Oracle. The modified repository is the one that contains the changes you made to the original repository.

Generating a Repository Patch

Use the Oracle BI Administration Tool to generate a patch that contains the differences between two repositories.

  1. In the Administration Tool, open the current Oracle BI EE repository in offline mode. In other words, open the updated repository that contains the changes you want to put in the patch.

    Note:

    If changes are made using projects, you must add metadata changes to an existing project. Changes made to a new project are lost during the patch merge process.

  2. Select File, then select Compare.
  3. Select the original Oracle BI EE repository. Select Repository from the submenu to select a binary repository file in RPD format, or select XML to select a set of MDS XML documents.
  4. In the Open Offline dialog, enter the repository password and click OK.
  5. It is a good practice to equalize your changes to clean up underlying object IDs before generating a patch.
  6. In the Compare repositories dialog, review the changes between the repositories. Then, click Create Patch.
  7. In the Create Patch dialog, enter a name for the patch file, for example, my_patch.xml, and click Save.

If the patch contains passwords, such as connection pool passwords, the patch file is encrypted using the repository password from the current repository. The current repository password effectively becomes the patch file password. You might need to supply this patch file password when applying the patch, if it is different from the repository password for the original repository.

You can also generate a patch at the command line using the comparerpd utility. See Comparing Repositories Using comparerpd.

Applying a Repository Patch

Use the Oracle BI Administration Tool to apply a patch that contains the differences between two repositories.

Note:

You can apply patches from a larger multiuser repository to a smaller subset extract repository. In this case, only the changes in the subset are applied from the patch.

  1. In the Administration Tool, open the Oracle BI repository in offline mode to apply the patch.
  2. Select File, then select Merge. The Merge Repository Wizard appears.
  3. For Merge Type, select Patch Repository Merge. When you select this option, the Partial Subset Merge field displays. By default, this field is selected and the patch is applied as a partial subset merge. Clear this option if you want the patch applied to the whole repository.
  4. Select the original parent repository by clicking Select next to Original Master Repository. Select Repository from the submenu to select a binary repository file in RPD format, or select XML to select a set of MDS XML documents.

    For binary repositories, browse to select the original repository, and then click Open. For MDS XML format repositories, use the Browse For Folder dialog to select the root folder location of the MDS XML documents, and then click OK.

    Note:

    The original repository cannot be the same as the modified (currently open) repository.

  5. Enter the repository password for the original repository.
  6. Click Select next to Patch File. Browse to select the patch file you want to apply, then click Open. The patch file must be in XML format.
  7. In most cases, you can leave the Patch Password field blank. You only need to supply the patch file password when the patch file contains passwords for objects, such as connection pool passwords, and when the patch file password is different from the original repository password. The patch file password is the same as the password for the current repository.
  8. Optionally, you can change the default name and location of the saved (patched) repository by clicking Select next to the Save Merged Repository as field. Select Repository from the submenu to save the merged repository as a binary repository file in RPD format, or select XML to save the merged repository as a set of MDS XML documents.

    For binary repositories, provide a new name and location, and then click Save. For MDS XML format repositories, use the Browse For Folder dialog to select the root folder location of the MDS XML documents, and then click OK.

  9. Click Finish.
Using patchrpd to Apply a Patch

You can apply a patch using the patchrpd utility.

Use patchrpd when you want to patch repositories on Linux and UNIX systems where the Administration Tool is not available. The patchrpd utility is available on both Windows and UNIX systems. You can only run patchrpd with binary repositories in RPD format.

Unlike the Administration Tool patch feature, patchrpd provides an option to apply default decisions for conflicts automatically. patchrpd also provides the capability to save all conflicts to a decision file so that you can examine the results and determine whether additional manual changes are needed. See Using Patchrpd to Automate the Patch Process.

Patchrpd also provides the ability to select the set of merge rules to apply. By default, the merge rules for patches are used, but you can optionally select to use the full (upgrade) merge rules or the multiuser development merge rules.

The location of the patchrpd utility is:

BI_DOMAIN/bitools/bin

Syntax

The patchrpd utility takes the following parameters:

patchrpd [-P modified_rpd_password] -C modified_rpd_pathname 
[-Q original_rpd_password] -G original_rpd_pathname [-S patch_file_password] 
-I patch_file_pathname [-S patch_file_2_password -I patch_file_2_pathname ...]
[-D input_decision_file_pathname] -O output_rpd_pathname 
[-V output_decision_file_pathname] [-E] [-M mode] [-R] [-A] [-U] [-N] [-8]

Where:

-P modified_rpd_password is the repository password for the modified repository, also called the customer or customized repository.

-C modified_rpd_pathname is the name and location of the modified repository.

-Q original_rpd_password is the repository password for the original repository.

-G original_rpd_pathname is the name and location of the original repository.

-S patch_file_password is the password for the patch file. The patch file password is the same as the password for the current repository. You only need to supply the patch file password when the patch file contains passwords for objects, such as connection pool passwords, and when the patch file password is different from the original repository password.

-I patch_file_pathname is the name and location of the XML patch file you want to apply. You can apply multiple patches by including multiple -I arguments with paired -S arguments, as needed.

-D input_decision_file_pathname is the name and location of a decision file in CSV format that you want to use to affect the behavior of this patch merge. This argument is optional.

-O output_rpd_pathname is the name and location of the RPD output file you want to generate.

-V output_decision_file_pathname is an optional argument that lets you generate a CSV format decision file. The decision file shows all the conflicts from the merge. In other words, the decision file lists the decisions that would have been displayed in the Define Merge Strategy screen of the Merge Wizard in the Administration Tool. The decision file provides a record of all items that could be influenced by user input. This argument must be used in conjunction with the -U argument.

-E is an optional argument that enables you to skip the equalize step.

-M mode is an optional argument that enables you to change the mode of the merge. By default, patchrpd runs in patch mode, in which as many changes as possible are applied silently. To change this default, then for mode specify mud to use merge rules for multiuser development merges, or upgrade to use merge rules for full merges. See Merge Rules.

By default, the Administration Tool's merge functionality uses full merge. If you want to run the patchrpd utility to match the Administration Tool's default merge functionality, then you must specify "upgrade" in the -M mode argument.

-R is an optional argument that skips consistency checking for logical columns. This option can speed up the patch process when the patch file does not contain logical to physical column mappings.

-A is an optional argument that can be used in multiuser development environments to skip subset patching and instead apply the patch using input repository files.

-U is an optional argument that applies default decisions for conflicts automatically so that patchrpd can finish successfully. If you do not include this parameter, patchrpd displays a warning and exits if a conflict is detected.

-N is an optional argument that is used to ignore all non-fatal errors. Examples of non-fatal errors are unresolved objects, duplicated objects, and broken or incorrect expressions.

-8 specifies UTF-8 encoding.

Note:

The arguments for all passwords, including the modified_rpd_password, original_rpd_password, and patch_file_password, are optional. If you do not provide password arguments, you are prompted to enter any required passwords when you run the command. To minimize the risk of security breaches, Oracle recommends that you do not provide password arguments either on the command line or in scripts. The password arguments are supported for backward compatibility only. For scripting purposes, you can send the password through standard input.

For example:

patchrpd -C customer.rpd -G original.rpd -I patch.xml -O patched.rpd 
-V decision.csv -U
Give password for customer repository: my_modified_rpd_password
Give password for original repository: my_original_rpd_password

This example applies a patch called patch.xml to the customer.rpd repository, and then generates an output repository called patched.rpd and an output decision file called decision.csv.

Note:

Provide the full path names to all files, including the repository files and the XML patch file, if they are located in a different directory.

Querying and Managing Repository Metadata

You can use repository queries to help manage repository metadata and configure the repository to handle large complex queries.

This section contains the following topics:

Querying Related Objects

Query Related Objects enables querying objects related to one or more objects that you select from the Physical, Business Model and Mapping, or Presentation layer.

You can only use this feature with objects selected from the same layer. You cannot, for example, query objects related to both a Physical layer object and a Business Model and Mapping layer object. See Repository Query Options.

  1. In the Administration Tool, open your repository.
  2. Select one or more objects of the same type from a single layer, for example, a set of logical columns from the Business Model and Mapping layer.
  3. Right-click the objects and select Query Related Objects.
  4. Select an object type to narrow your search to a particular type of object, or select All Types to query all objects related to your source objects.

After you select an object type, the Query Related Objects dialog is displayed, showing the objects related to your source objects in the Name list.

Repository Query Options

Review this topic to see options available in the Query Repository dialog.

Option Description

Mark

Select one or more objects in the Name list and click Mark to mark the selected objects. To unmark the objects, select them and click Mark again. Marking objects makes them easier to visually identify as you develop metadata.

Set Icon

Select one or more objects in the Name list and click Set Icon to select a different icon for the objects. You can set special icons for objects to help visually identify them as having common characteristics. For example, you might want to pick a special icon to identify columns used only by a specific user group.

To change the icons back to the original icons, select the objects and click Set Icon again. Then, select Remove associated icon and click OK.

Show Qualified Name

Use this option to display the fully qualified name of the objects found by the query.

For example, if you query for logical columns, the default value in the Name list is the column name. However, if you select Show Qualified Names, the value in the Name list changes to businessmodel.logicaltable.column.

Show Parent

Select an object in the Name list and click Show Parent to view the parent hierarchy of an object. If the object does not have a parent, a message appears. You cannot use Show Parent with users or application roles.

In the Parent Hierarchy dialog, you can edit or delete objects. If you delete an object from this dialog, any child objects of the selected object are also deleted.

GoTo

Select one or more objects in the Name list and click GoTo to go to the objects in the Administration Tool view of the repository. The selected objects appear highlighted in the Physical, Business Model and Mapping, or Presentation layer.

The Query Related Objects dialog closes when you choose this option.

Querying the Repository

You can query for objects in the repository to examine and update the internal structure of the repository.

Query a repository and view reports that show such items as all tables mapped to a logical source, all references to a particular physical column, content filters for logical sources, initialization blocks, and security and user permissions. Run a report before making any physical changes in a database that might affect the repository. You can save the report to a file in comma-separated value (CSV) or tab-delimited format.

You can construct a filter to restrict the results to display specific values, save a query, run a previously saved query, or create new repository objects. See Constructing a Filter for Query Results.

  1. In the Administration Tool, open your repository.
  2. Select Tools, then select Query Repository.
  3. In the Query Repository dialog, complete the query information using the table as a guide.
  4. Click Query.

Constructing a Filter for Query Results

Use the Query Repository Filter dialog to create criteria the select the data that you want returned in the results.

If you are constructing a complex filter, you might want to click OK after adding each constraint to verify that the filter construction is valid for each constraint.

You can construct multiple filters. When you do, the Operator field becomes active. When the Operator field is active, you can set AND and OR conditions.

See Query Filter Examples.

In the Options dialog on the General tab, select Show Upgrade ID in Query Repository to enable filtering by Upgrade ID.

  1. In the Administration Tool, select Tools, then select Query Repository.
  2. In the Query Repository dialog, select an item in the Results list or select an item from the Type list, and then click Filter.
  3. In the Query Repository Filter dialog, click the Item field. The Item list contains the items by which you can filter.
  4. In the Item list, select the filter that you want to apply to the Results or Type object you selected in the previous step.
  5. Type information in the Value column, as appropriate.
  6. Click OK to return to the Query Repository dialog.

Query Filter Examples

Review the examples to learn how to use filters in your queries.

Viewing All Databases Referenced In a Business Model

The following example shows how to create a filter that lets you view all databases referenced in a particular business model.

  1. In the Query Repository dialog, select Database from the Type list, and then click Filter.

  2. In the Query Repository Filter dialog, click the Item field, and then select Related to.

  3. Click the ellipsis button to the right of the Value field, and in the list, choose Select object.

  4. In the Select dialog, select the business model by which you want to filter, and then click Select. Your selection appears in the Value field.

  5. Click OK to return to the Query Repository dialog. The filter appears in the box to the left of the Filter button.

  6. Click Query. The Results list shows the databases referenced by the business model you selected.

Viewing All Presentation Columns Mapped to a Logical Column

The following example shows how to create a filter that lets you view all presentation columns mapped to a particular logical column.

  1. In the Query Repository dialog, select Presentation Column from the Type list, and then click Filter.

  2. In the Query Repository Filter dialog, click the Item field, and then select Column.

  3. Click the ellipsis button to the right of the Value field, and in the list, choose Select object.

  4. In the Select dialog, select the column by which you want to filter, and then click Select. Your selection appears in the Value field.

  5. Click OK to return to the Query Repository dialog. The filter appears in the box to the left of the Filter button.

  6. Click Query. The Results list shows the presentation columns mapped to the logical column you selected.

Nested Queries

The following example shows nested queries, where the filter itself is another query.

  1. In the Query Repository dialog, select Logical Column from the Type list, and then click Filter.

  2. In the Query Repository Filter dialog, click the Item field, and then select Related to.

  3. Click the ellipsis button to the right of the Value field, and in the list, choose Set Condition for Physical Column.

  4. In the new Query Repository Filter dialog, click the Item field, and then select Source column.
  5. Click the ellipsis button to the right of the Value field, and in the list, choose Select Object.

  6. In the Browse dialog, select a source physical column (for example, Column A) and click Select.

  7. Click OK in the Query Repository Filter dialog for the subquery condition. This subquery queries all aliases for the source column you selected.

  8. In the Query Repository Filter dialog for the main query, click the Item field in the next row and then select Related to.

  9. Click the ellipsis button to the right of the Value field, and in the list, choose Select Object.

  10. In the Browse dialog, select the same source physical column (for example, Column A) and click Select.

  11. Select OR from the Operator list.

  12. Click OK to return to the Query Repository dialog. The filter appears in the box to the left of the Filter button.

  13. Click Query. The Results list shows a list of logical columns related to either Column A, or aliases of Column A.

Configuring the Repository for Large Complex Queries

Change the OBIS_DISABLE_QUERY_GOVERN_MEMORY parameter value in the obis.properties file to support long and large complex queries that exceed the memory limits imposed by the Oracle BI Server.

The value of OBIS_DISABLE_QUERY_GOVERN_MEMORY itself doesn’t prevent recursive queries from disrupting the availability of the Oracle BI Server. The memory limits are imposed for all queries by default to prevent service disruption. However, the limits might also prevent large, complex queries from running if the query would exceed the built-in limits. Disabling the memory limits of the query governor by setting the OBIS_DISABLE_QUERY_GOVERN_MEMORY value to 1 might allow large, complex queries to run. However, the Oracle BI Server is no longer protected from recursive queries that might disrupt its availability.

Consider changing the OBIS_DISABLE_QUERY_GOVERN_MEMORY value to bypass the memory limits if you see the following error message:

State: HY000. Code: 43119. [nQSError: 43119] Query Failed: (HY000)
State: HY000. Code: 59151. [nQSError: 59151] The user query with request
id:request_ID and logical hash:hash_number exceeded the maximum query governing
memory limit. (HY000)
  1. Open the obis.properties file for editing from the following location:

    obiee_home/user_projects/domains/bi/config/fmwconfig/bienv/OBIS/obis.properties

  2. Append the following to the file:

    OBIS_DISABLE_QUERY_GOVERN_MEMORY=1

  3. Restart the Oracle BI Server, and retry the query.

Changing the Oracle BI Repository Password

Each Oracle BI repository has a password that is used to encrypt its contents.

You create the repository password when you create a new Oracle BI repository file, or when you upgrade a repository from a previous release of Oracle Business Intelligence.

You can change the repository password using the Administration Tool in offline mode, or using the obieerpdpwdchg utility. You cannot change the repository password when the repository is open in the Administration Tool in online mode.

The obieerpdpwdchg utility is especially useful when you want to change the repository password on Linux and UNIX systems where the Administration Tool is not available.

Note:

If you are using the SampleAppLite.rpd or SampleApp.rpd sample repository, you must change the default password the first time you open it in the Administration Tool, for security reasons. See About the SampleApp.rpd Demonstration Repository for the sample repository.

This section contains the following topics:

Changing the Oracle BI Repository Password Using the Administration Tool

Learn how to change your password in the Administration Tool and publish a modified repository.

Use the Upload Repository Command to change the repository password and to publish the modified repository.

  1. Open the repository in the Administration Tool in offline mode.
  2. Select File, then select Change Password.
  3. Enter the current (old) password.
  4. Enter the new password and confirm it. The repository password must be longer than five characters and cannot be empty.
  5. Click OK.
  6. Save and close the repository.

Changing the Oracle BI Repository Password Using the obieerpdpwdchg Utility

Learn how to change the repository password.

Use these steps to change the repository password using the obieerpdpwdchg utility, and then publish the modified repository using the Upload Repository Command.

You must define the repository password with more than five characters. Passwords are masked on the command line unless you include the -C option in the command to disable masking.

  1. Navigate to the obieerpdpwdchg utility, which is located here:

    BI_DOMAIN/bitools/bin

  2. Type the following arguments for obieerpdpwdchg:
    • -I name_and_path_of_existing_repository

    • -O name_and_path_of_new_repository

    Then, enter the current (old) password and the new password when prompted, for example:

    obieerpdpwdchg  -I my_repos.rpd -O my_changed_repos.rpd
    Please enter the repository password:
    
    Please enter a new repository password:
    

OBIS Metadata Compatibility

You can use a current OBIS (Oracle Business Intelligence Server) metadata file with past versions of Oracle Business Intelligence.

As a result, you can open a repository (RPD), XUDML (Oracle BI Server XML API), or BAR (BI archive) file from an Oracle BI EE version such as 12.2.1.3, and modify the file with the 12.2.1.1 Administration Tool, biserverxmlexec, or other tools and utilities.

You can also use older OBIS metadata files with the current version of Oracle BI EE.