Documents

Www Rittmanmead Com 2012 05 Obiee Performance Tuning Myth Bi

Description
Www Rittmanmead Com 2012 05 Obiee Performance Tuning Myth Bi
Categories
Published
of 4
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
  pdfcrowd.comopen in browserPRO version Are you a developer? Try out the HTML to PDF API HomeAboutCareersClientsConsultingTrainingSupportArticlesBlog 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 theBI Server log. It is a line that is repeated by Oracle support, propogated in “Best Practice” guides, and repeated throughoutblog posts on the subject. Antony Heljula did a talk on the subject at the recent RittmanMead BI Forum in Brighton, and Iwould 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. Instinct would tell us that writing a log is going to take longer than not writing to a log2. On a system with high user concurrency, we would expect to see contention for writing to the log file3. Usage Tracking records report response times, so why do we also need the server logging4. 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. TheBI Server log gives us vital information such as what physical SQL results from a logical query from the front end. If youturn off logging, you lose all visibility of quer y 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 r un, 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. It’s still slow, it’s still a performance problem – and now you don’thave the data available with which to diagnose the problem!4. Usage Tracking doesn’t record the same level of detail around a query’s 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 Search the blogRecent Posts  Analytics with Kibana andElasticsearch through Hadoop –part 3 – Visualising the data inKibana Analytics with Kibana andElasticsearch through Hadoop –part 2 – Getting data intoElasticsearch Analytics with Kibana andElasticsearch through Hadoop –part 1 – IntroductionUKOUG Partner of the Year  AwardsOracle BI Cloud Service for SaaS Application Reporting Part 1:Integrating BICS toSalesforce.com using REST APIs Top Posts OBIEE 11g Security Week :Managing Application Roles andPolicies, and Managing SecurityMigrations and DeploymentsUpgrading OBIEE to 11.1.1.7OBIEE 11gR1 : Architecture andUse of WebLogic Server OBIEE 11g Security Week :Connecting to Active Directory,and Obtainin Grou Membershi  pdfcrowd.comopen in browserPRO version Are you a developer? Try out the HTML to PDF API where report run times seem unusually high)7. Error messages returned from the database are not captured in Usage Tracking It Depends To a point, I am being contrary in arguing this specific issue, but it is important with this and other broad-strokepronouncements around performance that get regurgitating without context and caveats that they are understood. Inparticular, labelling it a “Best Practice” is a dangerous fallacy as it implies that it should be done without much further thoughtor consideration of its consequences.If the NFR for a report’s performance is [sub]-second and it is not being met, then profiling of the end-to-end response timebreakdown should be done, and it might be that it demonstrates that the logging is impeding performance. But the point isthat it is proven  rather than done blindly. Further reading Cary Millsap’s 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 “RightPractice”  Thanks to Tony for reviewing & making further suggestions for this article.  Related Posts: BI Forum 2014 preview – No Silver Bullets : OBIEE Performance in the Real WorldAdvanced Presentation Services settings for OBIEE testing & developmentMonitoring OBIEE Performance for the End User with JMeter from EM12c Tags: logging , nqserver.log , obiee , performance , usage tracking  from Database Tables Analytics with Kibana andElasticsearch through Hadoop -part 1 - Introduction Random Posts Thoughts on Running OBIEE in theCloud : Part 1 - The BI PlatformIntroduction to Oracle BI CloudService : Provisioning DataNew Feature in OEM CloudControl 12cR3 - Exalytics Server ManagementNew OTN Article: Making theMove from Oracle WarehouseBuilder to Oracle Data Integrator 12cIntroduction to the BI Apps11.1.1.7.1 - Release Overview Tags 11g   Big Data Appliance BIP   BI Publisher    dw  em12c Endeca   exalytics extremebi   git goldengate hadoop   Hive   init.d  install linux   MDS XML   monitoringnew features   nqcmd   OBIA obiee   odi   odi12c opatch   Oracle   Oracle BI Applications   oracle dataintegrator    OracleEndeca   Oracle EndecaInformation Discovery  owb performance   Real Time Share11  pdfcrowd.comopen in browserPRO version Are you a developer? Try out the HTML to PDF API Tags: logging , nqserver.log , obiee , performance , usage tracking Posted in Oracle BI Suite EE , Performance  | 2 Comments » 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 Venkat’s load testingtool 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 thatno logging whas the “standard” in Production environments and everyone took it as the “way”. Thanks for the post and theeffort to test this instead of going “with the flow”. Decisions   replication ReportService RTD  runReport sampleapp   screen   scripting security  startup testing training   XML 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) Home Services > Consultin ConsultingServicesTraining > OBIEE Resources > Articles Blog Authors > Mark Rittman Rittman Mead Consulting ltd. Registered Office : Suite B,  pdfcrowd.comopen in browserPRO version Are you a developer? Try out the HTML to PDF API Website Design & Build: tymedia.co.uk   > About us> About our team> Contact us> Our clients > Training> Support> Projects> Expert Services> OBIEE 11g> Sustainability> On Discoverer?> Oracle DW Bootcamp> OBIEE End-User > Exalytics> ODI 11gBootcamp> Oracle BI Apps > Blog> OBIEE 11g > 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 KingdomCompany No. : 6032852 VAT No. : 900 3839 48  Rittman Mead America, Inc. Registered Office : 4550 North Point Parkway 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 Pvt Ltd. Registered Office : Unit 105-106 Regent PrimeWhitefield Main Road Whitefield Bangalore 560066  Rittman Mead Belgium Registered Office : Chaussée de Louvain 426 1380 LasneBelgium  © 2010-2011 Rittman Mead Consulting. | Privacy Policy | E: info@rittmanmead.com  
Search
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks