AIX 4.3.3 / Compress Problem 1

[Peter4711]

Hello all! I've a great problem and does not find the reason for it. So I hope anybody have good ideas to find the solution.
Problem: I'm sysadmin for 7 RS6000 Servers (7044/170) running with AIX 4.3.3 and a Oracle 7 Database (I know - OLD! But there is no way to upgrade the Software. This solution is for only 2 years!). Now my company bought "new" (refurbished) Servers with maintenance (7028/6C1). I've installed AIX 4.3.3 and the Oracle DB. All works fine and without any problems. Only the backupscript have Problems at one line.
The line is: "find /oradata/dbs0/* -prune -print | cpio -oB | compress > /dev/rmt0"
This works fine on the old Servers and works fine without the COMPRESS command.
Compress and uncompress works in a directory (e.g. compress /oradata/dbs0/*) without errors, but in the combination with rmt0 I get always the error:
# find /oradata/dbs0/* -prune -print | cpio -oB | compress > /dev/rmt0
# 14040 blocks
A system call received a parameter that is not valid
#
Questions: Where is the system call? What is the reason for it?

I've checked all smit settings... there is no difference to the old servers. Backup to rmt0 works - but only without compress.
Any ideas? Thanks a lot

 

[KenCunningham]

Sounds like it may be a block size issue for cpio. I think the default is 512. Have you tried setting it to 0 or 1024?

 

[columb]

Try

find /oradata/dbs0/* -prune -print | cpio -oB | compress [COLOR=red]-c[/color] > /dev/rmt0

The '-c' flag means 'write to stdout'

Ceci n'est pas une signature
Columb Healy

 

[mrn]

You could also try using a full path

/usr/bin/compress

Mike

"Whenever I dwell for any length of time on my own shortcomings, they gradually begin to seem mild, harmless, rather engaging little things, not at all like the staring defects in other people's characters."

 

[Peter4711]

@columb
Thanks for the fast help... But as describet the line works on the old servers. I've tryed your input, but I got the same error...

@KenCunningham
You mean the setting for the tape drive?

@all:
I've tryed the following:
find /oradata/dbs0/* -prune -print | cpio -oB | compress > /backup/cpio/test123.cpio.Z
and it works without error...

The error have something to do with the tape drive.. I'm sure. I've changed the Tapedrive and the tape - same Problems...

 

[KenCunningham]

Peter what is the block size set to when viewing the tape through smitty? This are our exabyte settings:

Change / Show Characteristics of a Tape Drive

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

[TOP] [Entry Fields]
Tape Drive rmt0
Tape Drive type scsd
Tape Drive interface scsi
Description LVD SCSI Tape Drive
Status Available
Location 1Z-08-00-0,0
Parent adapter scsi0
Connection address 0,0
BLOCK size (0=variable length) [1024] +#
Use DEVICE BUFFERS during writes yes +
RETURN error on tape change or reset no +
RETENSION on tape change or reset no +
DENSITY setting #1 129 +

 

[Peter4711]

@KenCunningham

Old Server : 512
new Server: Tryed with 512 and 1024

 

[Peter4711]

Where can i find the " system call" and the "parameter that is not valid"?

usual should there be a hint for the error...

 

[hfaix]

Is the tape compatible with the drive?

 

[RodKnowlton]

Peter,

I agree with KenCunningham that this is probably a block size problem.

Please post the output of "lsattr -El rmt0".

Also, can you read tapes made on other servers with this one?

KenCunningham,

Thanks for quoting that output. It showed me that Toggle Fixed Font wasn't affecting quotes.

(Can't fix it at userscripts.org right now, though. Source editing is broken. :-()

- Rod


IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+

Wish you could view posts with a fixed font? Got Firefox & Greasemonkey? Give yourself the option.

 

[p5wizard]

You might try this modification:

find /oradata/dbs0/* -prune -print | cpio -oB | compress | dd ibs=512 obs=1024 of=/dev/rmt0

or

find /oradata/dbs0/* -prune -print | cpio -oB | compress | dd ibs=512 obs=10240 of=/dev/rmt0

It forces the writes to tape to the tapd drives block size (and in the second option to a 10fold of that block size.)


HTH,

p5wizard

 

[kozlow]

We use to do the same thing creating a named pipe to the tape drive. It worked great.....

check the mkfifo

Check this site out:

http://www.idevelopment.info/data/Oracle/DBA_tips/Export_Import/EXP_2.shtml

I am assuming that the tape devicse are the same on both the old and new servers... DLT requires 0.... You said it works without the compress, so this is a non-issue.

If I find the old backup script, I will pass it on.....

We export to disk now to save time and then us a backup tool to move the EXPORT or Online/Offline backups to Tape

 

[Peter4711]

Hi all
First: Thanjk you all for your replys!

@hfaix: Yes, I'm sure that it is compatible

@RodKnowlton : here is the output:
# lsattr -El rmt0
mode yes Use DEVICE BUFFERS during writes True
block_size 512 BLOCK size (0=variable length) True
extfm no Use EXTENDED file marks True
ret no RETENSION on tape change or reset True
density_set_1 38 DENSITY setting #1 True
density_set_2 37 DENSITY setting #2 True
compress yes Use data COMPRESSION True
size_in_mb 20480 Size in Megabytes False
ret_error no RETURN error on tape change or reset True

@p5wizard:
I've tryed both version of your suggestions. Here the output:
# find /oradata/dbs0/* -prune -print | cpio -oB | compress | dd ibs=512 obs=1024 of=/dev/rmt0
14040 blocks
dd: 0511-053 The write failed.
: A system call received a parameter that is not valid.
18421+1 records in.
9210+1 records out.
#
======================
# find /oradata/dbs0/* -prune -print | cpio -oB | compress | dd ibs=512 obs=10240 of=/dev/rmt0
14040 blocks
dd: 0511-053 The write failed.
: A system call received a parameter that is not valid.
18421+1 records in.
921+1 records out.
#

@kozlow:
what did you mean with check mkfifo? How did I know which file AIX uses as temp file for compress? O should I generate a new one?

Thanks for your Help

 

[p5wizard]

Do you need to use cpio? You could try the backup command instead (or tar):

find /oradata/dbs0/* -prune -print | backup -iqf/dev/rmt0

tar -cf/dev/rmt0 /oradata/dbs0


HTH,

p5wizard

 

[RodKnowlton]

Peter4711,

Since your tape drive has compression enabled and the pipeline works without the "compress" command, why not just leave it out?

Sending compressed data to a drive that has its own compression mechanism turned on will ruin its streaming performance, as it wastes time trying to compress the uncompressable (caveat: some newer drives can handle this better, by detecting compressed data and letting it through without trying to compress it again).

In many cases, compressing data that is already compressed will cause it to grow.

- Rod


IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+

Wish you could view posts with a fixed font? Got Firefox & Greasemonkey? Give yourself the option.