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 AT VM.MARIST DOT EDU> wrote on 01/12/2017
03:50:44 PM:
> From: "Schaub, Steve" <Steve_Schaub AT BCBST DOT COM>
> To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On
> Behalf Of Del Hoobler
> Sent: Thursday, January 12, 2017 9:30 AM
> To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU> wrote on 01/12/2017
> 08:54:13 AM:
>
> > From: "Schaub, Steve" <Steve_Schaub AT BCBST DOT COM>
> > To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On
> > Behalf Of Del Hoobler
> > Sent: Thursday, January 12, 2017 7:47 AM
> > To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU> wrote on 01/11/2017
> > 11:17:24 AM:
> >
> > > From: "Schaub, Steve" <Steve_Schaub AT BCBST DOT COM>
> > > To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT 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
>
|
