2009-08-14 10 views
3

メインフレームにあるDB2データベースと通信する必要があるWindows 2003上で動作するASP.NETアプリケーションがあります。私たちはサーバー上にDB2クライアント・ドライバーv9.5をインストールして、アプリケーションが接続を実行してデータベースと連動できるようにしました。データベースに接続するための接続文字列にはユーザー名とパスワードが含まれていますが、信頼された接続ではありません。Windows 2003上のDB2クライアントv9.5接続の確立に長時間を要する

明確にするために、私たちが気付いているものなど、OLE DB、ODBC

をDB2 .NETプロバイダを使用していないと、ASP.NETアプリケーションがへの最初の接続を作成しようとしているときということですDB2では、非常に長い時間がかかります。約20秒です。常駐DBAの1人と話したところ、DB2ドライバがActive Directoryに対してデータベースに接続するために使用されているユーザーアカウントを認証しようとしている可能性があると回答しました。

これに対する解決策は、接続に使用されているユーザーアカウントと同じ名前のWin2003サーバー上にローカルユーザーアカウントを作成することでした。ローカルユーザーアカウントは、どのaclグループのメンバーである必要もなく、無効にすることもできます。

私はこの解決策を試しましたが、私の驚きには、実際に働いていました。接続はミリ秒以内に行われました。私が懸念しているのは、この「機能」がDB2ドライバの欠陥のように見えることです。このドライバの新しいバージョンでは、実際にこの機能が再び動作するのを防ぐことができます。

私たちが設定できるDB2ドライバに実際の設定があるので、誰でも知っているので、Active Directoryで認証しようとしませんか?私は、その設定を使用することで、認証アルゴリズムの脆弱性に頼るよりも、より快適に感じるでしょう。

おかげところで、同じ質問がサーバー障害に頼まれた

は、しかし、誰が答えることができませんでした。

https://serverfault.com/questions/53971/db2-client-v9-5-on-win-2003-taking-long-time-to-establish-connection

答えて

1

私たちのDBAは、適切な解決策を見つけました。ローカルユーザーを追加しなくても機能します。

基本的には、DB2アプリケーションサーバー上で接続をカタログするときに、「認証サーバー」のようなものを指定する必要があります。これにより、DB2ドライバがActive Directoryに対して認証されなくなります。

私は答えが曖昧だと知っていますが、それは私が彼から出ることができる最大です。

1

DB2は、「データベースのみ」ユーザーIDの概念がありませんし、常に認証を実行するオペレーティングシステムを使用します。 OS認証がActive Directoryを介して行われる場合、それがDB2の認証方法です。

あなたのDBAは、OSの設定/アカウントを変更して認証を簡単にすることで、正しい解決策を得たと思います。

私はこれがドライバの欠陥だとは思わない。

関連する問題