Skip to main content
Planview Customer Success Center

Supported Databases

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.
    • 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

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

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 encryptionYou 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

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

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 encryptionYou 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

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

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 encryptionYou 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

Extended Support

  • 10 (End-of-Service-Life Date: July 31, 2024

If you are interested in extended support, please reach out to your customer care.

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

Extended Support

  • 2017 (End-of-Service-Life Date: July 31,

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

Extended Support

  • N/A

If you are interested in extended support, please reach out to customer care.

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

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

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 encryptionYou 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

Extended Support

  • 10 (End-of-Service-Life Date: July 31,

If you are interested in extended support, please reach out to your customer care.

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

Extended Support

  • 2017 (End-of-Service-Life Date: July 31, 2024

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

Extended Support

  • N/A

If you are interested in extended support, please reach out to customer care.

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 SEQUENCECREATE TABLECREATE 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

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

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

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 encryptionYou 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.