Hi John,
This is very much a "ground up" approach to splitting mirrors - there's
far easier methods for this, especially if all you're doing is
snapshotting within the same dg. Take a look at vxsnap in the admin
guide. Basically, once the snapshots have been initially synchronized,
all that's need
Hi All,
You are correct - the "failing" flag is set when there's an intermediate
failure, "failed" gets set when it's more permanent. As shown below, vxedit is
the way to turn it off. It's only a flag, more of a fyi really, and will not
affect anything else.
Regards,
James.
_
Hi Mike,
No worries, the problem relating to mmap'd files was fixed in 4.0MP2.
Regards,
James.
> -Original Message-
> From: Myers, Mike [mailto:[EMAIL PROTECTED]
> Sent: 29 June 2007 17:45
> To: James Slater; Khurram Tariq; veritas-vx@mailman.eng.auburn.edu
> Subj
Hi Mike,
This is what I was trying to allude to in my mail earlier. In the older
versions of SF it was sometimes not possible to move certain application
files due to them being memory mapped (Oracle in particular). However,
this has been fixed for the later releases of storage foundation.
Rearran
Hi Khurram,
Have you tried stopping the application yet & then running fsadm? What
version of storage foundation are you running?
Regards,
James.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Khurram
Tariq
Sent: 29 June 2007 13:01
T
Hi Sunny,
My guess is that after the pkgadd of
VRTSvxvm you haven’t rebooted before trying the encapsulation right? If
so, then the chances are the libraries are still mounted under /a so vxencap
can’t find them. When I set up jumpstart here I pkgadd’d everthing,
rebooted, then used ano
Hi,
Try running:
vxdisk list HDS9980V0_248
and check the hostid: flag - sounds like that disk could be in use by
another host. Basically, the disk has already been initialized and
incorporated into oradg either on your node or somewhere else.
Regards,
James.
> -Original Message-
> Fro
