Oracle: Failed to create Cloud Base DB Service DB-System with RU 19.32.

Issue

I recently had to create a 19c Oracle Database on the Base Database Service on Oracle@Azure. Creating the DB-System failed with the following error:

Launch DbSystem failed. 
Reason : 
DCS-10001:Internal error encountered: 
Failed to download the fast clone.DcsException{errorHttpCode=InternalError,
msg=Failed to verify the checksum of file /opt/oracle/oak/pkgrepos/orapkgs/clones/oci_nid_19300_EE_AL32UTF8.tar.gz ,
msgId=11031,
causedB. Refer to WorkRequestId 5e4...c4d when opening a Service Request at My Oracle Support.

We didn’t see that issue before Database Release Update 19.32. A first test on native Oracle Cloud Infrastructure (OCI) to create a Base DB Service DB-system was successful. However further tests showed that shape “VM.StandardDB.x86” or “VM.BaseDB.x86” resulted in the same error whereas shape “AMD” resulted in a successful deployment of the DB-system on OCI. Trying to deploy on Oracle@Azure always failed, because the only shapes to chose from are “VM.StandardDB.x86” and “VM.BaseDB.x86”.

I opened a Service Request (SR) with the Oracle Multicloud team and requested escalation as we were stuck. After it was clear that the issue could be reproduced on native OCI, a 2nd SR was opened with the OCI team. I wanted the severity 2 SR to be escalated and requested that in a “manager engagement request”. The next update in the SR was this:

“Duty Manager update: escalating SR, will increase severity to sev1”

So with Cloud SRs either there’s no possibility anymore to “escalate” a sev2 SR, or the manager concluded that my issue has an impact on all customers trying to deploy a Base DB Service and decided to raise the issue to sev1.

The Support engineer involved an internal OPS-team which responded that they applied an internal fix and I should re-deploy my DB-system. It still failed and after another cycle the OPS-team responded that I should try again as they had to reload the zip-files. Afterwards we were able to deploy the DB-system successfully with a 19.32-database.

When looking into the documentation about the difference between the shapes VM.BaseDB.x86, VM.Standard.x86, Ampere VM.Standard.A1.Flex, AMD VM.Standard.E5.Flex, AMD VM.Standard.E4.Flex and Intel X9 VM.Standard3.Flex it can be seen that the shapes VM.BaseDB.x86 and VM.Standard.x86 are more independent of the features of a processor generation (generation-agnostic) whereas the AMD, Ampere and Intel shapes enable features of its processor generation. In addition the VM.BaseDB.x86 and VM.Standard.x86 let you customize the ECPUs (Elastic Compute Processing Unit = approx 25% of a CPU Core) allocated to a system whereas the other shapes are customizable on OCPUs (Oracle Compute Processing Unit = CPU Core) only. I.e. with ECPUs Oracle tries to provide a hardware independent CPU resource so that Oracle can replace the underlying hardware by e.g. going to the next Exadata generation without asking a customer to chose a different shape.

Summary

The case was interesting, because

• a new Database Release Update may cause the deployment of a Cloud DB-system to fail.
• Oracle is going in the direction of processor generation independent CPU resources on the Cloud. I.e. I could think of having ECPUs based on an AMD-processor today for my DB-system or Autonomous DB, an Intel processor tomorrow and in the future run my Database-system on a next x86-64 compatible processor architecture. Oracle may just replace the underlying Exadata with the next generation.
• doing a “manager engagement request” can give the Cloud SR a real push.
• trying to escalate a severity 2 Cloud SR may cause it to be raised to severity 1.
• the engineer working on the SR and a manager called me and asked if I can provide feedback and fill in the survey about the case. It feels to me that Oracle Cloud Support engineers are under pressure and need good feedback from customers as they fear to be replaced by an AI service.