TDP SQL MS Failover Cluster Config Backup Scripts

2014-02-12 Thread Faisal Khan
Hello TSMers,

I need to setup a TDP-SQL client configuration for a 2 node MS failover
cluster on Windows 2008 R2 / SQL 2008 R2 Server. I would appreciate it, if
you could help me with the tested config files and SQL backup scripts(Full,
Differential, Log) alongwith non-zero return code exit.

Thank You.

Kind Regards,
Faisal Khan


Re: upgrade V6.3.4.0 to V7.1.0.0 on Windows ended not well :(

2014-02-12 Thread Karel Bos
Hi,

After expanding the C: drive to 20GB of free space the upgrade DB proces
completed succesfully. Clearly the free space check is not working properly
(when using mounted disks on windows).

All in all, 7.1 is running now.

Kind regards,

Karel


2014-02-12 0:35 GMT+01:00 Saravanan evergreen.sa...@gmail.com:

 Hi Karel,

 I think you need to keep your active log size as multiples of 8 so that it
 can create enough 512 mb files in the active log directory.

 16384/512=32 active log files

 In your case : 19000/512=37.10 active log files


 By Sarav
 +65-82284384


  On 11 Feb, 2014, at 10:34 pm, Karel Bos tsm@gmail.com wrote:
 
  Hi Zoltan,
 
  activelogsize   19000
 
  And there was abt 20GB free space in the active log disk.
 
  Kind regards,
 
  Karel
 
 
  2014-02-11 14:52 GMT+01:00 Zoltan Forray zfor...@vcu.edu:
 
  What is your ACTIVELOGSIZE set to?  Maybe it is enforcing that limit,
 not
  the available free space?
 
 
  On Tue, Feb 11, 2014 at 8:44 AM, Karel Bos tsm@gmail.com wrote:
 
  Hi,
 
  I upgraded my windows TSM Test server from V6.3.4.0 to V7.1.0.0 and it
  didn't end well.
 
  Software install went ok. Both DB2 and TSM where upgraded but the
 upgrade
  db part ended with
 
  SQL1762N  Unable to connect to database because there is not enough
 space
  to allocate active log files.  SQLSTATE=08004
 
  Bit strange because the active log drive had almost 20 GB of free
 space.
  Also any other drive connected to this system had more than 5 GB of
 free
  space.
 
  Looking in the DB2diag log I see this message:
 
  MESSAGE : ZRC=0x85100084=-2062548860=SQLP_NO_SPACE_FOR_LOG
   Not enough space to create primary logs
  DATA #1 : String, 59 bytes
  Log path / Free space (bytes) / Log space required (bytes):
  DATA #2 : String, 43 bytes
  C:\tsm\actlog\vol12\NODE\LOGSTREAM\
  DATA #3 : unsigned integer, 8 bytes
  10466885632
  DATA #4 : unsigned integer, 8 bytes
  17180131328
 
  If I calculate #3 its the amount of free space on C:, but not the
 amount
  on
  c:\tsm\actlog (which is a mounted disk!).
 
  Trying to relocate the log to another lun just end up with the same
  error.
  Any ideas? If its because of free space calculation going wrong because
  of
  mounted disk, we have a challenge. All our TSM servers running on
  windows
  use mounted disks instead of drive letters
 
  I also have a ticket open with IBM support about this, but until now
 the
  support engineer is still thinking an upgrade is the same as a fresh
  install and running the install wizzard a 2nd time is a good idea
 
  All in all, not a great start with TSM V7.1.
 
  Kind regards,
 
  Karel
 
 
 
  --
  *Zoltan Forray*
  TSM Software  Hardware Administrator
  Virginia Commonwealth University
  UCC/Office of Technology Services
  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
 



TDP for SQL 6.4.1 cross-server restore setup

2014-02-12 Thread Schaub, Steve
Windows 2012, TSM  TDP 6.4.1

Our DBA's do a fair amount of cross-server restores here.  Since I cant depend 
on them editing the dsm.opt file (tried that before, ended up with a bunch of 
backups in the wrong place because they forgot to change it back), I came up 
with a little pre-launch script that allows them to pick a SQL node from our 
inventory to restore from, then builds a temp opt file using that node name, 
and launches the tdp gui using that opt file.

However, now that 6.4.1 has killed off the tdp gui in favor of the mmc, I 
haven't been able to figure out how to achieve the same results.  Can someone 
tell me how to launch the mmc using an alternate opt file?

Thanks,

Steve Schaub
System Engineer II, Backup/Recovery
Blue Cross Blue Shield of Tennessee

-
Please see the following link for the BlueCross BlueShield of Tennessee E-mail 
disclaimer:  http://www.bcbst.com/email_disclaimer.shtm


Re: TDP for SQL 6.4.1 cross-server restore setup

2014-02-12 Thread Del Hoobler
Hi Steve,

See if this helps:

http://www-01.ibm.com/support/docview.wss?uid=swg21597023

BTW... this is a known requirement. There are plans to add
this function directly to the launch of the MMC soon.


Thank you,

Del




ADSM: Dist Stor Manager ADSM-L@vm.marist.edu wrote on 02/12/2014
11:46:58 AM:

 From: Schaub, Steve steve_sch...@bcbst.com
 To: ADSM-L@vm.marist.edu,
 Date: 02/12/2014 12:36 PM
 Subject: TDP for SQL 6.4.1 cross-server restore setup
 Sent by: ADSM: Dist Stor Manager ADSM-L@vm.marist.edu

 Windows 2012, TSM  TDP 6.4.1

 Our DBA's do a fair amount of cross-server restores here.  Since I
 cant depend on them editing the dsm.opt file (tried that before,
 ended up with a bunch of backups in the wrong place because they
 forgot to change it back), I came up with a little pre-launch script
 that allows them to pick a SQL node from our inventory to restore
 from, then builds a temp opt file using that node name, and launches
 the tdp gui using that opt file.

 However, now that 6.4.1 has killed off the tdp gui in favor of the
 mmc, I haven't been able to figure out how to achieve the same
 results.  Can someone tell me how to launch the mmc using an
 alternate opt file?



Re: Exchange 2010 backup performance

2014-02-12 Thread Dave Canan
Wanda, did your test show anything? Let me know if you have any questions.

Dave Canan
TSM Performance 
ddca...@us.ibm.com

-Original Message-
From: Prather, Wanda wanda.prat...@icfi.com
Sent: ‎2/‎10/‎2014 10:19 AM
To: ADSM-L@VM.MARIST.EDU ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Exchange 2010 backup performance

Woot, that's cool to know!
Thanks Dave.
I will run a test tonight and look for a spike.

Is RSS something that is enabled in the NIC or in Windows? 
 I know the network guys already had to do some tweaking of the 10G TOE card.

Wanda


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Dave 
Canan
Sent: Monday, February 10, 2014 1:07 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Exchange 2010 backup performance

Wanda, one other thing I would like to point out. With the TSM Server being on 
Windows, one other thing to consider is RSS (Receive Side Scaling). All the 
processing of IP packets happens on 1 core of the server, and this can be a 
potential bottleneck. One way to determine this is to watch the TSM server when 
the Exchange Backup occurs. Is there a CPU spike on 1 core? Not only can you 
enable RSS to spread the packet processing out amongst more cores, but you can 
specify how many cores and which core numbers to start with. If a perfmon run 
is done against the Windows Server, it is easy to see if one particular core is 
doing more worth than the others, and this can be a symptom that RSS may 
provide a benefit.


Dave Canan
TSM Performance
ddca...@us.ibm.com



On Mon, Feb 10, 2014 at 8:16 AM, Prather, Wanda wanda.prat...@icfi.comwrote:

 Thank you - forgot to mention this is a Windows TSM server.
 I am curious that the drive is the bottleneck - a big file of zeros 
 should compress, and give you  200MB/sec on LTO5, yes?


 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf 
 Of Hans Christian Riksheim
 Sent: Monday, February 10, 2014 9:04 AM
 To: ADSM-L@VM.MARIST.EDU
 Subject: Re: [ADSM-L] Exchange 2010 backup performance

 In my experience there is nothing wrong with the TCP stack in Windows.
 Especially Windows2008R2 performs very well. For a single stream from 
 a
 2008R2 client (dsm sel big file of zeroes) to an AIX TSM-server 
 500km away over 10Gig directly to LTO5 has a speed of around 200MB/ at our 
 setup.
 Bottleneck being the drive.

 After too much experimenting I have found the critical factor to be to 
 set TCPWINDOWSIZE 0 at both dsm.opt and dsmserv.opt and increase the 
 tcp-sizes in AIX(and override the tcp-settings on the NIC). Windows OS 
 can be left alone as its default is quite OK. YMMV of course.

 Regards,

 Hans Chr.


 On Mon, Feb 10, 2014 at 1:57 PM, Schaub, Steve steve_sch...@bcbst.com
 wrote:

  Wanda,
 
  I have fought with this problem myself, and here is what I concluded 
  (at least in our environment, YMMV):
 
  1. Running single-stream backups (one db at a time) you will never 
  see the performance you expect, due to the Windows O/S tcpip stack.  
  I haven't had a chance to stress-test Win2012-R2 yet, but at least 
  through 2008-R2, there seems to be a single-thread constraint that 
  prevents any backup from getting much more than about 20% of the
 bandwidth.
 
  2. The only way to get around this is to do as Del suggests and 
  parallelize your backups.  If you can get 4-6 concurrent jobs 
  running, you can push the network card pretty close to 100%.  The 
  catch, as Dell also pointed out, is that you can't run concurrent 
  backups on databases that live on the same disk (since the vss snap 
  is at the disk
 level).
 
  Bottom line is that you would need to divide up your Exchange 
  databases so they are on different disks (or at least, create as 
  many disks as you want to have concurrent backups, then create 
  separate jobs
 to backup each group).
 
  Good luck,
 
  Steve Schaub
  System Engineer II, Backup/Recovery
  Blue Cross Blue Shield of Tennessee
 
 
  -Original Message-
  From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On 
  Behalf Of Prather, Wanda
  Sent: Sunday, February 09, 2014 1:08 PM
  To: ADSM-L@VM.MARIST.EDU
  Subject: Re: [ADSM-L] Exchange 2010 backup performance
 
  Del, you are a national treasure!
  You are very kind to take time to respond.
 
  My backups are already very well balanced, I have 2 servers, the 
  DBA's have the DBs split between them so well that they backup 
  almost the same amount of data, and finish within 30 minutes of each other.
   (3.7 TB each, takes 10 hours on a 10G network, direct to LTO5 tape, 
  with /SKIPINTEGRITYCHECK specified.  Exchange DBs coming from V7000 
  disk so should be spiffy speed there.).
 
  I tried setting resourceutilization 10 once before, was an 
  impressive failure.  The backup appeared to be looping doing VSS 
  snaps (or rather failing to); I think it was doing as you mentioned 
  in 2 below, trying to snap the same LUN multiple 

Re: Exchange 2010 backup performance

2014-02-12 Thread Schaub, Steve
Hans,
What tcp-sizes are you using in AIX and on the nic?  When you ran that test on 
the file of zeros, you had client compression turned off, right?  I would love 
to get 200MB single-thread throughput from my clients.
Thanks,
-steve

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Hans 
Christian Riksheim
Sent: Monday, February 10, 2014 9:04 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Exchange 2010 backup performance

In my experience there is nothing wrong with the TCP stack in Windows.
Especially Windows2008R2 performs very well. For a single stream from a
2008R2 client (dsm sel big file of zeroes) to an AIX TSM-server 500km away 
over 10Gig directly to LTO5 has a speed of around 200MB/ at our setup.
Bottleneck being the drive.

After too much experimenting I have found the critical factor to be to set 
TCPWINDOWSIZE 0 at both dsm.opt and dsmserv.opt and increase the tcp-sizes in 
AIX(and override the tcp-settings on the NIC). Windows OS can be left alone as 
its default is quite OK. YMMV of course.

Regards,

Hans Chr.


On Mon, Feb 10, 2014 at 1:57 PM, Schaub, Steve steve_sch...@bcbst.comwrote:

 Wanda,

 I have fought with this problem myself, and here is what I concluded 
 (at least in our environment, YMMV):

 1. Running single-stream backups (one db at a time) you will never see 
 the performance you expect, due to the Windows O/S tcpip stack.  I 
 haven't had a chance to stress-test Win2012-R2 yet, but at least 
 through 2008-R2, there seems to be a single-thread constraint that 
 prevents any backup from getting much more than about 20% of the bandwidth.

 2. The only way to get around this is to do as Del suggests and 
 parallelize your backups.  If you can get 4-6 concurrent jobs running, 
 you can push the network card pretty close to 100%.  The catch, as 
 Dell also pointed out, is that you can't run concurrent backups on 
 databases that live on the same disk (since the vss snap is at the disk 
 level).

 Bottom line is that you would need to divide up your Exchange 
 databases so they are on different disks (or at least, create as many 
 disks as you want to have concurrent backups, then create separate jobs to 
 backup each group).

 Good luck,

 Steve Schaub
 System Engineer II, Backup/Recovery
 Blue Cross Blue Shield of Tennessee


 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf 
 Of Prather, Wanda
 Sent: Sunday, February 09, 2014 1:08 PM
 To: ADSM-L@VM.MARIST.EDU
 Subject: Re: [ADSM-L] Exchange 2010 backup performance

 Del, you are a national treasure!
 You are very kind to take time to respond.

 My backups are already very well balanced, I have 2 servers, the DBA's 
 have the DBs split between them so well that they backup almost the 
 same amount of data, and finish within 30 minutes of each other.
  (3.7 TB each, takes 10 hours on a 10G network, direct to LTO5 tape, 
 with /SKIPINTEGRITYCHECK specified.  Exchange DBs coming from V7000 
 disk so should be spiffy speed there.).

 I tried setting resourceutilization 10 once before, was an impressive 
 failure.  The backup appeared to be looping doing VSS snaps (or rather 
 failing to); I think it was doing as you mentioned in 2 below, trying 
 to snap the same LUN multiple times.

 Will go through the references you included, then open a performance 
 PMR if no improvement.

 Thank you so much!

 W

 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf 
 Of Del Hoobler
 Sent: Friday, February 07, 2014 6:48 PM
 To: ADSM-L@VM.MARIST.EDU
 Subject: Re: [ADSM-L] Exchange 2010 backup performance

 Hi Wanda,

 I have a few ideas for you...

 --

 Are you running in a DAG environment? If so, you could do some load 
 balancing between DAG Servers:

 Most of this in the Exchange book under Managing Exchange Database 
 Availability Group members by using a single policy:



 http://pic.dhe.ibm.com/infocenter/tsminfo/v6r4/index.jsp?topic=%2Fcom.
 ibm.itsm.mail.exc.doc%2Ft_dpfcm_bup_reduce_redundant_exc.html

 The key to load balance when setting up the scheduled backup script 
 is to have a separate invocation of each database. For example:

 TDPEXCC BACKUP DB1 FULL /MINIMUMBACKUPINTERVAL=720 /PREFERDAGPASSIVE 
 TDPEXCC BACKUP DB2 FULL /MINIMUMBACKUPINTERVAL=720 /PREFERDAGPASSIVE 
 TDPEXCC BACKUP DB3 FULL /MINIMUMBACKUPINTERVAL=720 /PREFERDAGPASSIVE 
 TDPEXCC BACKUP DB4 FULL /MINIMUMBACKUPINTERVAL=720 /PREFERDAGPASSIVE 
 TDPEXCC BACKUP DB5 FULL /MINIMUMBACKUPINTERVAL=720 /PREFERDAGPASSIVE

 Then, run this command from each of the Exchange servers at or about 
 the same time.

 --

 Here are a few more things to look at:

 To help with some performance issues, some customers have split their 
 backups into multiple threads or processes in two ways:

 1. Increase the value of the RESOURCEUTILIZATION parameter in the
DSM.OPT file for the 

Re: Exchange 2010 backup performance

2014-02-12 Thread Ryder, Michael S
I'd like to second the comments by Hans --

Windows servers can perform well -- assuming the infrastructure is there to
support it.

Our TSM server is running 6.2 on a 64-bit Windows 2003 Server.  One 1Gb
ethernet nic.
Our datamover/proxy is running 6.3 client on a Windows 2008 R2 (64-bit)
Server.  One 1Gb ethernet nic.

We are regularly able to stream image backups at 500Mbps (that's
megabits-per-second, just to be clear), reading from 4Gb fibre-channel and
dumping across a dedicated LAN connection to the TSM server.  Sometimes
sending for 15-30 seconds at 700-750Mbps, topping out at around 815Mbps.  I
can run two proxies simultaneously streaming, and the TSM server will be
receiving data from multiple image backups at a sustained rate of
~700-750Mbps.

Incremental, file-level backups are another story... searching 6 Million
files in 4TB and backing up 50GB can take ~2 hours.

I would love to see what I can do with 10Gb ethernet, but we're not there
yet...

Mike

On Wed, Feb 12, 2014 at 2:13 PM, Schaub, Steve steve_sch...@bcbst.comwrote:

 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
 Hans Christian Riksheim
 Sent: Monday, February 10, 2014 9:04 AM
 To: ADSM-L@VM.MARIST.EDU
 Subject: Re: [ADSM-L] Exchange 2010 backup performance

 In my experience there is nothing wrong with the TCP stack in Windows.
 Especially Windows2008R2 performs very well. For a single stream from a
 2008R2 client (dsm sel big file of zeroes) to an AIX TSM-server 500km
 away over 10Gig directly to LTO5 has a speed of around 200MB/ at our setup.
 Bottleneck being the drive.

 After too much experimenting I have found the critical factor to be to set
 TCPWINDOWSIZE 0 at both dsm.opt and dsmserv.opt and increase the tcp-sizes
 in AIX(and override the tcp-settings on the NIC). Windows OS can be left
 alone as its default is quite OK. YMMV of course.

 Regards,

 Hans Chr.




Best regards,

Mike
RMD IT, x7942


Re: Exchange 2010 backup performance

2014-02-12 Thread Hans Christian Riksheim
Hi,

I have set send/recv-space at 16MB globally with no and use_isno=0 to
override the NICs.  Most important is to set TCPWINODWSIZE=0 on the client
and TSM server and then just let the OS handle it. I had to experiment with
these settings for weeks as we have clients 500km away with high latency(9
ms ping) but with very good throughput(10 Gb fibre.)

As always YMMV, network tuning is a mess and I may have just been lucky.

Yes, client compression was off.

Regards,

Hans Chr.


On Wed, Feb 12, 2014 at 8:13 PM, Schaub, Steve steve_sch...@bcbst.comwrote:

 Hans,
 What tcp-sizes are you using in AIX and on the nic?  When you ran that
 test on the file of zeros, you had client compression turned off, right?  I
 would love to get 200MB single-thread throughput from my clients.
 Thanks,
 -steve

 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
 Hans Christian Riksheim
 Sent: Monday, February 10, 2014 9:04 AM
 To: ADSM-L@VM.MARIST.EDU
 Subject: Re: [ADSM-L] Exchange 2010 backup performance

 In my experience there is nothing wrong with the TCP stack in Windows.
 Especially Windows2008R2 performs very well. For a single stream from a
 2008R2 client (dsm sel big file of zeroes) to an AIX TSM-server 500km
 away over 10Gig directly to LTO5 has a speed of around 200MB/ at our setup.
 Bottleneck being the drive.

 After too much experimenting I have found the critical factor to be to set
 TCPWINDOWSIZE 0 at both dsm.opt and dsmserv.opt and increase the tcp-sizes
 in AIX(and override the tcp-settings on the NIC). Windows OS can be left
 alone as its default is quite OK. YMMV of course.

 Regards,

 Hans Chr.


 On Mon, Feb 10, 2014 at 1:57 PM, Schaub, Steve steve_sch...@bcbst.com
 wrote:

  Wanda,
 
  I have fought with this problem myself, and here is what I concluded
  (at least in our environment, YMMV):
 
  1. Running single-stream backups (one db at a time) you will never see
  the performance you expect, due to the Windows O/S tcpip stack.  I
  haven't had a chance to stress-test Win2012-R2 yet, but at least
  through 2008-R2, there seems to be a single-thread constraint that
  prevents any backup from getting much more than about 20% of the
 bandwidth.
 
  2. The only way to get around this is to do as Del suggests and
  parallelize your backups.  If you can get 4-6 concurrent jobs running,
  you can push the network card pretty close to 100%.  The catch, as
  Dell also pointed out, is that you can't run concurrent backups on
  databases that live on the same disk (since the vss snap is at the disk
 level).
 
  Bottom line is that you would need to divide up your Exchange
  databases so they are on different disks (or at least, create as many
  disks as you want to have concurrent backups, then create separate jobs
 to backup each group).
 
  Good luck,
 
  Steve Schaub
  System Engineer II, Backup/Recovery
  Blue Cross Blue Shield of Tennessee
 
 
  -Original Message-
  From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf
  Of Prather, Wanda
  Sent: Sunday, February 09, 2014 1:08 PM
  To: ADSM-L@VM.MARIST.EDU
  Subject: Re: [ADSM-L] Exchange 2010 backup performance
 
  Del, you are a national treasure!
  You are very kind to take time to respond.
 
  My backups are already very well balanced, I have 2 servers, the DBA's
  have the DBs split between them so well that they backup almost the
  same amount of data, and finish within 30 minutes of each other.
   (3.7 TB each, takes 10 hours on a 10G network, direct to LTO5 tape,
  with /SKIPINTEGRITYCHECK specified.  Exchange DBs coming from V7000
  disk so should be spiffy speed there.).
 
  I tried setting resourceutilization 10 once before, was an impressive
  failure.  The backup appeared to be looping doing VSS snaps (or rather
  failing to); I think it was doing as you mentioned in 2 below, trying
  to snap the same LUN multiple times.
 
  Will go through the references you included, then open a performance
  PMR if no improvement.
 
  Thank you so much!
 
  W
 
  -Original Message-
  From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf
  Of Del Hoobler
  Sent: Friday, February 07, 2014 6:48 PM
  To: ADSM-L@VM.MARIST.EDU
  Subject: Re: [ADSM-L] Exchange 2010 backup performance
 
  Hi Wanda,
 
  I have a few ideas for you...
 
  --
 
  Are you running in a DAG environment? If so, you could do some load
  balancing between DAG Servers:
 
  Most of this in the Exchange book under Managing Exchange Database
  Availability Group members by using a single policy:
 
 
 
  http://pic.dhe.ibm.com/infocenter/tsminfo/v6r4/index.jsp?topic=%2Fcom.
  ibm.itsm.mail.exc.doc%2Ft_dpfcm_bup_reduce_redundant_exc.html
 
  The key to load balance when setting up the scheduled backup script
  is to have a separate invocation of each database. For example:
 
  TDPEXCC BACKUP DB1 FULL /MINIMUMBACKUPINTERVAL=720 /PREFERDAGPASSIVE
  TDPEXCC BACKUP DB2 FULL