Hi Steve, We don't want to change existing behavior or any customer using this could break. We won't get into designing it on the ADSM-L. :-)
Thanks for the RFE! Del ---------------------------------------------------- "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 01/12/2017 03:50:44 PM: > From: "Schaub, Steve" <steve_sch...@bcbst.com> > To: ADSM-L@VM.MARIST.EDU > Date: 01/12/2017 03:55 PM > Subject: Re: ANS1311E (RC11) Server out of data storage space - > container pool > Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> > > Del, > I opened an RFE for this, #99603. > Thanks, > -steve > Although now I'm wondering if the 2 couldn't just be merged into one > parm? If the percentage was identifying the estimated percentage of > data sent after data reduction, 25 would tell TSM to take 25% of the > actual data size to use for its calculation, but 125 would basically > tell TSM to calculate based on an increase in the actual size by 25%. > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On > Behalf Of Del Hoobler > Sent: Thursday, January 12, 2017 9:30 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] ANS1311E (RC11) Server out of data storage > space - container pool > > 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 > > > > ------------------------------------------------------------------------------ > Please see the following link for the BlueCross BlueShield of > Tennessee E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm >
