전문가칼럼

DBMS, DB 구축 절차, 빅데이터 기술 칼럼, 사례연구 및 세미나 자료를 소개합니다.

오라클 운반 최소 단위 BLOCK

전문가칼럼
DBMS별 분류
Oracle
작성자
dataonair
작성일
2016-06-13 00:00
조회
10994




◎ 연재기사 ◎


물탱크 구조로 알아본 오라클의 블록 옵션 ‘PCTFREE와 PCTUSED’


이산가족 찾기 생방송을 통해 배우는 DB 원리


개발자에게 맞는 DB 공부방법 찾기: 물리적 분류와 논리적 분류 그리고 인덱스


데이터베이스 인덱스의 오해와 진실


쉬운 것이 올바른 것이다. ‘인덱스 끝장리뷰’ (상)


쉬운 것이 올바른 것이다. ‘인덱스 끝장리뷰’ (하)


누구도 알려주지 않았던 ‘오라클 인덱스 생성도’의 비밀


누구도 알려주지 않았던 ‘오라클 쿼리 작성의 비법’


퀴리 최적화 및 튜닝을 위한 오라클 공정쿼리 작성법


만능 쿼리와 한 방 쿼리


오라클 옵티마이저 ‘CBO와 RBO’ 이해하기


재미있는 DB 이야기 ‘60갑자와 쿼리’


그림으로 배우는 ‘오라클 조인의 방식’ 이야기


반드시 알아야 하는 오라클 힌트절 7가지


오라클 플랜을 보는 법


개발자들의 영원한 숙제 ‘NULL 이야기’


알면 유용한 오라클 기능 ‘GATHER_PLAN_STATISTICS’


알면 유용한 오라클 기능들


오라클 DICTIONARY를 활용한 DB툴 프로그램 ‘FreeSQL’


이제는 말할 수 있다: 주식 자동매매 프로그램(상)


이제는 말할 수 있다: 주식 자동매매 프로그램(하)


개발자들이 자주 접하는 오라클 에러 메세지


재미있는 DB 이야기 ‘사라진 날짜를 찾아라’


오라클 랜덤 함수와 사용자 정의 함수


그림으로 배우는 ‘공정쿼리와 인덱스 생성도’


이병국의 개발자를 위한 DB 이야기: 디폴트 세팅의 함정과 오라클 파라미터


재미있는 DB 이야기 ‘놀라운 마방진의 세계’


오라클 운반 최소 단위 BLOCK


이병국의 개발자를 위한 DB 이야기: 이세돌과 알파고의 세기의 대결


이병국의 개발자를 위한 DB 이야기(30회) : DB 엔지니어의 가볍게 읽는 세상 이야기


이병국의 개발자를 위한 DB 이야기: 튜닝(31회) : 개발자를 위한 DB 튜닝 실전(1편)


이병국의 개발자를 위한 DB 이야기: 튜닝(32회) : 개발자를 위한 튜닝 실전(2편)


이병국의 개발자를 위한 DB 이야기: 튜닝(33회) : 개발자를 위한 튜닝 실전(3편)


이병국의 개발자를 위한 DB 이야기: 튜닝(34회) : 개발자를 위한 DB 튜닝 실전(4편)


이병국의 개발자를 위한 DB 이야기: 튜닝(35회) : 개발자를 위한 튜닝 실전(5편)


이병국의 개발자를 위한 DB 이야기: 페이징 처리에 대한 이해 (36회)


보기 좋은 떡이 먹기도 좋다 - 좋은 쿼리 좋은 성능


테이블의 수직분할과 수평분할에 대한 이해


DB 성능 제고를 위한 채번의 이해와 방식별 장단점 비교


이병국의 개발자를 위한 DB 이야기: 마지막회 : ‘개발자를 위한 DB 이야기’ 연재를 마치며



이병국의 개발자를 위한 DB 이야기: 블록(28회)



오라클 운반 최소 단위 BLOCK



성공과 실패의 경험을 나누자, 용기와 희망을 나누자

개발업무를 시작으로 IT계에 입문했던 필자가 10년 가까이 DB엔지니어로서 활동하면서 얻은 경험과 지식을 나누고자 한다. DB를 자주 접하는 SW 개발자뿐 아니라, DB 전문가를 꿈꾸는 대학생에서DB 분야에 입문한지 1~2년 된 기입문자가 쉽게 이해할 수 있도록 비유를 통해 쉽게 접근해볼 계획이다. 물론 전문가들이라도 다시 한번 개념을 정립하는 의미에서 필요한 내용이 될 수 있다.

전체적으로 DB의 기본 원리와 개념을 이해하고 테이블, 인덱스, 쿼리, 튜닝, 플랜 등 개발자들이 알아야 하는 DB 전분야에 대해 쉽게 이해하도록 설명하겠다. DB 기술서적이나 번역서보다는 조금 더 부드럽게 접근할 계획이다. 그렇다고 흔히 서점에서 만날 수 있는 개발자 위주의 SQL 소개서도 아니다. 이 연재는 시리즈로 나갈 것이다. 연재를 끝까지 읽는 독자라면 준전문가 수준의 DB 원리를 아는 것을 목표로 한다.



대상을 세는 단위에 대한 고찰

우리 민족은 예로부터 물건이나 대상을 세는 다양한 단위를 사용했다. 대개의 나라들은 면적, 크기, 부피, 길이 등에 따른 몇 가지의 단위가 전부인데 반해 우리 나라는 면적, 크기, 부피, 길이뿐 아니라 단위를 세는 구체적인 대상에 따라서도 세분화해 사용하였다.



접: 마늘이나 감 등을 세는 단위(100개)
톳: 김 40장 또는 100장의 한 묶음
축: 오징어 20마리
쾌: 북어 20마리
톨: 밤, 도토리를 세는 단위
태: 나무 꼬챙이에 꿰어 말린 명태 20마리
치: 손가락 한마디의 크기를 의미한다. 한치 앞도 못 본다는 말이 있는데 바로 눈 앞의 것도 못 본다는 의미다.
그런데 실제로 눈에서 한치 앞의 사물을 보면 초점이 안 맞아서 어지럽고 눈물이 난다. 실제 틀린 말은 아닌 것이다.
자: 한자로는 척이라 하고 팔뚝에서 손까지의 길이를 의미한다(약 30cm).
통: 광목 60자
필: 명주 40자(명주 한 필)
필: 말이나 소를 세는 단위를 의미한다. 대개 동물은 마리라는 단위가 있지만 말이나 소를 헤아리는 단위는
마리뿐만 하니라 필이라는 단위도 같이 사용한다. 아마 옛날 농경 및 국방에 대한 중요성 때문에
특별히 붙여진 단위가 아닐까 생각해 볼 수 있다.
모: 두부나 묵의 수를 세는 단위
길: 사람의 키를 의미한다(천길 낭떠러지, 열길 물속은 알아도 한길 사람 속은 모른다).
닢: 잎, 쇠붙이, 동전, 등 얇은 물건을 세는 단위
단: 푸성귀, 짚, 땔나무 따위의 묶음을 세는 단위
손: 고등어, 배추, 미나리, 파를 세는 단위(고등어 2마리, 배추 2통, 미나리 한줌, 파 한줌)
매: 젓가락 한 쌍을 의미하기도 하고, 종이 따위를 세는 것
장: 종이처럼 얇은 것을 세는 단위
연: 종이 전지 500장
쌈: 바늘 24개
벌: 옷이나 그릇의 짝을 이룬 단위, 세트의 개념
홰: 닭이 홰를 치며 우는 횟수를 세는 단위를 의미하는데, 이런 단위도 있구나 싶어서 놀람
땀: 바느질에서 한번 바늘로 뜬 것(한 땀 한 땀 정성들인 옷)
촉: 난초의 포기 수를 세는 단위
첩: 한방약 한 봉지
제: 한방약 20첩
홉: 양손으로 움켜진 양, 1되의 1/10, 작은 소주가 2홉이므로 소주 반 병 정도의 부피
되: 10홉을 의미하며 주로 쌀 등을 세는 단위
되가웃: 한 되 반 정도의 쌀
되드리: 한 홉의 1/10
말: 10되를 의미하며 두와 같은 단위
가마니: 5말
섬: 10말, 2가마니, 만석꾼에서 석과 같은 단위
담불: 벼 100섬을 의미
거리: 오이나 가지 50개(반 접과 같은 단위)
우리: 기와를 세는 단위(기와 2000장)
사리: 국수나 실 등의 둥그런 뭉치를 세는 단위
바리: 마소가 실어 나르는 짐을 세는 단위(‘바리바리 짐을 싣고’라는 말도 있음)
리: 0.4Km 의미, 십 리는 4Km
마장: 십 리나 오 리가 못 되는 거리
평: 가로, 세로 방향으로 한 사람의 키 정도 되는 넓이(3.3평방미터)
묘: 30평
단보: 10묘, 300평
정보: 10단보, 100묘, 3000평
마지기: 논은 200~300평, 밭은 300평 내외로 지역마다 의견이 분분한데 그 이유는 면적에
대한 단위가 아니기 때문이다. 정확한 표현은 한 말의 씨를 뿌릴 만한 땅을 의미한다.
가리: 계곡 안에 자리잡은 한나절 밭갈이를 할 수 있는 정도의 땅을 의미하며 아침가리,
연가리, 가리, 명지가리가 우리나라에서 유명한 4가리에 속한다.
특히 아침가리는 우리나라 최고의 계곡 트레킹 코스이다.
손에 꼽을 오지이지만 땅 값은 매물이 없어서 매길 수가 없다고 한다.



이 외에도 무수히 많은 세는 단위가 있지만 요즘은 사람들이 잘 사용하지 않고 잊어 버리는 것이 많아져 아쉽다. 이번 연재의 내용은 오라클 I/O 최소 운반 단위인 블록에 관한 것이다. 조금은 딱딱한 주제이지만 튜닝에 있어서 중요한 부분이므로 정독을 필요로 한다.



오라클 블록에 대한 이해

오라클 블록은 사용자가 입력한 데이터를 HDD에 저장하거나 혹은 저장된 데이터를 작업하려고 메모리에 로드할 때 처리하는 최소 작업 단위이자 최소 운반 단위다. 오라클 블록은 데이터 블록 또는 페이지라고 불리기도 한다. 한마디로 블록이란 물리적 데이터가 저장되는 디스크 공간이라고 이해하면 된다.

오라클 9i 이전에는 데이터베이스를 생성할 때 블록의 크기를 결정할 수 있었으며, 한 번 정해진 블록의 크기는 변경이 불가해서 재 설정하려면 데이터베이스를 다시 설치해야 했다. 하지만 오라클 9i부터는 재설치 않고도 블록 사이즈를 변경할 수 있도록 지원한다(multiple oracle block size 지원).

블록 크기 설정은 초기 파라미터인 db_block_size에 의해 결정된다. OS 종류에 따라 2KB에서 32KB까지 제공되며 간혹 64KB를 제공하기도 한다. 블록의 크기는 홀수보다는 짝수 및 그 배수로 설정을 권장한다. 아래 [그림 1]은 오라클의 저장 구조를 순서대로 간략히 표현한 것이다.

column_img_2414.jpg

[그림 1] 오라클의 저장구조

위 [그림 1]에 따르면 오라클 저장 구조의 순서는 아래와 같다.

OS Block → Oracle Block → Extent → Segment → Tablespace → Database

오라클 블록은 하나 이상의 OS 블록의 집합으로 이루어졌다. 오라클 블록의 사이즈는 입출력을 원활히 하기 위해 OS 블록 사이즈의 배수로 선택해야 한다. 만약 오라클 블록이 OS 블록보다 작게 된다면 나머지의 데이터들은 항상 따로 읽히게 되어 읽기 수행 속도에 문제를 일으키고, OS 블록의 배수가 되지 않는다면 공간 낭비를 초래하게 된다.

오라클 데이터 블록은 실제 물리적 하드디스크 상의 저장 공간으로 데이터베이스가 생성될 때 오라클 파라미터 db_block_size에 의해 결정된다. 아래 쿼리로 설정된 블록의 크기를 확인할 수 있다.

SELECT VALUE FROM V$PARAMETER WHERE NAME = ‘db_block_size’

익스텐트(Extents)는 오라클 데이터 블록의 연속적인 집합으로 이루어지며, 데이터가 데이터 파일에 추가될 때마다 할당된다. 세그먼트(Segment)는 익스텐트 상위의 논리적인 데이터베이스 레벨을 세그먼트라고 한다. 세그먼트는 특정 논리적 구조를 위해 할당된 익스텐트의 집합이다. 세그먼트에는 4가지 타입이 있다.

데이터세그먼트, 인덱스세그먼트, 롤백세그먼트, 임시세그먼트

오라클은 존재하는 세그먼트의 익스텐트들이 Full 되었을 때 동적으로 공간을 할당한다. 그러므로 오라클은 필요로 하는 만큼 또 다른 세그먼트의 익스텐트를 할당한다.



오라클 블록의 크기와 OLTP & OLAP

오라클은 작업의 효율성과 속도의 향상을 위해 블록 단위로 작업을 수행한다. 데이터를 하나씩 처리하는 것이 아니라 블록 단위로 처리하기 때문에 효율성과 속도의 향상을 얻을 수 있다.

블록의 사이즈가 크면 한번에 담는 양이 많아서 I/O 횟수가 줄어드는 장점이 있다. 반면에 공간 낭비 및 경합이 발생할 수 있어 전체 성능 저하의 원인이 되기도 한다. 대체적으로 OLTP 시스템에서는 블록의 사이즈를 작게 하고, OLAP 시스템에서는 블록의 사이즈를 크게 하는 것이 좋다.

OLTP(Online Transaction Processing): 일반적인 업무 처리에 적합(현황 처리가 목적, Block Size↓)
OLAP(Online Analytical processing): 분석을 위한 통계에 적합(미래 예측이 목적, Block Size↑)

많은 DML을 유발시키는 OLTP에서는 작은 블록이 유리하다. 왜냐하면 블록 내에 적은 로우가 있어서 경합이 적게 발생하기 때문이다. 반면에 통계 또는 집계를 내기 위한 OLAP 환경의 데이터 베이스는 블록 사이즈를 크게 잡는 것이 유리하다. 이러한 여러 가지 상황을 고려하여 사이즈를 결정하는데 대개 8KB 정도로 잡는 것이 무난하다.

오라클 블록 사이즈와 연관된 중요한 또 하나의 파라미터가 있다. db_file_multiblock_read_count 파라미터가 그것이다. 데이터베이스 성능에 영향을 미치는 파라미터로서 한번의 I/O로 운반할 수 있는 블록의 개수를 정할 수 있다.

SELECT VALUE FROM V$PARAMETER WHERE NAME = ‘db_file_multiblock_read_count‘



오라클 블록과 Row Chaining & Row Migration

블록과 관련하여 Row Chaining과 Row Migration이 발생하는데 블록 단위의 작업을 하는 오라클에서 성능 저하를 일으키기도 한다.

Row chaining는 해당 블록에 저장 공간이 부족해서 다른 블록에 데이터를 이어서 저장한 상황에 대한 것이다. 관리상의 문제로 인하여 성능 저하가 발생한다. 블록의 크기를 증가 시키는 것이 해결책이 될 수 있으나 블록의 크기를 증가 시키면 Wait 현상이 발생하여 오히려 성능이 떨어 질 수도 있다.

Row migration은 해당 블록에 저장된 데이터가 공간이 부족해서 다른 블록으로 이동한 경우를 말하며, 원래 블랙에는 이동한 주소 정보를 남겨야 한다. 이것도 역시 관리상의 성능 이슈가 있다. 해결책은 reorg 하거나 pctfree 값을 증가시키면 되지만, pctfree 값을 증가시키면 공간 낭비 발생으로 오히려 성능이 떨어 질 수도 있다.



오라클 블록과 성능의 연관성

오라클 블록은 성능과 밀접한 관련이 있다. 예를 들어 [그림 2]와 같이 여러 개의 Row를 조회할 때, 서로 다른 블록에 존재한다면 우리는 그 Row를 조회하기 위해 각각의 블록을 읽어야 한다. 디스크 I/O 운반 횟수가 많으므로 성능상으로 손해를 보았다.

column_img_2415.jpg

[그림 2] 서로 다른 블록에 있는 조회 대상 Row

또 다른 예를 보자. [그림 3]과 같이 여러 개의 Row를 조회하는데 모두 같은 블록에 존재한다면 우리는 해당 Row를 조회하기 위해서 오직 하나의 블록만 읽으면 된다. 디스크 I/O 운반 횟수가 적으므로 성능상으로 이익을 보았다.

column_img_2416.jpg

[그림 3] 동일한 블록에 있는 조회 대상 Row

결론적으로 블록의 크기도 성능에 영향을 미치는 중요한 요소이지만, 블록에 적재된 데이터의 내용도 성능에 영향을 미치는 중요한 변수가 됨을 우리는 알 수 있다.

이번 연재에서는 오라클 블록에 관하여 설명하였다. 오라클 블록은 I/O의 가장 작은 단위이며 오라클 성능에도 중요한 요소임을 이해하였다. 다음 연재에서는 얼마 전에 세간에 화제를 몰고 온 이세돌과 바둑 대결에서 승리한 알파고 및 인공 지능에 관한 것이다. (다음 회에 계속)



[지난 문제의 정답과 풀이] 원리를 이해하고 논리로 풀어가는, 쉬어가는 DB 문제

지난 연재에 출제한 ‘원리를 이해하고 논리로 풀어가는, 쉬어가는 DB 문제’에 대한 정답과 해설은 아래와 같다. 문제를 풀면서 DB 원리를 하나씩 배우고 이해할 수 있다.

column_img_2417.jpg

column_img_2418.jpg



[이번 호 문제] 원리를 이해하고 논리로 풀어가는, 쉬어가는 DB 문제

각 연재의 말미에 간단하면서도 재미있고 생각해 보는 문제를 출제하려 한다. 모든 문제는 DB의 원리를 이해할 수 있는 문제로 출제할 예정이다. 문제를 풀면서 DB 원리를 하나씩 배우고 이해할 수 있다. 정답과 그에 대한 설명은 다음 연재에서 한다.

column_img_2419.jpg