Showing posts with label fail. Show all posts
Showing posts with label fail. Show all posts

Wednesday, March 21, 2012

servers Fail

I have a Windows 2000 active/passive cluster. I have configured 6 linked servers using OpenLink Database Proxy Client.

I have had to repeatedly cycle the cluster (stop/restart SQL services) because the linked servers "fail". By failing, I mean that the linked servers stop responding to user queries. The user query simply spins with no activity.

The linked servers are configured in the following manner:
1. I configure a DSN using the OpenLink client
2. I configure SQL Server linked server to point to the DSN

Each node in the cluster has identical DSN entries (same name, same driver, same settings). We have tested failing the cluster from Node 1 to Node 2 and back again. We have tested the failover process with queries actively running (they fail). We are always able to reconnect and resume normal processing after the backup node recovers the SQL server.

The linked server failures don't appear to have any real pattern to them. There seems to be a weak correlation between a failover and failure in the linked servers (the linked servers fail 1 - 2 days later).

This is not making any sense to me at all. I am NOT a fan of linked servers, but I have no choice here: I inherited these and the developers are NOT interested in alternative solutions.

If you have any thoughts on the matter, please drop a line.

Regards,

hmscott

Additonal info:
Windows 2000 SP4
SQL 2000 SP3 (hotfix 0818)
MDAC 2.7 SP1
OpenLink MultiTier 5.1Contacted MS PSS for answer. Did a stack dump and traced error to a modal messagebox that the client provider raised (!!!).

Back to the provider.

Was not related to cluster server, but it sure "felt" that way. Learned some great things about stack dumps and such.

Regards,

hmscott

servers Fail

I have a Windows 2000 active/passive cluster. I have
configured 6 linked servers using OpenLink Database Proxy
Client. See below for steps I took to create linked
server entries.
In two months of testing, I have had to cycle the SQL
cluster (stop/restart SQL services) three or four times
because the linked servers "fail". By failing, I mean that
the linked servers stop responding to user queries. The
user query simply spins with no activity. I have isolated
the failure to the interaction between SQL and the DSN
entry (ie, the DB proxy works, the DSN works, but SELECT *
FROM OPENQUERY(MyLink, 'SELECT * FROM db2Table.db2Column')
does not work).
The linked servers are configured in the following manner:
1. I configure a DSN using the OpenLink client
(www.openlinksw.com)
2. I configure SQL Server linked server to point to the DSN
Each node in the cluster has identical DSN entries (same
name, same driver, same settings). We have tested failing
the cluster from Node 1 to Node 2 and back again. We have
tested the failover process with queries actively running
(they fail). We are always able to reconnect and resume
normal processing after the backup node recovers the SQL
server.
The linked server failures don't appear to have any real
pattern to them. There seems to be a weak correlation
between a failover and failure in the linked servers (the
linked servers fail 1 - 2 days later).
This is not making any sense to me at all. I am NOT a fan
of linked servers, but I have no choice here: I inherited
these and the developers are NOT interested in alternative
solutions.
If you have any thoughts on the matter, please drop a line.
Regards,
hmscott
Additonal info:
Windows 2000 SP4
SQL 2000 SP3 (hotfix 0818)
MDAC 2.7 SP1
OpenLink MultiTier 5.1Contact MS PSS for answer. Did a stack dump and traced
error to a modal messagebox that the client provider
raised (!!!).
Back to the provider.
Regards,
hmscott
>--Original Message--
>I have a Windows 2000 active/passive cluster. I have
>configured 6 linked servers using OpenLink Database Proxy
>Client. See below for steps I took to create linked
>server entries.
>In two months of testing, I have had to cycle the SQL
>cluster (stop/restart SQL services) three or four times
>because the linked servers "fail". By failing, I mean
that
>the linked servers stop responding to user queries. The
>user query simply spins with no activity. I have
isolated
>the failure to the interaction between SQL and the DSN
>entry (ie, the DB proxy works, the DSN works, but SELECT
*
>FROM OPENQUERY(MyLink, 'SELECT * FROM
db2Table.db2Column')
>does not work).
>The linked servers are configured in the following manner:
>1. I configure a DSN using the OpenLink client
>(www.openlinksw.com)
>2. I configure SQL Server linked server to point to the
DSN
>Each node in the cluster has identical DSN entries (same
>name, same driver, same settings). We have tested failing
>the cluster from Node 1 to Node 2 and back again. We have
>tested the failover process with queries actively running
>(they fail). We are always able to reconnect and resume
>normal processing after the backup node recovers the SQL
>server.
>The linked server failures don't appear to have any real
>pattern to them. There seems to be a weak correlation
>between a failover and failure in the linked servers (the
>linked servers fail 1 - 2 days later).
>This is not making any sense to me at all. I am NOT a fan
>of linked servers, but I have no choice here: I inherited
>these and the developers are NOT interested in
alternative
>solutions.
>If you have any thoughts on the matter, please drop a
line.
>Regards,
>hmscott
>Additonal info:
>Windows 2000 SP4
>SQL 2000 SP3 (hotfix 0818)
>MDAC 2.7 SP1
>OpenLink MultiTier 5.1
>.
>

Wednesday, March 7, 2012

server to UDB

I'm trying to set up a linked server from sql server 2000 to udb 8.1.14. My selects to the UDB table work fine. Inserts/updates deletes fail. The insert returns - OLE DB error trace [OLE/DB Provider 'IBMDADB2' IRowsetChange::InsertRow returned 0x80040e53: The provider does not support the necessary method.]. Here's the insert format - INSERT OPENQUERY(TESTUDB3, 'SELECT * FROM TEST.T1') VALUES( '1','1','1','1','1'). Is this the correct format? Does the IBM provider allows updates?What happens when you try

insert into TESTUDB3.TEST.T1
VALUES ( '1','1','1','1','1')|||Same error.