RE: Backing up large DBs on ASM
- From: "Kenneth Naim" <kennaim@xxxxxxxxx>
- To: <John.Hallas@xxxxxxxxxxxxxxxxxx>, <Amir.Hameed@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 23 Jun 2009 04:55:13 -0400
The first task is to determine the bottleneck using v$backup_async_io and
v$backup_sync_io. The views map nicely to rman backupsets and with a little
analysis any performance issues will be revealed. To test the maximum
throughput of your server vs your storage/network you can run the rman
commands "RESTORE DATABASE VALIDATE" "BACKUP DATABASE VALIDATE". If the
backup validate runs much faster than your refular backup with everything
else being equal ( parallelism, load etc.) then your bottleneck is on your
network (ethernet/fiber cards, switches etc.) or tape library, if it is
slower than your issue is either with your server (parallelism, cpu, memory
etc.) or with your disk drives (data not being spread out relative to the
reads). I did the research on a similar issue for a client that had an
uncooperative OS team and with minimal info about the hardware setup I was
able to determine that it was their network using the 2 v$views mentioned
above. It turns out they were using shared gigabit Ethernet to backup a 7Tb
database and they were scheduled to buy more ram to solve this issue since
ram was showing above 80% utilized on a sun box during the backups. Once I
proved the issue they took the server and directly attached it to the tape
library with multiple 2gb fiber paths, reducing the backup time from 30
hours to under 5. Feel free to contact me off list if you want more details.
Ken
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of John Hallas
Sent: Tuesday, June 23, 2009 3:30 AM
To: Amir.Hameed@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: Backing up large DBs on ASM
Is this a DW by any chance. If so then use of readonly tablespaces with the
skipreadonly clause in the RMAN command should help reduce volume (combined
with a long-term retention policy on the tapes of course).
Cumulative backups (level 1) and use of a block change tracking file should
be investigated.
I am surprised it is not quicker to disk than tape. Are you using multiple
channels.
John
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Hameed, Amir
Sent: 22 June 2009 03:50
To: oracle-l@xxxxxxxxxxxxx
Subject: Backing up large DBs on ASM
Folks,
One of our large client has a very large DB (~40TB) configured with ASM.
They are currently using RMAN to back it up to tape and it takes a very
long time to do that. They have also tried backing up to disk but the
timing has not really improved much. What they are looking for is ways
to speed up the backup and restore timing. I am not directly involved
with this client and do not have extensive experience with ASM and RMAN
either. Are their any ways and best practices to speed up backups on ASM
for very large DBs. Any feedback will be greatly appreciated.
Thanks
Amir
--
//www.freelists.org/webpage/oracle-l
______________________________________________________________________
Wm Morrison Supermarkets Plc is registered in England with number 358949.
The registered office of the company is situated at Gain Lane, Bradford,
West Yorkshire BD3 7DL. This email and any attachments are intended for the
addressee(s) only and may be confidential.
If you are not the intended recipient, please inform the sender by replying
to the email that you have received in error and then destroy the email.
If you are not the intended recipient, you must not use, disclose, copy or
rely on the email or its attachments in any way.
Wm Morrison Supermarkets PLC accepts no liability or responsibility for
anything said in the email or its attachments and gives no warranty as to
accuracy. It is the policy of Wm Morrison Supermarkets PLC not to enter into
any contractual or other obligations by email.
Although we have taken steps to ensure the email and its attachments are
virus-free, we cannot guarantee this or accept any responsibility,
and it is the responsibility of recipients to carry out their own virus
checks.
______________________________________________________________________
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
