Oracle ZFS Storage Appliance: SMU - Deprovisioning a Clone Database fails with error "Not On Storage"

Asset ID:	1-72-2390449.1
Update Date:	2018-05-11
Keywords:

Solution Type Problem Resolution Sure

Solution 2390449.1 : Oracle ZFS Storage Appliance: SMU - Deprovisioning a Clone Database fails with error "Not On Storage"

Related Items


Sun ZFS Storage 7320
 Oracle ZFS Storage Appliance Racked System ZS5-4
 Sun Storage 7210 Unified Storage System
 Oracle ZFS Storage ZS5-4
 Oracle ZFS Storage Appliance Racked System ZS5-2
 Oracle ZFS Storage Appliance Racked System ZS4-4
 Oracle ZFS Storage ZS3-BA
 Oracle ZFS Storage ZS3-2
 Sun Storage 7410 Unified Storage System
 Oracle ZFS Storage ZS3-4
 Oracle ZFS Storage ZS5-2
 Sun Storage 7310 Unified Storage System
 Sun Storage 7110 Unified Storage System

Related Categories


PLA-Support>Sun Systems>DISK>ZFS Storage>SN-DK: ZS

In this Document

Symptoms

Cause

Solution

Created from <SR 3-17308023991>

Applies to:

Oracle ZFS Storage ZS5-2 - Version All Versions to All Versions [Release All Releases]
Oracle ZFS Storage ZS5-4 - Version All Versions to All Versions [Release All Releases]
Oracle ZFS Storage Appliance Racked System ZS5-2 - Version All Versions to All Versions [Release All Releases]
Oracle ZFS Storage Appliance Racked System ZS4-4 - Version All Versions to All Versions [Release All Releases]
Oracle ZFS Storage ZS3-4 - Version All Versions to All Versions [Release All Releases]
7000 Appliance OS (Fishworks)

Symptoms

Using Snap Management Utility (SMU), trying to deprovision a clone fails with the error:

ERROR: Application Oracle Database clonedb1 is not on storage Sun ZFS Storage zfssa-server1

Cause

SMU determines the ZFSSA shares used by the database dynamically, from the running database, or statically, from the profile (name.xml).

If the database fails to start and there is no profile, SMU cannot determine the ZFSSA shares used by the database.

Solution

Recreate the profile (xml file) by using another clone's xml file.

For instance: clonedb1 fails to start and there is no clonedb1.xml file

clonedb2 is a running clone database and has a clonedb2.xml file

On a Solaris SMU host, cd /var/opt/ORCLsmu/store

On a Linux SMU host, cd /var/opt/oracle/smu/store

cp clonedb2.xml clonedb1.xml

Edit clonedb1.xml and change the database name and clone name to the names used for clonedb1 in all places that they appear.

Also in clonedb1.sml, change the smu-clone share name to match the smu-clone for clone1db.

You can determine the smu-clone share by looking in /var/opt/ORCLsmu/smu.log.0 and find the task where the clone was created and search for smu-clone for an entry like this:

PARAMS: {"share": "smu-clone-1519760949449-0","mountpoint": "/export/smu-clone-1519760949449-0"

Run deprovision to remove clonedb1.

Attachments

This solution has no attachment