Back Up and Restore: Version 21.2 and Later
In releases 21.2 and later, Oracle-scripted backups are for a single Essbase instance. This means that you can use Oracle scripts to perform backups even if you deployed multiple Essbase instances using a single Autonomous Database.
The Oracle-provided scripts support only Autonomous Database deployments (Autonomous Transaction Processing or Autonomous Data Warehouse).
Note:
If you didn't deploy with Autonomous Database, you cannot use the Oracle scripts to back up your Essbase instance. Instead, follow the same instructions provided for prior releases in Non-Oracle-Scripted Backup and Restore.- Autonomous Transaction Processing is the relational database into which Essbase schemas are deployed.
- OCI Identity and Access Management (IAM) or Oracle Identity Cloud Service (IDCS) is the security provider for the Essbase deployment.
- The Essbase system admin user name (stored in WebLogic; it is the only non-IAM or IDCS user in the system) is the same between the source and the target Essbase stacks.
- At the time of restore, the source instance backup has at least one valid IAM or IDCS user with an Essbase system administrator role.
Oracle-Scripted Backup of an Essbase Instance
The Oracle-provided scripts perform the following tasks:
- Configure your database to work with your object storage.
- Stop the Essbase services.
- Back up your database.
- Back up your Essbase data block volume.
- Start the Essbase services.
Before beginning a backup, gradually disconnect active user sessions, using MaxL alter application disable commands and/or connects (to prevent any new user activity), followed by alter system logout session and/or kill request (if you need to terminate any active sessions that don't need to complete). If you use disable commands in the application, remember to re-enable commands for that application after performing the backup.
Note:
If using a private IP, provision an Oracle Cloud Infrastructure Bastion Service instance and use it as a proxy.- Ensure that the required policies to manage backups are in place.
- ssh to your Essbase compute (as opc user).
- Switch to the oracle user.
sudo su oracle
- Change directories to
/u01/vmtools/backup/
.cd /u01/vmtools/backup/
- Run the script to configure your database to work with object storage. This is a one-time action per Essbase instance.
./configure-backup-storage.sh
After you launch the script, you are prompted for three inputs:Enter database admin password:
Type the clear text password. Because the password is protected information, you will not see the text as you type at the command prompt.
Enter OCI Username:
To find the Oracle Cloud Infrastructure username:- In Oracle Cloud
Infrastructure, go to the upper right hand corner and click the profile menu icon
.
- Click on the user.
- Copy the profile name at the top of the page.
Copy the full username including
oracleidentitycloudservice/
(not just the e-mail address). - Go back to the command prompt, paste and press Enter.
- In Oracle Cloud
Infrastructure, go to the upper right hand corner and click the profile menu icon
-
Enter OCI Token:
Enter the auth token. Because the auth token is protected information, you will not see the text you type or paste at the command prompt.
- Run the backup script,
run-backup.sh
. This script also backs up the data block volume.Note:
This backup script does NOT back up data and files in object storage if the stack catalog was configured with object storage in 21.4 or higher. You must take a backup of the data and files.You are prompted for the database admin password if the vault option is not provided. Enter the clear text password. Because the password is protected information, you will not see the text as you enter it at the command prompt.
The syntax is as follows:
./run-backup.sh [--vault | -V] [--cpu n | -C n] [--parallel n]
Example:
./run-backup.sh --vault
The script has the following options:
--vault
or-V
sets the script to take the required credentials (admin password) stored in the vault, accessed using the OCID, instead of prompting you for the password.--parallel
sets the degree of paralleling for the backup. The default is to use all available parallel processes. This parameter is supported only for stacks created in Essbase 21.4+.--cpu
or-C
also sets the degree of paralleling for the backup; this parameter is shown here only for backward compatibility.If option
--vault
or-V
is not used, you are prompted to enter the database admin (clear text) password. The protected password is not displayed as you enter it.Note:
Essbase services are stopped by thebackup.sh
script and restarted after it finishes. - Capture object storage native URI.
At the end of the backup script, there will be two "moving export file" entries. You can copy and save the first one, which contains your object storage native URI. The object storage native URI is required when you issue the Data Pump Import command during restore. You must modify the moving export file entry to replace the
.dmp
file name withessbase%u.dmp
.
Restore an Essbase Instance Using an Oracle-Scripted Backup
If you haven't done so already, install and configure Oracle Instant Client and tools. You will need to run Data Pump and SQL*Plus.
When recovering from disaster, you'll need to deploy a new target Essbase instance before you can restore a non-Oracle-scripted backup. The new target instance should be the same version that was deployed on your failed compute. After your new target instance is deployed, you can recover from backup using the target.
- Skip steps 1 through 6.
- Do not include the
REMAP_SCHEMA=<sourceEBprefix>_ESSBASE:<targetEBprefix>_ESSBASE
parameter in step 8b. - Because you are recovering on the same host from which you took your backup, the target instance referenced in the steps below will be your source instance.
Note:
If using a private IP, provision an Oracle Cloud Infrastructure Bastion Service instance and use it as a proxy.- Deploy a target Essbase stack using Oracle Marketplace.
- Use the source Oracle Identity Cloud Service confidential application.
- Use the source Autonomous Database and password. Optionally, create a new Autonomous Database. This is necessary if you are restoring in a new region.
- Use the source virtual cloud network and application subnet. Optionally, use a new network. This is necessary if you are restoring in a new region.
- If your source stack has a load balancer, do not deploy a target load balancer. You can change the backend set after deploying the target stack. Optionally, create a new load balancer. This is necessary if you are restoring in a new region.
- If your source stack has a bastion, deploy a bastion with the target stack (the source bastion can be deleted after successful recovery).
- Use the same Essbase system admin user name and password in the target as you used in the source.
- Use the same IAM or IDCS Essbase admin user in the target stack as you used in the source stack. If this is not possible, make sure the source Essbase instance has at least one valid IAM or IDCS user with the Essbase system administrator role. After you restore, you must log in to the target instance as a valid IAM or IDCS user who had Essbase system administrator role on the source instance.
- Manage the target instance log in URL:
- If you have a source load balancer, manage its 'essbase’
backend set for use with the target compute. After allowing the load
balancer time to refresh its connection to the target compute, log in to
the Essbase web interface to make sure your
target instance is deployed correctly before proceeding to restore from
backup.
- Remove the source compute backend.
- Add the target compute backend. Use port 443.
There is no need to update the IAM or IDCS confidential application URLs, as the same load balancer IP is now routing to the target Essbase instance.
- If your source stack did not have a load balancer, update your IAM or IDCS Confidential Application Redirect and Post Logout Redirect URLs with the target IP address.
- If you have a source load balancer, manage its 'essbase’
backend set for use with the target compute. After allowing the load
balancer time to refresh its connection to the target compute, log in to
the Essbase web interface to make sure your
target instance is deployed correctly before proceeding to restore from
backup.
- ssh to your target Essbase compute (as opc user).
- Switch to the oracle user.
sudo su oracle
- Change directories to
/u01/vmtools/backup/
.cd /u01/vmtools/backup/
- Run the script to configure your database to work with object storage. This is a one-time action per Essbase instance.
Execute the configure-backup script for the target.
./configure-backup-storage.sh [--vault | -V]
where --vault or -V option will pull the required credentials from the vault instead of prompting for the password. By specifying this, the script will automatically take the password / OCID secret stored in the vault. The vault is identified to the instance from the metadata.
After you launch the script, you are prompted for three inputs:Enter database admin password:
Type the clear text password. Because the password is protected information, you will not see the text as you type at the command prompt.
Enter OCI Username:
To find the Oracle Cloud Infrastructure username:- In Oracle Cloud
Infrastructure, go to the upper right hand corner and click the profile menu icon
.
- Click on the user.
- Copy the profile name at the top of the page.
Copy the full username including
oracleidentitycloudservice/
(not just the e-mail address). - Go back to the command prompt, paste and press Enter.
- In Oracle Cloud
Infrastructure, go to the upper right hand corner and click the profile menu icon
-
Enter OCI Token:
Enter the auth token. Because the auth token is protected information, you will not see the text you type or paste at the command prompt.
- Record the directory name and the credential name, which will be printed on the screen after the script has finished executing.
- Stop the target Essbase services (as oracle user). Do not stop the node manager or the Essbase compute in Oracle Cloud Infrastructure
- Restore the target database schema from source schema backup that was taken by the
backup.sh
script.When restoring the Autonomous Database for your target stack, you will import your source schema backup into the target Essbase schema using the REMAP_SCHEMA option.
- Make sure your Instant Client is configured to point to the Autonomous Database containing your target Essbase schemas.
- Using the Oracle Instant Client, issue the following Data
Pump import
command
impdp admin@<database name>_high directory=<directory name> credential=<credential name> dumpfile=<object storage native URI> REMAP_SCHEMA=<source essbase prefix>_ESSBASE:<target essbase prefix>_ESSBASE table_exists_action=replace
Notes:- The <database name> is the name of the database to which you connect to do the import.
- The <directory name> is the directory
name you recorded after running the
configure-backup-storage.sh
script. - The <credential name> is the credential
name you recorded after running the
configure-backup-storage.sh
script. - The <object storage native uri> is the
same one you captured during backup:
- The namespace (/n/) is your tenancy’s namespace.
- The bucket (/b/) is the source instance object storage bucket.
- The object (/o/) is the <backup
folder name>/<dump file name> of the source
instance object storage. The
.dmp
file name used in the impdp statement should beessbase%u.dmp
. The%u
is a wildcard that will pick up multiple.dmp
files, in case more than one is created.
- After the schema import finishes, audit your data using a database client like SQL Developer. You can look at the ESSBASE_APPLICATION table within the <targetprefix>_ESSBASE schema and see that the target schema (which was empty prior to schema import) has the source applications.
- Temporarily disable the
/etc/fstab
data block volume entry.- ssh to target compute (as opc user).
sudo vi /etc/fstab
- Insert a # in front of the
/u01/data
entry. - Save the file.
- Detach
data block volume from the target Essbase compute. Note the iSCSI caution and be sure to unmount and
disconnect the volume before detaching using the Oracle Cloud
Infrastructure console.
- To unmount:
- ssh to target compute (as opc user).
lsblk
sudo umount /u01/data
- To disconnect iSCSI:
- In the Oracle Cloud Infrastructure console, select the target compute.
- Select resources > attached block volumes.
- From the Actions menu
for the data block volume select iSCSI Commands & Information.
- Copy iSCSI commands for disconnect.
- ssh to the target compute (as opc user).
- Paste the disconnect command you copied and press enter.
- To detach:
- In the Oracle Cloud Infrastructure console, select the target compute.
- Select resources > attached block volumes.
- From the Actions menu
for the data block volume select Detach.
- To unmount:
- Restore data block volume from source data block volume backup. Be sure to select the same Availability Domain as your target compute instance.
- Attach the data volume using the following OCI CLI command (as opc user)
oci compute volume-attachment attach-iscsi-volume --instance-id $instanceid --volume-id $datavolumeid --display-name data-volume --auth instance_principal
where
instanceid
is the OCID of the compute instance anddatavolumeid
is the OCID of the data volume. The--display-name
parameter must be provided with this value. - Use the iSCSI commands listed in the OCI console to connect your newly attached target block volumes.
- Update
/etc/fstab
/u01/data entry and mount the new data block volume.- ssh to the target compute (as opc user).
lsblk
to identify the name of the newly attached config and data volumes.sudo blkid
and record the UUID of the newly attached data volume.sudo vi /etc/fstab
- Uncomment the data block volume entries.
- Replace the UUID in the existing data volume entry with the UUID of the newly
attached data volume. Be sure not to change the mount point
/u01/data
. See Traditional fstab Options. - After saving the
/etc/fstab
file, issue the following commands:sudo systemctl daemon-reload
sudo mount -a
lsblk
to verify the mount points.
- Start the Essbase services (as oracle user).
Note:
After successfully recovering into the target Essbase stack, you can delete the failed source compute node and do further cleanup to unneeded data block volumes and backups.