Installation problem with SQLServer metadata (XA not config)

A forum for discussing DataStage<sup>®</sup> basics. If you're not sure where your question goes, start here.

Moderators: chulett, rschirm, roy

Post Reply
rob2812
Participant
Posts: 4
Joined: Fri Apr 13, 2007 1:14 am
Location: Milan

Installation problem with SQLServer metadata (XA not config)

Post by rob2812 »

Hi all,
I'm finally installing in Production the IS 8.7 on a Win2008R2 box with metadata in Sql Server 2008. So far I didn't have any issues in lower environments with pretty much similar configuration.
Now, during the installation (silent or interactive) I get a "The SQL Server on xxxx was not configured for XA support.". We obviously followed the instructions for the configuration of DTC, JTA, XA etc as per lower environments.
Doing some cross check tests it seems that it is really the DB the one to look at.
The only difference in Production compared to DEV is that there is an underlining Windows cluster with two nodes; while in DEV there is only a DB Cluster. Btw, we configured DTC as well on the Nodes.

Error from the log is

Code: Select all

18-Feb-2013 15:47:36, SEVERE: com.ibm.is.install.check.SQLServerXASupportChecker
java.sql.SQLException: [IBM][SQLServer JDBC Driver][SQLServer]xa_open (0) returns -3
It's not clear what exactly is checking the installer and the log doesn't say much more to help on troubleshooting the problem.

Any help appreciated.

thx Roberto
wwilliamson
Participant
Posts: 21
Joined: Fri Oct 01, 2010 2:45 pm
Contact:

Same issue in 9.1 installation

Post by wwilliamson »

I'm having the same error while installing IIS 9.1 in our QA environment. There was no such issue with the installation in the dev environment. Both environments are using Windows Server 2008 Enterprise R2 (x64) as the host OS, and SQL Server 2008 Enterprise r2 (x64) as the metadata repository.

The installer produces the error when I click "next" on the page where the xmetasr info/credentials are to be entered. The prior page - specifying xmeta info/credentials - appears to function fine.

We've followed (and triple-checked) all of the prerequisite steps (x64-specific) from the below page of the installation process
http://pic.dhe.ibm.com/infocenter/iisin ... b_win.html

The QA server was "hardened" at the OS and application level so I'm trying to find out what exactly was done prior to the installation.
wwilliamson
Participant
Posts: 21
Joined: Fri Oct 01, 2010 2:45 pm
Contact:

Potential solution for XA transaction configuration error

Post by wwilliamson »

Our solution was taken from the following URL: http://pic.dhe.ibm.com/infocenter/wasin ... cess4.html

Per those instructions we created two dwords on each of our cluster hosts: a separate dword is required for sqljdbc.dll and sqljdbc_xa.dll. According to the explanation provided these values must be present for security purposes. I'm assuming that SQL Server will refuse to load the dlls if the keys aren't present.

Once the keys were created, we stopped all of the SQL Server engines in the cluster, restarted the DTC service, and started the engines again. It took a couple of tries to get the registry changes to apply.

edit 2013-02-26 14:18:37 - corrected the name of the xa dll
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

Thank you for posting that. I'm sure it will get someone out of that particular hole more quickly in future.
:)
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
rob2812
Participant
Posts: 4
Joined: Fri Apr 13, 2007 1:14 am
Location: Milan

Post by rob2812 »

Hi,
We finally solved the problem as well.

We added as well the registry keys (even if supposed to be only for Win Server 2003), but wasn't enough.
With Microsoft support we reconfigured DTC on each Virtual Cluster on the DB server and on each nodes of the underlining physical cluster.
Then we set the DTC in Virtual Cluster (where my DB instance was) as the main one and mapped it to the SQL Instance.

At the end, restarting the services (both DTC and SQL) wasn't enough and only after a full reboot of the box we had it working.
Roberto
Post Reply