Connecting To An Autonomous Database
There are two methods by which you can connect other network resources (hosts etc.) to an Autonomous Database (ADB).
Public Endpoint
If you need connectivity to an ADB from the public internet, you need to create an Autonomous Database with a public endpoint. This is the default option when creating an Autonomous Database instance.
Access to this type of ADB instance can be controlled by using an Access Control List. This can be specified at the time of instance creation. The ACL can restrict access in a number of ways;
- Allow access only for one or more individual public IP addresses
- Allow access only for one or more public CIDR block ranges
- Allow access only for hosts within one or more specific VCNs
- Allow access for one or more individual IP addresses within a VCN
- Allow access for one or more CIDR block ranges within a VCN
The ACL can be amended after the creation of the ADB instance.
If connectivity to the ADB public endpoint is required from within an OCI VCN, this can be achieved through gateways. The gateway you need depends on the type of subnet within the VCN that requires connectivity.
Public Subnet
For connectivity to an ADB instance (with a public endpoint) from a public subnet within a VCN, you need to configure an Internet Gateway.
Private Subnet
For connectivity to an ADB instance (with a public endpoint) from a private subnet within a VCN, you need to configure a Service Gateway.
In either case, routing tables will need to be configured for each type of subnet so that traffic destined for the ADB is routed correctly by the DRG to the appropriate gateway.
Tip:
Connectivity between on-premises network resources and the ADB instance can be achieved through the use of Transit Routing.
Private Endpoint
If you want to only allow connectivity to an Autonomous Database (ADB) via an OCI VCN, you need to create an Autonomous Database with a private endpoint. This method ensures that all traffic to and from your ADB is kept off the public internet.
When creating the ADB to be accessed via a private endpoint, you must supply a pre-existing private subnet within an OCI VCN and a pre-existing Network Security Group.
Making the Connection
Whether the ADB you have created has a private or a public endpoint, the means of resolving and making a connection are the same.
Connections to the ADB are made by client applications that reference connection credentials contained in one or more configuration files. These files are stored collectively in a “wallet” and are downloadable as a single .zip file from the ADB instance details page.
The wallet contains the following files;
Credential Files
- cwallet.sso and ewallet.p12 - These files are used to help authenticate users database users without them having to specify a username and password
- keystore.jks and truststore.jks - These files are used when authenticationg clients and servers over SSL/TLS (usually via HTTP).
Helper Files
- sqlnet.ora - This file contains entries to direct the Oracle client software to the wallet’s location.
- tnsnames.ora - This file is used to resolve the name of the oracle database service to be connected to.
- ojdbc.properties - This file specifies the connection properties for Java applications wanting to connect to the ADB using JDBC.
The wallet needs to be located on any device that is acting as a client to the ADB. Which files are actually used depends on the type of connection that is being made.
Tip:
For more information about using Wallets to connect to an Autonomous Database, we recommend the following Oracle Documentation; How to Connect to an Autonomous Database