サーバー障害発生後にデータベースが開かない、リストア不可、
マウントできない等、データベース専門の復旧サービスを提供しています。
ディスク故障に影響によるサーバダウン、システム障害やエンジニアのミスによる削除等、データベース復旧には専門技術が必要です。
ORACLE | *.dbf,*.log,*.ctlファイルの削除、dmpファイルのインポート不可、dbfファイルからのdmpエクスポート |
---|---|
MS-SQL | *.mdf,*.ldf,*.datファイルの削除、SQLサーバー起動不可、mdf、ldfがattachできない |
MYSQL | *.myi,*.myd,*.frmファイルの削除、attachできない、サーバー起動不可 |
毎日定期バックアップを取得していました。サーバーに障害が発生したため、エラーの発生したディスクを交換しましたが、ORACLEが起動できない状態に。仕方がなくOSとORACLEを新規インストールし定期バックアップしてあったdmpファイルをインポートしてみたところ、正常にインポートできず、お手上げの状態に。
ディスクに障害が発生している状態で取得したdmpファイルは、正常にエクスポートされていない状態(途中で切れてしまっている)であることを確認。障害ディスクから取得したdbfファイルを元にORACLEを復旧、正常インポートを確認後、お客様環境に合わせてFull dmp export にて納品しました。
作業結果:成功 作業日数:3日 納品dmpファイル:27GB
稼働中、ORA-600でインスタンスがダウンしてしまった。DBインスタンスを再起動したところクラッシュリカバリー中に再度ORA-600が発生し、起動できなかった。取得していたバックアップから戻そうとしてみたが、うまくいかなかった。ORACLEのデータベースを復旧してほしい。
取得されたバックアップを確認した結果、ORACLEオープン中に取得したデータのため、一貫性(SCN)が一致しないためにオープンできない状態を確認。コントロールファイルの修復とデータブロックのエラーを追加で確認。スキーマ生成スクリプトおよびdbfファイルのご提供をいただき、ORACLEデータベースの分析および抽出を行いました。抽出データをインポートし、お客様ORALCE環境に合わせて、dmpファイルにて納品完了しました。
作業結果:成功 作業日数:2日(緊急対応) 納品dmpファイル:300GB
ORACLEを運用中のサーバー(RAID5構成)にディスク障害が発生し、起動不可の状態になったので、別のデータ復旧会社に依頼してデータを復旧してもらった。VMの仮想環境であり、vmdk内のオラクルデータを復旧してほしい。仮想ディスクデータやオラクルに関してはノーチェックということで、実データファイルだけあるが、弊社ではオラクルに取り込むことができない。正常なデータかの判断もできていない。
vmdkファイルから実データファイルとなる、ctlファイルや設定ファイル、dbfファイルを抽出後、分析を開始。サーバーのデータ復旧自体は正常に行われているようで、実ファイル内のデータは残っていることを確認。弊社ツールを使用してORACLEに読み込み、エラーブロックの修正を行った上でfull dmp export 行い、dmpファイルを納品しました。
作業結果:成功 作業日数:3日(緊急対応) 納品dmpファイル:40GB
HDD x6 RAID5 のサーバー構成で、ディスク2本が故障してしまったため、稼働できなくなった。他のデータ復旧会社に依頼してデータは抽出してもらったが、ORACLEデータベースに関しての整合性の確認やサポートは一切ないと言われた。ORACLEが復旧できなければ意味がない。なんとかオラクルとして読み込めるようにしてほしい。
提供いただいたdbfファイルを弊社オラクル復旧ツールにて解析を行いました。エラーブロックはほとんどなく、exp full=y にてdmpファイルを抽出、納品しました。
作業結果:成功 作業日数:3日 納品dmpファイル:132GB
ファイルサイズ、損傷具合によりお見積もり 作業日数3日~