設問
Universal Containers (UC) では顧客情報と注文をSalesforceに同期しています。最大顧客のUnited Airlinesには12,000件超の取引先責任者があり、同期後から営業担当者がこのアカウントに取引先責任者を追加すると UNABLE_TO_LOCK_ROW エラーが発生します。主に大口顧客で発生し、夜遅くなら保存できます。原因解消の推奨策はどれか。
選択肢
A. ロールベース共有ルールを追加し、全営業が取引先責任者を読み書きできるようにする。
B. 共有ルールを削除し、United Airなど大規模アカウントをApex共有に置き換える。
C. アカウント階層を実装し、取引先責任者を子アカウントへ均等に再分配する。
D. すべてのアカウント項目を読み書き可能にする権限セットを営業に付与する。
解答
C. アカウント階層を実装し、取引先責任者を子アカウントへ均等に再分配する。
解説
A. ロールベース共有ルールを追加し、全営業が取引先責任者を読み書きできるようにする。
不正解です。共有ルール追加はロック競合の根本原因である親レコード高負荷を解消できません。レコード数スキューが続くためUNABLE_TO_LOCK_ROWは改善しない。
B. 共有ルールを削除し、United Airなど大規模アカウントをApex共有に置き換える。
不正解です。Apex共有へ変更しても親アカウントに集中する子レコード数は変わらず、保存時に発生する親行ロック競合は回避できない。根本対策にならない。
C. アカウント階層を実装し、取引先責任者を子アカウントへ均等に再分配する。
正解です。子アカウントに取引先責任者を分散すれば親レコード1件当たりの子レコード数が減少し、親行ロック競合が大幅減。大規模データスキューを解消し保存エラーを防止。
D. すべてのアカウント項目を読み書き可能にする権限セットを営業に付与する。
不正解です。権限不足が原因ではなくロック競合であるため、アクセス権を拡大してもエラーは解決しない。大量子レコード構造を変えない限り状況は改善しない。
第97問
こちらをクリック
