PART 07 — DB Link

他システムのDBに直接クエリを飛ばせるDB Linkは便利な反面、トランザクション境界やネットワーク遅延を意識しないと思わぬ落とし穴にはまります。導入前に知っておきたい制約をまとめました。

DB Link（データベースリンク）とは

あるDBから、別のDB上のオブジェクトをあたかも自分のオブジェクトのようにSQLで参照できる仕組み。

用語は製品により異なる

• Oracle: DATABASE LINK
• PostgreSQL: postgres_fdw, dblink
• SQL Server: Linked Server
• Db2: Federated / Nickname

本質は同じで「リモートDBへのプロキシ接続」。

-- DB A (ローカル) から DB B (リモート) のcustomersを参照
SELECT *
  FROM orders o
  JOIN customers@DB_B c
    ON o.cust_id = c.id;

DB Linkの作成と利用（例）

-- 1) DB Link の作成 (Oracle 例)
CREATE DATABASE LINK link_to_b
  CONNECT TO remote_user IDENTIFIED BY ****
  USING 'DB_B_TNS_NAME';

-- 2) 利用例 (テーブル参照は @name 付与)
SELECT *
  FROM orders o
  JOIN customers@link_to_b c
    ON o.cust_id = c.id
 WHERE o.created_at >= :d;

-- 3) PostgreSQL (FDW) の場合
CREATE EXTENSION postgres_fdw;
CREATE SERVER svr_b ... ;
CREATE USER MAPPING FOR app SERVER svr_b ... ;
IMPORT FOREIGN SCHEMA public FROM SERVER svr_b INTO remote_b;

性質

• 接続は呼び出し時に確立
• パスワードはDBに保持
• SELECT/DML/JOIN可能
• 結果はネットワーク経由
• COMMITは分散2PCになることがある
• シノニムで隠蔽するとアプリ側は意識せず使える

分散SQLの内部動作

1. App ⇒ DB A（Coordinator）にクエリ送信
2. DB A ⇒ DB B（Remote）にサブクエリ送信
3. DB B ⇒ DB A に行をネットワーク経由で返却
4. DB A で結合し、最終結果をAppに返却

• コーディネータ側（= DB Link元）が分散実行計画を立てる。
• どこまでをリモート側で絞り込み（述語プッシュダウン）できるかが性能を決める。
• WHEREが先に効けば数件しか転送されないが、効かないと全件転送になる。
• 更新が絡むと2フェーズコミット（2PC）になり、片方が落ちるとCOMMITがぶら下がる。

DB Link利用時の注意点

• パフォーマンス: ネットワーク往復がボトルネック化しやすい。リモート側でWHERE/集約を済ませる設計が必須。
• セキュリティ: 認証情報がDB内部に保存される。権限は最小限で。SSL/暗号化の検討。
• 可用性: リンク先が停止すると、コーディネータ側のセッションも待たされる。タイムアウト設定が重要。
• 分散トランザクション: 更新を伴うと2PC、コミットが2倍の往復になる。読み取り専用にできるならその方が圧倒的に楽。
• バージョン互換: リンク元・先のDBバージョン差で挙動が変わる。テスト環境でバージョン一致を確認。
• 運用: リンク自体の存在・依存関係を文書化する。本番DBの「隠れ依存」になりがち。

DB Link でよくある失敗パターン

失敗パターン	原因	対策
リモートテーブルを全件JOINして遅い	WHERE句がリモート側にプッシュダウンされず全件転送	リモート側で絞り込むサブクエリを書くか、インライン・ビューで事前集約
更新処理が途中で止まりCOMMITが宙吊りに	2PCのコーディネータ/参加者間で片方がダウン	更新はDB Linkを避ける。必要ならメッセージキューや非同期レプリを検討
リンク先DB停止でアプリ全体が応答なし	接続タイムアウトがデフォルト（無限）のまま	sqlnet.ora の SQLNET.OUTBOUND_CONNECT_TIMEOUT を設定
本番でリンク先が変わって気づかない	DB LinkのTNS名がハードコードされた運用構成	シノニムを介してリンク名を隠蔽し、変更時はシノニムのみ差し替え