Hi Steve, Yes... something along the lines of what was done for growth during backups (i.e. the reverse problem):
/ADJUSTKBtsmestimate=numkb /ADJUSTPERcenttsmestimate=numpercent Reference: http://www.ibm.com/support/knowledgecenter/SSER7G_8.1.0/db.sql/dps_ref_opt_backupoptional.html If you get a chance, please open an RFE for this: https://www.ibm.com/developerworks/rfe/?BRAND_ID=352 I recommend making it a generic request (for any type of backup) and cite SQL as the example use case. Thanks! Del ---------------------------------------------------- "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 01/12/2017 08:54:13 AM: > From: "Schaub, Steve" <steve_sch...@bcbst.com> > To: ADSM-L@VM.MARIST.EDU > Date: 01/12/2017 08:54 AM > Subject: Re: ANS1311E (RC11) Server out of data storage space - > container pool > Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> > > Thanks, Del. An interim solution might be a cfg parm that allows us > to specify a percentage of data reduction that TDP would use. So we > could tell TDP to assume a 75% total data reduction to factor into > its calculation. > -steve > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On > Behalf Of Del Hoobler > Sent: Thursday, January 12, 2017 7:47 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] ANS1311E (RC11) Server out of data storage > space - container pool > > Hi Steve, > > It's a great question. Data is a funny thing... it can dedup/ > compress really well one day.. then not very much the next (for > example, if database maintenance or re-orgs are done). > > As it stands right now, Spectrum Protect has to assume it won't > dedup to make sure there is a enough space on the server to hold it. > If Spectrum Protect allowed 2.9TB of your 3TB to be backed up.. then > failed it because "out of space" conditions, IBM would get an APAR > that said... if you knew that backup would fail due to space... why > not fail it right away? > > Making an educated guess (cognitive) is a great idea... i.e. using > historical analysis of previous backups of this database to apply an > algorithm on estimated space needed. > > These (and others) are the types of things Spectrum Protect > development is looking at as we investigate other cognitive ideas to > make the system smarter. > > FYI... there is a Data Protection for SQL 8.1 already available: > > > http://www.ibm.com/support/knowledgecenter/SSER7G_8.1.0/db.sql/ > dps_con_info_whatsnew.html > > > Thank you, > > Del > > ---------------------------------------------------- > > > "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 01/11/2017 > 11:17:24 AM: > > > From: "Schaub, Steve" <steve_sch...@bcbst.com> > > To: ADSM-L@VM.MARIST.EDU > > Date: 01/11/2017 11:17 AM > > Subject: ANS1311E (RC11) Server out of data storage space - container > pool > > Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> > > > > BA client 7.1.3 > > TDP client 7.1.4 > > TSM server 7.1.7 > > > > Doing some testing of SQL TDP with container pools. Getting ~ 95% > > data reduction (client level compression & dedupe). > > Seeing this ANS1311E error on a 3TB database. > > It should barely fit the free space in the container pool if dedupe/ > > compression is ignored, and easily fit once dedupe/compression are > > factored in. > > > > My question is whether there is a client/server version combination > > that is smart enough to know that based on the compress/dedupe a > > backup is getting, to go ahead and attempt the backup? > > Is there a TDP 8.1 coming out anytime soon? > > > > Thanks, > > > > Steve Schaub > > Systems Engineer II, Backup/Recovery > > Blue Cross Blue Shield of Tennessee > > > > > > > ------------------------------------------------------------------------------ > > Please see the following link for the BlueCross BlueShield of > > Tennessee E-mail disclaimer: > > http://www.bcbst.com/email_disclaimer.shtm > > > > ------------------------------------------------------------------------------ > Please see the following link for the BlueCross BlueShield of > Tennessee E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm >
