収録問題 70問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
データベースの災害復旧要件を決める際、最初に業務側と合意すべき組み合わせはどれですか？
答え： 許容データ損失（RPO）と許容停止時間（RTO）
RPOとRTOを先に定義すると、バックアップ頻度、ログ保管、レプリケーション方式、復旧拠点、コストの選択根拠ができます。測定可能な業務要件として合意します。
バックアップジョブが毎日成功になっている。復旧可能性を最も確実に確認する方法はどれですか？
答え： 隔離環境へ定期的にリストアして検証する
バックアップ成功は復元成功を保証しません。実際のリストア訓練でメディア、鍵、権限、手順、依存関係を含めて検証し、達成RTOと復元時点を記録します。
高可用性構成とバックアップの関係について正しい説明はどれですか？
答え： HAは停止時間を、バックアップは復旧範囲を担う
レプリケーションやクラスターは可用性を高めますが、誤DELETE、ランサムウェア、論理破損が複製される場合があります。HAと独立したバックアップ/リストアを組み合わせます。
ランサムウェアや管理者誤操作にも備えるバックアップ保管設計として適切なのはどれですか？
答え： 別の障害ドメインへ複数世代を不変保管する
本番認証情報侵害がバックアップ削除へ直結しないよう、アカウント・リージョン・メディア等を分離します。保持ロックや不変ストレージと復元試験を組み合わせます。
異なるDBエンジンへ一部スキーマを移行する際、一般に扱いやすいバックアップ形式はどれですか？
答え： DDLとデータを含む論理エクスポート
論理エクスポートは選択的移行や変換に向きます。ただし型、照合順序、シーケンス、権限、手順などの差を変換・検証する必要があります。
稼働中データベースの複数ファイルをストレージスナップショットでバックアップする場合に重要なのはどれですか？
答え： DBエンジンの整合性手順に沿って取得する
Crash-consistent復旧が可能か、複数Volumeをアトミックに取得できるか、必要なログが揃うかを製品仕様で確認します。単純ファイルコピーは不整合を招きます。
14:37の誤DELETE直前へデータベースを戻したい。PITRに必要な構成はどれですか？
答え： ベースバックアップと連続したログ
PITRはベースバックアップへWAL、バイナリログ、トランザクションログ、アーカイブ済みRedo等を順序どおり適用します。ログ欠落があると、その先の時点へ進めません。
暗号化バックアップを遠隔地へ保管する際のキー管理として適切なのはどれですか？
答え： 鍵とバックアップの障害ドメインを分けて管理する
暗号化はキーを失うと復旧不能になります。KMS等で権限を分離し、保持期間中の旧キー利用と災害時のキー復旧をリストア訓練へ含めます。
非同期レプリケーションの健全性を横断監視する際、優先すべき指標はどれですか？
答え： 適用位置の差、時間遅延、キュー量、エラー
レプリケーションはトランスポートと適用のどこで遅れているかを分けて見ます。単一のSeconds遅延だけでなく、位置、キュー、ワーカーエラー、増加傾向を監視します。
スタンバイが接続中で遅延も小さい。フェイルオーバー可能と判断する前に追加確認すべきことはどれですか？
答え： 昇格から旧プライマリ隔離までを定期演習する
同期状態だけではサービス復旧を保証しません。ロール変更、接続先、認証情報、アプリケーション再接続、フェンシングまで含むフェイルオーバー訓練で実測RTOを確認します。
非同期レプリケーション構成でプライマリサイトが完全消失した。正しいリスク認識はどれですか？
答え： 未適用トランザクションが失われる可能性がある
非同期方式は通常レイテンシを抑える代わりに、障害時のデータ損失ウィンドウを持ちます。最後の永続/適用済み位置を確認し、宣言したRPOとのずれを共有します。
ネットワーク分断時に旧プライマリと新プライマリの両方が書込を受けるスプリットブレインを防ぐ中核制御はどれですか？
答え： クォーラムとフェンシングで片方の書込みを止める
昇格前に旧プライマリをストレージ、ネットワーク、プロセス等からフェンスし、単一の書き込み元を保証します。曖昧な到達不能を停止済みとみなしてはいけません。
フェイルオーバー後もアプリケーション変更を最小化する接続設計はどれですか？
答え： ロールに追従するエンドポイントと再接続を使う
リスナー、クラスターエンドポイント、プロキシ、DNS等で接続先を抽象化し、アプリケーション側も接続再生成とトランザクション再試行を安全に扱います。DNS TTLだけに依存しません。
計画メンテナンスでプライマリとスタンバイを入れ替えるスイッチオーバー前の手順として適切なのはどれですか？
答え： 同期状態と切替条件を確認し変更ウィンドウで行う
計画切替は事前に同期と依存ジョブを確認し、変更中だけアラートをメンテナンス扱いにします。切替後は書き込み、読み取り、ジョブ、バックアップ、監視を検証します。
利用者の大量DELETEが即座に通常レプリカへ反映されるリスクを緩和する選択肢はどれですか？
答え： 遅延レプリカかPITR可能なログアーカイブを持つ
遅延レプリカは論理誤操作の検知猶予を作れますが、最新フェイルオーバー先には向きません。PITR、不変バックアップ、権限制御と組み合わせます。
リードレプリカへ書込直後のクエリを振ると古い値が返る。適切な設計判断はどれですか？
答え： 書き込み直後の読み取りはプライマリへ寄せる
非同期レプリカにはEventual Consistencyがあります。業務ごとにStaleness許容度を定義し、セッションStickiness、LSN/GTID等の位置待機、プライマリ読み取りを選びます。
異なるDB製品を横断して性能問題を調べる最初の進め方はどれですか？
答え： ベースラインと現在の負荷・待機を比較する
製品名より、何が待たされ、いつから、どのワークロードで悪化したかを共通シグナルで絞ります。その後に各エンジンの待機イベントやクエリストアへ掘り下げます。
特定SQLが急に遅くなった。実行計画を比較する際の適切な確認はどれですか？
答え： 推定行数と実測行数、結合順序、変更点を確認する
カーディナリティ推定のずれやプラン変化の原因を、実測と変更履歴で確認します。プラン強制は緊急緩和になり得ますが、適用範囲と解除条件が必要です。
統計情報やインデックスメンテナンスを複数DB製品で標準化する際の方針はどれですか？
答え： 製品の自動機能を把握し測定して対象を絞る
過剰メンテナンスはI/O、ログ、レプリケーション遅延、ロックを増やします。エンジンの自動統計・Vacuum・オンライン機能を理解し、効果と副作用を測って実施します。
ブロッキングセッションが増えてアプリケーションタイムアウトが発生した。最初の対応として適切なのはどれですか？
答え： ブロッキングチェーンを特定し最小範囲で解除する
ルートブロッカーと業務処理を特定して、キャンセル、ロールバック、トラフィック制御を判断します。証跡を残し、長時間トランザクションやアクセス順序を恒久対策します。
アプリケーションインスタンス増加でDB接続上限に達した。適切な対策はどれですか？
答え： 接続予算を決めプール上限とタイムアウトを調整する
プールはインスタンス数との積で考えます。DBのワーカー、メモリ、ワークロードを基に予算化し、急増時はキューとアドミッション制御でデータベースを保護します。
長時間トランザクションがMVCCクリーンアップやログ再利用を妨げている。適切な恒久対策はどれですか？
答え： トランザクションを短くしアイドルタイムアウトを設ける
長時間トランザクションはOldバージョン、取り消し、WAL/ログ、ロックを保持します。アプリケーション境界を見直し、オーナーが分かる監視と安全なタイムアウトを設けます。
DBレイテンシが上昇したがCPUは低い。次に優先して確認すべきものはどれですか？
答え： ストレージI/O、ログフラッシュ、ロック待ちを確認する
データベースはI/O、ログフラッシュ、ネットワーク、ロックを待つ間CPUを消費しない場合があります。ホスト、ストレージ、エンジン待機を同じ時間枠で相関します。
データファイル以外の領域が急増してディスクフルが迫っている。横断的な調査として適切なのはどれですか？
答え： ログ・一時領域など増加源ごとに分解する
容量増加はバックアップ失敗、レプリカ停止、長時間トランザクション、大規模ソート、ログローテーション不備などのシグナルです。緊急容量確保と原因除去を並行します。
アプリケーション用DBアカウントの権限設計として適切なのはどれですか？
答え： 業務ロールごとに必要な操作だけを付与する
ランタイム、マイグレーション、監視、バックアップ等のロールを分離し、シークレットマネージャー、短期認証情報、ローテーションを使います。権限変更はコードレビューと監査対象にします。
緊急障害時だけ強いDB権限を使う緊急用運用として適切なのはどれですか？
答え： 承認付きで短時間だけ権限を発行し記録する
緊急用は通常経路が使えない時の例外です。本人性、理由、承認、期限、セッション記録、通知を備え、利用後に認証情報と権限を確実に戻します。
データベース監査ログを設計する際の適切な方針はどれですか？
答え： 高リスク操作を定義し改ざん耐性と保持を設ける
監査目的と脅威モデルからイベントを選び、機密値を最小化します。中央転送、時刻同期、アクセス制限、改ざん検知、検索可能な共通フィールドを整備します。
データベース接続のTLS証明書を無停止でローテーションする準備はどれですか？
答え： 新旧の信頼を重複させて段階的に切り替える
サーバーと多数クライアントを同時変更できないため、期限付き重複を使います。ホスト名検証と暗号化を維持したままカナリアで接続し、旧キー/CAを撤去します。
大規模テーブルへNOT NULL列を無停止に近い形で追加したい。一般的に安全なマイグレーションパターンはどれですか？
答え： null許容で追加しバックフィル後に制約化する
スキーマとアプリケーションの互換期間を作り、バックフィルをスロットルします。製品ごとのオンラインDDL、ロック、ログ量、レプリケーション遅延を事前検証します。
数TBのテーブルへインデックスを追加する際、適切な変更計画はどれですか？
答え： オンライン機能と追加領域を検証し段階実施する
オンラインDDLでもCPU、I/O、ログ、短時間ロック等の影響があります。本番相当データで測定し、トラフィック制御、停止条件、完了後プラン確認を用意します。
PostgreSQLから別エンジンへマイグレーションする際、事前に重点確認すべき互換性はどれですか？
答え： データ型、照合順序、タイムゾーン、SQL方言の差
構文が変換できてもセマンティクスが同じとは限りません。空文字とNULL、タイムスタンプ、10進数、文字ソート、真偽値、自動生成キー、トランザクション挙動をテストケース化します。
大容量データベースを短い停止時間で異種エンジンへ切り替える一般的な方式はどれですか？
答え： バルクロード後にCDCで差分同期し切り替える
バルクロードと変更データキャプチャを分けると停止時間を最終差分へ限定できます。DDL変更、順序、重複、削除、再実行、CDC保持期間も管理します。
マイグレーション前後のデータ一致を検証する方法として適切なのはどれですか？
答え： 件数・チェックサム・業務不変条件を段階比較する
単一指標では欠落、重複、変換誤りを隠します。重要テーブルと業務ルールを優先し、スナップショット時点を揃え、負荷を制御して差分を再現可能に記録します。
データベースマイグレーションのロールバック条件として事前定義すべきものはどれですか？
答え： エラー率や差分の閾値と、戻せる最終時点
Go/中止とロールバックを数値・オーナー・デッドラインで定義します。ターゲットへの新規書き込み開始後は逆同期が必要になるため、後戻りできない地点（Point of No Return）を明示します。
データベースメジャーバージョンアップグレード前の適切な準備はどれですか？
答え： 本番相当コピーでアップグレードをリハーサルする
メジャーアップグレードはSQL、ドライバー、拡張、認証、オプティマイザ、パラメータデフォルトを変える場合があります。非推奨機能をインベントリ化し、カナリアと性能回帰テストを行います。
多数のデータベースインスタンスで設定ドリフトを抑える方法はどれですか？
答え： ポリシーをバージョン管理しドリフトを検知する
共通インテントを暗号化、ロギング、バックアップ、タイムアウト等で定義し、製品別実装へマッピングします。例外はオーナー、理由、期限を持たせます。
データベースフリートの運用リスクを把握するインベントリとして優先すべき情報はどれですか？
答え： オーナー、重要度、バージョン、RPO/RTO、依存先
所有権とライフサイクルが不明なDBはパッチ、バックアップ、廃止判断から漏れます。CMDB/インベントリを検出と照合し、EOLや未保護インスタンスを優先是正します。
PostgreSQL、MySQL、SQL Server、Oracleを一つの監視基盤で扱う設計はどれですか？
答え： 共通モデルで揃え製品アダプターで詳細を補う
共通サービスヘルスでフリートを比較し、異常時は待機イベント、バッファ、ログ、レプリケーションワーカー等の製品詳細へドリルダウンします。SLOとベースラインに応じて閾値を調整します。
データベースインシデントで再起動が有力な暫定策になった。実行前の適切な行動はどれですか？
答え： セッションや待機の証跡を保全し影響を共有する
再起動は証跡とキャッシュ内状態を消す場合があります。復旧を遅らせない範囲で取得項目をランブック化し、再起動後も症状、データ整合性、再発を確認します。
データベース横断運用ランブックの品質を継続的に高める方法はどれですか？
答え： 演習と実インシデントで計測し改善を反映する
ランブックは実行可能なプロダクトとして扱います。前提、停止条件、エスカレーション、ベンダー差、検証、ロールバックを含め、定期的に別担当者でも完遂できるか試します。
バックアップマニフェストとチェックサム検証が成功したため、リストアテストを廃止しようとしています。適切な判断はどれですか？
答え： チェックサム検証に加えて定期リストアも続ける
チェックサムやマニフェストは欠落・改変の検出に有効ですが、エンジン起動、ログ適用、キー取得、権限、業務整合性までは保証しません。リストア訓練でRTOも実測します。
フルバックアップは正常ですが、途中のトランザクションログバックアップが1本欠落しています。欠落後の時点へPITRできますか？
答え： 欠落を越えられず別のベースバックアップからが必要
PITRはベースバックアップから目標時刻までの連続したWAL・バイナリログ・トランザクションログ等を必要とします。カタログでチェーン完全性と保持を継続監視します。
停止したレプリカがログを保持させ続け、プライマリのWAL・バイナリログ領域が逼迫しています。中核対策はどれですか？
答え： スロットの遅延と保持量に上限と解放手順を設ける
停止レプリカの再開可能性を守る保持がプライマリ停止を招いてはいけません。経過時間・バイト数・ディスク余裕を監視し、業務RPOと再シード時間に基づく上限を決めます。
2サイト構成のDBクラスターでネットワーク分断時の二重プライマリを防ぎたい。クォーラム設計として適切なのはどれですか？
答え： 奇数投票か独立ウィトネスで多数派だけが書ける構成
クォーラムは可用性より先に単一の書き込み元を守る仕組みです。ウィトネスのネットワーク・電源・管理ドメインも独立させ、サイト喪失と分断の各マトリクスを演習します。
DRサイトへフェイルオーバー後、旧プライマリサイトが復旧しました。最初に行うべきことはどれですか？
答え： 旧プライマリを隔離したまま乖離を確認し再同期する
旧プライマリはフェイルオーバー点以降の別履歴を持つ可能性があります。書込をフェンシングし、タイムライン・GTID・LSN等で関係を確認してからスタンバイとしてReinstateします。
非同期レプリカへ強制フェイルオーバーした後、一部クライアントは成功応答済みトランザクションが見えないと報告しています。適切な対応はどれですか？
答え： 新旧の適用位置を比較し損失範囲を業務記録と照合する
非同期フェイルオーバーでは確認済み済みでもレプリカへ未到達のトランザクションがあり得ます。冪等性キー、業務台帳、メッセージ記録を使って欠落と重複を制御します。
デプロイ後に同じSQLのレイテンシが急増し、実行計画が変わっていました。再発防止を含む対応はどれですか？
答え： プラン履歴とデプロイ時刻を比較し暫定固定する
プランリグレッションは履歴がないと再現しにくいため、プランハッシュ、実行時間、行、待機、デプロイを関連付けます。プラン固定は恒久策ではなくデータ分布変化も再評価します。
入力パラメータにより対象行が数件から数百万件まで変わり、再利用プランの性能が不安定です。適切な進め方はどれですか？
答え： パラメータ帯ごとのプランと統計を比較して対策する
単一プランが異なる選択性へ適合しない問題を、パラメータSniffingという名称だけで決めつけず実測します。機密値はバケット化・秘匿化して観測します。
ソート・ハッシュ処理がメモリに収まらず一時領域へスピルし、DBレイテンシが上昇しています。適切な対応はどれですか？
答え： スピル量と推定行数・メモリ設定を関連付ける
スピルは統計誤差、プラン、インデックス不足、過大な中間結果、メモリ付与等の症状です。グローバル設定変更は同時実行時の総メモリを見積もって段階検証します。
デッドロック検出エラーを通常の長時間ブロッキングと同じ扱いで調査しています。適切な切り分けはどれですか？
答え： デッドロックとブロッキングを別の指標で分析する
デッドロックは循環待ちをエンジンが検出して犠牲側を選ぶ事象です。ロック取得順序統一やトランザクション短縮を行い、リトライは冪等かつ上限・ジッター付きにします。
同じ当直枠に医師が最低1人必要な処理で、2トランザクションが互いを見ず別々の行を更新し、両方休みにしました。中核対策はどれですか？
答え： 直列化可能分離か明示ロックで不変条件を守る
異なる行の更新でも集合全体の不変条件を壊す書き込みスキューが起こり得ます。分離レベル名だけでなく対象エンジンの実装と競合動作をテストします。
コネクションプールの利用数が上限へ張り付き、DB CPUは低いままです。次に確認すべきものはどれですか？
答え： 接続の取得待ちと返却漏れをトレースで確認する
接続枯渇はCPU以外の待ちやアプリケーションの返却漏れでも起きます。取得時間、保持時間、クエリ、トランザクションオーナーを相関し、タイムアウトとライフサイクルを修正します。
CDCで異種DBへ継続同期中、ソースへ列追加するとコンシューマーが停止しました。再発防止の中核はどれですか？
答え： スキーマ互換ルールを版管理して先行対応する
CDCパイプラインではDDLもインタフェース変更です。加算的変更、デフォルト、null許容性、リネーム・ドロップの互換期間、スキーマレジストリ、DLQとリプレイ手順を設計します。
異種DB移行でアプリケーションがソースとターゲットへ二重書き込みしていますが、片側成功・片側失敗が発生しました。適切な設計はどれですか？
答え： ソースを正本にCDC等でターゲットへ冪等に適用する
独立DBへの同期二重書き込みはアトミックではありません。正本のコミットから再実行可能な変更ストリームを作り、冪等性キーと照合で欠落・重複を制御します。
データ移行後、ターゲットの自動採番が既存最大IDより小さく、新規挿入が重複エラーになりました。カットオーバー前の対策はどれですか？
答え： シーケンスの現在値を最大IDより先へ同期する
行コピーだけではシーケンス等のジェネレータ状態は移らない場合があります。各テーブルの所有関係、インクリメント、サイクル、キャッシュ、フェイルオーバー後動作もカットオーバーチェックリストへ含めます。
異種DB移行後、文字列の一意判定と並び順が変わり、日時も数時間ずれました。事前検証として適切なのはどれですか？
答え： 照合順序とタイムゾーンを対応表化して全量検査する
同じテキストや日時でもエンジン設定と型セマンティクスで比較・保存・表示が変わります。カットオーバー前に競合レポートを作り、業務規則として変換方針を合意します。
マルチテナントDBでアプリケーションのWHERE tenant_id漏れにより他テナントの行が返りました。再発防止の中核はどれですか？
答え： 行レベルセキュリティ等でDB側の境界を強制する
テナント境界は各クエリの実装規律だけに依存させません。DBポリシー、最小権限、プールでのテナントコンテキストリセット、否定テスト、監査を防御in深さで実装します。
TDEを有効にしたため、TLSと列単位の機密データ保護は不要だと判断しています。正しい理解はどれですか？
答え： TDEは保存時の保護であり通信・権限は別に設計する
暗号化はThreat Boundaryごとに役割が違います。保存時、転送中、利用中データ、管理者権限、鍵バックアップ・ローテーション・復旧を分けて設計します。
DBアプリケーション認証情報を無停止ローテーションしたい。安全な移行パターンはどれですか？
答え： 新認証情報を先に有効化し確認後に旧を失効する
重複ウィンドウを短く管理し、プールが古い接続を保持する時間、ロールバック条件、監査、失効確認まで自動化します。可能なら短期トークンやManaged Identityも検討します。
データベースインシデント後、DBログ・アプリケーションログ・クラウド監査の時刻がずれてタイムラインを再構成できません。再発防止はどれですか？
答え： 時刻源を同期しトレースIDで証跡を相関する
正確なタイムラインは障害原因、データ影響、監査判断の基盤です。クロックドリフトアラート、改ざん耐性保持、アクセス制御、証跡エクスポート手順も事前に検証します。
MySQL 8.4のInnoDBで、トランザクション内のUPDATEに続けて通常テーブルへALTER TABLEを実行しました。後でROLLBACKすればUPDATEも必ず戻る、という手順書の問題はどれですか？
答え： ALTER TABLEの暗黙コミットで、先行更新が確定し得る
通常のALTER TABLEは暗黙コミットを伴います。DDLとDMLをまとめてロールバックできると全製品へ一般化せず、製品・文ごとの境界を確認し、復旧手順を分けます。
PostgreSQLで更新SQLの性能を調べるため、本番でEXPLAIN ANALYZE UPDATEを実行する案が出ました。実行前に共有すべき注意はどれですか？
答え： 対象SQLを実行するため、更新と副作用の影響を評価する
EXPLAIN ANALYZEは実際にSQLを実行して測定します。まず検証環境を使い、本番で必要ならロック・負荷・トリガーなども評価します。明示的なROLLBACKで戻せない副作用もあり得るため、無害とはみなしません。
除外リストにない顧客を id NOT IN (SELECT customer_id FROM excluded) で探すと、除外リストへNULLが入ってから結果が消えました。idはNOT NULLです。適切な修正はどれですか？
答え： 一致行が存在しないことを、相関NOT EXISTSで判定する
NOT INは一致値がなくても、右辺にNULLがあるとunknownになり得ます。WHEREはtrueだけを残します。NOT EXISTS (SELECT 1 FROM excluded e WHERE e.customer_id = c.id) なら、この非NULLの顧客IDに一致する行の有無を判定できます。
移行後テーブルの行数確認で、NULLを許すemail列へCOUNT(email)を使いました。全行数を検証したつもりなのに少なく出る理由と修正はどれですか？
答え： COUNT(email)はNULLを除くため、全行にはCOUNT(*)を使う
COUNT(式)は式がNULLでない行を数え、COUNT(*)は行を数えます。移行検証では同じ対象範囲で全行数とNULL件数を分けて比較し、件数一致だけで内容一致と断定しないようにします。
PostgreSQLでnextvalを使ったINSERTがロールバックされ、IDに欠番ができました。欠番だけを根拠にデータ欠損と判断する運用の問題はどれですか？
答え： シーケンス値はロールバックで戻らず、正常でも欠番が生じる
nextvalで取得した値は、取引が中止されても再利用のために戻されません。欠番なしの業務番号と内部IDを区別し、欠損調査は業務記録や監査証跡と照合して行います。
接続プールの物理接続で、ある処理がセッションのタイムゾーンを変更しました。返却時にその設定をリセットしない構成です。次の処理へ影響させない改善はどれですか？
答え： 取得時の初期化やスコープ限定設定を設計し、再利用で検証する
物理接続が再利用されると、リセットされないセッション状態も残ります。利用するDB・ドライバー・プールの契約を確認し、取得時の基準設定や対応するトランザクション限定設定で境界を作ります。
PostgreSQLのSerializable取引がSQLSTATE 40001で中止されました。読んだ在庫に応じて更新量を決める処理です。再試行の範囲として適切なのはどれですか？
答え： 読取と判断を含む取引全体を、新しい取引としてやり直す
シリアライゼーション失敗では、判断に使ったデータも読み直して取引全体を再実行します。回数・時間を制限し、外部通知などDB外の副作用がある場合は重複防止も別に設計します。
更新のないテーブルをcreated_atだけで並べてページ分割すると、同じ時刻の行がページ境界で入れ替わります。順序を一意にする改善はどれですか？
答え： 一意なidもORDER BYへ加え、同値時の順序を定める
同じcreated_atの中の順序は、その列だけでは定まりません。ORDER BY created_at, id のように一意な並びを指定します。更新中のページングでの整合性は、カーソルやスナップショットなど別の検討も必要です。
PostgreSQLの既定の単一列UNIQUE制約で複数NULLを許している表を、SQL Serverの通常の単一列UNIQUE制約へ移します。重点確認すべき点はどれですか？
答え： NULLの一意性の扱いが異なるため、データと制約方式を見直す
PostgreSQLの既定ではNULL同士を等しいと扱いませんが、SQL Serverの通常の単一列UNIQUEではNULLは1件に制限されます。業務要件に応じ、非NULLだけを対象とする一意インデックスなども検討します。
注文登録のCOMMITを送信した直後に接続が切れ、成否の応答を受け取れませんでした。二重登録を避ける次の対応はどれですか？
答え： 結果不明として業務キーで照合し、冪等な回復手順を使う
応答がないだけでは、サーバーで確定したかを判断できません。業務キーや重複防止キーを使い、確定状況を信頼できる参照先で照合します。未確定の旧取引との競合も考慮し、一意制約などで再実行の重複を防ぎます。