Aggregates, source control and Monitoring

I have been fortunate enough to have some time to do some housekeeping on the OBIEE systems.

Monitoring.

I think it's fair to say that we had very little monitoring in place, and we knew things were bad when users phoned to say that their pages were 'slow'. Now to get a user to phone you takes some doing, usually they'll live with it, so things must get pretty bad before they do. Luckily this is only n our exploratory areas, otherwise people would be questioning just what it is we do.

Source Control

No-one like interrupting their work to perform a manual step, like source control. it is one of those things that somehow gets missed the one time you really need it. I've been looking at ways to automate this, behind the scenes, totally hands off using SVN (Subversion)

Aggregates 

Need I say more. Level heirarchies and aggregates go hand in hand. If you can provide the least number of rows back to satisfy your answers report, it will run a lot faster that running an aggregate operation over raw data.

Expect a couple of posts over the coming days detailing just what I've been doing.

Renaming Objects in the Business Layer

Rename Wizard

If you need to rename of your business layer objects in the repository, try using the Rename Wizard, found under Tools > Utilities > Rename Wizard. You can also right click objects in the Business Model and Mapping or Presentation layer and Select the rename option from the context menu.

Actually the first line should start WHEN.

You will be able to quickly and globally replace underscores with spaces, database names with business names, change from all caps to first letter capitalized only, and perform many other useful Find and Replace operations. 

The Wizard allows you to create an ordered sequence of operations, and select which repository objects to include in the processing. Be aware though, if you include objects from the presentation layer, the original object names will be preserved as aliases once you have renamed them using the Wizard.

You will be asked to approve all changes before they are applied.



See more in the Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition -- Chapter 18

OBIEE - Mapviewer Error after 11.1.1.7 Upgrade

You may get an error after upgrading your 11.1.1.6 environment to 11.1.1.7.

Here is what to do:

After upgrading to OBIEE 11.1.1.7 mapviewer shows error:

  "HTTP 500 Internal server Error"

When trying URL:

  http://localhost:9704/mapviewer


The log contains :

java.lang.NoClassDefFoundError: oracle/adfinternal/view/faces/taglib/html/HtmlHtmlTag
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
at java.lang.Class.newInstance0(Class.java:326)
at java.lang.Class.newInstance(Class.java:308)
Truncated. see log file for complete stacktrace
>
<Watch 'UncheckedException' with severity 'Notice' on server 'bi_server1' has triggered at Jul 9, 2013 12:00:02 PM CEST. Notification details:
WatchRuleType: Log
WatchRule: (SEVERITY = 'Error') AND ((MSGID = 'WL-101020') OR (MSGID = 'WL-101017') OR (MSGID = 'WL-000802') OR (MSGID = 'BEA-101020') OR (MSGID = 'BEA-101017') OR (MSGID = 'BEA-000802'))
WatchData: DATE = Jul 9, 2013 12:00:02 PM CEST SERVER = bi_server1 MESSAGE = [ServletContext@285430038[app:mapviewer module:/mapviewer path:/mapviewer spec-version:2.5 version:11.1.1]] Root cause of ServletException.
java.lang.NoClassDefFoundError: oracle/adfinternal/view/faces/taglib/html/HtmlHtmlTag
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
......
......
......
at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
SUBSYSTEM = HTTP USERID = SEVERITY = Error THREAD = [ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)' MSGID = BEA-101017 MACHINE = VMBO TXID = CONTEXTID = 3f3d2d8955322f32:-750ddf2f:13fc2ab56ea:-8000-00000000000012de TIMESTAMP = 1373364002231
WatchAlarmType: AutomaticReset
WatchAlarmResetPeriod: 30000
>

CAUSE

Known issue

Need to clean some files

SOLUTION

There is a known issue when upgrading to 11.1.1.7

Here is the workaround:

Workaround:

A number of files have to be removed from the MapViewer deployment and the
Weblogic internal cache of the MapViewer application needs to be deleted.

- Stop the managed server, e.g. bi_server1

(Note : the following step is also required if 11.1.1.7.1 patches are to be
applied)
- Delete the following files from MapViewer deployment, e.g. <middleware
home>/Oracle_BI1/bifoundation/jee/mapviewer.ear

web.war/WEB-INF/lib/adf-faces-api.jar
web.war/WEB-INF/lib/adf-faces-impl.jar
web.war/WEB-INF/lib/commons-digester.jar
web.war/WEB-INF/lib/commons-logging-1.1.jar
web.war/WEB-INF/lib/jsf-api.jar
web.war/WEB-INF/lib/jsf-impl.jar
web.war/WEB-INF/lib/jsr173_1.0_api.jar
web.war/WEB-INF/lib/mvutil.jar
web.war/WEB-INF/lib/xdb.jar
web.war/WEB-INF/adf-faces-config.xml
web.war/WEB-INF/orion-web.xml

- Recursively delete the directory: <middleware
home>/user_projects/domains/bifoundation_domain/servers/bi_server1/tmp/_WL_use
r/mapviewer_11.1.1


- Restart the managed server.

Internal Reference:
Bug 16906739 - UPGRADE OF BIEE FROM 11.1.1.6.0 TO 11.1.1.7.0 CAUSES MAPVIEWER RUNTIME FAILURE

Also documented in the Release notes:

41.6.1.4 MapViewer Runtime Failure After Upgrading from Release 11.1.1.6 to Release 11.1.1.7 (link http://docs.oracle.com/cd/E28280_01/doc.1111/e14770/biee.htm#CHDJIDBD )

MUD - Multi User Development (option file)

Recommendation - Each user of MUD ie. those that will check out projects, make changes and check those changes in, should have a full (simple) install on their local machine.

Before going 'big-bang' on MUD, try all the features in a simple and controlled manner.

Pay particular attention to creating the (hidden) repository.opt file and using the correct options. This has a big impact on the way you will work.

1. The MUD options are set in a file that you create in the MUD shared directory.
2. The filename should be be the same as the MUD master repository ie. if your MUD master is called BIREP.rpd, then your options file should be called BIREP.opt.
3. The file attributes should be set to hidden using the file properties dialog box.
4. As an additional step you may want to disallow edit permissions to all users (beyond a nominated set of administrators).

Note: Any options not explicitly set are considered to be turned off by default.

The contents of the opt file are as below:
[Options]
BuildNumber = Yes
Enforce Build Number = 11.1.1.7.0
Enforce MUD Protocol Version Number = 1
Prevent Rpd Upgrade = Yes
Admin = weblogic;joebloggs
Mandatory Consistency Check = Yes
Equalize During Merge = Yes

To turn an option off either, remove it from the file or set the value from Yes to No.

BuildNumber = Yes - when set to Yes this displays the build version of the administration tool in MUD history.

Enforce Build Number = 11.1.1.7.0 - When set this means that only users with an exact match of Administration Tool version can make changes. To unset this option remove it from the opt file.

Enforce MUD Protocol Version Number = 1 - This option will only allow those users with an exact match of MUD version number to perform changes. Remove this option to disable the enforcement.

Prevent Rpd Upgrade = Yes - Only users with an exact match of repository version can perform changes using MUD. It is possible for later versions (client side) to check out and make changes to the repository and potentially (though unlikely) make changes incompatible with the current master MUD repository . Set to No or remove to disable this option.

Admin = weblogic;joebloggs - This is the list of MUD administrators, seperated by semicolons. Only administrators listed here can delete MUD history.

Mandatory Consistency Check = Yes - A full consistency check is performed at publish to network. All errors in the repository will need to be fixed before publishing completes. Set to No or remove to disable this option.

Equalize During Merge = Yes - A equalisation process takes place during the merge process, potentially affecting performance. The equalization process ensures that objects in the two repositories that have the same name but different upgrade ids are treated as the same object, preventing unintended renaming during the merge.

iPad and OBIEE sessions

There are several users that connect via iPads to view dashboards.

Here's what they look like when connected and you view them in the session manager from the Administration page.

We haven't made any special accommodation for these devices, but they don't seem to suffer as a result of our unintentional neglect and their performance is no worse than through a browser over wifi.