KBHS-00600: Internal Error, Arguments [1] [kbhshtCreateDataBucket] Error During Backup To Oracle Cloud

When setting up Oracle Cloud Backup Service for first time and the Oracle Database Cloud Backup Module has been installed successfully using:
Installing the Oracle Database Cloud Backup Module

Your RMAN session will hang and eventually give the following error:

Starting backup at 2017/08/10 12:56:58 
current log archived 
RMAN-00571: =========================================================== 
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 
RMAN-00571: =========================================================== 
RMAN-03002: failure of backup plus archivelog command at 08/10/2017 16:20:05 
ORA-19554: error allocating device, device type: SBT_TAPE, device name: 
ORA-27023: skgfqsbi: media manager protocol error 
ORA-19511: non RMAN, but media manager or vendor specific failure, error text: 
KBHS-00600: internal error, arguments [1] [kbhshtCreateDataBucket] [] [] []

If the replication policy has not been set for this account, as explained in the MOS Note:
KBHS-00600: Internal Error, Arguments [1] [kbhshtCreateDataBucket] Error During Backup To Cloud (Doc ID 2232778.1)

Details of the replication policy can be found in the following documentation:
Selecting a Replication Policy for Your Service Instance

β€œPolicies that have no georeplication:

These policies specify only the primary data center (DC) that hosts your service instance.

All read and write requests go to the primary DC, always. If the primary DC is unavailable, then the requests fail.

 Such a policy may be adequate if you have standard data-durability requirements and if an occasional failure of read requests (when the primary DC is down) is acceptable.

The Georeplication policies:

These policies specify a primary DC that hosts your service instance as well as a geographically distant, georeplication DC.

Write requests that you send to the global namespace URL are routed to the primary DC. Data that you write is replicated automatically, but asynchronously, to the georeplication DC. The primary and secondary DCs are eventually consistent.

 If the primary DC is unavailable, then write requests fail with the 403 – Forbidden error, but read requests are routed to the georeplication DC. When the primary DC is available again, requests to the global namespace URL are routed to the primary DC.

 You’ll be billed for the sum of the capacities used in both DCs and for the data transfer from the primary to the georeplication DC.

 A policy that has a georeplication DC is ideal if you have advanced durability requirements for your data or if read requests must succeed always regardless of the state of the primary DC.”

The first option, there’s a possibility of not being able to reach your backups but has the benefit of 1:1 ratio on storage used.   The second option has the benefit of guarantees being able to reach your backups but double storage usage and you are charged for data transfer between DC.

Once you select your georeplication policy, your backup will work πŸ™‚

If you found this blog post useful, please like as well as follow me through my various Social Media avenues available on the sidebar and/or subscribe to this oracle blog via WordPress/e-mail.


Zed DBA (Zahid Anwar)