전문가칼럼

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

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

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




◎ 연재기사 ◎


물탱크 구조로 알아본 오라클의 블록 옵션 ‘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 이야기: 파라미터(26회)

디폴트 세팅의 함정과 오라클 파라미터



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

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

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



디폴트 세팅의 영향

디폴트 세팅은 디폴트 옵션이라고도 하는데 사전적인 의미는 의사 결정 과정을 미리 정해 놓은 것을 의미한다. 우리가 가장 흔하게 디폴트 세팅을 경험하는 것은 바로 컴퓨터에 운영체제를 설치하는 과정이다. 여러분은 운영체제 설치 시 대부분 디폴트로 세팅할 것이다. 또한 모바일 기기를 구매할 때도 디폴트 세팅 그대로 사용하는 경우가 대부분이다.

디폴트 세팅은 운영체제 설치나 기기의 설정에 국한 하지는 않는다. 컴퓨터를 켜고 웹 브라우저를 실행했을 때, 처음 나타나는 사이트도 디폴트 세팅의 영향이다. 필자의 컴퓨터는 네이버가 뜬다. 우리나라에서 디폴트 세팅의 효과를 가장 많이 보는 회사가 네이버가 아닐까 생각한다.

column_img_2352.jpg
[그림 1] 유럽 국가별 장기 기증 동의율 현황
(출처: Johnson, E. J. & Goldstein, D. G. (2003). Do defaults save lives Science, 302, 1338-1339.)

[그림 1]은 유럽 국가들의 사후 장기 기증 동의율을 나타낸 것이다. 독일과 오스트리아는 지리적으로 인접한 국가이지만 사후에 장기 기증에 동의한 비율은 각각 12퍼센트와 99.98퍼센트로 차이가 크다. 이와 같은 차이는 그 나라 국민성과는 아무런 관련이 없다. 단지 동의서 양식의 디폴트 세팅에 따라 달라진다고 한다.

오스트리아-프랑스-스웨덴과 같이 사후 장기 기증 동의율이 높은 나라의 신청 양식에는 동의하는 것이 디폴트 세팅으로 되어 있지만, 덴마크-네덜란드-독일과 같이 사후 장기 기증 동의율이 낮은 나라의 신청 양식에는 동의하는 것이 디폴트 세팅으로 되어 있지 않다.

column_img_2353.jpg

이와 같이 디폴트 세팅의 방법에 따라서 동의 비율이 확연하게 차이가 난다. 그렇다면 우리나라의 사후 장기 기증 양식은 어떻게 되어 있을까 참고로 우리나라 장기 이식술은 세계적 수준이지만 2005년 우리나라의 뇌사 시 장기 기증률은 1.78퍼센트라고 한다.



디폴트 세팅의 함정

대부분의 사람들은 현재의 상태를 그대로 유지하려는 속성을 가지고 있다. 쉽게 말해 ‘귀차니즘’이 존재하는 것이다. ‘시청률이 높은 TV 프로그램 뒤에 편성한 프로그램 또한 시청률이 높다’는 말이 있다. 특별한 이유가 있지 않는 한 채널을 바꾸지 않으려는 사람들의 자연스런 성향 때문이라고 한다.

기업 마케팅에서 이러한 사람들의 성향을 적극 활용하고 있다. 고객 정보 활용 동의서의 경우에는 ‘동의함’에 디폴트 세팅되어 있고, 이메일 수신 거부 의사 표시에는 ‘거부함’이 디폴트 세팅으로 되어 있지 않는 것이 그러한 예이다. 결국 고객 정보 활용 동의서는 별다른 반대 의지가 있지 않는 한 자연스레 동의 하게끔 유도하고 있다. 이메일 수신 거부 의사 표시도 반대 의사를 적극적으로 나타내지 않으면 우리의 생각과는 다르게 수신 동의 하게끔 유도하고 있다.

column_img_2354.jpg

다양한 분야에서 사람들의 귀차니즘 행태를 이용하려는 기업의 노력들은 치열하다. 인터넷 브라우저 시장의 경쟁도 좋은 예이다. Chrome(구글), IE(마이크로소프트), Safari(애플), Opera(오페라), Firefox(모질라) 등이 디폴트 세팅을 차지하려고 치열하게 경쟁하고 있다. 우리나라는 IE의 점유율이 압도적으로 높다. 왜냐하면 마이크로소프트 운영체제에서 디폴트 세팅으로 제공하기 때문이다.

column_img_2355.jpg
[그림 2] 디폴트 세팅을 차지하려는 인터넷 브라우저 시장의 치열한 경쟁

일반적으로 가장 사용 빈도가 높거나 가장 효율적인 것을 디폴트 세팅으로 해야 하지만 현실은 그렇지 않다. 기업들은 디폴트 세팅을 자기들에게 유리하게 이용하려고 최대한 애쓴다. 이러한 디폴트 세팅의 사례는 기업에 국한된 것은 아니다. 4년마다 다가오는 국회의원 선거에서 3번보다는 2번이 유리하고 2번 보다는 1번이 유리하다는 것은 널리 알려진 사실이다. 이것도 디폴트 세팅이라 할 수 있다. 우리의 생활 구석 구석에 디폴트 세팅의 함정이 있다. 귀차니즘의 폐해가 있다.

- 페이스북: 너무 많은 개인 정보를 공유하게 만드는 SNS의 디폴트 세팅
- 스마트폰: 애플과 삼성의 충성 고객을 확보하기 위한 디폴트 세팅 전략
- 검색 사이트: 네이버, 다음, 라이코스, 야후, 드림위즈 간의 과거 치열했던 디폴트 세팅 경쟁
- 여론조사: 여론 조사 기관의 편익에 부합하는 설문지의 디폴트 세팅

이와 같이 디폴트 세팅은 단지 어떤 옵션의 설정에 대한 부분을 넘어서, 일상 생활에서 폭넓게 해석될 수 있다. 디폴트 세팅은 여러분의 입장이 아닌 기기의 제조사 및 판매자, 국가 정보기관, 프로그램 제작사의 이익을 추구하는 입장에 서 있는 경우가 휠씬 더 많다. 디폴트 세팅은 간편하지만 의도하지 않는 나쁜 결과를 초래할 수 있다. 지금도 많은 영역, 많은 부분에서 여러분의 디폴트 세팅을 훔치고 있다. 당신의 의지를 훔치고 있다. 여러분은 ‘어떻게 자기 자신의 의지를 지킬 것인가’를 놓고 고민해야 한다. 우리는 항상 본인의 정보나 권리가 침해 받지 않도록 행동해야 한다. 의지를 가져야 한다.



‘사용자 설정은 의지의 설정’

이번 연재의 내용은 오라클 파라미터에 관한 것이다. 오라클 설치시 디폴트로 세팅되겠지만 사용자의 의지에 따라서 재설정 되어야 하는 부분이 있을 것이다. 오라클의 선택이 아닌 사용자의 의지에 따라서 설정하여야 할 것이다. 귀차니즘이 지금 당장은 편의를 주지만 항상 편의를 보장하는 것은 아니며 최선의 선택이 아닐 수도 있다. 설정될 것인가, 설정할 것인가 이제는 결정해야 한다. 사용자 설정은 곧 의지의 설정이다.



오라클 파라미터의 이해

오라클 환경을 구성하는 속성을 오라클 파라미터라고 한다. 파라미터에 대한 설정 값을 저장한 파일을 오라클 파라미터 파일이라고 하는데, DB 구동 시에 파라미터 파일을 참조하여 SGA (System Global Area) 및 기타 필요한 환경을 구성한다. 서버의 성능이나 운영 업무의 특성에 따라서 파라미터의 설정 값을 변경 할 수 있다.

오라클 파라미터 파일은 정적 파라미터 파일과 동적 파라미터 파일 2가지가 있다. 가장 큰 차이점은 동적 파라미터는 DB의 재기동 없이 ALTER SYSTEM SET 명령어로 변경해 적용이 가능하나 휘발성이기 때문에 DB 재기동 시 설정이 해제된다. 변경 후 파라미터 파일에서도 설정 값을 변경해야만 다음 DB 재기동 시에도 유지된다. 반면 정적 파라미터는 대상 파라미터를 변경 후에 DB를 재기동 해야만 적용되는 특징이 있다. 결국 DB 운영중에는 동적 파라미터만 변경이 가능하고 즉시 적용된다. 이것은 큰 장점이지만 모든 파라미터가 동적으로 적용되는 것은 아니다.

정적 파라미터 파일(Static parameter file)
- 텍스트 형식의 파일로서 사용자가 관리(텍스트 편집기로 수정 가능)
- V$PARAMETER 뷰로 확인 가능
- initSID.ora 파일로 저장하며 pfile이라고 함
- 변경 후 DB를 재기동 해야만 변경 내역이 적용됨

동적 파라미터 파일(Dynamic parameter file)
- 바이너리 형식의 파일로서 오라클이 관리(SQL 명령어로 수정 가능)
- V$SPPARAMETER 뷰로 확인 가능
- spfileSID.ora 파일로 저장하며 spfile이라고 함
- DB 재기동 없이 ALTER SYSTEM SET 명령어로 변경 내역이 적용됨

먼저 DB 오픈 시 pfile을 사용하는지 spfile을 사용하는지 확인해 보자.

- SQL> show parameter spfile → 현재 instance가 사용하는 파일이 spfile인지 pfile인지 확인 가능
- SQL> show parameter pfile → 현재 instance가 사용하는 파일이 spfile인지 pfile인지 확인 가능

pfile 사용 시에는 initSID.ora 파일의 파라미터를 수정하고 DB를 다시 올리면 변경된 파라미터 값들이 적용된다. spfile 사용 시에는 spfileSID.ora 파일의 파라미터를 오라클 명령어로 수정하여 사용하면 된다. 파라미터 파일의 위치는 기본적으로 %ORACLE_HOME/dbs다.

이제 파라미터와 관련된 SQL 명령어를 알아보자. 다음은 현재 DB의 정적 파라미터 파일과 동적 파라미터 파일을 조회하는 뷰다. 모든 파라미터 값들을 조회할 수 있다.

- SQL> SELECT * FROM V$PARAMETER → 정적 파라미터 파일의 파라미터 값들을 조회
- SQL> SELECT * FROM V$SPPARAMETER → 동적 파라미터 파일의 파라미터 값들을 조회

하나의 특정 파라미터 값을 조회할 수도 있다. 다양한 파라미터 예시를 살펴보자.

- SQL> show parameter db_name → DB 이름을 알 수 있음
- SQL> show parameter nls_language → DB에서 기본적으로 사용할 언어 지정
- SQL> show parameter open_cursors → 1개의 세션당 사용하는 cursor의 최대 open 개수 지정
- SQL> show parameter sessions → 오라클 서버에서 생성 가능한 최대 세션 수 지정
- SQL> show parameter processes → 동시에 접속할 수 있는 사용자 process의 최대수

만약 최대 프로세스 수치를 초과하여 ORA-00020 에러가 발생하였다면 spfile인 경우 아래와 같은 명령어로 파라미터 값을 변경 할 수 있다.

- SQL> alter system set processes=400 scope=spfile → 범위가 spfile이므로 즉시 적용은 안됨
- SQL> shutdown immediate → 오라클 내림
- SQL> startup → 오라클 올림
- SQL> show parameter processes → 변경된 동시 접속 사용자 process 최대값 확인

scope는 파라미터 적용 범위를 말하는데 memory, spfile, both가 있다.

- memory: 메모리 영역에만 적용되므로 DB 재기동 시 변경된 속성값은 적용되지 않는다.
- spfile: 메모리 영역에는 적용 되지 않았지만 DB 재기동 시 변경된 속성값은 적용된다.
- both: 메모리 영역에도 적용되고 DB 재기동 시에도 변경된 속성값은 적용된다.

참고로 memory는 DB가 운영중인 상태에서도 파라미터에 즉시 적용 가능하지만, 모든 파라미터에 사용 가능한 것은 아님에 유의하자. 사용 가능 여부는 아래 명령어로 확인할 수 있다.

- SQL> show parameter parameter_name

아래와 같이 각각의 파라미터에서 사용 가능한 scope를 운영 상황에 맞게 적절히 선택하면 된다.

- SQL> alter system set parameter_name = parameter_value scope = memory → 메모리에만 적용
- SQL> alter system set parameter_name = parameter_value scope = spfile → spfile에만 적용
- SQL> alter system set parameter_name = parameter_value scope = both → 모두 적용

다음은 파라미터 파일을 복사하는 명령어다.

- SQL> create spfile from pfile → pfile로부터 spfile 생성
- SQL> create pfile from spfile → spfile로부터 pfile 생성

오라클은 DB 오픈시 어떤 파라미터 파일을 사용할지 선택 할 수 있다. DB 오픈 상태에서 파라미터 파일의 성격에 따라서 어떤 방식의 어떤 범위에서 변경하여 적용할지 결정하면 된다. PFILE 파라미터인 경우 오라클 명령어로는 변경할 값이 파라미터 파일에 기록되지 않으므로 반드시 vi 편집기를 통해서 파라미터를 수정하고 DB 재기동을 해야 변경 값이 적용된다. SPFILE 파라미터인 경우에는 SQL 명령어를 통하여 적용이 가능하다.



오라클의 주요 파라미터

수많은 파라미터가 있지만 그 중에서도 주요하다고 생각되는 파라미터를 소개한다.

column_img_2356.jpg

10여년 전 전국 250여 개 시군구 DB 서버를 관리한 적이 있었다. 그 당시 오라클 파라미터 설정 작업을 진행하였는데, 250여개 시군구 서버 각각에 맞는 최적의 파라미터 설정은 무리한 작업이었다. 그래서 서버의 성능, 사용자 수, 운영 업무의 특성을 고려하여 몇 개의 큰 그룹으로 분류하여 관리했다.



무모한 도전과 경험 사이에서

그때까지 개발자로서의 경험만을 쌓아 오다가 처음으로 맡은 DBA 역할이어서 흥분되고 아찔했지만 돌이켜 생각하면 아주 좋은 경험이었다. 주변인들은 DB 경력도 경험도 없었는데 너무 무모한 도전이었다고 말했지만, 어차피 우리나라 대통령도 경험이 있는 사람이 하는 것은 아니지 않는가 경험했던 것이 중요한 것이 아니라 경험하는 것이 중요하다고 생각한다.

이번 연재를 통해 오라클 파라미터에 대해서 살펴보았다. 개발자들은 파라미터 관련 이슈가 생겼을 때 DBA에게 파라미터 변경을 주장할 필요가 있다.

현재 설정된 파라미터가 가장 최적의 설정이라고 믿지는 말자. 중소 규모의 회사에서는 오라클 설치 초기의 파라미터를 한번의 변경도 없이 계속해서 유지하는 경우도 많기 때문이다.

또한 전담 DBA가 없는 회사에서는 개발자 스스로 오라클 파라미터를 설정-변경할 필요도 있으므로 몇몇의 중요한 파라미터에 대해서는 공부할 필요가 있고 파라미터 설정 방법에 대해서도 알아 둘 필요가 있다. 오라클 파라미터 설정이 오라클의 디폴트 설정이 아닌 여러분의 의지에 따른 설정이 되길 기대해 본다.

참고로 ‘디폴트 세팅의 함정’에 대한 보다 더 자세한 내용은 한겨레신문(사람과디지털연구소장) 구본권 기자의 저서인 『당신을 공유하시겠습니까』란 책을 읽어 보기를 추천한다.

다음 연재의 내용은 마방진에 관한 내용이다. 마방진의 원리와 마방진의 재미있는 역사에 대해서 살펴볼 것이다. 또한 N차 마방진, 입체 마방진, 슈퍼 마방진 등 현재까지 발견된 많은 마방진을 구현하는 방법에 대해서도 배울 것이다. 그런데 놀라운 것은 이 모든 마방진이 쿼리로 구현 가능하다는 것이다. 신기한 마방진의 세계로 여러분을 초대한다.



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

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



column_img_2357.jpg

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

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

column_img_2358.jpg