Unsolved
This post is more than 5 years old
2 Intern
•
385 Posts
0
1041
April 3rd, 2008 05:00
Migrate DB2 on AIX server to new DMX
Without getting into too many details - we are in the position of wanting to migrate a relatively large (1.9TB) AIX server running DB2 to a DMX-4 with larger LUN sizes. Since we are switching to a larger LUN size and use striped meta devices an SRDF migration is out of the question so we are stuck with doing a host migration.
We are being told that using a tape backup/recovery method we are looking at a 12 hour outage (the backup goes over a 1Gb network link which is the obvious bottleneck) which is not going to be acceptable. Asked the question why we could not migrate disk-to-disk and the answer we received was that we were not sure if that was supported.
This needs to be a question to IBM (which it will be) but before I pushed this point was looking to see if anyone knew of any reason why a process such as this (which I am sure would beat the 12 hour estimate) would not work:
1) Create new VG/filesystems and mount them.
2) Shutdown the database(s)
3) Copy every filesystem to the new filesystem using dump/tar/cpio or some other AIX copy utility of choice.
4) Unmount/export the old VGs.
5) Unmount/export the new VGs.
6) Import the new VGs and mount the new filesystems as the "old" names.
Restart the database with no changes required. Am I missing something?
I am aware this is what OpenMigrator does - that may be an option though when we first discussed this a few months back that software was dismissed.
We are being told that using a tape backup/recovery method we are looking at a 12 hour outage (the backup goes over a 1Gb network link which is the obvious bottleneck) which is not going to be acceptable. Asked the question why we could not migrate disk-to-disk and the answer we received was that we were not sure if that was supported.
This needs to be a question to IBM (which it will be) but before I pushed this point was looking to see if anyone knew of any reason why a process such as this (which I am sure would beat the 12 hour estimate) would not work:
1) Create new VG/filesystems and mount them.
2) Shutdown the database(s)
3) Copy every filesystem to the new filesystem using dump/tar/cpio or some other AIX copy utility of choice.
4) Unmount/export the old VGs.
5) Unmount/export the new VGs.
6) Import the new VGs and mount the new filesystems as the "old" names.
Restart the database with no changes required. Am I missing something?
I am aware this is what OpenMigrator does - that may be an option though when we first discussed this a few months back that software was dismissed.
No Events found!
dynamox
9 Legend
•
20.4K Posts
0
April 3rd, 2008 05:00
bodnarg
2 Intern
•
385 Posts
0
April 3rd, 2008 05:00
So ... good suggestion but does not apply for this particular case unfortunately.
The real gist of my question is does DB2 do something odd with its files that would render a cold copy useless? I can't find anything to make me believe that is the case - but for some reason the SA and DBA are being cautious...
dynamox
9 Legend
•
20.4K Posts
0
April 3rd, 2008 05:00
bodnarg
2 Intern
•
385 Posts
0
April 3rd, 2008 05:00
There is SRDF/A involved, but we realize it will be "out-of-sync" for a short time while we flip some things around. That outage can extend 12+ hours - it is the downtime that is being balked at.
dynamox
9 Legend
•
20.4K Posts
0
April 3rd, 2008 05:00
dynamox
9 Legend
•
20.4K Posts
0
April 3rd, 2008 06:00
xe2sdc
2 Intern
•
2.8K Posts
1
April 3rd, 2008 06:00
Since new devices have different size I think you have brand new R2 devices for your remote replica. Please leave the new pairs in ACP_DISK and set a QOS of 6 if you don't want to slow down your copy/tar/cpio/whateveryouwant ...
xe2sdc
2 Intern
•
2.8K Posts
0
April 3rd, 2008 06:00
SKT2
2 Intern
•
1.3K Posts
0
April 3rd, 2008 10:00
Also we can avoid specyfing the new disk list while mirroring if a dummy lv is created which could consume all the free space in the VG(only with old disk).
bodnarg
2 Intern
•
385 Posts
0
April 4th, 2008 05:00
The limitation involves being able to add these large LUNs into the volume groups - nothing to do with the LVM mirroring or movement of PVs within the VG. I do not know the exact parameter/setting which is causing the conflict.
Really looking to see if anyone has experience with moving DB2 data around. I think the scenario I layed-out should work, but for some reason this is not being well received. I think it is simply being comfortable with the database method which unfortunately triples the migration time...
xe2sdc
2 Intern
•
2.8K Posts
0
April 4th, 2008 05:00
bodnarg
2 Intern
•
385 Posts
0
April 4th, 2008 05:00
I am trying to figure-out how to improve the actual data migration process with unfortunately limited knowledge of the database environment.
Timing wise we are talking about a process which is being estimated at 10+ hours which should only take 2-3 hours if we move data one time instead of the process of build data base, dump data, reload data which drags out the process...
dynamox
9 Legend
•
20.4K Posts
0
April 4th, 2008 05:00
dynamox
9 Legend
•
20.4K Posts
0
April 4th, 2008 06:00
xe2sdc
2 Intern
•
2.8K Posts
0
April 4th, 2008 15:00