 TechNet Magazine March 2007
TechNet Magazine March 2007
MARCH 2007
SQL Server

SQL SERVER 튜닝

이번 TechNet Magazine에서는 SQL Server를 중심으로 살펴봅니다. 이번 호에서는 특히 SQL Server를 보다 효율적으로 활용하는 방법에 대해 자세히 다루며 인덱스를 적절한 상태로 유지 관리하여 SQL Server에서 더욱 신속하게 쿼리를 수행하고 필요한 모든 정보를 간편하게 관리하는 방법에 대해 알아봅니다.

SQL Server 클러스터링을 통해 여분의 가용성을 제공하고 가동 시간을 늘리는 방법에 대해 알아봅니다. 또한 사용자의 환경에서 고가용성이 갖는 의미와 이를 달성하는 방법에 대해 살펴봅니다. 마지막으로 테이블 분할 문제를 완벽하게 해결하는 방법도 확인합니다.

Windows Administration

Mark Russinovich는 이번 호에서도 Windows Vista 커널의 향상된 기능에 대해 조명합니다.
주요 기사
SQL Server 인덱스 상태를 진단하기 위한 새로운 도구

SQL Server의 성능을 최대로 끌어 올리려면 인덱스를 검토하고 적절한 상태로 유지 관리해야 합니다. 새로운 동적 관리 뷰 및 함수를 사용하면 SQL Server 인덱스의 작동 방법을 보다 잘 이해하고 잠재적 성능 문제를 보다 쉽게 찾을 수 있습니다.

Randy Dyess SQL Server의 고가용성 실현

SQL Server 2005에는 복제, 클러스터링 및 로그 전달을 포함하여 데이터베이스 가용성을 높여 주는 다양한 옵션이 있습니다. 이 문서에서는 다양한 SQL Server 구성 옵션에 대해 자세히 살펴보고 사용자의 환경에 적합한 구성을 찾는 방법에 대해 알아볼 것입니다.

Zach Nichter 테이블 파티션을 사용한 데이터베이스 유지 관리 단순화

과거에는 파티션 작업과 대용량 테이블 작업이 매우 어렵고 귀찮은 작업이었지만 SQL Server 2005를 사용하면 테이블 분할 작업을 훨씬 쉽게 수행할 수 있습니다. 이제는 간편하게 복수 파티션을 만들고, 파티션을 이동하고, 기존 파티션을 제거할 수 있을 뿐만 아니라 데이터의 분할 방법까지도 바꿀 수 있습니다. 이 문서에서 자세한 방법을 살펴봅니다.

Noah Gomez SQL Server 클러스터링에 유용한 정보

서버 클러스터의 장애 조치 기능으로 중요한 작업을 중단 없이 실행할 수 있습니다. 하지만 클러스터를 효과적으로 사용하려면 적절한 구현이 필요합니다. 이 칼럼에서는 클러스터의 속도를 높이고 안정적으로 실행하는 데 도움이 되는 몇 가지 유용한 정보를 제공합니다.

Tom Moreau, PhD Windows Administration Windows Vista 커널 속으로: 2부

이번 달에도 계속해서 Windows Vista 커널의 새로운 기능에 대해 자세하게 살펴봅니다. 이번 호에서는 Windows Vista 메모리 관리 방식의 몇 가지 개선점을 알아보고 시스템 시작, 종료 및 전원 관리 영역에 대해 설명합니다.

Mark Russinovich
칼럼
From The Editor

트로피 진열장

Joshua Trupin Toolbox

IT 전문가를 위한 새로운 제품

Greg Steen Utility Spotlight

SyncToy

Jay Munro SQL Q&A

일광 절약 시간제, 서버 메모리 및 기타

편집자: Nancy Michell The Cable Guy

DHCPv6 프로토콜

Joseph Davies Windows Powershell

변수의 강력한 기능

Don Jones 		Hey, Scripting Guy!

Scripting Guys의 OU에 대한 고찰 - 5센트를 위하여!

The Microsoft Scripting Guys Exchange Queue & A

트랜잭션 로그, Cmdlet, 원격 관리 및 기타 기능

KC Lemson 및 Nino Bilic Security Watch

EFS 배포: 2부

John Morello The Desktop Files

PsTools 입문서

Wes Miller Inside Microsoft.com

데이터베이스 미러링 시작하기

Saleem Hakani Field Notes

의사는 진료 중!

Matt Hester Windows Confidential

수준을 낮춰서 수준을 높임

Raymond Chen


 SQL Server: 인덱스 상태를 진단하기 위한 새로운 도구
SQL Server Randy Dyess

인덱스 상태를 진단하기 위한 새로운 도구
한 눈에 보기:
  • 인덱스 조각화
  • 인덱스 사용률
  • 인덱스 실행 작업
이 기사의 코드 다운로드: DyessSQLIndex2007_03.exe (151KB)

SQL Server 성능 조정 검사 목록에 포함되는 상위 10개 항목 중 하나가 바로 데이터베이스의 인덱스를 조정하는 작업입니다. 쿼리를 실행하는 동안 인덱스를 적절하게 사용하는 SQL Server 쿼리 최적화 프로그램의 성능은 효과적인 인덱스의 생성뿐만 아니라 인덱스의 상태에 따라서도 달라집니다.
데이터베이스 관리자는 SQL Server™ 2005에 도입된 일련의 DMV(동적 관리 뷰)와 DMF(동적 관리 함수)를 사용하여 인덱스가 효율적인지 여부를 판단하고 성능 문제를 발견할 수 있습니다.
DMV와 DMF를 사용하면 서버를 관찰하고 서버 상태 정보를 확인하여 서버 인스턴스의 상태와 성능을 모니터링하고 문제를 진단할 수 있습니다. 이전 버전의 SQL Server에 친숙한 데이터베이스 관리자라면 이러한 DMV와 DMF가 DBCC 명령을 사용하고 특정 시스템 저장 프로시저를 실행하고 다양한 시스템 테이블을 쿼리하고 SQL 프로파일러를 사용하여 이벤트를 캡처하는 등의 작업을 대체하게 되리라는 사실을 알 수 있을 것입니다.
세 가지 주요 함수와 뷰 sys.dm_db_index_physical_stats, sys.dm_db_index_usage_stats 및 sys.dm_db_index_operational_stats를 사용하면 인덱스가 예상대로 작동하는지를 알 수 있습니다. 이러한 뷰와 함수를 사용하면 인덱스의 I/O와 잠금 패턴을 검토하고, 쿼리 최적화 프로그램이 인덱스를 활용할 때 데이터베이스에서 불필요한 경합이 발생하지 않는지 확인할 수 있습니다.

인덱스 조각화
sys.dm_db_index_physical_stats DMF는 DBCC SHOWCONTIG를 대체할 목적으로 만들어졌으며 인덱스의 조각화 정보를 보여 줍니다. 하지만 해당 인덱스가 포함된 테이블에 공유 잠금(S)을 설정하는 DBCC SHOWCONTIG와는 달리 sys.dm_db_index_physical_stats는 의도 공유 잠금(IS)만 설정함으로써 함수가 실행되는 동안 테이블 차단을 대폭 줄입니다.
sys.dm_db_index_physical_stats를 사용하여 인덱스의 조각화 정보를 확인하려면 함수 출력의 세 열을 함께 검토해야 합니다. 인덱스의 논리적 조각화 정보(힙의 익스텐트 조각화)는 avg_fragmentation_in_percent 열에 반환된 값을 통해 확인할 수 있습니다. 논리적 조각화는 인덱스의 리프 수준에서 순서가 잘못된 페이지 수에 대한 백분율인 반면 익스텐트 조각화는 인덱스의 리프 수준에서 순서가 잘못된 익스텐트에 대한 백분율입니다. 논리적 조각화와 익스텐트 조각화가 발생하면 페이지를 순서대로 읽기 위해 디스크 헤드가 페이지를 건너뛰어야 하기 때문에 추가 I/O 및 디스크 헤드 이동을 유발하여 인덱스 성능에 영향을 줄 수 있습니다. 따라서 논리적 조각화와 익스텐트 조각화는 가능하면 모두 0에 가깝게 유지해야 합니다.
인덱스의 내부 조각화는 페이지 사용률을 나타냅니다. 인덱스 페이지가 가능한 한 꽉 차도록 설정할 수도 있지만 페이지 분할 수를 절대 최소값으로 유지하려면 페이지 사용률과 인덱스 페이지에 대한 삽입 수가 적절한 균형을 이루도록 설정해야 합니다.
인덱스 페이지 사용률을 확인하려면 sys.dm_db_index_physical_stats의 avg_page_space_used_in_percent 인수를 검토합니다. 이 수치가 100%에 얼마나 가깝게 되도록 허용할지를 적절하게 구성하려면 인덱스 채우기 비율을 조정하면서 이때 발생하는 페이지 분할 수를 관찰합니다. 특정 시점에 페이지 분할 수가 급격하게 증가하기 시작하면 인덱스 채우기 비율이 적정 수준보다 높게 설정되었음을 나타냅니다. 인덱스 채우기 비율을 조정하는 데는 적지 않은 시간과 테스트가 필요하므로 계획을 적절히 세운 후에 수행하는 것이 좋습니다. 인덱스에 대한 임의 삽입이 없는 인덱스의 경우 페이지 분할 수가 증가하지 않으므로 채우기 비율을 100으로 설정할 수 있습니다.
AdventureWorks.HumanResources.Employee 테이블에 있는 모든 인덱스의 조각화 수준을 확인하려면 다음과 같은 문을 사용합니다.
SELECT *
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,OBJECT_ID('HumanResources.Employee')
,NULL
-- NULL to view all indexes;
-- otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') -- We want all information
이 DMF를 사용하면 다시 만들어야 할 인덱스, 다시 구성해야 할 인덱스 및 유지 관리가 필요하지 않은 인덱스를 자동으로 결정할 수 있습니다. 인덱스 조각화 정보를 보여 주는 이 DMF의 avg_page_space_used_in_percent 및 avg_fragmentation_in_percent 열에서 허용되는 논리 및 밀도 임계값을 벗어나는 값을 검토하면 인덱스에 필요한 작업이 무엇인지 쉽게 확인할 수 있습니다.
인덱스 상태에 따라 그림 1의 예제가 AdventureWorks 샘플 데이터베이스 복사본에 있는 데이터를 반환하지 않는 경우도 있을 수 있지만, 이 예제는 다른 데이터베이스에도 쉽게 적용할 수 있습니다.
Figure 1 페이지 사용률 및 조각화 검토 (Close Figure 1)
--Reorganize the following indexes in the AdventureWorks database
USE AdventureWorks
GO

SELECT OBJECT_NAME([object_id]) AS 'Table Name',
index_id AS 'Index ID'
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,NULL -- NULL to view all tables
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') --We want all information
WHERE ((avg_fragmentation_in_percent > 10
AND avg_fragmentation_in_percent < 15) -- Logical fragmentation
OR (avg_page_space_used_in_percent < 75
AND avg_page_space_used_in_percent > 60)) --Page density
AND page_count > 8 -- We do not want indexes less than 1 extent in size
AND index_id NOT IN (0) --Only clustered and nonclustered indexes

--Rebuild the following indexes in the AdventureWorks database
USE AdventureWorks
GO

SELECT OBJECT_NAME([object_id]) AS 'Table Name',
index_id AS 'Index ID'
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,NULL -- NULL to view all tables
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') --We want all information
WHERE ((avg_fragmentation_in_percent > 15) -- Logical fragmentation
OR (avg_page_space_used_in_percent < 60)) --Page density
AND page_count > 8 -- We do not want indexes less than 1 extent in size
AND index_id NOT IN (0) --Only clustered and nonclustered indexes
쿼리 결과를 테이블 변수에 저장한 다음 테이블 변수에 대해 루프를 실행하여 올바른 ALTER INDEX 문에 대한 동적 문자열을 만드는 것은 쉽습니다(그림 2 참조).
Figure 2 동적 ALTER INDEX 문자열 만들기 (Close Figure 2)
--Rebuild the following indexes in the AdventureWorks database
USE AdventureWorks
GO

--Table to hold results
DECLARE @tablevar TABLE(lngid INT IDENTITY(1,1), objectid INT,
index_id INT)

INSERT INTO @tablevar (objectid, index_id)
SELECT [object_id],index_id
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,NULL -- NULL to view all tables
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') --We want all information
WHERE ((avg_fragmentation_in_percent > 15) -- Logical fragmentation
OR (avg_page_space_used_in_percent < 60)) --Page density
AND page_count > 8 -- We do not want indexes less than 1 extent in size
AND index_id NOT IN (0) --Only clustered and nonclustered indexes

SELECT 'ALTER INDEX ' + ind.[name] + ' ON ' + sc.[name] + '.'
+ OBJECT_NAME(objectid) + ' REBUILD'
FROM @tablevar tv
INNER JOIN sys.indexes ind
ON tv.objectid = ind.[object_id]
AND tv.index_id = ind.index_id
INNER JOIN sys.objects ob
ON tv.objectid = ob.[object_id]
INNER JOIN sys.schemas sc
ON sc.schema_id = ob.schema_id

인덱스 사용률
sys.dm_db_index_physical_stats는 인덱스 상태를 쉽게 볼 수 있도록 지원하며 DBCC SHOWCONTIG를 대체할 만큼 기능이 뛰어나기는 하지만, 테이블에 대해 실행할 쿼리에 어떤 인덱스가 유용한지를 결정하는 것과 관련해서는 더 복잡한 문제를 유발합니다. 대개 데이터베이스 개발자나 관리자는 쿼리를 실행하는 동안 쿼리 최적화 프로그램에서 사용할 것으로 예상되는 테이블에 대한 인덱스를 만듭니다. 이전 버전의 SQL Server에서는 이러한 인덱스가 실제로 사용되는지를 확인하기가 지금보다 훨씬 어려웠습니다. 이전에는 인덱스를 삭제한 다음 이것이 쿼리 성능에 영향을 주는지 관찰하거나 쿼리 실행 계획을 캡처한 다음 인덱스 사용 통계를 검토하는 방법을 이용했습니다.
그러나 이제는 새로운 동적 관리 뷰 sys.dm_db_index_usage_stats를 사용하여 쿼리 최적화 프로그램 및 테이블에 대해 실행된 쿼리에서 인덱스를 어느 정도나 사용하고 있는지를 쉽게 확인할 수 있습니다. 이 뷰를 검토하면 인덱스의 유용성을 결정하여 쿼리 최적화 프로그램에서 사용하지 않는 인덱스가 있으면 삭제할 수 있습니다. 인덱스가 저장 공간만 낭비하고 있지는 않은지, 사용되지 않는 인덱스가 유지되어 데이터베이스 성능이 저하되지 않는지에 대해 더 이상 신경 쓸 필요가 없습니다.
이 DMV의 출력에서 탐색(seek) 및 검색(scan) 횟수가 0인 인덱스를 검토하면 SQL Server를 마지막으로 시작한 이후에 인덱스가 사용되었는지 여부를 확인할 수 있습니다. 하지만 대부분의 DMV와 DMF는 지속적이지 않으며 SQL Server를 다시 시작할 때마다 0으로 다시 설정되므로 DMV나 DMF를 사용하여 인덱스 사용률을 확인할 때는 이에 유의해야 합니다. 서비스를 마지막으로 시작한 이후에는 필요하지 않지만 주말이나 월말 또는 분기별 보고서 쿼리에 인덱스가 필요할 수도 있기 때문입니다.
마지막으로 SQL Server 서비스를 시작한 이후 인스턴스의 사용되지 않은 모든 인덱스를 보려면 다음 문을 사용합니다.
SELECT DB_NAME(database_id),OBJECT_NAME([object_id])
FROM sys.dm_db_index_usage_stats
WHERE user_seeks = 0
AND user_scans = 0
AND user_lookups = 0
AND system_seeks = 0
AND system_scans = 0
AND system_lookups = 0

인덱스 실행 작업
인덱스의 작업을 이해하는 데는 sys.dm_db_index_operational_stats DMF가 매우 유용합니다. 이 DMF를 사용하면 각 인덱스에서 발생하는 I/O, 잠금, 래치 및 액세스 방법 작업을 볼 수 있으며 이를 통해 인덱스가 어떤 방식으로 사용되고 있는지를 이해하고 과도한 I/O 작업 또는 인덱스의 "핫 스폿"으로 인한 인덱스 잠금 문제를 진단할 수 있습니다.
이 DMF의 래치 대기 열을 검토하면 읽기 및 쓰기 작업이 인덱스 리소스에 액세스하는 데 필요한 시간을 설정할 수 있습니다. 또한 인덱스를 저장하는 데 사용되는 디스크 하위 시스템이 인덱스 I/O 작업에 적합한지도 확인할 수 있습니다. 이 열의 정보는 인덱스의 디자인이나 사용 방법으로 인해 하나 이상의 인덱스 페이지에서 과도한 작업이 발생하고, 그 결과 해당 페이지에 포함된 데이터에 대한 경합을 야기하는 핫 스폿이 발생하는지 여부도 나타냅니다. 이러한 경합이 발생하면 대개 해당 영역에 대해 읽기나 쓰기를 시도하는 작업이 지나치게 차단될 수 있습니다.
그림 3은 AdventureWorks.HumanResources.Employee 테이블의 모든 인덱스에 대한 잠금 및 I/O 패턴을 확인하는 방법을 보여 줍니다.
Figure 3 잠금 및 I/O 패턴 확인 (Close Figure 3)
SELECT page_latch_wait_count --page latch counts
,page_latch_wait_in_ms --page latch wait times
,row_lock_wait_in_ms --row lock wait times
,page_lock_wait_in_ms --page lock wait times
,row_lock_count --row lock counts
,page_lock_count --page lock counts
,page_io_latch_wait_count --I/O wait counts
,page_io_latch_wait_in_ms --I/O wait times
FROM sys.dm_db_index_operational_stats (DB_ID('AdventureWorks')
,OBJECT_ID('HumanResources.Employee')
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
)

추가 정보
이 문서에서 소개한 DMV와 DMF는 여기서 설명한 것 외에도 그 용도가 매우 다양합니다. 짬을 내서 이러한 함수와 뷰에 대해 설명하는 SQL Server 온라인 설명서의 기사를 읽어 보면 이들을 사용하여 반환 및 검토할 수 있는 광범위한 정보를 이해하는 데 도움이 될 것입니다. SQL Server 온라인 설명서의 관련 기사로 연결되는 링크는 아래의 "추가 리소스" 추가 기사에 나와 있습니다.
이 문서에서 설명하지 않은 추가 인덱스 DMF와 DMV에 대한 자세한 내용을 보려면 SQL Server 쿼리 최적화 팀에서 게시한 블로그 blogs.msdn.com/queryoptteam/570176.aspx를 참조하십시오.
추가 리소스
  • sys.dm_db_index_physical_stats
  • sys.dm_db_index_usage_stats
  • sys.dm_db_index_operational_stats

Randy Dyess는 Solid Quality Learning의 강사로서 SQL Server OLTP 시스템을 전문적으로 다루고 있습니다. 지금까지 SQL Server와 관련된 수많은 저서와 기사를 집필했으며 www.TransactSQL.Com과 www.Database-Security.Info의 설립자이자 주요 저자입니다.
© 2007 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..


 SQL Server: SQL Server의 고가용성 실현
SQL Server Zach Nichter

SQL Server의 고가용성 실현
한 눈에 보기:
  • 미러링
  • 데이터베이스 스냅숏
  • 로그 전달
  • 클러스터링
  • 복제
이 기사의 코드 다운로드: NichterHA2007_03.exe (151KB)

고가용성은 모든 데이터베이스 관리자가 알아야 하는 개념으로서, 시스템의 응답성과 액세스 가능성을 의미합니다. 고가용성은 초 단위의 응답 시간을 의미하기도 하지만 밀리초 단위의

응답 시간을 의미할 수도 있습니다. SQL 쿼리의 왕복 응답 시간이 밀리초 단위로 설정된 웹 서버를 사용하고 있는 회사의 자문을 맡은 적이 있습니다. 응답 시간이 이 제한 시간을 초과할 경우 데이터베이스 시스템은 다운된 것으로 간주되고 웹 서버는 사용 가능한 다음 데이터베이스 서버에 다시 연결되었습니다.
응용 프로그램의 빠른 실행을 원하는 사용자의 경우 고가용성과 빠른 응답 시간을 실현하는 방법을 알고 있으면 데이터 종속적 응용 프로그램을 현명하게 계획하는 데 많은 도움이 됩니다.
다행히 SQL Server™ 2005에는 복제, 클러스터링, 데이터베이스 미러링, 데이터베이스 스냅숏 및 데이터베이스 로그 전달을 포함하여 가용성을 높여 주는 다양한 옵션이 있습니다. 이러한 기능을 살펴보고 사용자의 환경에 적합한 기능을 결정하는 방법에 대해 알아보겠습니다. 먼저 SQL Server 2005의 가용성 옵션을 보여 주는 그림 1을 살펴보겠습니다.
Figure 1 고가용성 옵션 (Close Figure 1)

기술 특성 | 복제 | 데이터베이스 미러링 | 클러스터링 | 데이터베이스 스냅숏 | 로그 전달
고가용성 옵션 |  |  |  |  |
높은 트랜잭션 요구 사항 허용 |  |  |  |  |
실시간 데이터 가용성 |  |  |  |  |
읽기 전용인 데이터 이미지 |  |  |  |  |
고유한 하드웨어 구성 |  |  |  |  |
저렴한 비용 |  |  |  |  |
데이터 복구 제공 |  |  |  |  |
자동 장애 조치 |  |  |  |  |
잠재적으로 복잡한 구현/관리 |  |  |  |  |
가능한 성능 고려 사항 |  |  |  |  |

고가용성 정의
고가용성 응용 프로그램을 계획할 때 우선적인 목표로 고려해야 하는 사항 중 하나는 현재 자신이 속한 환경에서 고가용성이 의미하는 바를 정의하는 것입니다. 일부 조직의 경우 고가용성은 프로덕션 하드웨어와 동일한 예비 하드웨어가 있고, 데이터와 하드웨어 두 가지 모두의 가동 시간 및 가용성이 99.995% 이상이 되는 것을 의미합니다. 반면 데이터 자체의 고가용성만 필요로 하고 프로덕션 수준 성능을 위해서는 장애 조치만을 고려하는 조직도 있습니다. 고가용성 정의는 상황에 적합한 솔루션을 결정하는 데 중요합니다.
발생할 수 있는 가동 중단 유형을 식별하고 이러한 가동 중단이 서비스 수준 계약(SLA)에 어떤 영향을 주는지 나타내야 할 필요가 있습니다. 가용성에 영향을 줄 수 있는 가동 중단에는 계획된 중단, 계획되지 않은 중단 및 성능 저하가 포함됩니다.
계획된 중단은 일반적으로 예약된 유지 관리 시간대로, 시스템 사용자에게 미리 통보됩니다. 계획되지 않은 중단은 일반적으로 하드웨어 또는 소프트웨어 오류로 인해 발생하며 데이터에 액세스할 수 없게 됩니다. 성능 저하로 인해서도 중단이 발생할 수 있는데 성능 저하는 주로 최종 사용자 응답 시간으로 측정되며 일반적으로 기업뿐만 아니라 IT 조직에 의해 SLA 형태로 미리 계약됩니다.
가동 중단의 가능한 원인을 식별하는 것 외에도 데이터의 작업 수준을 결정하고 데이터가 항상 온라인 상태여야 하는지 니어라인 또는 오프라인 상태가 되어도 되는지를 결정해야 합니다. 가용성 옵션을 동일 지역 위치에 적용할지 또는 원격 위치에 적용할지도 결정해야 합니다. 예산의 규모 또한 결정을 내리는 데 중요한 고려 사항입니다. 이제 각 가용성 옵션을 살펴보겠습니다.

데이터베이스 미러링
데이터베이스 미러링에 대한 설명을 시작하기 전에 용어를 정의하겠습니다.
주 서버 는 미러 서버와 데이터베이스에 지속적으로 트랜잭션 로그를 보내는 데이터베이스가 설치되어 있는 주 프로덕션 서버입니다.
미러 서버 는 데이터베이스의 백업 사본이 설치되어 있는 보조 서버입니다. 미러 사본은 주 데이터베이스와 일관성 있게 동기화됩니다.
역할 은 특정 서버의 목적 즉, 해당 서버가 주 서버인지 미러 서버인지를 나타냅니다.
미러링 모니터 서버 는 역할을 수행하는 주 및 미러 서버를 모니터링하고 자동 장애 조치를 시작할 수 있는 인스턴스입니다.
파트너 서버 는 주 서버 또는 미러 서버가 될 수 있습니다.
일반적인 환경의 경우 주 데이터베이스는 주 인스턴스에 백업되고 백업은 미러 인스턴스에 복원됩니다(그림 2 참조). 데이터베이스가 복원된 후에는 SMSS(SQL Server Management Studio)에서 주 데이터베이스의 속성 창을 사용하거나 T-SQL 스크립트를 사용하여 주 서버에서 미러링을 설정해야 합니다.
Figure 2 Database mirroring architecture
Figure 2 Database mirroring architecture (더 작게 보려면 이미지를 클릭하십시오.)
Figure 2 Database mirroring architecture
Figure 2 Database mirroring architecture (더 크게 보려면 이미지를 클릭하십시오.)
미러링이 구성되고 미러링 세션이 설정되면 주 데이터베이스와 미러링된 데이터베이스가 동기화됩니다. 그런 다음 주 데이터베이스에서 미러 서버에 마지막 백업이 적용된 이후로 발생한 이벤트에 대한 트랜잭션 로그를 보냅니다. 미러 서버에서는 로그를 수신한 후 가능한 빨리 적용하려고 시도합니다. SQL Server 2005 Enterprise Edition을 사용하는 경우에는 이 프로세스가 다중 스레드로 처리되지만 그렇지 않은 경우에는 단일 스레드로 처리됩니다. 이러한 로그가 미러 서버에 적용되면 데이터베이스는 동기화된 것으로 간주되며 미러링된 세션이 끊길 때까지 동기화된 상태로 유지됩니다.
클라이언트에서 새 트랜잭션을 실행하면 주 서버에서 주 데이터베이스에 대한 트랜잭션이 실행되면서 트랜잭션 로그 레코드가 주 데이터베이스에서 미러링된 데이터베이스의 다시 실행 로그나 로그 큐로 전달된 후 미러링된 데이터베이스에 선택되어 적용됩니다. 미러 데이터베이스에서 트랜잭션이 적용 및 커밋되면 트랜잭션이 미러 서버에서 커밋되었음을 알리는 응답이 주 서버에 전달됩니다. 주 서버는 미러 서버의 확인 응답이 수신되기 전까지는 시스템에 적용될 수 있는 새 트랜잭션을 확인하지 않습니다.
오류가 발생할 경우 미러 서버는 자동 장애 조치를 시작할 수 있으며 미러링 모니터 서버는 주 데이터베이스를 사용할 수 있는지 여부를 확인하여 이 프로세스를 지원합니다. 오류가 발생하면 현재 미러 파트너가 된 서버에서 문제를 해결해야만 해당 서버가 다시 주 파트너가 될 수 있습니다. 미러 파트너에서 문제가 해결되면 미러 파트너 서버로 되돌아가는 프로세스가 시작되고 데이터베이스가 다시 동기화됩니다. 데이터베이스가 동기화되면 미러링 세션을 다시 시작할 수 있습니다.
이 특정 미러링 모드는 트랜잭션 안정성을 설정하여 동기 트랜잭션 작업을 제공하는 안정성이 높은 모드지만 자동 장애 조치를 사용하지 않기 때문에 즉, 모든 장애 조치를 수동으로 시작하기 때문에 미러링 모니터 서버가 필요하지 않습니다. 동기 트랜잭션 작업을 제공하는 다른 종류의 미러링 모드로는 고가용성 모드가 있습니다. 이 모드에서는 트랜잭션 안정성을 설정해야 할 뿐만 아니라 오류가 발생할 경우 자동 장애 조치를 위해 미러링 모니터 서버도 사용됩니다.
미러링에 사용할 수 있는 세 번째 마지막 모드는 고성능입니다. 이 모드에서는 비동기 작업을 지원하기 위해 트랜잭션 안정성을 해제해야 합니다. 그래야 트랜잭션 레코드가 미러 서버에 기록될 때까지 기다릴 필요 없이 주 파트너에서 트랜잭션을 커밋할 수 있습니다. 고성능 모드에서는 미러링 모니터 서버를 구성할 필요가 없습니다.
미러링을 위해서는 주 서버와 미러 서버에서 동일한 에디션의 SQL Server를 사용해야 하지만 미러링 모니터 서버의 경우 다른 서버와 상관없이 SQL Server Express Edition을 사용할 수 있습니다. 또한 주 데이터베이스는 전체 복구 모드여야 합니다.
SQL Server 2005에 통합된 ADO.NET 2.0에는 데이터베이스 미러링을 지원하는 기능과 미러링된 환경에서 응용 프로그램에 대한 투명한 장애 조치를 수행할 수 있는 기능이 있습니다. 따라서 주 데이터베이스에 대한 연결을 설정할 수 없는 경우 추가 코딩 또는 구성 작업 없이도 ADO.NET 응용 프로그램에서 자동으로 장애 조치를 수행할 수 있습니다. 두 환경의 공통 사용자와 장애 조치 파트너를 연결 문자열에 지정하기만 하면 구성이 완료됩니다. 다음은 미러링된 데이터베이스 환경에 대한 장애 조치 파트너를 식별하는 ADO.NET 연결 문자열의 예입니다.
"Provider=SQLNCLI.1;Data Source=MirrorDB;Failover Partner=SQL03;
 Initial Catalog=AdventureWorks;
Persist Security Info=True;User ID=TestUser; Password=TestPswd; Pooling=True;
Connect Timeout=5;Application Name=ADOMirrorTest"
회사의 응용 프로그램 및 데이터 요구 사항에 따라 데이터베이스 미러링이 좋은 선택이 될 수 있지만 최적의 성능을 얻기 위해서는 여러 가지 사항을 고려해야 합니다. 예를 들어 시스템의 트랜잭션 속도와 데이터 변경의 양을 어느 정도로 할 것인지 결정해야 합니다. 데이터베이스 미러링을 고려할 때는 대역폭과 네트워크 속도가 데이터 볼륨과 트랜잭션 처리 속도를 충분히 처리할 수 있는지 여부를 확인하는 것이 중요합니다. 또한 링크의 포화도를 고려해야 합니다. 미러 서버가 다른 지역에 있는 경우에는 링크의 포화도가 매우 중요합니다. 미러링의 정상적인 작동을 방해하는 환경 제한이 있는지 여부를 알 수 있으므로 시스템을 미리 모니터링하는 것이 중요합니다.
데이터베이스 미러링은 비용을 절감하려는 경우에 매우 좋은 선택이 될 수 있습니다. 실제로 데이터베이스 미러링 아키텍처에서는 공유 디스크를 사용하지 않아도 되며 환경을 운영하는 데 특별한 고급 기술이 필요하지도 않습니다. 그리고 클러스터링과는 달리 데이터베이스 미러링에는 두 파트너가 동일한 하드웨어를 사용할 필요도 없습니다. 또한 데이터베이스 속성 창의 미러링 탭에 있는 설치 마법사를 사용하여 미러링을 쉽게 구현할 수 있습니다(그림 3 참조). 자세한 내용은 "데이터베이스 미러링 최선의 방법 및 성능 고려 사항"(go.microsoft.com/fwlink/?LinkId=80897) 백서를 참조하십시오.
Figure 3 Mirroring setup wizard
Figure 3 Mirroring setup wizard (더 작게 보려면 이미지를 클릭하십시오.)
Figure 3 Mirroring setup wizard
Figure 3 Mirroring setup wizard (더 크게 보려면 이미지를 클릭하십시오.)

데이터베이스 스냅숏
데이터베이스 스냅숏은 SQL Server 2005 Enterprise Edition에 포함된 새로운 기술이지만 고가용성 옵션으로 간주되지는 않습니다. 데이터베이스 스냅숏은 다른 기술과 함께 사용될 경우 복구 또는 실행 가능한 보고 옵션으로 사용됩니다. 스냅숏은 단순히 특정 시점의 읽기 전용 데이터베이스 뷰입니다.
스냅숏은 다음과 같이 CREATE DATABASE 명령을 사용하여 만듭니다.
CREATE DATABASE SnapDB_20061028_2030 ON
(NAME = SnapDB_Data, FILENAME =
    'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SnapDB_20061028_2030.snp')
AS SNAPSHOT OF SnapDB;
GO
데이터베이스 스냅숏이 만들어지면 일반적으로 데이터베이스에서 사용되는 데이터 파일 대신 스파스 파일이라는 하나 이상의 파일이 사용됩니다. 이러한 스파스 파일은 기본적으로 처음에는 어떠한 데이터도 갖고 있지 않는 가상 공간으로서, 원본 데이터베이스에서 데이터가 변경 또는 삭제되는 경우에만 데이터를 저장하는 데 사용됩니다. 데이터는 한 번에 한 데이터 페이지씩 스파스 파일에 기록되며 실제 데이터베이스 스냅숏에는 스냅숏이 만들어진 이후 변경된 데이터만 표시됩니다. 나머지 데이터는 원본 데이터베이스의 데이터 페이지로 구성됩니다.
데이터베이스 스냅숏 파일은 스냅숏을 만드는 시점의 데이터베이스 크기에 따라 할당됩니다. 할당된 크기를 통해 실제 저장된 데이터의 양을 파악할 수는 없습니다. 이 정보를 확인하려면 다음과 같은 T-SQL 문을 실행합니다.
SELECT *
FROM fn_virtualfilestats(DB_ID(N'SnapDB_20061028_
    2030'), 1);
GO

데이터가 스파스 파일과 원본 데이터베이스에 저장되는 방법 때문에 데이터베이스 스냅숏에 액세스하면 원본 데이터베이스 데이터 파일의 데이터 페이지와 스냅숏의 스파스 파일에 있는 데이터 페이지가 검색됩니다. 데이터 페이지를 공유해야 하기 때문에 스냅숏을 만든 원본 데이터베이스가 설치된 서버에서만 스냅숏을 사용할 수 있습니다. 이 아키텍처에서는 원본 데이터베이스에 대한 I/O 부담이 완화되지 않기 때문에 데이터베이스의 실제 상태를 나타내지 못하는 스냅숏은 사용하기에 적합한 보고 옵션이 아닙니다.
데이터베이스 미러링을 스냅숏과 함께 사용하는 시나리오를 살펴보겠습니다. 이 시나리오에서는 보고 데이터, 미러 및 스냅숏 데이터베이스를 주 데이터베이스와 물리적으로 분리할 수 있습니다. 데이터베이스 스냅숏은 SQL Server 에이전트와 사용자 지정 스크립트를 사용하여 정기적으로 갱신된 스냅숏을 제공하도록 예약됩니다. 그림 4의 예제 스크립트에서는 이 작업을 수행하는 데 사용된 저장 프로시저를 보여 줍니다. 이 스크립트는 환경에 설치된 특정 데이터베이스에 대한 스냅숏을 만들고 제거하는 작업을 관리하는 작업 내에서 사용할 수 있도록 설계되었습니다. 이 스크립트를 사용하면 보고 데이터가 프로덕션 데이터로부터 격리되기 때문에 보고 솔루션으로 사용하기에 적합합니다.
Figure 4 스냅숏 예약을 위한 저장 프로시저 (Close Figure 4)
use msdb;
GO
set nocount on
GO

CREATE PROCEDURE usp_snaprefresh
     @database    sysname = NULL    --name of the database to snapshot
    ,@keepsnap    int        = 24   --# of hours to keep a snapshot
                                    --after it was created
                                    --use a value of '0' to keep all
                                    --existing snapshots
    ,@fileloc    sysname            --location for snapshot
        = 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\'
AS

DECLARE
     @dt            datetime        ,@cnt          int
    ,@databaseid    int             ,@snap         sysname
    ,@sql           nvarchar(1000)  ,@yy           varchar(4)
    ,@mm            varchar(2)      ,@dd           varchar(2)
    ,@h             varchar(2)      ,@m            varchar(2)
    ,@lname         sysname         ,@pname        sysname
    ,@file          sysname         ,@pos1         int
    ,@pos2          int

-- initialize variables
SELECT
     @dt = getdate()
    ,@cnt = 0, @pos1 = 0, @pos2 = 0
    ,@databaseid = db_id(@database)

-- check if valid database was provided
IF @databaseid IS NULL
BEGIN
    RAISERROR ('Missing database name. Rerun the procedure specifying a
       valid database name.',16,1)
    RETURN (0)
END

--determine if snapshots should be kept
IF @keepsnap <> 0
BEGIN
    -- determine if other snapshots exist for this server older than @
    -- keepsnap value hrs
    SELECT ROW_NUMBER() OVER(ORDER BY name DESC) AS [RowNum],
        name INTO #t1
    FROM master.sys.databases
    WHERE source_database_id = @databaseid
        AND create_date < dateadd(hh,-(@keepsnap),getdate())

    IF (SELECT max(RowNum) FROM #t1 where name is not null) > 0
    BEGIN
        WHILE @cnt <= (SELECT max(RowNum) FROM #t1)
        BEGIN
            SELECT @snap = name FROM #t1 WHERE RowNum = @cnt

            PRINT 'Dropping snapshot ''' + @snap + ''''

            SET @sql = 'DROP DATABASE ' + @snap

            EXEC(@sql)
            SELECT @cnt = @cnt + 1
        END
    END
END

-- break apart point in time date time information for file name
SELECT @yy = convert(varchar(4),year(@dt)),@mm = convert(varchar(2),
   month(@dt))
    ,@dd = convert(varchar(2), day(@dt)),@h = convert(varchar(2),
         datepart(hh,@dt))
    ,@m = convert(varchar(2), datepart(mi,@dt))

-- piece together the database snapshot name and the file name
SELECT @file = @database + '_' + @yy + @mm + @dd + '_' + @h + @m

-- identify logical file name of primary data file
SET @sql = 'SELECT name INTO tempdb..t1
FROM ' + @database + '.sys.database_files
WHERE file_id = 1'

EXEC(@sql)

--setting logical filename for the snap
SELECT @lname = name FROM tempdb..t1

-- making sure the file location ends with '\'
IF substring(@fileloc, len(@fileloc), 1) <> '\'
BEGIN
    SET @fileloc = @fileloc + '\'
END

-- build sql statement to be run
SET @sql = N'CREATE DATABASE ' + @file + ' ON
(NAME = ' + @lname + ', FILENAME = ''' + @fileloc + @file + '.snp'')
AS SNAPSHOT OF ' + @database

EXEC(@sql)

-- cleanup
DROP TABLE tempdb..t1;
GO
그러나 스냅숏은 백업이 불가능하고 원본 데이터베이스가 없으면 존재할 수 없기 때문에 데이터베이스 스냅숏은 임시 데이터라는 점을 잊지 마십시오. 스파스 파일의 여유 공간이 없어지면 스냅숏은 손상된 것으로 간주되어 제거됩니다.
또한 데이터베이스 스냅숏을 사용하면 스냅숏이 만들어질 때마다 원본 데이터베이스 데이터 파일의 데이터 페이지가 스파스 파일에 기록되기 때문에 원본 데이터베이스에서 데이터 수정 작업이 수행되는 동안 시스템 성능이 저하될 수 있습니다. 결과적으로 데이터베이스에 있는 스냅숏 수에 비례하여 쓰기 횟수가 늘어납니다.
스냅숏이 만들어질 때 원본 데이터베이스에 의해 정의되는 읽기 권한은 변경할 수 없습니다. 스냅숏과 원본 데이터베이스는 데이터 페이지뿐만 아니라 동일한 버퍼 캐시도 공유하므로 동일한 인스턴스에 있어야 합니다.
스냅숏은 미러링을 함께 사용할 경우에만 보고 솔루션으로 사용하는 것을 고려할 만하며 그 외의 경우에는 환경의 성능 향상에 도움이 되지 않습니다. 데이터베이스 스냅숏은 의심이 가는 작업을 시스템에서 실행하기 전에 데이터를 보존할 수 있는 가장 빠른 방법일 수 있습니다. 데이터베이스를 스냅숏의 상태로 되돌리거나 스냅숏의 데이터를 원본 데이터베이스의 데이터와 바꿀 수 있습니다.
스냅숏 데이터베이스에 대한 명명 표준을 결정해야 합니다. 여기서 사용하는 표준은 originaldatabasename_date_time.snp입니다. 이 표준은 원본 데이터베이스를 먼저 지정한 후 스냅숏이 만들어진 날짜와 시간(24시간 형식)을 지정합니다.

로그 전달
로그 전달은 백업과 복구를 사용하여 매우 저렴한 솔루션을 만들 수 있는 제한된 고가용성 옵션입니다. 로그 전달은 예약된 간격으로 트랜잭션 로그 백업을 수행하여 보조 데이터베이스를 최신 상태로 유지합니다.
SQL Server 2005의 로그 전달에서는 마법사를 통해 설치, 예약, 초기화 및 모니터링 프로세스를 수행합니다(그림 5 참조). 이 프로세스는 간단하기 때문에 몇 분 안에 완료할 수 있습니다.
Figure 5 Log shipping setup wizard
Figure 5 Log shipping setup wizard (더 작게 보려면 이미지를 클릭하십시오.)
Figure 5 Log shipping setup wizard
Figure 5 Log shipping setup wizard (더 크게 보려면 이미지를 클릭하십시오.)

주 데이터베이스가 식별되면 일정이 만들어지고 백업 파일에 대한 파일 보존 기간이 결정됩니다. 그런 다음 백업 파일에 대한 파일 공유를 설정해야 합니다. 파일 공유를 설정한 후에는 보조 데이터베이스 파일 위치를 설정한 다음 주 데이터베이스의 복원을 완료하여 보조 데이터베이스를 초기화해야 합니다. 마지막으로 각 단계에 필요한 경고 또는 지연과 함께 트랜잭션 로그 백업의 복원과 백업 파일 사본에 대한 일정을 설정해야 합니다.
설정이 완료되면 로그 전달은 예약된 일정에 따라 데이터베이스의 트랜잭션 로그를 공유 네트워크 위치에 백업합니다. 파일이 공유 위치로 전송되면 정해진 일정에 따라 백업이 보조 데이터베이스에 적용됩니다.
로그 전달은 단순하기 때문에 여러 상황에서 잘 작동할 뿐만 아니라 트랜잭션이 높은 시스템에 사용할 수 있고 저렴하기 때문에 고가용성을 위해 선택할 수 있는 좋은 방법입니다. 로그 전달에 사용되는 보조 데이터베이스는 읽기 전용 모드로 사용할 수 있기 때문에 보고 데이터베이스로 사용하기에 좋습니다. 로그 전달은 오버헤드가 매우 낮지만 오류를 처리해야 하는 경우에는 경고 정책을 사용해야 합니다.
환경에서 로그 전달을 사용할 경우 얻을 수 있는 장점은 설정 및 관리가 간편하고 특별한 기술이 거의 필요하지 않다는 점입니다. 로그 전달은 실시간 고가용성 솔루션이 아니지만 데이터베이스 미러링과 함께 사용할 경우 이 목적으로 사용할 수 있습니다. 로그 전달은 일정과 백업, 파일 사본 및 복원과 같은 작업에 의해 제한됩니다. 또한 수동 장애 조치가 필요합니다. 이러한 이유 때문에 로그 전달은 시간 요구 사항의 중요성이 높지 않은 환경에 적합한 간단한 솔루션입니다.

SQL 서버 클러스터링
서버 클러스터링은 OS 수준에서 작동하며 여분의 하드웨어를 배치해야 하고 클러스터에서 액세스할 공유 디스크 리소스도 필요합니다. 클러스터링은 최종 사용자에게 가장 많은 혜택을 줄 수 있는 방법인 동시에 비용도 가장 많이 드는 방법입니다. 클러스터링되지 않은 인스턴스를 실행하는 데 필요한 하드웨어에 비해 두 배 이상의 하드웨어가 필요합니다.
클러스터링이라는 주제는 매우 광범위하므로 여기서는 모든 것을 자세히 설명하는 대신 일반적인 개요만 설명하겠습니다. 클러스터링에는 두 개 이상의 서버가 필요하며, 이들 서버에는 동일한 버전의 Windows® 2000 Advanced 또는 Datacenter Edition이나 Windows Server® 2003 Enterprise 또는 Datacenter Edition이 설치되어 있어야 합니다. 또한 서버 간 공유 리소스의 소유권을 처리하고 IP 주소, 공유 디스크 및 네트워크 이름을 관리하는 Microsoft® Cluster Services(MSCS)가 설치되어 있어야 합니다. 또한 클러스터링에는 일반적으로 SAN(Storage Area Network) 또는 SCSI 연결 저장소 형태로 된 공유 디스크 리소스도 필요합니다.
SQL Server 인스턴스도 리소스로 고려되며 SQL Server 2005 Standard 및 Enterprise Edition을 클러스터 구성에 설치할 수 있습니다. SQL Server 2005 Standard 및 Enterprise Edition에서 지원되는 기능 목록은 "SQL Server 2005 기능 비교 차트"(microsoft.com/sql/prodinfo/features/compare-features.mspx)를 참조하십시오.
클러스터에 리소스가 설정되면 클러스터의 두 노드를 연결하는 개인 네트워크에 설정된 하트비트를 통해 클러스터의 보조 노드와 주 노드 사이의 정기적인 통신이 유지됩니다. 하트비트는 주 노드의 오류 여부를 확인하기 위해 사용되는 간격 검사점입니다.
주 노드에 오류가 발생하면 리소스가 보조 노드로 옮겨지고 논리 서버의 상태는 그대로 유지됩니다. 이 경우 클라이언트에서는 일시적으로 상호 작용이 중단되기는 하지만 계속해서 작업을 수행할 수 있습니다. 전체 장애 조치 프로세스는 5 - 30초 정도 소요되며, 클러스터에 관련된 하드웨어, 소프트웨어 및 네트워킹 구성 요소에 따라 그 이상의 시간이 걸릴 수도 있습니다.
클러스터링은 시스템 오류를 해결하기 위해 전문적인 기술이 필요한 복잡하고 많은 비용이 드는 기술이기는 하지만 자동 장애 조치 옵션 중 가장 원활한 장애 조치 성능을 제공하는 기술입니다. 다양한 응용 프로그램 중에는 클러스터를 인식하지 못하거나 호환이 되지 않는 응용 프로그램이 있을 수 있으며, 최악의 경우에는 응용 프로그램을 다시 연결해야 합니다.

복제
SQL Server 2005 복제도 고가용성 아키텍처에 사용할 수 있습니다. SQL Server 2005 복제에는 스냅숏, 트랜잭션, 피어-투-피어 및 병합이라는 네 가지 유형의 복제가 있습니다. 피어-투-피어 복제는 실제로 트랜잭션 복제의 한 형태이므로 여기서는 설명하지 않겠습니다.
복제를 사용하면 주 데이터베이스와 완전 동일하게 작동하는 보조 사이트 및 데이터베이스를 통해 고가용성을 얻을 수 있습니다. 이러한 효과는 주 데이터베이스와 보조 데이터베이스의 트랜잭션을 모두 받아서 변경 내용을 상대 데이터베이스에 병합하는 병합 복제를 통해 얻을 수 있습니다. 그러나 예상한 대로 이 구성에는 충돌 해결 절차가 필요합니다.
트랜잭션 복제는 논리 설계면에서 데이터베이스 미러링과 매우 비슷합니다. 환경을 일관되게 유지하기 위해 주 데이터베이스에 적용된 트랜잭션이 보조 데이터베이스에 전달됩니다. 수신된 트랜잭션은 보조 데이터베이스에 적용된 후 시스템에 적용될 다음 트랜잭션을 기다립니다.
스냅숏 복제는 예약된 간격으로 실행된다는 점과 각 트랜잭션이 커밋될 때 두 시스템에 적용되지 않고 대량의 변경 내용을 적용하여 보조 데이터베이스를 업데이트한다는 점에서 로그 전달과 매우 비슷합니다. 두 기술은 매우 비슷한 방식으로 사용됩니다.
복제에는 특별한 지식이 필요하기 때문에 전담 DBA가 없는 환경에서는 많은 부담을 느낄 수 있습니다. 복제는 문제 해결 과정이 다소 복잡할 수 있으며 고가용성 옵션으로 사용할 경우 보다 복잡한 설계가 필요합니다.
복제는 고가용성 솔루션에 대한 요구 사항을 적절하게 충족할 수 있습니다. 이 기술은 데이터베이스 미러링이 수행할 수 있는 작업을 자동 장애 조치에 대한 옵션 없이 트랜잭션 복제를 사용하여 레코드 수준에서 수행합니다. 충분한 리소스가 있고 어느 정도의 창의성만 있으면 자동 장애 조치 솔루션도 어렵지 않게 스크립트로 작성할 수 있습니다.
데이터베이스 미러링과는 달리 원본 및 대상 데이터베이스 모두 클라이언트 응용 프로그램에 완전히 액세스할 수 있습니다. 복제는 스냅숏 복제를 사용하는 로그 전달과 동일한 기능을 제공합니다.
그러나 복제 기술은 현장에서 검증된 기술로서 문서화가 잘 되어 있다는 점을 고려해야 합니다. 복제를 고가용성 솔루션으로 사용할 경우에는 몇 가지 단점이 있으며 데이터베이스 미러링과 마찬가지로 성능 문제가 발생할 수 있습니다. 복제를 사용하여 설계한 고가용성 솔루션은 아키텍처가 복잡하기 때문에 관리하기가 어렵습니다. 반드시 고급 아키텍처라고는 할 수 없지만 보다 복잡한 것은 분명합니다. 또한 고려해야 할 난제 중 하나는 데이터베이스 테이블 구조가 변경되거나 복제할 테이블을 추가할 경우 두 데이터베이스에 적용할 변경 내용에 대한 게시를 삭제하고 다시 정의해야 한다는 것입니다.

요약
이제 환경에 적합한 고가용성 솔루션을 만들기 위해서는 약간의 창의성이 필요하다는 것을 알 수 있습니다. 각 SQL Server 2005 고가용성 기술에는 장단점이 있기 때문에 적합한 상황 또한 각기 다릅니다.
로그 전달, 스냅숏 복제 및 고성능 모드의 데이터베이스 미러링은 주 웹 데이터베이스 환경과 보조 데이터베이스 환경이 지역적으로 분리되어 있는 경우, 특히 보조 데이터를 실시간으로 액세스하지 않아도 되는 경우에 적합합니다.
반면 실시간 데이터 액세스가 보조 데이터베이스의 요구 사항에 포함된 경우, 주 서버의 트랜잭션 속도가 낮고 두 환경 사이트 간의 링크가 빠르면서 비포화 상태라면 트랜잭션 복제나 데이터베이스 미러링이 적합합니다.
또한 이러한 기술에 대해 얼마나 잘 알고 있는지도 고려해야 합니다. 이미 이러한 기술에 대한 작업 경험이 있으면 도움이 될 것입니다. 전담 DBA가 없는 관리자라면 이동해야 할 부분이 많고 문제 해결이 복잡할 수 있는 복제와 같은 복잡한 기술은 사용하지 않는 것이 좋습니다. 또한 경험 많은 SQL Server 컨설턴트에 문의하여 환경에 적합한 새로운 고가용성 솔루션에 대한 설계, 구현 및 관리 직원 교육에 필요한 도움을 받을 수 있습니다.
데이터의 가용 시간을 최대한으로 유지해야 하고 데이터 중지 시간을 매우 중요하게 고려하는 조직의 경우 고가용성을 위해 클러스터링을 선택하는 것도 좋은 방법입니다.
이 모든 내용의 주제는 SQL Server 2005가 다양한 유형의 환경에 적합한 고가용성을 구현하는 데 필요한 여러 가지 새 옵션을 제공한다는 것입니다. 단일 가용성 옵션이 요구에 적합할 수 있는 반면 여러 기술을 결합해서 사용할 수도 있습니다. 앞에서 설명한 대로 환경에 적합한 다양한 선택의 기회가 있습니다.

Zach Nichter는 10년 이상의 경력을 가진 SQL Server 전문가로서, DBA, 팀장, 관리자 및 컨설턴트를 비롯한 다양한 SQL Server 지원 업무를 수행했습니다. 현재 Levi Strauss & Co.에서 DBA 설계자로 근무하고 있는 Zach는 주로 SQL Server 성능, 모니터링, 아키텍처 및 기타 전략적 이니셔티브에 관한 업무를 담당하고 있습니다.


 SQL Server: 테이블 파티션을 사용한 데이터베이스 유지 관리 단순화
SQL Server Noah Gomez

테이블 파티션을 사용한 데이터베이스 유지 관리 단순화
한 눈에 보기:
  • 파티션 테이블 만들기
  • 파티션 추가 및 병합
  • 분할된 인덱스 생성 및 관리
이 기사의 코드 다운로드: GomezPartitioning2007_03.exe (156KB)

이전에는 데이터베이스 관리자가 수백만 개의 데이터 행이 포함된 테이블을 관리하기 위해 여러 테이블을 만들어야 했습니다. 이러한 테이블을 분할한 뒤 관리자는
많은 쿼리를 실행하는 동안 테이블들을 다시 결합시켜야 했습니다. 파티션을 결합하는 작업에는 분할된 뷰를 만들거나 데이터가 있는 위치를 찾은 다음 다른 저장 프로시저를 실행하여 데이터 집합을 반환하는 데 필요한 파티션만을 찾아내는 래퍼 저장 프로시저를 만드는 작업이 포함됩니다.
이러한 방법은 효과가 있기는 하지만 귀찮은 작업이었습니다. 여러 테이블과 인덱스를 관리하는 작업과 테이블을 다시 결합하는 데 사용된 방법 때문에 관리 및 유지 관리 문제가 자주 발생했었습니다. 또한 여러 테이블을 만들어 데이터를 분할하려면 저장 프로시저, 유지 관리 작업, DTS(데이터 변환 서비스) 작업, 응용 프로그램 코드 및 다른 프로세스에서 분할의 특성을 이해하고 있어야 했기 때문에 유연성이 크게 떨어지는 문제가 있었습니다. 코드를 변경하지 않고 이러한 파티션을 추가하거나 삭제할 수 있도록 하기 위해 일반적으로 이들 요소를 비동적인 방법으로 만들었지만 결과적으로 효율이 떨어졌습니다.
SQL Server™ 2005 Enterprise 및 Developer Edition에서는 단일 테이블에 있는 대용량 데이터를 여러 작은 파티션으로 분할하여 효과적으로 유지 관리할 수 있습니다. 단일 입력 지점을 통해 액세스되는 데이터 세그먼트를 만드는 기능은 기존 방법으로 인한 많은 관리 문제를 줄여 줍니다. 단일 입력 지점(테이블 이름 또는 인덱스 이름)을 사용하면 응용 프로그램 코드에서 여러 데이터 세그먼트가 숨겨지며 관리자나 개발자는 코드 베이스를 조정하지 않고도 필요에 따라 파티션을 변경할 수 있습니다.
다시 말해서 응용 프로그램의 코드를 조정하지 않고서도 복수 파티션을 만들고, 파티션을 이동하고, 기존 파티션을 제거할 수 있을 뿐만 아니라 데이터의 분할 방법까지도 변경할 수 있습니다. 응용 프로그램 코드에서는 계속해서 동일한 기본 테이블이나 인덱스 이름을 호출하기만 하면 됩니다. 따라서 개별 인덱스에 포함된 데이터의 양을 줄일 수 있고, 결과적으로 인덱스에 대한 유지 관리 시간이 단축될 뿐만 아니라, 빈 파티션에 데이터를 로드하여 로드 속도를 높일 수 있습니다.
기술적으로 모든 SQL Server 2005 테이블은 분할됩니다. 즉, 모든 테이블에는 하나 이상의 파티션이 있습니다. SQL Server 2005에서 데이터베이스 관리자는 각 테이블에 추가 파티션을 만들 수 있습니다. 테이블 및 인덱스 파티션은 단일 입력 지점(테이블 이름 또는 인덱스 이름)을 사용할 수 있는 명확히 정의된(hard-defined) 행 수준 파티션(열 단위 분할은 안 됨)으로, 응용 프로그램 코드에서는 입력 지점 뒤에 있는 파티션의 수를 몰라도 됩니다. 파티션은 기본 테이블 및 테이블과 연관된 인덱스에 존재할 수 있습니다.

분할된 테이블 만들기
파티션 함수와 파티션 구성표를 사용하여 기본 단일 파티션 이상으로 확장 가능한 테이블을 만들 수 있습니다. 이러한 개체는 데이터를 특정 세그먼트로 나누고 스토리지 설계에 배치된 데이터 세그먼트의 위치를 제어하는 기능을 제공합니다. 예를 들어 데이터의 사용 기간을 기준으로 하거나 다른 공통 식별자를 사용하여 데이터를 여러 드라이브 배열에 분산시킬 수 있습니다. 테이블은 테이블의 한 열을 기준으로 분할될 수 있으며, 각 파티션에는 다른 파티션에 배치될 수 없는 데이터가 있어야 합니다.
파티션 함수: 테이블을 분할할 때는 먼저 데이터를 여러 세그먼트로 어떻게 나눌 것인지 결정해야 합니다. 파티션 함수는 개별 데이터 행을 여러 파티션으로 매핑하는 데 사용됩니다. 이러한 개별 데이터 행은 text, ntext, image, xml, timestamp, varchar(max), nvarchar(max), varbinary(max), 별칭 데이터 형식 또는 CLR(공용 언어 런타임) 사용자 정의 데이터 형식을 제외한 모든 열 형식을 사용하여 매핑할 수 있습니다. 그러나 파티션 함수는 하나의 데이터 행을 하나의 테이블 파티션에만 배치할 수 있으며, 같은 데이터 행을 여러 파티션에 동시에 매핑할 수 없습니다.
테이블을 분할하려면 대상 테이블에서 분할 열을 만들어야 합니다. 이 분할 열은 테이블을 처음 만들 때 테이블 스키마에 포함하거나 나중에 테이블을 변경하면서 추가할 수 있습니다. 이 열에는 NULL 값을 사용할 수 있지만 NULL 값이 포함된 모든 행은 기본적으로 테이블의 맨 왼쪽 파티션에 배치됩니다. 이를 원하지 않는 경우에는 파티션 함수를 만들 때 NULL 값이 테이블의 가장 오른쪽 파티션에 배치되도록 지정할 수 있습니다. 왼쪽 또는 오른쪽 파티션의 사용은 파티션 구성표를 수정하고 파티션을 추가하거나 기존 파티션을 삭제하는 작업과 관련된 설계상의 중요한 결정 사항입니다.
파티션 함수를 만들 때 LEFT 또는 RIGHT 파티션 함수를 선택할 수 있습니다. LEFT 파티션과 RIGHT 파티션은 파티션 구성표에 배치되는 경계 값의 위치가 서로 다릅니다. LEFT 파티션(기본값)에서는 경계 값이 파티션에 포함되지만 RIGHT 파티션에서는 경계 값이 다음 파티션에 배치됩니다.
이 개념을 이해하기 위해 간단한 LEFT 및 RIGHT 파티션을 살펴보겠습니다.
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

CREATE PARTITION FUNCTION Right_Partition (int) AS RANGE RIGHT
FOR VALUES (1,10,100)
첫 번째 함수 Left_Partition에서 값 1, 10 및 100은 첫 번째, 두 번째 및 세 번째 파티션에 각각 배치됩니다. 두 번째 함수 Right_Partition에서는 값이 두 번째, 세 번째 및 네 번째 파티션에 배치됩니다.
분할된 테이블을 만들 때는 되도록 파티션을 균등하게 나누는 것이 좋습니다. 이렇게 하면 파티션에 필요한 공간을 쉽게 파악할 수 있습니다. LEFT와 RIGHT를 사용하면 데이터의 배치 위치가 결정될 뿐만 아니라 파티션의 크기와 파티션에서 만든 인덱스의 크기도 결정됩니다.
다음과 같이 $PARTITION 함수를 사용하여 데이터 값이 배치될 파티션 번호를 결정할 수 있습니다.
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Right_Partition (10)
첫 번째 SELECT 문에서 결과는 2가 됩니다. 두 번째 SELECT 문에서는 3이 반환됩니다.
파티션 구성표: 함수를 만들고 데이터의 분할 방법을 결정한 후에는 개별 파티션을 디스크 하위 시스템의 어느 위치에 만들 것인지 결정해야 합니다. 파티션 구성표는 이러한 디스크 레이아웃을 만드는 데 사용됩니다. 파티션 구성표에서는 파일 그룹을 사용하여 각 파티션을 디스크 하위 시스템에 배치함으로써 개별 파티션의 디스크 스토리지를 관리합니다. 파티션 구성표를 구성하여 모든 파티션을 단일 파일 그룹에 배치하거나, 모든 파티션을 여러 파일 그룹에 배치하거나, 여러 파티션에서 여러 파일 그룹을 공유하도록 설정할 수 있습니다. 데이터베이스 관리자는 이 마지막 방법을 사용하여 디스크 I/O를 유연하게 분산시킬 수 있습니다.
그림 1은 하나 이상의 파일 그룹을 파티션 구성표에 할당하는 몇 가지 방법을 보여 줍니다. 파티션 구성표에 사용할 파일 그룹은 파티션 구성표를 만들기 전에 데이터베이스에 이미 있어야 합니다.
Figure 1 파티션 구성표에 파일 그룹 지정 (Close Figure 1)
--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

--Place all partitions into the different filegroups
CREATE PARTITION SCHEME Different_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      TO (Filegroup1, Filegroup2, Filegroup3, Filegroup4)
--Filegroups must currently exist in database

--Place multiple partitions into the different filegroups
CREATE PARTITION SCHEME Multiple_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      TO (Filegroup1, Filegroup2, Filegroup1, Filegroup2)
--Filegroups must currently exist in database
그림 1과 같은 샘플 파티션 함수를 만들고 파티션 구성표를 사용하여 테이블을 만든 경우에는 새로 분할된 테이블에 배치될 개별 데이터 행의 위치를 결정할 수 있습니다. 그런 다음 분할된 테이블에 삽입된 데이터 행의 분포를 볼 수 있습니다. 이 모든 작업을 수행하는 코드는 그림 2와 같습니다.
Figure 2 데이터 행 배치 및 분포 보기 (Close Figure 2)
--Prepare database
IF OBJECT_ID('Partitioned_Table') IS NOT NULL
DROP TABLE Partitioned_Table
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
      ALL TO ([PRIMARY])

CREATE TABLE Partitioned_Table
(
col1 INT
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

--Determine where values will be placed (this is not required)
--You should try to do this before executing the code
SELECT $PARTITION.Left_Partition (1)
SELECT $PARTITION.Left_Partition (2)
SELECT $PARTITION.Left_Partition (3)
SELECT $PARTITION.Left_Partition (4)
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Left_Partition (11)
SELECT $PARTITION.Left_Partition (12)
SELECT $PARTITION.Left_Partition (13)
SELECT $PARTITION.Left_Partition (14)
SELECT $PARTITION.Left_Partition (100)
SELECT $PARTITION.Left_Partition (101)
SELECT $PARTITION.Left_Partition (102)
SELECT $PARTITION.Left_Partition (103)
SELECT $PARTITION.Left_Partition (104)

--Insert data into partitioned table
INSERT INTO Partitioned_Table VALUES (1,'Description')
INSERT INTO Partitioned_Table VALUES (2,'Description')
INSERT INTO Partitioned_Table VALUES (3,'Description')
INSERT INTO Partitioned_Table VALUES (4,'Description')
INSERT INTO Partitioned_Table VALUES (10,'Description')
INSERT INTO Partitioned_Table VALUES (11,'Description')
INSERT INTO Partitioned_Table VALUES (12,'Description')
INSERT INTO Partitioned_Table VALUES (13,'Description')
INSERT INTO Partitioned_Table VALUES (14,'Description')
INSERT INTO Partitioned_Table VALUES (100,'Description')
INSERT INTO Partitioned_Table VALUES (101,'Description')
INSERT INTO Partitioned_Table VALUES (102,'Description')
INSERT INTO Partitioned_Table VALUES (103,'Description')
INSERT INTO Partitioned_Table VALUES (104,'Description')

--View the distribution of data in the partitions
SELECT ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('Partitioned_Table')

분할된 테이블 수정
아무리 철저하게 계획을 세웠더라도 테이블을 만들고 채운 이후에 분할된 테이블을 조정해야 하는 경우가 발생할 수 있습니다. 예를 들어 파티션 구성표가 예상대로 작동하더라도 새 데이터가 누적되어 새 파티션을 추가해야 하거나 많은 양의 분할된 데이터를 동시에 삭제해야 하는 경우가 발생할 수 있습니다. 다행히 분할된 테이블과 기본 분할 구조는 테이블이 활성화되어 데이터가 채워진 이후에도 변경할 수 있습니다.
파티션 추가: 많은 분할 계획에는 나중에 새 파티션을 추가할 수 있는 기능이 포함되어 있습니다. 이 시점은 특정 날짜일 수 있으며 증분 ID 열의 값에 따라 달라질 수도 있습니다. 그러나 미리 계획하지 않았더라도 나중에 새 파티션을 분할된 테이블에 추가할 수 있습니다. 그림 2에서 만든 테이블을 예로 들면, 다음과 같이 500보다 큰 값이 포함된 새 파티션을 이 테이블에 추가할 수 있습니다.
--Determine where values live before new partition
SELECT $PARTITION.Left_Partition (501)  --should return a value of 4

--Create new partition
ALTER PARTITION FUNCTION Left_Partition ()
SPLIT RANGE(500)

--Determine where values live after new partition
SELECT $PARTITION.Left_Partition (501)  --should return a value of 5
파티션 추가 기능은 높은 유연성을 제공합니다. 그림 3은 함수의 왼쪽에 파티션을 추가하는 방법을 보여 줍니다. 이 경우에는 처음 파티션 구성표를 작성할 때 만든 파일 그룹이 모두 사용되고 없으므로 새 파티션을 배치할 위치를 파티션 구성표에 알려야 합니다. 또한 모든 파티션에 대해 PRIMARY 파일 그룹을 사용하고 있더라도 PRIMARY 파일 그룹을 새 파티션에 다시 사용할 것임을 파티션 구성표에 알려야 합니다.
Figure 3 함수의 왼쪽에 파티션 추가 (Close Figure 3)
--Determine where values live after new partition
SELECT $PARTITION.Left_Partition (5)   --should return a value of 2
SELECT $PARTITION.Left_Partition (1)   --should return a value of 1
SELECT $PARTITION.Left_Partition (10)  --should return a value of 2

--Add new filegroups to the partitioning scheme
ALTER PARTITION SCHEME Primary_Left_Scheme
NEXT USED [PRIMARY]

--Create new partition
ALTER PARTITION FUNCTION Left_Partition ()
SPLIT RANGE(5)

--Determine where values live after new partition
SELECT $PARTITION.Left_Partition (5)   --should return a value of 2
SELECT $PARTITION.Left_Partition (1)   --should return a value of 1
SELECT $PARTITION.Left_Partition (10)  --should return a value of 3
두 파티션 병합 SQL Server에서는 데이터를 유지한 채 테이블에서 단일 파티션을 삭제할 수 있습니다. 이 기능은 오래된 활성 데이터를 보관된 데이터에 병합하거나 사용하는 파티션의 수를 줄이려는 경우에 사용되며 분할된 테이블에 대한 관리 작업을 간편하게 만들어 줍니다. 또한 이 기능을 통해 파일 그룹 간에 데이터를 이동하여 파티션을 병합함으로써 특정 드라이브 배열의 여유 디스크 공간을 늘릴 수 있습니다. 그림 4의 코드에서는 동일한 파일 그룹에 있는 파티션 간에 데이터를 이동하는 방법을 보여 줍니다.
Figure 4 파티션 간 데이터 이동 (Close Figure 4)
--Prepare database
IF OBJECT_ID('multiple_partition') IS NOT NULL
DROP TABLE multiple_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

INSERT INTO multiple_partition VALUES (1,'Description')
INSERT INTO multiple_partition VALUES (2,'Description')
INSERT INTO multiple_partition VALUES (3,'Description')
INSERT INTO multiple_partition VALUES (4,'Description')
INSERT INTO multiple_partition VALUES (10,'Description')
INSERT INTO multiple_partition VALUES (11,'Description')
INSERT INTO multiple_partition VALUES (12,'Description')
INSERT INTO multiple_partition VALUES (13,'Description')
INSERT INTO multiple_partition VALUES (14,'Description')
INSERT INTO multiple_partition VALUES (100,'Description')
INSERT INTO multiple_partition VALUES (101,'Description')
INSERT INTO multiple_partition VALUES (102,'Description')
INSERT INTO multiple_partition VALUES (103,'Description')
INSERT INTO multiple_partition VALUES (104,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')

--Check where data would be placed
SELECT $PARTITION.Left_Partition (1)
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Left_Partition (100)
SELECT $PARTITION.Left_Partition (101)

--Merge two partitions
ALTER PARTITION FUNCTION Left_Partition()
MERGE RANGE (10)

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')

--Check where data would be placed
SELECT $PARTITION.Left_Partition (1)
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Left_Partition (100)
SELECT $PARTITION.Left_Partition (101)
단일 파티션 테이블을 분할된 테이블로 이동: 로드 루틴을 실행하는 동안 많은 양의 데이터를 데이터베이스에 로드한 다음 수집하거나 집계한 후 실제 데이터 테이블로 이동해야 하는 경우가 자주 발생합니다. SQL Server 2005 분할 기능을 사용하면 단일 파티션 테이블을 여러 파티션을 가진 테이블로 이동할 수 있습니다. 즉, 데이터를 단일 로드 테이블에 로드해서 데이터를 수정한 다음 개별 데이터 행을 이동할 필요 없이 전체 테이블을 기존 테이블로 이동할 수 있습니다. 이 분할 작업에서는 기본 분할 구조를 변경하지 않고 분할된 테이블만 수정합니다. 그림 5의 코드는 이 작업을 수행하는 방법을 보여 줍니다.
Figure 5 전체 테이블을 기존 테이블로 이동 (Close Figure 5)
--Prepare database
IF OBJECT_ID(‘multiple_partition’) IS NOT NULL
DROP TABLE multiple_partition
GO

IF OBJECT_ID(‘single_partition’) IS NOT NULL
DROP TABLE single_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = ‘Primary_Left_Scheme’)
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = ‘Left_Partition’)
DROP PARTITION FUNCTION Left_Partition
GO

--Create single partition table
CREATE TABLE single_partition
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
)

--Table must have a CHECK Constraint
ALTER TABLE single_partition
WITH CHECK
ADD CONSTRAINT CK_single_partition
    CHECK (col1 > 100)

INSERT INTO single_partition VALUES (101,’Description’)
INSERT INTO single_partition VALUES (102,’Description’)
INSERT INTO single_partition VALUES (103,’Description’)
INSERT INTO single_partition VALUES (104,’Description’)

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

INSERT INTO multiple_partition VALUES (1,’Description’)
INSERT INTO multiple_partition VALUES (2,’Description’)
INSERT INTO multiple_partition VALUES (3,’Description’)
INSERT INTO multiple_partition VALUES (4,’Description’)
INSERT INTO multiple_partition VALUES (10,’Description’)
INSERT INTO multiple_partition VALUES (11,’Description’)
INSERT INTO multiple_partition VALUES (12,’Description’)
INSERT INTO multiple_partition VALUES (13,’Description’)
INSERT INTO multiple_partition VALUES (14,’Description’)
INSERT INTO multiple_partition VALUES (100,’Description’)

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID(‘multiple_partition’), OBJECT_
      ID(‘single_partition’))

--Move the single table into the partitioned table
ALTER TABLE single_partition SWITCH TO multiple_partition PARTITION 4

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID(‘multiple_partition’), OBJECT_ID(‘single_partition’))
테이블 간 파티션 이동: 오래된 데이터를 별도의 보관 테이블로 이동하는 작업은 일반적인 관리 작업입니다. 보관 프로세스에서는 일반적으로 트랜잭션 로그에 추가 리소스 사용량을 만들 수 있는 일련의 문이 포함됩니다. 그러나 파티션의 소유권을 한 테이블에서 다른 테이블로 전환하면 트랜잭션 로그 오버헤드 없이 대용량 데이터를 간편하게 보관할 수 있습니다. 이 기능을 통해 데이터베이스 관리자는 오래된 데이터 세그먼트를 활성 테이블에서 보관된 테이블로 이동할 수 있습니다. 또한 데이터가 실제로 이동하지는 않기 때문에 개별 데이터 행을 이동할 때보다 많은 시간을 절약할 수 있습니다. 그림 6에서는 이 작업을 수행하는 방법을 보여 줍니다.
Figure 6 오래된 데이터를 보관 테이블로 이동 (Close Figure 6)
--Prepare database
IF OBJECT_ID('active_data') IS NOT NULL
DROP TABLE active_data
GO

IF OBJECT_ID('archive_data') IS NOT NULL
DROP TABLE archive_data
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Active_Scheme')
DROP PARTITION SCHEME Active_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Active_Partition')
DROP PARTITION FUNCTION Active_Partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Archive_Scheme')
DROP PARTITION SCHEME Archive_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Archive_Partition')
DROP PARTITION FUNCTION Archive_Partition
GO

--Create active function
CREATE PARTITION FUNCTION Active_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Create archive function
CREATE PARTITION FUNCTION Archive_Partition (int) AS RANGE LEFT
FOR VALUES (100,200,300)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Active_Scheme
AS PARTITION Active_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Archive_Scheme
AS PARTITION Archive_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE active_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Active_Scheme (col1)

CREATE TABLE archive_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Archive_Scheme (col1)

INSERT INTO active_data VALUES (1,'Description')
INSERT INTO active_data VALUES (2,'Description')
INSERT INTO active_data VALUES (3,'Description')
INSERT INTO active_data VALUES (4,'Description')
INSERT INTO active_data VALUES (10,'Description')
INSERT INTO active_data VALUES (11,'Description')
INSERT INTO active_data VALUES (12,'Description')
INSERT INTO active_data VALUES (13,'Description')
INSERT INTO active_data VALUES (14,'Description')
INSERT INTO active_data VALUES (100,'Description')

INSERT INTO archive_data VALUES (200,'Description')
INSERT INTO archive_data VALUES (300,'Description')
INSERT INTO archive_data VALUES (400,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

--Switch ownership of partition to another table
ALTER TABLE active_data SWITCH PARTITION 3 TO archive_data PARTITION 1

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))
단일 파티션을 사용하여 새 테이블 만들기: 분할된 기존 테이블에 있는 단일 파티션을 분할되지 않은 빈 테이블로 이동할 수 있습니다. 이 기능을 통해 데이터베이스 관리자는 단일 파티션에 대한 인덱스 유지 관리 작업을 수행할 수 있으며 또한 삭제 프로세스를 로깅하지 않고 많은 양의 데이터를 쉽게 삭제할 수 있습니다. 그림 7의 샘플은 파티션을 빈 테이블로 이동한 다음 새 테이블을 사용하여 데이터를 삭제하는 방법을 보여 줍니다.
Figure 7 데이터 이동 및 삭제 (Close Figure 7)
--Prepare database
IF OBJECT_ID('active_data') IS NOT NULL
DROP TABLE active_data
GO

IF OBJECT_ID('archive_data') IS NOT NULL
DROP TABLE archive_data
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Active_Scheme')
DROP PARTITION SCHEME Active_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Active_Partition')
DROP PARTITION FUNCTION Active_Partition
GO

--Create active function
CREATE PARTITION FUNCTION Active_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Active_Scheme
AS PARTITION Active_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE active_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Active_Scheme (col1)

CREATE TABLE archive_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
)

INSERT INTO active_data VALUES (1,'Description')
INSERT INTO active_data VALUES (2,'Description')
INSERT INTO active_data VALUES (3,'Description')
INSERT INTO active_data VALUES (4,'Description')
INSERT INTO active_data VALUES (10,'Description')
INSERT INTO active_data VALUES (11,'Description')
INSERT INTO active_data VALUES (12,'Description')
INSERT INTO active_data VALUES (13,'Description')
INSERT INTO active_data VALUES (14,'Description')
INSERT INTO active_data VALUES (100,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

--Switch ownership of partition to another table
ALTER TABLE active_data SWITCH PARTITION 3 TO archive_data

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

--Drop all archive data without logging
DROP TABLE archive_data
GO

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

분할된 인덱스
테이블의 데이터를 분할하는 기능과 함께 분할된 인덱스를 만드는 기능도 제공됩니다. 이 기능을 통해 데이터베이스 관리자는 전체 테이블의 데이터 대신 분할된 데이터를 기반으로 하는 인덱스 구조를 설계할 수 있습니다. 분할된 인덱스를 만들면 분할된 인덱스에 개별 B-트리가 만들어집니다. 인덱스를 분할하면 데이터를 수정, 추가 및 삭제하는 중에 스토리지 엔진에서 보다 쉽게 관리할 수 있는 작은 인덱스를 만들 수 있습니다. 이러한 작은 인덱스는 데이터베이스 관리자가 개별적으로 유지 관리할 수 있기 때문에 대용량 데이터 집합에 대한 인덱스를 보다 효율적으로 유지 관리할 수 있습니다.
분할된 인덱스 만들기: 분할된 인덱스를 만들 때 정렬된 인덱스 또는 정렬되지 않은 인덱스를 만들 수 있습니다. 정렬된 인덱스의 경우 분할된 데이터에 대한 직접 관계를 사용하여 인덱스를 만들고, 정렬되지 않은 인덱스의 경우 다른 파티션 구성표를 선택합니다.
주로 사용되는 방법은 정렬된 인덱스로, 파티션 테이블을 만든 후 다른 파티션 구성표를 지정하지 않고 인덱스를 만들면 자동으로 정렬된 인덱스가 만들어집니다. 정렬된 인덱스를 사용하면 유연하게 추가 파티션을 테이블에 만들 수 있으며 파티션의 소유권을 다른 테이블로 전환할 수도 있습니다. 이러한 기능 때문에 데이터베이스 관리자가 분할된 테이블을 먼저 만드는 것입니다. 또한 테이블의 파티션 구성표를 인덱스에 사용하는 것만으로도 분할 목표를 쉽게 달성할 수 있습니다.
인덱스의 데이터가 테이블의 데이터와 대응되지 않는 테이블에 대한 인덱스를 만들 수 있습니다. 데이터가 분할된 테이블에 있는 경우에는 다양한 방법으로 데이터를 결합할 수 있습니다. 분할된 데이터는 쿼리 최적화 프로그램을 통해 다른 분할된 데이터와 효과적으로 결합할 수 있습니다. 분할되지 않은 테이블을 사용해서도 이 작업을 수행할 수 있습니다. 이 경우에는 단일 파티션 테이블에 대한 분할된 인덱스를 만들 수 있기 때문에 인덱스를 쉽게 유지 관리할 수 있습니다.
그림 8의 코드는 분할된 비클러스터형 인덱스를 분할된 테이블에 만듭니다. 비클러스터형 인덱스는 테이블과 대응되도록 정렬되며 테이블의 분할 열을 비클러스터형 인덱스 키로 사용합니다.
Figure 8 분할된 테이블의 분할된 비클러스터형 인덱스 (Close Figure 8)
--Prepare database
IF OBJECT_ID('multiple_partition') IS NOT NULL
DROP TABLE multiple_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
    ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

--Create partitioned non-clustered index
CREATE NONCLUSTERED INDEX cl_multiple_partition ON multiple_
      partition(col1)

INSERT INTO multiple_partition VALUES (1,'Description')
INSERT INTO multiple_partition VALUES (2,'Description')
INSERT INTO multiple_partition VALUES (3,'Description')
INSERT INTO multiple_partition VALUES (4,'Description')
INSERT INTO multiple_partition VALUES (10,'Description')
INSERT INTO multiple_partition VALUES (11,'Description')
INSERT INTO multiple_partition VALUES (12,'Description')
INSERT INTO multiple_partition VALUES (13,'Description')
INSERT INTO multiple_partition VALUES (14,'Description')
INSERT INTO multiple_partition VALUES (100,'Description')
INSERT INTO multiple_partition VALUES (101,'Description')
INSERT INTO multiple_partition VALUES (102,'Description')
INSERT INTO multiple_partition VALUES (103,'Description')
INSERT INTO multiple_partition VALUES (104,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')

--Verify index partitions
SELECT partition_id, index_id FROM sys.partitions pt
WHERE pt.[object_id] = OBJECT_ID('multiple_partition')
그림 9의 코드에서는 정렬되지 않은 비클러스터형 인덱스를 분할된 테이블에 만듭니다. 이 비클러스터형 인덱스는 다양한 열을 인덱스 키로 사용하며 다른 분할된 테이블에 대한 정렬된 결합에 사용될 수 있습니다.
Figure 9 분할된 테이블의 정렬되지 않은 비클러스터형 인덱스 (Close Figure 9)
--Prepare database
IF OBJECT_ID('multiple_partition') IS NOT NULL
DROP TABLE multiple_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Index_primary_Left_Scheme')
DROP PARTITION SCHEME Index_primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Index_Left_Partition')
DROP PARTITION FUNCTION Index_Left_Partition
GO

--Create partitioned index function
CREATE PARTITION FUNCTION Index_Left_Partition (int) AS RANGE LEFT
FOR VALUES (10,50,100)

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all index partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Index_primary_Left_Scheme
AS PARTITION Index_Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT
,col2 INT
) ON Primary_Left_Scheme (col1)

--Create non-aligned partitioned nonclustered index
CREATE NONCLUSTERED INDEX cl_multiple_partition ON multiple_
     partition(col2)
ON Index_primary_Left_Scheme (col2)

INSERT INTO multiple_partition VALUES (1,10)
INSERT INTO multiple_partition VALUES (2,10)
INSERT INTO multiple_partition VALUES (3,10)
INSERT INTO multiple_partition VALUES (4,10)
INSERT INTO multiple_partition VALUES (10,50)
INSERT INTO multiple_partition VALUES (11,50)
INSERT INTO multiple_partition VALUES (12,50)
INSERT INTO multiple_partition VALUES (13,50)
INSERT INTO multiple_partition VALUES (14,50)
INSERT INTO multiple_partition VALUES (100,100)
INSERT INTO multiple_partition VALUES (101,100)
INSERT INTO multiple_partition VALUES (102,100)
INSERT INTO multiple_partition VALUES (103,100)
INSERT INTO multiple_partition VALUES (104,100)

--Verify row count on partitioned data
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')
AND p.index_id = 0

--Verify row count on partitioned index
--Row counts will not match those found in the data partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')
AND p.index_id <> 0
분할된 인덱스 유지 관리: 예전의 데이터베이스 관리자는 수백만 또는 수십억 개의 데이터 행이 포함된 대용량 테이블에 대한 인덱스를 유지 관리하는 데 많은 시간을 빼앗기곤 했습니다. 인덱스가 다시 작성되는 동안 데이터가 잠겨서 유지 관리 작업이 완료되지 않은 상태로 중지되는 경우도 자주 발생했습니다. SQL Server 2005를 사용하는 데이터베이스 관리자는 기본 테이블을 오랜 시간 동안 잠그지 않고도 인덱스 유지 관리를 온라인으로 수행할 수 있습니다. 그러나 사용자가 데이터에 액세스하는 동안 인덱스 유지 관리를 수행할 수 있는 이 방법을 사용하는 경우에도 리소스 사용량 때문에 시스템의 처리 속도가 낮아질 수 있습니다. 따라서 인덱스를 작은 세그먼트로 분할한 다음 작은 파티션에 대한 인덱스 유지 관리를 수행하는 것이 더 효율적인 방법입니다. 예를 들어 하나의 인덱스 파티션에 대한 인덱스 유지 관리를 수행하려면 그림 8의 코드 끝에 다음 코드 조각을 추가하기만 하면 됩니다.
ALTER INDEX cl_multiple_partition
ON multiple_partition
REBUILD Partition = 2
단일 인덱스 파티션에 대한 인덱스 유지 관리는 오프라인으로 수행해야 하며 인덱스 유지 관리 동안 테이블이 잠길 수 있습니다. 이 문제를 방지하기 위해 단일 파티션을 별도의 파티션으로 이동하고, 인덱스 유지 관리를 수행한 다음 파티션을 기본 테이블로 다시 이동할 수 있습니다. 이 프로세스를 수행하면 파티션이 테이블로 다시 옮겨지고 클러스터형 인덱스가 업데이트되기 때문에 성능 문제가 발생할 수 있지만 전체 테이블이 잠기는 것보다는 심각하지 않으며 필요한 시스템 리소스도 더 작습니다.

요약
위에서 볼 수 있는 것처럼 SQL Server 2005 테이블 분할 기능을 사용하면 응용 프로그램 코드나 SQL Server 프로세스를 다시 작업하지 않고서도 대용량 테이블의 데이터를 유연하게 저장 및 유지 관리할 수 있습니다. 이러한 기능을 통해 SQL Server는 엔터프라이즈 수준의 중요한 데이터베이스에 적합한 플랫폼임을 직접 증명해 보이고 있습니다.

Noah Gomez는 VLDB와 대규모 응용 프로그램을 전문적으로 다루는 Verizon의 수석 SQL Server 개발 DBA입니다. 그는 PASS(Professional Association for SQL Server) 멤버이며 Verizon DBA 팀에서 멀티 테라바이트 VLDB 작업을 통해 2003년에 Winter Corp. Top Ten Grand Prize를 수상한 경력이 있습니다.


 SQL Server: SQL Server 클러스터링에 유용한 정보
SQL Server Tom Moreau

SQL Server 클러스터링에 유용한 정보
한 눈에 보기:
  • 클러스터에서 SQL Server 실행
  • 하드웨어 및 소프트웨어 요구 사항
  • 1 노드 클러스터링
  • 비용 효율적인 옵션

서버 클러스터를 사용하면 여러 개의 실제 서버나 노드를 연결하여 각각이 서로의 장애 조치 파트너로 작동하도록 할 수 있습니다. 클러스터가 제공하는 중복성은 중요 작업을 위한 가동 시간을
더 늘려 줍니다. 지난 13년간 SQL Server™를 사용하면서 수많은 클러스터를 구현해 보았는데 저마다 고유의 문제를 지니고 있었습니다. 이러한 경험을 바탕으로 클러스터링을 보다 쉽고 안정적으로 사용하는 데 도움이 되는 많은 유용한 정보를 수집할 수 있었습니다.
서버 클러스터는 Windows Server® Enterprise Edition 제품군에서 기본적으로 제공되는 클러스터링 기능을 사용합니다. 사실 클러스터링을 사용할 목적이라면 Windows 2000 Advanced Server보다 Windows Server 2003이 훨씬 낫습니다. 클러스터링을 통해 얻을 수 있는 이점을 최대화하려면 적절한 하드웨어를 사용해야 하는데 이를 위해서는 어느 정도의 비용을 투자할 필요가 있습니다. 공유 디스크를 사용하여 두 개의 서버를 연결하는 것만으로는 충분하지 않습니다. 또한 개별 하드웨어 구성 요소는 Windows® 카탈로그(이전의 하드웨어 호환성 목록)에서 구할 수 있다는 사실에만 의존해서도 안 됩니다. 시스템 전체가 Windows 카탈로그에 있는 것이어야 합니다. 하지만 저렴한 비용으로 사용할 수 있는 몇 가지 검증된 클러스터 솔루션이 있으므로 걱정할 필요는 없습니다. 그림 1에서는 일반적인 클러스터 구성을 보여 줍니다.
Figure 1 A typical cluster
Figure 1 A typical cluster (더 작게 보려면 이미지를 클릭하십시오.)
Figure 1 A typical cluster
Figure 1 A typical cluster (더 크게 보려면 이미지를 클릭하십시오.)
물론 클러스터링을 구현하려면 하드웨어 외에 적절한 SQL Server 2005 버전도 선택해야 합니다. Enterprise Edition을 사용하면 클러스터링뿐 아니라 더 많은 수의 CPU를 활용할 수 있는 기능, 분산되어 있고 업데이트가 가능한 분할된 뷰, 기본으로 제공되는 로그 전달, 인덱싱된 뷰 자동 사용과 같은 여러 유용한 기능을 사용할 수 있습니다. 이미 Enterprise Edition 라이선스를 구입한 경우 일반적인 클러스터 구성에 필요한 2-8대의 서버가 있는지 여부에 관계없이 클러스터링 사용을 고려해야 합니다. 잠시 후 1 노드 클러스터에 대해 살펴보겠습니다. SQL Server 2005 Standard Edition을 사용하는 경우 2 노드 클러스터를 설치할 수 있습니다.
Windows Server 2003의 Enterprise Edition 및 Datacenter Edition에서는 클러스터링이 기본으로 제공되므로 클러스터 관리자를 실행하여 클러스터를 설치하기만 하면 됩니다. 노드를 한 번에 모두 추가하거나 한 번에 하나씩 추가할 수 있습니다. 마찬가지로 SQL Server를 클러스터링되지 않은 개별 서버에 설치하거나 클러스터에 가상 인스턴스를 설치할 수 있습니다. 가상 인스턴스를 설치할 경우 클러스터의 모든 노드, 일부 노드 또는 한 노드에만 설치할 수 있습니다.
마지막으로, 클러스터링을 통해 고가용성이라는 궁극적인 목적을 달성하려면 자격을 갖춘 인력과 비상 사태에 대한 대비 절차가 마련되어 있어야 합니다. 클러스터링이 하드웨어 오류에 대한 좋은 방책은 될 수는 있지만 데이터베이스 관리자가 야간 근무 중에 수면 부족으로 중요한 테이블을 잘못 삭제하는 것과 같은 사용자 오류까지 막을 수는 없습니다.

1 노드 클러스터
지금은 단일 서버만 필요하더라도 1 노드 클러스터를 만드는 것을 고려해 보십시오. 그러면 나중에 필요할 때 클러스터로 업그레이드할 수 있으므로 다시 만들 필요가 없습니다. 선택한 하드웨어가 Windows 카탈로그의 클러스터 부분에 포함되어 있는지 확인하기만 하면 됩니다.
이는 나중에 노드를 추가할 수 있도록 하는 고가용성만을 위한 것이 아닙니다. 나중에 서버의 용량이 충분하지 않게 될 경우 어떤 일이 발생할지 생각해 보십시오. 이로 인해 많은 시간과 노력이 수반되는 마이그레이션을 수행해야 할 수도 있습니다. 1 노드 클러스터를 만들면 작동 중단 시간은 대폭 줄이면서도 마이그레이션은 더욱 쉽게 수행할 수 있습니다. 클러스터에 새 노드를 추가하고 새 노드에 SQL Server 이진 파일과 서비스 팩을 추가한 다음 새 노드로 장애 조치합니다. 그런 다음 서비스 팩 이후 나온 업데이트를 추가하고 이전 노드를 제거합니다. 시스템 작동은 장애 조치를 수행하고 업데이트를 추가하는 동안에만 중단됩니다.

노드 추가
클러스터의 노드는 모두 동일해야 하므로 여분의 노드를 미리 준비해 두는 것이 좋습니다. 그렇지 않으면 동일 노드의 생산이 중단될 경우 어려움을 겪을 수 있습니다. 이전에 수행했던 한 프로젝트에서는 SQL Server 2000 클러스터에 한 개의 노드를 다시 만들어야 했습니다. 당시 컴퓨터를 다시 구축하는 기본적인 작업은 운영 체제/네트워크 관리자에게 위임하고 필자는 클러스터에 노드를 다시 추가하여 SQL Server 노드로 작동하도록 준비하는 작업을 진행했습니다. 새 노드로 장애 조치를 시작하기 전까지는 모든 것이 순조롭게 진행되었습니다. 하지만 장애 조치를 시작하자마자 곧바로 오류가 발생했습니다. 간단히 말하자면, 클러스터 서비스 및 SQL Server 서비스 계정을 두 노드에 추가하는 방법을 포함하여 새 클러스터 구축에 대한 자세한 문서를 마련해 두었는데 이 문서의 내용이 정확하게 반영되지 않았던 것입니다. 그 관리자는 다시 만든 노드에 서비스 계정을 추가하지 않았고 그 결과 노드를 다시 만들기 전까지 해당 서비스 계정에 부여되어 있었던 권한이 없어졌습니다.
이 문제의 원인을 추적하기까지 많은 시간이 걸렸습니다. 어느 날 로컬 그룹 멤버 자격을 검토하게 될 일이 생겼고, 이때 두 개의 계정을 추가하게 되었는데 이후부터는 장애 조치가 원활하게 이루어졌습니다. 그때 문득 다음과 같은 생각이 들었습니다. 노드를 다시 만드는 작업은 비상시에만 수행하는 일이지 자주 수행하는 일은 아니라는 것입니다. 문서까지 마련해 두었지만 적절히 사용되지 않았습니다. 당시 두 개의 계정을 추가하고 필요에 맞게 기타 사항을 사용자 지정하는 간단한 스크립트를 작성하여 이 보안 부분을 자동화할 수 있었습니다. SQL Server 2005에서는 상황이 개선되어 설치 관리자가 SQL Server 서비스 계정에 대해 도메인 수준 그룹을 설정하도록 요청합니다.
물론 이로 인해 생각해야 할 것도 많아졌습니다. CLUSTER.EXE를 호출하여 MSCS(Microsoft® Cluster Server) 클러스터에 노드를 추가하는 스크립트를 만들 수 있습니다. 노드 이름만 제공하면 나머지는 스크립트가 자동으로 처리합니다. 비상시에는 자동화가 정말로 편리합니다.

N+1 클러스터
노드를 대체하려는 것이 아닌 다른 이유로 클러스터에 노드를 추가해야 할 경우가 있습니다. 클러스터에 SQL Server 인스턴스를 추가할 수 있지만 각 인스턴스에는 별도의 디스크 리소스가 필요합니다. 단일 노드에서 여러 개의 인스턴스를 실행할 수도 있지만 이 경우 모든 인스턴스가 CPU와 RAM을 공유하므로 성능이 저하될 수 있습니다. 따라서 단일 노드에서 단일 인스턴스를 실행하는 것이 가장 이상적입니다. 하지만 이 경우 장애 조치를 어떻게 수행해야 하는지에 대한 문제가 발생합니다. 방법은 간단합니다. 한 노드에서만 서비스를 실행하지 않고 이외 다른 노드에서는 SQL Server 인스턴스를 하나씩 실행하는 것입니다. 즉, N+1 클러스터란 N+1개의 노드에서 N개의 인스턴스를 실행하는 클러스터를 의미하며, 여분의 노드는 백업용입니다.

SQL Server 업그레이드
클러스터링된 SQL Server 인스턴스를 업그레이드하는 것은 결코 쉬운 작업이 아닌데 클러스터링의 목적이 바로 가동 시간을 늘리는 데 있기 때문입니다. 하지만 SQL Server 2005에서는 이러한 경우에 유용하게 사용할 수 있는 여러 향상된 기능이 있으므로 작동 중단 시간을 최소화하면서 업그레이드를 수행할 수 있습니다.
아래의 내용을 읽고 자신에게 적합한 방법을 선택하십시오. 먼저 비용이 가장 많이 드는 솔루션인 새 클러스터를 만드는 것에 대해 살펴보겠습니다. 새 클러스터를 만든다는 것은 새 서버, 그리고 경우에 따라 새 SAN(Storage Area Network)을 만드는 것을 의미합니다. 기존 네트워크 스위치는 그대로 사용할 수 있지만 그게 전부입니다. 분명히 이 방법은 비용이 저렴하다고는 할 수 없지만 장점이 많습니다. 디스크 용량과 속도가 매우 빠르게 향상되고 있는 새 하드웨어를 사용하면 일반적으로 기존 하드웨어보다 더 나은 성능을 얻을 수 있습니다. 즉, 새 하드웨어만으로도 성능이 개선되는 효과를 볼 수 있습니다. 단순히 기술면에서 앞서가려는 목적이라면 장비를 임대할 수도 있습니다.
하드웨어가 준비되었으면 여기에 새로운 가상 SQL Server를 만들고 프로덕션 데이터베이스를 복사하여 새로운 시스템의 성능을 시험해 봅니다. 시스템 전환일까지 버그를 없앨 시간도 충분합니다. 기존 서버에서 새 서버에 로그인할 수 있도록 지원하는 작업은 스크립트를 통해 수행하십시오. 자세한 내용은 support.microsoft.com/kb/246133에서 확인할 수 있습니다. 치명적 오류가 발생한 경우 로그인 생성 스크립트를 업데이트하는 것도 좋은 방법입니다.
데이터베이스 크기가 매우 작고 어떤 사용자도 연결하지 않는 특정 시간대가 있는 경우가 아니면 작동 중단 시간을 최소화하기 위해 로그 전달을 사용해야 합니다. 시스템 전환일 직전에 로그를 전달할 수도 있습니다. 그런 다음 사용자에게 시스템 사용을 중단할 것을 요청하고 마지막 로그를 잘라서 전달한 다음 새 인스턴스를 가리키도록 응용 프로그램을 설정하면 됩니다. 로그 전달 대신 사용할 수 있는 다른 방법은 아래의 데이터베이스 미러링 단원을 참조하십시오. DNS 별칭을 사용하는 경우 새 인스턴스를 가리키도록 응용 프로그램을 설정할 필요가 없습니다. 이때는 DNS 별칭을 업데이트하면 됩니다. 이 방법은 마이그레이션 작업을 상당 부분 진행했는데 원래 데이터베이스로 되돌려야 할 경우 원래 데이터베이스가 남아 있다는 점에서 그 장점을 찾을 수 있습니다.
이보다 저렴한 방법도 있지만 이를 수행하려면 보다 치밀한 계획이 필요합니다. 클러스터가 둘 이상의 SQL Server 인스턴스를 지원할 수는 있지만 각 인스턴스는 자체의 디스크 리소스를 사용해야 합니다. 따라서 SAN을 구성할 때 향후 업그레이드에 대비하여 LUN 하나를 여분으로 남겨 두어야 합니다. 업그레이드를 수행하려면 이 디스크 리소스에 SQL Server 이진 파일을 설치합니다. 새로운 시스템이 제대로 실행되는지 테스트한 다음 준비가 되면 현재 SQL Server를 종료합니다. 그런 다음 이전 SQL Server 그룹에서 디스크 리소스를 이동하고 종속 관계를 업데이트한 다음 새 SQL Server 인스턴스를 온라인으로 전환합니다. 이전 인스턴스의 데이터베이스를 연결하면 시스템이 작동되기 시작합니다. 잊지 말고 모든 항목을 미리 백업해 두십시오.
이것이 비용이 저렴한 방법입니다. 하지만 여기에는 몇 가지 위험도 따릅니다. 어딘가에서 오류가 발생하더라도 새 인스턴스에서 데이터베이스를 분리하여 원래대로 되돌릴 수 없습니다. 따라서 백업에서 복원할 수밖에 없는데 이 경우 작동 중단 시간이 너무 길어지게 됩니다.
대안으로 SAN에 SQL Server 인스턴스를 두 개 배치하는 방법이 있는데 이 방법을 사용하려면 공간이 충분해야 합니다. 프로덕션 백업과 로그 전달을 새 인스턴스로 복원한 다음 앞에서 설명했던 절차를 진행합니다. 하지만 앞에서와는 다르게 지금은 여분의 LUN이 있습니다. 마이그레이션이 완료되면 이전 인스턴스의 SAN 리소스를 확보할 수 있습니다. 따라서 추가로 사용된 디스크에만 비용을 투자하면 됩니다.

부하 분산
지금부터는 흔히 잘못 알고 있는 다음과 같은 개념에 대해 그 진실을 밝혀보겠습니다. MSCS 클러스터링은 부하 분산이 아니라 고가용성을 위해 사용합니다. 또한 SQL Server에는 기본적으로 제공되는 자동 부하 분산 기능이 없으므로 응용 프로그램의 물리적 설계를 통해 부하를 분산해야 합니다. 이것이 의미하는 바가 무엇인지 궁금하실 것입니다.
테이블의 크기가 커짐에 따라, 특히 이와 함께 테이블 검색이 수반될 경우 성능 저하를 예상할 수 있습니다. 데이터베이스의 행이 엄청나게 많아질 경우 이를 해결하기 위한 방법으로 지금까지는 분할된 뷰가 사용되어 왔습니다. 분할된 뷰란 UNION ALL로 연결된 테이블의 집합이며 테이블들은 동일한 스키마를 가집니다. 또한 멤버 테이블을 구분할 수 있도록 CHECK 제약 조건을 적용하는데 이 때문에 분할된 뷰에서는 데이터 복제가 수행될 수 없었습니다. CHECK 제약 조건에 사용된 열이 기본 키의 일부이기도 한 경우에는 뷰를 업데이트할 수 있습니다.
멤버 테이블이 자체의 파일 그룹에 있으며 해당 파일 그룹의 파일이 별도의 실제 드라이브에 있으면 디스크 성능이 향상됩니다. 테이블을 별도의 데이터베이스에 둘 수도 있습니다. 하지만 SQL Server 2005에서는 모든 데이터가 동일한 데이터베이스에 있는 경우에만 구현하기 휠씬 쉬운 테이블 분할 기술을 사용할 수 있습니다.
하지만 테이블 분할 또는 로컬 분할된 뷰를 사용하여 할 수 있는 모든 시도를 해 보았으나 여전히 성능이 느리다고 가정해 보십시오. SQL Server 2000 또는 SQL Server 2005를 사용하는 경우 분산된 분할된 뷰를 사용할 수 있습니다. 분할된 뷰와 비교했을 때 분산된 분할된 뷰가 가지는 가장 큰 차이점은 멤버 테이블이 서로 다른 SQL Server 인스턴스에 상주할 수 있으며 이러한 인스턴스를 N+1 클러스터에 설치할 수 있다는 것입니다. 굉장하지 않습니까? 분할된 뷰에서는 멤버 테이블 중 하나가 오프라인으로 전환되면 뷰 전체가 오프라인으로 전환됩니다. 이러한 멤버를 클러스터의 일부로 만들면 성능을 개선하는 데 필요한 안정성과 함께 부하 분산이라는 두 가지 목적을 모두 달성할 수 있습니다.

클러스터가 정말로 필요하십니까?
여분의 서버가 있는데 이러한 서버가 Windows 카탈로그의 클러스터 부분에 없는 서버라고 가정해 보십시오. 남아도는 서버가 있는데 클러스터를 지원하려고 새로운 서버를 구입한다는 것은 말이 되지 않습니다.
데이터베이스 미러링은 클러스터링 대신 사용할 수 있는 매우 매력적인 기술입니다. 미러링에는 다음 세 가지 요소가 포함됩니다. 하나는 미러링된 데이터베이스의 원본이 되는 주 서버라는 인스턴스이고 다른 하나는 미러 서버라고 하는 백업 서버입니다. 마지막으로 자동 장애 조치를 원하는 경우 미러링 모니터 서버라고 하는 제3의 서버가 필요합니다. 간단히 말하면 주 서버의 데이터베이스에 있는 트랜잭션이 미러 서버에서 다시 실행됩니다. 주 서버가 다운되면 미러 서버로 장애 조치되며 미러링 모니터 서버가 있는 경우 장애 조치가 자동으로 수행됩니다. 각 응용 프로그램 데이터베이스에 대해 미러링을 설정해야 하며 시스템 데이터베이스는 미러링할 수 없습니다.
미러 서버는 별도의 SQL Server 인스턴스이므로 클러스터와는 달리 수천 킬로미터 떨어진 곳에 둘 수도 있습니다. 미러 서버의 캐시는 주 서버에서 복제된 트랜잭션으로 인해 발생하는 업데이트 작업을 통해 채워집니다. 물론 이는 주 서버에서 미러링된 트랜잭션을 받는 것 외에는 미러 서버에서 어떤 작업도 일어나지 않는다고 가정했을 때의 경우입니다. 미러 서버에서 SQL Server가 이미 실행되고 있으므로 장애 조치가 수행되는 속도는 일반적으로 클러스터보다 빠릅니다. 적어도 캐시의 일부는 최적의 상태이므로 초기 성능은 클러스터링 시나리오만큼 느리지는 않습니다. 또한 미러링된 데이터베이스에 장애 조치가 필요한 경우 주 서버와 미러 서버의 역할이 바뀐다는 점에도 주목하십시오.
데이터베이스 미러링의 경우 클러스터에 비해 필요한 총 디스크 용량이 클러스터의 두 배에 달한다는 단점이 있습니다. 데이터 손실이 없는 동기화 모드로 실행하려면 CPU 성능도 더 우수해야 합니다. 앞에서도 언급했지만 고가용성은 결코 저렴한 기술이 아닙니다.

두 방법의 결합
미러 서버는 주 서버와 멀리 떨어진 지점에 배치할 수 있으므로 장애 복구(DR) 계획에 적합합니다. 클러스터를 최전방 방어선으로 사용할 수 있지만 클러스터링과 미러링을 모두 사용하면 훨씬 좋습니다. 클러스터 장애 조치를 사용할 경우 미러링 구성의 일부로 미러링 모니터 서버를 배치하면 클러스터링된 SQL Server가 온라인으로 전환되는 동안 미러 서버가 주 서버가 됩니다. 하지만 새로운 주 서버에서 클러스터링된 새 미러 서버로의 장애 조치는 자동으로 수행되지 않는다는 점에 주목하십시오. 결과적으로 클러스터와 함께 사용할 때는 미러링된 데이터베이스에 자동 장애 조치를 사용하지 않는 것이 좋습니다.
미러링을 사용하는 이유가 재해 복구에만 있는 것은 아닙니다. 미러링은 주 서버에 서비스 팩이나 핫픽스를 적용해야 할 경우 미러 서버로 수동으로 장애 조치할 수 있으므로 유용합니다. 서비스 팩이나 핫픽스를 적용하는 동안에는 이전의 주 서버가 임시로 오프라인으로 전환되고 새로운 주 서버에서 발생하는 커밋된 트랜잭션은 큐로 보내져 다시 새 미러 서버(이전의 주 서버)로 보내질 때까지 대기합니다. 서비스 팩 또는 핫픽스 설치가 끝나면 동기화가 수행되어 두 서버가 완전히 동기화됩니다. 동기화가 끝나면 주 서버와 미러 서버의 역할을 바꿀 수 있습니다. 장애 조치를 수행하고 원래대로 되돌리는 데 필요한 작동 중단 시간은 매우 짧습니다. SQL Server를 다른 컴퓨터로 마이그레이션하는 데 이 방법을 사용할 수 있습니다. 실패하지 말고 잘 해보십시오.

가상 서버 추가가 제공하는 융통성
가상화 기술을 사용하면 한 대의 실제 서버에서 하나 이상의 운영 체제를 동시에 실행할 수 있습니다. 가상화 소프트웨어를 사용하면 소프트웨어에도 클러스터링을 적용할 수 있으므로 클러스터의 기능이 한 층 더 다양해집니다. 결론부터 말하자면 호스트가 실행되는 서버에서 오류가 발생하면 서버와 서버의 게스트 운영 체제가 백업 노드로 장애 조치됩니다. 따라서 게스트 서버를 간편하게 마이그레이션하는 방법으로 이용할 수 있습니다. 게다가 게스트 운영 체제에서는 클러스터링을 지원할 필요가 없으므로 클러스터에서 Microsoft Virtual Server 2005를 실행하는 게스트 Windows Server 2003 내에서 SQL Server Workgroup Edition을 실행할 수 있습니다. 이를 통해 간접적으로 Workgroup Edition을 클러스터링한 결과를 얻을 수 있습니다(그림 2 참조).
Figure 2 Using a virtual server
Figure 2 Using a virtual server (더 작게 보려면 이미지를 클릭하십시오.)
Figure 2 Using a virtual server
Figure 2 Using a virtual server (더 크게 보려면 이미지를 클릭하십시오.)

관리
SQL Server 구현을 담당하는 사람은 서버를 항상 사용 가능한 상태로 유지해야 합니다. 서버 클러스터링을 사용하면 이러한 목표를 쉽게 달성할 수 있습니다. 이 문서에서는 클러스터링을 시작하는 데 도움이 되는 몇 가지 유용한 정보를 제공합니다. . "클러스터링 리소스" 추가 기사에서는 보다 자세한 정보를 제공하는 문서의 링크를 제공합니다.
클러스터링 리소스
이 문서에서 설명하는 방법 및 SQL Server 클러스터를 설정하는 데 필요한 다양한 제품에 대한 자세한 내용은 다음 리소스를 참조하십시오.
  • SQL Server 2005 장애 조치 클러스터링
  • SQL Server 2000 장애 조치 클러스터링
  • 클러스터링 서비스
  • Microsoft 클러스터 서버 관리자 가이드
  • Microsoft Virtual Server 2005 R2

Tom Moreau는 토론토에 거주하며 이학 석사 학위, 박사 학위, MCSE 인증 및 MCDBA 인증을 소지하고 있습니다. 현재는 SQL Server 데이터베이스 관리, 설계 및 구현 분야의 전문적인 독립 컨설턴트로 활동하고 있습니다. 1993년부터 SQL Server를 사용해 왔고 2001년부터 SQL Server MVP로 활동하고 있습니다. 지금까지 작성한 기사만 100편이 넘으며 SQL Server 관련 서적의 공동 저자이기도 합니다. 유용한 정보를 제공한 SQL Server MVP Geoff Hiten에게 감사를 전합니다.


 Windows Administration: Windows Vista 커널 속으로: 2부
Windows Administration Mark Russinovich

Windows Vista 커널 속으로: 2부
한 눈에 보기:
  • 메모리 관리
  • 시작 및 종료
  • 전원 관리

3부로 구성된 이 연재물의 첫 번째 칼럼이 게시되었던 지난 달에는 프로세스와 I/O 영역에서 Windows Vista 커널의 향상된 기능을 살펴봤습니다.
이번 호에는 시스템 시작, 종료 및 전원 관리와 Windows Vista의 메모리 관리 방식에서 어떤 점이 향상되었는지 설명하겠습니다(1부).
Windows®는 새로운 릴리스가 나올 때마다 확장성과 성능이 향상되었으며 Windows Vista™도 예외는 아닙니다. Windows Vista 메모리 관리자에는 멈춤 없는 동기화 기술, 세부적인 잠금, 더 강력해진 데이터 구조 압축, 더 큰 페이징 I/O, 최신 GPU 메모리 아키텍처 지원, 하드웨어 TLB(Translation Lookaside Buffer)의 효율적 활용 등 다양한 향상된 기능이 포함되어 있습니다. 또한 Windows Vista 메모리 관리 기능은 이제 다양한 작업 부하 요구 사항을 충족하는 동적 주소 공간 할당을 제공합니다.
Windows Vista에서는 새로운 4가지 성능 향상 기술인 SuperFetch, ReadyBoost, ReadyBoot 및 ReadyDrive가 새롭게 제공됩니다. 이에 대해서는 뒷부분에서 자세히 살펴보겠습니다.

동적 커널 주소 공간
Windows와 Windows용 응용 프로그램은 32비트 프로세서의 주소 공간 한계에 직면했습니다. 즉, Windows 커널은 기본적으로 2GB 또는 전체 32비트 가상 주소 공간의 절반으로 제한되며 나머지 절반은 CPU에서 현재 실행되고 있는 스레드가 속한 프로세스에 사용하도록 예약됩니다. 커널은 이 절반의 주소 공간에서 자신을 매핑하고, 장치 드라이버, 파일 시스템 캐시, 커널 스택, 세션별 코드 데이터 구조 및 장치 드라이버가 할당하는 비페이징(잠긴 실제 메모리) 버퍼와 페이징 버퍼 모두를 매핑해야 합니다. Windows Vista 이전의 메모리 관리자는 부팅될 때 이러한 여러 용도로 할당할 주소 공간의 크기를 결정했습니다. 즉, 이와 같이 유연하지 못하기 때문에 일부 영역에는 가용 공간이 많이 남고 일부 영역에는 가용 공간이 없는 상황이 발생하기도 합니다. 영역을 모두 사용하게 되면 응용 프로그램 오류가 발생하고 장치 드라이버는 I/O 작업을 마칠 수 없게 됩니다.
32비트 Windows Vista에서는 메모리 관리자가 커널의 주소 공간을 동적으로 관리하여 작업 부하 요구 사항에 따라 공간을 여러 용도에 할당 및 할당 취소합니다. 즉, 장치 드라이버가 더 많은 주소 공간을 요구하면 페이징 버퍼 저장에 사용되는 가상 메모리의 양을 늘릴 수 있으며 드라이버의 요구가 사라지면 가상 메모리의 양을 줄일 수 있습니다. 따라서 Windows Vista는 더 다양한 작업 부하를 처리할 수 있으며, 마찬가지로 향후 발표될 Windows Server®의 32비트 버전인 코드명 "Longhorn"에서는 더 많은 동시 터미널 서버 사용자를 처리할 수 있습니다.
물론 64비트 Windows Vista 시스템의 주소 공간에는 현재 실질적으로 아무런 제약이 없으므로 최대값으로 구성하기 위한 별다른 조치는 필요하지 않습니다.

메모리 우선 순위
지난 호에서 언급했듯이 Windows Vista에서는 I/O 우선 순위를 추가한 것처럼 메모리 우선 순위도 구현합니다. Windows가 메모리 우선 순위를 사용하는 방식을 이해하려면 메모리 관리자가 대기 목록이라고 하는 메모리 캐시를 구현하는 방식을 이해해야 합니다. Windows Vista 이전의 모든 Windows 버전에서는 프로세스가 소유하는 실제 페이지(일반적으로 크기가 4KB)를 시스템이 회수하면 메모리 관리자는 일반적으로 페이지를 대기 목록의 끝에 배치합니다. 프로세스가 페이지에 다시 액세스하려고 하면 메모리 관리자가 대기 목록에서 페이지를 가져와서 프로세스에 다시 할당합니다. 프로세스가 실제 메모리의 새 페이지를 사용하려고 하는데 사용 가능한 메모리가 없으면 메모리 관리자는 대기 목록의 앞에 있는 페이지를 프로세스에 할당합니다. 이러한 구성에서는 대기 목록의 모든 페이지가 기본적으로 동일하게 처리되며 목록에 배치된 시간만 정렬의 기준으로 사용됩니다.
Windows Vista에서는 메모리의 모든 페이지에 0부터 7까지의 우선 순위가 있기 때문에 메모리 관리자는 대기 목록을 특정 우선 순위의 페이지가 저장되는 8개의 목록으로 나눕니다. 메모리 관리자는 대기 목록에서 페이지를 가져올 때 우선 순위가 낮은 목록에서부터 페이지를 가져옵니다. 페이지의 우선 순위에는 일반적으로 해당 페이지를 처음 할당한 스레드의 우선 순위가 반영됩니다. 페이지가 공유된 경우에는 공유 스레드 중 가장 높은 메모리 우선 순위가 반영됩니다. 스레드는 자신이 속한 프로세스에서 페이지 우선 순위 값을 상속합니다. 메모리 관리자는 프로세스의 메모리 액세스를 예측할 때 미리 디스크에서 읽는 페이지에 대해 낮은 우선 순위를 사용합니다.
기본적으로 프로세스의 페이지 우선 순위 값은 5이지만 함수를 사용하면 응용 프로그램과 시스템이 프로세스 및 스레드 페이지 우선 순위 값을 변경할 수 있습니다. 메모리 우선 순위의 진정한 효과는 페이지의 상대적 우선 순위를 전체적인 차원에서 이해할 때만 현실화되는데 이 작업을 바로 SuperFetch가 수행합니다.

SuperFetch
메모리 관리자가 실제 메모리를 관리하는 방식에는 상당한 변화가 있습니다. 이전 버전의 Windows에서 사용되던 대기 목록 관리에는 두 가지 제한이 있습니다. 첫 번째는 페이지의 우선 순위 지정이 프로세스의 최근 동작에만 의존하며 향후의 메모리 요구 사항은 예측하지 않는다는 점입니다. 두 번째는 우선 순위 지정에 사용되는 데이터가 모든 특정 시점에서 프로세스가 소유한 페이지의 목록으로 제한된다는 점입니다. 이러한 단점 때문에 잠시 컴퓨터 앞을 떠나면 바이러스 검사나 디스크 조각 모음과 같이 메모리 사용이 많은 시스템 응용 프로그램이 실행되는 "점심 식사 후 신드롬"과 같은 상황이 발생할 수 있습니다. 이 경우 현재 활성화된 응용 프로그램이 메모리에 캐시한 코드와 데이터를 메모리 사용량이 많은 작업이 덮어쓰게 됩니다. 사용자가 다시 컴퓨터로 돌아오면 응용 프로그램은 데이터와 코드를 디스크에 요청해야 하기 때문에 성능 저하가 발생합니다.
Windows XP에서는 대용량 디스크 I/O를 수행하여 이전의 부팅 및 응용 프로그램 실행을 기준으로 예측되는 코드와 파일 시스템 데이터를 메모리에 미리 로드함으로써 부팅과 응용 프로그램의 시작 성능을 높이는 프리페치(Prefetch)를 지원했습니다. Windows Vista에서는 기록 정보와 예측적인 메모리 관리를 기반으로 "오래 전 액세스(Least-Recently Accessed)" 알고리즘을 향상시키는 메모리 관리 구성인 SuperFetch를 통해 이를 더욱 향상시킵니다.
SuperFetch는 서비스 호스트 프로세스(%SystemRoot%\System32\Svchost.exe) 내에서 실행되는 Windows 서비스로 %SystemRoot%\System32\Sysmain.dll에서 구현됩니다. 이 구성은 메모리 관리자의 지원을 통해 페이지 사용 내역을 검색하며, 메모리 관리자가 디스크의 파일이나 페이징 파일의 데이터와 코드를 대기 목록으로 미리 로드하고 페이지에 우선 순위를 할당하도록 합니다. SuperFetch 서비스는 기본적으로 메모리에 한 번 로드되었지만 새 데이터와 코드를 위한 공간을 마련하기 위해 메모리 관리자에서 다시 사용되는 데이터와 코드에까지 페이지 추적을 확장합니다. 이 정보는 응용 프로그램 실행을 최적화하는 데 사용되는 표준 프리페치 파일과 함께 %SystemRoot%\Prefetch 디렉터리에서 .db 확장명으로 시나리오 파일에 저장됩니다. SuperFetch는 메모리 사용에 대한 이러한 자세한 정보를 통해 실제 메모리를 사용할 수 있게 되었을 때 데이터와 코드를 미리 로드합니다.
응용 프로그램이 종료되었거나 메모리가 해제된 경우와 같이 메모리가 해제되면 SuperFetch는 최근 지워진 데이터와 코드를 페치하도록 메모리 관리자에게 요청합니다. 이 작업은 매우 낮은 우선 순위 I/O를 통해 초당 몇 페이지의 속도로 수행되므로 미리 로드가 사용자나 기타 활성 응용 프로그램에는 영향을 미치지 않습니다. 따라서 점심 식사를 위해 자리를 비운 동안 메모리 사용이 많은 백그라운드 작업으로 인해 활성 응용 프로그램의 코드와 데이터가 메모리에서 삭제된 경우 SuperFetch는 사용자가 돌아오기 전에 이 코드와 데이터 전부 또는 대부분을 다시 메모리로 로드할 수 있습니다. 또한 SuperFetch는 최대 절전 모드, 대기 모드, FUS(빠른 사용자 전환) 및 응용 프로그램 실행에 대한 몇 가지 시나리오도 지원합니다. 예를 들어 시스템이 최대 절전 모드에 들어가면 SuperFetch는 이전의 최대 절전 모드를 기준으로 하여 이후의 작업 재개 도중 액세스할 것으로 예상되는 데이터와 코드를 최대 절전 모드 파일에 저장합니다. 이와 반대로 Windows XP에서는 작업을 다시 시작하는 경우 이전에 캐시된 데이터가 참조되면 해당 데이터를 디스크에서 다시 읽어야 합니다.
SuperFetch가 사용 가능한 메모리에 영향을 주는 방식에 대해서는 추가 기사 "SuperFetch 살펴보기"를 참조하십시오.
SuperFetch 살펴보기
Windows Vista 시스템을 어느 정도 사용하고 나면 작업 관리자의 성능 페이지에 Free Physical Memory(사용 가능한 실제 메모리) 카운터의 숫자가 낮은 것을 볼 수 있습니다. SuperFetch와 표준 Windows 캐시가 디스크 데이터를 캐시하기 위해 사용 가능한 모든 실제 메모리를 사용하기 때문입니다. 예를 들어 처음 부팅했을 때 즉시 작업 관리자를 실행하면 Cached Memory(캐시된 메모리)의 값이 늘어남에 따라 Free Memory(사용 가능한 메모리) 값이 줄어드는 것을 볼 수 있습니다. 메모리를 많이 사용하는 프로그램을 실행한 후 종료하거나(예: 많은 양의 메모리를 할당했다가 해제하는 프리웨어 "RAM 최적화 프로그램") 매우 큰 파일을 복사한 경우에는 시스템이 할당 해제된 메모리를 회수하기 때문에 사용 가능 숫자는 올라가고 실제 메모리 사용 현황 그래프는 떨어집니다. 하지만 시간이 지나면 SuperFetch는 강제로 메모리에서 해제된 데이터를 캐시에 다시 채우므로 캐시됨 메모리 값은 늘어나고 사용 가능 메모리 값은 줄어듭니다.
Watching memory
Watching memory (더 작게 보려면 이미지를 클릭하십시오.)
Watching memory
Watching memory (더 크게 보려면 이미지를 클릭하십시오.)

ReadyBoost
CPU와 메모리의 속도는 하드 디스크 속도와 비교할 수 없을 정도로 빠르기 때문에 디스크는 흔히 시스템 성능의 병목 지점이 됩니다. 특히 디스크 헤드 검색 시간은 오늘날 많이 사용되는 3GHz 프로세서에 비하면 매우 느린 10밀리초대에 머무르기 때문에 임의 디스크 I/O는 특히 심한 병목 지점이 됩니다. 디스크 데이터의 캐시에는 RAM이 이상적이기는 하지만 RAM은 상대적으로 가격이 높습니다. 그러나 플래시 메모리는 일반적으로 저렴하며 일반 하드 디스크에 비해 최대 10배 빠른 임의 읽기를 제공할 수 있습니다. 따라서 Windows Vista에는 메모리와 디스크 사이에 논리적으로 존재하는 중간 캐시 계층을 플래시 메모리에 만들어서 플래시 메모리 저장 장치의 장점을 활용하는 ReadyBoost라는 기능이 포함되어 있습니다.
ReadyBoost는 서비스 호스트 프로세스에서 실행되는 %SystemRoot%\System32\Emdmgmt.dll에서 구현되는 서비스와 볼륨 필터 드라이버인 %SystemRoot%\System32\Drivers\Ecache.sys로 구성됩니다. Emd는 외부 메모리 장치(Enternal Memory Device)를 의미하며 개발 과정에서는 ReadyBoost의 임시 명칭이었습니다. USB 키 등의 플래시 장치를 시스템에 연결한 경우 ReadyBoost 서비스는 장치의 성능 특성을 검사하고 그 테스트 결과를 그림 1에 표시된 것처럼 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt에 저장합니다.
Figure 1 ReadyBoost device test results in the registry
Figure 1 ReadyBoost device test results in the registry (더 작게 보려면 이미지를 클릭하십시오.)
Figure 1 ReadyBoost device test results in the registry
Figure 1 ReadyBoost device test results in the registry (더 크게 보려면 이미지를 클릭하십시오.)
아직 장치를 캐시용으로 사용하고 있지 않은 경우 새 장치의 크기가 256MB부터 32GB 사이이고 임의 4KB 읽기에 대한 전송 송도가 2.5MB/s 이상, 임의 512KB 쓰기에 대한 전송 속도가 1.75MB/s 이상이면 ReadyBoost는 저장 장치의 최대 4GB를 디스크 캐시에 사용할 것인지 묻습니다(ReadyBoost는 NTFS를 사용할 수 있지만 FAT32 제한을 수용할 수 있도록 최대 캐시 크기를 4GB로 제한함). 이 질문에 동의하면 서비스는 장치의 루트에 ReadyBoost.sfcache라는 캐시 파일을 만들고 SuperFetch에게 백그라운드에서 캐시를 채우라고 요청합니다.
ReadyBoost 서비스가 캐시를 초기화하고 나면 Ecache.sys 장치 드라이버는 로컬 하드 디스크 볼륨(예: C:\)에 대한 모든 읽기와 쓰기를 가로채고 기록 중인 모든 데이터를 서비스가 만든 캐시 파일에 씁니다. Ecache.sys는 데이터를 압축하며 일반적으로 2:1 압축 비율을 제공하기 때문에 4GB 캐시 파일에는 대개 8GB의 데이터가 포함됩니다. 드라이버는 장치가 시스템에서 제거되었을 때 캐시에 있는 데이터의 보안을 유지하기 위해 AES(고급 암호화 표준) 암호화를 사용하여 임의로 생성된 부팅별 세션 키로 각 블록을 암호화합니다.
ReadyBoost는 캐시에서 사용 가능한 임의 읽기 작업이 있으면 캐시에서 이를 지원합니다. 그러나 하드 디스크는 플래시 메모리보다 순차 읽기 액세스 성능이 더 뛰어나므로 ReadyBoost는 순차 액세스 패턴의 일부인 읽기 작업을 데이터가 캐시에 있더라도 디스크에서 직접 수행할 수 있습니다.

ReadyBoot
Windows Vista는 시스템 메모리가 512MB 미만인 경우에는 Windows XP와 동일하게 부팅 시 프리페치를 사용하지만 시스템 RAM이 700MB 이상인 경우에는 부팅 프로세스를 최적화하기 위해 RAM 내부 캐시를 사용합니다. 캐시의 크기는 사용 가능한 전체 RAM에 따라 다르지만 적절한 캐시를 만들 수 있으면서 시스템이 매끄럽게 부팅될 수 있을 정도가 사용됩니다.
모든 부팅 후 ReadyBoost 서비스(앞서 설명한 ReadyBoost 기능을 구현하는 것과 같은 서비스)는 유휴 CPU 시간을 사용하여 다음 부팅에 대한 부팅 시간 캐시 계획을 계산합니다. 다섯 번의 이전 부팅을 토대로 파일 추적 정보를 분석하여 액세스된 파일의 위치와 디스크에서의 각 파일 위치를 확인합니다. 이렇게 처리된 추적을 %SystemRoot%\Prefetch\Readyboot에 .fx 파일로 저장하고 캐시 계획은 HKLM\System\CurrentControlSet\Services\Ecache\Parameters 아래에서 추적이 참조하는 내부 디스크 볼륨을 따라 이름이 지정된 REG_BINARY 값으로 저장합니다.
캐시는 ReadyBoost 캐시를 구현하는 것과 동일한 장치 드라이버(Ecache.sys)로 구현되지만 캐시를 채우는 작업은 시스템 부팅 시 ReadyBoost 서비스에 의해 진행됩니다. 부팅 캐시는 ReadyBoost 캐시처럼 압축되지만 ReadyBoost와 ReadyBoot 캐시 관리의 또 다른 차이점은 ReadyBoot 모드에서는 ReadyBoost 서비스의 업데이트를 제외하고 부팅 도중 읽거나 쓴 데이터에 따라 캐시가 변경되지 않는다는 점입니다. ReadyBoost 서비스는 부팅 시작 90초 후 또는 다른 메모리에서 이와 같이 요구하는 경우 캐시를 삭제하며 캐시의 통계를 그림 2와 같이 HKLM\System\CurrentControlSet\Services\Ecache\Parameters\ReadyBootStats에 기록합니다. Microsoft의 성능 테스트 결과 ReadyBoot는 이전 Windows XP 프리페처에 비해 약 20퍼센트 높은 성능 향상을 제공합니다.
Figure 2 ReadyBoot Performance statistics
Figure 2 ReadyBoot Performance statistics (더 작게 보려면 이미지를 클릭하십시오.)
Figure 2 ReadyBoot Performance statistics
Figure 2 ReadyBoot Performance statistics (더 크게 보려면 이미지를 클릭하십시오.)

ReadyDrive
ReadyDrive는 H-HDD라고 하는 새로운 혼성 하드 디스크 드라이브를 사용하는 Windows Vista 기능입니다. H-HDD는 NVRAM이라고도 하는 비휘발성 플래시 메모리가 내장된 디스크입니다. 일반적인 H-HDD에는 50MB에서 512MB의 캐시가 포함되지만 Windows Vista의 캐시 제한은 2TB입니다.
Windows Vista는 ATA-8 명령을 사용하여 플래시 메모리에 유지될 디스크 데이터를 정의합니다. 예를 들어 Windows Vista는 더 빠르게 다시 시작할 수 있도록 시스템 종료 시 부팅 데이터를 캐시에 저장합니다. 또한 시스템이 최대 절전 모드에서 더 빠르게 다시 시작할 수 있도록 시스템이 최대 절전 모드에 들어갈 때 최대 절전 모드 파일 일부를 캐시에 저장합니다. 캐시는 디스크가 회전하지 않을 때도 사용할 수 있기 때문에 Windows에서는 배터리 전원으로 시스템을 실행할 때 디스크를 회전시키지 않고 플래시 메모리를 디스크 쓰기 캐시로 사용할 수 있습니다. 디스크가 회전하지 않도록 하면 일반적인 사용 상황에서 디스크 드라이브가 소모하는 전력을 상당히 절약할 수 있습니다.

부팅 구성 데이터베이스
Windows Vista에서는 시작 및 종료의 여러 측면이 향상되었습니다. 시스템 및 OS 시작 구성을 저장하기 위한 BCD(부팅 구성 데이터베이스), 시스템 시작 프로세스의 새로운 흐름 및 구성, 새로운 로그온 아키텍처, 지연된 자동 시작 서비스 지원 등을 통해 시작 기능이 향상되었습니다. Windows Vista 종료 기능은 Windows 서비스의 사전 종료 알림, Windows 서비스 종료 순서 지정 및 OS의 전원 상태 전환 관리 방법을 비롯하여 상당히 변경되었습니다.
시작 프로세스에서 가장 눈에 띄는 변화는 시스템 볼륨의 루트에 Boot.ini가 없다는 점입니다. 이전 버전의 Windows에서 Boot.ini 텍스트 파일에 저장되던 부팅 구성이 Windows Vista에서는 BCD에 저장되기 때문입니다. Windows Vista에서 BCD를 사용하는 이유 중 하나는 BCD를 통해 Windows가 지원하는 두 가지의 최신 부팅 아키텍처인 MBR(마스터 부트 레코드)과 EFI(Extensible Firmware Interface)를 통합할 수 있기 때문입니다. MBR은 일반적으로 x86 및 x64 데스크톱 시스템에 사용되며 EFI는 Itanium 기반 시스템에 사용됩니다. 그러나 조만간 데스크톱 PC에도 EFI 지원이 적용될 것으로 예상됩니다. BCD는 펌웨어를 추상화하며 유니코드 문자열 지원 또는 대체 부팅 전 실행 파일 지원과 같이 Boot.ini에 비해 여러 가지 장점을 갖고 있습니다.
BCD는 실제로 Windows 레지스트리로 로드되어 레지스트리 API를 통해 액세스할 수 있는 레지스트리 하이브에 저장됩니다. PC의 경우 BCD는 시스템 볼륨의 \Boot\Bcd에 저장되고 EFI 시스템의 경우에는 EFI 시스템 파티션에 저장됩니다. 하이브는 로드된 경우 HKLM\Bcd00000000 아래에 나타나지만 내부 형식은 문서화되지 않으므로 하이브를 편집하려면 %SystemRoot%\System32\Bcdedit.exe와 같은 도구를 사용해야 합니다. 또한 BCD를 조작하기 위한 인터페이스를 WMI(Windows Management Instrumentation)를 통해 사용자 정의 편집기 및 스크립트에서도 사용할 수 있으며, Windows 시스템 구성 유틸리티(%SystemRoot%\System32\Msconfig.exe)를 사용하여 커널 디버깅 옵션과 같은 기본 매개 변수를 편집하거나 추가할 수 있습니다.
BCD는 기본 OS 선택 및 부팅 메뉴 시간 제한과 같은 플랫폼 전체의 부팅 설정을 OS 부팅 옵션 및 OS 부팅 로더의 경로와 같은 OS별 설정과 분리합니다. 예를 들어 그림 3에서 Bcdedit를 명령줄 옵션 없이 실행하면 출력 상단의 Windows 부팅 관리자 섹션에 플랫폼 설정이 표시되고 그 뒤의 Windows 부팅 로더 섹션에 OS별 설정이 표시되는 것을 볼 수 있습니다.
Figure 3 Settings displayed in BCDEdit
Figure 3 Settings displayed in BCDEdit (더 작게 보려면 이미지를 클릭하십시오.)
Figure 3 Settings displayed in BCDEdit
Figure 3 Settings displayed in BCDEdit (더 크게 보려면 이미지를 클릭하십시오.)
설치된 Windows Vista를 부팅하면 이러한 새로운 구성에 따라 이전 버전의 Windows에서 운영 체제 로더(Ntldr)로 처리되던 작업이 서로 다른 두 실행 파일인 \BootMgr 및 %SystemRoot%\System32\Winload.exe로 분리됩니다. Bootmgr은 BCD를 읽고 OS 부팅 메뉴를 표시하며, Winload.exe는 운영 체제 로드를 처리합니다. 클린 부팅을 수행하면 Winload.exe는 부팅 시작 장치 드라이버와 Ntoskrnl.exe를 포함한 운영 체제 핵심 파일을 로드하고 제어 권한을 운영 체제에게 넘깁니다. 시스템이 최대 절전 모드에서 다시 시작하는 경우에는 %SystemRoot%\System32\Winresume.exe를 실행하여 최대 절전 모드 데이터를 메모리로 로드하고 OS를 다시 시작합니다.
Bootmgr은 추가적인 부팅 전 실행 파일도 지원합니다. Windows Vista에서는 RAM의 상태를 검사하기 위한 옵션으로 미리 구성된 Windows 메모리 진단 도구(\Boot\Memtest.exe)를 제공하지만 타사의 부팅 전 실행 파일을 옵션으로 추가하여 Bootmgr의 부팅 메뉴에 표시할 수도 있습니다.

시작 프로세스
이전 버전의 Windows에서는 여러 시스템 프로세스 간의 관계가 간단하지 않았습니다. 예를 들어 시스템이 부팅될 때 대화형 로그온 관리자(%SystemRoot%\System32\Winlogon.exe)는 로컬 보안 기관 하위 시스템 서비스(Lsass.exe) 및 서비스 제어 관리자(Services.exe)를 실행합니다. 또한 Windows는 세션이라고 하는 네임스페이스 컨테이너를 사용하여 서로 다른 로그온 세션에서 실행되고 있는 프로세스를 격리합니다. 그러나 Windows Vista 이전에는 사용자가 세션 0을 공유하는 콘솔로 로그인했으며 이 세션은 시스템 프로세스에 사용되었기 때문에 잠재적인 보안 문제가 있었습니다. 예를 들어 잘못 작성된 Windows 서비스가 세션 0에서 실행되어 대화형 콘솔에 사용자 인터페이스를 표시하면 맬웨어가 파편 공격(Shatter Attack)과 같은 방법을 통해 Windows를 공격하고 관리 권한을 획득할 가능성이 있습니다.
이러한 문제를 해결하기 위해 Windows Vista에서는 몇 가지 시스템 프로세스의 아키텍처가 재구성되었습니다. 세션 관리자(Smss.exe)는 이전 버전의 Windows와 마찬가지로 부팅 도중 만들어지는 첫 번째 사용자 모드 프로세스이지만 Windows Vista에서는 세션 관리자가 자신의 두 번째 인스턴스를 실행하여 시스템 프로세스 전용으로 사용되는 세션 0을 구성합니다. 세션 0의 세션 관리자 프로세스는 세션 0에 대한 Windows 하위 시스템 프로세스(Csrss.exe)인 Windows 시작 응용 프로그램(Wininit.exe)을 실행한 다음 종료됩니다. Windows 시작 응용 프로그램은 계속해서 서비스 제어 관리자, 로컬 보안 기관 하위 시스템과 시스템에 대한 터미널 서버 연결을 관리하는 로컬 세션 관리자(Lsm.exe)를 시작합니다.
사용자가 시스템에 로그온하면 최초 세션 관리자는 자신의 인스턴스를 새로 만들어서 새 세션을 구성합니다. 새 Smss.exe 프로세스는 새 세션에 대한 Winlogon 프로세스와 Windows 하위 시스템 프로세스를 시작합니다. 기본 세션 관리자가 자신의 복사본을 사용하여 새 세션을 초기화하는 것이 클라이언트 시스템에는 이점이 되지 않지만, 터미널 서버 역할을 하는 Windows Server "Longhorn" 시스템에서는 여러 개의 복사본을 동시에 실행하여 여러 사용자의 로그온 속도를 높일 수 있습니다.
이와 같은 새로운 아키텍처를 통해 Windows 서비스를 비롯한 시스템 프로세스는 세션 0으로 격리됩니다. 세션 0에서 실행되는 Windows 서비스가 사용자 인터페이스를 표시하면 대화형 서비스 감지 서비스(%SystemRoot%\System32\UI0Detect.exe)가 사용자의 보안 컨텍스트에 자신의 인스턴스를 실행하고 그림 4의 메시지를 표시하여 로그온한 모든 관리자에게 이를 알립니다. 사용자가 "메시지 표시" 단추를 선택하면 이 서비스는 바탕 화면을 Windows 서비스 바탕 화면으로 변경합니다. 사용자는 이 바탕 화면에서 서비스의 사용자 인터페이스와 상호 작용한 다음 다시 자신의 바탕 화면으로 전환할 수 있습니다. 시작 시 수행되는 작업에 대한 자세한 내용은 추가 기사 "시작 프로세스 관계 보기"를 참조하십시오.
Figure 4 Service has displayed a window
Figure 4 Service has displayed a window (더 작게 보려면 이미지를 클릭하십시오.)
Figure 4 Service has displayed a window
Figure 4 Service has displayed a window (더 크게 보려면 이미지를 클릭하십시오.)
시작 프로세스 관계 보기
Sysinternals의 Process Explorer(microsoft.com/technet/sysinternals)를 사용하면 Windows Vista의 프로세스 시작 트리를 볼 수 있습니다.
스크린 샷에는 Process Explorer의 열 대화 상자를 통해 추가할 수 있는 세션 열이 포함되어 있습니다. 강조 표시된 프로세스는 최초 Smss.exe입니다. 그 아래에는 세션 0 Csrss.exe 및 Wininit.exe가 있습니다. 세션 0을 구성한 Smss.exe의 인스턴스인 상위 프로세스가 종료되었기 때문에 이 두 프로세스는 왼쪽으로 정렬되어 있습니다. Wininit의 세 가지 하위 프로세스는 Services.exe, Lsass.exe 및 Lsm.exe입니다.
Process Explorer를 통해 여러 프로세스가 세션 1에서 실행되고 있음을 확인할 수 있습니다. 이러한 세션은 필자가 원격 데스크톱 연결을 통해 로그인한 세션입니다. Process Explorer에서 동일한 계정으로 실행되고 있는 프로세스는 파란색으로 강조 표시되어 있습니다. 마지막으로, 세션 2가 초기화되어 사용자의 콘솔 로그인 및 새 로그온 세션 생성을 준비합니다. 이 세션에서 Winlogon이 실행되며 LogonUI가 새 콘솔 사용자에게 "로그온하려면 &lt;Ctrl+Alt+Del&gt; 을 누르십시오."를 표시하고 Logonui.exe가 사용자에게 자격 증명을 요청합니다.
Startup process and session information
Startup process and session information (더 작게 보려면 이미지를 클릭하십시오.)
Startup process and session information
Startup process and session information (더 크게 보려면 이미지를 클릭하십시오.)

자격 증명 공급자
Windows Vista에서는 로그온 아키텍처도 변경되었습니다. 이전 버전의 Windows에서는 Winlogon 프로세스가 레지스트리에 지정된 GINA(Graphical Identification and Authentication) DLL을 로드하여 사용자에게 자격 증명을 요청하는 로그온 UI를 표시했습니다. 그러나 GINA 모델에는 몇 가지 제약이 있습니다. 즉, 하나의 GINA만 구성할 수 있고, 타사에서 완벽한 GINA를 작성하는 것이 어렵고, 비표준 사용자 인터페이스가 있는 사용자 지정 GINA가 Windows 사용자 환경을 변경하는 것 등이 있습니다.
Windows Vista에서는 GINA 대신 새로운 자격 증명 공급자 아키텍처를 사용합니다. Winlogon은 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers에 구성된 자격 증명 공급자를 로드하는 로그온 사용자 인터페이스 호스트(Logonui.exe)라는 별도의 프로세스를 실행합니다. Logonui는 여러 개의 자격 증명 공급자를 동시에 호스트할 수 있습니다. 실제로 Windows Vista에서는 대화형 공급자(Authui.dll) 및 스마트 카드 공급자(Smart-cardcredentialprovider.dll)를 모두 제공합니다. 일관된 사용자 환경을 제공하기 위해 LogonUI는 최종 사용자에게 표시되는 사용자 인터페이스를 관리하며, 자격 증명 공급자는 LogonUI를 통해 텍스트, 아이콘 및 편집 컨트롤 등의 사용자 지정 요소를 지정할 수 있습니다.

지연된 자동 시작 서비스
Windows 시스템을 시작한 후 바로 로그인한 적이 있다면 데스크톱이 완전히 구성되고 셸 및 기타 응용 프로그램을 사용할 수 있을 때까지 약간의 시간이 지연되는 것을 경험했을 수 있습니다. 사용자가 로그온하는 동안 서비스 제어 관리자는 자동 시작 서비스로 구성되어 부팅할 때 활성화되는 여러 Windows 서비스를 시작합니다. CPU 및 디스크 사용량이 많은 초기화를 수행하는 서비스는 많이 있으며 이러한 서비스는 사용자의 로그온 작업과 경쟁하게 됩니다. 이러한 상황을 해결하기 위해 Windows Vista에서는 Windows 부팅 후 즉시 활성화할 필요가 없는 서비스에 사용할 수 있는 지연된 자동 시작이라고 하는 새로운 서비스 시작 유형을 제공합니다.
서비스 제어 관리자는 자동 시작 서비스의 시작이 완료된 후에 지연된 자동 시작으로 구성된 서비스를 시작하고 이러한 서비스의 초기 스레드 우선 순위를 THREAD_PRIORITY_LOWEST로 설정합니다. 이 우선 순위 수준으로 인해 스레드가 수행하는 모든 디스크 I/O는 매우 낮음 I/O 우선 순위가 됩니다. 서비스의 초기화가 완료되면 서비스 제어 관리자는 해당 우선 순위를 보통으로 설정합니다. 지연된 시작, 낮은 CPU 및 메모리 우선 순위, 백그라운드 디스크 우선 순위가 결합되어 사용자의 로그온에 미치는 영향이 크게 줄어듭니다. 부팅 후의 로그온 성능을 높이기 위해 BIT(Background Intelligent Transfer), Windows Update 클라이언트 및 Windows Media® Center를 포함한 많은 Windows 서비스가 이러한 새로운 시작 유형을 사용합니다.

종료
Windows 서비스 개발자를 괴롭히는 문제 중 하나는 Windows 종료 시 정리를 수행하기 위한 시간이 기본적으로 최대 20초라는 점입니다. Windows Vista 이전 버전의 Windows에서는 버그가 있는 서비스로 인해 종료가 완료되지 못할 수 있기 때문에 모든 서비스가 종료될 때까지 기다리는 "완전한 종료(Clean Shutdown)"를 지원하지 않았습니다. 하지만 네트워크 관련 종료 작업이 있거나 많은 데이터를 디스크에 저장해야 하는 일부 서비스의 경우에는 시간이 더 필요할 수 있기 때문에 Windows Vista에서는 서비스가 사전 종료 알림을 요청할 수 있습니다.
Windows Vista를 종료하면 서비스 제어 관리자는 먼저 사전 종료 알림을 요청하는 서비스에 Windows Vista 종료를 알립니다. 이러한 서비스가 종료될 때까지 무기한 대기하지만 버그가 있어서 쿼리에 응답하지 않는 서비스가 있는 경우 서비스 제어 관리자는 3분간 기다린 후 포기하고 다음 단계를 진행합니다. 이러한 서비스가 모두 종료되었거나 시간 제한이 만료되면 서비스 제어 관리자는 나머지 서비스에 대해 기존 방식의 서비스 종료를 진행합니다. 그룹 정책 및 Windows Update 서비스는 새로 설치된 Windows Vista의 사전 종료 알림을 등록합니다.
그룹 정책 및 Windows Update 서비스는 또한 다른 Windows Vista 서비스인 종료 순서 지정 기능도 사용합니다. Windows Vista 이전 버전의 Windows에서 서비스는 서비스 제어 관리자가 각 서비스에 맞는 순서로 서비스를 시작하도록 허용하는 시작 종속성을 지정할 수 있었지만 종료 종속성은 지정할 수 없었습니다. 이제는 사전 종료 알림에 등록한 서비스가 HKLM\System\CurrentControlSet\Control\PreshutdownOrder에 저장된 목록에 해당 서비스를 삽입할 수 있으며 이 경우 서비스 제어 관리자는 이 순서에 따라 해당 서비스를 종료합니다. 이러한 서비스에 대한 자세한 내용은 "지연된 자동 시작 및 사전 종료 서비스 확인" 추가 기사를 참조하십시오.

전원 관리
절전 모드 및 최대 절전 모드는 종료의 한 형태입니다. Windows 2000의 전원 관리 기능을 Windows NT® 기반 Windows 운영 체제 제품군에 적용한 이후로 드라이버와 응용 프로그램에서 발생하는 전원 관리 버그는 이동이 잦은 사용자에게 문제가 되곤 했습니다. 출장을 떠나기 전에 랩톱 시스템이 일시 중단 또는 최대 절전 모드로 들어갈 것으로 예상하고 랩톱 시스템을 닫았지만 목적지에 도착해 보니 랩톱 시스템이 계속 실행되고 있거나 배터리가 방전되었거나 데이터가 손실된 것을 경험한 사용자가 많습니다. 이러한 문제의 원인은 Windows가 항상 장치 드라이버와 응용 프로그램에게 전원 상태 변경에 대한 동의를 요청하며 응답하지 않는 드라이버나 응용 프로그램이 하나라도 있으면 전원 모드를 전환하지 않는다는 데 있습니다.
Windows Vista의 경우 커널의 전원 관리자는 드라이버와 응용 프로그램에게 전원 상태 변경을 알려 미리 준비할 수 있도록 하지만 이에 대해 동의를 구하지는 않습니다. 또한 전원 관리자는 이전 버전의 Windows에서처럼 2분씩 기다리는 것이 아니라 응용 프로그램이 변경 알림에 응답할 때까지 최대 20초만 기다립니다. 결과적으로 Windows Vista 사용자는 시스템의 최대 절전 모드 또는 일시 중단 모드로의 전환에 대해 안심할 수 있습니다.

다음 호에서 다룰 내용
앞서 설명했듯이 이 문서는 3부로 구성된 연재물 중 두 번째입니다. 1부에서는 I/O 및 프로세스 영역에서 Windows Vista 커널의 향상된 기능을 살펴봤습니다. 이번 호에서는 메모리 관리, 시작 및 종료 부분에서 Windows Vista의 향상된 기능에 대해 다루었습니다. 다음 호에서는 안정성 및 보안 측면에서 커널의 변경 사항을 설명하여 이 연재물을 마무리하려고 합니다.
지연된 자동 시작 및 사전 종료 서비스 확인
Windows Vista에서는 기본 제공 SC 명령이 업데이트되어 다음과 같이 지연된 자동 시작 서비스로 구성된 서비스가 표시됩니다.
Using SC to display start type
Using SC to display start type (더 작게 보려면 이미지를 클릭하십시오.)
Using SC to display start type
Using SC to display start type (더 크게 보려면 이미지를 클릭하십시오.)
그러나 SC 명령은 사전 종료 알림을 요청한 서비스를 보고하지 않습니다. 대신 Sysinternals의 PsService 유틸리티를 사용하면 서비스가 사전 종료 알림을 수용하는지 확인할 수 있습니다.
Viewing pre-shutdown status
Viewing pre-shutdown status (더 작게 보려면 이미지를 클릭하십시오.)
Viewing pre-shutdown status
Viewing pre-shutdown status (더 크게 보려면 이미지를 클릭하십시오.)

Mark Russinovich는 Microsoft의 플랫폼 및 서비스(Platform and Services) 부서에서 근무하는 기술 연구원으로, Microsoft Windows Internals(Microsoft Press, 2004)의 공동 저자이자 IT와 개발자 회의에 자주 서는 연설자이며 최근 Microsoft에서 인수한 Winternals Software의 공동 설립자이기도 합니다. 그는 자신이 설립한 Sysinternals에서 Process Explorer, Filemon 및 Regmon 유틸리티를 개발하기도 했습니다.


 From The Editor: 트로피 진열장
From The Editor
트로피 진열장
Joshua Trupin

필자는 30년 가까이 살아오면서 상이라고는 받아본 적이 없습니다. 하다못해 즉석 복권도 숫자 두 개 이상은 맞춰본 적이 없을 정도이니까요. 경품을 준다는 과자 봉지를 열어도 "다음 기회에"라는 문구밖에는 없었습니다. 풋볼 플레이오프 우승팀을 예상하는 투표에서도 항상 뉴욕 팀만 선택하곤 했습니다.
이러한 형편없는 이력을 감안하면 실제로 뭔가 상을 받게 되었을 때 필자가 얼마나 기뻐했을지 상상할 수 있을 겁니다. 얼마 전 TechNet Magazine이 STC(Society for Technical Communication)로부터 4개 부문에서 상을 받게 된 것입니다. 매 발행 호마다 심혈을 기울여왔기 때문에 이러한 노력이 인정을 받게 된 것에 대해 정말 뿌듯하게 생각하고 있습니다. 이 지면을 빌려 우리 직원과 기고자들에게 감사를 전합니다.
2006년 3월/4월호에서는 그림 맞추기 퍼즐 포스터 형식으로 Active Directory에 대한 명확하고 이해하기 쉬운 가이드를 제공했습니다. 이 기사는 너무 인기를 끌어 아직까지도 사본을 요청하는 독자들이 있을 정도입니다. STC에서는 이 포스터에 Excellence for Software Guides 상을 수여했습니다.
이외에도 기사 2개가 높은 점수를 받았습니다. Greg Taylor와 Simon Shepherd가 작성한 2006년 8월호 기사 "Playing with Exchange in a Sandbox", 그리고 Jesper Johansson과 Steve Riley가 작성한 2006년 5/6월호 기사 "Deconstructing Common Security Myths"는 STC로부터 Merit 상을 받았습니다.
TechNet Magazine 자체도 학술 및 전문지 부문에서 Award of Excellence 상을 받았습니다. 이러한 최고의 영예를 얻게 된 것에 대해 더없이 기쁜 마음은 필자는 물론 우리 팀에서 일하는 다른 동료들도 마찬가지입니다.
그렇다고 여기에 안주해 있지는 않을 테니 걱정하지 않으셔도 됩니다. 이번 호에서 Mark Russinovich는 Windows Vista의 커널 변경 사항에 대해 설명을 계속합니다. 이는 데스크톱 개발 또는 지원 서비스와 관련한 일을 하는 모든 IT 전문가에게 중요한 정보가 될 것입니다. 또한 이번 호에서는 SQL Server에 대해서도 심도 있게 살펴봅니다. 이 기사는 인덱스 메타데이터를 사용한 테이블 분할 및 고가용성 옵션, 클러스터링 팁에 이르기까지 다양한 주제를 다룹니다.
One TechNet Magazine Plaza의 모든 직원은 지금도 쉴 새 없이 움직이고 있습니다. 항상 마감 기한에 쫓기고 있으니까요. 그러나 가끔은 색다른 곳에서 일하는 즐거움이 따르기도 합니다. 2007년 6월 4일에서 8일까지 올랜도에서 Microsoft TechoEd에 참여하게 되었습니다. 자세한 내용은 microsoft.com/teched를 참조하십시오. 이 행사에 참가하여 수상 경력을 자랑하는 TechNet Magazine 편집자와 작가들을 만나 보시기 바랍니다. 몇 가지 기념품과 재미있는 순서도 마련되어 있으므로 기대하시기 바랍니다. -JOSHUA TRUPIN
많은 Microsoft 기술 전문가들께서 도움을 주셨습니다. Vijay Bharadwaj, Paul Bowden, Elden Christensen, Manish Karla, Michael Murgolo, Rajeev Nagar, John Peng, Mark Russinovich, Abraham Samuel, Mark Scurrell, Jim Truher, George Walters, 그리고 Buck Woody에게 감사를 전합니다.

Joshua Trupin


 Toolbox: IT 전문가를 위한 새로운 제품
Toolbox
IT 전문가를 위한 새로운 제품
Greg Steen

네트워크 동기화 관리
ViceVersa Pro
www.tgrmn.com

극히 단순한 인프라를 사용하는 것이 아니라면 현재 환경에서 사용하는 모든 파일을 항상 이동해야 할 것입니다. 로그 파일에서 응용 프로그램 릴리스, 데이터베이스 백업에 이르기까지 데이터는 언제나 네트워크를 통해 이동됩니다. 또한 다른 환경의 동기화를 유지하기 위해 어떤 파일을 복사해야 하는지 아는 것이 중요합니다. 대부분의 IT 전문가는 환경 내의 파일을 수동으로 이동하지 않습니다. 이는 두말할 것도 없이 동기화에 악영향을 초래하기 때문입니다.
TGRMN Software의 ViceVersa Pro를 사용하면 동기화 작업을 손쉽게 자동화하고 예약할 수 있습니다. 이 응용 프로그램에서는 네 가지 복사 모드를 제공합니다. Basic Synchronization 모드를 사용하면 원본에서 대상으로 동기화할 수 있으며 Advanced Synchronization 모드를 사용하면 파일 추적과 함께 양방향 파일 및 디렉터리 동기화 작업을 수행할 수 있습니다. 나머지 두 가지 모드는 Backup(원본 미러링 작업 수행)과 Consolidation입니다.
Backup 모드에서는 원본을 대상에 미러링하며 해당 대상에서 파일을 추가하고 삭제할 수 있습니다. 또한 파일 복제를 선택하여 대상에 파일을 복사만 할 수도 있습니다. 이 기능은 사용자가 예기치 않게 항목을 삭제한 경우 매우 유용합니다. 이름에서 알 수 있듯이, 양방향 동기화를 수행하면 충돌 및 삭제를 추적할 수 있습니다. 다음번 동기화 전에 원본과 대상의 파일이 모두 변경된 경우 충돌이 감지되며 사용자는 이러한 충돌을 수동으로 조정할 수 있습니다. Consolidation 방식은 양방향 동기화와 비슷하지만 충돌이나 삭제를 추적하지는 않습니다.
Protect against copy errors and data loss
Protect against copy errors and data loss (더 작게 보려면 이미지를 클릭하십시오.)
Protect against copy errors and data loss
Protect against copy errors and data loss (더 크게 보려면 이미지를 클릭하십시오.)
ViceVersa Pro를 사용하면 Backup 모드에서 통합된 파일 압축 및 파일 암호화 기능을 사용하여 로그 전달 작업을 수행할 수 있습니다. ViceVersa Pro에서는 원본 파일을 암호로 보호할 수 있는 표준 gzip 형식으로 압축합니다.
통합된 파일을 손쉽게 비교할 수 있는 기능도 포함되어 있으나 외부 파일 비교 프로그램을 사용하고 싶은 경우 ViceVersa Pro에서 해당 설정을 지정할 수 있습니다. 또한 ViceVersa에서는 유니코드 문자 및 256자를 초과하는 경로를 처리할 수 있으므로 전 세계 각국 환경에서 사용할 수 있습니다. 인터넷 시간 동기화도 기본적으로 지원되므로, ViceVersa를 사용할 환경에서의 아웃바운드 요청을 허용하면 ViceVersa가 로컬 NTP 상자나 외부의 모든 NTP 서버를 가리키도록 설정할 수 있습니다.
트래픽이 VPN 또는 WAN을 통과하는 경우 대역폭 활용이 문제가 될 수 있습니다. 이 경우 ViceVersa를 사용하면 각 동기화 작업에 사용하는 대역폭을 제한할 수 있습니다. 이렇게 하면 항목을 복사할 서버나 복사해 올 서버에서 프로덕션 수준의 대응을 수행할 수 있습니다. 또는 최대 CPU 사용률 임계값을 설정하면 응용 프로그램 실행 시 서버 가용성을 유지할 수 있습니다.
ViceVersa Pro에서는 안전 복사 알고리즘을 사용하여 복사 오류 및 데이터 손실을 방지합니다. 또한 데이터 무결성을 주기적으로 중복 확인합니다. 실시간 모드를 비롯한 대부분의 모든 간격에서 동기화 작업이 실행되도록 일정을 설정할 수 있습니다. 이렇게 하면 동기화 폴더에 추가되었거나 삭제된 파일을 동기화할 수 있습니다.
ViceVersa Pro의 또 다른 뛰어난 기능은 실행 전에 UI를 통해 모든 작업을 미리 볼 수 있다는 점입니다. 이를 통해 복사하도록 의도한 파일을 정확하게 복사하고 작업이 완료된 후 시스템 디렉터리에 몇 GB의 로그 파일이 남게 되는 일을 방지할 수 있습니다.
저렴한 가격대에 완전한 기능을 갖춘 동기화 도구를 찾고 계시다면 지금 바로 ViceVersa Pro를 사용해 보시기 바랍니다.
가격: 단일 사용자당 $59.95

시스템 디스크 관리
Partition Manager 8.0 Professional Edition
www.partition-manager.com/corporate/professional
시스템 디스크를 관리할 수 있는 응용 프로그램을 찾고 있다면 Paragon Software Group의 Partition Manager 8.0 Professional Edition을 강력히 추천합니다.
Partition Manager 8.0 Professional Edition은 Windows® 기반 응용 프로그램으로서 직관적인 마법사 기반 인터페이스로 되어 있어 표시 내용을 쉽게 만들고, 삭제하고, 변경할 수 있으며 FAT16/32, NTFS, Ext2/3, HPFS와 같은 모든 파일 시스템 형식의 하드 디스크 파티션을 포맷할 수 있습니다. 또한 기존 파티션의 크기를 조정하거나 다른 디스크로 파티션을 이동할 수도 있습니다.
여기에서 한 단계 더 나아가 NTFS와 같은 파일 시스템 형식을 FAT 16/32으로 또는 Ext2에서 Ext3로 전환할 수 있으며 반대로 전환할 수도 있습니다. 한 디스크에서 다른 디스크로 파티션을 복사하면 해당 디스크의 크기에 맞게 파티션의 크기를 자동으로 조정하므로, 모든 파일을 수동으로 복사할 필요 없이 시스템의 데이터 드라이브를 쉽게 확장할 수 있습니다. 8.0 버전의 대표적인 유용한 기능은 "Hot Resize"입니다. 이 기능을 사용하면 Windows를 다시 부팅하지 않고도 사용 중인 NTFS 파티션의 크기를 늘릴 수 있습니다.
Increase the size of an active NTFS partition £ without rebooting
Increase the size of an active NTFS partition £ without rebooting (더 작게 보려면 이미지를 클릭하십시오.)
Increase the size of an active NTFS partition £ without rebooting
Increase the size of an active NTFS partition £ without rebooting (더 크게 보려면 이미지를 클릭하십시오.)
Pro Edition의 또 다른 유용한 기능으로는 Windows 2000, Windows XP, Windows Server® 2003 클라이언트에서 동적 디스크를 기본 디스크로 변환할 수 있는 기능을 들 수 있습니다. Partition Manager는 적어도 최대 500GB(Paragon사에서 검증한 테스트 한계이며 실제적인 한계치는 아님)의 디스크를 지원하며 FireWire 및 USB 연결 드라이브도 지원합니다. 또한 PATA(IDE), SATA, 및 SCSI 하드 디스크를 지원합니다.
Partition Manager를 사용하면 치명적인 디스크 오류 이후 시스템을 복원할 수 있는 복구 CD(또는 DVD나 플로피 디스크)를 만들 수 있습니다. 또는 시스템을 사용하는 도중 실수로 파티션을 삭제한 경우 인터페이스를 통해 해당 파티션의 삭제를 취소할 수 있습니다. 디스크의 클러스터 크기를 변경하여 성능을 세부적으로 조정할 수도 있습니다. 또한 "Virtual Pre-execution" 보기를 통해 디스크에 실제적인 변경 사항을 적용하기 전에 해당 디스크의 변경 사항을 평가할 수 있습니다.
Partition Manager 8.0을 사용하면 시스템의 하드 드라이브를 업그레이드할 수 있으며, 하나의 파티션이나 전체 하드 디스크 이미지를 새 디스크로 복사하여 대상 파티션에 맞게 크기를 조정해 줍니다.
끝으로 Partition Manager에는 최대 99%까지 찬 드라이브에서도 조각 모음을 할 수 있는 디스크 조각 모음 기능이 포함되어 있습니다. 물론 드라이브가 이와 같이 되기 전에 다른 조치를 취하시길 바랍니다.
가격: Professionals Edition - 99.95$

SQL 편집기에 자동 완료 추가
SQL Prompt: IntelliSense for SQL
www.red-gate.com/products/SQL_Prompt/index.htm

표준화된 양식의 논리적 명명 규칙에 따라 모든 데이터베이스를 만들고 구조화할 수 있다면 정말 좋겠지만, 안타깝게도 이는 불가능한 것이 사실입니다. 필자의 경우 시스템 관리나 데이터베이스 관리 업무를 수행하면서 쿼리를 만들거나 실행할 때 테이블 구조를 자꾸 다시 참조하는 버릇이 있다는 걸 알 수 있었습니다. 개발 업무를 수행할 때에도 마찬가지로 말입니다.
SQL Server™ Management Studio for SQL Server 2005로 인해 개체 브라우저를 인터페이스의 트리 보기 섹션으로 통합할 수 있게 되어 작업이 훨씬 수월해졌지만, 여전히 Visual Studio® IDE: IntelliSense®에서 사용했던 익숙한 기능을 사용하고 싶었습니다. 반갑게도 이제 Red-Gate Software사의 SQL Prompt를 사용하면 Microsoft SQL Server 편집기에서 자동 완성 기능이 제공됩니다.
이 응용 프로그램은 작업 표시줄에서 실행되며 편집기에서 작업을 시작하면 이를 감지합니다. 우선 SQL Prompt에서는 모든 개체 데이터에 연결하고 이를 캐싱할 수 있도록 해당 데이터베이스에 대한 연결 정보를 묻는 메시지를 표시합니다. 이렇게 하면 작업 성능 속도를 올리고 오버헤드를 감소시킬 수 있지만 지속적으로 데이터베이스 인스턴스에서 개체를 수정할 경우에는 캐시를 제거(두 번 클릭으로 간단히 제거 가능)해야만 메시지 표시 목록의 변경된 사항을 볼 수 있습니다.
또한 Visual Studio IDE, Enterprise Manager, Query Analyzer 및 SQL Server Management Studio 이외에도 SQL Prompt는 UltraEdit 및 EditPlus 2와 바로 통합될 수 있습니다. Setting UI의 Options 탭에서 트리거할 후보 목록(예: FROM, JOIN, EXEC 등)의 SQL 키워드를 지정할 수 있습니다. SQL JOINS에서 SQL Prompt를 트리거하면 동일한 이름을 가진 참조 집합이나 필드를 사용한다고 가정했을 때 ON 문이 제공됩니다. 또한 코드 조각 삽입을 위한 텍스트 바로 가기도 설정할 수 있습니다. 예를 들어 "ssf"를 입력하고 Tab 키를 누르면 이를 "SELETCT * FROM"으로 변경하도록 설정할 수 있습니다. SQL Prompt를 사용하면 SQL 키워드 입력 시 자동으로 대문자로 변경되도록 할 수 있습니다. 이 방법과 코드 조각을 사용하면 많은 시간을 절약할 수 있습니다.
Settings UI의 Candidates 탭에서 SQL Prompt가 정규화된 열 이름(소유자/스키마 정보가 있는 접두사를 붙이고 대괄호로 이름을 묶음)을 사용하도록 할 것인지 여부를 설정할 수 있으며, 후보 목록에 어떤 유형의 SQL 함수를 표시할 것인지도 설정할 수 있습니다. SQL 사용자라면 이 도구를 비장의 무기로 사용하고 싶으실 것입니다.
SQL Prompt는 3.0 버전이 릴리스되기 전까지 무료로 제공되며 현재 최종 베타가 진행 중입니다. 3.0 버전의 가격은 아직 책정되지 않았습니다.
가격: 무료

페이지 크기 계산
Atomic Web Page Size Calculator
www.info-pack.com/pagesize
최종 사용자 대역폭은 앞으로 더욱 늘어날 것이며 새로운 기술을 통해 최종 사용자에게 웹 콘텐츠를 보다 빠르게 전달할 수 있겠지만 페이지 크기는 여전히 중요한 문제입니다. 이러한 모든 바이트는 트래픽이 많은 사이트의 경우 막대한 대역폭 비용으로 이어집니다.
Info-pack.com의 Atomic Page Size Calculator 유틸리티는 저렴한 비용으로 웹 사이트 페이지의 용량을 확인할 수 있는 방법을 제공합니다. 사용 방법은 아주 간단합니다. 크기를 알아 보려는 페이지 URL을 입력하면 해당 프로그램에서 페이지를 찾아 외부에 참조된 이미지(기본 도메인의 웹 로그에 표시되지 않는 항목)를 포함한 모든 요소의 용량을 계산합니다.
Keep an eye on bandwidth cost
Keep an eye on bandwidth cost (더 작게 보려면 이미지를 클릭하십시오.)
Keep an eye on bandwidth cost
Keep an eye on bandwidth cost (더 크게 보려면 이미지를 클릭하십시오.)
이 프로그램은 페이지, 이미지 및 JavaScript 파일을 지원하므로 페이지에 있는 대부분의 리소스에서 데이터를 가져올 수 있습니다. 또한 404 "끊긴" 리소스에 접근할 경우 알림을 통해 이를 사용자에게 알립니다. URL 용량 정보를 받은 다음에는 Report 단추를 눌러 크기 분석 및 다양한 연결 속도에서 해당 URL을 다운로드할 경우 소요되는 예상 시간을 확인할 수 있습니다.
이 프로그램에서 여러 개의 URL을 동시에 처리할 수 있다면 더욱 좋겠지만 이 기능은 후속 릴리스에서 만나볼 수 있을 것 같습니다. 개발 부서에서 작업하고 있는 페이지의 크기를 신속하게 확인할 수 있는 방법을 찾고 있다면 바로 이 프로그램을 사용해 보기 바랍니다.
가격: $19.95

Toolbox로 의견 보내기
여기에서 다루었으면 하는 도구나 유틸리티가 있으면 tntools@microsoft.com 주소로 저자에게 알려 주십시오.
Greg Steen은 열정적으로 일하는 기술 전문가이자 기업가로서, IT 전문가들이 작업과 개발을 보다 쉽게 수행할 수 있도록 항상 새로운 도구와 방법을 모색합니다.


 Utility Spotlight: SyncToy
Utility Spotlight
SyncToy
Jay Munro
이 기사의 코드 다운로드: SynctToy (971KB)

IT 전문가, 네트워크 관리자 및 기술 지원 부서 직원에게 있어서 가장 골치 아플 때는 백업도 마련해 두지 않은 상태에서 컴퓨터에 오류가 발생한 사용자로부터 지원 요청을 받을 때입니다. 컴퓨터에 대해 잘 안다는 사람들도 작업을 로컬뿐만 아니라 네트워크에 저장하는 습관을 기르는 것이 쉽지 않을 수 있습니다. SyncToy를 사용하면 이러한 경우에 도움이 됩니다.
카메라, 컴퓨터 및 외부 드라이브 간에 디지털 사진을 동기화할 목적으로 설계된 SyncToy는 거의 모든 종류의 파일을 백업하는 데 사용할 수 있는 융통성이 뛰어나고 안정적인 도구입니다. Windows Vista™는 물론 Windows® XP 및 Windows Server® 2003에서도 실행할 수 있는 SyncToy는 로컬 드라이브, 외부 드라이브, USB 드라이브는 물론 네트워크 공유 또는 작업 그룹 공유와도 잘 작동합니다.
SyncToy는 왼쪽 및 오른쪽 디렉터리로 구성된 쌍으로 된 폴더 구조를 사용합니다. 폴더 쌍은 원하는 만큼 얼마든지 만들 수 있으며 단추를 한 번만 클릭하여 한 폴더나 모든 폴더를 동기화할 수 있습니다. 폴더 쌍을 만들려면 4단계로 구성된 마법사를 단계별로 진행하여 왼쪽 및 오른쪽 폴더의 경로를 입력하거나 붙여 넣습니다. 폴더의 위치를 찾아볼 수도 있습니다. SyncToy는 UNC 파일 이름 지정(예: \\MyServer\Joe_smith\backup\)은 물론 로컬 드라이브 매핑과 경로(E:\doc_backup)를 인식합니다. 경로를 입력한 후에는 다음 다섯 가지 작업 중 하나를 선택합니다. 이 다섯 가지 작업은 SyncToy에서 폴더를 비교할 때 수행하는 작업입니다.
Sync 두 디렉터리 모두로 새로운 파일 및 업데이트된 파일을 복사합니다. 한 폴더에서 파일 이름을 바꾸거나 파일을 삭제한 경우에는 해당 작업 내용이 다른 폴더에 복제됩니다.
Echo 왼쪽 폴더에서 오른쪽 폴더로만 새로운 파일 및 업데이트된 파일을 복사하고 삭제 및 이름 바꾸기를 수행합니다.
Subscribe 왼쪽 폴더에 파일이 이미 있는 경우에만, 업데이트된 파일을 오른쪽 폴더에서 왼쪽 폴더로 복사합니다. 왼쪽 폴더의 변경 내용은 오른쪽 폴더로 복제되지 않습니다.
Contribute 왼쪽 폴더의 새로운 파일 및 업데이트된 파일을 오른쪽 폴더로 복사합니다. 삭제된 내용은 무시합니다.
Combine 한 폴더에는 있지만 다른 폴더에는 없는 파일을 복사하여 여러 컴퓨터를 동기화된 상태로 유지합니다. 두 폴더 중 하나에서 삭제되거나 이름이 바뀐 파일은 영향을 받거나 복제되지 않습니다.
작업을 선택한 후에는 폴더 쌍의 이름을 선택합니다. 현재까지는 SyncToy에서 폴더 쌍을 한번 만든 후에는 폴더 쌍의 경로를 편집하거나 이름을 변경할 수 없으므로 잘못 만든 경우에는 폴더 쌍을 선택하고 삭제를 클릭하여 폴더 쌍을 제거한 다음 다시 만듭니다. 포함할 파일 및 하위 디렉터리를 비롯하여 덮어쓴 파일을 휴지통에 저장할지 여부 등의 옵션도 설정할 수 있습니다. 기본적으로 덮어쓴 파일은 휴지통에 저장됩니다.
Synchronizing files with SyncToy
Synchronizing files with SyncToy (더 작게 보려면 이미지를 클릭하십시오.)
Synchronizing files with SyncToy
Synchronizing files with SyncToy (더 크게 보려면 이미지를 클릭하십시오.)

기본 SyncToy 대화 상자의 왼쪽에는 폴더 쌍과 함께 폴더 쌍의 경로와 폴더 쌍에 설정된 옵션 및 작업이 표시됩니다. All Folder Pairs 옵션은 모든 폴더 쌍을 나열합니다. 선택한 폴더 쌍에 대해 Preview나 Run All을 수행할 수 있습니다. Preview를 선택하면 실제로 동기화가 수행되는 것과 같이 일련의 동작이 일어나지만 실제로는 어떤 것도 변경되지 않습니다. 무인 동기화를 예약하려는 경우에는 이러한 미리 보기 기능이 상당히 유용합니다. 미리 보기를 수행하면 어떤 작업이 수행될지를 보여 주는 보고서가 표시됩니다. 보고서의 내용에 아무 문제가 없으면 Run을 클릭합니다.
예약 기능은 기본으로 제공되지 않습니다. 하지만 도움말 파일에서 Windows Vista와 Windows XP의 스케줄러를 사용하여 작업을 예약하는 단계를 볼 수 있습니다. 관련 지식이 없는 사용자의 경우 작업 예약을 설정하는 데 도움이 필요할 수도 있습니다. 하지만 한 번만 설정해 두면 폴더 쌍의 변경 내용, 작업 및 옵션은 SyncToy 자체에서 수행되므로 걱정할 필요가 없습니다.
모든 Power Toy와 마찬가지로 SyncToy도 일반적으로 제공되는 소프트웨어와 동일한 표준에 따라 작성되기는 했지만 Microsoft에서 별도로 지원하지는 않습니다. 도움이 필요하면 커뮤니티 포럼과 설명서를 참조하십시오. 모든 것을 직접 해결해야 합니다. 도움말 파일은 모든 수준의 사용자에 맞게 작성되었으며 관련 기능을 매우 자세하게 다룹니다. UI는 처음 보면 기본 기능을 금방 이해할 수 있을 정도로 직관적입니다.
이제 SyncToy를 다운로드하여 사용자에게 파일을 백업하는 방법을 보여 주십시오. 그러면 한밤중에 지원 요청을 받는 일 없이 숙면을 취할 수 있을 것입니다.

Jay Munro는 Microsoft의 Windows User Assistance 팀에서 라이터로 활동하고 있으며 전문 분야는 Internet Explorer입니다. 이전에는 PC Magazine Lab의 프로젝트 팀장으로 활동한 이력이 있습니다.


 SQL Q&amp;A: 일광 절약 시간제, 서버 메모리 및 기타
SQL Q&A
일광 절약 시간제, 서버 메모리 및 기타
편집자: Nancy Michell

일광 절약 시간제
Q: 포괄적 에너지법안(Energy Policy Act of 2005)에 따라 곧 미국의 DST(일광 절약 시간제)가 바뀌게 될 텐데 이에 맞춰 SQL Server™를 업데이트해야 합니까?
A: 그렇지 않습니다. 현재까지는 변경된 DST를 지원하기 위해 SQL Server에서 특별히 수행해야 할 업데이트는 없습니다. SQL Server에서는 기본 운영 체제의 설정에 따라 시간 관련 데이터를 처리합니다. 즉, 운영 체제에서 올바른 날짜와 시간을 보고한다면 SQL Server에서도 동일한 값을 사용하고 보고하므로 아무런 문제가 없습니다. 앞으로 시행될 변경된 DST를 적용하려면 support.microsoft.com/kb/928388에 설명된 바와 같이 Windows® 복사본을 업데이트해야 합니다. 변경된 DST를 따르려면 SQL Server가 실행되는 Windows 운영 체제를 포함하여 Windows Vista™ 이전의 모든 Windows 운영 체제에서 이 업데이트 작업을 수행해야 합니다. Windows Vista™에는 변경된 DST가 적용되어 있습니다. 오스트레일리아에서도 일부 지역의 DST가 변경되었습니다. 자세한 내용은 support.microsoft.com/kb/912475를 참조하십시오.

Windows Vista에 연결
Q: Windows Vista를 설치한 후부터 시스템의 SQL Server 2005에 연결할 수 없습니다. 로컬 관리자이며 지금까지는 아무런 문제 없이 연결할 수 있었습니다. 무엇이 문제일까요?
A: 이는 Windows Vista와 SP2(서비스 팩 2)가 설치되지 않은 SQL Server 2005에서 나타날 수 있는 현상입니다. Windows Vista에는 사용자 계정 컨트롤이라는 새로운 보안 모델이 도입되었습니다. 이 보안 모델은 로컬 관리자 그룹의 사용자 멤버 자격을 인식하여 사용자가 관리자 권한이 필요한 작업을 수행하려 한다는 것을 알려 주는 대화 상자를 표시합니다. 허용 단추를 클릭하면 사용자의 관리자 토큰이 포함된 자격 증명이 응용 프로그램으로 보내집니다. 단순히 도구만 실행할 때는 관리자 권한이 필요하지 않으므로 SSMS(SQL Server Management Studio)를 사용하려고 할 경우에는 대화 상자가 표시되지 않습니다. 이 문제의 원인은 SQL Server 2005 시스템 관리자 역할에 기본적으로 운영 체제의 로컬 관리자 그룹이 포함된다는 데 있습니다. 이전에는 이 로컬 관리자 그룹의 계정을 통해 SQL Server에 액세스했습니다. 하지만 Windows Vista에서는 이 권한을 보내지 않으므로 SQL Server에 액세스할 수 없게 됩니다.
SP2가 설치되지 않은 SQL Server 2005는 Windows Vista에서 실행이 지원되지 않으며, SP2에는 사용자 계정을 추가하는 도구가 포함되어 있습니다. 아직 SP2가 제공되지 않은 경우에는 다른 방법으로 이 문제를 간단히 해결할 수 있습니다. 개별 Windows 사용자 계정을 SQL Server 시스템 관리자 역할에 추가하면 됩니다. SQL Server Management Studio를 마우스 오른쪽 단추로 클릭하고 관리자 권한으로 실행을 선택하여 SQL Server에 연결한 다음 시스템 관리자 역할에 Windows 계정을 추가하기만 하면 됩니다. 이에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

뷰를 사용한 트랜잭션 복제
Q: 뷰를 게시하고 업데이트한 경우에는 트랜잭션이 복제된다는 것을 알고 있습니다. 하지만 이 뷰의 기본 테이블을 업데이트한 경우에도 트랜잭션이 복제됩니까? 마지막으로, 테이블을 게시하고 테이블의 뷰를 만든 다음 기본 테이블 대신 이 뷰를 업데이트했습니다. 이 경우에도 트랜잭션이 복제됩니까?
A: 기본 테이블이 게시의 아티클로 구성되어 있으면, 즉 기본 테이블을 복제되도록 구성한 경우에는 기본 테이블에 대한 모든 업데이트가 복제됩니다.
뷰를 복제할 때는 인덱싱된 뷰를 제외하고는 기본적으로 뷰의 스키마 부분만 또는 뷰의 코드만 뷰의 일부로 복제되고 뷰의 기본이 되는 데이터는 복제되지 않습니다. 그러므로 복제를 수행하지 않더라도 뷰를 업데이트하면, 즉 해당 뷰를 대상으로 사용하여 DML(데이터 조작 언어) 문을 실행하면 뷰가 아니라 기본 테이블의 데이터가 업데이트됩니다. 인덱싱된 뷰를 제외하고 모든 뷰는 쿼리 문의 논리적 저장소일 뿐이지 실제 저장소가 연결되어 있는 것은 아닙니다.

최대 서버 메모리
Q: RAM 크기가 5GB이고 Windows Server® 2003과 SQL Server 2000이 실행되는 컴퓨터가 있습니다. /3GB 스위치를 사용하여 사용자 모드 가상 주소 공간을 늘리고, /PAE 스위치를 사용하여 Windows 커널 PAE(Physical Address Extensions) 버전을 로드하고, AWE(Address Windowing Extensions)를 1로 설정하여 메모리의 페이지 잠금을 활성화하려고 합니다. AWE가 활성화된 경우에는 최대 서버 메모리 옵션으로 데이터 캐시 크기만 구성할 수 있습니까, 아니면 데이터, 프로세스, 세션 등의 전체 버퍼 캐시 크기를 구성할 수 있습니까? 데이터 캐시만 AWE로 매핑된 메모리를 사용할 수 있습니다. 그렇다면 최대 서버 메모리를 4GB로 구성할 경우 데이터 캐시가 AWE로 매핑된 1GB만 사용합니까, 아니면 이 추가 1GB를 사용하면서 다른 메모리 소비 항목과 함께 표준 주소 공간도 계속해서 사용할 수 있습니까?
A: 최대 서버 메모리는 항상 전체 버퍼 풀 크기를 제한합니다. 하지만 AWE로 매핑된 메모리를 사용할 수 있는 메모리 소비 항목은 데이터 캐시뿐입니다.
먼저 첫 번째 질문에 대한 답변입니다. AWE가 활성화되어 있더라도 최대 서버 메모리 옵션으로 전체 버퍼 풀 크기를 제한할 수 있습니다. 하지만 데이터 캐시 이외의 메모리 소비 항목은 AWE로 매핑된 메모리를 사용할 수 없습니다.
두 번째 질문에 대한 답입니다. 데이터 캐시는 AWE로 매핑된 메모리와 함께 SQL Server에서 적합성을 확인한 버퍼 풀의 다른 메모리를 사용합니다. 데이터 캐시가 사용하는 메모리는 AWE 메모리로만 제한되지 않으며 데이터 캐시는 AWE 메모리를 사용할 수 있는 유일한 메모리 소비 항목이기도 합니다. /3GB 스위치의 기능에 대해 자세히 알아보려면 Raymond Chen의 블로그를 참조하십시오.

프로파일링 및 성능
Q: 프로덕션 환경에서 SQL Server 2005를 미러링했습니다. 데이터베이스 컴퓨터에서 SQL Server 프로파일러를 시작하고 파일에 추적 데이터를 쓰기 시작하면 성능이 급격하게 저하됩니다. 왜일까요?
A: 성능이 저하되는 이유는 프로파일러를 어디에서 실행하는지에 따라 다릅니다. 서버 컴퓨터에서 대화형으로 프로파일러를 실행하면 프로파일러 UI가 서버의 메모리와 CPU를 모두 사용하게 되므로 성능에 영향을 줍니다.
워크스테이션에서 대화형으로 프로파일러를 실행하면 네트워크를 통해 이벤트 정보가 이동되어 처리량에 영향을 줍니다. 이 네트워크가 미러링에 사용되는 네트워크라면 미러링에도 성능 저하가 발생합니다. 또한 프로파일러 출력을 네트워크 공유에 저장하는 경우에도 네트워크를 통해 데이터가 이동되므로 성능에 좋지 않은 영향을 주게 됩니다.
성능에 미치는 이러한 영향을 완화할 수 있는 가장 좋은 방법은 프로파일링할 인스턴스가 실행되는 서버에서 프로파일러를 비대화형으로 실행한 다음 출력을 로컬 파일에 연결하는 것입니다. 이때도 서버 리소스는 사용되지만 대체적으로 성능에 미치는 영향은 가장 적습니다. 이 방법이 메모리 내 프로파일러 추적보다 훨씬 낫습니다. 파일 추적의 경우 버퍼 크기가 크고 버퍼가 더 효율적으로 디스크로 플러시되기 때문에 시스템 메모리를 보다 효과적으로 사용합니다. 또한 파일 추적은 SQL Server 프로파일러와 같은 외부 프로세스에 종속되지도 않습니다.
마지막으로 추적 데이터는 프로파일러가 프로파일링을 수행하는 동안 디스크 파일에 기록됩니다. 추적 파일은 공유되므로 다른 사용자가 원격으로 실시간 프로파일링 데이터를 볼 수 있습니다. 추적 파일을 대화형으로 호출할 경우 수동으로 프로파일러를 호출하고 화면에서 출력을 봅니다. 시각적 출력 없이 프로그래밍 방식으로 출력을 만들 수도 있는데 대개 프로그램을 비대화형으로 실행하는 경우는 이 때문입니다.
일반적으로 로컬 디렉터리의 최상위 수준에 공유를 만들어 다른 사용자가 이곳의 파일에 액세스하도록 하는 것이 적절한 방법입니다. 앞에서도 설명했듯이 원격 공유, 특히 미러링에 사용된 것과 동일한 네트워크 파이프를 통해 액세스되는 원격 공유의 파일로 추적 출력을 보내는 것은 바람직하지 않습니다.
또한 검토가 반드시 필요한 최소한의 이벤트 집합만 선택해야 합니다. 추적 파일의 위치로는 시스템에서 가장 빠른 드라이브를 선택해야 하며 SQL Server 데이터베이스 및 트랜잭션 로그 드라이브가 아니면 더욱 좋습니다. 이렇게 했는데도 성능 저하 문제가 해결되지 않으면 이벤트를 분할하여 서로 다른 하드 드라이브를 대상으로 하도록 지정합니다. 추적이 동일한 하드 드라이브를 대상으로 하더라도 추적마다 자체의 버퍼 집합을 사용하게 되므로 분할로 인한 장점을 누릴 수 있습니다. 자세한 내용은 SQL Server 온라인 설명서에서 sp_trace_create 및 모든 관련 명령문을 참조하십시오.

클러스터링 문제
Q: Windows Server 2003을 실행하는 클러스터에 SQL Server를 설치하려고 할 때마다 "클러스터 노드에 필요한 작업을 수행하지 못했습니다."라는 오류 메시지가 나타납니다. sqlstp.log에는 다음과 같은 내용만 제공됩니다.
Script file copied to '\\SERVER01\ADMIN$\SERVER01_MSSQLSERVER.iss' successfully.
Installing remote service (SERVER01)...
An error occured in the service create (SERVER01): 1069...
무엇이 문제일까요?
A: 이 오류가 발생한 데는 몇 가지 이유가 있을 수 있습니다. 설치 프로그램에서는 개별 컴퓨터의 설치 프로세스를 원격으로 관리하기 위해 선택된 모든 노드에 Windows NT® Service를 설치하는데, 이 과정에서 몇 가지 문제에 직면할 수 있습니다.
첫째, 도메인 계정 사용자에게 "서비스로 로그온" 권한을 거부하는 그룹 정책이 적용되어 있을 수 있습니다. 도메인 정책은 로컬 컴퓨터 정책보다 우선하므로 이와 같은 제한이 없는 계정을 사용해야 합니다.
둘째, 설치 프로그램을 실행 중인 컴퓨터에 로그온한 계정은 모든 노드에 대한 관리 권한을 가지고 있어야 하는데 그 이유는 다음과 같습니다. 마스터 설치 프로세스에서 모든 컴퓨터의 레지스트리에 원격으로 액세스해야 하거나, 설치 프로그램에서 원격 컴퓨터의 Windows 디렉터리에 cnvsvc.exe를 복사하거나, 설치 프로그램에서 로그온한 계정의 권한만 사용하여 원격 컴퓨터에 액세스하는 표준 Windows API를 사용합니다. 이러한 이유로 모든 노드에는 기본적으로 관리자로 로그온해야 합니다.

장애 복구 계획
Q: SAP 데이터베이스에 DR(장애 복구) 전략을 구현하기 위해 데이터베이스 미러링(비동기 모드)을 사용할지 또는 로그 전달을 사용할지 고려 중입니다. 프로덕션 사이트와 DR 사이트에는 100Mb의 광대역 연결이 지원될 예정이지만 미러링 세션 전용은 아니며, 다른 미러링 세션이나 DR 서버와도 연결을 공유하려고 합니다.
로그 레코드가 미러 데이터베이스로 전송되는 것을 방해하는 네트워크 문제가 있을 경우 다시 시도가 이루어집니까?
미러링 세션이 일시 중지될 때 보존 기간이 있습니까? 그리고 시스템 뷰 외에 미러링 트래픽과 로그 레코드 전송을 모니터링하는 데 사용할 수 있는 로깅 정보가 있습니까?
A: 먼저 데이터베이스 미러링의 다시 시도 논리에 관한 질문에 답을 드리겠습니다. 이 문제는 두 가지 방법으로 살펴볼 수 있습니다. 첫째, 일시적인 네트워크 문제가 있는 경우에는 미러링 세션의 상태가 연결이 끊긴 상태입니다. 기본적으로 네트워크 시간 초과 값은 10초인데 이는 주 데이터베이스에서 미러 데이터베이스로 로그 레코드를 보낼 수 없음을 의미합니다. 이러한 경우에는 주 데이터베이스가 계속해서 "노출된" 상태로 실행되므로 트랜잭션이 클라이언트 쪽에서 커밋됩니다. 네트워크 문제가 해결되면 사용자가 관여하지 않아도 미러링 세션이 자동으로 다시 시도됩니다. 먼저 로그 레코드를 사용하여 격차를 만회하고 파트너가 먼저 동기화되어 격차를 만회하면 상태가 동기화됩니다.
둘째, 다시 실행 문제가 있는 경우에는 미러링 세션의 상태가 일시 중지됩니다. 다시 실행 문제는 미러 데이터베이스가 자체 데이터베이스에서 로그 레코드를 커밋할 수 없음을 의미합니다. 다시 실행 문제는 대개 실제 파일을 찾을 수 없거나 디스크 공간이 부족하여 발생합니다. 이러한 경우에는 주 데이터베이스가 계속해서 노출된 상태로 실행되므로 트랜잭션이 클라이언트 쪽에서 커밋됩니다. 미러 서버에서 다시 실행 문제를 수동으로 수정한 후 미러 세션에 대해 다음과 같은 작업을 수행해야 합니다.
ALTER DATABASE <db> SET PARTNER RESUME;
보존 기간에 대해 답하자면, 미러 세션이 연결이 끊긴 상태인지 또는 일시 중지된 상태인지 여부에 관계없이 로그 레코드는 세션이 복원될 때까지 보존되며, 세션이 일시 중지되었을 때부터 다시 시작될 때까지의 모든 레코드는 미러 데이터베이스에서 확정됩니다. 기본적으로 미러링 세션이 연결이 끊기거나 일시 중지된 동안에는 주 데이터베이스의 로그를 자를 수 없습니다. 이를 자르게 되면 다시 실행 체인이 끊기기 때문입니다. 따라서 세션이 복원될 때까지 주 데이터베이스의 로그가 무한정 커집니다. 따라서 미러링 세션에서는 보존과 관련된 어떠한 제한도 없습니다. 로그를 자를 수는 없으므로 주 서버에서 로그를 저장하는 데 사용할 수 있는 디스크 공간이 제한될 뿐입니다.
마지막으로, 미러링을 모니터링하는 데 사용할 수 있는 별도의 로그 파일은 없습니다. SQL Server 2005에서는 이러한 목적으로 사용할 수 있는 데이터베이스 미러링 모니터라는 GUI 도구를 제공합니다. 시스템 관리자는 이 도구를 사용하여 상태를 보거나 업데이트하고 몇 가지 핵심 성능 메트릭에 대한 경고 임계값을 구성하여 미러링이 제대로 수행되지 않을 경우 경고 메시지를 받을 수 있습니다. 데이터베이스 미러링과 관련하여 고려하게 되는 주요 성능 문제는 로그 레코드가 적시에 처리되느냐의 여부입니다. 데이터베이스 미러링을 모니터링하는 방법에 대한 자세한 내용은 미러링 상태 모니터링(msdn2.microsoft.com/en-us/library/ms365781.aspx)을 참조하십시오.

기술적 자문을 주신 Microsoft IT 전문가: Chad Boyd, Sandu Chirica, Alan Doby, Kaloian Manassiev, Luciano Moreira, Ivan Penkov, Sivagaminathan Rajarethinam, Deborah To, Patrick Woodward, Buck Woody, Stanley Yau, Warren Young


 The Cable Guy: DHCPv6 프로토콜
The Cable Guy
DHCPv6 프로토콜
Joseph Davies

DHCP(동적 호스트 구성 프로토콜)는 IP 주소와 기타 네트워킹 정보를 컴퓨터에 할당하여 컴퓨터가 네트워크에서 자동으로 통신할 수 있도록 지원하기 위해 설계되었습니다. IPv6 네트워크에서는 DHCP를 사용하여 주소를 구성하지 않아도 되지만 DHCP를 사용하면 몇 가지 이점이 있습니다. DHCPv6(IPv6용 DHCP)에서는
상태 저장 주소 구성 또는 상태 비저장 구성 설정을 IPv6 호스트에 제공할 수 있습니다. IPv6 호스트에서는 여러 가지 방법으로 주소를 구성할 수 있습니다.
상태 비저장 주소 자동 구성 은 인접 라우터 간에 라우터 요청 및 라우터 알림 메시지를 교환하여 링크 로컬 주소와 추가 비링크 로컬 주소를 구성하는 데 사용됩니다.
상태 저장 주소 자동 구성 은 DHCP와 같은 구성 프로토콜을 사용하여 비링크 로컬 주소를 구성하는 데 사용됩니다.
IPv6 호스트는 상태 비저장 주소 자동 구성을 자동으로 수행하고 인접 라우터에서 보낸 라우터 알림 메시지의 다음 플래그에 따라 DHCPv6와 같은 구성 프로토콜을 사용합니다.
M 플래그라고도 하는 관리되는 주소 구성 플래그. 이 플래그를 1로 설정하면 호스트에서는 구성 프로토콜을 사용하여 상태 저장 주소를 가져옵니다.
O 플래그라고도 하는 기타 상태 저장 구성 플래그 . 이 플래그를 1로 설정하면 호스트에서는 구성 프로토콜을 사용하여 기타 구성 설정을 가져옵니다.
M 및 O 플래그의 값을 조합하여 다음과 같은 결과를 얻을 수 있습니다.
M 및 O 플래그가 모두 0으로 설정된 경우. 이 조합은 DHCPv6 인프라가 없는 네트워크에 해당합니다. 호스트에서는 비링크 로컬 주소에 대한 라우터 알림 및 다른 방법(예: 수동 구성)을 사용하여 기타 설정을 구성합니다.
M 및 O 플래그가 모두 1로 설정된 경우. DHCPv6를 사용하여 주소 및 기타 구성을 설정합니다. 이 조합에서는 DHCPv6가 IPv6 호스트에 상태 저장 주소를 할당하기 때문에 DHCPv6 상태 저장이라고도 합니다.
M 플래그는 0으로 설정되고 O 플래그는 1로 설정된 경우. DHCPv6가 주소 할당에는 사용되지 않고 기타 구성 설정을 할당하는 데만 사용됩니다. 인접 라우터는 IPv6 호스트에서 상태 저장 주소를 파생하는 데 사용되는 비링크 로컬 주소 접두사를 알리도록 구성됩니다. 이 조합에서는 DHCPv6가 IPv6 호스트에 상태 저장 주소를 할당하지 않고 상태 비저장 구성 설정을 수행하므로 DHCPv6 상태 비저장이라고도 합니다.
M 플래그는 1로 설정되고 O 플래그는 0으로 설정된 경우. 이 조합에서는 DHCPv6가 주소 구성에 사용되고 기타 설정에는 사용되지 않습니다. 일반적으로 IPv6 호스트에서는 DNS(Domain Name System) 서버의 IPv6 주소와 같은 기타 설정을 구성해야 하므로 이 조합은 자주 사용되지 않습니다.
IPv4용 DHCP와 마찬가지로 DHCPv6 인프라의 구성 요소는 구성을 요청하는 DHCPv6 클라이언트, 구성을 제공하는 DHCPv6 서버 및 DHCPv6 서버가 없는 서브넷에 클라이언트가 있을 때 클라이언트와 서버 사이에서 메시지를 전달해 주는 DHCPv6 릴레이 에이전트로 구성됩니다.

DHCPv6 메시지
IPv4용 DHCP와 마찬가지로 DHCPv6에서도 UDP(User Datagram Protocol) 메시지를 사용합니다. DHCPv6 클라이언트는 UDP 포트 546을 통해 DHCP 메시지를 수신합니다. DHCPv6 서버 및 릴레이 에이전트는 UDP 포트 547을 통해 DHCPv6 메시지를 수신합니다. DHCPv6 메시지의 구조는 디스크 없는 워크스테이션을 지원하는 BOOTP 프로토콜을 기반으로 만들어졌기 때문에 IPv4용 DHCP보다 훨씬 간단합니다. 그림 1은 클라이언트와 서버 간에 전송되는 DHCPv6 메시지의 구조를 보여 줍니다.
Figure 1 DHCPv6 messages between client and server
Figure 1 DHCPv6 messages between client and server (더 작게 보려면 이미지를 클릭하십시오.)
Figure 1 DHCPv6 messages between client and server
Figure 1 DHCPv6 messages between client and server (더 크게 보려면 이미지를 클릭하십시오.)
1바이트 Msg-Type 필드는 DHCPv6 메시지의 형식을 나타냅니다. 3바이트 Transaction-ID 필드는 클라이언트에 의해 결정되며 DHCPv6 메시지 교환 메시지를 그룹화하는 데 사용됩니다. Transaction-ID 필드 다음에 있는 DHCPv6 옵션은 클라이언트 및 서버 ID, 주소 및 기타 구성 설정을 나타내는 데 사용됩니다. 정의된 DHCPv6 옵션 목록은 "DHCPv6 RFC 리소스" 추가 기사에 나와 있는 RFC 3315를 참조하십시오.
DHCPv6 옵션의 형식은 TLV(형식, 길이, 값) 형식으로 지정됩니다. 그림 2는 DHCPv6 옵션의 구조를 보여 줍니다.
2바이트 Option-Code 필드는 특정 옵션을 나타냅니다. 2바이트 Option-Len 필드는 Option-Data 필드의 길이를 바이트 단위로 나타냅니다. Option-Data 필드에는 옵션에 대한 데이터가 포함됩니다.
릴레이 에이전트 간에 교환된 메시지의 경우 추가 정보를 기록하기 위해 별도의 메시지 구조를 사용합니다. 그림 3은 이러한 메시지 유형의 구조를 보여 줍니다.
Figure 2 Structure of DHCPv6 options
Figure 2 Structure of DHCPv6 options (더 작게 보려면 이미지를 클릭하십시오.)
Figure 2 Structure of DHCPv6 options
Figure 2 Structure of DHCPv6 options (더 크게 보려면 이미지를 클릭하십시오.)
1바이트 홉 수 필드는 메시지를 수신한 릴레이 에이전트의 수를 나타냅니다. 수신한 릴레이 에이전트는 이 필드의 값이 구성된 최대 홉 수를 초과하는 경우 메시지를 버릴 수 있습니다. 16바이트 링크 주소 필드에는 클라이언트가 있는 서브넷에 연결된 인터페이스에 할당된 비링크 로컬 주소가 들어 있습니다. 링크 주소 필드를 통해 서버는 주소를 할당할 올바른 주소 범위를 결정할 수 있습니다. 16바이트 피어 주소 필드에는 처음에 메시지를 보낸 클라이언트 또는 메시지를 릴레이한 이전 릴레이 에이전트의 IPv6 주소가 들어 있습니다. 피어 주소 필드 다음에는 릴레이되고 있는 메시지 및 기타 옵션이 포함된 릴레이 메시지 옵션을 비롯한 DHCPv6 옵션이 있습니다. 릴레이 메시지 옵션은 클라이언트와 서버 사이에서 교환되는 메시지에 대한 캡슐화 기능을 제공합니다.
IPv6에는 정의된 브로드캐스트 주소가 없습니다. 따라서 일부 DHCPv4 메시지에서 제한된 브로드캐스트 주소를 사용했었지만 DHCPv6에서는 FF02::1:2라는 All_DHCP_Relay_Agents_and_Servers 주소를 사용합니다. 예를 들어, 네트워크에 있는 DHCPv6 서버의 위치를 찾으려는 DHCPv6 클라이언트가 해당 링크 로컬 주소부터 FF02::1:2까지 간청 메시지를 보냅니다. 호스트의 서브넷에 DHCPv6 서버가 있으면 해당 서버에서 간청 메시지를 수신한 후 적합한 응답을 보냅니다. 일반적으로는 호스트의 서브넷에 있는 DHCPv6 릴레이 에이전트에서 간청 메시지를 수신한 후 DHCPv6 서버에 전달합니다.
Figure 3 Structure of messages between relay and server
Figure 3 Structure of messages between relay and server (더 작게 보려면 이미지를 클릭하십시오.)
Figure 3 Structure of messages between relay and server
Figure 3 Structure of messages between relay and server (더 크게 보려면 이미지를 클릭하십시오.)

상태 저장 메시지 교환
수신된 라우터 알림의 M 및 O 플래그가 1로 설정되어 있는 경우 IPv6 주소 및 구성 설정을 가져오는 DHCPv6 상태 저장 메시지 교환은 일반적으로 다음과 같은 메시지로 구성됩니다.
  • 서버를 찾기 위해 클라이언트에서 보낸 간청 메시지
  • 주소와 구성 설정을 보낼 수 있음을 알리기 위해 서버에서 보낸 알림 메시지
  • 특정 서버의 주소와 구성 설정을 요청하기 위해 클라이언트에서 보낸 요청 메시지
  • 요청을 받은 서버에서 주소와 구성 설정을 담아 보낸 응답 메시지
클라이언트와 서버 사이에 릴레이 에이전트가 있는 경우 릴레이 에이전트는 클라이언트의 캡슐화된 간청 및 요청 메시지가 포함된 릴레이 전달 메시지를 서버에 보냅니다. 서버는 클라이언트에 대한 캡슐화된 알림 및 응답 메시지가 포함된 릴레이 응답 메시지를 릴레이 에이전트에 보냅니다. 전체 DHCPv6 메시지 목록은 그림 4를 참조하십시오.
Figure 4 DHCPv6 메시지 (Close Figure 4)

DHCPv6 메시지 | 설명 | 해당하는 IPv4용 DHCP 메시지
간청 | 서버를 찾기 위해 클라이언트에서 보내는 메시지 | DHCPDiscover
알림 | 간청 메시지에 대한 응답으로 가용성을 알리기 위해 서버에서 보내는 메시지 | DHCPOffer
요청 | 특정 서버의 주소나 구성 설정을 요청하기 위해 클라이언트에서 보내는 메시지 | DHCPRequest
확인 | 클라이언트의 구성이 연결된 링크에 유효한지 확인하기 위해 클라이언트에서 모든 서버에 보내는 메시지 | DHCPRequest
갱신 | 할당된 주소의 유효 기간을 연장하고 업데이트된 구성 설정을 가져오기 위해 클라이언트에서 특정 서버에 보내는 메시지 | DHCPRequest
다시 바인딩 | 갱신 메시지에 대한 응답을 받지 못했을 때 클라이언트에서 임의의 서버에 보내는 메시지 | DHCPRequest
응답 | 간청, 요청, 갱신, 다시 바인딩, 정보 요청, 확인, 해제 또는 거부 메시지에 대한 응답으로 서버에서 특정 클라이언트에 보내는 메시지 | DHCPAck
해제 | 할당된 주소를 더 이상 사용하지 않고 있음을 알리기 위해 클라이언트에서 보내는 메시지 | DHCPRelease
거부 | 할당된 주소가 이미 사용되고 있음을 알리기 위해 클라이언트에서 특정 서버에 보내는 메시지 | DHCPDecline
다시 구성 | 서버에 업데이트되거나 새로운 구성 설정이 있음을 알리기 위해 서버에서 클라이언트에 보내는 메시지. 이 메시지를 받은 클라이언트는 갱신 또는 정보 요청 메시지를 보냅니다. | 해당 사항 없음
정보 요청 | 구성 설정(주소 제외)을 요청하기 위해 클라이언트에서 보내는 메시지 | DHCPInform
릴레이 전달 | 메시지를 서버에 전달하기 위해 릴레이 에이전트에서 보내는 메시지. 릴레이 전달 메시지에는 DHCPv6 릴레이 메시지 옵션과 마찬가지로 캡슐화된 클라이언트 메시지가 있습니다. | 해당 사항 없음
릴레이 응답 | 릴레이 에이전트를 통해 클라이언트에게 메시지를 보내려는 서버에서 보내는 메시지. 릴레이 응답 메시지에는 DHCPv6 릴레이 메시지 옵션과 마찬가지로 캡슐화된 서버 메시지가 있습니다. | 해당 사항 없음

상태 비저장 메시지 교환
수신된 라우터 알림의 M 플래그가 0으로 설정되어 있고 O 플래그가 1로 설정되어 있는 경우 구성 설정만을 가져오는 DHCPv6 상태 비저장 메시지 교환은 일반적으로 서버의 구성 설정을 요청하기 위해 DHCPv6 클라이언트에서 보낸 정보 요청 메시지와 서버에서 요청된 구성 설정을 담아 보낸 응답 메시지로 구성됩니다.
라우터가 상태 비저장 주소 접두사를 IPv6 호스트에 할당하도록 구성되어 있는 IPv6 네트워크의 경우 두 가지 메시지로 이루어지는 DHCPv6 교환을 사용하여 DNS 서버, DNS 도메인 이름 및 라우터 알림 메시지에 없는 기타 구성 설정을 할당할 수 있습니다.

Windows에서 DHCPv6 지원
Windows Vista™와 Windows Server®의 다음 버전(코드명 "Longhorn")에는 DHCPv6 클라이언트가 포함되어 있습니다. DHCPv6 클라이언트는 수신된 라우터 알림 메시지의 M 및 O 플래그의 값에 따라 DHCPv6 기반 구성을 설정합니다. 따라서 DHCPv6를 사용하려면 각 IPv6 서브넷을 지원하도록 DHCPv6 서버와 릴레이 에이전트를 구성한 후 IPv6 라우터를 구성하여 이러한 두 플래그를 적합한 값으로 설정해야 합니다. 특정 서브넷에 대한 알림 라우터가 여러 개인 경우 동일한 상태 비저장 주소 접두사와 M 및 O 플래그 값을 알리도록 해당 라우터를 구성해야 합니다. Windows® XP 또는 Windows Server 2003을 실행하는 IPv6 호스트에는 DHCPv6 클라이언트가 없기 때문에 수신된 라우터 알림에 있는 M 및 O 플래그의 값은 무시됩니다.
Windows Vista 또는 Windows Server "Longhorn"을 실행하고 있는 IPv6 라우터에서 "netsh interface ipv6 set interface InterfaceName managedaddress=enabled" 명령을 사용하여 라우터 알림의 M 플래그를 1로 설정하도록 구성할 수 있습니다. 이와 비슷하게 "netsh interface ipv6 set interface InterfaceName otherstateful=enabled" 명령을 사용하여 라우터 알림의 O 플래그를 1로 설정할 수 있습니다.
Windows Server "Longhorn" 베타 2는 DHCP 서버 서비스를 통해 DHCPv6 릴레이 에이전트와 DHCPv6 상태 비저장 구성을 지원합니다. DHCPv6 옵션이 앞에서 설명한 두 가지 메시지로 이루어지는 DHCPv6 메시지 교환을 통해 모든 DHCPv6 클라이언트에 배포되도록 DHCP 서버 서비스를 구성할 수 있습니다. Microsoft에서는 DHCP 스냅인에서 IPv6 주소 범위를 만드는 기능을 포함한 DHCPv6 상태 저장 작업에 대한 지원을 Windows Server "Longhorn" 베타 3 릴리스에 포함할 계획입니다.
DHCPv6 RFC 리소스
엄선된 DHCPv6 관련 RFC:
  • RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
  • RFC 2462 IPv6 Stateless Address Autoconfiguration
  • RFC 3633 IPv6 Prefix Options for DHCP version 6
  • RFC 3646 DNS Configuration Options for DHCPv6
  • RFC 3736 Stateless DHCP Service for IPv6

Joseph Davies는 Microsoft의 기술 전문 저술가로 1992년부터 Windows 네트워킹을 주제로 글을 쓰고 가르치는 일을 하고 있습니다. Microsoft Press에서 5권의 책을 저술한 그는 월간 온라인 TechNet Cable Guy 칼럼의 저자이기도 합니다.


 Windows Powershell: 변수의 강력한 기능
Windows Powershell
변수의 강력한 기능
Don Jones

VBScript나 KiXtart와 같은 Windows 기반 스크립트로 작업을 수행하는 사용자라면 변수는 일종의 데이터 저장 메커니즘에 불과하다고 생각해왔을 것입니다. Windows PowerShell에도 변수가 포함되어 있지만 이는 다른 스크립트 언어의 변수보다 훨씬 강력한 기능을 갖고 있습니다. Windows
PowerShell 변수는 실제로 Microsoft® .NET Framework의 기본 클래스로 매핑됩니다. 그리고 Framework에서 변수는 개체이기 때문에 데이터를 저장할 수 있고 여러 방법으로 조작할 수도 있습니다. Windows PowerShell™ 스크립트 언어에 내부 데이터 조작 함수가 포함되어 있지 않은 이유는 Windows PowerShell의 변수의 기능이 강력하기 때문입니다. 변수 자체에서 이미 기능이 제공되기 때문에 이러한 함수가 필요 없습니다.

변수 선언
Windows PowerShell의 New-Variable cmdlet를 사용하여 변수를 선언하고 초기 값을 할당할 수 있지만 반드시 cmdlet를 사용할 필요는 없습니다. 대신 다음과 같이 값을 할당하기만 하면 새 변수가 생성됩니다.
$var = "Hello"

Windows PowerShell에서 변수 이름은 항상 달러 기호($)로 시작되며 문자, 숫자, 기호 또는 공백을 혼합하여 사용할 수 있습니다. 공백을 사용할 때는 ${My Variable} = "Hello"처럼 변수를 중괄호 안에 넣어야 합니다. 이 예는 이름이 $var인 새 변수를 만들고 "Hello"라는 초기 값을 할당합니다. 이 경우 값이 문자열이기 때문에 Windows PowerShell에서는 문자열 데이터 형식을 사용하여 값을 저장합니다. .NET Framework 용어로 설명하자면 이것은 모든 변수 형식의 기본 제공 기능을 대부분 갖고 있는 System.String 클래스입니다. 예를 들어 $var에 있는 값을 모두 소문자로 보고 싶다면 다음과 같이 할 수 있습니다.
PS C:\> $var.ToLower()
hello
PS C:\>
ToLower 메서드는 System.String 클래스에 포함되어 있으며 문자열 값을 모두 소문자로 표시하지만, 변수 $var의 실제 내용을 변경하지는 않습니다. System.String 클래스가 수행할 수 있는 모든 기능에 대한 목록을 보려면 다음과 같이 문자열 변수를 Get-Member cmdlet로 보냅니다.
$var | get-member
그림 1이 그 결과이며 여기에는 문자열 조작에 사용되는 여러 메서드가 포함되어 있습니다. VBScript 문자열 조작 함수에서 제공되는 거의 모든 기능은 Windows PowerShell의 문자열 변수의 메서드를 통해 제공됩니다.
Figure 1 A look at the System.String class output
Figure 1 A look at the System.String class output (더 작게 보려면 이미지를 클릭하십시오.)
Figure 1 A look at the System.String class output
Figure 1 A look at the System.String class output (더 크게 보려면 이미지를 클릭하십시오.)

관리 측면에서 볼 때 VBScript와 같은 언어의 문자열 함수보다는 여러 문자열 변수의 기능이 더 유용합니다. 파일에서 UNC(Universal Naming Convention) 경로를 읽은 후 이 경로에 대해 어떤 작업을 수행하는 스크립트를 작성했다고 가정해 보겠습니다. 경로를 사용하기에 앞서, 읽은 각 경로가 UNC인지 확인하려면 StartsWith 메서드를 사용합니다. 이 메서드를 사용하면 문자열의 값이 UNC에 필요한 백슬래시 문자로 시작되는지 확인할 수 있습니다.
PS C:\> $path = "\\Server\Share"
PS C:\> $path.StartsWith("\\")
True
PS C:\>
StartsWith는 True 또는 False 값을 반환하기 때문에 다음과 같은 논리 구문에 사용할 수 있습니다.
if ($path.StartsWith("\\")) {
 # code goes here
}
Windows PowerShell에서는 변수 메서드에 대한 일종의 자동 완성 기능을 제공하므로 입력해야 할 문자 수를 줄일 수 있습니다. $var에 문자열이 포함된 경우 다음과 같이 입력하고
$var.
Tab 키를 누르면 $var 변수에 대한 첫 번째 메서드 이름이 표시됩니다. Tab 키를 한 번 더 누르면 다음 메서드로 이동하고 Shift+Tab을 누르면 이전 메서드로 돌아갑니다. 이러한 방법을 통해 사용할 수 있는 모든 메서드를 순환하여 원하는 메서드를 찾을 수 있습니다.

변수 혼동
지금까지의 예에서는 Windows PowerShell로 변수의 데이터 형식을 결정할 수 있었습니다. 변수에 문자열을 할당하는 것은 근본적으로 해당 변수를 System.String 클래스의 변수로 만드는 것과 같습니다. 반면, 변수에 숫자를 할당하면 일반적으로 변수는 정수가 됩니다. 더 구체적으로 말하자면 특정한 값의 범위를 저장할 수 있는 Int32가 되는 것입니다. 다음 예를 살펴보겠습니다.
PS C:\> $int = 5
PS C:\> $int | get-member

  TypeName: System.Int32
이 잘려진 출력을 보면 Windows PowerShell에서 $int를 자체적인 메서드 및 속성 집합이 있는 Int32로 처리한다는 것을 알 수 있습니다. 그리고 이 메서드 및 속성 집합은 문자열 형식의 집합보다 훨씬 적습니다.
$int는 값이 따옴표로 묶여 있지 않고 숫자로만 구성되어 있기 때문에 Int32가 되었습니다. 따옴표로 묶여 있었으면 System.String으로 해석되었을 것입니다.
사용할 데이터 형식을 Windows PowerShell에서 결정할 수 있도록 허용할 경우 항상 원하는 결과가 나오는 것은 아닙니다. 예를 들어 파일에서 값을 읽을 때 값이 항상 문자열로 처리되기를 바랄 수 있습니다. 그러나 일부 값에는 숫자만 포함되어 있을 수 있으며 Windows PowerShell에서는 이러한 값을 Int32 또는 다른 숫자 형식으로 처리할 가능성이 생깁니다. 이 경우 스크립트에 문제가 발생할 수 있습니다. Windows PowerShell에서 값을 문자열로 인식하지 않으면 System.String 클래스의 모든 메서드를 사용하지 못하게 되며, 스크립트에서 이런 메서드 중 하나를 사용해야 하는 경우에 문제가 발생합니다.
이 문제를 해결하려면 변수를 처음 사용할 때 형식을 선언하여 Windows PowerShell에서 해당 변수를 특정 형식으로 처리하도록 지정할 수 있습니다. 예를 들면 다음과 같습니다.
[string]$var = 5
일반적으로 $var는 Int32지만 여기서는 System.String 클래스와 연관된 모든 메서드를 사용할 수 있도록 하기 위해 Windows PowerShell에서 $var를 문자열로 처리하도록 했습니다. 또한 변수 형식 선언은 코드에 일종의 설명을 붙이는 역할도 하므로 이 코드를 보면 $var에 들어갈 데이터 형식이 무엇인지 확실하게 알 수 있습니다. 필자는 항상 습관적으로 모든 변수에 구체적 형식을 지정하여 Windows PowerShell 대신 필자 스스로 형식을 결정합니다. 이렇게 하면 스크립트의 동작을 더욱 잘 예측할 수 있으며 경우에 따라 디버깅 시간이 상당히 단축될 수도 있습니다.
물론 변수 강제 선언으로 인해 영향을 받는 부분도 있지만 이런 영향이 꼭 나쁜 것만은 아닙니다. 변수의 형식을 선언하지 않는 다음 예를 살펴보겠습니다.
PS C:\> $me = 5
PS C:\> $me = "Don"
$me 변수는 처음에는 Int32였지만 값 "Don"이 추가되자 Windows PowerShell에서 이를 문자열로 변경했습니다. Windows PowerShell에서는 명시적으로 변수를 특정 형식으로 설정한 경우가 아니면 필요에 따라 변수의 형식을 변경할 수 있습니다.
이 예에서는 [int] 형식 이름을 사용하여 $me를 Int32로 지정했습니다.
PS C:\> [int]$me = 5
PS C:\> $me = "Don"
Cannot convert value "Don" to type
"System.Int32". Error: "Input string
was not in a correct format."
At line:1 char:4
+ $me <<<< = "Don"
그런 다음 여기에 문자열 값을 할당하려고 하자 오류 메시지가 표시됩니다. $me를 Int32로 명시적으로 지정했기 때문에 Windows PowerShell에서는 문자열 "Don"을 정수 값으로 변환해야 합니다. 하지만 이렇게 변환하는 것이 불가능할 뿐 아니라 $me의 형식을 문자열로 변경할 수도 없기 때문에 오류 메시지가 표시된 것입니다.

다양한 형식
Windows PowerShell 내에서 사용할 수 있는 형식은 아주 다양합니다. 사실 모든 .NET Framework 형식을 사용할 수 있으며 사용 가능한 형식의 수는 수백 개에 달하지만 Windows PowerShell에는 자주 사용하는 몇 가지 데이터 형식이 바로 가기로 정의되어 있습니다. 그림 2는 그 중 일부 목록으로, 가장 많이 사용되는 10가지 형식의 바로 가기를 나타낸 것입니다. 전체 목록을 보려면 Windows PowerShell 설명서를 참조하십시오.
Figure 2 자주 사용하는 형식 바로 가기 (Close Figure 2)

바로 가기 | 데이터 형식
[datetime] | 날짜 또는 시간
[string] | 문자열
[char] | 단일 문자
[double] | 배정밀도 부동 소수점 수
[single] | 단정밀도 부동 소수점 수
[int] | 32비트 정수
[wmi] | WMI(Windows Management Instrumentation) 인스턴스 또는 컬렉션
[adsi] | Active Directory Services 개체
[wmiclass] | WMI 클래스
[Boolean] | True 또는 False 값
다음과 같이 전체 .NET Framework 클래스 이름을 사용하여 변수의 형식을 선언할 수도 있습니다.
[System.Int32]$int = 5
이 방법을 사용하면 .NET Framework에 있기는 하지만 Windows PowerShell에 특정한 바로 가기가 없는 형식을 사용할 수 있습니다.

형식 확장
Windows PowerShell의 가장 강력한 기능 중 하나는 이러한 변수 형식의 기능을 확장할 수 있다는 것입니다. Windows PowerShell 설치 폴더(일반적으로 %systemroot\system32\windowspowershell\v1.0에 있지만 64비트 시스템에서는 경로가 조금 다름)에는 types.ps1xml이라는 파일이 있습니다. 이 파일은 메모장 또는 PrimalScript와 같은 XML 편집기에서 편집할 수 있습니다. 기본적으로 다른 많은 형식들은 나열되어 있지만 System.String 클래스는 나열되어 있지 않습니다. 그러나 types.ps1xml 파일에 Sytem.String 형식을 추가함으로써 System.String 형식에 새 기능을 추가할 수 있습니다.
변경한 뒤에는 Windows PowerShell을 닫았다 다시 열어야 합니다. 또한 types.ps1xml에 서명하지 않았으므로 로컬 스크립트 실행 정책에서 서명되지 않은 스크립트 실행을 허용하도록 해야 합니다.
Set-executionpolicy remotesigned
이제 Windows PowerShell을 다시 시작하면 다음과 같이 새 기능을 사용할 수 있습니다.
PS C:\> [string]$comp = "localhost"
PS C:\> $comp.canping
True
PS C:\>
여기서 볼 수 있듯이 System.String 클래스에 CanPing 속성이 추가되었습니다. 이 속성은 로컬 컴퓨터가 문자열에 포함되어 있는 주소로 ping을 실행할 수 있는지 여부를 나타내는 True 또는 False를 반환합니다. 그림 3에서는 WMI 쿼리가 특수 변수인 $this를 사용하는 것을 볼 수 있습니다. $this 변수는 문자열에 포함되어 있는 현재 값을 나타내며 문자열 변수의 내용이 WMI 쿼리로 전달되는 방식입니다.
Figure 3 System.String 형식 확장 (Close Figure 3)
<Type>
  <Name>System.String</Name>
  <Members>
    <ScriptProperty>
      <Name>CanPing</Name>
      <GetScriptBlock>
      $wmi = get-wmiobject -query "SELECT *
FROM Win32_PingStatus WHERE Address = '$this'"
      if ($wmi.StatusCode -eq 0) {
        $true
      } else {
        $false
      }
      </GetScriptBlock>
    </ScriptProperty>
  </Members>
</Type>

변수의 활용
Windows PowerShell은 유연하고 풍부한 기능의 변수 형식을 제공하며 형식의 기능을 확장할 수 있는 유연한 시스템입니다. 이러한 기능 덕분에 스크립트에서 강력한 기능을 매우 쉽게 구현할 수 있습니다. 사실 변수는 복잡한 스크립트의 중요한 기초 요소가 될 수 있으며, 보다 복잡한 함수에서 볼 수 있는 고급 기능을 제공합니다.
온라인에서 자세한 내용 보기
매월 둘째 주 화요일에 열리는 이 웹캐스트에 참가하십시오. 웹캐스트에서는 Windows PowerShell에서 제공하는 다양한 스크립트 기능을 지속적으로 살펴봅니다. microsoft.com/events/series/donjonesscripting.mspx를 방문하여 지금 등록하십시오.

2007년 2월 20일 Windows PowerShell: The Scripting Crash Course
이 웹캐스트에 참가하면 Windows PowerShell의 변수, 언어 구문, 스크립트 및 함수에 대해 배울 수 있습니다. 1시간 동안 진행되는 이 특강에서는 Windows PowerShell의 간단하고도 효과적인 언어를 통해 Windows® 관리 자동화 작업을 보다 빠르게 수행할 수 있는 방법을 소개합니다. 또한 Windows PowerShell 스크립트를 간편하게 활용할 수 있도록 해 주는 타사의 몇 가지 도구도 살펴봅니다.

2007년 3월 20일 Windows PowerShell: Functions, Filters, and Efficiency
Windows PowerShell 함수와 필터를 사용하여 효과적이고 모듈화된 코드를 만드는 방법을 배웁니다. 함수와 필터를 완전하게 캡슐화할 수 있는 Windows PowerShell의 강력한 범위 지정 규칙을 살펴보고 프로젝트 전체에 이러한 함수와 필터를 손쉽게 재사용할 수 있는 방법을 살펴봅니다. 또한 Windows PowerShell의 전역 범위에 사용자 고유의 사용자 지정 함수를 추가하여 유용한 유틸리티 함수 라이브러리를 손쉽게 조합하는 방법도 소개합니다.

2007년 4월 17일 Windows PowerShell and Windows Management Instrumentation
Windows PowerShell에서는 WMI(Windows Management Instrumentation)의 모든 성능과 기능에 액세스할 수 있습니다. 이 웹캐스트에서는 Windows PowerShell을 사용하여 WMI에 액세스하는 방법뿐 아니라 Windows PowerShell 파이프라인을 통해 WMI 개체와 컬렉션을 전달하는 방법도 설명합니다. 또한 Windows PowerShell 스크립트에서 WMI 속성과 메서드를 활용하는 방법을 소개하고 WMI의 기본 보안 및 구성 기능을 설명합니다.

2007년 5월 22일 Windows PowerShell: Converting from VBScript
스크립트는 물론 더 나아가 현재 가지고 있는 기술을 VBScript에서 Windows PowerShell로 변환하고 싶으십니까? 이 웹캐스트에서 그 방법을 살펴보십시오. 본 웹캐스트에서는 VBScript의 모든 주요 구문과 기능을 Windows PowerShell에 포함시켜 VBScript 기술을 새로운 관리 환경으로 손쉽게 전환하는 방법을 소개하고, VBScript의 도구를 Windows PowerShell의 기본 스크립트 언어로 변환하는 방법을 설명합니다. 또한 Windows PowerShell의 고유 구조를 살펴보고, 보다 효과적이고 효율적인 작업을 위해 Windows PowerShell 스크립트 언어를 어떻게 사용해야 하는지 알아봅니다.

2007년 6월 19일 Windows PowerShell: Under-the-Hood Extensions
이 웹캐스트에서는 Windows PowerShell에서 .NET Framework의 강력하고 유연한 기능(문자열, 날짜 및 기타 데이터 형식을 관리할 수 있는 수백 개의 기본 제공 함수)을 사용하여 데이터를 처리하는 방법을 소개합니다. Windows PowerShell 스크립트를 사용하여 이러한 기능을 확장할 수 있다는 것을 알고 계셨습니까? 또한 컴퓨터 이름을 포함할 뿐만 아니라 컴퓨터의 실행 여부를 알려 줄 수 있는 문자열 변수를 만드는 방법에 대해서도 소개합니다. 외부 함수를 사용하지 않고도 자동으로 데이터의 서식을 지정할 수 있는 날짜 및 시간 변수를 만드는 방법에 대해서도 알아봅니다. 이 세션에 참가하면 모든 종류의 새로운 기능을 단 몇 분 이내에 Windows PowerShell에 구축하는 방법과 Windows 관리 작업을 보다 쉽고 빠르게 수행하는 방법을 확인할 수 있습니다.

Don Jones는 SAPIEN Technologies의 프로젝트 및 서비스 담당 이사이자 Windows PowerShell: TFM(SAPIEN Press)의 공동 저자입니다. 문의 사항이 있으시면 www.ScriptingAnswers.com으로 연락하십시오.


 Hey, Scripting Guy!: Scripting Guys의 OU에 대한 고찰 - 5센트를 위하여!
Hey, Scripting Guy!
Scripting Guys의 OU에 대한 고찰 - 5센트를 위하여!
Microsoft Scripting Guys
이 기사의 코드 다운로드: HeyScriptingGuy2007_03.exe (151KB)

Q: Active Directory에서 OU를 선택할 수 있도록 하는 대화 상자를 표시하려면 어떻게 해야 합니까?

여러분에게 문의를 받을 때마다 Scripting Guys가 5센트씩 받았다면... 흠, 뭐 그래도 37.15달러밖에 안 되겠군요. 하지만 질문을 하려고 마음먹었다가 실행에 옮기지 않은 모든 사람에게서 5센트씩 받았다면 얘기가 달라지겠죠? 뭐, 그래도 우리가 돈을 목적으로 Scripting Guys가 된 것은 아니니까요. 우리는 사람들이 시스템 관리 작업을 쉽고 빠르게 수행할 수 있도록 돕는 데서 오는 만족감을 느끼고자 Scripting Guys가 된 것입니다.
참고: 사실 어쨌든 처음에는 돈을 벌기 위해 Scripting Guys가 되었어요. 그렇지만 우리의 직속 상관으로부터 "잘만하면 큰 돈을 벌 수도 있지만, 그러려면 중노동을 각오하고 정말로 높은 품질의 결과물을 만들어 내야 해"라는 이야기를 들은 다음부터 우리 Scripting Guys는 돈이 전부가 아니라는 생각을 하게 되었습니다.
어쨌든 중요한 사실은, 많은 사용자들이 OU를 선택할 수 있는 대화 상자를 표시한 다음 스크립트를 사용하여 해당 OU에 연결할 수 있는 방법을 알고자 한다는 것입니다. 최근 한 독자로부터 "폴더를 선택할 수 있는 대화 상자 표시 방법에 대한 기사를 봤습니다. 또한 파일을 선택하는 대화 상자 표시 방법을 설명한 기사도 봤습니다. 그런데 왜 Active Directory®에서 OU를 선택할 수 있는 대화 상자 표시 방법에 대해서는 다루지 않는 겁니까?"라는 내용의 문의 메일을 받았습니다.
맞습니다. 폴더를 선택할 수 있는 대화 상자 표시 방법부터 연재를 시작했으며, 여기에서 예를 보실 수 있습니다. 또한 파일을 선택할 수 있는 대화 상자를 표시하는 방법도 설명되어 있습니다. 아직 해당 기사를 보지 못했다면 microsoft.com/technet/scriptcenter/resources/qanda/jan05/hey0128.mspx에서 확인하시기 바랍니다. 두 기사 모두 많은 독자들이 참조했으며 기사에서 제시된 방법을 스크립트에 적용한 사용자도 많습니다. 그렇다면 우리가 Active Directory에서 OU를 선택하는 대화 상자 표시 방법에 대해서 다루지 않은 이유는 무엇일까요? Microsoft가 꾸민 모종의 음모일까요?
물론 아닙니다. (잠깐. 혹시 필자가 Microsoft에 몸담고 있기 때문에 진실을 은폐하려 한다고 생각하는 사람은 없겠죠?) 사실 Active Directory에서 OU를 선택하는 대화 상자 표시 방법에 대해 다루지 않은 데는 그만한 이유가 있습니다. 바로 그런 대화 상자는 없기 때문입니다. 야구로 치자면 보이지 않는 공을 칠 수는 없는 노릇이니까요. 그리고 스크립팅으로 말하자면 존재하지 않는 것을 표시할 수는 없습니다.
자, 이번 호에서는 더 이상 설명할 내용이 없는 것 같군요. 그럼 다음 호에서 뵙겠습니다.
허나 제게 그런 행운이 있을 리 없죠! TechNet Magazine 편집자에 따르면 이번 달 칼럼에서는 다른 내용을 다룬다고 합니다. "그런 대화 상자가 없다고 그냥 끝낼 수는 없지 않느냐? Scripting Guys라면 해당 기능을 제공하는 대화 상자를 새로 만들어 내야 하지 않겠나? 스크립팅에 관해서는 못하는 게 없는 사람들 아니냐?"고 말하면서 말이지요.
당연한 얘기지만 TechNet Magazine 편집자들이 우리에 대해 완전히 오해하고 있는 것 같습니다. 스크립팅에 관해서는 못하는 것이 없다고요? 그렇지 않습니다. 사실 Scripting Guys는 스크립팅에 대한 것밖에 할 줄 모르는 사람들입니다.
그나마 다행스러운 건 Active Directory에서 OU를 선택할 수 있는 대화 상자를 만드는 것 역시 우리가 할 수 있는 일 중 하나라는 점입니다. 그림 1을 살펴보시기 바랍니다.
예, 정말 긴 스크립트입니다. 하지만 여러 개의 달걀을 깨지 않고는 오믈렛을 만들 수 없습니다. 마찬가지로 사용자 지정 대화 상자를 만들 때도 달걀을 여러 개 깨야 합니다. (이 칼럼을 반쯤 작성했을 때쯤 배가 고파서 간식을 먹어야 했으니까요.) 이제 배도 채웠으니 설명을 시작하도록 하겠습니다.
지금부터 수행하려는 스크립팅 작업은 Internet Explorer® 개체 모델을 사용하여 의사 대화 상자를 만드는 것입니다. Internet Explorer 인스턴스를 만들고 Active Directory에서 OU의 컬렉션을 가져온 다음 해당 OU를 Internet Explorer 창의 목록 상자에 표시해 보겠습니다. 그리고 사용자가 OU를 선택할 때까지 기다린 다음 선택한 항목의 ADsPath를 가져오고 "대화 상자"를 닫은 후 작업을 계속 진행합니다.
참고: 이 대화 상자가 이제껏 만들었던 대화 상자 중에서 가장 멋지고 기발한 대화 상자가 될 수 있을까요? 맞습니다. "가장 멋지고 기발하다"는 것이 확인 또는 취소 단추도 없는 단순한 대화 상자를 의미하는 것이라면 말입니다. 하지만 변명을 하자면 여기서는 기본적인 골자만 제공하는 것이 목적이므로 대화 상자를 꾸미고 수정하는 작업은 직접 해 보시기 바랍니다.
(우리가 "죄송합니다. 직접 하셔야 합니다."라고 말할 때마다 5센트씩 받았다면 아마 부자가 되었을 겁니다. 뭐, 기부금을 주시겠다면 The Scripting Guys c/o TechNet Magazine으로 보내 주셔도 됩니다.)
한정된 지면에 맞추어 방법을 설명해야 하므로 몇 가지 사항은 생략하도록 하겠습니다. 예를 들어 다음 코드 블록에 대해서는 350x400 픽셀의 Internet Explorer의 인스턴스를 만들고 그 과정에서 주소 표시줄과 상태 표시줄을 숨긴다는 정보만 설명합니다.
Set objExplorer = CreateObject( _
    "InternetExplorer.Application")

objExplorer.Navigate "about:blank"
objExplorer.ToolBar = 0
objExplorer.StatusBar = 0
objExplorer.Width= 350
objExplorer.Height = 400
objExplorer.Left = 400
objExplorer.Top = 400
objExplorer.Visible = 1
물론 이 코드는 빈 Internet Explorer 창을 제공하는 역할을 할 뿐입니다. 도메인에 있는 OU 목록을 가져오려면 Active Directory를 검색해야 합니다. 이 칼럼에서는 Active Directory 검색에 대해 자세히 설명할 수 없으므로 Script Center(microsoft.com/technet/scriptcenter/resources/tales/sg0405.mspx)에서 2부로 구성된 연재 기사를 참조하시기 바랍니다. 여기에서는 fabrikam.com 도메인에 있는 각 OU의 Name 및 ADsPath를 검색하는 데 사용되는 다음 코드만 소개하겠습니다.
objCommand.CommandText = _
    "SELECT Name, ADsPath FROM 'LDAP://DC=fabrikam,DC=com' WHERE objectCategory=
    'organizationalUnit' ORDER BY Name"
그리고 독자 여러분의 이해를 돕기 위해 OU를 이름에 따라 사전순으로 정렬했습니다. ORDER BY Name 절을 사용하여 이러한 작업을 수행할 수 있습니다. 이쯤이야 식은 죽 먹기죠. 여러분을 돕는 것이 우리의 임무이니까요.
Execute 메서드를 호출하면 fabrikam.com에 있는 모든 OU로 구성된 레코드 집합이 반환됩니다. 따라서 다음 단계로 각각의 해당 OU를 목록 상자에 표시해야 합니다.
그러기 위해선 어떻게 해야 할까요? 먼저 메모리에 전체 목록 상자를 구성해야 합니다. 맨 먼저 다음 코드 줄을 사용하여 strHTML이라는 변수에 <SELECT> 태그를 저장합니다.
strHTML = "<select size = '20' name='OUList' style='width:300px'>"
이 코드 줄은 어떤 역할을 할까요? 표준 HTML 목록 상자를 만드는 것(<SELECT> 태그를 사용한 작업)뿐입니다. 그 과정에서 목록 상자의 Name을 OUList로 지정하고 300픽셀(300px) 너비로 한 번에 20개의 항목을 표시하도록 구성했습니다. HTML에 대한 지식이 조금이라도 있다면 위의 코드를 쉽게 이해할 수 있을 것입니다.
다음으로 목록 상자에 항목(OU)을 추가해야 합니다. 신기하게도 우리가 사용할 레코드 집합은 도메인의 각 OU에 대한 정보로 구성되어 있습니다. 따라서 전체 레코드 집합에 대해 반복 실행되는 Do Until 루프를 설정하여 정보를 가져온 다음 목록 상자에 각 OU를 추가할 수 있습니다. 이 루프에서는 다음 코드(목록 상자에 항목을 추가하는 표준 HTML)를 사용하여 각 OU를 추가하고 목록에 OU Name이 표시될 수 있도록 하며, 목록 상자에서 해당 OU를 클릭할 경우 ADsPath가 스크립트로 전달되도록 항목을 구성합니다.
strHTML = strHTML & "<option value= " & _
    Chr(34) & objRecordSet.Fields
    ("AdsPath").Value & Chr(34)
strHTML = strHTML & ">" & objRecordSet.
    Fields("Name").Value
ADsPath를 스크립트로 전달하는 이유는 무엇일까요? 간단합니다. OU Name을 대신 전달한다고 가정해 봅시다. Name이 Finance라면 해당 OU를 바인딩하기가 어렵게 됩니다. "Finance"라는 이름 자체는 유효한 ADSI 바인딩 문자열이 아니기 때문입니다. 그러나 ADsPath(LDAP://ou=Finance,dc=fabrikam,dc=com)를 사용하면 간단히 바인딩할 수 있습니다. 때문에 ADsPath를 찾아 Active Directory의 개체에 연결해야 하는 것입니다.
여기서는 OU의 이름이 고유하다는 가정하에 목록 상자에 Name을 표시하고 있습니다. 그러나 North America\Research 및 Europe\Research와 같이 OU의 이름(Research)이 같다면 이렇게 할 수 없습니다. OU의 이름이 중복되는 경우에는 목록 상자에 ADsPath나 distinguishedName과 같은 다른 속성을 대신 사용해야 합니다. 이는 여러분이 직접 결정해야 할 사항 중 하나입니다. (또 5센트를 받을 수 있겠군요!)
어쨌든 메모리에 목록 상자를 만드는 작업을 계속하도록 하겠습니다. 이 상자에 추가한 각 항목은 strHTML 변수에 추가됩니다. 이것이 바로 우리 계획의 핵심입니다. 즉, 목록 상자의 전체 코드를 strHTML 변수에 저장한 다음 해당 변수의 값을 사용하여 실제로 목록 상자를 Internet Explorer 인스턴스에 추가하는 것입니다.
OU를 모두 추가한 후에는 아래의 코드 줄을 사용하여 목록 상자의 끝을 표시합니다.
strHTML = strHTML & "</select>"
이때 strHTML에는 목록 상자를 만드는 데 필요한 모든 HTML 태그가 들어 있게 됩니다. 그리고 해당 목록 상자의 각 항목은 Active Directory의 OU를 나타냅니다. 따라서 이제 strHTML 값을 Internet Explorer 문서의 InnerHTML 속성에 할당할 수 있습니다.
objExplorer.Document.Body.InnerHTML = strHTML
결과적으로 도메인의 모든 OU를 표시하는 목록 상자가 만들어집니다.
하지만 이것으로 끝이 아닙니다. 예를 들어 사용자가 대화 상자에서 OU를 선택할 때까지 스크립트를 일시 중지하는 코드가 필요합니다. 이러한 코드가 없으면 목록 상자는 표시되겠지만 사용자가 OU를 선택했는지에 관계없이 스크립트가 계속 실행됩니다. 이와 같은 문제가 생기지 않도록 하기 위해 다음 코드 블록을 사용합니다.
Do While objExplorer.Document.Body.All.OUList.Value = ""
    Wscript.Sleep 300
Loop
이 코드 블록은 반복적으로 목록 상자(앞서 설명했듯이 OUList로 이름을 지정한 목록 상자)의 Value를 확인합니다. Value가 빈 문자열(선택된 항목이 없는 경우)이면 스크립트를 300밀리초 동안 일시 중지하고 루프를 실행한 후 다시 확인합니다. 이러한 프로세스는 a) 영원히, b) 사용자가 목록 상자에서 항목을 선택할 때까지, 또는 c) 사용자가 Internet Explorer를 닫을 때까지 계속됩니다.
사용자가 목록 상자에서 OU를 선택했다고 가정해 봅시다. 이 경우 Value(OU의 ADsPath)를 가져와 strTargetOU라는 변수에 할당합니다.
strTargetOU = objExplorer.Document.Body.All.OUList.Value
그런 다음 아래와 같이 Quit 메서드를 사용하여 Internet Explorer 인스턴스를 종료합니다.
objExplorer.Quit
이제 거의 끝났습니다. 먼저 strTargetOU가 빈 문자열인지 확인합니다.
If strTargetOU = "" Then
    Wscript.Quit
End If
빈 문자열인 경우 사용자가 OU를 선택하지 않고 Internet Explorer를 닫은 것이므로 Wscript.Quit 메서드를 사용하여 스크립트를 종료합니다. (사용자가 OU를 선택하지 않으면 스크립트를 실행할 의도가 없는 것으로 가정하는 것입니다.) 그러나 strTargetOU가 빈 문자열이 아니면 변수의 값을 출력합니다.
Wscript.Echo strTargetOU
물론 실제로 스크립트를 작성할 때는 단순히 ADsPath를 출력하는 데 그치지 않고 Active Directory의 해당 OU에 바인딩하게 될 것입니다. 그러나 항상 말하듯이 그 과정은 여러분의 몫으로 남겨 두겠습니다.
앞서 설명했듯이, 그리고 그림 2에서 볼 수 있듯이 화려한 대화 상자는 아니지만 잘 작동할 뿐만 아니라 ADsPath를 직접 입력하는 것(ADsPath를 알고 있다는 가정하에)보다 훨씬 간단합니다. 또한 코드와 대화 상자를 필요에 따라 알맞게 사용자 지정할 수도 있습니다.
Figure 2 A simple script dialog
Figure 2 A simple script dialog

자, 이제 Active Directory에서 OU를 선택하는 대화 상자를 표시하는 방법에 대한 칼럼도 썼으니 5센트어치의 값은 한 셈이라고 생각합니다. 결국 TechNet Magazine에서 주는 임금에서 5센트가 늘게 되었군요.
뭐, 절대 불평하는 것은 아닙니다.

Microsoft Scripting Guys는 Microsoft의 직원입니다. 이들은 야구 경기를 하거나, 감독하거나, 관람하는 등의 일상적인 다른 활동을 하지 않을 때 TechNet 스크립트 센터를 운영합니다. 자세한 내용은 www.scriptingguys.com에서 확인하십시오.


 Exchange Queue &amp; A: 트랜잭션 로그, cmdlet, 원격 관리 및 기타 기능
Exchange Queue & A
트랜잭션 로그, cmdlet, 원격 관리 및 기타 기능
KC Lemson and Nino Bilic

Q: Microsoft® Exchange Server 2007에서는 트랜잭션 로그 크기가 1MB로 줄었는데 그 이유가 무엇입니까?
A: Exchange 2007에는 LCR(로컬 연속 복제)과 CCR(클러스터 연속 복제)이라는 새로운 기능의 기반이 되는 로그 전달이라는 매우 우수한 기술이 도입되었습니다. 이 로그 전달 기능을 SG(저장소 그룹) 수준에서 사용할 때는 실행 중인 프로덕션 SG에서 복사본 SG로 트랜잭션 로그가 복사됩니다. 복사본 SG의 트랜잭션 로그는 다시 데이터베이스로 재생되어 데이터베이스가 최신 상태로 유지됩니다. 설명이 너무 간단한 것 같지만 큰 그림은 파악할 수 있으리라 믿습니다.
중요한 것은 프로덕션 SG에서 트랜잭션 로그가 닫히지 않으면 복사본 SG로 트랜잭션 로그를 보낼 수 없다는 것입니다. 다시 말해, 첫 번째 저장소 그룹의 현재 로그 e00은 꽉 차서 닫힌 후 이름이 바뀌기 전에는 복사본 SG로 보낼 수 없습니다. 또한 가용성과 성능 간의 균형을 이루도록, 이 프로세스에서 자동으로 기록되는 로그의 수를 제어하는 설정도 제공됩니다. 이러한 설정은 Exchange 관리 셸의 Set-MailboxServer cmdlet을 실행하여 사용할 수 있습니다. 필요한 매개 변수에 대한 정보는 도움말 파일을 통해 볼 수 있습니다.
간단히 요약하면, 저장소 그룹의 두 복사본 간의 동기화되지 않은 데이터 양을 최소화하기 위해 트랜잭션 로그 크기를 줄인 것입니다. 이는 프로덕션 데이터베이스가 있는 하드 드라이브에 오류가 발생하여 복사본에서 SG를 시작해야 할 경우에 매우 유용한데, 트랜잭션 로그의 크기가 작을수록 손실되는 데이터의 양도 줄어들기 때문입니다.
그렇다고 정확히 1MB의 데이터만 손실된다는 말은 아닙니다. 1MB의 데이터가 트랜잭션 로그라고 가정할 경우, 손실된 1MB의 로그 파일에는 5MB의 데이터에 대한 COMMIT 트랜잭션 로그가 포함되어 있을 수도 있습니다. 이러한 경우에는 복사본에 이 5MB의 데이터가 존재하지 않게 됩니다. 데이터 자체가 있는 다섯 개의 로그를 받았더라도 소량의 데이터가 있고 COMMIT 트랜잭션을 필요로 하는 마지막 필수 로그를 받지 못했기 때문입니다.
결국 비즈니스 요구 사항에 비추어서 이러한 데이터 손실이 감당할 만한 것인지를 결정하는 것은 순전히 사용자의 몫입니다. 이는 복원하는 데 시간이 오래 걸리는 다른 방법에 비해 손실되는 데이터의 양이 적고 복구 시간이 짧다는 점에서 매우 우수하다고 볼 수 있습니다. 이 주제에 관해서는 향후에 자세히 다루겠습니다.

Q: 트랜잭션 로그의 크기가 작아지면 트랜잭션 로그가 더 빨리 소모되나요?
A: Exchange에서는 "소모된다"라는 표현이 트랜잭션 로그 이름에 적용됩니다. Exchange Server 2003에서는 트랜잭션 로그 이름이 다음과 같이 지정됩니다.
E nn fffff.log
nn은 SG마다 다르게 지정되는 접두사입니다. nn은 SG가 사용되는 동안에는 동일하게 유지되므로 저장소 그룹에 대해 고유하게 만들어지는 번호는 "fffff" 값이라고 할 수 있습니다. 이 값은 로그 수를 최대 백만 개까지 수용할 수 있습니다. 어마어마한 수에 놀라울 지경이지만 저희 고객 중 몇몇은 사용량이 많은 메일 서버에서 실제로 이 한계에 도달한 적도 있었습니다.
Exchange Server 2000부터는 이 한계에 근접했을 때 응용 프로그램 로그에 이벤트를 표시하는 핫픽스를 제공하고 있습니다. 이에 대한 자세한 내용은 support.microsoft.com/kb/896001 페이지를 참조하십시오.
Exchange 2007에서는 이런 식의 이름 지정으로 인해 어떤 현상이 발생할까요? 앞에서 Exchange 2007에서는 트랜잭션 로그 크기가 이전 버전 Exchange의 5MB에서 1MB로 줄었다는 설명을 드린 바 있습니다. 그러면 고유 트랜잭션 로그 이름이 모두 소모되기 전까지 5분의 1의 데이터만 수용할 수 있다는 의미일까요?
아닙니다. Exchange 2007에서는 트랜잭션 로그 이름이 다음과 같은 형식으로 지정됩니다.
E nn ffffffff.log
이전 버전의 "fffff"가 아니라 "ffffffff" 로그를 사용하게 되었다는 점을 눈여겨보십시오. 내부 ESE(Extensible Storage Engine)에서 사용하는 수학 공식으로 인해 Exchange 2007에서는 "ffffffff" 로그를 전부 만들지는 못하고 대신 "7fffffec" 로그를 만드는데, 이 수치는 어마어마합니다. 못 믿으시겠다면 이 16진수를 10진수로 변환해 보십시오.
실제 환경에서는 이것이 무엇을 의미할까요? Exchange 2007에서는 이전 버전의 Exchange보다 2,048배나 많은 로그를 만들 수 있다는 것을 의미합니다. 이제 이러한 로그 수를 5로 나누면 최종 수치가 나옵니다.
2048 / 5 = 409.6
앞에서 살펴보았듯이 새로운 이름 지정 체계는 이전보다 409배나 많은 데이터를 처리할 수 있습니다. 또한 저장소 그룹마다 e00, e01 등, 서로 다른 로그 파일 접두사가 지정되므로 이러한 처리 성능의 개선은 서버 단위가 아니라 SG 단위로 이루어집니다. 뿐만 아니라 Exchange 2007 Enterprise 버전에서는 서버당 SG를 50개나 만들 수 있습니다. 이렇게 많은 트랜잭션 로그를 모두 사용할 수 있는 조직은 앞으로 당분간은 거의 없다고 봅니다.

Q: Exchange 2007 서버를 원격으로 관리하려면 어떻게 해야 합니까?
A: Exchange 2007 서버는 몇 가지 방법을 사용하여 원격으로 관리할 수 있습니다. 먼저, Exchange 서버와는 별도의 컴퓨터에 Exchange 2007 관리 도구를 설치할 수 있습니다. 단, Exchange 2007 관리 도구를 설치하는 컴퓨터에서 32비트 또는 64비트 버전의 Windows Server® 2003 SP1(서비스 팩 1) 이상, Windows Server 2003 R2 또는 Windows XP SP2 이상을 실행해야 합니다. 프로덕션 환경에서 클라이언트 액세스, 사서함, Edge 전송 서버 등의 서버 역할은 32비트 하드웨어에 설치할 수 없지만 관리 도구는 32비트 컴퓨터에 설치할 수 있습니다. 또한 Exchange Server 2007이 처음 릴리스될 당시에는 Windows Vista™에서 관리 도구가 지원되지 않았다는 점에도 유의하십시오.
일부 조직의 IT 부서에서는 관리 서버로 사용할 서버를 하나 만든 다음, 이 서버에 다양한 제품을 관리하는 데 필요한 관리 도구를 모두 설치합니다. 그리고 해당 관리 도구를 사용해야 하는 관리자가 터미널 서버를 통해 관리 서버에 액세스하여 원격 관리 작업을 수행합니다. 다른 설정 환경에서는 사용자가 자신의 데스크톱 컴퓨터에 관리 도구를 설치합니다.
콘솔이나 셸에서 조직의 서버에 대한 작업을 수행할 수 있습니다. 콘솔에는 조직의 서버가 모두 표시되므로 원하는 서버에서 작업을 수행할 수 있습니다. 셸에서는 대부분의 작업에 필터링 플래그가 지원됩니다. 예를 들어 -server와 같은 필터링 플래그는 작업 범위를 단일 서버로 제한하려는 경우에 유용합니다. 하지만 Get-NetworkConnectionInfo와 같이 로컬에서만 실행해야 하는 명령이 있는 등, 몇 가지 제한도 따릅니다.

Q: 지난 호 칼럼에서는 Exchange 2007 서버의 권장 RAM 크기에 대해 설명하신 바 있습니다. 권장 페이지 파일 크기는 어느 정도입니까?
A: Exchange 2007 서버의 잠재적 가상 메모리 부족 오류를 방지하려면 다음 지침에 따라 시스템의 페이지 파일 크기를 결정하는 것이 좋습니다.
서버의 RAM 크기가 8GB 미만이면 페이지 파일의 최소 크기가 RAM 크기에 10MB를 더한 크기여야 합니다. 따라서 서버의 RAM 크기가 4GB일 경우 페이지 파일의 최소 크기는 이 4GB에 10MB를 더한 크기입니다. 하지만 페이지 파일의 권장 크기는 RAM 크기에 1.5를 곱한 크기이므로 4GB 서버의 경우 6GB가 됩니다.
RAM 크기가 8GB 이상인 서버의 경우에도 페이지 파일의 최소 크기는 RAM 크기가 8GB 미만인 서버와 마찬가지로 RAM 크기에 10MB를 더한 크기입니다. 하지만 권장 크기는 이와는 다르게 결정됩니다. 기본적으로 RAM 크기가 8GB 이상인 서버에서는 작은 페이지 파일로 인해 가상 메모리 부족 오류가 발생할 경우에만 RAM 크기의 1.5배로 페이지 파일 크기를 설정하면 됩니다.
여기서 말하는 오류는 Exchange 2000 및 Exchange 2003 서버에서 문제가 되었던 가상 메모리 조각과는 아무런 관계가 없으며, 페이지 파일 크기를 늘리도록 요청하거나 페이지 파일이 너무 작다는 것을 알려 주는 시스템에 기록된 실제 팝업 오류를 의미합니다.

Q: Exchange 관리 셸을 사용하는 방법을 배우고 싶은데 명령줄을 사용하여 시스템을 관리해 본 적이 없습니다. 어디서부터 시작하는 것이 좋을까요?
A: 먼저 몇 가지 기본적인 사항부터 살펴보겠습니다. Exchange 관리 셸의 각 cmdlet은 동사 하나와 명사 하나로 이루어집니다. Exchange 관리 셸에는 몇 가지 동사밖에 사용되지 않습니다. "Get"은 개체의 속성을 검색하는 데 사용되고, "Set"은 개체의 속성을 변경하는 데 사용되며, "New"는 개체에 새로운 속성을 만드는 데 사용됩니다. Exchange 관리 셸에서 사용되는 명사에는 Exchange 관리자라면 누구나 잘 알고 있는 Mailbox, Contact, Queue, OWAVirtualDirectory 등의 다양한 개념이 포함됩니다. 이와 더불어 Exchange Server 2007에 새로 추가된 TransportRule, StorageGroupCopy, UMAutoAttendant 등의 개념도 포함됩니다. 실제로 사용되는 기본적인 cmdlet은 사서함을 만드는 New-Mailbox나 조직의 사서함 목록을 검색하는 Get-Mailbox와 같은 형식입니다.
하지만 대부분의 cmdlet의 경우 이를 사용하여 원하는 작업을 정확하게 수행하려면 보다 구체적인 정보를 제공해야 합니다. 예를 들어 사서함 속성을 변경하려면 사서함과 속성을 지정해야 하는데 이때는 매개 변수를 사용하면 됩니다. 예를 들어 New-Sandwich가 cmdlet이라면, -NumberOfTomatoSlices 4, -Bread Wheat, 그리고 원하는 샌드위치를 만들기 위해 보다 자세히 지정하는 데 사용되는 다양한 옵션이 매개 변수가 됩니다.
이러한 동사-명사 구조만 이해한다면 EMC(Exchange 관리 콘솔) 마법사에 표시되는 명령줄을 사용하여 각 cmdlet으로 어떤 작업을 수행할 수 있는지를 금방 배울 수 있습니다. EMC에서 마법사를 처음부터 끝까지 실행하여 새 사용자를 만들어 보십시오. 작업이 완료된 후 마법사가 끝날 때 마법사가 배경에서 실행한 명령의 복사본이 표시됩니다(그림 1 참조). Ctrl+C를 누르면 대화 상자의 내용이 복사되므로 cmdlet을 메모장에 붙여 넣어 고유의 간단한 배치 파일을 만들 수 있습니다.
Figure 1 Command-line exposure for creating a new user
Figure 1 Command-line exposure for creating a new user (더 작게 보려면 이미지를 클릭하십시오.)
Figure 1 Command-line exposure for creating a new user
Figure 1 Command-line exposure for creating a new user (더 크게 보려면 이미지를 클릭하십시오.)
시스템에 어떠한 손상도 주지 않고 cmdlet을 직접 사용해 보려면 명령 끝에 -WhatIf를 넣으십시오. 그런 다음 명령을 실행하면 시스템에서 실제로 무언가가 변경되는 대신, 명령을 실행할 경우 어떤 일이 발생하는지를 보여 주는 메시지가 표시됩니다.
*-Mailbox와 같은 기본 cmdlet에 익숙해지면 몇 가지 다른 명령을 시도해 볼 수 있습니다. cmdlet에 대한 자세한 정보를 보려면 Get-ExCommand cmdlet을 사용하십시오. Get-ExCommand cmdlet을 실행하면 모든 Exchange 관리 cmdlet 목록이 표시됩니다. 이 명령은 Exchange 관리 셸을 실행하는 동안 실행해야 합니다. 단순히 Microsoft Command Shell이나 Windows PowerShell™을 열었다고 해서 cmdlet을 이용한 작업이나 다른 Exchange 관리 작업을 수행할 수 있는 것은 아닙니다. 표시되는 목록이 방대하므로 와일드카드 검색 방법을 사용하여 원하는 cmdlet을 찾아야 합니다. 예를 들어 Get-ExCommand *database*는 Dismount-Database, Move-DatabasePath, New-MailboxDatabase 등 이름에 "database"가 있는 모든 Exchange cmdlet 목록을 반환합니다.
찾으려는 cmdlet의 명사 부분을 알고 있는 경우에는 옵션을 차례로 볼 수 있습니다. 예를 들어 Get-Mailbox를 입력한 다음 Tab 키를 눌러 작업 이름의 명사에 mailbox가 들어가는 모든 cmdlet을 차례로 표시할 수 있습니다. 와일드카드 일치와 Tab 키를 이용한 완성 기능을 함께 사용할 수도 있습니다. 예를 들어 Get-*Mailbox*를 입력한 다음 Tab 키를 눌러 가능한 옵션을 차례로 표시할 수 있습니다.
프롬프트를 사용하는 방법도 있습니다. 각 cmdlet에는 해당 작업을 수행하는 데 필요한 기본 매개 변수 집합이 있습니다. Get-Mailbox와 같은 "Get" cmdlet에는 매개 변수가 필요하지 않습니다. 기본적으로 Get-Mailbox는 조직 전체의 모든 사서함 목록을 반환합니다. 목록은 기본적으로 1,000개까지 반환됩니다. 이 최대값을 변경하려면 Get-Mailbox -ResultSize 2000과 같이 값을 입력합니다. 개체를 만들거나 변경하는 Set 또는 New cmdlet은 만들거나 수정하려고 하는 개체에 필요한 정보를 사용자에게 요청합니다. 예를 들어 New-Mailbox를 실행하면 암호, 데이터베이스, 이름 등을 요청하는 프롬프트가 한 번에 하나씩 셸에 표시됩니다.
특정 cmdlet에 사용할 수 있는 매개 변수에 대한 자세한 정보를 보려면 Help Move-DatabasePath를 실행하여 도움말 시스템을 사용하십시오. 기본적인 내용만 살펴보려면 Move-DatabasePath, Move-DatabasePath -? 등으로만 입력해도 됩니다. 그러면 cmdlet에 대한 설명과 함께 각 cmdlet의 용도와 매개 변수 목록이 표시됩니다. Get-Help cmdlet을 사용하여 도움말을 표시할 수도 있습니다. Get-Help만 입력하면 되므로 정말 편리합니다. 다른 사람들에게도 이 cmdlet을 실행하는 방법을 쉽게 알려 줄 수 있습니다.
cmdlet에 필요한 매개 변수를 찾는 또 다른 방법은 Tab 키를 사용하여 매개 변수 이름을 표시하는 것입니다. 예를 들어 Get-Mailbox -S를 입력한 다음 Tab 키를 누르면 S로 시작하는 매개 변수가 차례로 표시됩니다.
이 외에 더 광범위한 도움말 시스템도 제공됩니다. 원하는 정보를 오프라인에서 찾지 못한 경우에는 go.microsoft.com/fwlink/?linkid=79421의 정기적으로 업데이트되는 도움말 및 go.microsoft.com/fwlink/?linkid=64647의 빠른 참조 안내를 참조하십시오.
이 정도의 지식만 있으면 Exchange 관리 콘솔을 사용하는 데 별 무리가 없습니다. 하지만 여기에서 제공한 정보는 명령줄의 우수한 성능과 융통성이 지닌 일면만 간단히 보여 준 것에 불과합니다. 명령줄의 성능과 융통성에 대해서는 향후에 제공될 칼럼에서 보다 자세히 다루겠습니다.

Q: Exchange Server 2003 ESM(Exchange 시스템 관리자)에서는 모든 사용자의 사서함 크기를 쉽게 볼 수 있었는데 Exchange 2007에는 이와 같은 기능이 없는 것 같습니다. Exchange 2007에 이에 해당하는 기능이 있습니까?
A: 새로운 Exchange 2007 콘솔에서는 사서함 자체의 속성 페이지에서 사서함 크기를 볼 수 있습니다. 여러 사용자의 사서함 크기를 보려면 Exchange 관리 셸을 사용해야 합니다.
Exchange 관리 셸에서 Get-MailboxStatistics를 실행하면 특정 데이터베이스뿐만 아니라 서버 전체의 모든 사서함과 관련된 통계를 볼 수 있습니다. 기본적으로 크기는 표시되지 않습니다. 크기를 보려면 Format-List와 함께 이 cmdlet을 실행해야 합니다.
get-mailboxstatistics | format-list
이 경우에는 보려는 정보를 선택한 다음 이를 표에 연결하는 것이 좋습니다. 다음 예에서는 사서함의 표시 이름, 항목의 총 크기, 지운 편지함의 총 크기, 사서함이 있는 데이터베이스를 표시합니다.
Get-MailboxStatistics | Select-Object
displayname,totalitemsize,
totaldeleteditemsize,databasename
| Format-Table
보려는 정보에 따라 출력 내용에 서로 다른 형식을 사용할 수 있습니다. 이 예에서는 Format-List보다 Format-Table을 사용하는 것이 적절합니다.

KC Lemson은 Exchange Server 팀의 수석 프로그램 관리자이고 ATM PIN 번호는 0000입니다. 한 곳에서 모두 인출하지만 마십시오.
Nino Bilic은 기술 팀장 직을 맡고 있으며 Bill에게 전자 메일을 전달하는 대가로 1,000달러짜리 수표를 받으며 여가 시간을 보내고 있습니다.


 Security Watch: EFS 배포: 2부
Security Watch
EFS 배포: 2부
John Morello

파일 시스템 암호화(EFS) 배포는 기본적으로 인증서 관리 및 복구 에이전트에 초점을 둔 백 엔드 디자인 부분과 사용자가 접하는 EFS 배포 부분의 두 부분으로 구성된다고 간주할 수 있습니다. 지난 달에는 백 엔드 부분에 대해 다뤘고 클라이언트용 인증서를 준비할 때의 옵션과 데이터 및 키 복구 옵션에 대해 설명했습니다.
이번 호에서는 Windows® 탐색기의 향상된 기능, 암호화할 파일 시스템 위치 선택 및 그룹 정책으로 암호화 옵션을 관리하는 방법 등과 같이 최종 사용자가 접하게 될 배포 측면을 중점적으로 다룹니다.

EFS를 사용 중인지 여부 확인
EFS를 배포하기로 결정한 이후의 첫 번째 단계는 조직 내 EFS 사용의 현재 상태를 확인하는 것입니다. EFS는 독립 실행형 모드로 사용할 수 있으며, 이 경우 암호화 키의 생성과 백업에 대한 책임은 전적으로 최종 사용자에게 있습니다. 조직에 이러한 방식으로 이미 EFS를 사용하고 있는 고급 사용자가 있을 수 있으므로 보다 강력하게 관리되는 배포로 무리 없이 전환하기 위해서는 이러한 사용자를 파악하는 것이 중요합니다.
컴퓨터의 지정된 사용자가 EFS를 처음 배포하면 Windows의 HKEY_CURRENT_USER에 다음과 같은 레지스트리 항목이 생성됩니다.
HKCU\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys\CertificateHash
Microsoft® Systems Management Server(SMS), Active Directory 로그온 스크립트 또는 다른 도구를 사용하여 엔터프라이즈의 전체 시스템을 대상으로 이 항목이 있는지 확인할 수 있습니다. 레지스트리에 이 값이 있으면 EFS를 사용한 적이 있는 사용자입니다. 하지만 이 값이 있다고 해서 꼭 EFS를 현재 사용하고 있다거나 암호화된 데이터가 있음을 나타내는 것은 아닙니다. 따라서 이 레지스트리 키가 있는 시스템이 발견되면 더 자세히 조사하여 파일이 현재 암호화되어 있는지 확인해야 합니다.
/U와 /N 스위치를 지정하여 cipher.exe를 실행하면 컴퓨터에 있는 파일 및 디렉터리의 암호화 상태를 볼 수 있습니다. 예를 들어 시스템에 암호화된 데이터가 있는지 확인하려면 다음 명령을 실행합니다.
cipher /U /N
레지스트리 검사와 암호화 보고를 하나의 스크립트로 결합하여 이 레지스트리 값이 있는지 검사하고 이 값이 있으면 컴퓨터에서 현재 암호화된 파일에 대한 보고서를 생성할 수도 있습니다. 이 보고서가 생성되면 어떤 사용자의 어떤 파일이 암호화되었는지 파악하고 이를 중앙 관리 디자인으로 마이그레이션할 수 있습니다.
배포 도중 그룹 정책의 적용을 제어하려면 도메인에 두 개의 보안 그룹을 만들어서 EFS를 사용하는 컴퓨터와 사용하지 않는 컴퓨터를 분리하는 것이 좋습니다. 예를 들어 "SG-ComputersUsingEFS"에는 EFS를 이미 사용하고 있는 컴퓨터의 컴퓨터 계정이 포함되고 "SG-ComputersNotUsingEFS"에는 현재 EFS를 사용하고 있지 않은 다른 모든 시스템이 포함될 수 있습니다.

그룹 정책으로 EFS 사용 제어
EFS를 사용하는 사용자와 사용하지 않는 사용자를 파악했으면 클라이언트 배포의 다음 단계는 현재 EFS를 사용하고 있지 않은 사용자가 독립 실행 방식으로 EFS를 사용하지 않도록 하는 것입니다. 자체 서명된 인증서를 사용하고 있는 사용자를 마이그레이션하는 것보다 처음부터 EFS를 적절하게 사용 가능하도록 하고 구성하는 것이 더 쉽기 때문에 이 단계는 배포 프로세스에서 매우 중요합니다. EFS를 사용하지 않도록 그룹 정책을 통해 설정하면 이미 EFS를 사용 중이던 사용자는 현재 암호화된 파일에 액세스할 수 없게 되므로 EFS를 이미 사용 중인 사용자가 누구인지 먼저 파악한 뒤에 이 단계를 수행해야 합니다. 이 정책은 컴퓨터 구성\Windows 설정\보안 설정\공개 키 정책\파일 시스템 암호화 아래의 그룹 정책 개체 편집기에서 찾을 수 있습니다.
앞에서 설명했듯이 이미 EFS를 사용 중인 사용자의 작업이 중단되지 않도록 현재 EFS를 사용하고 있지 않은 컴퓨터에만 이 값을 적용해야 합니다. 따라서 위의 예에서 EFS를 사용하지 않도록 하는 그룹 정책 개체(GPO)의 액세스 제어 목록(ACL)에서는 "SG-ComputersNotUsingEFS" 그룹에만 그룹 정책을 적용하도록 허용합니다.

암호화 여부
관리되는 배포 전까지 현재 EFS를 사용 중인 시스템을 확인하고 그렇지 않은 모든 시스템의 EFS를 중지하였으면 다음 단계는 해당 관리되는 배포에서 암호화할 대상을 결정하는 것입니다. 클라이언트 시스템을 관리하는 방식에 따라 이 프로세스는 간단할 수도 있고 꽤 복잡할 수도 있습니다.
암호화할 파일을 결정할 때 첫 번째로 고려해야 할 사항은 사용자가 자신의 시스템에서 관리자인지 여부입니다. 사용자가 로컬 관리자라면 중요한 데이터를 암호화하도록 사용자를 교육하고 장려할 수는 있지만 실질적으로 데이터 암호화를 관리되는 방식으로 제어할 수는 없습니다. 그 이유는 간단합니다. 로컬 관리자는 파일 시스템의 어떤 곳에나 파일과 디렉터리를 만들 수 있기 때문입니다. 따라서 내 문서와 같은 공통 위치를 암호화할 수는 있지만 사용자가 다른 위치에 새 디렉터리를 만들고 거기에 중요한 정보를 저장하면 이 데이터도 보호되는지 확인하기가 꽤 어렵습니다. 이런 사실 때문에 EFS는 최종 사용자가 로컬 관리자가 아닐 때 얻는 모든 보안 장점에 추가하여 관리 편의성과 보안을 더욱 강화합니다.
EFS에 대해 염두에 두어야 할 또 다른 중요한 정보는 EFS는 사용자별 암호화라는 점입니다. 즉, 특정 사용자에 의해 암호화된 항목은 해당 사용자만 해독할 수 있고 SYSTEM 계정을 포함한 다른 사용자는 해독할 수 없습니다(물론 데이터 복구 에이전트(DRA)가 되는 상황은 예외임). 따라서 실행 파일이나 DLL이 사용자의 키로 암호화되어 있을 때 시스템의 다른 개체가 이에 액세스하려고 하면 액세스 거부 오류가 발생합니다. 이런 이유 때문에 일반적으로 시스템의 여러 주체가 액세스해야 하는 실행 코드를 포함하는 파일이나 디렉터리는 암호화하지 않아야 합니다. Windows에서는 %SystemRoot%의 파일 또는 SYSTEM 속성을 포함하는 파일의 암호화를 금지하지만 SYSTEM 계정에 의해 실행되는 서비스를 위해 바이너리를 %ProgramFiles%에 설치하는 소프트웨어 공급업체도 많습니다. 예를 들어 랩톱 공급업체의 경우 서비스로 실행되는 전원 및 장치 관리 소프트웨어를 이런 방식으로 설치하는 경우가 많습니다.
그러면 이 두 가지를 고려했을 때 최적의 EFS 암호화 대상은 무엇일까요? 이에 대한 답변은 사용자의 시스템이 일반적으로 어떻게 구성되어 있는지에 따라 달라집니다. 표준화된 운영 체제 이미지를 사용한 잘 관리되는 환경에서는 이미지에 미리 결정되어 있는 데이터 저장 위치를 기준으로 사용자를 위한 암호화 프로세스를 자동화할 수 있을 가능성이 큽니다. 예를 들어 사용자가 %userprofile%\내 문서에만 데이터를 저장하는 경우에는 이 디렉터리만 암호화하면 됩니다. 참고로 폴더 리디렉션을 사용하는 경우에는 내 문서를 암호화할 때 주의해야 합니다. 내 문서가 서버로 리디렉션되는 경우 서버는 위임용으로 트러스트되어야 하며 사용자의 프로필에 액세스할 수 있어야 합니다. 이런 경우에는 일반적으로 오프라인 파일 캐시만 암호화하는 것이 더 쉽습니다. 이에 대해서는 이 칼럼 뒷부분에서 설명합니다.
사용자가 파일 시스템의 여러 위치에 쓸 수 있는 관리 수준이 낮은 환경에서는 몇 개의 공통 저장 위치의 암호화를 자동화한 다음 사용자들에게 다른 위치를 직접 암호화하는 방법을 교육하는 접근법을 사용할 수 있습니다. 어떤 환경이든지 항상 파일 수준이 아닌 디렉터리 수준에서 암호화해야 합니다. 이렇게 하면 임시 파일을 포함하여 해당 디렉터리에 만들어지는 모든 파일을 항상 암호화할 수 있습니다.

권장되는 암호화 위치
일반적으로 암호화해야 하는 위치는 %userprofile%\내 문서, %userprofile%\Application Data\Microsoft\Outlook(Microsoft Office Outlook®을 메시징 클라이언트로 사용하는 경우) 및 %userprofile%\바탕 화면입니다. 내 문서를 암호화하면 Windows XP에서 파일이 저장되는 기본 위치를 보호할 수 있습니다. Outlook 디렉터리를 보호하면 로컬로 캐시되는 민감한 전자 메일도 암호화할 수 있습니다. 이는 Outlook 2003을 기본값인 캐시 모드로 실행하는 사용자에게 특히 중요합니다. 마지막으로 바탕 화면은 사용자가 현재 작업 중인 문서나 자주 사용하는 프레젠테이션을 넣어두는 일종의 임시 디렉터리로 사용하는 경우가 많습니다. 물론 조직에 따라 이러한 디렉터리 중 일부의 기본 위치를 수정했을 수 있으므로 조직에서 일반적으로 사용되는 위치를 반영하여 EFS 암호화를 적용해야 합니다.
이러한 일반적인 권장 사항 이외에도 민감한 정보를 다른 위치에 저장할 수 있는 응용 프로그램이 있는지 여부도 확인해야 합니다. 예를 들어 일부 응용 프로그램은 사용자 정보를 사용자의 프로필이 아니라 %ProgramFiles%\AppName에 저장합니다. 따라서 사용자가 사용하는 모든 데이터를 적절하게 보호할 수 있도록 클라이언트 시스템에 이러한 응용 프로그램이 있는지 확인하는 것이 중요합니다. 가장 좋은 시나리오는 EFS를 변경할 필요가 없도록 변경 내용을 다른 사용자 프로필 고유 경로(예: 내 문서)에 저장하도록 응용 프로그램을 구성하는 것입니다. 응용 프로그램이 데이터를 해당 응용 프로그램의 Program Files 디렉터리에 저장해야 하는 최악의 시나리오에서는 EFS를 사용하여 Program Files의 특정 하위 디렉터리만 암호화하도록 할 수 있습니다.
끝으로 임시 디렉터리(%TMP% 및 %TEMP%)를 암호화하려는 경우에는 주의해야 합니다. 응용 프로그램 설치 프로그램 중에는 이 디렉터리에 설치 패키지 내용의 압축을 푼 다음 압축이 풀린 파일에 대한 파일 이동 작업을 수행하여 %ProgramFiles%의 적절한 경로로 옮기는 경우가 많습니다. 같은 볼륨에서 이동된 파일은 원래의 속성이 유지되므로 %ProgramFiles%로 이동된 뒤에도 계속 암호화된 상태가 유지됩니다. 따라서 설치 프로그램을 실행한 사용자가 아닌 다른 사용자가 이 파일을 사용하려고 하면 액세스가 거부됩니다. 이러한 문제는 근본적인 원인을 알려주는 명확한 응용 프로그램 오류 메시지를 표시하지 않는 경우가 많습니다. 이런 이유 때문에 %TMP%는 최종 사용자가 직접 응용 프로그램을 설치하지 않는 잘 관리되는 환경에서만 암호화할 것을 권장합니다.

오프라인 파일 보호
오프라인 파일은 사용자가 파일 서버에 저장된 데이터의 로컬 복사본을 만들 수 있도록 해 주는 Windows 2000 이상에서 제공하는 기능으로서, 서버와의 연결이 끊긴 상태에서도 사용자가 이 데이터에 대한 작업을 수행하고 다음에 서버에 연결되었을 때 변경 내용을 서버로 동기화할 수 있도록 합니다. 하지만 오프라인 파일은 단순히 서버에 있는 파일의 복사본이 들어 있는 디렉터리가 아니라, 시스템 전체에서 공유되며 SYSTEM 계정의 컨텍스트에서 실행되는 데이터베이스입니다. Windows XP에서 이 데이터베이스를 EFS로 보호할 수 있습니다. EFS는 사용자 단위가 되어야 한다는 점을 고려하면서 이것의 의미를 생각해 보십시오. 사용자별 EFS로 어떻게 여러 보안 주체가 사용하는 데이터베이스를 암호화할 수 있을까요?
Windows XP를 사용하는 사용자가 Windows 탐색기에서 오프라인 파일을 암호화하도록 선택했을 때 사용되는 암호화 루틴은 사용자가 시작할 수 있는 다른 암호화 작업에 사용되는 루틴과 다릅니다. 사용자의 개인 EFS 키 쌍을 프로세스에 사용(SYSTEM이 파일에 액세스할 수 없음)하는 대신 SYSTEM 계정에서 EFS에 사용할 키 쌍을 자체적으로 생성하고 이 키 쌍을 사용하여 클라이언트 쪽 캐시를 암호화합니다. 따라서 누군가가 SYSTEM으로 실행할 수 있는 코드를 얻을 수 있다면 캐시의 데이터를 해독할 수 있게 되는 심각한 보안 문제가 있습니다. 랩톱을 도난당한 경우 공격자는 쉽게 관리자 암호를 재설정하여 관리자로 로그온할 수 있습니다. 관리자로 실행하기만 하면 코드가 SYSTEM으로 실행되도록 하여 캐시에 액세스하는 것 역시 매우 간단합니다. Windows Vista™에서는 이 동작이 변경되었습니다. 이제 Windows Vista에서는 사용자별 오프라인 파일을 암호화할 때 개인 사용자의 키를 사용합니다.
보안 계정 관리(SAM)의 오프라인 데이터베이스를 위한 암호화 키를 부팅 시 암호 입력으로 저장하거나(모드 2) 부팅 프로세스 도중 플로피 디스크에 저장하도록(모드 3) 랩톱을 구성하여 이러한 종류의 공격으로부터 보호할 수 있습니다. 하지만 이 두 방법 모두 부팅 프로세스 도중 컴퓨터와의 상호 작용이 필요하고 이 상호 작용은 자동화할 수 없으므로 자동화된 시스템 관리에 문제가 될 수 있기 때문에 귀찮은 작업일 수 있습니다. 하지만 오프라인 파일이 있는 컴퓨터에 EFS를 사용해야 한다면 이 방법 중 한 가지를 사용하여 캐시의 데이터를 보호해야 합니다. 일반적으로 부팅 시 암호(그림 1)를 사용할 것을 권장합니다. 랩톱 가방을 분실한 경우 대부분 디스크가 랩톱 안에 이미 있거나 가방 안에 함께 있는 경우가 많기 때문입니다.
Figure 1 Automate EFS operations
Figure 1 Automate EFS operations

EFS 사용
클라이언트에서 암호화할 대상을 결정했으면 다음 단계는 실제 암호화 작업을 수행하는 것입니다. 이 프로세스는 로그온 스크립트 또는 cipher.exe를 호출하여 암호화 작업을 수행하는 클라이언트 스크립트를 실행하는 다른 프로세스를 통해 처리할 수 있습니다. 앞에서 설명한 예에서처럼, 환경에 기존 독립 실행형 EFS 사용자가 있는 경우 이 사용자를 먼저 마이그레이션하는 것이 좋습니다.
이러한 독립 실행형 사용자를 마이그레이션하는 첫 번째 단계는 2007년 2월에 게시한 이 칼럼의 1부(microsoft.com/technet/technetmag/issues/2007/02/SecurityWatch)에서 설명한 것처럼 클라이언트 시스템에 관리되는 인증서를 제공하는 것입니다. 모든 시스템이 이 관리되는 인증서에 등록되었으면 /U 스위치와 함께 cipher를 실행하여 기존의 모든 파일을 새 암호화 및 복구 에이전트 키로 업데이트해야 합니다. 이 단계에서 SG-ComputersUsingEFS 그룹의 모든 시스템은 관리되는 방식으로 EFS를 사용하는데, 여기에는 중앙에서 발급되고 보관되었을 수 있는 키와 중앙에서 관리되는 복구 에이전트가 포함됩니다.
현재 EFS를 사용하고 있지 않은 사용자를 대상으로 EFS를 배포하려면 먼저 EFS 사용을 금지하는 그룹 정책을 제거해야 합니다. 이 작업이 완료되고 관리되는 인증서에 사용자가 등록되었으면 로그온 스크립트를 실행하여 앞에서 설명한 키 경로를 암호화할 수 있습니다. 다음은 간단한 스크립트 샘플입니다.
cipher /e /s /a "%userprofile%\My Documents"

cipher /e /s /a "%userprofile%\Application Data\Microsoft\Outlook"

cipher /e /s /a "%userprofile%\Desktop"
원하는 디렉터리에 EFS를 적용했으면 EFS 배포의 보안을 강화하기 위한 두 가지 추가적인 옵션의 설정을 고려해야 합니다. 이 두 옵션은 모두 메모리에서 디스크로 페이징되는 데이터와 관련됩니다. 각 시나리오에서 악의적인 사용자가 복구할 가능성이 있는 데이터의 양은 정상적 사용 도중 디스크로 페이징되었거나 메모리에 로드된 데이터로 제한됩니다. 즉, 사용자가 보지 않았기 때문에 메모리로 로드되지 않은 중요한 EFS 보호 데이터가 시스템에 있는 경우 해당 데이터는 이러한 공격 방식으로부터 위험하지 않다는 의미입니다.
페이지 파일은 Windows에서 가상 메모리로 사용되며(다른 운영 체제에서는 스왑 공간이라고도 함) 메모리 내 원시 데이터를 하드 드라이브에 일반 텍스트로 기록한 것입니다. 따라서 공격자가 페이지 파일을 복구할 수 있으면 분석 도구를 사용하여 이 파일에서 유용한 데이터를 추출해낼 가능성이 있기 때문에 EFS 보호 시스템에서 중요한 데이터가 위험해질 수 있습니다. Windows XP에서는 페이지 파일 자체를 암호화할 수 없기 때문에(Windows Vista에서는 암호화 가능) 가장 좋은 방법은 종료 시 Windows가 이를 삭제하도록 하는 것입니다. 그림 2에서처럼 그룹 정책을 통해 이렇게 할 수 있습니다.
Figure 2 Setting group policy
Figure 2 Setting group policy (더 작게 보려면 이미지를 클릭하십시오.)
Figure 2 Setting group policy
Figure 2 Setting group policy (더 크게 보려면 이미지를 클릭하십시오.)
이 설정의 단점은 특히 메모리의 양이 큰 시스템에서 시스템 종료에 걸리는 시간이 크게 늘어난다는 점입니다. 기본적으로 페이지 파일의 크기는 컴퓨터의 실제 메모리 양과 직접적인 관련이 있습니다. 페이지 파일을 지우려면 Windows가 종료 전에 디스크의 모든 페이지에 물리적 쓰기 작업을 해야 하기 때문입니다.
전원 관리 모드가 최대 절전 모드를 사용하도록 설정된 경우 Windows의 최대 절전 모드 파일에는 시스템의 실제 메모리의 덤프가 포함됩니다. 최대 절전 모드가 실행되면 Windows는 사용자가 작업을 재개할 때 컴퓨터를 이전과 동일한 상태로 복원할 수 있도록 하기 위해 실제 메모리의 전체 내용을 최대 절전 모드 파일의 디스크에 기록합니다. 페이지 파일과 마찬가지로 최대 절전 모드 파일은 Windows XP에서 암호화할 수 없습니다. 하지만 페이지 파일과 달리 최대 절전 모드는 GPO에서 직접 해제할 수 없습니다. 대신 /HIBERNATE 스위치와 함께 powercfg.exe를 호출하는 스크립트를 사용하여 최대 절전 모드를 해제하거나 다시 설정해야 합니다.
초기 암호화 및 구성 작업을 마친 뒤에는 배포에서 디스크의 느려진 공간(slack space)에 대한 정리를 고려해야 합니다. 이 프로세스는 매우 시간이 오래 걸리고 작업에 많은 영향을 미칠 수 있지만 높은 보안 환경에서 많은 보안 장점을 가집니다. 느려진 공간은 시스템에서 현재 활성화된 데이터가 포함되어 있지는 않지만 하드 디스크의 작동 방식 때문에 이전에 사용된 파일의 중요한 정보 조각이 포함되어 있을 수 있는 디스크 영역입니다. 즉, 파일 삭제 작업은 디스크에서 파일이 차지하고 있는 모든 섹터를 실제로 덮어쓰는 것이 아니라 파일 테이블의 포인터만 제거하기 때문에 삭제된 데이터가 계속 디스크에 남아 있을 수 있습니다. 이러한 경우 느려진 공간을 읽어서 파일을 재조합할 수 있는 도구를 사용하면 데이터를 복구하는 것이 가능합니다. 이러한 잔여 데이터를 안전하게 지우려면 cipher를 /W 스위치와 함께 실행하십시오. 이렇게 하면 cipher는 디스크에서 사용 가능한 것으로 표시된 모든 섹터를 반복적으로 덮어씁니다. 그 다음부터는 중요한 데이터에 대한 이후의 모든 파일 작업이 EFS로 보호되는 디렉터리에서만 수행된다면 이 명령을 주기적으로 실행할 필요는 없습니다.

EFS를 위한 Windows 탐색기 향상
기본적으로 파일 및 디렉터리에 대한 암호화 및 해독 옵션은 Windows 탐색기의 고급 속성 메뉴에서 잘 보이지 않습니다. 마우스 오른쪽 버튼을 클릭하면 나타나는 Windows 탐색기 상황에 맞는 메뉴에 "암호화" 및 "암호화 해제"를 표시하여 최종 사용자 환경을 향상시킬 수 있습니다. 또한 EFS로 보호된 파일과 디렉터리는 다른 파일과 다른 색(녹색)으로 표시되도록 Windows 탐색기를 구성할 수 있습니다. 이렇게 하면 사용자가 고급 속성 메뉴까지 들어가지 않고도 파일이나 디렉터리가 암호화되었는지 여부를 알 수 있습니다. 끝으로 파일이나 디렉터리에 액세스할 수 있는 사용자를 정의하는 옵션을 추가할 수 있습니다. 이 옵션을 사용 가능으로 설정하려면 reg.exe를 호출하는 스크립트를 통해 레지스트리를 다음과 같이 변경하십시오.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced]

"EncryptionContextMenu"=dword:00000001

"ShowCompColor"=dword:00000001

[HKEY_CLASSES_ROOT\*\Shell\Encrypt To User...\Command]
@="rundll32 efsadu.dll,AddUserToObject %1"

Windows Vista에서의 EFS
Windows Vista에서는 EFS가 크게 향상되어 보안이 강화되었음은 물론 배포와 관리도 더 쉬워졌습니다. 이러한 개선 사항 중 중요한 사항은 EFS 키의 스마트 카드 저장이 완전하게 지원된다는 점입니다. 이미 스마트 카드 로그온을 활용하고 있는 조직의 경우 같은 카드를 사용하여 사용자의 EFS 키를 저장할 수도 있기 때문에 특히 유용한 기능입니다. 스마트 카드 지원은 복구 에이전트 인증서로 확장할 수도 있으므로 중요한 DRA 인증서도 카드에 저장할 수 있습니다.
또한 Windows Vista에서는 Windows XP에서 불가능하거나 쉽게 구현할 수 없었던 항목의 암호화도 지원됩니다. Windows Vista에서는 페이지 파일을 암호화할 수 있기 때문에 "가상 메모리 페이지 파일 지움" 옵션을 설정할 필요가 없습니다. Windows Vista에서는 오프라인 파일이 전체적으로 다시 설계되었습니다. 더욱 사용자 친화적으로 바뀐 인터페이스와 크게 향상된 성능 및 안정성 이외에도 클라이언트 쪽 캐싱이 사용자 단위로 바뀌었기 때문에 SYSKEY 모드 2 또는 3을 사용할 필요 없이 캐시를 안전하게 암호화할 수 있습니다. 이 두 가지 중요 개선 사항 덕분에 오늘날 Windows XP 기반 환경에서의 중요한 배포 문제점이 해결되었습니다.
마지막으로, Windows Vista에서 관리자는 별도의 스크립트를 사용할 필요 없이 그룹 정책을 통해 Documents 폴더의 암호화를 직접 구성할 수 있습니다. 그림 3은 Windows Vista에서 GPO를 통해 사용할 수 있는 새로운 EFS 속성을 보여 줍니다.
Figure 3 EFS properties in Windows Vista
Figure 3 EFS properties in Windows Vista (더 작게 보려면 이미지를 클릭하십시오.)
Figure 3 EFS properties in Windows Vista
Figure 3 EFS properties in Windows Vista (더 크게 보려면 이미지를 클릭하십시오.)

요약
EFS는 Windows 관리자에게 모바일 데이터를 보호하기 위한 강력한 보안 옵션을 제공합니다. EFS는 확장성이 높고, 관리가 용이하며, 유연한 데이터 복구 메커니즘을 제공합니다. 또한 Windows Vista에서 EFS는 스마트 카드 기반 키 저장 지원, 보다 쉬운 관리와 배포를 위해 개선된 기능을 통해 더욱 향상되었습니다. 시스템을 물리적으로 분실한 경우에도 데이터를 보호하고자 하는 조직을 위해 EFS는 이미 기존 Windows 플랫폼의 일부인 저장 솔루션을 제공합니다.
추가 정보
이 칼럼에서 논의한 주제에 대한 자세한 내용은 다음 리소스를 참조하십시오.
  • 2007년 2월 Security Watch 칼럼
  • Windows XP 및 Windows Server 2003에서의 파일 시스템 암호화
  • SysKey 유틸리티를 사용한 Windows 보안 계정 관리자 데이터베이스의 보호

John Morello는 LSU를 수석으로 졸업했으며 지난 6년 동안 Microsoft에서 다양한 업무를 담당했습니다. 선임 컨설턴트로서 Fortune 100대 기업과 연방 민간 및 방어 클라이언트용 보안 솔루션을 설계하였으며, 현재는 Windows Server 그룹의 프로그램 관리자로 보안 및 원격 액세스 기술을 담당하고 있습니다.


 The Desktop Files: PsTools 입문서
The Desktop Files
PsTools 입문서
Wes Miller
이 기사의 코드 다운로드: MillerTheDesktopFiles2007_03.exe (150KB)

작년까지 필자가 근무했던 Winternals Software는 2006년 7월에 Microsoft에 인수되었습니다. Winternals는 상용 소프트웨어를 판매하는 회사였지만 공동 설립자 Mark Russinovich와 Bryce Cogswell은 다양한 도구를 프리웨어로 배포했던 Sysinternals라는 별도의 회사도 소유하고 있었습니다. Sysinternals에서 배포했던 프리웨어 응용 프로그램 중 몇 가지는 Winternals Administrator's Pak의 구성 요소로 포함되기도 했습니다.
뿐만 아니라 Mark와 Bryce는 일반적인 프리웨어 라이선스 조건을 벗어나는 방식으로 이러한 제품을 사용하고자 하는 회사에 사용권을 판매하기도 했습니다.
수많은 Sysinternals 라이브러리에서 필자가 가장 좋아하는 도구 중 하나인 PsTools 제품군은 현재 microsoft.com/technet/sysinternals/utilities/pstools.mspx에서 제공되고 있습니다. Mark는 UNIX 프로세스 열거 유틸리티인 ps의 이름을 따서 이 도구의 이름을 정했습니다. 이 도구의 다운로드 사이트에 언급되어 있듯이 Windows®에는 이 도구와 같은 기능을 일부 수행하는 기본 제공 명령줄 유틸리티가 있습니다. 그러나 PsTools 제품군은 중요한 고유 기능을 제공하며 로컬은 물론 원격 시스템이 제대로 구성되어 있을 경우 원격으로 사용할 수 있다는 큰 차이점이 있습니다. 게다가 원격으로 실행하는 방법은 로컬로 실행하는 방법만큼이나 간단합니다.
PsTools 제품군에는 그림 1에 나와 있는 몇 가지 개별 응용 프로그램이 포함되어 있습니다. 나머지 Sysinternals 유틸리티와 마찬가지로, 설치 관리자는 없으며 응용 프로그램만 제공됩니다. 따라서 원하는 경로에 넣고 바로 사용하면 됩니다.
Figure 1 PsTools 유틸리티 (Close Figure 1)

도구 | 설명
PsExec | 모든 사용자 컨텍스트에서 프로세스를 실행할 수 있도록 합니다.
PsFile | 시스템에서 원격으로 연 파일을 표시합니다.
PsGetSid | 컴퓨터 또는 사용자의 Windows SID(보안 식별자)를 표시합니다.
PsInfo | Windows 시스템에 대한 정보를 나열합니다.
PsKill | 이름 또는 프로세스 ID를 사용하여 프로세스를 중단합니다.
PsList | 실행 중인 프로세스에 대한 자세한 정보를 나열합니다.
PsLoggedOn | 로컬로 로그온한 사용자와 원격 리소스 공유 사용자를 모두 표시합니다.
PsLogList | Windows 이벤트 로그 레코드를 덤프합니다.
PsPasswd | 사용자 계정 암호를 변경합니다.
PsService | Windows 서비스를 확인 및 제어합니다.
PsShutdown | 컴퓨터를 종료, 다시 부팅, 최대 절전 모드로 전환 또는 일시 중단합니다.
PsSuspend | 실행 중인 프로세스를 일시 중단합니다.
지금쯤 이 기능 중 일부(특히 PsLogList)를 WMI(Windows Management Instrumentation)와 일부 복잡한 스크립팅을 통해 구현할 수 있다는 사실을 눈치챈 독자들도 있을 것입니다. 그러나 PsTools 제품군의 가장 큰 특징은 각 유틸리티별로 특정 작업을 쉽고 간단하게 수행하도록 설계되었다는 점입니다.
이 칼럼에서는 각 도구에 대해 설명하고 용도와 사용 방법을 보여 주는 간단한 예를 살펴보겠습니다. 그 전에 먼저 이 도구 자체의 작동 방식을 소개하고 작동에 필요한 필수 구성 요소에 대해 알아보겠습니다.

도구의 작동 방식
모든 도구는 일반적으로 같은 방식으로 작동합니다. 즉, 호스트 시스템에서 원하는 PsTool을 실행하면 됩니다. 대부분의 도구를 로컬로 실행할 수도 있지만 일반적으로 원격 시스템에 대해 실행하거나 동시에 여러 시스템에 대해 실행할 때 최상의 성능을 얻을 수 있습니다단, PsExec는 예외로, 이에 대해서는 아래 예에서 설명하겠습니다. 이 유틸리티는 사용자가 제공한 명령줄 인수를 사용하여 원격 시스템에서 %SystemRoot%(Windows 디렉터리)에 해당하는 원격 시스템의 관리 공유에 자신을 복사합니다.
원격 디렉터리로 복사된 응용 프로그램은 자동으로 실행되어 Windows 서비스를 설치합니다. 이 Windows 서비스는 실행 시에 사용자가 제공한 자격 증명을 사용하여 요청한 작업을 수행합니다. 특정 도구에서 클라이언트 시스템의 최종 사용자 UI가 필요한 경우 이 서비스는 사용자의 컨텍스트에서 추가 바이너리를 실행합니다.서비스는 대화형 UI를 직접 표시할 수 없다는 데 주의하십시오. 그리고 이 서비스를 실행한 콘솔로 필요한 정보를 전송합니다. 마지막으로 서비스가 자동으로 제거됩니다.
지금까지 설명한 내용에서 알 수 있듯이 이 도구는 강력하고 독립적으로 실행됩니다. 여러 가지 바이너리와 프로세스가 필요하지만 원하는 도구를 실행하기만 하면 자동으로 처리되므로 사용자는 바이너리나 프로세스에 대해 신경 쓰지 않아도 됩니다.
이 도구를 사용하기 위해서는 Windows NT®, Windows 2000, Windows XP 또는 Windows Server® 2003(x86 또는 x64 버전의 Windows는 지원되지만 Itanium 버전은 지원되지 않음), 도구를 실행하는 원격 시스템에 설정된 기본 관리 네트워크 공유(admin$), 원격 시스템에서 파일 및 프린터 공유에 사용할 수 있도록 열려 있는 포트(Windows 방화벽, 인터넷 연결 방화벽 또는 기타 방화벽 제품 중 어떤 것을 사용하는지에 관계없음) 등의 필수 구성 요소가 필요합니다.

PsExec
PsExec은 이 유틸리티에 포함된 도구 중 필자가 개인적으로 가장 좋아하는 도구입니다. 아마 그 이유는 독자 여러분이 생각하는 이유와는 다를 것입니다. 2년 동안 필자는 시스템에서 "관리자가 아닌 사용자", 즉 Administrator 그룹이 아닌 User 그룹의 계정으로 도구를 실행한 적이 많았습니다. 대신 run.vbs라는 짧은 스크립트를 사용하여 로컬 Administrator로 응용 프로그램을 실행할 수 있었습니다. 이렇게 하면 다른 사용자처럼 간단하게 실행할 수 있습니다. 그림 2에서는 이 스크립트의 내용을 보여 줍니다. 또한 TechNet Magazine 사이트(technetmagazine.com/code07.aspx)에서도 이 스크립트의 내용을 볼 수 있습니다. 이 스크립트는 Path 시스템 변수에 PsTools가 들어 있다는 전제 하에 작성되었습니다.
Figure 2 Run.vbs (Close Figure 2)
SET WshShell = WScript.CreateObject("WScript.Shell")
SET WshSysEnv = WshShell.Environment("SYSTEM")
SET FSO = CreateObject("Scripting.FileSystemObject")
IF WScript.Arguments.Count <> 0 Then
    FOR EACH arg IN WScript.Arguments
        iArgCount = iArgCount + 1
        strCmdArg = (arg)
        strCmdArray = Split(strCmdArg, " ", 2, 1)
        IF iArgCount = 1 THEN
        strExe = strCmdArray(0)
        ELSEIF iArgCount = 2 THEN
        strRun = strCmdArray(0)
        ELSE
        strParams = strParams&" "&strCmdArray(0)
        END IF
    NEXT
END IF
'/t:0A && title ***** Admin *****
        strExt = LCase(Right(strExe, 3))

IF strExt <> "exe" AND strExt <> "bat" AND strExt <> "cmd" THEN
WshShell.Run "psexec.exe -d -i -e -u COMPUTERNAME\USER -p PASSWORD  cmd /c start "&strExe&"
    "&strRun&" "&strParams, 0, FALSE
ELSE
WshShell.Run "psexec.exe -d -i -e -u COMPUTERNAME\USER -p PASSWORD "&strExe&" "&strRun&"
    "&strParams, 0, FALSE
END IF

    SET WshShell = NOTHING
    SET WshSysEnv = NOTHING
    SET FSO = NOTHING
이 간단한 스크립트는 Winternals에서 Protection Manager 제품을 개발할 때 Mark가 추가한 기능을 사용하여 PsExec를 이용한 예입니다. 이 추가 기능은 제한된 사용자가 PsExec을 로컬로 실행할 수 있도록 보다 권한이 확장된 자격 증명을 제공합니다. 물론 보다 일반적인 PsExec의 용도는 원격 실행입니다. 예를 들어 원격 실행, 스크립팅 또는 자동화 프레임워크를 자체적으로 제공하지 않는 유틸리티를 원격으로 실행하는 것입니다. PsExec의 두 가지 핵심 기능은 실행할 원격 시스템에 바이너리를 복사하는 것과 프로세서 선호도를 제어하는 것입니다. 이외에도 하나의 스크립트 파일을 제공하여 여러 시스템에 대해 동시에 스크립트를 작성하는 기능도 매우 유용합니다.
다음은 PsExec의 간단한 사용 예입니다.
PsExec \\computer -u username -p password command
이 코드는 그림 3에 나와 있는 스위치를 사용하여 확장할 수 있습니다.
Figure 3 PsExec 스위치 (Close Figure 3)

스위치 | 설명
-a | 프로세서 선호도를 지정합니다.
-c | 원격 시스템에 응용 프로그램을 복사할지 여부를 나타냅니다.
-d | 프로세스가 끝나기를 기다리지 않고 바로 끝내도록 지정합니다. 성공 또는 오류 메시지가 표시되는 동안 기다리지 않습니다.
-e | 지정한 계정의 프로필을 사용하여 로드합니다.
-f | 원격 시스템에 있는 경우에도 응용 프로그램을 복사합니다. 현재(또는 특정) 버전을 실행 중인지 확인합니다.
-i | 원격 시스템에서 응용 프로그램을 대화형으로 실행합니다. 응용 프로그램에서 최종 사용자에게 사용자 인터페이스를 표시하려는 경우에 필요합니다.
-l | 제한된 사용자로 응용 프로그램을 실행합니다. Administrators 그룹 토큰과 프로세스 권한을 제거하여 Users 그룹의 구성원이 실행할 수 있도록 합니다. 위험이 큰 인터넷 연결 응용 프로그램을 최소한의 권한으로 실행하는 데 유용합니다.
-n | 원격 컴퓨터에 대한 연결 오류를 발생시키기 전에 기다리는 제한 시간을 지정합니다.
-priority | 지정한 우선 순위로 프로세스를 실행합니다. 즉, Windows에서 해당 작업의 처리 우선 순위(-low, -belownormal, -abovenormal, -high 또는 -realtime )를 어떻게 설정해야 할지를 지정합니다.
-s | System 계정을 사용하여 프로세스를 실행합니다. Regedit를 실행하여 사용 권한이 지정된 레지스트리 키에 액세스하는 데 유용합니다.
-v | 복사하려는 응용 프로그램이 최신인 경우에만 복사합니다.
-x | Winlogon 보안 데스크톱에 UI를 표시합니다. 로컬 시스템에 대해서만 작동합니다.
@file | 텍스트 파일에 지정된 모든 컴퓨터에 대해 명령을 실행합니다.

PsFile
PsFile은 PsExec보다 용도가 한정된 도구입니다. 특히 원격 시스템에 열려 있는 파일과 해당 파일을 연 사용자를 확인하는 데 주로 사용됩니다. 이러한 기능은 서버를 다시 부팅하기 전에 열려 있는 파일을 추적하려는 경우에 유용합니다. 또한 파일을 편집하거나 삭제하지 못하도록 잠근 사용자를 파악하여 수동으로 알리거나 PsFile을 통해 해당 파일을 닫을 수 있습니다. PsFile의 사용 예는 다음과 같습니다.
PsFile \\computer -u username -p password
이 코드를 실행하면 원격 시스템에 열려 있는 파일 핸들이 반환됩니다. 일반적인 사용 방법 외에도 문에 Id 매개 변수를 추가하여 관련 정보를 찾거나 닫으려는 파일의 이름을 지정할 수도 있습니다. 뿐만 아니라 Id 매개 변수로 지정한 파일을 닫는 -c 스위치를 추가할 수도 있습니다.

PsGetSid
PsGetSid도 용도가 매우 한정된 도구로 컴퓨터, 사용자 또는 그룹의 SID(보안 식별자)를 알려 줍니다. 이러한 기능은 도메인의 시스템 SID가 중복되지 않았는지 확인하거나 단순히 시스템의 모든 사용자 또는 그룹의 SID를 확인하려는 경우에 유용합니다. PsGetSid의 사용 예는 다음과 같습니다.
PsGetSid \\computer -u username -p password account
여기서 account는 사용자, 컴퓨터 또는 그룹을 나타냅니다. PSGetSid의 구문 자체는 간단하지만 몇 가지 추가 매개 변수를 사용할 수 있습니다. 그 중 SID 매개 변수는 SID가 지정된 계정(그룹 또는 컴퓨터)을 나타내고 @file은 지정된 텍스트 파일에 나열되어 있는 모든 컴퓨터에 대해 명령을 실행합니다.

PsInfo
PsInfo는 자세한 시스템 정보를 제공하는 데 사용됩니다. 이 도구는 여러 원격 시스템에 대해 출력 내용을 파일(Excel® 및 데이터베이스에 사용 가능한 CSV 파일 등)로 전송하도록 스크립트를 작성한 경우 특히 유용합니다. 이 유틸리티는 대부분의 도구와는 다른 중요한 개념을 기반으로 작동합니다. 즉, 컴퓨터 이름을 제공하지 않으면 PsInfo는 기본적으로 도메인의 모든 컴퓨터에 쿼리합니다. PsInfo의 사용 예는 다음과 같습니다.
PsInfo  \\computer -u username -p password
구문 자체는 간단하지만 그림 4와 같은 추가 스위치와 매개 변수를 사용할 수 있습니다.
Figure 4 PsInfo 스위치 (Close Figure 4)

스위치 | 설명
-h | 모든 Windows 업데이트를 표시합니다.
-s | 시스템에 설치된 모든 응용 프로그램을 표시합니다.
-d | 시스템의 디스크/볼륨 정보를 표시합니다.
-c | 결과를 CSV 형식으로 출력합니다.
-t | CSV 파일의 구분 기호를 기본값(\t)과 다르게 지정합니다.
Filter | 지정한 필터에 해당하는 데이터만 표시합니다.
@file | 지정된 텍스트 파일에 나열된 모든 컴퓨터에 대해 명령을 실행합니다.

PsKill
PsKill은 로컬 시스템 또는 원격 시스템에서 프로세스를 종료하는 뛰어난 유틸리티입니다. 매우 간단한 사용 방법으로, 프로세스뿐만 아니라 모든 관련 하위 프로세스까지 종료할 수 있습니다. PsKill의 사용 방법은 앞서 설명한 다른 도구와 매우 유사합니다.
PsKill -t \\computer -u username -p password process id | process name
종료하려는 프로세스 id 또는 프로세스 이름을 지정할 수 있습니다.

PsList
필자는 개인적으로 Process Explorer를 선호하기 때문에 PsList는 잘 사용하지 않습니다. Process Explorer에 대한 자세한 내용은 microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx를 참조하십시오. 하지만 원격 실행이 가능한 Process Explorer 버전이 없는 관계로, Process Explorer에서 제공되는 주요 기능 중 몇 가지에 대해 PsList를 사용하게 되었습니다. 사실 PsList는 원격 시스템에서 실행되는 하나 이상의 프로세스에 대한 원격 목록이라고 할 수 있습니다.
PsList의 사용 방법은 매우 간단합니다.
PsList \\computer -u username -p password account
다른 도구와 마찬가지로 account 매개 변수는 사용자, 컴퓨터 또는 그룹을 나타냅니다. 이 외의 추가 매개 변수는 그림 5에 나와 있습니다.
Figure 5 PsList 스위치 (Close Figure 5)

스위치 | 설명
-t | 스레드 수준에서 정보를 표시합니다.
-m | 각 프로세스의 자세한 메모리 정보를 제공합니다.
-x | 프로세스, 메모리 및 스레드 정보를 표시합니다.
-t | 정보를 Process Explorer의 트리 뷰와 유사한 프로세스 트리로 표시합니다.
-s [n] | 지정한 시간(초) 동안 작업 관리자 모드로 실행합니다. 이 경우 원격 프로세스 정보를 실시간에 가깝게 표시할 수 있습니다.
-r [n] | 작업 관리자 모드로 실행할 때 새로 고치는 간격(초)을 지정합니다.
name | 지정한 이름으로 시작하는 프로세스에 대한 정보를 표시합니다.
-e | 이름이 정확히 일치하는 프로세스에 대해 실행합니다.
pid | 지정한 프로세스에 대한 정보를 표시합니다.
PsList는 강력한 기능을 제공하면서도 사용이 간편하며, 원격 데스크톱을 사용하지 않고도 원격 프로세스를 자세히 파악할 수 있도록 하는 도구입니다. 이러한 정보를 바탕으로 제어해야 할 프로세스가 있는 경우 PsKill 또는 PsSuspend를 실행할 수 있습니다.

PsLoggedOn
PsLoggedOn은 명료성을 전제로 개발된 유틸리티로, 시스템에 로그온한 사용자를 보여 줍니다. 여기에는 로컬(대화형) 로그온과 네트워크 공유 로그온이 모두 포함됩니다. PsFile과 마찬가지로 이 기능은 유지 관리 작업을 수행할 서버를 사용 중인 사용자를 확인하는 데 유용합니다. 이 유틸리티의 사용 방법은 매우 간단합니다.
PsLoggedOn \\computer
PsLoggedOn에 사용할 수 있는 선택 매개 변수는 두 가지뿐입니다. -l은 로컬 로그온만 표시(네트워크 로그온은 표시하지 않음)하고 -x는 로그온 시간을 제외합니다.
기초적이긴 하지만 PsLoggedOn은 보통 한 두 가지 Windows 위치를 조사해야 알 수 있는 정보를 쉽게 확인할 수 있도록 합니다.

PsLogList
일반적으로 가장 많이 사용되는 유틸리티 중 하나인 PsLogList는 Windows 이벤트 로그를 로그 판독기, 데이터베이스 등에 사용할 수 있는 텍스트 형식으로 덤프하는 도구입니다. 이 도구의 가장 큰 이점은 이벤트 로그 항목을 이진 형식에서 쉽게 변환 및 자동화할 수 있는 형식으로 변환한다는 점입니다. 물론 Windows Vista™에서 이벤트 로그는 기본적으로 XML로 제공되지만 이는 별개의 사항입니다.
PsLogList의 사용 예는 다음과 같습니다.
PsLogList \\computer -u username -p password
그림 6과 같은 다양한 추가 스위치와 매개 변수를 사용할 수 있습니다.
Figure 6 PsLogList 스위치 (Close Figure 6)

스위치 | 설명
-a | 지정한 날짜 이후에 발생한 이벤트만 덤프합니다.
-b | 지정한 날짜 이전에 발생한 이벤트만 덤프합니다.
-c | 자세한 출력을 덤프한 후 이벤트 로그를 영구적으로 지웁니다.
-d | 지정한 일수에 대한 정보만 표시합니다.
-e | 지정한 이벤트 ID(최대 10개까지 지정 가능)에 해당하는 이벤트를 제외합니다.
-f | 이벤트 유형(경고, 오류 등)을 필터링합니다.
-g | 이벤트 로그를 EVT 파일로 내보냅니다. -c 스위치가 필요합니다.
-h | 지정한 시간(시) 동안에 대한 정보만 표시합니다.
-l | 지정한 EVT 파일에서 덤프합니다.
-m | 지정한 시간(분) 동안에 대한 정보만 표시합니다.
-n | 지정한 일수에 대한 정보만 표시합니다.
-o | 지정한 원본의 이벤트만 표시합니다(예: Windows 시스템 복원 서비스의 경우 -o SRService).
-q | 지정한 소스의 이벤트를 제외합니다(-o와는 반대의 기능).
-r | 로그 이벤트 덤프 순서를 역순(가장 오래된 항목에서 가장 최신 항목순)으로 바꿉니다.
-s | 각 줄의 구분된 필드에 레코드를 나열합니다.
-t | -s 출력에 사용할 구분 기호를 쉼표 이외의 기호로 지정합니다.
-w | 새 이벤트가 채워지고 실시간으로 덤프될 때까지 기다립니다. 이 스위치는 로컬 시스템에 대해서만 사용할 수 있습니다.
-x | 이벤트 로그에서 확장된 데이터를 덤프합니다.
eventlog | 덤프할 이벤트 로그를 지정합니다. 기본값은 System입니다.
@file | 텍스트 파일에 지정된 모든 컴퓨터에 대해 명령을 실행합니다.
Windows 이벤트 로그는 매우 강력한 진단 도구가 될 수 있지만 데이터를 조작 및 통합할 수 있는 곳으로 가져오는 것이 가장 큰 문제입니다. PsLogList는 이러한 문제를 해결합니다.

PsPasswd
PsPasswd는 간단하지만 강력한 유틸리티로, Net.exe와 동일한 기능을 원격 실행 및 자동화가 가능한 방식으로 제공합니다.
PsPasswd  \\computer -u username -p password Username Newpassword
컴퓨터를 지정하거나 지정하지 않을 수 있으며(로컬 시스템), 컴퓨터를 \\*로 지정하면 현재 도메인의 모든 컴퓨터에 대해 유틸리티가 실행됩니다. PsPasswd에 사용할 수 있는 매개 변수는 텍스트 파일에 지정된 모든 컴퓨터에 대해 명령을 실행하는 @file뿐입니다. 이 유틸리티도 간단하지만 강력한 다중 시스템 기능을 제공합니다.

PsService
PsService를 사용하면 네트워크에 있는 하나 이상의 시스템에 대해 SCM(서비스 제어 관리자) 정보를 확인하고 편집할 수 있도록 했으며 네트워크의 시스템에서 지정한 서비스 이름을 검색할 수도 있습니다.
PsService \\computer -u username -p password command options
PsService를 실행할 때는 그림 7에 있는 명령 중 하나가 사용되며 옵션에 따라 해당 명령에 적용할 특성이 지정됩니다. 추가 명령 스위치를 제공하지 않으면 PsService는 SCM 정보의 전체 덤프를 제공합니다.
Figure 7 PsService 명령 (Close Figure 7)

명령 | 설명
query | 지정한 서비스를 쿼리합니다.
config | 지정한 서비스의 구성 정보를 쿼리합니다.
setconfig | 지정한 서비스의 구성 정보를 설정합니다.
start | 서비스를 실행합니다.
stop | 서비스를 중지합니다.
restart | 서비스를 중지하고 다시 시작합니다.
pause | 서비스를 일시 중지합니다.
cont | 일시 중지된 서비스를 다시 시작합니다.
depend | 지정한 서비스에 종속된 서비스를 표시합니다.
find | 네트워크에서 서비스의 지정한 인스턴스를 찾습니다.
security | 지정한 서비스에 대한 보안 정보를 제공합니다.
PsService는 강력하고 원격 실행이 가능한 Services.msc의 명령줄 버전으로 생각할 수 있지만 네트워크에서 서비스(특히 위험성이 있는 서비스)를 조회하고 구성 정보를 설정하는 데도 사용할 수 있습니다.

PsShutdown
PsShutdown도 필자가 가장 선호하는 유틸리티 중 하나입니다. Microsoft에서도 이 작업을 처리하는 도구(shutdown.exe)를 제공하지 않느냐고 반문하는 사람도 있겠지만, 사실 두 도구는 다릅니다. 가장 큰 차이점은 바로 PsShutdown을 사용하면 원격 시스템을 종료하거나 다시 시작할 수 있다는 것입니다. 이외에도 대기 모드나 최대 절전 모드로 전환하고 시스템을 잠그며 사용자에게 일정 시간 동안 메시지를 표시한 후 시스템을 다시 시작하는 기능도 제공합니다.
PsShutdown \\computer -u username -p password
PsShutdown에는 그림 8과 같은 다양한 추가 매개 변수를 사용할 수 있습니다.
Figure 8 PsShutdown 스위치 (Close Figure 8)

스위치 | 설명
-a | PsShutdown에 의해 시작되어 이미 진행 중인 종료 프로세스를 중단합니다.
-c | 대화형 사용자가 종료 프로세스를 중단할 수 있도록 합니다.
-d | 컴퓨터를 일시 중단(대기 모드)합니다.
-e | 종료 원인 코드를 표시합니다. PsShutdown 및 기본 제공 shutdown.exe와 함께 사용하면 문제가 발생할 수 있기 때문에 Microsoft 웹 사이트에서 자세한 내용을 참조하는 것이 좋습니다. 자세한 내용은 msdn2.microsoft.com/en-us/library/aa376885.aspx를 참조하십시오.
-f | 실행 중인 모든 응용 프로그램을 강제 종료합니다.
-h | 컴퓨터를 최대 절전 모드로 전환합니다.
-k | 컴퓨터의 전원을 끕니다(전원 끄기가 지원되지 않는 경우 다시 부팅).
-l | 컴퓨터를 잠급니다.
-m | 모든 대화형 사용자에게 메시지를 표시하도록 지정합니다.
-n | 원격 컴퓨터에 대한 연결 오류를 발생시키기 전에 기다리는 제한 시간을 지정합니다.
-o | 콘솔 사용자를 로그오프합니다.
-r | 컴퓨터를 다시 부팅합니다.
-s | 컴퓨터를 종료하지만 전원은 끄지 않습니다.
-t | 종료 명령을 실행하기까지 대기하는 시간 또는 전원을 끄는 특정 시간을 지정합니다.
-v | 종료할 때까지 사용자에게 메시지를 표시합니다.
@file | 텍스트 파일에 지정된 모든 컴퓨터에 대해 명령을 실행합니다.
PsShutdown은 매우 강력하고 자유롭게 구성할 수 있으면서도 비교적 사용이 간편한 시스템 성능 제어 유틸리티입니다.

PsSuspend
PsSuspend는 데이터 또는 응용 프로그램 컨텍스트를 잃지 않으면서 불량 프로세스를 일시적으로 제어하거나 CPU 사용률이 높은 프로세스를 일시적으로 종료하려는 경우에 유용하게 사용할 수 있는 유틸리티입니다.
PsSuspend \\computer -u username -p password process ID
PsList를 사용하면 프로세스 ID를 가져올 수 있습니다. 프로세스를 일시 중단한 후에는 -r 스위치를 사용하여 다시 시작할 수 있습니다. 프로세스 일시 중단 및 다시 시작 작업은 Process Explorer로도 구현할 수 있지만 이 경우 로컬로만 작동합니다. 하지만 PsSuspend는 로컬뿐 아니라 원격으로도 프로세스를 일시 중단하고 다시 시작할 수 있으므로 Process Explorer의 기본 구현 기능을 능가하는 성능을 제공합니다.

결론
필자는 PsTools 제품군이 매우 유용한 유틸리티 모음이라고 생각합니다. PsTools는 나머지 Sysinternals 유틸리티(Regmon, Filemon, Process Explorer 및 새로 추가된 Process Monitor)와 함께 필자가 시스템에 Windows를 다시 설치할 때 가장 먼저 설치하는 프로그램 중 하나입니다. 이 칼럼이 PsTools에 익숙해지는 계기가 되고, 이미 익숙한 사용자라면 도구에 대해 몇 가지 추가 정보를 얻는 기회가 되기를 바랍니다. 이 도구를 수년간 무료로 제공하고 이 칼럼을 쓰는 데 도움을 준 Mark Russinovich에 감사를 전합니다.

Wes Miller는 텍사스 오스틴에 있는 Pluck(www.pluck.com)의 개발 관리자입니다. 이전에는 오스틴에 있는 Winternals Software에서 근무했으며 Microsoft에서 프로그램 관리자 및 Windows 제품 관리자로도 근무한 경력이 있습니다. 문의 사항이 있으신 분은 technet@getwired.com으로 연락하시기 바랍니다.


 Inside Microsoft.com: 데이터베이스 미러링 시작하기
Inside Microsoft.com
데이터베이스 미러링 시작하기
Saleem Hakani

데이터베이스가 오프라인이 되면 난처한 상황이 발생할 것입니다. 그러나 SP1이 설치된 SQL Server 2005의 데이터베이스 미러링 기능을 사용하면 재난을 미연에 방지할 수 있습니다. 이 새로운 고가용성 기술은 프로덕션 데이터베이스 서버를 사용할 수 없게 되었을 때 이를 대체하여 사용할 수 있도록 데이터베이스를 상시 대기 상태로 유지합니다.
데이터베이스 미러링 기능은 데이터베이스의 트랜잭션 로그 기록을 주 서버에서 보조 서버로 전송하는 방식으로 작동하며, 여기에서 보조 서버는 상시 대기 서버 역할을 합니다. 데이터베이스 미러링에서는 SQL Server™ 업데이트의 작동 방식과 마찬가지로 데이터 변경 내용을 트랜잭션 로그에 기록한 후 실제 데이터 페이지에 적용합니다. 로그 기록은 먼저 메모리에 있는 주 데이터베이스의 로그 버퍼에 저장된 다음 디스크에 영구적으로 저장됩니다. 그리고 트랜잭션 로그는 미러 서버의 데이터베이스에 복사 및 적용됩니다. 이렇게 하면 주 데이터베이스의 변경 내용이 미러 데이터베이스에 복제됩니다. 주 데이터베이스만 클라이언트 연결에 액세스할 수 있음을 유의하십시오. 클라이언트에서 요청한 변경 내용을 주 데이터베이스에서 수신하면 주 서버는 이 활성 변경 내용을 미러 서버에 보내게 됩니다. 이 과정에서 미러 서버는 변경 내용에 대해 어떠한 결정도 내리지 않습니다. 데이터베이스 미러링을 사용하고 있을 때 주 데이터베이스에 오류가 발생하면 미러링된 데이터베이스가 작동합니다.

데이터베이스 미러링의 메커니즘
데이터베이스 미러링은 SQL Server 2005를 지원하는 모든 표준 하드웨어에서 작동하며 데이터베이스 오류가 발생하더라도 데이터가 손실되지 않도록 합니다. 미러 데이터베이스는 주 데이터베이스 서버에서 처리되고 있는 현재 트랜잭션을 통해 항상 업데이트됩니다. 그림 1은 데이터의 흐름을 보여 줍니다.
주 서버가 다운되더라도 마지막 트랜잭션이 커밋된 시점과 정확히 일치하는 시점의 주 데이터베이스 사본이 미러 서버에 있으므로 안심할 수 있습니다. 따라서 미러 서버는 항상 주 서버 역할을 대신 수행할 수 있는 준비가 되어 있는 것입니다.
Figure 1 Data replication to the mirror
Figure 1 Data replication to the mirror (더 작게 보려면 이미지를 클릭하십시오.)
Figure 1 Data replication to the mirror
Figure 1 Data replication to the mirror (더 크게 보려면 이미지를 클릭하십시오.)
데이터베이스 미러링 토폴로지에서 주 서버와 미러 서버 간의 자동 장애 조치를 사용하려면 미러링 모니터 서버라는 세 번째 서버가 필요합니다. SQL Server 2005를 지원하는 모든 컴퓨터는 미러링 모니터 서버가 될 수 있습니다.

운영 모드
사용하게 될 데이터베이스 미러링 토폴로지는 선택한 트랜잭션 안정성 및 운영 모드에 따라 달라집니다. 데이터베이스 미러링에서 지원되는 운영 모드에는 보호 우선 모드(자동 장애 조치 포함 또는 제외)와 성능 우선 모드가 있습니다.
자동 장애 조치가 있는 보호 우선 모드는 미러 데이터베이스로의 동기 데이터 전송 및 자동 장애 조치를 수행하여 데이터베이스 가용성을 최대로 유지하도록 지원합니다. 이 운영 모드는 주 서버와 미러 서버 간의 통신 상태가 빠르고 안정적이면서 단일 데이터베이스에 대한 자동 장애 조치가 필요한 경우에 적합합니다. 이 모드에서 주 데이터베이스는 미러 서버에서 트랜잭션의 로그를 디스크에 기록했음을 알리는 미러 서버의 메시지를 수신할 때까지 기다린 후 트랜잭션을 커밋합니다.
자동 장애 조치가 없는 보호 우선 모드는 자동 장애 조치를 사용하지 않고 미러 데이터베이스로의 동기 데이터 전송을 수행하여 데이터베이스 가용성을 최대로 유지하도록 지원합니다. 이 모드에서는 미러 서버 인스턴스를 사용할 수 없게 되어도 주 서버 인스턴스가 계속해서 작동하기는 하지만 데이터를 미러링하지는 못합니다. 주 서버가 다운되면 데이터베이스 미러링이 중지되지만 서비스를 수동으로 장애 조치할 수는 있습니다.
성능 우선 운영 모드에서는 데이터가 비동기적으로 전송됩니다. 위의 두 모드와는 달리 주 서버는 미러 서버의 승인을 기다리지 않습니다. 미러 서버는 최대한 주 서버와 동일한 상태를 유지하려고 시도하지만 특정 시점에서 주 서버의 최신 트랜잭션이 미러 서버의 트랜잭션 로그에 기록되어 있지 않을 수 있습니다. 주 서버가 다운되면 데이터베이스 미러링이 중지되지만 서비스를 수동으로 장애 조치할 수는 있습니다.

기반 구축
최선의 방법을 사용하여 강력한 기반을 마련하면 데이터베이스 미러링을 간편하게 설정할 수 있습니다.
서버 버전 주 서버와 미러 서버가 동일한 버전의 SQL Server 2005에서 실행되고 있는지 확인해야 합니다. Standard 또는 Enterprise Edition을 사용할 수 있습니다.
미러링 모니터 서버 가용성 자동 장애 조치가 있는 보호 우선 모드를 사용하려면 미러링 모니터 서버가 있어야 하고 SQL Server 2005(모든 버전 사용 가능)가 설치되어 있어야 합니다. 미러링 모니터 서버는 SQL Server 2005를 지원할 수 있는 모든 안정적인 컴퓨터 시스템에서 실행할 수 있습니다.
미러 이미지 미러 서버 인스턴스의 작업, 로그인, SQL Server Integration Service(SSIS) 패키지, 디스크 파티션, 파일 위치 및 서버 구성이 주 서버 인스턴스와 동일한지 확인합니다. 미러 서버를 주 서버와 완전히 동일하게 구성하면 미러 서버가 주 서버와 동일하게 작동합니다.
전체 복구 데이터베이스 미러링에 참여하는 모든 데이터베이스는 전체 복구 모델로 설정해야 합니다.
Master 및 TempDB 미러링 토폴로지에 속한 모든 서버 인스턴스에서 동일한 Master 및 TempDB 데이터 정렬 및 코드 페이지를 사용하는지 확인합니다. 다른 데이터 정렬 및 코드 페이지를 사용하게 되면 데이터베이스 미러링 설정 중에 문제가 발생할 수 있습니다.
백업 미러링할 데이터베이스의 용량이 큰 경우에는 먼저 데이터베이스를 전체 백업한 다음 NORECOVERY 옵션을 사용하여 미러 서버 인스턴스에서 복원해야 합니다.
사전 계획 서버 이름, 포트 번호, 보안 계정 및 데이터베이스의 위치를 모두 결정한 다음 문서로 작성합니다. 검사 목록은 "데이터베이스 미러링 모범 사례" 추가 기사를 참조하십시오.
기반이 마련되었으면 이제 환경에 데이터베이스 미러링을 설정할 차례입니다.
데이터베이스 미러링 모범 사례
  1. 동일한 CPU, 메모리, 스토리지 및 네트워크 용량을 가진 파트너 서버를 사용합니다.
  2. 파트너 서버에는 동일한 SQL Server 및 OS 버전, 서비스 팩 및 업데이트를 설치해야 합니다.
  3. 주 서버 인스턴스 및 미러 서버 인스턴스에서 동일한 디렉터리 및 드라이브 구조로 SQL Server를 설치합니다.
  4. 성능이 문제가 되는 경우에는 전용 네트워크 인터페이스 카드를 사용하여 부하를 분산시킬 수 있습니다.
  5. 서버 파트너와 마찬가지로 주 서버 인스턴스 및 미러 서버 인스턴스에도 동일한 CPU, 메모리, 스토리지 및 네트워크 용량을 사용해야 합니다. 두 서버의 디렉터리 구조, 디스크 분할 스키마 및 SQL Server 구성이 동일하면 미러 파트너로의 장애 조치를 수행하는 도중이나 이후에 이들 요소에 대한 변경 작업을 수행하지 않아도 됩니다.
  6. 모든 응용 프로그램에서 연결이 가능하고 모든 필요한 작업을 실행할 수 있는지 확인한 다음 주 서버 인스턴스의 모든 활성 SQL Server 로그인(및 사용 권한)이 미러 서버 인스턴스에도 있는지 확인합니다. 이 작업은 SQL Server 2005 Integration Services의 로그인 전송 작업을 통해 수행할 수 있습니다.
  7. SQL Server 에이전트 작업, 경고, SSIS 패키지, 지원 데이터베이스, 링크된 서버 정의, 백업 장치, 유지 관리 계획, 데이터베이스 메일 프로파일 등을 주 서버에서 미러 서버로 복사합니다.
  8. 주 서버에서 수정 작업(예: 하드웨어, 소프트웨어, SQL Server 설정 또는 데이터베이스 개체에 대한 변경)을 수행할 때마다 자동으로 반복 또는 복제하여 해당 변경 내용을 미러 서버 인스턴스에 전송하는 절차를 수립합니다.
  9. 실제로 사용하기 전에 장애 조치 테스트를 여러 차례 수행합니다.

설정
이제 자동 장애 조치가 있는 보호 우선 운영 모드를 사용하여 데이터베이스 미러링을 설정하는 방법을 알아보겠습니다. 앞에서 말한 대로 이 경우에는 미러링 모니터 서버 인스턴스가 필요합니다. 이 문서의 예에서는 그림 2와 같이 각 서버의 역할을 나타내는 서버 및 데이터베이스 이름을 사용합니다.
보류 중인 트랜잭션 로그를 주 서버에서 미러 서버로 복사하는 경우처럼 구성이 성능에 영향을 미칠 수 있으므로, 사용량이 적은 시간에 데이터베이스 미러링의 초기 구성을 수행하는 것이 좋습니다.
미러를 설정하는 단계에는 참여하는 서버에 끝점을 만들고, 주 데이터베이스의 백업 및 복원을 수행하고, 참여하는 모든 서버에서 미러링 세션을 활성화하는 세 단계가 있습니다.
데이터베이스 미러링 세션을 설정하기 전에 데이터베이스 미러링에 참여하는 모든 서버 간의 통신 메커니즘을 설정해야 합니다. 이 작업을 수행하려면 ServerA와 ServerB에서 다음 문을 실행하여 양 서버에 끝점을 만듭니다.
Create Endpoint Mirroring_Endpoint
State= Started as TCP (Listener_Port=5001)
For Database_Mirroring (Role=Partner);
미러링 모니터 서버로 작동할 ServerC의 경우에는 (Role=Partner)를 (Role=Witness)로 변경한 후 문을 실행합니다. 이 서버는 각 인스턴스에서 수신하는 TCP 포트를 제어합니다.
다음 단계에서는 전체 데이터베이스 백업을 수행하고, 주 서버에 있는 DBM_Demo 데이터베이스의 로그를 백업한 다음 NORECOVERY 옵션을 사용하여 미러 서버 인스턴스에 백업을 복원합니다. NORECOVERY 옵션은 미러 데이터베이스를 복원 중인 상태로 유지하여 트랜잭션 로그를 적용할 수 있도록 합니다.
다음은 주 서버 인스턴스인 ServerA에 있는 DBM_Demo 데이터베이스의 전체 데이터베이스 백업을 수행하는 T-SQL 문입니다.
Backup Database DBM_Demo to DISK='E:\MSSQL\Bak\DBM_Demo_FULL.bak';
전체 데이터베이스 백업을 수행한 후 데이터베이스가 변경되면 데이터베이스의 로그를 백업해야 하며, 그렇지 않은 경우에는 백업하지 않아도 됩니다.
필요한 경우, 다음 T-SQL 문을 사용하여 ServerA에 있는 DBM_Demo 데이터베이스의 로그를 백업할 수 있습니다.
Backup Log DBM_Demo to Disk='E:\MSSQL\Bak\DBM_Demo_Log.bak';
모든 백업 작업을 수행한 후에는 백업을 ServerB에 복원하기 위해 백업 파일을 ServerB 또는 공유 위치로 이동합니다. 이 작업을 완료한 후에는 ServerA에서 전체 데이터베이스 백업을 마지막으로 실행한 이후에 수행한 모든 트랜잭션 로그 백업도 복원해야 합니다.
NORECOVERY 옵션이 지정된 다음 T-SQL 문을 사용하여 ServerB에 전체 및 로그 백업을 복원할 수 있습니다.
--Restore full database backup on the mirror --server instance
Restore Database DBM_Demo from Disk='E:\MSSQL\Bak\DBM_Demo_FULL.bak' with NORECOVERY;
마지막으로 NORECOVERY 옵션이 지정된 다음 T-SQL 문을 사용하여 미러 서버에 로그 백업을 복원합니다.
Restore Log DBM_Demo from Disk='E:\MSSQL\Bak\DBM_Demo_Log.bak' with NORECOVERY;
모든 백업을 복원한 후에는 참여하는 모든 서버에서 데이터베이스 미러링 세션을 활성화하는 마지막 단계를 수행합니다.
데이터베이스 미러링 세션을 설정하기 위해서는 각 서버 인스턴스에 대한 서버 네트워크 주소가 필요합니다. 이 주소에는 인스턴스를 식별하기 위해 시스템 주소와 인스턴스가 수신하는 포트 번호가 들어 있어야 합니다. 서버 네트워크 주소의 형식은 다음과 같습니다.
TCP://<System-address>:<port>
<System-address>는 정규화된 도메인 이름 또는 IP 주소이며, 로컬 시스템의 명령 프롬프트에서 IPCONFIG를 실행하여 이 정보를 확인할 수 있습니다.
<Port>는 끝점을 만들 때 설정됩니다.
다음과 같은 방법으로 ServerB에서 데이터베이스 미러링 세션을 시작할 수 있습니다.
Alter Database DBM_Demo
Set Partner= 'TCP://ServerA.com:5001';
이제 다음 T-SQL을 실행하여 ServerA에서 세션을 시작합니다.
Alter Database DBM_Demo
Set Partner='TCP://ServerB.com:5001';
다음과 같은 방법으로 ServerC(미러링 모니터 서버)에서 미러링 세션을 활성화합니다.
Alter Database DBM_Demo
Set Witness='TCP://ServerC.com:5001';
이제 데이터베이스 미러링을 실행할 수 있는 준비가 완료되었습니다. DBM_Demo 데이터베이스에서 수정되거나 새로 추가된 모든 데이터베이스 개체는 ServerB 사본에 전송됩니다. 그리고 ServerA의 데이터베이스를 사용할 수 없게 되면 장애 조치가 발생하면서 미러링된 데이터베이스의 역할이 주 역할로 변경됩니다.
이제 데이터베이스 미러링이 실행되고 있기 때문에 프로덕션 데이터베이스에 오류가 발생하더라도 언제라도 안심하고 작업할 수 있습니다.

Saleem Hakani는 14년 이상의 데이터베이스 시스템 경력을 지닌 Microsoft 수석 데이터베이스 엔지니어입니다. 그는 Microsoft SQL Community를 만들어 이끌고 있으며 Windows Live 조직을 통해 SQL Server 표준 및 자동화를 전달하는 책임을 맡고 있습니다. Saleem은 MCTS, MCDBA 및 MCSA 자격을 가지고 있습니다. 문의 사항이 있으면 Saleem@sqlcommunity.net으로 연락하시기 바랍니다.


 Field Notes: 의사는 진료 중!
Field Notes
의사는 진료 중!
Matt Hester

얼마 전 문득, IT 전문가는 의사와 비슷하다는 생각을 하게 되었습니다. 이러한 생각을 하게 된 건 처음으로 Windows Vista™를 사용하게 되었을 때입니다. 그 당시 필자는 네트워크 연결 문제로 씨름하고 있었습니다. 몇 시간 동안 ping, ipconfig를 실행하고 다시 부팅을 마치고 나자 우리 IT 전문가들의 특징이라 할 만한 타고난 호기심에 방아쇠를 당기는 새로운 단어가 머리 속에 떠올랐습니다. 그 단어는 바로 "진단"이었습니다. 일반적으로 운영 체제에서 작업을 하고 있으면 "복구", "상태", "작업 관리자", "오류 보고서 전송"과 같은 단어와 표현이 떠오르는데 이를 통해 운영 체제의 알려지지 않은 부분을 탐색할 수 있게 됩니다. 그러나 "진단"이라는 단어는 이 두 전문가 사이의 유사점을 생각하게 합니다.
우선 의사와 IT 전문가는 모두 자격 시험을 치르고 인증을 받음으로써 자신의 이름 뒤에 특별한 수식을 하나씩 붙이게 되죠. 이러한 수식은 자신의 전공 분야를 나타낼 뿐 아니라 벽이나 명함에 보기 좋게 표시할 수도 있습니다.
의사와 마찬가지로 IT 전문가 역시 문제를 해결하기 위해 방대한 양의 리소스를 사용합니다. 의사는 자신의 동료들과 문제를 상담하고 의학 전문 잡지 및 인터넷에서 정보를 검색합니다. IT 전문가 역시 동료와 함께 상의하고 인터넷과 기술 전문 잡지(그 중에서도 단연 TechNet Magazine!)에서 문제를 해결하기 위한 정보를 검색합니다.
또한 의사와 IT 전문가 모두 신뢰할 수 있는 도구에 의존합니다. 의사의 경우 청진기와 같이 친숙하고 안전한 기구를 사용하고 IT 전문가의 경우에는 ping을 사용합니다. 이 두 가지 도구 모두 어떤 문제가 있는지 알려 준다는 점에서 같습니다.
마지막 공통점은 사실상 사교에 관한 것입니다. 의사와 IT 전문가는 사회적인 모임에 참가하면 자신의 직업을 드러내지 않는 것이 매우 중요하다는 사실을 깨닫게 됩니다. 최근 한 파티에서 어쩌다 필자의 직업이 알려지는 바람에 갑자기 엄청난 유명 인사가 되어 버린 적이 있습니다. 그러나 이 유명세라는 건 대가를 치르기 마련이지요. 저는 유명해진 덕분에 매력적인 한 사람으로서의 정체성을 잃어 버렸습니다. 대신 "컴선생"이 돼버린 것이지요. 또한 덤으로 모든 파티 참석자의 출장 수리 서비스 전문가가 돼버렸습니다. "저기요 컴선생, 오늘 아침에 제 컴퓨터가 왜 망가진 거죠?", "저기요 컴선생, 임의 키는 어디 있는 겁니까?", "저기요 컴선생, 제 Mac을 고쳐 주실 수 있나요?" 기타 등등 말입니다. 그러나 가장 최악이었던 건 파티장 건너편에서 그럴 줄 알았다는 표정으로 씨익 미소를 지으며 아무에게도 방해받지 않고 여유롭게 춤을 추고 있는 의사 양반과 눈이 마주쳤던 순간이었지요.
다시 이전의 연결 문제로 돌아와 이야기를 계속하겠습니다. 필자는 장장 세 시간 동안 연결 시도에 실패한 끝에 진단 및 복구 단추를 발견하고는 이를 클릭했습니다. 그러자 아래와 같은 화면이 나타났습니다. 이걸 본 순간 필자가 느꼈을 충격과 당혹감을 한 번 상상해 보십시오.

(더 작게 보려면 이미지를 클릭하십시오.)
필자는 벌린 입을 다물지도 못하고 얼굴은 홍당무가 된 채로, 주변을 두리번거리며 보고 있는 사람이 아무도 없나 확인했습니다. 그리고는 PC 근처로 다가가 케이블을 꽂았지요. 그 운 좋은 날 이후로 Windows Vista 작업을 계속 진행했을 뿐 아니라 진단 기능을 더욱 많이 사용하게 되었습니다. 진단 기능을 사용함으로써 문제의 원인을 찾는 데 들여야 하는 많은 시간을 절약할 수 있었지요. 뿐만 아니라 진단 기능은 온라인에서 추가 정보를 검색할 수 있는 문제 보고서 및 해결 방법 제어판과의 통합이 매우 용이합니다. 그러니 머리카락을 부여잡고 고심하기 전에 먼저 확인해 보실 것을 권장합니다.
그날 밤 잠에 곯아떨어지기 전에 네트워크 연결 문제를 확인하고 해결한 것을 생각하며 기뻐하던 도중 이런 의문이 들더군요. "그럼 나도 이젠 골프 많이 치고 최신 고급 스포츠카를 몰고 다녀야 하는 것인가?"

Matt Hester는 Microsoft Across America 팀의 TechNet 프레젠테이션 담당자입니다. Matt Hester의 프레젠테이션에 대해 자세히 알아보려면 technetevents.com/mhester를 참조하십시오. blogs.technet.com/matthewms에 있는 Matt의 블로그도 살펴보시기 바랍니다.


 Windows Confidential: 수준을 낮춰서 수준을 높임
Windows Confidential
수준을 낮춰서 수준을 높임
Raymond Chen

컴퓨터에 CD를 삽입하면 Windows®에서 어떤 작업을 수행할지 묻는 메시지를 표시하는 경우가 있습니다. 지난 번에 이미 지정했는데도 말입니다. Windows에서 사용자의 자동 재생 설정을 기억하지 못하는 이유가 무엇일까요? 기억하지 못하는 것이 아니라 재차 확인하는 것입니다.
Windows XP에서는 CD 자동 재생을 처리하는 데 두 가지 문제가 있었습니다. 첫째, 대부분의 사용자는 CD 자동 재생을 지원하는 프로그램을 설치한 후에 자신이 이 프로그램을 새로운 기본 CD 자동 재생 프로그램으로 설정하는 방법을 모른다는 사실을 알게 됩니다. 이전에 한 프로그램을 선택하고 "항상 이 작업 수행"과 같은 옵션을 선택한 경우에는 CD 자동 재생 대화 상자를 다시 표시하여 이러한 옵션을 취소함으로써 새 프로그램을 기본 프로그램으로 설정하는 방법을 쉽게 알아낼 길이 없습니다.
둘째, 몇몇 잘못 동작하는 프로그램의 경우 사용자의 선택을 무시하고 자신을 기본 CD 자동 재생 처리기로 설정하기 위해 설치될 때 CD 자동 재생 설정을 몰래 해킹합니다.
간단히 요약하면 사용자는 프로그램을 설치한 후 프로그램을 기본 CD 자동 재생 프로그램으로 설정하려는 경우와 그 반대로 프로그램을 설치한 후 프로그램을 기본 CD 자동 재생 프로그램으로 설정하지 않으려는 경우의 두 가지 문제에 직면할 수 있습니다.
Windows Vista treats autoplay settings globally
Windows Vista treats autoplay settings globally (더 작게 보려면 이미지를 클릭하십시오.)
Windows Vista treats autoplay settings globally
Windows Vista treats autoplay settings globally (더 크게 보려면 이미지를 클릭하십시오.)
Windows XP SP2(서비스 팩 2)에는 이러한 문제를 해결하기 위해 새로운 CD 자동 재생 동작이 도입되었습니다. 이제 Windows에서는 새로운 CD 자동 재생 처리기가 있음을 인식하면 CD 자동 재생 대화 상자를 한 번 더 표시합니다. 따라서 새로 설치한 프로그램을 기본 플레이어로 선택할 수도 있고, 새 프로그램이 자신을 자동으로 기본 플레이어로 설정한 경우에는 해당 프로그램의 선택을 취소할 수도 있습니다.
Windows XP SP2로 업그레이드한 후 처음으로 CD를 삽입할 때도 CD 자동 재생 대화 상자가 표시됩니다. 이 대화 상자는 Windows XP SP2로 업그레이드하기 전에 설치된 처리기를 다룰 수 있도록 제공되는 것으로, 늦더라도 안 하는 것보다는 낫기 때문입니다.
과거에는 운영 체제에서 개발자가 기능을 쉽게 사용할 수 있도록 지원하는 문제만 고민하면 되었는데 현재의 소프트웨어 사용 실태를 보면 프로그래머가 이러한 인터페이스를 남용하지 않도록 방지하는 것까지 고민해야 하는 실정입니다.
Windows에서 사용자의 자동 재생 설정을 기억하지 못하는 것처럼 보이는 다른 경우도 있습니다. USB 드라이브와 같은 휴대용 저장 장치를 삽입한 경우 "항상 이 작업 수행"과 같은 옵션을 선택했는데도 자동 재생 대화 상자가 표시될 수 있습니다. 이는 Windows에서 사용자 설정을 기억하지 못하기 때문이 아니라 너무도 잘 기억하고 있기 때문입니다.
휴대용 저장 장치에 대해 옵션을 선택하면 Windows에서는 해당 장치에 대한 설정을 기억합니다. 다른 장치를 연결할 경우 이 장치의 동작은 아직 지정하지 않았으므로 새 메시지가 표시되는 것입니다. 이렇게 설계된 까닭은 디지털 카메라는 기본적으로 그림을 표시하고 음악을 재생하는 플레이어는 기본적으로 음악을 재생하도록 하려는 의도 때문이었습니다. 장치에 일련 번호가 없는 경우 장치를 다른 USB 포트에 연결하면 다른 장치로 취급됩니다.
Windows XP의 설계로 인해 야기되는 혼동을 피하기 위해 Windows Vista™에서는 이 동작이 변경되었습니다. Windows Vista에서는 자동 재생 설정이 장치 단위가 아니라 전역으로 처리됩니다. "아무 작업 안 함"과 같은 옵션을 선택하면 Windows Vista에서는 사용자가 삽입하거나 연결하는 장치에 관계없이 아무 작업도 수행하지 않습니다. 때로는 운영 체제의 수준을 낮추는 것이 수준이 높아진 것처럼 보이기도 합니다.

Raymond Chen은 자신의 웹 사이트 The Old New Thing(blogs.msdn.com/oldnewthing)과 같은 제목의 저서(Addison-Wesley, 2007)에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있습니다. 여가 시간에는 7학년생의 논문에 학점을 매기는 데 시간을 보냅니다.