Pages

Wednesday 11 November 2015

OBIEE 12c Architecture vs 11g

Quite a lot has happened architecturally under the covers with the release of OBIEE 12c.

OBIEE 12c Architecture diagram


OBIEE 11g Architecture Diagram


There is one major difference...... OPMN is gone in OBIEE 12c.

OBIEE components are now started via a series of commands run from {DOMAIN_HOME}/bitools/bin

  • start
  • stop 
  • status
and it is also possible to run the 'commands' to stop and start the components in (the new look) FMW Enterprise Manager.




Tuesday 10 November 2015

OBIEE 12c - the correct location for the tnsnames.ora file

Where is the correct location for the tnsnames.ora file in OBIEE 12c?


Create or copy your tnsnames.ora file to 

         {DOMAIN_HOME}/config/fmwconfig/bienv/core  

(e.g. /.../Oracle_Home/user_projects/domains/bi/config/fmwconfig/bienv/core/tnsnames.ora)
Note: This would also include other OCI files, such as sqlnet.ora if used.

This is documented in the Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition 12c

see: Setting Up Oracle Database Data Sources


Monday 2 November 2015

OBIEE 12c - RCU - Create Repository

There are a few dependencies when running the OBIEE 12c RCU, one of which is that the database must be at least 11.2.0.4.

After that the next thing you notice after starting the RCU is the options available.

You now have the ability to generate the RCU scripts and pass them on to a DBA to run in seperately, rather than beg for admin access, organise meetings etc... just to run the RCU.

If you have the permissions already then nothing has changed and the top option System Load and Product Load is for you.

The remaining two options are to generate scripts and then load in the product information

  • Select Prepare Scripts for System Load if you are unable to provide login credentials for a user with DBA privileges. RCU will create the necessary SQL scripts for creating the component schema and also update schema_version_registry entry for selected components and change the status to "LOADED." Once the scripts are generated, another user with DBA privileges can run the scripts using SQL*Plus to complete the system load phase. 
  • Select Perform Product Load only after the system load phase scripts have been run to update the schema_version_registry and set the status to "VALID." Users with non-DBA privileges are able to select and execute this option. During the system load phase, some components will generate an additional post-data load script that requires DBA permissions. These scripts will also be run during the product load phase.

This means that the DBA gets to keep control, and you get your repository without ruffling too many feathers.