Re: TDP oracle to new domain policy - error deleting old backups from old domain
Hi, I believe what you said about the management classes is true. What rman errors are you getting? Did you change the nodename? Doing that upsets the combination of rman and tdp in finding backups. Regards Pete -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of Tae Kim Sent: 30 January 2006 17:27 To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TDP oracle to new domain policy - error deleting old backups from old domain Got a question for you all. Just move a tdp for oracle node to a different domain policy. this domain policy does not have management class of the same name that the node was using for the backup from its old domain policy. It is my understanding that once the node gets moved to a new domain, it would look for management class of the same name that it has bind its backups to and use that management class. If that management class does not exists, it would use the default management class. Is this true? Also we are having issues with deleting older DB from RMAN. what can cause these issues? Also the default management class of the new policy domain has different retention time. Would it help if I created the same management class with same backup copy group as the old one in the new policy domain? TIA, Tae Here is the env. TSM 5.2.4.4 on AIX 5.2 ML5 TDP for Oracle 5.2 on AIX 5.2 ML5 config of the node Platform: TDP Oracle AIX Client OS Level: 5.2 Client Version: Version 5, Release 2, Level 2.5 Policy Domain Name: FI_FIRST_DOM Last Access Date/Time: 01/30/06 12:15:13 Days Since Last Access: 1 Password Set Date/Time: 03/23/04 13:45:27 Days Since Password Set: 678 Invalid Sign-on Count: 0 Locked?: No Contact: Compression: Client Archive Delete Allowed?: Yes Backup Delete Allowed?: Yes Registration Date/Time: 03/22/04 11:56:24 Registering Administrator: Last Communication Method Used: Tcp/Ip Bytes Received Last Session: 4.50 M Bytes Sent Last Session: 17,599 Duration of Last Session: 0.67 Pct. Idle Wait Last Session: 18.32 Pct. Comm. Wait Last Session: 60.21 Pct. Media Wait Last Session: 0.00 Optionset: URL: Node Type: Client Password Expiration Period: 9,999 Day(s) Keep Mount Point?: No Maximum Mount Points Allowed: 2 Auto Filespace Rename : No Validate Protocol: No TCP/IP Name: TCP/IP Address: Globally Unique ID: Transaction Group Max: 0 Data Write Path: ANY Data Read Path: ANY Session Initiation: ClientOrServer High-level Address: Low-level Address: +=+ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. +=+
DB2 expire script for TSM
Hi all, I am looking for a script to expire my DB2 backups from TSM after 3 months. Does anyone have such a script? Regards, Jacques van den Berg Pick 'n Pay IT Email : [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Phone : 021-658 1694 Mobile : 082 - 653 8164 Dis altyd lente in die hart van die mens wat God en sy medemens liefhet (John Vianney). Read our disclaimer at: http://www.picknpay.co.za/pnp/view/pnp/en/page5093? If you don't have web access, the disclaimer can be mailed to you on request. Disclaimer requests to be sent to [EMAIL PROTECTED]
question on Tivoli reinstall agent
Troy thanks again for your response!
How to find out backupversions for datasets with special extensio n
Hi to all, has anybody a sql-query for datasets with extension for example JPG or MP3. Output ideally with filesize?! thanks
migration doesn't seem to be ending
Hello all, After viewing our Backup Disk Pool, I noticed that migration doesn't seem to be stopping. The below percentages don't seem right since I have the following settings. Anyone else see this as odd or am I missing something? If so what could be causing this? Thanks for any suggestions, help! update stgpool backuppool highmig=0 lowmig=0 update stgpool backuppool highmig=70 lowmig=40 Disk storage pools : BACKUPPOOL Storage Pool Name BACKUPPOOL Storage Pool Type PRIMARY Device Class Name DISK Estimated Capacity 1013760.0 Space Trigger Util 17.6 Pct Util 17.6 Pct Migr 16.3 Pct Logical 100.0 High Mig Pct 70 Low Mig Pct 40 Migration Processes 14 Next Storage Pool H3592POOL Maximum Size Threshold - Access READWRITE Description Disk Backup Pool Overflow Location - Cache Migrated Files? NO Collocate? - Reclamation Threshold - Maximum Scratch Volumes Allowed - Number of Scratch Volumes Used - Delay Period for Volume Reuse - Migration in Progress? NO Amount Migrated (MB) - Elapsed Migration Time (seconds) 632871 Reclamation in Progress? - Last Update Date/Time 2006-01-31 11:00:14.00 Last Update by (administrator) Reclaim Storage Pool - Migration Delay 0 Migration Continue YES Storage Pool Data Format Native Copy Storage Pool(s) - Continue Copy on Error? - CRC Data YES Reclamation Processes - Offsite Reclamation Limit - Reclamation Type THRESHOLD TSM 5.3.2.1 AIX 5.3 RS/6000
AW: [ADSM-L] migration doesn't seem to be ending
Hi, See http://people.bu.edu/rbs/ADSM.funcdir, keyword: MIGRATION Occurs with one process per node (regardless of the MIGPRocess value), choosing the node with the largest amount of data in the storage pool and moving *all* of that node's data before embarking upon the same processing for other nodes - or before again checking the LOwmig value. When you change the LOWMIG value TSM waits till it has moved *all* files of the node it is currently working on. So this might take some time if you have nodes with many, many files. HTH Thomas Rupp -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im Auftrag von Timothy Hughes Gesendet: Mittwoch, 01. Februar 2006 15:34 An: ADSM-L@VM.MARIST.EDU Betreff: [ADSM-L] migration doesn't seem to be ending Hello all, After viewing our Backup Disk Pool, I noticed that migration doesn't seem to be stopping. The below percentages don't seem right since I have the following settings. Anyone else see this as odd or am I missing something? If so what could be causing this? Thanks for any suggestions, help! update stgpool backuppool highmig=0 lowmig=0 update stgpool backuppool highmig=70 lowmig=40 Disk storage pools : BACKUPPOOL Storage Pool Name BACKUPPOOL Storage Pool Type PRIMARY Device Class Name DISK Estimated Capacity 1013760.0 Space Trigger Util 17.6 Pct Util 17.6 Pct Migr 16.3 Pct Logical 100.0 High Mig Pct 70 Low Mig Pct 40 Migration Processes 14 Next Storage Pool H3592POOL Maximum Size Threshold - Access READWRITE Description Disk Backup Pool Overflow Location - Cache Migrated Files? NO Collocate? - Reclamation Threshold - Maximum Scratch Volumes Allowed - Number of Scratch Volumes Used - Delay Period for Volume Reuse - Migration in Progress? NO Amount Migrated (MB) - Elapsed Migration Time (seconds) 632871 Reclamation in Progress? - Last Update Date/Time 2006-01-31 11:00:14.00 Last Update by (administrator) Reclaim Storage Pool - Migration Delay 0 Migration Continue YES Storage Pool Data Format Native Copy Storage Pool(s) - Continue Copy on Error? - CRC Data YES Reclamation Processes - Offsite Reclamation Limit - Reclamation Type THRESHOLD TSM 5.3.2.1 AIX 5.3 RS/6000
Backup Error
We've just upgraded to TSM client 5.3 on windows.and I'm now seeing the error below on the systemstate, systemservices... I understand that vss is used to do the system state backup.but does anyone know why this error shows up?? 02/01/2006 03:00:29 --- SCHEDULEREC OBJECT BEGIN DEV03BKUP 02/01/2006 03:00:00 02/01/2006 03:00:30 Incremental backup of volume '\\lm-server-03\c$' 02/01/2006 03:00:30 Incremental backup of volume '\\lm-server-03\d$' 02/01/2006 03:00:30 Incremental backup of volume '\\lm-server-03\e$' 02/01/2006 03:00:30 Incremental backup of volume 'SYSTEMSTATE' 02/01/2006 03:00:39 ANS1959W Removing previous incomplete group '\SYSSTATE' Id:0-681213062 02/01/2006 03:00:41 Incremental backup of volume 'SYSTEMSERVICES' 02/01/2006 03:00:45 ANS1959W Removing previous incomplete group '\WMI' Id:0-681213066 02/01/2006 03:00:45 ANS1959W Removing previous incomplete group '\EVENTLOG' Id:0-681213067 02/01/2006 03:00:46 ANS1959W Removing previous incomplete group '\IIS' Id:0-681213068 02/01/2006 03:02:39 Successful incremental backup of '\\lm-server-03\e$' 02/01/2006 03:26:31 Successful incremental backup of '\\lm-server-03\c$'
Re: AW: [ADSM-L] migration doesn't seem to be ending
Also, backups running during the migration time can prevent the pool from reaching 0. We use 1 to get around that problem. Andy Huebner -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Rupp Sent: Wednesday, February 01, 2006 8:41 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] AW: [ADSM-L] migration doesn't seem to be ending Hi, See http://people.bu.edu/rbs/ADSM.funcdir, keyword: MIGRATION Occurs with one process per node (regardless of the MIGPRocess value), choosing the node with the largest amount of data in the storage pool and moving *all* of that node's data before embarking upon the same processing for other nodes - or before again checking the LOwmig value. When you change the LOWMIG value TSM waits till it has moved *all* files of the node it is currently working on. So this might take some time if you have nodes with many, many files. HTH Thomas Rupp -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im Auftrag von Timothy Hughes Gesendet: Mittwoch, 01. Februar 2006 15:34 An: ADSM-L@VM.MARIST.EDU Betreff: [ADSM-L] migration doesn't seem to be ending Hello all, After viewing our Backup Disk Pool, I noticed that migration doesn't seem to be stopping. The below percentages don't seem right since I have the following settings. Anyone else see this as odd or am I missing something? If so what could be causing this? Thanks for any suggestions, help! update stgpool backuppool highmig=0 lowmig=0 update stgpool backuppool highmig=70 lowmig=40 Disk storage pools : BACKUPPOOL Storage Pool Name BACKUPPOOL Storage Pool Type PRIMARY Device Class Name DISK Estimated Capacity 1013760.0 Space Trigger Util 17.6 Pct Util 17.6 Pct Migr 16.3 Pct Logical 100.0 High Mig Pct 70 Low Mig Pct 40 Migration Processes 14 Next Storage Pool H3592POOL Maximum Size Threshold - Access READWRITE Description Disk Backup Pool Overflow Location - Cache Migrated Files? NO Collocate? - Reclamation Threshold - Maximum Scratch Volumes Allowed - Number of Scratch Volumes Used - Delay Period for Volume Reuse - Migration in Progress? NO Amount Migrated (MB) - Elapsed Migration Time (seconds) 632871 Reclamation in Progress? - Last Update Date/Time 2006-01-31 11:00:14.00 Last Update by (administrator) Reclaim Storage Pool - Migration Delay 0 Migration Continue YES Storage Pool Data Format Native Copy Storage Pool(s) - Continue Copy on Error? - CRC Data YES Reclamation Processes - Offsite Reclamation Limit - Reclamation Type THRESHOLD TSM 5.3.2.1 AIX 5.3 RS/6000 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: AW: [ADSM-L] migration doesn't seem to be ending
Thanks Thomas and Andy! Andy Huebner wrote: Also, backups running during the migration time can prevent the pool from reaching 0. We use 1 to get around that problem. Andy Huebner -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Rupp Sent: Wednesday, February 01, 2006 8:41 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] AW: [ADSM-L] migration doesn't seem to be ending Hi, See http://people.bu.edu/rbs/ADSM.funcdir, keyword: MIGRATION Occurs with one process per node (regardless of the MIGPRocess value), choosing the node with the largest amount of data in the storage pool and moving *all* of that node's data before embarking upon the same processing for other nodes - or before again checking the LOwmig value. When you change the LOWMIG value TSM waits till it has moved *all* files of the node it is currently working on. So this might take some time if you have nodes with many, many files. HTH Thomas Rupp -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im Auftrag von Timothy Hughes Gesendet: Mittwoch, 01. Februar 2006 15:34 An: ADSM-L@VM.MARIST.EDU Betreff: [ADSM-L] migration doesn't seem to be ending Hello all, After viewing our Backup Disk Pool, I noticed that migration doesn't seem to be stopping. The below percentages don't seem right since I have the following settings. Anyone else see this as odd or am I missing something? If so what could be causing this? Thanks for any suggestions, help! update stgpool backuppool highmig=0 lowmig=0 update stgpool backuppool highmig=70 lowmig=40 Disk storage pools : BACKUPPOOL Storage Pool Name BACKUPPOOL Storage Pool Type PRIMARY Device Class Name DISK Estimated Capacity 1013760.0 Space Trigger Util 17.6 Pct Util 17.6 Pct Migr 16.3 Pct Logical 100.0 High Mig Pct 70 Low Mig Pct 40 Migration Processes 14 Next Storage Pool H3592POOL Maximum Size Threshold - Access READWRITE Description Disk Backup Pool Overflow Location - Cache Migrated Files? NO Collocate? - Reclamation Threshold - Maximum Scratch Volumes Allowed - Number of Scratch Volumes Used - Delay Period for Volume Reuse - Migration in Progress? NO Amount Migrated (MB) - Elapsed Migration Time (seconds) 632871 Reclamation in Progress? - Last Update Date/Time 2006-01-31 11:00:14.00 Last Update by (administrator) Reclaim Storage Pool - Migration Delay 0 Migration Continue YES Storage Pool Data Format Native Copy Storage Pool(s) - Continue Copy on Error? - CRC Data YES Reclamation Processes - Offsite Reclamation Limit - Reclamation Type THRESHOLD TSM 5.3.2.1 AIX 5.3 RS/6000 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: AW: [ADSM-L] migration doesn't seem to be ending
TSM 5.3.2.1 server. Why don't you use the new migrate stg backuppool low=40 dur=XX option instead of the upd stg? Regards, Karel -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Hughes Sent: woensdag 1 februari 2006 19:06 To: ADSM-L@VM.MARIST.EDU Subject: Re: AW: [ADSM-L] migration doesn't seem to be ending Thanks Thomas and Andy! Andy Huebner wrote: Also, backups running during the migration time can prevent the pool from reaching 0. We use 1 to get around that problem. Andy Huebner -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Rupp Sent: Wednesday, February 01, 2006 8:41 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] AW: [ADSM-L] migration doesn't seem to be ending Hi, See http://people.bu.edu/rbs/ADSM.funcdir, keyword: MIGRATION Occurs with one process per node (regardless of the MIGPRocess value), choosing the node with the largest amount of data in the storage pool and moving *all* of that node's data before embarking upon the same processing for other nodes - or before again checking the LOwmig value. When you change the LOWMIG value TSM waits till it has moved *all* files of the node it is currently working on. So this might take some time if you have nodes with many, many files. HTH Thomas Rupp -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im Auftrag von Timothy Hughes Gesendet: Mittwoch, 01. Februar 2006 15:34 An: ADSM-L@VM.MARIST.EDU Betreff: [ADSM-L] migration doesn't seem to be ending Hello all, After viewing our Backup Disk Pool, I noticed that migration doesn't seem to be stopping. The below percentages don't seem right since I have the following settings. Anyone else see this as odd or am I missing something? If so what could be causing this? Thanks for any suggestions, help! update stgpool backuppool highmig=0 lowmig=0 update stgpool backuppool highmig=70 lowmig=40 Disk storage pools : BACKUPPOOL Storage Pool Name BACKUPPOOL Storage Pool Type PRIMARY Device Class Name DISK Estimated Capacity 1013760.0 Space Trigger Util 17.6 Pct Util 17.6 Pct Migr 16.3 Pct Logical 100.0 High Mig Pct 70 Low Mig Pct 40 Migration Processes 14 Next Storage Pool H3592POOL Maximum Size Threshold - Access READWRITE Description Disk Backup Pool Overflow Location - Cache Migrated Files? NO Collocate? - Reclamation Threshold - Maximum Scratch Volumes Allowed - Number of Scratch Volumes Used - Delay Period for Volume Reuse - Migration in Progress? NO Amount Migrated (MB) - Elapsed Migration Time (seconds) 632871 Reclamation in Progress? - Last Update Date/Time 2006-01-31 11:00:14.00 Last Update by (administrator) Reclaim Storage Pool - Migration Delay 0 Migration Continue YES Storage Pool Data Format Native Copy Storage Pool(s) - Continue Copy on Error? - CRC Data YES Reclamation Processes - Offsite Reclamation Limit - Reclamation Type THRESHOLD TSM 5.3.2.1 AIX 5.3 RS/6000 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. Dit bericht is vertrouwelijk en kan geheime informatie bevatten enkel bestemd voor de geadresseerde. Indien dit bericht niet voor u is bestemd, verzoeken wij u dit onmiddellijk aan ons te melden en het bericht te vernietigen. Aangezien de integriteit van het bericht niet veilig gesteld is middels verzending via internet, kan Atos Origin niet aansprakelijk worden gehouden voor de inhoud daarvan. Hoewel wij ons inspannen een virusvrij netwerk te hanteren, geven wij geen enkele garantie dat dit bericht virusvrij is, noch aanvaarden wij enige aansprakelijkheid voor de mogelijke aanwezigheid van een virus in dit bericht. Op al onze rechtsverhoudingen, aanbiedingen en overeenkomsten waaronder Atos Origin goederen en/of diensten levert zijn met uitsluiting van alle andere voorwaarden de Leveringsvoorwaarden van Atos Origin van toepassing. Deze worden u op aanvraag direct kosteloos toegezonden. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its
schedlogretention.
TSM client 5.3.1.1 OS linux RH 3.0 TSM server 5.3.1.2 On all three of my archive only Linux servers the schedlogretention and errorlogretention parameters in the dsm.sys are not being used. The contents in the logs date back to 10-12-05. The dsm.sys has not been changed since 9-12-2005. An archive process is scheduled to run every 12 hours. errorlogretention 7 d schedlogretention 7 d errorlogname /another_directory/dsmerror.log schedlogname /another_directory/dsmsched.log Has anybody seen this before ? Duane Ochs Information Systems - Enterprise Computing Quad/Graphics Inc. Sussex, Wisconsin 414-566-2375 phone 414-566-4010 pin# 2375 beeper [EMAIL PROTECTED] www.QG.com outbind://8/www.QG.com
Re: schedlogretention.
Have your restarted the scheduler? The scheduler only reads the dsm.sys file on startup. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Mark Stapleton Sent: Wednesday, February 01, 2006 12:49 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: schedlogretention. ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 02/01/2006 01:44:00 PM: TSM client 5.3.1.1 OS linux RH 3.0 TSM server 5.3.1.2 On all three of my archive only Linux servers the schedlogretention and errorlogretention parameters in the dsm.sys are not being used. The contents in the logs date back to 10-12-05. The dsm.sys has not been changed since 9-12-2005. An archive process is scheduled to run every 12 hours. errorlogretention 7 d schedlogretention 7 d errorlogname /another_directory/dsmerror.log schedlogname /another_directory/dsmsched.log Has anybody seen this before ? Curiousity: have you tried adding it to the relevant client option set on the server? I for one would be interested as to whether that did the job better. Another curiousity: does log retention work on archives only? I always see the trimming going on at the end of a scheduled backup. You might try a single scheduled backup on one box to see if that trims the logs. -- Mark Stapleton ([EMAIL PROTECTED]) MR Backup and Recovery Management 262.790.3190 -- Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. ==
Re: schedlogretention.
ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 02/01/2006 01:44:00 PM: TSM client 5.3.1.1 OS linux RH 3.0 TSM server 5.3.1.2 On all three of my archive only Linux servers the schedlogretention and errorlogretention parameters in the dsm.sys are not being used. The contents in the logs date back to 10-12-05. The dsm.sys has not been changed since 9-12-2005. An archive process is scheduled to run every 12 hours. errorlogretention 7 d schedlogretention 7 d errorlogname /another_directory/dsmerror.log schedlogname /another_directory/dsmsched.log Has anybody seen this before ? Curiousity: have you tried adding it to the relevant client option set on the server? I for one would be interested as to whether that did the job better. Another curiousity: does log retention work on archives only? I always see the trimming going on at the end of a scheduled backup. You might try a single scheduled backup on one box to see if that trims the logs. -- Mark Stapleton ([EMAIL PROTECTED]) MR Backup and Recovery Management 262.790.3190 -- Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. ==
