Learn how to use Model Check Manager to check for modeling problems that might affect Oracle BI Summary Advisor and the aggregate persistence engine.
This section contains the following topics:
You can use Model Check Manager to check your repository metadata for issues that might affect the success of Oracle BI Summary Advisor or the aggregate persistence engine.
Although the user experience of running Model Check Manager is very similar to running the Consistency Check Manager, there are three key differences between the two tools:
Unlike the Consistency Check Manager, Model Check Manager requires access to the summary statistics table, when using Filtered by Statistics, and back-end data sources for some checks. Because some of the back-end queries can be expensive, it is recommended to run Model Check Manager during off-peak periods.
Model Check Manager can only be run in online mode.
Model Check Manager does not make any changes to repository metadata - it only flags possible problems.
Similar to the Consistency Check Manager, Model Check Manager returns both error and warning messages. You must fix errors identified by Model Check Manager, or Oracle BI Summary Advisor recommendations might be incorrect, and the aggregate persistence engine might fail to create aggregates. It is recommended that you fix warnings, but not required. Issues identified by warnings result in suboptimal recommendations from Oracle BI Summary Advisor, or suboptimal performance from the aggregate persistence engine.
Model Check Manager runs parallel queries against the database for better performance. By default, 24 threads are enabled. To change the default number of threads for model check manager, create and set an operating system environment variable called MODEL_CHECKER_MAX_THREADS. The maximum number of threads you can specify is 100.
For Oracle BI Summary Advisor, run Model Check Manager after you have gathered Summary Advisor statistics, but before you run the Oracle BI Summary Advisor Wizard.
For aggregate persistence, run Model Check Manager right before you run the Aggregate Persistence Wizard. You can also run Model Check Manager to identify problems for selected objects after initial aggregate creation failure.
globally using the Administration Tool, select the File menu, then select Check Models. Then, choose one of the following options from the submenu:
Complete: Checks all objects in the Business Model and Mapping layer of the Oracle BI repository.
Filtered by Statistics: Checks only fact table objects and associated dimensions in the Business Model and Mapping layer that have been actively queried according to the statistics table. Select this option to speed up the process for large repositories.
This option is only available on the Oracle Exalytics Machine. If you attempt to filter by statistics on a non-Exalytics system, or if you attempt to filter when the statistics table is not available, a warning appears explaining that Model Check Manager cannot filter by statistics.
See the following sections for information about setting up the Summary Advisor statistics table:
To run Model Check Manager for selected objects using the Administration Tool, right-click one or more business models, dimension objects, or logical fact tables and select Check Model. Then, choose Complete or Filtered by Statistics from the submenu, as described in the preceding list. Note that the Filtered by Statistics menu option is only available for fact table objects and business model objects.
When using Model Check Manager with large repositories, it is recommended that you use Filtered by Statistics, or run it only for selected objects, to improve performance.
After running the Model Check Manager for one or more objects, the Model Check Manager opens so that you can correct errors in the repository.
You can check models from the command line using the Oracle BI Server validaterpd utility with the -L option.
Running this utility with -L performs the same model checks as Model Check Manager in the Administration Tool. The validaterpd utility is available on both Windows and UNIX systems.
To run validaterpd in Model Check mode, you must specify the DSN of a running Administration Tool.
The location of the validaterpd utility is:
BI_DOMAIN/bi/bitools/bin
See Using the validaterpd Utility to Check Repository Consistency.
Syntax
The validaterpd utility takes the following parameters in Model Check mode:
validaterpd -L -D DSN_name -U DSN_user_name [-P DSN_password] {-O output_txt_file_name |-C output_csv_file_name | -X output_xml_file_name} [-W] [-S] [-8]
Where:
-L: Specifies Model Check mode.
-D: The DSN of a running Oracle BI Server.
-U: The user name for the Oracle BI Server DSN.
-P: The password for the Oracle BI Server DSN.
The password argument is optional. If you do not provide the password argument, you are prompted to enter the password 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.
Note:
The password argument is supported for backward compatibility only. For scripting purposes, you can pass the password through standard input.
-O Use this option to output the results in a text file.
-C Use this option to output the results in a CSV file.
-X Use this option to output the results in an XML file.
-8 Use this option to specify UTF-8 output (optional).
-W You can optionally include a whitelisted objects file. This text file specifies a limited number of logical objects that you want to check. Enter the fully-qualified name of each logical object on a single line. If -W is not specified, all logical objects are checked.
-S Use this option to check only objects that have been actively queried according to the statistics table. If -S is not specified, all objects are checked. If -W is also specified, the whitelist file can only contain business models and logical fact tables, other objects are not checked. This option is only available on the Oracle Exalytics machine.
Examples
validaterpd -L -D DSNName -U Username -O results.txt Give password: my_dsn_password
The preceding example connects to an RPD using the DSNName connection, checks all models in the RPD, and writes output to results.txt.
validaterpd -L -D DSNName -U Username -O results.txt -W whitelist.txt -S Give password: my_dsn_password
The preceding example connects to an RPD using the DSNName connection, performs a model check, and writes output to results.txt. Only objects listed in whitelist.txt are checked. Furthermore, because -S is specified, only objects that have been actively queried according to the statistics table are checked.
When -W and -S are both specified, the whitelist can only contain business models and logical fact tables. Other objects are not checked.