2015년 사물인터넷 동향 및 시장전망에 대해 세미나 했던 자료입니다.

사물인터넷_기술동향_및_시장_전망.pdf
4.80MB

 

 

Oracle VM for SPARC 이라 불리는 오라클 유닉스 장비의 가상화 기술 자료입니다.

 

과거에 작성하여 세미나한 문서인데  현재 기능만 더 추가 되었을뿐 유닉스 OVM 가상화에 대한 기본 개념은 현재와 동일합니다.

 

아래 내용은 문서 중 일부 내용 발췌한 내용입니다.

 

I/O구성방안
I/O 이중화 방안
네트워크 이중화 방안

 

OVM_유닉스가상화_세미나자료.pdf
1.51MB

 

앞선 연재에서 소개한 것처럼 오라클 리얼 애플리케이션 클러스터의 핵심 기능은 캐시 퓨전이다. 이 캐시 퓨전은 각 노드 간의 버퍼 캐시의 내용을 교환해, 필요 없는 디스크 액세스를 줄이고 각각의 노드를 동기화해 사용자가 어떤 데이터베이스 서버에 접속해도 똑같은 하나의 서버에 접속하는 것 같은 느낌을 준다.
그럼 오라클 데이터베이스의 생김새를 알아보겠습니다. 오라클 데이터베이스가 어떤 구조를 하고 있는지를 잘 이해하는 것은 정말 중요한 일입니다. 왜냐구요 ?? 예를 들어, 자동차의 구조를 잘 이해하면 고장이 났을 때 쉽게 고칠 수 있습니다. 데이터베이스도 마찬가지입니다. 구조를 잘 이해하면 데이터베이스에 문제가 발생했을 때 쉽게 고칠 수 있기 때문입니다.
아래는 오라클 데이터베이스의 구조에 대한 설명입니다.

먼저, 오라클 데이터베이스는 세 가지 영역의 물리적 구성요소로 이루어져 있습니다.
첫 번째는 프로세스 영역입니다
  이 영역은 백그라운드 프로세스(DBWR, LGWR, PMON, SMON, CKPT)와 사용자 프로세스 그리고 서버 프로세스로 구성되어 있습니다
두 번째는 메모리 영역입니다.
  공유풀 영역(SHARED POOL), 데이터 버퍼캐쉬(DATA BUFFER CACHE) 영역, 로그 버퍼(LOGO BUFFER) 영역 그리고 라지풀(LARGE POOL) 영역으로 구성되어 있습니다.
마지막은 파일 영역입니다.
 
컨트롤 파일(CONTROL FILES), 파라메터 파일(PARAMETER FILES), 데이터 파일(DATA FILES) 그리고 리두로그 파일(REDO-LOG FILES)로 구성되어 있습니다.
 
시스템글로벌 영역
사용자가 실행한 SQL문에 의해 검색 또는 변경되는 테이블 데이터를 임시로 저장하는 메모 리 영역 시스템글로벌 영역(SYSTEM GLOBAL AREA)이라고 합니다.
SGA 영역은 오라클 데이터베이스에서 가장 중요한 영역이며 데이터베이스의 크기를 결정하는 척도이고 전체 실행속도를 향상시키기 위한 튜닝의 대상이 되기도 합니다. 그리고, 데이터베이스에 접속하는 모든 사용자들이 공유하는 영역이며 기본적으로 오라클 데이터베이스 서버는 하나의 SGA 영역으로 구성되어 있습니다.
공유 풀 영역(Shared Pool Area)
  SQL*PLUS, 애플리케이션 프로그램 등에서 데이터베이스에 접속하면 하나의 사용자 프로세스와 하나의 서버 프로세스가 할당되고 사용자는 SQL문을 실행하게 됩니다. 그리고, 서버 프로세스는 SQL문의 문법(Syntax)을 확인하고 사용된 테이블이 데이터베이스 내에 존재하는지를 확인한 다음 SQL문의 실행 가능한 실행코드와 실행에 필요한 실행 계획(Explain Plan)을 수립하고 그 내용을 저장하는 곳이 공유 풀(Shared Pool) 영역입니다. 공유 풀 영역은 2가지 영역으로 구성되어 있는데 라이브러리 캐쉬(Library Cache) 영역에는 실행코드와 실행계획이 저장되고 자료사전 캐쉬(Data Dictionary Cache) 영역에는 사용자가 읽게 되는 자료사전 테이블과 뷰 정보가 저장됩니다.
데이터 버퍼캐쉬 영역(Data Buffer Cache Area)
  서버 프로세스는 사용자가 실행한 SQL문에 정의된 테이블이 존재하는 데이터 파일로부터 테이블을 읽어서 데이터베이스 버퍼 캐쉬(Buffer Cache) 영역에 저장합니다. 예를 들어, 윈도우 운영체제의 탐색기 화면에서 어떤 파일을 참조하기 위해 더블-클릭을 하면 파일의 데이터는 메모리의 버퍼영역에 로드되고 다시 편집 프로그램에 의해 화면에 출력됩니다. 이때 사용되는 메모리 버퍼 영역과 원리가 유사합니다.
로그버퍼 영역(Log Buffer Area)
  사용자가 실행한 DML문을 커밋(Commit)하면 화면에 '커밋이 성공적이다'라는 메시지를 보여줍니다.(또는 롤백을 실행하면 '롤백되었읍니다') 이때 커밋했던 모든 작업내용을 메모리의 로그 버퍼(Log Buffer) 영역에 저장하게 됩니다. 모든 작업내역을 리두로그 버퍼에 저장하는 이유는 갑작스런 시스템의 다운 또는 데이터베이스의 다운 시 처리하고 있던 모든 작업내용을 복구하기 위해서 입니다.
예를 들어, 윈도우 운영체제 시스템을 사용하다 시스템의 전원이 갑자기 꺼졌을 때 수행중인 작업이 존재했다면 다시 전원을 켰면 "복구모드"로 전환되어 복구작업을 수행합니다. 이러한 복구작업을 수행하기 위해서 운영체제는 항상 디스크의 일부공간에 작업내역을 백업해두었다가 복구 시 사용하게 되는데 이러한 원리와 같은 개념입니다.
라지 풀 영역(Large Pool Area)
  오라클 8.x 버전부터 백업과 복구작업을 실행할 때 복구관리자(Recovery Manager)라는 툴을 사용할 수 있고 또한, 사용자가 데이터베이스에 접속하는 방법 중에 공유서버(Shared Server) 프로세스라는 환경이 있는데 이러한 환경을 구성할 때 라지 풀 영역을 사용합니다
 
  파일영역
데이터베이스의 마지막 구조인 파일영역에는 데이터베이스가 생성되면서 만들어졌던 자료사던 테이블과 뷰 그리고 사용자가 직접 생성한 테이블, 인덱스, 뷰, 시퀀스, 시노늄 등이 저장되어 있습니다. 또한, 데이터베이스의 모든 상태정보가 저장되어 있습니다. 파일영역을 "데이터베이스"라고 부르기도 합니다. 그럼, 보다 자세히 알아보도록 합시다.
컨트롤 파일(Control Files)
  데이터베이스를 시작(STARTUP)할 때 항상 참조되는 파일이 컨트롤 파일입니다. 왜냐하면, 컨트롤 파일은 데이터베이스에서 사용하게 될 모든 파일들의 절대경로와 파일크기 등의 정보를 저장하고 있기 때문에 파일들의 이상유무를 확인하기 위해서 참조하게 됩니다.(차후에 "백업과 복구"에서 자세히 소개됩니다.) 그리고 새로운 데이터 파일이 추가되면 해당 파일의 디렉토리 정보와 파일의 상태를 컨트롤 파일에 저장합니다.
오라클 데이터베이스가 시작되기 위해서는 최소한 하나의 컨트롤 파일이 존재해야 하는데 유니버셜 인스톨러에 의해 설치하면 3개의 컨트롤 파일이 기본적으로 생성됩니다. 이중에 하나는 원본이고 나머지는 복사 본 파일입니다. 컨트롤 파일은 오라클 데이터베이스가 존재하기 위해 꼭 필요한 파일이기 때문에 원본 컨트롤 파일에 문제가 발생하면(컨트롤 파일이 사용자에 의해 삭제되거나 컨트롤 파일이 존재하는 디스크가 깨지는 사태) 복사 본 컨트롤 파일로 대체해서 사용하기 위해서 입니다.
파라메터 파일(Parameter File)
  앞에서 배웠던 SGA 영역를 생각해 보십시오. SGA 영역은 시스템 메모리 영역으로부터 데이터베이스가 전용으로 사용하기 위해 할당받게 되는 영역입니다. 그렇다면, 시스템으로부터 얼마만큼의 메모리 크기를 할당받게 될까요 ? 그 의문의 해답을 가진 파일이 파라메터 파일입니다. 또한, 파라메터 파일은 컨트롤 파일의 경로, 데이터베이스의 환경설정 등 관련된 모든 정보를 포함하고 있습니다.
이 파일은 데이터베이스의 튜닝 시에도 사용되는 매우 중요한 파일 중의 하나입니다. 운용체제에 따라 약간의 차이는 있지만 기본적으로 데이터베이스를 설치하면 다음 그림과 같이 INIT<DB명>.ORA 또는 INIT.ORA 라는 파일 이름으로 존재합니다.
데이터 파일(Data Files)
  사용자들이 실행한 SQL문에 의해 변경되는 모든 데이터는 논리적으로는 테이블과 인덱스에 저장되지만 실제로는 운영체제 상에 존재하는 데이터 파일에 저장됩니다. 예를 들어, SQL*PLUS 툴에서 사용자가 생성한 테이블을 SQL*PLUS 내에서 SELECT, UPDATE, INSERT, DELETE 하면 데이터가 저장되고 변경됩니다. 하지만, SQL*PLUS 툴을 종료한 후 운영체제 상에서 사용자가 생성한 테이블을 조회하려면 어떻게 해야 할까요 ?? 운영체제 상에서는 확인 할 방법이 전혀 없습니다.
즉, SQL*PLUS 툴 내에서 만 테이블이라는 논리적인 구조를 눈으로 직접 확인할 수 있고 운영체제에서는 파일을 통해 사용자의 테이블이 존재한다는 것을 확인할 수밖에 없는 것입니다. 이러한 파일을 데이터 파일이라고 합니다.
리두로그 파일(Redo-Log Files)
  사용자가 실행한 SQL문을 커밋(Commit)하면 화면에 '커밋이 성공적이다'라는 메시지를 보여줍니다. 이때 커밋했던 모든 작업내용은 리두로그 파일에 백업됩니다. 이렇게 리두로그 파일에 저장하는 이유는 갑작스런 시스템의 다운 또는 데이터베이스의 다운 시 처리하고 있던 모든 작업에 대해 복구작업을 수행하기 위해서 입니다.
 
  백그라운드 프로세스
오라클 데이터베이스의 현재 상태를 모니터링하거나, 사용자가 실행한 SQL문의 작업을 처리해주는 프로세스를 백그라운드 프로세스라고 합니다. 백그라운드 프로세스에는 데이터베이스가 시작될 때 꼭 필요한 DBWR(Database Writer), LGWR(Log Writer), SMON(System Monitor), PMON(Process Monitor), CKPT(CheckPoint)가 있습니다. 만약, 5개의 백그라운드 프로세스 중 하나라도 존재하지 않는다면 데이터베이스는 더 이상 사용할 수 없습니다. 그리고, 이 5개의 프로세스를 필수 백그라운드 프로세스라고 합니다.
DBWR 프로세스
  데이터베이스 기록기(DBWR)는 사용자가 실행한 SQL문에 의해 데이터의 변경내역(입력, 수정, 삭제)을 테이블에 저장하는 작업을 수행합니다. 예를 들어, 사용자가 UPDATE문을 실행하고 커밋(Commit)문을 실행할 때 테이블에 데이터를 저장하는 작업을 데이터베이스 기록기 프로세스가 처리합니다. 데이터베이스 기록기(DBWR)와 로그 기록기(LGWR)는 데이터베이스를 시작하면 자동으로 생성되고 종료하면 없어지는 백그라운드 프로세스입니다.
LGWR 프로세스
  사용자가 실행한 SQL문을 커밋(Commit)하면 화면에 '커밋이 성공적이다'라는 메시지를 보여줍니다. 이때 커밋했던 모든 작업내용을 리두로그 파일에 백업 하게되는데 이러한 작업을 로그 기록기(LGWR)가 처리해 줍니다. 모든 작업내역을 리두로그 파일에 저장하는 이유는 갑작스런 시스템의 다운 또는 데이터베이스의 다운 시 처리하고 있던 모든 작업내용을 다시 복구하기 위해서 입니다.
PMON 프로세스
  사용자들이 데이터베이스에 접속하면 한번의 접속 요구마다 사용자 프로세스가 하나씩 생성됩니다. 프로세스 모니터(PMON)는 이러한 사용자 프로세스들의 상태를 감시합니다. 만약 어떤 사용자 프로세스에 오류가 발생하거나(예를 들어, SQL*PLUS에서 SQL문을 실행하는 중에 윈도우를 닫게 된다면) 또는 사용자 프로세스가 비정상적으로 종료된 경우 모든 작업을 자동적으로 롤백(Rollback) 시켜줍니다.
SMON 프로세스
  시스템 모니터(SMON)는 백그라운드 프로세스와 데이터베이스 메모리 영역의 상태를 감시하며 데이터베이스가 다운된 후 다시 시작될 때 자동적인 복구작업을 수행해 줍니다.
CKPT 프로세스
  체크포인트(CKPT)는 LGWR 프로세스에 의해 활동하며 사용자가 COMMIT문을 실행할 때마다 오라클 서버가 관리하는 시스템 변경번호(SYSTEM CHANGE NUMBER) 및 데이터베이스의 상태정보를 컨트롤 파일과 데이터 파일에 저장하는 작업을 하게됩니다. 또한, CKPT 프로세스가 발생하면 연속적으로 DBWR 프로세스가 작업을 수행하게 됩니다.
기타 백그라운드 프로세스
  5개의 필수 백그라운드 프로세스뿐만 아니라 경우에 따라서 사용할 수 있는 ARCH(Arch Iver), RECO(Recoverer), LCKn(Lock) 등의 기타 백그라운드 프로세스도 있습니다. ARCH 프로세스는 데이터베이스를 복구모드로 운영할 때 사용하며 RECO 프로세스는 분산 DB환경에서 서로 공유되는 객체 간의 동기화를 설정할 때 사용됩니다. 또한, LCKn프로세스는 병렬서버환경(Oralce Parallel Server)에서 테이블의 잠금과 관련된 백그라운드 프로세스입니다.

+ Recent posts

티스토리툴바