Tom It's true that DBAs are the 600 pound gorillas in the room and often get what they want out of fear and management ignorance. A lot of it is simple need for control over their own destiny as they see it and that is understandable.
Once you have tuned the DB backups as much as you can there are further options. 1. Use appropriate Flashcopy products to provide point in time snapshots. This could be VSS Snapshots or hardware snapshots depending on your particular mix of hardware and software. 2. There used to be a way of offloading the backup job to another box. - take a hardware snapshot mount it elsewhere and back that up - I assume that still works on a virtual source and physical target. 3. Once you have something on physical hardware, you can use Storage agent to offload that data direct to tape, bypassing your TSM server. Note also that you can use more exotic combinations of client to storage agent, for example multiple backups can use the same storage agent and can be situated on the same network. E.g. in AIX multiple LPARs on the same CEC can all talk across the internal network to a LPAR with a storage agent. 4. If that is not possible because of tape restrictions, then you have to go to storage agent and shared disk, and that requires GPFS. Lay these options out, come up with some indicative costings. Then go back so something more reasonable. About 5 years ago I had a big DB2 database that took most of a weekend to back up. As a result we used a Full monthly, Differential weekly, incremental daily + logs strategy. This particular database was then exported/imported and restored as a User acceptance environment. It all worked without a hitch once set up. You could use some sort of similar Full+differential+logs strategy for these MSSQL databases. Do not make the mistake of thinking we will do all the fulls on the weekend, you have no more bandwidth then than you do during the week and will have more disruption due to system changes. Upper Management will baulk at the cost and the DBAs will be asked to change to the cheaper strategy. Take a sample application, set up your new strategy and test it forward and backward until the DBAs understand how it works and are comfortable that it does indeed work. Then implement more widely. I'm having the same sort of discussions with my own DBAs in my current role.. They still rely on disk dumps(!) and that is even less sustainable that your case. Good luck. Steve Steven Harris TSM Admin/Consultant Canberra Australia -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Matthew McGeary Sent: Tuesday, 28 March 2017 8:29 AM To: [email protected] Subject: Re: [ADSM-L] Best Practices/Best Performance SP/TSM B/A Client Settings ? I haven't had to change the buffers or any other settings and it's made a big difference but I didn't really experiment with different numbers. I landed on 10 based on similar experience using 10 sessions for DB2 API backup/recovery. Our largest SQL server backup is probably in the 500-600 GB range, so we aren't operating on the same scale as you are. Del is right that this is only for 'legacy' backups, not for VSS-offloaded. __________________________ Matthew McGeary Senior Technical Specialist – Infrastructure Management Services PotashCorp T: (306) 933-8921 www.potashcorp.com -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Tom Alverson Sent: Monday, March 27, 2017 2:17 PM To: [email protected] Subject: Re: [ADSM-L] Best Practices/Best Performance SP/TSM B/A Client Settings ? I will try that tonight. Do you change any of the other "performance" settings from the defaults? Thanks! Tom On Mon, Mar 27, 2017 at 3:24 PM, Matthew McGeary < [email protected]> wrote: > If you're using TDP for SQL you can specify how many stripes to use in > the tdpo.cfg file. > > For our large SQL backups, I use 10 stripes. > > __________________________ > Matthew McGeary > Senior Technical Specialist – Infrastructure Management Services > PotashCorp > T: (306) 933-8921 > www.potashcorp.com > > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf > Of Tom Alverson > Sent: Monday, March 27, 2017 1:11 PM > To: [email protected] > Subject: Re: [ADSM-L] Best Practices/Best Performance SP/TSM B/A > Client Settings ? > > Our biggest performance issue is with SQL backups of large databases. > Our DBA's all want full backups ever night (and log backups every > hour) and for the databases that are around 1TB the backup will start > at Midnight and finish 5 to 13 hours later (varies day to day). When > these backups start extending into the daytime hours they complain but > I don't know how we could improve the speed. Our Storage servers all > have 10GB interfaces but they are backing up hundreds of clients every > night (mostly incremental file level backups). I am running a test > right now to see if RESOURCEUTILIZATION 10 helps one of these database > backups but I suspect it will make no difference as 99% of the data is > all in one DB and I don't think SQL/TSM will split that into multiple streams > (will it?). > > On Sun, Mar 26, 2017 at 6:57 AM, Del Hoobler <[email protected]> wrote: > > > Hi Tom, > > > > My original posting was an excerpt from best practices for container > > pools, and does not necessarily apply to other storage pool types. > > > > Yes, client-side deduplication and compression options should be > > avoided with a Data Domain storage pool. > > > > A fixed resourceutilization setting of 2 may underperform for > > clients that have a lot of data to back up and fast network > > connections, but this is not a black and white answer. There are > > various other conditions that can affect this and trying to narrow > > in on them in > ADSM-L would be difficult. > > If you want some help with a performance issue, please open a PMR. > > > > > > Del > > > > ---------------------------------------------------- > > > > "ADSM: Dist Stor Manager" <[email protected]> wrote on 03/25/2017 > > 12:20:43 AM: > > > > > From: Tom Alverson <[email protected]> > > > To: [email protected] > > > Date: 03/25/2017 05:40 AM > > > Subject: Re: Best Practices/Best Performance SP/TSM B/A Client > > > Settings > > ? > > > Sent by: "ADSM: Dist Stor Manager" <[email protected]> > > > > > > Del: > > > > > > We have been using these settings as our defaults. Is our > > > TCPWINDOWSIZE too large? > > > > > > RESOURCEUTILIZATION 2 (we increase this up to 10 for some WAN > > > backups) TXNBYTELIMIT 2097152 TCPNODELAY YES TCPBUFFSIZE 512 > > > TCPWINDOWSIZE 2048 LARGECOMMBUFFERS YES > > > > > > Also we never use compression because our storage folks believe it > > > will foul up the de-duplication that happens on our Data Domains?? > > > > > > On Mon, Mar 20, 2017 at 9:11 PM, Del Hoobler <[email protected]> > wrote: > > > > > > > Hi Ben, > > > > > > > > Here are some items to get you started: > > > > > > > > > > > > Backup-Archive client with limited, high latency network (WAN > > backups): > > > > =============================== > > > > TCPWINDOWSIZE 512 > > > > RESOURCEUTILIZATION 4 > > > > COMPRESSION Yes > > > > DEDUPLICATION Yes > > > > ENABLEDEDUPCACHE Yes > > > > > > > > Tip: Do not use the client deduplication caching for > > > > applications > > that > > > > use the IBM Spectrum Protect API. Refer to section 1.2.3.2.1 > > > > for additional details. > > > > > > > > > > > > Backup/Archive client or Client API with limited network > > > > (Gigabit LAN > > > > backups): > > > > =============================== > > > > TCPWINDOWSIZE 512 > > > > RESOURCEUTILIZATION 10 > > > > COMPRESSION Yes > > > > DEDUPLICATION Yes > > > > ENABLEDEDUPCACHE No > > > > > > > > > > > > Backup/Archive client or Client API with high speed network (10 > > Gigabit + > > > > LAN backups) > > > > =============================== > > > > TCPWINDOWSIZE 512 > > > > RESOURCEUTILIZATION 10 > > > > COMPRESSION No > > > > DEDUPLICATION No > > > > ENABLEDEDUPCACHE No > > > > > > > > > > > > Tip: For optimal data reduction, avoid the following client > > > > option > > > > combination: > > > > > > > > COMPRESSION Yes > > > > DEDUPLICATION No > > > > > > > > > > > > > > > > > > > > Del > > > > > > > > ---------------------------------------------------- > > > > > > > > "ADSM: Dist Stor Manager" <[email protected]> wrote on > > > > 03/15/2017 > > > > 02:39:04 PM: > > > > > > > > > From: "Alford, Ben" <[email protected]> > > > > > To: [email protected] > > > > > Date: 03/15/2017 02:39 PM > > > > > Subject: Best Practices/Best Performance SP/TSM B/A Client > > > > > Settings > > ? > > > > > Sent by: "ADSM: Dist Stor Manager" <[email protected]> > > > > > > > > > > I've looked at the IBM Blueprint documents but may have missed > > > > > what I was looking for - the Best Practices for Best > > > > > Performance > for TSM > > > > > B/A client settings. As we move from 6.4 to 7.x or 8.x clients > > > > > before the 6.4 EOL, we are looking to test with the current > > > > > client settings optimized for things like TCPBUFFSIZE, > > > > > TCPWINDOWSIZE, TXNBYTLIMIT, etc., etc. > > > > > Thanks! > > > > > > > > > > Ben Alford > > > > > IT Manager, Office of Information Technology > > > > > Systems: Shared Services > > > > > > > > > > The University of Tennessee > > > > > > > > > > > > > > > This message and any attachment is confidential and may be privileged or otherwise protected from disclosure. You should immediately delete the message if you are not the intended recipient. If you have received this email by mistake please delete it from your system; you should not copy the message or disclose its content to anyone. This electronic communication may contain general financial product advice but should not be relied upon or construed as a recommendation of any financial product. The information has been prepared without taking into account your objectives, financial situation or needs. You should consider the Product Disclosure Statement relating to the financial product and consult your financial adviser before making a decision about whether to acquire, hold or dispose of a financial product. For further details on the financial product please go to http://www.bt.com.au Past performance is not a reliable indicator of future performance.
