アサーション・エラー 50213 または 200601 dbunload 固定プロシージャ |
||||||||||||||||||||||||||||||||||||||||||||||
 |
||||||||||||||||||||||||||||||||||||||||||||||
|
テクニカル・サポートに報告されるデータベース破損のタイプの 1 つは、主にアサーション・エラー
50213 "Page number on page does not match page requested." に関連しています。Adaptive
Server Anywhere (SQL Anywhere) 6、7、または 8 で実行している場合には、アサーションは
200601 "Page for requested record not a table page or record not present
on page." になる可能性があります。ただし、最も報告が多かったのは、バージョン
5.x で作成されたデータベースがソフトウェアのアップグレードの前に破損してしまうということでした。
注意：外部アンロードを使用しない場合は、エンジン (またはサーバ) にとって意味のあるパスとして
<directory> を指定してください dbunload -c "uid=dba;pwd=sql;dbf=c:\working\asademo.db" -u c:\unloa出力は次のようになります。 Adaptive Server Anywhere Unload Utility Version 8.0.2.3601 Unloading "rs_systabgroup"."rs_lastcommit" into c:\unload\376.dat (relative to server)テクニカル・サポートの事例では、この時点で上記例にアサーション・エラー・メッセージが表示されます。customer テーブルによってアサーション・エラーが発生したと仮定します。 2. 次のコマンドを入力します (すべて 1 行に入力)。 dbunload -c "uid=dba;pwd=sql;dbf=c:\working\asademo.db" -u c:\unload -e出力は次のようになります。 C:\workingdbunload -c "uid=dba;pwd=sql;dbf=c:･working･asademo.db" -uこのプロセスは、正常に完了するか、または別の破損テーブルを生成します。アンロードが正常に完了するまで、除外するテーブルのカンマ区切りリストを使用してプロセスを再実行してください。 3. 破損したテーブルを除き、必要なデータを含む一連の *.DAT ファイルと、データベースのスキーマを含む reload.sql というファイルが生成されました。このデータベースの完全なスキーマが必要となります。RELOAD1.SQL を作成するためには、次のように入力します (すべて 1 行に入力)。 dbunload" -c "uid=dba;pwd=sql;dbf=c:\working\asademo.db" -n -r 4. 任意のテキスト・エディタ (メモ帳など) を使用して reload.sql と RELOAD1.SQL を開き、”RELOAD DATA (データの再ロード)” を検索します。このセクションの内容全体を reload.sql から RELOAD1.SQL の同じセクションにコピーします。 RELOAD DATA セクションには、次のような LOAD TABLE パラグラフが含まれます。 LOAD TABLE "DBA"."employee"細かい部分は、アンロードを実行するエンジンのバージョンによって若干異なります。 5. 破損したテーブルごとに、これらのパラグラフのいずれかを複製します。テーブル名 ("DBA"."CONTACT") を、破損したテーブルの名前 ("DBA"."CUSTOMER") に置き換えてください。また、DAT ファイルの名前を、同じディレクトリの一意のファイル名 (たとえば'c:\\unload\\customer.dat') に置き換えます。 LOAD TABLE "DBA"."customer" 6. RELOAD1.SQL ファイルを保存します。 7. 破損したテーブルから有効なデータを回復する必要があります。スタンドアロン・エンジンでデータベースを起動し、Interactive SQL から接続します。次の構文を使用して、テーブルのデータを選択して出力します。便宜上、データはプライマリ・キー順になります。 SELECT * FROM customer ORDER BY id ASC >># c:\unload\customer.datこれにより、エンジンがアサートするまで、できるかぎり多くのデータがテーブルから customer.dat に出力されます。 8. エンジンを再起動し、Interactive SQL から再接続して、ソート順を反転します。 SELECT * FROM customer ORDER BY id DESC >># c:\unload\customer.dat二重の > 記号を使用すると、新しい出力が最初のセットに結合されます。エンジンは、再度アサートします。書き込まれたローの数を期待数と比較するか、customer.dat を開いて最初のパスの最終ローのプライマリ・キー値と 2 番目のパスの最終ローのプライマリ・キー値を比較して、どれだけのデータが失われているかを確認します。ある程度のデータが失われるのは避けられませんが、かなりの数のローが失われている場合は、次のような構文を使用してプロセスを継続できます。 SELECT * FROM customer where id between 1600 and 20000 ORDER BY id ASC複数のローが破損していて、それらのローの位置が大きく離れている場合は、この処理に時間がかかることがあります。幸いこれらのローはプライマリ・キーで頻繁にグループ化されています。グループ化されていない場合は、インデックスを持つ別のカラムによってソートするか、このテーブルのインデックスをすべて削除してからデータの回復を行います。 注意：オプティマイザがテーブルの逐次スキャンを実行するように決定すると、ORDER BY 句を使用していても、常に同じポイントで失敗が起きます。このような時には、ユーザ推定を明示的に指定して、オプティマイザがインデックスを使用するようにします。しかし、必ずオプティマイザがインデックスを使用するかは保証できません。データ回復のもっとも有効な手段としては、適切なバックアップとリカバリ方法をとることです。 9. できるかぎり多くのデータを回復したら、dbinit コマンドを使用して新しいデータベースを作成する必要があります。オリジナルの照合順、ブランク埋め込み設定、大文字と小文字の区別、ページ・サイズに一致していることを確認してください。大量のキャッシュを備えたパーソナル・サーバで新しいデータベースを起動し、Interactive SQL を使用してその新しいデータベースに接続して、次のように入力します。 READ C:\WORKING\RELOAD1.SQLこれにより、元のデータベースから回復できたスキーマ情報とデータがすべて読み込まれます。唯一直面する可能性がある別の問題は、いつ外部キー関係が適用されるかということです。親レコードがないのに子レコードが存在する場合は、外部キー関係が確立されません。これを機能させるには、子レコードを削除するか、親レコードの置換／ダミー作成を行う必要があります。 10. オリジナルとは異なる名前を使用して新しいデータベースを作成した場合は、DOS／エクスプローラを使用してファイルの名前を変更し、dblog を実行してログ・ファイルの名前を変更します。 DBLOG -t asademo.log asademo.dbデータが完全で正確であることを確認するのは、お客様の責任となります。 |
||||||||||||||||||||||||||||||||||||||||||||||
 BACK : 技術情報（TechDoc）のトップページ |
||||||||||||||||||||||||||||||||||||||||||||||
 |
||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Copyright 2008-2010 iAnywhere Solutions K.K. |