Sie sind auf Seite 1von 4

Home

About

Careers

Clients

Consulting

Training

Support

Articles

Blog

OBIEE performance tuning myth : BI Server logging


May 22nd, 2012 by Robin Moffatt

One of the frequent recommendations around performance in OBIEE that one hears is a blanket insistence on disabling the
BI Server log. It is a line that is repeated by Oracle support, propogated in Best Practice guides, and repeated throughout
blog posts on the subject. Antony Heljula did a talk on the subject at the recent RittmanMead BI Forum in Brighton, and I
would like to echo and expand on it here.

The Myth:
If you are having performance problems in OBIEE, you should switch off BI Server logging

The arguments for:


1.
2.
3.
4.

Instinct would tell us that writing a log is going to take longer than not writing to a log
On a system with high user concurrency, we would expect to see contention for writing to the log file
Usage Tracking records report response times, so why do we also need the server logging
Log files will cause the disk to fill up, which left uncontrolled could cause system instability

The arguments against:


1. If you have performance problems in OBIEE, then you need logging in place to be able to trace and diagnose them. The
BI Server log gives us vital information such as what physical SQL results from a logical query from the front end. If you
turn off logging, you lose all visibility of query behaviour, timings, and row counts.
2. OBIEE writes lots of logs, more so now in 11g. Why only disable one of them? Why not all logs?
3. If a query takes 30 seconds to run, how much of that 30 seconds is actually going to be in log overhead? You disable
logging and now your query runs in 29.999 seconds. Its still slow, its still a performance problem and now you dont
have the data available with which to diagnose the problem!
4. Usage Tracking doesnt record the same level of detail around a querys behaviour (response time profile, row counts)
that the server log does.
5. By default, Usage Tracking chops off Logical SQL above 1024 characters in length.
6. Sometimes you need the log file to confirm that Usage Tracking is reporting correctly (especially in circumstances

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

Search the blog

Recent Posts
Analytics w ith Kibana and
Elasticsearch through Hadoop
part 3 Visualising the data in
Kibana
Analytics w ith Kibana and
Elasticsearch through Hadoop
part 2 Getting data into
Elasticsearch
Analytics w ith Kibana and
Elasticsearch through Hadoop
part 1 Introduction
UKOUG Partner of the Year
Aw ards
Oracle BI Cloud Service for SaaS
Application Reporting Part 1:
Integrating BICS to
Salesforce.com using REST APIs

Top Posts
OBIEE 11g Security Week :
Managing Application Roles and
Policies, and Managing Security
Migrations and Deployments
Upgrading OBIEE to 11.1.1.7
OBIEE 11gR1 : Architecture and
Use of WebLogic Server
OBIEE 11g Security Week :
Connecting to Active Directory,
and Obtaining Group Membership

pdfcrowd.com

where report run times seem unusually high)


7. Error messages returned from the database are not captured in Usage Tracking

It Depends

and Obtaining Group Membership


from Database Tables
Analytics w ith Kibana and
Elasticsearch through Hadoop part 1 - Introduction

To a point, I am being contrary in arguing this specific issue, but it is important with this and other broad-stroke
pronouncements around performance that get regurgitating without context and caveats that they are understood. In
particular, labelling it a Best Practice is a dangerous fallacy as it implies that it should be done without much further thought
or consideration of its consequences.

Random Posts

If the NFR for a reports performance is [sub]-second and it is not being met, then profiling of the end-to-end response time
breakdown should be done, and it might be that it demonstrates that the logging is impeding performance. But the point is
that it is proven rather than done blindly.

New Feature in OEM Cloud


Control 12cR3 - Exalytics Server
Management

Further reading
Cary Millsaps paper, Thinking Clearly About Performance, is an excellent starting point for developing an understanding of
a logical and methodical approach to performance problem solving.
James Morle wrote an great blog post on the subject of Best Practice and why it is dangerous terminology, entitled Right
Practice

Thoughts on Running OBIEE in the


Cloud : Part 1 - The BI Platform
Introduction to Oracle BI Cloud
Service : Provisioning Data

New OTN Article: Making the


Move from Oracle Warehouse
Builder to Oracle Data Integrator
12c
Introduction to the BI Apps
11.1.1.7.1 - Release Overview

Tags

11g Big Data Appliance


BIP BI Publisher dw em12c

Endeca exalytics
extremebi git
Thanks to Tony for reviewing & making further suggestions for this article.

linux MDS XML monitoring


new features nqcmd OBIA

Related Posts:
BI Forum 2014 preview No Silver Bullets : OBIEE Performance in the Real World
Advanced Presentation Services settings for OBIEE testing & development
Monitoring OBIEE Performance for the End User with JMeter from EM12c
Tags: logging, nqserver.log, obiee, performance, usage tracking
Share

obiee odi odi12c


opatch Oracle Oracle BI
Applications

oracle data

integrator Oracle
Endeca Oracle Endeca
Information Discovery ow b

performance Real Time

11

open in browser PRO version

goldengate
hadoop Hive init.d install

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

Share

Tw eet

11

10

Like

Decisions replication

Tags: logging, nqserver.log, obiee, performance, usage tracking

ReportService RTD runReport

Posted in Oracle BI Suite EE, Performance | 2 Comments

security startup testing

sampleapp screen scripting

training XML

Comments
Mark Rittman Says:
May 22nd, 2012 at 9:52 am

Strikes me that this could do with some actual evidence/numbers to back it up. How about using Venkats load testing
tool to test the impact of logging with 10, 100 etc concurrent users against SampleApp?

Mike Neal Says:


May 24th, 2012 at 10:58 pm

Thanks Robin, I had always thought the pros(log) more than out-weigh the cons (no log). But it went for several years that
no logging whas the standard in Production environments and everyone took it as the way. Thanks for the post and the
effort to test this instead of going with the flow.

Call us now to talk about your BI project:


+44 (0) 1273 911 268 (UK) or (888) 631-1410 (USA)
or +61 3 9596 7186 (Australia & New Zealand) or
+91 997 256 7970 (India) or +32 280 882 11 (Belgium)
Hom e

Services

About Us

> Consulting
> OBIEE
Are you a developer? Try out the HTML to PDF API

open in browser PRO version

Consulting
Services

Training

Resources

Blog Authors

> Articles

> Mark Rittman

Rittman Mead Consulting ltd.


Registered Office : Suite B,

pdfcrowd.com

About Us
>
>
>
>

About us
About our team
Contac t us
Our clients

> Consulting
> Training
> Support

Services
>
>
>
>
>
>

Projects
Expert Services
OBIEE 11g
Sustainability
On Discoverer?
Orac le DW

> OBIEE
Bootcamp
> OBIEE End-User
> Exalytics
> ODI 11g
Bootcamp
> Oracle BI Apps

> Articles
> Blog
> OBIEE 11g

>
>
>
>
>
>
>

Mark Rittman
Venkat J
Peter Scott
Borkur S
Mike Vickers
Robin Moffatt
Jon Mead

First Floor Moore House,


13 Black Lion Street,
Brighton, East Sussex,
BN1 1ND, United Kingdom
Company No. : 6032852
VAT No. : 900 3839 48
Rittman Mead America, Inc.
Registered Office : 4550 North Point Parkway Suite
390 Alpharetta, Georgia 30022, USA
Rittman Mead Oceania Pty Ltd.
Registered Office : 12 Moore Street,
Brighton East,
Victoria, 3187, Australia
Australian Company No. : 149 458 935
Rittman Mead Consulting Pv t Ltd.
Registered Office : Unit 105-106
Regent Prime
Whitefield Main Road
Whitefield
Bangalore
560066
Rittman Mead Belgium
Registered Office : Chausse de Louvain 426
1380 Lasne
Belgium

2010-2011 Rittm an Mead Consulting.

Privacy Policy

E: info@rittm anm ead.com

Website Design & Build: tymedia.co.uk

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

Das könnte Ihnen auch gefallen