ontape restore to new storage problem
Posted in 2008
Summary
A user running IDS 7.31 wanted to move all dbspaces/chunks to new storage with ontape, complicated by chunks being defined against raw device paths rather than symbolic links, and ruled out dbexport/dbimport and unload/load as too slow. Suggestions included mirroring each chunk onto the new storage then dropping the old side, and doing a redirected restore — but Jonathan Leffler noted 7.31 doesn't support redirected restore, and the mirror trick stumbles on swapping primary/mirror names. No satisfactory resolution was reached beyond upgrading or falling back to the rejected export/import approach.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hello , my box ids 7.31 like to switch all dbspace&chunks to a new
storage. Unfortunatelly , all chunks set to direct device name(not
link name). How could I migrate all db to new storage by ontape
safely and quickly?
I would rather not consider dbexport/dbimport or unload/load.
It take too long to finish and unstable .
↪ replying to roger@star2000.com.tw
On Thu, 2008-02-21 at 00:10 -0800, roger@star2000.com.tw wrote:
> Hello , my box ids 7.31 like to switch all dbspace&chunks to a new
> storage. Unfortunatelly , all chunks set to direct device name(not
> link name). How could I migrate all db to new storage by ontape
> safely and quickly?
> I would rather not consider dbexport/dbimport or unload/load.
> It take too long to finish and unstable .
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
Mirror chunks maybe?
Create a mirror of the chunk you want to move on the new storage, let
the mirror build, take down the old chunk and remove it from the
mirror . . .
Might work, I'd have to look up the commands.
--
--------------------------------------------
Chris Salch
Programmer/Analyst
LeTourneau University
903-233-3537
↪ replying to roger@star2000.com.tw
On 21 Feb, 08:10, ro...@star2000.com.tw wrote:
> Hello , my box ids 7.31 like to switch all dbspace&chunks to a new
> storage. Unfortunatelly , all chunks set to direct device name(not
> link name). How could I migrate all db to new storage by ontape
> safely and quickly?
> I would rather not consider dbexport/dbimport or unload/load.
> It take too long to finish and unstable .
Do a redirected restore if you version supports it.
↪ replying to david@smooth1.co.uk
david@smooth1.co.uk wrote:
> On 21 Feb, 08:10, ro...@star2000.com.tw wrote:
>> Hello , my box ids 7.31 like to switch all dbspace&chunks to a new
>> storage. Unfortunatelly , all chunks set to direct device name(not
>> link name). How could I migrate all db to new storage by ontape
>> safely and quickly?
>> I would rather not consider dbexport/dbimport or unload/load.
>> It take too long to finish and unstable .
>
> Do a redirected restore if you version supports it.
IDS 7.31 does not support directed restore.
Upgrade might be an answer, but probably isn't.
The mirroring idea is interesting; the difficulty is switching the names
of the primary and mirror chunks once the mirror is created. Running
with the primary chunks permanently down is not appealing.
My first choice recommendation would be export/import or load/unload,
but that is ruled out by the question. My second choice recommendation
is don't build a server so that the chunk names refer to physical
devices, but that too is ruled out by the question. Or maybe those two
choices would be reversed...
--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2007.0914 -- http://dbi.perl.org/
publictimestamp.org/ptb/PTB-2582 ripemd128 2008-02-22 06:00:07
75E279979E93FC9BD13A98A70DE02319
Related threads