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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Matthew McGeary
Sent: Tuesday, 28 March 2017 8:29 AM
To: ADSM-L AT VM.MARIST DOT EDU
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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Tom Alverson
Sent: Monday, March 27, 2017 2:17 PM
To: ADSM-L AT VM.MARIST DOT EDU
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 < Matthew.McGeary AT
potashcorp DOT com> 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:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Tom Alverson
> Sent: Monday, March 27, 2017 1:11 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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 <hoobler AT us.ibm DOT com>
> 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" <ADSM-L AT VM.MARIST DOT EDU> wrote on 03/25/2017
> > 12:20:43 AM:
> >
> > > From: Tom Alverson <tom.alverson AT GMAIL DOT COM>
> > > To: ADSM-L AT VM.MARIST DOT EDU
> > > 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" <ADSM-L AT VM.MARIST DOT EDU>
> > >
> > > 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 <hoobler AT us.ibm DOT com>
> 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" <ADSM-L AT VM.MARIST DOT EDU> wrote on
> > > > 03/15/2017
> > > > 02:39:04 PM:
> > > >
> > > > > From: "Alford, Ben" <balford AT UTK DOT EDU>
> > > > > To: ADSM-L AT VM.MARIST DOT EDU
> > > > > Date: 03/15/2017 02:39 PM
> > > > > Subject: Best Practices/Best Performance SP/TSM B/A Client
> > > > > Settings
> > ?
> > > > > Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> > > > >
> > > > > 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.
|
