Oracle Database 12c ①

 

 

 

 

 

 

 

 

 

오라클 데이터베이스 서버 개요

• Oracle 은 실제로 데이터를 저장하는 공간, 저장된 데이터를 관리, 변경, 입력하면서 사용자의 요구를 처리하는 프로세스, 그 프로세스가 사용하는 메모리 영역으로 구성됨
  Oracle 서버는 정보를 개방적이고 포괄적이며 통합된 방식으로 관리할 수 있는 객체 관계형 데이터베이스 관리 시스템으로 Oracle 데이터베이스와 Oracle 서버 인스턴스로 구성됨

 

• Oracle 데이터베이스는 물리적 구조와 논리적 구조로 생성됨
  물리적 서버 구조와 논리적 서버 구조가 분리되어 있으므로 논리적 저장 영역 구조의 액세스에 영향을 주지 않고 데이터의 물리적 저장 영영 구조를 관리할 수 있음

 

• 데이터베이스가 시작될 때마다 시스템 글로벌 영역이 할당되고 Oracle 백그라운드 프로세스가 시작됨
  시스템 글로벌 영역은 데이터베이스 사용자가 공유하는 데이터베이스 정보에 사용되는 메모리 영역임
  백그라운드 프로세스와 메모리 버퍼의 조합을 Oracle 인스턴스라고 함

 

 

 

 

 

 

 

 

 

 

 

물리적 데이터베이스 구조

• 데이터파일
  • 모든 Oracle 데이터베이스는 하나 이상의 물리적 데이터 파일을 가짐
    데이터베이스의 데이터 파일은 데이터베이스의 모든 데이터를 가짐
    테이블이나 인덱스 같은 데이터베이스의 논리적 구조는 데이터베이스를 위해 할당된 데이터 파일에 물리적으로 저장됨
  • 변경되거나 새로운 데이터는 데이터 파일에 즉시 쓸 필요는 없음
    디스크 출력을 줄이고 데이터 베이스 성능 향상을 위해 변경된 내용만 파일에 쓰여지면, 데이터 블록의 데이터는 메모리 내에 남겨 두었다가, 적절한 시간에 데이터 파일에 쓰기는 RDMBS 백그라운드 프로세스인 DBWR 가 물리적인 I/O 를 일으킴
  • 데이터 파일의 특성은 다음과 같음
    1. 데이터 파일은 하나의 데이터베이스에만 관련됨
    2. 데이터 파일은 데이터베이스의 영역이 모자랄 때 자동으로 확장할 수 있는 특성이 있음
    3. 하나 이상의 데이터 파일이 데이터베이스 저장 영역의 논리적 단위인 테이블 스페이스를 형성
  • 데이터 파일의 데이터는 데이터베이스가 정상적으로 작동하는 동안 언제든지 읽을 수 있으며 Oracle 메모리 캐시에 저장됨
    예를 들어, 사용자가 데이터베이스의 테이블에 있는 일부 데이터를 액세스하고자 할 때 요구한 정보가 메모리 캐시에 없다면 해당 데이터 파일에서 읽어 메모리에 저장할 수 있음
  • 수정된 데이터나 새로운 데이터를 데이터 파일에 즉시 쓸 필요는 없음
    디스크 액세스량을 줄이고 성능을 향상시키려면 데이터를 메모리에 저장했다가 적합한 데이터 파일에 한꺼번에 써야 하는데 이는 Oracle DBWn 백그라운드 프로세스가 결정함

 

 

 

 

• 컨트롤 파일
  • 모든 Oracle 데이터베이스는 제어 파일을 가짐
    제어 파일에는 데이터베이스의 물리적 구조를 지정하는 입력 항목이 있음
    예를 들어, 다음과 같은 정보가 있음
    
    1. 데이터베이스 이름
    2. 데이터베이스의 데이터 파일과 리두 로그 파일의 이름 및 위치
    3. 데이터베이스 생성 시간 기록
  • 데이터베이스가 오픈될 때마다, 제어 파일은 데이터 파일 처리를 위해 반드시 오픈 되어야 하며 데이터베이스 파일과 리두 로그 파일을 지정하기 위해 사용됨
    만일 물리적인 데이터베이스 구성이 변경된다면, 제어 파일은 자동으로 Oracle RDBMS 에 의해 변경된 내용이 수정됨
    또한, 데이터베이스 복구가 필요 할 때도 제어 파일이 사용됨
  • 제어 파일을 장애로부터 보호하기 위해 Oracle RDBMS 는 복수개의 제어 파일 사용을 미러링 방식으로 허용
    즉 두  개 이상의 제어 파일 복사본을 서로 다른 디스크에 둘 수 있음

 

 

 

 

• 리두로그 파일
  • 모든 Oracle 데이터베이스는 하나 이상의 리두 로그 파일 세트를 갖고 있음
    리두 로그의 가장 중요한 기능은 모든 데이터베이스 변경 정보를 기록하는 일
    모든 데이터베이스의 변경 사항은 리두 로그에 저장됨
    만약 수정된 내용을 데이터 파일에 반영하는데 실패하더라도, 변경사항은 리두로그 파일에서 얻을 수 있기 때문에, 작업 내용은 결코 유실되지 않음
  • 리두 로그 파일은 데이터베이스를 장애로부터 보호하기 위해 필수적임
    리두 로그 파일이 포함된 장애로부터 보호하기 위해, Oracle RDBMS 는 복수 개의 리두로그 파일 사용을 미러링 방식으로 허용함
    즉 두 개 이상의 리두 로그 파일을 서로 다른 디스크에 둘 수 있음
  • 리두 로그 파일 안의 정보는 시스템이나 미디어 장애 시 복구를 위해서만 사용됨
    예를 들어, 만일 이상 전압으로 인해 데이터베이스가 다운이 되었다면 메모리에 있던 데이터베이스는 데이터 파일에 미처 써지지 않았을 수도 있음
    잃어버린 데이터는 전원이 정상대로 공급되어 데이터베이스가 재기동 될 때 복구됨
    Oralce RDBMS 는 전원이 끊어질 때 최종의 리두 로그 파일로 데이터베이스의 데이터 파일을 자동적으로 복구함

 

 

 

 

 

• 아카이브 로그 파일
  
  • 리두 로그 파일을 자동적으로 archiving 할 수 있는 기능이 제공됨
    오라클은 데이터베이스가 ARCHIVELOG 모드일 때 로그 파일을 자동적으로 archiving 함
    물리 복구가 필요한 경우 사용됨

 

 

 

• 파라미터 파일
  • 데이터베이스와 인스턴스에 대한 파라미터들을 기록 / 관리하는 파일
  • 오라클은 초기화 파라미터들을 동적으로 변경 / 적용 할 수 있는 서버 파라미터를 사용할 것을 권장함

 

 

 

• 경고 및 추적로그 파일
  • 서버와 백그라운드 프로세스들은 관련 추적파일을 분류하여 생성
    내부 에러가 발생했을 때, 관련정보를 추적파일에 기록
  • 추적파일의 정보는 DBA 들에게 유용하나, 대부분 오라클 기술지원을 담당하는 부서에게 필요한 정보
  • Application 이나 오라클 인스턴스를 tuning 하기 위해 사용되기도 함

 

 

 

• 백업 파일
  • 데이터 파일을 restore 한다는 것은 백업 파일로 대체한다는 것
    일반적으로 미디어 장애나 사용자의 실수가 원본 데이터 파일을 손상 시켰을 때 restore 작업을 수행함

 

 

 

 

 

 

 

 

논리적 데이터베이스 구조

• 테이블 스페이스
  • 데이터베이스는 논리적 저장 영역 단위인 테이블 스페이스로 나누어짐
    테이블 스페이스는 연관된 논리적 구조를 그룹화 함
    예를 들어, 테이블 스페이스는 특정 관리 작업을 간단히 하기 위해 보통 응용 프로그램의 모든 객체를 그룹화 함
  • 데이터베이스는 논리적으로 하나 또는 하나 이상의 테이블 스페이스로 나눠짐
    하나 이상의 데이터 파일은 개별 테이블 스페이스를 구성하며 테이블 스페이스 내에 존재하는 모든 논리적 객체정보를 저장하게 됨
    테이블 스페이스를 구성하는 데이터 파일의 총 크기는 테이블 스페이스가 가질 수 있는 최대 크기가 됨
  • 모든 오라클 데이터 베이스는 SYSTEM 과 SYSAUX 테이블 스페이스를 포함해야 함
    이들은 데이터베이스가 만들어질 때 자동적으로 생성됨
  • 사용자는 여러 개의 테이블 스페이스를 자신의 Temporary 테이블 스페이스로 사용할 수 있는 temporary tablespace group 기능을 사용할 수도 있음

 

 

 

• 데이터 블록
  • 데이터베이스 데이터가 저장되는 최소 단위는 데이터 블록임
    하나의 데이터 블록은 실제 디스크의 다중 영역으로 구성됨
  • 사용자는 데이터베이스 내에 최대 5개의 다른 블록 크기를 지정할 수 있음

 

 

 

• 확장영역
  • 데이터블록 상위의 관리범주는 확장영역임
  • 즉, 하나 이상의 연속된 데이터블록이 하나의 EXTENT 를 구성하게 됨

 

 

 

• 세그먼트
  • 확장영역 상위의 논리적인 데이터베이스 저장 수준을 세그먼트라고 하며, 하나의 세그먼트는 특정 논리적 구조에 할당된 확장 영역들로 구성되며, 다음과 같은 여러 형태의 세그먼트들이 있음
    1. 데이터 세그먼트
    2. 인덱스 세그먼트
    3. 임시 세그먼트
    4. 롤백 세그먼트
  • 오라클은 세그먼트의 기존 확장 영역이 꽉 차면 동적으로 영역을 할당함
    따라서 세그먼트의 기존 확장 영역이 차면 해당 세그먼트에 필요한 만큼 확장 영역을 할당함
    필요한 만큼 확장 영역을 할당해야 하므로 새로 할당되는 세그먼트의 확장 영역은 디스크에서 연속적인 부분이 아닐 수도 있음

 

 

 

 

 

 

 

 

 

 

스키마와 스키마 오브젝트

• 스키마는 데이터베이스 객체의 집합체임
  하나의 스키마는 하나의 데이터베이스 사용자에 의해 관리되며 사용자 이름과 동일함
  스키마 객체는 데이터베이스 데이터를 직접적으로 참조하는 논리적인 구조임

 

• 스키마와 테이블 스페이스 사이의 상관관계는 존재하지 않음
  동일 스키마에 있는 객체는 다른 테이블 스페이스에 저장될 수 있고 하나의 테이블 스페이스는 다른 스키마들의 객체를 저장할 수 있음

 

• 테이블
  • 데이터 스토리지의 기본 단위로 행과 열로 저장됨
  • 실제 디스크 공간을 사용하지 않지만 사용자가 지정한 표현식이나 함수에 의해 계산될 수 있는 가상 컬럼을 지정할 수 있음
  • 테이블에 대한 압축 기능을 사용할 수 있음
  • 파티셔닝 옵션을 통해, 다양한 파티셔닝 기법을 사용할 수 있음
  • 테이블의 열로 또 다른 테이블을 정의할 수 있는 Nested Table 기능 지원
  • 특정 트랜잭션이나 세션에 한해 임시 테이블을 사용ㅎㄹ 수 있음
    해당 트랜잭션이나 세션이 종료되면 해당 데이터는 자동으로 사라짐

 

• 뷰
  • 뷰는 하나 혹은 그 이상의 테이블이나 다른 뷰에 저장된 데이터에 대한 맞춤형 표현 방법
  • 뷰는 테이블처럼 사용할 수 있지만, 테이블과는 달리 별도의 저장 공간이 필요치 않음
  • 조인 뷰를 사용할 수 있으며, DML 문장을 사용할 수 있는 경우를 Updatable Join View 라고 함

 

• 클러스터
  • 주로 함께 사용되는 공용 컬럼 값들을 기준으로 동일한 데이터 블록에 테이블 데이터들이 저장되도록 하는데 사용됨
  • Index cluster 형태를 쓸 수도 있고, cluster key 값에 대한 hash function 의 결과 값에 따라 저장하는 형태를 사용할 수도 있음

 

• Materialized View
  • 데이터에 대한 요약, 계산, 복제, 분산 등에 사용되는 스키마 오브젝트
  • 별도의 저장 공간 사용, 마스터 테이블이 변경되면 반영되는 점, SQL 실행 속도의 향상, Query Rewrite 에 의한 SQL의 투명성 등의 의미에서 인덱스와 유사한 개념

 

• Materialized View Log
  • Materialized View 가 정의된 마스터 테이블의 데이터가 변경된 경우, 이를 점진적으로 빠르게 반영할 수 있도록 마스터 테이블의 변경 내역을 저장하는 오브젝트

 

 

• 차원
  • DW 환경에서 많이 사용되는 일/월/년 등과 같이, 컬럼들 혹은 컬럼 집합들 간의 계층적 관계를 정의하는 오브젝트
  • 별도의 저장 공간이 필요하지 않음

 

 

• 시퀀스
  • 유일한 일련 번호를 쉽고 빠르게 얻을 수 있는 오브젝트
  • 오름차순/내림차순으로 사용할 수 있고, 번호들 간의 인터벌을 둘 수 있고, 메모리에 캐쉬 시킬 수도 있음

 

 

• 인덱스
  • 여러 컬럼을 조합해서 인덱스를 생성할 수 있음
  • 인덱스를 invisible 상태로 변경할 수 있음

 

 

 

 

 

 

 

 

 

 

데이터 딕셔너리

• 개별 데이터베이스는 하나의 데이터 딕셔너리를 갖고 있음
  • 데이터베이스 내의 가용한 사용자 정보
  • 테이블에 지정되어 있는 제약조건 정보
  • 스키마 객체를 위해 할당된 디스크 공간 및 활용도
• 데이터 딕셔너리는 데이터베이스가 만들어질 때 생성됨
  항상 데이터베이스에 대한 상태정보를 유지해야 하기 때문에 데이터 베이스 구조가 변경되는 작업처럼, 특정 작업에 대한 결과를 자동적으로 갱신하게 됨
• 데이터베이스는 수행하고자 하는 작업내용을 기록하고 검증하고 처리하기 위해 데이터 딕셔너리를 참조하게 됨