Re: TSM Tape performance

From: Sanjay Mishra <"Sanjay>
Date: Fri, 29 Apr 2016 14:29:30 +0000
Message-ID: <1413957647.4751590.1461940169052.JavaMail.yahoo_at_mail.yahoo.com>



Freek
Rman using public network are showing better rate and consistent while rman on Dedicated(High speed) sometime ran good but most of the time is bad which is strange. TSM admin mentioned that the issue with Dedicated network is only with RMAN as filesystem backup are running fine as expected from Dedicated network and they test with few full SO level backup and not with incremental. So Strange is that by doing Apple to Apple Comparision for last 4 week where One week with Public  and then dedicated network for whole week, the results are consistent showing Dedicated are 90% inconsistent where one day works fine and next day 5-6time slower than public network.  TxSanjay

    On Friday, April 29, 2016 2:33 AM, Freek D'Hooge <freek.dhooge_at_gmail.com> wrote:  

 reposting to list

Sanjay,

input_bytes_per_sec_display is the throughput for reading from the datafiles and output_bytes_per_sec_display is the throughput towards your backup destination (be it tape or disk) Following documentation link shows an example of a query using this information to the backup speed: http://docs.oracle.com/database/121/BRADV/rcmreprt.htm#BRADV90911

I'm now a little bit confused on the problem. Are you now saying that rman backups using the public network are achieving a good backup rate, but not when using a dedicated (high speed) network? Or is it that rman backups are always slow, but filesystem backups are running fine?

Kind regards,

Freek

On vr, 2016-04-29 at 00:45 +0000, Sanjay Mishra wrote:  Thanks Stefan/Freek/Mladen    

 Point is not about the size and timing. Yes there are several good points in the chain and will also check few important consideration. What I am trying is that why regular Public network backup are running fine while if the same been done using Dedicated high speed interface run sometime good but mostly speed is not even comparable to regular network.    

 eg. is that It take 1 hr for 500G for Incremental(using BCT) on Regular interface  while Dedicated interface is taking sometime 45min for the same but lots of time 4-5hr which is not acceptable to the configuration.     

 Regular Interface always has consistency for the backup size/timing while dedicated interface has big difference and very inconsistent.    

 Can someone help in clearing the difference on these two columns for v$rman_backup_job_details

  •  INPUT_BYTES_PER_SEC_DISPLAY 

-  OUTPUT_BYTES_PER_SEC_DISPLAY 
     I want to compare the rate of using Regular  vs Dedicated backup interface. I had now one node been setup to use regular prod interface and another node with Dedicated vlan. Not sure if the above two column are good to compare and what are the details for these column as not able to get from any Manual/book as what is best to compare. Backup are not compressed.    

 TIA  Sanjay  

 On Thursday, April 28, 2016 1:00 PM, Mladen Gogala <gogala.mladen_at_gmail.com> wrote:      

 Hi Sanjay,  

 My responses are in-line:  

 On 04/27/2016 03:33 PM, Sanjay Mishra (Redacted sender smishra_97 for DMARC) wrote:    

 Hi          

 I had a environment which is 11g R2 RAC and have 15 database running on it. Some are very big double digit terabytes and so rman backup to TSM tape library is taking long time. We worked with TSM and got dedicated vlan backup interface but it is not behaving correctly as sometime backup work good but another backup after one backup take 5-6 time more. If using regular interphase the performance is constant.  Os level backup using dedicated gigabit vlan backup interface is having not issue.  

 1GB LAN is simply too slow to handle double digit TB. What you need is 10GB or better (bonded interfaces). With 1GB NIC, you can reasonably expect between 300 GB/hr and 350 GB/hr. It will take you 3 hours to backup 1TB. With "double digit TB", it will take you triple digits in hours. That will give a new meaning to the notion of weekly backup. However funny it may sound, you should probably do incremental level 1 backup into the FRA and then backup FRA once per week.      

 Only RMAN backup is the issue.  Can someone share any experience as how to monitor and trace the issue. Ticket was opened with Oracle support but they found nothing on both OS (Using OEL) and Database (11.2.0.4). TSM team saying that OS level backup has no issue and it is only rRMAN which is having issue. Moreover RMAN work good sometime but having intermittent issue.          

 So if someone share how they think this can be handled or any of their experience.

 First and foremost, the database of that size should not be run without a standby. The first layer of protection for such a large database should always be a surviving RAC instance. The second layer of protection should be standby and the 3rd layer should be backup. Now, with 20GB/sec, Commvault can achieve 8TB/hr with deduplication and without compression and 9.2 TB/hr  with compression only. The client has opted for deduplication, since the savings in storage are significant. 9GB/hr should be enough to backup a very large 100TB database in about 12 hours. Backups with compression is very CPU intensive, so it should be running on standby db, not the primary one. However, the infrastructure you will need is rather significant. 1 GB LAN will definitely not cut it. If you don't have such a wide pipe, you may consider putting a VTL on the DB server and connect the disk library to the DB server by 16GB F/C controller. VTL will copy it to the tape, when the allocated disk library fills up.  Commvault software suite can do all of the above. However, you will still need good infrastructure                        

 TIA     Sanjay  

 Regards--
Mladen Gogala
Oracle DBA
Tel: (347) 321-1217           

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Apr 29 2016 - 16:29:30 CEST

Original text of this message