In my experience, reporting the space usage (cost)  of each RMAN instance
is the only way we can force them to expire backups.  Even then, it's only
administrative recommendations. As a result, I don't allow Oracle on our
disk-based backups.   In our environment, we need to maintain expiration
control if we are to allow something into the disk-backups.


Regards,
Shawn
________________________________________________
Shawn Drew





Internet
robert_clark AT MAC DOT COM

Sent by: ADSM-L AT VM.MARIST DOT EDU
08/27/2010 11:32 AM
Please respond to
ADSM-L AT VM.MARIST DOT EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] Data Domain: Data Domain, and SQL-Backtrack with Sybase
databases






I've recently been in an environment that went from very old slow low
capacity tape to slightly faster CDL/EDL. (VTL access being the only
choice in that case.)

EMC buying DD put DD on the inside track for doing proof of concepts for
things like replacing TSM/LanFree/EDL with RMAN over NFS to DD.

This use of DD reminds me of NAS. By that I mean that instead of the TSM
admin being on the hook for managing capacity and availability of TSM
pools, whoever admins the DD will need to work with the DBAs to make sure
they understand how close they are to running out of capacity at any given
point. Not being able to set nextpool to tape may make the DD less
forgiving with regards capacity forecasting.

It sounds like any given DD is going to be setup as one large pool. This
would seem to put the capability for reporting who is using what back on
the DBAs.(And the distinction of logical/physical usage sounds like a
headache.) Without TSM in the picture, there is no "query occupancy"
command to fall back on.

It is going to be interesting.

[RC]


On Aug 27, 2010, at 08:17 AM, Richard Rhodes <rrhodes AT FIRSTENERGYCORP DOT 
COM>
wrote:

> We don't have DD or any other dedup box . . .but we think about them a
lot.
>
> This has been one or our ongoing discussions. Our big database servers
that
> use rman/tdpo/lanfree.
> If we could get enought throughput with straight ethernet or 10g
ethernet,
> then we could ditch
> tdpo/lanfree and use straight rman to disk over NFS to the dedup box.
> The only value in tdpo/lanfree/vtl seems to be SAN speed. I wonder what
> the trade off is
> between tdpo/lanfree licensing and 10g ethernet adapters and switch
> ports . . . . hmmmm.
>
> Rick
>
>
>
>
>
>
> "Hart, Charles A"
> <charles_hart@UHC
> .COM> To
> Sent by: "ADSM: ADSM-L AT VM.MARIST DOT EDU
> Dist Stor cc
> Manager"
> <[email protected] Subject
> .EDU> Re: Data Domain: Data Domain, and
> SQL-Backtrack with Sybase databases
>
> 08/27/2010 09:32
> AM
>
>
> Please respond to
> "ADSM: Dist Stor
> Manager"
> <[email protected]
> .EDU>
>
>
>
>
>
>
> I could be shot for saying the following, but using a NFS share would
> provide the opportunity for you to remove the backup application and its
> associates hardware from the data protection stack altogether for things
> such as data bases which in some shops is 80% of the load.
>
> We are avid TSM users and fans but if RMAN backups directly to NFS
> mounts works well it appears there would be an opportunity reducing
> complexity and costs.
>
> Charles
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Nobody
> Sent: Thursday, August 26, 2010 5:18 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Data Domain: Data Domain, and SQL-Backtrack with
> Sybase databases
>
> The last time I checked <10% of DD customers use the VTL option. I'm
> willing to bet that 60-80% of those are TSM customers. The TSM folks
> I've
> talked to seem to prefer using VTL over file-type devices, which may
> explain that. The rest of the world (except large enterprise customers)
> tends to prefer NAS devices.
>
> On Thu, Aug 26, 2010 at 1:38 PM, ADSM-L <tsm AT networkc.co DOT uk> wrote:
>
> > Curtis,
> >
> > >> Data Domain has good market share, but very few DD customers use
> VTL.
> >
> > Really? That surprises me a little (i.e., the marginalised VTL usage)
> > and isn't necessarily representative of the TSM customers I've spoken
> > to or worked with using DDRs, many of whom still use the VTL
> > functionality. I can't comment on whether this is so much the case
> > with shops that use other backup software though (e.g., I know NBU has
> its own OST interface).
> >
> > In any case, whether through VTL or NFS/CIFS the principle is the same
>
> > and of course you're right, pre-appliance compression or even
> > encryption can be catastrophic to data de-dupe ratios. Without knowing
>
> > any more, it sounds like you may have to make a compromise somewhere
> > without changing your current config Nancy, either in terms of backup
> > data storage footprint or RPO.
> >
> > Cheers,
> > __________________
> > David McClelland
> > London, UK
> >
> > On 26 Aug 2010, at 19:10, Nobody <wcplists1 AT GMAIL DOT COM> wrote:
> >
> > > Data Domain has good market share, but very few DD customers use
> > > VTL.
> >
>
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the
intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
>
>
>
> -----------------------------------------
> 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.



This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.