Wednesday, August 12, 2026

Oracle Wallet file settings

 I have been doing more research on how to set wallet locations for the Oracle database as wallets are becoming more and more important to secure your database.



Oracle Wallet usage
Oracle wallet usage


I have found that there are different types of wallets, and  different ways to set the Wallet location depending on it's usage.


1) WALLET_ROOT

Wallet_root is a Database setting (spfile) that is used by a running database.  Below are the different sub-directories that can be created within wallet root and what they can be used for.

The most commonly used directories are

TDE - The wallet in this directory contains the encryption key(s) for the database and replaces the setting ENCRYPTION_WALLET_LOCATION in the sqlnet.ora.

TLS - The wallet in this directory contains the TLS certificate(s) used by the database to make secure TCPS connections.

SERVER_SEPS - The wallet in this location contains the login credentials for other databases or even the same database. Some examples of when this can be useful are.

  • Sending real-time redo to a ZDLRA
  • Creating Database Links to other databases
  • RMAN channel configurations that connect to different nodes in a RAC cluster.
* Note : It was pointed out to me, that using the wallet in server_seps for RMAN channel connects will replace the usage of the "connect ..." string when allocating RMAN channels.


Subdirectory Component / Purpose Typical File Types Notes & Details
tde Transparent Data Encryption (TDE) ewallet.p12, ewallet_*.p12 Created automatically when establishing TDE keystores. Contains master encryption keys for CDB$ROOT, non-CDBs, or isolated PDBs.
tde_seps TDE Auto-Login / SEPS cwallet.sso Stores the Secure External Password Store (SEPS) auto-login file used for automatic opening of the TDE keystore.
tls Transport Layer Security (TLS/SSL) ewallet.p12, cwallet.sso Stores public key infrastructure (PKI) certificates and private keys used for encrypted network communications.
eus Enterprise User Security (EUS) ewallet.p12, cwallet.sso Contains credentials for centralized directory service authentication (e.g., Oracle Internet Directory / LDAP).
xdb_wallet XML Database (XDB) Security ewallet.p12 Used for securing Oracle XML DB HTTP, HTTPS, and FTP server connections.
server_seps Server-Side Credential Store cwallet.sso, ewallet.p12 Used in newer releases (e.g., Oracle 23ai) for passwordless server-side connections and integrations (such as Recovery Appliance).
mfa Multi-Factor Authentication (MFA) ewallet.p12, cwallet.sso Holds certificates and PKI credentials used for native Multi-Factor Authentication integrations (e.g., OMA or Duo). Introduced in Oracle 19.28+.
bctable Blockchain Tables ewallet.p12, cwallet.sso Stores the PKI private key and certificates of the blockchain table owner. Required for signing and verifying rows using the DBMS_BLOCKCHAIN_TABLE package.
<PDB_GUID> Isolated Pluggable Database Root Subdirectories (e.g., /tde, /tls) A 128-bit GUID folder automatically generated per isolated PDB to isolate keystores from CDB$ROOT and other PDBs.



WALLET_ROOT Directory Structure
WALLET_ROOT/
├── bctable/                    # Blockchain Tables PKI store
│   └── ewallet.p12
├── eus/                        # Enterprise User Security credentials
│   └── ewallet.p12
├── mfa/                        # Multi-Factor Authentication wallet (19.28+)
│   └── ewallet.p12
├── server_seps/                # Server-side credential store
│   └── cwallet.sso
├── tde/                        # Master CDB/non-CDB TDE wallet
│   └── ewallet.p12
├── tde_seps/                   # CDB Auto-login keystore
│   └── cwallet.sso
├── tls/                        # TLS/SSL certificate wallet
│   └── ewallet.p12
├── xdb_wallet/                 # XML DB security wallet
│   └── ewallet.p12
└── <PDB_GUID>/                 # Isolated PDB directory
    ├── bctable/
    │   └── ewallet.p12
    ├── mfa/
    │   └── ewallet.p12
    ├── tde/                    # Isolated PDB TDE wallet
    │   └── ewallet.p12
    ├── tde_seps/
    │   └── cwallet.sso
    └── tls/
        └── cwallet.sso


2) SQLNET.ORA

The sqlnet.ora file is used by the database (during startup) and by client sessions.  Client sessions can override which sqlnet.ora is being used by setting TNS_ADMIN.

There are two locations that can be set in the sqlnet.ora file.

ENCRYPTION_WALLET_LOCATION 

This parameter is being deprecated in Oracle 26ai and it is being replaced with WALLET_ROOT mentioned previously.  WALLET_ROOT allows for easily setting individual wallet locations for each database sharing the same $ORACLE_HOME, along with the ability to set individual wallet locations for each PDB. it is recommended to no longer use this setting and migrate to WALLET_ROOT.

WALLET_LOCATION

Wallet_location is used for a number of wallets entries including SEPS, TLS, and EUS.  Because of this you need to be careful when setting the general wallet_location in the default location ($ORACLE_HOME/network/admin).  With consolidation, many environments today have multiple databases sharing the same $ORACLE_HOME and those databases often require separate, unique wallet files files for each database. 
It is best to create a separate sqlnet.ora directory for each database outside of the $ORACLE_HOME and utilize TNS_ADMIN to set your environment.
This parameter is being deprecated for use by the Oracle Database server (during startup), but not by client connections.

3) TNSNAMES.ORA

The tnsnames.ora file is used to make the connection to the database and it is possible set some wallet locations as part of the connection string.
This setting is done with the the (SECURITY= ...) block of the connect string.

SEPS_WALLET_LOCATION


This setting can be used to set the location of the SEPS wallet for each client connection. This can be useful if you make multiple connects in the same client session and wish to use different SEPS wallets for each connection. 

WALLET_LOCATION

Wallet_location is used for a number of wallets entries including SEPS, TLS, and EUS.  The usage of wallet location in the database connect string is the same as it would be within the sqlnet.ora. Using this setting will allow you to isolate which wallets is used for each connection when using the same client session.


Tuesday, June 23, 2026

Automating Creating Long Term backups from the Autonomous Recovery Service

 When I wrote my last blog on listing the Long Term Backups created by Autonomous Recovery Service, I didn't go through the process of how to dynamically create a new backup.

Below is how you create a long term backup in the console, but most customers want to automate this process.


The oci cli command you would use to create a new backup is "oci db backup create".

In order to create an end-of-month backup with a restore point as of midnight what I recommend customers do is

  1. Ensure you have a nightly backup that runs late at night (about 22:00) and will finish by midnight on a regular basis. 
  2. Schedule the automatic long term backup creation to occur about 00:45 on the next day. This ensures that a log sweep has occurred. For BaseDB you would wait until after the next hour.  If you have enabled the zero data loss feature (real-time redo), you want to make sure that the ARCHIVE_LAG_TARGET is set to 30 minutes or less and forcing a periodic log switch.
This ensures you are creating a long term backup with minimal archive logs to defuzzy the backup.

Command inputs

The easiest way to determine the input for this command is to use the --generate-full-command-json-input option.

oci db backup create --generate-full-command-json-input

What is returned is the JSON example below showing you what parameters need to be filled in to create the backup.

{
  "databaseId": "string",
  "displayName": "string",
  "maxWaitSeconds": 0,
  "retentionDays": 0,
  "retentionYears": 0,
  "waitForState": [
    "CREATING|ACTIVE|DELETING|DELETED|FAILED|RESTORING|UPDATING|CANCELING|CANCELED"
  ],
  "waitIntervalSeconds": 0
}

Source database and backup identifying name

  • databaseID : This is the OCID for the database that you want to create the long term backup for.
  • displayName: This is the name to identify the backup from a listing and would match the name I would put in the GUI.

Wait for state of command (Optional)

  • waitForState: Since the backup can take awhile to run, you can have the command wait to return until a specified state (or any one of a list of states) occurs. When creating a new backup the valid states would be
    • ACTIVE
    • CANCELED
    • CANCELING
    • CREATING
    • FAILED
  • maxWaitSeconds: How long to wait between state checks when waiting for a state to occur.
Example of  wait

oci db backup create --waitForState CREATING --waitForState CANCELED 

Would wait for the backup to start to be created or canceled before returning.

Retention (mandatory for long term backups and must be greater than 90 days and less than 10 years)

You would enter the number of days you want to keep backups for (retentionDays), or you would enter the number of years (retentionYears) , but not both.

Below is an example JSON file that would create a new long term backup named "bsgtest" and keep the backup for 100 days.


{
  "databaseId": "ocid1.database.oc1.phx.anyhqljtbv6267ia2wse63oz7xadpv5lfi2gf233333eomezhadfbdkt2eq",
  "displayName": "bsgtest",
  "maxWaitSeconds": 0,
  "retentionDays": 100
}


That's all you need to know about creating a long term backup dynamically.


Thursday, May 21, 2026

Autonomous Recovery Service - Listing backups

Autonomous Recovery Service - Listing backups

One of the unique features of the Autonomous Recovery Service (RCV) is the ability to create Long Term Backups by using existing backups that are currently stored in RCV.

NOTE: Long term backups, also known as "Keep" backups are self contained backups that provide the ability to restore to a small predetermined point-in-time window. These long term backups are often stored for months, or even years and are typically used for auditing purposes.

These backups are created dynamically outside of the database itself and the DB host is not used.
Because the DB host is bypassed, the normal backup listings on the DB host using the DBAASCLI tool do not see long term backups.


Viewing backups with OCI

All of the backups can be viewed in both the OCI Console and by using the OCI CLI tool.
In this blog, I will describe how you can use the OCI Cli tool to view all of the backups.
The command I am utilizing to display backups is

oci db backup list


Unfortunately, the output from this command is JSON objects which can be difficult to read if you want to produce a report.  

In this blog, I show examples leveraging JMESPath queries via the --query flag.



The Foundation: Listing Database Backups

The baseline command to list backups for a specific database requires the --database-id (OCID). By default, we want to output this as a table, grab all records across pages using the --all flag, and project key fields like Shape and Type:

oci db backup list \
  --database-id {DB OCID} \
  --output table \
  --query "data[?\"lifecycle-state\" == 'ACTIVE'] | sort_by(@, &\"time-started\")[].{Backup_Name: \"display-name\", Time_Started: \"time-started\", Status: \"lifecycle-state\", Version: \"version\", OCID: \"id\", Database_size_GBs: \"database-size-in-gbs\",Shape: \"shape\",Type: \"type\"}"

Running this execution in your environment outputs a perfectly structured text report directly in your shell stream:

+------------------+-------------------+-------------------------------------------------------------------------------------+-------------+--------+----------------------------------+-------------+-------------+
| Backup_Name      | Database_size_GBs | OCID                                                                                | Shape       | Status | Time_Started                     | Type        | Version     |
+------------------+-------------------+-------------------------------------------------------------------------------------+-------------+--------+----------------------------------+-------------+-------------+
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267iafzxovfcfwpr3pcact3e3vu2exz..........         | Exadata.X8M | ACTIVE | 2026-03-30T12:04:06.553000+00:00 | INCREMENTAL | 19.26.0.0.0 |
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267iat6czxrwvfnhrgl4voypnunsf2qmfc......          | Exadata.X8M | ACTIVE | 2026-03-31T12:05:41.932000+00:00 | INCREMENTAL | 19.26.0.0.0 |
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267iapdhn7ekp7ax2y74pbbk32yi4c5zr.......          | Exadata.X8M | ACTIVE | 2026-04-01T12:05:13.350000+00:00 | INCREMENTAL | 19.26.0.0.0 |
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267iakasw46kzqpk74g335esjwehihmkfzuj............. | Exadata.X8M | ACTIVE | 2026-04-02T12:04:54.891000+00:00 | INCREMENTAL | 19.26.0.0.0 |
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267iagzx75s2s6zravvpjoem2rkvtm7ue54d............. | Exadata.X8M | ACTIVE | 2026-04-03T12:05:40.559000+00:00 | INCREMENTAL | 19.26.0.0.0 |
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267ia2j7s7r464swgvrfc34dqh7b635hupho............. | Exadata.X8M | ACTIVE | 2026-04-04T12:03:59.219000+00:00 | INCREMENTAL | 19.26.0.0.0 |
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267iawkwrmemheourosyriczq3v7lecgmrcj............. | Exadata.X8M | ACTIVE | 2026-04-05T07:24:00.238000+00:00 | INCREMENTAL | 19.26.0.0.0 |
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267ia2j25fk53uf5fmfkivkoa6ijcbn3fdg7c............ | Exadata.X8M | ACTIVE | 2026-04-06T12:04:22.389000+00:00 | INCREMENTAL | 19.26.0.0.0 |
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267iass2o5w5bryallijsjjpk2nso2654jr2............. | Exadata.X8M | ACTIVE | 2026-04-07T12:03:56.898000+00:00 | INCREMENTAL | 19.26.0.0.0 |
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv62

Finding the most recent backup

In this example, I am limiting the command to extract only daily backups (no long term backups), sort by the execution time, and return only the first record.

This command can be also be used in any scripting to ensure you are cloning from the most recent backup.

oci db backup list \
  --database-id {DB OCID} \
--output table \ --query "data[?\"retention-period-in-days\" == \`null\` && \"retention-period-in-years\" == \`null\` && \"lifecycle-state\" == 'ACTIVE'] | sort_by(@, &\"time-started\")[-1].{Backup_Name: \"display-name\", Time_Started: \"time-started\", Status: \"lifecycle-state\", Version: \"version\", OCID: \"id\", Database_size_GBs: \"database-size-in-gbs\",Shape: \"shape\",Type: \"type\"}"

Executing this slice pattern evaluates down to a single, isolated record representing your absolute most recent backup:

+------------------+-------------------+-------------------------------------------------------------------------------------+-------------+--------+----------------------------------+-------------+-------------+
| Backup_Name      | Database_size_GBs | OCID                                                                                | Shape       | Status | Time_Started                     | Type        | Version     |
+------------------+-------------------+-------------------------------------------------------------------------------------+-------------+--------+----------------------------------+-------------+-------------+
| Automatic Backup | 24.01171875       | ocid1.dbbackup.oc1.phx.anyhqljtbv6267iaufuy74ggl2bvf66czd75x3v4366qrwc............. | Exadata.X8M | ACTIVE | 2026-05-19T12:04:12.917000+00:00 | INCREMENTAL | 19.26.0.0.0 |
+------------------+-------------------+-------------------------------------------------------------------------------------+-------------+--------+----------------------------------+-------------+-------------+

Finding all of the long term backups

This command will display only backups that were creating with a future expiration date. This can be used to view all of the long term backups that were created for this database.

 oci db backup list \
>   --database-id {Database OCID} \
>   --output table \
>   --query "data[?\"time-expiry-scheduled\" != \`null\` && \"lifecycle-state\" == 'ACTIVE'] | sort_by(@, &\"time-started\")[].{Backup_Name: \"display-name\", Time_Bacdkup_Started: \"time-started\", Status: \"lifecycle-state\", Version: \"version\", Time_Backup_Expires: \"time-expiry-scheduled\", OCID: \"id\", Database_size_GBs: \"database-size-in-gbs\",Shape: \"shape\"}"


+------------------+-------------------+-------------------------------------------------------------------------------------+-------------+--------+----------------------------------+----------------------------------+-------------+
| Backup_Name      | Database_size_GBs | OCID                                                                                | Shape       | Status | Time_Bacdkup_Started             | Time_Backup_Expires              | Version     |
+------------------+-------------------+-------------------------------------------------------------------------------------+-------------+--------+----------------------------------+----------------------------------+-------------+
| Long_term_backup | 21.0              | ocid1.dbbackup.oc1.phx.anyhqljtbv6267iaskl3otjhgovkhvefzcjzckdg3v5sfwfybglhrl2mqz7a | Exadata.X8M | ACTIVE | 2026-05-14T14:39:17.539000+00:00 | 2027-05-14T14:39:18.871000+00:00 | 19.26.0.0.0 |
+------------------+-------------------+-------------------------------------------------------------------------------------+-------------+--------+----------------------------------+----------------------------------+-------------+

Friday, April 10, 2026

Automating cloning of your Exadata Database Service on Dedicated Infrastructure database

One of the questions I often get from customers is 

"How do I automate the cloning of a production database backup to a non-prod copy?  This is something we do often."

There are three different OCI commands  to do what seems like the exact same thing. Specifically, when it comes to restoring a database from a backup, the OCI CLI gives us three primary paths.

The "secret sauce" to choosing the right command is understanding where the database is going and ensuring you have the right OCIDs for your target infrastructure. Let's break down the full parameter sets you need to keep your automation from failing.

These are all "oci db database " commands


The Restore Matrix: Choosing Your Command

Command Infrastructure Target Required Target ID Primary Use Case
create-database-from-backup Exadata / C@C --db-home-id Restoring into an existing Exadata Home.
create-from-backup Base DB (VM/BM) --db-system-id Adding a DB to an existing DB System.
create --source DB_BACKUP Base DB (VM/BM) --compartment-id Building a NEW DB System from a backup.

1. The Exadata Full Set: create-database-from-backup

This command uses a JSON object for the --database flag. This is where you define the identity of the clone within the Exadata rack along with the backup you want to use to create the new database.

{
  "adminPassword": "YourPassword123#",
  "backupId": "ocid1.dbbackup.oc1...",
  "backupTDEPassword": "SourceWalletPassword",
  "dbName": "EXACLON",
  "dbUniqueName": "EXACLON_PRD",
  "sidPrefix": "EXACL",
  "pluggableDatabases": ["PDB1", "PDB2"],
  "dbHomeId": "ocid1.dbhome.oc1...",
  "storageSizeDetails": {
    "dataStorageSizeInGBs": 256,
    "recoStorageSizeInGBs": 512
  },
  "sourceEncryptionKeyLocationDetails": {
    "providerType": "AWS|AZURE|GCP|EXTERNAL",
    "awsEncryptionKeyId": "string",
    "hsmPassword": "string"
  }
}

2. The VM/BM In-Place Clone: create-from-backup

`

This is for standard Virtual Machine shapes. You must provide the dbSystemId (the OCID of the VM) to tell OCI exactly where to deploy the restored data.

{
  "adminPassword": "NewAdminPassword123#",
  "backupId": "ocid1.dbbackup.oc1...",
  "backupTdePassword": "SourceWalletPassword",
  "dbSystemId": "ocid1.dbsystem.oc1.iad.example_vm_ocid",
  "dbName": "VMCLON",
  "dbUniqueName": "VMCLON_DEV",
  "sidPrefix": "VMCL",
  "kmsKeyId": "ocid1.key.oc1...",
  "dataStorageSizeInGbs": 256,
  "recoStorageSizeInGbs": 512,
  "databaseSoftwareImageId": "ocid1.dbsoftwareimage.oc1...",
  "isUnifiedAuditingEnabled": true,
  "waitForState": ["AVAILABLE"],
  "maxWaitSeconds": 3600
}

3. Provisioning New Infra: create with --source

This is the "All-In-One" command. It creates the VM Cluster or DB System infrastructure from scratch. Because of this, it requires networking IDs (VCN/Subnet) and hardware shapes.

{
  "source": "DB_BACKUP",
  "backupId": "ocid1.dbbackup.oc1...",
  "tdeWalletPassword": "SourceWalletPassword",
  "compartmentId": "ocid1.compartment.oc1...",
  "subnetId": "ocid1.subnet.oc1...",
  "vmClusterId": "ocid1.vmcluster.oc1...",
  "dbSystemId": "ocid1.dbsystem.oc1...",
  "dbHomeId": "ocid1.dbhome.oc1...",
  "dbName": "NEWDB",
  "dbUniqueName": "NEWDB_U",
  "shape": "VM.Standard.E4.Flex",
  "vaultId": "ocid1.vault.oc1...",
  "kmsKeyId": "ocid1.key.oc1...",
  "dbWorkload": "OLTP",
  "autoBackupEnabled": true,
  "waitForState": ["AVAILABLE"]
}

Key Identification Checklist:
  • Exadata: You must have the --db-home-id of an existing home on the rack.
  • VM In-Place: You need the --db-system-id of the running VM instance.
  • Identity: Every command requires a dbName (8 chars max) and dbUniqueName. For automation, use the sidPrefix to prevent instance ID collisions.



Example from my tenancy

This example shows the command I am using in my tenancy to clone a database

{
  oci db database create \
  --config-file          /home/opc/clone/config \		#--> My OCI authentication config file
  --profile              DEFAULT \				#--> Entry in the config file to use credentials for		
  --region               us-phoenix-1 \				#--> Region I am connecting to execute (source region)
  --source               DB_BACKUP \				#--> Source for the new database is a DB_BACKUP
  --db-home-id           ocid1.dbhome.{...} \			#--> Target home OCID to create new DB
  --vm-cluster-id        ocid1.cloudvmcluster.{...} \		#--> Target VM OCID to create the new DB in
  --admin-password       "$_ADMIN_PW" \				#--> Target DB admin password when creating
  --from-json            file:///{file location}/xx.json	#--> JSON input file 


}

Example from my tenancy (cont)

This is the contents of the .json input file

{
  "source": "DB_BACKUP",				#--> Source is a DB_BACKUP
  "dbHomeId": "ocid1.dbhome.{...}",			#--> Target DB Home OCID
  "database": {
    "backupId": "ocid1.dbbackup.{...}",		        #--> Backup OCID to create database from
    "dbName": "BGRENNC",				#--> New DB name
    "dbUniqueName": "bgrennc_clone",		        #--> New DB Unique name
    "adminPassword": "dd",				#--> New DB Admin password (new TDE password will be the same)
    "backupTDEPassword": "dd",				#--> Original TDE wallet password
    "dbBackupConfig": {
      "autoBackupEnabled": true,			#--> Configure automatic backups
      "recoveryWindowInDays": 30			#--> Set recovery window for new backups
    },
    "definedTags": {
      "Oracle-Tags": {
        "CostType": "Shared"
      }
    }
  }
}


Mastering TDE & Key Management

One of the biggest hurdles in database cloning is handling the Transparent Data Encryption (TDE) layer. If your source backup was encrypted using a key from a different cloud provider or a local HSM, you must tell OCI how to decrypt it during the restore process.

1. Cross-Cloud & External Key Providers

When using the create-database-from-backup command (Exadata), you use the sourceEncryptionKeyLocationDetails parameter. This is a JSON object where you must specify the providerType and the corresponding Key OCID or ID from the source provider.

Provider Type Parameter Required Description
AWS awsEncryptionKeyId The ARN of the AWS KMS key used on the source.
AZURE azureEncryptionKeyId The Azure Key Vault key URI.
GCP googleCloudProviderEncryptionKeyId The fully qualified resource name of the GCP KMS key.
EXTERNAL hsmPassword Used for backups protected by an on-premises Hardware Security Module.

2. Native OCI Vault Integration

For native OCI restores, you have two choices: use the standard Oracle-managed keys (default) or use your own keys via OCI Vault (KMS). If you want to use your own keys, you must provide the kmsKeyId and, in some cases, the vaultId.

  • kmsKeyId: The OCID of the Master Encryption Key in the OCI Vault.
  • kmsKeyVersionId: (Optional) Use this if you need to pin the restore to a specific version of your key.
  • vaultId: Required by the create command to identify which Vault the key resides in.
Important Security Note: If you are restoring a database into a different compartment or tenancy than the source, your Dynamic Group for the target DB System must have READ and USE permissions for the Vault and Key. Without these IAM policies, the restore will fail immediately with a "Not Authorized" error.

By correctly mapping these key parameters, you ensure that your data remains encrypted and compliant throughout its entire lifecycle, even as it moves across cloud boundaries.


Automating with Infrastructure as Code (Terraform)

While the CLI is great for one-off tasks, most of my customers eventually want to bake these clones into their CI/CD pipelines. In Terraform, we use the oci_database_database resource. The "magic" happens in the source attribute and the database_details block.

resource "oci_database_database" "cloned_db" {
    # This maps to the --source flag in the CLI
    source = "DB_BACKUP"

    database {
        admin_password      = var.database_admin_password
        db_name             = "CLONEDB"
        db_unique_name      = "CLONEDB_IAD"
        character_set       = "AL32UTF8"
        ncharacter_set      = "AL16UTF16"
        db_workload         = "OLTP"
        
        # TDE Management
        tde_wallet_password = var.source_tde_password
        kms_key_id          = var.target_vault_key_ocid
    }

    # Target Infrastructure IDs
    db_home_id   = var.target_db_home_ocid
    database_id  = var.source_database_backup_ocid

    # Best Practice: Ignore password changes after initial provision
    lifecycle {
        ignore_changes = [database[0].admin_password]
    }
}

Terraform Pro-Tip: Always use the ignore_changes lifecycle hook for the admin_password. Once the database is restored, security policies often require a password rotation. Without this hook, Terraform will try to revert the password to the plain-text value in your .tfvars every time you run an update!

Thursday, April 2, 2026

Autonomous Recovery Service Live Lab available

One of the latest additions to Oracle's Live Labs is the Autonomous Recovery Service. This lab  allow you to understand how to utilize the Autonomous Recovery Service Service for backing up your Oracle database in the cloud, even in a multicloud environment.

If you haven't used it,  Live Labs is Oracle's free, hands-on platform which allows you to go though a workshop or lab to learn more about Oracle's products.

Start Here <-------- Link to this lab


The nice thing about this lab is that you can utilize Oracle's sandbox to learn about the Autonomous Recovery Service (RCV) without the requirement of accessing your OCI/Multicloud tenancy.

Also, the features that are demonstrated in this lab are the same regardless of using the Autonomous Recovery Service in OCI, or in a multcloud environment.

NOTE:

Keep in mind that it does take time to configure your lab for you to use since the provisioning process performs an initial backup.  In my case it took about 60 minutes. You can view the status of building your lab environment on the "My Reservations" page to follow the progress.  Once completed, this makes the environment immediately available once the lab environment is configured.

Setup:

Once your tenancy is configured for the lab you need to log in using the supplied credentials, and change the log in. Be sure to follow the directions and screenshots in the setup portion of the lab before beginning.

Also be sure to note the region and compartment that you will be using, and change the region after logging into the tenancy to the correct region.

Lab 1: Onboarding a database

One you log into the tenancy and region, you can now go through the steps to configure a database to use the recovery service.

NOTE: The lab uses the "Base DB service" for the demo but the steps would be the same regardless of the Oracle Database server utilized or the location (OCI, AWS, GCP, Azure, etc.).

In this section you will 

Create a protection policy - There are default protection policies policies you can use, but most customers chose to create their own for the following reason.

  • You can chose the exact retention period between 14 and 95 days. Since the service is incremental forever, backup usage is not dependent on a weekly full backup.
  • You can chose the backup location if using multicloud. The default is OCI, and you need to create a protection policy if you want to change the location from the default.
  • You can configure a retention lock. Setting a retention lock is only available when creating your own protection policy.

Configure backups for the existing database - In this section you will view the backup configuration for the database.  When the lab environment was provisioned backups were configured, and in this step you will change the protection policy and enable real-time data protection.
Once the configuration changes are saved, you will monitor the update progress.
Lastly you will view the backup information for this database.

Lab 2: Perform point-in-time restores

The next section of the lab will walk through a point-in-time restore.
You will be guided through connecting to the Database directly through "Cloud Shell" and in cloud shell you will
  • Create new table and insert data into it.
  • Determine the current SCN at this point (with the new table).
  • Delete the table
  • Abort the database (demonstrating real-time data protection)
  • Delete the database files
  • Restore the database to the SCN in the second step
This does take a bit and you are encouraged to continue to lab 3 while this occurs.

Lab 3: Create an on-demand backup

This lab walks you through the process to dynamically create an on-demand.
On-demand backups can be either
  1. Kept for the current retention period. This is useful when upgrading, or rolling out a new release and you want to create a known restore point. This type of backup is stored in the recovery service and will age out with the retention period.
  2. Long-Term backup retention period. This type of backup goes to Oracle managed infrequent object storage, and you specify how long the backups are kept for. 

Lab 4: Monitor & Create Alarms

This section of lab walks you through two additional features that are available with the Autonomous Recovery Service.

Observability - In this section of the lab you explore the metrics that available to view.  The lab demonstrates viewing the data loss exposure in either a chart or table

Alarms - This section shows you how to create an alarm that will sent out an alert on data loss exposure (for example).


Summary:

This lab is a great way to learn more about the Autonomous Recovery Service by going through the features in Oracle's tenancy.








Tuesday, March 24, 2026

MCP Server for Autonomous Recovery Service

Wouldn't it be nice if I could just use AI and ask my tenancy to tell me about my Autonomous Recovery Service database backups ? I want to simply ask questions like ....

Well you can and the screenshot below is just part of the answer I got. !!



Thanks to Harini Gavisiddappa who created an MCP server within the Oracle MCP server github project you can do just that.
You can find the project at https://github.com/oracle/mcp

Installing


Here is the streamlined path to getting this running on your local Windows environment.
I chose putting it on my windows environment because I love using the Claude Chat tool so I can ask questions in a UI and get nicely formatted reports/output back.


Phase 1: Repository & Environment Setup

A) Download repository onto my PC


We start by pulling the source from the [Oracle MCP repository](https://github.com/oracle/mcp/tree/main/src/oci-recovery-mcp-server).




B) Initialize a scoped Python 3.13 environment

 To keep the footprint small and the execution fast, we’ll use `uv` for our Python toolchain.


C) Install the Recovery Server in development mode


Phase 2: Identity & Access Management

Before the server can bridge to your tenancy, you need an active OCI session. This ensures the MCP server inherits your existing IAM permissions.


Phase 3: Client Integration

Phase 4: Validation

Restart your client. You should now see the oracle-recovery toolset available. You can verify the connection immediately with a simple natural language query:

Now that it is installed, let's see what it can do

**************************************************

Question 1


List the databases that are actively using the recovery service in my tenancy and include their status, how much storage they are using, where there are any issues and break it down by both compartment and tag if tags are assigned.

Total databases
8
2 compartments
Storage used
354.6 GB
all databases
Protected
4
healthy, within SLA
Alert
4
recovery window = 0
Prod_databases — 2 databases · 139.9 GB
db19vdb19v_837_iad
Alert
20.3 GB used  ·  est. 14.6 GB  ·  14-day policy
Org: HR · Prod
Recovery window 0 of 14 days — redo logs not streaming or recently enrolled
tt2srctt2src_iad1mz
Protected
119.6 GB used  ·  est. 112.9 GB  ·  14-day policy
Org: Finance · Prod
14.3d retention · redo enabled
Nonprod_databases — 6 databases · 214.7 GB
db23cdb23c_npb_iad
Alert
3.0 GB used  ·  est. 9.1 GB  ·  14-day policy
Org: Finance · Pre-prod
⚠ Unprotected window: 70.5 days — no recent backup activity. Requires immediate attention.
ORCL_TESTORCL
Alert
4.1 GB used  ·  est. 11.3 GB  ·  14-day policy
Environment: Trial
⚠ Unprotected window: 24.9 days — recovery point significantly stale.
clprotclprot
Alert
10.5 GB used  ·  est. 22.1 GB  ·  14-day policy
Fleet agent managed
Recovery window 0 of 14 days · retention = 1 sec · min recovery needed 21 days
db23aidb23ai_6rm_iad
Protected
75.6 GB used  ·  est. 68.1 GB  ·  14-day policy
Org: Finance · Dev
15.0d retention · policy locked 2023-11-16
test2test2_rjh_iad
Protected
77.2 GB used  ·  est. 74.6 GB  ·  35-day policy
Org: HR · Dev
35.8d retention · redo enabled
demodbdemodb_tfj_iad
Protected
44.4 GB used  ·  est. 42.7 GB  ·  35-day policy
No Oracle-Standard tags
35.9d retention
By tag — Oracle-Standard · Org
OrgDatabasesStorageStatus
Finance4198.2 GB
2 ok2 alert
HR297.5 GB
1 ok1 alert
Untagged359.0 GB
1 ok2 alert
By tag — Oracle-Standard · Environment
EnvironmentDatabasesStorageStatus
Prod2139.9 GB
1 ok1 alert
Dev2152.8 GB
2 ok
Pre-prod13.0 GB
1 alert
Trial14.1 GB
1 alert
Untagged254.9 GB
1 ok1 alert

**************************************************

 Question 2


List out the databases that I have and look at the usage for the last 30 days.. Based on that usage give a line chart showing my space usage by database and based on the current growth show what the project usage will be for the next year.


Question 3

Using the tags create a pie chart showing the space usage for all of my backups and show the usage for each tag.




Summary:

Above are some examples of what you can do with the new OCI Recovery Service MCP server with Claude.

Below is a list of the tools available to you to use.

Here are the 19 tools available through the Recovery Service MCP server, grouped by what they do:

Protected Databases

  • list_protected_databases — list databases enrolled in Recovery Service, with metrics and subnet details, filtered by compartment, policy, lifecycle state, etc.
  • get_protected_database — get full details for a single protected database by OCID
  • summarize_protected_database_health — count of healthy / warning / alert / unknown databases in a compartment
  • summarize_protected_database_backup_destination — how databases in a compartment are backed up (Recovery Service vs other destinations)
  • summarize_protected_database_redo_status — how many databases have redo transport on or off

Protection Policies

  • list_protection_policies — list policies in a compartment
  • get_protection_policy — get a single policy by OCID

Recovery Service Subnets

  • list_recovery_service_subnets — list subnets in a compartment
  • get_recovery_service_subnet — get a single subnet by OCID

Backups

  • list_backups — list backups with flexible filters and optional auto-paging
  • get_backup — get a single backup by OCID

Metrics

  • get_recovery_service_metrics — time-series metrics for a compartment or single database; supported metrics are SpaceUsedForRecoveryWindow, ProtectedDatabaseSize, ProtectedDatabaseHealth, and DataLossExposure; resolutions of 1m, 5m, 1h, 1d; aggregations of mean, sum, max, min, count

Storage Summaries

  • summarize_backup_space_used — total backup space in GB across databases in a compartment
  • summarize_protected_database_backup_destination — breakdown by backup destination type

DB Systems & Homes (for enrollment context)

  • list_databases — list databases across DB Homes in a compartment, with backup settings and linked protection policy
  • list_db_homes — list DB Homes in a compartment
  • get_db_home — get a single DB Home by OCID
  • list_db_systems — list DB systems in a compartment
  • get_db_system — get a single DB system by OCID



Friday, March 20, 2026

How many IP addresses do I need for the Autonomous Recovery Service

 One of the most common questions that comes up is "How many IP addresses do I need to set aside for the Autonomous Recovery Service" or "How big does the CIDR block need to be for my Recovery Service subnet"?

In this blog post, I will explain how IPs are used by the service, but how many IP address you will need is hard to put an exact number on.

First below is a diagram showing how this works.


Backup Subnet(s)

After first publishing the blog, I found that if you do use your backup subnet for backups you also need to take into account the IPs used by the ExaDB-D host itself.
The link here gives the details for ExaDB-D including the number of backup subnet IPs needed.  The requirements are the same for multi-cloud configurations.




What you will find is that each DB node requires three IP address.  
This becomes VERY important if you have multiple VM clusters using the same VCN and backup subnet.

Keep this in mind when creating the backup subnet.  You may find that when you combine the number of  IPs needed for the DB nodes with the number of IPs needed for the Recovery Service, you may need a /24 CIDR block or even a /23 CIDR block.

Recovery Service Subnet(s)

The first piece to understand is how the Autonomous Recovery Service uses the Subnet(s) that are registered.

First you might be wondering why I have the "(s)" on the end.  When you register a recovery service subnet there are two levels.

You register a name for "Recovery Service Subnet" and this is actually a group of subnets. You can register multiple subnets as eligible to be used for a "Recovery Service Subnets".



 The screenshot above is what you will see in OCI. 

When you register a Recovery Service subnet,

  • You give it a name for the "Recovery Service subnet group" 
  • You identify the VCN that this subnet is registered for. Each VCN will have it's own registered subnet group.
  • You add one or more subnet within that VCN that can be used for endpoint IP address.

Any of these registered subnets can be used for Autonomous Recovery Service IP addresses.

Also subnets can be added, and removed within the group.


How many IP addresses for a Database backup?

I am going to start with a single database before I explain what happens when you have multiple databases using the service.  In order to support Oracle Database backups, the Autonomous Recovery Service uses endpoint IP addresses that map to a pair of ZDLRAs that store the backups as a service.  The pair of ZDLRAs provide an always available service.
For a single database below is what you would see for the endpoints that get created. In my example, you can see that there are 3 IP address per RA in the "Recovery Service Group".


Above, this shows the 6 private endpoint IP addresses that are created for the database backups being sent to two ZDLRAs (RA-018 and RA-020).  There are also FQDN names that are created for each each of the endpoints and you can see that the names map to the specific ZDLRAs that are storing the backups

NOTE: There are are also some 4 node ZDLRAs in some regions. In that case there will be 4 endpoint IP address for each ZDLRA in the pair, and a total of 8 IP addresses will be utilized.

How many IP addresses do I need for multiple databases?

This is where the answer is "It depends".  The simple example above shows you what happens for a single database. When you add another database it might not end up on the same "Recovery Service group". It is possible the new database backups could end up on another "Recovery Service group" needing additional IP addresses.
There are number of factors that affect how many "Recovery Service groups" are used when backing up multiple databases.
  • Number of databases - If you have a large number of databases, this increases the chances that more backup locations will be used to spread out the backups across multiple groups.
  • Size of the Database backups - if your backups are very large, the Recovery Service tries to balance larger database backups across more groups. 
  • Number of groups in the region - Some regions contain more "recovery Service groups" than other regions.  If you are backing up in a larger region there is a higher chance that more groups will be utilized to support many databases.
The diagram I started with below shows you what happens with 3 databases that are storing their backups across two different Recovery Service groups.


The first database is sending it's backup to a Recovery Service Group containing two X 2 DB node  ZDLRAs and it is utilizing 6 IP addresses.
The second and third databases are using the same Recovery Recovery Group which consists of Two X 3 DB node ZDLRAs and they are using the same 8 IP addresses.

How to interpret this?

The recommendation for Recovery Service Subnets is to create a separate subnet that is a /24 CIDR block which will provide the ability to have 254 private endpoint IP addresses. This will allow for at least 31 different Recovery Service groups.
If you only have a few databases, then this may be too big for what you need, and you may be able to have a smaller CIDR block, or have multiple subnets with smaller CIDR blocks.
The recommendation of /24 CIDR blocks ensures you will not have any issues with enough IP address.
As you decrease the number of available IP addresses you increase the chances that you will not enough IP address to add another database to be backed up to the Autonomous Recovery Service.

What happens if I don't register enough free IPs?

Once a database is added is configured for backups, it will not affect the need for additional free IP addresses.  The only time you will have an issue with free IP addresses for the recovery service is when you add a new database to be backed up. If the onboarded process decides that the backups need to reside a new Recovery Service Group of ZDLRAs, and there are not enough free IP address you will receive an error when configuring backups. At that point you can add more subnets to the Recovery Service subnet group registered with the VCN.

Do I have to worry about space since databases are assigned to Recovery Service groups?

No.  The recovery service will automatically manage the underlying storage for the database backups and move backups from one group to another group if needed in order ensure there is enough space for backups. Because of this, you may find that the names of the ZDLRAs where the backups reside could change over time. This is one of the reasons why the service dynamically creates the TNSNAMES entry as needed. The FQDN used for backups of a database will change if the database is moved because of space constraints.

Summary

There is no set number of number of IP addresses that need to be registered with the recovery service and freely available to be assigned for backups.  It is dependent on the size of your environment, and number of IP addresses utilized could grow as your environment adds more databases to be backed up.
If you have a start with a smaller number of IP addresses, keep an eye on the number of available IP address in subnets registered with the recovery service to ensure you have room to grow.






Thursday, March 5, 2026

Recovery Service failure checks

 When using the Autonomous Recovery Service there are some prerequisites that need be met. I have a checklist that goes through these requirements, and you can find that checklist here.


This blog post will help you perform some basic debugging and demonstrate what errors you will see if you miss some of the steps.

I want to point out that Billy Zou created a create post that will help you work through issues with Cross-region restore. Billy's post has some great information to use for debugging and you can find it here.

This post is broken into two possible places where you will have issues.

  1. Unable to Submit request. This can be caused by
    • Policy issues
    • Limits issue
  2. You submitted backup, but it failed to configure the Recovery Service. This can be caused by
    • DNS issues with resolving FQDN used by Recovery Service
    • Routing/port issues accessing the Recovery Service or Object Storage

Unable to submit Autonomous Recovery Service as a backup location


Policies for the tenancy

The first step is to ensure that you have configured policies for the recovery service.  The easiest way to do this is by utilizing Policy Builder.

NOTE: There is a policy that grants access to the "ADMIN" group. If your administrator group is a different group, you would 

Visible Issue

 If policies are not configured properly, you find that "Recovery Service" is greyed out as an option.


Limits for the Recovery Service

By default if you are not in a multi-cloud environment your paid tenancy will have a limit of
  • 10 Database
  • 10 TB of backups storage
If you are using Multi-cloud, and your database is in partner cloud, there is no default limits (defaulting to 0!), which means you have to apply for a limit increase!

This is the most common issue I see with multicloud.  You need to set the limit specifically for the multi-cloud subscription.

Visible Issue

 If limits  are not configured properly, you find that "Recovery Service" is greyed out as an option.

Below the choice for "Recovery service", you will see that there is a warning, telling you that you have exceeded your limits.


Thursday, February 12, 2026

Sudden ORA-12578: TNS:wallet open failed when logging in as SYS

ORA-12578: TNS:wallet open failed when logging in as SYS

This blog post covers a possible cause of a "ORA-12578: TNS:wallet open failed" error when trying to log into your database using 

>sqlplus / as sysdba



I have seen this issue a few times with DB 19.x.  I noticed the behavior changed with AI DB 26 and is much less likely to happen.

What causes this ?

The most likely reason why you would suddenly see this error code when trying to log in using "sys as sysdba" is a change to the sqlnet.ora file.

When logging in using "sys as sysdba", the sqlnet.ora file used by your environment will be parsed as part of the authentication process.  If the sqlnet.ora in your environment has any issues during the parsing, this will cause your login using "sys as sysdba" to fail with the above error.

Fortunately, this does not happen in AI DB 26.

How to test for the sqlnet.ora being the cause

The easiest way to test is by using the TNS_ADMIN environmental variable setting.
The steps I would follow are.
  1. cd to your $ORACLE_HOME/network/admin directory on the server
  2. Execute mkdir to create a new directory named "test"
  3. cd to that new directory "test"
  4. set TNS_ADMIN with "export TNS_ADMIN=$ORACLE_HOME/network/admin/test"
  5. Try logging in using "/ as sysdba"
Since there is no sqlnet.ora file in this new directory, if you can successfully login we have proven that the issue is the sqlnet.ora file.

Now that we have proven it is the sqlnet.ora (or ruled it out sorry I couldn't help), we can look at the causes.

Finding the issue

Now that you have a new directory, $ORACLE_HOME/network//admin/test, we can start working through the possible causes.

Step 1- copy the sqlnet.ora from the default location to this new directory so that we can update it and find the issue without affecting other users. "cp ../*.ora ."

Below is my sqlnet.ora that I am showing different issues with.

# sqlnet3189722425551944721.ora Network Configuration File: /tmp/sqlnet3189722425551944721.ora
# Generated by Oracle configuration tools.

SQLNET.WALLET_OVERRIDE = true

NAMES.DIRECTORY_PATH= (TNSNAMES, ONAMES, HOSTNAME)

WALLET_LOCATION =
 (SOURCE =
 (METHOD = FILE)
 (METHOD_DATA =
 (DIRECTORY = /opt/oracle/admin/ORCLCDB/wallet1/server_seps)
 )
)


Cause 1 - Wallet file

The first possible cause is that the location of the wallet location is not correct. The same issue will most likely occur if you are setting the encryption_wallet_location in the sqlnet.ora file.

Both of these must be true when looking at the wallet file.

  1. The directory in the sqlnet.ora file MUST exist. If the directory location is incorrect, you will have an issue opening the wallet
  2. There must be a wallet file in that directory. Not only must the directory exist, but there must also be a wallet file within the directory to read.

Cause 2 - Syntax in sqlnet.ora file

When the database parses the sqlnet.ora file, it can be sensitive to any issues within the sqlnet.ora file.  Simple issues can cause parsing failures, and cause your login to fail.

Some of the most common issues are:
  1. Hidden characters in the file. This can happen when copying across platforms (windows to Linux for example). If there are any characters in the file that cause parsing to fail, your login will fail.
  2. Missing "(" or ")". This can cause parsing to fail, and your login will also fail.
  3. Starting "(" in the first column.  Unfortunately this causes a parsing failure. This can be the most annoying, and difficult to find cause. 
Below is an example of a sqlnet.ora file that fails, and you can compare to my sqlnet.ora at the beginning of this blog.


# sqlnet3189722425551944721.ora Network Configuration File: /tmp/sqlnet3189722425551944721.ora
# Generated by Oracle configuration tools.

SQLNET.WALLET_OVERRIDE = true

NAMES.DIRECTORY_PATH= (TNSNAMES, ONAMES, HOSTNAME)

WALLET_LOCATION =
 (SOURCE =
 (METHOD = FILE)
 (METHOD_DATA =
(DIRECTORY = /opt/oracle/admin/ORCLCDB/wallet/server_seps)
 )
)

Can you spot the difference ? 
...
...
It's the "(" before the word "DIRECTORY". When it is in the first column, parsing fails.


Prevention-

What I tell customers to avoid any issues like this is the following:

  • NEVER change the default sqlnet.ora for all databases. This is the copy that is stored in the $ORACLE_HOME/network/admin directory.
  • ALWAYS set the WALLET_ROOT parameter in the database. This is interpreted first by the database, and replaces the encryptioin_wallet_location in the sqlnet.ora file.
  • ALWAYS put the SEPS wallet for Real-time redo with the ZDLRA in the {WALLET_ROOT}/server_seps directory. Even if it is a symbolic link.
  • ALWAYS use TNS_ADMIN when it is necessary to customize the sqlnet.ora.  When backing up using the ZDLRA I recommend customers create a customized sqlnet.ora file and use TNS_ADMIN when executing backup/restore scripts.
This will prevent any issues with the shared sqlnet.ora that may cause unexpected issues with logging in as sys.

SUMMARY:

If you suddenly receive a ORA-12578: TNS:wallet open failed when logging in as SYS the first place to look would be your sqlnet.ora file for any parsing errors.