Operating System - OpenVMS
1748354 Members
4706 Online
108763 Solutions
New Discussion

Re: Ultrium 3280 SAS Tape Drive on RX2800 - Restores times very slow

 
SOLVED
Go to solution
robert70
Valued Contributor

Ultrium 3280 SAS Tape Drive on RX2800 - Restores times very slow

Hi,

 

Having a problem on our new system with restore times from a Ultrium 3280 SAS tape Drive to a D2700 disk enclosure.

 

The backup of 220Gb of oracle data/index tables took about 25 minutes - however the restore of the same data set took about 15 hours! Help!

 

The server is a RX2800 Integrity running VMS 8.4.

 

I have seen in other posts various comments about turning off High water marking - which I tried - no noticeable differences in restore times. I have also tried putting the DIOLM to 8 on the SYSTEM account I am using for backups. As well as setting the PQL_MDIOLM to 8 before backups and then back to 100 after. Again no difference in timings.

 

Any ideas please.

 

 

17 REPLIES 17
robert70
Valued Contributor

Re: Ultrium 3280 SAS Tape Drive on RX2800 - Restores times very slow

meant to say here are the commands I used for the Backup and then the restore:-

 

$ init/over=(own,exp,acc) $2$MGA0: backup
$ mount/block=32768/for $2$MGA0: backup

 

$ back/media_format=compact/ignore=label/rew/nocrc/record/block=32768 -
  dkb100:[oracle_redo]*.* -
  $2$MGA0:data1.bck /save -
  /list = sys$backup:data1.lis /log
$!
$ back/media_format=compact/ignore=label/nocrc/record/block=32768 -
  dkb200:[oracle_data]*.* -
  $2$MGA0:data2.bck /save -
  /list = sys$backup:data2.lis /log
$!
$ back/media_format=compact/ignore=label/nocrc/record/block=32768 -
  dkb300:[oracle_idx]*.* -
  $2$MGA0:data3.bck /save -
  /list = sys$backup:data3.lis /log

 

 

 

And then on the restore side I went with

 

$MOUNT/FOR $2$MGA0:BACKUP
$BACKUP $2$mga0:DATA1.BCK DKB100:[ORACLE_REDO]*.*
$BACKUP $2$mga0:DATA2.BCK DKB200:[ORACLE_DATA]*.*
$BACKUP $2$mga0:DATA3.BCK DKB300:[ORACLE_IDX]*.*

 

 

 

 


 

Hoff
Honored Contributor

Re: Ultrium 3280 SAS Tape Drive on RX2800 - Restores times very slow

Is there a remote link involved here, as was the case in this thread?  If so, how fast is this link?

 

Are your BACKUP username process quotas per specification?

 

What is your rx2800 i2 storage hardware configuration; the details of your disk and tape I/O devices and paths? 

 

What else have you tried?  Does a disk-to-disk restore show the same timing and the same behavior?  Does a local tape-to-disk restore show the same timing?

 

And one general process question,  why are you using tape in what appears to be a time-critical DT configuration?  Can you get the Oracle giblets to put a backup or at least a journal directly on the remote box?

 

If this is the same configuration that was discussed before, there is no particular fix for a network connection that isn't sufficient for your time requirements, though it's possible that migrating to data compression MIGHT help reduce the contention on that data link SOMEWHAT.  That's data compression, and not media compaction.   Media compaction occurs entirely within the device, and that means that the uncompressed data will travels over that site-to-site network link, where data compression and data decompression occurs within BACKUP and that might reduce the volume of bits over the link at the cost of higher CPU overhead.

robert70
Valued Contributor

Re: Ultrium 3280 SAS Tape Drive on RX2800 - Restores times very slow

Hi Hoff,

 

Thanks

theres no "link" involved here

this is the new system totally standalone

Tape Drive connected to the integrity server adapter P411

D2700 connected via another P411 adapter

 

backup is super fast 220Gb at 20mins

restore is painfully slow at 15 hours!

 

will get back to you tomorrow re your other questions here

thanks

 

abrsvc
Respected Contributor

Re: Ultrium 3280 SAS Tape Drive on RX2800 - Restores times very slow

As Hoff suggested, I would recommend trying a pass disk-to-disk. Eliminate the tapedrive completely. See if the problem is the restore behavior alone.

Dan
Volker Halle
Honored Contributor

Re: Ultrium 3280 SAS Tape Drive on RX2800 - Restores times very slow

Robert70,

 

consider doing a BACKUP/LIS=filename $2$MGA0:*.*/SAVE/REWIND to time the read operations from tape. If this operation seems still 'very slow', consider even using /LIST=NLA0: If that is also slow, it must be the tape drive or the IO path to the tape.

 

Does ANALYZE/SYSTEM SDA> FC PERFORMANCE also do FC tape performance ? It's worth a try.

 

Volker.

Eberhard Heuser
Frequent Advisor

Re: Ultrium 3280 SAS Tape Drive on RX2800 - Restores times very slow

Did you try /block=32256 instead of 32768?

 

This is the number I alway see in the recommendations.

 

Eberhard

robert70
Valued Contributor

Re: Ultrium 3280 SAS Tape Drive on RX2800 - Restores times very slow

disk to disk backup/restore

 

backup of 3 files 35mb each took 6 seconds

restore of same data set took 93 seconds

 

so this would highlight a problem with the restore op and nothing to do with the tape and its config/connection.

 

 

robert70
Valued Contributor
Solution

Re: Ultrium 3280 SAS Tape Drive on RX2800 - Restores times very slow

Here’s the problem:
one of the adapter has NO write cache!

Adapter: _PKC0:
P411 (c) HP PACCTID11350SH7 Software 5.06
Port Address: 50014380-16c2f090
Supported Redundancy Mode: Not Available.
Cache:
144 megabyte read cache 0 megabyte write cache
Cache is GOOD, and Cache is enabled.
No unflushed data in cache.
Battery:
Battery is not reported as present.

Hoff
Honored Contributor

Re: Ultrium 3280 SAS Tape Drive on RX2800 - Restores times very slow

Given the lack of details, I'd suggest starting with the process quotas (as those can hammer performance), then check for and apply patches, then check for a fragmented disk or a near-capacity disk, then call HP support for a look at what you're doing, and to if they can replicate it and resolve it.

 

This could well be a command error, a problem with the hardware configuration, a problem with the hardware, a fragmented disk, or a bug in BACKUP or in a lower-level component.

 

Edit: And I see you have a problem with the hardware configuration.