ORA-00054: 리소스가 사용 중이고 NOWAIT가 지정되어 있거나 타임아웃이 만료되었습니다.

ORA-00054: 리소스가 사용 중이고 NOWAIT가 지정되어 있거나 타임아웃이 만료되었습니다.

테이블을 갱신할 때 이 데이터베이스 오류가 발생하는 이유는 무엇입니까?

1행 오류: ORA-00054: 리소스가 사용 중이며 NOWAIT가 지정되었거나 시간 초과되었습니다.

일부 쿼리에 의해 테이블이 이미 잠겨 있습니다.예를 들어 "업데이트 선택"을 실행했지만 아직 커밋/롤백하지 않고 다른 선택 쿼리를 실행했을 수 있습니다.쿼리를 실행하기 전에 커밋/롤백을 수행합니다.

from here ORA-00054: 리소스 사용 중 및 NOWAIT 지정으로 취득

또한 SQL, 사용자 이름, 머신, 포트 정보를 검색하여 연결을 유지하는 실제 프로세스를 확인할 수 있습니다.

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 트레이스를 실행하는 경우(구글 검색...)설명하기에 너무 많다.)DDL 작업을 수행하기 전에 Oracle이 다음을 수행합니다.

잠금 테이블 '탭LE_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

제 경우, 제 세션 중 하나가 차단되고 있다고 확신했습니다.따라서 다음 작업을 수행하는 것이 안전합니다.

• 문제가 되는 세션은 다음과 같습니다.

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

  세션은 비활성 상태였지만 어떻게든 잠금이 걸려 있었습니다.주의: 고객님의 경우 다른 WHERE 조건을 사용해야 할 수 있습니다(예: 시도).USERNAME ★★★★★★★★★★★★★★★★★」MACHINE□□□□□□□□★

• 을 종료합니다.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'

이 문제는 테이블 변경에 사용되는 세션 이외의 세션이 DML(업데이트/삭제/삽입) 때문에 잠금을 유지하고 있을 때 발생합니다.새로운 시스템을 개발 중인 경우 사용자 또는 팀원 중 누군가가 업데이트 스테이트먼트를 발행할 가능성이 높기 때문에 큰 영향 없이 세션을 종료할 수 있습니다.또는 누가 세션을 열었는지 알게 되면 해당 세션에서 커밋할 수 있습니다.

SQL 관리 시스템에 액세스할 수 있는 경우 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);

마지막으로 시스템에 이러한 종류의 유지보수를 수행할 사용자가 거의 없을 때까지 기다리는 것이 가장 좋습니다.

select
   c.owner,
   c.object_name,
   c.object_type,
   b.sid,
   b.serial#,
   b.status,
   b.osuser,
   b.machine
from
   v$locked_object a,
   v$session b,
   dba_objects c
where
   b.sid = a.session_id
and
   a.object_id = c.object_id;
   
   ALTER SYSTEM KILL SESSION 'sid,serial#';

다른 응답에서 설명한 바와 같이 이 오류는 다른 세션에서 동시에 실행되는 DML 조작에 의해 발생합니다.이로 인해 Oracle은 기본 NOWAIT 옵션을 사용하여 DDL의 테이블을 잠글 수 없습니다.

데이터베이스에 관리자 권한이 없거나 다른 세션을 종료/중지할 수 없는 사용자의 경우 DDL 작업을 수행하기 전에 다음을 수행할 수도 있습니다.

alter session set DDL_LOCK_TIMEOUT = 30;
--Run your DDL command, e.g.: alter table, etc.

백그라운드 작업이 대규모 삽입/업데이트 작업을 수행하는 데이터베이스에서 이 오류가 반복적으로 발생했으며 세션에서 이 파라미터를 변경하면 잠금이 설정될 때까지 몇 초 정도 기다린 후 DDL을 계속할 수 있었습니다.

자세한 내용은 이 답변에 대한 rshdev의 코멘트, Oracle 기반의 엔트리 또는 DDL_LOCK_TIMEOUT의 공식 문서를 참조하십시오.

세션을 보류하고 있는지 확인하고 종료하기만 하면 됩니다.정상으로 돌아왔어

아래 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와 시스템 킬 세션 '130,620,@1'을 변경해야 할 것 같습니다.

실행 중인 스크립트가 2개 있을 때 이 오류가 발생했습니다.나는 다음을 가지고 있었다.

• 스키마 사용자 계정(계정 #1)을 사용하여 직접 연결된 SQL*Plus 세션
• 다른 스키마 사용자 계정(계정 #2)을 사용하여 연결된 다른 SQL*Plus 세션이 첫 번째 계정으로 데이터베이스 링크를 통해 연결됨

테이블 드롭을 실행한 후 계정 #1로 테이블을 생성했습니다.2번 계정의 세션에서 테이블 업데이트를 실행했습니다.변경을 커밋하지 않았습니다.테이블 드롭/생성 스크립트를 계정 #1로 재실행합니다.에러가 발생했습니다.drop table x명령어를 입력합니다.

뛰어서 해결했다.COMMIT;계정 #2의 SQL*Plus 세션에 있습니다.

이 문제는 DML과 DDL 연산이 혼재하고 있는 것 같습니다.이 문제에 대해서는, 다음의 URL 를 참조해 주세요.

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

테이블을 만들 때 이 오류를 볼 수 있었습니다!분명히 아직 존재하지 않는 테이블에는 경합 문제가 없었다.그CREATE TABLE에는 「」가 되어 있습니다.CONSTRAINT fk_name FOREIGN KEY잘 채워진 테이블을 참조하는 절.어쩔 수 없었어요.

• CREATE TABLE 문에서 FORENAL KEY 절을 제거합니다.
• FK 열에 INDEX 생성
• FK 작성

IDE 탭 중 하나를 닫아서 이 문제를 해결했습니다.

PL/SQL 개발자 버전 10.0.5.1710

나 또한 비슷한 문제에 직면해 있다.이 오류를 해결하기 위해 프로그래머가 할 필요가 없습니다.오라클 DBA 팀에게 알렸습니다.그들은 세션을 망치고 마법처럼 일했다.

샤시의 링크가 주는 해결책은 최고...dba나 다른 사람에게 연락할 필요가 없다

백업을 하다

create table xxxx_backup as select * from xxxx;

모든 행을 삭제하다

delete from xxxx;
commit;

백업을 삽입합니다.

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

언급URL : https://stackoverflow.com/questions/4842765/ora-00054-resource-busy-and-acquire-with-nowait-specified-or-timeout-expired