OBIEE performance tuning guides are abundant these days. It seems any developer with a passing knowledge of OBIEE can make suggestions on how to make your reports run faster... "change this variable, disable logging, check this box." But what do the experts say?
Hogwash. "OBIEE performance tuning" implies performance issues can be solved with specific suggestions and solutions. But all customers are different, and thus the solutions are unique.
So instead of tuning, we optimize. Instead of dictating what must be changed, we work with the business to investigate solutions.
The simplest way to distinguish between tuning and optimizing is to look at the tasks. If the tasks are generalized and boilerplate, we're tuning. If the tasks include environment analysis and comparison of approaches, we're optimizing. Optimization provides true business value, where tuning only provides a facade of improvement.
How do we start optimizing? The best starting place is to have an understanding of where to start looking. Let's begin with best practices.
These are by no means practices you have to observe, but they’re good practices that keep OBIEE 12c and 11g running smoothly.
Tip: Copy and paste this list into a Word Document to create a checklist while you work on reconfiguring your OBIEE design.
The above steps are more like guidelines you should follow to always keep your system running smoothly. To further optimize OBIEE performance, you can take the more in-depth steps that we’ll cover in this section.
Caching can help improve your performance, but you need to make sure you’re managing it properly. Caching can improve performance in the following ways:
The BI Server cache is smart — it doesn’t only recognize a direct match on a previous query. It can also recognize a subset or an aggregate of an existing cache entry.
To benefit your users, rather than them having to wait for someone to run a query, you can pre-seed the cache. There are two ways to do this:
You can also purge the cache by:
You also need to think about cache persistence time, which tells you how long an entry stays in the cache, rather than how often you’re purging it. Cache persistence time is useful if you’re making frequent changes to your source data and you want a lag in the data your user sees to get a better response time for end users.
You probably already know that OBIEE writes and stores temporary files, like your cache data, to your disk. You may be able to improve performance by moving some of your temporary files to your RAM disk or fast disk. Keep in mind that some of these temporary files can be very large.
A typical OBIEE system will have WebLogic acting as the application server and the HTTP server. You might be able to improve response time by using an addition HTTP server, like Oracle HTTP Server (OHS). That way WebLogic is simply the application server, and OHS can handle things like compressing static files, enabling things to run faster.
Scaling out refers to adding more physical servers that you can extend your BI domain on to. Scaling up refers to increasing the components that run on an existing server.
If you have a component that is close to reaching capacity, you should consider scaling. This is not something you should try otherwise — it will only increase the complexity of your system configuration and ultimately give you more work to do.
In this section, we’ll cover a few tips for database administrators looking to optimize OBIEE.
Here we’ll go over various technique so you can evaluate the physical implementation of your data model. These techniques include:
You’re probably already aware of Oracle’s OBIEE tuning document. It’s a list of settings you can evaluate. However…
Optimizing OBIEE performance is something that should always be on your mind, but can often fall by the wayside. By taking the steps above, you can help alleviate some pain points and slowdowns you might be experiencing or prevent those problems in the future.
Feeling overwhelmed? Take a deep breath.
It’s easy for me to provide the suggestions above, but it’s another thing entirely to actually make these changes. Performance optimization is difficult. Not to mention, causes for poor performance can vary significantly. The suggestions above may not be exactly what your organization requires. Or worse, your performance issues may be caused by something even more obscure, so your efforts may be all for naught.
Make it easier on yourself and your organization — outsource these optimization tasks. Your BI developers are better utilized by implementing business requirements, rather than parsing log files or analyzing SQL. Save your time, save your money, and leave performance issues to experts who fix them daily. It’s what we’re here for. Even better, our knowledge and experience are now available to you and your team through OptimizeBI.
OptimizeBI is the performance optimization tool tailormade for OBIEE, OAC, and ODI. By providing a full-stack overview of the environment, performance issues can be identified and resolved quickly. Coupled with experienced US-Analytics experts, your performance issues will be a thing of the past.
You'll be in touch with an optimization expert within 1 business day!