안녕하세요. 김대우 입니다. 잘 지내셨는지요?

전 오늘 와이프와 함께 "꽃피는 봄이오면" 영화를 봤습니다.

음악과 함께 잔잔한 감동이 밀려오는 그 영화... 혹시 못보셨다면 꼭 봐 보십시요.

최민식형님 나오는 영화 올드보이는 앉은 자리에서 두번보고 이래저래 본거 합치면 댓번은 본거

같습니다. 이 "꽃봄" 영화 역시 한 댓번은 보게 될거 같습니다. ^_^


우선 바쁘신중에 답변 주셔서 감사합니다. 기술과 관련된 이슈를 먼저 풀어 보도록 하지요.

--------------------------------------------------------------------------------------------------
안녕하십니까. 코난님.
금요일이라 업무때문에 정신이 없는데, 친히 코난님께서 오셔서 한마디 해주시니 저도 시간을 내지 않을 수가 없
네요. 저도 SQLER에 종종 들리는 사람입니다. 회원가입은 하지 않았지만 여러 강좌도 보고 검색도 해서 좋은 자료들
많이 참고하고 있답니다.
--------------------------------------------------------------------------------------------------

제가 운영하는 사이트에 오신다니 무한한 영광입니다. 앞으로도 최선을 다하도록 하겠습니다.

--------------------------------------------------------------------------------------------------
근본적으로 저희 시스템이 과부하로 허덕이는 이유는 물론 있습니다. 짐작하시는 대로 2번, 즉 잘못된 쿼리나 인
덱스 때문입니다. 간단히 튜닝을 하면서 그런 부분은 대부분 파악했습니다. 그래서 제가 손을 댄 부분도 주로 인덱스
쪽이고요. 그런데 더 근본적으로 디비 구조 자체가 어그러진 부분이 많기 때문에, 전체 재개발이 필요한 상황입니다.
그러니까 튜닝을 했다고 하더라도 문제의 근원에 대한 수정이 된 것이 아니라 겨우 달래놓은 정도죠.
제가 입사하기 이전에 개발했던 외주 업체가 해놓은 일인데다 앞으로 두어달 정도는 재개발을 할 수 있는 상황이
아니기 때문에 그냥 달래놓고 쓰고 있습니다. 제가 튜닝을 했다고 말했던 것은 이정도의 상황을 말씀드린 겁니다. MS
에서 툴로서나 문서로서 제공하는 방법들은 거의 빼놓지 않고 검토 혹은 적용을 했다고 할 수 있습니다. 물론 말씀
하신 방법들도 이미 해보았습니다. 하지만 시간을 내셔서 좋은 조언들을 주신데 감사드립니다.
--------------------------------------------------------------------------------------------------

네. 잘알겠습니다. 그냥 달래 놓은 것을 첫번째 저를 여기 오게한 글에서는 지훈님께서

"입사후 거의 한달 가까이 디비 튜닝, 특히 SQL서버 튜닝에 대한 관련 자료들을 뒤적거려서 성공적으로 튜닝을 마

쳤습니다."

라고 적어 주신거군요. 그냥 달래 놓았으니 CPU가 100%를 쳐도 된다는 논리와 그것이 버그였다고 하신건

제가 이해하기 힘듭니다.

간단히 줄여 말씀 드리면

"그러니까 지훈님 말씀은 SQL 서버의 문제나 버그가 아니다"란 거군요.

잘 알겠습니다.
--------------------------------------------------------------------------------------------------
그러면, 코난님이 말씀하신 다른 이슈들에 대해 제 의견을 드리지요.
"만든 업체의 디자인 컨셉과 설계 철학이 틀리기 때문입니다."
코난님이 예제까지 들어가며 친절하게 설명하시기를, 오라클과 마이크로소프트가 선택한 방법의 차이라고 하셨는
데요. 저도 SQL 서버가 그렇게 한 것은 말씀하신 것처럼 성능과 리소스의 문제 때문일 것이라고 짐작합니다.
그런데 성능을 위해 이렇게 만들었다, 그러면 모든 문제와 혼란에 대한 답이 되는 것입니까?
짜짜로니와 사천짜장을 예로 드셨는데, 저는 좀 더 과격한 예를 들어보지요.
새로 나온 라면을 사먹었는데, 먹다 보니 면발이 밀가루가 아니라 횟가루로 만든 겁니다.
그 사실을 알고 항의를 하면 그 업체나 그 라면을 좋아하는 매니아분들이 이렇게 항변을 합니다.
횟가루로 만든 라면에도 충분한 영양이 있고 나름대로의 장점이 있다, 그리고 그 사실을 모르고 먹은 니가 잘못이
다. 이 업계에는 표준과 상식이 있습니다. 물론 제품에는 당연히 업체의 컨셉과 철학이 적용되게 마련입니다.
그래서 그만큼 어떤 부분에서는 더 최적화되거나 간혹은 더 나빠질 수도 있겠지요. 그런데 문제는 표준, 혹은 업
계에서 표준에 준한다고 일반적으로 생각되는 상식에 대한 준수 여부입니다. 트랜잭션의 ACID 개념에 대해서는 관계
형 디비를 다루는 이 IT 업계의 대부분의 사람들이 생각하는 상식이 있습니다.
그리고 상식 뿐만 아니라 X/Open에서 정한 표준도 있습니다. 제가 마이크로소프트의 철학을 몰라서 버그가 아닌
것을 버그라고 말한 것입니까? 물론 그렇습니다. 그런데 그게 제 잘못입니까? 아닙니다. 대학이든 다른 교육기관이
든 전산관련의 교육을 받은 사람이면 기본적으로 배우는 과정중에 트랜잭션이 빠지지 않습니다. 거기서 ACID는 당연
히 등장합니다. 그리고 대부분의 SQL 입문서에서도 ACID를 언급합니다. 왜 정규 혹은 비정규 교육과정에서 꼭 언급
합니까? 기본이기 때문입니다. 기본은 무엇입니까? 다른 모든 중고급 기술 지식의 기초에 있고 또 다른 기술들을 습득
하는 데 바탕이 되기 때문입니다. 저는 방금 표준과 기본을 얘기했습니다. ACID 원칙은 표준임과 동시에 기본이기도
합니다. 그래서 저는 기본과 표준을 알고 있는 대로 MS SQL을 사용했습니다. 그리고 문제가 발생했습니다. 누구 책
임입니까? 그러면 마이크로소프트가 이런 표준을 몰라서 지키지 않은 것입니까? 당연히 아니겠지요.
말씀하신 대로 마이크로소프트가 생각하는 디자인 컨셉과 설계 철학에 따라 의도적으로 지키지 않은 것입니다.
만약 코난님이나, 혹은 위의 김상욱님(한마디 하기 위해 친히 가입까지 하셨다는)께서 제가 몰라서 그런 것이고
공부를 하지 않은 제가 잘못한 것이라고 한다면 더 할 말이 없어지겠군요. 마이크로소프트의 기본 디자인 개념과
철학이 그렇다는 것이라면, 저도 한수 배웠으니까 이제는 알겠습니다. 그리고 SET XACT_ABORT ON 설정이라도 만
들어주어서 마이크로소프트에 참 황공합니다.
--------------------------------------------------------------------------------------------------

실례합니다만 누가 SQL서버는 ACID를 지원 안한다고 한건가요? 누가 표준을 안 지킨다고 한겁니까?

왜 제가 그런 거짓말을 했다고 하시는 건지요? 확인해 보니

--------------------------------------------------------------------------------------------------
못된똥 - 2004/11/18 19:42
SQL 서버는 기본적으로  트랜잭션의 속성(ACID) 중 원자성을 지원하지 않습니다.
....
--------------------------------------------------------------------------------------------------
못된똥님의 말씀중 이부분이 잘못된겁니다. 아마도 이 댓글에 달린 내용을

지훈님은 제가 쓴걸로 오해 하셨나 봅니다.

단편적인 지식의 출처를 잘못 알고 계시네요. 트랜젝션 진입 포인트라고 까지 계속 이야기 했는데

설마 그걸 지원 안한다는 말로 들으신 건지요?

제가 드린 샘플 자료 봐 보십시요.

SET XACT_ABORT ON 옵션 전의 구문을 봐 주십시요. IF 구문으로 체크하는 구문 있지요?

그구문입니다. SET XACT_ABORT ON 옵션 있습니까?

이런 형태가 바로 어플리케이션이나 대부분의 DBMS가 쓰는 방식입니다.

SET XACT_ABORT ON 모르셔도 됩니다. 이건 사실 분산 트렌젝션이나 런타임(주로 외부모듈), 에러 리턴이

필요 없을 경우에 사용되며 세션 단위 사용이라서 사실상 거의 사용 안합니다. 보통 개발자 분들은

에러 메세지 리턴을 위해 위의 방법을 더 선호하시죠.

혹시나 위 내용을 알고 계셨다고 하면 하나만 부탁 드립니다.

누군가가 지훈님을 위해 시간을 할애해 장문의 글을 적어 주면 대충 보고 넘어가서

또 다른데 가서 잘못된 이야기로 논지를 펴시니 정말 제 속이 다 상합니다.

제가 쓴 글은 이겁니다.


"설마 SET XACT_ABORT ON 이슈는 아니겠지...
설마... 그래도 사이트 주인장님에 프로그래밍 경력이 있지..."
지금 제 솔직한 심정은 트렌젝션에서 ACID는 기본 상식인걸 아신다는게 다행이라고 생각 합니다.


이게 제가 쓴 내용입니다. "SET XACT_ABORT ON 이슈" 이슈가 뭔가요?

이런 잘못된 트랜젝션 처리 구문 사용하는 이슈를 말합니다.

그럼 이제 SQL서버는 표준을 지킨다는것 감 잡히십니까?

이제 답변이 되셨습니까?

제가 오라클을 힘들게 트렌젝션, 잠금까지 예를든건 컨셉의 차이를 말씀 드린겁니다.

Microsoft SQL 서버의 AutoCommit 기능을 쿼리와 옵션을 이용해 오라클측에서도 역시 비슷한 처리가 가능합니다.

Microsoft SQL 서버 SET 옵션으로 오라클측 IMPLICIT TRANSACTION을 구현 가능합니다.

개인적으로 SQL서버, 오라클, DB2, 사이베이스에 대한 경험이 있습니다. 넷중 가장 이질적인게 뭔지 아십니까?

가장 이질적인 DBMS는 Oracle입니다. 그리고 그다음이 DB2. ANSI SQL 최초 표준이 DB2에서 나왔는데 우습죠?

Microsoft SQL 서버와 Sybase ASE가 가장 표준을 잘 따릅니다.
--------------------------------------------------------------------------------------------------
그런데, 사소한 것도 아니고 에러 상황에서 치명적일 수도 있는 이런 중요한 '철학'이 왜 충분히 공지되지 않고
있습니까? "기본 설정 상태에서 트랜잭션 중에 에러가 날 경우 이미 인서트된 데이터는 삭제되지 않는다" 이런 내용
을 SQL 서버를 사용하기 시작하는 입문자가 '혹 그런 황당한 설정이 있나' 하고 찾아봐야 하는 것이 아니라, 굳이 찾
아보지 않아도 처음 사용하기 시작할 때 바로 알 수 있게 되어있어야 하지 않습니까? 표준을 어긴 것은 마이크로소프
트이기 때문에 그런 사실을 충분히 공지할 책임도 마이크로소프트에게 있는 것 아닙니까?
--------------------------------------------------------------------------------------------------

아래글에서 함께 설명 드려도 될지요?

--------------------------------------------------------------------------------------------------
비용을 들여 제품을 구입한 소비자의 입장에서 각 RDBMS마다 그런 기본을 벗어나는 특성이 있는지 걱정을 하면서
써야 하는 겁니까?  SQL에 대한 기본부터 해서 인덱스, 트랜잭션과 잠금, 전부 다시 공부해야 당연한 겁니까?
혹시 이 질문에 '네'라고 말하는 분이 이 글을 보고 계십니까? 그런 분이 엔지니어시라면, 평생 공부만 하다가 죽
을 겁니다.혹 엔지니어가 평생 공부만 하는 것이 당연하다고 생각하시는 분이 계시다면, 그러면 도대체 개발은 언제
하고 자기 생활은 언제 찾느냐고 물어보고 싶습니다. 엔지니어의 정의가 평생 공부만 하는 사람입니까?
물론 오라클도 특성이 있고 DB2도 나름의 철학이 있겠습니다. 하지만 크리티컬할 수 있는 부분에서 표준과는 다르
게 만들어놓고 그렇게 한 것이 우리 설계 철학이니 모르는 소비자가 잘못이라고 하지는 않습니다.
그런데도 제가 SQL 서버라는 제품을 탓하는 것이 잘못입니까?
--------------------------------------------------------------------------------------------------

이 글에 대한 생각은 맨 마지막에 적겠습니다. 저도 한때 많이 고민했던 정체성의 문제라서요...

--------------------------------------------------------------------------------------------------
얘기가 나왔으니 계속해보지요. 먼저 역시 SQL 서버에 대한 문제입니다. 클러스터 인덱스라는 넘 말입니다.
이거 아주 웃기는 넘이더군요. 클러스터 인덱스라는 것은 물리적인 레코드 데이터에 연결되어 있어서 이걸 걸었다
가 중간에 레코드가 삽입되면 그 이후의 모든 물리적 데이터가 다 시프트된다고요. 그리고 별도 지정을 하지 않는
한, PK 필드는 이 클러스터 인덱스가 기본으로 잡혀버린다고요. 이게 무슨 뜻입니까? 고객 데이터를 주민번호를
키로 테이블로 저장한 상태에서 새 고객이 등록되면 새 주민번호가 인서트되죠. 그러면 그 주민번호보다 이후의 번호
들은 모조리 디스크상에서 이동됩니다. 최악의 경우에, 100만명의 고객이 있는데 1940년생의 새 고객이 인서트되면,
그 테이블의 대부분의 데이터가 디스크상에서 읽혀진 후 새로 씌여집니다. 이런 상황은 드문 경우가 아닙니다. 굳이
주민번호가 아니더라도 이런 경우는 흔합니다. 클러스터 인덱스가 효율적이려면 그 필드는 항상 기존의 데이터보다
증가만 하는 데이터, 즉 일련번호와 같은 경우만 가능합니다. 디스크상에서 100만건 이상이 한번에 이동되면, 당연히
그 테이블은 락이 걸리겠지요. 그 테이블의 데이터를 요구하는 다른 쿼리 동작들은 느려지거나 대기하게 됩니다. 전
체 성능에 엄청난 영향이 있는 겁니다. 제가 튜닝하던 도중에도 초당 수십, 수백번 인서트되는 테이블에 클러스터 인
덱스가 설정된 걸 봤습니다. 하루에 두세번씩 멈추던 데이터베이스 서버가 클러스터 인덱스를 넌클러스터로 바꾸니
까 쌩쌩하게 돌아가더군요. 그러면 제가, 클러스터 인덱스 외에 다른 RDB의 그냥 인덱스에 해당하는 넌클러스터 인덱
스를 선택할 수 있도록 배려해준마이크로소프트에 감사해야 합니까? 아닙니다. 다른 RDB가 하는 대로 기본 상태는 넌
클러스터로 하고 DBA의 선택으로 클러스터 인덱스를 선택할 수 있어야 당연한 겁니다.
--------------------------------------------------------------------------------------------------

제가 알고있는 사실을 말씀 드리겠습니다.

설명 : SQL서버는 페이지라는 8K단위 저장소 블럭으로 구성됩니다.

데이터 페이지가 죽 나열되 있습니다. 물리적으로 행을 재 배열(Clustered Index 생성)하면 이 페이지에

무슨일이 생기는가? 페이지가 서로서로 링크드리스트(C하시니 부연설명 안함) 처럼 양방향 노드를 포인팅 하게

됩니다.

자. 데이터가 삭제 되어서 페이지가 필요가 없습니다.

지훈님이 좋아하는 수치인 백만, 즉 1,000,000개의 페이지가 있다고 합시다.

1,000,000개중 앞에서 10번째 페이지가 삭제 되었습니다. 나머지 999,990개의 페이지

8KByte * 999,990 = 7,999,920 KByte = 7812 MByte = 일정 수량 삭제마다 대략 8기가의 데이터가

이동하게 되는 겁니까?

사실 : Clustered Index를 가진 인덱스의 데이터 변경시 양방향을 연결하고 있는 포인터가 다음 순서가 되어야 하

는 페이지를 포인팅하게 됩니다. 데이터가 바뀌는게 아니라 포인팅하는 부분만 바뀌는 겁니다.

지훈님 말처럼 삭제가 되어서 페이지가 빠지면 그 앞과 뒤 페이지의 포인터가 바뀌며

순수하게 페이지 처리를 위해 발생하는 IO는 8KByte * 2개 페이지 만큼의 IO가 발생합니다.

간단히 각 페이지의 96Byte 크기의 페이지 헤더에 포함되어 잇는 nextPage열과 prevPage열을 수정합니다.


데이터 페이지의 위치까지 재배열 시키는 작업은

1. Clustered Index를 처음 생성할 경우

2. DBCC DBREINDEX 를 수행할 경우

3. 매우 특수한 환경에서 거의 발생하지 않는 꽤 높은 수치의 Fragmentation이 발생할 경우(나도 본적 없음)

위 3번의 경우는 거의 본적 없습니다. 대부분의 분들이 스케쥴로

DBCC DBREINDEX나 DBCC INDEXDEFRAG를 하실테니까요.


지훈님 시스템의 특정 중요 테이블이 지금 Clustered Index가 없는 상태군요. 힙이라고 하죠.

말씀 주신대로 중요한 테이블이 힙이면 또 체크해야할 사항이 많습니다.

Clustered Index를 Non-Clustered index로 바꾸고 잘 되었다면 그렇게 쓰세요.

제 생각엔 테이블내 컬럼이 varchar 같은 가변자료형이 많거나 많은 삽입과 함께 조회가 되니

간단한 SELECT 구문의 잠금 처리 고려, 너무 많은 인덱스 생성 여부, Clustered Index의 키 크기가 너무 큰지 확

인 등등을 해야 할듯 하네요.

--------------------------------------------------------------------------------------------------
그리고 별도 지정을 하지 않는 한, PK 필드는 이 클러스터 인덱스가 기본으로 잡혀버린다고요. 이게 무슨 뜻입니
까? 그런데도 왜 이 클러스터 인덱스 설정이 기본으로 되어있습니까? 꼭 고객이 클러스터 인덱스라는 넘이 그런 것이
라는 것을 공부해서 SQL 서버의 철학에 굴복해야 합니까? 이 업계에는 마이크로소프트의 독단적인 철학 외에 대부분
의 구성원들이 동의하는 상식과 표준이 있습니다. 그걸 위반하고 철학과 설계탓을 하는 마이크로소프트에 제가 호의
적이어야 할 이유가 있습니까? 소비자가 표준과 상식을 지키지 않는 제품에 당황하는 것이 이상합니까?
--------------------------------------------------------------------------------------------------

저도 여쭤보겠습니다.

짜짜로니를 태어나서 처음 끓일때 어떻게 끓였습니까? 일반 신라면처럼 물 넣고 끓이다가 스프 넣고 끓입니까?

중간에 물을 면발이 잠길락~ 말락~(가장 중요한 튜닝 포인트) 할때까지 남겨두고 스프들을 넣고

물을 졸이면서 끓입니다.

짜짜로니 처음 끓일때 어떻게 끓였습니까? 라면 뒤 설명서 안 보시는지요?

내가 만들 인덱스가 뭔지 알고 싶을때 그게 PK의 기본 옵션으로 뭐가 생기는지도 모르고 진행 하시나요?

테이블 설계의 아주 중요한 부분을 차지하는 PK 생성을 그렇게 생각없이 생성하고 나중에 알고나서

SQL서버 문제라고 "이런 젠장~" 하시는 것인지요?

그럼 좀 물읍시다. SQL서버나 오라클, DB2, 사이베이스 등등 어떤건 PK 생성시 Clustered고

어떤건 non-clustered다?

제가 아는 대로라면 하나만 예를 들어도 오라클엔 아예 clustered, non-clustered index 라는 용어가 없습니다.

억지로라도 SQL서버와 매핑 시키면 Clustered Index는 IOT개념(Cluster), non-clustered Index는

그냥 Index라고 호칭하며

오라클의 인덱스 종류? 대충 생각나는 것만 말해볼까요?

Bitmap, Parallel, Compress, Function(?정확하지않음), Partitioned(Hash, Composite),

이렇게나 종류가 많습니다.

--------------------------------------------------------------------------------------------------
이번에는 개발툴인 비주얼 C++을 예로 듭시다.
비주얼 C++이 6.0 버전에 이르기까지  표준을 따르지 않았다는 것은 주지의 사실입니다.
--------------------------------------------------------------------------------------------------

제 생각엔 악성 루머인듯 합니다.

만약 이 내용의 출처가 볼랜드사라면 한국 볼랜드는 믿을만한 답변을 해줘야 한다고 생각 합니다.

저 SQL서버 엔지니어입니다. C++은 소켓 프로그래밍 정도 까지만 대학때 해봤고 지금

머리속에 C관련해 담고 다니는건 DB-Lib 뿐입니다.


지훈님께 묻습니다.

1. ANSI/ISO C++ 표준안 나온게 언제입니까?

2. Microsoft Visual Studio 6.0 나온게 언제 입니까?

3. 저도 이제 곧 아이를 가지려고 하는데요 태어나지도 않은, 아니 생기지도 않은 아이에게 너 왜 아빠 안닮았어?

    아빠는 장동건 얼굴인데 넌 왜 옥동자 얼굴이야? 이렇게 아이를 구박할 수 있습니까?(옥동자님께 죄송합니다.)


사실 : Microsoft Visual Studio 6.0 이 릴리즈 된 후 ANSI/ISO C++ 표준안이 나왔습니다.

--------------------------------------------------------------------------------------------------
이번에는 개발툴인 비주얼 C++을 예로 듭시다.
비주얼 C++이 6.0 버전에 이르기까지  표준을 따르지 않았다는 것은 주지의 사실입니다.
--------------------------------------------------------------------------------------------------

6.0 버젼에 이르기까지 C++표준이 없었는데 어떻게 표준을 따를 수 있습니까?

말씀대로라면 6.0 버젼에서는 표준을 따랐다는 말인데 나오지도 않은걸로 어떻게 비교합니까?

제 생각엔 좀 심한 악성 루머라고 생각이 되네요.

--------------------------------------------------------------------------------------------------
상황에 따라 민감할 수도 있는 키워드들을 여러가지로 재정의해놓았지요. 마이크로소프트가 C++ 언어에 표준이 있
다는 것을 몰라서 그랬습니까? 마이크로소프트라는 회사는 원래 상식과 표준을 잘 무시하고 독자적인 철학을 주장하
길 즐긴다는 것을 모르는 소비자가 죄인입니까? (닷넷 버전에 가서는 비주얼 C++의 표준 준수성을 높였다고 강조하더
군요. 그동안 그토록 비난을 받으면서도 오랫동안 표준을 무시해왔던 마이크로소프트가 갑자기 왜 표준을 들먹이는
지 첨에는 의아했는데, 그럴만한 이유들이 있겠더군요)
--------------------------------------------------------------------------------------------------

표준 무시라... 저나 이글을 보시는 많은 분들이 뭐가 표준이고 뭐가 표준이 아닌지도 잘 모릅니다.


자 지훈님께 질문 요청 하나 하겠습니다.

지훈님이 아는 양측이 어디가 얼만큼 표준을 잘 지키는지 조목 조목 아시는 것만이라도 좀 적어 주세요.

Visual C++가 뭘 안지키는 지도 아는것만 이라도 적어 주세요.

그리고 저도 Borland C++ Builder의 몇가지 기능과 개발, 유지비 관련해 궁금한게 있었는데

나중에 같이 해서 질문좀 올리겠습니다.

--------------------------------------------------------------------------------------------------
커뮤니티 운영자로서 코난님은 존경스러운 분입니다. 규모있는 커뮤니티 운영이 얼마나 어려운지 저도 잘 아니까
요. 하지만 표준과 상식을 무시하는 마이크로소프트의 독단적인 '설계 철학'에 대한 제 불만에 대답이 되지는 않는군
요.
--------------------------------------------------------------------------------------------------

...

예전에 말씀 주신 내용중에서 MySQL이야기 인데요..

MySQL은 트렌젝션 옛날에 지원했고 지금은 클러스터링도 지원합니다.

제 소견입니다.

문제가 생기면 단편적인 상황에러를 가지고 google.com에서 찾아서 적용합니다.

그리고 적용이 처음에 한두번 잘 되면 맹신해 버리죠. 자신의 시스템 디자인과 구현방식, 운용 방식이 모두가 다

틀린데 그냥 단편적인 상황 에러를 가지고 단편적인 검증 안된 웹상의 지식을 맞춥니다.

그러고도 안되면 많은 분들은 그냥 SQL서버 문제라고 우선 못을 받아 버리시지요....

SQL서버 문제다 싶으면 먼저 만든 회사에 문의하면 되지 않을까요?

Microsoft의 QFE라는 서비스가 있습니다.

24 * 7 고객지원 서비스도 있습니다.

혹시 문제 발생을 고려해 SQL서버 CD 뒤에 있는 서비스 센터 대표 전화번호를 서버 옆에 메모해 두고 있습니까?

예를들어 만약 문제가 정말 SQL서버의 버그이고 QFE가 필요하다면 Mircrosoft 돈 안받습니다.

라이센싱에 문제가 있어서 어디 물어보기 힘들면 SQLER에라도 물어 보시면 되지 않을까요?


최대한 지훈님에게 경어를 쓰고 존대를 하려고 노력 했습니다.

부족한 부분이, 미진한 답변이, 제가 틀린말을 했다면 지훈님 생각을 서슴 없이 말씀 주십시요.


정말 잘 만들었다고 생각하는 Microsoft SQL 서버가 이렇게 취급당할 수도 있다는 사실이 안타깝습니다.

- 이상 기술 관련 반론 마칩니다.


아래 이글 기억 나십니까?

--------------------------------------------------------------------------------------------------
비용을 들여 제품을 구입한 소비자의 입장에서 각 RDBMS마다 그런 기본을 벗어나는 특성이 있는지 걱정을 하면서
써야 하는 겁니까?  SQL에 대한 기본부터 해서 인덱스, 트랜잭션과 잠금, 전부 다시 공부해야 당연한 겁니까?
혹시 이 질문에 '네'라고 말하는 분이 이 글을 보고 계십니까? 그런 분이 엔지니어시라면, 평생 공부만 하다가 죽
을 겁니다.혹 엔지니어가 평생 공부만 하는 것이 당연하다고 생각하시는 분이 계시다면, 그러면 도대체 개발은 언제
하고 자기 생활은 언제 찾느냐고 물어보고 싶습니다. 엔지니어의 정의가 평생 공부만 하는 사람입니까? 물론 오라클도
특성이 있고 DB2도 나름의 철학이 있겠습니다. 하지만 크리티컬할 수 있는 부분에서 표준과는 다르게 만들어놓고 그
렇게 한 것이 우리 설계 철학이니 모르는 소비자가 잘못이라고 하지는 않습니다. 그런데도 제가 SQL 서버라는 제품을
탓하는 것이 잘못입니까?
--------------------------------------------------------------------------------------------------

이 글을 보고 생각난겁니다. 몇분이나 보실지 모르겠지만...  저역시 한때 무척이나 고민했던 글입니다.

항상 제 자신과 제 주변의 많은 개발자 분들의 정체성에 대해서 말씀 드리고 싶었습니다.

앞부분은 기고를 해달라는 부탁을 받고 3년 정도 전에 적어 두었던 업계 전반에 대한 가상의 글입니다.

뒤에는 제가 요즘에 정리해둔 제 글이 있구요.

모쪼록 많은 개발자 분들께 도움 되시면 좋겠습니다.

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

개발자들은 매일매일 너무 바쁩니다.

개발일 해야죠, 시스템 테스트 해야죠.

매일매일 하루가 멀다하고 나오는 새로운 기술들을 배워야 하죠,

클라이언트 요청 들어오면 하던일 멈추고 해줘야죠, 전화도 받아야죠, 기술지원 나가야 되죠,

출장도 가끔 나가야 되죠, 혼자 하시는 분이면 수주부터 수금까지 하실 겁니다.

개발일 하다가 문제가 생기면 문제 해결 하기 위해서 가뜩이나 짧은 프로젝트 기간

작업시간 더 짧아지고 야간 근무 시간만 늘어납니다. 예전에 해놨던 기술에 문제가 생기면

예전 기술의 해당 분야를 다시 공부해야 하고 새로운 기술로 프로젝트를 시작하니 새로운 기술을

일정 수준까지 공부해 놔야 합니다.

정말 바쁩니다.

나름대로 일을 열심히 하는 것 같아도 돈은 정말 안들어 옵니다.

대기업의 개발실이나 운영팀이 아닌이상 돈도 시원치 않고 회사내 복지 수준도 사실상

기대하기 힘듭니다.

그뿐입니까...

우리 개발자들 새로운 기술 공부하고 회사일 정말 열심히 하지만 돈에는 쥐약입니다.

작은 10명 ~ 20명 이하의 벤쳐회사...  우리 개발자가 꿈꾸고 믿는건 우리 회사 말그대로

"대박" 터지는 겁니다. 윗분 말씀대로 우리 회사 대박 터지면 우리 골고루 나눠 가지고

정말 제대로 살아 보자는 한마디에 오늘도 철야에 야간 작업 자청합니다.

월급 한두달 밀려도 대박만 믿으며 오늘도 힘냅니다.

네... 웬일입니까... 정말 대박이 터졌습니다. 회사 팀원들 얼굴에 웃음꽃이 피었습니다.

그런데 이상합니다. 부장장급 이상 몇명만 돈 많이 받았다는 소문입니다.

사실확인을 해 보니 계약상에 "대박"의 구문이 어색합니다.

"대박"의 기준이 모호합니다. 한달에 몇억이 터져야 "대박"이라 한다는 말도 안되는 조건입니다.

모호한 계약으로 피해를 봅니다. 하얗게 밤을 지세우며 불편 한마디 없이 "대박"만 꿈꾸었는데...

회사에 이런분 계실겁니다. IT업계 기술 전반을 두루두루 섭렵하고 있으며

회사내 업무와 관련된 일에 대해서는 "걸어다니는 도움말 화일"입니다. 누구보다 열심히 하죠.

심지어는 전혀 다른 일을 하는 옆 부서에서 일을 물어보러 와도 척척~ 답해 줍니다. 놀랍죠?

그런데 재밌는건 "어제 한일전 재미있었다" 라고 하면 "그래 몇대 몇이야?"로 반문하거나

"어제 환율이 XXX로 떨어 졌다고 하네요. 큰일이네..." 그러면 "그래? 환율 떨어지면 왜 큰일이야?"

네... 이런분 한분씩 꼭 계실겁니다.

정말 프로그래밍 잘하시는 분은 개발 작업만 몰두 하지 이런 경제나 돈에는 특히 약하죠.

사실 이런분이 더 많이 받아야 하는데 더 많이 받는건 코딩은 전혀 모르는 비전문가거나

낙하산 타고 떨어진 팀장일 경우가 많습니다. ㅋㅋㅋ

설계간 바빠 죽겠는데 말도 안되는 기술을 들고나와 "이렇게 하면 된다." 라고

이빨까고 우기면서 상세한 계획을 세워  가뜩이나 바쁜 프로젝트 설계 단계를 실컷 까먹게 됩니다.

시간만 까먹습니까? 서버나 솔루션, 개발툴을 잘못 구매해서 엄청난 비용 낭비도 하게 됩니다.

고생끝에 시스템을 결국 구현해도 개발자와 운영자가 서로 책임만 전가하다가 쫑나버린 회사도

여럿 봤습니다.

"하드웨어보다(장비와 자재) 소프트웨어(사람과 기술교육)에 투자하라"

성공하는 회사는 어딜가도 팀내 세미나, 팀원간 커뮤니케이션, 교육시간도 업무시간으로 반영

합니다. 대기업들이 특히 이런걸 잘하죠.


문제는 또 산적해 있습니다. 업계 인력 불균형도 문제 입니다.

지금은 그대로 덜하지만 전문 IT 학원에서 교육을 막 이수받은 후 업계에 뛰어드는

그런 분들이 넘쳐납니다. 정부의 잘못된 시책과 미디어의 "청년 벤쳐 사장" 광고를 통한 "인생한방" 주의로

뛰어드는 분들도 많습니다.

이렇게 과도한 인력 불균형이 이루어지면서 윗분들은 한명을 고용할때 비용 때문에

이런 막 IT에 입문한 초급 인력을 쓰게됩니다. 초급 인력이 나쁘다는건 아닙니다.

그러면서 IT업계에 존재하는 사람들은 99년부터 2000년정도 까지 "제값받고" 일하던 분이 점점 더 그 희소 가치를

잃어가게 됩니다.

"쟤는 한달에 100부르는데 넌 왜 200이냐? 우리 좀 깎자..."

100만원짜리를 데려와서 일 시켜 보십시요... 일이 되나... 가르치는 비용이 더 들어가죠...

차라리 200짜리를 뽑아서 바로 일에 투입하는게 싸게 먹힙니다.

100만원 짜리 인력이라고 무시하는건 절대 아닙니다. 병특처럼 욕은 욕대로 먹고 월 20만원도 못받는 것보단 낫죠

.

그리고 알만한 사람들은 이런 "검증 안된 인력"에 대해 면접 자체가 워낙 기술 면접이 타이트 해서

웬만해선 회사의 조건에 맞는 사람 구하기도 쉽지 않죠.

또 다른 입장에서 회사의 입장에서 본다면 또 열정보고 신입 신규 뽑았는데 한 회사에 오래 있지 않으려 합니다.

조금 키워서 이제 써먹을만~ 하면 좀 큰회사로 이직하거나 다른 경쟁 업체로 나가죠.

업계와 인력 사용에 대한 관행, 그리고 정부시책 이 세가지가 문제를 안고 있는 겁니다.


그뿐입니까... 공기업의 꽤 큼직한 프로젝트 입찰에 10원 입찰 사건.

인력과 회사는 넘치고 일은 없는 수급 불균형 상태.

이런 상황에서 큰건 공개 입찰이 있습니다. 싸게 적어야 프로젝트를 딸 수 있는 상황

어떻게라도 상대보다 일을 많이 따기 위해 업계 수준에 안맞는 가격으로 후려 칩니다.

그렇게 후려 치기 하다가 결국은 10원 입찰까지 나왔죠. (0원 입찰은 불법입니다.)

이런일이 비일비재하니 정부시책으로 최하입찰 금액을 쓰게 해도 결과는 마찬가지죠.


대기업 SI업체의 입찰

그뿐입니까 일이 안되니 이런 일도 벌어집니다. 대기업에서 운영하는 SI업체는 어떤지 아십니까?

대기업 SI업체가 돈도 얼마 안되는 업계 은어로 "코묻은"(대기업에 비하면) 프로젝트에 입찰 합니다.

대기업도 일이 없으니 어쩔 수 없는 겁니다.

당신이 사장이면 공개 입찰때 누구 뽑겠습니까? 이왕이면 대기업 SI업체 뽑습니다.

그럼 대기업 SI업체 예를들면 1,000만원 챙깁니다. 그럼 그회사 정식 직원이 나가서 일합니까?

아니요. 중형 정도 되는 SI업체에 선금 500 떼고 중형 업체에 보냅니다.

중형 업체는 어떻습니까? 500남은거의 300떼고 200주고 프리로 뛰는 우리같은 사람 보냅니다.

1,000만원 짜리 프로젝트가 200만원 짜리 프로젝트로 순식간에 바뀌는 겁니다.

이렇게 외주 관리만 대형 SI업체에서는 한사람이 많게는 20여개도 관리합니다.

좋습니다.

이제 진풍경이 벌어집니다.

프로젝트 진행 중입니다. 비지니스 프로세스 분석 하는데 단계 건너야 하는게

장난 아닙니다. 뭐 하나 물어 보려면 창구가 없거나 3계단중 1계단이 비어 있어서

뭐하나 확인도 잘 안되고 확인이 되어도 최초 문의 사항과 전혀 다른 동문 서답이 전달됩니다.


이건 약과죠.

진풍경의 날입니다. 프로젝트 검수일이 되어서 사장, 대형 SI업체 담당자, 중형 SI업체 담당자, 우리같은 개발자.

검수일이 되면 이제 난리가 납니다. 왜 솔루션이 안나오는 거냐고...

우리 개발자 정말 밤 꼬박 세워 열심히 했습니다. 이렇게 다 모인 자리에서 몇마디 자신을 변호해 봅니다.

중대형 SI업체 인력 관리자는 이런 상황에 매우 익숙하고 잘 대응하기 때문에 그런 자리에서

인력을 관리 하라고 뽑힌 사람들입니다. 우리네 개발자들과 말빨과 이빨이 비교가 됩니까?

결국 모든 문제의 근원은 말도 잘 못하고 자신을 대변하지도 못하는

우리 개발자의 문제가 됩니다.

이런 프로젝트의 문제는 진정 누구의 문제 입니까?

최근 대기업 SI업체 중소형 프로젝트 입찰 금지가 법으로 제정 되었습니다.

그래도 이런 프로젝트 입찰고 수주의 구조적인 문제는 여전하죠...

가뜩이나 적은 프로젝트 비용이 중간에 새고 새서 결국엔 허공만 잡는 겁니다.

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

이건 업계 이야기 기고글이 아니라 제 주변의 이야기 입니다.

얼마전 SQLER의 심은하 닮았다고 늘 자학(ㅋㅋㅋ)하는 아리따운 여성 회원 한분의

재즈 댄스 발표회였습니다. 덕분에 축하 해줄겸 겸사겸사 모임 분들도 만났죠.

이 모임에 아주 반가운 한분이 오래간만에 나오셨죠.

구수~한 입담과 둥글둥글한 아주 좋은 성격의... 저처럼 부족한 동생 챙겨주시고

조언도 해 주시는 형입니다.

얼마전까지 마눌님 몰래 "최신형 PDA핸드폰"를 구매하고 일주일간

냉전중이라는 허허웃음과 함께 와 주셨죠... 1년 정도만에 뵙게 되었어요. 왜 1년만인가요?

이 좋은 형은 1년 전까지 작은 웹개발 업체의 사장이였습니다. 그러다 갑자기

자유게시판에 폭탄 선언을 하고 업계를 뜨셨죠.


1년 전에 이 형이 쓴 폭탄글 입니다.
--------------------------------------------------------------------------------------------------
힘든 결정을 하게 되었네요....
정말 힘들었다면 힘들었고.. 즐거웠다면 즐거웠던 6년..
...
그동안 웹플해오면서 내가 만든 사이트 유저들이 좋아하면 같이 행복해 하고..
광고주가 GX하면 혼자 맘상해 하고 씁쓸하기도 하고 그랬지만..
이젠 떠나야 할듯 해요 ㅎㅎㅎ
남은것은 망가진 몸땡이와 절망뿐 ...
당분간 아무생각없이 와이프와 사랑하는 딸내미와 여행이나 다니려고 합니다.
플그래머도 접으려니 아쉬움이 많이 남네요..
하고 싶었던것 다 이루지 못하고 떠나니 말이죠..
나의 꿈은 정말 모든 사람들이 다 행복하게 이용할수 있는 웹사이트 만들어보는것 이었는데...
지금은 경기도 안좋고 인터넷 사업이나 IT를 보는 시각이 차갑지만..
...
(사이트 만드는데 200만원 이상 쓰면 빙신소리 듣는답니다. ㅋㅋㅋㅋ)
그리고 이쪽 계통에 일하는 사람들 우습게 보긴 하지만 (6년차 연봉으로 2400 제시하더군요 ㅋㅋㅋ)...
언젠간 좋아지겠죠.
다른분들 열심히 하셔서 나중에 환히 웃는 사람들이 되세요
비록 떠나지만 심심하믄 가끔씩 들러서 여러분들 안부도 묻고 헛소리두 하구 그랄께요 ㅋㅋㅋ
다들 즐SQL 하세연~~ ^_^//
--------------------------------------------------------------------------------------------------

그렇게 떠난 형이였지만 1년만에 바로 며칠 전에 돌아 오셨죠.

이번엔 리눅쪽 회사에서 MySQL 작업 하신다네요. 전혀 틀린 분야... ASP, COM+, MSSQL하시다가

리눅스 하신다니 역시 개발자는 개발자인가 봅니다. ㅎㅎㅎ


우리의 미래.

이런말 있습니다. 사오정, 오륙도

사오정(45세면 정년), 오륙도(56세까지 일하면 도둑놈)

우리들 개발자의 정년은 몇입니까? 업계에선 35라고 하네요. 저도 몇년 안 남았습니다.

일이 힘들고 지쳐서 이제 개발 그만두고 관리직으로 가는 겁니까?

아니요. 꽃피는 봄이오면에서 탄광에서 일하는 용석이 아버지의 말이 기억납니다.

--------------------------------------------------------------------------------------------------
용석아버지
"내가 두려운게 뭔지 아쇼? 저놈(중학생 아들)이 다 클때까지 내가 옆에 있어 주는거요"
"꿈? 오랫만에 들어보네... 나도 꿈이 있었어. 막장(탄광광부) 인생이 내꿈은 아니었거든.
꿈꾼다고 다 이루어 집디까? 참 선생 결혼 했수?"

현우
"아직 총각입니다."

용석아버지
"결혼해서 나중에 애 낳아봐 허허"
...
"내 아들은 절대 (관악부에) 보낼 수 없네!"
--------------------------------------------------------------------------------------------------


우리가 잊어버린 것.

아주아주 옛날처럼 느껴 지실 겁니다. 기억나십니까?

바로 첫 코딩의 순간입니다. 기억나십니까? 처음 어떤 프로그램 언어를 쓰셨건 상관 없이

화면에 "Hello, World!"를 찍으셨던 그때 그 감동.

지금 진행중인 프로젝트가 너무나 힘들고 지쳤습니까?

이전 프로젝트를 끝내고 내가 만든 프로그램을 프러덕션 한후 팀원들 끼리 서로 수고했다는

바로 그 한마디.

그날 저녁에 팀원들이 모여 그간 있던 안좋았던일, 클레임 걸던 윗분들, 새로 들어와 배우며 일하느라

고생했던 막내, 개발쪽과 맞춰서 같이 고생하면서 밤세워 디자인 맞춰준 디자이너...

이사람들과 서로 수고했다고 격려하고 나누던 삽겹살과 참이슬을 나누면 그간 있었던 고생은 모두 지난일이고

고통의 순간들과 당황했던 순간들은 모두 즐거운 에피소드가 되지요.

그때를 기억해 내셨습니까? ^_^


지금 우리의 일을 즐겨보는게 어떨까요?

내일이 불안하고 두렵습니까?

내가 지금 왜 이일을 하는지 모르겠습니까?

매일 매일 배워도 끝이 없습니까?

새로운 기술, 새로운 방식의 프로그래밍이 두렵고 스트레스 받게 합니까?


처음 그순간, 프로젝트 프러덕션한 그날을 떠올려 보십시요.

이 일이 성공적으로 완료 되었을 그 순간을 생각해 보십시요.

우리 앞의 일들을 현실적으로 보십시요.

우리는 3D업종에 근무하는 사람들이 아닙니다.

지금 당장은 이 업계가 힘들어도 우리는 이길을 좋아 합니다.


*** 우리는 새로움을 창조하는 개발자 들이기 때문입니다. - 마침.




부족한 글 읽어 주셔서 감사합니다. 앞으로도 최선을 다하겠습니다.

==================================================
^___^     :>       :)       :=)      :}      ^}{^
==================================================
웃는 모습은 언제나 봐도 기분 좋게 만들죠~~~
우리모두 항상 웃는 얼굴로 살면 어떨까요~~~~

즐거운 하루가 되세요..

Happy Konan SQLER
http://www.sqler.pe.kr
sqler@chollian.net
==================================================


박지훈.임프 님이 쓰신 글 :
: 안녕하십니까. 코난님.
: 금요일이라 업무때문에 정신이 없는데, 친히 코난님께서 오셔서 한마디 해주시니 저도 시간을 내지 않을 수가 없네요.
: 저도 SQLER에 종종 들리는 사람입니다. 회원가입은 하지 않았지만 여러 강좌도 보고 검색도 해서 좋은 자료들 많이
: 참고하고 있답니다.
:
: 근본적으로 저희 시스템이 과부하로 허덕이는 이유는 물론 있습니다. 짐작하시는 대로 2번, 즉 잘못된 쿼리나 인덱스
: 때문입니다. 간단히 튜닝을 하면서 그런 부분은 대부분 파악했습니다. 그래서 제가 손을 댄 부분도 주로 인덱스 쪽이고요.
: 그런데 더 근본적으로 디비 구조 자체가 어그러진 부분이 많기 때문에, 전체 재개발이 필요한 상황입니다.
: 그러니까 튜닝을 했다고 하더라도 문제의 근원에 대한 수정이 된 것이 아니라 겨우 달래놓은 정도죠.
:
: 제가 입사하기 이전에 개발했던 외주 업체가 해놓은 일인데다 앞으로 두어달 정도는 재개발을 할 수 있는 상황이 아니기
: 때문에 그냥 달래놓고 쓰고 있습니다.
: 제가 튜닝을 했다고 말했던 것은 이정도의 상황을 말씀드린 겁니다. MS에서 툴로서나 문서로서 제공하는 방법들은 거의
: 빼놓지 않고 검토 혹은 적용을 했다고 할 수 있습니다. 물론 말씀하신 방법들도 이미 해보았습니다.
: 하지만 시간을 내셔서 좋은 조언들을 주신데 감사드립니다.
:
: 그러면, 코난님이 말씀하신 다른 이슈들에 대해 제 의견을 드리지요.
: "만든 업체의 디자인 컨셉과 설계 철학이 틀리기 때문입니다."
:
: 코난님이 예제까지 들어가며 친절하게 설명하시기를, 오라클과 마이크로소프트가 선택한 방법의 차이라고 하셨는데요.
: 저도 SQL 서버가 그렇게 한 것은 말씀하신 것처럼 성능과 리소스의 문제 때문일 것이라고 짐작합니다.
: 그런데 성능을 위해 이렇게 만들었다, 그러면 모든 문제와 혼란에 대한 답이 되는 것입니까?
:
: 짜짜로니와 사천짜장을 예로 드셨는데, 저는 좀 더 과격한 예를 들어보지요.
: 새로 나온 라면을 사먹었는데, 먹다 보니 면발이 밀가루가 아니라 횟가루로 만든 겁니다.
: 그 사실을 알고 항의를 하면 그 업체나 그 라면을 좋아하는 매니아분들이 이렇게 항변을 합니다.
: 횟가루로 만든 라면에도 충분한 영양이 있고 나름대로의 장점이 있다, 그리고 그 사실을 모르고 먹은 니가 잘못이다.
:
: 이 업계에는 표준과 상식이 있습니다. 물론 제품에는 당연히 업체의 컨셉과 철학이 적용되게 마련입니다.
: 그래서 그만큼 어떤 부분에서는 더 최적화되거나 간혹은 더 나빠질 수도 있겠지요.
: 그런데 문제는 표준, 혹은 업계에서 표준에 준한다고 일반적으로 생각되는 상식에 대한 준수 여부입니다.
:
: 트랜잭션의 ACID 개념에 대해서는 관계형 디비를 다루는 이 IT 업계의 대부분의 사람들이 생각하는 상식이 있습니다.
: 그리고 상식 뿐만 아니라 X/Open에서 정한 표준도 있습니다.
:
: 제가 마이크로소프트의 철학을 몰라서 버그가 아닌 것을 버그라고 말한 것입니까? 물론 그렇습니다.
: 그런데 그게 제 잘못입니까? 아닙니다.
:
: 대학이든 다른 교육기관이든 전산관련의 교육을 받은 사람이면 기본적으로 배우는 과정중에 트랜잭션이 빠지지 않습니다.
: 거기서 ACID는 당연히 등장합니다. 그리고 대부분의 SQL 입문서에서도 ACID를 언급합니다. 왜 정규 혹은 비정규
: 교육과정에서 꼭 언급합니까? 기본이기 때문입니다. 기본은 무엇입니까? 다른 모든 중고급 기술 지식의 기초에 있고
: 또 다른 기술들을 습득하는 데 바탕이 되기 때문입니다.
:
: 저는 방금 표준과 기본을 얘기했습니다. ACID 원칙은 표준임과 동시에 기본이기도 합니다.
: 그래서 저는 기본과 표준을 알고 있는 대로 MS SQL을 사용했습니다. 그리고 문제가 발생했습니다. 누구 책임입니까?
:
: 그러면 마이크로소프트가 이런 표준을 몰라서 지키지 않은 것입니까? 당연히 아니겠지요.
: 말씀하신 대로 마이크로소프트가 생각하는 디자인 컨셉과 설계 철학에 따라 의도적으로 지키지 않은 것입니다.
:
: 만약 코난님이나, 혹은 위의 김상욱님(한마디 하기 위해 친히 가입까지 하셨다는)께서 제가 몰라서 그런 것이고
: 공부를 하지 않은 제가 잘못한 것이라고 한다면 더 할 말이 없어지겠군요.
:
: 마이크로소프트의 기본 디자인 개념과 철학이 그렇다는 것이라면, 저도 한수 배웠으니까 이제는 알겠습니다.
: 그리고 SET XACT_ABORT ON 설정이라도 만들어주어서 마이크로소프트에 참 황공합니다.
:
: 그런데, 사소한 것도 아니고 에러 상황에서 치명적일 수도 있는 이런 중요한 '철학'이 왜 충분히 공지되지 않고 있습니까?
: "기본 설정 상태에서 트랜잭션 중에 에러가 날 경우 이미 인서트된 데이터는 삭제되지 않는다" 이런 내용을
: SQL 서버를 사용하기 시작하는 입문자가 '혹 그런 황당한 설정이 있나' 하고 찾아봐야 하는 것이 아니라, 굳이 찾아보지
: 않아도 처음 사용하기 시작할 때 바로 알 수 있게 되어있어야 하지 않습니까? 표준을 어긴 것은 마이크로소프트이기
: 때문에 그런 사실을 충분히 공지할 책임도 마이크로소프트에게 있는 것 아닙니까?
:
: 비용을 들여 제품을 구입한 소비자의 입장에서 각 RDBMS마다 그런 기본을 벗어나는 특성이 있는지 걱정을 하면서 써야
: 하는 겁니까?  SQL에 대한 기본부터 해서 인덱스, 트랜잭션과 잠금, 전부 다시 공부해야 당연한 겁니까?
:
: 혹시 이 질문에 '네'라고 말하는 분이 이 글을 보고 계십니까? 그런 분이 엔지니어시라면, 평생 공부만 하다가 죽을 겁니다.
: 혹 엔지니어가 평생 공부만 하는 것이 당연하다고 생각하시는 분이 계시다면, 그러면 도대체 개발은 언제 하고 자기
: 생활은 언제 찾느냐고 물어보고 싶습니다. 엔지니어의 정의가 평생 공부만 하는 사람입니까?
:
: 물론 오라클도 특성이 있고 DB2도 나름의 철학이 있겠습니다. 하지만 크리티컬할 수 있는 부분에서 표준과는 다르게
: 만들어놓고 그렇게 한 것이 우리 설계 철학이니 모르는 소비자가 잘못이라고 하지는 않습니다.
: 그런데도 제가 SQL 서버라는 제품을 탓하는 것이 잘못입니까?
:
:
: 얘기가 나왔으니 계속해보지요.
:
: 먼저 역시 SQL 서버에 대한 문제입니다. 클러스터 인덱스라는 넘 말입니다.
: 이거 아주 웃기는 넘이더군요. 클러스터 인덱스라는 것은 물리적인 레코드 데이터에 연결되어 있어서 이걸 걸었다가
: 중간에 레코드가 삽입되면 그 이후의 모든 물리적 데이터가 다 시프트된다고요. 그리고 별도 지정을 하지 않는
: 한, PK 필드는 이 클러스터 인덱스가 기본으로 잡혀버린다고요. 이게 무슨 뜻입니까?
:
: 고객 데이터를 주민번호를 키로 테이블로 저장한 상태에서 새 고객이 등록되면 새 주민번호가 인서트되죠.
: 그러면 그 주민번호보다 이후의 번호들은 모조리 디스크상에서 이동됩니다. 최악의 경우에, 100만명의 고객이 있는데
: 1940년생의 새 고객이 인서트되면, 그 테이블의 대부분의 데이터가 디스크상에서 읽혀진 후 새로 씌여집니다.
:
: 이런 상황은 드문 경우가 아닙니다. 굳이 주민번호가 아니더라도 이런 경우는 흔합니다.
: 클러스터 인덱스가 효율적이려면 그 필드는 항상 기존의 데이터보다 증가만 하는 데이터, 즉 일련번호와 같은 경우만
: 가능합니다.
:
: 디스크상에서 100만건 이상이 한번에 이동되면, 당연히 그 테이블은 락이 걸리겠지요.
: 그 테이블의 데이터를 요구하는 다른 쿼리 동작들은 느려지거나 대기하게 됩니다.
: 전체 성능에 엄청난 영향이 있는 겁니다. 제가 튜닝하던 도중에도 초당 수십, 수백번 인서트되는 테이블에
: 클러스터 인덱스가 설정된 걸 봤습니다. 하루에 두세번씩 멈추던 데이터베이스 서버가 클러스터 인덱스를 넌클러스터로
: 바꾸니까 쌩쌩하게 돌아가더군요. 그러면 제가, 클러스터 인덱스 외에 다른 RDB의 그냥 인덱스에 해당하는 넌클러스터
: 인덱스를 선택할 수 있도록 배려해준마이크로소프트에 감사해야 합니까? 아닙니다. 다른 RDB가 하는 대로 기본 상태는
: 넌클러스터로 하고 DBA의 선택으로 클러스터 인덱스를 선택할 수 있어야 당연한 겁니다.
:
: 그런데도 왜 이 클러스터 인덱스 설정이 기본으로 되어있습니까? 꼭 고객이 클러스터 인덱스라는 넘이 그런 것이라는
: 것을 공부해서 SQL 서버의 철학에 굴복해야 합니까? 이 업계에는 마이크로소프트의 독단적인 철학 외에 대부분의
: 구성원들이 동의하는 상식과 표준이 있습니다. 그걸 위반하고 철학과 설계탓을 하는 마이크로소프트에 제가 호의적이어야 할 이유가 있습니까? 소비자가 표준과 상식을 지키지 않는 제품에 당황하는 것이 이상합니까?
:
: 이번에는 개발툴인 비주얼 C++을 예로 듭시다.
: 비주얼 C++이 6.0 버전에 이르기까지 ANSI/ISO C++ 표준을 따르지 않았다는 것은 주지의 사실입니다.
: 상황에 따라 민감할 수도 있는 키워드들을 여러가지로 재정의해놓았지요. 마이크로소프트가 C++ 언어에 표준이 있다는
: 것을 몰라서 그랬습니까? 마이크로소프트라는 회사는 원래 상식과 표준을 잘 무시하고 독자적인 철학을 주장하길
: 즐긴다는 것을 모르는 소비자가 죄인입니까?
:
: (닷넷 버전에 가서는 비주얼 C++의 표준 준수성을 높였다고 강조하더군요. 그동안 그토록 비난을 받으면서도 오랫동안
: 표준을 무시해왔던 마이크로소프트가 갑자기 왜 표준을 들먹이는지 첨에는 의아했는데, 그럴만한 이유들이 있겠더군요)
:
:
: 커뮤니티 운영자로서 코난님은 존경스러운 분입니다. 규모있는 커뮤니티 운영이 얼마나 어려운지 저도 잘 아니까요.
: 하지만 표준과 상식을 무시하는 마이크로소프트의 독단적인 '설계 철학'에 대한 제 불만에 대답이 되지는 않는군요.
:
:
:
: 김대우 님이 쓰신 글 :
: : 박지훈님 안녕하세요. 반갑습니다. 제이름은 김대우라고 합니다.
: :
: : 평소 볼랜드 포럼에 가끔 들려 눈팅도 하고 업계 뉴스나 보다 가다가
: :
: : 여기 자유게시판에서 박지훈님의 글을 보고 늦은 밤이지만... 토끼같은 와이프가
: :
: : 눈비비고 졸립다고 하지만 몇줄 적어 보려 합니다. ^_^
: :
: :
: : 저는 개인적으로 http://sqler.pe.kr 이라는 SQL서버와 DBMS와 관련된 여러 생각을 나누는
: :
: : 작은 사이트를 운영하고 있습니다.
: :
: : 여러 DBMS 공부를 시작한건 98년이니 햇수로 7년이네요. 사이트 운영은 99년부터 했으니
: :
: : 6년이란 시간이 벌써 지났나 봅니다. 지나보니 빠른데 세보니 참 오랜 시간이군요. ^_^
: :
: :
: : LG텔레콤에서 SQL로 마이그레이션 한다는 말을 듣고 개인적으로는 흐뭇~ 합니다.
: :
: : 지훈님도 마찬가지시겠지만 자신이 가장 관심있는 솔루션이 잘된다는 이야기를 듣는 것이니까요.
: :
: :
: : 그런데 지훈님 시스템에 약간의 문제가 있는듯 해서 짧은 경험이지만 제가 가진 지식을 나눠 드리려 합니다.
: :
: : 여러번의 SQL서버 관련 컨설팅 경험과 문제 해결, 기술 지원 경험이 있으니 믿어 주시길 바랍니다. ^_^
: :
: : ----------------------------------------------------------------
: : 이 디비 서버는 제온 4CPU짜리 서버 한대에서 돌리는데, 바쁠 때는 1~2초 간격으로 두개 이상의 CPU가
: : 100%를 칩니다.
: : 데이터는 백만건 단위로 그렇게 대규모는 아니지만, 트래픽이 대단히 많고 시스템의 특성상 시간이 지날 수록 제곱배로
: : 부하가 커질 수밖에 없는 구조인데요. 이미 4CPU로도 한계에 가까워지고 있어서 곧 디비 클러스터링을 고려해야 할 상황입니다.
: : ----------------------------------------------------------------
: :
: : 우선 Clustering은 기본 컨셉이 High Availability를 위한 솔루션입니다. 만약 성능을 위한 선택이라고 생각 하신다면
: :
: : 조금 어색한 분위기가 될듯 합니다.
: :
: : 설마 Clustering의 개념을 잘못 알고 계신것은 아니리라 생각하며 아마 CPU 성능 이야기와
: :
: : 클러스터링 이야기를 별개로 위에 적으신 것이리라 생각합니다.
: :
: : 클러스터링은 알고 계신듯 하니 넘어갑니다.
: :
: :
: : CPU가 100을 친다면 왜 치는 것입니까? 그리 많지 않은 데이터에 제온 Quad CPU인데요?
: :
: : 제 소견으론 먼저 어떤 쿼리나 모듈이 CPU 100%을 치게 만드는지 원인을 분석하는게 급선무라 생각 합니다.
: :
: : 이렇게 해 보십시요.
: :
: : SQL서버 툴들중 프로필러 툴 수행 -> 서버 선택 -> 템플릿을 SQL Profiler Tuning으로 선택
: : 화일에 저장 선택후 화일 지정-> 데이터 탭에서 CPU, Reads, Writes, 필요시 Application Name, 또는 NT User Name 추가 -> 필요시 필터 탭에서 적절히 CPU에 대해서 수치 필터 지정
: :
: : 그럼 SQL서버에 전달되는 모든 쿼리와 저장 프로시져가 기록 됩니다. 여기서 딱 보시면
: : CPU가 높은 쿼리가 있을 겁니다. CPU가 높으면 당연히 Disk IO인 Read나 Write가 높을 겁니다.
: :
: : 1. CPU, Duration 높음 : 내부에 복잡한 수치연산, 다양한 변환 함수 튜닝 필요
: : 2. CPU, Disk IO높음 : 대부분의 경우 잘못된 쿼리, 잘못 생성된 인덱스, 의도적인 Full scan 가능성
: : 3. CPU와 Disk IO는 낮고 Duration이 길 경우 : 잠금, 트렌젝션 처리로 인한 일시적인 Blocking, 또는 DeadLock. 상호 상관되는 쿼리 확인후 잠금 처리 필요.
: :
: : 2번일 겁니다. CPU의 문제라기 보다는 개발자, 관리자의 잘못된 쿼리 수행과 인덱스 생성이 문제죠.
: :
: : 분석하는 방법은 헤아릴 수 없이 많습니다. Microsoft에서 무료로 제공하는 분석툴을 이용하면
: :
: : 위의 프로필러로 잡은 쿼리의 재현과 실행 계획도 그자리에서 통계까지 포함해 볼 수 있으며
: :
: : 위의 프로필러 작업도 스크립트로 사실상 백그라운드로 UI없이 저장 및 구성이 가능합니다.
: :
: : 하지만 분석을 하시기 위한 가장 쉬운 방법을 가이드 해 드리면
: :
: : 해당 쿼리를 클릭하면 아래 아래 창에 전체 쿼리가 뜹니다. 복사해서 쿼리 분석기에 붙이신후
: :
: : 컨트롤 + K를 눌러 실행계획을 표시하고 수행해 보세요.
: :
: :
: : 실행계획 탭을 보시면 Index Scan, 또는 Full Scan이 있을 겁니다. 보시면 엄청나게 많은 데이터 PUMP가
: :
: : 일어나 있을 거구요. 자 문제를 찾았습니까? 혹시 어떻게 튜닝을 하는지도 알고 싶으시면 저에게 회신 주세요.
: :
: :
: : 자~~~ 그럼 다음 이야기 전에 제가 지훈님께 질문 올리겠습니다.
: :
: : 쿼리가 빠르게 수행 안되는 이유는 누구의 잘못 입니까?
: :
: : 이쁜 김정은을 전화줄 "앙~~~" 물게하는 어디처럼 64 Way CPU에 수백기가 메모리를 꼽으면 그냥 빨라집니까?
: :
: : 지훈님 회사와 같은 갯수의 CPU로도 어디 사이트는 "안녕하세요. 배철숩니다" 광고까지 하면서
: :
: : 현재 수백억건의 데이터를 가지고 사용자를 끝도 없이 끌어 모으는 이유는 무엇입니까?
: :
: : 아니, 97년부터 테라데이터를 상업용으로 서비스해온 SQL서버는 1997년도에 펜티엄4 3Ghz CPU 였습니까?
: :
: : 정녕 CPU가 100%를 치는것이 SQL서버에 문제가 있는 것입니까?
: :
: : 지금 현업에서 실제로 서버를 운영, 개발하시는 지훈님의 생각은 어떠십니까?
: :
: :
: : 다른 이야기는 접고 트랜젝션 처리 이야기로 넘어가 보시지요.
: :
: : "설마 SET XACT_ABORT ON 이슈는 아니겠지...
: :
: : 설마... 그래도 사이트 주인장님에 프로그래밍 경력이 있지..."
: :
: : 지금 제 솔직한 심정은 트렌젝션에서 ACID는 기본 상식인걸 아신다는게 다행이라고 생각 합니다.
: :
: : 개념은 알고 계시다는 것이기 때문입니다.
: :
: : 일부러 제작사명 말하고 지훈님께 여쭤보겠습니다.
: :
: : 농심 짜짜로니 - 삼양 사천짜장 두개의 짜장라면이 있습니다.
: :
: : 옷~ 이게 웬걸 짜짜로니는 스프가 세개나 됩니다. 근데 젠장 사천짜장은 비닐에 든 짜장 스프뿐.
: :
: : 좀전에 야식으로 와이프와 아침에 눈 팅팅 붓게 될걸 각오하고 먹었습니다.
: :
: :
: : 제 느낌에 짜짜로니~ 약간 느끼한게 바로 그 짜장맛입니다. 나름대로 제가 최고라 생각하는 짜장라면입니다.
: :
: : 사천짜장은 와이프의 Favorite입니다. 고소한게 짜짜로니보다 훨씬 낫다나요...
: :
: : 뭐 닭살이라고 하셔도 할말 없습니다.
: :
: :
: : 여기서 질문  브레인~ 서바이버~~ 처럼 순식간에 후다닥~ 들어 갑니다.
: :
: : "왜 짜짜로니는 스프가 세개인데 사천짜장은 하나 뿐입니까?"
: :
: :
: : 제가 생각하는 최고의 대답- 우문현답은 이겁니다.
: :
: : "만든 업체의 디자인 컨셉과 설계 철학이 틀리기 때문입니다. ~"
: :
: :
: : 많은 "어플리케이션"에서 트렌젝션 사용은 이렇습니다.
: :
: : //코드 시작
: : 선언문~~
: :
: : //예외 처리 모듈 선언
: : 예외 처리 시작
: :
: : //트렌젝션 시작
: : 처리 모듈 1
: : 처리 모듈 2
: : 처리 모듈 3
: :
: : //트랜젝션 끝
: :
: : //성공적으로 완료시
: : 모듈 10으로 이동
: :
: : //실패가 하나라도 있을 때
: : 에러 표시 후 모듈 9로 이동
: :
: : //완료
: :
: : 모든 모듈이 완료해야 완료로 가며 1개라도 틀리면 오류로 가죠.
: :
: : 그렇다면 DBMS는 어떻습니까?
: :
: : 먼저 오라클에서 역시 위의 방법과 비슷합니다. 결론부터 이야기해
: :
: : 오라클은 Implicit Transaction 방식으로 INSERT, UPDATE, DELETE가 발생하면
: :
: : "자동"으로 트렌젝션이 시작되는 방식입니다.
: :
: :
: : SQL Server는
: :
: : Auto COMMIT 으로 불리는 방식을 쓰며 매 INSERT, UPDATE, DELETE 구문마다 처리 됩니다.
: :
: :
: : 화끈한 이야기 들어 갑니다. 트렌젝션은 하나의 BATCH구문에서 최소한의
: :
: : 자원을 가지고 최소한의 시간동안 수행되는 것이 성능에 엄청난 영향을 줍니다.
: :
: : SQL서버의 설계자는 이 컨셉을 지상과제로 설계 했으며 개별 데이터 수정 구문에 자동으로 COMMIT을 하게해
: :
: : 높은 완성도와 동시성, 성능을 보장합니다.
: :
: :
: : 오라클의 잠금 철학은 또한 다음과 같습니다.
: :
: : A사용자가 1을 2로 변경하면 A사용자의 세션에서는 1이 2로 메모리상에 Rollback segment와 함께
: :
: : 저장됩니다.
: :
: : 그럼 이때 B사용자가 들어와서 1을 읽으려 하면? 1이라는 Uncommited 값을 잠금 없이 바로 읽을 수 있습니다.
: :
: : 1을 3으로 바꾸려 하면? A사용자는 명시적으로 COMMIT을 하지 않았기 때문에
: :
: : B사용자와 경합이 생기며 B사용자는 대기하게 됩니다. A사용자가 COMMIT 또는 ROLLBACK할때까지 대기하게 되지요.
: :
: :
: : 여기서 다시한번 짜장라면을 생각해 봅니다.
: :
: : 왜 그렇게 만든 겁니까? 양쪽 모두 나름대로의 최선의 방법이라고 생각했기 때문 아닐까요?
: :
: : SQL서버 개발팀의 설계가 그런 것입니다.
: :
: :
: : 그럼 여기서 실질적인 문제를 짚어 봅니다.
: :
: :
: : 2001년 7월에 제가 데브피아라는 곳에서 온라인 세미나를 진행하면서 사용한 구문 입니다.
: : ----------------------------------------------------------------------------------------------------
: : --프로시져에서 트랜젝션 처리
: : USE pubs
: : GO
: :
: : CREATE TABLE konan_TR_Test(
: :     c1    int    not null    PRIMARY KEY
: : ,    c2     int
: : )
: : GO
: :
: : --데이터 삽입
: : insert into konan_TR_Test(c1,c2) VALUES(1, 1)        --성공
: : insertT into konan_TR_Test(c1,c2) VALUES(1, 1)        --신텍스 에러
: : insert into konan_TR_TestTTT(c1,c2) VALUES(1, 1)    --객체명 에러
: : insert into konan_TR_Test(c1,c2) VALUES(1, 1)        --PK 제약 에러
: :
: : --데이터 조회
: : select * from konan_TR_Test
: :
: : --수행
: : BEGIN TRAN
: : insert into konan_TR_Test(c1,c2) VALUES(2, 2)        --2라는 값 삽입
: : insert into konan_TR_Test(c1,c2) VALUES(2, 2)        --2라는 값으로 PK오류 생성
: : insert into konan_TR_Test(c1,c2) VALUES(3, 3)
: : COMMIT TRAN
: : GO
: :
: : --데이터 조회 - 결과는? 2는? 3은?
: : SELECT * FROM konan_TR_Test
: :
: : --현업에서 문제.
: : --학생 테이블을 생성한다.
: : --drop table 수강
: : --drop table 학생
: : --drop table 과목
: :
: : CREATE TABLE 학생(
: :     학생ID         varchar(10) primary key
: : ,     학번        varchar(10) not null
: : )
: : GO
: :
: : CREATE TABLE 과목(
: :     과목ID         varchar(5) primary key
: : ,     과목명         varchar(20) not null
: : )
: :
: : CREATE TABLE 수강(
: :     수강ID         int primary key
: : ,     학생ID         varchar(10) not null
: :             FOREIGN KEY REFERENCES 학생 (학생ID)
: : ,     과목ID         varchar(5)
: :             FOREIGN KEY REFERENCES 과목 (과목ID)
: : )
: :
: : --학생 삽입
: : BEGIN TRAN
: : INSERT 학생 VALUES ('KONAN', '1111')
: : INSERT 학생 VALUES ('JOMIRYO', '2222')
: : COMMIT TRAN
: :
: : --과목 삽입
: : BEGIN TRAN
: : INSERT 과목 VALUES ('공수', '공업수학')
: : INSERT 과목 VALUES ('디비', '데이터베이스')
: : INSERT 과목 VALUES ('게임', '게임프로그래밍')
: : COMMIT TRAN
: :
: : --데이터 조회
: : select * from 학생
: : select * from 과목
: :
: : BEGIN TRAN
: : INSERT 수강 VALUES (1, 'KONAN', '공수')
: : INSERT 수강 VALUES (2, 'KONAN', '디비')
: : INSERT 수강 VALUES (3, 'KONAN', '겜')
: : COMMIT TRAN
: :
: : --조회
: : select * from 학생
: : select * from 과목
: : select * from 수강
: :
: : --겜 과목은??
: : --데이터 삭제
: : delete from 수강
: : select * from 수강
: :
: : --넣을 경우?  - 에러
: : BEGIN TRAN
: : INSERT 수강 VALUES (1, 'KONAN', '공수')
: : IF @@ERROR <> 0 GOTO ERROR_TRANSACTION
: : INSERT 수강 VALUES (2, 'KONAN', '디비')
: : IF @@ERROR <> 0 GOTO ERROR_TRANSACTION
: : INSERT 수강 VALUES (3, 'KONAN', '겜')
: :
: : IF @@ERROR <> 0 GOTO ERROR_TRANSACTION
: : --성공
: : print '삽입이 성공했습니다.'
: : COMMIT TRAN
: : GOTO END_BATCH
: :
: : ERROR_TRANSACTION:
: : print '삽입 실패'
: : ROLLBACK TRAN
: :
: : END_BATCH:
: : print 'BATCH가 끝났습니다.'
: : GO
: :
: :
: : --넣을 경우?  - 성공
: : BEGIN TRAN
: :
: : INSERT 수강 VALUES (1, 'KONAN', '공수')
: : IF @@ERROR <> 0 GOTO ERROR_TRANSACTION
: : INSERT 수강 VALUES (2, 'KONAN', '디비')
: : IF @@ERROR <> 0 GOTO ERROR_TRANSACTION
: : INSERT 수강 VALUES (3, 'KONAN', '게임')     --게임임.
: : IF @@ERROR <> 0 GOTO ERROR_TRANSACTION
: :
: : --성공
: : print '삽입이 성공했습니다.'
: : COMMIT TRAN
: : GOTO END_BATCH
: :
: : ERROR_TRANSACTION:
: : print '삽입 실패'
: : ROLLBACK TRAN
: :
: : END_BATCH:
: : print 'BATCH가 끝났습니다.'
: : GO
: :
: : --데이터 조회
: : SELECT * FROM 수강
: :
: : --만약 BATCH가 1000건이라면??
: : --테이블 데이터 삭제
: : delete from 수강
: :
: : --새롭게 바뀐 처리.
: : SET XACT_ABORT ON
: : BEGIN TRAN
: : INSERT 수강 VALUES (1, 'KONAN', '공수')
: : INSERT 수강 VALUES (2, 'KONAN', '디비')
: : INSERT 수강 VALUES (3, 'KONAN', '겜')     --에러
: : COMMIT TRAN
: :
: : --데이터 조회
: : SELECT * FROM 수강
: :
: : --새롭게 바뀐 처리.
: : SET XACT_ABORT ON
: : BEGIN TRAN
: : INSERT 수강 VALUES (1, 'KONAN', '공수')
: : INSERT 수강 VALUES (2, 'KONAN', '디비')
: : INSERT 수강 VALUES (3, 'KONAN', '게임')    --정상
: : COMMIT TRAN
: :
: : --데이터 조회
: : SELECT * FROM 수강
: :
: : --아울러 ASP 또는 COM+에서 에러 처리 루틴
: :
: : ------------------------------------------------------------------------------------------------
: :
: : 자 스크립트 테스트 해 보셨습니까? 여기서 여쭤 봅니다.
: :
: : SQL서버는 SET XACT_ABORT ON 구문을 이용해야만 합니다. 어떤 경우에 그렇습니까?
: :
: : "Run-Time 오류"일 경우와 "분산 트렌젝션"일 경우에 필요합니다.
: :
: : "Run-Time"이 뭡니까?
: :
: : SQL서버는 빠른 속도로 쿼리를 처리하기 위해 파싱, 개체 검사, 실행
: :
: : 작업을 통해 수행됩니다. 트렌젝션의 처리시 만약 위의 에러 구문에서 보는 것처럼
: :
: : PK제약 오류와 같은 Run-Time의 오류에 대해서는 처리를 안합니다.
: :
: : 사실상 SQL서버의 BEGIN TRAN은 트렌젝션 처리 모듈 시작 진입 포인트를 명시한다라는 의미입니다.
: :
: :
: : 왜 그렇습니까?
: :
: : 오라클은 작업을 주욱~ 진행하다가 하나만 문제가 생기면 무조건 롤백합니다.
: :
: : 즉, 쿼리 수행 절차가 SQL서버와 틀린 방식으로 진행되며
: :
: : 오라클은  트렌젝션 처리를 진입 포인트가 아닌 선언문처럼 사용하는 개념입니다.
: :
: : 여기서 질문 하나 던집니다. 둘중에 뭐가 더 빠릅니까? 나중에 시간나면 해 보십시요.
: :
: : 방식이 틀려도 성능의 차이는 특수한 상황이 아닌 이상 크지 않습니다.
: :
: :
: : 또 질문 하나 던집니다.
: :
: : "SQL서버는 왜 그런겁니까?"
: :
: : "설계의 컨셉이 그렇습니다."
: :
: : "왜 오라클이나 SQL서버가 똑같지 않습니까?"
: :
: : "볼랜드 C++ 빌더랑 Visual C++은 왜 틀립니까?"
: :
: :
: : 그럼 박지훈님에게 제가 묻습니다.
: :
: : 모든 SQL서버 "기본" 책들에서 심도있게 다루는 트렌젝션과 잠금 처리.
: :
: : SQL서버 개발을 하시면서 기초가 되는 책을 한권이라도 보셨다면 모르실리가 없다고 생각 합니다.
: :
: : 당연히 모두가 그렇게 쓰는 부분을 지훈님만 선언문을 빼고 쓰셨고 그걸 SQL서버의 문제 / 버그라고
: :
: : 하신 거군요. 
: :
: :
: : 지훈님이 보신다는 프로페셔널이라는 책은 제가 없어서 모르겠습니다만... Step by Step 책이나 기초 책은
: :
: : 안보시고 프로 책으로 넘어가신듯 하네요. 참 글을 읽으면서 궁금한건 도데체 한달동안 튜닝을 하셨다면서
: :
: : 이런 기초적인 부분은 하나도 안 보시고 도데체 뭘 튜닝 하신 것인지 궁금합니다.
: :
: :
: : 그래도 끝까지 "사람을 당황스럽게 하는 SQL서버"라고 하시는걸 보니 개발자 기질과
: :
: : 엔지니어 기질이 보이시네요.
: :
: :
: : 저역시 몇마디만 더 드리겠습니다.
: :
: : SQL서버를 처음 공부할때 였을 겁니다. 당시 다양한 언어와 그 매력에 푹 빠져서
: :
: : 한참 재미있을때 SQL서버 초급 책을 두어권 끝까지 독파 했습니다.
: :
: : 샘플도 다 돌려 보고 프로그램에 붙여도 보고... SQL서버의 모든걸 안것 같았습니다.
: :
: : 그러다 MCDBA라는게 있다길래 껌이지~~ 하고 시험 공부 하는데
: :
: : 웬걸 난이도가 엄청난겁니다. 열심히 온라인 도움말을 보면서 공부했지만 떨어졌습니다.
: :
: : 부끄럽지만... 하지만 참 감사하게도... 덕분에 SQL서버의 깊이를 알게 되었죠.
: :
: : SQL서버의 온라인 도움말을 파고 또 파면서 인덱스 부분과 이해가 안가는 부분은 프린트 해서 씹어 먹으면서
: :
: : 이 악물고 공부했습니다. 니가 이기나 내가 이기나 해 보자잉~~~
: :
: : Microsoft의 KB를 보면서... 또 3rd업체의 SQL서버 관련 Tip들을 보면서
: :
: : 지훈님도 볼랜드 제품에 대한 매력을 느끼시는 것처럼 저역시 SQL서버의
: :
: : 매력에 푹~ 빠지게 되었죠.
: :
: : 덕분에 SQL서버 튜닝, 컨설팅도 해보고... 좋은 기회도 많았구요.
: :
: : 하지만 지금 또 SQL서버를 공부하면서 느끼는건 정말 깊이 들어갈수록 한도 끝도 없다는
: :
: : 것입니다. 특히나 최근 이기종간의 분산 트렌젝션 처리나 이기종 DBMS와 관련된 작업을
: :
: : 많이 하면서 더더욱 그런 느낌을 가지게 되었고 요즘엔 주변의 SQL전문가 분들을 보면서
: :
: : 세상엔 숨어있는 초고수님들이 이리도 많구나 하는 생각만 듭니다.
: :
: :
: : 저역시 SQL서버라는 시스템에 열정이 있습니다. 지훈님도 그러시겠죠.
: :
: : 지훈님이 이렇게 멋지게 꾸며 놓으신 사이트를 보면서 저역시 지훈님의 열정을 잘 보고 있습니다.
: :
: : 제 사이트에서 나름대로 튜닝한 게시판 제작후 열심히 질문 답변도 달고, 강좌도 열심히 무료로
: :
: : 등록 같은 것 안해도 모두 볼 수 있게 무료로 아무런 대가 없이 적었고
: :
: : 더더욱 많은 분들에게 SQL서버의 여러 6만 2천건이 넘는 QnA를
: :
: : 좀더 많은 분들이 손쉽게 검색 할 수 있도록 하기 위해 QnA게시판의 내용을
: :
: : 로컬 오프라인으로도 검색 가능하도록 하는 SQLER 탐쉐이~ 라는 툴도 만들었습니다.
: :
: : 물론 무료죠. 등록도 필요 없습니다. 그냥 다운로드 해서 쓰세요.
: :
: :
: : MS가 지원 해 줬냐구요? 아니요~ 배너 하나 얼마얼마에~ 해준다는 말 한번도 없었습니다. ㅋㅋㅋ
: :
: : MS가 지원해 준다고 해도 내가 안했을 겁니다. 그럼 MS에게 하고싶은 말을 제 웹사이트에서
: :
: : 조차 할 수 없었을 테니까요.
: :
: : 이런 무료 봉사 쌩 뻘짓거리를 왜 했냐구요? 그것도 내직장 다니며, 9시에 출근해 11시에 퇴근하면서
: :
: : 새벽까지 강좌쓰고 게시판에 답글달고... 누가 돈주는 것도 아닌데 왜 했냐구요?
: :
: : 이 참 잘 만든 SQL서버를 많은 분들이 너무 몰라 주셔서, 잘못알고 계셔서,
: :
: : 많은 분들이 단순히 MS에 대한 악감정과  억하 감정만을 가지고 접근 하셔서 제가 직접 만들었습니다.
: :
: :
: : 지훈님께 부탁 드립니다.
: :
: : 아주 잘만드신 웹사이트입니다. 저역시 많은 업계의 정보와 볼랜드측 자료를 여기서 봅니다.
: :
: : 항상 감사 드리고 있는 그런 눈팅만 해온 사람입니다.
: :
: :
: : 한마디만 드리자면 지훈님은 웹사이트의 주인장님이신 많은 분들이 주목하는 공인입니다.
: :
: : 저역시 지훈님의 웹사이트에선 한명의 정보를 얻어가는 손님일 뿐이구요.
: :
: : 부디 공인의 입장에서 치우침 없이... 여기 지훈님이 버그 덩어리라고 느끼시는 그 SQL서버에
: :
: : 대한 열정만 있는 제 마음도 좀 편하게 해 주시길 간곡히 부탁 드립니다.
: :
: :
: : 읽어 주셔서 감사합니다. 혹시 기회가 되면 제가 잘익은 생삽겹살 구이에 참이슬 따라드리면서
: :
: : 이런 저런 이야기 나누고도 싶네요.
: :
: :
: : PS. SQL 서버를 운영하시면서 버그인것 같으시다면... 제게 메일, 게시판에 질문 주세요.
: :
: : 제가 처리 가능한 일이라면  해 드리고 다른 관련된 채널이 있으니 도움 드릴 수 있는 부분은 최대한
: :
: : 도움 드리겠습니다.
: :
: : 이만.
: :
: :
: :
: : 박지훈.임프 님이 쓰신 글 :
: : : 최근 며칠 사이에 MS SQL서버 2000의 버그로 강하게 의심되는 사례를 두차례나 겪어 글을 써봅니다.
: : : 마침 방금 올린 IT뉴스 기사중에도 LG텔레콤이 오라클에서 SQL서버로 마이그레이션을 시도한다는 기사도 있고 해서요.
: : :
: : : 제가 다니는 회사에서 사용하는 DBMS 제품이 나오는 관계로 회사가 어디인지 공개적으로 밝히진 않겠습니다.
: : : IT쪽 회사는 아니지만 해당 분야에서는 아주 잘 알려진 중견 기업이구요. 최근 오프모임에서 만난 분들은 물론 아시죠.
: : :
: : : 저희 회사에서는 전사적으로 MS SQL서버를 사용하고 있습니다.
: : : 파트별로 디비를 별개로 운영하고 있기 때문에 디비서버가 꽤 여러 대 되는데, 다 SQL서버를 돌리고 있죠.
: : : 그중에 제가 직접 관여한 시스템이 가장 많은 트래픽을 기록하는데요.
: : :
: : : 이 디비 서버는 제온 4CPU짜리 서버 한대에서 돌리는데, 바쁠 때는 1~2초 간격으로 두개 이상의 CPU가 100%를 칩니다.
: : : 데이터는 백만건 단위로 그렇게 대규모는 아니지만, 트래픽이 대단히 많고 시스템의 특성상 시간이 지날 수록 제곱배로
: : : 부하가 커질 수밖에 없는 구조인데요. 이미 4CPU로도 한계에 가까워지고 있어서 곧 디비 클러스터링을 고려해야 할
: : : 상황입니다.
: : :
: : : 사실 저는 디비 전문가는 전혀 아니지만, 그동안 개발을 하면서 당연히 디비쪽도 이래저래 꽤 다루기도 했고요.
: : : 또 어떻게 하다보니 이 회사에 입사하고 처음 한 일이 SQL서버 튜닝이었는데, 입사후 거의 한달 가까이 디비 튜닝, 특히
: : : SQL서버 튜닝에 대한 관련 자료들을 뒤적거려서 성공적으로 튜닝을 마쳤습니다.
: : : 그러니까 디비쪽으로 DBA 수준의 아주 전문은 아니어도 알만큼은 알고 다뤄볼 만큼은 다뤄본 정도라고 할 수 있지요.
: : :
: : : SQL서버의 버그로 의심되는 문제가 발생한 것은, 고객 정보를 DB에 등록하는 루틴에서였습니다.
: : : 고객 정보를 등록할 때 동시에 입력되는 정보가 꽤 많기 때문에 여러 테이블.. 대략 10개 이상의 테이블에 한방에
: : : 인서트를 합니다. 당연히 트랜잭션을 먼저 걸고 인서트 쿼리들을 날린 후에 커밋을 하지요. 그리고 트랜잭션의 특성상
: : : 어떤 에러라도 발생하면 전체 트랜잭션내의 모든 쿼리가 취소되지요.
: : :
: : : 며칠전.. 그러니까 지난주 금요일부터 갑자기 고객 정보 입력을 하는 ASP 페이지에서 에러가 나면서 입력이 안되는
: : : 문제가 발생했습니다. 입사한지 얼마 안되는 제가 알기로도 1년 이상 아무 문제없이 써오던 부분이라 꽤 당황스러웠죠.
: : : 하루에도 수십명씩의 고객을 등록해야 하는데, 입력 작업이 장난아니게 노가다이기 때문에 며칠 정도만 입력이 미뤄져도
: : : 감당 못하게 입력할 데이터가 쌓이고, 여러가지로 문제가 복잡해집니다.
: : :
: : : 보통 오랫동안 잘 동작하던 부분에서 문제가 생기면 어디서부터 뒤져봐야 할지 난감해지잖습니까.
: : : 월요일에야 문제를 찾았는데요. 문제의 직접적인 원인은 트랜잭션의 롤백이 제대로 이루어지지 않은 거였습니다.
: : :
: : : 에러가 발생하기 시작한 시점의 직전에 고객 데이터를 입력하다가 에러로 롤백된 데이터가 있었나보더군요.
: : : 당연히 고객 정보 전체의 마스터 테이블에서 고객 번호를 딴 후에 그 고객번호로 디테일 테이블에 차례로 데이터를 넣는
: : : 흐름으로 처리되게 되어있는데, 마스터를 포함한 다른 모든 테이블의 레코드들은 모두 롤백되어 사라졌는데, 세번째
: : : 디테일 테이블에 추가되었던 레코드가 지워지지 않고 남아있더군요.
: : :
: : : 게다가 하필이면 찌꺼기 레코드가 남은 이 디테일 테이블이 마스터 테이블과 1:1 관계에 있는 테이블이었습니다.
: : : 다시 말해서 마스터 테이블의 PK는 고객번호인데, 이 디테일 테이블의 PK도 고객번호로 되어 있다는 얘깁니다.
: : : 테이블의 PK인 고객번호 필드에 연결되어 있습니다.
: : :
: : : 고객번호를 딴다는 표현에서 짐작하셨겠지만 이 고객번호가 일련번호로 되어있습니다.
: : : 그러니까 새로 고객을 등록할 때마다 1씩 증가하는 새 번호를 만드는 건데요.
: : : 먼저 마스터테이블에서 번호를 따고 마스터 테이블에 1:1로 연결된 디테일 테이블에 새 레코드를 인서트하려고 시도할 때,
: : : 이미 해당 고객번호의 레코드가 있기 때문에 트랜잭션이 커밋되지 못하고 매번 롤백되어버린 거였습니다.
: : : 마스터테이블에는 해당 고객 번호가 없고 디테일에는 남아있는 상황이죠.
: : :
: : : 아시다시피 MySQL과 같이 기본적으로 트랜잭션을 지원하지 않는 디비를 제외하면, 데이터베이스에 있어 트랜잭션의
: : : 특성은 기본중의 기본입니다. ACID라고 해서 4원칙도 있잖습니까. 그런데 MS가 그렇게 안정적이라고 장담에 장담을 하는
: : : SQL 서버에서 롤백된 데이터중 일부가 지워지지 않고 남아버리는 어처구니 없는 상황이 벌어져서 며칠동안 대혼란이
: : : 일어난 겁니다.
: : :
: : : 이쯤 되면, SQL 서버를 상당기간 잘 써오신 분들은 제 말에 의심부터 드시겠지요.
: : : 정상적인 입력작업이 아닌 경로로 추가된 레코드가 아닌가? 라든지 말이죠.
: : :
: : : 그런데 이 DB 서버는 웹서버 머신과 저희팀의 네명의 PC 외에는 접근조차 할 수 없도록 IP가 막혀 있고요.
: : : 또 저도 설마, 혹시나, 하면서 저희 시스템의 전체 소스를 다 뒤져서 이 테이블에 인서트를 하는 다른 루틴이 있나 다시
: : : 찾아보기도 했습니다만 전혀 없었습니다. 게다가 남아있는 찌꺼기 레코드의 데이터와 입력되지 못하고 대기중이던
: : : 고객정보 문서들을 대조해본 결과 대기중이던 문서들중 하나에 그 레코드 내용들이 있더군요.
: : :
: : : 결과적으로 다르게 어떻게도 변명할 수 없는, SQL서버 자체의 버그가 아니면 있을 수가 없는 문제입니다.
: : :
: : : 게다가, 불과 이틀 후에 같은 문제가 다시 재발했습니다. 바로 며칠전에 겪은 일도 있고 해서 입력 에러가 생기기 시작하자
: : : 마자 바로 찌꺼기 레코드가 있나 찾아봤는데, 역시나 있더군요. 그런데 황당하게도 며칠전에 문제를 일으켰던 것과 똑같은
: : : 디테일 테이블에 똑같은 형태로 레코드가 남아있더라구요.
: : :
: : : 같이 인서트되는 테이블이 디테일 테이블이 열몇개나 되는데 불과 며칠 사이에 유독 이 테이블에만 두차례나 문제가
: : : 생기는 것이 신기하고 황당해서, 다른 테이블과 다르게 설정된 특이한 점이 있나 해서 이래저래 뒤져봤는데요.
: : : 한가지 차이점이 있었습니다. 실수로 FK가 안잡혀있더군요. 구조상 FK를 잡아줘야 하는데, 그걸 빼먹은 겁니다.
: : : 다른 테이블에는 다 잡혀있었고요.
: : :
: : : FK가 안잡혀있는 것은 분명히 실수이긴 하지만, FK가 안잡혀있다고 해서 롤백이 제대로 되지 않아서는 안되죠?
: : : 이번 케이스의 경우 서로 연관된 테이블들을 함께 인서트하는 거지만, 디비를 다루다보면 연관성이 없는 레코드들도
: : : 하나의 트랜잭션 안에서 커밋/롤백하는 경우도 종종 생깁니다. 트랜잭션의 All or Nothing 원칙에은 FK가 잡혀있건
: : : 안잡혀있건 무관하게 무조건 지켜져야 하는 겁니다.
: : :
: : : 아마도, 어떤 복잡하게 꼬인 조건에만 발생하는 버그가 있어서 그 조건중의 하나로 FK가 안잡혀있다는 조건이 포함되는
: : : 것 같습니다. 앞에서도 말했듯이 다른 경로로 이 찌꺼기 레코드가 들어갔을 가능성은 전무한 상태이므로 SQL 서버의
: : : 버그가 아니라면 있을 수가 없는 일이지요.
: : :
: : : 다시 한번 확인할 기회를 갖기 위해..
: : : 그 디테일 테이블에 FK를 잡지 않고 그대로 뒀습니다. 불과 3일만에 두번이나 발생한 문제이므로 다시 발생할 가능성이
: : : 높겠죠. 세번째까지 확인한 후에 FK를 잡아놓고 그 이후에 더이상 발생하지 않는다면 SQL서버의 버그일 가능성이
: : : 거의 틀림없겠죠.
: : :
: : : 하지만 FK를 잡기 전에 다시 발생하지 않는다거나 FK를 잡은 후에도 발생한다고 해서 SQL서버의 버그가 아니라고
: : : 할 수도 없습니다. 이런 종류의 버그는 발생하는 패턴을 잡아내기가 대단히 힘드니 예상한 방식으로 다시 나타나지
: : : 않을 가능성도 충분히 높죠. 그리고 이미 정황상 SQL서버의 버그가 틀림없어보이기도 하고요.
: : :
: : : 물론, 대부분의 다른 사이트에서는 잡음이 들리지 않는 걸로 봐서(들리지 않는다고 발생하지도 않는 것은 아니지만)
: : : SQL서버를 채택한 기업들이 적어도 그럭저럭은 쓰고 있다는 말일텐데요. 그렇다고 안심할 것이 못됩니다.
: : : 저희 회사에서 발생한 이번 건의 경우 그나마 고객 정보 입력 단계에서 발생한 문제여서 그렇게 시분초를 다툴 정도의
: : : 큰 문제는 아니었지만, 이런 문제가 만약 1초 1초가 급한 업무에서 발생해버린다면?
: : : 그야말로 대란이 일어나는 거지요 뭐.
: : :
: : : 바로 이런 면 때문에 기업에서 미션 크리티컬한 업무에는 "충분히" 검증되지 않은 DBMS를 쓰지 못한다는 건데..
: : : 아직 SQL 서버는 충분히 검증되지 않은 상태인데 시스템 구축시에 SQL 서버를 채택한 것이 성급했다고 할 수 있죠.
: : :
: : : MS에서 SQL서버는 사실상 7.0에서 완전히 새로 개발했다고 그렇게 자랑을 해대는데...
: : : 거꾸로 말하면 7.0이 출시된 98년인가 이후로 불과 6년 정도의 검증기회밖에 없었다는 얘기가 되죠.
: : :
: : : 어쨌든... 저희 회사에서는 현재 오라클로 마이그레이션할 것을 진지하게 고려하고 있습니다.
: : : 사실 오라클 마이그레이션 외에 다른 대안이 없죠.