오늘도 역시 할일 없이 다른 분들 블로그를 뒤적 거리다가 좋은 툴을 하나 발견했습니다.
항상 '위시'님 감사합니다...^__^v
원문 : http://wishy.net/forum/2823#0

Microsoft SQL Server Database Publishing Wizard 라는 툴인데, 현재의 DB를 Target (스크립트)를 실행 시킬 DB에 맞춰 SQL 스크립트로 뽑아주거나 직접 게시해 줍니다. (조만간에 TEST를 해봐야 겠네요...^^)
음... DTS 나 SSIS 를 쓰는게 편하지 않나 하시겠지만... 아무튼 다양성 측면에서...^^

다운 로드 : http://www.microsoft.com/downloads/details.aspx?FamilyID=56e5b1c5-bf17-42e0-a410-371a838e570a&DisplayLang=ko

<출처 : 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. 트랜잭션 로그의 기록과 복구 (http://maystyle.tistory.com/225)
5. 데이터 파일이 커질 때는 무슨일이 일어날까? (http://maystyle.tistory.com/231)
6. 데이터 파일은 어떻게 생겼을까?

데이터 파일의 구조는 각 8K 단위의 페이지로 이루어져 있다. 그리고 5번째 페이지 (4번 페이지) 부터 사용자 데이터가 입력되어, 4G 될때까지 데이터가 저장되고 다시 GAM 페이지와 SGAM 페이지가 저장되고 다시 사용자 데이터가 저장되는 순으로 저장되게 된다.

                                                                                                                    데이터 파일 구조

데이터베이스 파일의 기본 단위는 페이지(8KB)다. 이 공간은 익스텐트(extent)라고 불리는 단위로 관리된다. 한 익스텐트는 연속된 8개의 페이지(64KB)들로 구성되어 있다. SQL Server는 좀더 효율적인 공간 할당을 위해 작은 양의 데이터를 갖고 있는 테이블에 익스텐트 전체를 할당하지 않는다. SQL Server는 두 가지 유형의 익스텐트를 갖고 있다.
- 균일 익스텐트 : 한 개체만이 이것들을 소유한다. 익스텐트에 있는 8개의 페이지들은 소유하고 있는 개체에 의해서만 사용될 수 있다.
- 혼합 익스텐트 : 여러 개체들에 의해 공유 될 수 있다. (8 개체까지 공유할 수 있다.)

SQL Server는 혼합 익스텐트에서 새 테이블이나 익덱스를 위한 페이지들을 할당한다. 테이블이나 인덱스가 8페이지로 성장할때, 앞으로 이루어지는 모든 할당은 균일 익스텐트를 사용한다.

테이블이나 인덱스가 더 많은 공간을 필요로 할 때 SQL Server 는 할당될 수 있는 공간을 찾을 필요가 있다. 테이블이나 인덱스가 여전히 8페이지 보다 작으면 SQL Server가 여유 공간이 있는 혼합 익스텐트를 찾아야 한다. 테이블이나 인덱스가 8페이지이거나 이보다 크면 SQL Server가 균일 익스텐트를 찾아야 한다.

SQL Server는 어떤 익스텐트들이 할당되었고 이것들이 어떤 유형으로 사용되고 있는지를 기록하기 위해 특별한 두 가지 유형의 페이지들을 사용한다.
- 전역 할당 맵(GAM) 페이지 : 이 페이지는 어떤 익스텐트가 어떤 유형으로 사용되기 위해 할당되었는지를 기록한다. GAM은 각 익스텐트에 대해 비트 값을 갖고 있다. 이 비트가 0이면 대응하는 익스텐트가 사용중이고, 1이면 익스텐트가 사용중이지 않다. 페이지에서 헤더나 다른 오버헤드 뒤에 거의 8000바이트(64000비트)가 있기 때문에 각 GAM은 약 64,000 익스텐트(4GB)를 처리 할 수 있다.
- 공유 전역 할당 맵(SGAM) 페이지 : 이 페이지는 어떤 익스텐트들이 현재 혼합 익스텐트로 사용되고 있고 적어도 한 개의 사용되지 않는 페이지를 갖고 있는지 기록한다. GAM처럼 각 SGAM들도 약 64,000개의 익스텐트를 다룬다. SGAM은 각 익스텐트에 대한 비트를 갖고 있다. 이 비트가 1이면 익스텐트가 혼합 익스텐트로 사용되고 있고 여유 페이지를 갖고 있다. 0이면 익스텐트가 혼합 익스텐트로 사용되지 않거나, 모든 페이지들이 사용중인 혼합 익스텐트다.

SQL Server가 전혀 사용되지 않은 새 익스텐트를 찾을 필요가 있으면 GAM 페이지에서 비트 값 1을 가진 익스텐트를 사용할 수 있다. 여유 공간이 있는 혼합 익스텐트를 찾을 필요가 있으면 GAM 값이 0이고 SGAM 값이 1인 익스텐트를 찾는다.

GAM이 항상 데이터베이스 파일에서 세변째 페이지이기 때문에 (0, 1, 2 <--) SQL Server가 파일에서 GAM을 빠르게 찾을 수 있다. SGAM은 4번째 페이지이다. (0, 1, 2, 3 <--) 2번 페이지에 있는 첫번째  GAM 이후에 511,230 페이지마다 GAM이 나오고, 3번 페이지에 있는 첫번째 SGAM 이후에 511,230 페이지 마다 SGAM이 나온다. 파일에 있는 0번 페이지는 "파일 헤더" 페이지이고, 파일마다 파일 헤더 페이지가 한 개만 존재한다. 1번 페이지는 "페이지 여유 공간(PFS)" 페이지다.

인덱스 할당 맵(IAM) 페이지는 힙이나 인덱스에 의해 사용되는 데이터베이스 파일의 익스텐트를 매핑한다. (힙은 클러스터된 인덱스가 없는 테이블이다.) 힙이나 인덱스는 개체에 할당된 모든 익스텐트들을 기록하는 한개 이상의 IAM 페이지를 갖고 있다. 힙이나 인덱스는 익스텐트를 갖고 있는 각 파일 마다 적어도 한개의 IAM을 갖고 있다. 익스텐트 범위가 IAM이 기록할 수 있는 범위를 넘어서면 힙이나 인덱스는 파일에서 여러 개의 IAM을 가질 수 있다.

IAM는 작은 헤더와 8개의 페이지 포인터 슬롯과 익스텐트 범위를 파일로 매핑하는 비트들을 갖고 있다. 해더는 IAM에 의해 매핑되는 범위에 있는 첫번째 익스텐트의 주소를 갖고 있다. 8개의 페이지 포인터 슬롯은 관련 개체들에 속해 있고 혼합 익스텐트에 들어 있는 페이지들에 대한 포인터를 갖고 있다. 개체에 대한 첫번째  IAM만이 이 포인터들을 갖고 있따. 일단 개체가 9개 이상의 페이지를 차지하면 모든 익스텐트들이 균일 익스텐트이다. 즉, 개체가 혼합 익스텐트에 있는 페이지들을 가르키는 9개 이상의 포인터들을 결코 필요로 하지 않을 것이다. 테이블에서 행들이 삭제되면 테이블이 실제로 8개 미만의 포인터들을 사용할 수 있다. 익스텐트가 IAM을 소유하고 있는 개체에 할당되든지 그렇지 않든 간에, 비트맵의 각 비트들은 범위에 있는 익스텐트를 나타낸다. 비트가 OFF이면 관련 익스텐트가 IAM을 소유하고 있는 개체에 할당되지 않는다. 예를 들어 IAM의 첫번째 바이트에 있는 비트 패턴이 1100 0000이면 IAM의 범위에 있는 첫번째 익스텐트와 두번째 익스텐트가 IAM을 소유하고 있는 개체에 할당되고, 3~8번은 IAM을 소유하고 있는 개체에 할당되지 않는다.

IAM 페이지는 필요할 때 각 개체에 할당되고, 데이터베이스 파일에 무작위로 위치한다. 각 IAM들이 처리할 수 있는 범위는 약  512,000페이지 이다. Sysindexs.FirstIAM은 개체에 대한 첫번째 IAM 페이지를 가리킨다. 이 개체에 대한 모든 IAM 페이지들은 체인으로 연결되어 있다.(IAM은 논리적 연결만 가지고 있다.)

일단 익스텐트가 개체에 할당되면 SQL Server가 새 데이터를 삽입하기 위해 이 익스텐트에 있는 페이지들을 사용할 수있다. 데이터가 B 트리에 삽입되게 되어 있다면 새 데이터의 위치는 B 트리 내의 정렬 순서에 의해 결정된다. 데이터가 입에 삽이되게 되어 있다면 데이터는 아무 여유 공간에나 삽입될 수 있다. 파일 내에 있는 PFS 페이지는 각 페이지들의 할당 여부와 각 페이지에 있는 여유 공간 크기를 기록한다. 각 PFS 페이지들은 8088개의 연속된 페이지들 (약 64MB)을 처리한다. 각 페이지에 대해 PFS는 페이지가 비었는지, 1~50% 찼는지, 51~80%가 찼지는, 81~95%가 찼는지, 96~100%가 찼는지를 기록하는 1 바이트를 갖고 있다. SQL Server는 새로 삽입된 행을 보관할 수 있는 여유 공간이 있는 페이지를 찾을 필요가 있을 때 이 정보를 사용한다. 파일의 두번째 페이지와 이후에 8088번째 마다 나오는 페이지들이 PFS 이다.

데이터 파일 내에는 두 가지 다른 종류의 특별한 페이지들도 있다. 일곱번째 페이지(6번 페이지)는 DCM(Differential Changed Map) 페이지라고 불리고, 데이터베이스 전체 백업 이후 파일의 어떤 익스텐트들이 변경되어 있는지 추적한다.. 파일의 열번째 페이지(7번 페이지)는 BCM(Bulk Changed Map) 페이지라고 불리고, 파일에 있는 익스텐트가 최소한으로 또는 대량 로그 동작으로 사용할 때 사용된다. 역시 511,230페이지 마다 나타난다.

이전에 덤프 생성에 대한 포스트(http://maystyle.tistory.com/198)를 올린 적이 있습니다.
시스템에  Blue Screen 이 떴는데... 덤프가 발생하지 않으면 참... 난감합니다.
다음은 그런 사례 중 하나 입니다.

원래 덤프는 디바이스 드라이버를 통하지 않고 직접 쓰게 됩니다.
문제는 함부로 막 쓰게 되면 기존의 데이터를 덮어쓰거나 하는 등의 문제를 발생시킬 수도 있고, I/O의 확실성이 보장 되지 않은 경우 생성된 덤프가 무의미 해 질 수도 있을껍니다. (제 예상입니다...^^V)

그렇기 때문에 시스템은 부팅시 자신의 시스템 상태를 저장해 놓고 덤프를 생성 시키기 전 원 상태와 비교한 후 덤프를 만들지 말지를 결정하게 되는거죠...

보통 CPU, Memory, Disk, 보드의 I/O에 이상이 있을 시 덤프가 생성 되지 않습니다. 물론 블러스터 웜 바이러스(RPC 서버가 죽었습니다. 6008 오류)에 걸렸을 가능성도 있습니다.

현상 : 0x7A, 0xC0000185 (기타 파라메터는 아래를 참조하시기 바랍니다.)
해결 방법 :
하드웨어 문제라 가정할 시 Paging 파일이 위치하는 SCSI disk, the disk cabling and SCSI termination 을 모두 검사를 합니다. 물론 RAM에 문제가 있을 경우도 전반적인 0x7A가 뜨게 됩니다. 자세한 내용은 아래를 참조하세요.

출처 : http://www.osronline.com/DDKx/ddtools/bccodes_2vjb.htm

The KERNEL_DATA_INPAGE_ERROR bug check has a value of 0x0000007A. This indicates that the requested page of kernel data from the paging file could not be read into memory.

Parameters
The four parameters listed in the message can have two possible meanings. If the first parameter is one, two, or three, the following definitions should be used:

Parameter Description
1 Lock type that was held (1, 2, or 3)
2 Error status (usually an I/O status code) 
3 If Lock Type is 1 or 2: current process
If Lock Type is 3: virtual address
4 Virtual address that could not be paged into memory

Otherwise, use the following definitions:

Parameter Description
1 Page Table Entry (PTE) address
2 Error status (usually an I/O status code) 
3 Virtual address
4 Virtual address that could not be paged into memory

Cause
Frequently, the cause of this error can be determined from the error status (Parameter 2). Some common status codes are:

0xC000009A, or STATUS_INSUFFICIENT_RESOURCES, is caused by lack of nonpaged pool resources.
0xC000009C, or STATUS_DEVICE_DATA_ERROR, is typically due to bad blocks (sectors) on the hard disk.
0xC000009D, or STATUS_DEVICE_NOT_CONNECTED, indicates defective or loose cabling, termination, or the controller not seeing the hard disk.
0xC000016A, or STATUS_DISK_OPERATION_FAILED, is also caused by bad blocks (sectors) on the hard disk.
0xC0000185, or STATUS_IO_DEVICE_ERROR, is caused by improper termination or defective cabling on SCSI devices, or two devices attempting to use the same IRQ.
These codes are the most common ones for which specific causes have been determined. For information about other possible status codes that can be returned, see the file ntstatus.h in the Windows DDK.

Another common cause of this error message is defective hardware or failing RAM.

This bug check can also be caused by a virus infection.

Resolving the Problem
Resolving a bad block problem: An I/O status code of 0xC000009C or 0xC000016A normally indicates that the data could not be read from the disk due to a bad block (sector). If you can restart the system after the error, Autochk runs automatically and attempts to map the bad sector to prevent it’s further use.
If Autochk does not scan the hard disk for errors, you can manually launch the disk scanner. Run Chkdsk /f /r on the system partition. You must restart the system before the disk scan begins. If you cannot start the system due to the error, use the Recovery Console and run Chkdsk /r.
Warning  If your system partition is formatted with the FAT file system, the long filenames used by Windows can be damaged if Scandisk or another MS-DOS-based hard disk tool is used to verify the integrity of your hard disk from MS-DOS. Always use the version of Chkdsk that matches your Windows version.
Resolving a defective hardware problem: If the I/O status is C0000185 and the paging file is on an SCSI disk, the disk cabling and SCSI termination should be checked for problems.
Resolving a failing RAM problem: Run the hardware diagnostics supplied by the system manufacturer, especially the memory scanner. For details on these procedures, see the owner’s manual for your computer.
Check that all the adapter cards in the computer are properly seated. Use an ink eraser or an electrical contact treatment, available at electronics supply stores, to ensure adapter card contacts are clean.
Check the System Log in Event Viewer for additional error messages that might help pinpoint the device that is causing the error. Disabling memory caching of the BIOS might also resolve this error.
Make sure that the latest Windows Service Pack is installed.
If the preceding steps fail to resolve the error, take the system motherboard to a repair facility for diagnostic testing. A crack, a scratched trace, or a defective component on the motherboard can cause this error.
Resolving a virus infection: You should check your computer for viruses using any up-to-date, commercial virus scanning software that examines the Master Boot Record of the hard disk. All Windows file systems can be infected by viruses.

See Also
Bug Check 0x77 (KERNEL_STACK_INPAGE_ERROR)

Built on Friday, April 11, 2003

출처 : 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. 트랜잭션 로그의 기록과 복구 (http://maystyle.tistory.com/225)
5. 데이터 파일이 커질 때는 무슨일이 일어날까?

데이터베이스는 테이블 및 인덱스와 같은 사용자의 개체들의 영구적 저장소로 사용될 사용자 정의 공간으로 구성되어 있다. 이 공간은 운영체제 파일에 할당된다.

데이터베이스는 논리적 페이지(8K)로 나눠어져 있고, 각 파일 내에서 페이지들은 0 부터 x까지 연속적으로 번호가 매겨져 있다. 상한 값 x에는 데이터 베이스 ID, 파일 ID, 페이지 번호를 지정함으로써 어떤 페이지든 참조 할 수 있다. 만약 데이터가 꽉차서 새로운 공간이 추가 된다면 이는 x+1 페이지가 된다. 그리고 DBCC Shrinkdatabase 및 DBCC  Shrinkfile 명령어를 통해 데이터베이스를 축소 시킬 경우 페이지들은 가장 번호가 높은  페이지 부터 순서대로 제거 되어 항상 연속적으로 저장되도록 한다.

create database 를 통해 새 데이터베이스를 만들 때 고유한 dbid 가 주어지고, 이 데이터베이스에 대한 새 행이 master..sysdatabases  테이블에 삽입 된다.

 
name : 데이터베이스 이름
dbid : 고유한 데이터베이스ID, 데이터베이스가 삭제될 때 다시 사용될 수 있다.
sid : 데이터베이스 생성자 ID
mode : 잠금 모드
status : DB가 읽기 전용인지, 오프라인 상태인지 단일 사용자 모드인지를 알려주는 비트 마스크의 일부
status2 : 역시 데이터베이스 옵션

하지만 대충 DB들을 살펴보기는 Sp_helpdb 가 편하다.

status를 굳이 볼 필요가 없는게. 다 풀어서 알려준다.

http://msdn.microsoft.com/msdnmag/default.aspx
MSDN 메거진 입니다.
정말 주옥 같은 기사들이 많이 있습니다.

http://wishy.net 에서 NLBS 구현 시 참조해야할 MS KB 목록을 정리해 주셨습니다.
이전에 NLBS에 대해 올린 제 글이 있습니다. (http://maystyle.tistory.com/108)
간략한 소개와 문재 발생 시 대처 방법에 대한 KB 소개를 해드렸었죠.
거기에 wishy 님이 올려주신 자료를 첨가합니다.

193602 Configuration options for WLBS hosts connected to layer 2 switches
http://support.microsoft.com/?id=193602
303765 HOW TO: Perform Advanced Network Load Balancing Procedures in Windows
http://support.microsoft.com/?id=303765
323431 How To Set Up TCP/IP for Network Load Balancing in Windows Server
2003
http://support.microsoft.com/?id=323431
Network Load Balancing : Configuration Best Practices for Windows 2000 and
Windows Server 2003
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/clus
tering/nlbbp.mspx
NLB Troubleshooting Overview for Windows? Server 2003
http://www.microsoft.com/downloads/details.aspx?FamilyId=9E6F4999-AEEB-40CF-867B
-AF68742FFFDC&displaylang=en
197992 How to Configure WLBS Using a Single Network Interface Card
http://support.microsoft.com/?id=197992
197999 Single network interface card limitations with WLBS
http://support.microsoft.com/?id=197999
256124 HOW TO: Configure an IP Address for NLB with One Network Adapter
http://support.microsoft.com/?id=256124

보통은 TPC 측정 값을 기준으로 산정을 합니다.
물론 성능 데이터를 토대로 해당 모듈에 대한 부하를 측정하고, 업체로 부터 보정치를 받아 산술 연산을 하기도 하죠... (간간히 않 내놓는 업체들도...)

하지만 가장 정확한 방법은 실질적으로 서버에 로드를 줘서 TEST 하는 것입니다.
보통 해당 툴로 로드 런너 등의 툴이 사용되죠...^^

다음 MS에서 제공 되는 스트레스 테스트 툴입니다.

1. Web Application :  VS 2005에 들어있는 ACT
2. Exchange : Loadsim Exchange
3. SQL : Loadsim SQL
4. Terminal Service : Loadsim TS
5. Web : Loadsim Web
6. Media Service : Loadsim

이전 포스트 (http://maystyle.tistory.com/226)에서 잘못이 지적되서 고치고 싶어서 다시 글을 씁니다.

 
(tpc.org 에서 2007년 1월 ~ 현재까지의 Microsoft SQL 2005 서버를 기준으로 TPC를 측정)

위 그림을 볼때 동일 소켓 (프로세서) 대비 동일 코어 일 경우 HP Integrity rx6600가 HP ProLiant ML570G4 에 비해 TPC가 우수함을 알 수 있습니다. 물론 비용 대비 또한 우수합니다. 그런데 DL 580G5가 오히려 둘을 상회 함도 확인이 가능합니다. 음... 클럭속도와 Core 갯수의 승리 일까요...

즉 아주 미션 크리티컬 하고 대용량의 多 소켓이 아닌 이상은... IA 64가 의미가 없군요... 다만 IBM이나 유니시스와 동일 스팩의 IA64 자료가 없다는게 아쉽습니다. (IA 64의 경우 64 소켓 (프로세서) 128 코어 까지 지원됩니다.)

제가 알기로 L3 케쉬를 많이 쓰는 SQL Server 특성상 IA64가 좀 더 유리한 것으로 알고 있읍니다. 그와 더둘어 x64 보다 소켓이 늘어날 수록 성능 향상 폭이 크다는 점 그리고 설계 때부터 성능에 치중해서 설계 되었다는 장점을 통해 더 우수할거라 생각합니다. 하지만 요즘에 추세를 보면 꼭 그렇지도 않는 것 같습니다.
(예를 들면 인터럽트 처리만 하더라도 IA 64는 SAPIC를 통해 성능 향상에 신경을 썼다는 점이죠...^^v
x64는 x86과 동일한 인터럽트 컨트롤러를 제공해야 했기 때문에 하위 호환성이라는 제약을 가지고 있습니다. )
아쉬운 점은 2007년 이전 자료에서는 확실히 IA64가 우수하지만 2007년 이후로 TPC가 측정된 사례가 없다는 점이 아쉽군요... (MS SQL Server 의 경우) 게다가 多 소켓 자료... (프로세서) 또한 없네요...;;; 그리고 CPU 역시 최신이 아닌 IA64 9050 기반이네요... 9000의 경우 약 10~20 퍼센트 정도 향상된 성능을 보이는데... 주절 주절이였습니다.