This chapter contains the following topics:
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:
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.
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.
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.
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:
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.
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.
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.
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.
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 |
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:
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:
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.
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.
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:
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:
|
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 |
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 |
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. |
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.
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:
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.
Use the Oracle BI Administration Tool to generate a patch that contains the differences between two repositories.
See Equalizing Objects.
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.
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.
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.
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:
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.
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.
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 |
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. |
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.
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.
In the Options dialog on the General tab, select Show Upgrade ID in Query Repository to enable filtering by Upgrade ID.
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.
In the Query Repository dialog, select Database from the Type list, and then click Filter.
In the Query Repository Filter dialog, click the Item field, and then select Related to.
Click the ellipsis button to the right of the Value field, and in the list, choose Select object.
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.
Click OK to return to the Query Repository dialog. The filter appears in the box to the left of the Filter button.
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.
In the Query Repository dialog, select Presentation Column from the Type list, and then click Filter.
In the Query Repository Filter dialog, click the Item field, and then select Column.
Click the ellipsis button to the right of the Value field, and in the list, choose Select object.
In the Select dialog, select the column by which you want to filter, and then click Select. Your selection appears in the Value field.
Click OK to return to the Query Repository dialog. The filter appears in the box to the left of the Filter button.
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.
In the Query Repository dialog, select Logical Column from the Type list, and then click Filter.
In the Query Repository Filter dialog, click the Item field, and then select Related to.
Click the ellipsis button to the right of the Value field, and in the list, choose Set Condition for Physical Column.
Click the ellipsis button to the right of the Value field, and in the list, choose Select Object.
In the Browse dialog, select a source physical column (for example, Column A) and click Select.
Click OK in the Query Repository Filter dialog for the subquery condition. This subquery queries all aliases for the source column you selected.
In the Query Repository Filter dialog for the main query, click the Item field in the next row and then select Related to.
Click the ellipsis button to the right of the Value field, and in the list, choose Select Object.
In the Browse dialog, select the same source physical column (for example, Column A) and click Select.
Select OR from the Operator list.
Click OK to return to the Query Repository dialog. The filter appears in the box to the left of the Filter button.
Click Query. The Results list shows a list of logical columns related to either Column A, or aliases of Column A.
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)
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:
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.
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.
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.