This topic explains how to configure LabKey server to retrieve and display data from an Oracle database as an external data source
Oracle JDBC Driver
LabKey Server requires the Oracle JDBC driver to connect to Oracle databases. The driver can be downloaded from the Oracle JDBC/UCP Download page
. It is not redistributed with LabKey Server due to licensing restrictions, but it can be downloaded and used for free.
Download the file: ojdbc#.jar and place it in in the CATALINA_HOME/lib
Configure the Oracle Data Source
Add a <Resource> element to your installation's labkey.xml configuration file. Use the template below as a general starting point, replacing the words in capitals with their appropriate values.
: The username and password have been included in the connection URL for debugging purposes. You can remove the USERNAME/PASSWORD portion from the URL and include them in their own fields, but if you do, any debug information will only have the SID name and not the actual schema name.
Refer to Oracle FAQs: JDBC
for other Oracle JDBC URL syntax.
Define a New Schema
Now define a new schema from the Oracle data source. For details see Set Up an External Schema
Recovery File Size
Below are steps to take if you see an error on the Oracle console (or see an error in Event Viewer -> Windows Logs -> Application) that says one of the following:
- "ORA-19809: limit exceeded for recovery files"
- "ORA-03113: end-of-file on communication channel"
- "ORA-27101: shared memory realm does not exist"
- Update the RMAN value for "db_recovery_file_dest_size" to be a bit higher (i.e. from 16G to 20G).
- Restart your VM/machine.
- Restart start Oracle again.
Number (Decimal/Double) Data Truncates to Integer
If you have a column of type NUMBER and its value is being shown as an integer instead of a decimal, the source of the problem may be a bug in the Oracle JDBC driver. More information can be found here:
- Set the following Java system property in the arguments used to launch the JVM:
Open Cursor Limits
Oracle's thin JDBC driver has a long-standing bug that causes it to leak cursors
. This presents a problem because LabKey uses a connection pooling approach.
LabKey has worked around this problem by estimating the number of cursors that are still available for the connection and discarding it when it approaches the limit. To accomplish this, the server issues the following query to Oracle:
SELECT VALUE FROM V$PARAMETER WHERE Name = 'open_cursors'
If the query cannot be executed, typically because the account doesn't have permission, LabKey will log a warning indicating it was unable to determine the max open cursors, and assume that Oracle is configured to use its default limit, 50. If Oracle's limit is set to 50 or higher, the warning can be safely ignored.
To avoid the warning message, grant the account permission to run the query against V$PARAMETER.