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 you do not specifically include). INCLUDE.VMDISK EXACT VM NAME GOES HERE "Hard Disk 1" Disk(s) not specifically included restore blank at their full size during a full VM restore. I forget if a way exists to prevent the other disks from restoring in a full restore. If you see issues with VM backups or restores, you might also consider adding testflag VMBACKUP_UPDATE_UUID to your DSM.OPT file to force the backup to save the UUID every time you perform a VM backup. Good luck! Ray Storer NIBCO INC. 574.295.3457 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Robert Ouzen Sent: Wednesday, January 27, 2016 11:31 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] VM backup question Hi to all I have a VMware farm with around 300 VM machines and I try to figure the best way to configure the backup with TSM for VE V7.1.4 . 1. Need to backup for all the machines the "Hard disk 1" 2. Our structure don't let us to do it with VMfolder , think about domain.vmfull vmdatastore= data1.,data2, etc 3. Need for some VM machines to backup all disks or at least more than "Hard disk 1" , and some machines not to back up at all Any help will be appreciated Best Regards Robert CONFIDENTIALITY NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient. If you are not the intended recipient, please do not read, distribute or take action in reliance upon this message. If you have received this in error, please notify us immediately by return email and promptly delete this message and its attachments from your computer system. We do not waive attorney-client or work product privilege by the transmission of this message.
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, along with the amount of data stored for them in GB (cast(round(physical_mb/1024) as int) as "GB Stored"), sorted on size, the largest first. Can anybody help me out here? Thank you very much for your help in advance! Kind regards, Eric van Loon AF/KLM Storage Engineering 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
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 days(f.backup_end)<(days(current_date)-30) - ORDER BY o.physical_mb DESC On Thu, Jan 28, 2016 at 02:43:54PM +, Loon, EJ van (ITOPT3) - KLM wrote: > 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, > along with the amount of data stored for them in GB > (cast(round(physical_mb/1024) as int) as "GB Stored"), sorted on size, the > largest first. > Can anybody help me out here? Thank you very much for your help in advance! > Kind regards, > Eric van Loon > AF/KLM Storage Engineering > > 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. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch > Airlines) is registered in Amstelveen, The Netherlands, with registered > number 33014286 > -- -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine
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, Skylar Thompson wrote: 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 days(f.backup_end)<(days(current_date)-30) - ORDER BY o.physical_mb DESC On Thu, Jan 28, 2016 at 02:43:54PM +, Loon, EJ van (ITOPT3) - KLM wrote: 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, along with the amount of data stored for them in GB (cast(round(physical_mb/1024) as int) as "GB Stored"), sorted on size, the largest first. Can anybody help me out here? Thank you very much for your help in advance! Kind regards, Eric van Loon AF/KLM Storage Engineering 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine -- William Sefranek University of Buffalo Enterprise Infrastructure Services (716)645-5116
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 To: ADSM-L@VM.MARIST.EDU Subject: 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 days(f.backup_end)<(days(current_date)-30) - ORDER BY o.physical_mb DESC On Thu, Jan 28, 2016 at 02:43:54PM +, Loon, EJ van (ITOPT3) - KLM wrote: > 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, > along with the amount of data stored for them in GB > (cast(round(physical_mb/1024) as int) as "GB Stored"), sorted on size, the > largest first. > Can anybody help me out here? Thank you very much for your help in advance! > Kind regards, > Eric van Loon > AF/KLM Storage Engineering > > 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. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > -- -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
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.EDU Subject: 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, Skylar Thompson wrote: > 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 days(f.backup_end)<(days(current_date)-30) - ORDER BY > o.physical_mb DESC > > On Thu, Jan 28, 2016 at 02:43:54PM +, Loon, EJ van (ITOPT3) - KLM wrote: >> 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, >> along with the amount of data stored for them in GB >> (cast(round(physical_mb/1024) as int) as "GB Stored"), sorted on size, the >> largest first. >> Can anybody help me out here? Thank you very much for your help in advance! >> Kind regards, >> Eric van Loon >> AF/KLM Storage Engineering >> >> 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. >> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal >> Dutch Airlines) is registered in Amstelveen, The Netherlands, with >> registered number 33014286 >> > -- > -- Skylar Thompson (skyl...@u.washington.edu) > -- Genome Sciences Department, System Administrator > -- Foege Building S046, (206)-685-7354 > -- University of Washington School of Medicine > > -- William Sefranek University of Buffalo Enterprise Infrastructure Services (716)645-5116 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
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 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 To: ADSM-L@VM.MARIST.EDU Subject: 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 days(f.backup_end)<(days(current_date)-30) - ORDER BY o.physical_mb DESC On Thu, Jan 28, 2016 at 02:43:54PM +, Loon, EJ van (ITOPT3) - KLM wrote: > 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, > along with the amount of data stored for them in GB > (cast(round(physical_mb/1024) as int) as "GB Stored"), sorted on size, the > largest first. > Can anybody help me out here? Thank you very much for your help in advance! > Kind regards, > Eric van Loon > AF/KLM Storage Engineering > > 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. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > -- -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
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 change ACTIVELOGSIZE and restart the server. Unless I missed it, the link/article posted by Erwann ( http://www-01.ibm.com/support/docview.wss?uid=swg21677011) doesn't clarify. It just says "*Decrease the ACTIVELOGSIZE to allow the current filesystem to be 20% greater than the ACTIVELOGSIZE specified*" but no link says exactly how to do it. On Wed, Jan 27, 2016 at 2:26 PM, Nixon, Charles D. (David) < cdni...@carilionclinic.org> wrote: > This is what we had to do too (shrink logs to 50% before upgrade and then > grow after the procedure). It tried to double logs and then I believe that > it forgot about the mirrored location because we were out of space. > > > --- > David Nixon > System Programmer II > Technology Services Group > Carilion Clinic > 451 Kimball Ave. > Roanoke, VA 24015 > Phone: 540-224-3903 > cdni...@carilionclinic.org > > Our mission: Improve the health of the communities we serve. > > > > > From: ADSM: Dist Stor Manager [ADSM-L@VM.MARIST.EDU] on behalf of Lee, > Gary [g...@bsu.edu] > Sent: Monday, January 25, 2016 12:50 PM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] Upgrade server from 6.3 to 7.1 > > I never saw it in the docs. > > What I had to do was disable the server, do a full backup on the db, then > once I had verified the logs were empty, reduced log size to less than half > file system space. > Then do the upgrade, and enlarge logs as necessary after upgrade is > verified working. > > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Rainer Tammer > Sent: Monday, January 25, 2016 11:16 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] Upgrade server from 6.3 to 7.1 > > Hello, > Is this mentioned in the docs? > > That would be a bit difficult in our setup: > > Filesystem GB blocks Free %Used Iused %Iused Mounted on > /dev/lvtsmactlog 130.00 1.98 99%262 1% > /tsminst1/tsmactlog <- active log > /dev/lvtsmarchlog 197.00 193.37 2% 251% > /tsminst1/tsmarchlog <- archive log > > > Bye > Rainer > > On 25.01.2016 16:51, Lee, Gary wrote: > > Yes. > > > > Make sure that you have at least double the size of your active and > archive logs as available free space in the respective log directories. > > i.e. . if your active log size is 32 gB, insure that your log directory > has more than 64 gB free. Otherwise the database upgrade will fail on > install. > > > > Other than that, it went well, going from 6.3.4 to 7.1.3. > > > > > > > > -Original Message- > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf > Of molin gregory > > Sent: Monday, January 25, 2016 10:30 AM > > To: ADSM-L@VM.MARIST.EDU > > Subject: [ADSM-L] Upgrade server from 6.3 to 7.1 > > > > Hello everyone > > > > I plan to upgrade my server from version 6.3 to version 7.1. > > Have you had problems with this procedure? > > > > Thank you beforehand > > Grégory > > "ATTENTION. > > > > Ce message et les pièces jointes sont confidentiels et établis à > l'attention exclusive de leur destinataire (aux adresses spécifiques > auxquelles il a été adressé). Si vous n'êtes pas le destinataire de ce > message, vous devez immédiatement en avertir l'expéditeur et supprimer ce > message et les pièces jointes de votre système. > > > > This message and any attachments are confidential and intended to be > received only by the addressee. If you are not the intended recipient, > please notify immediately the sender by reply and delete the message and > any attachments from your system. " > > > > > > > > Notice: The information and attachment(s) contained in this communication > are intended for the addressee only, and may be confidential and/or legally > privileged. If you have received this communication in error, please > contact the sender immediately, and delete this communication from any > computer or network system. Any interception, review, printing, copying, > re-transmission, dissemination, or other use of, or taking of any action > upon this information by persons or entities other than the intended > recipient is strictly prohibited by law and may subject them to criminal or > civil liability. Carilion Clinic shall not be liable for the improper > and/or incomplete transmission of the information contained in this > communication or for any delay in its receipt. > -- *Zoltan Forray* TSM Software & Hardware Administrator Xymon Monitor Administrator Virginia Commonwealth University UCC/Office of Technology Services www.ucc.vcu.edu zfor...@vcu.edu - 804-828-4807 Don't be a phishi
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_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, Skylar Thompson wrote: >> 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 days(f.backup_end)<(days(current_date)-30) - >> ORDER BY o.physical_mb DESC >> >> On Thu, Jan 28, 2016 at 02:43:54PM +, Loon, EJ van (ITOPT3) - KLM wrote: >>> 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, >>> along with the amount of data stored for them in GB >>> (cast(round(physical_mb/1024) as int) as "GB Stored"), sorted on size, the >>> largest first. >>> Can anybody help me out here? Thank you very much for your help in advance! >>> Kind regards, >>> Eric van Loon >>> AF/KLM Storage Engineering >>> >>> 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. >>> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch >>> Airlines) is registered in Amstelveen, The Netherlands, with registered >>> number 33014286 >>> >> -- >> -- Skylar Thompson (skyl...@u.washington.edu) >> -- Genome Sciences Department, System Administrator >> -- Foege Building S046, (206)-685-7354 >> -- University of Washington School of Medicine >> >> > >-- >William Sefranek >University of Buffalo >Enterprise Infrastructure Services >(716)645-5116
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 / > 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 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 > To: ADSM-L@VM.MARIST.EDU > Subject: 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 days(f.backup_end)<(days(current_date)-30) - ORDER BY o.physical_mb > DESC > > On Thu, Jan 28, 2016 at 02:43:54PM +, Loon, EJ van (ITOPT3) - KLM wrote: > > 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, > > along with the amount of data stored for them in GB > > (cast(round(physical_mb/1024) as int) as "GB Stored"), sorted on size, the > > largest first. > > Can anybody help me out here? Thank you very much for your help in advance! > > Kind regards, > > Eric van Loon > > AF/KLM Storage Engineering > > > > 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. > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > > registered number 33014286 > > > > -- > -- Skylar Thompson (skyl...@u.washington.edu) > -- Genome Sciences Department, System Administrator > -- Foege Building S046, (206)-685-7354 > -- University of Washington School of Medicine > > 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. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch > Airlines) is registered in Amstelveen, The Netherlands, with registered > number 33014286 > > -- -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine
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 > 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_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, Skylar Thompson wrote: > >> 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 days(f.backup_end)<(days(current_date)-30) - > >> ORDER BY o.physical_mb DESC > >> > >> On Thu, Jan 28, 2016 at 02:43:54PM +, Loon, EJ van (ITOPT3) - KLM > >> wrote: > >>> 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, > >>> along with the amount of data stored for them in GB > >>> (cast(round(physical_mb/1024) as int) as "GB Stored"), sorted on size, > >>> the largest first. > >>> Can anybody help me out here? Thank you very much for your help in > >>> advance! > >>> Kind regards, > >>> Eric van Loon > >>> AF/KLM Storage Engineering > >>> > >>> 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. > >>> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch > >>> Airlines) is registered in Amstelveen, The Netherlands, with registered > >>> number 33014286 > >>> > >> -- > >> -- Skylar Thompson (skyl...@u.washington.edu) > >> -- Genome Sciences Department, System Administrator > >> -- Foege Building S046, (206)-685-7354 > >> -- University of Washington School of Medicine > >> > >> > > > >-- > >William Sefranek > >University of Buffalo > >Enterprise Infrastructure Services > >(716)645-5116 -- -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine
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.MARIST.EDU Subject: 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 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 To: ADSM-L@VM.MARIST.EDU Subject: 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 days(f.backup_end)<(days(current_date)-30) - ORDER BY o.physical_mb DESC On Thu, Jan 28, 2016 at 02:43:54PM +, Loon, EJ van (ITOPT3) - KLM wrote: > 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, > along with the amount of data stored for them in GB > (cast(round(physical_mb/1024) as int) as "GB Stored"), sorted on size, the > largest first. > Can anybody help me out here? Thank you very much for your help in advance! > Kind regards, > Eric van Loon > AF/KLM Storage Engineering > > 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. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > -- -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 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 immediat
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 RAID group and are writing to more than 1 tape drive you cause random seeks which slow down the throughput of the RAID group. When TSM writes to a disk pool it writes each session sequentially, but when there is more than 1 session it appears random to the RAID group. When I build disk volumes I try to limit the data written in such a way that the number of tape drives to be fed from each pool (RAID group for me) is limited. Because tape drives can take data faster than a RAID group can send it with many seeks you can end up with the tape drive stopping and starting. This really slows down the tape drive. More smaller disks (therefore RAID groups) to many tape drives will always win. The speed of the disk is less important when there are many arms (AS/400 speak) allowing for more than 1 access to occur at the same time. SSD solves the random access problem, but you still need to configure SSD for GB/sec not IOPS. The last disk pool I built was on a slow disk array (it was retired and 'gifted' to backups) To make it less slow I built many mirrored RAID groups.(1+0) Each became a file system and each contained a volume from each disk pool. The actual disks were 500GB FC disks. Ganged to together they were able to keep up with 3592 drives (110MB/sec + compression). One file system per RAID group helps reduce seeks and allows for TSM and AIX to understand the disk layout and cache better. I would avoid the purchase of large disks that are to be used for the transient daily backups in favor or smaller disks. I know there is a cost part to the problem so you have to make the best possible choice which may not be the best choice for the server. Andy Huebner SME - Storage and Backups GDC - Fort Worth -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Zoltan Forray Sent: Tuesday, January 26, 2016 2:56 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] When can too many disk volumes be detrimental RedHat Linux 6.7 with TSM 6.3.5.100 Back in the "good old days" of ADSM/TSM, I was always taught that the more TSM disk volumes you had, the better since TSM would spread the I/O's across the volumes in a somewhat balanced manner, to improve performance. Yes I realize this was with multiple physical spindles. Now with bigger hard drives, I am wondering if having to many volumes is hurting I/O performance. Here is the situation. We recently replaced 2-TSM servers that had rolled off warranty (4-year old Dell T710 systems) that had 8-600GB internal disk. The new servers are T720 systems with *6TB* drives (both have 96GB RAM). So I went from roughly *5TB* of internal disk storage for inbound backups to *30TB*. I went from multiple 300GB disk volumes to 30-1TB volumes. Plus add 20TB of SAN space gives me 40-disk volumes. The reasons for my concern is the time it takes to move the data from disk to tape. I am seeing it take 11-hours to empty (move data) a 100% full 1TB disk volume. To me, this is very, very slow. We had a hard disk failure that for some reason (all RAID5) took out part of the OS partition and damaged the /tsmlog and /tsmarchlog filesystems, forcing me to restore from a 8-hour old DB backup (even Dell said this should not have happened so they replaced the drive and PERC controller). It has taken more than *2-weeks* of non-stop audit, move data of non-damaged files, restore of damaged files - processes against the internal disk volumes. I recorded some audits running 32-hours). As I redefine/rebuild the disk volumes, I am starting to create 2 and 3TB volumes to see if that helps improve performance. So, your thoughts/ideas/suggestions on what might be going on here. -- *Zoltan Forray* TSM Software & Hardware Administrator Xymon Monitor Administrator 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: 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 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, Skylar Thompson wrote: > 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 days(f.backup_end)<(days(current_date)-30) - > ORDER BY o.physical_mb DESC > > On Thu, Jan 28, 2016 at 02:43:54PM +, Loon, EJ van (ITOPT3) - KLM wrote: >> 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, >> along with the amount of data stored for them in GB >> (cast(round(physical_mb/1024) as int) as "GB Stored"), sorted on size, the >> largest first. >> Can anybody help me out here? Thank you very much for your help in advance! >> Kind regards, >> Eric van Loon >> AF/KLM Storage Engineering >> >> 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. >> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch >> Airlines) is registered in Amstelveen, The Netherlands, with registered >> number 33014286 >> > -- > -- Skylar Thompson (skyl...@u.washington.edu) > -- Genome Sciences Department, System Administrator > -- Foege Building S046, (206)-685-7354 > -- University of Washington School of Medicine > > -- William Sefranek University of Buffalo Enterprise Infrastructure Services (716)645-5116
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 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] 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 change ACTIVELOGSIZE and restart the server. Unless I missed it, the link/article posted by Erwann ( http://www-01.ibm.com/support/docview.wss?uid=swg21677011) doesn't clarify. It just says "*Decrease the ACTIVELOGSIZE to allow the current filesystem to be 20% greater than the ACTIVELOGSIZE specified*" but no link says exactly how to do it. On Wed, Jan 27, 2016 at 2:26 PM, Nixon, Charles D. (David) < cdni...@carilionclinic.org> wrote: > This is what we had to do too (shrink logs to 50% before upgrade and then > grow after the procedure). It tried to double logs and then I believe that > it forgot about the mirrored location because we were out of space. > > > --- > David Nixon > System Programmer II > Technology Services Group > Carilion Clinic > 451 Kimball Ave. > Roanoke, VA 24015 > Phone: 540-224-3903 > cdni...@carilionclinic.org > > Our mission: Improve the health of the communities we serve. > > > > > From: ADSM: Dist Stor Manager [ADSM-L@VM.MARIST.EDU] on behalf of Lee, > Gary [g...@bsu.edu] > Sent: Monday, January 25, 2016 12:50 PM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] Upgrade server from 6.3 to 7.1 > > I never saw it in the docs. > > What I had to do was disable the server, do a full backup on the db, then > once I had verified the logs were empty, reduced log size to less than half > file system space. > Then do the upgrade, and enlarge logs as necessary after upgrade is > verified working. > > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Rainer Tammer > Sent: Monday, January 25, 2016 11:16 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] Upgrade server from 6.3 to 7.1 > > Hello, > Is this mentioned in the docs? > > That would be a bit difficult in our setup: > > Filesystem GB blocks Free %Used Iused %Iused Mounted on > /dev/lvtsmactlog 130.00 1.98 99%262 1% > /tsminst1/tsmactlog <- active log > /dev/lvtsmarchlog 197.00 193.37 2% 251% > /tsminst1/tsmarchlog <- archive log > > > Bye > Rainer > > On 25.01.2016 16:51, Lee, Gary wrote: > > Yes. > > > > Make sure that you have at least double the size of your active and > archive logs as available free space in the respective log directories. > > i.e. . if your active log size is 32 gB, insure that your log directory > has more than 64 gB free. Otherwise the database upgrade will fail on > install. > > > > Other than that, it went well, going from 6.3.4 to 7.1.3. > > > > > > > > -Original Message- > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf > Of molin gregory > > Sent: Monday, January 25, 2016 10:30 AM > > To: ADSM-L@VM.MARIST.EDU > > Subject: [ADSM-L] Upgrade server from 6.3 to 7.1 > > > > Hello everyone > > > > I plan to upgrade my server from version 6.3 to version 7.1. > > Have you had problems with this procedure? > > > > Thank you beforehand > > Grégory > > "ATTENTION. > > > > Ce message et les pièces jointes sont confidentiels et établis à > l'attention exclusive de leur destinataire (aux adresses spécifiques > auxquelles il a été adressé). Si vous n'êtes pas le destinataire de ce > message, vous devez immédiatement en avertir l'expéditeur et supprimer ce > message et les pièces jointes de votre système. > > > > This message and any attachments are confidential and intended to be > received only by the addressee. If you are not the intended recipient, > please notify immediately the sender by reply and delete the message and > any attachments from your system. " > > > > > > > > Notice: The information and attachment(s) contained in this communication > are intended for the addressee only, and may be confidential and/or legally > privileged. If you have received this communication in error, please > contact the sender immediately, and delete this communication from any > computer or network system. Any interception, review, printing, copying, > re-transmission, dissemination, or other use of, or taking of any action > upon this information by persons or entities other than the intended > recipient is strictly prohibited by law and may subject them to criminal or > civil liability. Carilion Clinic
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 Enterprise Infrastructure Services (716)645-5116
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 can't afford it. Even trying for 2-1TB mirrored volumes for the DB (500GB drives would cut it too close since the DB on this system is currently 315GB) is cost prohibitive. On Thu, Jan 28, 2016 at 10:58 AM, Huebner, Andy wrote: > 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 RAID group and are writing to more than 1 tape drive you cause > random seeks which slow down the throughput of the RAID group. > When TSM writes to a disk pool it writes each session sequentially, but > when there is more than 1 session it appears random to the RAID group. > > When I build disk volumes I try to limit the data written in such a way > that the number of tape drives to be fed from each pool (RAID group for me) > is limited. Because tape drives can take data faster than a RAID group can > send it with many seeks you can end up with the tape drive stopping and > starting. This really slows down the tape drive. > > More smaller disks (therefore RAID groups) to many tape drives will always > win. The speed of the disk is less important when there are many arms > (AS/400 speak) allowing for more than 1 access to occur at the same time. > > SSD solves the random access problem, but you still need to configure SSD > for GB/sec not IOPS. > > The last disk pool I built was on a slow disk array (it was retired and > 'gifted' to backups) To make it less slow I built many mirrored RAID > groups.(1+0) Each became a file system and each contained a volume from > each disk pool. The actual disks were 500GB FC disks. Ganged to together > they were able to keep up with 3592 drives (110MB/sec + compression). > One file system per RAID group helps reduce seeks and allows for TSM and > AIX to understand the disk layout and cache better. > > I would avoid the purchase of large disks that are to be used for the > transient daily backups in favor or smaller disks. I know there is a cost > part to the problem so you have to make the best possible choice which may > not be the best choice for the server. > > Andy Huebner > SME - Storage and Backups GDC - Fort Worth > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Zoltan Forray > Sent: Tuesday, January 26, 2016 2:56 PM > To: ADSM-L@VM.MARIST.EDU > Subject: [ADSM-L] When can too many disk volumes be detrimental > > RedHat Linux 6.7 with TSM 6.3.5.100 > > Back in the "good old days" of ADSM/TSM, I was always taught that the more > TSM disk volumes you had, the better since TSM would spread the I/O's > across the volumes in a somewhat balanced manner, to improve performance. > Yes I realize this was with multiple physical spindles. > > Now with bigger hard drives, I am wondering if having to many volumes > is hurting I/O performance. Here is the situation. > > We recently replaced 2-TSM servers that had rolled off warranty (4-year > old Dell T710 systems) that had 8-600GB internal disk. The new servers are > T720 systems with *6TB* drives (both have 96GB RAM). So I went from roughly > *5TB* of internal disk storage for inbound backups to *30TB*. I went from > multiple 300GB disk volumes to 30-1TB volumes. Plus add 20TB of SAN space > gives me 40-disk volumes. > > The reasons for my concern is the time it takes to move the data from disk > to tape. I am seeing it take 11-hours to empty (move data) a 100% full 1TB > disk volume. To me, this is very, very slow. > > We had a hard disk failure that for some reason (all RAID5) took out part > of the OS partition and damaged the /tsmlog and /tsmarchlog filesystems, > forcing me to restore from a 8-hour old DB backup (even Dell said this > should not have happened so they replaced the drive and PERC controller). > It has taken more than *2-weeks* of non-stop audit, move data of > non-damaged files, restore of damaged files - processes against the > internal disk volumes. I recorded some audits running 32-hours). > > As I redefine/rebuild the disk volumes, I am starting to create 2 and 3TB > volumes to see if that helps improve performance. > > So, your thoughts/ideas/suggestions on what might be going on here. > > -- > *Zoltan Forray* > TSM Software & Hardware Administrator > Xymon Monitor Administrator > 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
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 document you refer to? We were unaware of such a document (or config value). The RHEL read-ahead cache is set to the default of 128K. Currently all caching is via PERC. -- *Zoltan Forray* TSM Software & Hardware Administrator Xymon Monitor Administrator 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: 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 > 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 > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] 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 change ACTIVELOGSIZE and restart the > server. Unless I missed it, the link/article posted by Erwann ( > http://www-01.ibm.com/support/docview.wss?uid=swg21677011) doesn't > clarify. It just says "*Decrease the ACTIVELOGSIZE to allow the current > filesystem to be 20% greater than the ACTIVELOGSIZE specified*" but no link > says exactly how to do it. > > On Wed, Jan 27, 2016 at 2:26 PM, Nixon, Charles D. (David) < > cdni...@carilionclinic.org> wrote: > > > This is what we had to do too (shrink logs to 50% before upgrade and then > > grow after the procedure). It tried to double logs and then I believe > that > > it forgot about the mirrored location because we were out of space. > > > > > > --- > > David Nixon > > System Programmer II > > Technology Services Group > > Carilion Clinic > > 451 Kimball Ave. > > Roanoke, VA 24015 > > Phone: 540-224-3903 > > cdni...@carilionclinic.org > > > > Our mission: Improve the health of the communities we serve. > > > > > > > > > > From: ADSM: Dist Stor Manager [ADSM-L@VM.MARIST.EDU] on behalf of Lee, > > Gary [g...@bsu.edu] > > Sent: Monday, January 25, 2016 12:50 PM > > To: ADSM-L@VM.MARIST.EDU > > Subject: Re: [ADSM-L] Upgrade server from 6.3 to 7.1 > > > > I never saw it in the docs. > > > > What I had to do was disable the server, do a full backup on the db, then > > once I had verified the logs were empty, reduced log size to less than > half > > file system space. > > Then do the upgrade, and enlarge logs as necessary after upgrade is > > verified working. > > > > > > -Original Message- > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > > Rainer Tammer > > Sent: Monday, January 25, 2016 11:16 AM > > To: ADSM-L@VM.MARIST.EDU > > Subject: Re: [ADSM-L] Upgrade server from 6.3 to 7.1 > > > > Hello, > > Is this mentioned in the docs? > > > > That would be a bit difficult in our setup: > > > > Filesystem GB blocks Free %Used Iused %Iused Mounted on > > /dev/lvtsmactlog 130.00 1.98 99%262 1% > > /tsminst1/tsmactlog <- active log > > /dev/lvtsmarchlog 197.00 193.37 2% 251% > > /tsminst1/tsmarchlog <- archive log > > > > > > Bye > > Rainer > > > > On 25.01.2016 16:51, Lee, Gary wrote: > > > Yes. > > > > > > Make sure that you have at least double the size of your active and > > archive logs as available free space in the respective log directories. > > > i.e. . if your active log size is 32 gB, insure that your log directory > > has more than 64 gB free. Otherwise the database upgrade will fail on > > install. > > > > > > Other than that, it went well, going from 6.3.4 to 7.1.3. > > > > > > > > > > > > -Original Message- > > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf > > Of molin gregory > > > Sent: Monday, January 25, 2016 10:30 AM > > > To: ADSM-L@VM.MARIST.EDU > > > Subject: [ADSM-L] Upgrade server from 6.3 to 7.1 > > > > > > Hello everyone > > > > > > I plan to upgrade my server from version 6.3 to version 7.1. > > > Have you had problems with this procedure? > > > > > > Thank you beforehand > > > Grégory > > > "ATTENTION. > > > > > > Ce message et les pièces jointes sont confidentiels et établis à > > l'attention exclusive de leur destinataire (aux adresses spécifiques > > auxquelles il a été adressé). Si vous n'êtes pas le destinataire de ce > > message, vous devez immédiatement en avertir l'expéditeur et supprimer ce > > message et les pièces jointes de votre système. > > > > > > This message and any attachments are confidential and intended to be > > received only by the addressee. If you are not the intended recipient, > > please notify immediately the sender by reply and delete the message and > > any attachments from your system. " > > > > > > > > > > > > > > Notice: The information and attachment(s) contained in this communication > > are intended for the addressee only, and may be confidential and/or >
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 trying to protect? Backing up Eucalyptus (the CLC database, etc.) itself should not be that difficult. Ephemeral EC2 instance storage should not be backed up at all (by the cloud infrastructure). Educate the users to consider them throw-away storage and to make sure that the applications can survives a loss of an instance in one AZ. EBS storage can be backed up to S3 using snapshots, just like you do in AWS. Perhaps it might make sense to back up S3 (walrus) to TSM?
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, x7942 RMD IT Client Services On Thu, Jan 28, 2016 at 11:38 AM, Zoltan Forray wrote: > 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 document you refer to? We were unaware of such a document > (or config value). The RHEL read-ahead cache is set to the default of > 128K. Currently all caching is via PERC. > > > -- > *Zoltan Forray* > TSM Software & Hardware Administrator > Xymon Monitor Administrator > 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: 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 statement "*For the Tivoli Storage Manager database and logs, use the ext3 file system.*" Whats up with that? They explain why you should use ext4 for the storage volumes but no details on ext3 for DB/logs? On Thu, Jan 28, 2016 at 1:05 PM, Ryder, Michael S wrote: > 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, x7942 > RMD IT Client Services > > On Thu, Jan 28, 2016 at 11:38 AM, Zoltan Forray wrote: > > > 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 document you refer to? We were unaware of such a document > > (or config value). The RHEL read-ahead cache is set to the default of > > 128K. Currently all caching is via PERC. > > > > > > -- > > *Zoltan Forray* > > TSM Software & Hardware Administrator > > Xymon Monitor Administrator > > 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* TSM Software & Hardware Administrator Xymon Monitor Administrator 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: [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] On Behalf Of Zoltan Forray Sent: Thursday, January 28, 2016 11:45 AM To: ADSM-L@VM.MARIST.EDU Subject: [Non-DoD Source] Re: [ADSM-L] Upgrade server from 6.3 to 7.1 All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. 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 > memory serves. > Been too long since I did it, and can't find my notes. > > > -Original Message- > From: ADSM: Dist Stor Manager [Caution-mailto:ADSM-L@VM.MARIST.EDU] On > Behalf Of Zoltan Forray > Sent: Thursday, January 28, 2016 10:52 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] 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 change ACTIVELOGSIZE and restart > the server. Unless I missed it, the link/article posted by Erwann ( > Caution-http://www-01.ibm.com/support/docview.wss?uid=swg21677011) > doesn't clarify. It just says "*Decrease the ACTIVELOGSIZE to allow > the current filesystem to be 20% greater than the ACTIVELOGSIZE > specified*" but no link says exactly how to do it. > > On Wed, Jan 27, 2016 at 2:26 PM, Nixon, Charles D. (David) < > cdni...@carilionclinic.org> wrote: > > > This is what we had to do too (shrink logs to 50% before upgrade and > > then grow after the procedure). It tried to double logs and then I > > believe > that > > it forgot about the mirrored location because we were out of space. > > > > > > --- > > David Nixon > > System Programmer II > > Technology Services Group > > Carilion Clinic > > 451 Kimball Ave. > > Roanoke, VA 24015 > > Phone: 540-224-3903 > > cdni...@carilionclinic.org > > > > Our mission: Improve the health of the communities we serve. > > > > > > > > > > From: ADSM: Dist Stor Manager [ADSM-L@VM.MARIST.EDU] on behalf of > > Lee, Gary [g...@bsu.edu] > > Sent: Monday, January 25, 2016 12:50 PM > > To: ADSM-L@VM.MARIST.EDU > > Subject: Re: [ADSM-L] Upgrade server from 6.3 to 7.1 > > > > I never saw it in the docs. > > > > What I had to do was disable the server, do a full backup on the db, > > then once I had verified the logs were empty, reduced log size to > > less than > half > > file system space. > > Then do the upgrade, and enlarge logs as necessary after upgrade is > > verified working. > > > > > > -Original Message- > > From: ADSM: Dist Stor Manager [Caution-mailto:ADSM-L@VM.MARIST.EDU] > > On Behalf Of Rainer Tammer > > Sent: Monday, January 25, 2016 11:16 AM > > To: ADSM-L@VM.MARIST.EDU > > Subject: Re: [ADSM-L] Upgrade server from 6.3 to 7.1 > > > > Hello, > > Is this mentioned in the docs? > > > > That would be a bit difficult in our setup: > > > > Filesystem GB blocks Free %Used Iused %Iused Mounted on > > /dev/lvtsmactlog 130.00 1.98 99%262 1% > > /tsminst1/tsmactlog <- active log > > /dev/lvtsmarchlog 197.00 193.37 2% 251% > > /tsminst1/tsmarchlog <- archive log > > > > > > Bye > > Rainer > > > > On 25.01.2016 16:51, Lee, Gary wrote: > > > Yes. > > > > > > Make sure that you have at least double the size of your active > > > and > > archive logs as available free space in the respective log directories. > > > i.e. . if your active log size is 32 gB, insure that your log > > > directory > > has more than 64 gB free. Otherwise the database upgrade will fail > > on install. > > > > > > Other than that, it went well, going from 6.3.4 to 7.1.3. > > > > > > > > > > > > -Original Message- > > > From: ADSM: Dist Stor Manager > > > [Caution-mailto:ADSM-L@VM.MARIST.EDU] On Behalf > > Of molin gregory > > > Sent: Monday, January 25, 2016 10:30 AM > > > To: ADSM-L@VM.MARIST.EDU > > > Subject: [ADSM-L] Upgrade server from 6.3 to 7.1 > > > > > > Hello everyone > > > > > > I plan to upgrade my server from version 6.3 to version 7.1. > > > Have you had problems with this procedure? > > > > > > Thank you beforehand > > > Grégory > > > "ATTENTION. > > > > > > Ce message et les pièces jointes so
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 BDE (US) wrote: > 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] On Behalf Of > Zoltan Forray > Sent: Thursday, January 28, 2016 11:45 AM > To: ADSM-L@VM.MARIST.EDU > Subject: [Non-DoD Source] Re: [ADSM-L] Upgrade server from 6.3 to 7.1 > > All active links contained in this email were disabled. Please verify the > identity of the sender, and confirm the authenticity of all links contained > within the message prior to copying and pasting the address to a Web > browser. > > > > > > > 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 > > memory serves. > > Been too long since I did it, and can't find my notes. > > > > > > -Original Message- > > From: ADSM: Dist Stor Manager [Caution-mailto:ADSM-L@VM.MARIST.EDU] On > > Behalf Of Zoltan Forray > > Sent: Thursday, January 28, 2016 10:52 AM > > To: ADSM-L@VM.MARIST.EDU > > Subject: Re: [ADSM-L] 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 change ACTIVELOGSIZE and restart > > the server. Unless I missed it, the link/article posted by Erwann ( > > Caution-http://www-01.ibm.com/support/docview.wss?uid=swg21677011) > > doesn't clarify. It just says "*Decrease the ACTIVELOGSIZE to allow > > the current filesystem to be 20% greater than the ACTIVELOGSIZE > > specified*" but no link says exactly how to do it. > > > > On Wed, Jan 27, 2016 at 2:26 PM, Nixon, Charles D. (David) < > > cdni...@carilionclinic.org> wrote: > > > > > This is what we had to do too (shrink logs to 50% before upgrade and > > > then grow after the procedure). It tried to double logs and then I > > > believe > > that > > > it forgot about the mirrored location because we were out of space. > > > > > > > > > --- > > > David Nixon > > > System Programmer II > > > Technology Services Group > > > Carilion Clinic > > > 451 Kimball Ave. > > > Roanoke, VA 24015 > > > Phone: 540-224-3903 > > > cdni...@carilionclinic.org > > > > > > Our mission: Improve the health of the communities we serve. > > > > > > > > > > > > > > > From: ADSM: Dist Stor Manager [ADSM-L@VM.MARIST.EDU] on behalf of > > > Lee, Gary [g...@bsu.edu] > > > Sent: Monday, January 25, 2016 12:50 PM > > > To: ADSM-L@VM.MARIST.EDU > > > Subject: Re: [ADSM-L] Upgrade server from 6.3 to 7.1 > > > > > > I never saw it in the docs. > > > > > > What I had to do was disable the server, do a full backup on the db, > > > then once I had verified the logs were empty, reduced log size to > > > less than > > half > > > file system space. > > > Then do the upgrade, and enlarge logs as necessary after upgrade is > > > verified working. > > > > > > > > > -Original Message- > > > From: ADSM: Dist Stor Manager [Caution-mailto:ADSM-L@VM.MARIST.EDU] > > > On Behalf Of Rainer Tammer > > > Sent: Monday, January 25, 2016 11:16 AM > > > To: ADSM-L@VM.MARIST.EDU > > > Subject: Re: [ADSM-L] Upgrade server from 6.3 to 7.1 > > > > > > Hello, > > > Is this mentioned in the docs? > > > > > > That would be a bit difficult in our setup: > > > > > > Filesystem GB blocks Free %Used Iused %Iused Mounted on > > > /dev/lvtsmactlog 130.00 1.98 99%262 1% > > > /tsminst1/tsmactlog <- active log > > > /dev/lvtsmarchlog 197.00 193.37 2% 251% > > > /tsminst1/tsmarchlog <- archive log > > > > > > > > > Bye > > > Rainer > > > > > > On 25.01.2016 16:51, Lee, Gary wrote: > > > > Yes. > > > > > > > > Make sure that you have at least double the size of your active > > > > and > > > archive logs as available free space in the respective log directories. > > > > i.e. . if your active log size is 32 gB, insure that your log > > > > directory > > > has more than 64 gB free. Otherwise the database upgrade will fail > > > on install. > > > > > > > > Other than that, it went well, going from 6.3.4 to 7.1.3. > > > > > >
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 / Cordialement / مع تحياتي Erwann SIMON - Mail original - De: "Zoltan Forray" À: ADSM-L@VM.MARIST.EDU Envoyé: Jeudi 28 Janvier 2016 21:03:08 Objet: Re: [ADSM-L] [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 BDE (US) wrote: > 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] On Behalf Of > Zoltan Forray > Sent: Thursday, January 28, 2016 11:45 AM > To: ADSM-L@VM.MARIST.EDU > Subject: [Non-DoD Source] Re: [ADSM-L] Upgrade server from 6.3 to 7.1 > > All active links contained in this email were disabled. Please verify the > identity of the sender, and confirm the authenticity of all links contained > within the message prior to copying and pasting the address to a Web > browser. > > > > > > > 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 > > memory serves. > > Been too long since I did it, and can't find my notes. > > > > > > -Original Message- > > From: ADSM: Dist Stor Manager [Caution-mailto:ADSM-L@VM.MARIST.EDU] On > > Behalf Of Zoltan Forray > > Sent: Thursday, January 28, 2016 10:52 AM > > To: ADSM-L@VM.MARIST.EDU > > Subject: Re: [ADSM-L] 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 change ACTIVELOGSIZE and restart > > the server. Unless I missed it, the link/article posted by Erwann ( > > Caution-http://www-01.ibm.com/support/docview.wss?uid=swg21677011) > > doesn't clarify. It just says "*Decrease the ACTIVELOGSIZE to allow > > the current filesystem to be 20% greater than the ACTIVELOGSIZE > > specified*" but no link says exactly how to do it. > > > > On Wed, Jan 27, 2016 at 2:26 PM, Nixon, Charles D. (David) < > > cdni...@carilionclinic.org> wrote: > > > > > This is what we had to do too (shrink logs to 50% before upgrade and > > > then grow after the procedure). It tried to double logs and then I > > > believe > > that > > > it forgot about the mirrored location because we were out of space. > > > > > > > > > --- > > > David Nixon > > > System Programmer II > > > Technology Services Group > > > Carilion Clinic > > > 451 Kimball Ave. > > > Roanoke, VA 24015 > > > Phone: 540-224-3903 > > > cdni...@carilionclinic.org > > > > > > Our mission: Improve the health of the communities we serve. > > > > > > > > > > > > > > > From: ADSM: Dist Stor Manager [ADSM-L@VM.MARIST.EDU] on behalf of > > > Lee, Gary [g...@bsu.edu] > > > Sent: Monday, January 25, 2016 12:50 PM > > > To: ADSM-L@VM.MARIST.EDU > > > Subject: Re: [ADSM-L] Upgrade server from 6.3 to 7.1 > > > > > > I never saw it in the docs. > > > > > > What I had to do was disable the server, do a full backup on the db, > > > then once I had verified the logs were empty, reduced log size to > > > less than > > half > > > file system space. > > > Then do the upgrade, and enlarge logs as necessary after upgrade is > > > verified working. > > > > > > > > > -Original Message- > > > From: ADSM: Dist Stor Manager [Caution-mailto:ADSM-L@VM.MARIST.EDU] > > > On Behalf Of Rainer Tammer > > > Sent: Monday, January 25, 2016 11:16 AM > > > To: ADSM-L@VM.MARIST.EDU > > > Subject: Re: [ADSM-L] Upgrade server from 6.3 to 7.1 > > > > > > Hello, > > > Is this mentioned in the docs? > > > > > > That would be a bit difficult in our setup: > > > > > > Filesystem GB blocks Free %Used Iused %Iused Mounted on > > > /dev/lvtsmactlog 130.00 1.98 99%262 1% > > > /tsminst1/tsmactlog <- active log > > > /dev/lvtsmarchlog 197.00 193.37 2% 251% > > > /tsminst1/tsmarchlog <- archive log > >
