Oracle® Cloud

Known Issues for Oracle Database Cloud Service

E56337-36

October 2017

Supported Browsers

Oracle Cloud supports the following the minimum requirements for web browsers.

Web Browser Version

Microsoft Internet Explorer

9 or 10

Notes:

  • Set Browser Mode to IE9 or IE10

  • Set Document Mode to IE9 or IE10 standards

Google Chrome

29 and later

Mozilla Firefox

24 and later

Apple Safari

6

Known Issues

This section describes known issues associated with this release of Oracle Database Cloud Service.

Topics

Subset of actions are allowed with the Oracle Compute Cloud Service

When using Oracle Database Cloud Service, only limited use of the underlying Oracle Compute Cloud Service is supported.

The Compute Cloud Service Console can be used in the following ways:

  • Using the Instance tile on the Overview page to view details about instances (virtual machines) and assign instances to network groups.

  • Using the tiles on the Network page to manage network access to instances.

  • Using the Security page to manage SSH keys

The Compute Cloud Service command line utilities cannot be used.

The Compute Cloud Service REST API cannot be used.

After Applying Aug 2017 12.2 RU, attempts to log into DBaaS Monitor fail

After applying the August 2017 RU (release update) patch to a database deployment hosting Oracle Database Release 12.2, attempts to log into DBaaS Monitor may fail with an error.

Solution

To resolve this issue, you restart ORDS (Oracle REST Data Services):

  1. Connect as the opc user to the compute node.

    For detailed instructions, see Connecting to a Compute Node Through Secure Shell (SSH) in Using Oracle Database Cloud Service.

  2. Start a root-user command shell:

    $ sudo -s
    #
  3. Restart ORDS:

    # /etc/init.d/ords restart
    INFO: Stopping Oracle REST Data Services...
    INFO: Oracle REST Data Services stopped
    INFO: Starting Oracle REST Data Services...
    INFO: Oracle REST Data Services started with PID number
  4. Exit the root-user command shell and disconnect from the compute node:

    # exit
    $ exit

Cannot use the console to update the credentials for backups to OCI Object Storage buckets

Only Oracle Cloud Infrastructure This topic applies only to Oracle Cloud Infrastructure.

You cannot use the Oracle Database Cloud Service console to update the credentials (user name or password) for cloud backups to an Oracle Cloud Infrastructure Object Storage bucket. This is a known limitation of the console as of release 17.3.5.

Solution

To update the credentials:

  1. Follow Steps 7 through 15 of the procedure Changing the Backup Configuration on Database Deployments Hosting Single-Instance Databases in Using Oracle Database Cloud Service.

  2. Edit the /var/opt/oracle/creg/SID.ini file, changing the label of the oss_user entry to bkup_oss_user.

Cannot use the console to update the password for cloud backups if it contains special characters

You cannot use the Oracle Database Cloud Service console to update the password for backups to cloud storage if the new password contains special characters like $, &, >, ) and other punctuation. This is a known limitation of the console as of release 17.3.5.

Solution

To update the password:

  1. Follow Steps 7 through 15 of the procedure Changing the Backup Configuration on Database Deployments Hosting Single-Instance Databases in Using Oracle Database Cloud Service.

  2. Edit the /var/opt/oracle/creg/SID.ini file, changing the label of the oss_user entry to bkup_oss_user.

Cannot specify IP reservations when creating a deployment hosting Database Clustering with RAC

When you create a database deployment and choose the Database Clustering with RAC database type, you cannot specify IP reservations for the two compute nodes. Doing so will cause the deployment creation to fail.

This failure is currently a known limitation of Oracle Database Cloud Service, as of release 17.3.5.

raccli update rdk command may change parameter values in the patching_properties file

The raccli update rdk command updates the cloud tooling on Oracle Database Cloud Service database deployments that use Oracle Real Application Clusters (RAC). Running this command on Oracle Cloud Machine may erroneously change the source patching container values from internal OSS values to public OSS values in the patching_properties file. This will cause an error the next time you run a patching command.

Solution

After running the raccli update rdk command on Oracle Cloud Machine, examine the patching_properties file and correct any erroneously modified values.

Here are the steps:

  1. Connect as the opc user to the compute node.

    For detailed instructions, see Connecting to a Compute Node Through Secure Shell (SSH) in Using Oracle Database Cloud Service.

  2. Start a root-user shell:

    $ sudo -s
    #
  3. Open the following file:

    /opt/oracle/dcs/rdbaas/config/patching_properties
    
  4. Examine the values for the URI and CONTAINER parameters to determine if they have been changed to public OSS values.

    • If the URI value contains the host name storage.us2.oraclecloud.com, then it has been changed to a public OSS value.

    • If the CONTAINER value is rdbaas_patches, then it has been changed to a public OSS value.

    The following are examples of public OSS values:

    URI=https://storage.us2.oraclecloud.com/v1/rdbaascs-usoracle6789 
    CONTAINER=rdbaas_patches 
  5. If the URI and CONTAINER parameters have been changed to public OSS values, then edit the patching_properties file and substitute your internal OSS values.

    • Change the URI value to your internal OSS URI.

    • Change the CONTAINER value to racdbaas_patching.

Console does not display backups and may not permit new backups after switchover or failover

After performing a switchover or failover operation on a database deployment of type “Database Clustering with RAC and Data Guard Standby”, the Oracle Database Cloud Service console does not display backups taken before or after the operation. This situation persists even after you have manually enabled backups on the new primary database.

Additionally, if you attempt to use the console to create a backup before you manually enable backups on the new primary database, the attempt fails and the Backup Now button becomes unavailable.

These are known limitations of the Oracle Database Cloud Service console, as of release 17.3.1.

Manual backup configuration required after switchover or failover on Oracle RAC plus Data Guard deployments

After performing a switchover or failover operation on a database deployment that uses both Oracle RAC and Oracle Data Guard, you must manually disable backups on the old primary database and manually enable them on the new primary database.

  1. Connect as the opc user to the first compute node of the old primary database.

    For detailed instructions, see Connecting to a Compute Node Through Secure Shell (SSH) in Using Oracle Database Cloud Service.

  2. Display the current backup configuration:

    $ raccli list backupconfig
  3. Note down the values of the following settings:

    • diskEnabled

    • ossEnabled

    • cloudStorageUser

    • cloudStorageContainerUrl

  4. Disable backups of the old primary database:

    $ raccli update backupconfig -params '{"diskEnabled":false,"ossEnabled":false}'
  5. Disconnect from the first compute node of the old primary database:

    $ exit
  6. Connect as the opc user to the first compute node of the new primary database.

  7. Enable backups of the new primary database using information you noted down from the old primary database.

    (In the following command, line breaks have been added for clarity. Do not include them when entering the command.)

    $ raccli update backupconfig -params '{
    "diskEnabled":saved-value,
    "ossEnabled":saved-value,
    "cloudStorageUser":"saved-value",
    "cloudStoragePwd":"storage-user-password",
    "cloudStorageContainerUrl":"saved-value"
    }'

    where saved-value are the values you noted down from the old primary database, and storage-user-password is the password of the cloudStorageUser user.

  8. Disconnect from the first compute node of the new primary database:

    $ exit

DEMOS PDB is not plugged-in in Oracle Database 12c Release 2

When you create a database deployment, you can optionally create the DEMOS pluggable database (PDB). In database deployments created using Oracle Database 12c Release 2, DEMOS PDB is not plugged in after you create the database deployment. The DEMOS PDB cannot be successfully plugged in due to the fact that it includes APEX.

Do not select Include "Demos" PDB when creating a database deployment using Oracle Database 12c Release 2.

This is a known limitation of Oracle Database Cloud Service , as of release 17.3.1.

Deleting a deployment and its backups can fail due to a timeout

When you delete a database deployment and specify the option to delete the backups associated with the database deployment, the delete operation will fail due to a timeout if the operation takes more than four hours.

To avoid this failure, delete the database deployment and then delete its backups.

Application Express 5.0.0 and 5.0.4 not available after creating or replacing a Release 12c database using a cloud backup

Beginning with release 17.2.5 in early June 2017, database deployments you create include Oracle Application Express 5.1. Therefore, if you use the “instantiate from backup” technique to create a database deployment using a cloud backup or replace the database in a newly created deployment using a cloud backup, the Application Express software and configuration required by a backed up database that uses Application Express 5.0.0 or 5.0.4 are not available.

Perform the following steps to download and configure the proper version of Application Express for the database that was “instantiated from backup”.

  1. Connect as the oracle user to the database deployment’s compute node.

    For detailed instructions, see Connecting to a Compute Node Through Secure Shell (SSH) in Using Oracle Database Cloud Service.

  2. Check the version of Application Express expected by the database:

    $ sqlplus / as sysdba
      ...
    SQL> SELECT VERSION FROM DBA_REGISTRY WHERE COMP_ID = 'APEX';
    
    VERSION
    ------------------------------
    5.0.0.00.31
  3. On your computer, go to the Oracle Application Express 5.0 Archive page, http://www.oracle.com/technetwork/developer-tools/apex/downloads/apex-5-archive-2606313.html, and download the zip file for Oracle Application Express 5.0.4 or 5.0, as appropriate.

  4. Transfer the zip file to the database deployment’s computer node.

    For instructions, see Copying Files to or from a Database Cloud Service Database Deployment in Using Oracle Database Cloud Service.

  5. While still connected as the oracle user to the database deployment’s compute node, navigate to the directory when you transferred the zip file to.

  6. Unzip the zip file:

    $ unzip apex_version.zip -d /u01/app/oracle/product/apex/

    where version is the version you downloaded and transferred.

  7. Move the decompressed files to a directory corresponding to the version of Application Express:

    • For Application Express 5.0.0.00.31:

      $ mv /u01/app/oracle/product/apex/apex/ /u01/app/oracle/product/apex/5.0.0.00.31/
    • For Application Express 5.0.4.00.12:

      $ mv /u01/app/oracle/product/apex/apex/ /u01/app/oracle/product/apex/5.0.4.00.12/
  8. Disconnect from the compute node.

  9. Reconnect to the compute node as the opc user. Then, start a root-user command shell:

    $ sudo -s
    #
  10. Run the ORDS assistant to configure the version of Application Express:

    # cd /var/opt/oracle/ocde/assistants/ords
    # ./ords -out="/var/opt/oracle/ocde/res/ords.out" -ords_action="configure_apex"
  11. Exit the root-user command shell and disconnect from the compute node:

    # exit
    $ exit

Older deployments use TLS 1.0

Database deployments created before the 17.2.3 release (early May 2017) were configured with TLS (Transport Layer Security) version 1.0. If your security requirements demand you use TLS 1.2, you can upgrade such deployments to use TLS 1.2 by performing the following steps.

  1. Update the cloud tooling on the database deployment’s compute node by following the instructions in Updating the Cloud Tooling by Using the dbpatchm Subcommand in Using Oracle Database Cloud Service, but do not exit the root-user command shell or disconnect from the compute node.

  2. While still connected to the compute node, run the sslpatch.pl script:

    # perl /var/opt/oracle/misc/sslpatch.pl

    This script creates the log file /var/opt/oracle/log/misc/sslpatch/sslpatch.log.

  3. Exit the root-user command shell and disconnect from the compute node:

    # exit
    $ exit
  4. If you are upgrading a database deployment hosting a Data Guard configuration, repeat the preceding steps on the other compute node of the deployment.

Additional steps needed after applying Apr 2017 PSU to older deployments

After applying the April 2017 Patch Set Update (Apr 2017 PSU) to a database deployment created before early May 2017 (base image 17.2.3), you need to perform additional steps.

  1. Update the cloud tooling on the database deployment’s compute node to version 17.1.5.1 or later by following the instructions in Updating the Cloud Tooling by Using the dbpatchm Subcommand in Using Oracle Database Cloud Service.

  2. Connect as the opc user to the database deployment’s compute node.

    For detailed instructions, see Connecting to a Compute Node Through Secure Shell (SSH) in Using Oracle Database Cloud Service.

  3. Start a root-user command shell:

    $ sudo -s
    #
  4. Execute the following script:

    # /var/opt/oracle/patch/dst_postv28.pl
  5. Exit the root-user command shell and disconnect from the compute node:

    # exit
    $ exit

Attempts to add an SSH key to Oracle RAC deployments fail

Attempts to add an SSH key to a database deployment hosting an Oracle Real Application Clusters (RAC) database fail.

Solution

To resolve this problem, delete the authorized_keys.bkp file from every computer node of the deployment and then add the SSH key.

Here are the steps to delete the file from a single compute node.

  1. Connect as the opc user to the compute node.

    For detailed instructions, see Connecting to a Compute Node Through Secure Shell (SSH) in Using Oracle Database Cloud Service.

  2. Start a root-user command shell:

    $ sudo -s
    #
  3. Delete the authorized_keys.bkp file:

    # rm -rf /home/opc/.ssh/authorized_keys.bkp 
  4. Exit the root-user command shell and disconnect from the compute node:

    # exit
    $ exit

Additional step needed after applying Jan 2017 PSU to older deployments

After applying the January 2017 Patch Set Update (Jan 2017 PSU) to a database deployment created before early March 2017 (base image 17.1.5), you need to download and run an additional script.

This additional script applies additional DST (daylight savings time) updates.

  1. Connect as the opc user to the database deployment’s compute node.

    For detailed instructions, see Connecting to a Compute Node Through Secure Shell (SSH) in Using Oracle Database Cloud Service.

  2. Start a root-user command shell:

    $ sudo -s
    #
  3. Change to the patch directory and download the script:

    # cd /var/opt/oracle/patch 
    # wget https://storage.us2.oraclecloud.com/v1/dbcsswlibp-usoracle29538/dbaas_patch/DST/dst_postv28.pl
  4. Set the file permissions on the script to make it executable:

    # chmod +x dst_postv28.pl
  5. Execute the script:

    # ./dst_postv28.pl
  6. Exit the root-user command shell and disconnect from the compute node:

    # exit
    $ exit

Backup pieces on cloud storage not deleted during deletion of database deployment

When you delete a database deployment, you can specify the option to delete the backups associated with the database deployment. However, backups stored on cloud storage may not be completely deleted as expected.

If you are affected by this issue, then you must manually delete the backup pieces from cloud storage. See Deleting Objects for details.

Configure Backups fails to update credentials for backing up to cloud storage

Sometimes, attempts to use Configure Backups on the Backup page of the Oracle Database Cloud Service console on a Database Cloud Service database deployment hosting a single-instance database fail, reporting the error “Failed cloud storage credential reset for DBaaS service”.

Solution

To resolve this issue, update the cloud tooling on the database deployment to version 16.4.5.1 at a minimum. For instructions, see Updating the Cloud Tooling by Using the dbpatchm Subcommand in Using Oracle Database Cloud Service.

Updating the cloud tooling on a deployment hosting Oracle RAC requires manual update of the Oracle Database Cloud Backup Module

If you have used the update rdk subcommand of the raccli utility to update the cloud tooling to 16.4.5 or later on Database Cloud Service database deployments hosting Oracle Real Application Clusters (RAC), you must manually update the installer for the Oracle Database Cloud Backup Module before you use the update backupconfig subcommand.

You must perform this manual update on both RAC nodes.

Solution

Here are the steps to update the installer:

  1. Go to the Oracle Database Cloud Backup Module page on OTN:

    http://www.oracle.com/technetwork/database/availability/oracle-cloud-backup-2162729.html
  2. Select Accept License Agreement and click All Supported Platforms to download the opc_installer.zip file.

  3. Using a secure copy utility that supports key-based, passwordless authentication such as scp, copy the opc_installer.zip file into the /scratch/oss directory on the compute node.

  4. Connect as the opc user to the database deployment’s compute node.

    For detailed instructions, see Connecting to a Compute Node Through Secure Shell (SSH) in Using Oracle Database Cloud Service.

  5. Start a root-user command shell:

    $ sudo -s
    #
  6. Unzip the opc_installer.zip file into the same directory (/scratch/oss) to create the opc_installer.jar file.

  7. Exit the root-user command shell and disconnect from the compute node:

    # exit
    $ exit

Recovering an old backup causes database software and data to be out of sync

If you recover a Database Cloud Service database deployment using a backup created at a lower database software version than the deployment is running, the software and data can be out of sync. This situation can arise, for example, if you patch a database deployment and then recover using a backup created before the patch was applied.

This situation can cause other problems, such as failures if you attempt to roll back a patch.

Solution

To resolve this issue, you synchronize the software and data by manually running a script on the recovered deployment:

  1. Connect as the oracle user to the compute node.

    For detailed instructions, see Connecting to a Compute Node Through Secure Shell (SSH) in Using Oracle Database Cloud Service.

  2. Run the script:

    • For Oracle Database 12c:

      $ datapatch -verbose
    • For Oracle Database 11g:

      $ cd $OH/rdbms/admin
      $ sqlplus / as sysdba
      SQL> @@catbundle.sql psu apply
      SQL> exit;
  3. Disconnect from the compute node:

    $ exit

Cloning a snapshot fails if snapshot’s database was created or replaced using a cloud backup

Attempts to create a Database Cloud Service database deployment from a snapshot fail if the snapshot is of a database deployment whose database was created or replaced using the database from a cloud backup by using an “instantiate from backup” technique.

This failure is currently a known limitation of Oracle Database Cloud Service, as of release 16.3.5.

Configure Backups fails to update backup container password on Database Cloud Service instances hosting an Oracle RAC database

When you attempt to use Configure Backups on the Backup page of the Oracle Database Cloud Service console on a Database Cloud Service database deployment hosting an Oracle RAC database, the operation fails without notifying you of an error and the password to access the Storage Cloud Service container used for backups is not updated.

Solution

Use the raccli utility to update the password. For instructions, see Updating the Password by Using the raccli Utility in Using Oracle Database Cloud Service.

Oracle Database Cloud Service console reports failed backups of Oracle RAC deployments as successful

The Oracle Database Cloud Service console Activity page and list of backups on the Backup page show that backups of database deployments hosting an Oracle RAC database were successful even if they failed.

This issue is currently a known limitation of Oracle Database Cloud Service, as of release 16.3.5.

Cannot access EM 11g Database Control after Data Guard switchover

After performing a switchover operation on a Database Cloud Service database deployment hosting an Oracle Database 11g Data Guard configuration, attempts to connect to Enterprise Manager 11g Database Control fail with the message “Unable to connect”.

Solution

  1. Connect as the oracle user to the compute node of the new primary database.

    For detailed instructions, see Connecting to a Compute Node Through Secure Shell (SSH) in Using Oracle Database Cloud Service.

  2. Define the ORACLE_UNQNAME environment variable:

    $ export ORACLE_UNQNAME=SID

    where SID is the SID of the database.

  3. Create an emca response file that contains these lines:

    PORT=1521
    SID=ORCL
    SYS_PWD=password
    DBSNMP_PWD=password
    SYSMAN_PWD=password
    LISTENER_OH=oracle-home

    where password is the password of the SYS user and oracle-home is the path of the Oracle home directory.

  4. Change the ownership of the response file you created:

    $ chown oracle:oinstall response-file
  5. Reconfigure and stop Database Control:

    $ emca -deconfig dbcontrol db -repos drop -silent -respFile response-file
    $ emca -config dbcontrol db -repos create -silent -respFile response-file
    $ emctl stop dbconsole
  6. Check the status of emkey. When prompted, enter the password of the SYS.

    $ emctl status emkey
  7. If the check reports that emkey is not configured properly, configure it using this command:

    $ emctl config emkey -repos -sysman_pwd "password"

    where password is the password of the SYS user.

  8. Secure and start Database Control:

    $ emctl secure dbconsole -sysman_pwd "password"
    $ emctl start dbconsole
  9. Disconnect from the compute node:

    $ exit

Application Express, DBaaS Monitor and ORDS can become inaccessible

On some database deployments, Oracle Application Express, DBaaS Monitor and ORDS (Oracle REST Data Services) can become inaccessible.

If they were inaccessible after using the instantiate-from-backup technique to create 16.4.1 database deployment using a cloud backup of a 16.3.3 or 16.3.5 database deployment, see Application Express, DBaaS Monitor and ORDS inaccessible after creating a 16.4.1 database deployment using a cloud backup of a 16.3.3 or 16.3.5 database deployment.

If they were inaccessible after using the instantiate-from-backup technique to create database deployment using a cloud backup, see Application Express, DBaaS Monitor and ORDS inaccessible after creating a database deployment using a cloud backup.

For any other situation, use the following solution. Here are examples of other situations that can cause this problem:

  • After a linked-clone database deployment is created from a snapshot

  • After performing a switchover operation on a database deployment hosting an Oracle Data Guard configuration

Solution

Note:

If you are applying this solution to a database deployment hosting a Data Guard configuration, perform the following steps on both nodes; that is, on the one hosting the primary database and on the one hosting the standby database.

To resolve this issue, you restart ORDS:

  1. Connect as the opc user to the compute node.

    For detailed instructions, see Connecting to a Compute Node Through Secure Shell (SSH) in Using Oracle Database Cloud Service.

  2. Start a root-user command shell:

    $ sudo -s
    #
  3. Restart ORDS:

    # /etc/init.d/ords restart
    INFO: Stopping Oracle REST Data Services...
    INFO: Oracle REST Data Services stopped
    INFO: Starting Oracle REST Data Services...
    INFO: Oracle REST Data Services started with PID number
  4. Exit the root-user command shell and disconnect from the compute node:

    # exit
    $ exit
  5. If you are applying this solution to a database deployment hosting a Data Guard configuration, repeat the preceding steps on the other compute node of the deployment.

Application Express, DBaaS Monitor and ORDS inaccessible after creating a 16.4.1 database deployment using a cloud backup of a 16.3.3 or 16.3.5 database deployment

Oracle Application Express, DBaaS Monitor and ORDS (Oracle REST Data Services) are not accessible on Database Cloud Service 16.4.1 database deployments whose database is instantiated from a cloud backup of a Database Cloud Service 16.3.3 or 16.3.5 database deployment.

This issue arises because the instantiate-from-backup process does not correctly upgrade the version of ORDS on the new 16.4.1 database deployment. To resolve this issue, you manually upgrade ORDS to version 3.0.6.176.08.46 as described in the solution below.

Solution

Here are the steps to manually upgrade ORDS to version 3.0.6.176.08.46:

  1. Connect as the opc user to the database deployment’s compute node.

    For detailed instructions, see Connecting to a Compute Node Through Secure Shell (SSH) in Using Oracle Database Cloud Service.

  2. Start a root-user command shell:

    $ sudo -s
    #
  3. Stop the ORDS service:

    # /etc/init.d/ords stop
  4. Switch to the oracle user:

    # su - oracle
  5. Navigate to the ords installation directory and create an ords.properties file:

    $ cd /u01/app/oracle/product/ords/
    $ echo "bequeath.connect=true" > "./ords.properties"
  6. Reinstall ORDS:

    $ ../java/jdk1.8.0_74/bin/java -DuseOracleHome=true -jar ords.war setup basic --schemaOnly --parameterFile ./ords.properties --silent

    Messages during setup indicate that ORDS is being upgraded to version 3.0.6.176.08.46.

  7. Remove the ords.properties file:

    $ rm ords.properties
  8. Verify the upgrade:

    $ sqlplus / as sysdba
    ...
    SQL> SELECT VERSION FROM ORDS_METADATA.ORDS_VERSION;
    VERSION
    ------------------------------
    3.0.6.176.08.46
    SQL> exit
  9. Exit the oracle user session, navigate to the ORDS configuration assistant directory, and force a reconfiguration of ORDS:

    $ exit
    # cd /var/opt/oracle/ocde/assistants/ords/
    # ./ords -out=/var/opt/oracle/ocde/res/ords.out -ords_action=reconfigure
  10. Exit the root-user command shell and disconnect from the compute node:

    # exit
    $ exit

Application Express, DBaaS Monitor and ORDS inaccessible after creating a database deployment using a cloud backup

Oracle Application Express, DBaaS Monitor and ORDS (Oracle REST Data Services) are not accessible on some Database Cloud Service database deployments whose database is instantiated from a cloud backup created using Oracle Database Backup Cloud Service (a technique called “instantiate from backup”).

To resolve this issue, download and run a patching script, as described in the solution below.

Note that after running this patching script, Application Express may remain inaccessible and the “Open Application Express Console” link in the Oracle Database Cloud Service console will not work.

Also note that even after restoring accessibility, DBaaS Monitor may incorrectly report the database as stopped when it is in fact open.

Solution

Here are the steps to download and run patching script:

  1. Connect as the opc user to the database deployment’s compute node.

    For detailed instructions, see Connecting to a Compute Node Through Secure Shell (SSH) in Using Oracle Database Cloud Service.

  2. Start a root-user command shell:

    $ sudo -s
    #
  3. Download the patching script:

    # wget https://storage.us2.oraclecloud.com/v1/dbcsswlibp-usoracle29538/dbaas_patch/ibkp/bug-24322127.sh
  4. Set the file permissions on the script to make it executable:

    # chmod +x bug-24322127.sh
  5. Execute the patching script:

    # ./bug-24322127.sh database-password

    where database-password is the password of the SYSTEM user of the source database from which the cloud backup was made.

  6. Exit the root-user command shell and disconnect from the compute node:

    # exit
    $ exit

Standard Edition deployment reports backup failure of Archivelogs Backup

When you connect to or view backup status of a Database Cloud Service database deployment hosting a Standard Edition database, you see a backup failure message that includes the text “Cannot complete the Archivelogs Backup to Cloud Storage” and the backup log includes a reference to error KBHS-01602, “backup piece piece-name is not encrypted”.

Solution

To resolve this issue, update the cloud tooling on the database deployment. For instructions, see Updating the Cloud Tooling by Using the dbpatchm Subcommand in Using Oracle Database Cloud Service.

Creating a Java Cloud Service instance fails when a Database Cloud Service instance hosting an Oracle RAC database is specified

If you specify a Database Cloud Service instance hosting an Oracle RAC database as the database to use when creating a Java Cloud Service instance, the creation attempt fails, reporting Oracle Database error ORA-12514.

Workaround

To work around this issue, use the Server Control Utility to add a service to the database and enable the ora_p2_db_listener security rule of the Database Cloud Service instance.

  1. Connect as the opc user to node 1 of the Database Cloud Service instance.

    For detailed instructions, see Connecting to a Compute Node Through Secure Shell (SSH) in Using Oracle Database Cloud Service.

  2. Start a root-user command shell and then switch to the oracle user:

    $ sudo -s
    # su - oracle
    $
  3. Add a service to the Oracle RAC database using the Server Control Utility.

    • For Oracle Database 12c:

      $ srvctl add service -d database -s pdb.identity-domain.oraclecloud.internal \
      -pdb pdb -q FALSE -e NONE -m NONE -w 0 -z 0 -r instance1,instance2
    • For Oracle Database 11g:

      $ srvctl add service -d database -s database.identity-domain.oraclecloud.internal \
      -q FALSE -e NONE -m NONE -w 0 -z 0 -r instance1,instance2

    where:

    • database is the unique database name; for example, ORCL.

    • pdb is the name of the default PDB; for example, PDB1.

    • identity-domain is the id of the identity domain; for example, usexample1234.

    • instance1 and instance2 are the names of the two instances in the cluster; for example, ORCL1 and ORCL2.

  4. Start the newly added service:

    $ srvctl start service -d database

    where database is the unique database name.

  5. Close your connection to the compute node.

  6. Enable the ora_p2_db_listener security rule of the Database Cloud Service instance.

    For detailed instructions, see Enabling Access to a Compute Node Port in Using Oracle Database Cloud Service.

Cannot access EM 11g Database Control for a Database Cloud Service instance hosting an Oracle RAC database

Even after enabling the ora_p2_monitor_11g security rule, you cannot access Enterprise Manager 11g Database Control using the Open EM Console link in the service console for a Database Cloud Service instance hosting an Oracle RAC database.

Workaround

To work around this issue, use the Enterprise Manager Configuration Assistant to replace the existing configuration with one that refers to a new service you create using the Server Control Utility.

  1. Connect as the opc user to node 1 of the Database Cloud Service instance.

    For detailed instructions, see Connecting to a Compute Node Through Secure Shell (SSH) in Using Oracle Database Cloud Service.

  2. Start a root-user command shell and then switch to the oracle user:

    $ sudo -s
    # su - oracle
    $
  3. Remove any existing dbcontrol configuration:

    $ /u01/app/oracle/product/11.2.0.4/dbhome_1/bin/emca -deconfig dbcontrol db -repos drop -cluster

    If this command fails, it means there was no previous configuration. You can continue with these instructions despite the failure.

  4. Add a service to the Oracle RAC database using the Server Control Utility:

    $ srvctl add service -d database -s dbconsole.identity-domain.oraclecloud.internal \
    -r instance1,instance2

    where:

    • database is the unique database name; for example, orcl.

    • identity-domain is the id of the identity domain; for example, usexample1234.

    • instance1 and instance2 are the names of the two instances in the cluster; for example, orcl1 and orcl2.

  5. Start the newly added service:

    $ srvctl start service -d database -s service

    where database is the unique database name and service is the service name you provided in the srvctl add service command; for example, dbconsole.usexample1234.oraclecloud.internal.

  6. Create an emca response file to use later when configuring dbcontrol. The response file has this format:

    DB_UNIQUE_NAME=dbunique-name
    SERVICE_NAME=service-name
    PORT=1521
    LISTENER_OH=/u01/app/12.1.0.2/grid
    SYS_PWD=adminpasswd
    DBSNMP_PWD=adminpasswd
    SYSMAN_PWD=adminpasswd
    CLUSTER_NAME=cluster-name
    ASM_OH=/u01/app/12.1.0.2/grid
    ASM_SID=+ASM1
    ASM_PORT=1521
    ASM_USER_NAME=ASMSNMP
    ASM_USER_PWD=adminpasswd

    where:

    • dbunique-name is the unique database name; for example, orcl.

    • service-name is the service name you provided in the srvctl add service command; for example, dbconsole.usexample1234.oraclecloud.internal.

    • adminpasswd is the administrator password provided when the Database Cloud Service instance was created.

    • cluster-name is the name of the Database Cloud Service instance.

    Here is an example response file for a service instance named r11204 in the identity domain usexample1234, created using orcl as the database SID and Pa55_WoRd as the administrator password:

    DB_UNIQUE_NAME=orcl
    SERVICE_NAME=dbconsole.usexample1234.oraclecloud.internal
    PORT=1521
    LISTENER_OH=/u01/app/12.1.0.2/grid
    SYS_PWD=Pa55_WoRd
    DBSNMP_PWD=Pa55_WoRd
    SYSMAN_PWD=Pa55_WoRd
    CLUSTER_NAME=r11204
    ASM_OH=/u01/app/12.1.0.2/grid
    ASM_SID=+ASM1
    ASM_PORT=1521
    ASM_USER_NAME=ASMSNMP
    ASM_USER_PWD=Pa55_WoRd
  7. Configure dbcontrol using the response file you created:

    $ /u01/app/oracle/product/11.2.0.4/dbhome_1/bin/emca -config dbcontrol db \
    -repos create -cluster -silent -respFile response-file
    

    where response-file is the fully qualified name of the response file you created; for example, /tmp/emca.rsp.

  8. Propagate the configuration change to node 2 of the database:

    $ /u01/app/oracle/product/11.2.0.4/dbhome_1/bin/emca -reconfig dbcontrol \
    -silent -cluster -EM_NODE node2-name -EM_NODE_LIST node2-name \
    -DB_UNIQUE_NAME dbunique-name -SERVICE_NAME service-name 

    where:

    • node2-name is the name of node 2; for example, r112042.

    • dbunique-name is the unique database name; for example, orcl.

    • service-name is the service name you provided in the srvctl add service command; for example, dbconsole.usexample1234.oraclecloud.internal.

  9. Close your connection to the compute node.

Note:

As a security precaution, after you confirm access to Enterprise Manager 11g Database Control, you should delete the emca response file you created because it contains passwords in clear text.

Patching operation fails when database instance or virtual machine is restarted

When applying a patch to an Oracle Database Cloud Service instance, the operation fails if the database instance in manually shut down or restarted (shut down and then started up) or if the virtual machine hosting the service instance is rebooted.

Workaround

None. This failure is expected behavior. The Oracle Database Cloud Service tooling for patching service instances requires that the database instance be running throughout the patching operation. The patch tooling itself shuts down and then starts up the database instance as part of the patching operation.

After a patching failure of this sort, check the patch log file, /var/opt/oracle/log/dbpatchm/dbpatchm.log to determine when the patching operation failed:

  • If the operation failed before the config phase, you can simply reapply the patch.

  • If the operation failed during or after the config phase, you need to roll back the partially applied patch before you attempt to reapply it.

Deprecated Features/Commands

There are no deprecated features or commands in this release of Oracle Database Cloud Service.

Past Deprecations and Removals

The following features or commands have been deprecated or removed in past releases of Oracle Database Cloud Service:
  • Oracle GlassFish Server is no longer included in database deployments you create. The web server features that were provided by Oracle GlassFish Server are now provided by Oracle REST Data Services.

  • The Oracle Pluggable Database Self-Service Provisioning (PDBSS) application is no longer included in service instances you create. To create and manage pluggable databases, you can use DBaaS Monitor, as described in Administering Pluggable Databases in Using Oracle Database Cloud Service.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.


Oracle Cloud Known Issues for Oracle Database Cloud Service

E56337-36

Copyright © 2014, 2017, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.