Best practices guide for tuning oracle business intelligence enterprise edition

In Unix or Linux, get the data-model-cmd. Use the following commands to upload the. You can copy this. If you do not supply the password, you will be prompted for the password when the command is run.

For security purposes, Oracle recommends that you include a password in the command only if you are using automated scripting to run the command. Include this option only when you are running the command from a client installation.

New and Deprecated. Terminology for 12c This section discusses several common issues that you might encounter as you apply patches in OBIEE and provides solutions for you to try. To resolve this issue, remove the Java path from the bsu.

To change the WebLogic password, first log in and provide a new password by using the following steps:. Enter the password into the New Password and Confirm Password boxes. When prompted for the WebLogic username and password, provide the username and modified password.

This section discusses several common OBIEE report errors that you might encounter and provides solutions for you to try. When you download reports in CSV file format, you cannot exceed more than 65, rows by default.

The instanceconfig. Use the following paths to the instanceconfig. After you have completed all of the preceding steps, you should be able to export the reports in CSV format without any issues. The flip-side of pre-seeding the cache is purging it, and there are two sensible ways to do this :. Watch out for the Cache Persistence time in the Physical Table - this defines how long an entry remains in the cache , rather than how frequently to purge it.

If you have a daily data load, setting the cache persistence time to 24 hours will not do what you may think.

If your data is loaded at , the first user queries it and creates a cache entry at , that cache entry will remain until the following day , even though the cached data would have been stale for six hours since the subsequent data load at Where Cache persistence time can be useful is in systems with frequent changes in the source data and you want to deliberately introduce a lag in the data the user sees for the benefit of generally faster response times for end-users.

However, if the users would be happy with a lag in the data, for example ten minutes, then you could enable caching and set the cache persistence time for the relevant physical table to 10 minutes. For the ten minutes that the data is in the cache, the users get fast response times. This could be a pragmatic balance between freshness of data and response times to get the data. Bear in mind that a query taking 2 minutes to run is going to be reporting on data that is 2 minutes out of date already.

OBIEE writes various temporary files, including cache data and work files, to disk. You may find that using fast disk e. A dedicated HTTP server such as OHS can be configured to cache and compress static files which can improve the response time for users especially if the network is not a fast one.

Increasing the number of instances of the system components can help maximise the capacity of the overall BI Domain and enable it to use the full resource of the hardware on which it is running.

Scaling out is to add additional physical servers and extend the BI Domain onto them. Scaling up is to just increase the number of one or more of the components that are running on an existing server. An example of where this can be useful is the Javahost component. It is configured with a default maximum number of jobs that it can handle.

Certain workload types and volumes can hit this maximum with relative ease, so increasing the number of Javahosts can improve the performance by reducing contention for the process. Mark Rittman wrote a post recently in which he discussed the idea of scaling the BI Server nqsserver component in order to take advantage of multiple CPU cores, and whether this was in fact necessary.

This section is most definitely not a comprehensive study; it is a set of a few pointers that I would be looking for before speaking to my honourable DBA colleagues who have longer beards than I and know this stuff inside out.

On the one hand, publishing a list of settings to evaluate is of great help. On the other, publishing a list of settings to evaluate with no context or method with which to validate them is no help whatsoever. In my [not very humble] opinion, a supplemental list of configuration parameters - especially from the software vendor themselves - should only go hand-in-hand with details of how to properly evaluate them.

Here is why I think that:. It is very useful. For an overview and conclusion of my method for improving performance in OBIEE, see the final post in this series, here. Do you agree with this method, or is it a waste of time?

What have I overlooked or overemphasised? We get questions like these a lot. This post shares some key information that I hope will make your choice easier. To keep this post to a manageable length, this post deals only with Oracle Version 12c and Version 19c, and excludes Oracle cloud offerings. A future post will cover those feature sets.

One of the more frequently used options in Enterprise Edition is Data Guard. A set of Data Guard features is listed in the first table for each edition below.

These are used to implement high availability; that is, having a standby database available that is kept up to date with your primary production database in case your primary database goes down.

You will still need to license the database software on both the primary and the standby server, but both can be much less expensive Standard Edition licenses.

The advanced security option is an extra cost option that is only available with Enterprise Edition. This includes transparent data encryption, data redaction, data masking and subsetting very helpful for development environments , and other security options.

To adequately secure sensitive data at the database level, we advise that you use advanced security, and thus Oracle Enterprise Edition. With that said, if you are not using advanced security, and the only Enterprise-only option you need is Data Guard, then we recommend taking a good look at Dbvisit. Below are the features that are only available in Enterprise Edition for Oracle 12c.