Oracleダンプファイルの破損を確認・検証する方法

他社やチームメンバーから受け取った .dmp ファイルをインポートしようとしたらエラーが出た——こうした場面では、まずファイルが破損していないかを確認する必要があります。

本記事では、.dmp ファイルの整合性を検証する方法を紹介します。

ダンプファイルが破損する主な原因

• 転送中の破損: FTP のバイナリモード未設定、不完全なダウンロード、ネットワーク切断
• エクスポート中の異常終了: ディスク容量不足、プロセス強制終了
• ファイル分割・結合の失敗: 大容量ファイルを分割転送した際の結合ミス
• 圧縮・解凍の失敗: 破損した ZIP/GZIP からの展開

方法1: OraDB DUMP Viewer で検証（推奨）

最も手軽で確実な方法です。Oracle 環境は不要です。

1. OraDB DUMP Viewer で .dmp ファイルを開く
2. 以下を確認：
   • ファイルが正常に解析されるか（エラーなくツリーが表示されるか）
   • スキーマとテーブルの一覧が表示されるか
   • テーブルのデータが正常にプレビューできるか
   • ダンプ形式（EXP/EXPDP）が正しく認識されているか

判定基準:

• ✅ テーブルツリーが表示され、データプレビューが可能 → 正常
• ⚠️ 一部テーブルのデータが読めない → 部分的な破損の可能性
• ❌ ファイルを開けない、解析エラー → 破損またはサポート外の形式

方法2: ファイルサイズとチェックサムの確認

転送前後でファイルの整合性を確認する基本的な方法です。

ファイルサイズの比較

# 送信元（Linux）
ls -la export.dmp

# 受信側（Windows PowerShell）
Get-Item export.dmp | Select-Object Length

サイズが一致しない場合は転送が不完全です。

チェックサム（ハッシュ値）の比較

# Linux
sha256sum export.dmp

# Windows PowerShell
Get-FileHash export.dmp -Algorithm SHA256

# macOS
shasum -a 256 export.dmp

ハッシュ値が送信元と一致すれば、ファイルは破損していません。

方法3: impdp での検証（Oracle 環境あり）

Oracle 環境がある場合は、impdp の SQLFILE パラメータで簡易検証できます。

impdp user/pass DIRECTORY=dump_dir DUMPFILE=export.dmp SQLFILE=verify.sql

正常に SQL が出力されればファイルは読み取り可能です。エラーが出た場合はメッセージで破損箇所の手がかりが得られます。

方法4: strings コマンドでの簡易確認

strings export.dmp | head -20

EXP 形式なら先頭付近に EXPORT:V のような識別子が見えるはずです。何も表示されない場合はファイル形式自体が不正な可能性があります。

ファイル転送のベストプラクティス

項目	推奨
FTP	必ずバイナリモード（bin）で転送
ハッシュ値	転送前後で SHA-256 を比較
圧縮	GZIP/ZIP で圧縮してから転送
分割	可能なら分割せず単一ファイルで転送
ストレージ	転送先のディスク空き容量を事前確認

まとめ

.dmp ファイルの破損確認は、OraDB DUMP Viewer で開いてみるのが最も手軽です。ファイルが正常に解析でき、テーブルデータがプレビューできれば問題ありません。転送時はバイナリモードとチェックサム比較を徹底しましょう。

→ 無料でライセンスを取得する