Restore Takes long time

[Mahmoud_1]

Dear All,
I have two SDLT Tapes attached to two Alpha Servers ES45 clustered on HSG80, Running OpenVMS 7.3-2 and Oracle RAC 9.2.0.5 .
Problem is when a failure occurred we need more than 20 hours to restore 100gb.
Note the disks formatted as ODS-5.
I tried to restore the data on another system with disks formated as ODS-2 it takes only 3 hours.
Oracle is not my responsibility in this site.

Any OpenVMS suggestions will be appreciated.
Regards

[Marc Van den Broeck]

Mahmoud,

I have done some testing with ods-2 and ods-5 and found no difference in speed while copying files.
But, I found differnces between a mirror set and a raid-5. Copying to the raid-5 took 2 times longer.
So, can you check whether you are using mirrored discs are raid?
But even then a factor of almost 7 has to have another cause. Or you using the same tape device?

Rgds
Marc

[Mahmoud_1]

OK Van,
I have Data on raid-5 and raid-1.
I have same case on singl Systems (DS25,ES40,ES45) with no raid.
Regards.

[Wim Van den Wyngaert]

Are there FDDI shadow disks (or other slow connections ? What tape drive did you use in both tests ? What process quotas for the users that did the test ?

Wim

[Volker Halle]

Mahmoud,

in general, performance problems are hard to discuss and speculate about in a forum like this.

As you can see from the questions raised already, you need to provide a lot of data and details about your performance problem, if you expect more than just more questions and speculation.

You need to describe:

- the command(s) used
- the HW config involved (down to the disk/tape layer)

Volker.

[Jan van den Ende]

Mahmood,

Do the ODS-5 disks have High-watermarking enabled?
It _IS_ the default, and so easily overlooked.
That WOULD explain slowdown of this magnitude.

If yes, do you REALLY need it?
$ SET DEVICE xxx/NOHIGH will help here.

Worth checking...

Proost.

Have one on me.

jpe

[Mahmoud_1]

Dear All,
In fact I dont have shadow disks or volumes.
About the backup command its simple:
$backup/log/image/ignore=(inter,nobackup) $1$dga30: mkb500:disk3.bck
and the restore its the same.

Regards.

[Wim Van den Wyngaert]

As Volker said, we are missing a lot of data.
Also on controller level there are settings that can influence performance.

Wim

[Mahmoud_1]

Thanks all for fast response,
I will returne to the site HW Engineer for more information about the HW configuration.
Regards.

[Mahmoud_1]

Hi to All,
H/W enginer sent me the Tape specifications:
KZPBA-CA SE SCSI Controller
HP SDLT 160/320GB Tape Drive

Best Regards.

[Antoniov.]

Hi Mahmoud,
I'm not sure KZPBA-CA SE can run Ultra Wide3 SCSI (160Mbs); it appear as Ultra Wide (40Mbs) that's 4 times slower than your tape driver.

Antonio Vigliotti

[Antoniov.]

For for example,
you can see in island page http://www.islandco.com/scsi.html
KZPBA-CA is not ultra160 like IC-KZPEA-DB or 3X-KZPEA-DB

Antonio Vigliotti

[Veli Körkkö]

how about adding

/BLOCKSIZE=61440

to your backup command. It might make the backups pretty much faster and will also help restores.

_veli

[comarow]

There is a real problem is cache on SAN devices. It thrashes. Try reducing the diolm to 32. Note that xwindows won't start.

[comarow]

I'll add that if you must use xwindows the min is 100, but if you can do it in batch keep diolm below 32 even as low as 4 to prevent the san from thrashing.

[Mahmoud_1]

Hi,
In fact I passed all information to my customer site engineer, I am waiting.
I will Assigne points regarding to the solution.
.
Dear Comarow,
I want to inform you that the problem as i mentioned is on both SAN and local disks attached on single machine.

Best Regards.

[Emad Omar]

Dear all,

Thank you for your kind replies. But I need to clear something which it is very imporatnt to all of you. SDLT 160/320 Tape Drive has an Ultra 2 SCSI LVD Interface. This means that speed of the I/O will not exceed more than 80 MB/s even used Ultra 3 SCSI Controller. Therefore the Ultra 2 SCSI Controller (KZPCA-AA) is a good choice for using these SDLT Tape Drives on Alpha Servers.

On other hand I noticed that this problem was appeared at SAN/Cluster environment and also at Single Servers. So thinking on SAN configuration is putting aside.