(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/