이 글과 함께 4소켓의 성능 비교한 자료 및 본 글에 추가하는 글을 보고자 하신 다면 다음 포스트를 읽어 보시기 바랍니다. (http://maystyle.tistory.com/227)
SanKim 님 블로그를 보고 추가로 몇 가지더 말하고자 합니다.
(http://blogs.technet.com/sankim/archive/2007/12/28/windows-64bit-computing.aspx)

둘 사이의 객관적인 성능 즉 동일 소켓 대비 TPC는 현재 tpc.org에서 확인할 결과 x64가 우월 합니다.
다만 多 소켓의 경우 IA64가 64개까지 듀얼 코어로 지원합니다... tpc에서 4 소켓 이상의 자료가 없네요...;;;

MS Windows가 지원하는 64bit 플랫폼은 x64와 IA64가 있습니다.
기원을 말하자면 IA64는 진정한 Real 64bit 운영체제를 위한 CPU로써 인텔 HP Microsoft의 공동 작품입니다.
그리고 x64는 AMD에서 인텔의 64비트 프로세서에 대응하기 위해 Memory Addressing 영역을 2의 64승까지 늘린 프로세서 입니다.
(x86의 경우 2의 32승 즉 4G 까지 할당 가능 PAE 옵션 제외)

자 그렇다면 우리는 고객에게 어떤 CPU의 플랫폼을 권해야 할까요?
가장 기본적인 사실은 IA64는 x64에 비해 비싸다는 점입니다. 대신에 빵빵한 CPU의 케쉬등과 같은 장점과 x64같은 CISC 칩에 비해 소켓을 늘릴 경우 성능 향상이 돋보인다는 장점이 있습니다. 반면에 x64는 싸고 클럭속도가 우수합니다.

무엇에 좋을까요?
전 DB에 권해 드립니다. 왜? DB에 IA64를 써야 하나? 먼저 최근의 IT 트렌드는 Integration 입니다. 즉 이런 통합 DB에서는 IA64 머신과 동일 성능을 내기 위해서는 IA64과 비교하여 많은 소켓을 필요로 하고 실질적으로 비용적인 층면에서 소켓의 증가로 인한 SQL Server 단가 상승이 불가피 합니다.

수정해야 할 부분... 처음에는 아래처럼 생각했습니다.
고로~~~ 차라리 IA64 CPU 4Way ~ 8Way가 성능 뿐만 아니라 비용적인 측면에서도 우수 할 수 있다는 점입니다.
(물론 IBM의 16소켓 (서버 2대를 이어서 만들죠...;;) 이나 유니시스의 32소켓 같은 머신과 비교했을 경우 입니다.)
(x86, x64와 같은 CISC 칩은 RISC 칩에 비해 소켓 증가 대비 성능 향상 효과가 떨어집니다.)

하지만 논쟁을 거쳐 알아보니... 동일 소켓일 경우 TPC가 x64가 더 우수합니다.
http://maystyle.tistory.com/227
즉 굳이 아주 대용량이여서 8소켓 이상의 구조가 아닌 이상에야 x64가 가격 대비 성능이 탁월 하며, 다른 분들 중에는 요즘 들어 x64가 더 우수하다는 분도 계십니다. 그리고 저도 병렬처리가 그렇게 많지 않을 경우  x64가 더 우수하다는 기사를 자료를 찾으면서 읽기도 했습니다.

즉 아래의 글들은 좀더 수정을 해야 할것으로 보입니다.
하지만 타 플랫폼으로 이용하실때는 x64를 권해드립니다. 물론 IA64 서버가 DB만 나오기 때문이기도 하지만 실제 x64와 IA 64를 BMT 했을 때 x64가 성능이 나은 경우도 있다는 소문도 있고...(IA 64는 빵빵한 캐쉬로 인해 동일한 연산을 지속적으로 반복할 경우 속도가 빠릅니다. (실제 소켓일 경우 성능이 더 우수했습니다.) 즉 메모리와의 I/O가 거의 없는 반면 클럭속도는 비교적 느린 편에 속합니다. 하지만 x64의 경우 캐쉬가 x86에 비해 비약적으로 늘진 않아 CPU에 새로운 명령어셋이 들어갈때 메모리와의 I/O가 많습니다. 하지만 다양한 명령어 처리가 필요한 서비스의 경우 오히려 우수한 성능을 나타내기도 한다고 합니다.)

고로 대용량 DB는 IA64 머신으로 가야 할 것이며, 타 서버 (경량 DB 서버, Exchange, Domain Controller, IIS 등)는 x64로 가시는게 맞는 길로 보입니다.

출처 : Inside Microsoft SQL Server 2000
Windows Internals 와 비교해서 꽤 해석이 월활하게 되어 있습니다. 강추 드립니다...^______^!
SQL 2005버젼에서 변경된 내용을 동시에 이야기해 드릴 생각입니다.

DB 공부하기 1번째 : 선언적 데이터 무결성(Declarative Data Integrity) (http://maystyle.tistory.com/218)
DB 공부하기 2번째 : 트랜잭션 프로세싱 (http://maystyle.tistory.com/219)
DB 공부하기 3번째 : 데이터 파일과 트랜젝션 로그 파일
1. 왜 DB의 단편화가 일어나는 걸까? (http://maystyle.tistory.com/220)
2. 데이터 파일은 어떻게 쓰여질까? (Checkpoint) (http://maystyle.tistory.com/221)
3. 로그는 어떻게 쓰여질까? (http://maystyle.tistory.com/223)
4. 트랜잭션 로그의 기록과 복구

트랜잭션 로그는 데이터베이스의 모든 변경 사항들을 기록하고, 시스템이 고장났을 경우 또는 App가 특별히 명령을 내렸을 때 변경된 내용들이 Roll back 되거나 Roll forward 될 수 있도록 변경된 정보를 저장한다. 데이터베이스 업데이트를 수행하는 모듈들은 변경 사항들을 정확히 기술하는 로그 항목들을 기록한다. 각 로그 항목들에는 고유한 값을 갖는 로그 시퀀스 번호(LSN) 라벨이 붙는다. 시스템 복구 동안에 트랜잭션의 모든 부분들이 Roll back가 Roll forward를 위해 쉽게 검색 될 수 있도록 동일한 트랜잭션의 일부가 되는 항목들은 서로 연결되어 있다.

버퍼 관리자는 변경된 데이터베이스가 기록되기 전에 트랜잭션 로그가 기록되게 한다. 이것이 가능한 것은 SQL Server가 LSN을 통해 로그에 현재 위치를 유지하기 때문이다. 페이지가 변경될 때마다 이 변경에 대한 로그 항목에 대응하는 LSN이 데이터 페이지의 해더에 기록된다. 페이지에 있는 LSN이 로그에 기록된 마지막 페이지의 LSN보다 작을 때만 변경된 페이지가 디스크에 기록될 수 있다. 버퍼 관리자는 로그 페이지들이 특정 순서로 기록되게 한다. 이것은 시스템이 고장났을 때 언제 고장 났는지 상관없이 어느 로그 페이지들이 처리되어야 하는지를 분명하게 알 수 있게 해준다. 트랜잭션을 위한 로그 레코드들은 커밋 통보가 클라리언트 프로세스에게 전달되기 전에 디스크에 기록되지만, 변경된 실제 데이터는 물리적으로 테이터 페이지에 기록되지 않았을 것이다. 따라서 로그에 기록하는 것은 동기적으로 이루어져야 하지만 (SQL Server는 로그가 디스크에 안전하게 있다는 것을 알 수 있도록 로그 기록이 완료되기를 기다려야한다.), 데이터 페이지에 기록하는 것은 비 동기적으로 이루어질 수 있다. 즉 데이터 페이지에 기록하는 것은 운영체제에게 게시될 필요만 있고, SQL Server는 나중에이 작업이 완료 되었는지 확인 할 수 있다. 로그가 작업을 취소하기 위해 필요한 모든 정보를 갖고 있기 때문에 데이터 페이지에 기록하는 작업은 즉시 완료될 필요가 없다. 이것은 쓰기 작업이 완료되기 전에 시스템이 고장날 경우에도 마찬가지이다. 시스템이 다음 작업을 하기전에 모든 I/O 요청들이 완료되기를 기다려야 한다면 시스템은 지금 보다 훨씬 더 느려질 것이다.

로그에는 각 트랜잭션의 시작과 끝을 구분하는 정보가 들어간다. 트랜잭션이 저장점을 사용할 경우에는 저장점 정보도 들어간다. 시작 정보와 끝 정보 중간에 데이터 변경에 관한 정보가 있다. 이정보는 실제 "before" 데이터와 "after" 데이터 값 형태로 되어 있을 수도 있다. 또는, 이 값들이 유추될 수 있도록 수행된 동작을 참조할 수도 있다. 일반적인 트랜잭션의 끝에는 Commit 레코드가 표시되는데 이것은 트랜잭션이 데이터베이스에 반영되어야 하거나, 필요할 경우에는 다시 수행되어야 한다는 것을 나타낸다. 사용자의 롤백(roll back)이나 리소스에러 등의 문제 때문에 일반 런타임 중에 취소된 트랜잭션은 처음 데이터 변경을 되돌리는 변경작업을 적용함으로써 실제로 동작을 취소한다. 이변경들에 대한 레코드는 로그에 기록되고 "compensation log records"로 표시된다. 트랜잭션이 커밋했지만 데이터가 데이터 페이지에 기록되기 전에 시스템이 고장나면 트랜잭션이 복구되어야 한다. 복구 과정은 시스템 시작시에 자동으로 실행된다. 복구는 시스탬 시작 시의 기능이다. 그러나 복구는 백업된 데이터배이스를 불러들이는 마지막 단계 동안에도 실행되고, 수동으로 강제적으로 실행될 수 있다.

복구는 재실행 동작과 취소 동작 모두를 수행한다. 재 실행 동작에서 로그는 조사되고 변경된 것들은 이미 데이터베이스에 반영되었는지 검사한다. 변경된 내용이 데이터베이스에 없으면 로그에 있는 정보를 사용하여 적용 동작이 다시 수행된다. 트랜잭션이 완전하게 완료되지 않았다면 취소할 때 트랜잭션에 의해 부분적으로 변경된 것들이 제거되어야 한다.

복구 과정 동안에 마지막 검사점 이후에 일어났거나 진행중인 변경사항들만이 재실행되거나 취소된다. 복구 알고리즘에는 세 단계가 있고, 이단계들은 트랜잭션 로그에 있는 마지막 검사점 레코드를 중심으로 하여 있다.

복구 계획
1 단계 : 분석
첫번째 단계는 트랜잭션 로그에 있는 마지막 검사점 레코드에서 시작하여 앞으로 진행하는 것이다. 이 단계는 시스템 정지 시에 변경되어 있었을 수도 있는 페이지들로 구성된 DPT(dirty page table)을 알아내고 구성한다. 시스템 정지 시에 커밋되지 않은 트랜잭션들로 구성된 활성 트랜잭션 테이블이 만들어진다.
2 단계 : 재실행
이 단계는 데이터베이스를 시스템 정지 시의 상태로 되돌린다. 이 포워드 진행의 시작 지점은 DPT에 있는 모든 LSN들의 최소값이다. 복구될 필요가 없는 페이지들을 읽는 것을 피하고 로그에 기록되기 않은 변경 사항들을 덮어쓴느 것을 피하기 위해 DPT가 사용된다.
3 단계 : 취소
이 단계는 각 트랜잭션 마다 트랜잭션 로그에 있는 항목들간의 연결을 따라가면서 로그의 끝에서부터 뒤쪽 방향으로 움직인다. 시스템 정지 시에 커밋되지 않은 트랜잭션은 취소된다. 이것은 변경된 내용들이 실제로 데이터베이스에 반영되지 않도록 하기 위한 것이다. 

DB 공부하기 1번째 : 선언적 데이터 무결성(Declarative Data Integrity) (http://maystyle.tistory.com/218)
DB 공부하기 2번째 : 트랜잭션 프로세싱 (http://maystyle.tistory.com/219)
DB 공부하기 3번째 : 데이터 파일과 트랜젝션 로그 파일
1. 왜 DB의 단편화가 일어나는 걸까? (http://maystyle.tistory.com/220)
2. 데이터 파일은 어떻게 쓰여질까? (Checkpoint) (http://maystyle.tistory.com/221)
3. 로그는 어떻게 쓰여질까?

변경된 모든 것들은 버퍼 관리자에 의해 트랜잭션 로그로 "미리 기록"된다.이것은 변경된 데이터 페이지가 기록되기 전에 트랜잭션을 위한 로그 레코드가 항상 디스크에 기록된다는 것을 의미한다. 미리 쓰기 로깅은 Hard Disk가 고장나지 않는 한 서버가 완전히 망가진 상태에서도 복구 할 수 있도록 해 준다. 트랜잭션이 디스크의 트랜잭션 로그에 들어 있지 않으면 프로세스는 결코 트랜잭션이 커밋되었다는 것을 통보 받지 못한다. 이런 이유로 트랜잭션 로그 기록은 동기적으로 이루어진다. 데이터 페이지에 기록되는 것은 통보를 기다리지 않고 비동기적으로 이루어 질 수 있다. 만약 고자장 나면 트랜잭션 로그에 있는 정보를 사용하여 트랜잭션을 취소하거나 다시 수행할 수 있다.

로그 관리자는 트랜잭션 로그 레코드를 디스크에 기록하기 전에 메모리 내에서 이것의 형식을 지정한다. 로그 관리자는 이 로그 레코드들의 형식을 지정하기 위해 로그 캐시라고 불리는 연속된 메모리 영역을 유지한다. SQL Server 에서 로그 레코드는 데이터 페이지 및 인덱스 페이지와 버퍼 풀을 공유하지 않는다. 로그 레코드는 로그 캐시에만 유지된다.

로그 관리자는 이 캐시를 2개를 가지고 하나씩 채우고 비우고 하는 형식으로 보관하고 로그 기록자 (log writer)는 캐쉬가 비워질때 flushQueue를 조사하면서 로그 캐시를 한번에 디스크로 보내는 전용 스레이드 이다.

종합하자. 일단 데이터 파일에 저장되는 경우에는 Check Point를 만나는 경우다. 로그에 기록되는 경우는 로그 캐쉬의 내용이 Flush되는 순간이다. 보통은 거의 동기적으로 이루어진다.

+ @
로그는 VLF 라는 저장단위로 구성된다. 가상 로그 파일의 최소 단위는 256KB로써, 토랜잭션 로그가 가장 작은 크기인 512KB일때 두개의 가상로그 파일로 구성되며, 처음에 로그 파일을 500MB로 만들면 50MB의 가상로그 파일 10개로 구성된다. 그리고 이런 로그 파일은 circular queue 처럼 동작하는데... 문제는 이 로그 파일이 조금씩 증가하면 작은 가상 로그 파일들이 많이 만들어지고, 이것은 성능에 않좋은 영향을 미친다는 것이다. 10MB 단위로는 늘려주자...^^v

현재 DC가 살아 있고 터미널 서비스에 접속해 있습니다.

현재 DC가 Reboot 된 상황에서도 터미널 서비스 접속이 잘 되고 있습니다.

DB 공부하기 1번째 : 선언적 데이터 무결성(Declarative Data Integrity) (http://maystyle.tistory.com/218)
DB 공부하기 2번째 : 트랜잭션 프로세싱 (http://maystyle.tistory.com/219)
DB 공부하기 3번째 : 데이터 파일과 트랜젝션 로그 파일
1. 왜 DB의 단편화가 일어나는 걸까? (http://maystyle.tistory.com/220)
2. 데이터 파일은 어떻게 쓰여질까?

시스템 시작 시 데이터베이스가 복구될 때 검사점 동작은 SQL이 수행해야 할 작업의 양을 최소화 시킨다. 검사점은 데이터베이스 별로 실행되며 현재 데이터베이스에서 변경된 페이지들을 디스크에 기록한다. 검사점 동작이 실행될 때 SQL Server는 검사점 레코드를 트랜젝션 로그에 기록한다.

검사점 발생 상황
- 명시적인 Checkpoint 명령어 실행
- 로그 용량이 70%이상 찼고 데이터베이스가 SIMPLE 모드 일경우
- 긴 복구 시간이 예상될 경우 (SQL 기본값은 1분)

검사점은 sp_configure 의 복구 간격 옵션을 사용하여 조정이 가능하다.물론 시작시 -T3502 플래그를 설정하여 검사점 실행시 이벤트 로그에 로그를 남길 수 도 있다.

DB 공부하기 1번째 : 선언적 데이터 무결성(Declarative Data Integrity) (http://maystyle.tistory.com/218)
DB 공부하기 2번째 : 트랜잭션 프로세싱 (http://maystyle.tistory.com/219)
DB 공부하기 3번째 : 데이터 파일과 트랜젝션 로그 파일
1. 왜 DB의 단편화가 일어나는 걸까?

데이터베이스는 8KB 크기를 갖는 페이지들의 모음이다.
페이지 관리자는 모든 형식의 페이지들을 할당하고 할당된것을 해제하면서 각 페이지들의 크기를 정리한다. 8개의 페이지를 익스텐트라고 하는데 테이블이 8개 미만의 페이지를 사용할 경우 공간 활성화를 위해 혼합된 크기로 새페이지들을 할당한다.

문제는 이러한 할당 작업과 할당 해제 작업이 지속될 경우 DB가 단편화가 될 수 있다는 사실이다. 실제 SQL 서버의 경우 클러스터드된 인덱스의 순서에 따라 물리 파일에 저장됨으로 그러한 우려는 더욱 커지게 된다.

테이블의 데이터가 얼마나 연속적인지 알아보기 위해서 DBCC Showconfig 명령어를 사용한다. 일반적으로 30%가 넘어가면 Rebuild 한다. 실제 튜닝할때 경우 인덱스가 설정된 칼럼에 대한 쿼리를 함에도 불구하고 Full Scan을 하는경우가 있다. 이럴 경우에는 인덱스 리빌드 및 DBCC INDEXDEFRAG를 통해 성능을 향상시킬 수 있다.

DB 공부하기 1번째 : 선언적 데이터 무결성(Declarative Data Integrity) (http://maystyle.tistory.com/218)
DB 공부하기 2번째 : 트랜잭션 프로세싱

트랜잭션 프로세싱은 SQL 서버의 일관성과 복구 가능성을 보증하는 기능으로 SQL 서버 작업의 기본 단위이다. 모든 트랜잭션은 Commit 명령어가 실행되기 전까지 업데이트되지 않는다.

모든 트랜젝션은 ACID 속성을 갖는다.

원자성(Atomicity)
트랜잭션의 내용은 모두 Commit 되거나 Rollback 된다.

일관성(Consistencuy)
만약 송금 업무가 트랜잭션으로 발생할 경우 송금자의 계좌에서 빠져 나간 금액은 수금자의 계자에 입금된 금액과 일치해야 한다.

격리성(Isolation)
트랜잭션들은 서로 완벽하게 격리되어 다른 트랜잭션으로 부터 영향을 받지 않는다. SQL 2000의 경우  Update 혹은 Insert 등의 데이터 변환일 일어날 경우 with no lock 구믄을 사용하면 Select 시 트랜젝션이 종료 되지 않은 데이터가 읽어지는 현상이 있었다. 이는 격리성을 위반한 것으로 SQL 2005에서는 스냅샷 격리기능을 통하여, 위의 기능에 대한 격리성까지 지원 하고 있다.

영속성(Durability)
트랜잭션이 진행 되는 동안 (commit 이전)에 데이터베이스에 정전이 일어났을 경우 데이터베이스는 해당 트랜잭션을 반영하지 않는다. 반면에 Commit이 된 이후라면 반영하게 된다.

도메인 무결성 (Domain Integrity) : 열에 저장되는 값들은 일관성을 가져야 하며, 업무 규칙에 부합되어야 한다. 도메인 무결성은 가 열에서 수용 가능한 값을 지정해 주는  Check같은 제약 조건을 기본으로 가진다.
주 1 Check 제약 조건 : 제약 조건으로 지정된 기준을 만족시키는 값을 넣어야 한다. 데이터베이스 개발자는 양수값만 들어오게 Check 제약 조건을 정의 할 수 있다.

엔티티 무결성 (entity integrity) : 행(Row)에 저장된 정보를 참조한다. (테이블에 있는 각 행은 테이블을 설명하는 하나의 엔티티 유형에 관한 정보를 저장한다.) 이 유형의 제약 조건에서는 테이블 내에 있는 행에 저장된 정보가 일관성을 유지하고 지정된 규칙을 따르도록 해야한다. 예를 들면 각각의 행은 반드시 같은 수의 열을 보함해야 한다. (어떤 값은 빈곳으로 남겨두더라도) 좀 더 설명하도록 하겠다. 관계형 데이터베이스 이론의 핵심은 모든 관계의 모든 튜플(Tuple)(모든 테이블의 모든 행)이 고유하게 식별 될 수 있다는 것이다. 유일성을 보증하는 속성이나 속성들의 조합 (칼럼이나 칼럼들의 조합)을 "기본키"라고 부른다. 테이블은 한개의 기본키만을 가질 수 있다. 테이블을 정의할 때 키본키를 구성하는 칼럼들을 지정할 수 있다. 이를 Primary key 제약이라 부른다. 이렇게 기본키를 사용함으로써 테이블의 엔티티 무결성이 파괴되는것을 막는다. 물론 가끔 여러 칼럼들이 행을 고유하게 식별할 수 있다. 예를 들어 , employee 테이블은 ID, 주민번호 칼럼을 갖고 있을 수 있고, 이 칼럼들의 값들이 모두 유일한 값을 갖는다고 생각 할 수 있다. 이 키들을 대체키(alternate key) 또는 후보키 (candidate key) 라고 부른다.

참조 무결성(referential integrity) : 참조 무결성은 테이블 사이에 적용되며 이들 개체 간에 포함된 정보는 일관성을 유지되도록 해야 한다. 참조 무결성은 테이블들 사이의 관계를 포함한다. 테이블 사이에 대응하는 실제 열은 외래 키와 기본키를 참조한다.