Hi.

Solaris 2.6
IDS 7.31.

Company purchased new storage device and are going to move data to
that base. "Old" system use raw devices, "new" will be on files. IDS
is configured to use links to raw devices, so admin is going to
rearange links after data is moved.

They use onbar with SQL Backtrack, so one way of moving data would be
to make backup, then restore data on new system.

Only thing which worries me, is how good will backups work, if data is
taken from raw devices, and put to files, any information about that?
Also, can we try to dd data from raw devices to files and then
rearrange links for IDS (would be faster than backup)? Any other ideas
about possible problems with such migration process?

Thanks for feedback!

Andris

Why convert from raw to cooked storage? Your performance is going to
suffer.


"Andris" <andris_sh@yahoo.com> wrote in message
news:e3ae8cc2.0404260618.74ebc1e6@posting.google.c om...
> Hi.
>
> Solaris 2.6
> IDS 7.31.
>
> Company purchased new storage device and are going to move data to
> that base. "Old" system use raw devices, "new" will be on files. IDS
> is configured to use links to raw devices, so admin is going to
> rearange links after data is moved.
>
> They use onbar with SQL Backtrack, so one way of moving data would be
> to make backup, then restore data on new system.
>
> Only thing which worries me, is how good will backups work, if data is
> taken from raw devices, and put to files, any information about that?
> Also, can we try to dd data from raw devices to files and then
> rearrange links for IDS (would be faster than backup)? Any other ideas
> about possible problems with such migration process?
>
> Thanks for feedback!
>
> Andris

> Andris" <andris_sh@yahoo.com> wrote in message
news:e3ae8cc2.0404260618.74ebc1e6@posting.google.c om...
> Hi.
>
> Solaris 2.6
> IDS 7.31.
>
> Company purchased new storage device and are going to move data to
> that base. "Old" system use raw devices, "new" will be on files. IDS
> is configured to use links to raw devices, so admin is going to
> rearange links after data is moved.
>
> They use onbar with SQL Backtrack, so one way of moving data would be
> to make backup, then restore data on new system.

Yes. Informix mirroring is a very efficient way of achieving the same thing
with minimal downtime.

> Only thing which worries me, is how good will backups work, if data is
> taken from raw devices, and put to files, any information about that?

A corollary of the fact that you can use Informix mirroring is that the
dbspace chunks themselves contain no information about the actual physical
location (whehn used with soft links) or topology of the disks.

> Also, can we try to dd data from raw devices to files and then
> rearrange links for IDS (would be faster than backup)? Any other ideas
> about possible problems with such migration process?

Yes, you could do that too. But, as I say, mirroring is the way to go.

Well, to answer your question, try:

1. Backup
2. Down the instance
3. Redefine the chunks from raw to cooked
4. Restore

That said, why not user Veritas or Legato? They can backup raw or
cooked chunks, and restore either to the other (cooked --> raw and raw
--> cooked). Why does SQL Backtrack requires cooked chunks?

Brice Avila
Minneapolis, Minnesota

andris_sh@yahoo.com (Andris) wrote in message news:<e3ae8cc2.0404260618.74ebc1e6@posting.google. com>...
> Hi.
>
> Solaris 2.6
> IDS 7.31.
>
> Company purchased new storage device and are going to move data to
> that base. "Old" system use raw devices, "new" will be on files. IDS
> is configured to use links to raw devices, so admin is going to
> rearange links after data is moved.
>
> They use onbar with SQL Backtrack, so one way of moving data would be
> to make backup, then restore data on new system.
>
> Only thing which worries me, is how good will backups work, if data is
> taken from raw devices, and put to files, any information about that?
> Also, can we try to dd data from raw devices to files and then
> rearrange links for IDS (would be faster than backup)? Any other ideas
> about possible problems with such migration process?
>
> Thanks for feedback!
>
> Andris