Oracle   BI   Server     
          Architecture and Configuration  






The BI Server is a little like an iceberg.  Client applications only see that part of the iceberg that lies above the waterline: to these applications the BI Server appears as a simple ODBC data source.  But, below the surface, the BI Server contains some very sophisticated functionality.  The Server first maps the incoming SQL into multiple subqueries, one for each of the data sources needed to retrieve the query results.  Then it notes the type of each data source – say, an Oracle database, a SAP application, and an XML file – and optimizes each sub-query based on the range of functionality native to that data source – the sub-queries are optimized so that as much of the processing as possible is performed by the data source, and as little as possible by the BI Server.  Then the Server “function ships” the sub-queries to their respective data sources, and integrates the returned results by performing any functionality that can’t be performed at source.  Finally, it returns the results to the ODBC client in the expected format.


In this article we’ll examine the architecture of the BI Server in a basic, non-clustered configuration.



The ODBC Client Perspective


To an ODBC Client the BI Server appears just like any other ODBC data source:

BI Server – Input and Output


While the principal client application for the BI Server is the BI Presentation Services, OBIEE is also shipped with a simple ODBC client for testing purposes – see the “ODBC Client” item on the “Oracle Business Intelligence” menu. 

BI Server can work with any ODBC client


Any third-party ODBC client can also be connected to the BI Server if required.  By adhering to the ODBC standard, Oracle is providing its client base with a great deal of flexibility, allowing reporting software from other vendors to be integrated into OBIEE on a “mix-n-match” basis.



Configuring the BI Server ODBC Data Source


Now, an ODBC Client does not connect directly to the BI Server, but does so through an ODBC data source.  In the case of OBIEE, a data source called “AnalyticsWeb” is installed at the same time as the other OBIEE components.  This data source uses the “Oracle BI Driver” to connect to the BI Server, using 9703 as the default port:

ODBC Data Source for BI Server


If you need to configure the “AnalyticsWeb” data source – to, for example, change the default port – you can do so by navigating to “Start => Control Panel => Administrative Tools => Data Sources (ODBC)”.  When the “ODBC Data Source Administrator” window appears, navigate to the “System DSN” tab:

ODBC Data Source Administrator


Select “AnalyticsWeb” and then press the “Configure” button to change the configuration parameters.  Press “Help” if you need more information (if you do, you’ll notice that Oracle has not been very thorough in rebranding the OBIEE product; the frequent references to “Siebel Analytics” in the help text betray the origins of OBIEE – one of the reasons for Oracle’s 2005, $5.8 billion acquisition of Siebel Systems).


To confirm that the “AnalyticsWeb” data source is indeed being used by the Presentation Services, navigate to “Start => Program Files => Oracle Business Intelligence => Presentation Services”.  Log in using “Administrator” for the “User Id” and “Password”.  Navigate to “Settings => Administration” and you’ll find the following:

Presentation Services Administration


with “AnalyticsWeb” listed as the “Oracle BI Server Data Source”.


To confirm that “AnalyticsWeb” is available as a ODBC data source, navigate to “Start => Program Files => Oracle Business Intelligence => ODBC Client”.  When the “Oracle ODBC Client” window opens, select “File => Open DataBase”, and you’ll find “AnalyticsWeb” listed in the DSN popup:

Oracle BI ODBC Test Client



BI Server Configuration Files


The BI Server makes use of three configuration files: “DBFeatures.ini”, “NQClusterConfig.ini”, and “NQSConfig.ini”.  These files can found in directory “<oraclebi home>\server\config”.  The files are in text format and can be edited using a plain text editor, such as “Notepad”.


Two of these files are read by the BI Server when the server is started:

BI Server – Configuration Files read at Startup


The fact that the files are only read at startup means that any changes made to these files will not take effect until the BI Server has been stopped and then restarted.


File “NQClusterConfig.ini” holds information on clustering and SSL security, and we won’t discuss it in this article.



“NQSConfig.ini” Configuration File


File “NQSConfig.ini” holds almost all the key configuration parameters that you’ll need to change.  A detailed description of the meaning of these parameters can be found in "Appendix A" of the “Oracle Business Intelligence Infrastructure Installation and Configuration Guide” (which you’ll find here).


In particular, note the value of parameter “RPC_SERVICE_OR_PORT” in the “Server” section of the configuration file.  The default port value is 9703.  If you change this value then you must also change the value for the ODBC data source – “AnalyticsWeb” – used by the BI Server.


The section of the configuration file that’s likely to be of most interest is the “Repository” section.  This section lists the repositories that are available to the BI Server for mapping incoming SQL to outgoing commands directed to the relevant data sources.  Typically, one of these repositories will be set as the default, to be used when no repository is explicitly associated with a request:

BI Server – Reading Repository List at Startup


At startup, once the BI server has read the “NQSConfig.ini” file, it will then read the contents of the repositories referenced within that file:

BI Server – Reading Repositories at Startup


All these repositories must be stored in directory “<oraclebi home>\server\repository”.



Editing a Repository


If you open a repository with “Notepad” you’ll discover that it’s coded in a proprietary binary format.  So, as you’ve probably guessed, there must be a software tool to edit the contents of a repository.  This tool is called the “Oracle BI Administration Tool”, and you can open it using the “Administration” item on the “Oracle Business Intelligence” menu.


A repository can be opened in one of two modes: “offline” or “online”.  In offline mode changes made in the Administration Tool are saved to the repository on disk:

Saving Repository Data Offline


In online mode, changes made in the Administration Tool are first checked into the BI Server, changing the values held in memory, so that the changes become immediately visible to users (check-in), and then the checked-in changes are saved by the BI Server to the repository on disk (save) – clearly, useful when you need to perform a “hot-fix”.

Saving Repository Data Online


Once the repository is opened you can view and modify the mapping between the “Presentation Layer” – a semantic model of the data simplified for the benefit of end users, and the “Physical Layer” – the data as it actually exists, distributed among various data sources:

Repository Mapping


By right-clicking on “Connection Pool” in the “Physical Layer”, selecting “Properties”, and pressing “Yes” in the check out pop-up that appears you can view the parameters that define the connection between the BI Server and the database.  In the following example, the BI Server connects to an Oracle database, using a “tnsnames.ora” entry of “bisched” to database schema “sh”:

Data Source Connection Parameters



“DBFeatures.ini” Configuration File


File “DBFeatures.ini” holds information on the capabilities of all the data sources that the BI Server can, in principle, work with.  The file is divided into sections, one for each data source.  The data sources currently supported, excluding version variants, together with their current owners are as follows:


*  Access (Microsoft)

*  Adabas (Software AG)

*  DB2 (IBM)

*  Essbase (Oracle Corporation)


*  IMS (IBM)

*  Informix (IBM)

*  MySQL (Sun Microsystems)

*  Netezza SQL (Netezza)

*  NonStop SQL (HP)

*  ODBC (Generic)

*  Oracle (Oracle Corporation)

*  Redbrick (IBM)


*  SQL Server (Microsoft)

*  SQL Anywhere (Sybase Inc.)

*  Sybase (Sybase Inc.)

*  Teradata (Teradata Corporation)

*  TimesTen (Oracle Corporation)


*  XML (Generic)


Each section of the file contains a set of assertions as to what functionality is, or is not, supported; for example,




is set to “Yes” for the later versions of the Oracle database, but it’s set to “No” for the earlier versions, and for SAP.


By right-clicking on the database name (for example, “orcl SH”) in the “Physical Layer” of the “Administration Tool”, selecting “Properties”, and pressing “Yes” in the check out pop-up that appears you can view the physical database properties.  On the “Features” tab you can view the features imported from the “DBFeatures.ini” file when the schema was imported or defined, together with any overrides to the default values:

Database Features


Normally you’ll have no need to modify these settings, but you can do so if you wish to restrict the range of constructs that are sent to the data source.



Viewing Configuration Files


It’s usually far easier to view the configuration files using an editor, such as “Notepad”.  However, you can use the “jconsole” instead.


First start the agent by opening a command window (“Start => run => cmd”), navigating to directory “<oraclebi home>\systemdmanagement”, and issuing the command “runagent”.


Then start the “jconsole” by opening another command window, selecting the option “” and pressing the “Connect” button.  Select the “MBeans” tab, and then “Oracle BI Management => Configuration”.  The menu items under configuration correspond to various OBIEE configuration files.  For example, the following window shows entries from the “server” section of configuration file “NQSConfig.ini”:

Viewing configuration parameters with Jconsole