Bad restore performances with TDP for SAP

[benoit16]

Hello,

May you answer my two previous questions:
What is backom?
On your side, which bandwidth do you get, per tape drive, when you backup and restore?

Thanks in davnce for your answers.

 

[moon-buddy]

They managed to back it up at 1.6TB per hour.

This is backup to disk - not tape.

Remember also that this is TDP not the BA client so it will behave a little different.

I know this TDP and that is why in a classic setup: node --> disk --> tape, restores will be a lot slower except when you are running LAN Free, or cache data on disk. Restore will likewise be slow from copy tapes (DR scenario).

I think you are missing some points of my discussion/posts.

My experience with the TDP is with DB2 so the config may be different for Oracle.

There should be no difference with how TDP for DB2 and TDP for Oracle behaves in general except that the API for TSM is built into DB2 and there is no need to install one.

 

[DazRaz]

Ah, ok. Didn't pick up that it was going to disk first. Multiple sessions would be difficult to get the restores consistent as there is no guarantee when the data is migrated to tape that the individual sessions would end up on different tapes. This would mean that some restore sessions are likely to have long periods of wait for tape.

 

[DazRaz]

What is backom?
On your side, which bandwidth do you get, per tape drive, when you backup and restore?

Backom is the command used with the DB2 TDP.

1.2TB per hour across 3 tape drives so 400GB per hour on LTO5 through a 10G network.

When it comes down to it, you know you can transfer 1.6TB per hour from Oracle to TSM. We can assume you can do the same TSM to Oracle. If you want to speed restores then backup LAN free to multiple tapes would be best. Using network to backup to multiple tapes should still be good when it comes to restore.

 

[hogmaster]

Hi.
Before you next restore test make sure that you send your data directly to tape.

What may casuse your performance problem while using a disk cache (staging area) is the data is migrated from disk to tape in the "wrong" order. Rman (Oracle/SAP) is requesting files in the same order as they were written to the backup system. THe use of a staging disk in this case may affect the restore.

After completing the above test you should evaluate the result. If the performance is better you can use collocate=filespace on the tape stg pool and repeat the test but send the data to the disk first.

Please give feedback during your test and we can help with more alternatives.
/hogmaster

 

[moon-buddy]

What may cause your performance problem while using a disk cache (staging area) is the data is migrated from disk to tape in the "wrong" order. Rman (Oracle/SAP) is requesting files in the same order as they were written to the backup system. The use of a staging disk in this case may affect the restore.
/hogmaster

It is my understanding that the order for DB backups is maintained correctly by TSM when it writes to tape. Data tags are provided with each backup stored on disk such that when writing to tape, the sequential Data tags are observed and ordered correctly.

It is more of the way tape transfers data - fixed block (in most cases), CRC, mechanical pauses, etc. - that contributes to slow restores. I have obesrved tape drive movements when restoring from tape. No rewinds, just forward motions meaning data is stored sequentially correct.

 

[hogmaster]

Hi.
If you send 4 streams of data (think MS SQL backup with stripes). Then the data is migrated to 2 tapes.
Now when we we try to do a retore the application is asking for the files. TSM will deliver the data to the application.
THe data is delivered in the order the application is asking for it, this may mean that you have to skip a lot of data on the tape.

/Hogmaster