Beruflich Dokumente
Kultur Dokumente
hello world, connection pooling, the term in its simplest sense for any novice developer suggests "pool of connections", which is true. The "pool of connections" doesn't mean there exists multiple connections to the database. It should be comprehended as concurrent connections within A single database connection. This connection pool object is governed by a set of options which controls its 'demeanor'. Following are the options on general tab: 1. Connection Name and Permissions... 2. Call Interface 3. Maximum Connections. 4. Required fully qualified table names 5. Shared Logon 6. Enable Connection pooling. 7. Use multithreaded connections. 8. Execute queries asynchronously. 9. Parameters supported. 10. Isolation Level. 1. Connection Name: Identify every connection pool based on its usage. e.g. as recommended by oracle multiple connection pools exist for repository variable initialization blocks, session variable initialization blocks (mostly used to authenticate users..) etc. Delete unused connections, not deleting them increases server memory. Excerpt from OBIEE help: "In addition to the potential load and costs associated with the database resources, the Oracle BI
Server allocates shared memory for each connection upon server start up. This raises the number of connections and increases Oracle BI Server memory usage."
as a test, create some n (=50) connection pools, and check your task manager for nqsserver.exe on start up.
2. Call Interface: specify the interface through which you want the application to communicate with underlying database. To communicate with oracle databases select either odbc or native call interfaces (oci 8i/9i, oci 10g/11g). caveat 1, when a odbc is selected "Data source name:" is the name of the System DSN in odbc data source administrator. caveat 2, when a oci call interface is selected "Data source name:" is the TNS Name in the tnsnames.ora file. 3. Maximum Connections: this parameter specifies maximum concurrent connections - a database can handle. how many maximum concurrent connections are possible? this is an abstruse question. This is a multi-part question. As a developer one should analyze the average
number of users, reports fired from a dashboard page including any complex prompts, # dashboard pages... From the database perspective system dba determines how many concurrent connections can be possible. Again finding answer to this question depends upon what types (simple to complex) queries are being fired, what tables are accessed, indexes being accessed etc... overall, Maximum Connections parameter must be defined based on BI developer and system dba's input. No astronomical number must be used which might have adverse effects. 4. Required fully qualified table names: When checked the SQL issued to the back end data bases contains "shema.tablename" format. hence changing the schema, table, or column names in the physical layers is not advisable. If renamed, here is a sample error with sql server as back end data base:
5. shared logon: check shared logon to authenticate users based on the user name and password provided. If the shared logon is omitted application uses user name and password specified in the systems dsn. 6. Enable Connection Pooling: the parameter specifies the maximum wait time before a request reuses the database connection. If all the Maximum connections specified are being used, the new request either waits for a existing request to complete or looks for another connection pool (if specified). 7. Use multithreaded connections: a good excerpt from the help - "When the check box is select ed,
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 Oracle BI Server terminates idle threads. The lower number in the range is the number of threads that are kept open before Oracle BI Server takes action. If the number of open threads exceeds the low point in the range, Oracle BI Server terminates idle threads. For example, if DB_GATEWAY_THREAD_RANGE is set to 40-200 and 75 threads are open, Oracle BI Server terminates any idle threads."
8. Execute queries asynchronously: check if database supports asynchronous queries. Asynchronous queries helps boost the response time of an application. 9. Parameters Supported: check if the sql issued to the database employs any parameters. by default it's checked.
10. Isolation levels: In my perspective the Isolation levels are useful when there exists concurrent reads and writes - which implies a write back should exist.
To automate connection pool changes for use in a process such as production migration, consider using the Oracle BI Server XML API (11g).
Articles Related
OBIEE 10G/11G - Act as (Proxy user) Functionality OBIEE - BI Server (Overview / Architecture) OBIEE - Connection Script OBIEE 10G/11G - Oracle Call Interface (OCI) configuration OBIEE - Physical Layer OBIEE 10G/11G - Query Cache of BI Server OBIEE 11G - Installation Sample Application version 825 OBIEE - Security OBIEE - Which Usage Tracking time measure should be used to gauge the performance of SQL retrieval time ?
The Maximum Connections setting governs the number of active queries on the db. When the limit is reached, then the system waits for a connection to become available. As a single request can generate multiple db queries, it is possible for a maximum connections of 64 to be reached with less than 64 users. Also, a dashboard can have lots of requests so it is possible for a few users to occasionally hit the limit. The default value of 10 is usually too low (it will cause queuing) but setting it too high will eat up memory and the BI Server process may not even start. As a rule of thumb, calculate it using the following theory:
At any one time, 10-20% of your users will be logged in Of those users logged in, only 10-20% will actually be running queries There are a maximum of X reports on any one Dashboard Page
So if you have 1000 users in total and a maximum of 4 reports per dashboard page:
Or in other word:
Maximum number of connections = 20% of concurrent users * number of reports per dashboard.
Call interface
The call interface represents the driver that you use to connect to the data source. You have three methods:
ODBC OCI XML. Xml is a build-in drivers to be able to connect/read XML files in a specific format.
In place of the id and password, you can use the intern variable :USER and :PASSWORD for pass through.
Isolation Level
For ODBC and DB2 gateways only. Isolation Level :
Committed Read
Locks are held while the data is read to avoid dirty reads. Data can be changed before the transaction ends with that connection.
Dirty Read
0 Locking. Can read uncommitted or dirty data, change values in data during read process in a transaction. Least restrictive of all types.
Repeatable Read
Places locks on all data used in a query so that nobody can update the data. However new rows can be inserted by other users but will be available in later reads in the current transaction.
Serialization
Places a range lock on data set preventing other users to insert or update the rows in data set until the transaction is complete. Most restrictive of all.
Shared logon
OBIEE - How to define one different database credential for each user (the shared logon) ?
DSN
The data source name is
for ODBC, the data source name for OCI a connect identifier
Parameters Supported
If this option is not selected, and the database features table supports "parameters", special code executes that allows the Oracle BI Server to push filters (or calculations) with parameters to the database. The Oracle BI Server does this by simulating parameter support within the gateway/adapter layer by sending extra SQLPrepare calls to the database.
Support
Security
If you have this error :
Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 19007] The user does not have sufficient privilege to access the database ORCL. (HY000) SQL Issued: SELECT B.DATA saw_0 FROM SH ORDER BY saw_0
It comes from the OBIEE connection pools security parameters from the database. Suppose that we have only one connection pool for a database, the image below show that nobody have been granted to access the connection excepted the Administrator :
Write Back Implementation OBIEE Introduction Speaking about OBIEE, first thing which comes to our mind is, it is a reporting and analysis tool and mainly used for viewing data (Selection). But apart from this there is an advanced feature which allows us to enter or update the values directly into the database. The feature is called as Write Back. Users with appropriate permissions can use this feature. This article includes the general introduction and implementation steps of Write Back feature
What is Write Back option? Write Back is the ability to enter or update values directly into a report and have those values stored directly in to the database. In order to implement this feature in OBIEE we have to make some changes in the repository as well as in the presentation services layers. Lets see, the step wise implementation of this feature. Below mentioned are the general steps to be followed before using write back feature. 1. Making the table uncacheable from the physical layer of the repository. 2. Configuring the write back in the connection pool. 3. Granting the privileges of write back to the user from the Presentation Services. 4. Creating a XML Template and specifying the insert and update queries for write back. 5. Enabling write back from the column properties of the column in the request. 6. Specifying the template name in the table view write back properties of the request. Now to understand this feature, Let us assume a scenario where we have a customer table (containing fields like name, contact number and other details) and a user has to update the contact numbers of the customers very frequently. We will implement the write back feature for this scenario by using the following steps. (Note : In this article, We are using ORACLE DATABASE with supplier2 schema.)