Re: Practical difficulty with IDS 10-11.5 upgrade. Inspiration needed please ...!

On 05/08/2010 10:43, Clive Eisen wrote: >> >> Do you have any thoughts on the above or possible alternatives? My >> primary >> concern is that once we start the upgrade process we're committed to >> restoring replication via a backup - pretty much whether we decide to >> remain >> on V11 or revert back to V10. Therefore if the transfer/restore is not >> reliable Sydney reporting could be affected for a far longer time than is >> said to be acceptable" > Neil > > Whilst I have not tried this across a version gap as big as this (and > you will therefore need to experiment) > if you use > > gzip --rsyncable to compress the archives > > and use rsync to transfer the 11.5 archive over the top of an already > transferred 10.0 archive - you MAY be surprised at the transfer time. > > Others closer to the internals of an ontape archive may be able to blow > this out the water... > > If indeed it doesn't help enough can you do an upgrade in UK on a test > machine just to get a valid archive and get that transferred to rsync > over the top of? > > It might even be faster, once you have transferred such a reference > archive to rsync the final archive uncompressed, whilst using rsyncs own > on the fly compression. > > -- > Clive > Well, you could try something like the following : ontape -s -L 0 -F -t STDIO | gzip -c | remsh host1s "set_cl1_sec > /dev/null; gunzip | ontape -p -t STDIO 2>/dev/null' This will still have to pump say 50 Gig across the line (assuming that gzip can compress 300 Gig to 50 Gig), but it means that you do not have the intermediate archive file to write / read as it will go straight from source to target. ideally the restore completes before wrapping the logs on the primary. I know of 300 Gig plus instances being set up like this, and they were happy :o) Proof is obviously in the testing