Re: EXPIRE INVENTORY in TSM 6.3.6
My experience (which confounded IBM) is the expires would never end (let it run for over 9-days) even when picking a single node to expire. I was restarting the TSM server on a daily basis, it not multiple times a day - especially when I was going the expires 1-by-1 to determine which nodes were causing the lockups (the expiration would not cancel). Before were decided to push ahead with the upgrades to 7.1.6.300, I had written a server script with single expire statements for each node, exluding 8-troublemakers - i.e. the ones that would never complete. On Fri, Nov 11, 2016 at 3:40 AM, Henrik Ahlgren <pa...@seestieto.com> wrote: > Thanks. I think the reason why EXPIRE INVENTORY without NODES only seems > to expire a small amount of nodes is that it tries to continue where it > left the last time it stopped – if you happen to normally run expire > with DURATION= limitation. If TSM cancels the expire process > after duration is exceeded, it does not emit any errors or warnings > (unlike ANR4927W for reclamations) to the activity log, so this can > easily go unnoticed for few days unless there is a specific monitoring > for slow expires in place. > > On Thu, 2016-11-10 at 14:59 -0500, Zoltan Forray wrote: > > Here is the 6.3.6.000 expiration problem APAR description: > > > > IT17642: SLOW EXPIRATION AFTER UPGRADE TO 6.3.6.000 SERVER > > > > APAR status - OPEN - > > > > *Error description* > > After upgrading the server to 6.3.6.000 (or higher) and 7.1.3(or higher) > > expiration might "hang" on a node while expiring backup data only. > > Expiration is not actually hung it is still processing but very slowly > due > > to a non-optimized SQL/Select. A change to this SQL/Select occurred > > between 6.3.5.0 and 6.3.6.0. This code change was implemented in servers > > 6.3.6.0+ and 7.1.3.0 to 7.1.7. There have been no reported problems at > > 7.1.3 or above. > -- *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: EXPIRE INVENTORY in TSM 6.3.6
Thanks. I think the reason why EXPIRE INVENTORY without NODES only seems to expire a small amount of nodes is that it tries to continue where it left the last time it stopped – if you happen to normally run expire with DURATION= limitation. If TSM cancels the expire process after duration is exceeded, it does not emit any errors or warnings (unlike ANR4927W for reclamations) to the activity log, so this can easily go unnoticed for few days unless there is a specific monitoring for slow expires in place. On Thu, 2016-11-10 at 14:59 -0500, Zoltan Forray wrote: > Here is the 6.3.6.000 expiration problem APAR description: > > IT17642: SLOW EXPIRATION AFTER UPGRADE TO 6.3.6.000 SERVER > > APAR status - OPEN - > > *Error description* > After upgrading the server to 6.3.6.000 (or higher) and 7.1.3(or higher) > expiration might "hang" on a node while expiring backup data only. > Expiration is not actually hung it is still processing but very slowly due > to a non-optimized SQL/Select. A change to this SQL/Select occurred > between 6.3.5.0 and 6.3.6.0. This code change was implemented in servers > 6.3.6.0+ and 7.1.3.0 to 7.1.7. There have been no reported problems at > 7.1.3 or above.
Re: EXPIRE INVENTORY in TSM 6.3.6
Here is the 6.3.6.000 expiration problem APAR description: IT17642: SLOW EXPIRATION AFTER UPGRADE TO 6.3.6.000 SERVER APAR status - OPEN - *Error description* After upgrading the server to 6.3.6.000 (or higher) and 7.1.3(or higher) expiration might "hang" on a node while expiring backup data only. Expiration is not actually hung it is still processing but very slowly due to a non-optimized SQL/Select. A change to this SQL/Select occurred between 6.3.5.0 and 6.3.6.0. This code change was implemented in servers 6.3.6.0+ and 7.1.3.0 to 7.1.7. There have been no reported problems at 7.1.3 or above. *Customer/L2 Diagnostics* (if applicable) >From the server activity log - review expiration entries. Expiration processes by node/filespace. If it is seen that 1 node does not complete expiration in a timely manner your server may be experiencing this issue. By default Expiration restarts where it left off. If it starts on the same node repeatedly this may also be another indicator you are hitting this issue. Servermon.pl output can be gathered for 1 hour and needs to collect the db2 information. From the *db2.txt output search for the "ELAPSED_TIME_SEC" section. If you are experiencing this issue you will find the following select and a high Elapsed execution time - in this example 25310 seconds (which is a little over 7 hrs): ELAPSED_TIME_SEC STATE STMT_TEXT - 25310 EXEC SELECT IMBK.OBJID, IMBK.BFSIZE, CASE WHEN IMBK.GROUPTYPE IS NOT NULL AND BITAND(IMBK.GROUPTYPE,458752)>0 THEN 1 END AS ISIMGLLEAD, CASE WHEN IMBK.GROUPTYPE IS NOT NULL AND BITAND(IMBK.GROUPTYPE,7)>0 THEN 1 END AS ISIMGLMEMB FROM TSMDB1.BACKUP_OBJECTS IMBK WHERE IMBK.NODEID=? AND IMBK.FSID=? AND IMBK.OBJTYPE=? AND IMBK.STATE=2 AND IMBK.MCID=? AND (BITAND(IMBK.GROUPTYPE,CAST(? AS INT))=0 OR IMBK.GROUPTYPE=131072 OR IMBK.GROUPTYPE IS NULL ) AND ( IMBK.DEACDATE<='1956-10-11 00:00:00' OR ( IMBK.DEACDATE<=? AND 1 record(s) selected. *NOTE* The ELAPSED_TIME_SEC select has been truncated in the DB2 collection and this is how it will appear in the output. *Platforms affected:* Windows, Unix/Linux 6.3.6, 7.1.3 and higher *Initial Impact:* Medium *Additional Keywords:* IT07612 |MDVREGR 6.3.6.0| |MDVREGR 7.1.3.0| *Local fix* 1) Contact Tivoli Storage Manager Support for a "Diagnostic" server (6.3.6.000 only) which has been made available to correct this problem until the fix is available 2) If you can not apply the DIAG server the work-around would be to run expiration: excluding the "slow" node(s) and restarting expiration at the first node. This can be done by adding the 2 following undocumented parameters to the Expire Inventory command: restart=no excludenodes=node1,node2,etc (where node1, node2 are the names of the slow nodes) On Thu, Nov 10, 2016 at 12:14 PM, Zoltan Forray <zfor...@vcu.edu> wrote: > Not sure. We have always used "expire inventory resource=8" with no > issues until 6.3.6.000 > > Since the APAR info is behind IBM's support wall (don't get me started on > the inability to get firmware updates for my IBM TS3500 library from IBM), > I don't know if I can post it here. Hopefully someone from IBM can > chime-in. > > > > On Thu, Nov 10, 2016 at 11:34 AM, Henrik Ahlgren <pa...@seestieto.com> > wrote: > >> Thanks Zoltan, – I somehow missed your earlier posting about this topic. >> I'll try to get my hands on the IT17642 article (why on earth does IBM >> show it only to "authorized" users? I hate this vendor BS.). >> >> But in addition to slowness, it seems that EXPIRE INVENTORY NODE=* at >> least attempts to expire all nodes, unlike EXPIRE INVENTORY without the >> NODE or DOMAIN options. Have you seen this? >> >> On Thu, Nov 10, 2016, at 18:07, Zoltan Forray wrote: >> > Henrik, >> > >> > If you check recent posts here, you will see there is a major issue with >> > 6.3.6.000 server and expirations. I have been fighting it since I >> > upgrade >> > one server. IBM has a hotfix to address it or you can simply upgrade to >> > 7.1.6, which is what I did. You must contact IBM support for it. They >> > say >> > the impact has been minimal and hit-or-miss (not everyone who upgrades >> to >> > 6.3.6.000 has the problem) so an official patch has not been released so >> > far. >> > >> > Search Google for IT17642. >> > >> > On Thu, Nov 10, 2016 at 10:50 AM, Henrik Ahlgren <pa...@seestieto.com> >> > wrote: >> > >> > > The documentation for EXPIRE INVENTORY command says "If you do not >> > > specify either NODE or DOMAIN with value, data for all nodes is >> > > processes". That is in fact how it works up to 6.3.6.100, but it
Re: EXPIRE INVENTORY in TSM 6.3.6
Not sure. We have always used "expire inventory resource=8" with no issues until 6.3.6.000 Since the APAR info is behind IBM's support wall (don't get me started on the inability to get firmware updates for my IBM TS3500 library from IBM), I don't know if I can post it here. Hopefully someone from IBM can chime-in. On Thu, Nov 10, 2016 at 11:34 AM, Henrik Ahlgren <pa...@seestieto.com> wrote: > Thanks Zoltan, – I somehow missed your earlier posting about this topic. > I'll try to get my hands on the IT17642 article (why on earth does IBM > show it only to "authorized" users? I hate this vendor BS.). > > But in addition to slowness, it seems that EXPIRE INVENTORY NODE=* at > least attempts to expire all nodes, unlike EXPIRE INVENTORY without the > NODE or DOMAIN options. Have you seen this? > > On Thu, Nov 10, 2016, at 18:07, Zoltan Forray wrote: > > Henrik, > > > > If you check recent posts here, you will see there is a major issue with > > 6.3.6.000 server and expirations. I have been fighting it since I > > upgrade > > one server. IBM has a hotfix to address it or you can simply upgrade to > > 7.1.6, which is what I did. You must contact IBM support for it. They > > say > > the impact has been minimal and hit-or-miss (not everyone who upgrades to > > 6.3.6.000 has the problem) so an official patch has not been released so > > far. > > > > Search Google for IT17642. > > > > On Thu, Nov 10, 2016 at 10:50 AM, Henrik Ahlgren <pa...@seestieto.com> > > wrote: > > > > > The documentation for EXPIRE INVENTORY command says "If you do not > > > specify either NODE or DOMAIN with value, data for all nodes is > > > processes". That is in fact how it works up to 6.3.6.100, but it seems > > > that there is a bug in 6.3.6 that causes it to only expire a handful of > > > randomly selected nodes, unless you specify "NODE=*". > > > > > > Have any of you run into this? If you're using 6.3.6, I would urge you > > > to check the expire history, i.e. > > > > > > select date(start_time) as date,count(*) as nodes,sum(affected) as > > > expired > > > from summary > > > where activity='EXPIRED' > > > group by date(start_time) > > > > > > > > > > > -- > > *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: EXPIRE INVENTORY in TSM 6.3.6
Thanks Zoltan, – I somehow missed your earlier posting about this topic. I'll try to get my hands on the IT17642 article (why on earth does IBM show it only to "authorized" users? I hate this vendor BS.). But in addition to slowness, it seems that EXPIRE INVENTORY NODE=* at least attempts to expire all nodes, unlike EXPIRE INVENTORY without the NODE or DOMAIN options. Have you seen this? On Thu, Nov 10, 2016, at 18:07, Zoltan Forray wrote: > Henrik, > > If you check recent posts here, you will see there is a major issue with > 6.3.6.000 server and expirations. I have been fighting it since I > upgrade > one server. IBM has a hotfix to address it or you can simply upgrade to > 7.1.6, which is what I did. You must contact IBM support for it. They > say > the impact has been minimal and hit-or-miss (not everyone who upgrades to > 6.3.6.000 has the problem) so an official patch has not been released so > far. > > Search Google for IT17642. > > On Thu, Nov 10, 2016 at 10:50 AM, Henrik Ahlgren <pa...@seestieto.com> > wrote: > > > The documentation for EXPIRE INVENTORY command says "If you do not > > specify either NODE or DOMAIN with value, data for all nodes is > > processes". That is in fact how it works up to 6.3.6.100, but it seems > > that there is a bug in 6.3.6 that causes it to only expire a handful of > > randomly selected nodes, unless you specify "NODE=*". > > > > Have any of you run into this? If you're using 6.3.6, I would urge you > > to check the expire history, i.e. > > > > select date(start_time) as date,count(*) as nodes,sum(affected) as > > expired > > from summary > > where activity='EXPIRED' > > group by date(start_time) > > > > > > -- > *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: EXPIRE INVENTORY in TSM 6.3.6
Henrik, If you check recent posts here, you will see there is a major issue with 6.3.6.000 server and expirations. I have been fighting it since I upgrade one server. IBM has a hotfix to address it or you can simply upgrade to 7.1.6, which is what I did. You must contact IBM support for it. They say the impact has been minimal and hit-or-miss (not everyone who upgrades to 6.3.6.000 has the problem) so an official patch has not been released so far. Search Google for IT17642. On Thu, Nov 10, 2016 at 10:50 AM, Henrik Ahlgren <pa...@seestieto.com> wrote: > The documentation for EXPIRE INVENTORY command says "If you do not > specify either NODE or DOMAIN with value, data for all nodes is > processes". That is in fact how it works up to 6.3.6.100, but it seems > that there is a bug in 6.3.6 that causes it to only expire a handful of > randomly selected nodes, unless you specify "NODE=*". > > Have any of you run into this? If you're using 6.3.6, I would urge you > to check the expire history, i.e. > > select date(start_time) as date,count(*) as nodes,sum(affected) as > expired > from summary > where activity='EXPIRED' > group by date(start_time) > -- *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
EXPIRE INVENTORY in TSM 6.3.6
The documentation for EXPIRE INVENTORY command says "If you do not specify either NODE or DOMAIN with value, data for all nodes is processes". That is in fact how it works up to 6.3.6.100, but it seems that there is a bug in 6.3.6 that causes it to only expire a handful of randomly selected nodes, unless you specify "NODE=*". Have any of you run into this? If you're using 6.3.6, I would urge you to check the expire history, i.e. select date(start_time) as date,count(*) as nodes,sum(affected) as expired from summary where activity='EXPIRED' group by date(start_time)
Re: expire inventory and delete filespace hangs
Just went from v6.3.5.100 to v7.1.1.300. The procedure went smoothly, but so far I'm not impressed with the client backup - slow to start, slow to run. I'd hate to think that the only solution for the performance is a bit of sleight of hand to reconstruct the tablespace. Database is only ~350G with ~360 million objects. Just not sure if I'm going to stay at v7. Gretchen Thiele Princeton University From: ADSM: Dist Stor Manager [ADSM-L@vm.marist.edu] on behalf of Stef Coene [stef.co...@docum.org] Sent: Monday, August 10, 2015 10:51 AM To: ADSM-L@vm.marist.edu Subject: [ADSM-L] expire inventory and delete filespace hangs Hi, We have a V7 TSM server (upgraded from V6). Expire inventory hangs after running a few hours and we also found a filespace that we can not delete. The delete filespaces command just hangs. The only way to cancel the expire inventory and the delete filespace is to halt TSM. The TSM database is 850 GB. When we contacted IBM support and after tracing the server, they told us it's a performance problem. I don't understand why they think it's performance related because all the clients and other server processes are running fine. The fact that the TSM database, recovery log and archive log is stored on a SVC with FlashSystem 840 as backend was not impressive enough. To resolve the performance issues, they want us to convert the DB2 from V6 tablespace format to V7 tablespace format. They can provide scripts for this, but you need to be a DB2 guru to execute the scripts. This will give as an extra performance boost, but also a 30% reduction of the database! Since they consider this a performance issue, the upgrade procedure is not free. Has someone else got the same advice and if yes, have you followed the procedure and what was the result? Stef
Re: expire inventory and delete filespace hangs
On Thursday 13 August 2015 14:10:16 you wrote: Just went from v6.3.5.100 to v7.1.1.300. The procedure went smoothly, but so far I'm not impressed with the client backup - slow to start, slow to run. I'd hate to think that the only solution for the performance is a bit of sleight of hand to reconstruct the tablespace. Database is only ~350G with ~360 million objects. Just not sure if I'm going to stay at v7. IBM support was not really helpful. There conclusion was that we have a performance problem because they can see that the process was accessing the DB2, so it was not hanging. So it has to be a performance issue. The advice: use some script to convert the TSM 6 data to TSM 7 format. This will reorganize the data internally. It should give us an extra performance boost and up to 30% reduction in database size. But this is all at own risk and you need a DB2 guru to understand the scripts. Remember: 'you don't need any DB2 knowledge'. Yeah, right In the meantime, I restored the database (850 GB) on a standby server. This server has nothing else to do. Storage is FlashSystem 840 behind SVC. Expire inventory hangs, but delete filespace gives an error after a few hours. I also found out that the filespace I can not delete was not mentioned during expiration. I renamed the filespace some weeks ago hoping that that will fix the issue. But the new name is not appearing in the activity log during expiration. In stead, the original name is appearing. So it looks like the rename did something (q filespace, q occ, etc is showing the new name), but also messed up something else! So I updated my call and I hope that IBM support will believe me that we don't have a performance issue, but an inconsistency in the database! Stef
expire inventory and delete filespace hangs
Hi, We have a V7 TSM server (upgraded from V6). Expire inventory hangs after running a few hours and we also found a filespace that we can not delete. The delete filespaces command just hangs. The only way to cancel the expire inventory and the delete filespace is to halt TSM. The TSM database is 850 GB. When we contacted IBM support and after tracing the server, they told us it's a performance problem. I don't understand why they think it's performance related because all the clients and other server processes are running fine. The fact that the TSM database, recovery log and archive log is stored on a SVC with FlashSystem 840 as backend was not impressive enough. To resolve the performance issues, they want us to convert the DB2 from V6 tablespace format to V7 tablespace format. They can provide scripts for this, but you need to be a DB2 guru to execute the scripts. This will give as an extra performance boost, but also a 30% reduction of the database! Since they consider this a performance issue, the upgrade procedure is not free. Has someone else got the same advice and if yes, have you followed the procedure and what was the result? Stef
Re: AW: EXPIRE INVENTORY problem
The EXPIRE process finally finished about 6 hours after starting. It reported as successful but was qualified with finished before completion due to being cancelled. I got some info from IBM via the PMR. 1: CAN PRO number and CANCEL EXPIRATION accomplish the same thing. CAN PRO requires the process number, but CANCEL EXPIRATION cancels any currently running EXPIRE process. CANCEL EXPIRATION was created so it could be used in scripting where the process number would be unknown. Similar to the CANCEL REPLICATION command. 2: the EXPIRE process works on a filespace-by-filespace basis for a node. It processes ALL of given filespace, then checks for duration limit. If below the duration limit, it moves on to the next filespace. If beyond duration, the process stops. It's unknown why it took 6 hours to process a single filespace, the typical time on this server is about 1 hour. So, something odd, hopefully won't see that again. It really messed up my maintenance processing with significant that delay. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Michael malitz Sent: Wednesday, May 06, 2015 10:17 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] AW: EXPIRE INVENTORY problem Hallo Harold, you should use the command cancel expiration instead of cancel process. With cancel expiration you have checkpointing at transaction boundaries. Rgds Michael Malitz -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] Im Auftrag von Rick Harderwijk Gesendet: Mittwoch, 6. Mai 2015 16:44 An: ADSM-L@VM.MARIST.EDU Betreff: Re: EXPIRE INVENTORY problem If you cancel an expiration, does it not log every transaction, so that when you cancel, it effectively does a rollback on all the entries in the database? That might take some time as well... On Wed, May 6, 2015 at 4:31 PM, Vandeventer, Harold [OITS] harold.vandeven...@ks.gov wrote: I'm running TSM 6.3.4.300 on Windows. I have a script that issues EXPIRE INVENTORY DURATION=90 RESOURCE=40 WAIT=YES. It was still running over 2 hours after start. I issued a CANCEL PRO and it's been in cancel in progress for over 30 minutes. During all this time, Q PRO is reporting a constant number of nodes processed, objects examined and objects deleted. Database and log space look fine, Health Monitor via the AdminCenter GUI looks fine. What's happening in that process that would cause this behavior? Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] ** * This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. ** *
Re: AW: EXPIRE INVENTORY problem
Hello. This is good info. Does anyone know; if there are multiple Replications happening, would the 'CANCEL REPLICATION' cancel all of them? Can I associate the name of the replication with it if I wanted to cancel only one of them? (In this case I know the 'name' of the replication, but not the process numberfor scripting purposes and it's the middle of the night) -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [OITS] Sent: Thursday, May 07, 2015 8:57 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] AW: EXPIRE INVENTORY problem The EXPIRE process finally finished about 6 hours after starting. It reported as successful but was qualified with finished before completion due to being cancelled. I got some info from IBM via the PMR. 1: CAN PRO number and CANCEL EXPIRATION accomplish the same thing. CAN PRO requires the process number, but CANCEL EXPIRATION cancels any currently running EXPIRE process. CANCEL EXPIRATION was created so it could be used in scripting where the process number would be unknown. Similar to the CANCEL REPLICATION command. 2: the EXPIRE process works on a filespace-by-filespace basis for a node. It processes ALL of given filespace, then checks for duration limit. If below the duration limit, it moves on to the next filespace. If beyond duration, the process stops. It's unknown why it took 6 hours to process a single filespace, the typical time on this server is about 1 hour. So, something odd, hopefully won't see that again. It really messed up my maintenance processing with significant that delay. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Michael malitz Sent: Wednesday, May 06, 2015 10:17 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] AW: EXPIRE INVENTORY problem Hallo Harold, you should use the command cancel expiration instead of cancel process. With cancel expiration you have checkpointing at transaction boundaries. Rgds Michael Malitz -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] Im Auftrag von Rick Harderwijk Gesendet: Mittwoch, 6. Mai 2015 16:44 An: ADSM-L@VM.MARIST.EDU Betreff: Re: EXPIRE INVENTORY problem If you cancel an expiration, does it not log every transaction, so that when you cancel, it effectively does a rollback on all the entries in the database? That might take some time as well... On Wed, May 6, 2015 at 4:31 PM, Vandeventer, Harold [OITS] harold.vandeven...@ks.gov wrote: I'm running TSM 6.3.4.300 on Windows. I have a script that issues EXPIRE INVENTORY DURATION=90 RESOURCE=40 WAIT=YES. It was still running over 2 hours after start. I issued a CANCEL PRO and it's been in cancel in progress for over 30 minutes. During all this time, Q PRO is reporting a constant number of nodes processed, objects examined and objects deleted. Database and log space look fine, Health Monitor via the AdminCenter GUI looks fine. What's happening in that process that would cause this behavior? Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] ** * This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. ** *
Re: AW: EXPIRE INVENTORY problem
Hi Jeanne, No, CANCEL REPLICATION does not support any option and so only allows to cancel all running replication processes. If you want to have have more control over you replication processes, you can replicate by node groups and/or use replication rules. -- Best regards / Cordialement / مع تحياتي Erwann SIMON - Mail original - De: Jeanne Bruno jbr...@cenhud.com À: ADSM-L@VM.MARIST.EDU Envoyé: Jeudi 7 Mai 2015 16:09:53 Objet: Re: [ADSM-L] AW: EXPIRE INVENTORY problem Hello. This is good info. Does anyone know; if there are multiple Replications happening, would the 'CANCEL REPLICATION' cancel all of them? Can I associate the name of the replication with it if I wanted to cancel only one of them? (In this case I know the 'name' of the replication, but not the process numberfor scripting purposes and it's the middle of the night) -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [OITS] Sent: Thursday, May 07, 2015 8:57 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] AW: EXPIRE INVENTORY problem The EXPIRE process finally finished about 6 hours after starting. It reported as successful but was qualified with finished before completion due to being cancelled. I got some info from IBM via the PMR. 1: CAN PRO number and CANCEL EXPIRATION accomplish the same thing. CAN PRO requires the process number, but CANCEL EXPIRATION cancels any currently running EXPIRE process. CANCEL EXPIRATION was created so it could be used in scripting where the process number would be unknown. Similar to the CANCEL REPLICATION command. 2: the EXPIRE process works on a filespace-by-filespace basis for a node. It processes ALL of given filespace, then checks for duration limit. If below the duration limit, it moves on to the next filespace. If beyond duration, the process stops. It's unknown why it took 6 hours to process a single filespace, the typical time on this server is about 1 hour. So, something odd, hopefully won't see that again. It really messed up my maintenance processing with significant that delay. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Michael malitz Sent: Wednesday, May 06, 2015 10:17 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] AW: EXPIRE INVENTORY problem Hallo Harold, you should use the command cancel expiration instead of cancel process. With cancel expiration you have checkpointing at transaction boundaries. Rgds Michael Malitz -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] Im Auftrag von Rick Harderwijk Gesendet: Mittwoch, 6. Mai 2015 16:44 An: ADSM-L@VM.MARIST.EDU Betreff: Re: EXPIRE INVENTORY problem If you cancel an expiration, does it not log every transaction, so that when you cancel, it effectively does a rollback on all the entries in the database? That might take some time as well... On Wed, May 6, 2015 at 4:31 PM, Vandeventer, Harold [OITS] harold.vandeven...@ks.gov wrote: I'm running TSM 6.3.4.300 on Windows. I have a script that issues EXPIRE INVENTORY DURATION=90 RESOURCE=40 WAIT=YES. It was still running over 2 hours after start. I issued a CANCEL PRO and it's been in cancel in progress for over 30 minutes. During all this time, Q PRO is reporting a constant number of nodes processed, objects examined and objects deleted. Database and log space look fine, Health Monitor via the AdminCenter GUI looks fine. What's happening in that process that would cause this behavior? Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] ** * This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. ** *
Re: AW: EXPIRE INVENTORY problem
Hello. We do use node groups. But what rule would I use if I want to cancel one of the replications that may be running and I don't know the process number and if it's still running by 6am, then cancel it? Can I use a 'duration' on a replication?? This select statement works if I run from the console: select TSM_N:cancel process, cast((PROCESS_NUM)as num(5)) as PROCESSID from Processes where PROCESS=Replicate Node and STATUS LIKE Replicating node(s) EXCHANGE_BA1% (where TSM_N is your server name on the console prompt) But trying to use the processid (or PROCESS_NUM variable) in a script wasn't working for me to cancel it. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Erwann SIMON Sent: Thursday, May 07, 2015 10:23 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] AW: EXPIRE INVENTORY problem Hi Jeanne, No, CANCEL REPLICATION does not support any option and so only allows to cancel all running replication processes. If you want to have have more control over you replication processes, you can replicate by node groups and/or use replication rules. -- Best regards / Cordialement / مع تحياتي Erwann SIMON - Mail original - De: Jeanne Bruno jbr...@cenhud.com À: ADSM-L@VM.MARIST.EDU Envoyé: Jeudi 7 Mai 2015 16:09:53 Objet: Re: [ADSM-L] AW: EXPIRE INVENTORY problem Hello. This is good info. Does anyone know; if there are multiple Replications happening, would the 'CANCEL REPLICATION' cancel all of them? Can I associate the name of the replication with it if I wanted to cancel only one of them? (In this case I know the 'name' of the replication, but not the process numberfor scripting purposes and it's the middle of the night) -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [OITS] Sent: Thursday, May 07, 2015 8:57 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] AW: EXPIRE INVENTORY problem The EXPIRE process finally finished about 6 hours after starting. It reported as successful but was qualified with finished before completion due to being cancelled. I got some info from IBM via the PMR. 1: CAN PRO number and CANCEL EXPIRATION accomplish the same thing. CAN PRO requires the process number, but CANCEL EXPIRATION cancels any currently running EXPIRE process. CANCEL EXPIRATION was created so it could be used in scripting where the process number would be unknown. Similar to the CANCEL REPLICATION command. 2: the EXPIRE process works on a filespace-by-filespace basis for a node. It processes ALL of given filespace, then checks for duration limit. If below the duration limit, it moves on to the next filespace. If beyond duration, the process stops. It's unknown why it took 6 hours to process a single filespace, the typical time on this server is about 1 hour. So, something odd, hopefully won't see that again. It really messed up my maintenance processing with significant that delay. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Michael malitz Sent: Wednesday, May 06, 2015 10:17 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] AW: EXPIRE INVENTORY problem Hallo Harold, you should use the command cancel expiration instead of cancel process. With cancel expiration you have checkpointing at transaction boundaries. Rgds Michael Malitz -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] Im Auftrag von Rick Harderwijk Gesendet: Mittwoch, 6. Mai 2015 16:44 An: ADSM-L@VM.MARIST.EDU Betreff: Re: EXPIRE INVENTORY problem If you cancel an expiration, does it not log every transaction, so that when you cancel, it effectively does a rollback on all the entries in the database? That might take some time as well... On Wed, May 6, 2015 at 4:31 PM, Vandeventer, Harold [OITS] harold.vandeven...@ks.gov wrote: I'm running TSM 6.3.4.300 on Windows. I have a script that issues EXPIRE INVENTORY DURATION=90 RESOURCE=40 WAIT=YES. It was still running over 2 hours after start. I issued a CANCEL PRO and it's been in cancel in progress for over 30 minutes. During all this time, Q PRO is reporting a constant number of nodes processed, objects examined and objects deleted. Database and log space look fine, Health Monitor via the AdminCenter GUI looks fine. What's happening in that process that would cause this behavior? Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] ** * This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review
Re: AW: EXPIRE INVENTORY problem
Jeanne, It's just an as I haven't tested it before but I know that command routing can be used with two different syntaxes : - one is : server_name:command - another is : (server_name) command And only the second on is valid in TSM scripts. From Admin guide : Note: When you are writing scripts, you must use the parentheses for server routing information. -- Best regards / Cordialement / مع تحياتي Erwann SIMON - Mail original - De: Jeanne Bruno jbr...@cenhud.com À: ADSM-L@VM.MARIST.EDU Envoyé: Jeudi 7 Mai 2015 17:45:50 Objet: Re: [ADSM-L] AW: EXPIRE INVENTORY problem Hello. We do use node groups. But what rule would I use if I want to cancel one of the replications that may be running and I don't know the process number and if it's still running by 6am, then cancel it? Can I use a 'duration' on a replication?? This select statement works if I run from the console: select TSM_N:cancel process, cast((PROCESS_NUM)as num(5)) as PROCESSID from Processes where PROCESS=Replicate Node and STATUS LIKE Replicating node(s) EXCHANGE_BA1% (where TSM_N is your server name on the console prompt) But trying to use the processid (or PROCESS_NUM variable) in a script wasn't working for me to cancel it. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Erwann SIMON Sent: Thursday, May 07, 2015 10:23 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] AW: EXPIRE INVENTORY problem Hi Jeanne, No, CANCEL REPLICATION does not support any option and so only allows to cancel all running replication processes. If you want to have have more control over you replication processes, you can replicate by node groups and/or use replication rules. -- Best regards / Cordialement / مع تحياتي Erwann SIMON - Mail original - De: Jeanne Bruno jbr...@cenhud.com À: ADSM-L@VM.MARIST.EDU Envoyé: Jeudi 7 Mai 2015 16:09:53 Objet: Re: [ADSM-L] AW: EXPIRE INVENTORY problem Hello. This is good info. Does anyone know; if there are multiple Replications happening, would the 'CANCEL REPLICATION' cancel all of them? Can I associate the name of the replication with it if I wanted to cancel only one of them? (In this case I know the 'name' of the replication, but not the process numberfor scripting purposes and it's the middle of the night) -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [OITS] Sent: Thursday, May 07, 2015 8:57 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] AW: EXPIRE INVENTORY problem The EXPIRE process finally finished about 6 hours after starting. It reported as successful but was qualified with finished before completion due to being cancelled. I got some info from IBM via the PMR. 1: CAN PRO number and CANCEL EXPIRATION accomplish the same thing. CAN PRO requires the process number, but CANCEL EXPIRATION cancels any currently running EXPIRE process. CANCEL EXPIRATION was created so it could be used in scripting where the process number would be unknown. Similar to the CANCEL REPLICATION command. 2: the EXPIRE process works on a filespace-by-filespace basis for a node. It processes ALL of given filespace, then checks for duration limit. If below the duration limit, it moves on to the next filespace. If beyond duration, the process stops. It's unknown why it took 6 hours to process a single filespace, the typical time on this server is about 1 hour. So, something odd, hopefully won't see that again. It really messed up my maintenance processing with significant that delay. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Michael malitz Sent: Wednesday, May 06, 2015 10:17 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] AW: EXPIRE INVENTORY problem Hallo Harold, you should use the command cancel expiration instead of cancel process. With cancel expiration you have checkpointing at transaction boundaries. Rgds Michael Malitz -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] Im Auftrag von Rick Harderwijk Gesendet: Mittwoch, 6. Mai 2015 16:44 An: ADSM-L@VM.MARIST.EDU Betreff: Re: EXPIRE INVENTORY problem If you cancel an expiration, does it not log every transaction, so that when you cancel, it effectively does a rollback on all the entries in the database? That might take some time as well... On Wed, May 6, 2015 at 4:31 PM, Vandeventer, Harold [OITS] harold.vandeven...@ks.gov wrote: I'm running TSM 6.3.4.300 on Windows. I have a script that issues EXPIRE INVENTORY DURATION=90 RESOURCE=40 WAIT=YES. It was still running over 2 hours after start. I issued a CANCEL PRO and it's been in cancel in progress for over 30 minutes. During all this time, Q PRO is reporting a constant number of nodes processed, objects examined and objects deleted. Database and log space look fine, Health Monitor via the AdminCenter
Re: EXPIRE INVENTORY problem
If you cancel an expiration, does it not log every transaction, so that when you cancel, it effectively does a rollback on all the entries in the database? That might take some time as well... On Wed, May 6, 2015 at 4:31 PM, Vandeventer, Harold [OITS] harold.vandeven...@ks.gov wrote: I'm running TSM 6.3.4.300 on Windows. I have a script that issues EXPIRE INVENTORY DURATION=90 RESOURCE=40 WAIT=YES. It was still running over 2 hours after start. I issued a CANCEL PRO and it's been in cancel in progress for over 30 minutes. During all this time, Q PRO is reporting a constant number of nodes processed, objects examined and objects deleted. Database and log space look fine, Health Monitor via the AdminCenter GUI looks fine. What's happening in that process that would cause this behavior? Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] *** This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. ***
EXPIRE INVENTORY problem
I'm running TSM 6.3.4.300 on Windows. I have a script that issues EXPIRE INVENTORY DURATION=90 RESOURCE=40 WAIT=YES. It was still running over 2 hours after start. I issued a CANCEL PRO and it's been in cancel in progress for over 30 minutes. During all this time, Q PRO is reporting a constant number of nodes processed, objects examined and objects deleted. Database and log space look fine, Health Monitor via the AdminCenter GUI looks fine. What's happening in that process that would cause this behavior? Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] *** This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. ***
Re: AW: EXPIRE INVENTORY problem
Thanks for advice Michael and Rick. The process is still in cancel in progress state, over two hours since cancelled. Normally expire takes only about 60 minutes. I've opened a PMR with IBM for advice. I'll update the group when we've resolved the issue. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Michael malitz Sent: Wednesday, May 06, 2015 10:17 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] AW: EXPIRE INVENTORY problem Hallo Harold, you should use the command cancel expiration instead of cancel process. With cancel expiration you have checkpointing at transaction boundaries. Rgds Michael Malitz -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] Im Auftrag von Rick Harderwijk Gesendet: Mittwoch, 6. Mai 2015 16:44 An: ADSM-L@VM.MARIST.EDU Betreff: Re: EXPIRE INVENTORY problem If you cancel an expiration, does it not log every transaction, so that when you cancel, it effectively does a rollback on all the entries in the database? That might take some time as well... On Wed, May 6, 2015 at 4:31 PM, Vandeventer, Harold [OITS] harold.vandeven...@ks.gov wrote: I'm running TSM 6.3.4.300 on Windows. I have a script that issues EXPIRE INVENTORY DURATION=90 RESOURCE=40 WAIT=YES. It was still running over 2 hours after start. I issued a CANCEL PRO and it's been in cancel in progress for over 30 minutes. During all this time, Q PRO is reporting a constant number of nodes processed, objects examined and objects deleted. Database and log space look fine, Health Monitor via the AdminCenter GUI looks fine. What's happening in that process that would cause this behavior? Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] ** * This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. ** *
Re: AW: EXPIRE INVENTORY problem
The expire process finished, 6 hours after starting; about 4 hours after the cancel was issued. Act log does indicate success, but that it was cancelled prior to completion. Between 07:12:43 and 12:12:35, there are no activity log items related to the process. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Michael malitz Sent: Wednesday, May 06, 2015 10:17 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] AW: EXPIRE INVENTORY problem Hallo Harold, you should use the command cancel expiration instead of cancel process. With cancel expiration you have checkpointing at transaction boundaries. Rgds Michael Malitz -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] Im Auftrag von Rick Harderwijk Gesendet: Mittwoch, 6. Mai 2015 16:44 An: ADSM-L@VM.MARIST.EDU Betreff: Re: EXPIRE INVENTORY problem If you cancel an expiration, does it not log every transaction, so that when you cancel, it effectively does a rollback on all the entries in the database? That might take some time as well... On Wed, May 6, 2015 at 4:31 PM, Vandeventer, Harold [OITS] harold.vandeven...@ks.gov wrote: I'm running TSM 6.3.4.300 on Windows. I have a script that issues EXPIRE INVENTORY DURATION=90 RESOURCE=40 WAIT=YES. It was still running over 2 hours after start. I issued a CANCEL PRO and it's been in cancel in progress for over 30 minutes. During all this time, Q PRO is reporting a constant number of nodes processed, objects examined and objects deleted. Database and log space look fine, Health Monitor via the AdminCenter GUI looks fine. What's happening in that process that would cause this behavior? Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] ** * This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. ** *
AW: EXPIRE INVENTORY problem
Hallo Harold, you should use the command cancel expiration instead of cancel process. With cancel expiration you have checkpointing at transaction boundaries. Rgds Michael Malitz -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] Im Auftrag von Rick Harderwijk Gesendet: Mittwoch, 6. Mai 2015 16:44 An: ADSM-L@VM.MARIST.EDU Betreff: Re: EXPIRE INVENTORY problem If you cancel an expiration, does it not log every transaction, so that when you cancel, it effectively does a rollback on all the entries in the database? That might take some time as well... On Wed, May 6, 2015 at 4:31 PM, Vandeventer, Harold [OITS] harold.vandeven...@ks.gov wrote: I'm running TSM 6.3.4.300 on Windows. I have a script that issues EXPIRE INVENTORY DURATION=90 RESOURCE=40 WAIT=YES. It was still running over 2 hours after start. I issued a CANCEL PRO and it's been in cancel in progress for over 30 minutes. During all this time, Q PRO is reporting a constant number of nodes processed, objects examined and objects deleted. Database and log space look fine, Health Monitor via the AdminCenter GUI looks fine. What's happening in that process that would cause this behavior? Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] *** This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. ***
expire inventory seems to be hanging and not processing all nodes
I have an AIX server with TSM 6.3.4.0. Expiration is set to run at 2am and seems to get so far and then hangs. But what's odd is that is also seems to only process some of the nodes but not all. For example, I have it running now and it seems to be stuck: 1 Expiration Processed 462 nodes out of 595 total nodes, examined 4315 objects, deleting 4271 backup objects, 0 archive objects, 0 DB backup volumes, 0 recovery plan files; 0 objects have been retried and 0 errors encountered. I looked at previous nights and it ran successfully but only processed 462 nodes out of 595 and says it ended successfully. If I cancel the one that is running now, it just hangs and never cancels. The only way to get rid of the process is to halt the server. I have opened a problem with IBM but I thought I would see if any of you have seen this issue. Any idea why it isn't processing all 595 nodes?
Re: expire inventory seems to be hanging and not processing all nodes
How long have you been at 6.3.4.0? I've seen this on slightly older servers when Windows 2008 Server clients (and similar era Windows desktop, from what I hear) back up their system states. You get huge numbers of small objects, and expiration takes a long, long time to process those with no obvious progress. However, that's supposed to be fixed in 6.3.4.0. I'm wondering if you backed up some such clients before upgrading to 6.3.4.0? Nick On Aug 9, 2013, at 11:02 AM, Dury, John C. jd...@duqlight.com wrote: I have an AIX server with TSM 6.3.4.0. Expiration is set to run at 2am and seems to get so far and then hangs. But what's odd is that is also seems to only process some of the nodes but not all. For example, I have it running now and it seems to be stuck: 1 Expiration Processed 462 nodes out of 595 total nodes, examined 4315 objects, deleting 4271 backup objects, 0 archive objects, 0 DB backup volumes, 0 recovery plan files; 0 objects have been retried and 0 errors encountered. I looked at previous nights and it ran successfully but only processed 462 nodes out of 595 and says it ended successfully. If I cancel the one that is running now, it just hangs and never cancels. The only way to get rid of the process is to halt the server. I have opened a problem with IBM but I thought I would see if any of you have seen this issue. Any idea why it isn't processing all 595 nodes?
Re: expire inventory seems to be hanging and not processing all nodes
-How long have you been at 6.3.4.0? I've seen this on slightly older servers -when Windows 2008 Server clients (and similar era Windows desktop, from what I -hear) back up their system states. You get huge numbers of small objects, and -expiration takes a long, long time to process those with no obvious progress. - -However, that's supposed to be fixed in 6.3.4.0. I'm wondering if you backed up -some such clients before upgrading to 6.3.4.0? - -Nick We've been running v6.3.4.0 for a few weeks now. -I saw a similar behavior on my 6.3.3.100 on Windows earlier this week. - -Expiration appeared to be stuck for a couple of hours having processed only 10 -or 15 nodes of 200. - -Do you have a duration specified to limit time? That might explain your 462 of -595. - -I had also tried to cancel, and also did the halt to clear the process. - -Upon restarting, then a new expire, it again appeared to stall, but in time -picked up and cruised through without issue. - -All expiration since that day has run fine, in normal behavior and timespan. I do not have duration limit on the process. I looked at a previous night and it ran in 90 minutes or less. The current one has been running for a few hours and is still hung at 462 out of 595 nodes and the number of objects hasn't changed. From: Dury, John C. Sent: Friday, August 09, 2013 12:03 PM To: ADSM-L (ADSM-L@VM.MARIST.EDU) Subject: expire inventory seems to be hanging and not processing all nodes I have an AIX server with TSM 6.3.4.0. Expiration is set to run at 2am and seems to get so far and then hangs. But what's odd is that is also seems to only process some of the nodes but not all. For example, I have it running now and it seems to be stuck: 1 Expiration Processed 462 nodes out of 595 total nodes, examined 4315 objects, deleting 4271 backup objects, 0 archive objects, 0 DB backup volumes, 0 recovery plan files; 0 objects have been retried and 0 errors encountered. I looked at previous nights and it ran successfully but only processed 462 nodes out of 595 and says it ended successfully. If I cancel the one that is running now, it just hangs and never cancels. The only way to get rid of the process is to halt the server. I have opened a problem with IBM but I thought I would see if any of you have seen this issue. Any idea why it isn't processing all 595 nodes?
Re: Expire Inventory errors after upgrade to 6.1.5.10
Mark, Any way to suppress these harmless/annoying messages? Since they are harmless, am I right in guessing someone forgot to turn off some debugging code/messages? While I don't mind opening up a PMR, I would assume there is going to be a quick update (6.1.5.11?) to address it? Zoltan Forray TSM Software Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services 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 From: Mark Haye mark.h...@us.ibm.com To: ADSM-L@VM.MARIST.EDU Date: 07/28/2011 01:46 PM Subject: Re: [ADSM-L] Expire Inventory errors after upgrade to 6.1.5.10 Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 7/28/2011 10:20:14 AM ANRD_3916334743 ComputeHashValue (tbcache.c:4313) Thread91: Table Group.Leaders, Column 4 of type 0 not valid for hashKey. This is a known problem, fixed in internal defect 73872. It is not related to the Win2K8 system state cleanup problem. All indications are that the message is harmless and does not adversely affect server operation. If you haven't opened a PMR for it yet, that would be the next step ... Mark Haye (马克海), IBM TSM Server Development, mark.h...@us.ibm.com, 8/321-4403, (520)799-4403, 0N6/9062-2, Tucson Professional programmer. Closed source. Do not attempt.
Re: Expire Inventory errors after upgrade to 6.1.5.10
Any way to suppress these harmless/annoying messages? Unfortunately, no. Since they are harmless, am I right in guessing someone forgot to turn off some debugging code/messages? No, but the effect is the same. While I don't mind opening up a PMR, I would assume there is going to be a quick update (6.1.5.11?) to address it? Apparently there is already a PMR (04704,070,724) which was opened yesterday, but I didn't find it until today. Looks like the response is that the fix will be in 6.1.6, due sometime next year. Mark Haye (马克海), IBM TSM Server Development, mark.h...@us.ibm.com, 8/321-4403, (520)799-4403, 0N6/9062-2, Tucson Professional programmer. Closed source. Do not attempt.
Re: Expire Inventory errors after upgrade to 6.1.5.10
Looks like the response is that the fix will be in 6.1.6, due sometime next year. Are you kidding on this? a bug introduced in a patch is going to generate annoying error messages every day for the next 5+ months? My monitoring system (TSMManager) send me error emails for each message and since it is a generic ANR message, I can't filter on just the message number since I might miss other failures. I would have thought the patch would have been pulled. I still might open a PMR. Thanks for the response/update. Zoltan Forray TSM Software Hardware Administrator Virginia Commonwealth University - UCC/Office of Technology Services 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 From: Mark Haye mark.h...@us.ibm.com To: ADSM-L@VM.MARIST.EDU Date: 07/29/2011 02:47 PM Subject: Re: [ADSM-L] Expire Inventory errors after upgrade to 6.1.5.10 Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU Any way to suppress these harmless/annoying messages? Unfortunately, no. Since they are harmless, am I right in guessing someone forgot to turn off some debugging code/messages? No, but the effect is the same. While I don't mind opening up a PMR, I would assume there is going to be a quick update (6.1.5.11?) to address it? Apparently there is already a PMR (04704,070,724) which was opened yesterday, but I didn't find it until today. Looks like the response is that the fix will be in 6.1.6, due sometime next year. Mark Haye (马克海), IBM TSM Server Development, mark.h...@us.ibm.com, 8/321-4403, (520)799-4403, 0N6/9062-2, Tucson Professional programmer. Closed source. Do not attempt.
Expire Inventory errors after upgrade to 6.1.5.10
I just upgraded my 6.1 server to 6.1.5.10 - waited for the additional patch to .10 due to folks commented on various issues. Now after performing the upgrade, expire inventory kicked off and is spewing error: 7/28/2011 10:20:14 AM ANRD_3916334743 ComputeHashValue(tbcache.c:4313) Thread91: Table Group.Leaders, Column 4 of type 0 not valid for hashKey. 7/28/2011 10:20:14 AM ANRD Thread91 issued message from: 7/28/2011 10:20:14 AM ANRD Thread91 0xc3dcb2 OutDiagToCons 7/28/2011 10:20:14 AM ANRD Thread91 0xc40844 outDiagfExt 7/28/2011 10:20:14 AM ANRD Thread91 0x7639de ComputeHashValue 7/28/2011 10:20:14 AM ANRD Thread91 0x76489d TbCacheFlushRow 7/28/2011 10:20:14 AM ANRD Thread91 0x78e362 tbRegExecEx 7/28/2011 10:20:14 AM ANRD Thread91 0x8a3e9e ImDeleteDependents 7/28/2011 10:20:14 AM ANRD Thread91 0x8a32f7 ImDeleteDependents 7/28/2011 10:20:14 AM ANRD Thread91 0x88ad1b imDeleteObject 7/28/2011 10:20:14 AM ANRD Thread91 0x8b356b ExpireBackupData 7/28/2011 10:20:14 AM ANRD Thread91 0x8bb510 ExpirationProcessThread 7/28/2011 10:20:14 AM ANRD Thread91 0xcb2a8b StartThread 7/28/2011 10:20:14 AM ANRD Thread91 0x336b206367 *UNKNOWN* 7/28/2011 10:20:14 AM ANRD Thread91 0x336a6d30ad *UNKNOWN* Doesn't make me feel warm-and-fuzzy... I realize one of the APARS talked about W2K8 systemstate backups not being properly purged/expired and there are a lot of these type nodes on this TSM server.. Any thoughts? Should I be concerned or are these errors the result of trying to cleanup the W2K8 garbage? Zoltan Forray TSM Software Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services 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: Expire Inventory errors after upgrade to 6.1.5.10
7/28/2011 10:20:14 AM ANRD_3916334743 ComputeHashValue (tbcache.c:4313) Thread91: Table Group.Leaders, Column 4 of type 0 not valid for hashKey. This is a known problem, fixed in internal defect 73872. It is not related to the Win2K8 system state cleanup problem. All indications are that the message is harmless and does not adversely affect server operation. If you haven't opened a PMR for it yet, that would be the next step ... Mark Haye (马克海), IBM TSM Server Development, mark.h...@us.ibm.com, 8/321-4403, (520)799-4403, 0N6/9062-2, Tucson Professional programmer. Closed source. Do not attempt.
Re: Expire Inventory errors after upgrade to 6.1.5.10
Thank you for the info. Just for the ha-ha's, I ran another expire and it didn't generate any errors. However, I found it interesting that it still found something to delete considering there weren't any backups run and there was only about 10-minutes between runs. I guess if the expiration process is very granular down to the minute/second, theoretically it would always find something to expire.. Zoltan Forray TSM Software Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services 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 From: Mark Haye mark.h...@us.ibm.com To: ADSM-L@VM.MARIST.EDU Date: 07/28/2011 01:46 PM Subject: Re: [ADSM-L] Expire Inventory errors after upgrade to 6.1.5.10 Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 7/28/2011 10:20:14 AM ANRD_3916334743 ComputeHashValue (tbcache.c:4313) Thread91: Table Group.Leaders, Column 4 of type 0 not valid for hashKey. This is a known problem, fixed in internal defect 73872. It is not related to the Win2K8 system state cleanup problem. All indications are that the message is harmless and does not adversely affect server operation. If you haven't opened a PMR for it yet, that would be the next step ... Mark Haye (马克海), IBM TSM Server Development, mark.h...@us.ibm.com, 8/321-4403, (520)799-4403, 0N6/9062-2, Tucson Professional programmer. Closed source. Do not attempt.
Re: expire inventory process
We do run it daily, just considering what the ramifications of once a week would be. Tim -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu]on Behalf Of Steven Langdale Sent: Saturday, July 03, 2010 11:44 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: expire inventory process Tim I think most people run inventory expiration every day, there generally isn't any reason not to for the majority of installations. Is there any particular reason why you don't want to run it daily? Thanks Steven Tim Brown tbr...@cenhud.com Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 03/07/2010 13:03 Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] expire inventory process Caterpillar: Confidential Green Retain Until: 02/08/2010 We run reclamation just on weekends, would running expire inventory just prior be ok and not run daily. Tim -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu]on Behalf Of Grigori Solonovitch Sent: Friday, July 02, 2010 5:25 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: expire inventory process There is dependency between reclamation and expiry process. You have to run expiry daily to have daily reclamation. I have scheduled reclamation 3 times per day at time suitable for automatic reclamation. From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Tim Brown [tbr...@cenhud.com] Sent: Friday, July 02, 2010 10:58 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] expire inventory process Is it recommended to run expire inventory every day or can it be run once a week. Tim Brown Systems Specialist - Project Leader Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments. Thank you. Please consider the environment before printing this Email. CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail message and any attachments hereto may be legally privileged and confidential. The information is intended only for the recipient(s) named in this message. If you are not the intended recipient you are notified that any use, disclosure, copying or distribution is prohibited. If you have received this in error please contact the sender and delete this message and any attachments from your computer system. We do not guarantee that this message or any attachment to it is secure or free from errors, computer viruses or other conditions that may damage or interfere with data, hardware or software.
SV: expire inventory process
Hi, I have a sit where we run Expire Inventory per Domain everyday. Expire Inventory Domain A - Monday Expire Inventory Domain B - Tuesday and so on... Best Regards Christian Svensson Cell: +46-70-325 1577 E-mail: christian.svens...@cristie.se Skype: cristie.christian.svensson Supported Platform for CPU2TSM:: http://www.cristie.se/cpu2tsm-supported-platforms Från: Tim Brown [tbr...@cenhud.com] Skickat: den 6 juli 2010 13:17 Till: ADSM-L@VM.MARIST.EDU Ämne: Re: expire inventory process We do run it daily, just considering what the ramifications of once a week would be. Tim -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu]on Behalf Of Steven Langdale Sent: Saturday, July 03, 2010 11:44 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: expire inventory process Tim I think most people run inventory expiration every day, there generally isn't any reason not to for the majority of installations. Is there any particular reason why you don't want to run it daily? Thanks Steven Tim Brown tbr...@cenhud.com Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 03/07/2010 13:03 Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] expire inventory process Caterpillar: Confidential Green Retain Until: 02/08/2010 We run reclamation just on weekends, would running expire inventory just prior be ok and not run daily. Tim -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu]on Behalf Of Grigori Solonovitch Sent: Friday, July 02, 2010 5:25 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: expire inventory process There is dependency between reclamation and expiry process. You have to run expiry daily to have daily reclamation. I have scheduled reclamation 3 times per day at time suitable for automatic reclamation. From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Tim Brown [tbr...@cenhud.com] Sent: Friday, July 02, 2010 10:58 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] expire inventory process Is it recommended to run expire inventory every day or can it be run once a week. Tim Brown Systems Specialist - Project Leader Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments. Thank you. Please consider the environment before printing this Email. CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail message and any attachments hereto may be legally privileged and confidential. The information is intended only for the recipient(s) named in this message. If you are not the intended recipient you are notified that any use, disclosure, copying or distribution is prohibited. If you have received this in error please contact the sender and delete this message and any attachments from your computer system. We do not guarantee that this message or any attachment to it is secure or free from errors, computer viruses or other conditions that may damage or interfere with data, hardware or software.
Expire Inventory Hangs?
Hi, I have a TSM Server 6.1.3.4 running on a Windows Server 2008 R2. When I run Expire Inventory on my server it seams to hang on a unique node and I think I have found the exact node it hangs on. My question is. How can I solve this? Is it possible to run a online audit on the database now when the database is on DB2 or is it only offline audit availbile? Best Regards Christian Svensson Cell: +46-70-325 1577 E-mail: christian.svens...@cristie.se Skype: cristie.christian.svensson Supported Platform for CPU2TSM:: http://www.cristie.se/cpu2tsm-supported-platforms
Re: Expire Inventory Hangs?
On Jul 5, 2010, at 5:29 AM, Christian Svensson wrote: Hi, I have a TSM Server 6.1.3.4 running on a Windows Server 2008 R2. When I run Expire Inventory on my server it seams to hang on a unique node and I think I have found the exact node it hangs on. My question is. How can I solve this? Is it possible to run a online audit on the database now when the database is on DB2 or is it only offline audit availbile? Does the client have a session open with the server while you're running EXPIRE INVENTORY? (That probably was one of the first things you checked, but you didn't say so, so I ask. :-) ) Best Regards Christian Svensson Nick
SV: Expire Inventory Hangs?
Hi, Their is no backup or restore session active. And the Expire inventory can hangs for over 24 hours without any problem on the same node and on the same filespace. So I,m guessing it is a corruption in the TSM Database. Best Regards Christian Svensson Cell: +46-70-325 1577 E-mail: christian.svens...@cristie.se Skype: cristie.christian.svensson Supported Platform for CPU2TSM:: http://www.cristie.se/cpu2tsm-supported-platforms Från: Nick Laflamme [dplafla...@gmail.com] Skickat: den 5 juli 2010 15:22 Till: ADSM-L@VM.MARIST.EDU Ämne: Re: Expire Inventory Hangs? On Jul 5, 2010, at 5:29 AM, Christian Svensson wrote: Hi, I have a TSM Server 6.1.3.4 running on a Windows Server 2008 R2. When I run Expire Inventory on my server it seams to hang on a unique node and I think I have found the exact node it hangs on. My question is. How can I solve this? Is it possible to run a online audit on the database now when the database is on DB2 or is it only offline audit availbile? Does the client have a session open with the server while you're running EXPIRE INVENTORY? (That probably was one of the first things you checked, but you didn't say so, so I ask. :-) ) Best Regards Christian Svensson Nick
Re: Expire Inventory Hangs?
I have a similar one. It's 4.5M objects with odd retention. Everything before and after it in the expiration process completes in my 12 hour window. It takes 2+ days. When I see expiration hung, I cancel and restart without specifying duration. It's a weekly procedure for me. From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Christian Svensson [christian.svens...@cristie.se] Sent: Monday, July 05, 2010 8:46 AM To: ADSM-L@vm.marist.edu Subject: [ADSM-L] SV: Expire Inventory Hangs? Hi, Their is no backup or restore session active. And the Expire inventory can hangs for over 24 hours without any problem on the same node and on the same filespace. So I,m guessing it is a corruption in the TSM Database. Best Regards Christian Svensson Cell: +46-70-325 1577 E-mail: christian.svens...@cristie.se Skype: cristie.christian.svensson Supported Platform for CPU2TSM:: http://www.cristie.se/cpu2tsm-supported-platforms Från: Nick Laflamme [dplafla...@gmail.com] Skickat: den 5 juli 2010 15:22 Till: ADSM-L@VM.MARIST.EDU Ämne: Re: Expire Inventory Hangs? On Jul 5, 2010, at 5:29 AM, Christian Svensson wrote: Hi, I have a TSM Server 6.1.3.4 running on a Windows Server 2008 R2. When I run Expire Inventory on my server it seams to hang on a unique node and I think I have found the exact node it hangs on. My question is. How can I solve this? Is it possible to run a online audit on the database now when the database is on DB2 or is it only offline audit availbile? Does the client have a session open with the server while you're running EXPIRE INVENTORY? (That probably was one of the first things you checked, but you didn't say so, so I ask. :-) ) Best Regards Christian Svensson Nick
Re: Expire Inventory Hangs?
I have an open apar on a similar problem. We had a Win2008 client that backed up several million system objects (full backup was happening every day for a while) with 14 copies being kept. The client then stopped backing up the system objects and after 30 days all but the last copy were eligible for expiration. That's when we started having expiration problems. It seems the further into expiration on this node we got, the slower it ran. We ended up excluding this node from expiration and everything was back to normal. We were then asked by support to run a DELETE FILESPACE on the system in question and it produced the same results; ran ok for a while and then slowed to a crawl. Tivoli support had us take some traces and it appears this is a DB2 bug. I have received a test fix which includes apar IC69156 that I'm going to install this week. This is projected to be fixes in 6.1.4. I'll report back with the results. Sam Sheppard San Diego Data Processing Corp. (858)-581-9668 From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Fred Johanson [f...@uchicago.edu] Sent: Monday, July 05, 2010 7:01 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Expire Inventory Hangs? I have a similar one. It's 4.5M objects with odd retention. Everything before and after it in the expiration process completes in my 12 hour window. It takes 2+ days. When I see expiration hung, I cancel and restart without specifying duration. It's a weekly procedure for me. From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Christian Svensson [christian.svens...@cristie.se] Sent: Monday, July 05, 2010 8:46 AM To: ADSM-L@vm.marist.edu Subject: [ADSM-L] SV: Expire Inventory Hangs? Hi, Their is no backup or restore session active. And the Expire inventory can hangs for over 24 hours without any problem on the same node and on the same filespace. So I,m guessing it is a corruption in the TSM Database. Best Regards Christian Svensson Cell: +46-70-325 1577 E-mail: christian.svens...@cristie.se Skype: cristie.christian.svensson Supported Platform for CPU2TSM:: http://www.cristie.se/cpu2tsm-supported-platforms Från: Nick Laflamme [dplafla...@gmail.com] Skickat: den 5 juli 2010 15:22 Till: ADSM-L@VM.MARIST.EDU Ämne: Re: Expire Inventory Hangs? On Jul 5, 2010, at 5:29 AM, Christian Svensson wrote: Hi, I have a TSM Server 6.1.3.4 running on a Windows Server 2008 R2. When I run Expire Inventory on my server it seams to hang on a unique node and I think I have found the exact node it hangs on. My question is. How can I solve this? Is it possible to run a online audit on the database now when the database is on DB2 or is it only offline audit availbile? Does the client have a session open with the server while you're running EXPIRE INVENTORY? (That probably was one of the first things you checked, but you didn't say so, so I ask. :-) ) Best Regards Christian Svensson Nick
SV: Expire Inventory Hangs?
Hi Sam, Can you send over what trace flag you are using to debug Expire inventory? Sometimes can you see a bullet point when you go though the Trace Logs. Best Regards Christian Svensson Cell: +46-70-325 1577 E-mail: christian.svens...@cristie.se Skype: cristie.christian.svensson Supported Platform for CPU2TSM:: http://www.cristie.se/cpu2tsm-supported-platforms Från: Sheppard, Sam [sshepp...@sddpc.org] Skickat: den 5 juli 2010 20:20 Till: ADSM-L@VM.MARIST.EDU Ämne: Re: Expire Inventory Hangs? I have an open apar on a similar problem. We had a Win2008 client that backed up several million system objects (full backup was happening every day for a while) with 14 copies being kept. The client then stopped backing up the system objects and after 30 days all but the last copy were eligible for expiration. That's when we started having expiration problems. It seems the further into expiration on this node we got, the slower it ran. We ended up excluding this node from expiration and everything was back to normal. We were then asked by support to run a DELETE FILESPACE on the system in question and it produced the same results; ran ok for a while and then slowed to a crawl. Tivoli support had us take some traces and it appears this is a DB2 bug. I have received a test fix which includes apar IC69156 that I'm going to install this week. This is projected to be fixes in 6.1.4. I'll report back with the results. Sam Sheppard San Diego Data Processing Corp. (858)-581-9668 From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Fred Johanson [f...@uchicago.edu] Sent: Monday, July 05, 2010 7:01 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Expire Inventory Hangs? I have a similar one. It's 4.5M objects with odd retention. Everything before and after it in the expiration process completes in my 12 hour window. It takes 2+ days. When I see expiration hung, I cancel and restart without specifying duration. It's a weekly procedure for me. From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Christian Svensson [christian.svens...@cristie.se] Sent: Monday, July 05, 2010 8:46 AM To: ADSM-L@vm.marist.edu Subject: [ADSM-L] SV: Expire Inventory Hangs? Hi, Their is no backup or restore session active. And the Expire inventory can hangs for over 24 hours without any problem on the same node and on the same filespace. So I,m guessing it is a corruption in the TSM Database. Best Regards Christian Svensson Cell: +46-70-325 1577 E-mail: christian.svens...@cristie.se Skype: cristie.christian.svensson Supported Platform for CPU2TSM:: http://www.cristie.se/cpu2tsm-supported-platforms Från: Nick Laflamme [dplafla...@gmail.com] Skickat: den 5 juli 2010 15:22 Till: ADSM-L@VM.MARIST.EDU Ämne: Re: Expire Inventory Hangs? On Jul 5, 2010, at 5:29 AM, Christian Svensson wrote: Hi, I have a TSM Server 6.1.3.4 running on a Windows Server 2008 R2. When I run Expire Inventory on my server it seams to hang on a unique node and I think I have found the exact node it hangs on. My question is. How can I solve this? Is it possible to run a online audit on the database now when the database is on DB2 or is it only offline audit availbile? Does the client have a session open with the server while you're running EXPIRE INVENTORY? (That probably was one of the first things you checked, but you didn't say so, so I ask. :-) ) Best Regards Christian Svensson Nick
Re: Expire Inventory Hangs?
The two traces we were asked to provide are as follows: You can enable instrumentation traces with the following commands in dsmadmc: instrument begin (gather instrumentation for about 30 minutes of DEL FI) instrument end file=your_filename.txt and 1) start del fi ... process if not already running (or the expire inventory) 2) do show threads to see which thread the delete fi is 3) do trace enable DBSTMT 4) do trace begin /tmp/delfitrace.txt bufsize=4096 5) Let run for only a few seconds due to size of trace file 6) do trace end Another serious symptom we experienced was that after the DEL FI or EXP INVENT were running for a while on the problem filespace, the buffer pool hit ratio declined drastically from 98+% all the way down to ~65%. Also, I misspoke as to the client causing the problem; it was Windows 7. Sam Sheppard San Diego Data Processing Corp. (858)-581-9668 From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Christian Svensson [christian.svens...@cristie.se] Sent: Monday, July 05, 2010 12:29 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] SV: Expire Inventory Hangs? Hi Sam, Can you send over what trace flag you are using to debug Expire inventory? Sometimes can you see a bullet point when you go though the Trace Logs. Best Regards Christian Svensson Cell: +46-70-325 1577 E-mail: christian.svens...@cristie.se Skype: cristie.christian.svensson Supported Platform for CPU2TSM:: http://www.cristie.se/cpu2tsm-supported-platforms Från: Sheppard, Sam [sshepp...@sddpc.org] Skickat: den 5 juli 2010 20:20 Till: ADSM-L@VM.MARIST.EDU Ämne: Re: Expire Inventory Hangs? I have an open apar on a similar problem. We had a Win2008 client that backed up several million system objects (full backup was happening every day for a while) with 14 copies being kept. The client then stopped backing up the system objects and after 30 days all but the last copy were eligible for expiration. That's when we started having expiration problems. It seems the further into expiration on this node we got, the slower it ran. We ended up excluding this node from expiration and everything was back to normal. We were then asked by support to run a DELETE FILESPACE on the system in question and it produced the same results; ran ok for a while and then slowed to a crawl. Tivoli support had us take some traces and it appears this is a DB2 bug. I have received a test fix which includes apar IC69156 that I'm going to install this week. This is projected to be fixes in 6.1.4. I'll report back with the results. Sam Sheppard San Diego Data Processing Corp. (858)-581-9668 From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Fred Johanson [f...@uchicago.edu] Sent: Monday, July 05, 2010 7:01 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Expire Inventory Hangs? I have a similar one. It's 4.5M objects with odd retention. Everything before and after it in the expiration process completes in my 12 hour window. It takes 2+ days. When I see expiration hung, I cancel and restart without specifying duration. It's a weekly procedure for me. From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Christian Svensson [christian.svens...@cristie.se] Sent: Monday, July 05, 2010 8:46 AM To: ADSM-L@vm.marist.edu Subject: [ADSM-L] SV: Expire Inventory Hangs? Hi, Their is no backup or restore session active. And the Expire inventory can hangs for over 24 hours without any problem on the same node and on the same filespace. So I,m guessing it is a corruption in the TSM Database. Best Regards Christian Svensson Cell: +46-70-325 1577 E-mail: christian.svens...@cristie.se Skype: cristie.christian.svensson Supported Platform for CPU2TSM:: http://www.cristie.se/cpu2tsm-supported-platforms Från: Nick Laflamme [dplafla...@gmail.com] Skickat: den 5 juli 2010 15:22 Till: ADSM-L@VM.MARIST.EDU Ämne: Re: Expire Inventory Hangs? On Jul 5, 2010, at 5:29 AM, Christian Svensson wrote: Hi, I have a TSM Server 6.1.3.4 running on a Windows Server 2008 R2. When I run Expire Inventory on my server it seams to hang on a unique node and I think I have found the exact node it hangs on. My question is. How can I solve this? Is it possible to run a online audit on the database now when the database is on DB2 or is it only offline audit availbile? Does the client have a session open with the server while you're running EXPIRE INVENTORY? (That probably was one of the first things you checked, but you didn't say so, so I ask. :-) ) Best Regards Christian Svensson Nick
Re: expire inventory process
We run reclamation just on weekends, would running expire inventory just prior be ok and not run daily. Tim -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu]on Behalf Of Grigori Solonovitch Sent: Friday, July 02, 2010 5:25 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: expire inventory process There is dependency between reclamation and expiry process. You have to run expiry daily to have daily reclamation. I have scheduled reclamation 3 times per day at time suitable for automatic reclamation. From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Tim Brown [tbr...@cenhud.com] Sent: Friday, July 02, 2010 10:58 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] expire inventory process Is it recommended to run expire inventory every day or can it be run once a week. Tim Brown Systems Specialist - Project Leader Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments. Thank you. Please consider the environment before printing this Email. CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail message and any attachments hereto may be legally privileged and confidential. The information is intended only for the recipient(s) named in this message. If you are not the intended recipient you are notified that any use, disclosure, copying or distribution is prohibited. If you have received this in error please contact the sender and delete this message and any attachments from your computer system. We do not guarantee that this message or any attachment to it is secure or free from errors, computer viruses or other conditions that may damage or interfere with data, hardware or software.
Re: expire inventory process
It all depends. In some environments, expiration just takes a few hours, in others, it runs all day log. In the first case, running it just once a week won't hurt, in the latter, it needs to run daily to keep up On 3 jul 2010, at 14:02, Tim Brown wrote: We run reclamation just on weekends, would running expire inventory just prior be ok and not run daily. Tim -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu]on Behalf Of Grigori Solonovitch Sent: Friday, July 02, 2010 5:25 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: expire inventory process There is dependency between reclamation and expiry process. You have to run expiry daily to have daily reclamation. I have scheduled reclamation 3 times per day at time suitable for automatic reclamation. From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Tim Brown [tbr...@cenhud.com] Sent: Friday, July 02, 2010 10:58 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] expire inventory process Is it recommended to run expire inventory every day or can it be run once a week. Tim Brown Systems Specialist - Project Leader Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments. Thank you. Please consider the environment before printing this Email. CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail message and any attachments hereto may be legally privileged and confidential. The information is intended only for the recipient(s) named in this message. If you are not the intended recipient you are notified that any use, disclosure, copying or distribution is prohibited. If you have received this in error please contact the sender and delete this message and any attachments from your computer system. We do not guarantee that this message or any attachment to it is secure or free from errors, computer viruses or other conditions that may damage or interfere with data, hardware or software. -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622
Re: expire inventory process
Tim I think most people run inventory expiration every day, there generally isn't any reason not to for the majority of installations. Is there any particular reason why you don't want to run it daily? Thanks Steven Tim Brown tbr...@cenhud.com Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 03/07/2010 13:03 Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] expire inventory process Caterpillar: Confidential Green Retain Until: 02/08/2010 We run reclamation just on weekends, would running expire inventory just prior be ok and not run daily. Tim -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu]on Behalf Of Grigori Solonovitch Sent: Friday, July 02, 2010 5:25 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: expire inventory process There is dependency between reclamation and expiry process. You have to run expiry daily to have daily reclamation. I have scheduled reclamation 3 times per day at time suitable for automatic reclamation. From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Tim Brown [tbr...@cenhud.com] Sent: Friday, July 02, 2010 10:58 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] expire inventory process Is it recommended to run expire inventory every day or can it be run once a week. Tim Brown Systems Specialist - Project Leader Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments. Thank you. Please consider the environment before printing this Email. CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail message and any attachments hereto may be legally privileged and confidential. The information is intended only for the recipient(s) named in this message. If you are not the intended recipient you are notified that any use, disclosure, copying or distribution is prohibited. If you have received this in error please contact the sender and delete this message and any attachments from your computer system. We do not guarantee that this message or any attachment to it is secure or free from errors, computer viruses or other conditions that may damage or interfere with data, hardware or software.
expire inventory process
Is it recommended to run expire inventory every day or can it be run once a week. Tim Brown Systems Specialist - Project Leader Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments. Thank you.
Re: expire inventory process
There is dependency between reclamation and expiry process. You have to run expiry daily to have daily reclamation. I have scheduled reclamation 3 times per day at time suitable for automatic reclamation. From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Tim Brown [tbr...@cenhud.com] Sent: Friday, July 02, 2010 10:58 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] expire inventory process Is it recommended to run expire inventory every day or can it be run once a week. Tim Brown Systems Specialist - Project Leader Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments. Thank you. Please consider the environment before printing this Email. CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail message and any attachments hereto may be legally privileged and confidential. The information is intended only for the recipient(s) named in this message. If you are not the intended recipient you are notified that any use, disclosure, copying or distribution is prohibited. If you have received this in error please contact the sender and delete this message and any attachments from your computer system. We do not guarantee that this message or any attachment to it is secure or free from errors, computer viruses or other conditions that may damage or interfere with data, hardware or software.
Expire Inventory
When expire inventory runs.. in what order is expiration processed? I would thought it would be in alphabetical order, but it does appear to be after closer examination. I wish we can expire inventory by the node name. That would be cool. Thanks, Sung Y. Lee Email: [EMAIL PROTECTED]
Re: Expire Inventory
It runs in the same order as the q auditocc output, which is the order that they were registered on the server. Ben -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Sung Lee Sent: Tuesday, June 17, 2008 9:36 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Expire Inventory When expire inventory runs.. in what order is expiration processed? I would thought it would be in alphabetical order, but it does appear to be after closer examination. I wish we can expire inventory by the node name. That would be cool. Thanks, Sung Y. Lee Email: [EMAIL PROTECTED] The BCI Email Firewall made the following annotations - *Confidentiality Notice: This E-Mail is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you have received this communication in error, please do not distribute, and delete the original message. Thank you for your compliance. You may contact us at: Blue Cross of Idaho 3000 E. Pine Ave. Meridian, Idaho 83642 1.208.345.4550 -
Re: Expire Inventory
Expiration is by node number. Numbers are assigned when the node is registered with the TSM server. Using the beginnode and endnode parameters of the expiration command you can perform selective expiration. To get the node numbers use these case-sensitive commands from a dsmadmc session. create sqltable Nodes Mynodes select c0,c1 from Mynodes order by c1 drop sqltable Mynodes Enjoy, Jim Schneider -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Sung Lee Sent: Tuesday, June 17, 2008 10:36 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Expire Inventory When expire inventory runs.. in what order is expiration processed? I would thought it would be in alphabetical order, but it does appear to be after closer examination. I wish we can expire inventory by the node name. That would be cool. Thanks, Sung Y. Lee Email: [EMAIL PROTECTED]
Re: Expire Inventory
Hi Sung, Expiring inventory by node seems to be one goal fro the next TSM release, see this presentation from Dave Cannon : http://tsm-symposium.oucs.ox.ac.uk/2007/papers/Dave%20Cannon%20-%20Preview%20of%20Future%20Enhancements.pdf By now, it can be done with undocumented options of the expire inventory command, on advide from support. You'll find some tricks about that here : http://www.lascon.co.uk/d005303.htm#m36 http://tsmwiki.com/tsmwiki/ExpireInventory BE REALLY CAREFULL using CREATE SQLT command ! Just a question, why do you want to expire nodes on an alphabetical order rather than on a tsm decided order ? -- Best regards / Cordialement / مع تحياتي Erwann SIMON Sung Lee a écrit : When expire inventory runs.. in what order is expiration processed? I would thought it would be in alphabetical order, but it does appear to be after closer examination. I wish we can expire inventory by the node name. That would be cool. Thanks, Sung Y. Lee Email: [EMAIL PROTECTED] -- Ce message ne contient aucun virus connu. http://www.astaro.fr -- Ce message ne contient aucun virus connu. http://www.astaro.fr
Re: Expire Inventory
Thank you to those you replied for quick turnaround information. I replied to not necessary in the order who replied first :-) But you know who you are. Actually I meant to say I would like to expire per node name not alphabetical. We performed a manual backup delete and wanted to see the results right away and instead of waiting for expiration to finish. Sung Y. Lee Email: [EMAIL PROTECTED] Erwann Simon [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 06/17/2008 11:56 AM Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] Expire Inventory Hi Sung, Expiring inventory by node seems to be one goal fro the next TSM release, see this presentation from Dave Cannon : http://tsm-symposium.oucs.ox.ac.uk/2007/papers/Dave%20Cannon%20-%20Preview%20of%20Future%20Enhancements.pdf By now, it can be done with undocumented options of the expire inventory command, on advide from support. You'll find some tricks about that here : http://www.lascon.co.uk/d005303.htm#m36 http://tsmwiki.com/tsmwiki/ExpireInventory BE REALLY CAREFULL using CREATE SQLT command ! Just a question, why do you want to expire nodes on an alphabetical order rather than on a tsm decided order ? -- Best regards / Cordialement / مع تحياتي Erwann SIMON Sung Lee a écrit : When expire inventory runs.. in what order is expiration processed? I would thought it would be in alphabetical order, but it does appear to be after closer examination. I wish we can expire inventory by the node name. That would be cool. Thanks, Sung Y. Lee Email: [EMAIL PROTECTED] -- Ce message ne contient aucun virus connu. http://www.astaro.fr -- Ce message ne contient aucun virus connu. http://www.astaro.fr ForwardSourceID:NT94AA
Expire inventory.
Question needing answered please. Is there a way to expire old data in your tape copy pools from a particular node? Dave Hensley Technical Analyst McNeilus Companies, Inc. Desk: 1-507-374-8587 Cell: 1-507-244-0921 Although this e-mail and any attachments are believed to be free of any virus or other defect which might affect any computer system, it is the responsibility of the recipient to check that it is virus-free and the sender accepts no responsibility or liability for any loss, injury, damage, cost or expense arising in any way from receipt or use thereof by the recipient. The information contained in this electronic mail message is confidential information and intended only for the use of the individual or entity named above, and may be privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please contact the sender immediately, delete this material from your computer and destroy all related paper media. Please note that the documents transmitted are not intended to be binding until a hard copy has been manually signed by all parties. Thank you.
Re: Expire inventory.
Dave, Yes. I got this from IBM support. expire inventory beginnode=number endnode=number To get the node numbers, use the following case-sensitive commands. From a dsmadmc session: create sqltable Nodes Mynodes select c0,c1 from Mynodes order by c1 drop sqltable Mynodes Cheers, Jim Schneider -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of David Hensley Sent: Monday, May 19, 2008 4:09 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Expire inventory. Question needing answered please. Is there a way to expire old data in your tape copy pools from a particular node? Dave Hensley Technical Analyst McNeilus Companies, Inc. Desk: 1-507-374-8587 Cell: 1-507-244-0921 Although this e-mail and any attachments are believed to be free of any virus or other defect which might affect any computer system, it is the responsibility of the recipient to check that it is virus-free and the sender accepts no responsibility or liability for any loss, injury, damage, cost or expense arising in any way from receipt or use thereof by the recipient. The information contained in this electronic mail message is confidential information and intended only for the use of the individual or entity named above, and may be privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please contact the sender immediately, delete this material from your computer and destroy all related paper media. Please note that the documents transmitted are not intended to be binding until a hard copy has been manually signed by all parties. Thank you.
Re: Expire inventory.
On May 19, 2008, at 5:09 PM, David Hensley wrote: Question needing answered please. Is there a way to expire old data in your tape copy pools from a particular node? dsmc expire -virtualnodename= FileSpec
Re: Expire inventory.
If your goal is to fully remove a node's data from a storage pool, rather than pruning certain files, see topic Copy Storage Pool, remove node from in http://people.bu.edu/rbs/ADSM.QuickFacts . Richard Sims
Expire Inventory.
I am running TSM server 5.5 on a Windows 2003 server. I want any data residing in my copy pools (Onsite and Offsite) over 42 days old to expire. The volumes that expire their data should show up as EMPTY. Below is a copy of a script that runs on the server daily. I am still not receiving any EMPTY. Tapes. Can anyone help me? /* --- DO NOT EDIT THIS SCRIPT ---*/ /* */ /* This script was generated as the */ /* result of the maintenance plan wizard */ /* or properties notebook. Editing this */ /* script will cause those tools to fail. */ /* */ /* --- DO NOT EDIT THIS SCRIPT ---*/ /***/ /* BACKUP_STORAGE_START */ /* BA_STG:DISKPRIM=HPOFFSITETAPEPOOL; */ /* BA_STG:HPONSITETAPEPOOL=HPOFFSITETAPEPOOL; */ /* BA_STG:DISKWINDIR=HPOFFSITETAPEPOOL; */ /* BACKUP_STORAGE_END */ PARALLEL backup stg DISKPRIM HPOFFSITETAPEPOOL wait=yes backup stg HPONSITETAPEPOOL HPOFFSITETAPEPOOL wait=yes backup stg DISKWINDIR HPOFFSITETAPEPOOL wait=yes SERIAL /* BACKUP_DB_START */ /* BA_DB:DEVCLASS=HPLTO;BATYPE=batype_full; */ /* BACKUP_DB_END */ backup db devclass=HPLTO type=full wait=yes /* REM_VOLS_START */ /* REM_VOLS:VOLNAME=*;WHERESTATE=MOUNTABLE;TOSTATE=Courier;APPEND=NO;REMOVE=Bulk;SOURCE=dbbackup; */ /* REM_VOLS_END */ move drm '*' wheresta=MOUNTABLE tostate=Courier app=NO rem=Bulk source=dbbackup wait=YES /* CREATE_RPF_START */ /* RPF:SOURCE=dbbackup; */ /* CREATE_RPF_END */ prepare source=dbbackup wait=YES DELETE VOLHISTORY TODATE=TODAY-1 TOTIME=00:01 type=dbb /* MIG_STG_START */ /* MIG_STG:STGPOOL=DISKPRIM;LOWMIG=60;DURATION=120; */ /* MIG_STG_END */ migrate stgpool DISKPRIM lowmig=60 duration=120 wait=yes /* EXP_INV_START */ /* EXP_INV:SKIPDIRS=NO;DURATION=120; */ /* EXP_INV_END */ expire inventory skipdirs=NO wait=yes duration=120 /* RECL_STG_START */ /* RECL_STG:STGPOOL=HPONSITETAPEPOOL;THRESHOLD=60;DURATION=360; */ /* RECL_STG:STGPOOL=TAPEPRIM;THRESHOLD=60;DURATION=360; */ /* RECL_STG:STGPOOL=HPOFFSITETAPEPOOL;THRESHOLD=60;DURATION=360; */ /* RECL_STG_END */ PARALLEL reclaim stgpool HPONSITETAPEPOOL threshold=60 duration=360 wait=yes reclaim stgpool HPOFFSITETAPEPOOL threshold=60 duration=360 wait=yes SERIAL Dave Hensley Although this e-mail and any attachments are believed to be free of any virus or other defect which might affect any computer system, it is the responsibility of the recipient to check that it is virus-free and the sender accepts no responsibility or liability for any loss, injury, damage, cost or expense arising in any way from receipt or use thereof by the recipient. The information contained in this electronic mail message is confidential information and intended only for the use of the individual or entity named above, and may be privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please contact the sender immediately, delete this material from your computer and destroy all related paper media. Please note that the documents transmitted are not intended to be binding until a hard copy has been manually signed by all parties. Thank you.
Re: Expire Inventory.
Do you have a script that you can run to see how many reclaimable tapes you have? For the storage pools you show below run the following two: select volume_name as ONSITE_VOLUME,est_capacity_mb as CAPACITY,pct_utilized as UTILIZATION,pct_reclaim as RECLAIMABLE from volumes where stgpool_name='HPONSITETAPEPOOL' and pct_reclaim=60 order by pct_reclaim desc select volume_name as OFFSITE_VOLUME,est_capacity_mb as CAPACITY,pct_utilized as UTILIZATION,pct_reclaim as RECLAIMABLE from volumes where stgpool_name='HPOFFSITETAPEPOOL' and pct_reclaim=60 order by pct_reclaim desc If you have an excessive number of tapes in an offsite pool you may want to manually run the reclaim stg command with the option to limit the number of volumes so that it actually completes. Also check your reuse delay setting on both tape storage pools. You may have a lot of volumes in pending status. See Ya' Howard -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of David Hensley Sent: Thursday, May 15, 2008 2:11 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Expire Inventory. I am running TSM server 5.5 on a Windows 2003 server. I want any data residing in my copy pools (Onsite and Offsite) over 42 days old to expire. The volumes that expire their data should show up as EMPTY. Below is a copy of a script that runs on the server daily. I am still not receiving any EMPTY. Tapes. Can anyone help me? /* --- DO NOT EDIT THIS SCRIPT ---*/ /* */ /* This script was generated as the */ /* result of the maintenance plan wizard */ /* or properties notebook. Editing this */ /* script will cause those tools to fail. */ /* */ /* --- DO NOT EDIT THIS SCRIPT ---*/ /***/ /* BACKUP_STORAGE_START */ /* BA_STG:DISKPRIM=HPOFFSITETAPEPOOL; */ /* BA_STG:HPONSITETAPEPOOL=HPOFFSITETAPEPOOL; */ /* BA_STG:DISKWINDIR=HPOFFSITETAPEPOOL; */ /* BACKUP_STORAGE_END */ PARALLEL backup stg DISKPRIM HPOFFSITETAPEPOOL wait=yes backup stg HPONSITETAPEPOOL HPOFFSITETAPEPOOL wait=yes backup stg DISKWINDIR HPOFFSITETAPEPOOL wait=yes SERIAL /* BACKUP_DB_START */ /* BA_DB:DEVCLASS=HPLTO;BATYPE=batype_full; */ /* BACKUP_DB_END */ backup db devclass=HPLTO type=full wait=yes /* REM_VOLS_START */ /* REM_VOLS:VOLNAME=*;WHERESTATE=MOUNTABLE;TOSTATE=Courier;APPEND=NO;REMOV E=Bulk;SOURCE=dbbackup; */ /* REM_VOLS_END */ move drm '*' wheresta=MOUNTABLE tostate=Courier app=NO rem=Bulk source=dbbackup wait=YES /* CREATE_RPF_START */ /* RPF:SOURCE=dbbackup; */ /* CREATE_RPF_END */ prepare source=dbbackup wait=YES DELETE VOLHISTORY TODATE=TODAY-1 TOTIME=00:01 type=dbb /* MIG_STG_START */ /* MIG_STG:STGPOOL=DISKPRIM;LOWMIG=60;DURATION=120; */ /* MIG_STG_END */ migrate stgpool DISKPRIM lowmig=60 duration=120 wait=yes /* EXP_INV_START */ /* EXP_INV:SKIPDIRS=NO;DURATION=120; */ /* EXP_INV_END */ expire inventory skipdirs=NO wait=yes duration=120 /* RECL_STG_START */ /* RECL_STG:STGPOOL=HPONSITETAPEPOOL;THRESHOLD=60;DURATION=360; */ /* RECL_STG:STGPOOL=TAPEPRIM;THRESHOLD=60;DURATION=360; */ /* RECL_STG:STGPOOL=HPOFFSITETAPEPOOL;THRESHOLD=60;DURATION=360; */ /* RECL_STG_END */ PARALLEL reclaim stgpool HPONSITETAPEPOOL threshold=60 duration=360 wait=yes reclaim stgpool HPOFFSITETAPEPOOL threshold=60 duration=360 wait=yes SERIAL Dave Hensley Although this e-mail and any attachments are believed to be free of any virus or other defect which might affect any computer system, it is the responsibility of the recipient to check that it is virus-free and the sender accepts no responsibility or liability for any loss, injury, damage, cost or expense arising in any way from receipt or use thereof by the recipient. The information contained in this electronic mail message is confidential information and intended only for the use of the individual or entity named above, and may be privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please contact the sender immediately, delete this material from your computer and destroy all related paper media. Please note that the documents transmitted are not intended to be binding until a hard copy has been manually signed by all parties. Thank you.
Re: Expire Inventory.
On May 15, 2008, at 3:10 PM, David Hensley wrote: I am running TSM server 5.5 on a Windows 2003 server. I want any data residing in my copy pools (Onsite and Offsite) over 42 days old to expire. The volumes that expire their data should show up as EMPTY. Below is a copy of a script that runs on the server daily. I am still not receiving any EMPTY. Tapes. Can anyone help me? It is unlikely that tapes will go empty on their own, due to the persistence of Active files representing unchanging files on clients. You should principally experience tapes returning to Scratch by virtue of reclamation, rather than retention policies. Note also that you impose a time limit on expirations, which could result in a growing backlog of expired data, depending upon your system size. Richard Sims
Re: Run expire inventory before TSM Server upgrade
Cool, because we run it to completion daily, followed by reclamation processing. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Monday, February 25, 2008 4:54 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Run expire inventory before TSM Server upgrade The IBM advisory to run Expire Inventory prior to an upgrade is probably to deal with customers who don't run them regularly, and who may get flustered in the time taken by any database updating involved in the upgrade. I would imagine that all of us are running Expire Inventory to completion as frequently as feasible, so it's a non- instruction for us. Richard Simsat Boston University - Confidentiality Notice: The information contained in this email message is privileged and confidential information and intended only for the use of the individual or entity named in the address. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this information is strictly prohibited. If you received this information in error, please notify the sender and delete this information from your computer and retain no copies of any of this information.
Run expire inventory before TSM Server upgrade
Why does the documentation recommend thisà Before migrating the Tivoli(R) Storage Manager server to the new release, perform some clean up by running the EXPIRE INVENTORY command. We are planning to upgrade from 5.3.1.2 to 5.4.0 to 5.4.2, this Thursday. Is there anyone out there that can say that adding 'expire inventory' to our to-do list will actually save us some time, considering an expire is time-consuming itself? God bless you!!! Chip Bell Network Engineer I IBM Tivoli Certified Deployment Professional Baptist Health System Birmingham, AL - Confidentiality Notice: The information contained in this email message is privileged and confidential information and intended only for the use of the individual or entity named in the address. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this information is strictly prohibited. If you received this information in error, please notify the sender and delete this information from your computer and retain no copies of any of this information.
Re: Run expire inventory before TSM Server upgrade
The IBM advisory to run Expire Inventory prior to an upgrade is probably to deal with customers who don't run them regularly, and who may get flustered in the time taken by any database updating involved in the upgrade. I would imagine that all of us are running Expire Inventory to completion as frequently as feasible, so it's a non- instruction for us. Richard Simsat Boston University
Re: Run expire inventory before TSM Server upgrade
We did not run expire before our upgrade last month. We do run expire to completion daily. Andy Huebner -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Monday, February 25, 2008 4:54 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Run expire inventory before TSM Server upgrade The IBM advisory to run Expire Inventory prior to an upgrade is probably to deal with customers who don't run them regularly, and who may get flustered in the time taken by any database updating involved in the upgrade. I would imagine that all of us are running Expire Inventory to completion as frequently as feasible, so it's a non- instruction for us. Richard Simsat Boston University This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.
Re: 'generate backupset' and 'expire inventory'
I generally do a LOCK NODE prior to GENERATE BACKUPSET which I know will take a long time. I'm currently in a Disaster Recovery situation for several dozen client nodes that were destroyed in a fire. I've locked them all, and removed their associations with any schedule, to prevent inadvertent backups which would cause unintended de-activation or expiration of valuable pre-disaster files. Expiration has not been an issue. New backups has, especially since a new backup can trigger expiration of that node. Stop that node from backing up until you fully restore it, by whatever means either by normal client restore, or by delivering a generated backupset on a stack of DVDs. Once you stop backup, then normal expiration will simply skip over that node. Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] On Fri, 25 Jan 2008, Thomas Denier wrote: Earlier today I attempted to create a backup set for a very large file server. The process generating the backup set was running at the same time as our daily inventory expiration process. As far as I can tell, all went well until inventory expiration got to the system for which the backup set was being created, at which point a remarkably ugly deadlock condition occured. The backup set process, the inventory expiration process, and a tape reclamation process all stopped making headway, and client sessions were starting but not making any headway after they connected. I ended up cancelling the backup set process. Our server is at the 5.3.4.0 level and runs under mainframe Linux. The client involved is a Windows 2003 system with 5.3.4.0 client code. Is there a bug fix that will prevent the deadlock condition? What would happen if we tried to run a 'generate backupset' process that run through the normal backup window for the client involved? Extrapolation from the part of the backup set that completed before the deadlock suggests that the entire process would take 13 hours. This would make it a mathematical impossibility to avoid overlap with either the client backup window or the normal inventory expiration window.
'generate backupset' and 'expire inventory'
Earlier today I attempted to create a backup set for a very large file server. The process generating the backup set was running at the same time as our daily inventory expiration process. As far as I can tell, all went well until inventory expiration got to the system for which the backup set was being created, at which point a remarkably ugly deadlock condition occured. The backup set process, the inventory expiration process, and a tape reclamation process all stopped making headway, and client sessions were starting but not making any headway after they connected. I ended up cancelling the backup set process. Our server is at the 5.3.4.0 level and runs under mainframe Linux. The client involved is a Windows 2003 system with 5.3.4.0 client code. Is there a bug fix that will prevent the deadlock condition? What would happen if we tried to run a 'generate backupset' process that run through the normal backup window for the client involved? Extrapolation from the part of the backup set that completed before the deadlock suggests that the entire process would take 13 hours. This would make it a mathematical impossibility to avoid overlap with either the client backup window or the normal inventory expiration window.
expire inventory performance
We have a TSM Server on SUSE Linux Enterprise Server 10 One week ago I updated the TSM Server for Linux/x86_64 from version5.4.0.3 to 5.4.1.2 Since that the duration of Expire Inventory went from 1 hour to 1 hour 20 minutes. Everything else is as usual. Has someone else observed something similar? Karl Rößmann -- Karl RößmannTel. +49-711-689-1657 Max-Planck-Institut FKF Fax. +49-711-689-1198 Postfach 800 665 70506 Stuttgart email [EMAIL PROTECTED]
Long running expire inventory
I posted this before, not sure if it made it out there. I have a TSM server version 5.3.3.1 on AIX with a 70GB database. I recently moved my db/log vols from 500GB sata drives to internal drives along with mirrored vols on separate internal drives on the aix box. My backups went from 2 hours to 30 minutes, my startup went from about 2 hrs to 20-30 minutes, and I've seen other performance gains. Everything seems better except for my expire inventory in went from running in a couple of hours to several hours, and my current expiration has been running since yesterday morning at 10:00 a.m.. Does anybody know why my expire inventory run times would have gotten worse. I can't really tell from the activity log. Any suggestions? This has been running for almost 24 hours: tsm: TSMCORP3q pr Process Process Description Status Number - 2,301 Expiration Examined 1600 objects, deleting 1568 backup objects, 0 archive objects, 0 DB backup volumes, 0 recovery plan files; 0 errors encountered. This email and any files transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended addressee, then you have received this email in error and any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Please notify us immediately of your unintended receipt by reply and then delete this email and your reply. Tyson Foods, Inc. and its subsidiaries and affiliates will not be held liable to any person resulting from the unintended or unauthorized use of any information contained in this email or as a result of any additions or deletions of information originally contained in this email.
Fw: Long running expire inventory
Your startup time was 2 hours, and is now only 30 minutes? I've had MUCH bigger databases that come back from a crash, with a nearly full log, faster than that. Combined with the poor performance on expiration, I'd guess you have some corruption in the database, or something wrong on the system. Have you measured CPU utilization, disk IO, memory usage? Is something there at 100%? I did use the words database corruption, which, to me, means Call TSM Support. While there's great knowledge on the list about the analysis and recovery tools, you want to get it from TSM Support. Nick Cassimatis - Forwarded by Nicholas Cassimatis/Raleigh/IBM on 04/17/2007 08:51 AM - ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 04/17/2007 08:21:02 AM: I posted this before, not sure if it made it out there. I have a TSM server version 5.3.3.1 on AIX with a 70GB database. I recently moved my db/log vols from 500GB sata drives to internal drives along with mirrored vols on separate internal drives on the aix box. My backups went from 2 hours to 30 minutes, my startup went from about 2 hrs to 20-30 minutes, and I've seen other performance gains. Everything seems better except for my expire inventory in went from running in a couple of hours to several hours, and my current expiration has been running since yesterday morning at 10:00 a.m.. Does anybody know why my expire inventory run times would have gotten worse. I can't really tell from the activity log. Any suggestions? This has been running for almost 24 hours: tsm: TSMCORP3q pr Process Process Description Status Number - 2,301 Expiration Examined 1600 objects, deleting 1568 backup objects, 0 archive objects, 0 DB backup volumes, 0 recovery plan files; 0 errors encountered. This email and any files transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended addressee, then you have received this email in error and any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Please notify us immediately of your unintended receipt by reply and then delete this email and your reply. Tyson Foods, Inc. and its subsidiaries and affiliates will not be held liable to any person resulting from the unintended or unauthorized use of any information contained in this email or as a result of any additions or deletions of information originally contained in this email.
How does EXPIRE INVENTORY work ?
Hi *SMers, i've come across some behaviour of the EXPIRE IVENTORY command which i don't understand. We have a daily job that executes EXPIRE EIVENTORY. Results are shown in the Activity Log and read as follows: 09/02/06 07:49:48 ANR0812I Inventory file expiration process 301 completed: examined 9604 objects, deleting 1929 backup objects, 0 archive objects, 0 DB backup volumes, and 0 recoveryplan files. 0 errors were encountered. 09/04/06 05:15:35 ANR0812I Inventory file expiration process 313 completed: examined 40052 objects, deleting 1162 backup objects, 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. Two things really upset me: - The numbers of objects examined are significant different, but i am sure the database grows very slowly - A rough estimate for the total number of objects gives a value somewhere between 200,000 and 300,000 objects. Can someone shade a light on this? Thanks in advance regards Guenther -- Guenther Bergmann, Am Kreuzacker 10, 63150 Heusenstamm, Germany Guenther_Bergmann at gbergmann dot de http://www.gbergmann.de
Re: How does EXPIRE INVENTORY work ?
Each time it is basicly expiring files that no longer are required to meet the definitions in the mangement group. Perhaps a client deleted a file system and the number of days for inactive file retention was passed. [EMAIL PROTECTED] 09/11/06 1:07 PM Hi *SMers, i've come across some behaviour of the EXPIRE IVENTORY command which i don't understand. We have a daily job that executes EXPIRE EIVENTORY. Results are shown in the Activity Log and read as follows: 09/02/06 07:49:48 ANR0812I Inventory file expiration process 301 completed: examined 9604 objects, deleting 1929 backup objects, 0 archive objects, 0 DB backup volumes, and 0 recoveryplan files. 0 errors were encountered. 09/04/06 05:15:35 ANR0812I Inventory file expiration process 313 completed: examined 40052 objects, deleting 1162 backup objects, 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. Two things really upset me: - The numbers of objects examined are significant different, but i am sure the database grows very slowly - A rough estimate for the total number of objects gives a value somewhere between 200,000 and 300,000 objects. Can someone shade a light on this? Thanks in advance regards Guenther -- Guenther Bergmann, Am Kreuzacker 10, 63150 Heusenstamm, Germany Guenther_Bergmann at gbergmann dot de http://www.gbergmann.de The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain information that is confidential, privileged, and/or otherwise exempt from disclosure under applicable law. If this electronic message is from an attorney or someone in the Legal Department, it may also contain confidential attorney-client communications which may be privileged and protected from disclosure. If you are not the intended recipient, be advised that you have received this message in error and that any use, dissemination, forwarding, printing, or copying is strictly prohibited. Please notify the New York State Thruway Authority immediately by either responding to this e-mail or calling (518) 436-2700, and destroy all copies of this message and any attachments.
Re: How does EXPIRE INVENTORY work ?
Don't worry about it. According to a talk I heard from L2 support, the expire inventory process is optimized and clever. It looks at the objects belonging to a filespace, expires those that are ready to expire, but can tell by the dates when it doesn't need to look further through the filespace for things that have expired. So it doesn't have to look at every object in the DB, and objects examined is not an indicator of how many objects you have in the data base. Wanda Prather I/O, I/O, It's all about I/O -(me) -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Lawrence Clark Sent: Monday, September 11, 2006 1:14 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: How does EXPIRE INVENTORY work ? Each time it is basicly expiring files that no longer are required to meet the definitions in the mangement group. Perhaps a client deleted a file system and the number of days for inactive file retention was passed. [EMAIL PROTECTED] 09/11/06 1:07 PM Hi *SMers, i've come across some behaviour of the EXPIRE IVENTORY command which i don't understand. We have a daily job that executes EXPIRE EIVENTORY. Results are shown in the Activity Log and read as follows: 09/02/06 07:49:48 ANR0812I Inventory file expiration process 301 completed: examined 9604 objects, deleting 1929 backup objects, 0 archive objects, 0 DB backup volumes, and 0 recoveryplan files. 0 errors were encountered. 09/04/06 05:15:35 ANR0812I Inventory file expiration process 313 completed: examined 40052 objects, deleting 1162 backup objects, 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. Two things really upset me: - The numbers of objects examined are significant different, but i am sure the database grows very slowly - A rough estimate for the total number of objects gives a value somewhere between 200,000 and 300,000 objects. Can someone shade a light on this? Thanks in advance regards Guenther -- Guenther Bergmann, Am Kreuzacker 10, 63150 Heusenstamm, Germany Guenther_Bergmann at gbergmann dot de http://www.gbergmann.de The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain information that is confidential, privileged, and/or otherwise exempt from disclosure under applicable law. If this electronic message is from an attorney or someone in the Legal Department, it may also contain confidential attorney-client communications which may be privileged and protected from disclosure. If you are not the intended recipient, be advised that you have received this message in error and that any use, dissemination, forwarding, printing, or copying is strictly prohibited. Please notify the New York State Thruway Authority immediately by either responding to this e-mail or calling (518) 436-2700, and destroy all copies of this message and any attachments.
Re: How does EXPIRE INVENTORY work ?
...09/02/06 07:49:48 ANR0812I Inventory file expiration process 301 ... See that message number in http://people.bu.edu/rbs/ADSM.QuickFacts for collected factoids. All behaviors are subject to change with product evolution. Richard Sims
FW: Expire Inventory
Hello I have a Windows 2003 TSM server with LTO2 and 3 tape drives with Ultrium driver 6.0.8.2, everytime it reboots it loses the ultrium device drivers on some of the LTO2 and 3 tape drives. The actual SCSI ids change i.e. lb0.1.0.9 then after reboot it becomes lb0.1.0.10. Dioes anyone know why these SCSI IDs are changing? Persistent binding is on Removable storage manager is off Thanks Ian _ Ian Smith SAN/TSM Specialist _ This email (including any attachments to it) is confidential, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this email in error, please advise us immediately and delete it. You are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Although we have taken reasonable precautions to ensure no viruses are present in this email, we cannot accept responsibility for any loss or damage arising from the viruses in this email or attachments. We exclude any liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided in this email or its attachments, unless that information is subsequently confirmed in writing. If this email contains an offer, that should be considered as an invitation to treat. _
Re: Expire Inventory
Depends entirely on your server. There's no chart based on the overall load incurred; however, the extra I/O is all actlog. If your DB performance has room to spare, then it shouldn't be a problem. You could always turn it on for a day and compare your expiration performance the next day with: select activity, cast((end_time) as date) as Date, - (examined/cast((end_time-start_time) seconds - as decimal(18,13))*3600)Pages backed up/Hr - from summary where activity like '%DB%' and - days(end_time) - days(start_time)=0 -Josh On 06.02.13 at 09:05 [EMAIL PROTECTED] wrote: Date: Mon, 13 Feb 2006 09:05:16 -0500 From: David E Ehresman [EMAIL PROTECTED] Reply-To: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To: ADSM-L@VM.MARIST.EDU Subject: Re: Expire Inventory Instead, you may want to run EXPire Inventory with Quiet=No Does the QUIET=NO vs QUIET=YES on expirations have much of an effect on the overall speed of expiration? David
Expire Inventory
Hi I have been having database performance issues possibly related to unexpired objects in the database. The problem manifests itself with all the client sessions during the backup window grinding to a halt. There are 7 pages of locks on the database and nothing is moving. After running expiration, which expired 60% of the objects that is analysed, the problems goes away. Can anyone tell me how to work out the actual number of objects in the database? Also, once the expiration process complete- I ran it again, immediately and it found another few hundred thousand objects to expire- why? Has anyone else seen this type of problem? If so is there a statement that can be written to analyse the number of unexpired objects that currently reside in the database? As light weight as possible, as a heavy weight global lock enforced by a big statement probably wont complete when the system is under this massive load! Thanks Ian _ Ian Smith SAN/TSM Specialist _ This email (including any attachments to it) is confidential, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this email in error, please advise us immediately and delete it. You are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Although we have taken reasonable precautions to ensure no viruses are present in this email, we cannot accept responsibility for any loss or damage arising from the viruses in this email or attachments. We exclude any liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided in this email or its attachments, unless that information is subsequently confirmed in writing. If this email contains an offer, that should be considered as an invitation to treat. _
Re: Expire Inventory
Ian - It sounds like you're cursed with a high-churn environment... You seem to have clients whose file population is greatly changing over time, making for a lot of work for the TSM server. You can look at Occupancy for your number of files in the TSM server, but that's not going to tell you much, as time is passing and files are aging and moving toward expiration as you analyze. Instead, you may want to run EXPire Inventory with Quiet=No and get some sense of what's contributing the most. You can probably get an equivalent sense by analyzing your client session recordings of number of files being sent, per the Activity Log or accounting records, where some of them will stand out numerically. Then you can talk to the client administrators and determine what's going on. Or it may be that the expirations you're seeing now were from some client transition event in the distant past, depending upon your retention policies. It might also be the case that your Expirations had fallen behind at some point, and are now catching up. Keep in mind that Expiration runs, not against your server files inventory, but against the internal server table called Expiring.Objects, which is populated during client-induced object expirations and time-based expirations in the server (presumably through one of its ongoing housekeeping threads). It's a bucket which gets refilled, and so another expiration run will get more work from that. So do the investigation, assure that your TSM db is configured for best performance, and spread client activity and server maintenance processes over time to the extent possible to mitigate contention. Richard Sims On Feb 13, 2006, at 5:03 AM, Smith, I (Ian) wrote: Hi I have been having database performance issues possibly related to unexpired objects in the database. The problem manifests itself with all the client sessions during the backup window grinding to a halt. There are 7 pages of locks on the database and nothing is moving. After running expiration, which expired 60% of the objects that is analysed, the problems goes away. Can anyone tell me how to work out the actual number of objects in the database? Also, once the expiration process complete- I ran it again, immediately and it found another few hundred thousand objects to expire- why? Has anyone else seen this type of problem? If so is there a statement that can be written to analyse the number of unexpired objects that currently reside in the database? As light weight as possible, as a heavy weight global lock enforced by a big statement probably wont complete when the system is under this massive load!
Fw: Expire Inventory
One recommendation would be to try to avoid having expiration running while client sessions are accessing the server. They both hit the some of the same parts of the database, so the locks do start to conflict. You can run expiration in multiple windows through the day (with the duration parameter) to avoid other processing that it could conflict with (client backups and TSM database backups). Nick Cassimatis - Forwarded by Nicholas Cassimatis/Raleigh/IBM on 02/13/2006 07:37 AM - ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 02/13/2006 05:03:47 AM: Hi I have been having database performance issues possibly related to unexpired objects in the database. The problem manifests itself with all the client sessions during the backup window grinding to a halt. There are 7 pages of locks on the database and nothing is moving. After running expiration, which expired 60% of the objects that is analysed, the problems goes away. Can anyone tell me how to work out the actual number of objects in the database? Also, once the expiration process complete- I ran it again, immediately and it found another few hundred thousand objects to expire- why? Has anyone else seen this type of problem? If so is there a statement that can be written to analyse the number of unexpired objects that currently reside in the database? As light weight as possible, as a heavy weight global lock enforced by a big statement probably wont complete when the system is under this massive load! Thanks Ian _ Ian Smith SAN/TSM Specialist _ This email (including any attachments to it) is confidential, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this email in error, please advise us immediately and delete it. You are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Although we have taken reasonable precautions to ensure no viruses are present in this email, we cannot accept responsibility for any loss or damage arising from the viruses in this email or attachments. We exclude any liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided in this email or its attachments, unless that information is subsequently confirmed in writing. If this email contains an offer, that should be considered as an invitation to treat. _
Re: Expire Inventory
Instead, you may want to run EXPire Inventory with Quiet=No Does the QUIET=NO vs QUIET=YES on expirations have much of an effect on the overall speed of expiration? David
expire inventory, examined objects
Storage Management Server for AIX-RS/6000 - Version 5, Release 1, Level 7.3 We do EXPPRE INVENTORY every day and receive a message like ANR0812I Inventory file expiration process 9171 completed: examined 4761131 objects, deleting 56808 backup objects, 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. During the last year the number of examined objects did not change dramatically, but since last week we have an increase of 1.5 million examined objects. We observed the number of inactive files and DEACTIVATE_DATE from the BACKUPS table. We observed the number of files in AUDITOCCUPANCY We could not find any explanation. Any ideas ? -- Karl Roessmann Tel. +49-711-689-1657 Max-Planck-Institut FKF Fax. +49-711-689-1198 Postfach 800 665 70506 Stuttgart email [EMAIL PROTECTED]
Re: expire inventory, examined objects
Hello Karl, we observed the same thing when we migrated from Version 5, Release 1, Level 8 to Version 5, Release 2, Level 0. ANR0812I Inventory file expiration process 273 completed: examined 421039003 objects, deleting 3974009 backup objects, 247900 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 97849, PROCESS: 273) Maybe the expiration process is getting more and more enhanced. Greetings, Bert Moonen ABP / USZO CIS / BS / TB / Storage Management Telefoon : +31(0)45 579 7773 Fax : +31(0)45 579 3990 Email : [EMAIL PROTECTED] Centrale Mailbox : Centrale Mailbox - BS Storage (eumbx05) Tech Support: Have you made backups of your software and data? Customer: I didn't know it had a reverse. -Oorspronkelijk bericht- Van: Karl Roessmann [mailto:[EMAIL PROTECTED] Verzonden: dinsdag 2 maart 2004 12:39 Aan: [EMAIL PROTECTED] Onderwerp: expire inventory, examined objects Storage Management Server for AIX-RS/6000 - Version 5, Release 1, Level 7.3 We do EXPPRE INVENTORY every day and receive a message like ANR0812I Inventory file expiration process 9171 completed: examined 4761131 objects, deleting 56808 backup objects, 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. During the last year the number of examined objects did not change dramatically, but since last week we have an increase of 1.5 million examined objects. We observed the number of inactive files and DEACTIVATE_DATE from the BACKUPS table. We observed the number of files in AUDITOCCUPANCY We could not find any explanation. Any ideas ? -- Karl Roessmann Tel. +49-711-689-1657 Max-Planck-Institut FKF Fax. +49-711-689-1198 Postfach 800 665 70506 Stuttgart email [EMAIL PROTECTED] =DISCLAIMER= De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen. The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose its contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission.
cleanup backupgroups and expire inventory
Hi *, I need your help!!! We have 2 TSM-server, both on AIX 4.3.3. The first Server is on TSM V 4.2.2.6 and second Server is on TSM V 4.2.4.0. On both server are librarys attached. Three steps to backup the clients. 1. backup the client to SSA-disks on the first server 2. migrate this data to the first library 3. backup stg for copy data from the first library to the second library on the second TS-server Now I have a big problem with the space on the second server. I can delete some data on the first server and run exp inventory and I get more space in the library. It runs fine. But I get no space on the second server and now the library is full. I search in this mailing lists and find some hint s for 1. audtit db fix=yes 2. claenup backupsgroups Can this help?? Best regards, Frank Mueller
Problem with Expire Inventory.
Hi, folks. I'm having a trouble with TSM Version 5, Release 1, Level 1.0 Whem I run Expire inventory, I received the following message: 11/04/2003 07:00:10 ANR0106E imarqry.c(4633): Unexpected error 2 fetching row in table Archive.Descriptions. 11/04/2003 07:00:10 ANR0104E imarins.c(1503): Error 2 deleting row from table Archive.Descriptions. I saw a possible solution that will be run a DB Fix (auditdb fix=yes) and clean the table entries (clean archdir), but the problem stays over How can I repair my database ??? Hugs for everybody !!! Jorge Martins _ Quer ajudar o Brasil e nco sabe como? AjudaBrasil: http://www.ajudabrasil.org/mail.html.
Re: Problem with Expire Inventory.
On Wed, 5 Nov 2003 12:58:36 -0200 Jorge Martins [EMAIL PROTECTED] wrote: Hi, folks. I'm having a trouble with TSM Version 5, Release 1, Level 1.0 Whem I run Expire inventory, I received the following message: 11/04/2003 07:00:10 ANR0106E imarqry.c(4633): Unexpected error 2 fetching row in table Archive.Descriptions. 11/04/2003 07:00:10 ANR0104E imarins.c(1503): Error 2 deleting row from table Archive.Descriptions. I saw a possible solution that will be run a DB Fix (auditdb fix=yes) and clean the table entries (clean archdir), but the problem stays over How can I repair my database ??? call tsm support... They have found marvellous solutions to repair my db once, and it didn't even include an audit Hugs for everybody !!! Jorge Martins _ Quer ajudar o Brasil e nco sabe como? AjudaBrasil: http://www.ajudabrasil.org/mail.html. -- Met vriendelijke groeten, Remco Post SARA - Reken- en Netwerkdiensten http://www.sara.nl High Performance Computing Tel. +31 20 592 8008Fax. +31 20 668 3167 I really didn't foresee the Internet. But then, neither did the computer industry. Not that that tells us very much of course - the computer industry didn't even foresee that the century was going to end. -- Douglas Adams
Expire Inventory process on a 24GB DB?
Enviro: W2K TSM 5.1.6.3 I have been doing an expire inventory for some 14 hours now after changing the MC (# in retain extra versions) which is causing rebinding. Number of nodes to rebind: Node Name Type FilespaceFSID Storage Number of Physical Logical Name Pool Name Files Space Space Occupied Occupied (MB) (MB) -- -- - -- - - - CIR_SERVER Bkup \\cir_ser- 1 DLTPOOL2 40,486 3,746.67 3,626.22 ver\c$ CIR_SERVER Bkup \\cir_ser- 2 DLTPOOL2 55,701 51,335.77 51,329.46 ver\d$ CIR_SERVER Bkup \\cir_ser- 3 DLTPOOL2 582 5,181.29 5,181.29 ver\f$ CIR_SERVER Bkup \\cir_ser- 4 DLTPOOL2 78 3,810.46 3,810.46 ver\g$ CIR_SERVER Bkup \\cir_ser- 5 DLTPOOL2 563 8,537.17 8,537.17 ver\h$ CIR_SERVER Bkup \\cir_ser- 6 DLTPOOL2 21,886 21,195.37 21,195.36 ver\i$ CIR_SERVER Bkup SYSTEM 7 DLTPOOL2 11,611 1,457.64 1,457.64 OBJECT GV-GRIEGBkup \\gv-grie- 1 DLTPOOL28,014 1,360.96 1,303.52 g\c$ GV-GRIEGBkup \\gv-grie- 2 DLTPOOL2 16,136 708,755.7 708,365.9 g\d$ 4 0 GV-HELPDE- Bkup \\gv-help- 1 DLTPOOL29,889 930.72 821.88 SKdesk\c$ GV-HELPDE- Bkup \\gv-help- 2 DLTPOOL2 173,454 339,038.7 337,217.2 SKdesk\d$ 0 5 GV-HELPDE- Bkup \\gv-help- 3 DLTPOOL23 0.00 0.00 SKdesk\e$ GV-ITDEVBkup \\gv-itde- 1 DLTPOOL2 20,795 1,919.14 1,828.15 v\c$ GV-ITDEVBkup \\gv-itde- 2 DLTPOOL226,319,35 2,201,544 2,188,569 v\d$ 2.79 .38 GV-ITDEVBkup \\gv-itde- 3 DLTPOOL22 0.01 0.01 v\e$ GV-ITDEVBkup \\gv-itde- 4 DLTPOOL21,381 584.32 584.32 v\f$ GV-ITDEVBkup \\gv-itde- 5 DLTPOOL2 14 5.37 5.37 v\j$ GV-ITDEVBkup SYSTEM 6 DLTPOOL2 38,194 4,773.29 4,773.29 OBJECT GV-ODIN Bkup \\gv-odin- 1 DLTPOOL24,450 930.13 890.27 \c$ GV-ODIN Bkup \\gv-odin- 2 DLTPOOL2 319,636 40,882.39 40,738.97 \d$ GV-PVCS Bkup \\gv-pvcs- 1 DLTPOOL2 17,860 2,052.13 1,937.81 \c$ GV-SCDHCP Bkup \\gv-scdh- 1 DLTPOOL27,036 823.27 798.70 cp\c$ GV-TASKEBkup \\gv-task- 1 DLTPOOL29,939 1,664.50 1,658.13 e\c$ GV-TASKEBkup \\gv-task- 2 DLTPOOL24,039 280.37 280.37 e\e$ GV1 Bkup \\gv1\c$1 DLTPOOL2 10,380 991.95 972.94 GV1 Bkup \\gv1\d$2 DLTPOOL25,909 1,504.43 1,504.43 GV1 Bkup \\gv1\f$3 DLTPOOL2 541 195.28 195.28 GV1 Bkup SYSTEM 4 DLTPOOL2 30,623 4,485.21 4,485.21 OBJECT GV_NUTKIN Bkup \\gv_nutk- 1 DLTPOOL25,865 975.10 851.19 in\c$ GV_NUTKIN Bkup \\gv_nutk- 2 DLTPOOL22 0.01 0.01 in\d$ GV_NUTKIN Bkup \\gv_nutk- 3 DLTPOOL2 986 4,261.35 4,261.35 in\e$ GV_ROCKYBkup \\gv_rock- 1 DLTPOOL24,533 656.26 601.28 y\c$ GV_ROCKYBkup \\gv_rock- 2 DLTPOOL24,343 83,665.93 83,665.93 y\d$ GV_ROCKYBkup \\gv_rock- 3 DLTPOOL22 0.01 0.01 y\e$ HOTSPALTBkup / 1 DLTPOOL22,610 41.95 41.95 HOTSPALTBkup /usr2 DLTPOOL2 47,607 1,532.10 1,532.10 HOTSPALTBkup /var3 DLTPOOL21,758 951.87 951.40 HOTSPALTBkup /home 4 DLTPOOL22,660 71.24 71.24 HOTSPALTBkup /home/wor- 5 DLTPOOL21,114 80.45 80.45 kflow HOTSPALTBkup /opt6 DLTPOOL2 114,104 31,088.24 31,088.24 HOTSPALTBkup /opt2 7 DLTPOOL2 99 25,501.85 25,501.85 METRIXALT Bkup / 1 DLTPOOL21,386 45.93 45.93 METRIXALT Bkup /usr2 DLTPOOL2 34,377 934.21 934.21 METRIXALT Bkup /var3 DLTPOOL2 581 212.50 212.03 METRIXALT Bkup /home 4
Re: Expire Inventory process on a 24GB DB?
1) Could take a while depending on how you changed your retention for example if you went from 180 active version of a file to 20 then TSM would have to potentially expire 60xeach changed file. In additional WIN2k is not know for very fast I/O, not to mention if your tsm db is not layed out in an optimal way (multiple disks etc) could affect performance of that process If you need to cancel make sure and do Cancel expiration so when you start expire inventory again it should pick up where it left off. Keep an eye on your log, expiration could reek havoc on it. 2- 3 ) Hard to say, I think there's a way to find out object count other than keeping an eye on the process which tells you how many expired and how many processed. Hope this helps -Original Message- From: Ken Sedlacek [mailto:[EMAIL PROTECTED] Sent: Friday, August 22, 2003 7:10 AM To: [EMAIL PROTECTED] Subject: Expire Inventory process on a 24GB DB? Enviro: W2K TSM 5.1.6.3 I have been doing an expire inventory for some 14 hours now after changing the MC (# in retain extra versions) which is causing rebinding. Number of nodes to rebind: Node Name Type FilespaceFSID Storage Number of Physical Logical Name Pool Name Files Space Space Occupied Occupied (MB) (MB) -- -- - -- - - - CIR_SERVER Bkup \\cir_ser- 1 DLTPOOL2 40,486 3,746.67 3,626.22 ver\c$ CIR_SERVER Bkup \\cir_ser- 2 DLTPOOL2 55,701 51,335.77 51,329.46 ver\d$ CIR_SERVER Bkup \\cir_ser- 3 DLTPOOL2 582 5,181.29 5,181.29 ver\f$ CIR_SERVER Bkup \\cir_ser- 4 DLTPOOL2 78 3,810.46 3,810.46 ver\g$ CIR_SERVER Bkup \\cir_ser- 5 DLTPOOL2 563 8,537.17 8,537.17 ver\h$ CIR_SERVER Bkup \\cir_ser- 6 DLTPOOL2 21,886 21,195.37 21,195.36 ver\i$ CIR_SERVER Bkup SYSTEM 7 DLTPOOL2 11,611 1,457.64 1,457.64 OBJECT GV-GRIEGBkup \\gv-grie- 1 DLTPOOL28,014 1,360.96 1,303.52 g\c$ GV-GRIEGBkup \\gv-grie- 2 DLTPOOL2 16,136 708,755.7 708,365.9 g\d$ 4 0 GV-HELPDE- Bkup \\gv-help- 1 DLTPOOL29,889 930.72 821.88 SKdesk\c$ GV-HELPDE- Bkup \\gv-help- 2 DLTPOOL2 173,454 339,038.7 337,217.2 SKdesk\d$ 0 5 GV-HELPDE- Bkup \\gv-help- 3 DLTPOOL23 0.00 0.00 SKdesk\e$ GV-ITDEVBkup \\gv-itde- 1 DLTPOOL2 20,795 1,919.14 1,828.15 v\c$ GV-ITDEVBkup \\gv-itde- 2 DLTPOOL226,319,35 2,201,544 2,188,569 v\d$ 2.79 .38 GV-ITDEVBkup \\gv-itde- 3 DLTPOOL22 0.01 0.01 v\e$ GV-ITDEVBkup \\gv-itde- 4 DLTPOOL21,381 584.32 584.32 v\f$ GV-ITDEVBkup \\gv-itde- 5 DLTPOOL2 14 5.37 5.37 v\j$ GV-ITDEVBkup SYSTEM 6 DLTPOOL2 38,194 4,773.29 4,773.29 OBJECT GV-ODIN Bkup \\gv-odin- 1 DLTPOOL24,450 930.13 890.27 \c$ GV-ODIN Bkup \\gv-odin- 2 DLTPOOL2 319,636 40,882.39 40,738.97 \d$ GV-PVCS Bkup \\gv-pvcs- 1 DLTPOOL2 17,860 2,052.13 1,937.81 \c$ GV-SCDHCP Bkup \\gv-scdh- 1 DLTPOOL27,036 823.27 798.70 cp\c$ GV-TASKEBkup \\gv-task- 1 DLTPOOL29,939 1,664.50 1,658.13 e\c$ GV-TASKEBkup \\gv-task- 2 DLTPOOL24,039 280.37 280.37 e\e$ GV1 Bkup \\gv1\c$1 DLTPOOL2 10,380 991.95 972.94 GV1 Bkup \\gv1\d$2 DLTPOOL25,909 1,504.43 1,504.43 GV1 Bkup \\gv1\f$3 DLTPOOL2 541 195.28 195.28 GV1 Bkup SYSTEM 4 DLTPOOL2 30,623 4,485.21 4,485.21 OBJECT GV_NUTKIN Bkup \\gv_nutk- 1 DLTPOOL25,865 975.10 851.19 in\c$ GV_NUTKIN Bkup \\gv_nutk- 2 DLTPOOL22 0.01 0.01 in\d$ GV_NUTKIN Bkup \\gv_nutk- 3 DLTPOOL2 986 4,261.35 4,261.35 in\e$ GV_ROCKYBkup \\gv_rock- 1 DLTPOOL24,533 656.26 601.28 y\c$ GV_ROCKYBkup \\gv_rock- 2 DLTPOOL24,343 83,665.93 83,665.93 y\d
Re: expire inventory not looking at all files
Sorry I should have included more information. I am running TSM server 5.1.6.3 and we run expiration daily by way of administrative command. And I am sure that at least there should be more than 10% of all of our files should be inactive or considered for expiration as we have been running TSM for more than 3 years, so I would hope to have 2 million+ files show up in the summary. Greg Redell Great-West Life Annuity Insurance Co. Phone: 314-525-5877 Email: [EMAIL PROTECTED] John Bremer [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 06/27/2003 05:08 PM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: expire inventory not looking at all files expire inventory is only looking at inactive versions of files. At 04:27 PM 6/27/2003 -0500, you wrote: I think I may have an issue. When Expire inventory runs it does not appear to run through all of my files. When I run the following sql statement I see many files but the expire inventory ending message does not match. Has any one seen this before? TIA select sum(num_files) as File Count from occupancy File Count --- 22802065 06/27/2003 16:21:00 ANR0812I Inventory file expiration process 175 completed: examined 2091 objects, deleting 0 backup objects, 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. 06/27/2003 16:21:00 ANR0985I Process 175 for EXPIRE INVENTORY running in the BACKGROUND completed with completion state SUCCESS at 16:21:00. Greg Redell Great-West Life Annuity Insurance Co. Phone: 314-525-5877 Email: [EMAIL PROTECTED]
Re: expire inventory not looking at all files
Sorry I should have included more information. I am running TSM server 5.1.6.3 and we run expiration daily by way of administrative command. And I am sure that at least there should be more than 10% of all of our files should be inactive or considered for expiration as we have been running TSM for more than 3 years, so I would hope to have 2 million+ files show up in the summary. Greg - If Expiration dumbly worked by running through the full list of Inactive files at every Expire Inventory, there would be a lot of disgruntled customers. The developers made it a lot smarter than that. *SM keeps track of the smaller list of expirables by virtue of file transitions: introduction into the system, retention changes, etc. And, of course, Expire Inventory deals with that set of files retained by age, rather than number of versions, making for that many fewer. The small number you are seeing reflects the number of candidates reflected in that table. Remember that directories can be a special case, due to their different binding. Richard Sims, BU
expire inventory not looking at all files
I think I may have an issue. When Expire inventory runs it does not appear to run through all of my files. When I run the following sql statement I see many files but the expire inventory ending message does not match. Has any one seen this before? TIA select sum(num_files) as File Count from occupancy File Count --- 22802065 06/27/2003 16:21:00 ANR0812I Inventory file expiration process 175 completed: examined 2091 objects, deleting 0 backup objects, 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. 06/27/2003 16:21:00 ANR0985I Process 175 for EXPIRE INVENTORY running in the BACKGROUND completed with completion state SUCCESS at 16:21:00. Greg Redell Great-West Life Annuity Insurance Co. Phone: 314-525-5877 Email: [EMAIL PROTECTED]
Re: expire inventory not looking at all files
expire inventory is only looking at inactive versions of files. At 04:27 PM 6/27/2003 -0500, you wrote: I think I may have an issue. When Expire inventory runs it does not appear to run through all of my files. When I run the following sql statement I see many files but the expire inventory ending message does not match. Has any one seen this before? TIA select sum(num_files) as File Count from occupancy File Count --- 22802065 06/27/2003 16:21:00 ANR0812I Inventory file expiration process 175 completed: examined 2091 objects, deleting 0 backup objects, 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. 06/27/2003 16:21:00 ANR0985I Process 175 for EXPIRE INVENTORY running in the BACKGROUND completed with completion state SUCCESS at 16:21:00. Greg Redell Great-West Life Annuity Insurance Co. Phone: 314-525-5877 Email: [EMAIL PROTECTED]
Re: expire inventory question
How long does expiration take? Is it finishing? If not, you are in big trouble. What is your reclamation threshold? A good rule of thumb is to simply set it to 50%, which is the default. Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] ( ) ASCII ribbon campaign X against HTML e-mail / \ On Tue, 23 Jul 2002, Rob Schroeder wrote: When I run inventory expiration, I can look in the activity log and see the process going through each of my file spaces. I see it hitting the TSM clients as well as the TDP for SQL clients, however I do not see the messages for the TDP for Oracle clients. I have used RMAN to expire and delete the backups that are older than 10 days, but are still not getting any tape storage back. My TSM server is Win2k Sp2 4.1.6 and my client is Win2k Sp2 TDP 2.2 TSM 4.2.1.20. I have double checked the settings for verdeleted and retonly and both are set to 0. Am I missing something here. Help Rob Schroeder Famous Footwear
Re: expire inventory question
Expiration is finishing successfully. I takes about an hour to run, the DB is 20 Gig at 50% util. The reclamation threshold is 50% already. What should be noted is that the files are not expiring. The volumes say full and the used percentage is 100%. Rob Schroeder Roger Deschner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent by: ADSM: cc: Dist StorSubject: Re: expire inventory question Manager [EMAIL PROTECTED] .EDU 07/24/2002 01:46 AM Please respond to ADSM: Dist Stor Manager How long does expiration take? Is it finishing? If not, you are in big trouble. What is your reclamation threshold? A good rule of thumb is to simply set it to 50%, which is the default. Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] ( ) ASCII ribbon campaign X against HTML e-mail / \ On Tue, 23 Jul 2002, Rob Schroeder wrote: When I run inventory expiration, I can look in the activity log and see the process going through each of my file spaces. I see it hitting the TSM clients as well as the TDP for SQL clients, however I do not see the messages for the TDP for Oracle clients. I have used RMAN to expire and delete the backups that are older than 10 days, but are still not getting any tape storage back. My TSM server is Win2k Sp2 4.1.6 and my client is Win2k Sp2 TDP 2.2 TSM 4.2.1.20. I have double checked the settings for verdeleted and retonly and both are set to 0. Am I missing something here. Help Rob Schroeder Famous Footwear
Re: expire inventory question
What about retv for t=a. I know that on TDP for SAP is it does everything as archives so it may actually be your archives that aren't going away. You do need to make sure that retv is greater then or equal to how long you keep them in TDP. Becky -Original Message- From: Rob Schroeder [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 23, 2002 10:55 AM To: [EMAIL PROTECTED] Subject: expire inventory question When I run inventory expiration, I can look in the activity log and see the process going through each of my file spaces. I see it hitting the TSM clients as well as the TDP for SQL clients, however I do not see the messages for the TDP for Oracle clients. I have used RMAN to expire and delete the backups that are older than 10 days, but are still not getting any tape storage back. My TSM server is Win2k Sp2 4.1.6 and my client is Win2k Sp2 TDP 2.2 TSM 4.2.1.20. I have double checked the settings for verdeleted and retonly and both are set to 0. Am I missing something here. Help Rob Schroeder Famous Footwear
expire inventory question
Hi All Everyday I run the following command line : expire inventory skipdir=no duration=300 and the result is : ANR0812I Inventory file expiration process 582 completed:examined 229248 objects, deleting 1004 backup objects, 756 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. I woul like to know exactly what does it means ? What the real difference between skpdir=yes and skpdir=no and what is the best choice ? Thanks in advanced !
Re: Expire inventory (or audit license) hangs migrations and back ups
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Jane Bamberger I had that problem with expiration - my mail server kept pinning the process - When it finally ran to completion it took 4-5 days, and expired 16M files. Which goes to show that you simply *must* run a complete expiration on a regular basis. If your current schedule doesn't allow it, you need to shove the start time for events until you *do* have a window. In my experience, a fair percentage of heavily-used/heavily-abused TSM servers that fail to run properly often do so because of incomplete expirations. -- Mark Stapleton ([EMAIL PROTECTED])
Expire inventory (or audit license) hangs migrations and backups
Hi there, Env: TSM server for MVS v4.2.0.0 with about 200 client nodes At last time I had noted TSM server hangs when expire inventory or audit license processes are running. Some client backup sessions and all processes (migrations including audit or expire itself) are freezed, otherwise administration is possible. After recycling TSM server all gone OK. My question: Is there some restrictions to simultaneous running of expire inventory (or audit license) and migrations (or client backups)? Is it posible that these two precesses can definitely hangs all other server work? The system that I mentioned is relatively high-loaded and there is hard to avoid collisions with backups. Any help will be appreciated. Sorry for my english :-) Tom
Re: Expire inventory (or audit license) hangs migrations and back ups
Hi Tom! I have seen this too a few days ago on my AIX server, running TSM 4.2.2.0. It looks like some kind of deadlock on a logpage. You will see that the expire inventory is just hanging and that one of your backup sessions is hanging too. You don't have to recycle the server though. As soon as you cancel the hanging client session, the expire inventory process continues. I haven't seen an APAR or fix for it, but since Tivoli implemented a the command SHOW LOGPINNED in 4.2.2.1 I think it's a known problem. Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: Tom Hrouda [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 16, 2002 12:14 To: [EMAIL PROTECTED] Subject: Expire inventory (or audit license) hangs migrations and backups Hi there, Env: TSM server for MVS v4.2.0.0 with about 200 client nodes At last time I had noted TSM server hangs when expire inventory or audit license processes are running. Some client backup sessions and all processes (migrations including audit or expire itself) are freezed, otherwise administration is possible. After recycling TSM server all gone OK. My question: Is there some restrictions to simultaneous running of expire inventory (or audit license) and migrations (or client backups)? Is it posible that these two precesses can definitely hangs all other server work? The system that I mentioned is relatively high-loaded and there is hard to avoid collisions with backups. Any help will be appreciated. Sorry for my english :-) Tom ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **
Re: Expire inventory (or audit license) hangs migrations and back ups
Another variation on the theme: On a 4.1.4.1 server here we see the 'log pinned' situation a LOT - very heavily abused server. One of the oddities is that once we clear the sessions, and do an incremental db backup, the log utilization doesn't drop until we issue an expire inventory command. Running an expire inventory drives log utilization up at an extremely high rate on this server, consequently expiration has not completed on this server in a very long time. I'm shutting down all other activity on the server over a 24 hour period this weekend to see if we can force a full expiration and hopefully that will alleviate the symptoms a bit. -Original Message- From: Loon, E.J. van - SPLXM [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 16, 2002 6:43 AM To: [EMAIL PROTECTED] Subject: Re: Expire inventory (or audit license) hangs migrations and back ups Hi Tom! I have seen this too a few days ago on my AIX server, running TSM 4.2.2.0. It looks like some kind of deadlock on a logpage. You will see that the expire inventory is just hanging and that one of your backup sessions is hanging too. You don't have to recycle the server though. As soon as you cancel the hanging client session, the expire inventory process continues. I haven't seen an APAR or fix for it, but since Tivoli implemented a the command SHOW LOGPINNED in 4.2.2.1 I think it's a known problem. Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: Tom Hrouda [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 16, 2002 12:14 To: [EMAIL PROTECTED] Subject: Expire inventory (or audit license) hangs migrations and backups Hi there, Env: TSM server for MVS v4.2.0.0 with about 200 client nodes At last time I had noted TSM server hangs when expire inventory or audit license processes are running. Some client backup sessions and all processes (migrations including audit or expire itself) are freezed, otherwise administration is possible. After recycling TSM server all gone OK. My question: Is there some restrictions to simultaneous running of expire inventory (or audit license) and migrations (or client backups)? Is it posible that these two precesses can definitely hangs all other server work? The system that I mentioned is relatively high-loaded and there is hard to avoid collisions with backups. Any help will be appreciated. Sorry for my english :-) Tom ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **
Re: Expire inventory (or audit license) hangs migrations and back ups
I had that problem with expiration - my mail server kept pinning the process - When it finally ran to completion it took 4-5 days, and expired 16M files. Good luck! Jane %% Jane Bamberger IS Department Bassett Healthcare 607-547-4750 - Original Message - From: Jolliff, Dale [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 16, 2002 8:11 AM Subject: Re: Expire inventory (or audit license) hangs migrations and back ups Another variation on the theme: On a 4.1.4.1 server here we see the 'log pinned' situation a LOT - very heavily abused server. One of the oddities is that once we clear the sessions, and do an incremental db backup, the log utilization doesn't drop until we issue an expire inventory command. Running an expire inventory drives log utilization up at an extremely high rate on this server, consequently expiration has not completed on this server in a very long time. I'm shutting down all other activity on the server over a 24 hour period this weekend to see if we can force a full expiration and hopefully that will alleviate the symptoms a bit. -Original Message- From: Loon, E.J. van - SPLXM [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 16, 2002 6:43 AM To: [EMAIL PROTECTED] Subject: Re: Expire inventory (or audit license) hangs migrations and back ups Hi Tom! I have seen this too a few days ago on my AIX server, running TSM 4.2.2.0. It looks like some kind of deadlock on a logpage. You will see that the expire inventory is just hanging and that one of your backup sessions is hanging too. You don't have to recycle the server though. As soon as you cancel the hanging client session, the expire inventory process continues. I haven't seen an APAR or fix for it, but since Tivoli implemented a the command SHOW LOGPINNED in 4.2.2.1 I think it's a known problem. Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: Tom Hrouda [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 16, 2002 12:14 To: [EMAIL PROTECTED] Subject: Expire inventory (or audit license) hangs migrations and backups Hi there, Env: TSM server for MVS v4.2.0.0 with about 200 client nodes At last time I had noted TSM server hangs when expire inventory or audit license processes are running. Some client backup sessions and all processes (migrations including audit or expire itself) are freezed, otherwise administration is possible. After recycling TSM server all gone OK. My question: Is there some restrictions to simultaneous running of expire inventory (or audit license) and migrations (or client backups)? Is it posible that these two precesses can definitely hangs all other server work? The system that I mentioned is relatively high-loaded and there is hard to avoid collisions with backups. Any help will be appreciated. Sorry for my english :-) Tom ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **
Re: Expire inventory (or audit license) hangs migrations and back ups
OK, now is question, how can I recognize hanging client session? (There is about 150 sessions at the time) I did q sess to file last time it happens, but all session were at Run state. In addition ... when I recognize it and cancel it, will the client reestablish session with server to end up backup? I see no good solution for this situation in automated manner (this is what I need), except of prevent it - this means write script to test if no client sessions are started at the time, disable clients, start expiration, and past it stops, enable clients. Any other idea? Tom -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Loon, E.J. van - SPLXM Sent: Thursday, May 16, 2002 1:43 PM To: [EMAIL PROTECTED] Subject: Re: Expire inventory (or audit license) hangs migrations and back ups Hi Tom! I have seen this too a few days ago on my AIX server, running TSM 4.2.2.0. It looks like some kind of deadlock on a logpage. You will see that the expire inventory is just hanging and that one of your backup sessions is hanging too. You don't have to recycle the server though. As soon as you cancel the hanging client session, the expire inventory process continues. I haven't seen an APAR or fix for it, but since Tivoli implemented a the command SHOW LOGPINNED in 4.2.2.1 I think it's a known problem. Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: Toma9 Hrouda [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 16, 2002 12:14 To: [EMAIL PROTECTED] Subject: Expire inventory (or audit license) hangs migrations and backups Hi there, Env: TSM server for MVS v4.2.0.0 with about 200 client nodes At last time I had noted TSM server hangs when expire inventory or audit license processes are running. Some client backup sessions and all processes (migrations including audit or expire itself) are freezed, otherwise administration is possible. After recycling TSM server all gone OK. My question: Is there some restrictions to simultaneous running of expire inventory (or audit license) and migrations (or client backups)? Is it posible that these two precesses can definitely hangs all other server work? The system that I mentioned is relatively high-loaded and there is hard to avoid collisions with backups. Any help will be appreciated. Sorry for my english :-) Tom ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **
Re: v4.2.2.2 - problems with expire inventory
Hi Everybody, I am very disappointed with 4.2.2 patch levels. I upgraded to 4.2.2.1 and saw the worst version I have ever seen. I think we all should stick to 4.2.2.0 for a time or upgrade 5.1.x.x Regards, Burak [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 15.05.2002 17:24 Please respond to ADSM-L To: [EMAIL PROTECTED] cc: Subject: v4.2.2.2 - problems with expire inventory On our well-behaved and moderately loaded system, I am not seeing a problem with anything in v4.2.2.2 (AIX 4.3.3). However, on the more 'abused' systems, ones that are constantly migrating and have users on them all the time, the expiration hangs whenever there is a migration, reclamation or move data going on. Simultaneous expiration and migration wasn't a problem on the well-behaved server. I am letting one run with a migration right now to see if it eventually resolves itself (deadlock?). Right now, it's going on 15 minutes and has locked up the other migration process. I'm not sure if backups to the disk pool are affected yet. At 30 minutes or so, I'll halt the server, restart and call the problen in. Gretchen Thiele Princeton University
v4.2.2.2 - problems with expire inventory
On our well-behaved and moderately loaded system, I am not seeing a problem with anything in v4.2.2.2 (AIX 4.3.3). However, on the more 'abused' systems, ones that are constantly migrating and have users on them all the time, the expiration hangs whenever there is a migration, reclamation or move data going on. Simultaneous expiration and migration wasn't a problem on the well-behaved server. I am letting one run with a migration right now to see if it eventually resolves itself (deadlock?). Right now, it's going on 15 minutes and has locked up the other migration process. I'm not sure if backups to the disk pool are affected yet. At 30 minutes or so, I'll halt the server, restart and call the problen in. Gretchen Thiele Princeton University
Re: TSM Expire Inventory
So how many objects are being expired? You do not say if there is a lot more expiration than normal happening. If Oracle TDP is anything like Lotus Notes TDP you may have huge numbers to be expired. So it could be just the amount of work and the power of your machine. Have you done query occupancy against the Oracle TDP filespaces Carl Lea [EMAIL PROTECTED] on 11/14/2001 02:32:31 AM Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: John Naylor/HAV/SSE) Subject: TSM Expire Inventory I have a TSM Inatall running on Windows 2000 SP2, ADSM- Version 4, Release 1, Level 3.0. Normally the Expire invetory process taked 1 -1.5 hours max the longest time is on a Monday after archives are expiring. Since the last weekend it is taking a really long time ..Like days...the Data base is 12 GB in size. The only thing I can think of that is different is last Friday some Oracle TDP backups were expired. Any Ideas ?? Thanks Carl - Transit New Zealand - A world leader in roading solutions. This electronic mail message together with any attachments is confidential. If you are not the intended recipient: - do not copy, disclose or use the contents in any way - please let us know by return e-mail immediately, then destroy this message Transit New Zealand is not responsible for any changes made to this message and/or any attachments after sending by Transit New Zealand. Thank you. ** The information in this E-Mail is confidential and may be legally privileged. It may not represent the views of Scottish and Southern Energy plc. It is intended solely for the addressees. Access to this E-Mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any unauthorised recipient should advise the sender immediately of the error in transmission. Scottish Hydro-Electric, Southern Electric, SWALEC and S+S are trading names of the Scottish and Southern Energy Group. **
TSM Expire Inventory
I have a TSM Inatall running on Windows 2000 SP2, ADSM- Version 4, Release 1, Level 3.0. Normally the Expire invetory process taked 1 -1.5 hours max the longest time is on a Monday after archives are expiring. Since the last weekend it is taking a really long time ..Like days...the Data base is 12 GB in size. The only thing I can think of that is different is last Friday some Oracle TDP backups were expired. Any Ideas ?? Thanks Carl - Transit New Zealand - A world leader in roading solutions. This electronic mail message together with any attachments is confidential. If you are not the intended recipient: - do not copy, disclose or use the contents in any way - please let us know by return e-mail immediately, then destroy this message Transit New Zealand is not responsible for any changes made to this message and/or any attachments after sending by Transit New Zealand. Thank you.
Re: Error in expire inventory
Extreme with ADSM!! by the way what is the version TSM u are using. Perform UNLOADDB = .DMP Perform LOADFORMAT all log volumes and dbvolumes (see the syntax in tsmadmin guide) Perform LOADDB from .DMP Perform AUDITDB after completion of LOADDB process. Then start TSM server. This will solve your problem. If not, u need to send ur DMP file to IBM lab or restore good old copy. This is my experience. Regards sreekumar. Robert Ouzen [EMAIL PROTECTED]@VM.MARIST.EDU on 09/30/2001 15:53:02 Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Error in expire inventory Hi I run a dsmserv auditdb fix=yes but still have error when running expire inventory as: Activity Log Date and Time Message -- 09/30/2001 08:20:14 ANR0104E imarins.c(1547): Error 2 deleting row from table Arch.Objs.ByDescription. 09/30/2001 08:20:14 ANRD imutil.c(3779): Primary row for archive object 0.33054338 not found. Any ideas what to do to get a clean database !! Regards Robert Ouzen E-Mail: [EMAIL PROTECTED]
