쑤나이퍼's diary

데이타 라는 것은 쌓이면 쌓일수록 고통스러워 합니다.

나를 좀 줄 맞춰 달라고...

애초 설계에서부터 잘 설계 하였다면..

시간이 지남에 따른 Maintenance 계획까지도 고려해서 개발했겠지만 그렇지 않은경우는..

주기적으로 상태를 확인하고 관리 해 줘야지만 클릭 = 응답 이라는 결과를 가져올 수 있겠지요.

전 지금 회사에서 DBA는 아니지만 부득이 DBA Role의 일부를 대신 해고 있는 관계로 DB쪽의 전문가는 아니지만..

개발자로서 DB에 대해 아는 부분만큼 정리합니다.

혹시 부족한 부분이 있으면 꼭 지적 해 주는 센스 ! 그렇다고 무시하진 말아주시공. ㅋ

----

1. 인덱스 단편화 확인

dbcc showconfig( 테이블명, '인덱스명') 으로

2. 인덱스 Re-build

  실행시키는 명령어에는 여러 가지가 있을지 모르겠지만 인덱스 Re-build 하는 방법은 2 가지가 있습니다.

그 절대 기준은 Lock 을 유발하느냐 안 하느냐

 2.1 Lock 유발 하는 rebuild

    - DBCC DBREINDEX( 테이블명, 채우기비율 )

    - ALTER INDEX 인덱스명 ON 테이블명 REBUILD WITH ( 각종 옵션들 )

 2.2 Lock 을 유발하지 않는 rebuild

    - DBCC INDEXDEFRAG( DB명, 테이블명, 인덱스명 )

3. 통계 업데이트

   UPDATE STATISTICS 테이블명

4. 성능 개선 확인

  위 작업을 하기 전에 현재 시스템의 Base line 이 어느 정도인지 정리하는 작업이 무엇보다 가장 중요하다 할 수 있겠습니다.

 우리의 현 상황을 제대로 알지 못하면 개선의 여지도 없기 때문에..

 특히나 엔지니어라면 '좀 느린데~~' 라는 추상적인 말 보다는 구체적인 수치로 정량화 할 수 있는 능력을 갖추어야 할 것 같습니다.

 어쨌든 위 1 ~ 3 번까지의 작업을 완료 후에는 Stored Procedure 의 실행 상태를 모니터링 하면서 작업 전 대비 얼마나 향상되었는지 확인 및 정리하시면 되겠습니다.

---------------------------

2005 부터는 ALTER INDEX 명령문을 사용해서도 On-line 서비스 중에 rebuild 할 수 있다고 해서 찾아보니...

약간의 제약 사항이 있네요.

Tech-net (http://technet.microsoft.com/ko-kr/library/ms188388.aspx)에서 퍼 온 내용입니다.

-----

---

 MS-SQL 에서 제공하는 가장 좋은 기능이자 운영시 많은 문제를 갖고 있는 양날의 검인 복제(Replication) 에 대해 포스팅 합니다.

최근 한 DB 장비의 성능이 문제가 되서 장비를 2대로 분리 하는 작업을 하였습니다.

그런데 작업 후에 여러 가지 문제가 나타나는 걸 보는데요.

그 중 하나가 복제와 연관된 부분이고 참고할 사항이기에 정리해 봅니다.

위에서 언급한 것처럼 2대의 장비로 신규 구성하고 한 대의 복제를 받는 장비가 있었는데요.

신규 구성되는 장비에 대해서만 신경을 쓰다보니 복제 서버에는 많이 신경을 쓰지 못하였습니다.

그러다 보니 일일 통계를 구하는 Job 이 이틀 정도 실패를 했는데도 모르고 있다가 삼일째가 되어서야 현상에 대해 인지하기 시작하였습니다.

평상시에는 일찍 끝나는 작업인데도 불구하고 몇 시간이 지나도록 끝이 나지 않다가 결국은 Fail !

실패시 Event 에도 기록하지 않고 메일 설정도 없고.. 하.. 관리자의 부재가 여기서 나타나는 군요.

그래서.. 여기 저기 살펴보니..

File Size 증가가 1M(기본값) 으로 설정되어져 있고..

통계를 구하는 SP 에선 Isolate 가 uncommited 로 되어져 있었습니다.

이 복제 대상(Source)의 DB는 평균 2-300 Batch Request 씩 처리 되고 있는 Database에 대해  복제로 설정되어져 있었고..

이러다보니.. 복제는 받는 쪽에서는 끊임 없이 File size 가 증가가 되면서 또 통계 SP 에서는 Dirty read 를 시도하다보니..

내부적으로는 Latch 카운트가 엄청나게 증가하더니 결국은 Job이 실패하고 있었던것이죠.

이 때 성능 카운터로 살펴보니 Disk Queueing 이 100 이상을 오르락 내리락 하고 있었습니다.

간접적으로 SQL 에서는 latch 카운트 수치로 이상여부를 나타내었지만.. 실질적으로는 I/O lock 을 유발하는 상황이 아니었을까 유추하였습니다.

그래서...

여기서의 해결방법은 매우 간단하였습니다.

1. File Size 증가 (10% 이상 Free space 를 주었습니다.)

   alter database modify file ( name = 땡땡땡, size = 100GB )

2. 자동 증가 사이즈 변경

   alter database modify file ( name = 땡땡땡, filegrowth = 1GB )

3. 통계 sp 의 isolate 설정을 read commited 로 변경

   어차피 전일 데이타에 대해서 통계를 구하는 부분임으로..

   이 부분은 sp 개발하신 분이 미처 생각하지 못하고 어디서 퍼 온 소스 기반으로 작업하지 않았나 싶습니다.

이렇게 설정하고 다시 통계 잡을 구하니 10초 만에 끝나네요. OTL !

이번 경험으로 다시 한 번 느끼게 된 것이..

서버 프로그래밍을 할 때도 그렇고 DB 튜닝을 할 때도 마찬가지도 성능을 좌우하는데 있어서 가장 큰 영향을 미치는 부분은 ..

역시나 IO 였던것 같습니다.

한정된 자원의 효율적인 분배.

그런데.. 생각해 보면 이건 컴퓨터 상의 얘기만은 아니지 않나요 ?

우리 삶에서도 한정된 자원(시간, 돈, 체력 등)을 얼마나 효율적으로 나누어서 사용할 수 있느냐는 끝없이 선택해야만 하는 우리의 사명인것 같습니다. ㅎ

ps>> 글을 쓰고 나니.. 이건 복제에 대한 얘기가 아닌 듯 ㅋㅋ

 지난 개발 이력을 잠시 생각해 보면..

처음 직장 생활에선 C(Turbo C) 언어부터 시작해서 Delphi (Borland 제품) 을 사용하다가 .Net (VS2003 부터) 으로 넘어 왔었고..  이제는 Java 개발 쪽으로 이동하고 있습니다.

Turbo C(Borland), Delphi, Visual Studio .Net 이 세가지 언어와 툴은 이것만 있으면 모든 개발을 할 수 있을 정도로 완벽한 개발 환경을 제공합니다. (물론 뛰어난 기능을 갖은 상용 Library 들은 많이 있구요. ^^ )

그러다가 자바쪽으로 넘어와서 개발을 하려 하니..

자바 개발을 위해서 어느 것 하나만 있으면 된다는 믿음은 없어졌습니다.

말 그대로 Open source 진영이라 불러도 좋을 만큼 많은 휼륭한 기능들을 GNU License 로 포장을 하고 무료로 제공하다 보니 이러 저러한 Open source 들을 갖다 쓰지 않고서는 위의 상용 개발환경을 따라 갈 수가 없습니다.

그러다 보니 자연스럽게 오픈 소스 하나 둘씩 갖다 쓰게 됩니다.

이런 상황속에서 자바 개발자 vs 비자바 개발자(또는 MS 개발자) 구도로 편 가르기를 하더니 서로 우리 것이 더 낫니 어쩌니 소모성 논쟁을 많이 합니다.

물론 한 사람의 개발자로서 이런 논쟁을 지켜 보고 있으면 재미 있긴 합니다.

어쨌든 재미 있는 논쟁 거리를 하나 찾은 김에..

제가 겪어 본 환경 중에서 양쪽의 특징에 대해 한 번씩 정리해 보면 어떨까 싶어 비교 해 봅니다.

(물론 제가 아는 지식이 전부는 아니기에 혹시라도 잘 못 된 부분이 있으면 언제든 글 남겨 주세요. 시비는 사양이구요. ㅋ)

자 그 많은 비교 대상중에 요즘 이슈가 되고 있는 기능 중 하나인 Entity Mapping 기능에 대해 정리 해 봅니다.

Entity Mapping 이라 함은..

데이타 관점의 개발을 지향하는 방법 중 하나로서 DB 스키마 정보를 프로그램 개발 환경으로 좀 더 깊숙히 가져와서 데이타 위주의 효율적인 개발을 할 수 있도록 지원하는 환경이라고 말하고 싶습니다.

아무래도 DB 개발 따로 하고 비지니스 개발 따로 해서 두 가지를 조합하다보면 여기 저기서 문제가 될 만한 부분이 많으니 데이타 모델에 대해서는 간결하고 핵심적인 부분들을 추려서 프로그램 영역으로 가져온 후 통합 개발을 한다면 개발적인 부분에서는 생상선 향상을 가져 올 수 있다는 것이죠.

예를 들자면 기존에는 SP를 만들고 그 결과(Result set)을 특정 클래스로 구현해서 필요한 정보만 가져온 후 일련의 비지니스를 처리하는 방식이었다면..

Entity Mapping 방식은 SP가 됐든 Native Query 문이 됐든 DB에서 리턴하는 모든 결과셋을 해당 테이블의 Result set class 로 전달 받는 구조입니다.

어찌보면 큰 틀의 개념은 별 차이가 없어 보이기는 하지만 ..

결과셋을 재이용하는 측면에서 보면 공통된 테이블에 대해서 여러 가지 다른 결과셋을 가져오는 쿼리문이 존재할 경우에 재사용성이 증가할 수 있겠죠.

여기서 주목할 점은 과거엔 비지니스 위주의 개발을 했다면..  이제부턴 데이타 관점의 개발을 한다는 부분입니다.

사실 많은 개발 요소 중 System Core Library 모듈들을 제외하곤 데이타가 로직의 중심이니 맞는 말이겠죠 ?

자.. 그럼 자바 환경과 MS 환경에선 어떤 이름으로 제품이 나왔는지 보겠습니다.

Entity Framework (MS) : myBatis (Java)

참고 자료는 아래와 같습니다.

EF : http://msdn.microsoft.com/en-us/data/bb399567

iBatis : http://code.google.com/p/mybatis/

두 제품을 히스토리를 간단히 정리해 보자면 ..

MS 에서는 .Net Framework 3.5 부터 LinQ 라는 이름의 ORM Mapping 기능과 동적 쿼리를 생성해 주는 강력한 기능을 제공하고 있었고 자바 진영에서는 Hibernate 라는 프로덕트로 역시 동일한 기능을 제공하고 있었습니다.

양 쪽 모두 휼륭한 기능을 갖고 있었고 생산성 향상이라는 놀라운 효과를 갖고 오긴 했지만..

문제는 동적 쿼리 문을 생성하다보니 DB(Database) 입장에서는 최고의 성능을 내도록 하기 위해서는 DBA 가 아닌 개발자의 목을 졸라야만 하는 한계를 가져 오게 됩니다.

한 마디로 DBA들은 문제의 쿼리를 어떤 놈이 만드는지 모르게되고 개발자들은 혼자만의 세상을 꾸며 놓고 인수인계란 절차를 남겨 놓고 떠나게 됩니다.

 이러한 문제점이 비단 한국내의 문제점만은 아닌 듯 싶네요.

어쨌든 양쪽 진영에도 동일한 문제점에 대해 이슈가 되는 일이 많아졌고 이런 틈 속에서 iBatis 라는 오픈 소스가 대안으로 주목을 받기 시작합니다.

iBatis 는 동적으로 쿼리를 생성하지는 않지만 DB Result Set 에 대해서는 클래스로 맵핑할 수 있는 기능을 제공하고 쉬운 환경 설정 및 간단한 코드만으로 쉽게 개발 할 수 있는 환경을 제시합니다. 한 마디로 휼륭합니다.

그러다 최근에는 apache 진영과 이별을 했는지 myBatis 란 이름으로 바꾸면서 많은 부분 네임스페이스에서도 아파치가 사라졌습니다.

하지만 여전히 최고입니다.

 myBatis가 인기를 끌기 시작하면서 MS 진영에서는 .Net F/W 4.0을 Release 하게됩니다.

Entity Framework 이란 먼가 거창한 이름을 갖고 대대적인 홍보를 하게 됩니다. 이름 짓는것만 봐도 MS 답다는 느낌을 개인적으로 받습니다만.. ;;

아직 EF( Entity Framework) 으로 개발을 해 보지는 않아서 구체적인 기능에 대해서 논하긴 어렵지만 후발 주자로 나선 라이브러리인만큼 기존 myBatis 에서 제공하던 기능 외에도 많은 편리한 기능을 제시하지 않을까 싶습니다.

간단히 MS 홈페이지에 소개하는 소주제 내용을 살펴보면 아래와 같습니다.

(우측의 글은 제가 이해한 내용에 대한 의미 부여입니다.)

먼가 대단한게 있어 보이는데요..

그렇다면 아키텍쳐 그림은 어떨까요 ?

myBatis

Entity Framework

위 2가지 모델에 대해 System layer 를 구분해 정리해 보면 이런 것 같습니다.

어떤가요 ?

이름만 다를뿐 동일하지 않나요 ? ㅋㅋㅋ

누가 먼저 만들었는지는 모르겠지만.. 소송을 걸어도 될 만한 구성인것 같습니다.

EF를 사용해 봤으면 좀 더 유익한 분석을 할 수 있었을테지만 MS 툴이 엄청난 고가인지라 회사에 라이센스가 없습니다.

트라이얼 버젼을 설치해서 해 볼까도 생각이 들지만..

귀차니즘으로 인해 스킵합니다.

어찌됐든 양쪽 진영이 Data Driven Architecture 를 좀 저 자연스럽게 지원할 수 있는 환경을 제시한다는 점에서는 매우 고무적입니다. 이를 통해서 MVC 모델로 개발하기도 쉬워지고 굳이 방법론에 대해 잘 몰라도 그냥 쓰다보면 방법론을 적용할 수 있다는 것이 매우 흥미로운 것 같습니다.

MSSQL DB 를 자주 사용하다보면 Transaction Log가 Full 차게 되서 더 이상 데이타의 변경이 불가능한 경우가 발생합니다.

물론 DB 설정에 보면 Data 뿐만 아니라 Log 사이즈도 자동 증가 모델로 해 놓긴 하지만..

버그인지 아니면 기타 설정이 더 있는지 간혹 그렇지 않은 경우가 발생하네요.

이럴 때 유용하게 쓸수 있는 스크립트

alter database 데이타베이스명 set recovery simple

dbcc sqlperf( logspace )  -- 현재의 가용 공간 확인

backup log 데이타베이스명 with truncate_only

dbcc shrinkfile( 논지적db 화일명, 사이즈 ) 

dbcc sqlperf( logspace )  -- 변경 후 가용 공간 확인

alter database 데이타베이스명 set recovery full

Java Editor 단축키

Ctrl + Shift + M : 특정 클래스 Import 시키기
Ctrl + Shift + O : 자동으로 Import 시키기
Ctrl + Shift + F : 코드 자동 정리
Ctrl + Shift + G : 특정 메써드나 필드를 Reference하고 있는 곳을 찾는다.
Ctrl + 1 : Quick Fix. 에러가 발생했을 경우 Quick Fix를 통해 쉽게 해결이 가능하다.
Ctrl + Shift + / : 블럭 주석 설정
Alt + Shift + UP : 커서를 기준으로 토큰단위 블럭지정
Alt + Shift + DOWN : 커서를 기준으로 토큰단위 블럭해제
CTRL + L : 특정 줄번호로 가기
Alt + Shift + J : 자동으로 주석 달기 (메소드나 멤버변수에 포커스 두고 실행)

Window 이동

F10 : 메뉴창을 활성화
Ctrl + F8 : 다음 Perspective로 이동
Ctrl + N : 새로운 파일 및 프로젝트 생성.
Ctrl + Shift + Down : Java Editor에서 다음 member로 이동.
Ctrl + F7 : 다음 View로 이동.
Ctrl + Shift + F7 : 이전 View로 이동.
Alt + <- : 이전 작업 화면
Alt + -> : 다음 작업 화면
F12 : 컴파일 중 에러등으로 포커스가 다른데로 갔을 때 Editor 로 커서 이동
Ctrl + 1 : 컴파일 에러가 발생한 곳에서 Ctrl + 1을 누를 경우 컴파일 에러에 대한 해결책을 제시

디버깅 단축키

CTRL + Shift + B : 현 커서의 위치에 브레이크 포인터 설정/해제
F11 : 디버깅 시작
F8 : 디버깅 계속
F6 : 한줄씩 실행(Step Over)
F5 : 한줄씩 실행하되 함수일 경우 그 함수 내부로 들어감(Step Into)
CTRL + R : 현재 라인까지 실행(Run to Line)

Refactoring 단축키

Shift + ALT + 알파벳 : Refactoring을 위한 단축키 임.

RUN 단축키

Ctrl + F11 : 이전에 실행되었던 Run파일 실행.