Import/Deport - Veritas Volume Manager

This is a discussion on Import/Deport - Veritas Volume Manager ; Hi gang.... Using IBM's flash copy software to clone production db to a reporting db. These two db's reside on the same machine, which results in a problem......production db is mounted on sourcedg disk group, and reporting db is mounted ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Import/Deport

  1. Import/Deport


    Hi gang....

    Using IBM's flash copy software to clone production db to a reporting db.
    These two db's reside on the same machine, which results in a problem......production
    db is mounted on sourcedg disk group, and reporting db is mounted in destdg
    disk group. So what we need to do is this: export sourcedg and import it
    as destdg, but then reimport sourcedg in its original location. The first
    part works fine with the vxdg export sourcedg and then renaming it on the
    import to destdg. However, on the import, it complains that the diskgroup
    exists already, and we can only swap the 2 disk groups.

    Thoughts, suggestions and solutions appreciated.

    Adam


  2. Re: Import/Deport


    "Adam Weiner" wrote:
    >
    >Hi gang....
    >
    >Using IBM's flash copy software to clone production db to a reporting db.
    >These two db's reside on the same machine, which results in a problem......production
    >db is mounted on sourcedg disk group, and reporting db is mounted in destdg
    >disk group. So what we need to do is this: export sourcedg and import it
    >as destdg, but then reimport sourcedg in its original location. The first
    >part works fine with the vxdg export sourcedg and then renaming it on the
    >import to destdg. However, on the import, it complains that the diskgroup
    >exists already, and we can only swap the 2 disk groups.
    >
    >Thoughts, suggestions and solutions appreciated.
    >
    >Adam
    >

    Hello Adam,

    When you deport a disk group it does not actually
    remove the disk group. It only disables the use of
    the disk group by the system. Each disk group has
    a unique id. Use vxdg list to see this. VM does not
    allow two dgs of the same name on a system. This is why
    you cannot import the exported dg sourcedg as destdg.

    You will only be able to import it as destdg if you
    destroy the old destdg disk group. Which is probably
    what you mean by swap the disk groups.

    Cheers
    Lucas

  3. Re: Import/Deport

    Lucas Bunyan wrote:

    > "Adam Weiner" wrote:
    > >
    > >Hi gang....
    > >
    > >Using IBM's flash copy software to clone production db to a reporting db.
    > >These two db's reside on the same machine, which results in a problem......production
    > >db is mounted on sourcedg disk group, and reporting db is mounted in destdg
    > >disk group. So what we need to do is this: export sourcedg and import it
    > >as destdg, but then reimport sourcedg in its original location. The first
    > >part works fine with the vxdg export sourcedg and then renaming it on the
    > >import to destdg. However, on the import, it complains that the diskgroup
    > >exists already, and we can only swap the 2 disk groups.
    > >
    > >Thoughts, suggestions and solutions appreciated.
    > >
    > >Adam
    > >

    > Hello Adam,
    >
    > When you deport a disk group it does not actually
    > remove the disk group. It only disables the use of
    > the disk group by the system. Each disk group has
    > a unique id. Use vxdg list to see this. VM does not
    > allow two dgs of the same name on a system. This is why
    > you cannot import the exported dg sourcedg as destdg.
    >
    > You will only be able to import it as destdg if you
    > destroy the old destdg disk group. Which is probably
    > what you mean by swap the disk groups.
    >
    > Cheers
    > Lucas


    Hi,

    What you can do is:
    You can deport the two disk groups and then import sourcedg with the temporary name of
    destdg. You don't have to destroy any diskgroups to do this operation.
    But, what is it you want to achieve with your idea above ?

    All disk groups have to be imported with unique names, hence you can not have two disk
    groups with the name destdg imported at the same time.
    VM can handle disk groups with the same name; you can temporarily import a rootdg from a
    different host to for example repairing a failed root. This is because the disk group id
    (dgid) is unique an all disk groups. Instead of using the dgname during the import you
    will use the dgid.

    Regards,
    Peter


  4. Re: Import/Deport


    Peter Sevborn - Dimension AB wrote:
    >
    >Lucas Bunyan wrote:
    >
    >> "Adam Weiner" wrote:
    >> >
    >> >Hi gang....
    >> >
    >> >Using IBM's flash copy software to clone production db to a reporting

    db.
    >> >These two db's reside on the same machine, which results in a problem......production
    >> >db is mounted on sourcedg disk group, and reporting db is mounted in

    destdg
    >> >disk group. So what we need to do is this: export sourcedg and import

    it
    >> >as destdg, but then reimport sourcedg in its original location. The first
    >> >part works fine with the vxdg export sourcedg and then renaming it on

    the
    >> >import to destdg. However, on the import, it complains that the diskgroup
    >> >exists already, and we can only swap the 2 disk groups.
    >> >
    >> >Thoughts, suggestions and solutions appreciated.
    >> >
    >> >Adam
    >> >

    >> Hello Adam,
    >>
    >> When you deport a disk group it does not actually
    >> remove the disk group. It only disables the use of
    >> the disk group by the system. Each disk group has
    >> a unique id. Use vxdg list to see this. VM does not
    >> allow two dgs of the same name on a system. This is why
    >> you cannot import the exported dg sourcedg as destdg.
    >>
    >> You will only be able to import it as destdg if you
    >> destroy the old destdg disk group. Which is probably
    >> what you mean by swap the disk groups.
    >>
    >> Cheers
    >> Lucas

    >
    >Hi,
    >
    >What you can do is:
    >You can deport the two disk groups and then import sourcedg with the temporary

    name
    >of
    >destdg. You don't have to destroy any diskgroups to do this operation.
    >But, what is it you want to achieve with your idea above ?
    >
    >All disk groups have to be imported with unique names, hence you can not

    have two disk
    >groups with the name destdg imported at the same time.
    >VM can handle disk groups with the same name; you can temporarily import

    a rootdg from
    >a
    >different host to for example repairing a failed root. This is because the

    disk group
    >id
    >(dgid) is unique an all disk groups. Instead of using the dgname during

    the import you
    >will use the dgid.
    >
    >Regards,
    >Peter
    >
    >Content-Description: Card for Peter Sevborn - Dimension AB
    >
    >begin:vcard
    >n:Sevborn;Peter
    >tel;cell:+46 709 310112
    >tel;fax:+46 46 2882125
    >tel;work:+46 46 2882112
    >x-mozilla-html:FALSE
    >url:www.dimension.se
    >org:

    ;
    Dimension
    >Makes IT run

    >adr:;;Företagsvägen 28;Lund;;227 61;Sweden
    >version:2.1
    >email;interneteters@syd.dimension.se
    >title:Systems Engineer
    >x-mozilla-cpt:;0
    >fn:Peter Sevborn
    >end:vcard
    >
    >

    Although not supported, here is a solution:

    To setup for the Flash Copy, two LUNs are created in the same LSS. In the
    ESS Copy Services panels, a relationship is defined that links these two
    disks, one as the source, the other as the target. Then, both the source
    and target volumes are attached to the same system and logically acquired
    by Veritas. They each have their own disk name, Solaris identity, and Veritas
    identity.

    Next we execute the Flash Copy task to create the copy relationship between
    the two drives.

    At this point we have two exact copies of data at the block level on both
    of the disks. We know disk1 is mounted on the HOST and is functioning normally.
    The objective is to mount disk2 on the HOST and perform backup.


    What we are starting with is two disks:
    Disk1 The original disk on the server
    Disk2 The new disk copied by flash copy on the server

    Disk1 is currently mounted (available) in Veritas.

    Disk2 cannot be directly mounted on the server because the server can already
    see disk1 and disk2 has an exact copy of the Veritas volume manager information
    in its disk header. Since disk1 is already functional, mounting disk2 would
    result in address space collision between volume manager information for
    disk1 and disk2.

    The objective here is to be able to manipulate the volume manager information
    on disk2 and mount it on the server as a different disk group on different
    mount points.

    As disk2 is an exact copy of disk1, and disk1 has a Veritas state of imported,
    disk2 will also have the same state (i.e. 'imported').


    We will have to first clear the processor lock on the disk group.
    vxdisk clearimport 'devicename'
    (where devicename is something like c0t0d0)
    vxprivutil set /dev/dsk/device dgname=
    vxprivutil set /dev/dsk/device dgid=


    Once that is done, the next step is to initialize a new disk group.
    vxdg -o override init 'newdg' 'diskname'='devicename'


    We know disk1 and disk2 are identical, so lets make a copy of the disk group
    information from disk1.
    vxprint -g 'diskgroup_on_disk1' -mQq > diskgroup.sav


    The next step is to export the copy of the disk group information from disk1
    to another file.
    vxprint -D - -mhv < diskgroup.sav > 'newdiskgroup.sav'


    Now, make a 'newdg' disk group using the 'newdiskgroup.sav' template.
    vxmake -g 'newdg' -d 'newdiskgroup.sav'


    Look at the disk group information.
    vxprint -ht


    Recover the disk groups
    vxrecover -s
    vxprint -ht
    vxrecover -g 'newdg' -s 'new_volume_name'


    At this point the 'newdg' has been created with the new volume names.

    Run fsck on the 'new volume name' (the dirty bit doesnt get turned off, so
    we have to fsck it).
    fsck /dev/vx/rdsk/'newdg'/'new_volume_name'

    Now, mount the volume..!
    mount /dev/vx/dsk/'newdg'/'new_volume_name' /new_mount_point


    Now we have a second copy mounted on the same system.
    We can now start backup using the instant copy disk mounts.



+ Reply to Thread