The tightly coupling between Oracle/Rman backups into TSM that TDP provides
is both
a strength and weakness. Strength -> as you indicate, it saves local
backup areas.
Weakness -> backups/restores require TSM. If TSM is down, backups and/or
restores
do not occur.
We use a mixture of these methods (although currently our "TDP" backps are
HP Omniback with
it's integration software - to be replaced with TSM/TDP next year). It's
conforting to know
that when TSM is down, Oracle backups just keep working to their local disk
areas. Also,
our Oracle databases are supposed to have archive log space for 24hours of
operations.
One of the issues I fight is that it's tough to convince people that TSM
isn't perfect. The DBAs
think (as well as eveyone who does backups to TSM) that once they send
something to TSM (like
an archive log) that it is "SAFE". I try to explain that it is entirely
possible for TSM to loose their
backup until the following occurs: a second copy is made of the backup
(copy pool), the second
copy is offsite, and, a backup of the tsm db that contains the backup is
made and is offsite
(incremental/full, whichever mode you're in). I just had this discussion
with our firewall folks.
Due to regulations, they simply cannot loose a firewall log. They though
that once they sent
them to TSM they could delete them. I told them "no", they needed to hold
on to them for
about 24hr to give TSm time to make a second copy, get a db backup, and
get copies offsite.
Rick
Steven Harris
<steve@STEVENHARR
IS.INFO> To
Sent by: "ADSM: ADSM-L AT VM.MARIST DOT EDU
Dist Stor cc
Manager"
<[email protected] Subject
.EDU> Re: RMAN without TDP.
11/27/2006 06:54
PM
Please respond to
"ADSM: Dist Stor
Manager"
<[email protected]
.EDU>
Guys,
DBAs will always want to do the simplest thing that is completely under
their control. This is human nature because if they ever get caught
without a backup the blame will fall on them. They don't want to trust
any one or any thing else.
You need to prove the TDP with extensive testing, and re-prove it
regularly with different tests on different databases so that they build
up a level of trust with the product and its reliability.
Only then can you point out that TSM can use disk pools, sequential
files and tapes in a far more efficient and effective manner than
allocating individual dump areas on every database server. At that
point management will leap at the savings in their ever expanding disk
farm and your DBAs won't have leg to stand on. TSM wins the war again.
Regards
Steve
Steven Harris
AIX and TSM Admin
Brisbane Australia
William Sherrill wrote:
> Larry,
>
> I have worked on accounts that use RMAN to create backups to files.
> We then typically use TSM ba client to do archives or backups of the
files
> which can allow you to provide retentions and offsite copies. I preffer
> archives so the data is retained for a set length of time. If there is
> enough space on your sata drives that are assigned to the database server
> then you can literally just let rman create as many backups as you have
> space. RMAN is an oracle tool and the TDP for Oracle allows the RMAN to
> tie into TSM.
>
>
>
> We were setting up the TDP for Oracle for the DBA's.
> We are also adding a SAN.
> The DBA's have said that with disk based backups (which
> we are moving to with the SATA drives), they can use
> RMAN without TSM.
> I do not know enough about RMAN to know if that is true.
>
> Any one out there that has a SAN and Oracle and just
> backs up to disk without TSM.
>
> Preiviously we used SQL-BACKTRACK and TSM for Oracle.
>
>
>
>
> The information contained in this electronic message and any attachments
to
> this message are intended for the exclusive use of the addressee(s) and
may
> contain information that is confidential, privileged, and/or otherwise
> exempt from disclosure under applicable law. If this electronic message
is
> from an attorney or someone in the Legal Department, it may also contain
> confidential attorney-client communications which may be privileged and
> protected from disclosure. If you are not the intended recipient, be
> advised that you have received this message in error and that any use,
> dissemination, forwarding, printing, or copying is strictly prohibited.
> Please notify the New York State Thruway Authority immediately by either
> responding to this e-mail or calling (518) 436-2700, and destroy all
copies
> of this message and any attachments.
>
>
>
-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.
|
