Can't load a compressed dump

[John Flynn]

Hi.

I am on ASE 15.0.2 ESD#6. I have just started experimenting with compressed
dumps to tape, and I'm having trouble with it. I'm doing a dump operation
like this:

dump database master to "/dev/rmt/0n" with init
dump database miqs to "/dev/rmt/0n" with compression=1

My intention is to write two sequential dumps to the tape, the first one
uncompressed but the second one compressed. The dumps report no errors and
appear to run fine. If I then use load with headeronly or listonly, I get
what looks like the expected responses. The problem comes when I try to load
the second dump back into the database. I use a command like:

load database miqs from "/dev/rmt/0n" with file="miqs091200D381"

That results in the following output:

Backup Server: 6.84.2.1: Volume validation error: illegal volume change,
device /dev/rmt/0n: stripe 0 is already loaded.
Backup Server: 6.36.2.7: Header labels of rejected volume:
Backup Server: 6.34.2.7:
VOL1 0
7
HDR1miqs091200D381
HDR2F
Backup Server: 6.46.1.1: OPERATOR: Mount the next volume to read.
Backup Server: 6.78.1.1: EXECUTE sp_volchanged
etc.

I believe my sequence of commands are okay, and my tape is okay, because
when I repeat the entire process as above but WITHOUT any compression, the
load works perfectly. I have repeated several times, sometimes with
compression and sometimes without, and my results have been consistent.

What am I doing wrong?

Thanks.
- John.

[Bret Halford [Sybase]]

Post by John Flynn
Hi.
I am on ASE 15.0.2 ESD#6. I have just started experimenting with compressed
dumps to tape, and I'm having trouble with it. I'm doing a dump operation
dump database master to "/dev/rmt/0n" with init
dump database miqs to "/dev/rmt/0n" with compression=1
My intention is to write two sequential dumps to the tape, the first one
uncompressed but the second one compressed. The dumps report no errors and
appear to run fine. If I then use load with headeronly or listonly, I get
what looks like the expected responses. The problem comes when I try to load
load database miqs from "/dev/rmt/0n" with file="miqs091200D381"
Backup Server: 6.84.2.1: Volume validation error: illegal volume change,
device /dev/rmt/0n: stripe 0 is already loaded.
VOL1 0
7
HDR1miqs091200D381
HDR2F
Backup Server: 6.46.1.1: OPERATOR: Mount the next volume to read.
Backup Server: 6.78.1.1: EXECUTE sp_volchanged
etc.
I believe my sequence of commands are okay, and my tape is okay, because
when I repeat the entire process as above but WITHOUT any compression, the
load works perfectly. I have repeated several times, sometimes with
compression and sometimes without, and my results have been consistent.
What am I doing wrong?
Thanks.
- John.

I don't see anything obviously wrong with what you are doing.
If you use compression for both of the dumps (i.e. don't mix compressed
and normal dumps), does that work or still fail on the second?

Please check the versions of the backupserver and sybmultbuf binaries as
well - are they also 15.0.2 ESD #6? ( $SYBASE/ASE-*/bin/backupserver -v )

Perhaps post the entire sequence from you client showing the dump
commands, all output, the load commands, all output. We might spot
something in it.

-bret

[John Flynn]

Hi Bret,

Post by Bret Halford [Sybase]
Please check the versions of the backupserver and sybmultbuf binaries
as well - are they also 15.0.2 ESD #6? (
$SYBASE/ASE-*/bin/backupserver -v )

They are 15.0.2 ESD #6.

Post by Bret Halford [Sybase]
I don't see anything obviously wrong with what you are doing.
If you use compression for both of the dumps (i.e. don't mix
compressed and normal dumps), does that work or still fail on the
second?

Bingo. I have changed it so ALL the dumps on the tape are done "with
compression=1", and once I do that, I can load the second dump with no
errors. For now that is my workaround. Thanks for suggesting that.

Another thing I noticed is when I do "load with listonly=full" on a tape
with multiple dumps, the very first record contains a field called
"compression level", like this:

Backup Server: 4.35.1.1: Device '/dev/rmt/0n':
Label name: 'VOL1'
Volume id: ' '
Access code: ' '
Reserved: ' '
Compression level: '1'
Owner id: ' '
Reserved: ' '
Labeling version: 7

But "compression level" appears nowhere else in the listing. Implying that
the compression level applies to the tape as a whole and not to any
individual dump on the tape. Furthermore, up until today when I did NOT
compress the first dump but DID compress the second dump, the listonly
output showed the compression level as zero.

It acts as if the compression level for the first dump is stamped into the
tape header and is then assumed to apply to all subsequent dumps, regardless
of the compression that is really used on those subsequent dumps. This seems
like a bug.

Thanks.
- John.

[Bret Halford [Sybase]]

Post by John Flynn
It acts as if the compression level for the first dump is stamped into the
tape header and is then assumed to apply to all subsequent dumps, regardless
of the compression that is really used on those subsequent dumps. This seems
like a bug.
Thanks.
- John.

Hi John,

I agree. Either the dump should be prevented or the load should succeed.

I've filed CR 570758 for the issue. If you have a support contract, I
recommend opening a case so the CR will be associated with a customer
case.

Cheers,
-bret