Hi,
How many of those filesystem backups are double digit TB?
No offense to the backup guys but a backup that runs quick in 20 minutes or
slow in 40 minutes for a filesystem backup is most likely not going to be
flagged as a problem.
When systems get stretched is when problems start occurring. I have heard
the "it is not us so it must be you" many times before where it ended up
being them after all.
Backups may be going to Disk Pool when fast. but when Disk Pool is small
and fills up with your back up who knows what happens. You may end up
waiting for housekeeping to clear the disk pool most of the time but get
"lucky" every now and than.
This is just a general statement to make sure you don't just focus on RMAN
Jack van Zanen
-------------------------
This e-mail and any attachments may contain confidential material for the
sole use of the intended recipient. If you are not the intended recipient,
please be aware that any disclosure, copying, distribution or use of this
e-mail or any attachment is prohibited. If you have received this e-mail in
error, please contact the sender and delete all copies.
Thank you for your cooperation
On Sat, Apr 30, 2016 at 12:29 AM, Sanjay Mishra <dmarc-noreply@xxxxxxxxxxxxx
wrote:
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.
Tx
Sanjay
On Friday, April 29, 2016 2:33 AM, Freek D'Hooge <freek.dhooge@xxxxxxxxx>
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>
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@xxxxxxxxx> 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
