Verifying a database server copy
Posted in 2009
Topics: Storage & Space Management, Logging & Checkpoints, Migration, Import/Export & Data Conversion, Platform-Specific Issues, Versions, Editions & End-of-Life
IDS 10.0FC8 on HP-UX 11.31 We're migrating a 200g database server from one data centre to another. The migration method chosen (not by me) is a block-by-block SAN copy of the LUNs containing the source database server (which of course will be quiescent) to the remote site. How can we get right the balance between thoroughly checking that the database chunks have been copied faithfully, and not taking unnecessarily long to do so? At the opposite ends of the "checking" spectrum are: - comparing the checkpoint timestamps on the source and target environments. all this really shows though is that the relevant resrved page(s) has been copied correctly - running an md5summ on all the character devices for the Informix chunks. This would take forever I expect ... A halfway-house might be to check the max value of serial or timestamp columns in selected tables. What I did wonder - haven't been on an Internals course for years - is, when Informix opens primary chunks, does it sanity-check the timestamp on the chunk with the reserved page value? That would be a pretty reliable check ... thanks Neil
On 28 June, 11:37, "Neil Truby" <neil.tr...@ardenta.com> wrote:
> IDS 10.0FC8 on HP-UX 11.31
>
> We're migrating a 200g database server from one data centre to another. The
> migration method chosen (not by me) is a block-by-block SAN copy of the LUNs
> containing the source database server (which of course will be quiescent) to
> the remote site.
>
> How can we get right the balance between thoroughly checking that the
> database chunks have been copied faithfully, and not taking unnecessarily
> long to do so? At the opposite ends of the "checking" spectrum are:
>
> - comparing the checkpoint timestamps on the source and target environments.
> all this really shows though is that the relevant resrved page(s) has been
> copied correctly
> - running an md5summ on all the character devices for the Informix chunks.
> This would take forever I expect ...
>
> A halfway-house might be to check the max value of serial or timestamp
> columns in selected tables. What I did wonder - haven't been on an
> Internals course for years - is, when Informix opens primary chunks, does it
> sanity-check the timestamp on the chunk with the reserved page value? That
> would be a pretty reliable check ...
>
> thanks
> Neil
- checksum the first 1MB of each chunk to ensure that the right chunks
were copied to the correct place.
- oncheck -pe and checksum the reserved pages, chunk free list,
partition pages, sysmaster,
and the system catalog tables
- oncheck -pe and if you have time checksum all used (non-free)
extents
otherwise just checksum all chunks with a reasonable level of
parallelism.
You could also do some work before hand with purging old data, "alter
fragment on table"
and index rebuilds, to reduce the number of used extents
"Neil Truby" <neil.truby@ardenta.com> wrote in message
news:7aovfgF20384jU1@mid.individual.net...
> IDS 10.0FC8 on HP-UX 11.31
>
> We're migrating a 200g database server from one data centre to another.
> The migration method chosen (not by me) is a block-by-block SAN copy of
> the LUNs containing the source database server (which of course will be
> quiescent) to the remote site.
>
> How can we get right the balance between thoroughly checking that the
> database chunks have been copied faithfully, and not taking unnecessarily
> long to do so? At the opposite ends of the "checking" spectrum are:
we do it all the time. we have a script for that. this is the logic we
follow
1. on the outgoing server after Informix is shutdown, we run the script
which runs oncheck -pe for every chunk and dumps the first 1000 blocks
of it via the dd command and save it to a file.
2. later on , on the new incoming server, before Informix is started, we
run
the script in the new mode, which does the same. However this time we
also diff the original file with the new one.
Only when step (2) reports all chunks as same, do we bring the server.
"DBA" <dba.999@nomail.com> wrote in message
news:7ap5gnF2042omU1@mid.individual.net...
>
> "Neil Truby" <neil.truby@ardenta.com> wrote in message
> news:7aovfgF20384jU1@mid.individual.net...
>> IDS 10.0FC8 on HP-UX 11.31
>>
>> We're migrating a 200g database server from one data centre to another.
>> The migration method chosen (not by me) is a block-by-block SAN copy of
>> the LUNs containing the source database server (which of course will be
>> quiescent) to the remote site.
>>
>> How can we get right the balance between thoroughly checking that the
>> database chunks have been copied faithfully, and not taking unnecessarily
>> long to do so? At the opposite ends of the "checking" spectrum are:
>
> we do it all the time. we have a script for that. this is the logic we
> follow
>
> 1. on the outgoing server after Informix is shutdown, we run the script
> which runs oncheck -pe for every chunk and dumps the first 1000 blocks
> of it via the dd command and save it to a file.
> 2. later on , on the new incoming server, before Informix is started, we
> run
> the script in the new mode, which does the same. However this time we
> also diff the original file with the new one.
>
> Only when step (2) reports all chunks as same, do we bring the server.
Cool! Do email me the script, thanks! ;-)
Neil Truby wrote: > We're migrating a 200g database server from one data centre to another. A jiffy bag with a 76p stamp should suffice ;-) -- RGB