Obiee Mate

7/30/2019 Obiee Mate

1/26

OBIEE Scripted TestingPosted on July 27, 2011by John Lamont Watson

It is possible to run a pre-defined report against the BI Server via command line and read the

output. The obvious benefit of this is that it allows us to create a suite of tests that could be ran

at the touch of a button.

Input XML File

A single report is defined in OBIEE as XML; that XML is available in the Advanced tab when

defining a request in Answers.

A report has two files associated to it in the Catalog; one of the files will contain this XML andthe other file, an ATR file, is a binary file containing the permissioning for the object. For this

blog we are interested only in the XML File; and that is all we need. We could also use the BI

SQL tranlsation found in the same screen, however, I have found this less reliable.

Executing a Report

Once a report exists as an XML file then we can run it against the BI Server using the NQCMDcommand and the parameters below. The executable is stored in the directoryOracleBI/server/Bin.

d datasource set this as AnalyticsWeb u username such as Administrator

p password such as SADMIN

s source file this would be your XML file o output file the results will be recorded in this file utf16 defines the coding standard to use I would use UTF16

An example of the command as I have used it is below:

nqcmd d AnalyticsWeb u Administrator p SADMIN utf16 s test1.xml o test1.txt

The Output Text File

The results can be displayed to screen and written to a text file. They will display the BI SQL

for the report, which will be followed by the report results (note: there is little formatting and

column headings will be referred to as saw1, saw2 etc).

In Summary

In previous projects I have scripted the running of a set of test reports stored in a test directory.

Output files have then been interrogated automatically seeking a pass or fail. The complexityand flexibility of these scripted tests is really upto you. It can significantly reduce the time taken

for testing cycles.

Posted in Scripting,Testing,obiee | Leave a comment

OBIEE Query HintsPosted on May 11, 2011by John Lamont Watson

Ive found quite a few blogs describing how to add an oracle database hint to a physical table in

OBI; but they all stop short of showing how they can be added to an Alias Object. There is asection at the end of the blog addressing this.
http://testing/http://am/http://watson/http://scripting/http://testing/http://testing/http://obiee/http://obiee/http://businessdecisionsystems.com/blog/?p=265#Testinghttp://hints/http://pm/http://watson/http://testing/http://testing/http://testing/http://am/http://am/http://watson/http://watson/http://watson/http://scripting/http://testing/http://obiee/http://businessdecisionsystems.com/blog/?p=265#Testinghttp://businessdecisionsystems.com/blog/?p=265#Testinghttp://businessdecisionsystems.com/blog/?p=265#Testinghttp://hints/http://hints/http://hints/http://hints/http://pm/http://pm/http://watson/http://watson/http://watson/http://testing/


2/26

Database Hints allow us to change suboptimal SQL Execution Plans; they simply allow us to

provide more information to the optimizer and influence the plan executed. A database hint will

take the form as below.

SELECT

/*+ index(T222,PK) */

ROW_WID as c1FROM

W_CUSTOMER_D T222

OBIEE Query Hints

In OBIEE we can add a database hint to a table object in the physical layer; whenever this table

is referenced in a query the hint will be applied. Importantly, a hint should use the table aliaswhenever a query specifies an alias for a table; the table itself should not be used. If you look at

the underlying SQL of an OIBEE query, via the OBIEE Query Log, you will notice OBIEE will

always use an alias for a table in the generated SQL; an alias taking the form such as T222above.

The first step to adding our hint to a table is to determine the alias that OBIEE will use in thegenerated SQL. Select to Query Repository from the Tools Menu of the Administration Tool.The Query Repository Tool will open, as in the image below. Enter the Name of the table in the

Name textbox and select Physical Table from the Type menu; click query to run the tool. Notice

the use of the wildcard character, *.
http://businessdecisionsystems.com/blog/?p=122http://businessdecisionsystems.com/blog/?p=122http://businessdecisionsystems.com/blog/?p=122http://businessdecisionsystems.com/blog/?p=122


3/26

In this example you can see we have a physical table in the database, W_CUSTOMER_D, and

that I have created an Alias ojbect based on that table of Dim_W_CUSTOMER_D. In the IDcolumn the two objects have IDs of 3001:111 and 3001:222 respectively. If we were using the

table in our query, we can deduce we will use an alias of T111. Actually we used the Alias

object and the database alias generated would be T222. You can see it is the latter segment ofthe ID that is used.

We can now add the hint; a hint can not be added to an OBIEE Alias object, only to an

underlying Table object. We open the properties for the table object and add the hint to the textbox as below.


4/26

You can see that the hint is applied to the OBIEE Alias object, T222; but we are creatingthat definition on the underlying Table object. If there were no Alias object and the table itself

were used in the query then we would need to use the SQL generated alias of T111.

Hinting an Alias Object

But what do we do if we have multiple Alias objects sharing the same underlying Table object;

this happens all the time.

We cant apply the hint to the Alias object itself; instead we apply it to physical joins to and

from the Alias object. The screenshot below shows where we apply the hint for the Alias table

above.


5/26

You can see that weve populated the hint textbox referencing the SQL alias T222. Whenever

this join is used the hint will be added to the query.

Posted in Performance, RPD Metadata, obiee | Leave a comment

OBIEE Report Selection Prompt

Posted on April 4, 2011byJohn Lamont Watson

I was asked yesterday how to create View Selector type functionality that will allow the user toselect between reports, rather than just views of the same report. I have a feeling this information

must already be available, but I said that Id provide instructions on how to achieve this and mayas well add it to my blog.

I will go through the steps with screenshots. We want to create 2 reports, Option 1 and Option 2;we need to create a third report that will return either true or false (results or no results). Both

reports, Option 1 and Option 2 will be placed on the Dashboard, both in their own Sections; and

both sections with Guided Navigation making use of the conditional request. We create a
http://performance/http://metadata/http://obiee/http://businessdecisionsystems.com/blog/?p=486#Hintshttp://prompt/http://pm/http://watson/http://watson/http://performance/http://metadata/http://metadata/http://obiee/http://businessdecisionsystems.com/blog/?p=486#Hintshttp://businessdecisionsystems.com/blog/?p=486#Hintshttp://businessdecisionsystems.com/blog/?p=486#Hintshttp://prompt/http://prompt/http://prompt/http://prompt/http://prompt/http://pm/http://pm/http://watson/http://watson/http://watson/


6/26

Dashboard prompt giving the options of Option 1 and Option 2; and add a filter to the

conditional report so that it filters by the value selected in the prompt. Essentially if Option 1 is

selected in the prompt then Report 1 will be displayed; and if Option 2 is selected then Report 2will be displayed. Reading through this sounds very complex, but it isnt really if you havent

understood then follow the steps below.

Create the Dashboard Prompt

The Dashboard Prompt will display a list of the Reports available; we can enter anything that we

like for each option. To achieve this we must use SQL to generate the Show Values. OBI forcesus to select an existing column to populate the prompt, but we get around this by using the

expresssion CASE WHEN 1=2; the expression will never result to true and will always show the

result of the else statement, our option. We create a SQL statement for each option we would

like in the Prompt and union the statements together (in the order that we would like them toappear).

Note: The Column used should match the values you would like to generate

Prompt Show SQL

For the SQL above, obviously change the references to column, table and Business

Model. Once happy with your SQL I would usually select the Preview Button to check my

code.

Test Prompt Show SQL

For this functionality you would usually not want an All Choices option; uncheck its inclusion.

We should also choose to default to a Specific Value to restrict the list to only valid options.

Click on the elipses button and type your preferred default value from the last - no need forquotes, just the text itself. I would usually verify that the default value is working by viewing the

preview again.

Updated Prompt


7/26

The only remaining task is to populate a Presentation Variable using the Set Presentation

Variable Drop Down. I have created a variable pVar_ViewOption. You will also probably want

to relabel the prompt to something more meaningful and then you can save it.

Set Presentation Variable

Create a Conditional Report

We need to create a conditional report; the report will filter by the presentation variable created.

We will design the report to return values when one Prompt option is selected and return no

values otherwise. Essentially the report will return true or false, based upon the option selectedin the prompt.

We need only a single column in the report; which should be the column referred to by

the prompt. Similar to the expression used in the prompt, we use a CASE statement to alwaysreturn the relevant option; in this case the preffered option.

Conditional Column Expression

We now add the filter to the conditional report to filter this column by the Presentation Variable.

If the option displayed by the column is selected then the report returns results; otherwise itreturns no results.

Conditional Filter


8/26

The Conditional Report is complete. We also need to create the reports to be displayed with

each option. For this example Ive created one for each of the 2 options. So thats 3 reports in

total and a prompt. The screenshot below shows these object in My Folder.

My Folder

Configure the condition on a Dashboard

Create a section for the prompt and another for each report.

Dashboard Layout

We need to use Guided Navigation on each of the Report Sections; we will only show eachsection based upon the results returned by the Conditional Request we have created. The Guided

Navigation setup for Report Option 1 is given below; notice that it returns a report on the

condition the conditional report returns results (ie the prompt selection is our preferred option).

Report Option 1 Guided Navigation

Report 1 - Conditional Navigation

We need to set Guided Navigation for the second report to show when our conditional reportreturns no results, as below.


9/26

Report 2 - Conditional Navigation

And thats the process complete. When we save our Dashboard and view the page our prompt is

shown and defaults to the preferred option; the guided navigation kicks in to display the firstreport and not the second.

Test One

And then when we select the other option in our prompt the guided navigation kicks in to display

only Report Option 2 section, and not our other Report Section.

Report Two Test

It is worth noting that behind the scenes all three reports will be ran by the BI Server. I wouldnt

be concerned unless the approach causes too much load on the server. However, this approachshould not be used to improve performance; it doesnt work like that unfortunately.

Posted in Presentation Services,obiee| Leave a comment

OBIEE MSSQL and Dates

Posted on February 23, 2011byJohn Lamont Watson

My first time working with OBIEE on an MSSQL database. I have a base script that I use tocreate and populate the Date Dimension on an Oracle Database. I have created the equivelent for

MS SQL.
http://services/http://services/http://obiee/http://obiee/http://businessdecisionsystems.com/blog/?p=448#Prompthttp://dates/http://pm/http://watson/http://watson/http://services/http://services/http://obiee/http://businessdecisionsystems.com/blog/?p=448#Prompthttp://businessdecisionsystems.com/blog/?p=448#Prompthttp://businessdecisionsystems.com/blog/?p=448#Prompthttp://dates/http://dates/http://dates/http://dates/http://dates/http://pm/http://pm/http://watson/http://watson/http://watson/


10/26

MSSQL and Dates

For a fuller description on creating an OBIEE Date Dimensionplease follow the link. The bloguses an Oracle Database as an example, but you could replace the Oracle SQL Script with the T-

SQL script above and follow the rest of the article.

Good Luck!

Posted in RPD Metadata,Time & Dates,Uncategorized,obiee| Leave a comment

OBIEE 2 Way Merge


The 2 Way Merge, or Parentless 3 Way Merge, is the most reliable method that we have, out ofthe box, for merging mutliple repository files. If you have no idea what Im talking about then

follow the link to understand the OBIEE 3 Way Merge.

How does it differ from the 3 Way Merge?

Usually we would checkout a Modified RPD from the MUD, taking a snapshot at checkout

called the Original RPD in the process. When we checkin our changes then we take asubsequent snapshot of the MUD called the Current RPD. We merge the Current RPD with the

Modified version, using the Original to help understand the source of conflicts.

We may want to merge 2 entirely different RPDs from different streams of work. I would saythat it is good practice to keep a Trunk (or baseline) RPD and consider this as the Current RPD.

Additional RPDs can be merged into this baseline; they should be merged one at a time and eachtime regarded as the Modified version. A blank RPD should be created and this should be

regarded as our Original version.
http://businessdecisionsystems.com/blog/?p=22http://metadata/http://dates/http://dates/http://uncategorized/http://uncategorized/http://uncategorized/http://obiee/http://obiee/http://businessdecisionsystems.com/blog/?p=438#Dateshttp://merge/http://am/http://watson/http://watson/http://businessdecisionsystems.com/blog/?p=325http://businessdecisionsystems.com/blog/?p=267http://businessdecisionsystems.com/blog/?p=22http://businessdecisionsystems.com/blog/?p=22http://businessdecisionsystems.com/blog/?p=22http://metadata/http://metadata/http://dates/http://dates/http://dates/http://uncategorized/http://obiee/http://businessdecisionsystems.com/blog/?p=438#Dateshttp://businessdecisionsystems.com/blog/?p=438#Dateshttp://businessdecisionsystems.com/blog/?p=438#Dateshttp://merge/http://merge/http://merge/http://merge/http://am/http://am/http://watson/http://watson/http://watson/http://businessdecisionsystems.com/blog/?p=325http://businessdecisionsystems.com/blog/?p=325http://businessdecisionsystems.com/blog/?p=325http://businessdecisionsystems.com/blog/?p=325http://businessdecisionsystems.com/blog/?p=267


11/26

Files required for the Merge

Steps to merge into a single Merged RPD are detailed in the next section.

Creating the Merged RPD

This is not the only method of merging RPDs, but it is quite reliable; there is a short discussion at

the end of the blog, following the How To steps.

Merging 2 Repository FilesMake sure that you have the three source files, as described in the previous section. We need to

open the Current version, which will be your Baseline. I would also take a backup.

Once open, select Merge from the File Menu

Select Merge from File Menu

You will be asked to select the Original Repository; this will be the blank RPD created


12/26

Select the Original RPD In the Merge Repositories Window, click to Select your Modified RPD file

Click to Select Modified RPD Browse to and select the Modified version, the in-coming RPD.

Select the Modified Branch RPD You will need to provide valid credentials to login


13/26

Enter Modified Login Credentials In the Merge Repositories Window you have all source files named; select which RPD to

take each conflict from. Once all conflicts are resolved you may click Merge.

Resolve any Conflicts & click Merge

Once the Merge is complete, click Yes to perform a consistency check; you should dothis

Click Yes to check consistency

All going well there should be no issues; click Close to complete the process

Click Close to complete check

The process is quite straight forward; and although you will find some niggling issues, in the

main it is a reliable one.

Points to Note

The main problem with this approach is that any objects that do not translate into the

Presentation Layer will not be included in the Merged RPD. I think it is rare this issue will

occur; this currently occurs with a client where we have a database used only for a session


14/26

variable; the database is not included in the Merged RPD and the initialization pool errors during

the conssitency check as it does not relate to any Connectin Pool.

To resolve this issue you can manually copy and paste the Database Object into the Merged RPD

at the end of the process. If the process is likely to repeat with a fequency then we can use

UDML scripting to apply the missing objects following the Merge.

There are other methods of merging Repositories, but I find this method most reliable.

Posted in RPD Metadata,Release Management,Uncategorized| Leave a comment

OBIEE Repository Merge


The OBIEE Multi User Development Environment makes use of the three way merge process.

The process itself is described below. This is useful when planning mechanisms in a multiuser

development environment.

When we Checkout a Project we create two RPD files on our local development machine; one is

a snapshot of the Shared MUD RPD, generally referred to as the Original; the other is a subset ofthe MUD RPD containing only our selected project(s), generally referred to as the Modifiedversion. The Original version will be used during Checkin to help determine why any conflicts

have occured between the shared MUD RPD and the Modified version.

The Checkout Process

Changes are configured in the Modified version of the RPD. When we want to check these

changes into the Current (shared) RPD then we start by Merging Local Changes. When we doso, as shown in the diagram below, a lock is placed on the MUD RPD and a current snapshot is

copied locally; the lock ensures the validity of the snapshot (Current.rpd).

Merging Local Changes

The Original, Modified and Current RPDs will be analyzed and conflicts displayed to the user if

choices are required. Once conflicts are resolved the 3 way merge will be actioned, producing asingle Merged RPD. The lock remains on the MUD.rpd; again, ensuring the validity of your

Merged.rpd.
http://metadata/http://management/http://management/http://management/http://uncategorized/http://uncategorized/http://businessdecisionsystems.com/blog/?p=361#Mergehttp://merge/http://am/http://watson/http://watson/http://businessdecisionsystems.com/blog/?p=325http://metadata/http://metadata/http://management/http://management/http://uncategorized/http://businessdecisionsystems.com/blog/?p=361#Mergehttp://businessdecisionsystems.com/blog/?p=361#Mergehttp://businessdecisionsystems.com/blog/?p=361#Mergehttp://merge/http://merge/http://merge/http://merge/http://am/http://am/http://watson/http://watson/http://watson/http://businessdecisionsystems.com/blog/?p=325http://businessdecisionsystems.com/blog/?p=325http://businessdecisionsystems.com/blog/?p=325http://businessdecisionsystems.com/blog/?p=325http://businessdecisionsystems.com/blog/?p=325


15/26

The 3 Way Merge

You can see from the schematics that throughout this process the MUD RPD has been locked toprevent other changes being made. The final step to the process is for us to Publish our Merged

RPD, releasing the lock and overwritting the MUD.rpd.

Publishing the Merged RPD

That is the process completed; the MUD is unlocked and other users are now free to Checkin

their changes. It should be noted that at any point in the process, until we Publish, we could back

out our changes by Discarding Local Changes; this would delete our local files and release thelock on the MUD enabling other developers to checkin their changes.

Discarding Local Changes

But How Does this Help Me?

We can action a 3 way merge manually by selectingMerge from the File Menu and certainly, as

a developer, there will be a point where you will need to merge one code stream into another, ormore correctly a branch of code into the trunk. There are many ways to achieve this, all with

their pros and cons; I have found the most reliable method to be the Parentless 3 Way Merge.

Posted in RPD Metadata,Release Management,obiee| Leave a comment

OBIEE Multi User Development

http://metadata/http://management/http://management/http://management/http://obiee/http://obiee/http://businessdecisionsystems.com/blog/?p=325#Mergehttp://development/http://pm/http://watson/http://watson/http://metadata/http://metadata/http://management/http://management/http://obiee/http://businessdecisionsystems.com/blog/?p=325#Mergehttp://businessdecisionsystems.com/blog/?p=325#Mergehttp://businessdecisionsystems.com/blog/?p=325#Mergehttp://development/http://development/http://development/http://development/http://development/http://pm/http://pm/http://watson/http://watson/http://watson/


16/26

The concept of the MUDE, or Multi User Development Environment, was introduced way back

with Siebel Analytics 7.7. In theory it is really quite simple; in practice, although useful, it can be

tedious.

Setting up the MUD

Set up is very easy. Primarily all you need is a shared folder on a filesystem, accessible to all ofthe relevant developers.

Open the Administration Tool Select Options from the Tools Menu, as in the screenshot below.

Select Options from Tools Menu

Select the Multi-User Tab Browse to the Folder containing your Multi User RPD File

Enter your Name and Click OK

Complete the Options' Multiuser tab

And actually thats it; youre setup. Each developer that requires access must follow the same

process.

Using the MUD

For the rest of this article we will use the samplesales.rpd file as an example. The RPD is

organized into 2 Projects. When we want to work on the RPD in a shared environment we checkout the project that we want to work on; make our changes; merge our code back into the shared

repository and then, once totally happy, publish our merged repository to replace the current

version.


17/26

Checking Out a Project

Select Multiuser, Checkout from the File MenuSelect Multiuser Checkout from the FileMenu

You will be prompted for a Username and Password for the MUD RPD

Provide Username and Password

From the Project List, select the Project(s) that you would like to Checkout and Click OK

Select Project(s) to Checkout

A subset of the Current Repository will be created locally, containing only the project(s)

selected. Choose a name and location for the file; I would just accept defaults; and click

Save.

Save your Modified, or subset, Repository File

The subset Repository, known as the Modified version, is now stored locally and should be openin the Admin Tool. This is the point at which you should generally make changes.


18/26

Merging the Project back into the MUDE

Select Multiuser, Merge Local Changes from the File Menu

Select Multiuser Merge Local Changes from the File Menu

You should receive a request for Lock information, as below. If you dont you willprobably receive Information that the Repository is already locked. The information

may tell you when it is likely to be available, or you may have to contact the person

currently locking it. You dont need to Complete the Lock Information, but it may helpyour fellow developers. Click OK.

Enter Lock Information and Click OK

You will get a Merge Repositories Dialog Box. Any conflicts between your Modified

RPD and the Current RPD will be detailed here; for each conflict you must specify which

specify which RPD is correct; the Merge button will not be available until all conflictsare resolved. Resolve any conflicts and click Merge.

Note: When you Checkout, a copy of the project(s) checked out will be contained in your Modified Repository, stored locally; this will contain

any changes that you have made during Checkout. At the point of Checkout a copy of the whole MUD Repository is also taken and this is

referred to as the Original Repository. The Current Repository is the MUD, containing any changes made since your Checkout. The 3 versions

of the RPD are required for the 3 Way Merge.

At this point you should check Consistency of the Merged Repository, Click Yes


19/26

Click Yes to Check Consistency

All going well, you should recieve a blank sheet as below; click to Close the ConsistencyCheck

Click to Close the Consistency Check

You should now have a copy of the Current Repository with your changes merged. At this pointwe have not committed to the merge; we can still Discard Local Changes; although we would

lose our changes, we would not impact the MUD. We have also locked the MUD so no other

changes can be made until we do either discard these changes or publish them to overwrite theCurrent Repository.

Publishing the Merged Repository

Select Multiuser, Publish to Network from the File Menu

Select Multiuser - Publish to Network

At this point you will be asked again whether you would like a Consistency Check. If you have

made no further changes since the Merge then there is no reason to. However, you are able to

make changes post merge, whilst the Repository is still locked; this second Consistency Check

should be used in this case.When to Configure the Merged RPD

We should configure a locked RPD, post Merge, when our changes could be considered global tothe RPD; such as changing the Administrator password. It is not necessary, but may be useful

for example if we introduced a new Dimension that joins to every Fact. And as you start to use

the MUD you will come to learn there are a couple of strange features that can be overcome byediting in the locked RPD.


20/26

You should remember that this is not a risky approach as you are not committed until you

Publish your changes; but locking the RPD for longer periods may impact other developers.

OBIEE Project Management

So far Ive not mentioned how you organize your RPD into Projects, but you will need to know

how to do this and how to make changes. You can manage projects in either the Checked Out orLocked RPD.

Select Projects from the Manage Menu

Select Project from the Manage Menu

The Project Manager will open; double click to view or edit an existing Project

Double Click on an existing Project to View itNote: To Create a new Project Select NewProject from the Action Menu

In the Project Definition Window the applet on the left shows Objects available in theRPD and the applet on the right shows those Objects included in this Project. Use the

Add and Remove buttons to manage the Objects contained withint this Project and click

OK.

Choose the Objects contained in the Project


21/26

Note: An object can be contained in more than one Project; and indeed the same Project can be checked out by many different users at the same

time.

The next time you Checkout, any new projects should be displayed; and edited projects shouldreflect any changes made.

Posted in RPD Metadata,Release Management,obiee| 1 Comment

OBIEE PerformancePosted on January 14, 2011by John Lamont Watson

I dont think that Ive been involved in a project yet that did not meet performance hurdles. We

have always overcome them, but do tend to be found towards the end of the project when things

are already stressfull enough. I have decided to blog about the subject and hopefully help somepeople.

Performance is a large issue to cover; I guess that I will create quite a few blogs that will

hopefully stitch together nicely. This is really just an introduction to the text.

What can we tune

When you come across obiee Performance issues then there are 4 main areas that you may lookat to try and improve performance.

SQL Tuning

Database Tuning System Tuning

Network Tuning

Of these areas it is most likely that you will spend your time in the first area, SQL tuning, andthat is area that I will cover. The BI Server is really an engine that uses the definitions given in

the RPD to translate user Requests into SQL, submit them to the relevant datasource(s) and

return the result. The definitions determine the SQL ultimately created; we use the definitions in

the RPD file to ultimately determine the SQL generated.

Where do we Start

Because tuning is such a big subject when we get hit with a problem it can be quite

overwhelming to resolve it; when the issue is down to SQL Performance then we can follow a 3

step process. Actually, the process is similar regardless, but we will only be looking at SQL

Performance.

1 - Isolate the Problem to a Single SQL Statement

To make the problem manageable then we need to reduce the issue to its most basic form; forexample remove tables and columns in the query to only those causing the issue. It may be that

there is an issue with the join to one dimension from the fact and another issue to another

dimension; treat them differently, they may well be different issues. They may be the sameissue, but breaking the issue down will make it more manageable and help to understand the

overall problem.

To isolate the problem, the first thing that we do must be to derive the SQL submitted by the BIServer. We have a blog on the obiee query log, which will help if you dont know how to do this.

If you still have difficulties finding a query then it could be down to caching; we have a blog on

purging obiee server cache, which would help with this issue.
http://metadata/http://management/http://management/http://management/http://obiee/http://obiee/http://businessdecisionsystems.com/blog/?p=267#Developmenthttp://performance/http://pm/http://watson/http://businessdecisionsystems.com/blog/?p=122http://businessdecisionsystems.com/blog/?p=124http://metadata/http://metadata/http://management/http://management/http://obiee/http://businessdecisionsystems.com/blog/?p=267#Developmenthttp://businessdecisionsystems.com/blog/?p=267#Developmenthttp://performance/http://performance/http://performance/http://pm/http://pm/http://watson/http://watson/http://watson/http://businessdecisionsystems.com/blog/?p=122http://businessdecisionsystems.com/blog/?p=122http://businessdecisionsystems.com/blog/?p=122http://businessdecisionsystems.com/blog/?p=124http://businessdecisionsystems.com/blog/?p=124http://businessdecisionsystems.com/blog/?p=124http://businessdecisionsystems.com/blog/?p=124


22/26

2 Analyze the SQL to determine the cause of the problem

Once you actually locate and analyze the problem you will usually find that the problem itself isquite easy to fix; the difficult, or at least time consuming bit, is in the analysis.

To analyse the SQL we need to extract it from the query log and then use a tool such as Oracle

SQL Developer, or Toad, to submit it to the plan table and then read the explain plan from theplan table see my blog on theobiee explain plan.

3 Fix the Problem

As suggested earlier, it is very rare that there is not a solution to a performance problem,

although the fix may vary in its complexity.

Every problem is unique, but hopefully some of the problems that I mention may suggest somesolutions to help you.

Posted in Uncategorized| Leave a comment

OBIEE Explain Plan

Posted on January 14, 2011by John Lamont Watson

To analyse the SQL generated by the BI Server you will most likely use the Explain Plan; this

blog hopes to increase your understanding and ultimately help resolve performance issues.

What is an Explain Plan

An execution plan, sometimes called a row source tree, is logically a tree of row source

operators, where each operator is just a function written in C. The functions are mutually

exclusive; they have no knowledge of one another. Some operators are hidden, such as theSTATISTICS operator, and are not visible in the Explain Plan. Some operators also have

options, affecting their behaviour; such as the INDEX operation which has options such as

UNIQUE, RANGE SCAN, SKIP and SCAN, etc.

We can run and display an Explain Plan to help us understand which functions are being chosen

by the Oracle Optimizer. Through experience you will learn that some functions do certain jobs

better than others; we can manipulate the SQL or DB settings to ensure the Optimizer choosesthe better function.

Importantly, the Explain Plan contains the following information regarding your query.

Ordering of the tables referenced

Access method for each table

Join method for each join operation Data operations, such as filter, sort or aggregation

And in addition:

Optimization (Cost and Cardinality) Partitioning

Parallel Execution

It is worth bearing in mind when looking at obiee queries that the BI server harbours its own

Execution Plan, which may be the same or different to that of the database. We have a blog on

obiee cursor sharing; to help overcome this issue.
http://businessdecisionsystems.com/blog/?p=246http://businessdecisionsystems.com/blog/?p=246http://uncategorized/http://uncategorized/http://businessdecisionsystems.com/blog/?p=239#Performancehttp://plan/http://pm/http://watson/http://businessdecisionsystems.com/blog/?p=68http://businessdecisionsystems.com/blog/?p=246http://businessdecisionsystems.com/blog/?p=246http://businessdecisionsystems.com/blog/?p=246http://uncategorized/http://businessdecisionsystems.com/blog/?p=239#Performancehttp://businessdecisionsystems.com/blog/?p=239#Performancehttp://businessdecisionsystems.com/blog/?p=239#Performancehttp://plan/http://plan/http://plan/http://plan/http://pm/http://pm/http://watson/http://watson/http://watson/http://businessdecisionsystems.com/blog/?p=68http://businessdecisionsystems.com/blog/?p=68http://businessdecisionsystems.com/blog/?p=68


23/26

Running an Explain Plan

A table exists, the Plan Table; it is set up automatically, that stores the Explain Plans for allusers. To submit a query to the table we must precede the query with the commandEXPLAIN

PLAN FOR, as in the example below. More information is available in abundance online for

those interested.

Submitting a query to the Plan Table

Displaying the Explain Plan

Once we have asked for an Explain Plan to be made available through through the Plan Table.

We need to display to query to read it. The command below is one way to display the contents

of the Plan Table. The command below willget you by, but there are more options available;

again information available all over the Interent.

Displaying Plan Table

Understanding the Plan Table Output

More to follow

Posted in Uncategorized| Leave a comment

OBIEE Query LogPosted on December 22, 2010by John Lamont Watson

The obiee query log, NQQuery.log, exists in the directory /OracleBI/server/Log. As the namesuggests it records the queries requested from the BI Server. The initials NQ remind us of

obiees history, being originally created by a company named NQuire; these clues are littered

throughout the application.

The Logging Level

The contents of the log file are, or at least the level of detail is determined by a Repository

Variable, LOGLEVEL. The variable can accept values from 0 to 5, 5 being the most verbose.
http://uncategorized/http://uncategorized/http://businessdecisionsystems.com/blog/?p=246#Planhttp://log/http://pm/http://watson/http://uncategorized/http://businessdecisionsystems.com/blog/?p=246#Planhttp://businessdecisionsystems.com/blog/?p=246#Planhttp://businessdecisionsystems.com/blog/?p=246#Planhttp://log/http://log/http://log/http://log/http://pm/http://pm/http://watson/http://watson/http://watson/


24/26

As a general rule I set the variable to 0 in production, effectively disabling loggin and improving

performance; 2 in development, setting to 3 on occassion when 2 is not enough to resolve the

issue.

Setting as a System-Wide Session Variable:

We can set the logging level globally for all users. We can set this in the RPD usingtheAdministration Tool and this logging level will take precendence of other logging settings.

Select to manage Variables from the Manage Menu In Variable Manager Select New, Session, Variable from the Action menu Give the Variable the name of LOGLEVEL, a value of 2 and click OK

Close Variable Manager

Setting with the User Object for a particular user:

We can also set the LOGLEVEL by user, however, this value will be overridden by the Session

Variable if it has been created. To set the Logging Level for a specific user, follow these steps.

Select to manage Security from the Manage Menu

In Security Manager Select the Users Object Type from the left pane The right pane lists the user objects, open the properties for an a user object Give the Logging Level a vlue 0 to 5 and click OK

Close Security Manager

Setting for a specific Request:

You can set the LOGLEVEL variable for a specific request. In this example you will update the

session variable LOGLEVEL before the request is run and, as such, this will take precedence

over the Session Variable set in the RPD.

Select to Modify a request or create a new one

Navigate to the Advanced Tab

In the Prefix Text Box type SET VARIABLE LOGLEVEL=2; Now when you navigate to the results tab an entry will be made to the log file

Save the changed request if you would like always to be the case

In the above example there is no space either side of the equals sign; the statement must end in a

semi colon and, again, there is no space either side of it.

Viewing the Log File

There are a couple of ways to view the query log. All query logging is recorded in the Query

Log File, NQQuery.log; we can view this file using a text editor if we have access to the OS.

OBIEE uses a log viewer utility nQLogViewer to structure this log file into a more useful formatcalled the Session Monitor; we can use the Session Monitor online if we have administrative

access. And finally we can use the nQLogViewer utility ourselves to view specific information,but again we require OS access.

Using the Session Monitor:

Select Administration from the Settings Menu From the Administration Window select to Manage Sessions The Session Monitor will open


25/26

The Session Monitor is split into two tables, Sessions and Cursor Cache. Sessions lists the users

currently logged on, or with a thread still running; and the Cursor Cache table displays the

queries shown in the log file, NQQuery.log.

The session records show sessions by user ID and other details such as the client machine name,IP address, browser details, timestamp of login and timestamp of last request.

And the Query records show each request by ID; each record detailing the user ID, the status of

the query, how long it has taken to run, when it was run, the query itself, its location in thecatalog (if appropriate) and the number of records returned. In the Action column you can select

to view the log in more detail.

Session Monitor Query Record

Using the Viewer Utlity:

We can use the utility nQLogViewer to view log records; as stated above, each entry in thequery log is tagged with the user ID of the user who issued the query, the session ID of the

session in which the query was initiated, and the request ID of the query; and we can use thesedetails to restrict the utility to a spcific query.

To use the nQLogViewer utility we must open a command window in either Linux or

Windows. Navigate to /OracleBI/server/Bin. Use the command with the syntax below.

nqlogviewer [-u] [-f]

[-o]

[-s] [-r]

I would like to note that the request ID is generated in a circular manner; when IDs run out then

new requests will re-use existing IDs. This may explain why different queries can sometimesdisplay in a single log record.

Interpreting Log Records

Whether looking at the Query log directly, or using the Viewer Utility or via the Session Monitorthe Log Record is the same; they all come from same log file. A log record can be broken down

into sections; these sections are described brielfy below.

The log will start with the user ID for the requesting user (followed by the user Account code in

hex) and the timestamp for running the request.

SQL Request:

This section provides the Application SQL produced in the Presentation Layer; it does not define

relationships, just the columns used. It can be used to rerun the exact query in the Answer part

of the application; although it is less reliable than using the request xml (not available in thelog). It will also show additional attributes such as Pre and Post SQL and the path or location of

a saved request.

General Query Information:


26/26

This section describes the repository, business model and catalog from which the report has been

run; usually useful in putting together query statistics. I will providing a later log that goes into

more detail on this.

Logical Request:

Displays the columns used in the report from the Logical Layer; this section will be displayedwhen the Log Level is set to 2 or above.

Execution Plan:

When we set the Log Level to 2 or above then we also get to see the Execution Plan.

Database Query:

Identify this section from the initial text Sending query to the database named; the data_source_name is the name of the data source to which the Oracle

BI Server is connecting. If the server is connecting to Multiple database each query will have an

entry in the log.

This is the section of the log that you are most likely to be interested in and is the most useful. It

provides the actual SQL generated and executed against the database. It can be used to verifythat the application is behaving as required; especially useful when troubleshooting; and also tosupport performance tuning.

I would like to point out that the SQL that you read at times may not refelct the SQL that isactually executed on the database. You may notice sometimes that the SQL in the log executes

very well, but the OBIEE query seems to perform poorly. This is due to this unexpected

difference. I have blogged about this particular risk to OBIEE Performance.

Query Status:

Essentially the status section will tell you whether the query has succeeded or failed. You will

usually know this before looking at the log, but I guess its worth having it in there.

Log Retention

In terms of configuring the query log we can use the parameter USER_LOG_FILE_SIZE to setthe limit of the Query Log. When the size of the log file grows to half of that value it will be

renamed to NQQuery.log.old and fresh queries will be logged to the recreated file NQQuery.log.

Other than the size of the file system there are no further limitations to the size of the log file.

An example of the NQSConfig.INI file is given in the screenshot below.

Query Log Sizing in the NQSConfig.INI

Happy Logging and Happy Christmas!
http://businessdecisionsystems.com/blog/?p=68http://businessdecisionsystems.com/blog/?p=68http://businessdecisionsystems.com/blog/?p=68

Documents

Obiee Mate