Skip to Main Content

Infrastructure Software

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Stale State Database Replicas

807559Oct 16 2006 — edited Oct 18 2006
Hi,

I have a mirror setup between c1t2d0s0 and c1t3d0s0 as d30. Submirror has come up as being unavailable and the metadb on this slice was in an "unknown" state, with a metastat giving me a "Stale state database replicas" warning. I removed the stale metadb's using metadb -d and recreated them, but the disk c1t2d0s0 (submirror 0) is still unavailable. The production file system is currently mounted to the disk device/not to the mirror.

Any suggestions to fix the "unavailable" disk? Could i just remove the mirror and re-create it without loosing data on the mounted disk /dev/dsk/c1t3d0s0?

See output below:
-----------------------

# metastat
****
WARNING: Stale state database replicas. Metastat output may be inaccurate.
****

d30: Mirror
Submirror 0: d10
State: Unavailable
Submirror 1: d20
State: Okay
Pass: 1
Read option: roundrobin (default)
Write option: parallel (default)
Size: 143237376 blocks (68 GB)

d10: Submirror of d30
State: Unavailable
Size: 143237376 blocks (68 GB)
Stripe 0:
Device Start Block Dbase State Reloc Hot Spare
c1t2d0s0 0 No - Yes


d20: Submirror of d30
State: Okay
Size: 143237376 blocks (68 GB)
Stripe 0:
Device Start Block Dbase State Reloc Hot Spare
c1t3d0s0 0 No Okay Yes


hsp001: is empty

Device Relocation Information:
Device Reloc Device ID
c1t3d0 Yes id1,sd@SSEAGATE_ST373307LSUN72G_3HZ9AA1N000075123ZGF
# metadb -i
flags first blk block count
a u 16 8192 /dev/dsk/c1t2d0s7
a u 8208 8192 /dev/dsk/c1t2d0s7
a u 16 8192 /dev/dsk/c1t3d0s7
a u 8208 8192 /dev/dsk/c1t3d0s7
r - replica does not have device relocation information
o - replica active prior to last mddb configuration change
u - replica is up to date
l - locator for this replica was read successfully
c - replica's location was in /etc/lvm/mddb.cf
p - replica's location was patched in kernel
m - replica is master, this is replica selected as input
W - replica has device write errors
a - replica is active, commits are occurring to this replica
M - replica had problem with master blocks
D - replica had problem with data blocks
F - replica had format problems
S - replica is too small to hold current data base
R - replica had device read errors
Comments
Locked Post
New comments cannot be posted to this locked post.
Post Details
Locked on Nov 15 2006
Added on Oct 16 2006
8 comments
2,011 views