Guidelines for Administering Database Cloud Service Database Deployments

When you create a database deployment, Oracle Database Cloud Service creates a complete environment for you, including a running Oracle database and automatic scheduled backups, all configured according to values you provided when creating the deployment. You have root privilege to the compute nodes of the deployment and you have full administrative privileges for the Oracle database.

You are responsible for administering the database deployment. To simplify your administrative duties, Database Cloud Service provides service automation tooling (also called cloud tooling) for a variety of operations like backup, recovery, patching and upgrade. This cloud tooling takes two forms:

  • The web-based Oracle Database Cloud Service console, which provides an easy-to-use graphical interface to perform database deployment lifecycle and management tasks.

  • Utilities and scripts on the compute nodes of a database deployment. The Oracle Database Cloud Service console interacts with these utilities and scripts to perform management tasks, and you can use them as well. Examples of these utilities and scripts are bkup_api, dbaascli and raccli.

These on-node utilities and scripts are configured to work optimally with the deployment as it was initially configured. When you make changes to the deployment’s configuration, you should always use the cloud tooling in favor of underlying Oracle Database utilities. In this way, the on-node tooling will remain in sync with the deployment’s configuration.

Additionally, you should follow these guidelines to ensure that your deployment continues to run smoothly and as expected.

  • Do not create additional installations of Oracle Database software.

    Each deployment comes with Oracle Database software already installed.

  • Do not create additional Oracle databases.

    Each deployment is intended to house the one Oracle database (or, in the case of Oracle Data Guard configurations, the one primary Oracle database and one standby Oracle database) created when the deployment was created.

  • Do not change fundamental characteristics of the database, such as the DB name (SID).

  • For deployments that use Oracle Data Guard, use only cloud tooling to update the password of the SYS and SYSTEM database users.

    For Data Guard configurations of two single-instance databases, use dbaascli database changepassword. For Data Guard configurations of two Oracle RAC databases, use raccli update databasepassword.

  • Apply only patches that are available through Database Cloud Service.

    Do not apply patches from any other source unless directed to by Oracle Support. This best practice applies to both database and OS patches.

  • Apply database and OS patches when they become available through Database Cloud Service.

    For information about applying database patches, see Patching Database Cloud Service; for OS patches, see Applying Linux OS Security Patches.

  • Update the cloud tooling on a deployment regularly.

    On a monthly basis you should check for and apply updates to the cloud tooling as described in Updating the Cloud Tooling on Database Cloud Service.

  • Do not disable or close access to the SSH port (port 22).

    You can open other ports and protocols. See About Network Access to Database Cloud Service for information about the available options.

  • Do not directly modify a compute node’s user or SSH settings.

    Database Cloud Service configures default OS users and Secure Shell (SSH) access settings during the creation of a deployment. Do not modify these default users and use only the features of Database Cloud Service to modify the SSH keys for these users.

  • Do not modify the default administration ports.

    Do not change the ports for Oracle Application Express, Oracle Net Listener, Enterprise Manager Database Express 18c, Enterprise Manager Database Express 12c, or Enterprise Manager 11g Database Control after the deployment is created.

  • When specifying backups to cloud storage, use a different cloud storage container or bucket for each deployment.

  • Do not manually remove files from a cloud storage container or bucket that is being used for backups.

  • Always use the cloud tooling when changing the configuration of automatic backups. In particular, for deployments on Oracle Cloud Infrastructure Classic, always use the cloud tooling to change the password used to access the cloud storage container for backups, as described in Updating the Password for Backing Up to the Storage Cloud.

  • Do not detach, change file access permissions for, or change the mount point of any storage volume that was attached to a compute node during the creation of your deployment. In particular, do not unmount or change the file access permissions of /u01 through /u05.

    For details about these volumes, see Storage Volumes and File System Layout.

  • When adding storage to a deployment configured for local backups, be sure add both FRA storage and Data storage to maintain a 1.7-to-1 ratio of FRA storage to Data storage. That is, the FRA storage size should be 1.7 times the Data storage size.

  • When adding storage to a deployment, especially on Oracle Cloud Infrastructure Classic, avoid adding small amounts (under 10GB) of storage.

    Oracle Cloud Infrastructure Classic supports 10 storage volumes attached to a compute node, of which 5 are used when the database deployment is created. Thus, you have only 5 opportunities to scale up storage.

  • When adding storage to a deployment on Oracle Cloud Infrastructure Classic, use the Oracle Database Cloud Service cloud tooling, as described in Scaling Up the Storage for a Database Deployment.

    Do not use the Oracle Cloud Infrastructure Compute Classic cloud tooling unless you are adding temporary storage to use for a specific short-term period and then remove, as described in Adding Temporary Storage to a Database Deployment.