ADSM-L

Re: [ADSM-L] ANS1311E (RC11) Server out of data storage space - container pool

2017-01-12 15:56:52
Subject: Re: [ADSM-L] ANS1311E (RC11) Server out of data storage space - container pool
From: "Schaub, Steve" <Steve_Schaub AT BCBST DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 12 Jan 2017 20:50:44 +0000
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