집 > 기사 > 데이터 베이스 > Oracle 잠금 테이블 솔루션에 대한 자세한 그래픽 및 텍스트 설명

Oracle 잠금 테이블 솔루션에 대한 자세한 그래픽 및 텍스트 설명

WBOY앞으로: 2022-08-17 18:13:513186검색

이 기사에서는 Oracle에 대한 관련 지식을 제공합니다. Oracle 데이터베이스를 개발할 때 자주 사용되는 Oracle 데이터 테이블이 있는데, Oracle 잠금 테이블에 대한 솔루션을 소개합니다. 이 방법은 모든 사람에게 도움이 될 것입니다.

추천 튜토리얼: "Oracle Video Tutorial"

DML 문에서 자주 발생하는 테이블 잠금 또는 잠금 시간 초과는 데이터베이스 실행 시 발생하는 문제입니다. DML 문 트랜잭션이 커밋 또는 롤백되거나 현재 세션이 강제 종료될 때까지 테이블 또는 행 데이터가 잠깁니다.

우리 응용 프로그램 시스템의 경우 SQL 실행이 느리고 타임아웃이 없는 경우(어떤 이유로 SQL이 성공적으로 실행되지 않았고(Spoon 도구가 데이터 추출 및 푸시를 수행함) 리소스가 해제되지 않은 경우) 테이블 잠금이 발생할 가능성이 높습니다. 따라서 효율적인 SQL을 작성하는 것도 특히 중요합니다! 높은 동시성 시나리오인 테이블 잠금이 발생할 수 있는 다른 상황이 있습니다. 높은 동시성으로 인해 발생하는 문제는 Spring 트랜잭션으로 인해 데이터베이스 트랜잭션이 커밋되지 않고 교착 상태가 발생한다는 것입니다(현재 트랜잭션은 다른 트랜잭션이 잠금 리소스를 해제하기를 기다리고 있습니다). )! 따라서 java.sql.SQLException: Lock wait timeout 초과; 예외가 발생합니다.

그렇다면 잠금 테이블이나 잠금 시간 초과를 해결하는 방법은 무엇일까요? 임시 해결책은 잠금 리소스를 놓고 경쟁하는 테이블이나 명령문을 찾아서 현재 세션이나 세션을 직접 종료하고 잠금 리소스를 강제로 해제하는 것입니다. 예를 들어

해결책은 다음과 같습니다.

1. Session1은 특정 데이터를 수정하지만 트랜잭션을 제출하지 않습니다. Session2는 커밋되지 않은 트랜잭션의 기록을 쿼리합니다

수정된 내용을 볼 수 있습니다. 커밋되지 않은 트랜잭션의 기록은 상대방이 잠금 리소스를 해제하거나 세션을 강제로 닫을 때까지 대기 상태에 있습니다.1. 이는 또한 Oracle이 행 수준 잠금을 달성했음을 보여줍니다!

이것은 테이블 잠금 상황에 대한 간단한 시뮬레이션입니다. Session1에 의한 테이블 잠금임을 한눈에 알 수 있습니다. 실제 개발에서 이런 상황에 직면하게 되면 대개 SQL을 사용하여 Lock 자원을 놓고 경쟁하는 테이블이나 문장을 직접 찾아낸 후 강제로 자원을 해제해 줍니다! !

3. Session3은 경쟁 리소스의 테이블이나 명령문을 쿼리하고 리소스를 강제 해제합니다.

-- 查询未提交事务的session信息，注意执行以下SQL，用户需要有DBA权限才行
SELECT
    L.SESSION_ID,
    S.SERIAL#,
    L.LOCKED_MODE AS 锁模式,
    L.ORACLE_USERNAME AS 所有者,
    L.OS_USER_NAME AS 登录系统用户名,
    S.MACHINE AS 系统名,
    S.TERMINAL AS 终端用户名,
    O.OBJECT_NAME AS 被锁表对象名,
    S.LOGON_TIME AS 登录数据库时间
FROM V$LOCKED_OBJECT L
    INNER JOIN ALL_OBJECTS O ON O.OBJECT_ID = L.OBJECT_ID
    INNER JOIN V$SESSION S ON S.SID = L.SESSION_ID
WHERE 1 = 1

쿼리 결과는 다음과 같습니다

예를 들어 처음 두 필드만 유용합니다. ,

-- 强制 结束/kill 锁表会话语法
ALTER SYSTEM KILL SESSION &#39;SESSION_ID, SERIAL#&#39;;

-- 强制杀死session1，让session2可以修改id=5的那条记录
ALTER SYSTEM KILL SESSION &#39;34, 111&#39;;

세션1을 강제로 종료한 후, 세션2의 실행에 주의하세요! session2의 대기가 종료되고 즉시 실행되는 것을 볼 수 있습니다! session_id가 29와 34인지, session1에 속하는지 아니면 session2에 속하는지 어떻게 확인하고, session1이 종료되고 session2가 DML 문을 성공적으로 실행할 수 있는지 확인하는 방법은 무엇입니까?

사실 매우 간단합니다. 여기서 판단 방법은 session1 실행입니다. 트랜잭션을 업데이트하고 커밋하지 않으려면 먼저 위 SQL을 사용하여 커밋되지 않은 트랜잭션의 세션 정보를 쿼리할 수 있습니다. 이때 찾은 정보는 session1의 정보입니다.

Oracle 잠금 테이블 솔루션에 대한 자세한 그래픽 및 텍스트 설명

해결책은 다음과 같습니다.

관련 기사