misc.log

日常茶飯事とお仕事と

64bit環境でのODP.NET 64bit版、32bit版の共存

Oracle 11gから導入されたInstant Clientを使えばいけそうだけど、でもやっぱ共存となると要確認かな……というオチでした。Instant Clientも「よくわからないものは使うな」でNG出されそうなので、残念ながら環境を別々に作って考え事を減らす路線でいきます。

自分用メモとして経緯を以下に書き残しておきます。

.NET Framework 4.0を使ったサーバー用アプリケーションを64ビット版Oracleデータベースが稼働するサーバーで動かすという時に、考えないといけないことが1つ……「アプリは64bit用に作る?32bit用に作る?」という件。32bitのクライアントPCで動くアプリも別途ある状況なんで、管理の手間を考えるとできれば32ビット用アプリで固めたいところ。ですが、既にサーバーには64bit版のODP.NETも含めた一式がインストールしてあり、GACにもバッチリODP.NETのDLLが登録されているという……。さて、どうしたものかね、というのが今回の課題。

ここで思うのが「ドットネットならそんなの関係ないじゃない。自分のフォルダにDLLがあればそれで動くでしょ?」って感じなのですが、どうも、これがOracleのDLLに限っては適用できなかったらしいのです。Oracle10gまでは、ODP.NETであっても裏側でOracle Clientのライブラリも利用しており、アプリの導入先にはOracle提供のあの使いづらいインストーラーを使ってライブラリを導入する必要があったとか。この辺については、2008年にも自分もこのブログで触れてました(さっき自分で検索して思いだしたというww)。これについてはOracle 11gから提供される「Instant Client」を使えば、XCopy環境変数の指定だけでODP.NETを使ったアプリを配布できるようです。

www.backyrd.net

では、この11gからのInstant Clientを使えるかという点なのですが……ん〜。環境変数の設定が必要という話と、既に64ビット用のものが一式入っているということから、やはり調査は必要だろう。というのが私の結論。簡単に「できます」とはちょっと言えません。

ちなみに、64ビット環境で32ビットアプリを使うことについてどうなの?という疑問もあるかと思います。これについては、このブログの以下のエントリで紹介しているブログに面白い記述があります。

www.backyrd.net

上記のエントリにあるリンク「AnyCPU Exes are usually more trouble than they're worth」から、「The costs of architecture-neutral EXEs」と銘打たれた段落の項番2、「2. 32-bit tends to be faster anyway」にあるように、64ビットのポインタ操作などに掛かるオーバーヘッドや、実際の業務的なシナリオでの動作場面を考えると、WOWを使って32bitアプリを動かした方が速いという話が書いてあります。ここを信じるのならば、たとえば4ギガバイトを越えるような巨大なオンメモリ処理を行う、といったアプリでなければ64bitである必要は無いということになります。というわ背景と、複数プラットフォームのビルド環境やテスト環境の管理コストという面から、32bitアプリで行きたいな、と思ったのが今回の検討に至った理由です。

ま、今回は32bit、64bitそれぞれ用を作る路線でいきますか。実際に開発環境も含めて運用するのは自分じゃないし(←そこか)。

図解 64ビットがわかる (図解 知りたい!テクノロジー)

図解 64ビットがわかる (図解 知りたい!テクノロジー)