Connection Pool General Properties

The topic describes the connection pool properties in the Connection Pool's tab General pane. These properties are common among most connection types.

Use the information in this topic to help you create or modify a connection pool. See Set a Connection Pool's General Properties.

Property	Description
Persist connection pool	Displays for all data sources. Specifies the connection pool you want to use to populate stored procedures or to perform a generalized subquery. See Set Up Persist Connection Pools.
Connection	Displays for all data sources. Displays the connections available to semantic models. A connection's System Connection property must be selected for the connection to display in this list. See Manage Connections to Data Sources. Oracle Analytics doesn't always automatically assign the connection pool's connection, so sometimes you must manually assign one. You're not able to preview a physical table's data until it's database's connection pool connection is assigned.
Remote Connection	Displays for relational and Essbase data sources. Identifies if the database connection uses remote data connectivity. This field isn't automatically selected if the database uses remote data connectivity. You must set this field manually. If the database uses remote data connectivity and this field isn't selected then you'll receive an error when you run consistency check.
Max Connections	Displays for all data sources. Specifies the maximum number of connections allowed for this connection pool. The default is 10. You can determined the value by the database make and model and the configuration of the hardware for the computer where the database runs, and the number of concurrent users who require access. 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. You can adjust the number based on usage. Define the total number of all connections in the semantic model to 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 processing.
Timeout	Displays for all data sources. Specifies the amount and increment of time that a connection 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.
Isolation Level	Displays for relational data sources. Specifies the value sets the transaction isolation level on each connection to the back-end database. For ODBC gateways only. Controls the default transaction locking behavior for all statements issued by a connection. You can only set one at a time. It remains set for that connection until it's explicitly changed. The options are: Dirty read - Implements dirty read, isolation level 0 locking. This is the least restrictive isolation level. When this option is set, it's possible to read uncommitted or dirty data, change values in the data, and have rows appear or disappear in the data set before the end of the transaction. Dirty data is data to clean before running a query to obtain correct results. For example, duplicate records, records with inconsistent naming conventions, or records with incompatible data types. Committed read - Specifies that shared locks are held while the data is read to avoid dirty reads. You can change the data before the end of the transaction, resulting in non-repeatable reads or phantom data. Repeatable read - Places locks on all data that's used in a query, preventing other users from updating the data. You can insert new phantom rows into the data set by another user and are included in later reads in the current transaction. Serializable - Places a range lock on the data set, preventing other users from updating or inserting rows into the data set until the transaction is complete. This is the most restrictive of the four isolation levels. Because concurrency is lower, use this option only if necessary.
Require fully qualified table names	Displays for relational data sources. When selected, specifies that all requests sent from the connection pool use fully qualified names to query the underlying database. Select this option if the database or database configuration requires fully qualified table names. This option isn't available for some connection types. The fully qualified names are based on the physical object names in the semantic model. If you're querying the same tables that the physical layer metadata was imported from, then you can safely select this option. If you've migrated your semantic model from one physical database to another physical database that has different database and schema names, the fully qualified names are invalid in the newly migrated database. In this case, if you don't select this option, the queries succeed against the new database objects. For some connections, fully qualified names are a safer because they guarantee that the queries are directed to the desired tables in the desired database. For example, if the RDBMS supports an original database concept, a query against a table named Customer first looks for that table in the original database, and then looks for it in the specified database. If the table named Customer exists in the original database, that table is queried, not the table named Customer in the specified database. You might need to select this option when you're using an Oracle Database and you're accessing the database with a user that isn't the owner of the schema containing the tables. When the Oracle Database interprets table names in SQL, it assumes that the user that made the query is the owner if the table name isn't fully qualified in the query. This can result in an incorrect qualified name. For example, if the user SAMPLE creates a table called CUSTOMER, the fully qualified table name is SAMPLE.CUSTOMER. When the SAMPLE user references the CUSTOMER table in a query, the Oracle Database assumes the fully qualified table name is SAMPLE.CUSTOMER, and the access is successful. However, if the JANEDOE user references the CUSTOMER table in a query, the Oracle Database assumes the fully qualified table name is JANEDOE.CUSTOMER, and a Table or view not found error can result. To enable access for JANEDOE, you must select Require fully qualified table names in the connection pool so that the Oracle Analytics query engine specifies SAMPLE.CUSTOMER in all queries.
Use multithreaded connections	Displays for all data sources. When selected, specifies that the Oracle Analytics query engine 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.
Parameters supported	Displays for all data sources. When selected, indicates that the database features table supports parameters and special code runs that allows the Oracle Analytics query engine to push filters (or calculations) with parameters to the database. The Oracle Analytics query engine does this by simulating parameter support within the gateway/adapter layer by sending extra SQLPrepare calls to the database.
Enable connection pooling	Displays for relational data sources. 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 don't select this option, each query sent to the database opens a new connection.