Thanks all for the helpful reply's. It's going to be option 3 due to TDP compatibility and the extreme cost of upgrading Oracle in this setup (application rebuild that is going to be replaced in 2-3 years). I have no say in this, I think I would risk it an go with the TDP without support since it worked well for the past 4-5 years but the wheel are in motion.
So both Oracle logs and db's can be 'dumped' to disk via rman and picked up with the B/A client to be restored via the B/A client to disk and then restored back to Oracle, that is basically the message. It can be done but takes a lot of good (errors need to be caught, lock files, etc) scripting, testing and more than 2x the disk space currently in use by Oracle due to DB dump and logs that need to be dumped to their backup location on disk. Thanks again. Stefan On Fri, Sep 13, 2013 at 6:57 AM, Grigori Solonovitch < [email protected]> wrote: > There are next ways to backup Oracle databases using TSM: > 1) using RMAN + TDPO + TSM Client to TSM server by periodic full backups > and incremental backups on other days; > 2) using RMAN + DDBoost to Data Domain by periodic full backups and > incremental backups on other days with Data Domain de-duplication; > 3) using RMAN to local disk with following backup of flat files to TSM > Server using TSM Client; > 4) using direct TSM backup for Oracle database files using TSM Client > (offline backup). > The first option is a classical TSM backup for Oracle databases with quite > solid expenses for licenses, but most reliable in comparison with other > options. We are using this way for many years and I can provide complete > set of required scripts for Unix environment (contact me by direct E-mail); > The second option is the fastest way to backup Oracle databases directly > to external Data Domain storage. RMAN is free (part of Oracle license), but > you need to pay for Data Domain system itself with DDBoost and > de-duplication licenses (maybe 10Gb/s network is required as well for > mentioned capacity). According to stated Oracle database size this is > preferable option (in my opinion). > The third option is almost impossible to use due to huge disk space > requirements (more than double capacity is required on local disks). It can > be used only if disk space is not a problem for customer. > The forth option can be used for small databases and for not 24/7 > applications. > > Grigori Solonovitch, Senior Systems Architect, IT, Ahli United Bank > Kuwait, www.ahliunited.com.kw > > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of > Stefan Folkerts > Sent: 12 09 2013 4:26 PM > To: [email protected] > Subject: [ADSM-L] Oracle v9 backup and restore without TDP > > Hi guy's, > > A customer of ours is investigating cutting out the Oracle TDP for Oracle > v9 and replacing it with rman backups to disk that get picked up by the > TSM B/A client. > > I am wondering if people here are doing this already. > > I'm no Oracle or rman man but I wonder if you can create a workable > environment with scripting and procedures, I understand we need disk space > for the 'dumps' to disk and some space to stage the restore from TSM before > it goes back to Oracle. > > But how about archive log backups and how to go about telling rman a > backup is back on another disk ready to restore to Oracle. > Can you script the name of the backups with rman and is this usually done > with the B/A archive function or the backup function. > I can image that the Oracle naming might be an issue. > > If anybody here could give me some pointers that would be great, it's a > fairly large Oracle environment with full backups of more than 40TB's and > single database or multiple TB's. > > Regards, > Stefan > > > > Please consider the environment before printing this Email. > > ________________________________ > > CONFIDENTIALITY AND WAIVER: The information contained in this electronic > mail message and any attachments hereto may be legally privileged and > confidential. The information is intended only for the recipient(s) named > in this message. If you are not the intended recipient you are notified > that any use, disclosure, copying or distribution is prohibited. If you > have received this in error please contact the sender and delete this > message and any attachments from your computer system. We do not guarantee > that this message or any attachment to it is secure or free from errors, > computer viruses or other conditions that may damage or interfere with > data, hardware or software. >
