Connecting Oracle SQL Developer to Autonomous Database

adb wallet What the wallet is

Autonomous Database only accepts encrypted connections, and it authenticates the server as well as you. The wallet is a zip file containing the certificates that make that possible, plus the connection descriptors for each service level. Downloading it from the cloud console is the step that has no equivalent when you connect to a database on your own network.

adb steps Making the connection

1. In the Oracle Cloud console, open your Autonomous Database and download the client credentials wallet. You set a wallet password here — keep it, you will need it shortly.
2. Save the zip somewhere permanent. Oracle SQL Developer reads it at connect time, so a Downloads folder you periodically clear out is a poor choice.
3. In Oracle SQL Developer, create a new connection and set the connection type to Cloud Wallet.
4. Browse to the zip file. There is no need to unpack it.
5. Pick a service from the dropdown that populates — these come from the wallet.
6. Enter your database username and password, click Test, then Connect.

The username is a database user such as ADMIN, not your cloud account. That distinction trips people up on the first attempt, because the console signs you in with one identity and the database expects another.

adb services Which service to pick

The dropdown lists several services whose names end in suffixes like _low, _medium and _high. They point at the same database; what differs is how much parallelism and how many concurrent statements each allows.

• _low — no parallelism, highest concurrency. The right default for interactive work in a SQL worksheet.
• _medium — some parallelism, fewer concurrent statements.
• _high — most resources per statement, fewest concurrent statements. For heavy one-off queries.

Start with _low. Reaching for _high because it sounds better is a common way to hit concurrency limits that have nothing to do with your query.

adb problems When it does not connect

• Invalid username/password — you are probably using your cloud console login rather than a database user. Try ADMIN with the password set when the database was created.
• The wallet is rejected — wallets are tied to a specific database. One downloaded for a different instance, or a stale one after rotation, will not work.
• Nothing populates the service dropdown — the zip may be partly extracted or corrupted. Re-download it.
• The database is stopped — Autonomous instances can be stopped from the console and free-tier ones are reclaimed after a period of inactivity. Check its state before debugging the client.
• Access control list — if the instance restricts client IPs, your address has to be on the list regardless of a valid wallet.

adb tns The older TNS route

Older guides describe unzipping the wallet, editing sqlnet.ora to point WALLET_LOCATION at the extracted folder, setting TNS_ADMIN, and then choosing a TNS connection type in Oracle SQL Developer. That still works and is worth knowing, because tools other than Oracle SQL Developer often need it.

For Oracle SQL Developer itself there is no reason to prefer it. The Cloud Wallet connection type reads the zip directly, so there is nothing to extract, no environment variable to set, and nothing to redo when you replace an expiring wallet. If you are following an older tutorial that has you editing configuration files, you are doing work the client no longer requires.

adb notes Worth knowing

Wallets expire. Oracle issues them with a validity period, and a connection that worked for months will stop one day with a certificate error — the fix is to download a fresh wallet, not to change anything in Oracle SQL Developer.

SQLcl reads the same wallets, so a connection set up here works from the command line too. If you are unsure which tool suits a task, the comparison is here.