Conference aosg::lsm

Hi,

Have a look in volplex(8) snapstart and snapshot operation.

But, to use that feature, you first need to integrate the 9 new disks
in LSM, and then create 46 plexes with the same size/characteristic as
the existing one.

Before starting your test, you make a snapstart of each of your 46 volumes
with the 46 newly created plexes, then, when the copy is finished, you can
make a snapstart to create 46 new volume with the old data.

Then run your test, and once you need to reload your data, simply revert 
the snapstart/snapshot operation.

Regards, Manu.

Okay, we'll look into volplex snapshot. However, this brings up 
another issue.

When the customer created the LSM disk group with the original 9 
disks, they took the default of 10 for the maximun number of disks 
that will be in the disk group. Now, if I add 9 more disks for the 
volplex, the disk count will be 18, which is obviously more than 10. 
What problems will this cause? Is there a way to increase the maximun 
number of disks allowed in an existing disk group?

Thanks in advance.

/jim

Jim,

Don't worry. The default answer of 10 is only used to figure out how much
space should be given to the LSM PRIVate area on the disk. You will get 
512 sectors for the config and I think it should be enough to store about
300 records. 

With 18 disks + 2x46 sub-disks + 2x46 plexes + 46 volumes, you reach about
250 records.

If you are missing some space, then you can still decrease the default number
of configuration in ALL your disks with the command:

	# voldisk moddb nconfig=1 rzxx

and repeat it for all the disk of the diskgroup such that 

	# voldg list diskgroup

shows that you only have ONE configuration in ALL your disks.

Regards, Manu.

    Well volplex(8) snapstart and snapshot seem to work fine for making 
    the first copy. However, reversing it is not as easy. The plex copied
    to it appears must not be in a volume. Removing the original volumes
    does not work because the original volumes are drd in a TruCluster
    system. There doesn't seem to be any easy way to bring the copied
    plexes back over the original - like doing a restore from tape.
    
    Unless someone has some EASY script that guarantees that there will be
    no problems with the underlying structure that clusters needs, I guess
    I will resort to using dd - slow but it will work.
    
    /jim
    

Hello Jim,

You are right, it is not easy to reverse it.

What you can do is:

1) stop the database after the test.
2) stop every LSM volumes of the database
3) Make all plexes of these LSM volume STALE 
4) Dissociate the "backup" plexes from the snapstarted voluumes.
5) Attach them to the original volume and make them clean
6) Restart the database volumes. As the moved plexes are CLEAN and the
   other plexes are STALE, the volumes will be synchronized on the CLEAN
   plexes. But you still have to wait the end of the synchronisation before
   restarting your test to avoid impairing the performance of the test by
   the synchronisation process.

But, anyway, dd would be most likely easier to use if your are not an LSM expert.

Regards, Manu.

    Well, we have the dd scripts setup. Can can dd 36GB per system (72GB in
    total) in about 50 minutes. This is accepptable to the customer.
    
    Thanks for all the help. I will try the last response in the future.
    
    /jim