Re: VM backup question

Robert, you might use the -vm parameter to exclude certain VMs in your DSM.OPT file. DOMAIN.VMFULL VMHOSTCLUSTER=CLUSTER_NAME;-VM=VM_TO_EXCLUDE1,VM_TO_EXCLUDE2 Also, in your DSM.OPT file you can add INCLUDE.VMDISK options to specifically target VM disks you want (which excludes the other disks y

SQL statement

Hi guys! I'm trying to join the filespaces and occupancy tables in one SQL statement, but I get stuck on the point where I want to calculate with the amount of days... I would like to create a list of filespaces (node_name, filespace_name,backup_end) which are not backed up for more than 30 days

Re: SQL statement

Hi EJ, I think this will do the trick: SELECT - f.node_name, - f.filespace_name, - f.backup_end, - CAST(ROUND(o.physical_mb/1024) as int) as "GB Stored" - FROM - filespaces f, - occupancy o - WHERE - o.node_name=f.node_name - AND o.filespace_name=f.filespace_name - AND

Re: SQL statement

Eric, One other line you can add to the select section is: DAYS(current_timestamp)-DAYS(f.BACKUP_END) AS DAYS_SINCE_BACKUP - Which will list the number of days since this filespace completed a backup. I use that in our query to list old filespaces due for cleanup. Bill On 1/28/2016 9:58 AM, Sk

Re: SQL statement

Hi Skylar! This is exactly what I was looking for. Thank you very much for your help!!! Kind regards, Eric van Loon AF/KLM Storage Engineering -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Skylar Thompson Sent: donderdag 28 januari 2016 15:59

Re: SQL statement

Hi Bill! Nice! Thank you very much for your valuable suggestion! Kind regards, Eric van Loon AF/KLM Storage Engineering -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of William Sefranek Sent: donderdag 28 januari 2016 16:11 To: ADSM-L@VM.MARIST.

Re: SQL statement

Hi Eric, You maybe should add a condition if backup_end is null -- Best regards / Cordialement / مع تحياتي Erwann SIMON - Mail original - De: "EJ van Loon (ITOPT3) - KLM" À: ADSM-L@VM.MARIST.EDU Envoyé: Jeudi 28 Janvier 2016 16:20:57 Objet: Re: [ADSM-L] SQL statement Hi Skylar! This i

Re: Upgrade server from 6.3 to 7.1

So, if I read correctly, to reduce my activelogsize, I 1. Backup the DB 2. Stop the TSM server 3. DELETE everything in the activelog directory/filesystem (in my case - /tsmlog) i.e. rm /tsmlog/* 4. Change ACTIVELOGSIZE to 65536 5. Restart the TSM server Or is it simpler than that, i.e. just

Re: SQL statement

Bill where are you putting the “DAYS” part of the query? I’m a bit confused and can’t reproduce your statement. -- Hal On 1/28/16, 10:11 AM, "ADSM: Dist Stor Manager on behalf of William Sefranek" wrote: >Eric, > >One other line you can add to the select section is: >DAYS(current_timest

Re: SQL statement

Good call, a filter like this would do the trick: (days(f.backup_end)<(days(current_date)-30) OR f.backup_end IS NULL) On Thu, Jan 28, 2016 at 04:46:17PM +0100, Erwann SIMON wrote: > Hi Eric, > > You maybe should add a condition if backup_end is null > > -- > Best regards / Cordialement / ??

Re: SQL statement

It would actually be in the table expression at the top: SELECT ... DAYS(current_timestamp)-DAYS(f.BACKUP_END) AS DAYS_SINCE_BACKUP, - FROM - ... On Thu, Jan 28, 2016 at 03:46:43PM +, King, Harold Clyde (Hal) wrote: > Bill where are you putting the ???DAYS??? part of the query? I???m a bit

Re: SQL statement

Hi Erwann! Yes, that's a good tip too. This field is sometimes empty. Thanks! Kind regards, Eric van Loon AF/KLM Storage Engineering -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Erwann SIMON Sent: donderdag 28 januari 2016 16:46 To: ADSM-L@VM

Re: When can too many disk volumes be detrimental

This is long, but I hope it helps without being too specific. From you description I think you have violated my disk usage rules. Tape drives are very fast, disk drives (SSD too) are very slow (sequential access), that is why we gang disks together (RAID) to keep up. If you have a very large R

Re: SQL statement

Hi,I'm looking for some help on SQL statement as well. Would you have a statement that lists just the amount of active data a node has stored - not the active and inactive... Thank youMichael On Thursday, January 28, 2016 10:08 AM, William Sefranek wrote: Eric, One other line you can

Re: Upgrade server from 6.3 to 7.1

Shouldn't have to delete anything. Backing up the db should do it if memory serves. Been too long since I did it, and can't find my notes. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Zoltan Forray Sent: Thursday, January 28, 2016 10:52 AM

Re: SQL statement

You could do that but the query does not fail for filespaces with a BACKUP_END of null it just lists a blank value for DAYS_SINCE_BACKUP On 1/28/2016 10:46 AM, Erwann SIMON wrote: Hi Eric, You maybe should add a condition if backup_end is null -- William Sefranek University of Buffalo Enterp

Re: When can too many disk volumes be detrimental

Andy, Thanks for the information. It sounds like you are sort-of agreeing that having too many TSM disk volumes is a factor in my slowness (i.e. 30-1TB volumes is bad since I have them all in one array so reducing to fewer, larger TSM volumes per array could help.) I agree SSD would help but we

Re: When can too many disk volumes be detrimental

On Wed, Jan 27, 2016 at 10:05 AM, Ryder, Michael S < michael_s.ry...@roche.com> wrote: > Did you follow the docs and disable RHEL's read-ahead > caching? If so, you may want to consider enabling it. > Mike, Can you expand on your statement about RHEL read-ahead cache and some tuning/config docu

Re: Upgrade server from 6.3 to 7.1

I don't think it does. I just checked and I have log files with timestamps going back to January 12 (the day we restored the server) and I do full DB backups daily. On Thu, Jan 28, 2016 at 11:14 AM, Lee, Gary wrote: > Shouldn't have to delete anything. Backing up the db should do it if > memor

Re: Eucalyptus backups: Any suggestions?

On Wed, Jan 27, 2016 at 10:45:58PM +, Taylor, Marc D wrote: > We have been tasked to protect (i.e. backup) a local Eucalyptus installation. > Anyone on the list doing anything similar with TSM? Backing up Eucalyptus > doesn't seem to be a straightforward thing to do. Well, what are you try

Re: When can too many disk volumes be detrimental

Hi Zoltan Here is the reference... I know it is for TSM 7.1, but the reference is specific to RHEL and it's filesystems, which is still relevant to the discussion, I think: http://www-01.ibm.com/support/knowledgecenter/SSGSG7_7.1.0/com.ibm.itsm.perf.doc/t_perf_diskos_lnx.html Best regards, Mike

Re: When can too many disk volumes be detrimental

Mike, Thanks, again. Very helpful. So, did I understand your earlier statement/comment that you disagree with "*Set the LVM read-ahead to 0 for all logical volumes on disk systems that provide adaptive read-ahead capabilities, for example, enterprise-type disk systems.*" I also read the stateme

Re: [Non-DoD Source] Re: [ADSM-L] Upgrade server from 6.3 to 7.1

When you reduce the size of the active log, you have to restart the TSM server twice. The first restart just changes the DB2 parameters. The second restart removes the log files that are no longer required. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU]

Re: [Non-DoD Source] Re: [ADSM-L] Upgrade server from 6.3 to 7.1

Great. So just reduce the actlogsize value and restart the server twice. I have a server whose DB backups constantly fail with the -2428 error since I set actlogsize to 120GB and the filesystem only has 126GB total space. On Thu, Jan 28, 2016 at 2:50 PM, Reese, Michael A (Mike) CIV USARMY 93 SIG

Re: [Non-DoD Source] Re: [ADSM-L] Upgrade server from 6.3 to 7.1

Hi Zoltan, I don't think that restarting the server twice after having modified the activelogsize is still necessary as it was the case in early TSM v6 versions. You'll tell us. Be prepared to have a DB backup to automatically start (to the default DBRECOVERY device class). -- Best regards /