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 [email protected] Sent by: [email protected] 08/27/2010 11:32 AM Please respond to [email protected] 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 <[email protected]> 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_h...@uhc > .COM> To > Sent by: "ADSM: [email protected] > 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:[email protected]] On Behalf Of > Nobody > Sent: Thursday, August 26, 2010 5:18 PM > To: [email protected] > 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 <[email protected]> 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 <[email protected]> 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.
