Oracle에서 날짜/시간은 소수점으로 시간 단위를 표현합니다.

• 1 = 1일
• 1/24 = 1시간
• 1/1440 = 1분 (1 / (24 * 60))
• 1/144 = 약 10분 (1 / (24 * 6))

그러므로:

1/24/(60/10) = 1/144 = 10분(interval of 10 minutes)

• 이벤트 이름: DLM cross inst call completion
• 상황: 한 RAC 인스턴스의 세션이 다른 인스턴스에 있는 리소스(락, 캐시 블록 등)에 접근하려 할 때, DLM을 통해 cross-instance 호출을 하며, 그 호출이 완료되기를 기다리는 시간 동안 이 대기 이벤트가 발생합니다.
• 유형: 일반적으로 GC(Global Cache) 관련 처리 또는 락 해제, 변경, 동기화와 관련되어 있습니다.

📋 주요 발생 원인

블록 클린아웃은 트랜잭션에 의해 설정된 로우 Lock을 해제하고 블록 헤더에 커밋 정보를 기록하는 오퍼레이션이다.

대량의 갱신 작업이 있고 나서는 해당 블록들을 일일이 찾아 다니며 클린아웃을 수행하려면 시간이 오래 걸려 오라클은 대량 갱신 작업 후에는 커밋 정보를 트랜잭션 테이블에만 기록하고 커밋을 빠르게 끝낸다.

항상 이 방식으로 작동하는것은 아니며, 오라클은 delayed 블록 클린 아웃과 커밋 클린아웃 두 가지 매커니즘을 사용한다.

(1) Delayed 블록 클린아웃

트랜잭션이 갱신한 블록 개수가 총 버퍼 캐시 블록 개수의 1/10을 초과할 때 사용하는 방식이다. 커밋 이후 해당 블록을 액세스하는 첫 번째 쿼리에 의해 클린아웃이 이루어지며, 이때 아래와 같은 작업을 수행한다.

1. ITL 슬롯에 커밋 정보 저장 --> active 상태의 블록이, 다른 트랜잭션이 변경 시킨 사항이 ITL에 아직 기록되지 않았다면 ITL슬롯에 기록된 트랜잭션 ID를 이용해 undo 세그먼트 헤더에 있는 트랜잭션 테이블 슬롯을 찾아가 현재 상태를 확인하고 커밋된 상태면 이를 ITL슬롯에 반영.

2. 레코드에 기록된 lock byte 해제

3. online redo에 logging

(2) 커밋 클린아웃(=fast 블록 클린아웃) 

트랜잭션이 갱신한 블록 개수가 버퍼 캐시 블록 개수의 1/10을 초과하지 않을때는 커밋 시점에 곧바로 블록 클린아웃을 수행한다.

다만, 이 경우에도 커밋 시점에는 '불완전한 형태의 클린아웃'을 수행하며 해당 블록을 갱신하는 다음 트랜잭션에 의해 완전한 클린아웃이 이루어진다.

ITL 슬롯에 커밋 정보만 저장하고 로우 헤더의 lock byte는 해제하지 않는다. 

즉 커밋 클린아웃시에는 online redo에 로그를 남기지 않는다. 로깅 시점을 미룸

그러고 나서 해당 블록을 갱신하려고 currnt 모드로 읽는 시점에 비로소 lock byte를 해제하고 완전한 클린아웃을 수행함.

그리고 그 내역을 online redo 에 로깅. 이를 delayed 로깅 블록 클린 아웃이라고 부름.

db 기동 시 발생하는 ORA 메세지

해결 방법 : 파라미터 파일에서 사용되지 않는 파라미터 제거

위 메세지는 해당 버전에서 지원하지 않는 파라미터를 파라미터파일에 삽입했을 때 발생하는 에러메세지임

현재 버전에서 지원하지않는(deprecated) 파라미터 목록 확인

현재 파라미터 파일 확인

spfile 을 사용하고 있어서 보기 좋게 pfile을 생성

현재 db 의 파라미터 파일 확인

확인 결과 지원하지 않는 파라미터인 sec_case_sensitive_logon 파라미터가 적용되어 있음

해당 파라미터 제거

db 재기동 후 확인

ORA 메세지가 발생하지 않음

원인 : 해당 버전에서 지원하지 않는 파라미터 사용

해당 버전에서 지원하지 않는 파라미터를 파라미터파일에 삽입했을 때 발생하는 에러메세지임

해당 파라미터를 제거해줌으로서 해결

12cR1 문서에 아래와 같이 호환성을 위해서만 유지된다고 나와있음

https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=vorrc9qj7_53&_afrLoop=154992560185424#SYMPTOM

Doc ID 2939270.1
***********************************************************************
Fatal NI connect error 12637, connecting to:
 (LOCAL=NO)

  VERSION INFORMATION:
        TNS for IBM/AIX RISC System/6000: Version 12.2.0.1.0 - Production
        TCP/IP NT Protocol Adapter for IBM/AIX RISC System/6000: Version 12.2.0.1.0 - Production
        Oracle Bequeath NT Protocol Adapter for IBM/AIX RISC System/6000: Version 12.2.0.1.0 - Production
  Time: 27-APR-2025 12:18:14
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12637

TNS-12637: Packet receive failed
    ns secondary err code: 12532
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0
Sun Apr 27 12:18:14 2025
opiodr aborting process unknown ospid (35324084) as a result of ORA-609
***********************************************************************


***********************************************************************

Fatal NI connect error 12170.

  VERSION INFORMATION:
        TNS for IBM/AIX RISC System/6000: Version 12.2.0.1.0 - Production
        TCP/IP NT Protocol Adapter for IBM/AIX RISC System/6000: Version 12.2.0.1.0 - Production
        Oracle Bequeath NT Protocol Adapter for IBM/AIX RISC System/6000: Version 12.2.0.1.0 - Production
  Time: 27-APR-2025 07:43:32
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12535

TNS-12535: TNS:operation timed out
    ns secondary err code: 12606
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0
  Client address: <unknown>
Sun Apr 27 07:43:32 2025
opiodr aborting process unknown ospid (28049744) as a result of ORA-609
Sun Apr 27 07:46:31 2025


***********************************************************************

oracleasm과 UDEV은 둘 다 Oracle ASM에서 디스크를 식별하고 접근할 수 있도록 도와주는 디바이스 레이어 매핑 방식이지만, 방식과 유연성, 관리 측면에서 차이가 있습니다. 아래에서 둘의 차이를 비교해볼게요.

✅ 1. 개념적 차이

✅ 2. 구성 및 사용 방법

oracleasm

• Oracle에서 제공하는 툴 (oracleasm-support, oracleasm-lib)
• oracleasm createdisk, oracleasm listdisks, oracleasm scandisks 명령 사용
• 디바이스 준비, 파라미터 설정, ASM에서 바로 인식

UDEV

• 리눅스 기본 udev 시스템 사용
• 디바이스에 대한 규칙을 직접 작성해야 함
• KERNEL==, OWNER=, GROUP=, MODE= 같은 매핑 조건 사용
• 디스크 이름, 소유자, 권한 직접 지정 가능

✅ 3. 장단점 비교

✅ 4. 현재 Oracle의 권장 방식은?

Oracle은 11g까지는 oracleasm을 많이 사용했지만,
12c 이후부터는 UDEV 사용을 더 권장하고 있습니다.

• 이유: 표준 리눅스 방식이고, 더 유연하고 범용성이 좋기 때문
• Oracle 공식 문서에서도 UDEV 기반으로 ASM 디스크 구성하는 예제가 많습니다

✅ 결론 정리

✅ 1. ASM 디스크 물리 경로 확인

oracleasm 사용 시:

→ 결과:

→ 실제 물리 디바이스: /dev/sdb1

UDEV 사용 시 (oracleasm 미사용)

보통 /dev/mapper/, /dev/oracleasm/disks/, /dev/asmdisk*, /dev/sdX, /dev/nvmeXnXpX 등이 될 수 있습니다.
UDEV 매핑 규칙은 /etc/udev/rules.d/99-oracle-asm.rules 등에 정의돼 있어요.

🔎 2. 디스크 접근 권한 확인

디바이스의 퍼미션, 소유자, 그룹을 확인합니다:

결과 예시:

꼭 확인해야 할 조건:

🧑‍💼 3. grid 사용자가 접근 가능한지 확인

• 에러 없이 1+0 records in 이렇게 나오면 접근 OK.
• Permission denied → UDEV/소유권 문제 있음.

🛠️ 4. 권한 수정 예시 (root 사용자로 실행)

또는 UDEV를 사용하는 경우, 규칙 파일 예시:

→ 변경 후 적용:

✅ 정리

$ crsctl stat res -t

--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER        STATE_DETAILS
--------------------------------------------------------------------------------
ora.asm        ONLINE  ONLINE       node1
               ONLINE  ONLINE       node2
ora.LISTENER.lsnr
               ONLINE  ONLINE       node1
               ONLINE  ONLINE       node2
ora.DATA.dg     ONLINE  ONLINE      node1
                ONLINE  ONLINE      node2
ora.FRA.dg      ONLINE  ONLINE      node1
                ONLINE  ONLINE      node2
ora.cssd        ONLINE  ONLINE      node1
                ONLINE  ONLINE      node2
ora.crsd        ONLINE  ONLINE      node1
                ONLINE  ONLINE      node2
ora.evmd        ONLINE  ONLINE      node1
                ONLINE  ONLINE      node2
ora.node1.vip   ONLINE  ONLINE      node1
ora.node2.vip   ONLINE  ONLINE      node2
...

🔧 1. 리소스 기동 정책

리소스(예: DB, Listener, ASM 등)는 Oracle Clusterware에서 자동 기동 여부를 다음 속성으로 관리합니다:

확인 방법 

crsctl status resource -p 

• AUTO_START: CRS 기동 시 리소스를 자동으로 기동할지 여부
  • always : 항상 자동 기동
  • restore : 이전 상태 복원
  • never : 수동으로만 기동

📌 2. 설정 확인 방법

• 예시 출력: AUTO_START=restore

✍️ 3. 설정 변경 방법

예시

1. DB 인스턴스를 항상 자동으로 기동하도록 설정:

1. 리스너 자동 기동 끄기:

1. 변경 후 반영 여부 확인:

🛠️ 4. 기타 관련 속성

• ENABLED: 해당 리소스를 CRS가 관리 대상으로 할지 여부
  • ENABLED=1 → CRS에서 관리함
  • ENABLED=0 → CRS에서 관리하지 않음
  • 변경 방법:
  • bash
    복사편집
    crsctl modify resource ora.orcl.db -attr "ENABLED=0"
• TARGET: 대상 상태 (기동 시도 여부)
  • ONLINE, OFFLINE 등
  • 보통 crsctl start/stop resource 명령으로 수동 제어

✅ 실무 팁

정의

Call이 어디서 발생하느냐에 따라 User Call과 Recursive Call로 나눌 수 있다.

1) User Call : OCI(Oracle Call Interface)를 통해 외부로부터 들어오는 Call

2) Recursive Call : 오라클 내부에서 발생하는 Call, 
- SQL파싱과 최적화 과정에서 발생하는 Data Dictionary 조회, 
- PL/SQL로 작성된 사용자 정의 함수 , Procedure , Trigger로 인한 SQL수행

 특징
1) User Call
User Call 발생 빈도를 결정하는 요소들
 개발자의 기술이 관여
 프레임워크 내에 Array processing을 지원 유무가 중요하다.
 설계 표준 가이드
 사용자 정의 함수/프로시저에 대한 무조건적인 제약
 모듈이 지나치게 단위로 구성되어 SQL이 건건이 호출되는 개발환경

 Loop 쿼리를 해소하고, 집합적 사고를 통해 One-SQL로 구현

 Array Processing : Array 단위 Fetch, Bulk Insert / Update / Delete
 부분범위처리 활용
 효과적인 화면 페이지 처리
 사용자 정의함수 / 프로시저 / 트리거의 적절한 활용

2) Recursive Call
     Hard Parsing에 대해 Recursive Call 발생 

     바인드 변수의 적극적 사용, 하드파싱 횟수 절감을 통해 Recursive Call 감소
     Recursive Depth를 크게 만들지 않게끔 프로시저 구성 ( 프로시저 안에 프로시저가 들어있는 횟수 : Recursive Depth )
     Recursive Depth를 크기 만들지 않게끔 지나친 Procedure의 모듈화를 지양
     대용량 데이터 조회시 함수호출이 건건이 발생하지 않게끔, 함수를 부분범위 처리가 가능한 상황에서,
     제한적으로 사용해야함
    조인 또는 스칼라 서브쿼리 형태로 변환.

Array Processing 활용

# Array Processing 기능을 사용하면 한번의 SQL수행으로 다량의 로우를 insert/update/delete 할수 있다.
  이를 통해 Network를 통한 데이터베이스 Call을 감소시켜 SQL수행시간과 CPU 사용량을 줄일 수 가 있다.

# 예시상황 : "03 데이터베이스 Call이 성능에 미치는 영향"에 있는 예시상황 
1) 3만건인 월요금납부실적 테이블에서 각로우를 fetch하여 읽은 다음 조건에 맞게끔
   납입방법별_월요금집계 테이블에 중복삽입
2) stmt1.setFetchSize(1000); 구문을 통해 월요금납부실적 테이블을 fetch 할때 1000건씩 fetch
3) select시 fetch call    : 30
   insert시 execute call : 30
4) fetch Array processing size    : 1000 (=Fetch Size)
   execute Array processing size : 5000

---------------------------------------------------------------------------------------------------------------------------------
public static void execute (Connection con , String i nput month) 
throws Exception { 
   long rows 0;
   String SQLStmtl "SELECT 고객번호, 납입월 "
               + ", 지로, 자동이체, 신용카드, 핸드폰, 인터넷"
               + "from 월요금납부실적"
               + "where 납입월 ? ";
   String SQLStmt2 "INSERT INTO 납입방법별_월요금집계 " 
               +"(고객변호, 납입월,납입방법묘드, 납입금액) "
               + "VALUES (?, ?, ?, ?)";
con. setAutoCommit(false);
PreparedStatement stmtl = con.prepareStatement(SQLStmt1);
PreparedStatement stmt2 = con.prepareStatement(SQLStmt2);
stmt1.setFetchSize(1000);
stmtl.setString(1, input month);
ResultSet rs = stmtl.executeQuery();

while(rs.next()) {
   String 고객변호 = rs.getString(1);
   String 납입월 = rs.getString(2);
   long 지로 = rs.getLong(3);
   long 지동이체 = rs.getLong(4);
   long 신용카드 = rs.getLong(5);
   long 핸드폰 = rs.getLong(6);
   long 인터넷 rs.getLong(7);
   if( 지로 > 0 )
      insertData (con, stmt2, 고객변호, 납입월, "A", 지로);
   if ( 지동이체 > 0 )
      insertData (con, stmt2, 고객번호, 납입월, "B", 지동이체);
   if ( 신용카드 > 0 ) 
      insertData (con, stmt2, 고객변호, 납입월, "C", 신용카드);
   if ( 핸드폰 > 0 ) 
      insertData (con, stmt2, 고객변호, 납입월, "D" , 핸드폰);
   if ( 인터넷 > 0 )
      insertData (con, stmt2, 고객변호, 납입월, "E" , 인터넷) ;
   if(++rows%1000 == 0) stmt2.executeBatch();
}
---------------------------------------------------------------------------------------------------------------------------------

# Array processing의 효과를 제대로 발휘하려면, 연속된 일련의 처리과정이 모두 Array 단위로 지정되어야 한다.
   ex : insert select문 - select (fetch), insert(execute)의 각각의 단계에서 
Array processing size가 일치해야한다. 만약 select에서 5000건식 Fetch를 한다 하더라도,
         insert 단계에서, 건건이 execute를 수행하면, 병렬로부터 직렬로 처리되는 부분이 병목현상을 야기하기 때문에
         쿼리 처리속도가 빠르지 않다.

위의 표는 앞 절에서 수행한 3가지 테스트(PL/SQL,JAVA(array가 10),One-SQL)와 방금 확인한 java(array가 1000)결과를 표로 정리한 것.
네트워크를 경유해 발생하는 데이터베이스 Call이 얼마만큼 심각한 성능부하를 일으키는지 알 수 있다. 그 뿐 아니라 One-SQL로 통합하지 않더라도 Array Processing만으로 그에 버금가는 성능개선 효과를 얻을 수 있음을 확인 할 수 있다.