Tips for Managing Oracle Cloud Infrastructure Database Instances.
Now, let's explore how to set up a standby database with Data Guard, creating backups, and examining the nuances of multi-tenant (pluggable databases) and client networking. This article only covers virtual machine (VM) databases. (There are a number of differences when dealing with Bare Metal and Exadata databases that will not be covered.)
Setting up Data Guard in an on-prem environment is often a difficult and error-prone process. There are many dependencies and prerequisites that must be met, and troubleshooting errors can be challenging. OCI has simplified the process by making the setup of Data Guard a single-click feature.
Setting up Data Guard for a typical on-prem database would require setting up a second environment to host the standby database. OCI eliminates this step by making the provisioning of the second database environment part of the Data Guard setup.
Starting at the DB System Details screen in OCI for the database you have provisioned, click on Databases under the Resources header in the left pane. There should be a single database displayed on the screen. To the right of the database details, click on the three dots and select Enable Data Guard. The dialog screen will look similar to the screen that was used to provision the original database, with a few less options.
Despite the simplified process, there is no magic to set up the standby database. Oracle is setting it up the same way that an administrator would. The original VM is cloned to create the standby VM. The standard clone scripts for the clusterware and database homes are then executed on the new VM. The new database and associated clusterware resources are subsequently updated to reflect a new unique database name. Oracle uses Recovery Manager (RMAN) duplicate to do the rest of the database conversion to a standby. Finally, Data Guard Manager (DGMGRL) is used to configure and start the Data Guard replication process.
Once the Data Guard setup is complete, an orange icon will be present next to the database name in the UI, indicating that the database is protected with Data Guard. More details about the standby database can be found by clicking on the database name and selecting Data Guard Associations under the Resources header in the left pane. From this screen, you have the ability to perform a switchover to, or reinstatement from the primary database. From the standby database screen, the only option is to perform a failover.
Testing showed a switchover to take about 10 minutes from the UI. However, the actual time it took for my standby database to become the primary and open successfully was much less. The actual switchover commands are executed with DGMGRL and are logged in detail on the VM. The switchover to standby process started about 30 seconds after I clicked the UI button. The standby database became the primary and was open about 50 seconds after that. The scripts then perform a number of checks and validations before returning the status of complete back to the UI. Performing a switchover back to the original database showed similar results and timing.
Backup, Restore, and Clone
Creating database backups has also been simplified to a single click. Found in the same menu as the Data Guard setup is the option to Create Backup. The only available option in the Create Backup dialog is to provide a name. When the backup is complete, it will show up under the available backups, which can be shown by clicking on the name of the database in the UI.
Behind the scenes, the database is backed up using RMAN. The backup files can be seen in the RMAN catalog. The backup files are saved to a Swift object store. They are not saved locally on the VM. The database uses a media management library to send the files directly to the object store over sbt_tape device-type channels.
Restoring a database in OCI can be done through the UI in the database screen. Under the name of the database is a button labeled Restore. In the Restore dialog screen, you have the option of restoring to the last known good state, to a specific timestamp, or to a specific system change number (SCN). Knowing which of these to choose requires one to know a little about the state of the backups for a database. If there are no backups available, choosing any of the three options will return an error. Before shutting down the instance and going through the restore process, Oracle executes an RMAN validate using the timestamp or SCN provided in the backup dialog. While this won't protect you in every case, it will eliminate many failed recovery scenarios that could leave the database in an unhealthy state.
An alternative to restoring the existing database is to use the backup to create a database clone. On the database screen in the UI, click on the three dots next to one of the full backups and select Create Database. The options in this dialog are similar to provisioning a new VM and include the ability to choose a different VM shape than the one chosen for the original database. This is a good way to scale up the compute power or even do a RAC conversion of an existing database system.
Unlike Data Guard and backups, there are no OCI management utilities for creating and managing pluggable databases (PDBs), but there are a few things to be aware of with dealing with pluggable databases in OCI. By default, all databases created in OCI use Transparent Database Encryption (TDE). The USERS tablespace in the root and all pluggable containers are encrypted, as well as any newly created tablespaces.
When a new PDB is created, an encryption key must also be created since each PDB requires its own master key in the wallet. Following the creation of the PDB, execute the following SQL*Plus command while logged into the PDB:
administer key management set key force keystore identified by "wallet-pwd" with backup;
The client networking of OCI databases might catch a DBA off guard, especially if they are not used to using domains in their database networks. In most environments, the database unique name (DB_UNIQUE_NAME) matches the database name (DB_ NAME). In OCI, that is not the case. The unique name will be the database name appended with an underscore and six random letters and numbers. The default service name is the unique name appended with the full domain.
SERVICE_NAME: cdb_iad38n.sub10171753482.vcn10171753 48.oraclevcn.com
There are a number of ways to find the database unique name on the server, but the easiest way is to just look at the Database Details screen in the UI. The Database Unique Name can be found beneath the Database Version and Database Workload.
The PDB service names as well as any added services will also be appended with the full domain. Not including the domain with the service name will result in failed database connections from external connections, as well as connections from within the database server.
Managing Oracle databases in the cloud may require some adjustments to the way you are used to doing things, so there is likely a learning curve when adding the additional tasks discussed in this article. In the end, database services in OCI are engineered to save time and avoid problems, among other things, so it is definitely worth the investment.
The next article in this series will dive deeper by taking a look at the command-line and API tools available in OCI and how they can be used to manage and automate cloud databases.
Seth Miller, senior principal software engineer with Veritas Technologies, has been working with Oracle technologies since 2005 and specializes in database administration, and solutions integration. He currently serves as the director of communications for the IOUG.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||DATABASE TRENDS AND APPLICATIONS|
|Publication:||Database Trends & Applications|
|Date:||Jun 1, 2019|
|Previous Article:||DBAs Keep Asking: "Will I Have a Job in the Long-Term?".|
|Next Article:||Cool Security Features We Still Don't Have.|