Backup/restore compatibility

Hello, In the DB2 World, there is a (very annoying) constraint concerning backup/ restore: Data backed up on a big-endian host cannot be restored on a little-endian host, and vice versa. The constraint is very illogical considering that one of DB2's selling points is the possibility to scale from the smallest x86-servers to the really-big iron, as business expands. Forgive me... Anyways: Do the same kinds of constraints exist for IDS? More specifically: With IDS 11 on an x86_64 system, is it possible to restore database backups created from an IDS 9.3 x86 system? -- Regards, Troels Arvin <troels@arvin.dk> http://troels.arvin.dk/

Troels Arvin said: > Do the same kinds of constraints exist for IDS? Yes. > With IDS 11 on an x86_64 system, is it possible to restore database > backups created from an IDS 9.3 x86 system? In that specific case, I don't know but I'm fairly sure that in the unlikely event it worked, it wouldn't be supported. This is what dbexport exists for. -- Bye now, Obnoxio "There were a myriad of problems which conspired to corrupt your reason and rob you of your common sense. Fear got the best of you, and in your panic you turned to the Labour Party. They promised you order, they promised you peace, and all they demanded in return was your silent, obedient consent." -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.

Troels Arvin wrote: > In the DB2 World, there is a (very annoying) constraint concerning backup/ > restore: Data backed up on a big-endian host cannot be restored on a > little-endian host, and vice versa. The constraint is very illogical > considering that one of DB2's selling points is the possibility to scale > from the smallest x86-servers to the really-big iron, as business expands. > Do the same kinds of constraints exist for IDS? > > More specifically: > With IDS 11 on an x86_64 system, is it possible to restore database > backups created from an IDS 9.3 x86 system? Troels, I fail to see what one has to do with the other. Intel 32 to Intel 64 is supported in DB2. In fact there is no need for a backup/restore at all. You simply flip the instance to 64 bit. W.r.t. being illogical all DBMS that support native integers have the same issues. You hardly expect the DBMS to punish every I/O by normalizing integers to one scheme or the other just in the unlikely someday endianness will be changed. Supporting a cross-endianness restore would require changing the layout of all the data in the database while being aware what's numeric and what's string. This sort of thing is not the job of a restore which's purpose in life is speedy recovery from failure. Cheers Serge -- Serge Rielau DB2 Solutions Development IBM Toronto Lab

Serge Rielau wrote: > Troels Arvin wrote: >> In the DB2 World, there is a (very annoying) constraint concerning >> backup/ >> restore: Data backed up on a big-endian host cannot be restored on a >> little-endian host, and vice versa. The constraint is very illogical >> considering that one of DB2's selling points is the possibility to >> scale from the smallest x86-servers to the really-big iron, as >> business expands. >> Do the same kinds of constraints exist for IDS? >> >> More specifically: >> With IDS 11 on an x86_64 system, is it possible to restore database >> backups created from an IDS 9.3 x86 system? > Troels, > > I fail to see what one has to do with the other. > Intel 32 to Intel 64 is supported in DB2. In fact there is no need for a > backup/restore at all. You simply flip the instance to 64 bit. Same in IDS AFAIK. If you're running a 32bit version you can upgrade it (inplace) to 64bit. No need to backup/restore... If you're moving from 32 to 64bit platform you can restore into 32bit version running on 64bit platform and then upgrade it to 64bit version. > > W.r.t. being illogical all DBMS that support native integers have the > same issues. You hardly expect the DBMS to punish every I/O by > normalizing integers to one scheme or the other just in the unlikely > someday endianness will be changed. > Supporting a cross-endianness restore would require changing the layout > of all the data in the database while being aware what's numeric and > what's string. This sort of thing is not the job of a restore which's > purpose in life is speedy recovery from failure. > Possibly I'm not seeing the whole picture... But this would be a good feature for many cross platform migrations. Even with a performance hit it would be much easier and in many situations quicker to migrate than using other methods. In IDS though, this has other implications due to different default page sizes in different platforms... :( Regards, -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...

Fernando Nunes wrote: > Possibly I'm not seeing the whole picture... But this would be a good > feature for many cross platform migrations. Even with a performance hit > it would be much easier and in many situations quicker to migrate than > using other methods. You are correct. There is room for tooling that "morphs" databases. This can be changing endianess, but also code pages (e.g. move to Unicode). In DB2 the db2move utility is the tool of choice, but it has still ways to go. Perhaps similar tooling exists in IDS? Cheers Serge -- Serge Rielau DB2 Solutions Development IBM Toronto Lab

Hello, On Sun, 17 Feb 2008 23:36:27 +0000, Obnoxio The Clown wrote: > This is what dbexport exists for. Thanks - it looks like dbexport will be of use. And the dbexport word led me to the special Informix Migration Guide which I had overlooked. -- Regards, Troels Arvin <troels@arvin.dk> http://troels.arvin.dk/

(Sorry for this DB2 topic in the Informix group. I've cross-posted to the DB2 group and set follow-up to the DB2 group, as well.) Discussion history: I made a grumpy statement about DB2's inability to restore across endianness. On Sun, 17 Feb 2008 19:47:47 -0500, Serge Rielau wrote: > I fail to see what one has to do with the other. Intel 32 to Intel 64 is > supported in DB2. In fact there is no need for a backup/restore at all. > You simply flip the instance to 64 bit. Yes, but backups have other use cases, as well. Like: - We would sleep slightly more comfortably if we knew that we could easily restore our pSeries-DB2 data to an x86_64 server in case the pSeries server blew up: x86_64 hardware is easier to get hold of in a hurry. - Production system is on an x86 server which has run out of hardware upgrade options, so we want to move the database to a pSeries LPAR. - So we might as well use the TSM system's bytes instead of having to export all the data to files first. - Or the other way around: The pSeries hardware is somewhat old and overloaded. So let's move the database to a shining new x86_64 host. Again: TSM already has all the data, so why not use it. There are also situations where development is done on - e.g. x86_64, and (test+)production is on the expensive equipment, and in some cases, it makes sense to use the backup/restore system to move the data. db2look +db2move isn't very nice to work with because: - I've seen situations where db2look seemingly produced DDL which couldn't be used (wrong order of DB structure creations). - db2move seems to lock quite a bit, and db2move-based dumps don't guarantee inter-table consistency. > You hardly expect the DBMS to punish every I/O by > normalizing integers to one scheme or the other just in the unlikely > someday endianness will be changed. I know that this would add to the explosion-of-parameters danger, but: Why not make it an option to the BACKUP DATABASE command? -- Regards, Troels Arvin <troels@arvin.dk> http://troels.arvin.dk/

Serge Rielau wrote: > Fernando Nunes wrote: >> Possibly I'm not seeing the whole picture... But this would be a good >> feature for many cross platform migrations. Even with a performance >> hit it would be much easier and in many situations quicker to migrate >> than using other methods. > You are correct. There is room for tooling that "morphs" databases. > This can be changing endianess, but also code pages (e.g. move to > Unicode). In DB2 the db2move utility is the tool of choice, but it has > still ways to go. Perhaps similar tooling exists in IDS? > > Cheers > Serge > I'd have to check about db2move... Don't remember about it from my DB2 studying :) But there is no such tool in IDS... The conversion for UNICODE seems to me such an hard task, that you may as well use the normal ways to reload your data... As for the cross-platform restore I'd say that it's much simpler (excluding the different default page sizes) but this is an idea from someone who doesn't know enough about the subject :) -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...

Troels Arvin wrote: > Hello, > > On Sun, 17 Feb 2008 23:36:27 +0000, Obnoxio The Clown wrote: >> This is what dbexport exists for. > > Thanks - it looks like dbexport will be of use. And the dbexport word led > me to the special Informix Migration Guide which I had overlooked. > It will work, but it can be painfully slow when compared to other methods... -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...