ORA-00054：リソースがビジーで、NOWAITを指定して取得するか、タイムアウトの期限が切れました

テーブルを更新すると、このデータベースエラーが発生するのはなぜですか？

1行目のエラー：ORA-00054：リソースがビジーで、NOWAITを指定して取得するか、タイムアウトの期限が切れました

テーブルは既にいくつかのクエリによってロックされています。たとえば、「select for update」を実行し、まだコミット/ロールバックしておらず、別の選択クエリを実行していない可能性があります。クエリを実行する前に、コミット/ロールバックを実行します。

ここからORA-00054：リソースはビジーで、NOWAITを指定して取得します

また、sql、username、machine、port情報を検索して、接続を保持する実際のプロセスを取得することもできます

SELECT O.OBJECT_NAME, S.SID, S.SERIAL#, P.SPID, S.PROGRAM,S.USERNAME,
S.MACHINE,S.PORT , S.LOGON_TIME,SQ.SQL_FULLTEXT 
FROM V$LOCKED_OBJECT L, DBA_OBJECTS O, V$SESSION S, 
V$PROCESS P, V$SQL SQ 
WHERE L.OBJECT_ID = O.OBJECT_ID 
AND L.SESSION_ID = S.SID AND S.PADDR = P.ADDR 
AND S.SQL_ADDRESS = SQ.ADDRESS;

Oracleセッションを強制終了してください

以下のクエリを使用してアクティブなセッション情報を確認してください

SELECT
    O.OBJECT_NAME,
    S.SID,
    S.SERIAL#,
    P.SPID,
    S.PROGRAM,
    SQ.SQL_FULLTEXT,
    S.LOGON_TIME
FROM
    V$LOCKED_OBJECT L,
    DBA_OBJECTS O,
    V$SESSION S,
    V$PROCESS P,
    V$SQL SQ
WHERE
    L.OBJECT_ID = O.OBJECT_ID
    AND L.SESSION_ID = S.SID
    AND S.PADDR = P.ADDR
    AND S.SQL_ADDRESS = SQ.ADDRESS;

のように殺す

alter system kill session 'SID,SERIAL#';

（たとえば、alter system kill session '13,36543';）

リファレンス http://abeytom.blogspot.com/2012/08/finding-and-fixing-ora-00054-resource.html

この問題の回避策は非常に簡単です。

セッションで10046トレースを実行した場合（google this ...説明が多すぎます）。DDL操作の前にOracleが次のことを行うことがわかります。

テーブル 'TABLE_NAME'をロックしてください

したがって、別のセッションで開いているトランザクションがある場合、エラーが発生します。だから修正は...ドラムロールをお願いします。DDLの前に独自のロックを発行し、「NO WAIT」を省略します。

特記事項：

パーティションを分割/削除する場合、Oracleはパーティションをロックするだけです。-つまり、パーティションサブパーティションをロックするだけです。

次の手順で問題を解決します。

1. ロックテーブル 'テーブル名'; -あなたは「待つ」ことになります（開発者はこれをぶら下げと呼んでいます）。開いているトランザクションのセッションがコミットされるまで。これはキューです。あなたの前にいくつかのセッションがあるかもしれません。エラーは発生しません。
2. DDLを実行します。DDLはNO WAITでロックを実行します。ただし、セッションがロックを取得しました。だからあなたは良いです。
3. DDLは自動コミットします。これにより、ロックが解放されます。

テーブルがロックされている間、DMLステートメントは「待機」するか、開発者がそれを「ハング」します。

パーティションを削除するジョブから実行されるコードでこれを使用します。正常に動作します。これは、数百挿入/秒の速度で常に挿入されているデータベースにあります。エラーはありません。

あなたが疑問に思っているなら。11gでこれを行う。過去にもこれを10gでやったことがあります。

このエラーは、リソースがビジーのときに発生します。クエリに参照制約があるかどうかを確認します。または、クエリで言及したテーブルでさえビジーである可能性があります。彼らは、次のクエリ結果に間違いなくリストされる他の仕事に従事している可能性があります。

SELECT * FROM V$SESSION WHERE STATUS = 'ACTIVE'

SIDを見つけます。

SELECT * FROM V$OPEN_CURSOR WHERE SID = --the id

これは、テーブルの変更に使用されたセッション以外のセッションが、DML（更新/削除/挿入）が原因でロックを保持している場合に発生します。新しいシステムを開発している場合、あなたまたはあなたのチームの誰かが更新ステートメントを発行し、あまり影響なくセッションを終了する可能性があります。または、誰がセッションを開いているかがわかったら、そのセッションからコミットできます。

SQL管理システムにアクセスできる場合は、それを使用して問題のセッションを見つけます。そしておそらくそれを殺します。

v $ sessionやv $ lockなどを使用することもできますが、そのセッションを見つける方法と、それを強制終了する方法をググるように勧めます。

実動システムでは、それは本当に依存します。Oracle 10g以前の場合、次のコマンドを実行できます

LOCK TABLE mytable in exclusive mode;
alter table mytable modify mycolumn varchar2(5);

別のセッションで、時間がかかりすぎる場合に備えて次の準備をします。

alter system kill session '....

それはあなたが持っているシステムに依存します、古いシステムは毎回コミットしない可能性が高くなります。ロックが長く続く可能性があるため、これは問題です。したがって、あなたのロックは新しいロックを防ぎ、いつ解放されるかを知っているロックを待ちます。これが、他のステートメントの準備ができている理由です。または、同様の処理を自動的に実行するPLSQLスクリプトを探すこともできます。

バージョン11gには、待機時間を設定する新しい環境変数があります。それはおそらく私が説明したものと同様の何かを行うと思います。ロックの問題は解消されないことに注意してください。

ALTER SYSTEM SET ddl_lock_timeout=20;
alter table mytable modify mycolumn varchar2(5);

最後に、システム内にこの種のメンテナンスを行うユーザーが少なくなるまで待つのが最善です。

私の場合は、自分のセッションの 1つがブロックしていることを確信していました。したがって、以下を実行しても安全でした。

• 私は問題のあるセッションを見つけました：

  SELECT * FROM V$SESSION WHERE OSUSER='my_local_username';

  セッションは非アクティブでしたが、それでも何らかの理由でロックが保持されていました。場合によっては、他のWHERE条件を使用する必要があることに注意してください（たとえば、try USERNAMEまたはMACHINEfields）。

• を使用してセッションを終了し、上記IDでSERIAL#取得しました。

  alter system kill session '<id>, <serial#>';

@thermzによる編集：以前のオープンセッションクエリがどれも機能しない場合は、これを試してください。このクエリは、セッションを強制終了するときに構文エラーを回避するのに役立ちます。

• SELECT 'ALTER SYSTEM KILL SESSION '''||SID||','||SERIAL#||''' immediate;' FROM V$SESSION WHERE OSUSER='my_local_username_on_OS'

セッションを保持しているプロセスを確認し、それを強制終了してください。正常に戻った。

以下のSQLはあなたのプロセスを見つけるでしょう

SELECT s.inst_id,
   s.sid,
   s.serial#,
   p.spid,
   s.username,
   s.program FROM   gv$session s
   JOIN gv$process p ON p.addr = s.paddr AND p.inst_id = s.inst_id;

その後、それを殺します

ALTER SYSTEM KILL SESSION 'sid,serial#'

または

オンラインで見つけたいくつかの例では、インスタンスIDを変更し、システムのkillセッション '130,620、@ 1'を変更する必要があるようです。

DML操作とDDL操作が混在しているように見えます。この問題を説明している次のURLを参照してください。

http://www.orafaq.com/forum/t/54714/2/

テーブルを作成するだけでこのエラーが発生しました！まだ存在していないテーブルには明らかに競合の問題はありませんでした。CREATE TABLE声明は含まれてCONSTRAINT fk_name FOREIGN KEYよく人口テーブルを参照するWHERE句を。そうしなければならなかった：

• CREATE TABLEステートメントからFOREIGN KEY句を削除する
• FK列にINDEXを作成します
• FKを作成する

2つのスクリプトを実行していたときに、このエラーが発生しました。私が持っていた：

• スキーマユーザーアカウント（アカウント＃1）を使用して直接接続されたSQL * Plusセッション
• 別のSQL * Plusセッションは、異なるスキーマユーザーアカウント（アカウント＃2）を使用して接続しましたが、データベースリンクを介して最初のアカウントとして接続しました

テーブルドロップを実行してから、アカウント＃1としてテーブルを作成しました。アカウント＃2のセッションでテーブルの更新を実行しました。変更をコミットしませんでした。アカウント＃1としてテーブルのドロップ/作成スクリプトを再実行しました。でエラーが発生しましたdrop table xコマンドで。

COMMIT;アカウント＃2のSQL * Plusセッションで実行することで解決しました。

私も同様の問題に直面しています。このエラーを解決するためにプログラマが行うべきことは何もありません。オラクルDBAチームに連絡しました。彼らはセッションを殺し、魅力のように働いた。

シャシのリンクで与えられた解決策は最高です... dbaや誰かに連絡する必要はありません

バックアップを作成

create table xxxx_backup as select * from xxxx;

すべての行を削除

delete from xxxx;
commit;

バックアップを挿入します。

insert into xxxx (select * from xxxx_backup);
commit;