DAO 구현 기술 

Sean C. Sullivan 
소프트웨어 엔지니어
2003년 10월 7일

J2EE 개발자들은 Data Access Object (DAO) 디자인 패턴을 사용하여 저수준의 데이터 액세스 로직과 고급 비즈니스 로직을 분리한다. DAO 패턴을 구현하는 것은 단순히 데이터 액세스 코드를 작성하는 것 이상이다.

지난 18개월 동안, 재능 있는 소프트웨어 엔지니어들과 함께 웹 기반의 공급체인 관리 애플리케이션을 구현했다. 우리가 만든 애플리케이션은 선적 상황, 공급 체인 메트릭스, 창고 재고, 운송장, 프로젝트 관리 데이터, 사용자 프로파일 등의 광범위한 데이터에 접근했다. JDBC API를 사용하여 회사의 다양한 데이터베이스 플랫폼에 연결했고 이 애플리케이션에 DAO 디자인 패턴을 적용했다.

그림 1은 애플리케이션과 데이터 소스의 관계이다:

그림 1. 애플리케이션과 데이터 소스

DAO의 기초
DAO 패턴은 표준 J2EE 디자인 패턴들 중 하나이다. 이 패턴을 사용하여 저수준 데이터 액세스와 고급 비지니스 로직을 분리한다. 전형적인 DAO 구현에는 다음과 같은 요소들이 있다:

• DAO 팩토리 클래스
• DAO 인터페이스
• DAO 인터페이스를 구현하는 구체적 클래스
• 데이터 전송 객체들(밸류(value) 객체)

구체적인 DAO 클래스에는 특정 데이터 소스로 부터 데이터에 액세스하는데 쓰이는 로직이 포함되어 있다.

트랜잭션 경계설정(demarcation)
DAO는 트랜잭션 객체들이라는 것을 반드시 기억해야 한다. DAO에 의해 수행되는 각각의 작동(데이터 구현, 업데이트, 삭제)은 트랜잭션과 관련있다. 따라서 트랜잭션 경계설정(demarcation) 개념은 매우 중요하다.

트랜잭션 경계설정은 트랜잭션 영역들이 정의 되는 방식이다. J2EE 스팩은 두 가지 모델의 트랜잭션 경계설정을 설명하고 있다. (표 1):

표 1. 트랜잭션 경계설정

프로그램에 입각한(Programmatic) 트랜잭션 경계설정을 중점적으로 설명하겠다.

디자인 고려사항
앞서 언급했지만, DAO는 트랜잭션 객체이다. 전형적인 DAO는 구현, 업데이트, 삭제 같은 트랜잭션 작동을 수행한다. DAO를 설계할 때 다음 사항들을 점검한다:

• 트랜잭션은 어떻게 시작하는가?
• 트랜잭션은 어떻게 끝나는가?
• 트랜잭션 시작을 담당하는 객체는 무엇인가?
• 트랜잭션 종료를 담당하는 객체는 무엇인가?
• DAO가 트랜잭션의 시작과 종료를 담당해야 하는가?
• 이 애플리케이션이 다중의 DAO를 통해 데이터에 액세스해야 하는가?
• 트랜잭션에 포함될 DAO의 수는?
• 하나의 DAO가 또 DAO에 대한 메소드를 호출할 수 있는가?

이러한 질문들에 대한 답을 알고있다면 자신의 DAO에 가장 잘 맞는 트랜잭션 경계설정 전략을 선택하는데 도움이 된다. DAO에는 두 가지 주요한 트랜잭션 경계설정 전략이 있다. 하나는 DAO가 트랜잭션의 경계를 설정하도록 하는 것이다. 또 다른 방법은 트랜잭션 경계설정을 DAO의 메소드를 호출하는 객체에 맡기는 것이다. 전자를 선택한다면 DAO 클래스 안에 트랜잭션 코드를 임베딩해야 한다. 후자의 방법을 선택한다면 트랜잭션 경계설정 코드는 DAO 클래스의 외부에 있게 될 것이다. 코드 예제를 보고 이 두 가지 방법을 자세히 보도록 하자.

Listing 1- DAO와 두 개의 데이터 작동;구현 및 업데이트:

Listing 1. DAO 메소드

       public void createWarehouseProfile(WHProfile profile);
       public void updateWarehouseStatus(WHIdentifier id, StatusInfo status);

Listing 2은 간단한 트랜잭션이다. 트랜잭션 경계설정 코드는 DAO 클래스 외부에 있다. 이 예제에서 콜러(caller)가 다중의 DAO 작동들을 이 트랜잭션 내에서 결합하는 방법을 주목해보자.

Listing 2. 콜러(Caller)에 의해 관리되는 트랜잭션

      tx.begin();    // start the transaction
      dao.createWarehouseProfile(profile);
      dao.updateWarehouseStatus(id1, status1);
      dao.updateWarehouseStatus(id2, status2);
      tx.commit();   // end the transaction

이 트랜잭션 경계설정 전략은 단일 트랜잭션에서 다중의 DAO에 액세스 해야하는 애플리케이션에 특별히 어울린다.

JDBC API 또는 Java Transaction API (JTA)를 사용하여 트랜잭션 경계설정을 구현할 수 있다. JDBC 트랜잭션 경계설정은 JTA 보다 단순하다. 하지만 JTA는 보다 유연하다.

JDBC를 이용한 트랜잭션 경계설정
JDBC 트랜잭션은 Connection 객체를 사용하여 제어된다. JDBC Connection 인터페이스(java.sql.Connection)는 두 개의 트랜잭션 모드를 제공한다. (auto-commit과 manual commit). java.sql.Connection은 트랜잭션 제어에 다음의 메소드를 제공한다:

• public void setAutoCommit(boolean)
• public boolean getAutoCommit()
• public void commit()
• public void rollback()

Listing 3은 JDBC API를 사용하여 트랜잭션의 경계설정을 하는 방법이다:

Listing 3. JDBC API를 이용한 트랜잭션 경계설정

      import java.sql.*;
      import javax.sql.*;

      // ...
      DataSource ds = obtainDataSource();
      Connection conn = ds.getConnection();
      conn.setAutoCommit(false);
      // ...
      pstmt = conn.prepareStatement("UPDATE MOVIES ...");
      pstmt.setString(1, "The Great Escape");
      pstmt.executeUpdate();
      // ...
      conn.commit();
      // ...

JDBC 트랜잭션 경계설정을 이용하면 여러 개의 SQL 문장을 하나의 트랜잭션으로 결합할 수 있다. JDBC 트랜잭션의 단점 중 하나는 트랜잭션 범위가 하나의 데이터베이스 연결로 제한되어 있다는 점이다. JDBC 트랜잭션은 다중 데이터베이스로 확장할 수 없다. 다음에는 JTA를 사용한 트랜잭션 경계설정이다.

JTA 개요
Java Transaction API (JTA)와 Java Transaction Service (JTS)는 J2EE 플랫폼에 분산 트랜잭션 서비스를 제공한다. 분산 트랜잭션에는 트랜잭션 매니저와 한 개 이상의 리소스 매니저가 포함된다. 리소스 매니저는 일종의 영속 데이터스토어이다. 트랜잭션 매니저는 모든 트랜잭션 참여자들 간 통신을 조정하는 역할을 담당한다. 트랜잭션 매니저와 리소스 매니저 관계는 다음과 같다. (그림 2):

그림 2. 트랜잭션 매니저와 리소스 매니저

JTA 트랜잭션은 JDBC 트랜잭션 보다 강력하다. JDBC 트랜잭션이 하나의 데이터베이스 연결로 제한되어 있다면 JTA 트랜잭션은 다중의 참여자들을 가질 수 있다. 다음의 자바 플랫폼 컴포넌트 중 어떤 것이든지 JTA 트랜잭션에 참여할 수 있다:

• JDBC 커넥션
• JDO PersistenceManager 객체
• JMS 큐
• JMS 토픽
• Enterprise JavaBeans
• J2EE Connector Architecture 스팩에 호환하는 리소스 어댑터

JTA를 이용한 트랜잭션 경계설정
JTA로 트랜잭션 경계를 설정하기 위해 애플리케이션은 javax.transaction.UserTransaction 인터페이스에 대한 메소드를 호출한다. Listing 4는 UserTransaction 객체의 전형적인 JNDI이다:

Listing 4. UserTransaction 객체의 JNDI

      import javax.transaction.*;
      import javax.naming.*;
      // ...
      InitialContext ctx = new InitialContext();
      Object txObj = ctx.lookup("java:comp/UserTransaction");
      UserTransaction utx = (UserTransaction) txObj;

애플리케이션 UserTransaction 객체에 대한 레퍼런스를 가진 후에 트랜잭션을 시작한다. (Listing 5):

Listing 5. 트랜잭션 시작

      utx.begin();
      // ...
      DataSource ds = obtainXADataSource();
      Connection conn = ds.getConnection();
      pstmt = conn.prepareStatement("UPDATE MOVIES ...");
      pstmt.setString(1, "Spinal Tap");
      pstmt.executeUpdate();
      // ...
      utx.commit();
      // ...

애플리케이션이 commit()을 호출하면, 트랜잭션 매니저는 2 단계 커밋(two-phase commit) 프로토콜을 사용하여 트랜잭션을 종료한다.

트랜잭션 제어용 JTA 메소드
javax.transaction.UserTransaction 인터페이스는 다음의 트랜잭션 제어 메소드를 제공한다:

• public void begin()
• public void commit()
• public void rollback()
• public int getStatus()
• public void setRollbackOnly()
• public void setTransactionTimeout(int)

JTA 트랜잭션을 시작할 때 이 애플리케이션은 begin()을 호출한다. 트랜잭션을 끝내려면 commit() 또는 rollback()을 호출한다. (참고자료).

JTA와 JDBC 사용하기
개발자들은 DAO 클래스에서 저수준 데이터 작동에 JDBC를 사용하곤 한다. JTA를 이용하여 트랜잭션의 경계를 설정하려면 javax.sql.XADataSource, javax.sql.XAConnection, javax.sql.XAResource인터페이스를 구현하는 JDBC 드라이버가 필요하다. 이러한 인터페이스를 구현하는 드라이버는 JTA 트랜잭션에 참여할 수 있게된다. XADataSource 객체는 XAConnection 객체용 팩토리이다. XAConnection는 JTA 트랜잭션에 참여하는 JDBC 커넥션이다.

애플리케이션 서버의 관리 툴을 사용하여 XADataSource를 설정해야 한다. 애플리케이션 서버 문서와 JDBC 드라이버 문서를 참조하라.

J2EE 애플리케이션은 JNDI를 사용하여 데이터 소스를 검색한다. 일단 애플리케이션이 데이터 소스 객체에 대한 레퍼런스를 갖게 되면 이것은 javax.sql.DataSource.getConnection()을 호출하여 데이터베이스로의 커넥션을 획득하게 된다.

XA 커넥션은 비 XA 커넥션과는 다르다. XA 커넥션은 JTA 트랜잭션에 참여하고 있다는 것을 언제나 기억하라. XA 커넥션은 JDBC의 자동 커밋 기능을 지원하지 않는다. 또한 이 애플리케이션은 XA 커넥션 상에서 java.sql.Connection.commit() 또는 java.sql.Connection.rollback()을 호출하지 않는다. 대신 UserTransaction.begin(), UserTransaction.commit(), UserTransaction.rollback()을 사용한다.

최상의 접근방법 선택하기
JDBC와 JTA를 이용한 트랜잭션 경계설정에 대해 이야기했다. 각 접근방식 대로 장점이 있기 때문에 자신의 애플리케이션에 가장 알맞는 것을 선택해야 한다.

최근 많은 프로젝트에서 우리팀은 JDBC API를 사용하여 DAO 클래스를 구현했다. 이 DAO 클래스는 다음과 같이 요약된다:

• 트랜잭션 경계설정 코드는 DAO 클래스 안으로 임베딩된다.
• DAO 클래스는 트랜잭션 경계설정에 JDBC API를 사용한다.
• 콜러가 트랜잭션 경계를 설정할 방법은 없다.
• 트랜잭션 범위는 하나의 JDBC Connection으로 제한된다.

JDBC 트랜잭션이 복잡한 엔터프라이즈 애플리케이션에 언제나 적합한 것은 아니다. 트랜잭션이 다중 DAO 또는 다중 데이터페이스로 확장한다면 다음과 같은 구현 전략이 보다 적합하다:

• 트랜잭션은 JTA로 경계 설정된다.
• 트랜잭션 경계설정 코드는 DAO와 분리되어 있다.
• 콜러가 트랜잭션 경계설정을 담당하고 있다.
• DAO는 글로벌 트랜잭션에 참여한다.

JDBC 접근방법은 간단함이 매력이다. JTA 접근방법은 유연성이 무기이다. 애플리케이션에 따라 구현 방법을 선택해야 한다.

로깅과 DAO
잘 구현된 DAO 클래스는 런타임 작동에 대한 세부사항을 파악하기 위해 로깅(logging)을 사용한다. 예외, 설정 정보, 커넥션 상태, JDBC 드라이버 메타데이터, 쿼리 매개변수 중 어떤 것이든 선택하여 기록해야 한다. 기록은 모든 개발 단계에 유용하다.

로깅 라이브러리 선택하기
많은 개발자들은 단순한 형식의 로깅을 사용한다: System.out.println과 System.err.println. Println 문장은 빠르고 편리하지만 완벽한 로깅 시스템은 제공하지 않는다. 표 2는 자바 플랫폼을 위한 로깅 라이브러리이다:

표 2.자바 플랫폼을 위한 로깅 라이브러리

java.util.logging은 J2SE 1.4 플랫폼을 위한 표준 API이다. Jakarta Log4j가 더 많은 기능성과 유연성을 제공한다는 것에는 많은 개발자들이 동의하고 있다. java.util.logging의 이점 중 하나는 J2SE 1.3과 J2SE 1.4 플랫폼을 지원한다는 것이다.

Jakarta Commons Logging은 java.util.logging 과의 연결 또는 Jakarta Log4j에 사용될 수 있다. Commons Logging은 로깅 추상 레이어로서 애플리케이션을 기저의 로깅 구현에서 고립시킬 수 있다. Commons Logging을 사용하여 설정 파일을 변경하여 기저의 로깅 구현을 바꿀 수 있다. Commons Logging은 Jakarta Struts 1.1과 Jakarta HttpClient 2.0에 사용된다.

로깅 예제
Listing 7은 DAO 클래스에서 Jakarta Commons Logging을 사용하는 방법이다:

Listing 7. Jakarta Commons Logging 

import org.apache.commons.logging.*;

class DocumentDAOImpl implements DocumentDAO
{
      static private final Log log = LogFactory.getLog(DocumentDAOImpl.class);

      public void deleteDocument(String id)
      {
          // ...
          log.debug("deleting document: " + id);
          // ...
          try
          {
              // ... data operations ...
          }
          catch (SomeException ex)
          {
              log.error("Unable to delete document", ex);
              // ... handle the exception ...
  }
      }
}

로깅은 미션 수행에 중요한 애플리케이션의 중요한 일부이다. DAO에서 오류가 생기면 무엇이 잘못되었는지를 이해할 수 있게끔 최고의 정보를 로그가 제공한다. 로깅과 DAO를 결합하면 디버깅과 문제해결은 확실하다.

DAO에서의 예외 핸들링

DAO 패턴을 구현할 때 다음 사항을 자문해보라:

• DAO의 퍼블릭 인터페이스의 메소드들이 검사된 예외를 던지는가?
• 그렇다면 어떤 예외들인가?
• DAO 구현 클래스에서 예외는 어떻게 처리되는가?

DAO 패턴을 작업하는 과정에서 우리 팀은 예외 핸들링에 대한 가이드라인을 개발했다:

• DAO 메소드는 의미있는 예외를 던져야한다.
  
  
• DAO 메소드는 java.lang.Exception을 던져서는 안된다. java.lang.Exception은 너무 일반적이다. 근본 문제에 대한 정보를 제공하지 않을 것이다.
  
  
• DAO 메소드는 java.sql.SQLException 메소드를 던져서는 안된다. SQLException은 저급 JDBC 예외이다. DAO는 JDBC를 나머지 애플리케이션에 노출하는 것이 아니라 JDBC를 캡슐화 해야한다.
  
  
• DAO 인터페이스의 메소드들은 콜러가 예외를 처리할 수 있다고 합리적으로 판단될 때 에만 검사된예외를 던져야 한다. 콜러가 예외를 핸들할 수 없다면 검사되지 않은(런타임) 예외를 던질 것을 고려하라.
  
  
• 데이터 액세스 코드가 예외를 잡으면 이를 무시하지 말아라. 잡힌 예외를 무시하는 DAO는 문제해결에 애를 먹는다.
  
  
• 연쇄 예외를 사용하여 저급 예외를 고급 예외로 트랜슬레이팅 한다.
  
  
• 표준 DAO 예외 클래스를 정의하라. Spring Framework (참고자료)은 사전 정의된 DAO 예외 클래스를 제공한다.

구현 예제: MovieDAO
MovieDAO는 이 글에 논의된 모든 기술을 보여주는 DAO이다: 트랜잭션 경계설정, 로깅, 예외 핸들링. 코드는 세 개의 패키지로 나뉜다. (참고자료):

• daoexamples.exception
• daoexamples.movie
• daoexamples.moviedemo

DAO 패턴 구현은 클래스와 인터페이스로 구성된다:

• daoexamples.movie.MovieDAOFactory
• daoexamples.movie.MovieDAO
• daoexamples.movie.MovieDAOImpl
• daoexamples.movie.MovieDAOImplJTA
• daoexamples.movie.Movie
• daoexamples.movie.MovieImpl
• daoexamples.movie.MovieNotFoundException
• daoexamples.movie.MovieUtil

MovieDAO 인터페이스는 DAO의 데이터 작동을 정의한다. 이 인터페이스는 다섯 개의 메소드를 갖고 있다:

• public Movie findMovieById(String id)
• public java.util.Collection findMoviesByYear(String year)
• public void deleteMovie(String id)
• public Movie createMovie(String rating, String year, String, title)
• public void updateMovie(String id, String rating, String year, String title)

daoexamples.movie 패키지에는 두 개의 MovieDAO 인터페이스 구현이 포함되어 있다. 각 구현은 트랜잭션 경계설정에 다른 접근방식을 사용한다. (표 3):

표 3. MovieDAO 구현

MovieDAO 데모 애플리케이션
이 데모 애플리케이션 이름은 daoexamples.moviedemo.DemoServlet 이다. DemoServlet은 Movie DAO를 사용하여 무비 데이터를 쿼리 및 업데이트 한다.

Listing 8은 싱글 트랜잭션 에서의 JTA-aware MovieDAO와 Java Message Service의 결합 방법이다.

Listing 8. MovieDAO와 JMS 코드 결합

  UserTransaction utx = MovieUtil.getUserTransaction();
  utx.begin();
  batman = dao.createMovie("R",
      "2008",
      "Batman Reloaded");
  publisher = new MessagePublisher();
  publisher.publishTextMessage("I'll be back");
  dao.updateMovie(topgun.getId(),
      "PG-13",
      topgun.getReleaseYear(),
      topgun.getTitle());
  dao.deleteMovie(legallyblonde.getId());
  utx.commit();

데모를 실행하려면 XA 데이터소스와 비 XA 데이터소스를 애플리케이션 서버에 설정해야 한다. 그런다음 daoexamples.ear 파일을 전개한다.

출처 -http://lbass.tistory.com/entry/%EB%B3%B8%EB%AC%B8%EC%8A%A4%ED%81%AC%EB%9E%A9-%EA%B3%A0%EA%B8%89-DAO-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

트랜잭션은 비즈니스의 통합된 일부입니다. 일반 비즈니스 트랜잭션은 두 개 이상의 관련 부분 사이 자산 이동과 관련되어 있습니다. 정확성을 요하는 기록은 보통 하나 이상의 데이터베이스에 저장됩니다. 이 정보는 비즈니스 작업에 꼭 필요하기 때문에 항상 유효하고, 현재성을 가지고, 신뢰할 수 있어야 합니다. 초보 프로그래머에게는 트랜잭션 처리가 어려울 수 있습니다. J2EE 플랫폼은 종속 가능한 트랜잭션 처리 응용 프로그램 전개를 쉽게 해주는 여러 추상적 개념을 제공합니다. 이 장에서는 Sun ONE Application Server의 J2EE 트랜잭션 및 트랜잭션 지원을 설명합니다.

이 장에서는 일반적으로 Java 트랜잭션, 구체적으로는 Sun ONE Application Server에 포함되어 있는 트랜잭션 지원에 대해 설명합니다.

이 장에서는 다음 내용을 설명합니다.

• 트랜잭션 정보
• J2EE 트랜잭션
• 트랜잭션 자원 관리자
• 로컬 및 분산 트랜잭션
• 컨테이너 관리 트랜잭션
• Bean 관리 트랜잭션
• 트랜잭션 서비스 관리

트랜잭션 정보

---

비즈니스 트랜잭션을 에뮬레이트하려면 프로그램이 여러 단계를 수행해야 할 수 있습니다. 예를 들어, 재무 프로그램이 다음 의사 코드에 나열된 단계를 수행하면 자금을 수표 계좌에서 예금 계좌로 이체할 수 있습니다.

begin transaction

debit checking account

credit savings account

update history log

commit transaction

앞의 의사 코드에서 begin 및 commit 명령은 트랜잭션 경계를 표시합니다. 트랜잭션을 완료하려면 세 단계가 모두 완료되어야 합니다. 세 단계가 모두 완료되지 못하면 데이터 통합이 손상될 수 있습니다.

이 보장을 원자성이라고 합니다. 트랜잭션은 commit 또는 rollback 명령으로 끝납니다. 트랜잭션을 완결하면 트랜잭션 경계 내의 명령으로 수행한 모든 수정이 저장 및 지속됩니다. 변경은 영구적이며 이후 시스템 장애가 일어나도 그대로 유지됩니다. 트랜잭션 내의 명령 중 하나라도 실패하면 트랜잭션 전체가 롤백하며, 그 때까지 트랜잭션 내에서 실행된 모든 명령은 취소됩니다. 예를 들어, 의사 코드의 credit 단계 중 디스크 드라이브에 오류가 발생하면, 트랜잭션은 롤백되고 debit 명령으로 수행되었던 데이터 변경도 모두 취소됩니다.

트랜잭션이 실패해도 트랜잭션 계정 잔액은 여전히 유지되기 때문에 데이터 통합이 손상되지 않습니다. 트랜잭션 작동의 이런 측면을 트랜잭션 일관성이라 합니다.

트랜잭션 서비스는 고립화도 제공합니다. 이것은 트랜잭션이 완결 또는 롤백되기 전까지는 트랜잭션 내 구문을 다른 응용 프로그램에서 관찰할 수 없음을 의미합니다. 일단 트랜잭션이 완결되면 이 완결된 트랜잭션은 응용 프로그램 및 스레드가 안전하게 관찰할 수 있습니다.

J2EE 트랜잭션

---

J2EE의 트랜잭션 처리는 트랜잭션 관리자, 응용 프로그램 서버, 자원 관리자, 자원 어댑터 및 사용자 응용 프로그램의 다섯 참가자에 의해 수행됩니다. 각 엔티티는 다음에서 설명하는 여러 API 및 기능을 구현하여 신뢰할 수 있는 방법으로 트랜잭션을 처리합니다.

• 트랜잭션 관리자는 트랜잭션 구분, 트랜잭션 자원 관리, 동기화 및 트랜잭션 컨텍스트 전파 지원에 필요한 서비스 및 관리 기능을 제공합니다.
• 응용 프로그램 서버는 트랜잭션 상태 관리 등의 응용 프로그램 런타임 환경 지원에 필요한 기반 구조를 제공합니다.
• 자원 관리자(자원 어댑터를 통한)는 응용 프로그램에게 자원에 대한 액세스를 제공합니다. 자원 관리자는 트랜잭션 관리자가 트랜잭션 연결, 트랜잭션 완료 및 복구 작업과 통신할 때 사용하는 트랜잭션 자원 인터페이스를 구현하여 분산된 트랜잭션에 참여합니다. 이런 자원 관리자의 예로 관계형 데이터베이스 서버를 들 수 있습니다.
• 자원 어댑터는 응용 프로그램 서버 또는 클라이언트가 자원 관리자와의 연결에 사용하는 시스템 수준 소프트웨어 라이브러리입니다. 자원 어댑터는 일반적으로 자원 관리자마다 따로 지정됩니다. 자원 어댑터는 라이브러리로 사용 가능하며 이것을 사용하는 클라이언트 주소 공간 내에서 사용됩니다. 이런 자원 어댑터의 예로는 JDBC 드라이버가 있습니다.
• J2EE 응용 프로그램 서버 환경에서 작업하기 위해 개발된 트랜잭션 사용자 응용 프로그램은 JNDI를 사용하여 트랜잭션 데이터 소스 및 선택적으로 트랜잭션 관리자를 조회합니다. EJB의 선언적 트랜잭션 속성 설정 또는 명시적인 프로그램형 트랜잭션 구분을 사용할 수 있습니다.

자원 관리자와 자원 어댑터 엔티티는 서로 밀접하게 연관되어 있어서, 자원 관리자라는 용어가 자원 어댑터와 혼용되는 경우도 많습니다.

트랜잭션 자원 관리자

---

다음 트랜잭션 자원 관리자는 J2EE 트랜잭션 내에서 지원됩니다.

• 데이터베이스
• JMS 공급자
• J2EE 커넥터

데이터베이스

가장 자주 접하게 되는 J2EE 응용 프로그램의 트랜잭션 자원 관리자는 데이터베이스입니다. JDBC는 J2EE 구성 요소가 데이터베이스 액세스에 사용하는 API입니다. 데이터베이스 자원은 JDBC 자원으로 구성됩니다. JDBC 자원은 자원 관리자 또는 JDBC 드라이버가 관리합니다. JDBC 드라이버는 로컬 트랜잭션 또는 전역 트랜잭션 및 때로 로컬 및 전역 트랜잭션 모두에 대한 지원을 제공할 수 있습니다.

Sun ONE Application Server는 여러 J2EE 구성 요소의 JDBC 및 트랜잭션 사용을 지원합니다. JDBC 자원의 등록 및 구성 방법에 대한 자세한 내용은 "JDBC 자원 정보"를 참조하십시오. 응용 프로그램 서버는 트랜잭션 연속성 제공(즉 여러 응용 프로그램 구성 요소로부터 트랜잭션 초기화 및 데이터베이스 액세스 수행)을 담당합니다. 예를 들어, 서블릿이 트랜잭션을 시작하고, 데이터베이스를 액세스하고, 동일한 트랜잭션의 일부로 동일한 데이터베이스를 액세스하는 Enterprise Bean을 불러낸 후, 마지막으로 트랜잭션을 완결할 수 있습니다.

JMS 공급자

JMS는 Java Message Service의 약자입니다. JMS 공급자는 메시지 브로커 서비스를 의미하는 J2EE 용어입니다. JMS API는 응용 프로그램 사이에 신뢰할 수 있는 트랜잭션 방식의 교환을 제공합니다. 트랜잭션 JMS 데이터 소스 지원은 J2EE의 필수 기능입니다. JMS 자원 및 JDBC 자원이 함께 동일한 트랜잭션에 사용될 수 있습니다.

Sun ONE Application Server는 Sun ONE 메시지 대기열, 완전한 기능의 JMS 공급자 및 해당 트랜잭션 자원 관리자에 통합됩니다. 이렇게 하면 Sun ONE Application Server가 서블릿, JSP 페이지 및 Enterprise Bean에서 트랜잭션 JMS에 액세스할 수 있습니다. Sun ONE Application Server에 타사 JMS 공급자를 사용할 수도 있습니다. 자세한 내용은 "JMS 서비스 사용"을 참조하십시오.

J2EE 커넥터

Sun ONE Application Server는 트랜잭션 자원 관리자로 XATransaction 모드를 사용하는 자원 어댑터를 지원합니다. 플랫폼에서는 서블릿, JSP 페이지 및 Enterprise Bean에서 자원 어댑터로 트랜잭션 액세스할 수 있어야 합니다. 단일 트랜잭션 내의 여러 응용 프로그램 구성 요소에서 자원 어댑터에 액세스할 수 있습니다. 예를 들어, 서블릿이 트랜잭션을 시작하고, 자원 어댑터를 액세스하고, 동일한 트랜잭션의 일부로 자원 어댑터를 액세스하는 Enterprise Bean을 불러낸 후, 마지막으로 트랜잭션을 완결할 수 있습니다.

로컬 및 분산 트랜잭션

---

한 자원과만 관련 있는 트랜잭션은 로컬 트랜잭션을 사용하여 완료될 수 있습니다. 또한 로컬 트랜잭션은 모든 참여 응용 프로그램 구성 요소가 하나의 프로세스 내에서 실행되어야 합니다. 두 개 이상의 자원 또는 여러 참여 프로세스가 관련된 트랜잭션은 분산 또는 전역 트랜잭션이 될 수 있습니다. 로컬 트랜잭션 최적화는 최적화 전용 자원 관리자를 사용하며, 이것은 J2EE 응용 프로그램에 투명합니다.

트랜잭션 유형은 관련 자원 관리자에 구현된 인터페이스로 판단할 수 있습니다. 예를 들어, javax.sql.DataSource 인터페이스를 구현하는 JDBC 데이터 소스는 로컬 트랜잭션에 참여할 수 있습니다. javax.sql.XADataSource를 구현하는 데이터 소스는 전역 트랜잭션의 일부를 취할 수 있습니다. 일부 JDBC 자원은 두 인터페이스를 모두 구현하며, 이런 JDBC 자원이 Sun ONE Application Server에 등록되어 있으면 Sun ONE Application Server의 구성에 해당 자원의 선호 기능을 표시하는 구성 정보를 추가해야 할 수 있습니다.

로컬 트랜잭션이 더 간단하며 기본적으로 전역 트랜잭션보다 효율적입니다. 변형해야 할 데이터가 여러 데이터 소스에 있을 경우에는 로컬 트랜잭션이 적절하지 않습니다. 때로 몇 개의 데이터 소스가 트랜잭션에 나열되어야 하는지 예측할 수 없는 경우도 있습니다. 이 때문에 실제로는 전역 트랜잭션을 더 많이 사용합니다. 전역 트랜잭션에 사용할 수 있는 몇 가지 성능 개선 최적화가 있습니다.

J2EE는 트랜잭션 내의 여러 Enterprise Bean에 액세스하는 서블릿이나 JSP의 임의 조합을 모두 포함하는 트랜잭션 응용 프로그램을 지원합니다. 각 구성 요소는 하나 이상의 트랜잭션 자원 관리자에 대해 하나 이상의 연결을 가질 수 있습니다. 다음 그림에서, 호출 트리는 여러 Enterprise Bean을 액세스하는 서블릿 또는 JSP에서 시작하며, 이후 다른 Enterprise Bean을 액세스할 수 있습니다. 구성 요소는 연결을 통해 자원 관리자에 액세스합니다.

트랜잭션의 자원에 액세스하는 J2EE 구성 요소

 

예를 들어, 응용 프로그램은 위 그림의 모든 구성 요소가 단일 트랜잭션의 일부로 자원에 액세스해야 할 수도 있습니다. 응용 프로그램 서버 공급자는 이런 시나리오를 지원하는 트랜잭션 기능을 제공해야 합니다.

J2EE 트랜잭션 관리는 플랫 트랜잭션을 지원합니다. 플랫 트랜잭션은 자식(중첩된) 트랜잭션을 가질 수 없습니다.

트랜잭션 복구는 분산 트랜잭션에 있어 중요한 측면입니다. 크리티컬 포인트 동안 자원을 사용할 수 없거나 기타 복구할 수 없는 오류가 발생하면, 분산 트랜잭션의 상태를 모르게 될 수 있습니다. 꼬이거나 완료되지 못한 트랜잭션을 자동 및 수동으로 복구하는 것은 Sun ONE Application Server의 중요한 기능입니다. 자동 트랜잭션 복구는 관리 인터페이스를 사용하여 수행할 수 있습니다. 트랜잭션 복구 제어 방법의 자세한 내용은 "트랜잭션 서비스 관리"를 참조하십시오.

연결(여기에서는 자원과 동의어로 사용됨)은 공유 가능 여부가 표시될 수 있습니다. 공유 불가능한 방법으로 연결을 사용하려는 J2EE 응용 프로그램 구성 요소는 영향을 받는 측에 배포 정보를 제공하여 컨테이너가 연결을 공유하지 못하도록 해야 합니다. 이것이 필요할 수 있는 경우의 예로는 보안 속성, 고립화 수준, 문자 집합 및 로컬화 구성을 변경하는 경우가 포함됩니다.

컨테이너는 공유 불가능으로 표시된 연결을 공유하지 말아야 합니다. 연결이 공유 불가능으로 표시되어 있지 않으면, 이것은 연결이 실제 공유되어 있는지 여부와 상관없이 응용 프로그램에 투명해야 합니다.

J2EE 응용 프로그램 구성 요소는 선택적 전개 설명자 요소 res-sharing-scope를 사용하여 자원 관리자에 대한 연결의 공유 가능 여부를 표시할 수 있습니다. 컨테이너는 전개 관련 정보가 제공되지 않으면 공유 가능한 연결이라고 간주합니다. J2EE 응용 프로그램 구성 요소는 연결 객체를 캐시하여 여러 트랜잭션에서 다시 사용할 수 있습니다. 공유 연결을 제공하는 컨테이너는 이런 캐시된 연결 객체를 투명하게 전환하여(디스패치할 때) 올바른 트랜잭션 범위를 가진 적절한 공유 연결을 가리키도록 해야 합니다.

Enterprise Bean 응용 프로그램을 설계하는 경우, 개발자는 경계 지정 방법을 결정해야 합니다.

컨테이너 관리 트랜잭션

---

컨테이너 관리 트랜잭션이 있는 Enterprise Bean의 경우에는 EJB 컨테이너가 트랜잭션 경계를 설정합니다. Enterprise Bean 유형으로 Session, Entity 또는 Message-Driven을 가진 컨테이너 관리 트랜잭션을 사용할 수 있습니다. 컨테이너 관리 트랜잭션은 Enterprise Bean 코드가 트랜잭션의 경계를 명시적으로 표시하지 않기 때문에 간단하게 배포할 수 있습니다. 이 코드에는 트랜잭션 시작 및 종료 명령이 없습니다.

일반적으로 컨테이너는 Enterprise Bean 메소드가 시작하기 직전에 트랜잭션을 시작하고, 메소드가 종료되기 직전 트랜잭션을 완결합니다. 각 메소드는 단일 트랜잭션에 관련될 수 있습니다. 한 메소드 내에 중첩된 트랜잭션 또는 여러 트랜잭션을 허용하지 않습니다.

컨테이너 관리 트랜잭션이 트랜잭션에 연결될 때 모든 메소드가 필요하지는 않습니다. Bean을 배포할 때에는 트랜잭션 속성을 설정하여 트랜잭션과 관련된 Bean의 메소드를 지정합니다.

이 절에서는 다음 내용을 설명합니다.

• 트랜잭션 속성
• 트랜잭션 속성 설정
• 컨테이너 관리 트랜잭션 롤백
• Session Bean의 인스턴스 변수 동기화
• 컨테이너 관리 트랜잭션에 허용되지 않는 메소드

트랜잭션 속성

트랜잭션 속성은 트랜잭션 범위를 제어합니다. 다음 그림은 범위 제어가 왜 중요한지 보여주고 있습니다. 다이어그램에서, 메소드 A는 트랜잭션을 시작하고 Bean 2의 메소드 B는 트랜잭션을 불러냅니다. 메소드 B가 실행되면 메소드 A가 시작한 트랜잭션 범위 내에서 실행될까요? 아니면 새 트랜잭션으로 실행될까요? 답은 메소드 B의 트랜잭션 속성에 따라 달라집니다.

   
 
트랜잭션 속성

트랜잭션 속성은 다음 값 중 하나를 가질 수 있습니다.

• Required
• RequiresNew
• Mandatory
• NotSupported
• Supports
• Never

Required

클라이언트가 트랜잭션 내에서 실행 중일 때 Enterprise Bean의 메소드를 불러내면, 이 메소드는 클라이언트 트랜잭션 내에서 실행됩니다. 클라이언트가 트랜잭션과 관련되어 있지 않으면, 메소드가 실행되기 전 먼저 컨테이너가 새 트랜잭션을 시작합니다.

Required 속성은 대부분의 트랜잭션에 사용됩니다. 이 때문에 최소한 개발 초기에는 이것을 기본값으로 사용하는 것이 좋습니다. 트랜잭션 속성은 선언적이기 때문에 나중에 쉽게 변경할 수 있습니다.

RequiresNew

클라이언트가 트랜잭션 내에서 실행 중일 때 Enterprise Bean의 메소드를 불러내면, 컨테이너는 다음 단계를 수행합니다.

• 클라이언트의 트랜잭션 일시 중단
• 새 트랜잭션 시작
• 메소드에게 호출 위임
• 메소드 실행 완료 후 클라이언트의 트랜잭션 다시 시작

클라이언트가 트랜잭션과 관련되어 있지 않으면, 메소드가 실행되기 전 먼저 컨테이너가 새 트랜잭션을 시작합니다.

메소드가 새 트랜잭션 내에서 항상 실행되도록 하려면 RequiresNew 속성을 사용해야 합니다.

Mandatory

클라이언트가 트랜잭션 내에서 실행 중일 때 Enterprise Bean의 메소드를 불러내면, 이 메소드는 클라이언트 트랜잭션 내에서 실행됩니다. 클라이언트가 트랜잭션과 관련되어 있지 않으면 TransactionRequiredException이 발생합니다.

Enterprise Bean의 메소드가 클라이언트 트랜잭션을 사용해야 하는 경우 Mandatory 속성을 사용합니다.

NotSupported

클라이언트가 트랜잭션 내에서 실행 중일 때 Enterprise Bean의 메소드를 불러내면, 컨테이너는 이 메소드를 불러내기 전 먼저 클라이언트 트랜잭션을 일시 중단합니다. 메소드가 완료된 다음 컨테이너는 클라이언트 트랜잭션을 다시 시작합니다.

클라이언트가 트랜잭션과 관련되어 있지 않으면, 컨테이너는 메소드가 실행되기 전 새 트랜잭션을 시작하지 않습니다.

트랜잭션이 필요하지 않은 메소드에는 NotSupported 속성을 사용합니다. 트랜잭션 불러내기는 오버헤드가 있기 때문에 이 속성은 성능을 개선할 수 있습니다.

Supports

클라이언트가 트랜잭션 내에서 실행 중일 때 Enterprise Bean의 메소드를 불러내면, 이 메소드는 클라이언트 트랜잭션 내에서 실행됩니다. 클라이언트가 트랜잭션과 관련되어 있지 않으면, 컨테이너는 메소드가 실행되기 전 새 트랜잭션을 시작하지 않습니다.

메소드의 트랜잭션 작업은 다양하기 때문에 Supports 속성은 주의해서 사용해야 합니다.

Never

클라이언트가 트랜잭션 내에서 실행 중일 때 Enterprise Bean의 메소드를 불러내면, 컨테이너는 RemoteException를 발생합니다. 클라이언트가 트랜잭션과 관련되어 있지 않으면, 컨테이너는 메소드가 실행되기 전 새 트랜잭션을 시작하지 않습니다.

속성 요약

다음 표는 트랜잭션 속성의 영향을 요약합니다. T1 및 T2 트랜잭션은 모두 컨테이너로 제어됩니다. T1 트랜잭션은 Enterprise Bean의 메소드를 호출하는 클라이언트와 관련되어 있습니다. 대부분의 경우 클라이언트도 별도의 Enterprise Bean입니다. T2 트랜잭션은 메소드가 실행되기 전 컨테이너에 의해 시작됩니다.

마지말 열의 '없음'이라는 단어는 비즈니스 메소드가 컨테이너가 제어하는 트랜잭션 내에서 실행되지 않음을 표시합니다. 하지만 이런 비즈니스 메소드에 호출된 데이터베이스는 DBMS의 트랜잭션 관리자가 제어할 수 있습니다.

   트랜잭션 속성

트랜잭션 속성	클라이언트 트랜잭션	비즈니스 메소드의 트랜잭션
Required	없음	T2
	T1	T1
RequiresNew	없음	T2
	T1	T2
Mandatory	없음	오류
	T1	T1
NotSupported	없음	없음
	T1	없음
Supports	없음 T1	없음 T1

트랜잭션 속성 설정

트랜잭션 속성은 배포 설명자에 저장되기 때문에 Enterprise Bean 작성, 응용 프로그램 어셈블리 및 배포 등 J2EE 응용 프로그램 전개자의 여러 단계 도중 변경될 수 있습니다. 하지만 Bean 작성시 속성을 지정하는 것은 개발자가 해야 합니다. 속성은 구성 요소를 더 큰 응용 프로그램으로 어셈블리하는 응용 프로그램 개발자만 수정할 수 있어야 합니다. J2EE 응용 프로그램을 배포하는 사람은 트랜잭션 속성을 지정할 책임이 없습니다.

전체 Enterprise Bean 또는 각 메소드에 대해 트랜잭션 속성을 지정할 수 있습니다. 한 속성은 메소드에 대해 지정하고 다른 속성은 Bean에 대해 지정한 경우에는 메소드에 대해 지정한 속성이 우선권을 갖습니다. 각 메소드에 대해 속성을 지정하는 경우 필요한 사항은 Bean 유형에 따라 달라집니다. Session Bean에는 비즈니스 메소드에 정의된 속성이 필요하지만, 생성 메소드에 대해서는 허용하지 않습니다. Entity Bean에는 비즈니스, 생성, 제거 및 검색 메소드에 대한 트랜잭션 속성이 필요합니다. Message-Driven Bean에는 onMessage 메소드에 대한 트랜잭션 속성(Required 또는 NotSupported 중 하나)이 필요합니다.

컨테이너 관리 트랜잭션 롤백

컨테이너 관리 트랜잭션의 롤백에는 두 가지 방법이 있습니다. 먼저 시스템 예외가 발생하면 컨테이너는 자동으로 트랜잭션을 롤백합니다. 두 번째로 EJBContext 인터페이스의 setRollbackOnly 메소드를 불러내서, Bean 메소드가 컨테이너에게 트랜잭션 롤백을 지시할 수 있습니다. Bean이 응용 프로그램 예외를 발생시키면 롤백이 자동으로 실행되지 않아도 setRollbackOnly를 호출하여 초기화할 수 있습니다.

다음 예에서 BankEJB 예의 transferToSaving 메소드는 setRollbackOnly 메소드를 나타내고 있습니다. 수표 계정의 잔액이 마이너스가 되면, transferToSaving은 setRollBackOnly를 불러내고 응용 프로그램 예외(InsufficientBalanceException)를 발생시킵니다. updateChecking 및 updateSaving 메소드는 데이터베이스 테이블을 업데이트합니다. 업데이트에 실패하면 메소드는 SQLException을 발생시키고 transferToSaving 메소드는 EJBException을 발생시킵니다.

EJBException은 시스템 예외기 때문에, 컨테이너는 자동으로 트랜잭션을 롤백합니다. 다음은 transferToSaving 메소드의 코드입니다.

public void transferToSaving(double amount) throws
InsufficientBalanceException {

checkingBalance -= amount;
savingBalance += amount;

if (checkingBalance < 0.00) { 
context.setRollbackOnly();

throw new InsufficientBalanceException(); 
}
try {
updateChecking(checkingBalance);

updateSaving(savingBalance);
} catch (SQLException ex) {
throw new EJBException 
("Transaction failed due to SQLException: " 
+ ex.getMessage());
}
}

컨테이너가 트랜잭션을 롤백하는 경우, 이것은 항상 트랜잭션 내의 SQL 호출로 발생한 데이터 변경을 모두 실행 취소합니다. 하지만 컨테이너는 Entity Bean에서만 인스턴스 변수에 대한 변경을 취소합니다(이 작업은 Entity Bean의 ejbLoad 메소드를 자동으로 호출하여 수행하며, 데이터베이스에서 인스턴스 변수가 로드됨). 롤백이 발생하면 Session Bean은 트랜잭션 내에 변경된 인스턴스 변수를 명시적으로 다시 설정합니다. Session Bean 인스턴스 변수를 다시 설정하는 가장 쉬운 방법은 SessionSynchronization 인터페이스를 구현하는 것입니다.

트랜잭션 ID를 명령줄 인터페이스를 통해 전달하여 트랜잭션을 롤백할 수도 있습니다. 자세한 내용은 "명령줄 인터페이스를 사용한 트랜잭션 관리"를 참조하십시오.

Session Bean의 인스턴스 변수 동기화

SessionSynchronization 인스턴스(선택적)를 사용하면 인스턴스 변수를 데이터베이스 내의 대응하는 값과 동기화할 수 있습니다. 컨테이너는 트랜잭션의 각 주요 단계에서 SessionSynchronization 메소드(afterBegin, beforeCompletion 및 afterCompletion)를 불러냅니다.

afterBegin 메소드는 새 트랜잭션이 시작되었음을 인스턴스에게 알립니다. 컨테이너는 처음으로 트랜잭션 내의 비즈니스 메소드를 불러내기 전에 먼저 afterBegin을 불러냅니다. afterBegin 메소드는 데이터베이스에서 인스턴스 변수를 로드하기에 좋은 위치입니다. 예를 들어, BankBean 클래스는 afterBegin 메소드 내에 checkingBalance 및 savingBalance 변수를 로드합니다.

public void afterBegin() {

System.out.println("afterBegin()");
try {
checkingBalance = selectChecking();
savingBalance = selectSaving();
} catch (SQLException ex) {
throw new EJBException("afterBegin Exception: " +
ex.getMessage());
}
}

컨테이너는 비즈니스 메소드는 완료되었지만 트랜잭션이 완결되기 전에 beforeCompletion 메소드를 불러냅니다. beforeCompletion 메소드는 Session Bean이 트랜잭션을 롤백할 수 있는(setRollbackOnly를 호출하여) 마지막 장소입니다. 아직 인스턴스의 변수 값을 데이터베이스에 업데이트하지 않았다면, Session Bean은 이 작업을 beforeCompletion 메소드에서 수행합니다.

afterCompletion 메소드는 트랜잭션이 완료되었음을 표시합니다. 여기에는 boolean 값의 매개 변수 하나가 있으며, 트랜잭션이 완결되면 true, 트랜잭션이 롤백되면 false 값을 갖습니다. 롤백이 발생하면 Session Bean은 afterCompletion 메소드에서 데이터베이스의 인스턴스 변수를 새로 고칠 수 있습니다.

public void afterCompletion(boolean committed) {

System.out.println("afterCompletion: " + committed);
if (committed == false) {
try {
checkingBalance = selectChecking();
savingBalance = selectSaving();
} catch (SQLException ex) {
throw new EJBException("afterCompletion SQLException:
" + ex.getMessage());
}
}
}

컨테이너 관리 트랜잭션에 허용되지 않는 메소드

컨테이너가 설정한 트랜잭션 경계를 간섭할 수 있는 메소드는 모두 불러낼 수 없습니다. 금지되는 메소드 목록은 다음과 같습니다.

• java.sql.Connection의 완결, setAutoCommit 및 롤백 메소드.
• javax.ejb.EJBContext의 getUserTransaction 메소드.
• javax.transaction.UserTransaction의 모든 메소드.

하지만 Bean 관리 트랜잭션에는 이 메소드들을 사용하여 경계를 설정할 수 있습니다.

Bean 관리 트랜잭션

---

Bean 관리 트랜잭션의 경우, Session 또는 Message-Driven Bean 내의 코드에서 명시적으로 트랜잭션 경계를 표시합니다. Entity Bean은 Bean 관리 트랜잭션을 가질 수 없으며 대신 컨테이너 관리 트랜잭션을 사용해야 합니다. 컨테이너 관리 트랜잭션을 가진 Bean은 필요한 코드가 줄어들지만 한 가지 제한을 갖습니다. 메소드가 실행되면 Bean은 단일 트랜잭션에 관련되거나 아무런 트랜잭션에도 관련되지 않을 수 있습니다. 이 제한 때문에 Bean 코딩이 어려워지는 경우, Bean 관리 트랜잭션 사용을 고려해야 합니다.

다음 의사 코드는 Bean 관리 트랜잭션으로 구할 수 있는 세분화된 제어 종류를 표시합니다. 의사 코드는 여러 조건을 확인하여 비즈니스 메소드 내에서 여러 트랜잭션의 시작 또는 중지 여부를 결정합니다.

begin transaction
...
update table-a
...
if (condition-x)
commit transaction
else if (condition-y)
update table-b
commit transaction
else
rollback transaction
begin transaction
update table-c
commit transaction

트랜잭션 서비스 관리

---

관리 인터페이스 또는 명령줄 인터페이스를 사용하여 트랜잭션을 관리할 수 있습니다.

이 절에는 다음 주제가 포함됩니다.

• 관리 인터페이스를 사용한 트랜잭션 관리
• 명령줄 인터페이스를 사용한 트랜잭션 관리

관리 인터페이스를 사용한 트랜잭션 관리

관리 인터페이스를 사용하여 트랜잭션 모니터링, 로그 수준 설정, 고급 옵션 지정 등을 수행할 수 있습니다.

복구 정책 및 시간 초과와 같은 인스턴스 범위의 트랜잭션 서비스 속성을 제어할 수 있습니다. 여기에서 지정하는 등록 정보 및 구성은 server.xml 파일에 저장됩니다.

트랜잭션 서비스 옵션을 구성하려면 다음 작업을 수행합니다.

1. 관리 인터페이스의 왼쪽 창에서 트랜잭션 구성을 수정할 Sun ONE Application Server 인스턴스 트리를 엽니다.
2. 배포된 J2EE 서비스에서 트랜잭션 서비스를 선택합니다. 관리 인터페이스 오른쪽 창의 그림 트랜잭션 서비스 구성 옵션에 표시된 다음 창이 나타납니다.

   트랜잭션 서비스 구성 옵션

 

3. 트랜잭션에 대한 모니터링을 활성화하려면 "모니터링 활성화" 확인란을 표시합니다. 다음 표는 모니터링될 수 있는 Java Transaction Service 기능을 나열합니다.

   Java Transaction Service의 모니터링 가능한 속성

등록 정보	Type	설명
transactionsCompleted	int	모니터링이 활성화된 후 완료된 트랜잭션 개수
transactionsRolledBack	int	모니터링이 활성화된 후 롤백된 트랜잭션 개수
transactionsRecovered	int	모니터링이 활성화된 후 복구된 트랜잭션 개수
transactionsInFlight	int	현재 처리 중인 트랜잭션 개수
timeStamp	long	통계가 작성된 타임스탬프(밀리초 단위). 이것은 모두 System.getCurrentTimeInMillis()에서 보고합니다.

4. "로그 수준" 드롭다운 목록에서 트랜잭션에 설정할 로그 수준을 선택합니다. 로그 수준 및 통합 방법의 자세한 내용은 "로깅 사용"을 참조하십시오.
5. 서버 재시작시 실패한 트랜잭션을 자동으로 복구하려면 "재시작시 복구" 확인란을 표시합니다. 트랜잭션 완결 프로토콜의 크리티컬 포인트 동안 자원을 사용할 수 없으면, 트랜잭션은 완료되지 못하고 트랜잭션 로그 파일에 남을 수 있습니다. 이 확인란이 표시되어 있으면 서버는 서버 재시작시 오류가 발생한 트랜잭션 복구를 시도합니다. 관련 자원에 여전히 접근할 수 없으면 서버 재시작 시간이 지연될 수 있습니다. 이 확인란은 기본적으로 표시되지 않습니다.
6. 컨테이너 관리 트랜잭션이 있는 Enterprise Bean의 경우, 트랜잭션 시간 초과(초) 등록 정보의 값을 설정하여 트랜잭션 시간 초과 간격을 제어할 수 있습니다.

이 등록 정보의 값이 0으로 설정되면 트랜잭션은 시간 초과되지 않습니다.


"트랜잭션 시간 초과(초)" 필드에 트랜잭션 시간 초과 간격을 지정합니다. 트랜잭션이 지정된 시간 내에 완료되지 않으면 트랜잭션은 롤백됩니다. 이 속성의 값이 0으로 설정되면 트랜잭션은 시간 초과되지 않습니다.

7. "트랜잭션 로그 위치" 필드에 로그 파일을 저장할 디렉토리의 절대 경로를 지정합니다. 새로 지정한 트랜잭션 로그 디렉토리를 적용하려면 서버를 재시작해야 합니다.
8. "발견적 결정" 드롭다운 상자에서 트랜잭션에 적용할 발견적 결정을 선택합니다. 명백한 결과를 결정할 수 없는 경우 표시된 옵션에서 완결 또는 롤백을 선택하여 응용 프로그램 서버에서 복구 도중 의심스러운 트랜잭션의 결과를 결정하는 방법을 지정합니다. 발견적 결정을 롤백으로 설정하면 트랜잭션을 롤백합니다. 이런 트랜잭션을 완결하는 것이 허용되는 경우도 있습니다.
9. "키 포인트 간격(트랜잭션)" 필드에 로그의 키 포인트 작업 사이의 트랜잭션 개수를 지정합니다. 키 포인트 작업은 완료된 트랜잭션의 항목을 제거하고 파일을 압축하여 트랜잭션 로그 파일의 크기를 줄입니다. 이 속성 값이 커지면 트랜잭션 로그 파일이 커지지만, 키 포인트 작업이 줄어들어 성능이 좋아질 수 있습니다. 이 값이 작아지면(예를 들어, 100) 로그 파일이 작아지지만, 키 포인트 작업 빈도가 높아져서 성능이 약간 낮아질 수 있습니다.

명령줄 인터페이스를 사용한 트랜잭션 관리

다음 절에서 설명한 것처럼, CLI (Command Line Interface)를 사용하여 데이터베이스 트랜잭션을 관리 및 모니터링할 수 있습니다.

• 실행 중인 트랜잭션 나열
• 트랜잭션 관리
• 트랜잭션 서비스 고정
• 트랜잭션 모니터링

이 절은 명령줄 인터페이스를 사용한 트랜잭션 관리 및 모니터링 방법을 설명합니다.

실행 중인 트랜잭션 나열

다음 명령은 실행 중인 트랜잭션 데이터를 구할 때 사용됩니다(multimode에 있고 이미 사용자 이름 및 암호를 설정했다고 가정합니다).

- asadmin> get --monitor
<instanceName>.transaction-service.inflight-tx

다중 행 출력은 다음과 같습니다.

Transaction Id State Elapsed Time (ms)

txnid1 Prepared 20

txnid2 Active 100

txnid3 Active 120

... ... ...

트랜잭션 관리

실행 중인 트랜잭션 나열의 예에서는 트랜잭션 ID txn-ids, txnid2 및 txnid3로 트랜잭션을 롤백한다고 가정합니다. 선택한 트랜잭션을 롤백하는 샘플 명령은 다음의 예와 같습니다.

asadmin> set --monitor <instanceName>.transaction-service.rollback-list=txnid2,txnid3

트랜잭션 서비스 고정

트랜잭션 서비스를 고정하려면 다음 명령을 실행합니다.

asadmin> set --monitor <instanceName>.transaction-service.freeze=true

트랜잭션 서비스가 고정되면 응용 프로그램 서비스 내의 트랜잭션 관리자는 모든 실행 중인 트랜잭션이 일시 중단됩니다. 고정은 제품 배포 시스템에서는 권장하지 않습니다.

트랜잭션 서비스를 고정 해제하려면 다음 명령을 실행합니다.

asadmin> set --monitor <instanceName>.transaction-service.freeze=false

트랜잭션 서비스가 다시 동작 중으로 설정되면 시스템은 중단되었던 지점부터 다시 계속합니다. 활성 시스템을 너무 오래 고정 상태로 두면 일부 데이터베이스 연결이 시간 초과되어 트랜잭션이 롤백될 수 있습니다.

트랜잭션 모니터링

실행 중인 트랜잭션 데이터를 포함하여 트랜잭션 데이터를 모니터링하려면 다음 명령을 실행합니다.

asadmin> get --monitor <instanceName>.transaction-service.*

명령을 실행했을 때 활성 트랜잭션이 없으면 다음 출력을 구할 수 있습니다.

total-tx-completed = 5

total-tx-rolledback = 2

total-tx-inflight = 0

isFrozen = false

tx-inflight = No active transactions found.

명령을 실행했을 때 활성 트랜잭션이 있으면 다음 출력을 구할 수 있습니다.

total-tx-completed = 5

total-tx-rolledback = 2

total-tx-inflight = 2

isFrozen = false

tx-inflight =

Transaction Id State Elapsed Time(ms)

txnid1 Prepared 500

txnid2 Active 360

출처 - https://docs.oracle.com/cd/E19957-01/816-6865-10/agjts.html#266545

Undo tablespace

- 사용자가 DML 을 수행할 경우 원본 데이터(undo data)들을 저장해 두는 특별한 Tablespace

- 사용자가 생성 가능하며 관리 할 수 있음

- Undo 라는 용어는 8i 버전까지 rollback 이라는 용어로 사용됨

1. Undo tablespace 의 특징

- Oracle Server Process 는 이 Tablespace 에 Undo segment 를 생성하고 기본적으로 각 사용자 별로 undo segment(ex: _SYSMU1$) 를 할당하여 관리하며 사용자는 관여할 수 없음

- Undo tablespace 는 Instance 당 여러 개가 동시에 존재 할 수 있지만 사용되는 것은 한번에 1개이다.

-> create undo tablespace undo01 datafile '/~~~~/undo01.dbf' size 10M 으로 만들어 줘도 파라미터에 적용 시키지 않으면 바뀌지 않음

- 관리 방법은 AUM(Automatic Undo Management) 과 MUM(Manual Undo Management) 이 있음 -> 9i 버전 부터는 AUM 방식을 권장

2. Undo Tablespace 의 사용 목적

- Transaction Rollback – 사용자가 rollback 이라는 명령어를 수행할 경우에 이곳에 저장된 undo data를 사용해서 rollback 을 수행함

- Read Consistency (읽기 일관성) –CR 작업을 통해 트랙잭션이 끝나지 않은 데이터는 변경 전 데이터를 보여줌.

- 다음 그림과 같이 update 가 발생하면 Datafile 에서 DB Buffer Cache 로 데이터 블록을 불러오게 되며 블록에는 lock 이 설정되어 아무도 내용을 볼 수 없는 상태

- 또한 원본 Data(Undo Data) 는 undo segment 에 저장되게 된다.

 - Update 가 수행되던 중 사용자 2에 의해서 select 가 수행되었을 때 undo segment 에서 DB Buffer Cache 로 원본 Data 를 복사하여 사용자 2에게 결과값을 보여주게 됩니다. 대신 1(홍길동) Data 는 lock 이 설정되어 commit 이나 rollback 이 수행되기 전까지는 1 block 에 다른 사용자가 접근할 수 없습니다.

- Transaction Recovery (Instance recovery) : 운영 중이던 DB 서버가 비정상적으로 종료 되었을 때 Roll Forward 와 Roll backward 작업을 수행해서 Dirty Database 를 Clean DB 로 만들어 주는 과정에 사용됨

- Undo Parameter 확인

- 신규 Undo Tablespace 생성

SQL>create undo tablespace undo01

2 datafile '/data/temp2/undo01.dbf' size 10M

3 autoextend on;

Tablespace created.

- Undo tablespace 를 생성 하여도 파라미터 파일을 변경 하여야 함.

SQL>alter system set undo_tablespace=undo01;

-PFILE 의 경우 파라미터 값을 직접 변경해야 나중에 다시 DB Open 시 문제가 발생하지 않는다.

- 각 세션 별로 사용중인 undo segment 확인

SQL>select s.sid,s.serial#,s.username,r.name "ROLLBACK SEG"

1 from v$session s,v$transaction t,v$rollname r

2 where s.taddr=t.addr

3 and t.xidusn = r.usn;

3. Undo segment 할당되는 원리

- Undo tablespace 는 Data file 의 크기가 증가만 되고 절대 줄어들지 않는다.

<하늘색 : 트랜잭션 완료, 갈색 : 트랜잭션 미완료>

다음과 같이 사용자가 DML(E) 을 수행하게 되면 가장 먼저 Server Process 는 Undo Segment 를 확보하게 되는데 이 때 기존에 만들어져 있던 Segment 중 트랜잭션이 완료된 것이 없는지를 확인한 후 그 곳에 덮어쓰게 됩니다.

- 다음과 같이 완료된 트랜잭션이 존재하지 않을 경우 새로운 undo segment 를 새로 생성하게 됩니다.

- 이런 식으로 더 이상 빈 공간이 존재하지 않을 경우 Data file 의 저장 공간이 허요하는 범위까지 늘어나다가 만약 더 이상 공간이 없게 되면 하나의 Segment 에 2개 세션 이상의 undo data를 함께 기록하게 됩니다. 이것조차 불가능하게 된다면 해당 트랜잭션은 에러를 발생 합니다.

- Undo tablespace 의 용량을 줄이기 위해서는 새로운 Undo Tablespace 를 생성후 파라미터 값을 변경시킨 다음 기존 Undo Tablespace 를 삭제 하셔야 합니다.

4. 주요 Parameter

- undo_retention àcommit 수행 후에도 해당 undo segment 내의 데이터를 다른 서버 프로세스가 덮어 쓰지 못하고 일정 시간동안 대기 시켜주는 파라미터이며 이 파라미터는 undo segment 의 여분이 존재할 경우에만 적용되며 항상 보장하지 않습니다.

- undo_retention_guarantee à undo_retention 파라미터는 여분이 존재하지 않을 경우 undo segment 가 재사용 되어지는데 반해 undo_retention_guarantee 파라미터는 설정된 시간동안 무조건 보장해줍니다.

- Oracle 10g 버전 부터는 ORA-01555:Snapshot too old 라는 에러를 줄이기 위해 undo retention 을 자동으로 관리하는 기능을 제공합니다.

- 다음은 undo tablespace 를 확인하고 guarantee 로 바꿔주는 명령어

SQL>alter tablespace undotbs retention noguarantee;

- no guarantee 로 변경하는 명령어

- NOT APPLY 는 Undo tablespace 가 아니므로 적용할 수 없습니다.

출처 - http://thankyeon.tistory.com/31

DML 문의 처리과정
==================

1. 해당 트랜잭션에 대해 언두 세그먼트를 할당한다.  이 경우 현재 온라인 상태인 언두 세그먼트 중
   하나를 우선적으로 사용한다. 언두 세그먼트의 선택은 랜덤하게 이루어지며, 다른 트랜잭션이 사용
   중이면 3번까지 재시도 한다.(undo segment는 block 단위로 owner ship을 갖는다.)
   이 과정에서 실패하면 오프라인 상태의 언두 세그먼트를 온라인화해서 사용한다.
   만인 이과정까지 실패하면, 새로운 언두 세그먼트를 생성한다.
   위 과정에서 언두 세그먼트를 할당받지 못하면 오라클 8i까지 사용하던 롤백 세그먼트
   알고리즘을 사용한다. 즉, 이미 다른 트랜젝션에 의해 사용 중인 언두 세그먼트 중 가장 사용량이
   적은 것을 사용한다. 서버 프로세스가 언두 세그먼트를 획득하는 시점에 적당한 온라인 상태의
   언두 세그먼트가 없으면 온라인 상태의 언두 세그먼트가 확보될 때까지 
   enq: US - contention 이벤트를 대기한다.
   
2. 언두 세그먼트를 할당받으면, 언두 세그먼트 헤더에 트랜잭션 테이블 슬롯(Transaction table slot)을
   생성한다.
   
3. 트랜젝션 테이블을 생성하고 나면 TXID(Transaction ID)를 생성하고, 현재 트랜잭션에 할당한다.
   TXID는 V$TRANSACTION 뷰의 XIDUSN, XIDSLOT, XIDSQN으로 표현되는데, 이 값은 트랜젝션에 할당된
   언두 영역의 언두 세그먼트 헤더에 존재하는 트랜잭션 테이블의 정확한 위치를 가리킨다. 트랜잭션은
   반드시 언두 영역을 할당받은 다음에 ID를 부여받은 것에 유의하자.
 
4. 트랜잭션의 대상이 되는 블록들을 버퍼 캐시로 적재하고 블록 헤더의 ITL(Interested Transaction List)에
   트랜잭션 엔트리(Transaction Entry)를 등록한다. 만일 ITL에 엔트리를 등록할 공간이 없다면, 공간이
   확보될 때까지 enq:TX - allocate ITL entry 이벤트를 대기한다.
   
5. 변경할 블록들의 변경 정보는 PGA에 체인지 벡터라는 이름으로 저장된다. 보통 하나의 로우가 변경되는 경우
   각각 언두 헤더 블록(체인지 벡터#1), 언두 블록(체인지 벡터#2), 데이터 블록(체인지 벡터#3)에 해당하는
   체인지 벡터들이 생긴다. 프로세스는 PGA의 체인지 벡터들을 리두 레코드(또는 리두 엔트리)라는 이름으로
   리두 버퍼(Redo Buffer)로 복사한다. 리두 버퍼에 변경 내용을 복사하는 과정에서 redo copy 래치, redo
   allocation 래치, redo writing 래치를 획득해야 한다. 이 과정에서 래치 경합이 발생하면 각각 
   latch: redo copy, latch: redo allocation, latch:redo writing 이벤트를 대기한다.
   
6. 이전 이미지(Before Image)에 대한 정보를 언두 블록에 기록하고, 데이터 블록을 변경한다. 변경된
   데이터 블록은 더티(Dirty) 상태가 된다. 또한 변경된 데이터 블록에 대한 CR 블록이 버퍼 캐시에 생성된다.
   만일 변경하고자 하는 로우가 현재 다른 트랜잭션에 의해 변경 중(즉 변경 후 아직 트랜잭션이 종료되지 않은
   상태)이라면 해당 트랜잭션이 종료되기를 기다려야 하며 enq: TX - row lock contention 이벤트를 대기한다.
   
7. 커밋이 수행되면, 트랜잭션에 SCN을 할당한다. 커밋 정보는 리두 버퍼에 저장된다.

8. 언두 세그먼트 헤더의 트랜잭션 테이블에 커밋이 이루어졌음을 저장하고, 락을 포함한 모든 리소스에 대한 점유를
   해제한다.
   
9. 리두 버퍼의 내용이 리두 로그 파일에 기록된다. 변경된 블록들은 이후 DBWR에 의해 데이터 파일로 기록된다.

출처 - http://support.dbworks.co.kr/index.php?document_srl=3593&mid=ora_tb

트랜잭션 내부작업 진행 9단계

1.  해당 트랜잭션에 대해 언두 세그먼트를 할당.

2. 언두 세그먼트에 트랜잭션 테이블 슬롯을 생성.

3. TXID(transaction ID) 생성

SQL> delete scott.emp;

SQL> select xidusn, xidslot, xidsqn from v$transaction;

4. 블록헤더의 ITL에 트랜잭션 엔트리를 등록, ITL에 공간이 없다면 enq:TX – allocate ITL entry 이벤트 대기

5. 변경정보는 PGA에 체인지 벡터라는 이름으로 저장된다. 언두헤더블록, 언두블록,데이터블록 프로세스는 PGA의 체인지 벡터들을 리두 레코드라는 이름으로 리두버퍼에 복사한다.

6. 이전 이미지에 대한 정보를 언두 블록에 기록하고, 변경된 데이터 블록에 대한 CR블록이 버퍼캐시에 생성된다. 만일 다른 트랜잭션에 의해 변경 중이라면 종료될 때까지 enq:TX – row lock contention 이벤트 대기

7. 커밋이 수행되면, 트랜잭션에 SCN을 할당, 커밋 정보는 리두버퍼에 저장

8. 언두 세그먼트헤더의 트랜잭션 테이블에 커밋정보를 저장, 락을 포함한 리소스에 대한 점유 해제

9.  리두버퍼의 내용이 리두 로그파일에 기록된다

출처 - http://salme.tistory.com/1

1)SELECT 명령어 처리

(PARSING LEVEL) 

1.서버 프로세스 구문분석 요청

  사용자가 SQL 명령어들을 입력하면 SQL명령어는 text string으로 서버로 전송하게 된다.

2.소프트 파싱과 하드 파싱

  SGA의 라이크러리 캐쉬에서 동일문장을 실행했던 실행계획을 검색 동일 실행계획을 존재하면 DB버퍼캐쉬에서 해당결과를 찾아 바로 유저에서 Fetch 작업을 함, 동일문장이 존재하지 많으면 딕셔너리 캐쉬에서 오브젝트를 참조하여 하드파싱한다.

3. 문장검사

parsing과정이 많기 때문에 오라클의 처리 속도를 올리기 위해서는 동일한 SQL문을 사용하여 library cache에서 바로 실행을 할 수 있게 해주는 것이 기본이 된다.

4. 데이터베이스 분석

  딕셔너리 캐쉬에서 티이블 및 갈럼 존재 유무를 확인한다.

5. 쿼리 단순화

  옵티마이져가 좀 더 좋은 실행계획을 생성하기 위해 내부적으로 SQL을 변경한다.

6. 권한확인

  시스템 테이블 스페이스에 저장된 DBA_SYS_PRIVS, DBA_TAB_PRIVS 뷰를 이용해 권한 확인한 후 딕셔너리 캐쉬에 저장한다.

7. 락 수행

   USER가 DML를 던지면 변경되는 ROW에 대한 ROW LOCK과 TABLE에 대한 TABLE LOCK이 발생.

 ROW LOCK (TX)

SQL 문장에서 WHERE 조건에 해당되는 ROW에 대하여 다른 유저들이 변경할 수 없도록  EXCLUSIVE LOCK 이 생긴다.  TX LOCK이 걸린 ROW는 DML 문장을 실행한 유저가 COMMIT이나 ROLLBACK을 할때 까지 걸리므로 다른 유저들이 변경할 수 없다.

 TABLE LOCK (TM)

   TX LOCK이 걸린 ROW가 저장된 TABLE에 대한 LOCK 이다.
DML SQL 문장을 수행하는 중에, 해당 테이블이 ALTER 나 DROP 되는 것을 방지하기 위해서 TM LOCK을 사용한다.
 같은 테이블에서 실행할 수 있는 SQL 문장과 실행할 수 없는 SQL 문장을 구분하기 위해서다. 
TM LOCK에는 RS(ROW SHARE), RX(ROW EXCLUSIVE), S(SHARE), SRX(SHARE ROW EXCLUSIVE), X(EXCLUSIVE) 가 있다.
 

8. Excute Plan 및 Tree 생성

9. 결과물이 SGA에 저장

(EXCUTE LEVEL)

  실행계획을 가지고 DB버퍼 캐쉬에서 해당 ROW를 검색 후 존재하면 결과값을 우저에서 전홍 한다.

 존재하지 않으면 데이터 파일에서 해당값을 검색하여 DB버퍼 캐쉬로 읽어 올린다.

(FETCH LEVEL) 

 유저에서 해당 결과값을 화면으로 출력해준다.

2) DML 구문 처리

(PARSING LEVEL)

1. 서버프로세스 구문분석요청

2. SGA의 라이브러리 캐쉬에서 동일문장 검색 .........-> 소프트 파싱 or 하드 파싱

3. 문장검사 

4. 데이터 베이스 분석 ... 딕셔너리 캐쉬에서 데이블 및 칼럼 존재 유무 확인

5. 옵티 마이저가 좀더 좋은 실행계획을 생성하기위한 쿼리 단순화

6. 권한확인

7. 락수행

8. Excute Plan 및 Patse Tree 생성

9. 결과물이 SGA에 저장

(EXCUTE LEVEL)

1. 실행 계획을 가지고 데이터파일의 해당 값을 검색하여 DB 버퍼 캐쉬로 읽어 올린다.

2. 서버프로세스는 언두 세그 먼트를 확보한다.

3. 변경된 내용을 리두 로그버퍼에 저장한다.

4. 변경 이전 이미지를 언두 세그먼트에 저장한다.

5. DB버퍼 캐쉬에 변경된 내용을 적용한다.

6. 유저에게 1row update라는 결과를 전송한다.

7. commit 명령어를 수행하면 리두 로그버퍼에 있는 변경된 내용을 리두 로그 파일에 기록한다.

   단 시점은 사용자에 의한 commit 명령이 발생 했을 경우

       리두로그 버퍼가 1/3이상 사용되었을 경우

       1MB 이상의 리두가 생성되었을 경우

       3초마다 리두 로그 파일에 내려 쓰여 진다.

출처 - http://mes2good.egloos.com/761982

Part1 오라클서버

1. 오라클 구성요소의 개요

- 오라클 주요 구성요소 : 서버, 인스턴스, 데이터베이스

* 인스턴스 :  오라클 인스턴스는 백그라운드 프로세스와 메모리 구조로 구성됩니다. 
                      인스턴스는 사용자가 데이터베이스의 데이터에 접근하기 위해서 반드시

                      시작되어 있어야 합니다

          인스턴스가 시작할 때 System Global Area(SGA)가 할당되고 오라클 
          백그라운드 프로세스들이 시작됩니다.

* 데이타베이스 : 오라클 데이터베이스는 데이터베이스 정보를 위한 실제 물리적인 저장을 
                           제공하는 운영체제 파일들로 구성됩니다 데이터베이스 파일들은 데이터가 
                           일관되게 유지되고 인스턴스 실패 시에 복구될 수 있도록 하는데 사용됩니다

1) 오라클 서버

- 데이터베이스 서버는 정보 관리에 아주 중요한 부분입니다. 일반적으로 많은 사용자가 동일한 데이터를 동시에 접근하는 환경에서 서버는 상당한 양의 데이터를 관리합니다. 또한 데이터베이스 서버는 권한이 없는 접근을 금지해야 하며 장애 시에 효과적인 복구를 제공해야 합니다

- 오라클 서버는 오픈되고 포괄적이고 통합된 접근을 제공하는 데이터베이스 관리 시스템

- 오라클 서버는 오라클 인스턴스와 오라클 데이터베이스로 구성

2) 오라클 인스턴스

- 오라클 인스턴스는 아래 그림과 같이 System Global Area(SGA) 메모리 구조와 데이터베이스 관리 에 필요한 백그라운드 프로세스들로 구성

  - 하나의 인스턴스는 각각의 운영체제에서 지정하는 방법에 따라 확인되며, 한번에 하나의 데이터베이스에 대해서 오픈되고 사용

- 오라클 인스턴스는 오라클 데이터베이스에 접근할 수 있는 방법

- 오라클 인스턴스는 하나의 데이터베이스에만 오픈

- 오라클 인스턴스는 메모리와 백그라운드 프로세스들로 구성

3) 접속과 세션

- 사용자는 오라클 데이터베이스에서 SQL 문장을 수행하기 전에 인스턴스에 접속해야만 합니다

- 인스턴스에 접속하는 과정

  . 사용자가 SQL*Plus를 시작하면 사용자 프로세스가 시작됩니다.

  . 사용자가 오라클 서버에 로그온 하면 서버에는 서버 프로세스가 시작됩니다

  . 서버 프로세스는 사용자 프로세스를 대신하여 인스턴스와 통신합니다

-  접속 : 접속은 사용자 프로세스와 서버 프로세스간의 통신 수단입니다. 데이터베이스 사용자는

             다음의 세가지 방법 중에 하나로 오라클 서버에 접속합니다

  . 오라클 인스턴스가 수행되고 있는 시스템에 로그온하여 SQL*Plus를 수행

  . 오라클 인스턴스가 수행되고 있는 시스템과 네트워크로 연결된 컴퓨터에서 프로그램을 수행

  . 사용자 컴퓨터는 오라클 인스턴스와 네트워크로 연결되어 있는 응용프로그램 서버나 네트워크

    서버에 연결되어 있음

- 세션 : 세션은 사용자가 오라클 서버에 접속할 때 시작하여 로그아웃 할 때 끝납니다

※ Dedicated Server 환경에서는 한 개의 사용자 프로세스와 한 개의 서버 프로세스가 통신합니다

※ Shared Server 환경에서는 여러 사용자 프로세스가 한 개의 서버 프로세스를 공유합니다

4) 오라클 데이타베이스

- 물리적 구조

  . 물리적인 구조는 운영체제 파일들로서 데이터 파일, 리두 로그 파일, 컨트롤 파일로 구성되어 있음

  . 리두로그파일: 에러 시에 데이터들을 복구하기 위해 데이터베이스에서 만들어진 변경 정보들을

                           갖고 있음

  . 데이터파일 : 실제데이터를 갖고 있음

  . 컨트롤파일 : 데이터베이스의 무결성을 보장하기 위해 필요한 정보들을 갖고 있음

  . 오라클 서버는 데이터베이스를 구성하는 파일들은 아니지만 다른 파일들도 사용합니다

     @ 파라미터 파일 : 오라클 인스턴스의 특징을 정의하는 파라미터들을 갖고 있음

     @ 패스워드 파일 : 오라클 인스턴스를 시작하고 종료할 수 있는 권한이 있는 사용자를 인증

     @ 아카이브 파일 : 복구할 때 필요한 리두 로그 파일을 복사한 파일

- 물리적 구조

  . 논리적인 구조는 테이블스페이스, 세그먼트, 익스텐트, 블럭으로 구성되어 있으며 데이터베이스의

    물리적인 공간이 어떻게 사용되어 지는지를 나타냅니다

  . 테이블 스페이스 : 오라클 데이터베이스는 한 개 이상의 테이블 스페이스를 갖고 있음 

                               한 개의 테이블 스페이스는 한 개 이상의 세그먼트를 갖고 있음

  . 세그먼트 : 한 개의 세그먼트는 익스텐트들로 만들어짐

  . 익스텐트 : 한 개의 익스텐트는 논리적인 블럭들로 만들어 짐

  . 블럭 : 한 개의 블럭은 읽고 쓰기 위한 가장 작은 단위

2. 메모리 구조

- 오라클 메모리 구조는 System Global Area(SGA)와 Program Global Area(PGA)로

   구성되어 있습니다. SGA는 인스턴스가 시작할 때 할당되며 오라클 인스턴스의

   기본 구성요소입니다. PGA는 서버 프로세스가 시작할 때 할당됩니다 

1) System Global Area

- SGA는 Shared Global Area라고도 부릅니다. SGA에는 데이터베이스 프로세스들에 의해

   공유되는  데이터베이스 정보와 오라클 서버를 위한 데이터와 제어 정보가 저장되며, 오라클이

   설치된 컴퓨터의 가상 메모리에 할당됩니다

- SGA의 종류

  . Shared Pool

  . Database Buffer Cache

  . Redo Log Buffer

  . Large Pool

  . Java Pool

- 동적SGA

  . 오라클 9i부터, 동적 SGA는 인스턴스를 종료하지 않고 SGA 형태를 변경할 수 있는 기본조직을

    이행하므로, 인스턴스를 종료하지 않고 Database Buffer Cache와 Shared Pool의 크기를 변경할

    수 있습니다. Database Buffer Cache와 Shared Pool의 크기는 처음에는 작게 구성되었다가

    그들의 작업에 따라 SGA_MAX_SIZE의 최대 크기까지 성장 또는 축소될 수 있습니다

- SGA 크기

  . DB_CACHE_SIZE : 기본 블럭들의 Cache 크기 / UNIX의 기본은 48MB, NT의 기본은 52MB임

  . LOG_BUFFER : 리두 로그 버퍼에 할당될 바이트 수

  . SHARED_POOL_SIZE : 공유풀에 할당될 바이트 수 /기본은 16MB, 64bit에서는 64MB임

  . LARGE_POOL_SIZE : 대형풀의 크기 / PARALLEL_AUTOMATIC_TUNING=true로 설정되지

                                      않으면 기본은 0임

  . JAVE_POOL_SIZE : 자바풀의 크기, 기본은 24MB임

- SGA 크기 : SGA_MAX_SIZE - DB_CACHE_SIZE - LOG_BUFFER - SHARED_POOL_SIZE -

                      LARGE_POOL - JAVA_POOL

- 할당 단위 : Granule은 연속된 가상 메모리 할당 단위입니다. Granule의 크기는 SGA_MAX_SIZE

                      파라미터 값에 의해 계산된 SGA 전체 크기에 의존합니다

  . 계산된 SGA 크기가 128MB보다 적을 때 Granule 크기는 4MB

  . 계산된 SGA 크기가 128MB보다 클 때 Granule 크기는 16MB

  . Database Buffer Cache와 Shared Pool은 Granule 경계에 따라 확장되고 축소될 수 있습니다.  

    인스턴스가 시작할 때 오라클 서버는 각각의 구성요소에 한 개의 Granule을 할당합니다.

    데이터베이스가 계속 사용되면서 그들이 요구하는 것에 따라 더 많은 Granule을 할당합니다

  . SGA의 최소 구성은 다음과 같이 3개의 Granule입니다

    Redo Buffer를 포함한 Fixed SGA에 1개를 할당

    Database Buffer Cache에 1개를 할당

    Shared Pool에 1개를 할당

2) Shared Pool

- Shared Pool은 가장 최근에 실행된 SQL 문장과 가장 최근에 사용된 Dictionary를 저장하기 위해

   사용되며 아래 그림과 같이 Library Cache와 Data Dictionary Cache로 구성됩니다

-  Shared Pool 의 크기

  . Shared Pool은 다시 사용될 SQL Execution plan과 PL/SQL package, procedure, function과

    Cursor 정보 들을 공유하기 위해 사용됩니다

  . Shared Pool의 크기는 초기 파라미터 SHARED_POOL_SIZE에 의해 결정됩니다.

    또한 ALTER SYSTEM SET 명령을 사용하여 동적으로 조정할 수 있습니다. 그렇지만

    전체 SGA 크기는 SGA_MAX_SIZE를 초과 할 수 없습니다

- 초기 파라미터 SHARED_POOL_SIZE로 크기를 결정합니다

- ALTER SYSTEM SET SHARED_POOL_SIZE = 64M

- 전체 SGA 크기는 SGA_MAX_SIZE를 초과 할 수 없습니다

- Library Cache

  . Library Cache 크기는 Shared Pool의 크기에 의존하며 가장 최근에 사용된 SQL과 PL/SQL 문장

    에 관한 정보가 저장됩니다. 그러므로 Shared Pool의 크기가 너무 작으면, 이들 문장이 계속해서

    Library Cache에 올라오게 되어 성능에 영향을 미치게 됩니다

  . Library Cache는 LRU 알고리즘이 사용되므로 Cache가 꽉 차면 최근에 적게 사용된 Execution

    Plan과 Parse Tree를 제거하여 새로운 문장을 위한 공간을 만듭니다

  . Shared SQL : 다시 수행될 SQL문장을 위해 Execution Plan과 Parse Tree를 저장하며 동일한

                          SQL 문장이 다시 수행되면 Shared SQL에서 Parse 정보를 가져옴

                          동일한 문장이 되려면 글자와 스키마와 변수가 같아야 함

  . Shared PL/SQL : 가장 최근에 사용된 PL/SQL 문장을 저장

- Data Dictionary Cache

  . Data Dictionary Cache는 Row Cache 라고도 부릅니다. 오라클 서버에 의해 Dictionary 정보가

    필요하면 Dictionary Table로부터 정보를 읽어 Data Dictionary Cache에 저장합니다. Data

    Dictionary의 크기는 Shared Pool에 의존하므로, 만약 Data Dictionary의 크기가 너무

    작으면 서버에 의해 필요한 정보를 반복적으로 Dictionary Table로부터 읽게 됩니다. 그러므로

    Dictionary Cache로부터 읽는 것보다 속도가 느리게 됩니다

  . Data Dictionary Cache의 기능

    가장 최근에 사용된 Database 정보를 저장함

    파일, 테이블, 인덱스, 사용자, 권한, 기타 다른 객체 정보들이 저장됨

    Parse 단계에서 서버 프로세스가 Dictionary 정보를 찾음

3) Database Buffer Cache

- Query문을 수행하면 오라클 서버는 Database Buffer Cache에서 원하는 블럭들을

   찾습니다. 해당 블럭을 Buffer Cache에서 찾지 못하면 데이터 파일에서 블럭을 읽어

   Database Buffer Cache에 저장해 놓으므로 같은 블럭에 대한 요구가 있으면 메모리에서 그

   블럭을 찾을 수 있어 Physical Read를 하지 않아도 됩니다. 오라클 서버는 Database Buffer

   Cache에서 새로운 블럭에 대한 공간을 만들기 위해 최근에 사용이 안된 블럭들을 쫓아내는 LRU

   알고리즘을 사용합니다 

- Database Buffer Cache 크기

  . Database Buffer Cache안에 있는 각 버퍼의 크기는 DB_BLOCK_SIZE 파라미터에 의해 결정되는

    오라클 블럭 크기와 같습니다. Database Buffer Cache는 독립적인 sub-cache들로 구성되는데,

    DB_BLOCK_SIZE 파라미터는 기본 블럭 크기를 결정하며 SYSTEM 테이블스페이스에 사용됩니다

  . Database Buffer Cache 크기를 결정하는 파라메타

    DB_CACHE_SIZE : 기본 Buffer Cache 크기를 결정,반드시 지정하여야 하며 0으로 설정할 수

                                 없음

   DB_KEEP_CACHE_SIZE : 다시 사용되므로 메모리에 머무르게 하고 싶은 블럭을 위한 버퍼

                                           크기를 지정함

    DB_RECYCLE_CACHE_SIZE : 다시 사용되지 않으므로 메모리에서 제거하고 싶은 블럭을 위한

                                                 버퍼 크기를 지정함

- Buffer Cache Advisory

  . Buffer Cache Advisory는 다른 Cache 크기를 가졌을 때의 행동을 예견하기 위한 통계를 모으는

    작업을 활성화 혹은 비활성화 할 수 있다는 특징을 가지고 있습니다. 이 통계에 의해 제공되는

    정보는 주어진 작업에 따라 Database Buffer Cache 크기를 적당하게 조절할 수 있도록 합니다.

    Buffer Cache Advisory 정보는 V$DB_CACHE_ADVICE에 저장되며, DB_CACHE_ADVICE 초기

    파라미터로 활성화 할 수 있습니다

  . OFF : Advisory를 위한 메모리를 할당하지 않음

  . ON : CPU와 메모리의 과부하를 초래 / OFF 상태에서 ON으로 변경하면 ORA-4031 에러가 발생함

            / READY 상태에서 ON으로 변경하면 메모리가 할당되어 있어 에러가 발생하지 않음

  . READY : Advisory는 OFF되어 있지만 메모리는 할당되어 있음

4) Redo Log Buffer

- Redo Log Buffer는 데이터 파일 블럭들에 만들어진 변경을 포함하고 있는 순환 buffer입니다 

- 이 정보는 리두 엔트리 안에 저장됩니다 /

  . 리두엔트리 : INSERT, UPDATE, DELETE, CREATE, ALTER, DROP 명령에 의해 만들어진 변경전

                       의 데이타를 다시 만들기 위해 필요한 정보를 갖고 있음 

- Redo Log Buffer 크기 : 초기 파라미터 LOG_BUFFER에 의해 결정됩니다

5) Large Pool

- Shared Server, Oracle XA, Parallel Query Buffers에서 세션 메모리를 Large Pool에

   할당하므로 오라클은 공유하는 SQL 문장을 저장하기 위해 Shared Pool을 사용할 수 있습니다.

   따라서 Shared Pool 안의 영역에서 짐을 덜 수 있습니다. Shared Pool은 Shared Session 정보,

   I/O, Backup, Recover 프로세스들을 위하여 SQL Parse Tree를 메모리에서 포기할 필요가

  없습니다. 그러므로 Shared SQL을 확장하고 축소하며 발생하는 과부하를 줄여 성능이 좋아집니다

- Backup and Restore

  . BACKUP_DISK_IO=n, BACKUP_TAPE_IO_SLAVE=true 파라미터가 정의되었으면 Recovery

     Manager (RMAN)는 Large Pool을 사용합니다. 만약 Large Pool이 충분히 크지 않으면 Large

     Pool에 메모리 할당은 실패합니다. RMAN은 에러 메세지를 Alert! Log File에 기록하고 Backup이

    나 Restore를 위하여 I/O slaves를 사용하지 않습니다

- Parallel execution

  . PARALLEL_AUTOMATIC_TUNING=true 파라미터가 정의되었으면 Large Pool을 사용하고 그렇지

    않으면 Shared Pool을 사용합니다

- Large Pool 크기

  . LARGE_POOL_SIZE 파라미터에 의해 결정되며 이 파라미터는 동적이 아닙니다

- Large Pool 과 LRU list

  . Large Pool은 LRU list를 사용하지 않습니다. LRU list를 사용하는 Shared Pool안의 예약된

     공간과 다릅니다

6) Java Pool

- Java Pool은 선택적이지만 JAVA를 설치하거나 사용하려면 필요합니다. 크기는 JAVA_POOL_SIZE

   파라미터에 의해 결정되며, 기본 크기는 24MB입니다

7) Program Global Area

- Program Global Area 혹은 Process Global Area (PGA)는 단일 서버 프로세서나

  단일 백그라운드 프로세서를 위한 데이터와 제어정보를 갖고 있습니다. PGA는 프로세스가 시작할

  때 할당되고 프로세스가 종료되면 해제됩니다. 여러 개의 프로세스들에 의해 공유되는 SGA에 반해

  PGA는 단지 한 개의 프로세스에 의해 사용되는 영역입니다

- PGA 의 내용

  . PGA의 내용은 인스턴스가 Dedicated Server 혹은 Shared Server에서 운영되느냐에 따라 달라

     집니다. 일반적으로 PGA는 다음과 같은 정보를 포함

     Private SQL Area : bind 정보와 실행 메모리 구조 같은 데이터를 포함

     Session 메모리 : 세션 변수와 세션과 관련된 다른 정보를 포함

     SQL Work Area : Sort, Hash-join, Bitmap merge, Bitmap 생성시 사용

3. 프로세스 구조

오라클은 여러 가지 종류의 프로세스들을 갖고 있습니다. 사용자가 오라클 서버에
접속했을 때 시작하는 사용자 프로세스, 사용자가 세션을 만들었을 때 시작하여
오라클 인스턴스와 접속하는 서버 프로세스, 오라클 인스턴스가 시작했을 때
시작하는 백그라운드 프로세스가 그것입니다

1) 사용자 프로세스

- 데이터베이스의 정보를 요구하는 사용자는 먼저 오라클 서버와 접속을 해야 합니다. SQL*Plus

   같은 Tool을 사용하여 접속하면 사용자 프로세스가 시작됩니다. 사용자 프로세스는 오라클 서버와

   직접 작용하지 않는 대신 세션을 만들고 서버 프로세스를 시작시키는 User Program Interface

   (UPI)를 통해 접속합니다

2) 서버 프로세스

- 사용자가 접속하면 사용자의 요구를 처리하기 위해 서버 프로세스가 시작됩니다.

   서버 프로세스는 Dedicated Server process 혹은 Shared Server process가 될 수 있습니다.

   Dedicated Server 환경에서, 서버 프로세스는 한 개의 사용자 프로세스 요구를 처리하며 사용자

   프로세스가 종료하면 서버 프로세스도 종료합니다. 반면 Shared Server 환경에서, 서버

   프로세스는 여러 개의 사용자 프로세스 요구를 처리합니다. 서버 프로세스는 Oracle Program

   Interface(OPI)를 사용하여 오라클 서버와 통신합니다 

3) 백그라운드 프로세스

- 오라클은 뒤에서 설명할 다섯 개의 필수적인 백그라운드 프로세스와 옵션이 사용됐을 때

   시작하는 선택적인 백그라운드 프로세스가 있습니다

  . RECO : Recover

  . QMNn : Advanced Queuing

  . ARCn : Archiver

  . LCKn : Rac Lock Manager - Instance Locks

  . LMON : RAC DLM Monitor - Global Locks

  . LMDn : RAC DLM Monitor - Remote Locks

  . CJQ0 : Coordinator Job Queue background process

  . Dnnn : Dispatcher

  . Snnn : Shared Server

  . Pnnn : Parallel Query Slaves

- Database Writer (DBWn)

. 서버 프로세스는 변경을 Database Buffer Cache 안의 언두 블럭과 데이터 블럭에 기록합니다.

  DBWn은 Database Buffer Cache 안의 Dirty Buffer들을 데이터 파일에 기록합니다. 이렇게

  함으로써 Database Buffer Cache 안에 사용할 수 있는 많은 수의 Free Buffer를 보장할 수

  있습니다. 또한 서버 프로세스는 Database Buffer Cache 안에서만 변경을 하므로 데이터베이스의

  성능이 향상됩니다

. DBWn은 다음과 같은 경우가 될 때까지 데이터 파일에 기록을 지연합니다

  Checkpoint가 발생했을 때

  Dirty Buffer의 수가 한계에 도달했을 때

  서버 프로세스가 지정된 수의 블럭을 읽는 동안 Free Buffer를 찾지 못했을 때

  시간이 경과했을 때

  Real Application Clusters (RAC) 환경에서 ping을 요구했을 때

  테이블스페이스를 OFFLINE 시킬 때

  테이블스페이스를 READ ONLY로 변경시킬 때

  테이블을 DROP 하거나 TRUNCATE 시킬 때

  테이블스페이스를 BEGIN BACKUP 했을 때

- Log Writer (LGWR)

  . LGWR는 순차적으로 Redo Log Buffer를 리두 로그 파일에 기록합니다. 리두는 복구에 사용되므로

    LGWR는 리두가 디스크에 쓰여진 후에 COMMIT 명령을 확인합니다. LGWR는 데이터 파일에 기록

    하기 위해 DBWn을 부를 수도 있습니다 

  . LGWR는 다음과 같은 경우에 발생합니다

    COMMIT 명령이 수행됐을 때

    Redo Log Buffer가 1/3 이상 찼을 때

    Redo Log Buffer 안의 변경이 1MB를 초과했을 때

    DBWn이 Database Buffer Cache의 변경된 블럭을 데이터 파일에 기록하기 전 매 3초 마다

- System Monitor (SMON)

  . 오라클 인스턴스가 실패하면, 디스크에 기록되지 않은 SGA 안의 정보는 잃어버립니다.

    인스턴스를 잃은 후에 데이터베이스를 다시 시작하면 SMON이 자동적으로 인스턴스

    복구를 수행합니다 

  . 다음과 같은 순서로 인스턴스가 복구

- Process Monitor (PMON) 

. PMON은 실패한 프로세스를 다음과 같이 정리

  사용자의 현재 트랜잭션을 취소

  현재 걸려 있는 테이블 잠금과 로우 잠금을 해제

  사용자에 의해 유지되고 있는 다른 자원을 해제

  죽은 Dispatcher를 다시 시작함

- Checkpoint (CKPT)

. 매 3초마다 CKPT 프로세스는 리두로그 파일에서 복구가 시작될 위치를 확인하기 위해 컨트롤 파일

  안에 데이터를 저장합니다. 이것을 Checkpoint라고 부릅니다 

  Checkpoint의 목적은 한 시점 전에 Database Buffer Cache에서 수정된 모든 버퍼들이 데이터

  파일에 기록된 것을 보장하는 것입니다. 이 시점이 인스턴스 실패 시에 복구를 시작할 위치입니다.

  DBWn는 그 시점 이전에 Database Buffer Cache에서 변경된 모든 버퍼들을 기록합니다

  로그 스위치가 발생할 때 CKPT는 데이터 파일의 헤더에 Checkpoint 정보를 기록합니다

. Checkpoint는 다음과 같은 이유로 발생

  1. 메모리에서 수정된 데이터 블럭들이 주기적으로 디스크에 쓰여져 시스템 실패시에 데이터가

     손실되지 않도록 하기 위해

  2. 인스턴스 복구에 필요한 시간을 줄이기 위해, Checkpoint 이후의 리두 로그 엔트리만이 복구 필요

  3. 모든 COMMIT 된 데이터들이 데이터베이스 종료시에 데이터 파일에 기록된 것을 보장하기 위해

- Archiver (ARCn)

  . ARCn은 데이터베이스의 구성에 따라 선택이지만 디스크 손실 후에 데이터베이스를 복구하기 위해

    매우 중요합니다. 
    리두 로그 파일이 꽉 차면 오라클 서버는 다음 리두 로그 파일에 쓰기를 시작합니다. 한 개의 리두

    로그 파일에서 다음 리두 로그 파일로 옮겨 쓰는 것을 로그 스위치라고 부릅니다. 
    ARCn 프로세스는 로그 스위치가 발생하면 꽉 찬 리두 로그 파일의 백업을 시작합니다. 이렇게

    리두 로그 파일이 다시 사용되기 전에 자동적으로 백업되어 데이터베이스에서 만들어진 모든

    변경은 보관됩니다. DBA는 디스크가 깨진 경우 그 시점까지 데이터베이스를 복구할 수 있습니다 

. NOARCHIVELOG 혹은 ARCHIVELOG 모드로 운영

  NOARCHIVELOG : 리두 로그 파일은 로그 스위치가 발생할 때 겹쳐 쓰여 집니다

                              LGWR는 그 그룹에 대한 Checkpoint가 완료될 때까지 리두 로그 그룹을

                              겹쳐 쓸 수 없습니다. 이것은 COMMIT 된 데이터들이 인스턴스 실패 시에

                              복구될 수 있음을 보장합니다

  ARCHIVELOG  : 리두 로그 그룹은 다시 사용되기 전에 반드시 기록되어야 합니다

                           데이터베이스에서 만들어진 변경은 리두 로그 파일에 기록되어 있으므로 DBA는

                           데이터 파일의 물리적인 백업과 아카이브 파일을 사용하여 COMMIT 된 데이터의

                           손실 없이 데이터베이스를 복구할 수 있습니다

4. SQL 문장처리

사용자가 SQL*Plus를 사용하여 오라클 서버에 접속하면 사용자 프로세스가 시작하여
세션을 만들고 서버 프로세스를 시작시킵니다.
사용자 프로세스에서 수행시킨 SQL 문장을 서버 프로세스에서 처리할 때 사용되는 
구성요소는 SQL 문장의 종류에 따라 다릅니다. 어떤 구성요소는 SQL 문장 처리에
사용되지 않기도 합니다

- QUERY 문 처리

  . Parse (구문분석)

    1. 동일한 문장을 Library Cache에서 찾음

    2. 문법을 체크

    3. 객체명과 권한을 체크

    4. Parse 과정에서 사용되는 객체에 잠금을 함

    5. Execution plan을 생성하여 Library Cache에 저장함

  . Bind : 변수들에 값을 지정합니다

  . Execute : 문장을 처리합니다

  . Fetch : 사용자 프로세스에 데이터를 보냅니다

- DML 문 처리

  . Parse (구문분석)

  . Bind

  . Execute

    1. 데이터 블럭과 undo 블럭을 Buffer Cache에서 찾음

    2. 없으면 데이터 파일에서 읽어서 Buffer Cache에 저장함

    3. 변경될 데이터에 잠금을 함

    4. Redo Log Buffer에 변경 전 데이터와 변경 후 데이터를 기록

    5. 변경 전 데이터를 undo 블럭에 기록하고 데이터 블럭을 변경함

    6. Buffer Cache 안의 변경된 블럭은 Dirty Buffer로 기록됨

  . DELETE와 INSERT 문의 처리과정도 이와 유사합니다. DELETE 문의 변경 전 데이터는 삭제된

    로우의 전체 칼럼 값이며, INSERT 문의 변경 전 데이터는 로우의 위치 정보입니다

- DDL 문 처리

  . DDL 문의 실행은 DML 문이나 QUERY 문의 실행과 다릅니다.  왜냐하면 DDL 문의 성공은

    Dictionary에 쓰기를 요구합니다. 실제 Parsing은 Parsing과 Dictionary 검색과 Execution을

   포함합니다. Transaction Management, Session Management, System Management

   SQL 문이 Parse와 Execute 단계를 사용하여 처리됩니다

출처 - http://mes2good.egloos.com/763061#763061_1

OLTP (Online Transaction Processing) - 온라인 트랜잭션 처리

네트워크상의 여러 이용자가 실시간으로 데이터베이스의 데이터를 갱신하거나 조회하는 등의 단위 작업을 처리하는 방식을 말한다. 주로 신용카드 조회 업무나 자동 현금 지급 등 금융 전산 관련 부문에서 많이 발생하기 때문에 ‘온라인 거래처리’라고도 한다. 이 방식의 특징은 기존 컴퓨터 통신에서 이용해 온 온라인 방식과 달리 다수의 이용자가 거의 동시에 이용할 수 있도록 송수신 자료를 트랜잭션(데이터 파일의 내용에 영향을 미치는 거래 ·입출고 ·저장 등의 단위 행위) 단위로 압축, 비어 있는 공간을 다른 사용자들이 함께 쓸 수 있도록 한 점이다.

OLAP (OnLine Analytical Processing) - 온라인 분석 처리

OLAP는 사용자가 다양한 각도에서 직접 대화식으로 정보를 분석하는 과정을 말한다.OLAP 시스템은 단독으로 존재하는 정보 시스템이 아니며, 데이터 웨어하우스나 데이터 마트와 같은 시스템과 상호 연관된다. 데이터 웨어하우스가 데이터를 저장하고 관리한다면, OLAP은 데이터 웨어하우스의 데이터를 전략적인 정보로 변환시키는 역할을 한다. OLAP은 기본적인 접근과 조회·계산·시계열·복잡한 모델링까지도 가능하다. OLAP은 최근의 정보 시스템과 같이 중간매개체 없이 이용자들이 직접 컴퓨터를 이용하여 데이터에 접근하는 데 있어 필수적인 시스템이라 할 수 있다. 

OLAP 와 OLTP 의 차이점 

OLTP :  현재 업무의 효율적인 처리에만 관심이 있음

OLAP : 의사결정에 도움되는 데이터 분석에 관심이 있음

OLTP에서 가장 성능 좋은 DB를 만드는 방법에는 무엇일까요? 하드웨어의 성능을 올리거나, 확장하는 방법 또는 인덱스 생성 등 여러 가지 방법이 있겠지만, 가장 좋은 건 적합하고 합리적인 설계에 따른 DB모델링이 가장 중요하다고 생각 됩니다. OLAP도 마찬가지 입니다.

이번 시간에는 다차원모델에 대해서 알아볼 시간인데요, 처음부터 말씀 드리자면, OLTP와는 너무나 다른 설계 방법입니다. 또는 완전히 반대입니다. OLTP에서는 왼쪽으로 가야 한다면 OLAP에서는 오른쪽으로 가면 되겠네요~, 이러한 이유는 목적이 서로 틀리기 때문입니다. OLTP에서는 트랜잭션 단위로 처리하는 것에 중점이 있다면, OLAP은 최적화된 조회에 목적이 있기 때문입니다.

OLTP에는 관계형 데이터베이스(RDB)가 있다면, OLAP에서는 다차원DB(MDB or MDDB)가 있습니다. 비즈니스 영역, 또는 주제별 관점으로 구축되는 다차원DB를 설계하기 위해서는 다음의 구성요소가 필요 합니다.

가장 가운데 있는 다차원 모델은 별(Star), 눈꽃송이(Snowflake), 복합(Composite) 스키마로 구성됩니다. 별은 Star스키마, 눈꽃송이는 Snowflake스키마 라고 하겠습니다. 분석관점과 데이터 양에 따라서 모델을 선택하게 되는데, 대용량에서 가장 많이 사용되는 Star스키마부터 알아 보겠습니다.

하나의 Fact(사실)테이블과 다수의 Dimension(차원)테이블로 구성되어 실제 사용자가 쉽게 이해할 수 있도록 단순하게 모델링 되며,원하는 보고서를 만들기 위해 필요한 조인의 횟수를 줄임으로써 사용자 질의에 빠른 속도로 응답할 수 있다는 장점을 가졌습니다. 각 차원은 기본 키 - 외래 키 관계에 따라 Fact테이블에 직접 연결되어 있는 단일 Dimension테이블을 기반으로 합니다. 

예를 들어 위에 그림처럼 Dimension테이블을 성별과 연령으로 각각 만들어서 Fact테이블에 외래키로 연결하는 것입니다. OLTP에서는 회원에 대한 Dimension테이블을 하나만 만들어서 성별과 연령을 속성으로 가져가겠지만 Star스키마에서는 이렇게 역정규화를 하게 됩니다.

Star스키마는 대용량에서 많이 사용됩니다. 분석관점이 명확하고 데이터 건수가 많은 경우에 유리하지만, 다른 관점으로 분석 요구 시 Dimension테이블이 추가 되고 Fact테이블에 대해서 변경이 일어 날 경우 처음부터 다시 쌓거나 다른 사실테이블을 만들어야 하는 불편함이 있습니다. 그러다 보니, 비슷한 테이블들이 여러 존재하고 너무 많아 지면 ETL에서 시간이 늘어나는 점이 있으니 유의 해야 합니다. 경험상으로는 분석관점이 명확할 때 사용해야 하는데 그렇지 않을 경우에는 Snowflake스키마가 더 적합할 때가 있습니다.

Snowflake스키마는 다음과 같은 구조를 가집니다.

Star스키마의 Fact테이블 구조와 동일하게 유지하면서 Dimension테이블이 정규화된 구조를 말합니다. 

위에 Star스키마와 예와 비교한다면 회원에 대한 Dimension테이블을 하나를 만들어서 다시 여기서 성별 Dimension,연령Dimension을 생성한 후 회원Dimension과 연결하는 구조 입니다. 매출 Fact테이블에는 회원번호와 같이 식별할 수 있는 속성을 가지게 됩니다.

Snowflake스키마는 그래서 확장에 용이 합니다. 회원에 대한 속성에서 직업이 추가 된다고 해도 매출 Fact에는 변화가 없고 회원Dimension에 직업속성과 직업이라는 Dimension이 추가만 되면 됩니다. 하지만 Star스키마에 비해 많은 데이터를 보유 할 수 있으므로, 성능과 집계에 영향을 미칠 수 있습니다. 그리고 데이터 중복을 피할 수 있으나, 이해하기 어려운 단점이 있을 수 있습니다.이렇게 중간에 회원 Dimension과 같이 참조되는 테이블을 Outboard 또는 Outrigger 라고도 합니다.

Star스키마와 Snowflake는 각각 장단점을 가지고 있으므로, 실제 프로젝트에서는 획일적으로 설계하지 않고 복합적으로 설계합니다. 이러한 스키마 구조를 복합스키마 라고 합니다.

데이터의 무결성(Integrity)을 유지하고 데이터의 중복 성을 줄이기 위한 정규화와 성능향상을 위한 비정규화가 일정한 수준에서 조합된 형태를 취하게 됩니다. 여기서 두 가지를 항상 염두 해야 합니다. 첫 번째는 집계 상세수준을 고려해서 정의하는 것과 두 번째는 사용자 질의 유형과 질의 응답성능을 고려하여 적절한 수준에서 테이블을 비정규화 필요성 여부를 고려하는 것입니다.

알맞은 설계 방법을 선택하기 위하여 Fact테이블을 설계하기 전에 데이터의 차원 별 분포도를 먼저 파악하기도 합니다. 

그 외에 여러 개의 Star스키마의 집합관계를 가지고 있는 Constellation(별자리)스키마도 있습니다. 각기 다른 Fact테이블들이 동일한 Dimension테이블과 조인되는 구조입니다. 대게 Star스키마로만 이루어진 DM에서 나타납니다.

이렇게 다양한 스키마 구조들에 대해서 알아 보았습니다. 다시 한번 말씀 드리면, 한 스키마 구조에만 얽매이지 않고 데이터 양과 활용되는 관점에서 다양하고 자유로운 설계가 전체적인 BI프로젝트를 건강하게 합니다.

위에서 자주 언급된 Fact테이블에 대해서 구체적으로 함 알아 볼까요? Fact테이블은 정규화된 테이블로써 스키마에 중심에 위치하며 설계 시 가장 큰 테이블입니다, 수억 개의 행을 가질 수도 있을 정도로 엄청 큰 Big 테이블 입니다.

생성시 유의해야 할 점은 중복되는 데이터가 없어야 하며, 너무 큰 테이블의 경우에는 수직, 수평분할 고려해야 합니다. 또한 SQL 2005부터 지원하는 데이터 압축, 파티션 등을 적용하여 구성해야 합니다. 그리고 Fact테이블은 아래와 같은 특징을 가지고 있습니다.

l Dimension테이블과 연관된 키 구조를 가짐

l Dimension테이블과의 연관된 키 구조를 제외하고 숫자 형태의 포맷으로 주로 구성 (측정값)

l 측정값이 없는 Fact테이블은 Fact less Fact Tale(사실 없는 사실테이블)이라 하며, 카운트가능

그러면 측정값 집계 시 유형에는 3가지가 있다고 했습니다. 가산, 비가산, 반가산입니다. 각 집계유형에 따른 타입은 해당표를 참고 하시면 됩니다.

Fact테이블을 구성하면서 가장 많이 고민하는 문제는 Dimension테이블과 조인되기 때문에 인덱스 설계와, 참조 무결 성을 유지하기 위해서 ETL시 유의해야 하는 점입니다. 그리고 일반적으로 SUM할 수 있는 숫자 포멧의 값을 측정값이라고 합니다. 이러한 측정값은 가급적 가산형태로만 하는 것이 좋습니다. 반가산, 비가산 등의 측정값은 사용자에게 혼란 등을 야기할 수 있으며 데이터의 왜곡을 초래할 수도 있습니다. 또한 가급적 산신을 넣지 않습니다. 산식이 변경될 경우 재계산해서 UPDATE가 발생할 수 있는데, 이때UPDATE는 대용량에서는 바람직하지 않습니다. 그러면 UPDATE가 필요한 경우에는 병렬로 처리하는 CTAS가 오히려 유리할 수 있습니다. 

Fact테이블의 왜곡되는 현상을 아래 그림으로 살펴보면

인당 매출액을 평균값으로 Fact테이블에 적재할 경우, Type A: Sum(매출액)/Sum(고객수) = 인당평균매출액으로 구할 수 있지만, Type B: Sum(Avg(매출액)) / Count 로는 왜곡된 데이터가 나올 수 있으므로 유의해야 합니다.

많은 분들이 Fact테이블 구성 시 의문을 가지고 계시는 것이 바로 Dimension테이블과 FK를 만들어야 하는 가? 입니다. FK는 데이터의 정합성을 유지하는 Constraint로서 중요 합니다. 하지만 Fact테이블 적재하는 경우에 FK로 인하여 적재시간이 지연될 수 있는데, FK를 생략해서 나중에 테이블간의 정합성 체크를 하는 비용을 생각한다면 사전에 하는 것이 더 바람직해 보입니다.

일반적인 OLTP 모델링에서도 논리 명을 설계할 때 마찬가지 이겠지만, BI에서는 의사소통을 위해 더욱 강조 되는 부분이 명확한 명명 법 입니다. 예를 들면 ‘액’, ‘금액’ 등의 명명보다는 가급적 ‘매출액’, ‘판매액’ 등의 자세한 명명을 사용하여, 전사적으로 이해하는 용어를 사용하여 혼란을 야기 하지 않도록 합니다. 예를 들어 매출액 = 판매액 – 반품액, 매출액 = 판매액 등 ‘매출액’에 대한 이해가 부서마다 용어에 대한 이해가 다르다면 전사적으로 용어를 통일 시켜야 합니다. 

Fact테이블의 Row수는 차원의 상세수준에 따라 결정되는데, 이에 대해서 알아보겠습니다. 예를 들어 매장차원(20개 매장)과 상품차원(10개 상품)만으로 구성이 되어 있을 때, Fact테이블의 Row수는 20 X 10 가지의 경우의 수를 쉽게 예상할 수 있습니다. 또한 Dimension테이블의 수는 동일하나 상세수준으로 조절이 가능한데, 그림으로 표현하면 다음과 같습니다.

일반적으로 Dimension테이블의 수가 적을 수록 상세수준이 낮으며, 연관된 Dimension테이블들의 키(FK)의 경우의 수라고 보면 됩니다. 필요하다면 상세수준을 낮춰서 성능의 향상을 높일 수 있으며, 다양한 분석을 원한다면 높이는 것도 하나의 방법입니다. 이를 활용하여 실무자에게는 주문번호 별 매출 데이터를 보이고, CEO에게는 날짜 차원 별 데이터를 보여서 각각 리포트에서 성능을 조절하는 것입니다. 그러나 상세수준이 높은 Fact 테이블에서 상세수준이 낮은 Fact 테이블을 생성할 수 있으나, 반대로 상세수준이 낮은 Fact 테이블에서 상세수준이 높은 Fact테이블을 생성할 수 없으니 처음에 만들 테이블의 상세수준을 합리적으로 결정해야 합니다.

OLTP에서는 판매가 이루어질 때만 저장하므로, 10개의 매장에서 서로 다른 제품을 각각 1개씩팔았다면 10 Row가 되지만 다차원 모델에서는 10개 매장 * 10개 상품으로 Fact가 구성되므로 100 Row가 만들어 집니다. 이처럼 오히려 Fact테이블의Row수가 더 많게 되는데, 집계의 상세수준이 차원에 따라 달라진다는 점을 명심해서 집계의 효율성(성능)과 분석의 다양성 이라는 두 마리 토끼를 다 잡을 수 있게 고민의 고민을 거듭하게 됩니다. 

BI 프로젝트가 거의 마무리가 될 지점에서 테이블의 정보를 취합해 보면, 비슷한 Fact테이블들이 많이 존재하게 되는데, 이때 동일 상세수준과 동일Dimension테이블을 가진 Fact테이블간에 병합이 가능합니다. 이렇게 병합하게 되면 ETL 시간도 줄어 들고, 저장 공간도 절약되니 일석이조의 효과를 볼 수 있습니다. 단 업무적으로 상이한 Fact테이블 이라면, 분리되어 각각 존재하는 것이 향후 변경 Point가 적어 지므로 더 낳을 수 있습니다.

출처 - http://www.sqler.com/499404#0

이번 시간에서는 BI를 구축하기 위해서는 알아야 할 몇 가지 개념에 대해서 알아 보겠습니다.

아래 그림만 잘 이해할 수 있다면, 쉽게 이해가 되실 것 입니다.

공장에서 생산한 물건은 도매시장으로 넘어 오게 됩니다. 도매시장에서 다시 소매시장인 슈퍼마켓 등에서 물건을 구입하여 가정으로 오게 됩니다. 여러분들도 아시는 이러한 전통적인 프로세스는 물건이 공장에서 집으로까지 오는 일반적인 과정입니다.이러한 일련의 프로세스를 그대로 물건이 아니라 데이터에 비유하면 됩니다.

먼저, 정보를 생성하는 공장의 역할은 OLTP(On-Line Transaction Processing) 입니다. 기업 운영에 필요한 비즈니스 프로세스를 자동화한 시스템으로 인사, 급여, 구매, 생산, 재고, 물류 등 기업 운영의 전반적인 측면을 포함하고 있습니다. OLTP 시스템은 정보를 트랜잭션단위로 수집하고 분류, 저장, 유지보수, 갱신, 검색하는 기능을 빈번히 일어나는 수행 하는 시스템들입니다.

생산한 물건을 도매시장으로 모두 옮겼듯이, OLTP에서 발생한 데이터들을 모두 DW(Data Warehouse)라는 곳에 저장 합니다.사용자의 의사결정을 지원하기 위해 기업이 축적한 많은 데이터를 사용자 관점에서 주제별로 통합하여 아래와 같이 별도의 장소에 저장해 놓은 데이터베이스 입니다.

DW는 데이터 창고와 같은 개념이므로 몇 가지 특성이 있습니다. 

· 정보데이터를 위한 중립적인 저장영역

· 의사결정을 지원하기 위한 정제된 데이터

· 데이터의 단일공급원

· 데이터에 기반한 의사결정의 효율성향상

DW는 과거에서는 구축실패가 많았다고 합니다. Enterprise Data Warehouse(EDW)라고 하여 전사적으로 빅뱅방식으로 한번에 모두 구축하려다 보니, 노하우부족과 성숙되지 않은 설계가 주된 이유였습니다. 현재는 모델링부터 데이터이관을 위한 시스템까지 체계적으로 되어 있어 과거와는 달리 많은 기업들이 DW를 구축하고 있으며 다음과 같은 장점을 얻게 됩니다.

· OLTP(운영시스템)을 보호하고 사용자 질의에 신속한 응답성능을 제공할 수 있다.

· 여러 시스템에 산재된 데이터들이 DW로 취합되고 통합되므로 사용자는 자신들이 필요로 하는 데이터를 쉽게 가져다 쓸 수 있다.

· 데이터는 DW로 옮겨오기 전에 정제 및 검증과정을 거치게 되며, 따라서 사용자는 양질의 데이터를 사용할 수 있다

소매업인 DM(Data Mart)는 이해관계가 동일한 사용자 집단의 특화된 사용자 중심의 데이터장고로서, 동질적인 사용자 집단에게 유사한 비즈니스 모델과 비즈니스 언어를 제공함으로써 데이터에 대한 가 독성을 높이는데 초점을 맞춰져 있습니다. 이러한DM에는 다음과 같은 특징을 가지고 있습니다.

l 부서나 사용자집단의 필요에 맞게 자유롭게 가공

l 각 부서는 다른 부서에 영향을 주지 않고 필요한 시점에서 원하는 어떠한 프로세스도 가능

l DM에 없는 데이터를 필요로 할 경우 DW에 드릴스루(Drill-Through)할 수 있는 환경도 고려

그러면 DW와는 무슨 차이가 있는 것일까요? DW는 최종사용자와의 인터페이스보다는 방대한 분량의 데이터를 효율적으로 통합하고 관리하는 측면에 보다 초점을 맞춘다. 따라서 사용자 측면에서 편리한 형태로 설계되지 않을 수 있습니다. 그리고 전사적인 용도로 구축되기 때문에 각 개별부서나 사용자 집단에 적합한 형태로 데이터가 저장되지 않는다. 따라서 사용자 질의에 최적의 성능을 제공하지 못할 수도 있습니다. 대부분의 사용자들은 DW의 전체 데이터 중 일부분만을 주로 사용할 것이며, 기업의 모든 사용자들이 DW에 대해 직접 질의를 수행하는 것은 많은 시스템 자원을 필요로 하며 시스템 성능에 심각한 부하를 줄 수 있기 때문에 분산된 DB영역에서 구축 하는 것이 바람직합니다.

OLAP에 대해서 한번 알아 볼까요?

RDB와 OLAP의 창시자인 E.F CODD 박사가 10년전 돌아 가셨는데, 대용량에서 다양한 쿼리 후 결과를 얻는 것에 대해서 RDB의 한계를 느끼고 20여년전에 12개의 제언을 하였습니다. 이후 이러한 사상을 바탕으로 OLAP제품이 만들어지고 COGNOS, MSTR, BO, SQL SSAS등이 각축을 벌이고 있으며, 지금은 사상이나 처리방법에 대해서 OLAP에 대한 방향이 어느 정도 자리가 잡혀있는 상황입니다.

OLAP(On-Line Analytical Processing)은 OLTP에 상대되는 개념으로써, 최종 사용자가 다차원 정보에 직접 접근하여 대화식으로 정보를 분석하고 의사결정에 활용하는 과정입니다.

오른쪽과 같은 내용의 질의를 OLTP에서 쿼리로 만든다면 시간도 오래 걸리고, 빠른 결과를 낼 수가 없으며, 결정적으로 2년치의 판매테이블을 모두 읽어서 결과를 보기 위해서는 OLTP시스템에 영향을 줄 수 밖에 없을 것입니다. 그렇다고 OLTP에서 모든 것을 예측해서 리포트를 만들거나 할 수 없으므로, 업무 담당자가 원하는 관점에 따라 자유자재로 만들기가 어렵습니다. 또한 별도의 집계테이블을 가지고 있지 않는 이상 10초 안에 답을 구하기란 어려운 일입니다. 10초의 기준은 아래 같습니다.

사고의 흐름이 끊기지 않고 계속 분석하여 원하는 답을 얻어내는 것이 중요 합니다. 그리고 여기서 사용자는 매출액을 기간, 매장, 제품, 실적이라는 네 가지 각도에서 분석하였는데, 그림으로 표현하면 다음과 같습니다.

이러한 다양한 차원으로, 분석 목적에 적합하게 사용자의 관점에서 설정하게 되는데 이를 다차원분석이라고 합니다.

OLAP의 목표는 다음과 같습니다.

l 직접접근

전산 부서와 같은 정보 매개자를 거치지 않고 원하는 정보에 직접 접근하는 것입니다.

직접접근의 필요성은 전산부서에 요청 후 리포트를 얻기까지의 시간이 걸리며, 정형화된 양식이나 정보를 가공하려면 다시 의뢰해야 하는 번거로움이 발생할 수 있습니다. 의사결정에 활용하기 위해서는 사용자가 쉽게 이해할 수 있고, 조조작하기 쉬운 형태로 존재 사용자의 관점으로 보여줘야 학 때문입니다. 그러므로 사용자가 필요한 시점에 정보 매개자의 도움 없이 정보원에 직접 접근하여 다양한 각도에서 분석을 수행 할 수 있어야 합니다.

l 대화식 분석
하나의 질문에 대한 답은 또 다른 질문을 이끌어 냄으로써 사고의 흐름이 중간에 끊어지지 않도록 사용자 질의에 신속한 답을 제공해야 합니다

l 의사결정에 활용
기존 OLTP는 실제로 발생하고 기록되는 시스템으로 무엇(What)초점이 맞춰져 있는 반면, OLAP은 다차원 정보분석을 하여 왜(Why)라는 의사결정 활용 과점으로 시스템이 구축되어야 합니다.

BI프로젝트를 진행하다 보면, 일단 데이터를 모두 수집해와야 하고 모든 OLTP비즈니스를 담으려고 하는 강박관념에 빠지게 되면 자칫 프로젝트를 실패하게 됩니다. 항상 의사결정에 활용할 수 있는 것에 초점을 맞춰야 합니다. 리포트가 아무리 많아도 소용없으며, 단 하나의 리포트가 회사의 중요한 의사결정에 활용된다면, 100개의 리포트보다도 더 중요 합니다.

OLTP에서DW, DM, OLAP에 이르기까지의 과정에서 중간 중간에서 데이터를 이관하는 과정을 ETL이라고 합니다. E(Extraction – 추출), T(Transformation – 변형), L(Load – 적재)의 3가지 과정을 거치게 됩니다.ETL은 또는 ETT라고 합니다. 마지막에 T는 Transportation(수송) 입니다.

다음 그림과 같이 도식화할 수 있습니다. 중간에 변형작업에서 주로 하는 일은 바로 정제 입니다. OLTP에서 발생한 데이터를 그대로 이관하여 DW, DM을 만들게 될 때 가장 먼저 부딪히는 벽이 바로 데이터의 정합성 문제 입니다. 이를 해결하기 위해서 DQ(Data Quality)를 하게 되는데 다음에 알아 보도록 하겠습니다.

OLTP에서 DW로 바로 데이터를 넣기 전에 임시 영역이 있습니다. 이를 영어로 Staging 영역이라고 하며, 데이터베이스나 파일 시스템 기반의 물리적 저장소로서 각 영역 간의 데이터 이전/통합/가공을 원활히 하고 안정적으로 수행하기 위해 임시적으로 사용하는 영역이라고 할 수 있습니다.

DW에서 ODS(Operational data store)라고 하는 운영 데이터 영역은 분리된 각각의 원천 시스템으로부터 운영 데이터를 통합한 저장소를 말합니다. ODS에는 트랜잭션 레벨의 상세한 데이터가 전사적인 데이터 수요를 만족하는 일반적이고 통합된 데이터를 저장하고 있어 전사적인 정보가 트랜잭션 레벨의 상세한 형태로 중복이 제거되어 통합 저장되기 때문에, 운영 리포트를 제공할 수 있는 소스가 될 뿐 아니라 하나의 업무가 아닌 여러 업무에 걸친 현재 시점의 데이터를 통한 리포트 제공에도 활용됩니다. 이 영역은 때로는 고객이나 상품과 같은 핵심 주제 영역의 데이터 추출 용도의 마스터 데이터 관리 허브로 사용되기도 합니다.

이렇게 용어에 대해서 알아보았습니다. OLTP에서ODS, DW, DM, OLAP까지 한번에 오류 없이 데이터를 전송하기란 쉬운 일은 아닙니다. OLTP를 위한 시스템의 개발과는 달리 BI의 구축은 특히Data 에 관한 구체적인 지식이 요구되므로 데이터를 찾고, 품질을 높이고 데이터를 정련하는데 많은 시간이 소요됩니다. OLTP운영에서는 이상이 없지만, BI구축의 데이터 정합성 문제는 가장 큰 이슈입니다. 또 BI 개발이 끝났다 하더라도 OLTP에서 DB정보를 변경하는 일(컬럼 추가/삭제, 테이블 추가/삭제)은 비일비재합니다. 가장 안 좋은 케이스는 OLTP에서 제대로 된 ER-Diagram조차 없었을 때 입니다. 시스템의 분석을 위해 필요한 산출물이 없는 경우Reverse Engineering을 하기도 합니다. OLAP구축 전 단계인 DM까지 데이터를 이관하고 정합성을 체크하는데, 전체 개발기간의60% 이상이 할애되기도 합니다.

이번 시간에서는DW, DM, OLAP등 BI를 구축하기 위해서 필요한 용어 대해서 알아 보았습니다. BI를 구축하기 위해서는 많은 부서와의 협력이 필요 합니다. 특히 초기 구축에서는 정보부서의 도움이 필요하기 때문에, 기본적인 의사소통을 위해서는 정보부서를 포함하여, BI 구축과 연관된 부서에 이러한 용어 또는 개념에 대한 정보를 전달하는 것이 좋습니다.

출처 - http://www.sqler.com/498994