Re: ANS1311E (RC11) Server out of data storage space - container pool
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" wrote on 01/12/2017 03:50:44 PM: > From: "Schaub, Steve" > 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" > > 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" wrote on 01/12/2017 > 08:54:13 AM: > > > From: "Schaub, Steve" > > 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" > > > > 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" wrote on 01/11/2017 > > 11:17:24 AM: > > > > > From: "Schaub, Steve" > > > 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" > > > > > > 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 > > > S
Re: DECOMMISSION NODE
Bummer, I guess I've never tried canceling the process. It sounds like a bug to me, as other processes in TSM are supposed to be transactional and incremental. On Thu, Jan 12, 2017 at 03:44:24PM -0500, Zoltan Forray wrote: > It won't continue. When I canceled the processes, it said something about > undoing the decommissioning. However, when I just tried to restart the > DECOMMISSION NODE, it errors saying the node is already decommissioned? > Looking back in the logs, it says the decommission ended with "completion > state of SUCCESS" (wrong) eventhough I canceled it. Sounds like a bug to > me. Looks like I have to drag out the sledgehammer and delete it manually! > > On Thu, Jan 12, 2017 at 3:05 PM, Skylar Thompson > wrote: > > > The scan portion probably will take the same amount of time, but the > > heavy-hitting part (marking active objects as inactive) should pick up > > where > > it left off. > > > > On Thu, Jan 12, 2017 at 03:00:08PM -0500, Zoltan Forray wrote: > > > This node has >230M objects (both offsite and onsite) and total occupancy > > > of 12TB. It got to ~80M when I had to kill it. Sure wish I knew if it > > was > > > going to start all over again or pick-up where it left off? I have more > > > maintenance on this TSM server scheduled for Tuesday and if it starts all > > > over again, it clearly won't finish by then. > > > > > > On Thu, Jan 12, 2017 at 2:20 PM, Matthew McGeary < > > > matthew.mcge...@potashcorp.com> wrote: > > > > > > > Hello Zoltan, > > > > > > > > I use it every day, mostly because of changes to our VMware environment > > > > (VMs seem to breed like rabbits and die like fruit flies.) It never > > seems > > > > to take much time in those cases, but the object count and data stored > > in > > > > those cases isn't typically very large. > > > > > > > > I've never tried to decomm a node that is TB in size or one that > > contains > > > > millions of objects. > > > > __ > > > > Matthew McGeary > > > > Senior Technical Specialist ??? Infrastructure Management Services > > > > PotashCorp > > > > T: (306) 933-8921 > > > > www.potashcorp.com > > > > > > > > > > > > -Original Message- > > > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf > > Of > > > > Zoltan Forray > > > > Sent: Thursday, January 12, 2017 1:15 PM > > > > To: ADSM-L@VM.MARIST.EDU > > > > Subject: [ADSM-L] DECOMMISSION NODE > > > > > > > > Anyone out there using the DECOMMISSION NODE command? I tried it on an > > > > old, inactive node and after running for 4-days, I had to cancel it > > due to > > > > scheduled TSM server maintenance. > > > > > > > > My issue is, since it was only 35% finished (based on the number of > > > > objects processed), will it start from the beginning or remember where > > it > > > > left off? > > > > > > > > -- > > > > *Zoltan Forray* > > > > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon > > > > Monitor Administrator VMware Administrator (in training) Virginia > > > > Commonwealth University UCC/Office of Technology Services > > www.ucc.vcu.edu > > > > zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and > > other > > > > reputable organizations will never use email to request that you reply > > with > > > > your password, social security number or confidential personal > > information. > > > > For more details visit http://infosecurity.vcu.edu/phishing.html > > > > > > > > > > > > > > > > -- > > > *Zoltan Forray* > > > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator > > > Xymon Monitor Administrator > > > VMware Administrator (in training) > > > Virginia Commonwealth University > > > UCC/Office of Technology Services > > > www.ucc.vcu.edu > > > zfor...@vcu.edu - 804-828-4807 > > > Don't be a phishing victim - VCU and other reputable organizations will > > > never use email to request that you reply with your password, social > > > security number or confidential personal information. For more details > > > visit http://infosecurity.vcu.edu/phishing.html > > > > -- > > -- Skylar Thompson (skyl...@u.washington.edu) > > -- Genome Sciences Department, System Administrator > > -- Foege Building S046, (206)-685-7354 > > -- University of Washington School of Medicine > > > > > > -- > *Zoltan Forray* > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator > Xymon Monitor Administrator > VMware Administrator (in training) > Virginia Commonwealth University > UCC/Office of Technology Services > www.ucc.vcu.edu > zfor...@vcu.edu - 804-828-4807 > Don't be a phishing victim - VCU and other reputable organizations will > never use email to request that you reply with your password, social > security number or confidential personal information. For more details > visit http://infosecurity.vcu.edu/phishing.html -- -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Wash
Re: ANS1311E (RC11) Server out of data storage space - container pool
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" wrote on 01/12/2017 08:54:13 AM: > From: "Schaub, Steve" > 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" > > 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" wrote on 01/11/2017 > 11:17:24 AM: > > > From: "Schaub, Steve" > > 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" > > > > 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_disclaim
Re: DECOMMISSION NODE
It won't continue. When I canceled the processes, it said something about undoing the decommissioning. However, when I just tried to restart the DECOMMISSION NODE, it errors saying the node is already decommissioned? Looking back in the logs, it says the decommission ended with "completion state of SUCCESS" (wrong) eventhough I canceled it. Sounds like a bug to me. Looks like I have to drag out the sledgehammer and delete it manually! On Thu, Jan 12, 2017 at 3:05 PM, Skylar Thompson wrote: > The scan portion probably will take the same amount of time, but the > heavy-hitting part (marking active objects as inactive) should pick up > where > it left off. > > On Thu, Jan 12, 2017 at 03:00:08PM -0500, Zoltan Forray wrote: > > This node has >230M objects (both offsite and onsite) and total occupancy > > of 12TB. It got to ~80M when I had to kill it. Sure wish I knew if it > was > > going to start all over again or pick-up where it left off? I have more > > maintenance on this TSM server scheduled for Tuesday and if it starts all > > over again, it clearly won't finish by then. > > > > On Thu, Jan 12, 2017 at 2:20 PM, Matthew McGeary < > > matthew.mcge...@potashcorp.com> wrote: > > > > > Hello Zoltan, > > > > > > I use it every day, mostly because of changes to our VMware environment > > > (VMs seem to breed like rabbits and die like fruit flies.) It never > seems > > > to take much time in those cases, but the object count and data stored > in > > > those cases isn't typically very large. > > > > > > I've never tried to decomm a node that is TB in size or one that > contains > > > millions of objects. > > > __ > > > Matthew McGeary > > > Senior Technical Specialist ??? Infrastructure Management Services > > > PotashCorp > > > T: (306) 933-8921 > > > www.potashcorp.com > > > > > > > > > -Original Message- > > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf > Of > > > Zoltan Forray > > > Sent: Thursday, January 12, 2017 1:15 PM > > > To: ADSM-L@VM.MARIST.EDU > > > Subject: [ADSM-L] DECOMMISSION NODE > > > > > > Anyone out there using the DECOMMISSION NODE command? I tried it on an > > > old, inactive node and after running for 4-days, I had to cancel it > due to > > > scheduled TSM server maintenance. > > > > > > My issue is, since it was only 35% finished (based on the number of > > > objects processed), will it start from the beginning or remember where > it > > > left off? > > > > > > -- > > > *Zoltan Forray* > > > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon > > > Monitor Administrator VMware Administrator (in training) Virginia > > > Commonwealth University UCC/Office of Technology Services > www.ucc.vcu.edu > > > zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and > other > > > reputable organizations will never use email to request that you reply > with > > > your password, social security number or confidential personal > information. > > > For more details visit http://infosecurity.vcu.edu/phishing.html > > > > > > > > > > > -- > > *Zoltan Forray* > > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator > > Xymon Monitor Administrator > > VMware Administrator (in training) > > Virginia Commonwealth University > > UCC/Office of Technology Services > > www.ucc.vcu.edu > > zfor...@vcu.edu - 804-828-4807 > > Don't be a phishing victim - VCU and other reputable organizations will > > never use email to request that you reply with your password, social > > security number or confidential personal information. For more details > > visit http://infosecurity.vcu.edu/phishing.html > > -- > -- Skylar Thompson (skyl...@u.washington.edu) > -- Genome Sciences Department, System Administrator > -- Foege Building S046, (206)-685-7354 > -- University of Washington School of Medicine > -- *Zoltan Forray* Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon Monitor Administrator VMware Administrator (in training) Virginia Commonwealth University UCC/Office of Technology Services www.ucc.vcu.edu zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
Re: DECOMMISSION NODE
The scan portion probably will take the same amount of time, but the heavy-hitting part (marking active objects as inactive) should pick up where it left off. On Thu, Jan 12, 2017 at 03:00:08PM -0500, Zoltan Forray wrote: > This node has >230M objects (both offsite and onsite) and total occupancy > of 12TB. It got to ~80M when I had to kill it. Sure wish I knew if it was > going to start all over again or pick-up where it left off? I have more > maintenance on this TSM server scheduled for Tuesday and if it starts all > over again, it clearly won't finish by then. > > On Thu, Jan 12, 2017 at 2:20 PM, Matthew McGeary < > matthew.mcge...@potashcorp.com> wrote: > > > Hello Zoltan, > > > > I use it every day, mostly because of changes to our VMware environment > > (VMs seem to breed like rabbits and die like fruit flies.) It never seems > > to take much time in those cases, but the object count and data stored in > > those cases isn't typically very large. > > > > I've never tried to decomm a node that is TB in size or one that contains > > millions of objects. > > __ > > Matthew McGeary > > Senior Technical Specialist ??? Infrastructure Management Services > > PotashCorp > > T: (306) 933-8921 > > www.potashcorp.com > > > > > > -Original Message- > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > > Zoltan Forray > > Sent: Thursday, January 12, 2017 1:15 PM > > To: ADSM-L@VM.MARIST.EDU > > Subject: [ADSM-L] DECOMMISSION NODE > > > > Anyone out there using the DECOMMISSION NODE command? I tried it on an > > old, inactive node and after running for 4-days, I had to cancel it due to > > scheduled TSM server maintenance. > > > > My issue is, since it was only 35% finished (based on the number of > > objects processed), will it start from the beginning or remember where it > > left off? > > > > -- > > *Zoltan Forray* > > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon > > Monitor Administrator VMware Administrator (in training) Virginia > > Commonwealth University UCC/Office of Technology Services www.ucc.vcu.edu > > zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other > > reputable organizations will never use email to request that you reply with > > your password, social security number or confidential personal information. > > For more details visit http://infosecurity.vcu.edu/phishing.html > > > > > > -- > *Zoltan Forray* > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator > Xymon Monitor Administrator > VMware Administrator (in training) > Virginia Commonwealth University > UCC/Office of Technology Services > www.ucc.vcu.edu > zfor...@vcu.edu - 804-828-4807 > Don't be a phishing victim - VCU and other reputable organizations will > never use email to request that you reply with your password, social > security number or confidential personal information. For more details > visit http://infosecurity.vcu.edu/phishing.html -- -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine
Re: DECOMMISSION NODE
This node has >230M objects (both offsite and onsite) and total occupancy of 12TB. It got to ~80M when I had to kill it. Sure wish I knew if it was going to start all over again or pick-up where it left off? I have more maintenance on this TSM server scheduled for Tuesday and if it starts all over again, it clearly won't finish by then. On Thu, Jan 12, 2017 at 2:20 PM, Matthew McGeary < matthew.mcge...@potashcorp.com> wrote: > Hello Zoltan, > > I use it every day, mostly because of changes to our VMware environment > (VMs seem to breed like rabbits and die like fruit flies.) It never seems > to take much time in those cases, but the object count and data stored in > those cases isn't typically very large. > > I've never tried to decomm a node that is TB in size or one that contains > millions of objects. > __ > Matthew McGeary > Senior Technical Specialist – Infrastructure Management Services > PotashCorp > T: (306) 933-8921 > www.potashcorp.com > > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Zoltan Forray > Sent: Thursday, January 12, 2017 1:15 PM > To: ADSM-L@VM.MARIST.EDU > Subject: [ADSM-L] DECOMMISSION NODE > > Anyone out there using the DECOMMISSION NODE command? I tried it on an > old, inactive node and after running for 4-days, I had to cancel it due to > scheduled TSM server maintenance. > > My issue is, since it was only 35% finished (based on the number of > objects processed), will it start from the beginning or remember where it > left off? > > -- > *Zoltan Forray* > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon > Monitor Administrator VMware Administrator (in training) Virginia > Commonwealth University UCC/Office of Technology Services www.ucc.vcu.edu > zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other > reputable organizations will never use email to request that you reply with > your password, social security number or confidential personal information. > For more details visit http://infosecurity.vcu.edu/phishing.html > -- *Zoltan Forray* Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon Monitor Administrator VMware Administrator (in training) Virginia Commonwealth University UCC/Office of Technology Services www.ucc.vcu.edu zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
Re: DECOMMISSION NODE
We recently ran it on a node with ~6 million objects, and it worked fine. I think it ran for about an hour before completing, but it definitely thrashed the database. On Thu, Jan 12, 2017 at 02:14:37PM -0500, Zoltan Forray wrote: > Anyone out there using the DECOMMISSION NODE command? I tried it on an > old, inactive node and after running for 4-days, I had to cancel it due to > scheduled TSM server maintenance. > > My issue is, since it was only 35% finished (based on the number of objects > processed), will it start from the beginning or remember where it left off? > > -- > *Zoltan Forray* > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator > Xymon Monitor Administrator > VMware Administrator (in training) > Virginia Commonwealth University > UCC/Office of Technology Services > www.ucc.vcu.edu > zfor...@vcu.edu - 804-828-4807 > Don't be a phishing victim - VCU and other reputable organizations will > never use email to request that you reply with your password, social > security number or confidential personal information. For more details > visit http://infosecurity.vcu.edu/phishing.html -- -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine
Re: DECOMMISSION NODE
Hello Zoltan, I use it every day, mostly because of changes to our VMware environment (VMs seem to breed like rabbits and die like fruit flies.) It never seems to take much time in those cases, but the object count and data stored in those cases isn't typically very large. I've never tried to decomm a node that is TB in size or one that contains millions of objects. __ Matthew McGeary Senior Technical Specialist – Infrastructure Management Services PotashCorp T: (306) 933-8921 www.potashcorp.com -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Zoltan Forray Sent: Thursday, January 12, 2017 1:15 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] DECOMMISSION NODE Anyone out there using the DECOMMISSION NODE command? I tried it on an old, inactive node and after running for 4-days, I had to cancel it due to scheduled TSM server maintenance. My issue is, since it was only 35% finished (based on the number of objects processed), will it start from the beginning or remember where it left off? -- *Zoltan Forray* Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon Monitor Administrator VMware Administrator (in training) Virginia Commonwealth University UCC/Office of Technology Services www.ucc.vcu.edu zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
DECOMMISSION NODE
Anyone out there using the DECOMMISSION NODE command? I tried it on an old, inactive node and after running for 4-days, I had to cancel it due to scheduled TSM server maintenance. My issue is, since it was only 35% finished (based on the number of objects processed), will it start from the beginning or remember where it left off? -- *Zoltan Forray* Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon Monitor Administrator VMware Administrator (in training) Virginia Commonwealth University UCC/Office of Technology Services www.ucc.vcu.edu zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
Re: 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" wrote on 01/12/2017 08:54:13 AM: > From: "Schaub, Steve" > 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" > > 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" wrote on 01/11/2017 > 11:17:24 AM: > > > From: "Schaub, Steve" > > 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" > > > > 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 >
Re: ANS1311E (RC11) Server out of data storage space - container pool
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" wrote on 01/11/2017 11:17:24 AM: > From: "Schaub, Steve" > 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" > > 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
Re: 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" wrote on 01/11/2017 11:17:24 AM: > From: "Schaub, Steve" > 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" > > 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 >
Re: restructuring tsm db into several smaller filesystesm
Hi Gary Here, the corresponding documentation : http://www-01.ibm.com/support/docview.wss?uid=swg1IC78489 http://www-01.ibm.com/support/docview.wss?uid=swg21611157 Cheers. Arnaud -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Krzysztof Przygoda Sent: Thursday, January 12, 2017 11:55 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: restructuring tsm db into several smaller filesystesm Hi Gary You can do it backup .. drop .. restore way but you might also try way which is possible to be done even on working server. 1. add new storage paths by extend dbspace 2. from db2 run rebalance on each tablespace eg: db2 alter tablespace LARGESPACE1 rebalance and then reduce max on each: db2 alter tablespace LARGESPACE1 reduce max 2. from db2 drop old space with : alter database drop storage on '/bla/bla', '/bla/bla' (dont worry what it does is to leave data and just doesn't write new data to the disk) 3. db2 rebalance/reduce on each tablespace again 4. In the end old dbspaces should shrink to some initial size (like 1GB or so) and will disappear at next restart. You will not find this solution in tsm manuals (dont know why?) but its tested and working:) Keep in mind that some tricky rebalance rules come in place here (like to rebalance 1G tablespace into two 500M on new path you have to provide 1G initially to have it even started) so if you want to spread some big tablespaces into many small ones its recommended to do it in few loops... Have Fun Krzysztof Przygoda 2016-12-30 15:02 GMT+01:00 Lee, Gary : > TSM server 6.3.4 > Running on RHEL 6.7 > > Finally received a 24 drive disk shelf to attach to my tsm server. > Now want to move the db from a single mirrored disk pair to four smaller > raided disks to gain speed. > > I can add the new directories easily enough, but how to remove the old db > directory to re-use the disk space? >
Re: restructuring tsm db into several smaller filesystesm
Hi Gary You can do it backup .. drop .. restore way but you might also try way which is possible to be done even on working server. 1. add new storage paths by extend dbspace 2. from db2 run rebalance on each tablespace eg: db2 alter tablespace LARGESPACE1 rebalance and then reduce max on each: db2 alter tablespace LARGESPACE1 reduce max 2. from db2 drop old space with : alter database drop storage on '/bla/bla', '/bla/bla' (dont worry what it does is to leave data and just doesn't write new data to the disk) 3. db2 rebalance/reduce on each tablespace again 4. In the end old dbspaces should shrink to some initial size (like 1GB or so) and will disappear at next restart. You will not find this solution in tsm manuals (dont know why?) but its tested and working:) Keep in mind that some tricky rebalance rules come in place here (like to rebalance 1G tablespace into two 500M on new path you have to provide 1G initially to have it even started) so if you want to spread some big tablespaces into many small ones its recommended to do it in few loops... Have Fun Krzysztof Przygoda 2016-12-30 15:02 GMT+01:00 Lee, Gary : > TSM server 6.3.4 > Running on RHEL 6.7 > > Finally received a 24 drive disk shelf to attach to my tsm server. > Now want to move the db from a single mirrored disk pair to four smaller > raided disks to gain speed. > > I can add the new directories easily enough, but how to remove the old db > directory to re-use the disk space? >
Re: protect stg + replicate node
I would always go for the protect stgpool and replicate node combination if storagepool layout allows, it's faster and during protect stgpool you have less databack locking so less issues with other processes. On Wed, Jan 11, 2017 at 5:13 PM, rou...@univ.haifa.ac.il < rou...@univ.haifa.ac.il> wrote: > Hi to all > > A question to people using PROTECT STG and REPLICATE NODE what will be > the best practice to use in the target side for STGPOOL > > One STG for the protect stg and another STG for the replicate nodes , or > only one for everything ??? > > Both TSM servers version 7.1.7 with O.S Windows 2012 64B > > Best Regards > > Robert >
