RE: Backing up large DBs on ASM
Date: Tue, 23 Jun 2009 04:55:13 -0400
Message-ID: <02a301c9f3e0$52f0dab0$f8d29010$_at_com>
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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of John Hallas
Sent: Tuesday, June 23, 2009 3:30 AM
To: Amir.Hameed_at_xerox.com; oracle-l_at_freelists.org
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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Hameed, Amir
Sent: 22 June 2009 03:50
To: oracle-l_at_freelists.org
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
--
http://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.
--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jun 23 2009 - 03:55:13 CDT