SQL Serverのエラーは、番号だけでなく全文・State・Severity・発生したSQLを合わせて確認します。下の表は主な番号の早見表です。すべてのエラーを網羅するものではなく、使用中のSQL Serverでの正式なメッセージはsys.messagesから確認できます。
SQL Serverの主なエラーコード一覧
| 番号 | 意味の要約 | 最初の確認 |
|---|---|---|
| 18456 | ログイン失敗 | 認証方式・接続先・SQL ServerエラーログのStateを確認 |
| 4060 | 要求されたデータベースを開けずログイン失敗 | DB名・オンライン状態・ログインとDBユーザーの対応を確認 |
| 229／230 | オブジェクト／列の操作権限が拒否 | 拒否された操作・スキーマ・列を確認して必要な権限だけ管理者へ相談 |
| 102 | 構文が不正 | エラー行付近のSQLを確認 |
| 207／208 | 列名／オブジェクト名が無効 | 接続DB・スキーマ・実際の名前を確認 |
| 4104 | 複数部からなる識別子を関連付けられない | FROMにある別名と列参照の接頭辞を確認 |
| 515 | NOT NULL列へNULLを挿入 | 入力値と列の仕様を確認 |
| 517 | 列への値の追加でオーバーフロー | 対象列の型と演算結果の範囲を確認 |
| 547 | 制約と操作が競合 | メッセージの制約名と入力・参照先データを確認 |
| 2627 | 一意制約などの重複キー | 競合した制約・キー値を確認 |
| 8152／2628 | 文字列・バイナリの長さを超えて切り詰めが必要 | 入力長と列定義を確認。2628では対象列などが示される |
| 1205 | デッドロックの犠牲トランザクション | 競合の順序・処理範囲を調べ、必要な再試行を設計 |
| 1222 | ロック取得待ち時間を超過 | ブロックしている処理とロック保持時間を確認 |
| 3930 | 現在のトランザクションをコミットできない | 先行エラーを確認し、現在のトランザクションをロールバック |
| 9001 | データベースのログが使用できない | 直前のI/Oなどの関連エラーを確認 |
| 9002 | トランザクションログが満杯 | ログ再利用待ちの理由、空き容量とバックアップを調査 |
定義の根拠はMicrosoftの公式一覧です：0〜999、2000〜2999、3000〜3999、4000〜4999、8000〜8999。同じ番号でもメッセージ中のオブジェクト名や制約名が違うため、表の要約だけで設定変更を決めないでください。
sys.messagesから正式な意味を確認するSQL
sys.messagesは番号・言語ごとにメッセージを持つカタログビューで、message_id、language_id、severity、textを参照できます。以下は英語メッセージを読む例です。データや設定を変更しません。
SELECT message_id, language_id, severity, [text]
FROM sys.messages
WHERE language_id = 1033
AND message_id IN (517, 547, 4104, 9001, 9002)
ORDER BY message_id;実際に出た番号にINの値を置き換えます。日本語など別の言語で読む場合は、その環境の言語IDを確認してください。sys.messagesを読むにはpublicロールへの所属が必要とされており、この確認のために広い管理者権限を付与する必要はありません。
Msg 4104：テーブル名と別名の混在を確認する
4104の公式説明では、列の接頭辞がFROM句にあるテーブル／別名と結び付かない場合などを挙げています。別名を付けたテーブルを元のテーブル名で参照していないかを確認します。以下は既存テーブルを作成・更新せずに違いを見る例です。
-- 別名 s を付けた後で Sample を参照するため4104になる例
WITH Sample(ItemID) AS (SELECT 1)
SELECT Sample.ItemID FROM Sample AS s;-- 列の接頭辞を別名 s に合わせた例
WITH Sample(ItemID) AS (SELECT 1)
SELECT s.ItemID FROM Sample AS s;JOIN先のテーブルがFROMにない場合も、列名だけ直して解決するとは限りません。メッセージに表示された識別子を探し、クエリ内の別名・JOIN・参照範囲を確認します。
9001と9002を区別する
エラー9001はログが使用できない状態で、ログが満杯であることを示す9002とは区別します。 9001の公式説明は、この状態に至った原因を周辺のエラーから調べるよう案内しています。ログファイルへのアクセス、ストレージなどの問題を、該当時刻のログと合わせて管理者が調べます。
9002の公式説明では、sys.databasesのlog_reuse_wait_descがログ領域を再利用できない理由を示すとされています。ログバックアップの停止、ディスクやファイル上限、同期処理などを確認し、理由に合う対処を選びます。ログファイルを直接削除して空きを作る操作はしません。
18456・1205・1222の対処を選ぶ
18456はパスワードの誤りだけが原因ではありません。SQL認証／Windows認証、接続先、ログイン状態、サーバーログにあるStateを確認します。すべてのログイン失敗でパスワード変更やsysadmin付与を行うことは避けます。
1205ではSQL Serverがデッドロックの犠牲トランザクションを選び、その処理をロールバックします。1222はロックを待つ時間を超えたエラーです。両者を同じタイムアウトとして扱わず、競合するSQLと処理時間を調べます。再試行は、処理の重複や外部への副作用も考えてアプリケーション側で設計してください。
517・547・3930で誤った対処をしない
- 517：列への値の追加で生じたオーバーフローです。「復元ログが不完全」と一律に判断してデータベースの復元を始めるエラーではありません。
- 547：表示された制約と操作が競合しています。外部キーに限るとは決めつけず、制約名・定義・入力値を確認します。制約を削除する前に、必要なデータの整合性を確認してください。
- 3930：現在のトランザクションがコミットできず、ログへ書く操作もできない状態です。先行したエラーを調べ、ロールバックしてから再実行の条件を整えます。「すでに全体がロールバック済み」とは判断しません。
調査・問い合わせ時に残す情報
- エラー番号・全文・State・Severity・発生日時
- SQL Serverの版と接続先データベース、実行したSQL
- 直前のエラー、実行ユーザー、トランザクションの範囲
- 繰り返し発生するか、特定データや処理だけで起きるか
本番での復元・権限変更・制約変更は、この早見表だけで実行せず、管理者が該当エラーの公式資料と環境を照合します。まず正式なメッセージと直前の状態を読むことが、誤った対処を避ける近道です。
コメント