Typically the "No valid disks found contian disk group" error is presented when one or more of the disks that were originally part of the disk group are not found.  The "no valid disks" part of the error is kind of a misnomer.

You can do the following to investigate/confirm this:

List of visible disks reporting disk group membership:
# vxdisk -o alldgs list | grep <diskgroup_name>

Count of those disks:
# vxdisk -o alldgs list | grep <diskgroup_name> | wc -l

EG:
# vxdisk -o alldgs list | grep testdg
Disk_6          auto:cdsdisk    -            (testdg)     online
Disk_7          auto:cdsdisk    -            (testdg)     online
Disk_8          auto:cdsdisk    -            (testdg)     online

# vxdisk -o alldgs list | grep testdg | wc -l
3

Next you need to determine how many disks the disk group configuration says should be present.  To do this you need to identify a disk in the disk group with a configuration copy on it.  Start looking at the "vxdisk list <device>" output for those disks until you identify the following:

Defined regions:
 config   priv 000048-000239[000192]: copy=01 offset=000000 enabled
 config   priv 000256-051423[051168]: copy=01 offset=000192 enabled
 log      priv 051424-055519[004096]: copy=01 offset=000000 enabled
 lockrgn  priv 055520-055663[000144]: part=00 offset=000000

If the config lines say "enabled" then take a note of the "private" slice for that disk:

# vxdisk list Disk_6 | egrep "^private"
private:   slice=3 offset=256 len=65536 disk_offset=0

Next check the following:

# /etc/vx/diag.d/vxprivutil dumpconfig /dev/vx/rdmp/<device>s# | egrep "^dm"
(List of disk records in the disk group)

# /etc/vx/diag.d/vxprivutil dumpconfig /dev/vx/rdmp/<device>s# | egrep "^dm" | wc -l
(Count of those disk records)

EG:
# /etc/vx/diag.d/vxprivutil dumpconfig /dev/vx/rdmp/Disk_6s3 | egrep "^dm"
dm   disk01
dm   disk02
dm   disk03
dm   disk04
 
# /etc/vx/diag.d/vxprivutil dumpconfig /dev/vx/rdmp/Disk_6s3 | egrep "^dm" | wc -l
4

Next compare the value from the vxprivutil command line count and the vxdisk -o alldgs list count.  As you can see in the above example, the disk group is expecting to find 4 disks, but only 3 disks are attached to the system.

You can attempt to force disk group import as well:

# vxdg -f import <diskgroup>

Afterwards perform a "vxdisk list" and not any failed or missing device statements.

Other possibility here is, the disk names got changed...

for e.g if initially a disk was called Disk_0 in vxdisk list, it is now called Disk_1

This order may change depending on how OS builds its device tree... In this scenario you may need to match the diskids from old outputs under /etc/vx/cbr/bk

Gaurav

For Solaris/Sparc platform, the dgdebug tool (http://support.veritas.com/docs/331485) will be very helpful to identify the cause of import failure.

Hopefully springman managed to import his dg by now...? (it's been 6 weeks!)
Maybe he could give us feedback and let us know if any of the advice was useful.

We have a system which multiple power failure in last 18 months. One of the oracle backup file system,which has it's own disk group, failed to mount in last a few power interruption. Furthe check, the disk group record in the /etc/vx/cbr/* directory hasn't been updated.  Recreate the diskgroup/volume today, then; deport and import the disk. The deport/import work OK. I am expect to see new record regarding the disk since export and import action took place. But it is not in /etc/vx/cbr/*.  For the record, this server boot up without a lot of the default system processes running[like the script in rc2.d and rc3.d haven't been run]. I start them with for loop manually, but did not trouble shoot further. Without the cbr on the newly recreated disk group on the system, I suspect the system won't able to recognize the disk group again after another power interrupted crash.

How can I forcefully create a cbr record for this disk group named orabkup?

Dean