1

誤って、dbaccess セッションを使用して Informix でこのクエリを実行しました。

Delete from table #without where condition

を使うべきだったという自分の間違いに気づき、TRUNCATE私はまた愚かなことをしました。セッション
を終了しました。dbaccessしかし、テーブルは排他的にロックされており、そのテーブルに対してアクションを実行できません。

truncateロックとテーブルを削除するために私ができる手順は何ですか?

1) Restart Informix server
2) onmode -z <sessionid>  # Does not work. 
                            I see hell lot of sessions created for the delete query

この問題を解決する他の簡単な方法はありますか?

4

1 に答える 1

1

Informix SE を使用していないと仮定すると...

データベースはログに記録されていますか? その場合、明示的な (BEGIN WORK) トランザクション内でステートメントを実行しましたか?

分析

ログに記録されていないデータベースがある場合、サーバーが削除した各行はなくなります。DELETE を停止しても、部分的に完了した変更は取り消されません。ログに記録されていないデータベースを使用するということは、保証されたステートメント レベルの回復が必要ないことを意味します。

通常のログに記録されたデータベースがあり、明示的なトランザクションがない場合、DB-Access セッションが終了した後もステートメントが実行されている可能性があります。シングルトン ステートメントとして実行されているため、完了してコミットされます。それが完了するまで、サーバーを強制的に停止すると、高速リカバリによってステートメント (トランザクション) がロールバックされます。「5 時間前」と表示されていることを考えると、今すぐにサーバーをダウンさせる可能性は限られているのではないかと心配しています。

明示的なトランザクションでログに記録されたデータベース、または MODE ANSI データベース (常にトランザクション内にある場合) がある場合、DELETE ステートメントが完了すると、サーバーは COMMIT を待機し、セッション接続が終了し、コミットされていない作業をロールバックします。

回復

ログに記録されていないデータベースがある場合は、最後のアーカイブまでしか復元できません。ログに記録されていないため、論理ログから復元することはできません (ただし、ログに記録されている同じインスタンス内の他のデータベースは、最後の論理ログまで復元できます)。

ログに記録されたデータベースがあり、DELETE ステートメントが完了する前に、できれば制御下でサーバーをダウンさせることができますが、必要に応じてサーバーをクラッシュさせることができれば、高速復旧によって問題が処理されます。

DELETE が完了してコミットされ、適切なバックアップがある場合は、データベースのポイント イン タイム リストアを検討できます。その間、オフラインになります (ただし、テーブルのデータがすべて失われると、DB はしばらく機能しなくなります)。

これらのシナリオのいずれにも当てはまらない場合は、IBM テクニカル サポートに連絡する必要があります。

しかし、お気づきかもしれませんが、データベースの種類 (ログなし、ログあり、MODE ANSI) と、ステートメントを実行したときに有効な明示的なトランザクションがあったかどうかによって、多くのことが異なります。

DBMS の問題点は、信頼できる生き物であることです。あなたが手術を行う権限を与えられている場合、彼らは、あなたがやりたいと言ったことをあなたが行うつもりであると想定し、先に進み、能力を最大限に発揮します. 要求したことを実行するように要求しないと、人生は厄介になります。DBMS は引き続きユーザーを信頼し、ユーザーが実際に要求したことを実行します。

于 2012-09-25T18:23:09.950 に答える