안녕? 나야 :)

■ TX LOCK 1. 특정 행을 변경하고자 하는 경우 enq : TX - row lock contention create table hr.emp as select * from hr.employees; update hr.emp set salary = 2000 where employee_id = 200; delete from hr.emp where employee_id = 200; -- waiting 단계 모니터링 select sid, serial#, username, blocking_session, event, sql_id, prev_sql_id from v$session where event like '%TX%'; #) 현재 sql_id 확인해야 한다. => enq: TX - row lock conte..

■ Redo 기능 - Database '복구'를 목적으로 설계 - Database에 적용된 모든 변경 사항에 대한 이력 저장 - DML/DDL/Recursive SQL(select .. from .. for update : lock)에 의해 변경된 모든 Data 이력 (nologging 제외) - DDL Text 저장 (DML Text 제외) ■ LGWR에 의한 Redo 기록 - Redo Buffer 내용을 Redo Log File 에 기록하는 시점 - 매 3초 마다 - Log Buffer의 1/3 또는 1MB 가 저장될 때 - User Process가 Commit 또는 Rollback으로 Transaction을 종료할 때 (Log Force at Commit) - DBWR Process(발생하기 전)에..

■ Transaction 처리 순서 1. Undo Segment 할당 - 트랜잭션이 시작되면 undo segment를 할당받는다. - 만약 할당받지 못한다면 "enq: US - contention" 대기 이벤트가 발생한다. 2. Undo Segment Header에 Transaction Table Slot 생성 - Undo segment header에 트랜잭션 테이블 슬롯(Transaction Table Slot)을 생성. - 트랜잭션 정보, 즉 TXID(Transaction ID)를 생성. 3. Data Buffer Cache에서 대상 블록 찾기 - 트랜잭션의 대상이 되는 블록을 실행 계획을 통해 data buffer cache에서 찾는다. - 블록 헤더에 ITL(Interested Transactio..

[FLM(FreeList Management)] : 테이블 및 인덱스의 블록 내에서 여유 공간을 관리하는 기술 1. Free List 2. 리스트 형태의 공간 관리 3. Hot 및 Cold Region #) tablespace 생성 , management manual 로 생성 create tablespace flm_tbs datafile '/u01/app/oracle/oradata/ora11g/flm_tbs01.dbf' size 100m autoextend on extent management local uniform size 1m segment space management manual; ---------------- HR sess_1 ---------------- => storage..

■ Buffer Busy Wait - 동일한 데이터 블록에 대한 액세스에서 발생한 대기. - 특시, 같은 데이터 블록에서 서로 다른 행을 조회하거나 변경하는 동시성 상황에서 발생한다. ▶ 대기 상황 1. 조회 시 (Shared Mode) - 한 세션이 데이터 블록을 shared mode 로 읽고 있는데, 다른 세션이 동일한 블록의 서로 다른 행을 배타적인 모드(exclusive mode)로 변경. 2. 변경 시(Exclusive Mode) - 한 세션이 데이터 블록을 배타적인 모드(exclusive mode)로 변경 중인데, 다른 세션이 동일한 블록의 서로 다른 행을 읽거나 변경하려고 할 때 발생. ▶ 대응 방법 1. 트랜잭션 디자인 수정 : 서로 다른 행에 대한 액세스 충돌을 최소화하는 트랜잭션의 설계..

■ row cache lock - row cache lock : 'dictionary cache' 또는 'row cache' 에 관련된 정보에 접근하거나 수정하는 경우 발생하는 시스템 lock 이다. - oracle dictionary 정보에 대한 cache 영역으로, 유저, 테이블, 인덱스, 시퀀스, 컬럼, 함수, 프로시저, 패키지, 트리거 등 ▶ 주로 딕셔너리 객체를 조작하는 DDL 작업이나 SQL문이 실행될 때 발생 ▶ DDL 작업(테이블 생성, 수정, 삭제 등)을 수행하면 딕셔러리 정보가 입력, 수정, 삭제 → 딕셔러리 경합 발생 ex) 시퀀스 object (주문발생) ▶ SQL문 수행 시에 semantic(의미론적) 분석, 권한 체크 시 → 딕셔러리 정보를 이용해서 체크한다. - row cach..

■ version count (child LCO 많이 생성된다.) 1. 테이블이나 인덱스의 구조 변경 : DDL 문을 통해 구조가 변경되는 경우 2. 버전 관리 동시성 제어 : 멀티 버전 동시에 제어 지원. - 트랜잭션의 시작 시검에 따라 특정 데이터의 이전 버전에 접근할 수 있다. 3. DBMS_REDEFINITION 패키지 : 테이블이나 인덱스의 구조 변경 예제1) alter system flush shared_pool; # varchar2 size(32, 128, 2000, 4000) 4가지 크기로 결정된다. (참고) # 바인드변수 사용 # 1#) 익명블록, 트리거에서 바인드 변수(글로벌 변수로 사용하기 위함) 생성 가능. 2#) 패키지, 프로시저, 함수 : 글로벌 변수_ 패키지 스펙+body --..

■ shared pool latch & 서브 풀 1. Shared Pool Latch - Hard Parsing이 발생할 때, 즉 SQL 문이 처음 분석되고 실행 계획이 생성되어야 할 때, 해당 SQL 문에 대한 메모리를 할당받기 위해 Shared Pool Latch를 획득해야 한다. Shared Pool Latch는 여러 세션 간에 공유 메모리 영역인 Shared Pool의 자원을 보호하기 위한 lock이다. 2. Shared Pool Subpooling (서브풀링) - Oracle 9i 이후부터는 Shared Pool을 여러 개의 서브풀(subpool)로 나누어 관리한다. 이는 고성능을 유지하기 위한 메커니즘이며, CPU 개수가 4개 이상이고 Shared Pool 메모리 크기가 250MB 이상인 경우..

■ Library Cache Pin - SQL문장이나 PL/SQL 객체를 고정하여 여러 session에서 공유되는 것을 보장하는 lock이다. 이는 공유 자원에 대한 동시 접근을 통제하여 데이터베이스의 일관성과 무결성을 유지하는 데 사용한다. 1. SQL문 hard parsing ▶ library cache pin을 exclusive mode 획득한다. - SQL문장이 처음 parsing 될때 해당 SQL 문장을 다른 session이 변경하지 못하도록 보호한다. 2. SQL문 execute 단계 ▶ library cache pin을 shared mode 획득한다. - 다른 session에서 동시에 동일한 SQL문장을 실행 할 수 있도록 한다. 3. SQL문 fetch 단계 ▶ library cache p..

=> 새롭게 접속 후 진행하기 #) 대량의 data 로드 하기 create table hr.test(id number, name char(10)); insert into hr.test select rownum, lpad(rownum, 10, '0') from dual connect by level alter문 확인되지 않음. 놓치는 경우가 있을 수 있다. select sql_text from v$sql where sql_id = '1mat065c25crk'; #) library cache 보는 위한 쿼리문 alter table hr.test modify name char(30); select count(*) from hr.test; select h.sid, substr(s.sql_text, 1 , 40)..