단무지 시즌 IV: 단무지의 DB 운영 이야기(5회)

인재는 막을 수 있다! DB 일일점검의 실전(3)

서윤식은 외환신용카드에서 DBA 12년, 현대하이카다이렉트에서 DA로 10년을 일했다. 금융권 데이터 분야에서 22년간을 보내며, DBMS 운영 및 튜닝, SQL 튜닝, 데이터 모델링, 데이터 품질관리 영역 등 DB 전 영역을 고루 경험하였다. 이학사(전자계산학과), 경영학 석사를 거쳐 2015년 8월 IT 정책경영학과 박사과정을 수료하였다. 그리고 2016년 3월부터 데이터와사람들의 대표로 있으며, 한국데이터진흥원의 산업체 전문 강사로서 데이터 모델링 및 SQL 튜닝 강의를 하고 있다. 또한 ‘데이터와사람들(http://cafe.naver.com/dbstudydapsqlp)’이라는 네이버 카페를 운영하면서 데이터 영역의 지식이 필요한 사람들과 다양한 방법으로 소통하고 있다.

들어가면서

머나먼은 DBA를 하고 있으나, 정말 DB에 대한 지식만큼은 머나먼 다리를 지나 있는 것만 같았다. 이름만 DBA일 뿐이었다. 부서원 30여 명으로 구성된 애플리케이션 운영 및 유지보수 부서에서의 DBA는 DBMS뿐만 아니라 SQL 튜닝과 때에 따라서는 데이터 모델링도 진행해 줘야 한다. 하지만 우리의 머나먼 대리는 모델링도, SQL 튜닝도 머나먼 남의 일일 뿐이었다. 그 뿐이랴. DBA의 기초 중에 기초인 DBMS에 대한 이해마저 개나 줘버린 상황이었으니, 데이터 영역에서 잔뼈가 굵은 단무지의 눈에는 정말 머나먼을 개나 줘버리고 싶은 심정이었다. 하지만 어쩌랴. 단무지는 애플리케이션 운영의 전체 팀장이며, 안정적인 운영을 책임지고 있는 상황에서 머나먼을 무시하고는 본인의 책임을 정말 개나 줘버릴 수 있는 상황이었다.

그렇지만 위대한 우리의 단무지는 과거를 잊지 않고 있었다. DB에 대한 지식은 전무한 채 단순, 무식, xx로 똘똘 뭉쳐 앞뒤 안 가리고 사고를 치고 다니던 시절이 있었으며, 지금은 데이터 영역 전체를 꽤 뚫고 있는 혜안을 가진 인재가 되었다는 것을 단무지는 기억하고 있었다. 본인에게 있어 정신적 지주인 냉정해 부장과 같은 훌륭한 스승이 있었으며, 머나먼 대리에게는 본인이 냉정해와 같은 역할을 하겠다고 다짐했다. 다행히 머나먼은 단무지의 하드 트레이닝을 재미있게 받아 들이고 있었으며, 본인 또한 과거의 단무지를 능가하는 열정으로 임하고 있었다. 자, 그럼 단무지의 담금질이 또 다시 어떻게 시작하는지 독자 여러분들과 함께 알아 보겠습니다.

단무지의 혼비백산

단무지는 혼자 하늘에 떠 있다. 꿈이 아닌 현실이다. 몇 해 전부터 취미생활로 경비행기 조종을 배웠으며, 현재 라이선스까지 딴 상황이다. 비행장에서 비행기를 한 대 대여하여 한 시간 넘게 대부도와 시화호 상공을 비행하고 이제 착륙을 시도하고 있었다. 평상시 무리 없이 사뿐히 내려 앉은 모습과는 다르게 오늘은 왠지 불안 불안하다.

비행장에서 멀지 앉은 곳의 컨테이너가 보인다. 이때는 플랩을 내려야 한다. 플랩은 저속 비행 시 비행기의 양력을 높여 안전하게 이착륙을 유도하는 장치로, 날개를 더 넓혀 주는 것이다. 여객기를 탔을 때, 비행기가 착륙 지점에 다가갔을 때 날개를 넓혀 주는 것을 본 사람이 있을 것이다. 단무지는 천천히 플랩을 내렸다. 그리고 스로틀 밸브(자동차의 엑셀레이터)를 서서히 당겨 속도를 줄이고 있었다. 이제 기체를 고도 300피트까지 하강 시켰다. 그리고 활주로를 향해 우 선회하였다. 여기서는 활주로와 기체를 일직선 상에 두는 것과 속도 60마일을 유지하는 것, 그리고 천천히 줄어드는 고도를 정확하게 체크해야 한다. 바람은 지속적으로 기체를 활주로 밖으로 밀어 낸다. 단무지는 바람에 지지 않겠다는 굳은 다짐으로 좌 우측 러더(자동차의 핸들과 같은 역할을 하며, 모든 비행기는 양쪽 발의 페달로 조종하도록 되어 있다)를 번갈아 가며 차고 있다.

컨디션이 좋을 때는 러더를 조작하는 것이 부드럽지만, 그렇지 못할 때는 굉장히 과격해 진다. 따라서 기체는 좌우로 요동을 칠 수밖에 없다. 자동차는 2차원이지만, 비행기는 3차원이다. 러더에 의한 조종과 함께 조종관을 좌우로 흔들어 기체를 우측 또는 좌측으로 기울임에 다라 활주로를 벗어날 수도 또한 다시 안쪽으로 들어올 수도 있다.

단무지는 환장할 지경에 있다. 바람이 그리 심한 것도 아니었으나, 활주로와 기체를 일직선으로 맞추는 것과 사투를 벌이고 있었다. 아이고! 이놈의 활주로 정렬만 신경을 썼더니 속도가 너무 빠르다. 속도를 늦추기 위해 기체의 앞을 살짝 들었다. 속도는 어느 정도 맞췄으나, 다시 고도가 너무 높다. 겨우 속도와 고도를 잡았다. 이때 기체는 활주로와 많이 틀어져 있다. 다시 맞춰 보자. 점점 활주로는 다가오는데, 늦었다. 이대로는 안전한 착륙이 불가능할 것 같다. 순간 여러 기억들이 단무지의 머리를 스쳐 지나간다.

사람이 위기에 처했을 때는 CPU가 초 고속연산을 한다고 했던가 모든 기억들이 슬로우 모션처럼 스친다. 부모님과의 행복했던 기억, 정지연과의 연애 시절, 냉정해도, 머나먼도 순간 기억을 스친다. 단무지는 이제 판단을 해야 한다. 무리한 착륙을 시도할 것인가 아니면 포기할 것인가 이 순간 가장 중요한 것은 전광석화 같은 빠른 판단이다.

단무지는 착륙을 포기했다. 그리고 스로틀 밸브를 잡고 있던 왼손에 강하게 힘을 주었다. 동시에 조종관을 들어 기체를 살짝 들어 올렸다. 비행기는 강한 소음과 함께 다시 하늘로 솟아오른다. 착륙을 포기하고 다시 날아 오르는 것을 복행이라 한다. 단무지는 복행을 결정했다. 착륙할 때는 법칙이 있다. 조종사들은 초기 교육 때 10가지의 상황 중 하나라도 미심쩍다면 반드시 복행해야 한다고 배운다. 이때 주의할 점은 복행을 결정했다면, 절대로 되돌려서는 안 되는 것, 즉 다시 착륙을 시도하면 안 된다. 단무지 역시 안전한 착륙이 불가능한 지금 상황에서 복행을 결정했다. 그리고 이 복행 결정이 벌써 4번째다.

기체는 굉음과 함께 하늘로 다시 떠오른다. 이륙 시 프로펠러에서 불어오는 후류로 인해 기체가 좌측으로 쏠린다. 이것을 잡아주기 위해 오른발에 힘을 주어 러더를 강하게 밟아 준다. 다시 비행기는 고도 500피트를 유지했다. 이제 우 선회를 세번 하여 다시 착륙을 시도 해야 한다. 이 과정은 경비행기의 경우 약 7~8분이 소요된다. 단무지의 요동 쳤던 가슴도 일단 안정이 되었다. 이상하다. 100번 이상을 착륙했던 활주로다. 그 동안 시스템처럼 안정적으로 작동됐던 고도, 속도, 기체와 활주로의 정렬이 오늘따라 각자 따로 논다.

4번의 복행 시도에 따라 지상으로부터 무전이 요동을 친다. "무슨 일입니까 어떤 문제라도 있나요" 지상에 있는 교관의 다급한 목소리가 무전기를 통해 흘러 나온다. "아니요. 별 문제는 없는데, 두 달 만에 왔더니 착륙이 원활치가 않네요. 이번에는 사뿐히 내려 앉겠습니다. 걱정하지 마세요" 단무지는 일단 지상에 있는 교관을 안정시켰다.

다시 세 번의 우 선회 후 고도를 300피트까지 낮추고, 스로틀 벨브를 아이들(최소화) 시킨 후 기체를 숙였다. 속도 60마일을 유지하고, 이제 활주로와 기체를 일직선 상에 두고… 좋다. 이제 시선은 저 멀리 지평선을 바라본다. 지면이 빠른 속도로 다가오고 있었다. 이 순간 가장 중요한 것은 플래어 동작이다. 기체가 지면에 닿기 직전에 조종관을 당겨 앞을 들어주는 행위이다. 마치 새가 땅에 내려앉기 직전에 날개를 벌려 안정적인 착지를 하는 것과 같은 동작이다. 기체를 들었을 때 속력이 살아 있다면 비행기는 살짝 떠 올랐다가 땅으로 쿵 내려 앉는 하드 랜딩이 될 것이고, 속도가 너무 죽었을 때 역시 하드 랜딩이 된다. 정말 적정한 시점에 조종관을 당겨야 하는데 착륙 시 조종사가 가장 어려워하는 판단 중 하나다.

단무지는 정확한 플래어 시점을 찾고 있었다. 하드랜딩이란 비록 죽고 사는 문제는 아닐 지라도 비행 100시간이 넘는 단무지에게 있어 지대한 쪽팔림을 유발함과 동시에 본인의 조종 실력이 바닥이라고 비행장에 있는 모든 사람들에게 광고를 하는 것과 동일한 행위이다.

단무지는 조종관을 천천히 당겨 하강 모드로 있던 기체를 수평으로 만들었다. 순간 비행기는 지면 위 3미터에서 활주로와 일직선이 되어 날고 있다. 이제 플래어 동작만 남았다. 단무지의 모든 감각은 플래어 시점을 찾는데 동원되어 있었다. 2~3초의 순간이 마치 1년처럼 다가온다. 활주로 옆에 피어 있는 코스모스들이 연기처럼 스치고 지나간다. 드디어 단무지는 이때다 싶었다. 천천히 그리고 과감하게 조종관을 당겼다. 이때 모든 조종사들이 착륙 시점에 가장 듣기 좋아하는 소리인 소리인 ‘크르르르르~~~’ 소리가 들린다. 소프트랜딩이다. 뒷바퀴가 활주로에 부드럽게 키스를 하는 듯 하다. 이제 앞 바퀴가 자연스럽게 내려온다. 단무지는 앞 바퀴 역시 부드럽게 지면에 닿을 수 있도록 앞 바퀴가 땅으로 떨어지는 동안 조종관을 끝까지 당겨 주었다. 앞 바퀴가 닿는 것을 확인하고 1.5초를 기다린 후 브레이크를 당겼다. 비행기의 바퀴가 이제서야 자신의 역할을 하겠다는 심산인지 속도를 급격히 줄여주고 있었다.

단무지는 드디어 안도의 한숨을 내쉬었다. 그리고 활주로 중간 부분에서 정확히 속도를 줄였다. 천천히 활주로 좌측에 있는 무전실 앞쪽으로 기체를 유도하여 정지 시켰다. 시동을 끄고, 한동안 멍하니 앉아 있었다. 교관이 달려 온다. "괜찮습니까 별 이상 없지요" 교관의 물음에 단무지는 너스레를 떨며 대답했다. "네. 이상 없습니다. 비행 공백이 일 개월 이상일 경우는 교관님을 모시고 올라가야겠어요. 아주 혼이 났습니다. 하하하" "비행 100시간이 넘는 분이 한 달 지났다고, 복행을 4번씩이나 해서야 되겠습니까 이거 처음부터 다시 배워야 하는 것 아닙니까" 교관이 농담을 받았다. 그리고 "4번의 복행은 정말 잘 하셨습니다. 착륙은 조금만 이상 있어도 복행하는 것이 원칙입니다. 잘하셨습니다." 마지막으로 교관이 다시 한 번 조종술에 대한 리마인드를 시켜 준다.

다시 일상으로

어제의 상쾌했던 비행을 뒤로하고 아침 출근 후 머나먼과 커피를 한 잔 하고 있다. 머나먼은 단무지의 입만 바라보고 있다. 마치 할머니가 이야기 보따리를 풀어 놓기 직전, 쳐다보는 아이들의 눈동자처럼 반짝반짝 빛나고 있었다. 머나먼은 하고 싶지 않은 공부를 억지로 하는 것이 아니다. 본인의 업무수행에 필요한 것이며, 또한 자신의 기술력을 높이는 기회이기도 하다. 엔지니어는 본인의 스킬이 업그레이드 될 때 가장 짜릿한 희열을 느낀다. 그들은 그 희열을 먹고 사는 존재다. 만약 그것이 없다면, 엔지니어일 수 없다. 머나먼 또한 마찬가지다. 이 회사 입사 후 퇴근할 때면 매일 허무함을 느끼곤 하였다. 아무런 발전도 없이, 그저 매일 매일을 보내고 있는 것 같았다. 가슴 한편에는 먹어도 먹어도 채워지지 않는 뭔가가 항상 있었다. 그런 와중에 단무지를 만난 것이다. 요즘은 하루 하루 본인의 몸 속에 무공을 차곡차곡 채워 놓는 듯한 느낌이다. 회사 출근 길이 기쁘기만 하다. 오늘은 본인의 스승이 또 자신을 어떤 세계로 이끌어 줄 것인가에 대한 기대감으로 가득 차 있다.

alert log 파일

단무지: 오늘은 alert.log 파일에 대해 이야기해 보자. 이 파일의 정확한 명칭은
alert_.log라는 명칭으로 생성되며, 저장 위치는 parameter 파일에서도
확인할 수 있고 아래의 쿼리로 확인 가능하다.SELECT VALUE
FROM V$PARAMETER
WHERE NAME = 'background_dump_dest' ;alert log 파일에는 DBMS 기동과 종료, 데이터 파일 추가, log switch 등 DBMS에 대한
주요 변화가 기록되며, 또한 Background Process에서 발생되는 각종 에러들도 기록되지.
따라서 매일 확인하고, 에러 발생 시 원인 파악 및 조치를 해야 해.
이 파일을 확인하지 않는 DBA는 곡선 주로가 있는 200미터 달리기를
눈 감고 하는 것과 마찬가지야. 머나먼: 아~~ 그렇군요. 퇴근 후부터 아침까지 있었던 DBMS의 모든 일을 알 수 있겠네요.
정말 중요한 파일 이군요. 아~~~ 여태껏 한번도 보지 않았습니다.
이제는 매일 아침 주요 점검사항 중 하나로서 꾸준히 점검하도록 하겠습니다.단무지: 하하~~ 맞아. DBA가 절대로 잊어서는 안 되는 파일이야.
본인이 생각지 못하게 오라클 DBMS가 작동된다면 첫 번째로 확인할 항목으로 알아두면 정확해.머나먼: 감사합니다, 팀장님.

오라클 스케줄러

단무지: IT 자원을 운영하려면 배치 프로그램이 필요한데 말이야.
배치 프로그램은 직원이 퇴근한 이후 밤에 수행되는데,
그 프로그램을 수행시켜 주는 것이 있지머나먼: 네, 많이 있습니다. 각종 솔루션마다 스케줄러는 존재합니다.
메인 프레임에서 대표적으로 사용하는 것이 ‘컨트롤엠’이고요.단무지: 그렇지. 오라클 DBMS도 동일한 스케줄러가 있어. job이라고 하지. 머나먼: 아, 네. 잘 알고 있습니다. 저도 몇몇 배치 프로그램을 job에 등록하여 사용하고 있습니다.단무지: 음. 그런데 말야. 어떤 사람들은 DBMS의 스케줄러를 이용하여 애플리케이션 배치 프로그램을
관리하는데 말이야. 좋은 방법은 아니야. 애플리케이션의 배치 프로그램은 애플리케이션 용도의
스케줄러 솔루션으로 관리하는 것이 맞아. 그리고 DBMS의 job은 DBA가 DBMS를 관리하는 용도로만
사용하는 것이 맞아. 각 솔루션은 각자의 맞는 용도가 있거든.
DBMS의 job은 DBMS 관리를 위한 용도로만 사용할 것을 권장해.
애플리케이션 용도의 솔루션은 선행-후행 작업 등의 등록이 가능하지.
선행작업의 결과에 따라 후행작업이 수행될지 여부를 결정하기도 하고,
또한 선행작업의 결과를 후행작업의 파라미터로 사용하기도 하지.
그런데 오라클의 job은 그런 다양한 기능이 없어.
단순히 언제 수행되었으며, 다음 수행 일시는 언제인가 정도만 관리하는 job이거든.머나먼: 아 그렇군요. 그러면 어떠한 배치 프로그램을 관리하게 되나요단무지: 주로 통계정보 갱신이 가장 많이 사용하는 용도이며, 특별히 정해져 있지는 않지만,
DBA들이 DB를 관리하는 용도로 사용해. 회사마다 특성에 맞는 job을 등록하여 관리하면 되는 거야.
대신 한 번 등록하고 마는 것이 아닌 매일 정상적으로 수행되었는지 관리하는 것이 가장 중요해.머나먼: 아. 알겠습니다.단무지: 해당 스케줄러를 조회하는 쿼리는 다음과 같아.SELECT JOB, LOG_USER, LAST_DATE, NEXT_DATE, THIS_DATE, BROKEN,
WHAT, INSTANCE, INTERVAL
FROM DBA_JOBS
ORDER BY BROKEN
;단무지: 가장 중요한 것은 BROKEN 값이 "Y"로 되어 있으면 원인 파악 및 적당한 조치가 필요하고.

Tablepespace 용량 점검

머나먼: 넵. 감사합니다, 팀장님. 이제 Tablespace 용량 점검에 대해 이야기해 주실 차례입니다.단무지: 이제 일일점검 순서까지 외웠구먼. 좋아. 일일점검 항목의 내용 가운데 중요하지 않은 것이 없지만,
Tablespace 사용량 및 여유 양을 조사하는 것 또한 굉장히 중요한 항목 중 하나야.
왜냐하면 DB 장애 중 가장 많이 발생하는 것 중 하나가 Tablespace Full로 인한 장애야. 물론 Tablespace를 구성하는 파일의 특징을 자동 증가하게 해두면
이런 장애는 발생하지 않겠지만
사실상 대용량 DB를 운영하면서 데이터 파일의 특성을 자동 증가로 둘 수는 없기 때문이지. 그 이유는 raw device 파일을 사용할 수도 있고, 파일 시스템을 쓴다 할 지라도 데이터 파일을
무한정 늘릴 수는 없기 때문이야. 그래서 대부분의 DBA들은 자동 증가 옵션을 사용하지 않는데,
이때 Tablespace 여유량 점검을 깜박하고 놓치는 경우가 허다 하거든. 이런 것들은 매일 점검만 하면 절대 장애가 발생하지 않지만, 그렇지 않을 경우 거의 백이면 백
모든 DBA들이 한 번씩 경험을 하게 되는 장애란 말이지. 또한 Disk 증설이 필요하여 신규 Disk를 도입할 경우 IT 기획팀에서 최근 2년 간의 데이터 증가 추이를
요구하는 경우가 발생하지. 이럴 경우를 대비하여 별도의 Table에 매월 Tablespace 사용량을
저장해 둔다면, 매우 유용하게 활용할 수도 있어. 아래의 SQL을 활용하면 간단히 처리할 수 있지.SELECT TO_CHAR(SYSDATE, 'YYYYMMDD') CHECK_DATE,
A.FILE_ID, A.FILE_NAME, TABLESPACE_NAME,
ROUND(A.BYTES/1024/1024) TOT_MBYTES, -- 총용량(MB)
ROUND((A.BYTES-B.BYTES)/1024/1024) USED_MBYTES, -- 사용량(MB)
ROUND(B.BYTES/1024/1024) FREE_MBYTES, -- 가용량(MB)
ROUND((1- B.BYTES/A.BYTES)*100, 1) USED_RATE -- 사용율(%)
FROM DBA_DATA_FILES A,
(SELECT FILE_ID, SUM(BYTES) BYTES
FROM DBA_FREE_SPACE
GROUP BY FILE_ID
) B
WHERE A.FILE_ID = B.FILE_ID
ORDER BY A.FILE_ID;머나먼: 아. 네 그렇군요. 매일 여유 양을 점검할 뿐 아니라, 매월 현황을 저장하여 향후 데이터
증가 추이까지 파악할 수 있겠군요. 현황을 저장하는 것이 어렵지 않지만, 나중에는 정말 유용한
데이터로 활용할 수 있을 것 같습니다. 저는 생각지도 못했습니다. 항상 디스크 사용 추이를
달라고 하면, 대략 기억을 참고하여 주먹구구식으로 대충 만들어 주곤 했거든요.단무지: 맞아. 매년 9~10월이 되면 익년도 예산작업을 하는데, 그 때마다 꼭 필요한 데이터가
되는 거야. 이런 데이터를 누적해 놓지 않으면, 그 때가서 낭패를 보는 거지.
이는 디스크 사용량뿐 아니라 CPU 사용률 또한 마찬가지야. CPU 사용률에 대한 이야기는 다음에 하자고.머나먼: 네 알겠습니다. 이제 RAC 각 Node별 적정 세션 연결 여부에 대해 진행할 차례 입니다.단무지: 자 오늘은 여기까지 하자. 머 대리도 혼자 스터디할 시간이 있어야지.머나먼: 네. 벌써 한 시간이 지나 버렸습니다. 이제 한 5분 지난 것 같은데 말입니다.단무지: 하하, 이제 내 앞에서 능청도 떠는구먼.머나먼: 어 이거 왜 이러십니까 정말입니다. 하하단무지: 그래. 알았다 알았어. 오늘 하루 또 수고하고….머나먼: 넵. 충성!!!

에필로그

필자는 하이카다이렉트손해보험사에서 10년을 근무하였습니다. 근무하는 동안 DB에 장애가 단 한 건도 없었습니다. 10년 무장애라는 이야기죠. 회사에서 같이 근무했던 동료들을 제외하고는 이 말을 믿으려 하는 사람들이 없었습니다. 심지어는 되물어 오는 사람들도 있었습니다. "10년 무장애라는 게 가능한 것이냐 어떻게 그렇게 할 수 있냐" 하고 말이죠. 하지만 제가 했던 방법은 의외로 단순했습니다. 철저한 일일점검을 했을 뿐입니다. 거기다 추가로 하나 더 하자면 평상시 철저한 모니터링이었습니다.

일일점검이 장애의 95%를 걸러낼 수 있습니다. 그리고 나머지 5%가 모니터링이었던 것이죠. 거꾸로 이야기하면 이렇습니다. IT뿐 아니라 모든 시스템 장애의 95%는 인재다. 인재는 일일점검으로 막을 수 있다.

자, 이제 여러분들께서도 본인이 DBA이든 개발자든 상관없이 일일점검을 해 보세요. 위에서 시켜서 하는 일일점검이 아닌, 담당자만이 알고 찾아낼 수 있는 항목을 열거하고, 일일점검 가능한 방법을 찾아 매일 진행해 보기 바랍니다. 그럼 여러분이 운영하는 시스템의 장애는 95%는 예방 가능합니다. (다음 회에 계속)

출처 : 한국데이터진흥원

제공 : 데이터 전문가 지식포털 DBguide.net