TDP SQL errors backing up SQLSERVER Cluster on Windows2003

2004-07-31 Thread Leonard, Christopher
I am a SQL-Head (as Mark so elegantly put it), and one with more experience
than most.  The fact that the DBAs can do a backup from SQL Enterprise Manager
(or whatever) does *not* prove that this is not a SQL Server error.  It may,
sadly, give substantial evidence that they are stubborn or relatively
inexperienced DBAs if that's how they diagnose things.

I have seen this error pop up in different circumstances, and I urge you to
try the workaround that Del mentions below (which is the same as the one from
the MS KB article).  If this works, then it *is* most definitely a Microsoft
problem that can be resolved either by a Hotfix or by using the tcp:servername
syntax when registering or connecting to a SQL Server.

The first time I saw this error, my intuition told me it was probably not a
SQL thing, but note the word probably.  When I took the time to replicate
the connectivity environment of the client (which your SQL-Heads appear not to
have done), I saw the error, which led me to the KB.

We don't use SQL failover clusters at my current job (and I've only used
mostly DTC-bound clusters at other jobs) ... yet ... and this is the first job
I've had where we've used TDP for SQL Server.  Since we are likely to start
using failover clusters for SQL Server in the fairly near future, I'd really
appreciate it if you could post the resolution of this problem to the list.

Thanks,
Chris

_

Chris Leonard
MCSE, MCDBA, OCP, CIW
_

The Database Guy
http://www.databaseguy.com

Brainbench MVP for Oracle Admin
http://www.brainbench.com
_





| Date:Fri, 30 Jul 2004 16:45:03 -0400
| From:Del Hoobler [EMAIL PROTECTED]
| Subject: Re: TDP SQL errors backing up SQLSERVER Cluster on
| Windows2003
|
| Bill,
|
| Did you try this?
|
|tdpsqlc backup dbname full /sqlserver=tcp:server-name.abc.com
|
| for example:
|
|tdpsqlc backup master full /sqlserver=tcp:couples.endicott.ibm.com
|
| What happens?
|
| If you can't get it working, please ask that the PMR be
| forwarded to IBM Level 2 support. Level 2 can gather traces
| and work with Microsoft support to identify the problem.
|
| Thanks,
|
| Del
|


smime.p7s
Description: S/MIME cryptographic signature


TDP SQL errors backing up SQLSERVER Cluster on Windows2003

2004-07-30 Thread Bill Boyer
Windows2003 Cluster running SQL Server
TDP SQLServer 5.1.5.0
TSM Client 5.2.2.10
TSM Server on Windows2003 5.2.2.5


We were doing TDP backups of the SQLDatabases just fine, until the cluster
was re-addressed for IP. Now when the TDP backup runs, right at the end it
fails with a DBNETLIB error. It's looking like Microsoft #827452, but it was
working. What could have changed, or not changed, when the IP addresses were
changed? The Ipaddress of both cluster nodes as well as the cluster IP
resource were changed. TSM PROMPTED scheduling works, the B/A backups of the
C: drives on each node work, but the TDP backups fail.

I opened a PMR and they just pointed us to the Microsoft problem.

Anyone having problems or have some suggestions???

Bill Boyer
An Optimist is just a pessimist with no job experience.  - Scott Adams


Re: TDP SQL errors backing up SQLSERVER Cluster on Windows2003

2004-07-30 Thread Del Hoobler
Bill,

All I can say is that Microsoft found a problem
in MDAC that they had to fix. Every time we have seen the
[DBNETLIB]ConnectionRead (WrapperRead()) error
when backing up with Data Protection for SQL,
it has turned out to be KB827452. I think I remember
something about registry entries being invalid...
or something like that. Microsoft should be able
to tell you more details on what they fixed.
Here is the link to the KB article:

   http://support.microsoft.com/default.aspx?scid=kb;EN-US;827452

Thanks,

Del



ADSM: Dist Stor Manager [EMAIL PROTECTED] wrote on 07/30/2004
02:15:50 PM:

 Windows2003 Cluster running SQL Server
 TDP SQLServer 5.1.5.0
 TSM Client 5.2.2.10
 TSM Server on Windows2003 5.2.2.5


 We were doing TDP backups of the SQLDatabases just fine, until the
cluster
 was re-addressed for IP. Now when the TDP backup runs, right at the end
it
 fails with a DBNETLIB error. It's looking like Microsoft #827452, but it
was
 working. What could have changed, or not changed, when the IP addresses
were
 changed? The Ipaddress of both cluster nodes as well as the cluster IP
 resource were changed. TSM PROMPTED scheduling works, the B/A backups of
the
 C: drives on each node work, but the TDP backups fail.

 I opened a PMR and they just pointed us to the Microsoft problem.

 Anyone having problems or have some suggestions???

 Bill Boyer
 An Optimist is just a pessimist with no job experience.  - Scott Adams


Re: TDP SQL errors backing up SQLSERVER Cluster on Windows2003

2004-07-30 Thread Bill Boyer
Doing some more research on Microsoft and talking with the client, they
re-addressed the cluster on 7/26 when they moved it into their new CISCO
switch with VLAN's configured. I think they changed all the IP addresses
except for the IP address of the SQL Server virtual instance. I found a
couple articles on Microsoft about TCP not binding to the correct port after
an IP change to the cluster. I forwarded those articles to the client, but I
don't know if this is the problem either. The TDP backups worked before the
IP address change, so I'm hopeful!

This box is going production in a week and the backups dont' work now! Even
though it's a SQL error that is being returned, the DBA's point to TSM. So
it's up to me to fix it.

This is the KB article that level-2 referred to in my PMR. The DBA says
that's not the problem. They are using TCP, not named-pipes. The DBA says he
can back up the database via SQL Server manager, so it's not a SQL problem!

Bill Boyer
DSS, Inc.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
Del Hoobler
Sent: Friday, July 30, 2004 4:08 PM
To: [EMAIL PROTECTED]
Subject: Re: TDP SQL errors backing up SQLSERVER Cluster on Windows2003


Bill,

All I can say is that Microsoft found a problem
in MDAC that they had to fix. Every time we have seen the
[DBNETLIB]ConnectionRead (WrapperRead()) error
when backing up with Data Protection for SQL,
it has turned out to be KB827452. I think I remember
something about registry entries being invalid...
or something like that. Microsoft should be able
to tell you more details on what they fixed.
Here is the link to the KB article:

   http://support.microsoft.com/default.aspx?scid=kb;EN-US;827452

Thanks,

Del



ADSM: Dist Stor Manager [EMAIL PROTECTED] wrote on 07/30/2004
02:15:50 PM:

 Windows2003 Cluster running SQL Server
 TDP SQLServer 5.1.5.0
 TSM Client 5.2.2.10
 TSM Server on Windows2003 5.2.2.5


 We were doing TDP backups of the SQLDatabases just fine, until the
cluster
 was re-addressed for IP. Now when the TDP backup runs, right at the end
it
 fails with a DBNETLIB error. It's looking like Microsoft #827452, but it
was
 working. What could have changed, or not changed, when the IP addresses
were
 changed? The Ipaddress of both cluster nodes as well as the cluster IP
 resource were changed. TSM PROMPTED scheduling works, the B/A backups of
the
 C: drives on each node work, but the TDP backups fail.

 I opened a PMR and they just pointed us to the Microsoft problem.

 Anyone having problems or have some suggestions???

 Bill Boyer
 An Optimist is just a pessimist with no job experience.  - Scott Adams


Re: TDP SQL errors backing up SQLSERVER Cluster on Windows2003

2004-07-30 Thread Del Hoobler
Bill,

Did you try this?

   tdpsqlc backup dbname full /sqlserver=tcp:server-name.abc.com

for example:

   tdpsqlc backup master full /sqlserver=tcp:couples.endicott.ibm.com

What happens?

If you can't get it working, please ask that the PMR be forwarded
to IBM Level 2 support. Level 2 can gather traces and work
with Microsoft support to identify the problem.

Thanks,

Del



ADSM: Dist Stor Manager [EMAIL PROTECTED] wrote on 07/30/2004
04:19:31 PM:

 Doing some more research on Microsoft and talking with the client, they
 re-addressed the cluster on 7/26 when they moved it into their new CISCO
 switch with VLAN's configured. I think they changed all the IP addresses
 except for the IP address of the SQL Server virtual instance. I found a
 couple articles on Microsoft about TCP not binding to the correct port
after
 an IP change to the cluster. I forwarded those articles to the client,
but I
 don't know if this is the problem either. The TDP backups worked before
the
 IP address change, so I'm hopeful!

 This box is going production in a week and the backups dont' work now!
Even
 though it's a SQL error that is being returned, the DBA's point to TSM.
So
 it's up to me to fix it.

 This is the KB article that level-2 referred to in my PMR. The DBA says
 that's not the problem. They are using TCP, not named-pipes. The DBA
says he
 can back up the database via SQL Server manager, so it's not a SQL
problem!

 Bill Boyer
 DSS, Inc.


Re: TDP SQL errors backing up SQLSERVER Cluster on Windows2003

2004-07-30 Thread Stapleton, Mark
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On 
Behalf Of Bill Boyer
This box is going production in a week and the backups dont' 
work now! Even
though it's a SQL error that is being returned, the DBA's 
point to TSM. So it's up to me to fix it.

This is the default behavior of application owners. It's not my fault!

This is the KB article that level-2 referred to in my PMR. The DBA says
that's not the problem. They are using TCP, not named-pipes. 
The DBA says he can back up the database via SQL Server manager, so 
it's not a SQL problem!

I've read somewhere (can't remember where, but it wasn't from Microsoft)
that the best practice when you want to change static addresses for a MS
cluster is to backup the data, blow away and rebuild Windows and the
app(s), and restore the data. Changing the IP address at the NIC level
leaves not-so-easily-found registry entries unchanged.

One suggestion (FWIW) is to determine what the virtual interface's
address was prior to the address change, and look for that address with
regedit. I don't know whether you should manually change that registry
entry, but you can at least show the SQL-heads that something didn't get
updated correctly.

--
Mark Stapleton