こんにちは、阿久梨絵です！
データベースの世界では、
「同じ Oracle なのに、この環境では動くのに、あっちでは動かない」
という現象が昔から起きてきました。
その理由のひとつが、 CPU アーキテクチャの違いです。
ここでは、むずかしい専門用語をできるだけ避けながら、
“なぜ Oracle は CPU によって動作が変わるのか”
を静かに整理していきます。
1. Oracle は CPU ごとに“別の製品”だった時代がある
Oracle Database は長い歴史の中で、
CPU アーキテクチャごとに完全に別ビルドでした。
・x86（32bit）
・x86_64（64bit）
・SPARC
・Itanium（IA-64）
・PowerPC
・ARM（近年）
つまり、
CPU が違う＝別の Oracle
という世界だった。
そのため、
・インストーラが起動しない
・ライブラリがロードできない
・クライアントが接続できない
といった“CPU違いによる動作不可”は日常的に起きていました。
2. Oracle Client や ODBC/OCI も CPU依存だった
業務システムでよく使われる Oracle Client（OCI）も、
・Windows x86
・Windows x64
・Linux x86
・Linux x64
・Solaris SPARC
など、CPUごとに別パッケージ。
そのため、
・32bit アプリに 64bit Client を入れて動かない
・SPARC 用ライブラリを Linux に置いて動かない
・CPU違いで ODBC がロードできない
という“あるある事故”が多かった。
3. Java（JDK/JRE）も CPUごとに別ビルドだった
Oracle が管理していた時代の Java も、
・Windows x86
・Windows x64
・Linux x86
・Linux x64
・Solaris SPARC
など、CPUごとに完全に別ビルド。
特に JNI（ネイティブライブラリ）を使うアプリは、
CPU が違う → ライブラリがロードできない → アプリが起動しない
という問題が頻発していた。
4. 今はどうなの？ → 昔より改善されたが、完全には消えていない
クラウド化やコンテナ化が進み、
CPU の違いを意識する場面は減りました。
しかし、今でも次のような場面では CPU が影響します。
・Oracle Database のバイナリは今も CPUごとに別
・Instant Client も CPU別パッケージ
・ARM 版 Oracle はまだ対応範囲が限定的
・OCI/ODP.NET などネイティブ接続は CPU依存が残る
つまり、
昔よりはマシになったけれど、CPU違いの壁は今も存在する
というのが現実です。
5. なぜ CPU が違うと動かないのか
CPU は“命令セット”という言語を持っています。
・x86 は x86 の言語
・ARM は ARM の言語
・SPARC は SPARC の言語
Oracle のバイナリは、
その CPU の言語で書かれた“翻訳不要のプログラム”なので、
言語が違う CPU ではそのまま動きません。
これは、
「日本語の本を英語しか読めない人に渡す」
ようなもの。
まとめ
Oracle と CPU の関係は、昔から“切っても切れない”ものでした。
CPU が違えば、Oracle も別のバイナリになり、
クライアントやドライバも CPUごとに用意する必要がありました。
今はクラウドや仮想化で見えにくくなりましたが、
ネイティブ部分では今も CPU の違いが影響します。
使いにくさや動作不良は、設定ミスではなく
「CPUが違うだけ」ということもあるのです。
阿久梨絵でした！
