Supported Databases
- Last updated
- Save as PDF
This page is not applicable to Planview Hub Cloud.
Supported Databases for storing Hub Operational Data
Planview automatically stores operational data to a pre-configured Derby database. This is suitable for evaluation purposes only, and is not supported for production environments. Configuring Hub to utilize an external database enables you to perform frequent back-ups without stopping Hub, and ensures that your Hub practices are consistent with your existing disaster and recovery process.
Note: The database used for Hub operational data must support TLS 1.2.
To reduce latency, the Hub operational database should have its own machine and should be co-located with the Hub server.
Minimal User Permissions
For all supported databases, the user must have sufficient permissions to connect, create, alter and drop tables and indexes and create temporary tables. Users must also have sufficient permissions to select, insert, update, delete, and truncate tables.
Hub supports this operational database policy for scenarios where your database is on any cloud infrastructure like AWS or Azure. You can refer to the resources below for more information on encrypting communication between Hub and Database:
- For AWS, we recommend implementing a VPC. Click here for more information.
- For Azure, we recommend a VPN gateway. Click here for more information.
Note: A separate database must be used for Hub Operational Data and Enterprise Data Stream integrations.
Operational Database Recommendations
The recommendations below offer a general guideline only. We recommend consulting with customer care to determine the exact needs for your integration scenario, and for guidance on how to efficiently configure Hub.
You can see guidelines regarding external database sizing here.
We strongly recommend using the latest supported version of PostgreSQL for storing Hub Operational Data. At scale, Hub performs better, more reliably, and requires fewer resources with PostgreSQL than with the other available database options.
Supported Versions and Configuration Details
In the sections below, you will find supported database versions for storing Hub Operational Data and configuration details for each database.
PostgreSQL
Supported Versions
- 11
- 12
- 13
- 14
- 15
Configuration Settings
- The database must be case-sensitive (this is the default configuration).
- The database must be configured with the UTF8 character set.
CREATE DATABASE tasktop_hub ENCODING 'UTF8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8' TEMPLATE template0
Necessary User Permissions
The following provides sufficient permissions for the tasktop_hub
user on the tasktop_hub
database, when using a public schema:
CREATE USER tasktop_hub; REVOKE ALL PRIVILEGES ON DATABASE tasktop_hub FROM tasktop_hub; GRANT CONNECT, TEMP ON DATABASE tasktop_hub TO tasktop_hub; GRANT CREATE ON SCHEMA public TO tasktop_hub; GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA public TO tasktop_hub;
The following provides sufficient permissions for the tasktop_hub
user on the tasktop_hub
database, when using a custom schema:
Note: If you use a custom schema, please note that when configuring the external database connection you will need to add "?currentSchema=tasktop
" to the database connection URL, e.g. jdbc:postgresql://example.com:5432/dbName?currentSchema=tasktop
CREATE USER tasktop_hub; \connect tasktop_hub; CREATE SCHEMA TASKTOP; REVOKE ALL PRIVILEGES ON DATABASE tasktop_hub FROM tasktop_hub; GRANT CONNECT, TEMP ON DATABASE tasktop_hub TO tasktop_hub; GRANT CREATE ON SCHEMA Tasktop TO tasktop_hub; GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA Tasktop TO tasktop_hub;
Microsoft SQL Server
Supported Versions
- 2019
- 2022
Configuration Settings
The database must be case sensitive. We recommend Latin1_General_100_CS_AS_KS_WS.
ALTER DATABASE dbName COLLATE Latin1_General_100_CS_AS_KS_WS;
We recommend monitoring the size of your transaction log, as very large transaction logs can cause database connection errors.
We recommend using version 9.4 of the JDBC driver when transferring from operational database to SQL Server.
Necessary User Permissions
The user must be a SQL authenticated user (not a Windows authenticated user) Additionally, the user must have the following roles granted:db_datareader
db_datawriter
db_ddladmin
Note: Instance and Database name options can be specified by attaching ";instanceName=;databaseName=
" to the end of the JDBC URL in Hub. If using JDBC driver mssql-jdbc-10.2.x
or later, the “;trustServerCertificate=
“ parameter and its corresponding value is required by the driver.
Oracle
Supported Versions
- 19c
- 21c
Configuration Settings
- The database must be case-sensitive (this is the default configuration).
- The database must be configured with the AL32UTF8 character set.
ALTER DATABASE dbName CHARACTER SET AL32UTF8;
Necessary User Permissions:
User must have CREATE SEQUENCE
, CREATE TABLE
, CREATE SESSION
permissions, as well as sufficient quota. Typical user creation might look as follows:
CREATE USER tasktop_hub IDENTIFIED BY a_password DEFAULT TABLESPACE tasktop_hub; GRANT CREATE SESSION TO tasktop_hub; GRANT CREATE SEQUENCE, CREATE TABLE TO tasktop_hub; ALTER USER tasktop_hub QUOTA UNLIMITED ON tasktop_hub;
Troubleshooting
To resolve error ORA-30036 (UNABLE TO EXTEND SEGMENT BY 8 IN UNDO TABLESPACE), please refer to the following documentation.MySQL
If your Planview Hub instance is currently using MySQL for its operational database, note that MySQL will no longer be supported as an operational database for Planview Hub as of May 31, 2024. Planview recommends you migrate from MySQL to a supported database.
Note: A self-guided migration procedure to go from MySQL to Postgres is available here.
Supported Databases for use in Enterprise Data Stream Integrations
The Planview Hub Database add-on allows you to create integrations that send artifact information to one central database.
Note: A separate database must be used for Hub Operational Data and Enterprise Data Stream integrations.
You can see guidelines regarding external database sizing here.
Supported Versions
If your license includes the Hub Database add-on and you would like to configure an Enterprise Data Stream Integration, the following databases and versions are supported:
PostgreSQL
General Support
11 12 13 14 15Microsoft SQL Server
General Support
2019 2022Oracle
General Support
19c 21cWe recommend using JDBC driver version 8.0 or later when creating a SQL connection for Enterprise Data Stream integrations.
MySQL
If your Planview Hub instance is currently using MySQL for an Enterprise Data Stream database, note that MySQL will no longer be supported as a database for Planview Hub as of May 31, 2024. Planview recommends you migrate from MySQL to a supported database.
Note: A self-guided migration recommendation procedure to go from MySQL to Postgres is available here.
Database Connections and Encryption
The following section describes different ways to configure your database connection. If you choose not to encrypt your connection, data will be transmitted over the network unprotected and will be at risk of being intercepted. Likewise use of self-signed certificates or other certificates not signed by a trusted Certificate Authority puts your data at risk as Hub cannot verify the identity of the server at the end of the connection.
Please ensure your connection is configured in a way that is aligned with your security policy and the associated risks are understood and accepted.
Configuration Details
PostgreSQL
For PostgreSQL, please refer to PostgreSQL documentation for more information.
Location
- Example Format: jdbc:postgresql://hostServerName:postgreSqlServerPort/MyDatabaseName
You can enable encrypted connections by setting ‘ssl=true' (e.g., jdbc:postgresql://<server-name>:<port>/?ssl=true).
If the certificate for the PostgreSQL server is self-signed you'll need to set ‘sslfactory=org.postgresql.ssl.NonValidatingFactory' and ‘sslmode=require’ (e.g., jdbc:postgresql://<server-name>:<port>/?ssl=true&sslmode=require&sslfactory=org.postgresql.ssl.NonValidatingFactory).
If the certificate for the PostgreSQL server is not self-signed you'll need to add the certificate to the JDBC’s truststore.
Microsoft SQL Server
For SQL Server, please refer to Microsoft documentation for more information.
Location
- Example Format: jdbc:sqlserver://hostServerName;instanceN...MyDatabaseName
You can enable encrypted connections by setting 'encrypt=true' (e.g., jdbc:sqlserver://<server-name>:1433;encrypt=true;trustServerCertificate=false). If the certificate for the MySQL server is self-signed you'll need to set 'trustServerCertificate=true' (e.g., jdbc:sqlserver://<server-name>:1433;encrypt=true;trustServerCertificate=true)
If using JDBC driver mssql-jdbc-10.2.x
or later, the “;trustServerCertificate=
“ parameter and its corresponding value is required by the driver.
Note: Some older editions may be missing security updates and will need to apply security service packs to use a self-signed certificate and encryption. You may experience certificate errors if the SQL Server is using a self-signed or corporate certificate. To work around this, you will need to disable certificate validation in the JDBC driver or add the certificate to the JDBC’s truststore.
Oracle
For Oracle, please refer to this whitepaper for an overview of how to set up connections to encrypted Oracle server. For a guide to configuring the Oracle server to support SSL, please refer to Oracle documentation.
Location
- Example Format: jdbc:oracle:thin:@hostServerName:oracleServerPort/SID
For the most part assuming that the server is set up properly, you can follow Case#2 in the white paper and simply use a URL with the following format: jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(PORT=2484)(HOST=<hostname>))(CONNECT_DATA=(SERVICE_NAME=<servicename>))). On the server, make sure to disable client authentication by setting 'SSL_CLIENT_AUTHENTICATION=FALSE ' in the listener.ora and sqlnet.ora files.
For unencrypted connections, the protocol should be TCP and the port would generally be 1521, but the URL would otherwise be the same. The above example connection string is formatted in the 'Oracle Net connection descriptor' format, but Hub also accepts 'Thin-style service name' connection strings such as jdbc:oracle:thin:@<hostname>:1521:<servicename>.
If the certificate for the Oracle server is self-signed, but you still want to use SSL, you will need to follow Case#1 in the white paper. As described in the paper, only anonymous cipher suites are permitted when trying to use SSL without server authentication. You can specify the cipher suites in the sqlnet.ora file on the Oracle server.
Note: Some versions of Oracle do not by default support anonymous cipher suites. Thus, they will need to be imported to the server before enabling them.
-
This can be configured using the following command (replace dbName with the name of your database):
Supported Databases for storing Hub Operational Data
Planview automatically stores operational data to a pre-configured Derby database. This is suitable for evaluation purposes only, and is not supported for production environments. Configuring Hub to utilize an external database enables you to perform frequent back-ups without stopping Hub, and ensures that your Hub practices are consistent with your existing disaster and recovery process.
Note: The database used for Hub operational data must support TLS 1.2.
To reduce latency, the Hub operational database should have its own machine and should be co-located with the Hub server.
Minimal User Permissions
For all supported databases, the user must have sufficient permissions to connect, create, alter and drop tables and indexes and create temporary tables. Users must also have sufficient permissions to select, insert, update, delete, and truncate tables.
Hub supports this operational database policy for scenarios where your database is on any cloud infrastructure like AWS or Azure. You can refer to the resources below for more information on encrypting communication between Hub and Database:
- For AWS, we recommend implementing a VPC. Click here for more information.
- For Azure, we recommend a VPN gateway. Click here for more information.
Note: A separate database must be used for Hub Operational Data and Enterprise Data Stream integrations.
Operational Database Recommendations
The recommendations below offer a general guideline only. We recommend consulting with customer care to determine the exact needs for your integration scenario, and for guidance on how to efficiently configure Hub.
You can see guidelines regarding external database sizing here.
We strongly recommend using the latest supported version of PostgreSQL for storing Hub Operational Data. At scale, Hub performs better, more reliably, and requires fewer resources with PostgreSQL than with the other available database options.
Supported Versions and Configuration Details
In the sections below, you will find supported database versions for storing Hub Operational Data and configuration details for each database.
PostgreSQL
Supported Versions
- 11
- 12
- 13
- 14
- 15
Configuration Settings
- The database must be case-sensitive (this is the default configuration).
- The database must be configured with the UTF8 character set.
CREATE DATABASE tasktop_hub ENCODING 'UTF8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8' TEMPLATE template0
Necessary User Permissions
The following provides sufficient permissions for the tasktop_hub
user on the tasktop_hub
database, when using a public schema:
CREATE USER tasktop_hub; REVOKE ALL PRIVILEGES ON DATABASE tasktop_hub FROM tasktop_hub; GRANT CONNECT, TEMP ON DATABASE tasktop_hub TO tasktop_hub; GRANT CREATE ON SCHEMA public TO tasktop_hub; GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA public TO tasktop_hub;
The following provides sufficient permissions for the tasktop_hub
user on the tasktop_hub
database, when using a custom schema:
Note: If you use a custom schema, please note that when configuring the external database connection you will need to add "?currentSchema=tasktop
" to the database connection URL, e.g. jdbc:postgresql://example.com:5432/dbName?currentSchema=tasktop
CREATE USER tasktop_hub; \connect tasktop_hub; CREATE SCHEMA TASKTOP; REVOKE ALL PRIVILEGES ON DATABASE tasktop_hub FROM tasktop_hub; GRANT CONNECT, TEMP ON DATABASE tasktop_hub TO tasktop_hub; GRANT CREATE ON SCHEMA Tasktop TO tasktop_hub; GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA Tasktop TO tasktop_hub;
Microsoft SQL Server
Supported Versions
- 2019
- 2022
Configuration Settings
- The database must be case sensitive. We recommend Latin1_General_100_CS_AS_KS_WS.
-
This can be configured using the following command (replace dbName with the name of your database):
ALTER DATABASE dbName COLLATE Latin1_General_100_CS_AS_KS_WS;
-
- We recommend monitoring the size of your transaction log, as very large transaction logs can cause database connection errors.
-
We recommend using version 9.4 of the JDBC driver when transferring from operational database to SQL Server.
Necessary User Permissions
- The user must be a SQL authenticated user (not a Windows authenticated user)
- Additionally, the user must have the following roles granted:
-
db_datareader
db_datawriter
db_ddladmin
Note: Instance and Database name options can be specified by attaching ";instanceName=;databaseName=
" to the end of the JDBC URL in Hub. If using JDBC driver mssql-jdbc-10.2.x
or later, the “;trustServerCertificate=
“ parameter and its corresponding value is required by the driver.
Oracle
Supported Versions
- 19c
- 21c
Configuration Settings
- The database must be case-sensitive (this is the default configuration).
- The database must be configured with the AL32UTF8 character set.
ALTER DATABASE dbName CHARACTER SET AL32UTF8;
Necessary User Permissions:
User must have CREATE SEQUENCE
, CREATE TABLE
, CREATE SESSION
permissions, as well as sufficient quota. Typical user creation might look as follows:
CREATE USER tasktop_hub IDENTIFIED BY a_password DEFAULT TABLESPACE tasktop_hub; GRANT CREATE SESSION TO tasktop_hub; GRANT CREATE SEQUENCE, CREATE TABLE TO tasktop_hub; ALTER USER tasktop_hub QUOTA UNLIMITED ON tasktop_hub;
Troubleshooting
- To resolve error ORA-30036 (UNABLE TO EXTEND SEGMENT BY 8 IN UNDO TABLESPACE), please refer to the following documentation.
MySQL
If your Planview Hub instance is currently using MySQL for its operational database, note that MySQL will no longer be supported as an operational database for Planview Hub as of May 31, 2024. Planview recommends you migrate from MySQL to a supported database.
Note: A self-guided migration procedure to go from MySQL to Postgres is available here.
Supported Databases for use in Enterprise Data Stream Integrations
The Planview Hub Database add-on allows you to create integrations that send artifact information to one central database.
Note: A separate database must be used for Hub Operational Data and Enterprise Data Stream integrations.
You can see guidelines regarding external database sizing here.
Supported Versions
If your license includes the Hub Database add-on and you would like to configure an Enterprise Data Stream Integration, the following databases and versions are supported:
PostgreSQL
General Support
- 11
- 12
- 13
- 14
- 15
Microsoft SQL Server
General Support
- 2019
- 2022
Oracle
General Support
- 19c
- 21c
We recommend using JDBC driver version 8.0 or later when creating a SQL connection for Enterprise Data Stream integrations.
MySQL
If your Planview Hub instance is currently using MySQL for an Enterprise Data Stream database, note that MySQL will no longer be supported as a database for Planview Hub as of May 31, 2024. Planview recommends you migrate from MySQL to a supported database.
Note: A self-guided migration recommendation procedure to go from MySQL to Postgres is available here.
Database Connections and Encryption
The following section describes different ways to configure your database connection. If you choose not to encrypt your connection, data will be transmitted over the network unprotected and will be at risk of being intercepted. Likewise use of self-signed certificates or other certificates not signed by a trusted Certificate Authority puts your data at risk as Hub cannot verify the identity of the server at the end of the connection.
Please ensure your connection is configured in a way that is aligned with your security policy and the associated risks are understood and accepted.
Configuration Details
PostgreSQL
For PostgreSQL, please refer to PostgreSQL documentation for more information.
Location
- Example Format: jdbc:postgresql://hostServerName:postgreSqlServerPort/MyDatabaseName
You can enable encrypted connections by setting ‘ssl=true' (e.g., jdbc:postgresql://<server-name>:<port>/?ssl=true).
If the certificate for the PostgreSQL server is self-signed you'll need to set ‘sslfactory=org.postgresql.ssl.NonValidatingFactory' and ‘sslmode=require’ (e.g., jdbc:postgresql://<server-name>:<port>/?ssl=true&sslmode=require&sslfactory=org.postgresql.ssl.NonValidatingFactory).
If the certificate for the PostgreSQL server is not self-signed you'll need to add the certificate to the JDBC’s truststore.
Microsoft SQL Server
For SQL Server, please refer to Microsoft documentation for more information.
Location
- Example Format: jdbc:sqlserver://hostServerName;instanceN...MyDatabaseName
You can enable encrypted connections by setting 'encrypt=true' (e.g., jdbc:sqlserver://<server-name>:1433;encrypt=true;trustServerCertificate=false). If the certificate for the MySQL server is self-signed you'll need to set 'trustServerCertificate=true' (e.g., jdbc:sqlserver://<server-name>:1433;encrypt=true;trustServerCertificate=true)
If using JDBC driver mssql-jdbc-10.2.x
or later, the “;trustServerCertificate=
“ parameter and its corresponding value is required by the driver.
Note: Some older editions may be missing security updates and will need to apply security service packs to use a self-signed certificate and encryption. You may experience certificate errors if the SQL Server is using a self-signed or corporate certificate. To work around this, you will need to disable certificate validation in the JDBC driver or add the certificate to the JDBC’s truststore.
Oracle
For Oracle, please refer to this whitepaper for an overview of how to set up connections to encrypted Oracle server. For a guide to configuring the Oracle server to support SSL, please refer to Oracle documentation.
Location
- Example Format: jdbc:oracle:thin:@hostServerName:oracleServerPort/SID
For the most part assuming that the server is set up properly, you can follow Case#2 in the white paper and simply use a URL with the following format: jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(PORT=2484)(HOST=<hostname>))(CONNECT_DATA=(SERVICE_NAME=<servicename>))). On the server, make sure to disable client authentication by setting 'SSL_CLIENT_AUTHENTICATION=FALSE ' in the listener.ora and sqlnet.ora files.
For unencrypted connections, the protocol should be TCP and the port would generally be 1521, but the URL would otherwise be the same. The above example connection string is formatted in the 'Oracle Net connection descriptor' format, but Hub also accepts 'Thin-style service name' connection strings such as jdbc:oracle:thin:@<hostname>:1521:<servicename>.
If the certificate for the Oracle server is self-signed, but you still want to use SSL, you will need to follow Case#1 in the white paper. As described in the paper, only anonymous cipher suites are permitted when trying to use SSL without server authentication. You can specify the cipher suites in the sqlnet.ora file on the Oracle server.
Note: Some versions of Oracle do not by default support anonymous cipher suites. Thus, they will need to be imported to the server before enabling them.
Supported Databases for storing Hub Operational Data
Planview automatically stores operational data to a pre-configured Derby database. This is suitable for evaluation purposes only, and is not supported for production environments. Configuring Hub to utilize an external database enables you to perform frequent back-ups without stopping Hub, and ensures that your Hub practices are consistent with your existing disaster and recovery process.
Note: The database used for Hub operational data must support TLS 1.2.
To reduce latency, the Hub operational database should have its own machine and should be co-located with the Hub server.
Minimal User Permissions
For all supported databases, the user must have sufficient permissions to connect, create, alter and drop tables and indexes and create temporary tables. Users must also have sufficient permissions to select, insert, update, delete, and truncate tables.
Hub supports this operational database policy for scenarios where your database is on any cloud infrastructure like AWS or Azure. You can refer to the resources below for more information on encrypting communication between Hub and Database:
- For AWS, we recommend implementing a VPC. Click here for more information.
- For Azure, we recommend a VPN gateway. Click here for more information.
Note: A separate database must be used for Hub Operational Data and Enterprise Data Stream integrations.
Operational Database Recommendations
The recommendations below offer a general guideline only. We recommend consulting with customer care to determine the exact needs for your integration scenario, and for guidance on how to efficiently configure Hub.
You can see guidelines regarding external database sizing here.
We strongly recommend using the latest supported version of PostgreSQL for storing Hub Operational Data. At scale, Hub performs better, more reliably, and requires fewer resources with PostgreSQL than with the other available database options.
Supported Versions and Configuration Details
In the sections below, you will find supported database versions for storing Hub Operational Data and configuration details for each database.
PostgreSQL
Supported Versions
- 11
- 12
- 13
- 14
- 15
Configuration Settings
- The database must be case-sensitive (this is the default configuration).
- The database must be configured with the UTF8 character set.
CREATE DATABASE tasktop_hub ENCODING 'UTF8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8' TEMPLATE template0
Necessary User Permissions
The following provides sufficient permissions for the tasktop_hub
user on the tasktop_hub
database, when using a public schema:
CREATE USER tasktop_hub; REVOKE ALL PRIVILEGES ON DATABASE tasktop_hub FROM tasktop_hub; GRANT CONNECT, TEMP ON DATABASE tasktop_hub TO tasktop_hub; GRANT CREATE ON SCHEMA public TO tasktop_hub; GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA public TO tasktop_hub;
The following provides sufficient permissions for the tasktop_hub
user on the tasktop_hub
database, when using a custom schema:
Note: If you use a custom schema, please note that when configuring the external database connection you will need to add "?currentSchema=tasktop
" to the database connection URL, e.g. jdbc:postgresql://example.com:5432/dbName?currentSchema=tasktop
CREATE USER tasktop_hub; \connect tasktop_hub; CREATE SCHEMA TASKTOP; REVOKE ALL PRIVILEGES ON DATABASE tasktop_hub FROM tasktop_hub; GRANT CONNECT, TEMP ON DATABASE tasktop_hub TO tasktop_hub; GRANT CREATE ON SCHEMA Tasktop TO tasktop_hub; GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA Tasktop TO tasktop_hub;
Microsoft SQL Server
Supported Versions
- 2019
- 2022
Configuration Settings
- The database must be case sensitive. We recommend Latin1_General_100_CS_AS_KS_WS.
-
This can be configured using the following command (replace dbName with the name of your database):
ALTER DATABASE dbName COLLATE Latin1_General_100_CS_AS_KS_WS;
-
- We recommend monitoring the size of your transaction log, as very large transaction logs can cause database connection errors.
-
We recommend using version 9.4 of the JDBC driver when transferring from operational database to SQL Server.
Necessary User Permissions
- The user must be a SQL authenticated user (not a Windows authenticated user)
- Additionally, the user must have the following roles granted:
-
db_datareader
db_datawriter
db_ddladmin
Note: Instance and Database name options can be specified by attaching ";instanceName=;databaseName=
" to the end of the JDBC URL in Hub. If using JDBC driver mssql-jdbc-10.2.x
or later, the “;trustServerCertificate=
“ parameter and its corresponding value is required by the driver.
Oracle
Supported Versions
- 19c
- 21c
Configuration Settings
- The database must be case-sensitive (this is the default configuration).
- The database must be configured with the AL32UTF8 character set.
ALTER DATABASE dbName CHARACTER SET AL32UTF8;
Necessary User Permissions:
User must have CREATE SEQUENCE
, CREATE TABLE
, CREATE SESSION
permissions, as well as sufficient quota. Typical user creation might look as follows:
CREATE USER tasktop_hub IDENTIFIED BY a_password DEFAULT TABLESPACE tasktop_hub; GRANT CREATE SESSION TO tasktop_hub; GRANT CREATE SEQUENCE, CREATE TABLE TO tasktop_hub; ALTER USER tasktop_hub QUOTA UNLIMITED ON tasktop_hub;
Troubleshooting
- To resolve error ORA-30036 (UNABLE TO EXTEND SEGMENT BY 8 IN UNDO TABLESPACE), please refer to the following documentation.
MySQL
If your Planview Hub instance is currently using MySQL for its operational database, note that MySQL will no longer be supported as an operational database for Planview Hub as of May 31, 2024. Planview recommends you migrate from MySQL to a supported database.
Note: A self-guided migration procedure to go from MySQL to Postgres is available here.
Supported Databases for use in Enterprise Data Stream Integrations
The Planview Hub Database add-on allows you to create integrations that send artifact information to one central database.
Note: A separate database must be used for Hub Operational Data and Enterprise Data Stream integrations.
You can see guidelines regarding external database sizing here.
Supported Versions
If your license includes the Hub Database add-on and you would like to configure an Enterprise Data Stream Integration, the following databases and versions are supported:
PostgreSQL
General Support
- 11
- 12
- 13
- 14
- 15
Microsoft SQL Server
General Support
- 2019
- 2022
Oracle
General Support
- 19c
- 21c
We recommend using JDBC driver version 8.0 or later when creating a SQL connection for Enterprise Data Stream integrations.
MySQL
If your Planview Hub instance is currently using MySQL for an Enterprise Data Stream database, note that MySQL will no longer be supported as a database for Planview Hub as of May 31, 2024. Planview recommends you migrate from MySQL to a supported database.
Note: A self-guided migration recommendation procedure to go from MySQL to Postgres is available here.
Database Connections and Encryption
The following section describes different ways to configure your database connection. If you choose not to encrypt your connection, data will be transmitted over the network unprotected and will be at risk of being intercepted. Likewise use of self-signed certificates or other certificates not signed by a trusted Certificate Authority puts your data at risk as Hub cannot verify the identity of the server at the end of the connection.
Please ensure your connection is configured in a way that is aligned with your security policy and the associated risks are understood and accepted.
Configuration Details
PostgreSQL
For PostgreSQL, please refer to PostgreSQL documentation for more information.
Location
- Example Format: jdbc:postgresql://hostServerName:postgreSqlServerPort/MyDatabaseName
You can enable encrypted connections by setting ‘ssl=true' (e.g., jdbc:postgresql://<server-name>:<port>/?ssl=true).
If the certificate for the PostgreSQL server is self-signed you'll need to set ‘sslfactory=org.postgresql.ssl.NonValidatingFactory' and ‘sslmode=require’ (e.g., jdbc:postgresql://<server-name>:<port>/?ssl=true&sslmode=require&sslfactory=org.postgresql.ssl.NonValidatingFactory).
If the certificate for the PostgreSQL server is not self-signed you'll need to add the certificate to the JDBC’s truststore.
Microsoft SQL Server
For SQL Server, please refer to Microsoft documentation for more information.
Location
- Example Format: jdbc:sqlserver://hostServerName;instanceN...MyDatabaseName
You can enable encrypted connections by setting 'encrypt=true' (e.g., jdbc:sqlserver://<server-name>:1433;encrypt=true;trustServerCertificate=false). If the certificate for the MySQL server is self-signed you'll need to set 'trustServerCertificate=true' (e.g., jdbc:sqlserver://<server-name>:1433;encrypt=true;trustServerCertificate=true)
If using JDBC driver mssql-jdbc-10.2.x
or later, the “;trustServerCertificate=
“ parameter and its corresponding value is required by the driver.
Note: Some older editions may be missing security updates and will need to apply security service packs to use a self-signed certificate and encryption. You may experience certificate errors if the SQL Server is using a self-signed or corporate certificate. To work around this, you will need to disable certificate validation in the JDBC driver or add the certificate to the JDBC’s truststore.
Oracle
For Oracle, please refer to this whitepaper for an overview of how to set up connections to encrypted Oracle server. For a guide to configuring the Oracle server to support SSL, please refer to Oracle documentation.
Location
- Example Format: jdbc:oracle:thin:@hostServerName:oracleServerPort/SID
For the most part assuming that the server is set up properly, you can follow Case#2 in the white paper and simply use a URL with the following format: jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(PORT=2484)(HOST=<hostname>))(CONNECT_DATA=(SERVICE_NAME=<servicename>))). On the server, make sure to disable client authentication by setting 'SSL_CLIENT_AUTHENTICATION=FALSE ' in the listener.ora and sqlnet.ora files.
For unencrypted connections, the protocol should be TCP and the port would generally be 1521, but the URL would otherwise be the same. The above example connection string is formatted in the 'Oracle Net connection descriptor' format, but Hub also accepts 'Thin-style service name' connection strings such as jdbc:oracle:thin:@<hostname>:1521:<servicename>.
If the certificate for the Oracle server is self-signed, but you still want to use SSL, you will need to follow Case#1 in the white paper. As described in the paper, only anonymous cipher suites are permitted when trying to use SSL without server authentication. You can specify the cipher suites in the sqlnet.ora file on the Oracle server.
Note: Some versions of Oracle do not by default support anonymous cipher suites. Thus, they will need to be imported to the server before enabling them.
Supported Databases for storing Hub Operational Data
Planview automatically stores operational data to a pre-configured Derby database. This is suitable for evaluation purposes only, and is not supported for production environments. Configuring Hub to utilize an external database enables you to perform frequent back-ups without stopping Hub, and ensures that your Hub practices are consistent with your existing disaster and recovery process.
Note: The database used for Hub operational data must support TLS 1.2.
To reduce latency, the Hub operational database should have its own machine and should be co-located with the Hub server.
Minimal User Permissions
For all supported databases, the user must have sufficient permissions to connect, create, alter and drop tables and indexes and create temporary tables. Users must also have sufficient permissions to select, insert, update, delete, and truncate tables.
Hub supports this operational database policy for scenarios where your database is on any cloud infrastructure like AWS or Azure. You can refer to the resources below for more information on encrypting communication between Hub and Database:
- For AWS, we recommend implementing a VPC. Click here for more information.
- For Azure, we recommend a VPN gateway. Click here for more information.
Note: A separate database must be used for Hub Operational Data and Enterprise Data Stream integrations.
Operational Database Recommendations
The recommendations below offer a general guideline only. We recommend consulting with customer care to determine the exact needs for your integration scenario, and for guidance on how to efficiently configure Hub.
You can see guidelines regarding external database sizing here.
We strongly recommend using the latest supported version of PostgreSQL for storing Hub Operational Data. At scale, Hub performs better, more reliably, and requires fewer resources with PostgreSQL than with the other available database options.
Supported Versions and Configuration Details
In the sections below, you will find supported database versions for storing Hub Operational Data and configuration details for each database.
PostgreSQL
Supported Versions
- 11
- 12
- 13
- 14
- 15
Configuration Settings
- The database must be case-sensitive (this is the default configuration).
- The database must be configured with the UTF8 character set.
CREATE DATABASE tasktop_hub ENCODING 'UTF8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8' TEMPLATE template0
Necessary User Permissions
The following provides sufficient permissions for the tasktop_hub
user on the tasktop_hub
database, when using a public schema:
CREATE USER tasktop_hub; REVOKE ALL PRIVILEGES ON DATABASE tasktop_hub FROM tasktop_hub; GRANT CONNECT, TEMP ON DATABASE tasktop_hub TO tasktop_hub; GRANT CREATE ON SCHEMA public TO tasktop_hub; GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA public TO tasktop_hub;
The following provides sufficient permissions for the tasktop_hub
user on the tasktop_hub
database, when using a custom schema:
Note: If you use a custom schema, please note that when configuring the external database connection you will need to add "?currentSchema=tasktop
" to the database connection URL, e.g. jdbc:postgresql://example.com:5432/dbName?currentSchema=tasktop
CREATE USER tasktop_hub; \connect tasktop_hub; CREATE SCHEMA TASKTOP; REVOKE ALL PRIVILEGES ON DATABASE tasktop_hub FROM tasktop_hub; GRANT CONNECT, TEMP ON DATABASE tasktop_hub TO tasktop_hub; GRANT CREATE ON SCHEMA Tasktop TO tasktop_hub; GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA Tasktop TO tasktop_hub;
Microsoft SQL Server
Supported Versions
- 2019
- 2022
Configuration Settings
- The database must be case sensitive. We recommend Latin1_General_100_CS_AS_KS_WS.
-
This can be configured using the following command (replace dbName with the name of your database):
ALTER DATABASE dbName COLLATE Latin1_General_100_CS_AS_KS_WS;
-
- We recommend monitoring the size of your transaction log, as very large transaction logs can cause database connection errors.
-
We recommend using version 9.4 of the JDBC driver when transferring from operational database to SQL Server.
Necessary User Permissions
- The user must be a SQL authenticated user (not a Windows authenticated user)
- Additionally, the user must have the following roles granted:
-
db_datareader
db_datawriter
db_ddladmin
Note: Instance and Database name options can be specified by attaching ";instanceName=;databaseName=
" to the end of the JDBC URL in Hub. If using JDBC driver mssql-jdbc-10.2.x
or later, the “;trustServerCertificate=
“ parameter and its corresponding value is required by the driver.
Oracle
Supported Versions
- 19c
- 21c
Configuration Settings
- The database must be case-sensitive (this is the default configuration).
- The database must be configured with the AL32UTF8 character set.
ALTER DATABASE dbName CHARACTER SET AL32UTF8;
Necessary User Permissions:
User must have CREATE SEQUENCE
, CREATE TABLE
, CREATE SESSION
permissions, as well as sufficient quota. Typical user creation might look as follows:
CREATE USER tasktop_hub IDENTIFIED BY a_password DEFAULT TABLESPACE tasktop_hub; GRANT CREATE SESSION TO tasktop_hub; GRANT CREATE SEQUENCE, CREATE TABLE TO tasktop_hub; ALTER USER tasktop_hub QUOTA UNLIMITED ON tasktop_hub;
Troubleshooting
- To resolve error ORA-30036 (UNABLE TO EXTEND SEGMENT BY 8 IN UNDO TABLESPACE), please refer to the following documentation.
MySQL
If your Planview Hub instance is currently using MySQL for its operational database, note that MySQL will no longer be supported as an operational database for Planview Hub as of May 31, 2024. Planview recommends you migrate from MySQL to a supported database.
Note: A self-guided migration procedure to go from MySQL to Postgres is available here.
Supported Databases for use in Enterprise Data Stream Integrations
The Planview Hub Database add-on allows you to create integrations that send artifact information to one central database.
Note: A separate database must be used for Hub Operational Data and Enterprise Data Stream integrations.
You can see guidelines regarding external database sizing here.
Supported Versions
If your license includes the Hub Database add-on and you would like to configure an Enterprise Data Stream Integration, the following databases and versions are supported:
PostgreSQL
General Support
- 11
- 12
- 13
- 14
- 15
Microsoft SQL Server
General Support
- 2019
- 2022
Oracle
General Support
- 19c
- 21c
We recommend using JDBC driver version 8.0 or later when creating a SQL connection for Enterprise Data Stream integrations.
MySQL
If your Planview Hub instance is currently using MySQL for an Enterprise Data Stream database, note that MySQL will no longer be supported as a database for Planview Hub as of May 31, 2024. Planview recommends you migrate from MySQL to a supported database.
Note: A self-guided migration recommendation procedure to go from MySQL to Postgres is available here.
Database Connections and Encryption
The following section describes different ways to configure your database connection. If you choose not to encrypt your connection, data will be transmitted over the network unprotected and will be at risk of being intercepted. Likewise use of self-signed certificates or other certificates not signed by a trusted Certificate Authority puts your data at risk as Hub cannot verify the identity of the server at the end of the connection.
Please ensure your connection is configured in a way that is aligned with your security policy and the associated risks are understood and accepted.
Configuration Details
PostgreSQL
For PostgreSQL, please refer to PostgreSQL documentation for more information.
Location
- Example Format: jdbc:postgresql://hostServerName:postgreSqlServerPort/MyDatabaseName
You can enable encrypted connections by setting ‘ssl=true' (e.g., jdbc:postgresql://<server-name>:<port>/?ssl=true).
If the certificate for the PostgreSQL server is self-signed you'll need to set ‘sslfactory=org.postgresql.ssl.NonValidatingFactory' and ‘sslmode=require’ (e.g., jdbc:postgresql://<server-name>:<port>/?ssl=true&sslmode=require&sslfactory=org.postgresql.ssl.NonValidatingFactory).
If the certificate for the PostgreSQL server is not self-signed you'll need to add the certificate to the JDBC’s truststore.
Microsoft SQL Server
For SQL Server, please refer to Microsoft documentation for more information.
Location
- Example Format: jdbc:sqlserver://hostServerName;instanceN...MyDatabaseName
You can enable encrypted connections by setting 'encrypt=true' (e.g., jdbc:sqlserver://<server-name>:1433;encrypt=true;trustServerCertificate=false). If the certificate for the MySQL server is self-signed you'll need to set 'trustServerCertificate=true' (e.g., jdbc:sqlserver://<server-name>:1433;encrypt=true;trustServerCertificate=true)
If using JDBC driver mssql-jdbc-10.2.x
or later, the “;trustServerCertificate=
“ parameter and its corresponding value is required by the driver.
Note: Some older editions may be missing security updates and will need to apply security service packs to use a self-signed certificate and encryption. You may experience certificate errors if the SQL Server is using a self-signed or corporate certificate. To work around this, you will need to disable certificate validation in the JDBC driver or add the certificate to the JDBC’s truststore.
Oracle
For Oracle, please refer to this whitepaper for an overview of how to set up connections to encrypted Oracle server. For a guide to configuring the Oracle server to support SSL, please refer to Oracle documentation.
Location
- Example Format: jdbc:oracle:thin:@hostServerName:oracleServerPort/SID
For the most part assuming that the server is set up properly, you can follow Case#2 in the white paper and simply use a URL with the following format: jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(PORT=2484)(HOST=<hostname>))(CONNECT_DATA=(SERVICE_NAME=<servicename>))). On the server, make sure to disable client authentication by setting 'SSL_CLIENT_AUTHENTICATION=FALSE ' in the listener.ora and sqlnet.ora files.
For unencrypted connections, the protocol should be TCP and the port would generally be 1521, but the URL would otherwise be the same. The above example connection string is formatted in the 'Oracle Net connection descriptor' format, but Hub also accepts 'Thin-style service name' connection strings such as jdbc:oracle:thin:@<hostname>:1521:<servicename>.
If the certificate for the Oracle server is self-signed, but you still want to use SSL, you will need to follow Case#1 in the white paper. As described in the paper, only anonymous cipher suites are permitted when trying to use SSL without server authentication. You can specify the cipher suites in the sqlnet.ora file on the Oracle server.
Note: Some versions of Oracle do not by default support anonymous cipher suites. Thus, they will need to be imported to the server before enabling them.
Supported Databases for storing Hub Operational Data
Planview automatically stores operational data to a pre-configured Derby database. This is suitable for evaluation purposes only, and is not supported for production environments. Configuring Hub to utilize an external database enables you to perform frequent back-ups without stopping Hub, and ensures that your Hub practices are consistent with your existing disaster and recovery process.
Note: The database used for Hub operational data must support TLS 1.2.
To reduce latency, the Hub operational database should have its own machine and should be co-located with the Hub server.
Minimal User Permissions
For all supported databases, the user must have sufficient permissions to connect, create, alter and drop tables and indexes and create temporary tables. Users must also have sufficient permissions to select, insert, update, delete, and truncate tables.
Hub supports this operational database policy for scenarios where your database is on any cloud infrastructure like AWS or Azure. You can refer to the resources below for more information on encrypting communication between Hub and Database:
- For AWS, we recommend implementing a VPC. Click here for more information.
- For Azure, we recommend a VPN gateway. Click here for more information.
Note: A separate database must be used for Hub Operational Data and Enterprise Data Stream integrations.
Operational Database Recommendations
The recommendations below offer a general guideline only. We recommend consulting with customer care to determine the exact needs for your integration scenario, and for guidance on how to efficiently configure Hub.
You can see guidelines regarding external database sizing here.
We strongly recommend using the latest supported version of PostgreSQL for storing Hub Operational Data. At scale, Hub performs better, more reliably, and requires fewer resources with PostgreSQL than with the other available database options.
Supported Versions and Configuration Details
In the sections below, you will find supported database versions for storing Hub Operational Data and configuration details for each database.
PostgreSQL
Supported Versions
- 11
- 12
- 13
- 14
- 15
Configuration Settings
- The database must be case-sensitive (this is the default configuration).
- The database must be configured with the UTF8 character set.
CREATE DATABASE tasktop_hub ENCODING 'UTF8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8' TEMPLATE template0
Necessary User Permissions
The following provides sufficient permissions for the tasktop_hub
user on the tasktop_hub
database, when using a public schema:
CREATE USER tasktop_hub; REVOKE ALL PRIVILEGES ON DATABASE tasktop_hub FROM tasktop_hub; GRANT CONNECT, TEMP ON DATABASE tasktop_hub TO tasktop_hub; GRANT CREATE ON SCHEMA public TO tasktop_hub; GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA public TO tasktop_hub;
The following provides sufficient permissions for the tasktop_hub
user on the tasktop_hub
database, when using a custom schema:
Note: If you use a custom schema, please note that when configuring the external database connection you will need to add "?currentSchema=tasktop
" to the database connection URL, e.g. jdbc:postgresql://example.com:5432/dbName?currentSchema=tasktop
CREATE USER tasktop_hub; \connect tasktop_hub; CREATE SCHEMA TASKTOP; REVOKE ALL PRIVILEGES ON DATABASE tasktop_hub FROM tasktop_hub; GRANT CONNECT, TEMP ON DATABASE tasktop_hub TO tasktop_hub; GRANT CREATE ON SCHEMA Tasktop TO tasktop_hub; GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA Tasktop TO tasktop_hub;
Microsoft SQL Server
Supported Versions
- 2019
- 2022
Configuration Settings
- The database must be case sensitive. We recommend Latin1_General_100_CS_AS_KS_WS.
-
This can be configured using the following command (replace dbName with the name of your database):
ALTER DATABASE dbName COLLATE Latin1_General_100_CS_AS_KS_WS;
-
- We recommend monitoring the size of your transaction log, as very large transaction logs can cause database connection errors.
-
We recommend using version 9.4 of the JDBC driver when transferring from operational database to SQL Server.
Necessary User Permissions
- The user must be a SQL authenticated user (not a Windows authenticated user)
- Additionally, the user must have the following roles granted:
-
db_datareader
db_datawriter
db_ddladmin
Note: Instance and Database name options can be specified by attaching ";instanceName=;databaseName=
" to the end of the JDBC URL in Hub. If using JDBC driver mssql-jdbc-10.2.x
or later, the “;trustServerCertificate=
“ parameter and its corresponding value is required by the driver.
Oracle
Supported Versions
- 19c
- 21c
Configuration Settings
- The database must be case-sensitive (this is the default configuration).
- The database must be configured with the AL32UTF8 character set.
ALTER DATABASE dbName CHARACTER SET AL32UTF8;
Necessary User Permissions:
User must have CREATE SEQUENCE
, CREATE TABLE
, CREATE SESSION
permissions, as well as sufficient quota. Typical user creation might look as follows:
CREATE USER tasktop_hub IDENTIFIED BY a_password DEFAULT TABLESPACE tasktop_hub; GRANT CREATE SESSION TO tasktop_hub; GRANT CREATE SEQUENCE, CREATE TABLE TO tasktop_hub; ALTER USER tasktop_hub QUOTA UNLIMITED ON tasktop_hub;
Troubleshooting
- To resolve error ORA-30036 (UNABLE TO EXTEND SEGMENT BY 8 IN UNDO TABLESPACE), please refer to the following documentation.
MySQL
If your Planview Hub instance is currently using MySQL for its operational database, note that MySQL will no longer be supported as an operational database for Planview Hub as of May 31, 2024. Planview recommends you migrate from MySQL to a supported database.
Note: A self-guided migration procedure to go from MySQL to Postgres is available here.
Supported Databases for use in Enterprise Data Stream Integrations
The Planview Hub Database add-on allows you to create integrations that send artifact information to one central database.
Note: A separate database must be used for Hub Operational Data and Enterprise Data Stream integrations.
You can see guidelines regarding external database sizing here.
Supported Versions
If your license includes the Hub Database add-on and you would like to configure an Enterprise Data Stream Integration, the following databases and versions are supported:
PostgreSQL
General Support
- 11
- 12
- 13
- 14
- 15
Extended Support
- 10 (End-of-Service-Life Date: July 31, 2024)
If you are interested in extended support, please reach out to customer care.
Microsoft SQL Server
General Support
- 2019
- 2022
Extended Support
-
2017 (End-of-Service-Life Date: July 31, 2024)
Oracle
General Support
- 19c
- 21c
Extended Support
- N/A
We recommend using JDBC driver version 8.0 or later when creating a SQL connection for Enterprise Data Stream integrations.
MySQL
If your Planview Hub instance is currently using MySQL for an Enterprise Data Stream database, note that MySQL will no longer be supported as a database for Planview Hub as of May 31, 2024. Planview recommends you migrate from MySQL to a supported database.
Note: A self-guided migration recommendation procedure to go from MySQL to Postgres is available here.
Database Connections and Encryption
The following section describes different ways to configure your database connection. If you choose not to encrypt your connection, data will be transmitted over the network unprotected and will be at risk of being intercepted. Likewise use of self-signed certificates or other certificates not signed by a trusted Certificate Authority puts your data at risk as Hub cannot verify the identity of the server at the end of the connection.
Please ensure your connection is configured in a way that is aligned with your security policy and the associated risks are understood and accepted.
Configuration Details
PostgreSQL
For PostgreSQL, please refer to PostgreSQL documentation for more information.
Location
- Example Format: jdbc:postgresql://hostServerName:postgreSqlServerPort/MyDatabaseName
You can enable encrypted connections by setting ‘ssl=true' (e.g., jdbc:postgresql://<server-name>:<port>/?ssl=true).
If the certificate for the PostgreSQL server is self-signed you'll need to set ‘sslfactory=org.postgresql.ssl.NonValidatingFactory' and ‘sslmode=require’ (e.g., jdbc:postgresql://<server-name>:<port>/?ssl=true&sslmode=require&sslfactory=org.postgresql.ssl.NonValidatingFactory).
If the certificate for the PostgreSQL server is not self-signed you'll need to add the certificate to the JDBC’s truststore.
Microsoft SQL Server
For SQL Server, please refer to Microsoft documentation for more information.
Location
- Example Format: jdbc:sqlserver://hostServerName;instanceN...MyDatabaseName
You can enable encrypted connections by setting 'encrypt=true' (e.g., jdbc:sqlserver://<server-name>:1433;encrypt=true;trustServerCertificate=false). If the certificate for the MySQL server is self-signed you'll need to set 'trustServerCertificate=true' (e.g., jdbc:sqlserver://<server-name>:1433;encrypt=true;trustServerCertificate=true)
If using JDBC driver mssql-jdbc-10.2.x
or later, the “;trustServerCertificate=
“ parameter and its corresponding value is required by the driver.
Note: Some older editions may be missing security updates and will need to apply security service packs to use a self-signed certificate and encryption. You may experience certificate errors if the SQL Server is using a self-signed or corporate certificate. To work around this, you will need to disable certificate validation in the JDBC driver or add the certificate to the JDBC’s truststore.
Oracle
For Oracle, please refer to this whitepaper for an overview of how to set up connections to encrypted Oracle server. For a guide to configuring the Oracle server to support SSL, please refer to Oracle documentation.
Location
- Example Format: jdbc:oracle:thin:@hostServerName:oracleServerPort/SID
For the most part assuming that the server is set up properly, you can follow Case#2 in the white paper and simply use a URL with the following format: jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(PORT=2484)(HOST=<hostname>))(CONNECT_DATA=(SERVICE_NAME=<servicename>))). On the server, make sure to disable client authentication by setting 'SSL_CLIENT_AUTHENTICATION=FALSE ' in the listener.ora and sqlnet.ora files.
For unencrypted connections, the protocol should be TCP and the port would generally be 1521, but the URL would otherwise be the same. The above example connection string is formatted in the 'Oracle Net connection descriptor' format, but Hub also accepts 'Thin-style service name' connection strings such as jdbc:oracle:thin:@<hostname>:1521:<servicename>.
If the certificate for the Oracle server is self-signed, but you still want to use SSL, you will need to follow Case#1 in the white paper. As described in the paper, only anonymous cipher suites are permitted when trying to use SSL without server authentication. You can specify the cipher suites in the sqlnet.ora file on the Oracle server.
Note: Some versions of Oracle do not by default support anonymous cipher suites. Thus, they will need to be imported to the server before enabling them.