SEO

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

On 18 Feb, 22:09, Fernando Nunes <s...@onlinedomus.net> wrote:
> 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...

The unload the tables in parallel and load them in parrallel.

Also no-one has mentioned point in time table recovery in version 10
that as John Miller III pointed out at the Altanta conference
could be used to extract system catalogs from an IDS 10 backup and
then restore the tables in parallel.