Database migration. Possible to copy cooked chunks
A user asked whether an 80GB IDS 10 database could be migrated between two Solaris 10/SPARC servers by simply copying the cooked chunk files, instead of doing an ontape restore. Respondents agreed this works: it is effectively an external backup, provided the server is shut down or blocked first (onmode -c block, or onmode -yuk) so the chunk images are consistent, and the chunk paths/ownership/permissions are identical on the target machine. One reply also questioned the premise, noting an ontape restore of 80GB should only take roughly as long as the archive (around 20-30 minutes).
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
We need to migrate a 80G IDS10 database from one Solaris 10 server to another,
more powerful machine (both running Solaris 10 with SPARC chips). This client
currently does not have a storage manager so we use ontape, rather than onbar
for backups and restores.
Rather than using on ontape restore to migrate the data between the servers,
can we simply copy the cooked chunks that the database resides on?
Probably not a supported method however the ontape restore will be quite slow
and we have no experience with HPL.
Thanks and regards,
Paul Ridding
Tourism Technology
Paul-
This would be the same as executing an external backup. Assuming the you
execute either onmode -yuk or onmode -c block before you copy your chunks, you
should be good to go.
--EEM
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> PAUL RIDDING
> Sent: Thursday, February 18, 2010 4:28 PM
> To: ids@iiug.org
> Subject: Database migration. Possible to copy cooked chunks [19077]
>
> We need to migrate a 80G IDS10 database from one Solaris 10 server to
> another,
> more powerful machine (both running Solaris 10 with SPARC chips). This
> client
> currently does not have a storage manager so we use ontape, rather than
> onbar> for backups and restores.
>
> Rather than using on ontape restore to migrate the data between the
> servers,
> can we simply copy the cooked chunks that the database resides on?
>
> Probably not a supported method however the ontape restore will be
> quite slow
> and we have no experience with HPL.
>
> Thanks and regards,
> Paul Ridding
> Tourism Technology
>
>
> ***********************************************************************
> ********
> Forum Note: Use "Reply" to post a response in the discussion forum.
Yes. If you shutdown the server or block it (onmode -c block) so that the
disk images are consistent, you can copy them to the new storage array.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Thu, Feb 18, 2010 at 5:27 PM, PAUL RIDDING <pridding@tt.com.au> wrote:
> We need to migrate a 80G IDS10 database from one Solaris 10 server to
> another,
> more powerful machine (both running Solaris 10 with SPARC chips). This
> client
> currently does not have a storage manager so we use ontape, rather than
> onbar> for backups and restores.
>
> Rather than using on ontape restore to migrate the data between the
> servers,
> can we simply copy the cooked chunks that the database resides on?
>
> Probably not a supported method however the ontape restore will be quite
> slow
> and we have no experience with HPL.
>
> Thanks and regards,
> Paul Ridding
> Tourism Technology
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001517477fbeade9fd047fe7d0bb
Thanks very much Art, Everett and Paul for the quick - and consistent :) replies.
PAUL RIDDING wrote: > Thanks very much Art, Everett and Paul for the quick - and consistent :) > replies. Fools never differ. :o) -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com I will now proceed to pleasure myself with this fish. -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.
Yep :-) -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Obnoxio The Clown Sent: Thursday, February 18, 2010 5:17 PM To: ids@iiug.org Subject: Re: Database migration. Possible to copy cooke.... [19081] PAUL RIDDING wrote: > Thanks very much Art, Everett and Paul for the quick - and consistent :) > replies. Fools never differ. :o) -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com I will now proceed to pleasure myself with this fish. -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean. **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum. _____ avast! Antivirus <http://www.avast.com>; : Outbound message clean. Virus Database (VPS): 100218-1, 02/18/2010 Tested on: 2/18/2010 6:04:42 PM avast! - copyright (c) 1988-2010 ALWIL Software.
As long as every path to every chunk is the same in every way. ;-) = From: "Paul Watson" <paul@oninit.com> = = To: ids@iiug.org = = Date: 02/18/2010 06:08 PM = = Subject: RE: Database migration. Possible to copy cooke.... [1908= 2] = Sent by: ids-bounces@iiug.org = = Yep :-) -----Original Message----- From: ids-bounces@iiug.org [)mailto:ids-bounces@iiug.org] On Behalf Of Obnoxio The Clown Sent: Thursday, February 18, 2010 5:17 PM To: ids@iiug.org Subject: Re: Database migration. Possible to copy cooke.... [19081] PAUL RIDDING wrote: > Thanks very much Art, Everett and Paul for the quick - and consistent= :) > replies. Fools never differ. :o) -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com I will now proceed to pleasure myself with this fish. -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean. ***********************************************************************= ***** *** Forum Note: Use "Reply" to post a response in the discussion forum. _____ avast! Antivirus <http://www.avast.com>; : Outbound message clean. Virus Database (VPS): 100218-1, 02/18/2010 Tested on: 2/18/2010 6:04:42 PM avast! - copyright (c) 1988-2010 ALWIL Software. ***********************************************************************= ******** Forum Note: Use "Reply" to post a response in the discussion forum. =
On 18 February 2010 22:27, PAUL RIDDING <pridding@tt.com.au> wrote:
> We need to migrate a 80G IDS10 database from one Solaris 10 server to
another,
> more powerful machine (both running Solaris 10 with SPARC chips). This client
> currently does not have a storage manager so we use ontape, rather than onbar
> for backups and restores.
>
> Rather than using on ontape restore to migrate the data between the servers,
> can we simply copy the cooked chunks that the database resides on?
>
> Probably not a supported method however the ontape restore will be quite slow
> and we have no experience with HPL.
>
> Thanks and regards,
> Paul Ridding
> Tourism Technology
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
Paul
Why do you think a restore will be slow, unless your archives are
slow. I would expect a restore to take no more than 120% the time of
an archive and for 80 Gb on a resonably modern server I would expect
an archive to take no more than 20-25 minutes, 30 tops.
Keith