Chapter 3

Connect to Autonomous Database

3. Set the wallet location: Add the OraclePKIProvider at the end of the provider list
in the file java.security (this file is part of your JRE install located
at $JRE_HOME/jre/lib/security/java.security) which typically looks
like:

security.provider.14=oracle.security.pki.OraclePKIProvider

4. Compile and Run: Compile and run the sample to get a successful connection.
Make sure to have oraclepki.jar , osdt_core.jar, and osdt_cert.jar, in the
classpath. Also, you need to pass the connection properties. Update the
properties with the location where tnsnames.ora and wallet files are located.

java –classpath
./lib/ojdbc8.jar:./lib/ucp.jar:./lib/oraclepki.jar:./lib/
osdt_core.jar:./lib/osdt_cert.jar:.
-Doracle.net.tns_admin=/users/test/wallet_dbname
-Doracle.net.ssl_server_dn_match=true
-Doracle.net.ssl_version=1.2 (Not required for 12.2)
-Doracle.net.wallet_location= “(SOURCE=(METHOD=FILE)
(METHOD_DATA=(DIRECTORY=/users/test/wallet_dbname)))”
UCPSample

Note:
These are Windows system examples. Add a \ continuation character if you
are setting –D properties on multiple lines on UNIX ( Linux or a Mac).

Using Java KeyStore

To use Java and the 12.2 or older JDBC Thin Drivers to connect to Autonomous
Database with Java KeyStore (JKS), do the following:
1. Make sure that the prerequisites are met: See JDBC Thin Driver Connection
Prerequisites Connections with Wallets (mTLS) for more information.
2. Verify the connection: You can either use a Java program, a servlet, or IDEs to
verify the connection to the database. A simple test is to download
DataSourceSample.java or UCPSample.java from JDBC code samples and
update the connection URL to have the required TNS alias and pass TNS_ADMIN,
providing the path for tnsnames.ora and update the connection URL to have the
required TNS alias. Also, in the sample source code update the database
username and password. For example:

DB_URL="jdbc:oracle:thin:@dbname_high”

3-64
 Chapter 3
Connect to Autonomous Database

Note:
If you are using Microsoft Active Directory with Autonomous Database, then
update the sample source code to use the Active Directory username and
Active Directory user password. See Use Microsoft Active Directory with
Autonomous Database for more information.

3. Compile and Run: Compile and run the sample to get a successful connection. You
need to pass the connection properties as shown. Update the properties with the location
where tnsnames.ora and JKS files are placed. If you want to pass these connection
properties programmatically then refer to DataSourceForJKS.java. For example:

java
-Doracle.net.tns_admin=/users/test/wallet_dbname
-Djavax.net.ssl.trustStore=truststore.jks
-Djavax.net.ssl.trustStorePassword=**********
-Djavax.net.ssl.keyStore=keystore.jks
-Djavax.net.ssl.keyStorePassword=************
-Doracle.net.ssl_server_dn_match=true
-Doracle.net.ssl_version=1.2 // Not required for 12.2

JDBC Thin Connections with an HTTP Proxy

If the client is behind a firewall and your network configuration requires an HTTP proxy to
connect to the internet, you need to use the JDBC Thin Client 18.1 or higher which enables
connections through HTTP proxies.
To connect to Autonomous Database through an HTTPS proxy, open and update your
tnsnames.ora file. Add the HTTP proxy hostname(https_proxy) and port (https_proxy_port)
to the connection string. Replace the values with your HTTPS proxy information. For
example:
1. Add the HTTP proxy hostname and port to the connection definitions in tnsnames.ora.
You need to add the https_proxy and https_proxy_port parameters in the address section
of connection definitions. For example, the following sets the HTTP proxy to
proxyhostname and the HTTP proxy port to 80; replace these values with your HTTP
proxy information:

db2022adb_high =
(description=
(address=
(https_proxy=proxyhostname)(https_proxy_port=80)
(protocol=tcps)(port=1522)(host=adb.example.oraclecloud.com)
)
(connect_data=(service_name=db2022adb_high.adb.oraclecloud.com)
)
(security=security=(ssl_server_dn_match=yes)
)
)

3-65
 Chapter 3
Connect to Autonomous Database

Notes:

• JDBC Thin client versions earlier than 18.1 do not support connections
through HTTP proxy.
• Successful connection depends on specific proxy configurations and the
performance of data transfers would depend on proxy capacity. Oracle
does not recommend using this feature in Production environments
where performance is critical.
• Configuring tnsnames.ora for the HTTP proxy may not be enough
depending on your organization's network configuration and security
policies. For example, some networks require a username and password
for the HTTP proxy.
• In all cases, contact your network administrator to open outbound
connections to hosts in the oraclecloud.com domain using the relevant
port without going through an HTTP proxy.

JDBC Thin TLS Connections Without a Wallet

Autonomous Database mandates a secure connection that uses Transport Layer
Security (TLSv1.2). Depending on the configuration options, Autonomous Database
supports mTLS and TLS authentication. This section covers using JDBC Thin
Connections with TLS authentication without a wallet.
• JDBC Thin Driver Connection Prerequisites for TLS Connections Without a Wallet
Applications that use JDBC Thin driver support TLS and mutual TLS (mTLS)
authentication. Connecting to an Autonomous Database instance with TLS
authentication requires database credentials (username and password) and
provides a secure connection, but does not require that you download Oracle
wallets or Java KeyStore (JKS) files.
• Using a JDBC URL TLS Connection String for JDBC Thin Driver Without a Wallet
To connect the database using JDBC Thin Driver with TLS without a wallet, you
provide a connection string. Each database service has its own TNS Name and
connection string.

JDBC Thin Driver Connection Prerequisites for TLS Connections Without a Wallet
Applications that use JDBC Thin driver support TLS and mutual TLS (mTLS)
authentication. Connecting to an Autonomous Database instance with TLS
authentication requires database credentials (username and password) and provides a
secure connection, but does not require that you download Oracle wallets or Java
KeyStore (JKS) files.

Note:
See Update your Autonomous Database Instance to Allow both TLS and
mTLS Authentication for information on allowing TLS connections.

Perform the following steps before connecting to the database:

3-66
 Chapter 3
Connect to Autonomous Database

1. Provision Autonomous Database: Create a database and obtain your database

credentials (username and password).
2. Verify your JDK version for security: If you are using JDK11, JDK10, or JDK9 then you
don’t need to do anything for this step. If your JDK version is less than JDK8u162 then
you need to download the JCE Unlimited Strength Jurisdiction Policy Files. Refer to the
README file for installation notes. Download the JCE files from Java Cryptography
Extension (JCE) Unlimited Strength Jurisdiction Policy Files 8 Download.
3. Check JDBC Driver Version: Download the latest 18.3 JDBC Thin driver (ojdbc8.jar
and ucp.jar) from Oracle Database 18c (18.3) JDBC Driver & UCP Downloads. Use
the latest 18.3 JDBC driver, or newer, to take advantage of recent enhancements that
simplify connections and provide easy steps for configuration. You also need the
additional jars: oraclepki.jar, osdt_core.jar, and osdt_cert.jar for use with
Oracle wallets.

Using a JDBC URL TLS Connection String for JDBC Thin Driver Without a Wallet
To connect the database using JDBC Thin Driver with TLS without a wallet, you provide a
connection string. Each database service has its own TNS Name and connection string.
To run an application using the JDBC Thin Driver with TLS authentication without a wallet:
1. Copy a connection string for the Autonomous Database.
To connect with TLS authentication copy a TLS connection string. On the Database
Connection page, under TLS Authentication, select TLS to view the connection strings
for connecting with TLS authentication.
See View TNS Names and Connection Strings for an Autonomous Database Instance for
information on viewing and copying connection stings.
See Predefined Database Service Names for Autonomous Database for information on
the different databases services for each connection string.
2. Set the DB_URL parameter.
Use the following format for the DB_URL parameter:

DB_URL=jdbc:oracle:thin:@my_connect_string

For example:

DB_URL=jdbc:oracle:thin:@(description= (retry_count=20)(retry_delay=3)
(address=(protocol=tcps)
(port=1521)(host=adb.region.oraclecloud.com))
(connect_data=(service_name=u9adutfb2ba8x4d_database_medium.adb.oracleclou
d.com))
(security=(ssl_server_dn_match=yes)))

Preparing for Oracle Call Interface Connections

Using TLS with Oracle Call Interface connections with newer Oracle Instant Client/Oracle
Database Client versions, a wallet is not required. For TLS connections with Oracle Call
Interface running on older Oracle Instant Client/Oracle Database Client versions, a wallet is
required for both mTLS authenticated connections and TLS authenticated connections.

3-67
 Chapter 3
Connect to Autonomous Database

• Oracle Call Interface (OCI) Connections and Wallets (mTLS)

Oracle Net Services can find the location of the Autonomous Database wallet
using the WALLET_LOCATION parameter in the sqlnet.ora file.
• Oracle Call Interface (OCI) Connections with TLS Authentication
Using TLS with Oracle Call Interface, connections with newer Oracle Instant
Client/Oracle Database Client versions, a wallet is not required.

Oracle Call Interface (OCI) Connections and Wallets (mTLS)

Oracle Net Services can find the location of the Autonomous Database wallet using
the WALLET_LOCATION parameter in the sqlnet.ora file.

When WALLET_LOCATION is used, Oracle Net Services automatically uses the wallet.
The wallet is used transparently to the application. See Prepare for Oracle Call
Interface, ODBC, and JDBC OCI Connections with Wallets (mTLS) for information on
setting WALLET_LOCATION.

See Download Client Credentials (Wallets) for information on downloading client

credentials for Autonomous Database.

Oracle Call Interface (OCI) Connections with TLS Authentication

Using TLS with Oracle Call Interface, connections with newer Oracle Instant Client/
Oracle Database Client versions, a wallet is not required.
Oracle Call Interface (OCI) clients support TLS authentication without a wallet if you
are using the following client versions:
• Oracle Instant Client/Oracle Database Client 19.13 - only on Linux x64
• Oracle Instant Client/Oracle Database Client 19.14 (or later) and 21.5 (or later) -
only on Linux x64 and Windows

Note:
See Update your Autonomous Database Instance to Allow both TLS and
mTLS Authentication for information on allowing TLS connections.

See Prepare for Oracle Call Interface, ODBC, and JDBC OCI Connections Using TLS
Authentication to prepare for Oracle Call Interface connections.
When a wallet is required and you set WALLET_LOCATION parameter in the
sqlnet.ora file, Oracle Net Services finds the location of the wallet and uses the
wallet (use of the wallet is transparent to the application).

Predefined Database Service Names for Autonomous Database

The tnsnames.ora file provided with the credentials zip file contains the database
service names that allow you to connect to your database.
The available predefined service names differ depending on your workload. The
different services provide different levels of performance and concurrency for
Autonomous Database connections.

3-68
 Chapter 3
Connect to Autonomous Database

Workload Type Database Services Names

Data Warehouse dbname_high
dbname_medium
dbname_low

See Database Service Names for Autonomous Data Warehouse for

more information.
Transaction Processing dbname_tpurgent
dbname_tp
dbname_high
dbname_medium
dbname_low

See Database Service Names for Autonomous Transaction Processing

and Autonomous JSON Database for more information.
JSON Database dbname_tpurgent
dbname_tp
dbname_high
dbname_medium
dbname_low

See Database Service Names for Autonomous Transaction Processing

and Autonomous JSON Database for more information.

Connect with Oracle Analytics Desktop

Oracle Analytics Desktop makes it easy to visualize your data so you can focus on exploring
interesting data patterns. Just connect to Autonomous Database, select the elements that
you’re interested in, and let Oracle Analytics Desktop find the best way to visualize it. Choose
from a variety of visualizations to look at data in a specific way.
For details on connecting Autonomous Database with Oracle Analytics Desktop, see User’s
Guide for Oracle Analytics Desktop.

Connect with Oracle Analytics Cloud

Oracle Analytics Cloud is a scalable and secure public cloud service that provides a full set of
capabilities to explore and perform collaborative analytics for you, your workgroup, and your
enterprise.
For details for connecting Autonomous Database with Oracle Analytics Cloud, see Visualizing
Data and Building Reports in Oracle Analytics Cloud.

Connection and Networking Options and Features

Autonomous Database provides a number of different connection and networking options and
features for connecting to a database.
• Using ACLs, VCNs, and Private Endpoints with Autonomous Database
Describes the options for restricting network access to your Autonomous Database by
specifying access control rules or using a virtual cloud network (private access with a
private endpoint).

3-69
 Chapter 3
Connect to Autonomous Database

• Connect with Oracle Cloud Infrastructure FastConnect

Oracle Cloud Infrastructure FastConnect provides an easy way for you to connect
your on-premises network to Autonomous Database using FastConnect Public
Peering. FastConnect provides higher-bandwidth options, and a more reliable and
consistent networking experience compared to internet-based connections.
• Access Autonomous Database with VCN Transit Routing
Oracle Cloud Infrastructure supports private access from your on-premises
network to a database with virtual cloud network (VCN) Transit Routing.
• Access Autonomous Database with Service Gateway
Autonomous Database supports private access from Oracle Cloud Infrastructure
resources in a VCN through a service gateway.
• Use Database Resident Connection Pooling with Autonomous Database
Database Resident Connection Pool (DRCP) in Autonomous Database supports
easier and more efficient management of open connections. Using DRCP provides
you with access to a connection pool in your database that enables a significant
reduction in key database resources required to support many client connections
and when the database needs to scale for many simultaneous connections.

Using ACLs, VCNs, and Private Endpoints with Autonomous Database

Describes the options for restricting network access to your Autonomous Database by
specifying access control rules or using a virtual cloud network (private access with a
private endpoint).
• About Network Access Options
Provides an overview of the network access options available when you provision
or clone Autonomous Database.
• Overview of Restricting Access with ACLs
When you select the network access Allow secure access from anywhere
option when you provision or clone an instance, you can restrict network access
by defining an Access Control List (ACL). You can also add, update, or remove an
ACL for an active instance.
• Overview of Private Endpoints
You can specify that Autonomous Database uses a private endpoint inside your
Virtual Cloud Network (VCN) in your tenancy. You can configure a private endpoint
during provisioning or cloning your Autonomous Database, or you can switch to
using private endpoints in existing databases that use public endpoints. This
allows you to keep all traffic to and from your Autonomous Database off of the
public internet.

About Network Access Options

Provides an overview of the network access options available when you provision or
clone Autonomous Database.

Note:
For all of these options connections to your Autonomous Database use
certificate-based authentication and Secure Sockets Layer (SSL).

3-70
 Chapter 3
Connect to Autonomous Database

When you provision or clone your Autonomous Database you specify one of the following
network access options:
• Allow secure access from everywhere: This option assigns a public endpoint, public IP
and hostname, to your database. With this selection you have two options:
– The database is accessible from all IP addresses: this is the default option when you
provision or clone Autonomous Database.
– Select Configure access control rules: This option lets you restrict access by
defining access control rules in an Access Control List (ACL). By specifying an ACL,
the database will be accessible from a whitelisted set of IP addresses or VCNs.
If you configure your database with the Allow secure access from everywhere option,
you can add, modify, or remove ACLs after you provision or clone the database.
See Overview of Restricting Access with ACLs for more information.
• Virtual cloud network: This option assigns a private endpoint, private IP, and hostname
to your database. Specifying this option allows traffic only from the VCN you specify;
access to the database from all public IPs or VCNs is blocked. This allows you to define
security rules, ingress/egress, at the Network Security Group (NSG) level and to control
traffic to your Autonomous Database.
See Configure Private Endpoints When You Provision or Clone an Instance for more
information.

Note:
After you provision or clone your database, you can change the selection you make,
to either Allow secure access from everywhere or Virtual cloud network for the
database instance.

See Change from Public to Private Endpoints with Autonomous Database for more
information.
See Change from Private to Public Endpoints with Autonomous Database for more
information.

Overview of Restricting Access with ACLs

When you select the network access Allow secure access from anywhere option when you
provision or clone an instance, you can restrict network access by defining an Access Control
List (ACL). You can also add, update, or remove an ACL for an active instance.

3-71
 Chapter 3
Connect to Autonomous Database

Specifying an access control list blocks all IP addresses that are not in the ACL list
from accessing the database. After you specify an access control list, the database
only accepts connections from addresses on the access control list and the database
rejects all other client connections.
Depending on where the client machines that connect to your database are located
you have the following options with ACLs:
• If your client machines connect to your database through the public internet, then
you can use ACLs to specify the client machine's public IP addresses or their
public CIDR blocks. In this case only the specified public IP addresses can access
your database.
• If the client machines reside in an Oracle Cloud Infrastructure Virtual Cloud
Network (VCN), you can configure a Service Gateway to connect to your
database. In this case, you can specify the VCN in your ACL, this allows all client
machines in that VCN to access your database and blocks all other connections.
Furthermore, you can specify the VCN and a list of private IP addresses or CIDR
blocks in that VCN. This allows only those client machines with the specified IP
addresses or CIDR blocks to access your database and blocks all other
connections.
See VCNs and Subnets for details on Virtual Cloud Networks (VCN).
See Access to Oracle Services: Service Gateway for details on setting up a
Service Gateway.
• If you have on-premises clients that connect to your database through Transit
Routing, you can specify the VCN and also the private IP addresses or CIDR
blocks of these on-premises clients to access to your database.
See Transit Routing: Private Access to Oracle Services for details on Transit
Routing.
• You can use these options together to set multiple rules to allow access from
different types of clients. Multiple rules do not exclude each other.
See Configuring Network Access with Access Control Rules (ACLs) for the steps for
configuring network access with ACLs, either when you provision or clone your
database, or whenever you want to add, modify or remove ACLs.

Overview of Private Endpoints

You can specify that Autonomous Database uses a private endpoint inside your Virtual
Cloud Network (VCN) in your tenancy. You can configure a private endpoint during
provisioning or cloning your Autonomous Database, or you can switch to using private
endpoints in existing databases that use public endpoints. This allows you to keep all
traffic to and from your Autonomous Database off of the public internet.
Specifying the Virtual cloud network configuration option only allows traffic from the
VCN you specify and blocks access to the database from all public IPs or VCNs. This
allows you to define security rules, ingress/egress, at the Network Security Group
(NSG) level and to control traffic to your database.
See Configuring Network Access with Private Endpoints for the steps for configuring
network access private endpoints, either when you provision or clone your database,
or whenever you want to add, modify or remove private endpoints.

3-72
 Chapter 3
Connect to Autonomous Database

Connect with Oracle Cloud Infrastructure FastConnect

Oracle Cloud Infrastructure FastConnect provides an easy way for you to connect your on-
premises network to Autonomous Database using FastConnect Public Peering. FastConnect
provides higher-bandwidth options, and a more reliable and consistent networking experience
compared to internet-based connections.
Use FastConnect to access public services in Oracle Cloud Infrastructure without using the
internet, for example, access to Object Storage, or the Oracle Cloud Infrastructure Console
and APIs. Without FastConnect, the traffic destined for public IP addresses would be routed
over the internet. With FastConnect, that traffic goes over your private physical connection.
For details for connecting Autonomous Database with Oracle Cloud Infrastructure
FastConnect see FastConnect Overview.

Access Autonomous Database with VCN Transit Routing

Oracle Cloud Infrastructure supports private access from your on-premises network to a
database with virtual cloud network (VCN) Transit Routing.
Transit routing refers to a network setup in which your on-premises network uses a
connected virtual cloud network (VCN), through a service gateway on the VCN for
connectivity to a database. You connect the on-premises network to the VCN with
FastConnect or VPN Connect, and then configure the VCN routing so that traffic transits
through the VCN to a database beyond the VCN.
After transit routing is configured, there are no special steps required to access Oracle APEX
or Database Actions, or to consume RESTful services published in Oracle REST Data
Services.
See Transit Routing: Private Access to Oracle Services for more details and options available
with Transit Routing.
See VPN Connect for more information on VPN Connect.

Access Autonomous Database with Service Gateway

Autonomous Database supports private access from Oracle Cloud Infrastructure resources in
a VCN through a service gateway.
A service gateway allows connectivity to Autonomous Database from private IP addresses in
private subnets without requiring a NAT Gateway in your VCN. After a service gateway is
configured, there are no special steps required to connect to Autonomous Database. Use the
same connection steps as described in this chapter, depending on your application type or
the client tool you are using to connect to the database.
After a service gateway is configured, there are no special steps required to access Oracle
APEX or Database Actions, or to consume RESTful services published in Oracle REST Data
Services.
See Access to Oracle Services: Service Gateway for details.

Use Database Resident Connection Pooling with Autonomous Database

Database Resident Connection Pool (DRCP) in Autonomous Database supports easier and
more efficient management of open connections. Using DRCP provides you with access to a

3-73