Cross platform dump ( with compression ) and load not working

[Jesus M. Salvo Jr.]

Source: 32-bit ASE 12.5.4 on SUSE x86 ( with compression using new syntax ... dump database ... with compression="5" )
Target: 32-bit ASE 12.5.3 on 64-bit Solaris


Cross platform dump ( with compression using the new syntax ) and load does not seem to work
if the dump was compressed:

[21] .master.1> load database motiondb from "/data/sybbackup/SYBASE/motiondb_20060628.dmp"
[21] .master.2> go
Backup Server session id is: 88. Use this value when executing the 'sp_volchanged' system stored procedure after fulfilling any volume change request from the Backup Server.
Backup Server: 6.28.1.1: Dumpfile name 'otiondb061790F30C' section number 1 mounted on disk file '/data/sybbackup/SYBASE/motiondb_20060628.dmp'
Backup Server: 4.145.2.36: [95] Error for device '/data/sybbackup/SYBASE/motiondb_20060628.dmp'. Error reading from archive device /data/sybbackup/SYBASE/motiondb_20060628.dmp. Attempted to read 855769088 bytes, but 4092 bytes were read. The dump is probably bad.
Backup Server: 6.35.2.2: Volume validation error: bad magic number , expected USTH.
Msg 8009, Level 16, State 1
Server 'SYBASE', Line 1
Error encountered by Backup Server. Please refer to Backup Server messages for details.

[A.M.]

Post by Jesus M. Salvo Jr.
Source: 32-bit ASE 12.5.4 on SUSE x86 ( with compression using new syntax ... dump database ... with compression="5" )
Target: 32-bit ASE 12.5.3 on 64-bit Solaris
Cross platform dump ( with compression using the new syntax ) and load does not seem to work
[21] .master.1> load database motiondb from "/data/sybbackup/SYBASE/motiondb_20060628.dmp"

...

Post by Jesus M. Salvo Jr.
Backup Server: 4.145.2.36: [95] Error for device '/data/sybbackup/SYBASE/motiondb_20060628.dmp'. Error reading from archive device /data/sybbackup/SYBASE/motiondb_20060628.dmp. Attempted to read 855769088 bytes, but 4092 bytes were read. The dump is probably bad.
Backup Server: 6.35.2.2: Volume validation error: bad magic number , expected USTH.

How are you transferring the dump file? With ftp? "bad magic number"
might be a clue here. I wonder if the byte ordering isn't getting
transposed as you transfer between the INTEL endianess and the
SPARC endianess. You could use something like od or less to quickly
check that. You'd only need to examine the first few bytes.

-am © MMVI

[Jesus M. Salvo Jr.]

Post by A.M.

Post by Jesus M. Salvo Jr.
Source: 32-bit ASE 12.5.4 on SUSE x86 ( with compression using new syntax
... dump database ... with compression="5" ) Target: 32-bit ASE 12.5.3 on
64-bit Solaris
Cross platform dump ( with compression using the new syntax ) and load
[21] .master.1> load database motiondb from
["/data/sybbackup/SYBASE/motiondb_20060628.dmp"

...

Post by Jesus M. Salvo Jr.
Backup Server: 4.145.2.36: [95] Error for device
'/data/sybbackup/SYBASE/motiondb_20060628.dmp'. Error reading from
archive device /data/sybbackup/SYBASE/motiondb_20060628.dmp. Attempted to
read 855769088 bytes, but 4092 bytes were read. The dump is probably bad.
Backup Server: 6.35.2.2: Volume validation error: bad magic number , expected USTH.

How are you transferring the dump file? With ftp? "bad magic number"
might be a clue here. I wonder if the byte ordering isn't getting
transposed as you transfer between the INTEL endianess and the
SPARC endianess. You could use something like od or less to quickly
check that. You'd only need to examine the first few bytes.
-am © MMVI

Unfortunately, I checked both files with cksum, and they have the same
signature.

[A.M.]

Post by Jesus M. Salvo Jr.

Post by A.M.
How are you transferring the dump file? With ftp? "bad magic number"
might be a clue here. I wonder if the byte ordering isn't getting
transposed as you transfer between the INTEL endianess and the
SPARC endianess. You could use something like od or less to quickly
check that. You'd only need to examine the first few bytes.

Unfortunately, I checked both files with cksum, and they have the same
signature.

OK, so they are the same. Looks like a bug then.

I gather the uncompressed version works OK? What about the
older compression syntax?

-am © MMVI

[Jesus M. Salvo Jr.]

Post by A.M.

Post by Jesus M. Salvo Jr.

Post by A.M.
How are you transferring the dump file? With ftp? "bad magic number"
might be a clue here. I wonder if the byte ordering isn't getting
transposed as you transfer between the INTEL endianess and the
SPARC endianess. You could use something like od or less to quickly
check that. You'd only need to examine the first few bytes.

Unfortunately, I checked both files with cksum, and they have the same
signature.

OK, so they are the same. Looks like a bug then.
I gather the uncompressed version works OK? What about the
older compression syntax?
-am © MMVI

That's what we are trying now ... Will post results tomorrow.

[Jesus M. Salvo Jr.]

Post by Jesus M. Salvo Jr.

Post by A.M.

Post by Jesus M. Salvo Jr.

Post by A.M.
How are you transferring the dump file? With ftp? "bad magic number"
might be a clue here. I wonder if the byte ordering isn't getting
transposed as you transfer between the INTEL endianess and the
SPARC endianess. You could use something like od or less to quickly
check that. You'd only need to examine the first few bytes.

Unfortunately, I checked both files with cksum, and they have the same
signature.

OK, so they are the same. Looks like a bug then.
I gather the uncompressed version works OK? What about the
older compression syntax?
-am © MMVI

That's what we are trying now ... Will post results tomorrow.

FYI. Old compression syntax works

[m***@peppler.org]

Post by Jesus M. Salvo Jr.
Source: 32-bit ASE 12.5.4 on SUSE x86 ( with compression
using new syntax ... dump database ... with
compression="5" ) Target: 32-bit ASE 12.5.3 on 64-bit
Solaris
Cross platform dump ( with compression using the new
syntax ) and load does not seem to work if the dump was

I think I read in the 12.5.4 release docs that the backup
server has changed in 12.5.4, and that it may not be
backwards compatible for compressed dumps.

The workaround mentioned is to use a 12.5.4 backup server in
the 12.5.3 installation - maybe you can try that?

Michael

[Jesus M. Salvo Jr.]

Post by m***@peppler.org

Post by Jesus M. Salvo Jr.
Source: 32-bit ASE 12.5.4 on SUSE x86 ( with compression
using new syntax ... dump database ... with
compression="5" ) Target: 32-bit ASE 12.5.3 on 64-bit
Solaris
Cross platform dump ( with compression using the new
syntax ) and load does not seem to work if the dump was

I think I read in the 12.5.4 release docs that the backup
server has changed in 12.5.4, and that it may not be
backwards compatible for compressed dumps.
The workaround mentioned is to use a 12.5.4 backup server in
the 12.5.3 installation - maybe you can try that?
Michael

We ended up doing a dump of 12.5.4 using the old compression syntax and
loaded that into 12.5.3. That one works.


John