Migrate data from raw device to cooked file

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.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

> Andris" <andris_sh@yahoo.com> 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. 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