Re: Database backup performance
Well, changing the TAPEIOBUFS setting from 1 to 9 made no significant change ! Any other suggestions or am I simply out of luck and have to live with 3-4 hour DB backups ? === Zoltan Forray Virginia Commonwealth University University Computing Center e-mail: [EMAIL PROTECTED] voice: 804-828-4807 Petr Prerost cc: Sent by: Subject: Re: Database backup performance "ADSM: Dist Stor Manager" <[EMAIL PROTECTED] RIST.EDU> 07/04/2001 03:16 AM Please respond to "ADSM: Dist Stor Manager" Hi Zoltan , what is your tapeiobufs setting ? Can you see better tape throughput with migration processing ? regards Petr - Puvodnm zprava - Od: "Zoltan Forray/AC/VCU" <[EMAIL PROTECTED]> Komu: <[EMAIL PROTECTED]> Odeslano: 2. cervence 2001 15:47 Predmet: Database backup performance > I want to thank everyone who responded to my question(s). It seems that > *EVERYONE* goes faster than us, some by a big margin. > > I just finished upgrading the OS/390 server from ADSM 3.1.2.50 to TSM > 4.1.3. I was hoping the DB backup would be faster. Unfortunately, there is > "no joy in Mudville". > > The first full DB backup performed after the upgrade took 4h 43m. > > I am still looking for suggestions on how to improve these numbers. > > Changing the backup to 3590 drives/tapes only shaved about 20 minutes off > the time. That mostly accounts for rewind and mount times (1-3590 vs > 9-3490). > > I have bumped the BUFPOOLSIZE value to 80M but still cant achieve the > elusive 98+% "Cache Hit Pct.". > > I've thought about trying SELFTUNEBUFPOOLSIZE but am a little concerned > since we are currently somewhat real-storage constrained and TSM is > currently at over 120M WSS, already. > > Anyone have any experience with this new option ? Any suggestions/tips to > improve the DB backup performance ? > > f adsm,q db f=d > ANR5965I Console command: Q DB F=D > > Available Space (MB): 17,496 > Assigned Capacity (MB): 17,496 > Maximum Extension (MB): 0 > Maximum Reduction (MB): 3,020 >Page Size (bytes): 4,096 > Total Usable Pages: 4,478,976 > Used Pages: 3,700,667 > Pct Util: 82.6 >Max. Pct Util: 82.6 > Physical Volumes: 8 >Buffer Pool Pages: 20,480 >Total Buffer Requests: 63,986,411 > Cache Hit Pct.: 95.31 > Cache Wait Pct.: 0.00 > Backup in Progress?: No > Type of Backup In Progress: > Incrementals Since Last Full: 0 > Changed Since Last Backup (MB): 376.67
Antwort: Re: Database backup performance
Zoltan, I don't know your server level, but if you want to un- and reload your TSM database at a specific level, you should reset this value to 1 - because it's a known bug, that your reload will fail, when you unloaded your database with tapeiobufs greater than 1 Gerhard Wolkerstorfer [EMAIL PROTECTED] am 05.07.2001 18:14:35 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: (Blindkopie: Gerhard Wolkerstorfer/DEBIS/EDVG/AT) Thema:Re: Database backup performance *1* I have increased it to 9 to see what happens. This could help in a *BIG* way, expecially migration and such. Thanks for pointing it out. === Zoltan Forray Virginia Commonwealth University University Computing Center e-mail: [EMAIL PROTECTED] voice: 804-828-4807 Petr Prerost cc: Sent by: Subject: Re: Database backup performance "ADSM: Dist Stor Manager" <[EMAIL PROTECTED] RIST.EDU> 07/04/2001 03:16 AM Please respond to "ADSM: Dist Stor Manager" Hi Zoltan , what is your tapeiobufs setting ? Can you see better tape throughput with migration processing ? regards Petr - Puvodnm zprava - Od: "Zoltan Forray/AC/VCU" <[EMAIL PROTECTED]> Komu: <[EMAIL PROTECTED]> Odeslano: 2. cervence 2001 15:47 Predmet: Database backup performance > I want to thank everyone who responded to my question(s). It seems that > *EVERYONE* goes faster than us, some by a big margin. > > I just finished upgrading the OS/390 server from ADSM 3.1.2.50 to TSM > 4.1.3. I was hoping the DB backup would be faster. Unfortunately, there is > "no joy in Mudville". > > The first full DB backup performed after the upgrade took 4h 43m. > > I am still looking for suggestions on how to improve these numbers. > > Changing the backup to 3590 drives/tapes only shaved about 20 minutes off > the time. That mostly accounts for rewind and mount times (1-3590 vs > 9-3490). > > I have bumped the BUFPOOLSIZE value to 80M but still cant achieve the > elusive 98+% "Cache Hit Pct.". > > I've thought about trying SELFTUNEBUFPOOLSIZE but am a little concerned > since we are currently somewhat real-storage constrained and TSM is > currently at over 120M WSS, already. > > Anyone have any experience with this new option ? Any suggestions/tips to > improve the DB backup performance ? > > f adsm,q db f=d > ANR5965I Console command: Q DB F=D > > Available Space (MB): 17,496 > Assigned Capacity (MB): 17,496 > Maximum Extension (MB): 0 > Maximum Reduction (MB): 3,020 >Page Size (bytes): 4,096 > Total Usable Pages: 4,478,976 > Used Pages: 3,700,667 > Pct Util: 82.6 >Max. Pct Util: 82.6 > Physical Volumes: 8 >Buffer Pool Pages: 20,480 >Total Buffer Requests: 63,986,411 > Cache Hit Pct.: 95.31 > Cache Wait Pct.: 0.00 > Backup in Progress?: No > Type of Backup In Progress: > Incrementals Since Last Full: 0 > Changed Since Last Backup (MB): 376.67
Re: Database backup performance
*1* I have increased it to 9 to see what happens. This could help in a *BIG* way, expecially migration and such. Thanks for pointing it out. === Zoltan Forray Virginia Commonwealth University University Computing Center e-mail: [EMAIL PROTECTED] voice: 804-828-4807 Petr Prerost cc: Sent by: Subject: Re: Database backup performance "ADSM: Dist Stor Manager" <[EMAIL PROTECTED] RIST.EDU> 07/04/2001 03:16 AM Please respond to "ADSM: Dist Stor Manager" Hi Zoltan , what is your tapeiobufs setting ? Can you see better tape throughput with migration processing ? regards Petr - Puvodnm zprava - Od: "Zoltan Forray/AC/VCU" <[EMAIL PROTECTED]> Komu: <[EMAIL PROTECTED]> Odeslano: 2. cervence 2001 15:47 Predmet: Database backup performance > I want to thank everyone who responded to my question(s). It seems that > *EVERYONE* goes faster than us, some by a big margin. > > I just finished upgrading the OS/390 server from ADSM 3.1.2.50 to TSM > 4.1.3. I was hoping the DB backup would be faster. Unfortunately, there is > "no joy in Mudville". > > The first full DB backup performed after the upgrade took 4h 43m. > > I am still looking for suggestions on how to improve these numbers. > > Changing the backup to 3590 drives/tapes only shaved about 20 minutes off > the time. That mostly accounts for rewind and mount times (1-3590 vs > 9-3490). > > I have bumped the BUFPOOLSIZE value to 80M but still cant achieve the > elusive 98+% "Cache Hit Pct.". > > I've thought about trying SELFTUNEBUFPOOLSIZE but am a little concerned > since we are currently somewhat real-storage constrained and TSM is > currently at over 120M WSS, already. > > Anyone have any experience with this new option ? Any suggestions/tips to > improve the DB backup performance ? > > f adsm,q db f=d > ANR5965I Console command: Q DB F=D > > Available Space (MB): 17,496 > Assigned Capacity (MB): 17,496 > Maximum Extension (MB): 0 > Maximum Reduction (MB): 3,020 >Page Size (bytes): 4,096 > Total Usable Pages: 4,478,976 > Used Pages: 3,700,667 > Pct Util: 82.6 >Max. Pct Util: 82.6 > Physical Volumes: 8 >Buffer Pool Pages: 20,480 >Total Buffer Requests: 63,986,411 > Cache Hit Pct.: 95.31 > Cache Wait Pct.: 0.00 > Backup in Progress?: No > Type of Backup In Progress: > Incrementals Since Last Full: 0 > Changed Since Last Backup (MB): 376.67
Re: Database backup performance
Hi Zoltan , what is your tapeiobufs setting ? Can you see better tape throughput with migration processing ? regards Petr - Puvodnm zprava - Od: "Zoltan Forray/AC/VCU" <[EMAIL PROTECTED]> Komu: <[EMAIL PROTECTED]> Odeslano: 2. cervence 2001 15:47 Predmet: Database backup performance > I want to thank everyone who responded to my question(s). It seems that > *EVERYONE* goes faster than us, some by a big margin. > > I just finished upgrading the OS/390 server from ADSM 3.1.2.50 to TSM > 4.1.3. I was hoping the DB backup would be faster. Unfortunately, there is > "no joy in Mudville". > > The first full DB backup performed after the upgrade took 4h 43m. > > I am still looking for suggestions on how to improve these numbers. > > Changing the backup to 3590 drives/tapes only shaved about 20 minutes off > the time. That mostly accounts for rewind and mount times (1-3590 vs > 9-3490). > > I have bumped the BUFPOOLSIZE value to 80M but still cant achieve the > elusive 98+% "Cache Hit Pct.". > > I've thought about trying SELFTUNEBUFPOOLSIZE but am a little concerned > since we are currently somewhat real-storage constrained and TSM is > currently at over 120M WSS, already. > > Anyone have any experience with this new option ? Any suggestions/tips to > improve the DB backup performance ? > > f adsm,q db f=d > ANR5965I Console command: Q DB F=D > > Available Space (MB): 17,496 > Assigned Capacity (MB): 17,496 > Maximum Extension (MB): 0 > Maximum Reduction (MB): 3,020 >Page Size (bytes): 4,096 > Total Usable Pages: 4,478,976 > Used Pages: 3,700,667 > Pct Util: 82.6 >Max. Pct Util: 82.6 > Physical Volumes: 8 >Buffer Pool Pages: 20,480 >Total Buffer Requests: 63,986,411 > Cache Hit Pct.: 95.31 > Cache Wait Pct.: 0.00 > Backup in Progress?: No > Type of Backup In Progress: > Incrementals Since Last Full: 0 > Changed Since Last Backup (MB): 376.67
Re: Database backup performance
Zoltan, Your cache hit percentage is way too low, but that is not going to impact on your database backup performance anyway. I am not sure that you need to increase the number of bufferpool pages. My database is larger and has a smaller bufferpool with a better cache hit %. If you are happy that TSM is not busy doing numerous other processes or backups while you are performing your backup then the areas you need to be looking at are processor and device constraints. I f you have RMF, that will give you a good overview of what is slowing your database backup, in particular look at your disk activity rate and response times. These should be broadly speaking similar for all your devices. If you have one that is way worse than any of the others then you may want to add a new volume and move the database off the bad volume. If you do not have RMF you will need to have a look at the SMF records. Available Space (MB): 20,940 Assigned Capacity (MB): 20,940 Maximum Extension (MB): 0 Maximum Reduction (MB): 3,204 Page Size (bytes): 4,096 Total Usable Pages: 5,360,640 Used Pages: 4,492,151 Pct Util: 83.8 Max. Pct Util: 84.4 Physical Volumes: 9 Buffer Pool Pages: 12,288 Total Buffer Requests: 614,410,512 Cache Hit Pct.: 98.63 Cache Wait Pct.: 0.00 Hope this helps, John Available Space (MB): 17,496 Assigned Capacity (MB): 17,496 Maximum Extension (MB): 0 Maximum Reduction (MB): 3,020 Page Size (bytes): 4,096 Total Usable Pages: 4,478,976 Used Pages: 3,700,667 Pct Util: 82.6 Max. Pct Util: 82.6 Physical Volumes: 8 Buffer Pool Pages: 20,480 Total Buffer Requests: 63,986,411 Cache Hit Pct.: 95.31 Cache Wait Pct.: 0.00 Backup in Progress?: No Type of Backup In Progress: Incrementals Since Last Full: 0 Changed Since Last Backup (MB): 376.67 ** The information in this E-Mail is confidential and may be legally privileged. It may not represent the views of Scottish and Southern Energy plc. It is intended solely for the addressees. Access to this E-Mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any unauthorised recipient should advise the sender immediately of the error in transmission. Scottish Hydro-Electric and Southern Electric are trading names of Scottish and Southern Energy Group. **
Database backup performance
I want to thank everyone who responded to my question(s). It seems that *EVERYONE* goes faster than us, some by a big margin. I just finished upgrading the OS/390 server from ADSM 3.1.2.50 to TSM 4.1.3. I was hoping the DB backup would be faster. Unfortunately, there is "no joy in Mudville". The first full DB backup performed after the upgrade took 4h 43m. I am still looking for suggestions on how to improve these numbers. Changing the backup to 3590 drives/tapes only shaved about 20 minutes off the time. That mostly accounts for rewind and mount times (1-3590 vs 9-3490). I have bumped the BUFPOOLSIZE value to 80M but still cant achieve the elusive 98+% "Cache Hit Pct.". I've thought about trying SELFTUNEBUFPOOLSIZE but am a little concerned since we are currently somewhat real-storage constrained and TSM is currently at over 120M WSS, already. Anyone have any experience with this new option ? Any suggestions/tips to improve the DB backup performance ? f adsm,q db f=d ANR5965I Console command: Q DB F=D Available Space (MB): 17,496 Assigned Capacity (MB): 17,496 Maximum Extension (MB): 0 Maximum Reduction (MB): 3,020 Page Size (bytes): 4,096 Total Usable Pages: 4,478,976 Used Pages: 3,700,667 Pct Util: 82.6 Max. Pct Util: 82.6 Physical Volumes: 8 Buffer Pool Pages: 20,480 Total Buffer Requests: 63,986,411 Cache Hit Pct.: 95.31 Cache Wait Pct.: 0.00 Backup in Progress?: No Type of Backup In Progress: Incrementals Since Last Full: 0 Changed Since Last Backup (MB): 376.67
Re: Database backup performance
Our db backup stats are below. We do 2 db backups per day, one to disk and one to tape. all pages: 11,266,048 (44g) used pages: 8,387,060 (34g) disk bkup: 60min - local ESS disk tape bkup: 60min - 3590 drives processor: 6k-s7a
Re: Database backup performance
We back up 19,591,179 pages in 4 hours. This is an 83GB database, 91% utilized. Server is an RS/6000 M80. Backup media is DLT 7000 tape. Translates to 5.3MB/s by my calculation. Our incremental backups usually take 15-30 minutes.
Re: Database backup performance
Zoltan, I have a very large os/390 server. The last full dbb went at a rate of 3.3 million pages/hr, almost 5 times fater than yours. Since v1 r1 of adsm I haven't found any tricks to speed this up except to change hardware. My current system is cpu: 9672-ra6 tape: 9840 running 3590 emulation disk: STK SVA. 5 years ago the dbb went at a rate of 510,000 pages an hour. The hardware then was STK iceberg disk and 3490 tapes, I don't remember the processor. I don't think dbb speed has anything to do with the cache hit%. A sequential process like a full dbb should stay out of the cache since it would otherwise flood the cache with pages that aren't likely to be referenced again. Hope this helps, -- -- Bill Colwell C. S. Draper Lab Cambridge, Ma. [EMAIL PROTECTED] -- In <[EMAIL PROTECTED]>, on 06/27/01 at 01:34 PM, Zoltan Forray/AC/VCU <[EMAIL PROTECTED]> said: >I guess I should have clarified that the server is on OS/390, not *NIX !! >Thanks for all the responses on how long it takes. Now, how about ways to >improve the speed ? >I am trying a backup to 3590 drives, to see how much of a difference it >makes. So far, there does seem to be a speed difference. >I also went through the ADSM job log and collected some statistics. >The last FULL DB backup took more than 5-hours for 3665050 pages !!! >*** Hello, we full backup our 22.3 GB DB (assigned, used 92%) >in 39 minutes, using Magstar 3590E cartridges in the 3494 robotic. >Th DB is laying on mirrowed ssa-disks (7133) using 18GB-disks >(ibm7133-8518) >Processor in RS600/H50, OS/AIX 4.3.3 , TSM4.1.3.0 >...mabe you should first check the capability of the disks where your db >is located - what you would get there by reading on unix for example >a simple test would be done using dd for example >( if you have your server on unix) >Example: ># time dd if=/some_data_located_on_the_db_disk of=/dev/null bs=1024k >count=100 >100+0 records in. >100+0 records out. >real0m8.396s >user0m0.010s >sys 0m1.890s ># >... would get the time to just read 100MB ( just at the time of the test ) >running the example -dd- test again can to unrealistic low times when >data is cached, so a new test should be done with new data ( if=...)
Re: Database backup performance
Zoltan, Sorry I forgot to mention, as you are OS390 it will be worth looking at the RMF statistics for the period of the database backup. This should show which resource is causing your backup to run so slow. It could be cpu or possibly disk contention, John ** The information in this E-Mail is confidential and may be legally privileged. It may not represent the views of Scottish and Southern Energy plc. It is intended solely for the addressees. Access to this E-Mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any unauthorised recipient should advise the sender immediately of the error in transmission. Scottish Hydro-Electric and Southern Electric are trading names of Scottish and Southern Energy Group. **
Re: Database backup performance
Zoltan, We are OS390 too. Last full backup of 3.7.20.0 database took 1 hour 45 minutes (4464417 pages) to STK 9840 cartridge So you definitely should be faster John "Zoltan Forray/AC/VCU" <[EMAIL PROTECTED]> on 06/27/2001 05:04:04 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc:(bcc: John Naylor/HAV/SSEG) Subject: Re: Database backup performance I guess I should have clarified that the server is on OS/390, not *NIX !! Thanks for all the responses on how long it takes. Now, how about ways to improve the speed ? I am trying a backup to 3590 drives, to see how much of a difference it makes. So far, there does seem to be a speed difference. I also went through the ADSM job log and collected some statistics. The last FULL DB backup took more than 5-hours for 3665050 pages !!! *** >>> Hello, we full backup our 22.3 GB DB (assigned, used 92%) in 39 minutes, using Magstar 3590E cartridges in the 3494 robotic. Th DB is laying on mirrowed ssa-disks (7133) using 18GB-disks (ibm7133-8518) Processor in RS600/H50, OS/AIX 4.3.3 , TSM4.1.3.0 ...mabe you should first check the capability of the disks where your db is located - what you would get there by reading on unix for example a simple test would be done using dd for example ( if you have your server on unix) Example: # time dd if=/some_data_located_on_the_db_disk of=/dev/null bs=1024k count=100 100+0 records in. 100+0 records out. real0m8.396s user0m0.010s sys 0m1.890s # ... would get the time to just read 100MB ( just at the time of the test ) running the example -dd- test again can to unrealistic low times when data is cached, so a new test should be done with new data ( if=...) ** The information in this E-Mail is confidential and may be legally privileged. It may not represent the views of Scottish and Southern Energy plc. It is intended solely for the addressees. Access to this E-Mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any unauthorised recipient should advise the sender immediately of the error in transmission. Scottish Hydro-Electric and Southern Electric are trading names of Scottish and Southern Energy Group. **
Re: Database backup performance
I guess I should have clarified that the server is on OS/390, not *NIX !! Thanks for all the responses on how long it takes. Now, how about ways to improve the speed ? I am trying a backup to 3590 drives, to see how much of a difference it makes. So far, there does seem to be a speed difference. I also went through the ADSM job log and collected some statistics. The last FULL DB backup took more than 5-hours for 3665050 pages !!! *** >>> Hello, we full backup our 22.3 GB DB (assigned, used 92%) in 39 minutes, using Magstar 3590E cartridges in the 3494 robotic. Th DB is laying on mirrowed ssa-disks (7133) using 18GB-disks (ibm7133-8518) Processor in RS600/H50, OS/AIX 4.3.3 , TSM4.1.3.0 ...mabe you should first check the capability of the disks where your db is located - what you would get there by reading on unix for example a simple test would be done using dd for example ( if you have your server on unix) Example: # time dd if=/some_data_located_on_the_db_disk of=/dev/null bs=1024k count=100 100+0 records in. 100+0 records out. real0m8.396s user0m0.010s sys 0m1.890s # ... would get the time to just read 100MB ( just at the time of the test ) running the example -dd- test again can to unrealistic low times when data is cached, so a new test should be done with new data ( if=...)
Re: Database backup performance
Hello, we full backup our 22.3 GB DB (assigned, used 92%) in 39 minutes, using Magstar 3590E cartridges in the 3494 robotic. Th DB is laying on mirrowed ssa-disks (7133) using 18GB-disks (ibm7133-8518) Processor in RS600/H50, OS/AIX 4.3.3 , TSM4.1.3.0 ...mabe you should first check the capability of the disks where your db is located - what you would get there by reading on unix for example a simple test would be done using dd for example ( if you have your server on unix) Example: # time dd if=/some_data_located_on_the_db_disk of=/dev/null bs=1024k count=100 100+0 records in. 100+0 records out. real0m8.396s user0m0.010s sys 0m1.890s # ... would get the time to just read 100MB ( just at the time of the test ) running the example -dd- test again can to unrealistic low times when data is cached, so a new test should be done with new data ( if=...) > > -Original Message- > > From: Zoltan Forray/AC/VCU [SMTP:[EMAIL PROTECTED]] > > Sent: Wednesday, June 27, 2001 3:37 PM > > To: [EMAIL PROTECTED] > > Subject: Database backup performance > > > > Any suggestions on how to improve DB backup performance ? > > > > Doing a FULL DB backup of our 15GB ADSM (yes, not TSM YET. Hoping to > > convert to 4.1.3 RSN !!) server, sometimes takes 4-hours. > > > > Since I read a previous message about someone having a 52GB DB, I was > > wondering how long it takes to backup that much DB since my meager DB > > takes > > so long ? Note, there is no "operator delay" since it goes to a 3494 > > ATL, using 3490E drives. I was thinking about moving it to 3590 MAGSTAR > > but > > wasn't sure if it would make much of a difference since the only real > > change would be reduction/elimination of tape mounts (currently uses > > 9-cartridges). Since it is a robot, this would save a few minutes at most. > > > > I have tried increasing the BUFPOOL value (from 32MB to 80MB) with little > > noticable improvement. I still haven't reached/sustained the illusive 98% > > Cache Utilization ! > > > > Since the ADSM address space working set size has often exceed 110MB, I > > was > > wondering what was reasonable (or expected) for thise size DB. How much > > further should I increase the BUFPOOL value ? > > > > === > > Zoltan Forray > > Virginia Commonwealth University > > University Computing Center > > e-mail: [EMAIL PROTECTED] > > voice: 804-828-4807 -- Mit freundlichen Grüßen / best regards Rainer Wolf __ Rainer Wolf [EMAIL PROTECTED] Tel: 0731-50-22482 Fax: 0731-50-22471 University of Ulmhttp://www.uni-ulm.de/urz University Computing Center Albert-Einstein-Allee 11 AG Basissysteme 89069 Ulm
Re: Database backup performance
Doing the math on the quoted database backup sizes and times, plus my own, shows customers experiencing a db backup data rate of 3 - 4 MB/sec. That is well below the capabilities of the disk and tape technology in use, and points to the often-criticized TSM database system being the drag on performance. And many customers experiencing this are using today's fastest processors, so it looks like only architectural relief in the TSM database system will help. Richard Sims, BU
Re: Database backup performance
Our DB is 13.5GB, 65% utilized. Full backup in 30 minutes to IBM 3575 library with C-XL drives. TSM 3.7.4.0 on AIX 4.3.3, IBM RS6000 F50. David Longo >>> [EMAIL PROTECTED] 06/27/01 09:37AM >>> Any suggestions on how to improve DB backup performance ? Doing a FULL DB backup of our 15GB ADSM (yes, not TSM YET. Hoping to convert to 4.1.3 RSN !!) server, sometimes takes 4-hours. Since I read a previous message about someone having a 52GB DB, I was wondering how long it takes to backup that much DB since my meager DB takes so long ? Note, there is no "operator delay" since it goes to a 3494 ATL, using 3490E drives. I was thinking about moving it to 3590 MAGSTAR but wasn't sure if it would make much of a difference since the only real change would be reduction/elimination of tape mounts (currently uses 9-cartridges). Since it is a robot, this would save a few minutes at most. I have tried increasing the BUFPOOL value (from 32MB to 80MB) with little noticable improvement. I still haven't reached/sustained the illusive 98% Cache Utilization ! Since the ADSM address space working set size has often exceed 110MB, I was wondering what was reasonable (or expected) for thise size DB. How much further should I increase the BUFPOOL value ? === Zoltan Forray Virginia Commonwealth University University Computing Center e-mail: [EMAIL PROTECTED] voice: 804-828-4807 "MMS " made the following annotations on 06/27/01 11:07:49 -- This message is for the named person's use only. It may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Health First reserves the right to monitor all e-mail communications through its networks. Any views or opinions expressed in this message are solely those of the individual sender, except (1) where the message states such views or opinions are on behalf of a particular entity; and (2) the sender is authorized by the entity to give such views or opinions. ==
Re: Database backup performance
Our DB is 21 GB, 85% Utilized. Backup time is 34 minutes. Running TSM 3.7.4 on Windows 2000. Backup to DLT 7000 tape. This translates to about 9 MB/sec. Tim Rushforth City of Winnipeg
Re: Database backup performance
>Doing a FULL DB backup of our 15GB ADSM (yes, not TSM YET. Hoping to convert to 4.1.3 RSN !!) server, sometimes takes 4-hours. >Since I read a previous message about someone having a 52GB DB, I was wondering how long it takes to backup that much DB since my meager DB takes so long ? About 3 hours, as I recall. 3494 3590's, MCA high node, fast/wide scsi. It usually went to 2 tapes (barely.)
Re: Database backup performance
Hello, we full backup our 19 GB DB (used 80%) in 75 minutes, using Magstar 3590E cartridges in the 3494 robotic. Processor in Hitachi Pilot27, 120 mips, OS/390 2.9 Regards, René Lambelet Nestec S.A. / Informatique du Centre 55, av. Nestlé CH-1800 Vevey (Switzerland) *+41'21'924'35'43 7+41'21'924'28'88 * K4-117 email [EMAIL PROTECTED] Visit our site: http://www.nestle.com This message is intended only for the use of the addressee and may contain information that is privileged and confidential. > -Original Message- > From: Zoltan Forray/AC/VCU [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, June 27, 2001 3:37 PM > To: [EMAIL PROTECTED] > Subject: Database backup performance > > Any suggestions on how to improve DB backup performance ? > > Doing a FULL DB backup of our 15GB ADSM (yes, not TSM YET. Hoping to > convert to 4.1.3 RSN !!) server, sometimes takes 4-hours. > > Since I read a previous message about someone having a 52GB DB, I was > wondering how long it takes to backup that much DB since my meager DB > takes > so long ? Note, there is no "operator delay" since it goes to a 3494 > ATL, using 3490E drives. I was thinking about moving it to 3590 MAGSTAR > but > wasn't sure if it would make much of a difference since the only real > change would be reduction/elimination of tape mounts (currently uses > 9-cartridges). Since it is a robot, this would save a few minutes at most. > > I have tried increasing the BUFPOOL value (from 32MB to 80MB) with little > noticable improvement. I still haven't reached/sustained the illusive 98% > Cache Utilization ! > > Since the ADSM address space working set size has often exceed 110MB, I > was > wondering what was reasonable (or expected) for thise size DB. How much > further should I increase the BUFPOOL value ? > > === > Zoltan Forray > Virginia Commonwealth University > University Computing Center > e-mail: [EMAIL PROTECTED] > voice: 804-828-4807
Database backup performance
Any suggestions on how to improve DB backup performance ? Doing a FULL DB backup of our 15GB ADSM (yes, not TSM YET. Hoping to convert to 4.1.3 RSN !!) server, sometimes takes 4-hours. Since I read a previous message about someone having a 52GB DB, I was wondering how long it takes to backup that much DB since my meager DB takes so long ? Note, there is no "operator delay" since it goes to a 3494 ATL, using 3490E drives. I was thinking about moving it to 3590 MAGSTAR but wasn't sure if it would make much of a difference since the only real change would be reduction/elimination of tape mounts (currently uses 9-cartridges). Since it is a robot, this would save a few minutes at most. I have tried increasing the BUFPOOL value (from 32MB to 80MB) with little noticable improvement. I still haven't reached/sustained the illusive 98% Cache Utilization ! Since the ADSM address space working set size has often exceed 110MB, I was wondering what was reasonable (or expected) for thise size DB. How much further should I increase the BUFPOOL value ? === Zoltan Forray Virginia Commonwealth University University Computing Center e-mail: [EMAIL PROTECTED] voice: 804-828-4807
