Connection Pools for
Initialization Blocks
It is
recommended that you create a dedicated connection pool for initialization
blocks. This connection pool should not be used for queries.
Additionally,
it is recommended that you isolate the connections pools for different types of
initialization blocks. This also makes sure that authentication and
login-specific initialization blocks do not slow down the login process. The
following types should have separate connection pools:
- All
authentication and login-specific initialization blocks such as language,
externalized strings, and group assignments.
- All
initialization blocks that set session variables.
- All
initialization blocks that set repository variables. These initialization
blocks should always be run using credentials with administrator
privileges.
Be aware of the number of these initialization blocks,
their scheduled refresh rate, and when they are scheduled to run. Typically, it
would take an extreme case for this scenario to affect resources. For example,
refresh rates set in minutes, greater than 15 initialization blocks that
refresh concurrently, and a situation in which either of these scenarios could
occur during prime user access time frames.
Initialization
blocks should be designed so that the maximum number of Oracle BI Server
variables may be assigned by each block. For example, if you have five
variables, it is more efficient and less resource intensive to construct a
single initialization block containing all five variables. When using one initialization
block, the values are resolved with one call to the back end tables using the
initialization string. Constructing five initialization blocks, one for each
variable, would result in five calls to the back end tables for assignment.
If an initialization
block fails for a particular connection pool during Oracle BI Server start-up,
no more initialization blocks using that connection pool are processed.
Instead, the connection pool is blacklisted and subsequent initialization
blocks for that connection pool are skipped. This behavior ensures that the
Oracle BI Server starts in a timely manner, even when a connection pool has a
large number of associated initialization blocks or variables.
If this occurs,
a message similar to the following appears in the server log:
[OracleBIServerComponent] [ERROR:1]
[43143] Blacklisted connection pool
name_of_connection_pool
If you see this
error, check the initialization blocks for the given connection pool to ensure
they are correct.
Connection Pool
settings for Performance Enhancement - General Tab
Property
|
Description
|
Maximum connections
|
The maximum number of connections
allowed for this connection pool. The default is 10. This value should be
determined by the database make and model and the configuration of the
hardware for the computer on which the database runs, as well as the number
of concurrent users who require access.
Note: For deployments with Oracle
BI Interactive Dashboards pages, consider estimating this value at 10% to 20%
of the number of simultaneous users multiplied by the number of requests on a
dashboard. This number can be adjusted based on usage. The total number of
all connections in the repository should be less than 800. To estimate the
maximum connections needed for a connection pool dedicated to an
initialization block, you might use the number of users concurrently logged
on during initialization block execution.
|
Enable connection pooling
|
When selected, allows a single
database connection to remain open for the specified time for use by future
query requests. Connection pooling saves the overhead of opening and closing
a new connection for every query. If you do not select this option, each
query sent to the database opens a new connection.
|
Timeout
|
Specify the amount of time and in
what increment (such as minutes) that a connection to the data source remains
open after a request completes. During this time, new requests use this
connection rather than open a new one (up to the number specified for the
maximum connections). The time is reset after each completed connection
request.
|
Use multithreaded connections
|
When this option is selected, the
Oracle BI Server terminates idle physical queries (threads). When not
selected, one thread is tied to one database connection (number of threads =
maximum connections). Even if threads are idle, they consume memory.
The parameter DB_GATEWAY_THREAD_RANGE in the Server section of NQSConfig.ini establishes when
the Oracle BI Server terminates idle threads. The lower number in the range
is the number of threads that are kept open before the Oracle BI Server takes
action. If the number of open threads exceeds the low point in the range, the
Oracle BI Server terminates idle threads. For example, if DB_GATEWAY_THREAD_RANGE is set to 40-200 and 75 threads are open, the Oracle BI
Server terminates any idle threads.
|

Hi Mirsa
ReplyDeleteI am working with Siebel Anaytics - the performance of the segmentation process is not good.
During segementación OBI builds queries using the IN sentences - in SQL, this makes it not performant.
Is there another way that builds the OBI a different SQL statement?
Thanks in advance.
Ignacio
Thanks Mirsa,
ReplyDeleteOBI Version:
Build: 10.1.3.4.1.090414.1900
Release Version: Oracle Business Intelligence 10.1.3.4.1
Package: 090414.1900
Siebel Version:
INSTALLED : 8.1.1.2
In these versions is it necessary to install the patch?
Regards