 TechNet Magazine April 2008

TechNet Magazine April 2008

SQL Server 2008: 새로운 기능

새로운 버전의 SQL Server는 성능을 개선하고 보안을 강화하며 데이터베이스 관리자의 업무를 효율적으로 개선하는 수많은 새로운 기능과 향상된 기능을 제공합니다. 이 문서에서는 SQL Server 2008의 주요 변경 사항 및 SQL Server 2008을 통해 얻을 수 있는 이점에 대해 간략히 살펴봅니다.

Randy Dyess SQL Server 2008: 보안

보안은 SQL Server의 계획적인 기능 향상에 있어 하나의 중요한 영역으로 간주되고 있습니다. 암호화 및 인증 기능 향상에서 규정 요구 사항을 만족하는 데 도움이 되는 정책 기반 관리 및 새로운 감사 시스템에 이르기까지 SQL Server 2008의 몇 가지 가장 중요한 보안 관련 변경 사항에 대해 알아봅니다.

Rick Byham SQL Server 2008: 새로운 데이터 형식

SQL Server 2008은 보다 복잡한 데이터를 처리할 수 있으며 구조화된 데이터와 반구조화된 데이터의 관리뿐만 아니라 구조화되지 않은 데이터의 관리까지 단순화할 수 있는 7가지 새로운 기본 제공 데이터 형식을 제공합니다. 지금부터 새로운 데이터 형식에 대해 자세히 살펴보고 이러한 데이터 형식을 사용하여 인프라의 데이터 관리를 향상시키는 방법을 알아보겠습니다.

Kelly Wilson SQL Server 2008: 데이터 웨어하우스 쿼리 성능

SQL Server 2008은 더욱 강력한 관계형 데이터 웨어하우스 기능을 제공합니다. 핵심적인 성능 관련 데이터 웨어하우스 기능에 대해 자세히 살펴보고 이러한 새로운 기술을 이용하여 쿼리 성능을 최적화하는 방법을 알아보십시오.

S. Agarwal, T. Grabs, and J. Hammer SQL Server: SQL Server의 차단 최소화

잠금은 데이터베이스에서 동시 읽기 및 쓰기 작업을 지원하는 데 필수적인 반면, 차단은 시스템 성능에 부정적인 영향을 줄 수 있습니다. 차단을 최소화할 수 있도록 SQL Server 데이터베이스를 최적화하는 방법과 잠금이 성능에 미치는 영향을 보다 효과적으로 파악할 수 있도록 시스템을 모니터링하는 방법에 대해 알아봅니다.

Cherié Warren Microsoft Office: Access 데이터베이스와 SharePoint 통합

많은 기업에서 여전히 Microsoft Access를 사용하고 있습니다. 다행히 Microsoft Office SharePoint Server 2007을 사용하면 기존 Access 데이터를 통합할 수 있습니다. 이 기사에서는 이러한 도구를 사용하여 조직에 필요한 새로운 솔루션을 만드는 방법에 대해 설명합니다.

Peter Serzo From the Editor: 떠나는 동료와 새 동료

Joshua Hoffman Letters: 독자의 목소리

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

Greg Steen SQL Q&A: 데이터베이스 크기 증가, IFilter 사용 및 원격 연결

이 기사를 통해 프로그래밍 방식으로 데이터베이스 크기를 늘리는 방법, IFilter를 사용하는 방법 및 원격 SQL Server 연결을 지원하는 방화벽 설정에 대해 알아보십시오.

Edited by Matthew Graven Utility Spotlight: Web Capacity Analysis Tool

웹 로그 및 트래픽 분석에서는 시간의 흐름에 따라 트래픽 유형에 대한 유용한 정보를 제공합니다. 그러나 인프라에서 무엇이 처리되는지 어떻게 확인할 수 있을까요? 무료 Web Capacity Analysis Tool을 사용하면 부하 상태를 시스템에서 어떻게 처리하는지 손쉽게 확인할 수 있습니다.

Greg Steen The Cable Guy: NAP 적용 문제 해결

NAP(네트워크 액세스 보호) 플랫폼의 적용 과정에서 발생하는 문제를 해결하는 작업이 어렵게 느껴질 수 있습니다. 이번 달 Cable Guy 칼럼에서는 NAP 상태 정책 평가가 작동하는 방식과 가장 일반적인 문제를 해결하는 방법에 대해 설명합니다.

Joseph Davies Windows PowerShell: 여기 서명해 주세요

AllSigned 실행 정책은 가장 안전한 Windows PowerShell 환경을 제공합니다. 그런데 Windows PowerShell 스크립트에 서명하려면 어떻게 해야 할까요? Don Jones가 그 방법을 설명합니다.

Don Jones Hey, Scripting Guy!: 데이터베이스 스크립트의 귀환

조직의 가장 중요한 정보는 대개 데이터베이스에 저장됩니다. 이번 달 Scripting Guys 칼럼에서는 VBScript를 사용하여 몇 줄의 코드만으로 데이터베이스의 정보를 신속히 읽고, 레코드를 추가, 제거, 업데이트하는 방법을 소개합니다.

The Microsoft Scripting Guys Security Watch: 내 PII는 어디에 있을까요?

개인 식별이 가능한 정보를 효과적으로 보호하려면 우선 그러한 정보가 PC의 어디에 저장되는지 알아야 합니다. 여기서는 컴퓨터에 저장된 개인 데이터를 찾는 스크립트를 작성하는 방법에 대해 알아봅니다. 이러한 스크립트의 결과를 보면 적잖이 놀라게 될 것입니다.

Frank Simorjay The Desktop Files: WAIK를 사용한 Windows XP 배포

Windows 자동 설치 키트는 Windows Vista와 Windows Server 2008을 주 대상으로 설계되었지만 Windows XP와 Windows Server 2003을 배포하는 데에도 활용할 수 있습니다. 여기서는 Windows 자동 설치 키트를 사용한 Windows XP 및 Windows Server 2003 배포 작업을 시작하는 데 알아야 할 사항에 대해 설명합니다.

Wes Miller Field Notes: 놀라운 MAR 이니셔티브

기업에서 중고 PC를 재활용할 때 복잡한 소프트웨어 라이선스 문제를 처리하는 데 새로운 MAR(Microsoft Authorized Refurbisher: Microsoft 공인 재활용) 프로그램이 어떤 식으로 도움이 되는지에 대해 살펴봅니다.

Neil Fawcett Windows Confidential: 균등한 공유

Chen은 사용자가 프로그램을 제거할 때 제거 프로그램에서 "이 공유 파일을 제거하시겠습니까?"라고 묻는 메시지가 표시되는 이유를 설명합니다.

Raymond Chen


 SQL Server 2008: 새로운 기능
SQL Server 2008 Randy Dyess

새로운 기능
한 눈에 보기:
  • 관리 기능 강화
  • 성능 및 확장성 향상
  • 보안 및 가용성 개선
  • 개발자를 위한 변경 사항

Microsoft는 데이터베이스 관리자의 업무를 효율적으로 개선하는 새로운 버전의 SQL Server를 또 한번 출시했습니다. SQL Server의 최신 버전인 SQL Server 2008은 관리 작업을 혁신적으로 개선하는
광범위한 새로운 기능을 제공합니다.
오래 동안 SQL Server® 2005를 사용한 데이터베이스 관리자라면 그 동안 일상적인 작업에서 사용하던 기능의 대부분이 SQL Server 2008에서 그다지 달라지지 않았지만 이러한 친숙한 도구가 새롭게 향상되었다는 사실을 곧 알게 될 것입니다. 기존 기능을 토대로 개발된 새로운 기능은 복잡한 데이터베이스 환경에서 다양한 기능을 사용하는 데 필요한 여러 가지 사용자 지정이나 문제 해결 작업을 줄이는 데 도움이 됩니다.
SQL Server 2008의 새로운 기능에는 분류하기 어려울 정도의 광범위한 데이터베이스 작업 역할이 포함됩니다. 필자는 다른 기사에서 이러한 기능을 분류한 적이 있는데 이때 명백히 Z라는 범주에 속하는 X라는 기능을 Y라는 범주로 분류해 놓았습니다. 아마 일부 독자는 그 이유를 매우 궁금해할 것 같습니다. 이는 관점의 문제로 독자가 속한 회사의 사업 방식에 따라 달라질 수 있습니다.
데이터베이스 분야에 종사하는 사람들은 대개 많은 다양한 작업 역할을 수행하며 필자도 이 점을 잘 알고 있습니다. 따라서 이 기사에서는 새로운 기능을 관리, 확장성, 성능, 고가용성, 보안, 개발 및 비즈니스 인텔리전스라는 일반 범주로 분류해 보겠습니다.

관리를 위한 새로운 기능
필자와 같은 데이터베이스 관리자에게 SQL Server 2008은 제품에 추가된 관리 기능 덕분에 매우 흥미로운 신제품으로 다가옵니다. 새로운 정책 관리, 다양한 서버 쿼리 기능, 구성 서버 및 데이터 수집기/관리 웨어하우스는 수십, 수백 개가 넘는 서버에 수백, 수천 개의 데이터베이스가 있는 대규모의 복잡한 데이터베이스 환경 관리를 담당하는 데이터베이스 관리자를 위한 강력하고 새로운 기능을 제공합니다.
SQL Server 2008 정책 관리 기능(CTP(Community Technology Previews)에서는 Declarative Management Framework라고 함)을 사용하면 하나 이상의 데이터베이스 서버에 대해 구성 정책을 만들어 실행할 수 있습니다. 이러한 정책을 사용하여 각 대상 서버와 데이터베이스에 표준 구성 설정을 적용하고 유지할 수 있습니다. 그림 1에서 이 기능의 예를 볼 수 있습니다.
그림 1 Data and Log File Location Best Practice(데이터 및 로그 파일 위치 최상의 방법) 정책
그림 1 Data and Log File Location Best Practice(데이터 및 로그 파일 위치 최상의 방법) 정책
정책은 미리 정의된 패싯 집합에서 만듭니다. 각 패싯에는 SQL Server 2008 구성 설정 하위 그룹 및 사용자가 제어할 수 있는 기타 이벤트가 포함됩니다. 이러한 패싯에 조건을 연결하여 정책을 만듭니다. 조건은 패싯의 속성, 구성 설정 또는 패싯에 포함된 기타 이벤트에 대해 사용할 수 있는 값입니다.
또한 조건은 정책 필터에 사용되는 값이기도 합니다. 특정 데이터베이스에 대해서만 정책을 실행하기를 원한다고 가정해 보겠습니다. 이 경우 데이터베이스 이름이 포함된 조건을 만든 다음 이 조건을 정책에 추가합니다. 그러면 정책이 해당 데이터베이스에만 적용됩니다. SQL Server 2008 정책 관리는 다소 복잡하게 느껴질 수 있지만 한번만 사용해 보면 매우 쉽다는 것을 알 수 있을 것입니다.
새로운 Multiple Server Interaction(다중 서버 상호 작용) 및 구성 서버 기능은 여러 서버에 대해 동시에 쿼리를 실행해야 하는 경우 유용합니다. Management Studio에서 여러 서버를 등록한 후 이러한 서버를 한 그룹에 포함할 수 있습니다. 이렇게 하면 그룹에 포함된 모든 서버에 대해 정책이나 쿼리를 실행해야 할 경우 해당 그룹을 마우스 오른쪽 단추로 클릭하고 정책이나 쿼리를 실행하기만 하면 됩니다.
서버별로 하나의 결과 집합을 반환하거나 모든 결과 집합을 하나의 큰 결과 집합으로 병합하도록 이 기능을 구성할 수 있다는 추가적인 장점도 있습니다. 또한 각 서버의 개별 결과를 쉽게 알아볼 수 있도록 서버 및 데이터베이스 이름을 결과에 포함할지 여부도 지정할 수 있습니다. 등록된 서버를 각각의 Management Studio 대신 구성 서버에 저장할 수 있는 것도 큰 장점입니다.
유용한 다른 새로운 관리 기능으로는 데이터 수집기가 있습니다. 데이터베이스 관리자는 대개 다수의 서버에서 관리 데이터를 수집해야 하며 대부분의 데이터베이스 관리자는 이를 수행하기 위해 고유의 사용자 지정 솔루션을 만듭니다. 데이터 수집기는 관리 관련 데이터 수집 작업을 용이하게 하는 기본 제공 메커니즘입니다. 데이터 수집기를 사용하면 SQL Server 에이전트와 SSIS(SQL Server Integration Services)를 통해 데이터를 수집하고 저장하는 동시에 오류 처리, 감사 및 수집 기록 기능을 제공하는 프레임워크를 만들 수 있습니다.
타사 도구 및 사용자 지정 작업과 달리 데이터 수집기는 데이터의 연결, 수집 및 저장을 처리하기 위한 일련의 작업 및 패키지를 만드는 데 SQL Server 에이전트와 SSIS를 사용하므로 대부분의 데이터베이스 관리자가 쉽게 파악할 수 있습니다(그림 2 참조). 이 데이터를 관리 웨어하우스라고 하는 중앙 위치에 저장하면 일련의 T-SQL 문 및 SQL Server 2008 Reporting Services 보고서를 통해 데이터를 보고 구성할 수 있습니다. 이 중앙 데이터 저장소를 사용하면 데이터베이스 환경에 대한 전반적인 관리 메트릭을 훨씬 쉽게 분석하고 검토할 수 있습니다.
그림 2 데이터 수집기 디스크 사용 로그 파일
그림 2 데이터 수집기 디스크 사용 로그 파일

확장성을 위한 새로운 기능
시간이 지나면서 SQL Server 데이터베이스 관리자는 자신이 관리하는 데이터베이스 환경이 점점 커진다는 사실을 깨달았습니다. 데이터베이스 환경의 규모가 커지면 대부분의 엔터프라이즈에 요구되는 확장성을 달성하기 위해 새로운 방법과 도구가 필요합니다. SQL Server 2008에는 이를 지원하는 몇 가지 새로운 기능이 도입되었습니다.
SQL Server 2008에는 데이터베이스 파일 및 해당 데이터베이스와 관련된 트랜잭션 로그 파일을 압축할 수 있는 기본 제공 압축 기능이 있습니다. SQL Server 2005에도 읽기 전용 파일이나 파일 그룹에 데이터를 압축하는 기능이 도입되었지만 이 압축 기능은 단순히 Windows® NTFS의 압축 기능을 사용하는 데 그쳤습니다. SQL Server 2008은 행 수준 및 페이지 수준 압축 기능을 모두 제공하므로 데이터 파일 수준에서 압축을 수행할 필요가 없습니다.
행 및 페이지 수준에서 압축하면 데이터 공간 사용량이 줄어들 뿐만 아니라 데이터가 압축된 상태로 메모리에 유지되기 때문에 필요한 메모리 공간도 줄어듭니다. 따라서 메모리 사용률이 높아지며 이는 대부분의 시스템에 확장성 향상이라는 이점을 가져다 줍니다.
또한 SQL Server 2008에는 백업 수준 압축 기능도 도입되었습니다. 데이터베이스 백업은 데이터베이스의 활성 부분만 백업하지만 이러한 백업은 여전히 수백 기가바이트, 심지어는 수십 테라바이트까지 이를 수 있습니다. 수 테라바이트에 이르는 백업 파일의 복사본이 두 개 이상 있는 데이터베이스 환경에서는 이러한 백업으로 인해 보다 효과적으로 사용될 수 있는 귀중한 저장소 공간이 낭비됩니다. SQL Server 2008은 데이터베이스 관리자가 백업 파일을 압축하여 저장소 공간을 확보하고 이를 라이브 데이터에 사용할 수 있도록 지원합니다.
또한 리소스 관리자라는 기능도 있습니다. 이 새로운 기능을 사용하면 개별 작업이나 작업 그룹이 작업 실행 중 사용할 수 있는 리소스의 양을 정의할 수 있습니다. 리소스 관리자를 사용하면 여러 개의 다양한 작업을 한 서버에서 실행할 수 있으며 이 중 하나 이상의 작업이 해당 서버의 용량을 초과하여 다른 작업의 성능을 저하하지 않을까 염려할 필요가 없습니다.
이 기능의 장점은 데이터베이스 서버의 총 가용 리소스를 보다 효과적으로 사용할 수 있다는 데 있습니다. 그림 3에서는 리소스 관리자를 사용하여 서버의 작업을 제한하는 예를 보여 줍니다.
Figure 3 리소스 관리자를 사용하여 작업 제한 (Close Figure 3)
USE master
go

--Drop 함수
IF OBJECT_ID('rgclassifier_demo','Function') IS NOT NULL
DROP FUNCTION rgclassifier_demo
go

--보고 그룹에 대한 분류자 함수 만들기
CREATE FUNCTION rgclassifier_demo() RETURNS SYSNAME
WITH SCHEMABINDING
AS
BEGIN
    DECLARE @group_name AS SYSNAME
  IF (USER_NAME() LIKE '%Launch_Demo%')
         SET @group_name = 'demogroup'
    RETURN @group_name
END
GO

--Management Studio에서 가져온 모든 항목에 대한 작업 그룹 삭제
IF EXISTS (SELECT name FROM sys.resource_governor_workload_groups
  WHERE name = 'demogroup')
BEGIN
  DROP WORKLOAD GROUP demogroup
END
GO

--작업 그룹 만들기
CREATE WORKLOAD GROUP demogroup
GO

--리소스 관리자에
--분류자 함수 등록
ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION= dbo.rgclassifier_demo)
GO

--각 작업 요청에 대해 10%의 CPU만 허용하도록
--dbogroup 작업 그룹 변경
ALTER WORKLOAD GROUP demogroup
WITH (REQUEST_MAX_CPU_TIME_SEC = 10)
GO

--새 리소스 풀을 만들고 모든 작업에 대한 최대 CPU 제한 설정
IF EXISTS (SELECT name FROM sys.resource_governor_resource_pools
  WHERE name = 'pooldemo')
DROP RESOURCE POOL pooldemo
GO

CREATE RESOURCE POOL pooldemo
WITH (MAX_CPU_PERCENT = 40)
GO

--새 리소스 풀을 사용하도록
--작업 그룹 구성
ALTER WORKLOAD GROUP demogroup
USING pooldemo
GO

--리소스 관리자 메모리 내 구성에
--변경 사항 적용
ALTER RESOURCE GOVERNOR RECONFIGURE
GO

성능을 위한 새로운 기능
SQL Server 2008에서는 데이터베이스의 전반적인 성능이 향상됩니다. SQL Server 2008의 몇 가지 새로운 기능 덕분에 데이터베이스 및 데이터베이스에 대해 실행하는 응용 프로그램의 성능을 제어하고 모니터링할 수 있습니다.
초당 실행되는 트랜잭션의 수가 매우 많을 경우 트랜잭션 중에 일반적으로 발생하는 잠금이 데이터베이스 응용 프로그램의 성능에 좋지 않은 영향을 줄 수 있습니다. SQL Server는 소규모의 행 수준 및 페이지 수준 잠금에서 대규모의 테이블 수준 잠금으로 잠금을 에스컬레이션하여 한 프로세스에서 보유하는 총 잠금 수를 줄이도록 설계되었습니다. 단, 이 잠금 에스컬레이션은 몇 가지 문제를 야기할 수 있습니다. 예를 들어 단일 트랜잭션이 전체 테이블을 잠가서 다른 트랜잭션이 해당 테이블을 사용할 수 없게 될 수 있습니다.
SQL Server 2008은 SQL Server 2005에 도입된 테이블 파티션 메커니즘을 사용하여 SQL Server 엔진이 테이블 수준 잠금에 앞서 파티션 수준으로 잠금을 에스컬레이션할 수 있도록 합니다. 이 중간 잠금 수준은 초당 수백, 수천 개의 트랜잭션을 처리해야 하는 시스템에서 잠금 에스컬레이션이 주는 문제를 눈에 띄게 줄입니다.
SQL Server 2008은 분할된 테이블에 쿼리를 사용하는 경우 활용할 수 있는 몇 가지 새로운 향상된 쿼리 프로세서를 제공합니다. 이제 쿼리 최적화 프로그램이 개별 인덱스에 대해서와 마찬가지로 파티션에 대해서도 테이블 수준의 파티션 메커니즘을 사용하지 않고 파티션 ID만 사용하여 쿼리 검색을 수행할 수 있습니다.

고가용성을 위한 새로운 기능
데이터베이스 환경이 복잡해지고 데이터베이스의 크기가 커질수록 데이터베이스의 가용성을 보장하는 일도 점점 어려워지고 있습니다. 과거에 고가용성을 달성하기 위해 사용했던 친숙한 메커니즘이 SQL Server 2008에서도 제공됩니다. 그러나 SQL Server 2008에서는 이러한 기존 기능 중 일부가 향상되고 몇 가지 새로운 기능이 추가되었습니다.
SQL Server 2005에서 대부분의 관리자는 고가용성을 달성하기 위해 데이터베이스 미러링을 구현하기 시작했습니다. SQL Server 2008은 데이터베이스 미러링을 보다 쉽게 수행할 수 있도록 다양한 향상된 기능을 제공합니다. 예를 들어 이전에는 데이터베이스 미러링을 수행할 때 트랜잭션 로그 데이터를 주 데이터베이스에서 미러된 데이터베이스로 이동하는 것과 관련하여 성능 문제가 가끔 있었습니다. 이를 해결하기 위해 이제 SQL Server 2008에서는 정보를 미러 데이터베이스의 트랜잭션 로그로 보내기 전에 압축함으로써 네트워크를 통해 주 데이터베이스의 트랜잭션 로그에서 미러 데이터베이스의 트랜잭션 로그로 이동되는 정보의 양을 줄입니다.
이제 주 데이터베이스에서 손상된 데이터 페이지를 복구할 수 있습니다. 주 데이터베이스에서 오류 823 및 824로 인해 데이터 페이지 손상이 발생할 경우 주 데이터베이스는 해당 데이터 페이지의 새 복사본을 미러된 서버에 요청할 수 있습니다. 이러한 올바른 데이터 페이지를 요청하는 작업은 현재 주 데이터베이스에 액세스하는 어떤 사용자도 알지 못하게 이루어지는 자동화된 프로세스입니다.
다른 새로운 기능인 Hot Add CPU를 사용하면 데이터베이스 서버에 있는 데이터베이스의 가용성에 영향을 주지 않고 데이터베이스 서버에 CPU를 추가할 수 있습니다. 그러나 Hot Add CPU 기능에는 64비트 Itanium 기반 Windows Server® 2008 Enterprise Edition이나 Datacenter Edition을 실행하는 경우에만 이 기능이 유용하며 SQL Server 2008 Enterprise Edition을 사용해야 하는 등 몇 가지 제한이 있습니다.

보안을 위한 새로운 기능
SQL Server 2005에는 데이터 암호화 형태의 데이터 보안이 도입되었습니다. SQL Server 2008에서는 확장 가능 키 관리와 투명한 데이터 암호화라는 두 가지 기능이 도입되어 암호화가 크게 향상되었습니다.
확장 가능 키 관리는 암호화 인프라에 사용되는 키를 데이터베이스 자체뿐 아니라 데이터베이스 외부의 타사 소프트웨어 모듈이나 하드웨어 보안 보듈에 안전하게 저장할 수 있는 향상된 구조를 지원합니다.
투명한 데이터 암호화는 암호화가 단순히 한 줄의 코드로 된 함수의 결과가 아니라 데이터베이스의 속성이 되도록 지원함으로써 보다 융통성 있는 데이터 암호화 방법을 제공합니다. 따라서 관리자는 데이터베이스 구조나 응용 프로그램 코드를 변경할 필요 없이 데이터 수준에서 암호화를 수행할 수 있습니다. 그림 4의 코드는 투명한 데이터 암호화를 사용하여 데이터베이스를 암호화하는 방법을 보여 줍니다.
Figure 4 투명한 데이터 암호화 사용 (Close Figure 4)
USE master;
GO

--마스터 키 만들기
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'YouWillNeedToCreateAStrongPassword';
GO

--TDE에 사용할 인증서 만들기
CREATE CERTIFICATE TDECERT WITH SUBJECT = 'TDECert'
GO

--암호화할 데이터베이스 변경
USE AdventureWorks
GO

--데이터베이스 마스터 키 만들기
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128 --강력한 알고리즘 사용
ENCRYPTION BY SERVER CERTIFICATE TDECERT
GO

--마스터 데이터베이스 키를 사용하여 데이터베이스가 암호화되도록
--데이터베이스 변경
ALTER DATABASE AdventureWorks
SET ENCRYPTION ON
GO

개발자를 위해 제공되는 기능
SQL Server 2008의 변경을 통해 데이터베이스 관리자만 직접적인 혜택을 보는 것은 아닙니다. 데이터베이스 개발자를 지원하도록 설계된 새로운 기능도 많이 있습니다. 여기에는 여러 가지 향상된 새로운 T-SQL에서 개발자가 데이터베이스 쿼리를 만들고 활용하는 데 도움이 될 수 있는 새로운 구성 요소까지 다양한 기능이 포함됩니다.
대부분의 데이터베이스 개발자는 응용 프로그램에 필요한 데이터를 반환하는 쿼리를 만드는 작업을 담당합니다. 데이터베이스 개발자가 일반 T-SQL 문 대신 Microsoft® .NET 기반 프로그래밍 언어를 사용하여 데이터베이스에 대해 쿼리를 실행할 수 있도록 지원하는 LINQ(Language Integrated Query) 도구에 대해서는 잘 알고 있을 것입니다. SQL Server 2008에서는 개발자가 SQL Server 테이블 및 열에 대해 직접 LINQ 명령을 실행할 수 있도록 허용하는 새로운 LINQ to SQL 공급자를 제공함으로써 LINQ 기능을 향상합니다. 따라서 새 데이터 쿼리를 만드는 데 걸리는 시간이 줄어듭니다.
데이터베이스 개발자는 데이터베이스를 개발할 때 개별 데이터베이스 테이블과 열에 매핑되는 높은 수준의 개체를 사용합니다. 엔터티라고도 하는 이러한 개체는 데이터베이스 응용 프로그램에 필요한 데이터를 나타내므로 개발자는 데이터의 실제 저장소 구조 및 데이터베이스 스키마를 이해할 필요가 없습니다. 이제 개발자는 새로운 ADO.NET Entity Framework를 통해 이러한 엔터티를 사용하여 데이터베이스 쿼리를 만들 수 있습니다. 또한 기본 데이터베이스 구조의 추상화를 통해 개발자의 생산성이 높아집니다.
SQL Server 2008에서는 데이터베이스 개발자의 업무 효율성을 높이도록 T-SQL의 많은 기능이 향상되었습니다. 한 가지 예로 개발자가 데이터를 삽입하기 전에 해당 데이터가 있는지 확인하는 데 사용할 수 있는 새로운 MERGE 문을 들 수 있습니다. INSERT 문 실행 전에 이 검사를 수행하면 데이터를 업데이트할 수 있습니다. 따라서 이제 기존 데이터를 업데이트하고 없는 데이터를 삽입하기 위해 복잡한 조인을 만들 필요가 없습니다. 모든 작업을 하나의 문에서 수행할 수 있습니다.
뿐만 아니라 시간 및 날짜 데이터를 결합된 형태의 날짜/시간 데이터 형식에서 분리하는 작업도 더욱 쉬워졌습니다. SQL Server 2008에는 날짜 및 시간 데이터를 처리하기 위한 별도의 두 데이터 형식이 도입되었습니다. 별도의 데이터 형식이 도임됨으로써 데이터에 대해 별도의 작업을 수행할 필요 없이 곧바로 쿼리에 데이터를 사용할 수 있기 때문에 대부분의 쿼리 성능이 향상됩니다.
데이터베이스 개발자는 새로운 데이터베이스 구조를 만들 때 대개 매핑 응용 프로그램을 구현하기 위해 데이터베이스 구조를 확장합니다. SQL Server 2008은 새로운 공간 데이터 형식을 통해 이 문제를 해결할 수 있도록 지원합니다. 이제 개발자는 두 개의 공간 데이터 형식인 GEOGRAPHY와 GEOMETRY를 사용하여 데이터 요소를 다른 표준 데이터 형식에 맞는 형식으로 나눌 필요 없이 위치 데이터를 직접 데이터베이스에 저장할 수 있습니다. 그림 5의 코드는 단순한 공간 테이블을 보여 주는 예제입니다.
Figure 5 단순한 공간 테이블 (Close Figure 5)
IF OBJECT_ID ( 'Demo_SpatialTable', 'Table' ) IS NOT NULL
    DROP TABLE Demo_SpatialTable
GO

--공간 데이터를 유지할 테이블 만들기
CREATE TABLE Demo_SpatialTable
    ( SpatialID int IDENTITY (1,1),
    SpatialInputCol geography,
    SpatialOutputCol AS SpatialInputCol.STAsText() )
GO

--테이블에 데이터 삽입
INSERT INTO Demo_SpatialTable (SpatialInputCol)
VALUES (geography::STGeomFromText('LINESTRING(47.656 -122.360, 47.656 -122.343)', 4326));

INSERT INTO Demo_SpatialTable (SpatialInputCol)
VALUES (geography::STGeomFromText('POLYGON((47.653 -122.358, 47.649 -122.348, 47.658 -122.348, 47.658 -122.358, 47.653 -122.358))', 4326));
GO

--변환되어 l2열에 저장되었는지 데이터 확인
SELECT * FROM Demo_SpatialTable
이전에 데이터베이스 개발자가 흔히 겪었던 문제는 문서 및 미디어 파일 같은 BLOB를 저장하고 사용하는 방법이었습니다. 파일은 데이터베이스 외부에 저장하고 이 외부 파일에 대한 포인터만 데이터베이스에 저장하는 방법이 일반적으로 사용되었습니다. 그러나 이 방법을 사용할 경우 파일을 이동하면 포인터도 업데이트해야 합니다.
SQL Server 2008에서는 새로운 FILESTREAM 데이터 형식을 사용하여 이 문제를 해결합니다. 이 데이터 형식을 사용할 경우 파일을 여전히 데이터베이스 외부에 저장할 수 있지만 트랜잭션 일관성을 위해 데이터가 데이터베이스의 일부로 간주됩니다. 이를 통해 데이터베이스의 성능 및 보안상의 이점은 그대로 유지하면서 일반적인 파일 작업을 수행할 수 있습니다.

비즈니스 인텔리전스를 위한 기능
지난 몇 년 간의 SQL Server 사용량 증가는 비즈니스 인텔리전스 전략의 채택이 뒷받침된 결과입니다. 비즈니스 인텔리전스 기능이 SQL Server의 새로운 기능은 아니지만 SQL Server 2008은 테이블에 사용할 수 있는 몇 가지 새로운 비즈니스 인텔리전스 기능을 제공합니다.
예를 들어 데이터가 데이터 웨어하우스에 저장될 때 NULL 값으로 인해 공간이 낭비되는 경우가 많습니다. NULL 값을 저장하는 열은 열에 정의된 허용되는 가장 큰 데이터 크기에 해당하는 공간을 사용합니다. 이는 수천 개의 NULL 값이 있는 한 개의 열이 실제로 어떠한 데이터도 저장하지 않은 채 수 MB의 공간을 사용할 수 있음을 의미합니다.
SQL Server 2008에는 디스크의 실제 공간을 차지하지 않고 NULL 값을 저장할 수 있는 스파스 열이 도입되었습니다. 스파스 열은 실제로 공간을 사용하지 않으므로 스파스 열이 포함된 테이블의 경우 1,024개의 열 제한을 초과할 수 있습니다.
또한 SQL Server 2008에는 데이터 웨어하우스에 로드해야 하는 증분 변경을 관리하기 위한 변경 데이터 캡처라는 새로운 메커니즘이 도입되었습니다. 이 메커니즘은 변경된 데이터를 캡처하여 변경 테이블 집합에 저장합니다. 쉽게 사용되는 저장소 스키마에서 업데이트되고, 삭제되고, 삽입된 데이터를 캡처함으로써 데이터를 해당 테이블에서 데이터 웨어하우스로 증분 로드할 수 있으며 이는 데이터 웨어하우스를 업데이트하기 전에 기존 데이터 행에 수행된 변경을 추적하기 위해 사용자 지정 insert 문을 작성해야 하는 기존의 방법과 대조됩니다.

결론
이 기사에서는 SQL Server 2008이 제공하는 새로운 기능에 대해 간단히 살펴보았습니다. SQL Server 2008은 데이터베이스 관리자와 데이터베이스 개발자 모두의 업무를 효율적으로 개선하는 광범위한 새로운 기능 및 기존 기능에 대한 업데이트를 제공합니다. 궁극적으로 SQL Server 2008은 오늘날의 요구 사항이 많은 데이터베이스를 위한 대폭 향상된 성능과 확장성을 제공할 것입니다.

Randy Dyess는 Solid Quality Mentors의 강사이며 SQL Server OLTP 시스템을 전문적으로 담당하고 있습니다. Randy는 TransactSQL Language Reference Guide의 저자이자 MCTS Self-Paced Training Kit: Microsoft SQL Server 2005 Implementation and Maintenance (Exam 70-431)를 비롯한 다양한 잡지와 뉴스레터 기사의 공동 저자이며, 텍사스 북부 SQL Server 사용자 그룹의 프로그램 담당 이사이자 SQL Server MVP입니다. blogs.solidq.com/EN/rdyess/default.aspx에 있는 Randy의 블로그를 방문해 보십시오.
© 2007 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..


 SQL Server 2008: 보안
SQL Server 2008 Rick Byham

보안
한 눈에 보기:
  • 암호화 기능 향상
  • 인증 기능 향상
  • 보안 감사
  • 정책 기반 관리

SQL Server 2008은 데이터베이스 환경의 전반적인 보안을 개선하도록 설계된 많은 향상된 기능과 새로운 기능을 제공합니다. 또한 SQL Server 2008에는 키 암호화 및 인증 기능이 추가되었고 사용자 동작에 관해 보고하고 규정 요구 사항을 만족하는 데 도움이 되는
새로운 감사 시스템도 도입되었습니다.
이 문서에서는 SQL Server® 2008 보안을 위한 가장 중요한 저장소 변경 사항에 대해 개략적으로 살펴봅니다. 여기서 가장 주목해야 할 점은 SQL Server 2005 노출 영역 구성 도구가 SQL Server 2008에서는 제공되지 않는다는 점입니다. 노출 영역 구성 도구에서 제공되었던 프로토콜 옵션은 이제 구성 관리자 도구에서 제공됩니다. 그러나 이제는 새로운 SQL Server 2008 정책 기반 관리 프레임워크를 사용하여 기능을 설정하고 해제합니다.

암호화 기능 향상
암호화 영역에서는 두 가지 사항이 크게 개선되었습니다. 첫째는 이제 SQL Server에서 외부 타사 하드웨어 보안 모듈에 저장된 암호화 키를 사용할 수 있다는 점입니다. 둘째는 데이터베이스에 연결되는 응용 프로그램에 투명한 방법으로 SQL Server에 저장된 데이터를 암호화할 수 있다는 점입니다. 따라서 데이터베이스 관리자는 기존 응용 프로그램 코드를 수정하지 않고도 전체 데이터베이스에 저장된 모든 데이터를 손쉽게 암호화할 수 있습니다.
전자의 경우는 SQL Server 2008 Enterprise, Developer 및 Evaluation 버전에서 제공하는 새로운 EKM(확장 가능 키 관리) 기능을 통해 가능합니다. EKM을 사용하면 엔터프라이즈 키 관리 및 HSM(하드웨어 보안 모듈) 솔루션을 제공하는 타사 공급업체가 SQL Server에 해당 장치를 등록할 수 있습니다. 이러한 장치를 등록하면 사용자가 해당 모듈에 저장된 암호화 키를 사용할 수 있습니다.
이들 공급업체는 해당 모듈에 키 에이징, 키 회전 등 고급 암호화 기능도 제공할 수 있습니다. 일부 구성에서는 이를 통해 sysadmin 그룹의 구성원이 아닌 데이터베이스 관리자가 데이터를 보호할 수 있습니다. 이 경우 T-SQL 암호화 문을 통해 외부 EKM 장치에 저장된 키를 사용하여 데이터를 암호화하고 해독할 수 있습니다.
또 다른 새로운 기능인 투명한 데이터 암호화를 사용하면 응용 프로그램을 변경하지 않고도 데이터베이스 파일을 암호화할 수 있습니다. 이 기능은 데이터 및 로그 파일에 대해 실시간으로 I/O를 암호화하고 해독합니다. 암호화에서는 복구 중에 사용할 수 있도록 데이터베이스 부트 레코드에 저장되는 DEK(데이터베이스 암호화 키)를 사용합니다. DEK는 서버의 master 데이터베이스에 저장된 인증서를 통해 보호됩니다. 그림 1의 다이어그램에는 투명한 데이터 암호화를 가능하게 하는 아키텍처가 나와 있습니다.
그림 1 투명한 데이터 암호화 아키텍처
그림 1 투명한 데이터 암호화 아키텍처
이는 휴지 상태의 데이터를 보호하는 데 유용합니다. 기밀 자산을 암호화하고, 데이터베이스 서버 주변에 방화벽을 설치하는 등 데이터베이스를 보호하기 위한 몇 가지 예방 조치를 취할 수는 있지만 데이터베이스가 저장되는 실제 미디어(백업 테이프 포함)에는 또 다른 취약점이 있습니다. 즉, 악의적인 사용자가 이 미디어를 훔쳐 저장된 데이터에 액세스할 수 있습니다.
그러나 투명한 데이터 암호화를 사용하면 데이터베이스의 중요한 데이터를 암호화하고 인증서를 사용하여 데이터를 암호화하는 데 사용되는 키를 보호할 수 있습니다. 이를 통해 조직은 데이터 보호와 관련된 수많은 법률, 규정 및 업계 지침을 보다 쉽게 준수할 수 있습니다.
투명한 데이터 암호화를 사용하면 소프트웨어 개발자가 AES(Advanced Encryption Standard) 및 3DES(Triple Data Encryption Standard) 암호화 알고리즘을 통해 데이터를 암호화할 수 있습니다. 데이터베이스 파일의 암호화는 디스크에 기록되기 전에 암호화되어 나중에 메모리에서 읽을 때 해독되는 페이지를 통해 페이지 수준에서 수행됩니다. 투명한 데이터 암호화를 사용하는 데이터베이스의 백업 파일도 데이터베이스 암호화 키를 사용하여 암호화됩니다.
암호화된 데이터베이스를 복원하려면 데이터베이스 암호화에 사용된 비대칭 키나 인증서에 액세스할 수 있어야 합니다. 인증서나 비대칭 키가 없으면 데이터베이스를 복원할 수 없습니다. 관련된 백업에 액세스해야 할 수도 있으므로 모든 키를 잘 보관해 두어야 합니다.

인증 기능 향상
알고 있겠지만 Kerberos는 네트워크에서 클라이언트와 서버 엔터티(또는 보안 주체)를 매우 안전한 방식으로 상호 인증할 수 있는 네트워크 인증 프로토콜입니다. Kerberos를 통해 사용자는 유인 및 MITM(Man-In-The-Middle) 공격과 같은 보안 취약점을 해결할 수 있습니다. Windows® NTLM 인증에 비해 Kerberos는 더욱 안전하고 강력하며 보다 높은 성능을 제공합니다.
Kerberos를 사용하여 연결을 상호 인증하려면 SQL Server 인스턴스의 SPN(서비스 사용자 이름)을 Active Directory®에 등록하고 클라이언트 드라이버는 연결 시 등록된 SPN을 제공해야 합니다. SQL Server 2008에서는 Kerberos 인증이 TCP, 명명된 파이프, 공유 메모리 및 VIA(Virtual Interface Adapter)를 비롯한 모든 네트워크 프로토콜로 확대되었습니다. 기본적으로 클라이언트 드라이버는 연결된 SQL Server 인스턴스의 정확한 SPN을 자동으로 유추합니다. 또한 보다 효과적인 보안, 제어 및 문제 해결을 위해 연결 문자열 매개 변수에 SPN을 명시적으로 지정할 수도 있습니다.
IIS(인터넷 정보 서비스)는 ASP.NET, 보고서 관리자 또는 보고서 서버 웹 서비스에 대한 액세스를 더 이상 제공하지 않습니다. SQL Server 2008에서는 Reporting Services가 Windows 기반 및 사용자 지정 인증을 지원하는 새로운 인증 하위 시스템을 통해 모든 인증 요청을 처리합니다.
이제 Reporting Services에서 SQL Server CLR(공용 언어 런타임)에 기본 제공되는 Microsoft® .NET Framework 및 ASP.NET 기술을 호스트하며 OS의 HTTP.SYS 기능도 사용합니다. 보고서 서버에는 서버 구성 중에 정의한 포트 및 URL로 전달되는 요청을 수신하는 HTTP 수신기가 포함되어 있습니다. URL 예약 및 등록은 이제 HTTP.SYS를 통해 보고서 서버에서 직접 관리합니다.

보안 감사
SQL Server Audit는 데이터베이스 엔진 이벤트에 대한 사용자 지정 감사를 만들 수 있는 새로운 기능입니다. 이 기능에서는 확장된 이벤트를 사용하여 감사 정보를 기록하고 다양한 서버 및 데이터베이스 개체에 대한 감사를 사용, 저장 및 확인하는 데 필요한 도구와 프로세스를 제공합니다.
또한 SQL Server Audit는 SQL Server 추적보다 빠르며 SQL Server Management Studio를 사용하여 손쉽게 감사 로그를 만들고 모니터할 수 있습니다. 이제 개별 사용자에 대한 SELECT, INSERT, UPDATE, DELETE, REFERENCES 및 EXECUTE 문을 캡처하여 더 세부적인 수준으로 감사할 수 있습니다. 게다가 SQL Server Audit는 T-SQL 문인 CREATE SERVER AUDIT, CREATE SERVER AUDIT SPECIFICATION 및 관련 ALTER 및 DROP 문을 사용하여 완전한 스크립트가 가능합니다.
감사를 설정하려면 감사를 만들고 감사된 이벤트가 기록될 위치를 지정합니다. 감사는 Windows 보안 로그, Windows 응용 프로그램 로그 또는 지정한 위치의 파일에 저장할 수 있습니다. 그리고 감사의 이름을 지정하고 감사 파일에 대한 경로 및 최대 크기와 같은 감사 특성을 구성합니다. 또한 감사에 실패하면 SQL Server가 종료되도록 선택할 수도 있습니다. 감사된 이벤트를 둘 이상의 위치에 기록해야 하는 경우에는 둘 이상의 감사를 만듭니다.
다음 단계는 하나 이상의 감사 사양을 만드는 것입니다. 서버 감사 사양을 통해 SQL Server 인스턴스에 관한 정보가 수집됩니다. 이 사양에는 로그인 및 서버 역할 멤버 자격과 같은 서버 범위 개체를 포함하고, 데이터베이스 액세스 권한 등 master 데이터베이스에서 관리되는 데이터베이스 정보도 포함합니다. 감사 사양을 정의할 때에는 모니터된 이벤트를 수신할 감사를 지정할 수 있습니다. 서버 감사와 서버 감사 사양을 여러 개 정의할 수 있지만 각 서버 감사에는 한 번에 하나의 활성화된 서버 감사 사양만 포함될 수 있습니다.
또한 단일 데이터베이스에서 이벤트를 모니터하는 데이터베이스 감사 사양을 만들 수도 있습니다. 여러 데이터베이스 감사 사양을 감사에 추가할 수 있지만 한 서버 감사에서는 한 번에 데이터베이스당 하나의 데이터베이스 감사 사양만 활성화할 수 있습니다.
서버 감사 사양에 사용되는 SQL Server 감사 동작 이벤트는 관련된 감사 동작 이벤트 모음으로 그룹화되어 있습니다. 이러한 그룹은 감사 동작 그룹으로 제공됩니다. 감사 사양에 그룹을 추가하면 해당 그룹에 포함된 모든 이벤트를 모니터할 수 있습니다. 예를 들어 DBCC 명령을 제공하는 DBCC_GROUP이라는 감사 동작 그룹이 있습니다. 그러나 DBCC 명령을 개별적으로 감사에 사용할 수는 없습니다.
서버에 사용할 수 있는 감사 동작 그룹은 35개가 있으며 이 중에서 일부는 서로 밀접하게 관련되어 있습니다. SUCCESSFUL_LOGIN_GROUP, FAILED_LOGIN_GROUP 및 LOGOUT_GROUP을 예로 들 수 있습니다. 또한 감사 프로세스를 감사하는 데 사용할 수 있는 AUDIT_ CHANGE_GROUP 감사 동작 유형도 있습니다.
또한 데이터베이스 감사 사양에서는 데이터베이스 수준 감사 동작 그룹에 수집되는 감사 동작 이벤트의 그룹을 지정할 수도 있습니다. 감사 동작 그룹 외에도 데이터베이스 감사 사양에는 데이터 조작 언어 문을 감사하도록 개별 감사 동작 이벤트를 포함할 수 있습니다. 이러한 이벤트는 전체 데이터베이스를 모니터하거나 특정 데이터베이스 개체만 모니터하도록 구성할 수 있습니다. 예를 들어 SELECT 감사 동작을 단일 테이블 또는 전체 스키마의 SELECT 쿼리를 감사하는 데 사용할 수 있습니다. 또한 이러한 이벤트는 특정 사용자나 역할(예: 모든 db_writers)에 의한 동작을 모니터하도록 구성할 수도 있습니다.
예를 들어 SELECT 감사 동작을 통해 Mary 사용자나 FINANCE_DEPT 데이터베이스 역할 또는 공용 데이터베이스 역할에서 수행한 단일 테이블에 대한 SELECT 쿼리를 감사할 수 있습니다. 물론 사용자는 원하는 감사를 자유자재로 만들 수 있습니다.

종속성 보고
종속성 보고 기능은 새로운 카탈로그 뷰와 새로운 시스템 기능을 통해 개선되었습니다. sys.sql_expression_dependencies, sys.dm_sql_referencing_entities 및 sys.dm_sql_referenced_entities를 사용하는 경우 스키마 바운드 개체 및 비스키마 바운드 개체 모두에 대해 서버간 종속성, 데이터베이스간 종속성 및 데이터베이스 SQL 종속성을 보고할 수 있습니다.

새로운 데이터베이스 역할
msdb 데이터베이스에 포함된 데이터베이스 역할이 변경되었습니다. db_dtsadmin 역할 이름은 db_ssisadmin으로, db_dtsltduser 역할 이름은 db_ssisltduser로, db_dtsoperator 역할 이름은 db_ssisoperator로 바뀌었습니다. 이전 버전과의 호환성을 지원하기 위해 서버 업그레이드 시 이전 역할이 새로운 역할의 멤버로 추가됩니다.
이러한 변경 외에도 새로운 SQL Server 2008 기능을 지원하도록 새로운 데이터베이스 역할이 추가되었습니다. 특히 msdb 데이터베이스에는 서버 그룹(ServerGroupAdministratorRole 및 ServerGroupReaderRole), 정책 기반 관리(PolicyAdministratorRole) 및 데이터 수집기(dc_admin, dc_operator 및 dc_proxy)에 대한 새로운 역할이 포함되었습니다. 그리고 관리 데이터 웨어하우스 데이터베이스에는 데이터 수집기(mdw_admin, mdw_writer 및 mdw_reader)에 대한 새로운 역할이 포함되었습니다.

FILESTREAM 보안
이제 SQL Server에서는 FILESTREAM 저장소를 지원합니다. 이 지원을 통해 SQL Server 응용 프로그램은 문서 및 이미지 같은 구조화되지 않은 데이터를 파일 시스템에 저장할 수 있습니다. 따라서 클라이언트 응용 프로그램이 스트리밍 API와 파일 시스템의 성능을 통해 이점을 얻을 수 있을 뿐만 아니라 동시에 구조화되지 않은 데이터 및 해당 구조화된 데이터 간에 트랜잭션 일관성을 계속 유지할 수 있습니다.
FILESTREAM 데이터는 FILESTREAM 파일 그룹에 저장됩니다. 이 파일 그룹은 실제 파일 대신 파일 시스템 디렉터리가 포함된 특수한 파일 그룹입니다. 데이터 컨테이너라고 하는 이 디렉터리는 데이터베이스 엔진 저장소 및 파일 시스템 저장소 간에 인터페이스를 제공합니다.
보안 측면에서 보면 FILESTREAM 데이터는 다른 모든 데이터와 유사하게 보호됩니다. 즉, 테이블이나 열 수준에서 권한이 부여됩니다. FILESTREAM 컨테이너에 대한 NTFS 권한이 부여되는 유일한 계정은 SQL Server 서비스 계정이 실행되는 계정입니다. 데이터베이스를 열 때 T-SQL 트랜잭션 및 OpenSqlFilestream API를 사용하여 액세스하는 경우를 제외하고는 SQL Server가 FILESTREAM 데이터 컨테이너에 대한 액세스를 제한합니다.

정책 기반 관리
SQL Server 2008 정책 기반 관리에서는 SQL Server 관리를 위한 새로운 시스템을 제공합니다. SQL Server의 다양한 측면에서 테스트하고 보고하는 정책을 만들 수 있으며 이러한 정책은 단일 데이터베이스, SQL Server의 단일 인스턴스 또는 관리하는 모든 SQL Server에 적용할 수 있습니다.
정책 기반 관리를 통해 SQL Server 구성 옵션과 많은 보안 설정을 테스트할 수 있습니다. 그리고 일부 보안 설정에서는 정책을 준수하지 않는 데이터베이스 서버를 감지하고 이러한 데이터베이스 서버에게 정책을 강제로 준수하도록 단계별 조치를 취하는 정책을 만들 수 있습니다.
SQL Server 2008에서는 반드시 필요한 기능이 아닌 기능 상당수가 가능한 공격에 노출되는 것을 최소화할 수 있도록 기본적으로 해제되어 있습니다. 정책 기반 관리를 사용하면 필요한 추가 기능을 선택적으로 설정할 수 있습니다. 그리고 구성 설정이 정책에 맞지 않는 경우가 검색되면 경고가 표시되므로 정기적으로 구성을 평가할 수 있습니다.
정책 기반 관리는 관련된 속성을 그룹화하고 패싯이라는 구성 요소에서 이러한 속성을 제공합니다. 예를 들어 노출 영역 구성 패싯에는 임시 원격 쿼리, CLR 통합, 데이터베이스 메일, OLE 자동화, 원격 DAC, SQL 메일, 웹 길잡이 및 xp_cmdshell이 포함되어 있습니다. CLR 통합은 설정하지만 다른 모든 기능은 해제하는 정책을 만들 수 있습니다. 이 정책에는 이름을 Customer_Response로 지정하지 않는 한 모든 SQL Server 인스턴스에서 데이터베이스 메일 해제와 같은 복잡한 조건문을 포함할 수 있습니다.
정책을 만들었으면 모든 서버의 정책을 평가하여 이를 준수하지 않는 서버를 알려 주는 보고서를 생성할 수 있습니다. 구성 단추를 누르면 정책을 준수하지 않는 모든 인스턴스가 정책 설정을 사용하여 구성됩니다. 또한 서버 상태를 정기적으로 모니터하도록 정책을 예약해야 합니다. 노출 영역 구성 패싯은 데이터베이스 엔진, Analysis Services 및 Reporting Services에 대해 제공됩니다.
그러나 이 정책 기반 관리는 보안 적용 메커니즘으로 제공되는 것은 아닙니다. 대부분의 경우 충분한 권한이 있는 사용자는 정책을 위반하거나 정책을 무시하는 문을 실행하고 보안 정책을 위반할 수 있는 재구성 작업을 수행할 수 있습니다. SQL Server 2008 정책 기반 관리는 단순히 SQL Server 보안 설정을 모니터하는 데 유용한 보조 도구로만 간주해야 합니다.
패싯이 설정을 적용할 수 있는지 여부는 관련된 DDL 문이 비자동 커밋 모드에서 실행될 수 있는지 여부에 따라 달라집니다. 경우에 따라 패싯이 데이터베이스 엔진 인스턴스에 구성 설정을 적용할 수도 있지만 관리자 역시 이러한 설정을 다시 구성할 수 있습니다. 일부 패싯은 서버 트리거에 의해 실행될 수 있습니다. 이를 통해 권한이 낮은 사용자가 설정을 변경하지 못하도록 방지하고 관리자가 실수로 설정을 변경할 가능성을 줄일 수 있습니다. 이 경우 관리자는 설정을 변경하기 전에 정책을 임시로 해제해야 합니다. 또한 속성 상태를 보고만 할 수 있으며 속성을 변경할 수는 없는 패싯도 있습니다. 이러한 예로는 그림 2와 같이 대칭 키 또는 비대칭 키의 길이를 검사하는 정책이 설정된 패싯이 있습니다.
그림 2 비대칭 키에 대한 패싯
그림 2 비대칭 키에 대한 패싯
패싯은 대부분의 데이터베이스 개체 유형에 대해 제공되며 이들 중 상당수는 보안 용도로 사용됩니다. 예를 들어 로그인 패싯은 암호 정책이 각 로그인에 적용되는지 여부를 결정할 수 있으며 저장 프로시저 패싯은 모든 프로시저가 암호화되는지 여부를 확인할 수 있습니다. 또한 사용자, 스키마, 암호화 공급자, 일반 조건 호환성 및 C2 감사 속성을 테스트하는 패싯도 있습니다.

Windows Server 2008
SQL Server 2008은 방화벽이 설정된 상태로 함께 제공되는 Windows Server® 2008에서 충분한 테스트를 거쳤습니다. 이제 방화벽 설정을 구성하는 방법을 다시 살펴보는 것이 좋습니다. 그리고 Windows Server 2008에서는 Windows Vista®에서 이미 사용해 봤을 사용자 액세스 제어도 제공합니다. 이 사용자 액세스 제어는 관리자 사용자에게 자동으로 부여되는 권한을 제한합니다. 이 기능은 모든 SQL Server 버전에 영향을 줍니다.

결론
보안은 SQL Server의 계획적인 기능 향상에 있어 하나의 중요한 영역으로 간주되고 있습니다. 암호화 및 인증 기능 향상을 통해 새로운 기능이 추가되었으며 새로운 감사 시스템 및 SQL Server 2008 정책 기반 관리를 통해 보안 준수 상태를 모니터하는 새로운 도구를 사용할 수 있습니다.

Rick Byham은 1995년 Microsoft에 입사했습니다. 그는 고객 지원 서비스에서 SQL Server 지원 엔지니어로 근무했으며 그 후에는 Microsoft Learning의 SQL Server 팀에 합류했습니다. 2003년 Byham은 SQL Server 온라인 설명서 팀으로 자리를 옮겨 테크니컬 라이터로 활동하고 있으며 현재 보안 설명서를 담당하고 있습니다. 문의 사항이 있으면 rick.byham@microsoft.com으로 연락하시기 바랍니다.


 SQL Server 2008: 새로운 데이터 형식
SQL Server 2008 Kelly Wilson

새로운 데이터 형식
한 눈에 보기:
  • 새 날짜 및 시간 데이터 형식
  • 계층 구조의 위치 표현
  • 공간 데이터를 사용하는 두 가지 모델

오늘날의 전 세계 경제 환경에서 비즈니스를 수행하는 기업이 새로운 형식의 데이터와 응용 프로그램을 사용하고 복잡한 계산을 수행해야 할 필요성은 점차 증가하고 있습니다. SQL Server 2008에서 기본으로 제공하는 7가지 새로운 데이터 형식에 대해 알아보십시오.
새로운 데이터 형식을 사용하면 복잡한 데이터를 간편하게 사용하고 관리할 수 있습니다.

날짜 및 시간
이전의 datetime 데이터 형식에는 SQL Server® 사용자가 날짜와 시간 정보를 개별적으로 처리할 수 있는 기능이 없습니다. 이제 date, time, datetime2 및 datetimeoffset이라는 4가지 새로운 데이터 형식이 제공되므로 상황이 바뀌었습니다. 날짜 및 시간 데이터 작업이 훨씬 간단해지고 날짜 범위, 초 소수 부분 자릿수 및 표준 시간대 지원이 향상되었습니다. 새 데이터베이스 응용 프로그램에서는 기존 datetime 대신 이러한 새 데이터 형식을 사용해야 합니다. 새 데이터 형식에 대해 보다 자세히 살펴보겠습니다.
date 데이터 형식은 시간 구성 요소 없이 날짜를 저장합니다. 이 데이터 형식의 범위는 1000년 1월 1일부터 9999년 12월 31일까지입니다(0001-01-01에서 9999-12-31까지). 각 date 변수는 저장소로 3바이트를 사용하며 전체 자릿수는 10자리입니다. date 형식의 정확도는 1일로 제한됩니다.
그림 1에서는 T-SQL 스크립트에서 Date 변수를 만들고 초기화하는 방법을 보여 줍니다. @myDate1 변수는 'MM/DD/YYYY' 형식의 문자열로 초기화됩니다. @myDate2 변수는 초기화되지 않고 NULL 값을 가지게 됩니다. @myDate3 변수는 로컬 컴퓨터 시스템의 날짜로 초기화됩니다. 이 예에서 @myDate2 값을 변경하는 것처럼, 언제든지 SELECT 또는 SET 문을 사용하여 변수 값을 변경할 수 있습니다. 테이블에 date 열을 만들 수도 있습니다. 그림 2에서는 세 개의 date 열이 있는 테이블을 만드는 방법을 보여 줍니다.
Figure 2 세 개의 date 열이 있는 테이블 만들기 (Close Figure 2)
USE TempDB
GO

CREATE TABLE myTable
(
    myDate1 date,myDate2 date,myDate3 date
)
GO

INSERT INTO myTable
VALUES('01/22/2005',
       '2007-05-08 12:35:29.1234567 +12:15',
       GetDate())

SELECT * FROM myTable

--결과
--myDate1    myDate2    myDate3
------------ ---------- ----------
--2005-01-22 2007-05-08 2007-11-20
Figure 1 T-SQL 스크립트에서 date 변수 만들기 및 초기화 (Close Figure 1)
DECLARE @myDate1 date = '01/22/2005'
DECLARE @myDate2 date
DECLARE @myDate3 date = GetDate()

SELECT @myDate2 = '2007-05-08 12:35:29.1234567 +12:15'

SELECT @myDate1 AS '@myDate1',
       @myDate2 AS '@myDate2',
       @myDate3 AS '@myDate3'

--결과
--@myDate1   @myDate2   @myDate3
------------ ---------- ----------
--2005-01-22 2007-05-08 2007-11-20
time 데이터 형식은 날짜 구성 요소 없이 시간을 저장합니다. 이 데이터 형식은 24시간 형식에 기반을 두므로 지원되는 범위는 00:00:00.0000000부터 23:59:59.9999999까지입니다(시, 분, 초 및 초 소수). 초 소수 부분 자릿수는 데이터 형식을 만들 때 지정할 수 있습니다. 기본 전체 자릿수는 7자리이며 정확도는 100ns입니다. 전체 자릿수는 필요한 저장소 공간 크기에 영향을 미칩니다. 필요한 저장소 공간은 2자리까지는 3바이트, 3 또는 4자리에는 4바이트, 5에서 7자리까지는 5바이트입니다.
그림 3의 T-SQL 스크립트에서는 문자열 초기화 값의 암시적 변환이 변수 자릿수에 어떤 영향을 미치는지 보여 줍니다. T-SQL 코드에서는 먼저 time 변수 8개를 만들고 동일한 값으로 초기화합니다. 각 변수의 소수 부분 자릿수는 이름과 동일합니다. 예를 들어 @myTime3의 소수 부분 자릿수는 3자리입니다. 결과는 각 time 데이터 형식의 전체 자릿수가 해당 데이터 형식이 선언된 소수 부분 자릿수와 동일하다는 것을 보여 줍니다. 범위를 벗어나는 자릿수는 잘립니다.
Figure 3 time 데이터 형식의 변수 자릿수 표시 (Close Figure 3)
DECLARE @myTime  time = '01:01:01.1234567 +01:01'
DECLARE @myTime1 time(1) = '01:01:01.1234567 +01:01'
DECLARE @myTime2 time(2) = '01:01:01.1234567 +01:01'
DECLARE @myTime3 time(3) = '01:01:01.1234567 +01:01'
DECLARE @myTime4 time(4) = '01:01:01.1234567 +01:01'
DECLARE @myTime5 time(5) = '01:01:01.1234567 +01:01'
DECLARE @myTime6 time(6) = '01:01:01.1234567 +01:01'
DECLARE @myTime7 time(7) = '01:01:01.1234567 +01:01'

SELECT @myTime  AS '@myTime',
       @myTime1 AS '@myTime1',
       @myTime2 AS '@myTime2',
       @myTime3 AS '@myTime3',
       @myTime4 AS '@myTime4',
       @myTime5 AS '@myTime5',
       @myTime6 AS '@myTime6',
       @myTime7 AS '@myTime7'

--결과
--@myTime          @myTime1   @myTime2    @myTime3     @myTime4
------------------ ---------- ----------- ------------ -------------
--01:01:01.1234567 01:01:01.1 01:01:01.12 01:01:01.123 01:01:01.1235
--
--@myTime5       @myTime6        @myTime7
---------------- --------------- ----------------
--01:01:01.12346 01:01:01.123457 01:01:01.1234567

DROP TABLE myTable
time 데이터 형식을 테이블의 열로 만들 수 있습니다. 그림 4의 DROP TABLE myTable T-SQL 스크립트는 myTable1이라는 테이블을 만들고 time 열 세 개를 추가합니다. 그런 다음 테이블에 레코드를 삽입하고 SELECT 문을 사용하여 테이블의 내용을 표시합니다.
Figure 4 myTable1 만들기 (Close Figure 4)
USE TempDB
GO

CREATE TABLE myTable1
(
    myTime1 time(1),
    myTime2 time(2),
    myTime3 time(3)
)
GO

INSERT INTO myTable1
VALUES('01:30:01.1234567',
       '02:34:01.1234567',
       '03:01:59.1234567')

SELECT * from myTable1

--결과
--myTime1    myTime2     myTime3
------------ ----------- ------------
--01:30:01.1000000 02:34:15.1200000 03:01:59.1230000

DROP TABLE myTable1

Datetimeoffset 및 Datetime2
datetimeoffset 데이터 형식은 표준 시간대 인식 기능을 제공합니다. time 데이터 형식은 표준 시간대 정보를 포함하지 않으므로 현지 시간으로만 작동합니다. 하지만 전 세계를 대상으로 경제 활동을 하는 경우에는 한 지역의 시간이 다른 지역의 시간과 어떤 관계에 있는지 알아야 하는 경우가 많습니다. 표준 시간대 오프셋은 +/- hh:mm으로 표시됩니다.
다음 코드에서는 datetimeoffset 변수를 만들고 태평양 표준시인 오전 8:52 값으로 변수를 초기화합니다.
DECLARE @date DATETIMEOFFSET = '2007-11-26T08:52:00.1234567-08:00'
PRINT @date
--결과
--2007-11-26 08:52:00.1234567 -08:00
datetimeoffset 변수(스크립트의 @date)를 초기화하는 문자열은 중요한 요소가 먼저 배치되는 특별한 형식을 가지고 있습니다. 단일 대문자 T는 날짜와 시간 요소를 분리합니다. 빼기(-) 기호는 시간 요소와 표준 시간대를 분리합니다. 빼기(-) 기호와 시간 또는 표준 시간대 요소 사이에는 공백이 없습니다. 이 형식은 datetimeoffset 데이터 형식에서 지원되는 두 가지 ISO 8601 형식 중 하나입니다. ISO 8601은 날짜 및 시간 값 표현에 대한 국제 표준입니다.
시간 구성 요소의 전체 자릿수는 time 데이터 형식과 마찬가지로 지정되며, 전체 자릿수가 지정되지 않은 경우 기본값은 7자리로 동일합니다. 지원되는 범위도 같습니다.
datetime2 데이터 형식은 원래 datetime 형식의 확장입니다. datetime2 데이터 형식은 더 넓은 날짜 범위와 더 많은 초 소수 부분 자릿수를 지원하며, 전체 자릿수는 사용자 지정할 수 있습니다. 원래 datetime의 날짜 범위가 1753년 1월 1일부터 9999년 12월 31일까지인 것에 비해 datetime2 형식의 날짜 범위는 0001년 1월 1일부터 9999년 12월 31일까지입니다. time 형식과 마찬가지로 7자리의 초 소수 부분 자릿수가 제공됩니다. 원래 datetime 형식은 3자리 전체 자릿수와 00:00:00부터 23:59:59.999까지의 시간 범위를 제공했습니다. 다음은 datetime2 변수를 만들고 로컬 서버 날짜 및 시간으로 초기화하는 방법을 보여 줍니다.
DECLARE @datetime2 DATETIME2 = GetDate();
PRINT @datetime2

--결과
--2007-11-26 09:39:04.1370000
다음으로 새 hierarchyid 데이터 형식을 살펴보겠습니다. 이 데이터 형식은 특정 날짜나 시간 데이터가 아니라 테이블의 데이터 요소 간 관계에 사용합니다.

Hierarchyid 데이터 형식
hierarchyid 데이터 형식을 사용하면 테이블의 데이터 요소 간에서 계층적인 위치를 나타내는 관계를 구성할 수 있습니다. 이 데이터 형식을 탐색하려면 그림 5의 스크립트를 사용하여 MyCompany 데이터베이스를 만들고 직원 데이터로 데이터베이스를 채웁니다.
Figure 5 MyCompany 데이터베이스 만들기 및 채우기 (Close Figure 5)
USE MASTER
GO

CREATE DATABASE MyCompany
GO
USE MyCompany
GO

--MyCompany의 직원 데이터를 저장할
--직원 테이블을 만듭니다.

CREATE TABLE employee
(
    EmployeeID int NOT NULL,
    EmpName    varchar(20) NOT NULL,
    Title      varchar(20) NULL,
    Salary     decimal(18, 2) NOT NULL,
    hireDate   datetimeoffset(0) NOT NULL,
)
GO

--이 문은 MyCompany 직원의 데이터를 삽입합니다.

INSERT INTO employee
VALUES(6,   'David',  'CEO', 35900.00, '2000-05-23T08:30:00-08:00')

INSERT INTO employee
VALUES(46,  'Sariya', 'Specialist', 14000.00, '2002-05-23T09:00:00-08:00')

INSERT INTO employee
VALUES(271, 'John',   'Specialist', 14000.00, '2002-05-23T09:00:00-08:00')

INSERT INTO employee
VALUES(119, 'Jill',   'Specialist', 14000.00, '2007-05-23T09:00:00-08:00')

INSERT INTO employee
VALUES(269, 'Wanida', 'Assistant', 8000.00, '2003-05-23T09:00:00-08:00')

INSERT INTO employee
VALUES(272, 'Mary',   'Assistant', 8000.00, '2004-05-23T09:00:00-08:00')
GO
--결과
--EmployeeID  EmpName Title      Salary   hireDate
------------- ------- ---------- -------- --------------------------
--6           David   CEO        35900.00 2000-05-23 08:30:00 -08:00
--46          Sariya  Specialist 14000.00 2002-05-23 09:00:00 -08:00
--271         John    Specialist 14000.00 2002-05-23 09:00:00 -08:00
--119         Jill    Specialist 14000.00 2007-05-23 09:00:00 -08:00
--269         Wanida  Assistant  8000.00  2003-05-23 09:00:00 -08:00
--272         Mary    Assistant  8000.00  2004-05-23 09:00:00 -08:00
그림 6에서는 그 결과로 만들어진 단일 직원 테이블로 구성된 간단한 데이터베이스를 보여 줍니다. MyCompany 데이터베이스에서 이 직원 테이블에는 적용된 구조가 없습니다. 관계형 데이터베이스의 경우 응용 프로그램의 쿼리와 처리 코드를 통해 구조가 동적으로 적용되므로, 이것은 자연스러운 것입니다.
그림 6 MyCompany 직원 테이블
그림 6 MyCompany 직원 테이블
하지만 비즈니스 데이터는 일반적으로 기본 구조를 가지고 있습니다. 예를 들어 모든 비즈니스에는 보고 구조가 있습니다. 그림 7에서는 MyCompany의 보고 구조를 보여 줍니다. MyCompany의 모든 직원은 CEO인 David에게 보고합니다. Jill의 경우처럼 일부 직원은 직접 보고하지만 Mary와 같은 다른 직원은 중간 단계를 거쳐 보고합니다. 프로그래밍 용어로 MyCompany의 보고 구조는 나무와 같은 형태로 인해 트리 구조라고 합니다. 맨 위에 있는 David는 누구에게도 보고하지 않습니다. 즉, 부모 또는 상위 노드가 됩니다. David에게 보고하는 직원은 아래에 있습니다. 이러한 노드는 자식 또는 하위 노드라고 표현합니다. David는 자신에게 직접 보고하는 직원을 나타내는 하위 노드를 필요한 만큼 가질 수 있습니다.
그림 7 MyCompany의 조직 구조
그림 7 MyCompany의 조직 구조
그림 8의 스크립트는 hierarchyid 데이터 형식을 사용하여 MyCompany의 보고 구조와 일치하는 관계를 구성하여 MyCompany 데이터베이스를 다시 작성합니다. 먼저 ALTER TABLE 문을 사용하여 hierarchyid 형식의 열을 추가합니다. 그런 다음 hierarchyid의 GetRoot 메서드를 사용하여 David의 노드를 삽입합니다. 계속해서 GetDescendant 메서드를 사용하여 David에게 직접 보고하는 직원들을 트리에 추가합니다.
Figure 8 hierarchyid를 사용하여 데이터베이스 다시 작성 (Close Figure 8)
DELETE employee
GO
ALTER TABLE employee ADD OrgNode hierarchyid NOT NULL
GO

DECLARE @child hierarchyid,
@Manager hierarchyid = hierarchyid::GetRoot()

--첫 번째 단계로 트리의 맨 위에
--노드를 추가합니다. David는 CEO이므로 그의 노드는
--루트 노드가 됩니다.

INSERT INTO employee
VALUES(6,   'David',  'CEO', 35900.00,
       '2000-05-23T08:30:00-08:00', @Manager)

--다음으로 David에게 직접 보고하는 직원의
--레코드를 삽입합니다.

SELECT @child = @Manager.GetDescendant(NULL, NULL)

INSERT INTO employee
VALUES(46,  'Sariya', 'Specialist', 14000.00,
       '2002-05-23T09:00:00-08:00', @child)

SELECT @child = @Manager.GetDescendant(@child, NULL)
INSERT INTO employee
VALUES(271, ‚John',   ‚Specialist', 14000.00,
       '2002-05-23T09:00:00-08:00', @child)

SELECT @child = @Manager.GetDescendant(@child, NULL)
INSERT INTO employee
VALUES(119, ‚Jill',   ‚Specialist', 14000.00,
       ‚2007-05-23T09:00:00-08:00', @child)

--이제 Sariya에게 보고하는 직원을 삽입할 수
--있습니다.
SELECT @manager = OrgNode.GetDescendant(NULL, NULL)
FROM employee WHERE EmployeeID = 46

INSERT INTO employee
VALUES(269, ‚Wanida', ‚Assistant', 8000.00,
       ‚2003-05-23T09:00:00-08:00', @manager)

--그런 다음 John에게 보고하는 직원을 삽입합니다.
SELECT @manager = OrgNode.GetDescendant(NULL, NULL)
FROM employee WHERE EmployeeID = 271

INSERT INTO employee
VALUES(272, ‚Mary',   ‚Assistant', 8000.00,
       ‚2004-05-23T09:00:00-08:00', @manager)
GO
데이터베이스 레코드를 추가하고 계층 구조를 구성한 후에는 다음과 같은 쿼리를 사용하여 직원 테이블의 내용을 표시할 수 있습니다.
SELECT EmpName, Title, Salary, OrgNode.ToString() AS OrgNode
FROM employee ORDER BY OrgNode
GO
--결과
--EmpName  Title      Salary    OrgNode
---------- ---------- --------- -------
--David    CEO        35900.00  /
--Sariya   Specialist 14000.00  /1/
--Wanida   Assistant  8000.00   /1/1/
--John     Specialist 14000.00  /2/
--Mary     Assistant  8000.00   /2/1/
--Jill     Specialist 14000.00  /3/
OrgNode가 hierarchyid 열입니다. 결과에서 각 슬래시(/) 문자는 계층 구조 트리의 노드를 나타냅니다. David는 루트이므로 슬래시 하나로 표시되고, David에게 직접 보고하는 Sariya, John 및 Jill은 슬래시 표시가 두 개이므로 계층 구조에서 두 번째 노드임을 알 수 있습니다. 숫자 1, 2 또는 3은 해당 자식 노드의 순서를 나타냅니다. 이 시스템은 매우 유연하여 자식 노드를 필요에 따라 제거하거나 삽입하거나 추가할 수 있습니다. 예를 들어 John과 Jill 사이에 직원을 추가하면 해당 직원은 결과 집합에 /2.1/로 표시됩니다.
"Sariya에게 보고하는 직원은 누구입니까?"라는 질문에 답하려면 다음 T-SQL 코드와 같은 쿼리를 만들면 됩니다.
DECLARE @Sariya hierarchyid

SELECT @Sariya = OrgNode
FROM employee WHERE EmployeeID = 46

SELECT EmpName, Title, Salary, OrgNode.ToString() AS 'OrgNode'
FROM employee
WHERE OrgNode.GetAncestor(1) = @Sariya
GO
--결과
--EmpName Title     Salary  OrgNode
--------- --------- ------- -------
--Wanida  Assistant 8000.00 /1/1/
이 쿼리에서는 hierarchyid의 GetAncestor 메서드를 사용합니다. 이 메서드는 현재 hierarchyid 노드의 부모를 반환합니다. 이전 코드에서 @Sariya 변수는 Sariya에 대한 계층 구조 노드로 설정됩니다. 이것은 Sariya가 그녀에게 보고하는 모든 직원들의 직계 상위 노드이기 때문입니다. 따라서 Sariya에게 직접 보고하는 직원들을 반환하는 쿼리를 작성하려면 트리에서 Sariya의 노드를 검색한 후 상위 노드가 Sariya의 노드인 모든 직원을 선택합니다.
트리에서 노드를 나타내는 데 필요한 비트 수는 노드의 평균 자식 수(일반적으로 노드의 팬아웃이라고 함)에 따라 달라지므로 hierarchyid 열은 대개 매우 간결합니다. 예를 들어 100,000명의 직원이 있는 조직 계층 구조의 새 노드는 6단계의 평균 팬아웃(fanout)을 가지며 저장소에서 약 5바이트를 사용합니다.
hierarchyid 데이터 형식은 계층적 데이터를 쉽게 처리할 수 있는 몇 가지 메서드를 제공합니다. 이러한 메서드에 대한 요약이 그림 9에 나와 있습니다. 모든 메서드에 대한 자세한 내용은 SQL Server 온라인 설명서(msdn2.microsoft.com/ms130214)에서 확인할 수 있습니다.
Figure 9 hierarchyid 데이터 형식으로 제공되는 메서드 (Close Figure 9)

메서드 | 설명
GetAncestor | 해당 hierarchyid 노드의 n번째 상위 노드를 나타내는 hierarchyid를 반환합니다.
GetDescendant | 해당 hierarchyid 노드의 자식 노드를 반환합니다.
GetLevel | 전체 계층 구조에서 해당 hierarchyid 노드의 깊이를 나타내는 정수를 반환합니다.
GetRoot | 해당 계층 구조 트리에서 루트 hierarchyid 노드를 반환합니다. 정적입니다.
IsDescendant | 전달된 자식 노드가 해당 hierarchyid 노드의 하위 노드이면 true를 반환합니다.
Parse | 계층 구조를 나타내는 문자열을 hierarchyid 값으로 변환합니다. 정적입니다.
Reparent | 계층 구조 노드를 계층 구조 내의 새 위치로 이동합니다.
ToString | 해당 hierarchyid의 논리적 표현을 포함하는 문자열을 반환합니다.

공간 데이터 형식
공간 데이터는 주로 지구상의 지리적 위치와 형태를 식별하는 데이터입니다. 예를 들어 상징적인 건축물, 도로, 회사의 위치 등이 공간 데이터가 될 수 있습니다. SQL Server 2008은 이러한 형식의 데이터를 처리할 수 있는 geography 및 geometry 데이터 형식을 제공합니다.
geography 데이터 형식은 둥근 지구 정보를 사용하여 동작합니다. 둥근 지구 모델은 계산 시 지구의 굽은 표면을 고려합니다. 위치 정보는 경도와 위도로 지정됩니다. 이 모델은 지구 표면을 참조하는 대양 횡단 항해, 군사 계획 및 근거리 응용 분야와 같은 응용 프로그램에 적합합니다. 데이터를 위도와 경도로 저장하는 경우 사용하는 모델이 이 모델입니다.
geometry 데이터 형식은 평평한 지구 또는 평면 모델을 사용하여 동작합니다. 이 모델에서는 지구를 특정 지점에서 시작하는 평면 투영도로 취급합니다. 평평한 지구 모델은 지구의 곡률을 고려하지 않으므로 짧은 거리를 기술하는 데 주로 사용됩니다. 예를 들어 건물 내부를 측량하는 데이터베이스 응용 프로그램에 이 모델이 사용됩니다.
geography 및 geometry 형식은 WKT(Well-Known Text) 또는 WKB(Well-Known Binary) 형식으로 지정된 벡터 개체로 구성됩니다. 이러한 개체는 공간 데이터를 위한 전송 형식으로, OGC(Open Geospatial Consortium)의 Simple Features for SQL Specification에 설명되어 있습니다. 그림 10에서는 SQL Server 2008이 지원하는 7가지 벡터 개체 형식을 보여 줍니다.
Figure 10 SQL Server 2008에서 지원되는 벡터 개체 (Close Figure 10)

개체 | 설명
Point | 위치
MultiPoint | 일련의 점
LineString | 선으로 연결된 0개 이상의 일련의 점
MultiLineString | 일련의 linestring
Polygon | 일련의 닫혀진 linestring으로 기술되는 연속적인 영역
MultiPolygon | 일련의 다각형
GeometryCollection | geometry 형식의 컬렉션
하나 이상의 벡터 개체가 있는 geography 형식을 구성하려면 그림 11에서 볼 수 있는 것처럼 먼저 T-SQL 스크립트에서 geography 형식을 선언합니다. 그런 다음 그림 12에 나열된 메서드 중 하나를 호출하여 벡터 개체에 대한 문자열과 SRID(Spatial Reference ID)를 전달합니다. SRID는 European Petroleum Survey Group에서 정의한 공간 참조 식별 시스템으로, 지도 제작, 측량 및 측지 데이터 저장용으로 개발된 표준의 일부입니다. 각 SRID는 지리 계산에 사용할 특정 유형의 타원면을 식별합니다. 이것은 지구가 완전한 구가 아니기 때문에 필요합니다. SQL Server 2008은 SRID가 동일한 경우에만 계산을 수행할 수 있습니다.
Figure 12 geography 및 geometry에 대한 개체 구성 (Close Figure 12)

메서드 | 설명
STGeomFromText | 입력 텍스트에서 geography 인스턴스 형식을 구성합니다.
STPointFromText | 입력 텍스트에서 geography Point 인스턴스를 구성합니다.
STMPointFromText | 입력 텍스트에서 geography MultiPoint 인스턴스를 구성합니다.
STLineFromText | 입력 텍스트에서 geography LineString 인스턴스를 구성합니다.
STMLineFromText | 입력 텍스트에서 geography MultiLineString 인스턴스를 구성합니다.
STPolyFromText | 입력 텍스트에서 geography Polygon 인스턴스를 구성합니다.
STMPolyFromText | 입력 텍스트에서 geography MultiPolygon 인스턴스를 구성합니다.
STGeomCollFromText | 입력 텍스트에서 geography GeometryCollection 인스턴스를 구성합니다.
Figure 11 점, 선 및 다각형 geometry 만들기 (Close Figure 11)
DECLARE @geo1 geometry
SELECT @geo1 = geometry::STGeomFromText('POINT (3 4)', 0)
PRINT @geo1.ToString()

DECLARE @geo2 geometry
SELECT @geo2 = geometry::Parse('POINT(3 4 7 2.5)')
PRINT @geo2.STX;
PRINT @geo2.STY;
PRINT @geo2.Z;
PRINT @geo2.M;

DECLARE @geo3 geography;
SELECT @geo3 = geography::STGeomFromText(
    'LINESTRING(47.656 -122.360, 47.656 -122.343)', 4326);
SELECT @geo3.ToString();

--결과
--POINT (3 4)
--3
--4
--7
--2.5

DECLARE @gx geometry;
SET @gx = geometry::STPolyFromText(
    'POLYGON ((5 5, 10 5, 10 10, 5 5))', 0);
PRINT @gx.ToString();
--결과
--POLYGON ((5 5, 10 5, 10 10, 5 5))

Geography와 Geometry의 차이점
geography와 geometry 데이터 형식은 서로 다른 형식의 데이터를 처리하도록 설계되었으므로 몇 가지 주요한 차이점을 알고 있어야 합니다. geometry 데이터 형식에서는 거리와 면적이 인스턴스의 좌표와 동일한 측정 단위로 지정됩니다. 예를 들어 점 (0,0) 및 (6,8) 사이의 거리는 항상 10단위입니다. 하지만 위도와 경도로 표현되는 타원 좌표를 사용하는 geography 형식에서는 이와 다릅니다.
GEOMETRY 데이터 형식은 좌표를 위도와 경도의 쌍으로 표현할 경우 모순된 결과를 반환합니다. 다음 T-SQL 코드는 점 (90 0)과 (90 180) 사이의 거리를 계산합니다. 이 두 점 모두 북극을 나타내므로 두 점 사이의 거리는 0이어야 합니다. 하지만 GEOMETRY 형식에서는 거리가 180으로 계산됩니다.
DECLARE @g1 GEOMETRY, @g2 GEOMETRY, @g3 GEOGRAPHY, @g4 GEOGRAPHY
SELECT @g1 = GEOMETRY::STGeomFromText('POINT (90 0)', 0)
SELECT @g2 = GEOMETRY::STGeomFromText('POINT (90 180)', 0)

SELECT @g3 = GEOGRAPHY::STGeomFromText('POINT (90 0)', 4326)
SELECT @g4 = GEOGRAPHY::STGeomFromText('POINT (90 180)', 4326)
SELECT @g2.STDistance(@g1) AS 'GEOMETRY',
       @g4.STDistance(@g3) AS 'GEOGRAPHY';

--결과
--GEOMETRY               GEOGRAPHY
------------------------ ----------------------
--180                    0
공간 데이터의 방향 역시 두 데이터 형식에서 서로 다릅니다. geometry 데이터 형식에 사용되는 평면 시스템에서는 다각형 방향이 중요한 요소가 아닙니다. 예를 들어 좌표가 (0, 0), (10, 0), (0, 20), (0, 0)인 다각형은 좌표가 (0, 0), (0, 20), (10, 0), (0, 0)인 다각형과 동일한 것으로 간주됩니다. 하지만 geography 데이터 형식에 사용되는 데이터 모델에서는 지정된 방향이 없으면 다각형이 분명하지 않게 됩니다. 예를 들어 적도를 감싼 둥근 고리를 생각해보십시오. 이 고리로 기술되는 다각형은 남반구를 나타낼까요, 북반구를 나타낼까요? 요점은 geography 데이터를 사용할 때에는 방향과 위치를 정확하게 기술해야 한다는 것입니다.
SQL Server 2008에는 geography 데이터 형식에 대한 몇 가지 제한이 있습니다. 예를 들어 각 geography 인스턴스는 단일 반구 내에 들어가야 합니다. 반구보다 큰 공간 개체는 허용되지 않으며 ArgumentException이 발생하게 됩니다. 두 가지 입력이 필요한 geography 데이터 형식은 메서드의 결과가 단일 반구 내에 들어가지 않으면 NULL을 반환합니다.
SQL Server는 geography 및 geometry 인스턴스에 대한 작업을 수행할 수 있는 다양한 메서드를 제공합니다. 그림 13에서는 SQL Server 2008이 제공하는 메서드를 사용하여 공간 데이터를 처리하는 몇 가지 예를 보여 줍니다. 지면의 제약 때문에 이 항목에 대해 더 자세히 설명할 수 없지만 SQL Server 온라인 설명서에서 자세한 내용을 확인할 수 있습니다.
Figure 13 공간 데이터 사용 (Close Figure 13)
DECLARE @gm geometry;
DECLARE @gg geography;
DECLARE @h geography;

SET @gm = geometry::STGeomFromText('POLYGON((0 0, 13 0, 3 3, 0 13, 0 0),(2 2, 2 1, 1 1, 1 2, 2 2))', 0);
SELECT @gm.STArea();

--결과
--38

SET @gg = geography::STGeomFromText('LINESTRING(0 0, 5 5)', 4326);
--LINESTRING에서 약간 벗어난 점까지의 거리를 계산합니다.
SET @h = geography::STGeomFromText('POINT(4 4)', 4326);
SELECT @gg.STDistance(@h);

--결과
-- 430.182777043046

--LINESTRING의 점까지의 거리를 계산합니다.
SET @h = geography::STGeomFromText('POINT(5 5)', 4326);
SELECT @gg.STDistance(@h);

--결과
-- 0

DECLARE @temp table ([name] varchar(10), [geom] geography);

INSERT INTO @temp values ('Point', geography::STGeomFromText('POINT(
5 10)', 4326));
INSERT INTO @temp values ('LineString', geography::STGeomFromText(
'LINESTRING(13 5, 50 25)', 4326));
--LINESTRING의 점까지의 거리를 계산합니다.
--테이블 변수에 저장된 geography 개체에 대한 차원 수를 표시합니다.
INSERT INTO @temp values ('Polygon', geography::STGeomFromText(
'POLYGON((47.653 -122.358, 47.649 -122.348, 47.658 -122.348, 47.658 -122.358, 47.653 -122.358))', 4326));

SELECT [name], [geom].STDimension() as [dim]
FROM @temp;

--결과
--name       dim
------------ -----------
--Point      0
--LineString 1
--Polygon    2
여기서 다룬 SQL Server 2008의 새로운 7가지 데이터 형식에 대한 정보가 도움이 되기를 바랍니다.

Kelly Wilson은 소프트웨어 엔지니어링 분야에서 20년 이상 일했으며 SQL Server, 3D 그래픽, 게임 및 색채 연구 분야에서도 경력이 있습니다. Kelly는 현재 Microsoft의 SQL Server 그룹에서 프로그래밍 저술가로 근무하고 있습니다.


 SQL Server 2008: 데이터 웨어하우스 쿼리 성능
SQL Server 2008 Sunil Agarwal and Torsten Grabs and Joachim Hammer 박사

데이터 웨어하우스 쿼리 성능
한 눈에 보기:
  • 스타 조인 쿼리 최적화
  • 분할된 테이블 병렬 처리
  • 행 및 페이지 압축
  • 파티션 정렬 인덱싱된 뷰

SQL Server 2008은 이전 버전의 SQL Server보다 더 강력한 관계형 데이터 웨어하우징 기능을 제공하지만 어떻게 이러한 새 기술을 사용하여 수십억 개의 행을 기반으로 하는 의사 결정 지원을 위한 잘 작동하는 데이터 웨어하우스를 만들 수 있는지 궁금할 것입니다. 또는 어떤 기능을 사용해야 의사 결정 지원 쿼리와 보고서의 쿼리 성능을 최상으로 만들 수 있는지, 이 새로운 버전의 SQL Server®에서 현실적으로 어떤 종류의 성능 향상을 기대할 수 있는지 알고 싶을 것입니다.
출시가 가까워질수록 궁금한 점은 더 많아질 것입니다. SQL Server 2008에서 가장 중요한 성능 관련 데이터 웨어하우스 기능에 대해 자세히 다루는 이 문서가 여러분에게 도움이 되기를 바랍니다.

로컬 데이터베이스 설계: 다차원 모델링
트랜잭션 기반의 기간 업무(LOB) 응용 프로그램은 대개 정규화된 데이터베이스 스키마를 가지고 있습니다. 하지만 관계형 데이터 웨어하우스의 논리적 데이터베이스 스키마에서는 정규화를 그다지 중요하게 다루지 않습니다. 현재 많은 관계형 데이터 웨어하우스 설계는 Ralph Kimball과 Margy Ross가 공동 저술한 The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling을 통해 널리 알려진 차원 모델링 접근 방식을 따르고 있습니다.
데이터 웨어하우스를 오랫동안 다루어 보았다면 별모양 스키마와 눈송이 스키마 같은 관계형 데이터 웨어하우스의 일반적인 스키마 패턴에 대해 잘 알고 있을 것입니다. 차원 모델링에서는 차원 테이블과 팩트 테이블을 구분합니다. 차원 테이블은 제품, 고객, 매장, 국가 등의 마스터 데이터가 저장되는 테이블이고 팩트 테이블은 판매, 주문, 구매, 반품 등의 트랜잭션 데이터가 저장되는 테이블입니다.
차원 테이블과 팩트 테이블은 기본 키(PK)/외래 키(FK) 관계로 연결됩니다. 저장소 요구 사항을 최소화하기 위해 많은 데이터 웨어하우스는 FK 제약 조건을 강제하지 않으며 이를 통해 기반 인덱스의 저장소 오버헤드를 줄이고 팩트 테이블 유지 관리 비용을 낮춥니다. 대개 데이터 웨어하우스의 차원 테이블은 상당히 작아, 적게는 수천 개에서 많게는 수백만 개의 행을 유지합니다. 이와 달리 팩트 테이블은 수억 개에서 수십억 개에 이르는 행을 유지하는 매우 큰 테이블입니다. 따라서 논리적 설계에서 주의를 기울여야 하는 것은 팩트 테이블의 저장소 요구 사항입니다.
이 크기 요인은 팩트 테이블/차원 테이블 관계를 유지하기 위해 차원 테이블에서 선택해야 하는 키를 결정할 때도 영향을 미칩니다. 예를 들어 차원이 나타내는 엔터티의 실세계 식별자인 차원 비즈니스 키 기반의 복합 키는 대개 여러 열과 관련을 맺습니다. 팩트 테이블에 이러한 복합 키에 해당하는 외래 키가 있는 경우 여러 열 복합 키가 각 팩트 테이블 행에서 반복되므로 문제가 될 수 있습니다.
이 문제를 해결하기 위해 일반적으로 사용되는 방법은 팩트 테이블과 차원 간의 관계를 구현하는 작은 서로게이트 키를 사용하는 것입니다. 서로게이트 키는 차원 테이블의 인공적인 기본 키 역할을 수행하는 정수 형식의 ID 열입니다. 크기가 훨씬 작은 서로게이트 키를 참조하는 팩트 테이블을 사용하면 대규모 팩트 테이블에서 저장소 요구 사항을 상당히 줄일 수 있습니다. 그림 1에서는 차원 테이블 및 팩트 테이블과 함께 서로게이트 키를 사용하는 차원 모델링 데이터 웨어하우스 스키마를 보여 줍니다.
그림 1 팩트 테이블 하나와 차원 테이블 두 개가 있는 별모양 스키마 예제
그림 1 팩트 테이블 하나와 차원 테이블 두 개가 있는 별모양 스키마 예제
눈송이 스키마 설계에서는 하나 이상의 차원이 여러 수준으로 전파됩니다. 예를 들어 고객 차원이 고객, 국가 및 지역 수준으로 전파됩니다. 따라서 이 스키마 설계에서는 훨씬 큰 규모의 차원을 정규화해야 하며, 데이터가 과도하게 중복될 경우 문제가 발생할 수 있습니다. 수준은 개별 테이블로 표현되므로 이 스키마는 눈송이 형태를 갖게 됩니다. 이와 달리 별모양 스키마 설계에서는 스키마 차원이 테이블을 넘어 전파되지 않습니다. 별모양 스키마는 중앙의 팩트 테이블을 중심으로 차원 테이블이 그룹화된 별 형태를 갖게 됩니다.
차원 모델링된 별모양 스키마나 눈송이 스키마를 사용하면 의사 결정 지원 쿼리가 전형적인 패턴을 따르게 됩니다. 즉, 쿼리를 통해 팩트 테이블에서 여러 관심 측정값을 선택하고 서로게이트 키를 통해 팩트 행을 하나 이상의 차원과 조인하고 차원 테이블의 비즈니스 열에 필터 조건자를 배치하고 하나 이상의 비즈니스 열을 그룹화한 다음 일정 시간 동안 팩트 테이블에서 검색된 측정값을 집계합니다. 다음은 이 패턴을 보여 주는 예제입니다. 이러한 쿼리를 스타 조인 쿼리라고도 합니다.
select ProductAlternateKey,
CalendarYear,sum(SalesAmount)
from FactInternetSales Fact
     join DimTime
on Fact.OrderDateKey = TimeKey
     join DimProduct
on DimProduct.ProductKey =
   Fact.ProductKey
where CalendarYear between 2003 and 2004
      and ProductAlternateKey like 'BK%'
group by ProductAlternateKey,CalendarYear

실제 설계
관계형 데이터 웨어하우스의 많은 SQL 쿼리는 스타 조인 쿼리 구조를 따릅니다. 하지만 의사 결정권자는 기반 비즈니스 데이터를 새로운 방식으로 파악하기 위해 지속적으로 노력하므로 의사 결정 지원 쿼리는 대개 시간이 지나면서 변하게 됩니다. 이것이 데이터 웨어하우스 업무에서 임시 쿼리의 비율이 높은 이유이며 의사 결정 지원 쿼리와 차원 모델링된 데이터 웨어하우스 스키마의 실제 설계를 어렵게 만드는 원인입니다.
SQL Server를 사용하는 데이터 웨어하우스 설계자는 대개 SQL Server에서 제공하는 설계 초안이나 실제 설계를 기반으로 시작한 다음 시간이 지나 업무가 변화함에 따라 설계를 세밀하게 조정합니다. SQL Server의 설계 초안은 자유롭게 데이터 웨어하우스에 적용하고 변경할 수 있습니다. 이 작업을 수행할 경우 업데이트를 위한 인덱스 유지 관리로 인한 성능 영향과 인덱스의 저장소 요구 사항 같은 실제 데이터베이스 설계의 모범 사례를 고려해야 합니다.

팩트 테이블
설계 초안에서는 일반적인 스타 쿼리를 만들고 팩트 테이블에 대한 인덱스를 만든다고 가정합니다. 팩트 테이블의 클러스터형 인덱스에서는 여러 개의 차원 서로게이트 키 열(외래 키 열)을 인덱스 키로 사용합니다. 자주 사용되는 열은 인덱스 키 목록에 있어야 합니다. 이러한 인덱스 키 목록이 업무에서 자주 실행하는 쿼리에 대해 뛰어난 액세스 경로를 지원하는지 확인하기 위해 따로 시간을 할애할 수도 있습니다.
또한 설계 초안에서는 팩트 테이블의 차원 서로게이트(외래 키) 열 각각에 대해 비클러스터형 단일 열 인덱스를 만듭니다. 이러한 인덱스는 해당 차원 중 특정한 차원에 대해 대단히 효율적인 액세스 경로를 지원합니다.
클러스터형 인덱스의 목표는 업무 중에 실행되는 대부분의 쿼리에 뛰어난 성능을 지원하는 것입니다. 이와 달리, 비클러스터형 인덱스 집합의 목표는 특정 고객이나 제품에 대한 팩트 테이블 측정값을 가져오는 쿼리의 성능을 높이는 것입니다. 예를 들어 비클러스터형 인덱스를 사용하면 단일 고객에 대한 판매 데이터를 검색하기 위해 팩트 테이블을 검색할 필요가 없습니다.

차원 테이블
차원 테이블에 설계 초안을 적용할 때 각 차원 테이블에 대한 인덱스를 만들어야 합니다. 여기에는 차원의 서로게이트 키 열에 대한 비클러스터형 기본 키 제약 조건 인덱스와 차원 엔터티의 비즈니스 키 열에 대한 클러스터형 인덱스가 포함됩니다. 대규모 차원 테이블의 경우에는 선택도가 높은 조건자에서 자주 사용되는 열에 대한 비클러스터형 인덱스를 추가하는 것도 고려해야 합니다.
데이터 웨어하우스의 유지 관리 시간대에 실행되는 프로세스는 실행 시간이 중요한 경우가 많습니다. 클러스터형 인덱스를 사용하면 이 유지 관리 시간대에 효율적인 ETL(추출, 변환 및 로드)이 가능합니다. 예를 들어 느리게 변하는 차원이 있다면 기존 행은 적절히 업데이트되며 차원에 없는 행은 차원 테이블에 추가됩니다. 이 액세스 패턴이 성공적이려면 ETL 시점에 차원 테이블을 조회하고 업데이트하는 성능이 좋아야 합니다.
설계 초안은 SQL Server로 구축되는 관계형 데이터 웨어하우스를 실제로 설계하기 위한 좋은 시작점입니니다. 이 대표적인 관계형 데이터 웨어하우스 설정을 기반으로 SQL Server 2008의 새로운 주요 기능을 탐색해 볼 수 있습니다.

스타 조인 쿼리 최적화
차원 모델링된 관계형 데이터 웨어하우스에서 스타 조인 쿼리를 실행할 때 가장 많은 비용이 드는 부분은 대개 팩트 테이블 처리입니다. 선택도가 높은 쿼리의 경우에도 차원 테이블과 비교할 때 팩트 테이블에서 10배 이상의 행을 검색하므로 이 사실을 쉽게 확인할 수 있습니다. 따라서 팩트 테이블로 연결되는 최선의 액세스 경로를 사용하는 것이 뛰어난 쿼리 성능을 얻는 데 필수적입니다.
SQL Server의 쿼리 최적화 프로그램은 자동으로 여러 대체 경로 중에 예상 비용이 가장 낮은 액세스 경로를 선택합니다. 데이터 웨어하우스의 핵심 목표는 쿼리 최적화 프로그램이 스타 조인 쿼리의 실행 계획에서 가능성 있는 모든 대체 액세스 경로를 고려하도록 하는 것입니다. SQL Server의 쿼리 최적화 프로그램에는 뛰어난 성능의 스타 조인 쿼리 실행 계획을 자동으로 제공할 수 있도록 하는 다양한 기능이 포함되어 있습니다.
그림 2에서 볼 수 있는 것처럼, 스타 조인 쿼리는 크게 세 가지 분류로 나뉜다고 생각할 수 있습니다. 이 대략적인 분류는 SQL Server 엔진에서 각 쿼리에 맞는 적절한 계획을 선택할 때도 도움이 됩니다. SQL Server에서 사용하는 기본 개념은 팩트 테이블에 대한 쿼리의 선택도입니다. 쿼리는 팩트 테이블에서 사용하는 행 수가 적을수록 선택도가 높다고 간주됩니다. 팩트 테이블에서 검색되는 행의 비율이 이러한 쿼리 분류의 직관적인 근거로 사용됩니다. 이러한 비율은 일반적인 고객 배포를 통해 얻은 값을 나타내며 액세스 경로 정의를 생성할 때 사용되는 엄격한 경계는 아닙니다.
그림 2 스타 조인 쿼리의 선택도 범위
그림 2 스타 조인 쿼리의 선택도 범위
첫 번째 분류에는 팩트 테이블에서 최대 10%의 행을 처리하는 선택도가 높은 쿼리가 포함됩니다. 중간 선택도가 포함되는 두 번째 분류는 팩트 테이블 행의 10%부터 최대 75%까지 처리하는 쿼리로 구성됩니다. 낮은 선택도의 세 번째 분류에 속하는 쿼리는 팩트 테이블에 저장된 행의 75% 이상을 처리합니다. 그림의 상자에는 각 선택도 분류에 속하는 기본 쿼리 실행 계획이 강조 표시되어 있습니다.

선택도 기반의 계획 선택
선택도가 높은 스타 쿼리는 대개 팩트 테이블 행의 10% 미만을 검색하므로 팩트 테이블에 대한 임의 액세스가 가능합니다. 따라서 이 분류에 대한 쿼리 계획은 중첩 루프 조인과 함께 팩트 테이블에 대한 (비클러스터형) 인덱스 검색 및 책갈피 조회에 크게 의존하게 됩니다. 이 분류의 쿼리는 팩트 테이블에 대해 임의 I/O를 수행하므로 팩트 테이블의 상당한 부분을 검색해야 하는 순차적 I/O에 비해 성능이 훨씬 뛰어납니다. 따라서 팩트 테이블의 행 수가 특정 기준을 넘게 되면 여러 쿼리 계획에서 이 분류의 쿼리를 고려하게 됩니다.
선택도가 중간인 스타 쿼리는 팩트 테이블에서 상당한 비율의 행을 처리하므로, 대개 팩트 테이블 검색이나 팩트 테이블 범위 검색을 사용하는 해시 조인이 팩트 테이블의 선호되는 액세스 경로입니다. SQL Server는 비트맵 필터를 사용하여 이러한 해시 조인의 성능을 향상시킵니다.
그림 3에서는 SQL Server가 스타 조인 쿼리 실행 중에 비트맵 필터를 사용하여 조인 성능을 향상시키는 방법을 보여 줍니다. 이 그림에서는 서로게이트 키로 팩트 테이블이 조인되는 Product와 Time이라는 두 차원 테이블에 대한 쿼리 계획을 보여 줍니다. 쿼리에서는 두 차원 모두에 대해 WHERE 절과 같은 필터 조건자를 사용하여 한 행이 한 차원만 한정하게 만듭니다. 이것은 두 조인 연산자 옆에 있는 작은 빨간색 테이블로 표시됩니다.
그림 3 조인 감소 처리를 사용하는 스타 조인 쿼리 계획
그림 3 조인 감소 처리를 사용하는 스타 조인 쿼리 계획
각 조인의 조인 구현은 해시 조인이므로 SQL Server가 두 차원 테이블 모두에 대해 조인 감소 정보라고 하는 한정 열에 대한 정보를 차원 테이블에서 사용할 수 있습니다. 그림의 녹색 상자는 조인 감소 정보 데이터 구조를 나타냅니다. 기반 차원 테이블에서 정보가 입력되면 SQL Server가 쿼리 실행 중에 자동으로 이러한 데이터 구조를 팩트 테이블을 처리하는 연산자(예: 테이블 검색)에 전달합니다. 그러면 연산자가 차원 테이블 행에 대한 정보를 사용하여 차원에 대한 조인 조건을 한정하지 않는 팩트 테이블 행을 제거합니다.
SQL Server는 쿼리를 처리하는 동안 아주 초기 단계인 팩트 테이블에서 행을 검색한 직후에 이러한 팩트 테이블 행을 정리합니다. 이렇게 하면 쿼리 계획의 이후 연산자에서 정리된 행을 처리할 필요가 없으므로 CPU 사용량이 줄어들고 디스크 I/O가 줄어들 가능성도 있습니다. SQL Server는 쿼리 실행 시간에 비트맵 표현을 사용하여 조인 감소 정보 데이터 구조를 효율적으로 구현합니다.

스타 조인 최적화 파이프라인
최적화 프로세스에서는 조인 쿼리 최적화에 대한 표준적인 추론을 사용하여 대안 쿼리 실행 계획의 초기 집합을 생성합니다. 그런 다음 특수한 용도의 확장 기능을 호출하여 추가적인 대안 쿼리 계획을 생성합니다.
데이터 웨어하우스의 경우에는 확장 기능이 별모양 스키마, 눈송이 스키마 및 스타 쿼리 패턴을 검사하여 팩트 테이블에 대한 쿼리의 선택도를 추정합니다. 스키마 및 쿼리 형태가 패턴과 일치하면 SQL Server가 자동으로 계획 공간에 후속 쿼리 계획을 추가하며, 계속해서 비용 기반 최적화에 의해 이러한 쿼리 계획 중에서 실행 시 가장 성능이 좋을 것으로 예상되는 쿼리 계획이 선택됩니다.
또한 쿼리 실행 시 SQL Server는 런타임의 실제 조인 감소 선택도를 모니터링합니다. 선택도가 변하는 경우 SQL Server는 조인 감소 정보 데이터 구조를 동적으로 재배치하여 가장 선택도가 높은 쿼리를 먼저 적용합니다.

스타 조인 추론 기능
데이터 웨어하우스의 많은 실제 설계는 별모양 스키마를 따르지만 앞서 외래 키 제약 조건에서 설명한 것처럼 팩트 테이블과 차원 테이블 간의 관계를 완전하게 지정하지는 않습니다. 외래 키 제약 조건을 명시적으로 지정하지 않는 경우 SQL Server는 추론에 의존하여 별모양 스키마 쿼리 패턴을 검색해야 합니다. 스타 조인 쿼리 패턴을 검색하는 데는 다음과 같은 추론이 적용됩니다.
  1. n항 조인에 참여하는 테이블 중 가장 큰 테이블이 팩트 테이블로 간주되며 팩트 테이블의 최소 크기에 대한 추가 제한이 있습니다. 예를 들어 가장 큰 테이블이 지정된 크기보다 작으면 n항 조인이 스타 조인으로 간주되지 않습니다.
  2. 스타 조인 쿼리에서 이항 조인의 모든 조인 조건은 단일 열 동등 조건자여야 하며, 조인은 내부 조인이어야 합니다. 다소 제한적으로 느껴질 수도 있지만 이러한 조건은 일반적인 별모양 스키마에서 서로게이트 키에 대한 팩트 테이블과 차원 테이블 간의 거의 모든 조인에 적용됩니다. 조인에 위에서 설명한 패턴에 맞지 않는 보다 복합적인 조인 조건이 있는 경우에는 해당 조인이 스타 조인에서 제외됩니다. 예를 들어 5개 경로가 있는 조인에서 두 조인 경로가 패턴에 맞지 않는 복합 조인 조건자를 갖는다면 해당 조인은 3개 경로가 있는 스타 조인이 됩니다(추가 조인 두 개는 나중에 처리됨).
이것이 추론 규칙이라는 것을 기억하십시오. 추론에서 차원 테이블을 팩트 테이블로 선택하게 되는 실제 상황은 거의 없습니다. 추론이 계획 선택에 영향을 미치지만 선택된 계획의 정확성에는 영향을 미치지 않습니다. 계속해서 스타 조인에 포함된 이항 조인은 선택도가 낮아지는 순서로 정렬됩니다. 이 컨텍스트의 조인 선택도는 팩트 테이블의 입력 카디널리티와 조인의 결과 카디널리티 비율로 정의됩니다. 조인 선택도는 특정 차원이 팩트 테이블의 카디널리티를 줄이는 정도를 나타냅니다. 일반적인 규칙으로, 선택도가 높은 조인을 먼저 고려합니다.
결과 쿼리 계획의 예상 쿼리 비용이 적절한 경우 SQL Server의 쿼리 프로세서가 스타 조인 패턴과 앞서 설명한 조건에 따라 쿼리에 자동으로 최적화를 적용합니다. 따라서 응용 프로그램을 변경하지 않아도 상당한 성능 향상 효과를 얻을 수 있습니다. 조인 감소와 같은 일부 스타 조인 최적화는 SQL Server Enterprise Edition에서만 사용할 수 있다는 점에 유의하십시오.

스타 조인 성능 결과
SQL Server 2008의 스타 조인 최적화를 개발하는 노력의 일환으로, Microsoft에서는 벤치마크와 실제 고객 작업에 기반한 성능 연구를 다양하게 수행했습니다. 이러한 작업 중 세 가지 결과는 살펴볼 가치가 있습니다.
Microsoft 영업부 데이터 웨어하우스 이 작업에서는 Microsoft 영업부의 의사 결정 지원을 위해 내부적으로 사용되는 데이터 웨어하우스의 성능을 추적합니다. 이를 위해 인덱스를 포함해 약 750GB 크기의 데이터베이스 샘플 스냅숏을 만들었습니다. 이 작업의 쿼리는 많은 수가 10개 이상의 조인을 가지고 있기 때문에 쿼리 처리가 어렵습니다.
정품 고객 이 일련의 실험은 일반 매장과 온라인 매장을 모두 가진 소매 업종의 데이터 웨어하우징 고객을 대상으로 합니다. 이 고객의 특징은 차원 모델링된 눈송이형 스키마와 정식 스타 조인 쿼리를 사용한다는 것입니다. 실험을 위해 약 100GB의 원시 데이터를 웨어하우스 스냅숏에 입력했습니다.
의사 결정 지원 작업 이 일련의 실험에서는 100GB의 차원 모델링된 데이터베이스에서 의사 결정 지원 작업의 성능을 조사합니다. 그림 4에서는 이 세 작업의 결과를 보여 줍니다. 이 그림에서는 작업의 모든 쿼리에 대한 쿼리 응답 시간의 정규화된 기하 평균을 보여 줍니다. 이 메트릭은 작업에서 임의 쿼리를 실행할 때 어떤 쿼리 성능을 기대할 수 있는지 나타내는 뛰어난 지표입니다. 그림의 막대 그래프는 스타 조인 최적화를 사용하지 않는 기준 성능(1.0)을 스타 조인으로 최적화된 성능과 비교합니다. 모든 쿼리는 SQL Server 2008을 사용하여 수행되었습니다.
그림 4 스타 조인 최적화를 통한 성능 향상
그림 4 스타 조인 최적화를 통한 성능 향상
그림에서 볼 수 있는 것처럼 모든 작업이 12%에서 최대 30%까지 크게 향상됩니다. 개별적인 성능 향상 수준은 다를 수 있지만 SQL Server 2008의 새 기능인 스타 조인 관련 최적화 확장 기능을 통해 SQL Server 엔진을 사용하는 의사 결정 지원 작업이 약 15–20% 향상될 것으로 예상하고 있습니다.

분할된 테이블 병렬 처리
대규모 데이터 웨어하우스의 쿼리 처리 속도를 높이기 위해 데이터베이스 관리자는 대규모 팩트 테이블을 날짜별로 분할하는 경우가 많습니다. 이렇게 하면 데이터가 서로 다른 파일 그룹에 배치되어 특정 데이터 범위에 속한 행을 처리할 때 검색해야 하는 데이터 양이 줄어들 뿐만 아니라 많은 수의 실제 디스크에 파일 그룹을 배포할 때 기반 디스크 시스템의 동시성이 향상됩니다.
SQL Server 2005에서는 규모가 큰 관계를 작은 논리적 조각으로 분할하여 대규모 테이블의 유지 관리 성능을 개선하는 방법이 사용되었습니다. 또한 대규모 의사 결정 지원 응용 프로그램 등의 쿼리 처리 성능이 크게 향상되었습니다.
하지만 안타깝게도 SQL Server 2005를 사용하는 일부 고객은 이 분할된 테이블의 쿼리와 관련된 성능 문제를 겪고 있습니다. 특히 병렬 공유 메모리 다중 프로세서 컴퓨터에서 SQL Server 2005를 실행할 경우 문제가 심각합니다. SQL Server 2005에서 분할된 테이블에 대해 병렬 쿼리를 처리할 때 사용 가능한 스레드의 일부만 쿼리 실행에 할당되는 경우가 있습니다.
코어가 64개인 컴퓨터를 가정해 보겠습니다. 이 경우 쿼리는 최대 64개의 스레드를 병렬로 사용할 수 있으며 파티션 두 개를 사용합니다. SQL Server 2005는 64개 스레드 중에서 2개만 받기 때문에 컴퓨터 CPU 처리 능력의 3.1%(2/64)만 사용하게 됩니다. 일부 쿼리의 경우 분할된 팩트 테이블의 쿼리 성능이 동일한 컴퓨터에서 동일한 팩트 테이블의 분할되지 않은 버전에서 동일한 쿼리를 수행할 때의 성능보다 10배 이상 떨어지는 것이 보고되었습니다.
이 시점에서 SQL Server 2005는 단일 파티션을 사용하는 쿼리에 최적화되었다는 것을 언급해야겠습니다. 단일 파티션의 경우 쿼리 프로세서는 모든 사용 가능한 스레드를 할당하여 검색을 수행합니다. 이 특수한 최적화는 다중 코어 컴퓨터에서 단일 파티션 쿼리의 성능을 상당히 향상시킵니다. 따라서 고객이 다중 파티션을 사용하는 쿼리에 대해서도 같은 동작을 기대하는 것은 당연한 일입니다.
SQL Server 2008의 새로운 분할된 테이블 병렬 처리(PTP) 기능은 쿼리가 사용하는 파티션 수나 개별 파티션의 상대적인 크기에 관계없이 기존 하드웨어의 처리 성능을 최대한 활용하여 분할된 테이블에서 실행되는 쿼리의 성능을 향상시킵니다. 분할된 팩트 테이블이 있는 일반적인 데이터 웨어하우스의 경우 병렬 계획에서 실행하는 쿼리의 성능이 크게 향상되는 것을 확인할 수 있습니다. 특히 쿼리에 영향을 받는 파티션의 수보다 사용할 수 있는 프로세서 코어 수가 많다면 성능 향상이 두드러집니다. 이 새로운 기능은 어떠한 조정이나 구성 작업 없이 설치 즉시 사용할 수 있습니다.
판매 날짜별로 구분된 판매 데이터를 나타내는 팩트 테이블이 네 개의 파티션에 분할되어 있다고 가정해 보겠습니다. 그림 5의 다이어그램은 이 예제를 알기 쉽게 보여 줍니다. 전체 날짜 범위에 대해 단일 클러스터형 인덱스를 사용하는 대신, 분할되지 않은 팩트 테이블의 경우와 마찬가지로 각 파티션에 있는 팩트 테이블의 날짜 열에 클러스터형 인덱스가 있습니다. 이제, 지난 일주일의 판매 현황을 요약하는 Q라는 쿼리를 가정합니다. 새 판매 데이터는 팩트 테이블의 마지막 파티션(P4)에 계속 입력되지만 쿼리는 실행되는 시점에 따라 여러 파티션을 사용하게 됩니다. 다이어그램의 첫 번째 행에서 이것을 볼 수 있습니다. 즉, Q1 쿼리는 단일 파티션만 사용하지만 실행 시점에 관련 데이터가 P3 및 P4 파티션에 걸쳐 있는 Q2 쿼리는 두 개의 파티션을 사용합니다.
그림 5 새 PTP 기능의 작동 방식
그림 5 새 PTP 기능의 작동 방식
이제 사용할 수 있는 스레드가 8개라고 가정해 보겠습니다. SQL Server 2005에서 Q1 및 Q2를 실행하면 예기치 않은 동작이 발생할 수 있습니다. SQL Server 2005에서는 최적화 프로그램이 컴파일 시에 쿼리가 단일 파티션만 사용한다는 것을 인식하면 해당 파티션을 분할되지 않은 단일 테이블로 취급하고 모든 사용 가능한 스레드를 할당하여 테이블에 액세스하는 계획을 생성하는 방식으로 최적화를 수행합니다.
결과적으로 단일 파티션(P3)과 관련된 Q1은 8개의 스레드로 처리되는 계획을 만들게 됩니다(표시 안 됨). 하지만 두 개의 파티션을 사용하는 Q2의 경우에는 기반 하드웨어에 추가로 사용할 수 있는 스레드가 있음에도 실행기가 각 파티션에 단일 스레드를 할당합니다. 따라서 Q2는 사용 가능한 CPU 처리 능력 중 극히 일부만 사용하게 되고 대개 Q1보다 상당히 느리게 실행됩니다.
SQL Server 2008에서 Q1 및 Q2를 실행하면 하드웨어를 훨씬 잘 활용하게 되고 더 뛰어난 성능과 예측 가능한 결과 동작이라는 이점을 얻게 됩니다. 즉, Q1의 경우에는 이전과 마찬가지로 실행기가 사용 가능한 8개 스레드 모두를 할당하여 P2에 있는 데이터를 처리합니다(표시 안 됨). 하지만 Q2의 경우 실행기가 모든 사용 가능한 스레드를 라운드 로빈 방식으로 P3과 P4에 할당하는 병렬 계획이 만들어지므로, 다이어그램의 맨 아래 행에서 볼 수 있는 것처럼 두 파티션이 각각 4개의 스레드를 할당 받는 효과가 나타납니다. 따라서 CPU 처리 능력을 최대한 사용하게 되므로 Q1과 Q2의 성능이 비슷해집니다.
이 라운드 로빈 스레드 할당 방식을 사용하면 쿼리가 액세스하는 파티션 수보다 많은 수의 프로세서 코어를 사용하여 쿼리 성능을 향상시킬 수 있습니다. 그러나 유감스럽게도 파티션에 대한 스레드 할당이 이 예제의 경우처럼 간단하지 않은 경우가 많습니다.
다중 코어 프로세서 컴퓨터의 분할된 테이블 시나리오에 있어서, SQL Server 2005와 비교하여 SQL Server 2008에서 얻을 수 있는 성능 이점에 대한 자세한 설명은 그림 6을 참조하십시오. 이 그래프는 분할된 테이블의 검색 성능을 강조하여 보여 줍니다. 64개의 코어와 256GB의 RAM이 있는 시스템에서 수행된 이 테스트의 경우 121GB의 단일 테이블을 각각의 크기가 11GB인 11개의 파티션으로 분할했습니다. 이 그림에서 설명하는 일련의 테스트를 위해 콜드 및 웜 버퍼 시작을 모두 사용하는 힙 파일 구조를 사용했습니다. 모든 쿼리는 데이터에 대한 단순한 검색을 수행합니다.
그림 6 새 PTP 기능을 사용하는 SQL Server의 검색 성능
그림 6 새 PTP 기능을 사용하는 SQL Server의 검색 성능
y축은 응답 시간(초)을 나타내고 x축은 병렬 처리 수준(DOP)을 나타냅니다. 여기에서 DOP는 쿼리에 할당된 스레드 수와 유사합니다. 그림에서 확인할 수 있는 것처럼, 콜드 부팅과 웜 부팅 모두에서 DOP가 22에 도달할 때까지 응답 시간이 지속적으로 감소합니다. 콜드 부팅의 경우 DOP가 22에 도달하면 I/O 시스템이 가득 차게 됩니다. 이것은 이 예제에 사용된 쿼리가 I/O에 바인딩되어 있기 때문입니다. CPU에 바인딩된 작업이 더 많은 경우에는 이 제한이 나타나지 않거나 훨씬 높은 DOP에서 나타날 수 있습니다.
하지만 웜 부팅을 나타내는 곡선은 DOP 수준이 증가함에 따라 응답 시간이 계속 감소함을 보여 줍니다. SQL Server 2005에서는 다중 파티션을 처리할 때 파티션당 스레드 수가 1로 제한되기 때문에 DOP 11 근처에서 두 곡선이 평탄해지기 시작합니다.
DOP의 숫자를 늘려 얻을 수 있는 응답 시간 감소가 실제로는 선형이 아니라는 것을 기억해야 합니다. 예상되는 동작은 선형보다는 계단 함수를 닮았습니다. 이것은 쿼리가 본질적으로 가장 느린 부분이 완료될 때까지 대기해야 한다는 현실을 반영합니다. 즉, 모든 검색이 추가 스레드를 받아 모두 함께 빨라지기 전까지는 검색에 한두 개의 스레드를 추가해도 쿼리 완료 시간이 향상되지 않습니다.
Microsoft에서는 다른 다양한 하드웨어와 파일 구성에서 새 PTP의 동작을 테스트하는 추가 실험을 했습니다. 이러한 실험에서도 파티션당 스레드가 1 이상이 되는 DOP 증가 시점에 처리량이 증가하는 유사한 동작이 관찰되었습니다.
마지막으로 한 가지 중요한 사실을 더 언급하면, SQL Server 2008의 새 PTP 기능은 쿼리 계획의 가독성을 향상시키며 특정 작업이 어떻게 실행되는지 보다 잘 이해할 수 있게 해 줍니다. 예를 들어 XML 실행 계획에서 병렬 및 직렬 계획을 표현하는 방식, 컴파일 타임 실행 계획과 런타임 실행 계획 모두에 제공되는 분할 정보 등 PTP 기능에 속하는 여러 기능이 향상되었습니다.

데이터 압축
비즈니스 인텔리전스가 보편화되면서 데이터 웨어하우스에 저장되어 분석해야 하는 데이터의 양도 함께 늘어나고 있습니다. 그에 따라 관리가 필요한 데이터 크기도 기하급수적으로 증가하고 있습니다. 1995년에 처음 수행된 Winter Corporation의 데이터베이스 크기 조사에서 보고된 세계에서 가장 큰 시스템은 테라바이트 크기의 데이터를 포함하는 것이었습니다. 십 년이 지난 지금, 규모가 큰 데이터베이스는 그보다 100배 이상 큽니다. 더 놀라운 사실은 데이터 웨어하우스 크기가 2년마다 세 배로 커지고 있다는 것입니다. 그로 인해 대량의 데이터를 관리하고 데이터 웨어하우스 쿼리의 성능을 적절하게 유지하는 것과 관련된 새로운 어려움이 생겨났습니다. 이러한 데이터 웨어하우스 쿼리는 대개 많은 조인과 집계를 포함한 복잡한 쿼리이며 엄청난 양의 데이터에 액세스합니다. 또한 작업에 사용되는 쿼리가 I/O에 바인딩되는 경우도 있습니다.
네이티브 데이터 압축의 목표는 이 문제를 해결하는 것입니다. SQL Server 2005 SP2에는 소수점과 숫자 데이터를 위한 새로운 가변 길이 저장소 형식인 vardecimal 저장소 형식이 도입되었습니다. 이 새 저장소 형식을 사용하면 데이터베이스 크기를 크게 줄일 수 있습니다. 그에 따라 공간이 절약되므로 두 가지 측면에서 I/O 바인딩된 쿼리의 성능이 향상됩니다. 첫째는, 더 적은 수의 페이지를 읽음으로써 얻게 되는 성능 향상입니다. 두 번째는, 데이터가 버퍼 풀에 압축된 상태로 유지되므로 페이지 기대 수명(요청된 페이지를 버퍼에서 찾을 가능성)이 향상되는 것입니다. 물론, 데이터 압축을 통한 공간 절약 방식의 데이터 압축과 압축 해제 프로세스 때문에 CPU 비용이 발생합니다.
SQL Server 2008은 행 압축과 페이지 압축이라는 두 종류의 압축 방식을 제공하여 vardecimal 저장소 형식을 구축합니다. 행 압축은 모든 고정 길이 데이터 형식을 가변 길이 저장소 형식으로 저장하여 vardecimal 저장소 형식을 확장합니다.
정수, 문자, 부동 소수점 등이 고정 길이 데이터 형식의 몇 가지 예입니다. SQL Server가 이러한 데이터 형식을 가변 길이 형식으로 저장하지만 데이터 형식의 의미 체계는 그대로 유지됩니다. 즉, 응용 프로그램 관점에서 데이터 형식은 계속 고정 길이 데이터 형식입니다. 이것은 응용 프로그램을 변경하지 않아도 데이터 압축의 이점을 얻을 수 있다는 의미입니다.
페이지 압축은 지정된 페이지의 하나 이상의 행에서 열의 데이터 중복을 최소화합니다. 이 압축 방식은 LZ78(Lempel-Ziv) 알고리즘의 독점적인 구현을 사용하여 중복되는 데이터를 페이지에 한 번만 저장한 후 여러 열에서 참조하도록 합니다. 페이지 압축을 사용할 때 실제로는 행 압축이 포함된다는 점에 유의하십시오.
행 및 페이지 압축은 테이블이나 인덱스 또는 분할된 테이블 및 인덱스에 대한 하나 이상의 파티션에 사용할 수 있습니다. 테이블, 인덱스 및 파티션을 압축할 수 있는 완벽한 융통성이 제공되므로 공간 절약과 CPU 사용량 간에서 적절한 균형을 이루는 선택을 할 수 있습니다. 그림 7에서는 정렬된 인덱스를 통해 서로 다른 방식으로 분할된 판매 테이블을 사용하여 이러한 균형을 보여 줍니다.
그림 7 서로 다른 압축 설정의 분할된 테이블
그림 7 서로 다른 압축 설정의 분할된 테이블
각 파티션은 분기를 나타내며 10-12월이 마지막 분기입니다. 처음 두 파티션은 자주 액세스되지 않으며 세 번째 파티션은 중간, 마지막 파티션이 가장 활발하게 액세스된다고 가정해 보겠습니다. 이 경우 가능한 구성 중 하나는 처음 두 파티션에는 페이지 압축을 사용하여 작업 성능에 미치는 영향을 최소화하면서 공간을 최대한으로 절약하고 세 번째 파티션에는 행 압축을 사용하고 마지막 파티션에는 압축을 사용하지 않는 것입니다.
Alter Table 또는 Alter Index DDL(데이터 정의 언어) 문을 사용하여 오프라인 또는 온라인 상태에서 압축을 사용할 수 있습니다. 또한 SQL Server는 절약할 수 있는 공간 크기를 예측하는 저장 프로시저를 제공합니다. 절약할 수 있는 공간의 크기는 압축 대상 개체의 스키마와 데이터 분포에 따라 달라집니다.
많은 고객 데이터베이스를 사용한 테스트에서 확인된 결과에 따르면, 대부분의 고객이 데이터베이스 크기를 50–65% 줄이고 I/O 바인딩된 쿼리의 성능을 상당히 향상시킬 수 있습니다. 하지만 CPU 바인딩된 쿼리의 성능에 미치는 영향을 예상하는 작업에는 약간의 기술이 필요하며 쿼리의 복잡성에 따라 결과가 달라집니다. SQL Server에서 압축 해제 비용은 인덱스나 테이블에 액세스할 경우에만 발생합니다. 검색 연산자의 상대적인 CPU 비용이 쿼리의 전체 CPU 비용에 비해 낮은 경우(대부분의 데이터 웨어하우스 시나리오가 이에 해당) CPU 사용률에 미치는 영향은 20-30% 이하입니다.

파티션 정렬 인덱싱된 뷰
SQL Server 2008에서 파티션 정렬 인덱싱된 뷰를 사용하면 관계형 데이터 웨어하우스의 요약 집계를 보다 효율적으로 만들고 관리할 수 있으며 이전에는 효율이 떨어졌던 시나리오에 이 요약 집계를 사용할 수 있게 됩니다. 이를 통해 쿼리 성능이 향상됩니다. 일반적인 시나리오에는 날짜별로 분할된 팩트 테이블이 있습니다. 쿼리 속도를 높이기 위해 이 테이블에서 인덱싱된 뷰(또는 요약 집계)가 정의됩니다. 새 테이블 파티션으로 전환할 때는 파티션 정렬 인덱싱 뷰의 일치하는 파티션이 분할된 테이블 스위치에도 정의되며 이 작업은 자동으로 수행됩니다.
이것은 ALTER TABLE SWITCH 작업을 사용하여 파티션을 전환하기 전에 분할된 테이블에 정의된 모든 인덱싱된 뷰를 삭제해야 하는 SQL Server 2005에 비해 기능이 상당히 개선된 것입니다. SQL Server 2008의 파티션 정렬 인덱싱된 뷰 기능에는 분할된 전체 테이블에서 집계를 다시 구축할 필요 없이 대규모 분할된 테이블에서 인덱싱된 뷰를 사용할 수 있다는 이점이 있습니다. 또한 집계와 인덱싱된 뷰 일치가 자동으로 유지 관리된다는 이점도 있습니다.

파티션 수준 잠금 에스컬레이션
SQL Server는 관리 효율성을 위해 데이터를 분할하거나 사용 패턴에 따라 데이터를 그룹화할 수 있는 범위 분할을 지원합니다. 예를 들어 판매 데이터를 월별이나 분기별로 분할할 수 있습니다. 파티션을 고유한 파일 그룹에 매핑할 수 있으며, 파일 그룹은 파일 집합에 매핑할 수 있습니다. 이러한 매핑으로 두 가지 이점을 얻을 수 있습니다. 첫째, 파티션을 독립적인 단위로 백업하고 복원할 수 있습니다. 둘째, 파일 그룹을 사용 패턴이나 쿼리 부하에 따라 빠르거나 느린 I/O 하위 시스템에 매핑할 수 있습니다.
여기서 흥미로운 점은 데이터 액세스 패턴입니다. 쿼리와 DML 작업은 파티션의 일부분만 액세스하거나 조작해야 합니다. 예를 들어 2004년의 판매 데이터를 분석하는 경우 관련 파티션만 액세스해야 하며, 이상적인 경우 시스템 리소스를 제외하면 다른 파티션의 데이터에 동시에 액세스하는 쿼리의 영향을 받지 않아야 합니다. SQL Server 2005에서는 다른 파티션의 데이터에 대한 동시 액세스가 테이블 잠금으로 이어져 다른 파티션에 대한 액세스에 영향을 미칠 수 있습니다.
이러한 간섭을 최소화하기 위해 SQL Server 2008에는 파티션 또는 테이블 수준에서 잠금 에스컬레이션을 제어하는 테이블 수준 옵션이 도입되었습니다. SQL Server 2005와 마찬가지로 잠금 에스컬레이션은 기본적으로 테이블 수준에서 설정됩니다. 하지만 테이블에 대한 잠금 에스컬레이션 정책을 재정의할 수 있습니다. 예를 들어 다음과 같은 명령으로 잠금 에스컬레이션을 설정할 수 있습니다.
Alter table <mytable> set (LOCK_ESCALATION = AUTO)
이 명령을 사용하면 SQL Server가 테이블 스키마에 적합한 잠금 에스컬레이션 세분성을 선택합니다. 테이블이 분할되어 있지 않으면 잠금 에스컬레이션은 테이블 수준이 됩니다. 테이블이 분할되어 있으면 잠금 에스컬레이션 세분성은 파티션 수준이 됩니다. 이 옵션은 SQL Server가 테이블 수준에서 잠금 세분성을 제한하는 힌트로 사용되기도 합니다.

결론
이 문서는 관계형 데이터 웨어하우스에서 의사 결정 지원 쿼리의 성능을 향상시킬 수 있는 SQL Server 2008의 향상된 기능에 대한 간략한 개요일 뿐입니다. 또한 의사 결정 지원 쿼리의 빠른 응답 시간이 중요하기는 하지만 이 문서의 범위를 넘어서는 다른 중요한 요구 사항이 있을 수 있다는 점을 명심해야 합니다.
관계형 데이터 웨어하우스와 관련된 몇 가지 추가 기능은 다음과 같습니다.
  • T-SQL에서 단일 명령으로 (차원) 데이터의 업데이트, 삭제 또는 삽입을 수행하고 데이터베이스에 라운드 트립하는 MERGE 구문 지원
  • 보다 효율적인 ETL을 가능하게 만드는 SQL Server 엔진의 최적화된 로깅 성능
  • T-SQL로 집계 의사 결정 지원 쿼리를 손쉽게 작성할 수 있도록 하는 Grouping Sets
  • 전체 백업과 증분 백업 모두에서 I/O 요구 사항을 줄이는 백업 압축
  • 서로 다른 작업에 대한 시스템 리소스 할당을 제어하는 리소스 관리
SQL Server 웹 페이지(microsoft.com/sql)에서 다른 모든 놀라운 기능을 자세하게 살펴보시기 바랍니다.
전문 기술과 관련된 조언을 해 주신 Boris Baryshnikov, Prem Mehra, Peter Zabback 그리고 Shin Zhang 씨에게 감사 드립니다.

Sunil Agarwal은 Microsoft의 SQL Server 저장소 엔진 그룹에서 선임 프로그램 관리자로 근무하고 있으며 동시성, 인덱스, tempdb, LOBS, 지원 가능성 및 대량 가져오기/내보내기 기능을 담당하고 있습니다.
Torsten Grabs는 Microsoft의 SQL Server 팀의 핵심 저장소 엔진 그룹에서 선임 프로그램 관리자로 근무하고 있습니다. Torsten Grabs는 데이터베이스 시스템 분야의 박사 학위를 보유하고 있으며 10년 이상의 SQL Server 개발 경험을 가지고 있습니다.
Joachim Hammer 박사는 Microsoft의 쿼리 처리 그룹에서 프로그램 관리자로 근무하고 있습니다. 그의 전문 분야는 대규모 데이터 웨어하우스 응용 프로그램의 쿼리 최적화이며 분산 쿼리, ETL, 정보 통합 등에도 전문 지식을 가지고 있습니다.


 SQL Server: SQL Server의 차단 최소화
SQL Server Cherié Warren

SQL Server의 차단 최소화
한 눈에 보기:
  • 잠금 에스컬레이션이 발생하는 이유
  • 불필요한 차단 방지
  • 쿼리 최적화
  • 잠금이 성능에 미치는 영향 모니터링

잠금은 데이터베이스에서 동시 읽기 및 쓰기 작업을 지원하는 데 필수적인 반면, 차단은 시스템 성능에 부정적인(때로는 미미한 방식으로) 영향을 줄 수 있습니다. 이 기사에서는 차단을 최소화할 수 있도록 SQL Server 2005나 SQL Server 2008 데이터베이스를 최적화하는 방법과
잠금이 성능에 미치는 영향을 보다 효과적으로 파악할 수 있도록 시스템을 모니터링하는 방법에 대해 살펴보겠습니다.

잠금 및 에스컬레이션
SQL Server®는 잠금에 영향을 받는 레코드 수와 시스템에 존재하는 동시 작업을 기준으로 가장 적절한 잠금 수준을 선택합니다. 기본적으로 SQL Server는 가장 작은 수준의 잠금을 선택하며, 시스템 메모리를 보다 효율적으로 사용할 수 있는 경우에만 성긴 잠금을 선택합니다. SQL Server는 에스컬레이션이 전체 서버 성능에 도움이 된다면 잠금을 에스컬레이션합니다. 그림 1에서 볼 수 있듯이 특정 검색에서 잠금 수가 5,000개를 초과하거나 시스템에서 잠금에 사용된 메모리가 사용 가능한 용량을 초과하면 에스컬레이션이 발생합니다.
그림 1 잠금 에스컬레이션을 일으키는 조건
그림 1 잠금 에스컬레이션을 일으키는 조건
  • 잠금 설정이 0인 경우 데이터베이스 엔진에 사용된 비AWE(Address Windowing Extensions) 메모리의 24%
  • 잠금 설정이 0이 아닌 경우 데이터베이스 엔진에 사용된 비AWE 메모리의 40%
에스컬레이션이 발생하면 항상 테이블이 잠깁니다.

불필요한 차단 방지
차단은 모든 잠금 수준에서 발생할 수 있지만, 에스컬레이션이 발생하면 차단 노출이 증가합니다. 잠금 에스컬레이션은 응용 프로그램이 비효율적으로 디자인, 코딩 또는 구성되었다는 신호일 수 있습니다.
좁은 범위의 키를 통해 정규화된 스키마를 사용하고 트랜잭션 시스템에서 대량 데이터 작업을 피하는 등 데이터베이스 디자인의 기본 사항을 준수하는 것은 차단을 방지하는 데 중요합니다. 트랜잭션 시스템에서 보고 시스템을 분리하거나 업무 시간 외에 데이터 피드를 처리하는 등 원칙을 따르지 않으면 시스템을 튜닝하기가 어려워집니다.
인덱싱은 데이터 액세스에 필요한 잠금 수를 결정하는 데 중요한 요소가 될 수 있습니다. 인덱스는 데이터베이스 엔진에서 수행해야 하는 내부 조회 수를 줄임으로써 쿼리에서 액세스하는 레코드의 수를 줄일 수 있습니다. 예를 들어 테이블의 인덱싱되지 않은 열에서 단일 행을 선택할 경우 테이블의 각 행은 원하는 레코드가 확인될 때까지 임시로 잠겨 있어야 합니다. 반대로 이 열이 인덱싱되어 있으면 단일 잠금만 필요합니다.
SQL Server 2005와 SQL Server 2008에는 누적된 사용 통계를 기준으로 인덱스를 통해 이점을 얻는 테이블과 열을 보여 주는 동적 관리 뷰(sys.dm_db_missing_index_group_stats, sys.dm_db_missing_index_groups, sys.dm_db_missing_index_details)가 포함되어 있습니다.
또한 조각화도 성능에 영향을 줄 수 있습니다. 즉, 데이터베이스 엔진은 조각화로 인해 더 많은 페이지에 액세스해야 할 수 있습니다. 더욱이 잘못된 통계로 인해 쿼리 최적화 프로그램에서 효율성이 떨어지는 계획을 선택할 수도 있습니다.
인덱스는 데이터 액세스 속도를 높이지만 기본 데이터를 변경해야 할 뿐만 아니라 인덱스도 업데이트해야 하므로 인덱스로 인해 데이터 수정 속도가 느려질 수 있습니다. 동적 관리 뷰 sys.dm_db_index_usage_stats에는 인덱스가 사용되는 빈도가 강조되어 표시됩니다. 비효율적 인덱싱의 흔한 예로는 격리 및 조합 시 동일한 열이 인덱싱되는 복합 인덱스를 들 수 있습니다. SQL Server는 왼쪽에서 오른쪽으로 인덱스에 액세스하므로 맨 왼쪽 열이 유용한 경우에는 인덱스가 사용됩니다.
테이블을 분할하면 차단 노출을 최소화할 수 있도록 시스템을 최적화하고 데이터를 개별적으로 경쟁할 수 있는 별도의 물리적 개체로 분할할 수 있습니다. 행 파티션을 사용하면 데이터를 보다 명확하게 분리할 수 있지만, 데이터를 가로로 분할하는 또 다른 방법도 생각해 볼 수 있습니다. 테이블을 행과 키의 개수는 같지만 열이 다른 개별 테이블로 분할하는 방법을 통해 의도적으로 비정규화함으로써 개별 프로세스가 동시에 데이터에 독점적으로 액세스할 가능성을 줄일 수도 있습니다.
응용 프로그램이 특정 데이터 행에 액세스하는 방법이 다양해지고 이러한 행에 포함되는 열이 많아질수록 열 분할 방식의 장점이 더욱 부각될 수 있습니다. 경우에 따라서는 이러한 방식이 응용 프로그램 큐와 상태 테이블에 유용할 수도 있습니다. SQL Server 2008에서는 파티션마다(또는 테이블에 대해 파티션이 설정되어 있지 않은 경우에는 테이블마다) 잠금 에스컬레이션을 해제하는 기능을 제공합니다.

쿼리 최적화
쿼리 최적화는 성능을 향상시키는 데 중요한 역할을 합니다. 다음과 같은 세 가지 방법을 사용할 수 있습니다.
트랜잭션 단축 차단을 줄일 뿐만 아니라 전반적인 성능을 향상시키는 가장 중요한 방법 중 하나는 트랜잭션을 가능한 작게 만드는 것입니다. 관련 데이터 조회, 인덱싱 및 데이터 정리 등 트랜잭션 무결성에 있어 중요하지 않은 모든 처리 작업을 제거하여 트랜잭션의 크기를 줄여야 합니다.
SQL에서는 각각의 문을 암시적 트랜잭션으로 간주합니다. 이러한 문이 다수의 행에 영향을 주는 경우 단일 문이 큰 트랜잭션을 구성할 수 있습니다. 특히, 관련된 열이 많거나 열에 큰 데이터 형식이 포함되어 있는 경우가 이에 해당합니다. 또한 단일 문을 사용하면 채우기 비율이 높은 경우 또는 UPDATE 문이 할당된 것보다 큰 값으로 열을 채우는 경우 페이지가 분할될 수 있습니다. 이 경우 트랜잭션을 여러 행으로 분할하고 완료될 때까지 한 번에 하나씩 처리하는 것이 좋습니다. 일괄 처리는 성공하든 또는 실패하든 하나의 작업 단위로 완료된 것으로 간주할 수 있는 보다 작은 일괄 처리로 개별 문이나 여러 개의 문을 분할할 수 있는 경우에만 고려해야 합니다.
트랜잭션 순서 지정 트랜잭션 내에서 의도적으로 문의 순서를 지정하면 차단 가능성을 줄일 수 있습니다. 이 경우 주의해야 할 두 가지 원칙이 있습니다. 첫째, 시스템의 모든 SQL 코드 내에서 동일한 순서로 개체에 액세스합니다. 일정한 순서 없이 두 개의 경쟁 프로세스가 서로 다른 순서로 데이터에 액세스하는 경우 교착 상태가 발생하여 프로세스 중 하나에 시스템 오류가 발생할 수 있습니다. 둘째, 자주 액세스하는 개체 또는 액세스하는 데 많은 비용이 드는 개체를 트랜잭션 끝에 배치합니다. SQL은 트랜잭션에서 필요할 때까지 개체를 잠그기 위해 대기합니다. "핫 스폿"에 대한 액세스를 지연시키면 이들 개체가 더 짧은 시간 동안 잠금을 유지할 수 있습니다.
잠금 힌트 사용 잠금 힌트는 특정 테이블 또는 뷰의 세션 수준 또는 문 수준에서 사용할 수 있습니다. 세션 수준 힌트를 사용하는 일반적인 시나리오로는 데이터 웨어하우스의 일괄 처리가 있습니다. 이 경우 개발자는 해당 데이터 집합에서 지정된 시간에 하나의 프로세스만 실행된다는 것을 알 수 있습니다. 저장 프로시저 시작 부분에서 SET ISOLATION LEVEL READ UNCOMMITTED와 같은 명령을 사용하면 SQL Server가 읽기 잠금을 예약하지 않으므로 전체 잠금 오버헤드가 줄어들고 성능이 향상됩니다.
문 수준 힌트를 사용하는 일반적인 시나리오로는 개발자가 더티 읽기가 안전하게 이루어짐(예: 다른 동시 프로세스에서는 필요하지 않은 단일 행을 테이블에서 읽는 경우)을 알고 있는 경우 또는 다른 모든 성능 튜닝 조치가 실패하여(스키마 디자인, 인덱스 디자인 및 유지 관리, 쿼리 튜닝 등) 개발자가 특정한 유형의 힌트를 사용하도록 컴파일러를 강제 실행하려고 하는 경우가 있습니다.
행 잠금 힌트는 쿼리에 영향을 받는 레코드가 거의 없어서 차단이 줄어들 수 있는 보다 큰 수준의 잠금이 발생한 경우에 도움이 될 수 있습니다. 테이블 잠금 힌트는 테이블의 거의 모든 레코드가 쿼리에 영향을 받아서 잠금을 유지하는 데 필요한 시스템 리소스가 줄어들 수 있는 보다 작은 수준의 잠금이 유지(에스컬레이션되지 않음)되는 경우에 유용할 수 있습니다. 잠금 힌트를 지정하더라도 잠금 수가 시스템 메모리 임계값에 도달할 때 잠금이 에스컬레이션되지 않는 것은 아닙니다. 그러나 잠금 힌트를 지정하면 다른 모든 에스컬레이션은 차단됩니다.

구성 조정
그림 2에서 볼 수 있듯이 SQL Server 시스템을 구성할 때 고려해야 요소가 많이 있습니다.
그림 2 SQL Server에서 잠금에 사용할 수 있는 메모리 크기를 결정하는 방식
그림 2 SQL Server에서 잠금에 사용할 수 있는 메모리 크기를 결정하는 방식
메모리 잠금은 항상 비AWE 메모리에 유지되므로 비AWE 메모리의 크기를 늘리면 잠금을 유지할 시스템 용량이 늘어납니다.
비AWE 메모리 크기는 64비트 아키텍처에서는 제한이 없지만 32비트 아키텍처에서는 4GB로 제한되므로 잠금 용량을 늘리려면 64비트 아키텍처를 선택해야 합니다.
32비트 시스템에서는 Boot.ini 파일에 /3GB 스위치를 추가하여 SQL Server가 설치된 운영 체제에서 메모리(GB)를 추가로 확보할 수 있습니다.
SQL Server 구성 설정 잠금에 영향을 주는 sp_configure를 통해 여러 가지 설정을 조정할 수 있습니다. 잠금 설정을 통해 오류가 발생하기 전에 시스템에서 유지할 수 있는 잠금 수를 구성합니다. 기본 설정은 0입니다. 이는 메모리 확보를 위해 경쟁하는 다른 프로세스에 예약된 잠금이 서버에서 동적으로 조정됨을 의미합니다. SQL은 초기에 2,500개의 잠금을 예약하고 각각의 잠금에는 96바이트의 메모리가 사용됩니다. 페이징 메모리는 사용되지 않습니다.
최소 및 최대 메모리 설정에서는 SQL Server에 사용되는 크기의 메모리가 예약되므로 메모리를 정적으로 유지하도록 서버가 구성됩니다. 잠금 에스컬레이션은 사용 가능한 메모리와 관련이 있으므로 경쟁 중인 프로세스에서 예약하는 메모리 크기는 에스컬레이션 발생 여부에 영향을 줄 수 있습니다.
연결 설정 기본적으로 차단을 유발하는 잠금에는 제한 시간이 없지만, @@LOCK_TIMEOUT 설정을 사용할 수는 있습니다. 이 설정을 사용하면 잠금 해제에 대해 지정한 대기 임계값이 초과될 경우 오류가 발생합니다.
추적 플래그 특히, 잠금 에스컬레이션과 관련하여 두 가지 추적 플래그가 있습니다. 하나는 잠금 에스컬레이션을 해제하는 추적 플래그 1211입니다. 소비된 잠금 수가 사용 가능한 메모리를 초과하면 오류가 발생합니다. 또 다른 하나는 개별 문에 대해 잠금 에스컬레이션을 해제하는 추적 플래그 1224입니다.

시스템 관찰
추가 정보
  • Inside Microsoft SQL Server 2005: The Storage Engine(저자: Kalen Delaney)
  • SQL Server 2005 및 SQL Server 2000 블로킹을 모니터링하는 방법
  • SQL Server 2005 성능 통계 스크립트
  • SQL Server의 잠금 에스컬레이션으로 인해 발생한 차단 문제 해결 방법
  • 잠금 에스컬레이션(데이터베이스 엔진)

지정된 간격으로(예: 시간별) 상태 데이터를 폴링하고 유지된 잠금에 대한 현재 통계를 캡처하여 차단과 잠금이 전체 시스템 성능에 미치는 영향을 모니터링할 수 있습니다. 캡처할 주요 정보는 다음과 같습니다.
  • 영향 받는 개체, 수준 및 잠금 유형
  • 잠금 및 차단 기간
  • 실행된 SQL 명령(저장 프로시저 이름, 내부 SQL 문)
  • 차단 체인 정보(해당하는 경우)
  • 시스템에서 사용 가능한 잠금 용량을 소비하는 방식
그림 3에서 볼 수 있듯이 스크립트를 실행하여 이 정보를 캡처하고 적절한 타임스탬프를 통해 테이블에 기록할 수 있습니다. 그리고 차단된 데이터의 ResourceId를 추가로 분석하여 그림 4에서처럼 스크립트를 실행할 수 있습니다.
Figure 4 차단된 데이터에 대한 자세한 정보 (Close Figure 4)
DECLARE @SQL                           nvarchar(max)
      , @CallingResourceType           varchar(30)
      , @Objectname                    sysname
      , @DBName                        sysname
      , @resource_associated_entity_id int

-- TODO: 조회할 개체의 변수 설정

SET @SQL = N'
USE     ' + @DbName + N'
DECLARE @ObjectId int

SELECT  @ObjectId = CASE
                    WHEN @CallingResourceType = ''OBJECT''
                    THEN @resource_associated_entity_id
                    WHEN @CallingResourceType IN (''HOBT'', ''RID'', ''KEY'',''PAGE'')
                    THEN (SELECT  object_id
                          FROM    sys.partitions
                          WHERE   hobt_id = @resource_associated_entity_id)
                    WHEN @CallingResourceType = ''ALLOCATION_UNIT''
                    THEN (SELECT  CASE
                                     WHEN type IN (1, 3)
                                     THEN (SELECT  object_id
                                           FROM    sys.partitions
                                           WHERE   hobt_id = allocation_unit_id)
                                     WHEN type = 2
                                     THEN (SELECT  object_id
                                           FROM    sys.partitions
                                           WHERE   partition_id = allocation_unit_id)
                                     ELSE NULL
                                     END
                          FROM    sys.allocation_units
                          WHERE   allocation_unit_id = @resource_associated_entity_id)
                    ELSE NULL
                    END

SELECT  @ObjectName = OBJECT_NAME(@ObjectId)'

EXEC    dbo.sp_executeSQL
        @SQL
      , N'@CallingResourceType varchar(30)
      , @resource_associated_entity_id int
      , @ObjectName sysname OUTPUT'
      , @resource_associated_entity_id = @resource_associated_entity_id
      , @CallingResourceType = @CallingResourceType
      , @ObjectName = @ObjectName OUTPUT
Figure 3 잠금 통계 캡처 (Close Figure 3)
SELECT  er.wait_time                      AS WaitMSQty
      , er.session_id                     AS CallingSpId
      , LEFT(nt_user_name, 30)            AS CallingUserName
      , LEFT(ces.program_name, 40)        AS CallingProgramName
      , er.blocking_session_id            AS BlockingSpId
      , DB_NAME(er.database_id)           AS DbName
      , CAST(csql.text AS varchar(255))   AS CallingSQL
      , clck.CallingResourceId
      , clck.CallingResourceType
      , clck.CallingRequestMode
      , CAST(bsql.text AS varchar(255))   AS BlockingSQL
      , blck.BlockingResourceType
      , blck.BlockingRequestMode
FROM    master.sys.dm_exec_requests er WITH (NOLOCK)
        JOIN master.sys.dm_exec_sessions ces WITH (NOLOCK)
          ON er.session_id = ces.session_id
        CROSS APPLY fn_get_sql (er.sql_handle) csql
        JOIN (
-- 호출 프로세스의 잠금 정보 검색, 세션 수준에서 정보 보고를 위해
-- 한 개의 레코드만 반환
              SELECT  cl.request_session_id                 AS CallingSpId
                    , MIN(cl.resource_associated_entity_id) AS CallingResourceId
                    , MIN(LEFT(cl.resource_type, 30))       AS CallingResourceType
                    , MIN(LEFT(cl.request_mode, 30))        AS CallingRequestMode
-- (예: 스키마, 업데이트 등)
              FROM    master.sys.dm_tran_locks cl WITH (nolock)
              WHERE   cl.request_status = 'WAIT' -- 잠금 요청의 상태 = 대기
              GROUP BY cl.request_session_id
              ) AS clck
           ON er.session_id = clck.CallingSpid
         JOIN (
              -- 차단 프로세스의 잠금 정보 검색
              -- 한 개의 레코드만 반환됨(예를 들어
              -- 여러 행 잠금이 발생할 가능성)
              SELECT  bl.request_session_id            AS BlockingSpId
                    , bl.resource_associated_entity_id AS BlockingResourceId
                    , MIN(LEFT(bl.resource_type, 30))  AS BlockingResourceType
                    , MIN(LEFT(bl.request_mode, 30))   AS BlockingRequestMode
              FROM    master.sys.dm_tran_locks bl WITH (nolock)
              GROUP BY bl.request_session_id
                    , bl.resource_associated_entity_id
              ) AS blck
           ON er.blocking_session_id = blck.BlockingSpId
          AND clck.CallingResourceId = blck.BlockingResourceId
        JOIN master.sys.dm_exec_connections ber WITH (NOLOCK)
          ON er.blocking_session_id = ber.session_id
        CROSS APPLY fn_get_sql (ber.most_recent_sql_handle) bsql
WHERE   ces.is_user_process = 1
        AND er.wait_time > 0
또한 SQL 프로파일러(Lock:Escalation 이벤트), dm_db_index_operational_stats 동적 관리 뷰(index_lock_promotion_count) 또는 시스템 잠금 정보의 일반적인 폴링을 통해 시스템의 에스컬레이션을 모니터링할 수도 있습니다. 에스컬레이션 모니터링을 통해 처리 과정에서 에스컬레이션이 발생하는지 여부에 관한 정보를 수집합니다. 그렇지 않은 경우에는 적절한 저장 프로시저를 통해 성능 문제에 대한 근본적인 원인을 파악할 수 있습니다. 많은 양의 데이터가 포함된 테이블이나 동시 사용률이 높은 테이블은 분석 시 중점적으로 고려해야 할 대상입니다.
잠금, 차단 및 에스컬레이션과 관련된 데이터를 수집한 후에는 이러한 데이터를 분석하여 개체별로 누적된 차단 및 잠금 시간(발생 횟수에 지속 시간을 곱함)을 확인할 수 있습니다. 일반적으로 이를 통해 변경 사항이 배포, 모니터링, 분석 및 수정되는 반복적인 성능 튜닝 작업이 시작될 수 있습니다. 경우에 따라서는 눈에 띄는 성능 향상을 위해 인덱스를 추가하는 등의 간단한 변경을 수행하기만 하면 되며 이를 통해 시스템에서 가장 심각한 성능 병목 상태를 유발하는 영역이 변경되기도 합니다.
SQL Server에서 차단을 줄이는 방법에 대한 자세한 내용은 "추가 정보"에서 확인할 수 있습니다. 디자인, 코딩 및 안정화의 모든 단계에서 트랜잭션을 작게 유지하는 데 각별한 주의를 기울인다면 여러 가지 차단 문제를 최소화할 수 있습니다. 적절한 하드웨어를 사용하면 불필요한 에스컬레이션이 발생할 가능성도 크게 낮출 수 있습니다. 그러나 결국 성능 문제의 근본 원인을 빠르게 파악하는 방법은 시스템에서 차단을 지속적으로 분석하는 것입니다.

Cherié Warren은 Microsoft IT의 선임 개발 팀장으로, 현재 Microsoft에서 가장 큰 트랜잭션 데이터베이스 중 하나를 담당하고 있습니다. 또한 그녀는 문제의 근본 원인을 조사하고 차단과 관련된 성능 문제를 해결하는 데 많은 시간을 보내고 있으며 10년 동안 엔터프라이즈급 SQL Server 데이터베이스 전문가로 일해 왔습니다.


 Microsoft Office: Access 데이터베이스와 SharePoint 통합
Microsoft Office Peter Serzo

Access 데이터베이스와 SharePoint 통합
한 눈에 보기:
  • Access와 SharePoint 통합이 제공하는 이점
  • Access 데이터를 SharePoint로 마이그레이션
  • SharePoint를 사용하여 Access 기능 확장

필자는 최종 사용자에게 Microsoft Office SharePoint Server(MOSS) 2007에 대해 강의할 때마다 이들이 어떤 도구를 사용하고 어떻게 사용하는지 질문하곤 합니다. 그러면 예외 없이 조직의 어디에서든 누군가는
비즈니스의 필수 요구 사항을 해결하기 위해 Microsoft® Office AccessTM를 사용하고 있음을 알 수 있습니다. Access는 여전히 많은 기업에서 유용한 도구이자 중요한 자산입니다.
MOSS 2007은 Access 기반 응용 프로그램을 SharePoint®에 통합하여 보다 광범위한 기능이 포함된 새로운 솔루션을 만드는 방법을 제공합니다. 이 기사에서는 MOSS와 Access를 통합하는 방법과 통합되는 지점을 보여 주고 최종 사용자가 두 제품을 구성하여 솔루션을 만드는 방법을 설명합니다.
MOSS가 Access에 제공하는 기반 기술에는 워크플로, 일반 저장소(SQL Server®) 및 웹 기반 인터페이스(브라우저)가 포함됩니다. SharePoint 기능에는 문서 관리, 작업 영역과 함께 사용자 지정 목록을 설정하는 기능이 포함됩니다. 또한 이벤트 알림에서 연락처 목록 또는 문제점 목록 만들기 기능, 그리고 사용자 정의 양식 관리에 이르는 모든 사항을 다루는 기본 제공 워크플로와 웹 파트를 사용할 수 있습니다. 또한 사용이 간편하고 익숙한 Office 기술이므로 최종 사용자가 별다른 어려움 없이 접근할 수 있습니다. 나중에 살펴보겠지만 MOSS는 현재 사용 중인 솔루션에 방해가 되지 않습니다. 응용 프로그램을 다시 작성할 필요가 없으므로 최종 사용자가 기술적 문제가 아닌 비즈니스 문제를 해결하는 데 주력할 수 있어서 MOSS를 통해 기존 솔루션의 효율성이 더욱 높아집니다.
최종 사용자만 혜택을 보는 것이 아닙니다. IT 부서와 관리자는 최종 사용자가 회사의 업무와 관련하여 생성되는 모든 사용자 지정 데이터베이스를 유지 관리할 수 있도록 지원하기 위해 고군분투하고 있습니다. 대부분의 사용자는 저장소 제한, 다중 사용자 액세스, 보안, 손상된 데이터베이스 복구, 웹 사용, 호환되지 않는 Access 버전, 여러 데스크톱에 변경 내용 배포와 같은 특정 문제가 발생하기 전까지는 업무와 관련된 중요한 문제를 해결하기 위해 Access가 사용되고 있다는 사실조차 알지 못합니다. SharePoint는 이러한 각각의 문제에 대한 해결책을 제시합니다.
나름의 한계는 있지만 여전히 Access는 전문적인 코드 작성자가 아닌 일반 사용자들에게 특히 강력하고 사용이 편리한 제품입니다. 구성 가능한 관계형 테이블, 단순한 쿼리와 복잡한 쿼리, 끌어서 놓기 방식의 고급 폼 생성기, 데이터 기반 보고서 및 다중 사용자 구성 기능을 모두 사용할 수 있습니다. Access 및 SharePoint를 기반으로 하는 솔루션 구축은 리소스와 역량을 공동으로 이용하려는 조직과 수년간 축적된 기술 및 응용 프로그램을 활용하려는 개인 모두에게 유용한 방법입니다.

시작
Access 2007은 MOSS 2007과의 여러 통합 지점을 제공합니다. 그림 1에서 볼 수 있듯이 여기에는 SharePoint 목록에서 데이터 가져오기, SharePoint 사이트에 데이터 게시, SharePoint 목록 만들기, SharePoint 데이터를 외부 원본으로 사용, Access 데이터베이스를 새 SharePoint 사이트나 기존 SharePoint 사이트로 마이그레이션, SharePoint 데이터에 대한 오프라인 액세스가 포함됩니다.
그림 1 SharePoint와의 통합을 위한 간편한 진입점을 제공하는 Access 2007
그림 1 SharePoint와의 통합을 위한 간편한 진입점을 제공하는 Access 2007
먼저 Access 테이블에서 SharePoint 목록을 만드는 것부터 시작하는 것이 좋습니다. SharePoint 목록은 Access의 테이블과 매우 유사합니다. SharePoint 목록은 SQL Server 콘텐츠 데이터베이스에 저장되고 특정 필드 특성을 포함하며 조회를 지원합니다.
SharePoint 목록을 만드는 경우 몇 가지 제한이 있습니다. 최적의 성능을 얻으려면 보기당 항목 수가 2,000개를 넘지 않도록 하는 것이 좋습니다. 또한 SharePoint에서는 참조 무결성이 적용되지 않고 OLE 개체는 SharePoint로 내보낼 수 없으며 데이터 유효성 검사가 제한됩니다.
Access 테이블에서 SharePoint 목록을 만들려면 먼저 외부 데이터 탭을 선택한 다음 내보내기 그룹에서 활성화된 SharePoint 목록 단추를 클릭합니다. 이제 그림 2에 나오는 내보내기 - SharePoint 사이트 대화 상자를 채우거나 테이블을 마우스 오른쪽 단추로 클릭하고 내보내기, SharePoint 목록을 차례로 선택하여 이 목록을 사용할 SharePoint 사이트를 지정해야 합니다. 내보내는 테이블이 부모/자식 관계에서 자식 테이블이면 해당 부모 테이블도 모두 내보내집니다.
그림 2 지정한 SharePoint 사이트로 Access 데이터 내보내기
그림 2 지정한 SharePoint 사이트로 Access 데이터 내보내기
내보내기 프로세스가 끝나면 나중에 반복할 필요가 없도록 내보내기 단계를 저장하는 옵션이 제공됩니다. 이때 SharePoint 사이트로 이동하여 업로드된 데이터를 볼 수 있습니다. 이러한 단순한 작업은 데이터를 SharePoint로 이동하여 사용자가 액세스할 수 있도록 하는 데 유용합니다. 이렇게 하면 데이터가 SQL Server 데이터베이스에 저장되므로 보안이 향상되고 브라우저를 통해 정보를 볼 수 있으므로 데이터에 대한 액세스가 간편해지는 이점을 얻을 수 있습니다.
그러나 SharePoint의 목록을 Access의 테이블로 연결하는 또 다른 방법을 사용할 경우 Access와 SharePoint를 훨씬 효과적으로 통합할 수 있습니다. 이렇게 하려면 Access에서 외부 데이터 탭을 클릭하고 가져오기 그룹에서 SharePoint 목록을 선택합니다. 그러면 그림 3의 대화 상자가 나타납니다.
그림 3 Access를 SharePoint에 연결
그림 3 Access를 SharePoint에 연결
연결된 데이터 원본으로 사용할 SharePoint 목록이 포함된 사이트를 선택한 다음 연결할 목록을 선택합니다. 이 작업이 끝나면 해당 목록이 Access에서 연결된 테이블로 표시되고 응용 프로그램의 오른쪽 아래 모서리에 "SharePoint에서 온라인으로 작업" 표시기가 나타납니다. 이제 Access와 SharePoint 간에 양방향 동기화가 이루어지므로 SharePoint나 Access 중 하나에서 추가, 변경 및 삭제 작업을 수행할 수 있습니다. 나중에 살펴보겠지만 테이블에 대해 코드를 작성하여 추가 기능을 제공할 수 있습니다.
Access에서 SharePoint 목록에 연결하면 Windows® SharePoint Services(WSS) 사용자 정보 목록이라는 또 다른 테이블도 가져오게 됩니다. 이 테이블은 기본적으로 연결됩니다. 또한 "SharePoint 사이트로 이동 문제점"이라는 문제점 테이블이 생성되며 이 테이블에서는 데이터 충돌 문제를 검토할 수 있습니다.
데이터 마이그레이션 및 변환 중 데이터 형식 처리 방법에 대한 자세한 내용은 "Access 및 SharePoint 간의 데이터 형식 변환 방법"(office.microsoft.com/en-us/access/HP010477131033.aspx) 및 "데이터베이스를 이동하고 해당 테이블을 SharePoint 사이트에 연결"(office.microsoft.com/en-us/access/HA101314681033.aspx)의 마이그레이션 제한 관련 단원을 참조하십시오.
테이블과 목록을 통합하는 세 번째 방법은 SharePoint에서 시작합니다. 목록을 선택하고 작업 탭에서 "Access에서 열기" 옵션을 클릭합니다. 데이터베이스(새 데이터베이스 또는 기존 데이터베이스) 이름을 묻는 대화 상자가 나타납니다. 데이터베이스 이름을 입력한 후 단순히 SharePoint 사이트의 데이터에 연결할지 또는 데이터를 곧바로 Access로 내보낼지 여부를 선택합니다(그림 4 참조).
그림 4 Access를 통해 SharePoint 데이터에 연결할 수 있도록 설정
그림 4 Access를 통해 SharePoint 데이터에 연결할 수 있도록 설정

데이터베이스를 SharePoint로 이동
지금까지 SharePoint 목록을 연결된 테이블로 가져오고 Access 테이블을 SharePoint 목록으로 내보내는 방법을 살펴보았습니다. 그렇다면 전체 데이터베이스에 액세스해야 하는 경우에는 어떻게 해야 할까요? 많은 조직이 Access에서 실행되는 중요 업무용 응용 프로그램을 보유하고 있으며, 이러한 응용 프로그램은 개인이 보고서와 쿼리를 실행하고 데이터를 입력할 수 있도록 원격에서 사용이 가능해야 합니다. 이와 같은 경우 응용 프로그램을 다시 작성해야 하지만 경제적으로나 가용 기술을 고려했을 때 이것이 현실적으로 적절하지 않을 때가 있습니다. SharePoint와 Access에서는 Access의 SharePoint 목록 탭에 있는 "SharePoint로 이동" 옵션을 통해 이 문제를 해결합니다. 이 옵션은 Access 97에 처음 소개되었던 업사이징 마법사를 사용하여 SQL Server로 이동하는 옵션과 유사합니다.
전체 Access 데이터베이스를 SharePoint로 이동하면 모든 테이블이 SharePoint 목록으로 변환되고, Access 데이터베이스에 대한 백업이 만들어지며, 목록이 자동으로 Access의 연결된 테이블이 되고, 테이블뿐만 아니라 전체 데이터베이스를 이동할 수 있으며, 데이터베이스가 이동 전과 거의 비슷하게 작동하는 등 다양한 이점을 얻을 수 있습니다.
SharePoint로 이동 단추를 클릭하면 그림 5의 대화 상자가 나타납니다. 사이트를 지정한 후 데이터베이스 저장 옵션을 선택할지 여부를 결정해야 합니다. 그러면 전체 데이터베이스가 선택한 문서 라이브러리에 저장됩니다. 이는 폼, 보고서, 쿼리 및 매크로를 포함한 전체 데이터베이스가 SharePoint에 저장되며 서버에서 사용 가능한 상태가 됨을 의미합니다. 데이터베이스에 액세스하려는 사용자는 데이터베이스가 있는 라이브러리로 이동한 후 데이터베이스를 클릭하기만 하면 됩니다. 그러면 데이터베이스가 자동으로 사용자의 데스크톱에 배포됩니다.
그림 5 데이터베이스를 이동할 SharePoint 사이트 지정
그림 5 데이터베이스를 이동할 SharePoint 사이트 지정
전체 데이터베이스를 이동하도록 선택하면 변경 내용 게시라는 메시지 표시줄이 리본 메뉴 아래에 나타납니다. 이 옵션을 통해 디자인 및 데이터에 대한 로컬 변경 내용이 서버의 복사본과 동기화되도록 할 수 있습니다. 이 옵션을 선택하지 않으면 테이블만 목록으로 변환되고 Access에 연결됩니다. 이 경우 사용자 커뮤니티에서 전체 데이터베이스를 사용할 수 없을 뿐만 아니라 전체 데이터베이스가 SharePoint에서 하나의 개체로 백업되지도 않습니다.
이러한 옵션 중 하나를 선택하면 선택한 SharePoint 사이트를 통해 데이터베이스 및 데이터베이스와 관련된 정보를 사용할 수 있습니다. 다시 말하지만 "SharePoint 사이트로 이동 문제점"이라는 테이블이 자동으로 생성되며 이 테이블에는 마이그레이션으로 인한 모든 충돌 문제가 설명되어 있습니다. 이 테이블에서는 SharePoint 사이트에 테이블을 업로드하는 동안 Access에서 발생한 모든 문제를 검토할 수 있습니다.

보기, 폼 및 보고서
데이터베이스를 이동한 후에는 데이터베이스가 올바르게 작동하는지 테스트할 수 있습니다. 테스트를 시작하기 전에 "SharePoint에서 온라인으로 작업" 표시기가 표시되어 있는지 확인합니다. 이제 Access 쿼리가 SharePoint 보기로 바뀌었습니다. SharePoint 보기는 Access 쿼리와 매우 유사합니다.
전체 데이터베이스를 이동하는 경우 기존 쿼리는 SharePoint에 보기로 복사됩니다. Access 사용자는 쿼리를 작성하면 데이터 하위 집합을 볼 수 있다는 것을 알게 됩니다. SharePoint 보기에서 이를 수행하는 방법을 배우면 SharePoint 목록에서 데이터가 구성되는 방법을 쉽게 이해할 수 있습니다.
만들 수 있는 가장 유용한 보기 중 하나가 Access 보기입니다. Access 보기를 만들려면 먼저 보기를 만들 목록으로 이동한 후 보기를 선택한 다음 보기 만들기를 선택합니다. 그러면 목록을 기반으로 폼과 보고서를 만드는 데 사용할 수 있는 Access 보기 옵션이 표시됩니다. 이 옵션을 클릭하고 Access 데이터베이스를 선택하면 그림 6과 같은 대화 상자가 나타납니다. 그림에서 볼 수 있듯이 이제 형식(폼 종류, 피벗 차트, 피벗 테이블 또는 보고서)을 정의합니다. 이 프로세스가 완료되면 연결된 폼이나 보고서가 Access 데이터베이스에 생성됩니다.
그림 6 Access 보기 만들기
그림 6 Access 보기 만들기

오프라인 액세스
실제 환경에서 중요 업무용 응용 프로그램의 범위를 확장하면 ROI가 발생합니다. Access/SharePoint 통합 응용 프로그램의 범위를 확장하는 한 가지 방법은 응용 프로그램을 사용하기 위해 SharePoint에 연결할 필요가 없다는 점을 인식하는 것입니다. 이러한 융통성을 지원하기 위해 Access 2007에는 오프라인으로 작업할 수 있는 기능이 도입되었습니다. 서버에 연결될 때까지 정보는 데이터베이스의 로컬 복사본에 캐시됩니다. 데이터베이스를 오프라인으로 전환하려면 리본 메뉴의 외부 데이터|SharePoint 목록 그룹에서 오프라인으로 작업 단추를 클릭합니다.
SharePoint에 다시 연결할 준비가 되면 온라인으로 작업이나 동기화를 선택할 수 있습니다. 두 옵션 모두 데이터를 업로드하고 충돌되는 부분을 표시하여 검토할 수 있도록 합니다. 그러나 동기화를 선택하는 경우 데이터는 업로드되지만 응용 프로그램은 오프라인 상태로 유지됩니다.
SharePoint 목록 그룹에서 주의해야 할 또 다른 항목은 두 가지 옵션이 포함된 변경 내용 취소입니다. 첫 번째 옵션은 모든 변경 내용을 취소하지만 Access에서 SharePoint 데이터를 업데이트하지는 않습니다. 두 번째 옵션은 모든 변경 내용을 취소하고 SharePoint 데이터(연결된 목록)를 업데이트합니다.

Access 서식 파일
Access 2007에는 사용자가 비즈니스 솔루션을 손쉽게 만들 수 있도록 미리 작성된 여러 가지 서식 파일이 포함되어 있습니다. 만들기 탭에 있는 테이블 그룹에서 SharePoint 목록 단추를 클릭하면 이러한 서식 파일을 볼 수 있습니다(그림 7 참조). 서식 파일 중 하나를 선택하면 SharePoint에 연결된 테이블의 스키마가 자동으로 정의됩니다. 현재는 연락처, 작업, 문제점 및 이벤트만 지원됩니다. 따라서 이러한 정보 유형 중 하나가 포함된 테이블을 내보내면 데이터가 해당 콘텐츠 형식으로 나타납니다(예: 문제점 정보 유형을 내보내면 문제점 형식으로 나타남).
그림 7 목록 유형 선택
그림 7 목록 유형 선택
SharePoint 목록에 사용할 수 있는 사용자 지정 서식 파일을 만들거나 자동 연결되는 Access 2007 데이터베이스를 사용하여 SharePoint 사이트 서식 파일을 만들 수도 있습니다. 이를 위해서는 Access 2007 Developer Extensions가 설치되어 있어야 하고 테이블의 WSSTemplateID를 설정해야 합니다. 이 속성은 어떤 테이블이 해당 SharePoint 목록 서식 파일을 가지고 있는지 추적합니다.

Access 및 메타데이터
보안이 설정된 Access 응용 프로그램을 사용하는 기업은 이러한 응용 프로그램을 모두 SharePoint로 이동할 수 없거나 이동하고 싶지 않을 수도 있습니다. 이러한 경우에는 Access에서 코드를 작성하여 SharePoint를 업데이트하는 것이 적절할 수도 있습니다. 코드를 사용하여 SharePoint와 Access를 연결할 수 있습니다.
간단한 예로 제품, 공급업체 및 고객 주문에 대한 정보가 저장된 Northwind Trader 데이터베이스를 들 수 있습니다. 각 제품에는 일반적으로 협력업체에서 제공하는 .pdf 파일 형식의 제품 시트가 연결되어 있습니다. Access 데이터베이스는 지리적 위치, 제품 번호, 수정 기록, 회사 부서 코드 등 제품 시트에 포함된 모든 정보를 추적합니다. 이 정보는 SharePoint 엑스트라넷을 통해 공급업체와 협력업체에서 사용할 수 있어야 합니다.
이를 위해 SharePoint 사이트를 설정하고 모든 문서를 연결된 문서 라이브러리로 이동했습니다. 그러나 그림 8에서 볼 수 있듯이 메타데이터 필드는 비어 있는데 이는 해당 데이터가 Access에서 추적되기 때문입니다. 또한 이를 모니터링하는 담당자가 Access를 선호할 뿐만 아니라 변화를 바라지 않습니다.
그림 8 메타데이터가 누락된 상태로 SharePoint에 표시된 Northwind 문서
그림 8 메타데이터가 누락된 상태로 SharePoint에 표시된 Northwind 문서
다행히 그림 9에서 볼 수 있듯이 Visual Basic® for Applications(VBA) 코드를 추가하여 Access 응용 프로그램을 통해 메타데이터를 업데이트할 수 있습니다. 응용 프로그램을 다시 작성할 필요는 없습니다. 직원들은 이전부터 사용하던 도구로 웹에서도 작업할 수 있으며 협력업체는 부여받은 사용 권한에 따라 엑스트라넷에 액세스하여 허용된 정보를 볼 수 있습니다. 또한 동시성이나 데이터베이스 크기 문제는 발생하지 않습니다.
그림 9 코드를 사용하여 메타데이터 업데이트
그림 9 코드를 사용하여 메타데이터 업데이트

기본 제공 보안
Access 응용 프로그램을 SharePoint로 이동하는 경우 얻을 수 있는 가장 큰 이점 중 하나는 Active Directory® 인증이 기본적으로 포함된 SharePoint 보안 모델을 사용할 수 있다는 것입니다. 즉, 스키마와 테이블을 만든 다음 사용자를 추가하여 Access 응용 프로그램에 보안을 구현하는 방법에 대해 더 이상 신경쓸 필요가 없습니다. SharePoint 목록을 사용하는 경우 사용자가 자신에게 허용된 정보만 볼 수 있도록 하는 SharePoint 고유의 기능인 보안 조정을 활용할 수 있습니다. 그뿐만 아니라 SharePoint로 이동하고 싶지 않은 데이터베이스 구성 요소가 있는 경우 해당 구성 요소는 이동하지 않아도 됩니다.
SharePoint는 세분화된 역할 기반 보안 모델을 제공합니다. 데이터베이스 이동 방법 및 이동 위치를 결정할 때는 마이그레이션에 앞서 사이트와 보안을 디자인해야 합니다. 이렇게 하면 사용 권한을 설정하고 테스트하기가 쉽습니다. 또한 마이그레이션에 따르는 문제가 줄어들고 Access 데이터베이스가 보다 효율적으로 실행됩니다.

참조 무결성
참조 무결성에 대해서는 간단히라도 살펴보아야만 설명이 부족하지 않을 것입니다. 사실 SharePoint는 Access와는 달리 참조 무결성을 적용하지 않습니다. 대부분의 설치는 일정 수준에서 정규화됩니다. 중요 업무용 Access 데이터베이스가 올바르게 작동하려면 바로 이 점을 고려해야 합니다. 다행히 기존 시스템에 대한 향상 기능으로 간주할 수 있는 몇 가지 해결 방법이 있습니다.
앞서 데이터베이스를 SharePoint로 이동할 때 자식 테이블을 이동하면 해당 부모 테이블도 이동된다고 언급한 바 있습니다. 그뿐만 아니라 SharePoint에서는 선택한 특정 필드가 다른 테이블에 기반을 두고 있음을 파악한 경우 조회 필드를 사용합니다. 예를 들어 Northwind Traders 데이터베이스에서 고객이 선택되고 주문이 이루어졌다고 가정해 보십시오. 이러한 테이블이 SharePoint로 이동되면 고객 필드가 주문 목록에서 조회 필드가 됩니다.
연속적인 업데이트/삭제 작업 및 이보다 복잡한 작업의 경우는 어떨까요? 이와 같은 경우에는 SharePoint와 SharePoint 워크플로를 잠재적 솔루션으로 고려해야 합니다. 다시 Northwind Traders 데이터베이스로 돌아가서 고객이 전화를 걸어 기존 주문을 취소했다고 가정해 보십시오. 이 경우 재고를 원래대로 되돌리고, 공급업체에 이 사실을 알리고, 해당 주문에 연결된 직원이 고객에게 연락을 취해 주문 취소를 확인하고, 납품을 취소하고, 회계 정보를 업데이트하는 등의 여러 가지 작업이 시작됩니다. 이로 인해 많은 부분이 이동되고 조정되어야 합니다.
SharePoint Designer를 사용하면 주문 상태가 변경되는 즉시 앞서 설명한 모든 작업을 수행하는 워크플로를 SharePoint에서 만들 수 있습니다. 22개의 워크플로가 기본적으로 제공되며 수백 가지 작업에 맞게 이를 수정하여 사용할 수 있습니다. SharePoint Designer는 사이트를 꾸미거나 워크플로를 만드는 경우 모두에 유용한 도구입니다.
SharePoint Designer를 사용하여 워크플로를 만들 때 가장 좋은 점은 Access "프로그래밍" 방법을 알고 있는 사용자에게 친숙한 기술이 사용된다는 것입니다. 즉, Access 응용 프로그램을 만드는 사용자는 별다른 어려움 없이도 자신의 기술 지식을 워크플로 생성 분야로 확대할 수 있습니다. 워크플로를 만드는 데 SharePoint Designer를 사용할 경우 별도의 코드를 작성할 필요가 없으며 워크플로 배포 또한 매우 간단합니다.

Peter Serzo는 CDW Berbee의 수석 엔지니어이며 전 세계 기업을 대상으로 SharePoint 엔터프라이즈 솔루션을 설계하는 업무에 주력하고 있습니다.


 From the Editor: 떠나는 동료와 새 동료
From the Editor
떠나는 동료와 새 동료

이번 달에는 먼저 아쉬운 소식을 한 가지 전하겠습니다. 아쉽게도 The Cable Guy의 Joseph Davies가 이번 호 TechNet Magazine 칼럼을 끝으로 작별을 고하게 되었습니다. 지금까지 Joseph과 같이 탁월한 전문가를 통해 무수한 Windows 네트워킹 관련 주제에 대해 배울 수 있었던 것은 큰 행운이었습니다. 하지만 Microsoft에서 중요한 새 업무를 맡게 되면서 더 이상 매달 칼럼을 연재하기 어렵게 되었습니다. TechNet Magazine을 대표해 수년 간 수고를 아끼지 않은 Joseph에게 감사의 인사를 전하고 앞으로 새로운 길에 행운이 함께 하기를 기원합니다.
The Cable Guy를 떠나보내는 아쉬움을 뒤로 하고, 어쨌든 기사는 계속 이어가야겠죠. 그래서 다음 호부터는 "Inside SharePoint"라는 새로운 칼럼이 연재됩니다. 작년에 SharePoint에 대한 기사를 늘려 달라는 고객 의견이 많이 접수되었습니다. 뿐만 아니라 SharePoint가 빠르게 성장하고 있는 흥미로운 기술임을 감안하여 연재 칼럼 주제로 가장 적합하다는 결론을 내렸습니다. 첫 주자로 Pav Cherny가 나서서 SharePoint 인프라의 아키텍처에 대한 개괄적인 설명부터 시작하겠습니다. 그리고 앞으로 보안, 가용성, 성능, 문제 해결 등을 비롯한 다양한 주제를 다룰 예정입니다. 이 칼럼에서 다루었으면 하는 SharePoint 관련 주제가 있으면 주저하지 말고 tnmag@microsoft.com으로 메일을 보내 주시기 바랍니다.
수석 편집자 Terrence Dorsey와 Nancy Michell에게도 한없는 감사를 전합니다. Terry와 Nancy는 초기부터 함께 해온 동료로서 뛰어난 재능과 경험을 바탕으로 TechNet Magazine이 오늘날의 성공을 거두는 데 공헌했습니다. 그러나 아쉽게도 이번 호부터 Terry와 Nancy는 자매 발행물인 MSDN Magazine을 전담하게 되었습니다. 대신, 역시 뛰어난 능력을 갖춘 수석 편집자 Matthew Graven과 Sharon Terdeman이 MSDN Magazine에 작별을 고하고 TechNet Magazine을 담당하게 되었습니다. Terry와 Nancy가 앞으로도 늘 가까운 곳에서 TechNet Magazine이 그들의 식견과 전문 지식을 바탕으로 성장해가는 모습을 지켜볼 수 있어 매우 다행스럽다고 생각합니다.
그럼 잡지부의 가족 소식은 이것으로 접고, 이번 호의 주요 내용을 소개하는 것으로 마무리하도록 하겠습니다. 이번 달에는 출시를 앞둔 SQL Server 2008에 초점을 맞추어 날로 양이 증가하고 범위가 확대되고 있는 가장 중요한 자산인 데이터를 효과적으로 저장, 보호, 관리, 활용할 수 있도록 하는 다양한 새 기능을 살펴보겠습니다. —Joshua Hoffman


 Letters: 독자의 목소리
Letters
독자의 목소리

강력한 호스트와 취약한 호스트
2007년 9월 The Cable Guy 칼럼(technetmagazine.com/issues/ 2007/09/CableGuy)의 "강력한 호스트 모델 및 취약한 호스트 모델"에서 취약한 호스트를 활성화하거나 비활성화하는 기능을 다루었는데요, 이에 대한 구체적인 방법은 설명되지 않았습니다. 단지 방화벽을 활성화 또는 비활성화하거나 매개 변수 레지스트리를 설정하면 되는 것인가요? 이와 관련된 레지스트리 매개 변수가 있습니까?
아울러, 로컬 액세스를 구성할 때 IP 주소와 IP 마스크라는 두 가지 정보가 필요합니다. Microsoft에서 선택적 게이트웨이 매개 변수가 포함되지 않은 구성을 유효하지 않은 것으로 간주하는 이유가 무엇인가요?
—Milt B.
Windows Vista® 및 Windows Server® 2008에서는 그림(2007년 9월 처음 게시)에 나열된 명령을 사용하여 강력한 호스트 또는 취약한 호스트 동작을 구성할 수 있습니다. 이와 관련된 레지스트리 항목은 없습니다. IPv4는 취약한 호스트이고 IPv6는 강력한 호스트이므로 Windows® XP 및 Windows Server 2003에서는 강력한 호스트 또는 취약한 호스트 동작을 구성할 수 없습니다.
두 번째 질문의 경우 저희가 아는 바로는, 인터페이스에서 IPv4 또는 IPv6을 구성할 때 사용자 인터페이스를 통하거나 명령 줄에서 기본 게이트웨이 또는 라우터를 구성하지 않아도 되는 것으로 알고 있습니다.


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

다중 모니터 관리
UltraMon
realtimesoft.com
LCD 패널 가격이 하락하면서 여러 관리 대시 보드를 한 눈에 살펴보기 위해 워크스테이션에 모니터를 두 대 이상 연결해 사용하는 시스템 관리자가 많아졌습니다. 다중 모니터를 사용하지 않는 시스템 관리자가 있다면 개인적으로 이 방법을 추천하고 싶습니다. 작업이 훨씬 수월해질 테니까요. 하지만 추가 모니터를 하나 이상 연결하면 마우스 사용 범위가 넓어져 작업 속도가 저하될 수 있습니다. 이런 경우 바로 가기 키를 지원하는 간편한 디스플레이 관리 유틸리티가 큰 도움이 됩니다. 이러한 도구 중 하나로 Realtime Soft의 UltraMon을 들 수 있습니다. UltraMon은 Windows® 98에서 Windows Vista®까지 32비트 버전과 64비트 버전을 모두 지원합니다.
UltraMon을 처음 실행하면 각 응용 프로그램 창의 모서리에 작은 아이콘이 두 개 표시됩니다. 첫 번째 아이콘은 응용 프로그램 창을 여러 모니터에 걸쳐 빠르게 확장하고, 두 번째 아이콘은 응용 프로그램을 다른 모니터로 옮깁니다. 또한 작업 표시줄이 여러 모니터에 걸쳐 확장되고 각 모니터마다 열려 있는 응용 프로그램이 작업 표시줄에 표시됩니다. 즉, 응용 프로그램을 확장하기 위해 기본 모니터로 이동하지 않아도 되며 최대화하거나 최소화했을 때 응용 프로그램이 어디에 표시되는지 즉시 알 수 있습니다.
UltraMon 탭에서는 각 응용 프로그램 바로 가기를 실행했을 때 응용 프로그램을 시작할 모니터와 위치를 정의할 수 있습니다. 예를 들어 Microsoft® Outlook®은 항상 왼쪽 창에 표시되도록 하고 Internet Explorer®는 오른쪽에서 열리도록 할 수 있습니다. IT 전문가는 랩톱 또는 가정용 데스크톱 등 다른 위치에서 원격으로 워크스테이션에 연결하는 일이 잦습니다. 이렇게 원격으로 연결할 때마다 바탕 화면과 디스플레이 해상도가 약간 바뀝니다.
다행히 UltraMon에서는 여러 모니터에 걸쳐 사용자 지정된 보기 간의 변경을 손쉽게 할 수 있는 디스플레이 프로필이 지원됩니다. 특히 이 기능은 고유한 사용자 지정 보기를 사용하거나 사용하고자 하는 다른 사용자와 컴퓨터를 공유하거나, 작업에 따라 보기를 변경하려는 경우에 유용합니다.
Windows 2000 또는 Windows XP를 실행하는 경우 기본 모니터를 높은 해상도로 실행하고 프레젠테이션 모니터는 낮은 해상도로 실행하면서 양쪽 화면에 응용 프로그램 동작이 미러링되도록 할 수 있는 "미러링" 기능도 사용할 수 있습니다. 이 기능은 프레젠테이션에 더할 나위 없이 유용합니다. Windows Vista로 아직 업그레이드하지 않은 경우에도 여러 모니터 화면에 걸쳐 응용 프로그램이 표시되도록 확장할 수 있습니다. Windows Vista에서는 이 기능이 기본적으로 지원됩니다.
디스플레이 설정 화면에 대한 바로 가기, 시스템의 기본 모니터를 간편하게 설정 및 전환하는 기능, 여러 디스플레이 프로필 간 전환 기능 등 자주 사용하는 몇 가지 추가 디스플레이 기능은 UltraMon 시스템 트레이 아이콘을 통해 액세스할 수 있습니다. 시스템 트레이 아이콘에서는 "Smart Taskbar"를 사용자 지정하고 창을 이동하거나 변경하는 데 사용되는 바로 가기 키를 설정하고 마우스를 지정된 포커스 지점으로 가져오는 등의 작업이 가능한 UltraMon 옵션 창도 시작할 수 있습니다.

가격: 단일 라이선스(39.95달러~)
UltraMon의 옵션 창에서 바로 가기 키를 설정하고 Smart Taskbar를 관리할 수 있습니다.
UltraMon의 옵션 창에서 바로 가기 키를 설정하고 Smart Taskbar를 관리할 수 있습니다.

서평
Microsoft SQL Server 2005 Analysis Services
informit.com
방대한 고객 기반 데이터를 유지 관리하는 것은 그리 복잡한 문제가 아니지만 그 데이터를 이해하고 조작하여 고객과 관련된 유용하고 알기 쉬운 통계를 이끌어내는 것은 전혀 다른 문제입니다. 이러한 계산된 보기와 예측 데이터를 얻으려면 동적이고 강력한 비즈니스 인텔리전스 솔루션이 필요합니다. 이와 관련하여 Microsoft는 비즈니스 인텔리전스 및 OLAP(Online Analytical Processing) 영역을 토대로 SQL Server® 2005 Analysis Services를 선보였습니다. 이 솔루션을 완벽하게 활용하기 위한 지침서가 바로 Microsoft SQL Server 2005 Analysis Services입니다.
새로운 데이터 마이닝 배포를 고려 중이거나 Analysis Services 2000에서 Analysis Services 2005로 업그레이드하거나 조직에서 이러한 도구가 얼마나 유용할지 알아보려는 데이터베이스 관리자인 경우 Py Bateman, Alexander Berger, Irina Gorbach 및 Edward Melomed가 공동 집필한 이 책이 큰 도움이 될 것입니다. 이 책에서는 비즈니스 인텔리전스의 이론적 원리를 파헤치는 대신 실제 사례를 통해 Analysis Services의 사용, 관련 개발, 배포 및 관리 과정을 단계별로 자세히 설명합니다. 이 책에서 제공되는 예제는 대부분 소프트웨어와 함께 제공되는 샘플 데이터베이스인 Food Mart 2005에서 가져온 것이기 때문에 자체 테스트 환경에서 쉽게 테스트해볼 수 있습니다.
책의 서론 부분에서는 웹 서비스 XMLA(XML for Analysis) 통신, 통합 차원 모델, 향상된 안정성을 제공하는 클라이언트-서버 아키텍처 등 2005 버전의 새로운 기능을 소개합니다. 또한 Food Mart 샘플 데이터베이스 및 다차원 데이터베이스와 관련한 기본 사항도 소개합니다. 다음으로 데이터 모델 제작에 관한 내용으로 넘어가 DDL(데이터 정의 언어) XML와 차원 특성 및 계층, 큐브와 다차원 분석에 대해 다룹니다. 그리고 Business Intelligence Development Studio를 통해 2005 Analysis Services Business Intelligence Professional의 디자인 및 개발 작업 공간을 소개합니다.
이러한 디자인 개념을 자세히 살펴본 후에는 MDX(Multidimensional Expression)를 통한 데이터 조작에 대해 다룹니다. MDX로 데이터를 쿼리하는 방법은 물론, MDX 함수와 멤버 및 셀 속성을 사용하는 방법, 빈 집합과 null을 처리하는 방법, 하위 선택 항목, 하위 큐브, 큐브 기반 MDX 계산을 만들고 사용하는 방법, 저장 프로시저로 쿼리를 확장하는 방법 등에 대해서도 배웁니다. 다음으로 비즈니스 성장, 지표, 목표 등을 다양한 측면에서 보여 주는 KPI(핵심 성과 지표), 드릴스루 및 스코어카드에 대해서 다룹니다.
다음 부분에서는 데이터의 ETL(추출, 변환 및 로드) 프로세스를 통해 시스템으로 데이터를 가져오는 과정뿐만 아니라 집계 디자인을 최적화하고 사전 캐싱 기능을 활용해 성능을 높이는 방법까지 보여 줍니다. 또한 큐브와 차원의 실제 데이터 모델을 살펴보고, 2005 Analysis Services에서 각 작업을 처리하는 방법을 알아보며 네트워크 부하 분산, OLAP 팜, 연결된 측정값 및 차원 그룹, 원격 파티션 처리 등을 다루면서 비즈니스 요구 사항에 따라 배포 범위를 확장하는 방법을 설명합니다.
이어서 쿼리 실행의 가장 핵심적인 내용을 통해 응용 프로그램 성능을 세부적으로 조정하는 데 필요한 기본 작업에 대한 이해를 돕습니다. 이 부분에서는 클라이언트 쪽에서 데이터에 액세스하는 데 대해 설명하고 XMLA, ADOMD.net, AMO(Analysis Management Objects) 등 클라이언트 쪽 데이터 액세스에 사용되는 여러 가지 옵션을 소개합니다. 여기서는 Visual Studio와 Business Intelligence IDE를 활용해 사용자 지정 데이터 웨어하우스 응용 프로그램을 만드는 방법을 이해하기 위해 코드를 본격적으로 살펴보기 시작합니다.
책의 마지막 절에서는 Analysis Services 설치 관리에 대해 다룹니다. 여기서 설명하는 주요한 내용으로는 추적 도구, 비행 레코더 및 SQL Server 프로파일러를 사용하여 시스템의 성능과 상태를 모니터링하는 방법 등을 들 수 있습니다. 또한 DDL 명령을 사용한 데이터베이스 백업, SQL Server Agent 또는 SSIS(SQL Server Integration Services)를 통한 자동화, 손실되거나 손상된 데이터 복구 등을 다루는 절에서 다양한 배포 백업 및 복구 옵션을 살펴볼 수 있습니다. 이 책을 전반적으로 평가하자면 SQL Server 2005 Analysis Services에 대한 광범위하고 완전한 지침서라 할 수 있습니다.

가격: 59.99달러

데이터베이스 문제 진단
ApexSQL Audit
apexsql.com/sql_tools_audit.asp
문제를 해결하거나 근본 원인을 추적할 때 가장 먼저 문제의 원인이 된 이벤트와 관련된 정보를 수집해야 한다는 사실은 누구나 잘 알 것입니다. 최종 사용자 지원 관련 업무를 담당하다보면 "시스템 데이터 손실" 문제에 대해 문의하는 사용자를 많이 접하게 됩니다. SQL Server 데이터베이스와 관련한 문제를 쉽게 파악할 수 있는 도구로 ApexSQL의 ApexSQL Audit가 있습니다. 이 도구는 SQL Server 7.0에서 SQL Server 2005까지 완벽하게 지원합니다.
이 응용 프로그램의 이름으로, 해당 응용 프로그램이 지정한 데이터베이스의 작업을 추적하고 분석용 감사 추적 내역에 대한 사용자 지정 보고서를 만들 수 있도록 하는 것임을 쉽게 알 수 있을 겁니다. 감사 항목은 SQL 트리거를 통해 추가되고 자동 생성된 스키마에 저장됩니다. 감사 정보는 감사 대상 데이터와 동일한 데이터베이스에 저장하거나, 고유한 데이터베이스에 저장하여 격리되도록 선택할 수 있습니다.
감사 스키마(또는 아키텍처)는 그래픽 UI를 통해 손쉽게 설치하고 제거할 수 있습니다. 또한 데이터베이스 감사 계획도 데이터베이스를 선택하고 감사할 테이블과 필드를 선택한 다음 트리거를 생성하는 단추를 클릭하면 간단히 설정할 수 있습니다.
이 응용 프로그램에서는 프로젝트의 트리거 템플릿을 수정할 수 있습니다. 필자는 개인적으로 IntelliSense® 스타일의 감사 개체 모델 기능을 제공하는 템플릿 편집기가 마음에 듭니다. 트리거가 발생하는 시점과 저장되는 정보를 쉽게 사용자 지정할 수 있기 때문입니다. 또한 알 수 없는 ID만 제공하는 것이 아니라 조회 테이블을 쉽게 참조할 수 있도록 하여 감사 정보의 이해를 돕는 유용한 기능도 제공합니다. 열을 매핑하려는 경우 감사 대상 필드 이름을 감사 필드 이름에 매핑할 수도 있습니다.
일단 실행한 후에는 UI를 통해 현재 적용된 감사 트리거를 확인하고 필요에 따라 한 번의 클릭으로 특정 트리거를 활성화하거나 비활성화할 수 있습니다. 또한 인터페이스의 간편한 테이블 보기를 통해 감사 범위를 확인할 수도 있습니다.
아시다시피 감사 정보는 그 양이 방대한 경우가 많기 때문에 감사 데이터베이스를 보관하고 정리하는 정보 관리 계획이 필요합니다. 이와 관련하여 ApexSQL Audit는 한 번의 클릭으로 모든 정보를 삭제하거나, 일련의 기준을 설정하고 그에 따라 삭제하거나, 기준에 따른 삭제를 예약할 수 있는 데이터 관리 도구를 제공합니다.
예약된 작업은 DTS(데이터 변환 서비스) 패키지로 자동 생성되고 SQL 에이전트를 통해 예약됩니다. 물론 모든 감사 정보를 유지 관리하는 것 외에 그렇게 저장한 정보를 어떻게 사용할 것인지는 또 다른 문제입니다. 다행히 ApexSQL Audit에는 세부적인 감사 데이터와 해당 감사 데이터의 집계 보기를 필터링된 사용자 지정 보기로 생성할 수 있는 강력한 보고 구성 요소가 포함되어 있습니다. 생성된 보고서는 간단히 인쇄하거나 HTML, Microsoft Excel 또는 텍스트 파일로 내보낼 수 있습니다.

가격: 599달러~
ApexSQL Audit의 조회 테이블에서는 다양한 감사 정보가 제공됩니다.
ApexSQL Audit의 조회 테이블에서는 다양한 감사 정보가 제공됩니다.

암호 만료 알림 자동화
Password Reminder PRO v1.4
sysoptools.com/password-reminder-pro.html
조직의 그룹을 통해 암호 만료 정책을 배포했더니 헬프데스크에 문의 전화가 쇄도했던 경험을 해보신 적이 있으신가요? 이러한 경우 SysOp Tools의 Password Reminder PRO가 도움이 될 수 있습니다. Password Reminder PRO는 Active Directory®와 통합되어 계정 또는 암호가 곧 만료됨을 알려 주는 간단한 도구입니다.
서로 다른 텍스트 기반 전자 메일 템플릿이나 서식이 적용된 HTML 전자 메일 템플릿을 기반으로 한 세 가지 알림을 설정할 수 있습니다. 또한 최대 암호 사용 기간을 Active Directory 구성의 일 수와 동일하게 구성하거나 사용량이 많은 시간을 피해 알림 전송 시간을 구성할 수도 있습니다. 테스트 모드에서는 최종 사용자에게 실제로 영향을 주지 않으면서 구성 결과를 미리 봄으로써 올바르게 구성되었는지 확인할 수 있습니다.
이 유틸리티에는 만료 시점이 가까운 계정, 사용되지 않는 사용자 계정, 새 계정, 비활성화된 계정 등 여러 가지 사용자 클래스를 데이터 표 보기로 보여 주는 보고서 콘솔도 포함되어 있습니다. 이 보고서 콘솔에서 XLS 파일로 모든 정보를 내보낸 후에 나중에 검토할 수도 있습니다. 이전에 전송한 전자 메일도 감사할 수 있도록 Password Reminder PRO는 전송한 알림과 수신 사용자에 대한 일일 보고서도 보냅니다.

가격: 100개 사용자 라이선스(249달러~)
Password Reminder PRO에서는 배포 전 구성을 미리 봅니다.
Password Reminder PRO에서는 배포 전 구성을 미리 봅니다.

단순화된 원격 문제 해결
UltraVnc SC
uvnc.com/pchelpware/sc
일반적으로 문제를 해결하거나 사용자에게 문제 해결 과정을 안내할 때에는 컴퓨터에서 실제로 작업하는 것이 가장 손쉬운 방법입니다. 그러나 오늘날의 지리적으로 분산된 회사 환경에서는 이러한 방법이 물리적으로 불가능한 경우가 많습니다. Windows에서 기본 제공되는 원격 데스크톱 연결이나 원격 지원 도구의 경우 환경 내에서 일부 컴퓨터에 연결하는 데에는 도움이 되지만 전체 환경을 지원하려면 UltraVNC라는 기본 프로젝트의 일환으로 무료 제공되는 UltraVNC SC가 좋은 대안이 될 수 있습니다.
원격 컴퓨터를 보고 제어할 수 있도록 하는 기본 기능은 이전 버전과 다를 바 없지만 이 UltraVNC SC 버전은 166K의 작은 UltraVNC 서버로 만들어졌기 때문에 쉽게 구성하여 최종 사용자에게 보낼 수 있다는 점에서 의의가 있습니다. 또한 레지스트리 항목이 필요 없으므로 서비스로 실행되지도 않고, 설치 프로그램이 필요 없으므로 최종 사용자가 설치하거나 구성하지 않아도 됩니다. 즉, 사용자가 실행 파일을 두 번 클릭하여 미니 VNC 서버를 실행하기만 하면 다른 컴퓨터에 연결하여 필요한 지원 및 관리 작업을 수행할 수 있습니다.
표준 UltraVNC 서버는 파일 및 디렉터리 전송을 모두 지원하지만 현재 UltraVNC SC의 경우 파일 전송만 지원합니다. 보안 측면에 있어서 최고 Microsoft Crypto API(40 또는 128 비트) 수준까지 통신이 암호화됩니다. 또한 미니 서버에서 들어오는 연결이 허용되지 않으므로 최종 사용자에 의해서만 인스턴스화되고 최종 사용자에게 보내기 전에 구성에서 지정한 컴퓨터에만 연결할 수 있습니다.
몇 가지 텍스트 구성 파일과 그래픽을 수정하고 PCHelpware라는 다른 프로젝트 추가 기능의 설치 폴더에서 배치 파일을 실행하면 사용자 지정 뷰어를 만들 수 있습니다. 설명서는 다소 부족하지만 프로세스가 비교적 간단하기 때문에 이해하는 데 큰 어려움은 없습니다. 끝으로, 이 응용 프로그램은 사용 후 연결을 닫으면 자동으로 삭제되므로 흔적이나 보안 허점을 남기지 않습니다.

가격: 무료

Greg Steen은 사업가이자 열성적인 기술 전문가로, IT 전문가의 운영, QA 및 개발 작업에 도움을 줄 수 있는 새로운 도구를 끊임없이 연구하고 있습니다.


 SQL Q&amp;A: 데이터베이스 크기 증가, IFilter 사용 및 원격 연결
SQL Q&A
데이터베이스 크기 증가, IFilter 사용 및 원격 연결
편집자: Matthew Graven

팁: 캐시 지우기
테스트 환경에서 문제 없이 작동하던 저장 프로시저를 프로덕션 SQL Server에 배포하면 성능이 저하되는 이유가 궁금했던 적이 있습니까? 이는 캐시와 관련된 문제일 수 있습니다. 저장 프로시저를 프로덕션 환경에 배포하기 전에 캐시된 쿼리 계획을 지운 후 테스트 환경에서 프로시저를 테스트하면 "콜드" 캐시 환경에서 저장 프로시저가 어떻게 실행되는지 알 수 있습니다. 다음은 유용하게 사용할 수 있는 몇 가지 방법입니다.
SQL Server의 프로시저 캐시를 지우려면
DBCC FREEPROCCACHE
Go
캐시된 모든 계획을 나열하도록 쿼리하려면
Select * from sys.dm_exec_cached_plans
Go

Q: 주간에 사용률이 매우 높은 데이터베이스를 보유하고 있습니다. SQL Server®에서 데이터베이스 사용률이 높은 주간에 자동 증가를 실행할 경우 제한 시간이 초과될 수 있으므로 이 기능을 사용하고 싶지 않습니다. 사용된 공간에 대한 특정 비율만큼 데이터베이스 파일을 확장하는 정기적인 작업을 실행하고 싶은데, 어떻게 해야 합니까?
A: 파일 증가는 상당한 디스크 I/O를 야기하는 작업이며 SQL Server에서 데이터 또는 로그 파일이 확장될 때까지 대기해야 하는 경우에는 성능 저하 및 응답 시간 지연 현상이 발생할 수 있습니다. 기본 증가치는 데이터 파일의 경우 1MB이고 로그 파일의 경우 10%인데 사용량이 많은 시스템에서 이러한 증가치는 부족할 수도 있습니다. 뿐만 아니라 데이터나 로그 파일은 디스크상에서 연속적으로 배치되어 있지 않으므로 자동 증가 기능을 사용할 경우 디스크 조각화가 일어날 수 있습니다. 즉, 데이터가 디스크에서 물리적으로 분산되어 있으므로 응답 시간이 불필요하게 길어질 수 있습니다.
우수한 성능을 얻기 위해서는 데이터와 로그 파일에 필요한 충분한 파일 공간을 사전에 할당하는 것이 매우 중요합니다. 이렇게 하려면 대개 추세 분석과 증가 예측 작업이 필요합니다. 이를 바탕으로 파일 공간을 사전에 할당하면 파일이 디스크에서 연속적으로 배치되고 사용률이 가장 높은 시간대에 자동 증가 실행에 따르는 I/O 비용이 들지 않으므로 성능이 향상됩니다. 데이터 파일이나 로그 파일이 완전히 꽉 차면 데이터베이스에 액세스할 수 없으므로 자동 증가 기능은 일반적으로 활성화된 상태로 두어야 합니다. 그러나 자동 증가는 데이터베이스 관리를 위한 기능이라기보다는 안전 조치 정도로 간주하는 것이 좋습니다.
정기적 데이터베이스 파일 확장 예약도 하지 말아야 합니다. 이것도 디스크상의 파일 불연속을 야기하여 성능 저하를 가져올 수 있습니다. SQL 에이전트 작업을 통해 스크립트를 정기적으로 실행하여 각 데이터베이스의 사용 가능한 공간 비율을 확인한 다음 데이터베이스 메일을 통해 전자 메일 알림을 보내는 등의 조치를 취함으로써 사전 모니터링을 실현할 수 있습니다. 그림의 코드는 현재 데이터베이스의 사용 가능한 공간 비율을 수집하는 방법을 보여 주는 샘플 스크립트를 제공합니다.
알림이 생성되면 ALTER DATABASE 명령을 사용하여 1회용 파일 증가 스크립트를 작성한 후 SQL 에이전트 작업을 사용하여 이 작업이 사용량이 많지 않은 시간대에 수행되도록 예약할 수 있습니다. 당분간 확장이 필요하지 않을 만큼 충분히 파일 크기를 증가시켜 파일 확장이 작은 단위로 발생하지 않도록 해야 합니다. 모든 데이터베이스에서 자동 축소 기능이 활성화되어 있지 않도록 하는 것도 좋습니다. 이 기능이 활성화되어 있으면 데이터베이스 축소 또는 증가 주기가 불필요하게 발생할 수 있습니다.
—Justin Langford
데이터베이스의 사용 가능한 공간 확인
-- 현재 사용자 데이터베이스의
-- 크기, 사용 가능한 공간을 수집하고
-- 사용 가능한 공간 비율을 계산하는 스크립트
DECLARE @size DEC(15,2)
DECLARE @free DEC(15,2)
DECLARE @result DEC(15,2)

SELECT @size = SUM(size)*1.0/128
FROM sys.database_files

SELECT @free =
(SUM(unallocated_extent_page_count)*1.0/128)
FROM sys.dm_db_file_space_usage

PRINT 'DB Size ' + CONVERT(VARCHAR(15), @size)
PRINT 'Free Space ' +
CONVERT(VARCHAR(15), @free)

SELECT @result = (@free/@size)*100

PRINT '% Free Space ' +
CONVERT(VARCHAR(15), @result)

Q: 우리 회사에서는 varbinary 및 image 열을 사용하여 회사 데이터베이스 내에 다양한 형식의 파일을 저장하고 있습니다. 이러한 다양한 파일 형식을 검색할 수 있는 기능이 SQL Server에 통합되었다고 들었습니다. 이 기능을 사용하려면 SQL Server를 어떻게 구성해야 합니까?
A: 이 기능은 전체 텍스트 인덱싱 서비스에 기본으로 제공됩니다. 이 서비스에서는 IFilter 인터페이스를 사용할 수 있으므로 독점적인 데이터에서 유용한 정보를 추출할 수 있는 필터를 개발하여 로드할 수 있습니다. 이 IFilter는 크롤링된 파일에 대한 정보를 수집하기 위해 Microsoft® Office SharePoint® Server와 같은 다른 제품에도 사용됩니다.
IFilter는 해당 파일 형식의 작성자 또는 타사 공급업체에서 제공합니다. SQL Server에는 HTML 및 DOC 파일용 필터를 비롯하여 FTS(FulltextService)가 설치될 때 로드되는 몇 가지 IFilter가 이미 포함되어 있습니다. 필요에 따라 다른 IFilter를 추가할 수 있습니다. 예를 들어 Adobe 웹 사이트에서 Adobe PDF용 필터를 얻을 수 있으며 2007년 말에 게시된 2007 Office system 확장 기능용 새 필터 팩을 사용할 수도 있습니다. 필요한 IFilter 버전을 알고 있어야 합니다. 예를 들어 32비트 시스템용 IFilter는 64비트 버전의 SQL Server에서 작동하지 않습니다.
클라이언트에서 설치 패키지를 실행하면 일반적으로 OS 환경에서 IFilter가 등록됩니다. OS에 IFilter가 등록되면 FTS에서 필터를 로드할 수 있도록 몇 가지 단계를 수행해야 합니다. 쿼리 실행 도구를 시작한 후 다음 명령을 실행합니다.
  • sp_fulltext_service 'load_os_resources',1. 이 문은 FTS에서 단어 분리기 및 형태소 분석기와 같은 구성 요소를 비롯하여 처리를 위해 등록된 IFilter를 로드할 수 있도록 합니다.
  • sp_fulltext_service 'verify_signature',0. 표준에 따라 필터에 서명해야 하는데 대부분의 공급업체는 그렇게 하고 있지 않기 때문에, 이 문은 SQL Server에서 사용된 필터의 서명 여부를 확인하는 절차를 생략합니다.
  • SQL Server 인스턴스와 FTS 인스턴스를 다시 시작합니다.
  • SQL Server에서 내용을 리디렉션할 필터를 선택할 수 있도록 IFilter가 크롤링할 내용이 포함된 이진 열과 확장명 열(DOCX와 같은 확장명 유형이 있는 열)에 대해 전체 텍스트 인덱스를 만듭니다.
자세한 내용은 go.microsoft.com/?linkid=7912971을 참조하십시오.
—Jens Suessmeyer

Q: 원격 SQL Server에 연결할 수 없습니다. 클라이언트나 서버 컴퓨터에 방화벽을 구성해야 합니까?
A: SQL Server 2005에 대한 원격 연결은 여러 가지 이유로 실패할 수 있는데, 가장 일반적인 문제 중 하나로 방화벽 구성이 있습니다. SQL Protocols 블로그(blogs.msdn.com/sql_protocols)에서 SQL 연결과 관련된 많은 리소스를 찾아볼 수 있습니다.
SQL Server 2005의 기본 설치에서는 원격 연결이 허용되지 않습니다. 원격 연결을 사용하려면 SQL을 실행하는 컴퓨터에서 시작 메뉴를 클릭하고 Microsoft SQL Server 2005 | 구성 도구 | SQL Server 노출 영역 구성을 차례로 선택합니다. 서비스 및 연결에 대한 노출 영역 구성으로 이동한 다음 원격 연결을 선택하고 "TCP/IP 및 명명된 파이프 모두 사용" 라디오 단추를 선택합니다. 그런 다음 SQL을 다시 시작하면 변경 사항이 적용됩니다.
기본적으로 SQL Server에서는 포트 1433을 사용합니다. 이 포트가 열려 있는지 확인하려면 다음 텔넷 명령을 사용합니다. 이 명령에서 <ipaddress>를 SQL Server를 실행하는 컴퓨터의 실제 IP 주소로 바꿉니다.
telnet <ipaddress> 1433
연결이 실패했다는 응답이 표시되면 Windows® 방화벽을 열고 예외 탭으로 이동한 다음 포트 추가를 선택하고 TCP 포트 1433을 추가합니다. 그러면 텔넷 연결에 성공합니다. 텔넷은 Windows Vista®에 기본적으로 설치되어 있지 않습니다.
—Rick Anderson
이 칼럼을 기고하는 데 도움을 주신 SQL Server 전문가:
Justin Langford는 영국에 본사를 둔 시스템 통합 전문 기업이자 Microsoft 인증 파트너인 Coeo Ltd.에서 근무하고 있습니다. Jens Suessmeyer는 독일 Microsoft에서 데이터베이스 컨설턴트로 근무하고 있습니다. Rick Anderson은 Microsoft의 개발자 교육 팀에서 근무하고 있습니다. Saleem Hakani는 Microsoft의 수석 데이터베이스 엔지니어이자 SQL Server 커뮤니티 운영자입니다.


 Utility Spotlight: Web Capacity Analysis Tool
Utility Spotlight
Web Capacity Analysis Tool
Greg Steen

웹 로그 및 기록 트래픽 분석에서는 시간의 흐름에 따라 트래픽 유형에 대한 유용한 정보를 제공하지만, 인프라에서 실제로 무엇이 처리되는지는 어떻게 확인할 수 있을까요? 이를 확인하려면 인프라와 응용 프로그램 스택을 중단점까지 밀어낼 수 있는 도구가 필요합니다. 이러한 도구로는 무료로 제공되는 WCAT(Web Capacity Analysis Tool)가 있으며, 이 도구는 웹 서버(또는 부하가 분산된 서버 팜)에서 스크립트로 작성된 HTTP 요청을 재생하고 추후 분석을 위해 성능 통계를 수집하는 간단한 부하 생성 유틸리티입니다. 최신 버전(이 문서에서는 6.3.1 기준)은 x86 및 x64 Windows 시스템(x86: iis.net/downloads/1466/ItemPermaLink.ashx, x64: iis.net/downloads/1467/ItemPermaLink.ashx) 모두에 제공되며 IPv6 네트워크를 지원합니다. 또한 WCAT는 다중 스레드 형식으로, 단일 소스에서 제어되는 여러 부하 테스트 클라이언트를 지원하므로 수많은 동시 사용자를 시뮬레이트할 수 있습니다.
이 유틸리티를 사용하면 테스트 클라이언트로 이전 시스템의 기능을 변경하고 각각의 테스트 클라이언트는 여러 가상 클라이언트(네트워크 어댑터 및 기타 클라이언트 시스템의 하드웨어에 따라 달라지는 최대 수)를 생성할 수 있습니다. SSL이 포함되거나 제외된 HTTP 1.0 또는 HTTP 1.1 요청을 선택할 수 있습니다. 그리고 테스트 시나리오에 이 요청이 필요한 경우, 스크립트로 작성된 기본 인증 또는 NTLM 인증을 사용하여 사이트의 제한된 영역에 액세스할 수 있습니다. (해당 사이트에서 쿠키, 폼 또는 세션 기반 인증을 사용하는 경우에는 올바른 GET 또는 POST 요청을 생성하여 테스트 사용자를 인증할 수 있습니다.) 또한 WCAT는 사이트에서 설정한 모든 쿠키를 관리하여 프로필 및 세션 정보를 유지합니다.
WCAT는 웹 사이트 인프라의 한계를 테스트하는 데 유용함
WCAT는 웹 사이트 인프라의 한계를 테스트하는 데 유용함
WCAT는 Microsoft® .NET Framework 콘솔 응용 프로그램을 신속하게 만들 수 있는 내용이 포함된 사용자 가이드와 함께 제공됩니다. 이러한 응용 프로그램은 사이트 트래픽 감사 기록의 사용자 트래픽 데이터를 기반으로 테스트 클라이언트 스크립트를 생성하며, 배포 전에 새로운 코드베이스에서 실제 트래픽을 시뮬레이트할 수 있도록 해 줍니다. 또한 직원 중에 C 프로그래머가 있는 경우, 시나리오 파일을 사용하여 호출할 수 있는 사용자 지정 함수 및 응답 처리기를 만들어 사용자 환경에 맞게 기능을 조정할 수 있습니다.
WCAT를 사용하려면 컨트롤러 파일(클라이언트 수, 클라이언트당 가상 클라이언트, 추적할 성능 카운터 및 테스트 중인 웹 서버와 같은 일반 테스트 설정이 포함됨)과 시나리오 파일(테스트 시나리오, 기본 요청 매개 변수 및 사용자 지정 함수, 라이브러리에 대한 참조가 포함됨)이라는 두 가지 파일을 구성해야 합니다.
이러한 응용 프로그램은 포함된 XSL 스타일시트에 적용할 수 있는 XML 파일에 테스트 결과를 기록하여 해당 결과를 Internet Explorer®에서 정리된 표 형식으로 보여 줍니다. 이 보고서에는 실행된 트랜잭션 수, 발생한 컨텍스트 스위치, CPU 이용률(전체 CPU 중에서) 및 발생한 총 오류 수와 같은 요약 정보가 포함됩니다. 또한 설정 파일에 구성한 성능 카운터의 결과(예제의 스크린샷 참조), 응답 시간 분석, 트랜잭션당 통계 보고서, 클라이언트당 중단 구역 및 테스트 설정이 구성된 방법에 대한 정보가 나열된 섹션을 얻을 수도 있습니다. 뿐만 아니라 현재 테스트 중인 원격 웹 서버의 하드웨어 구성 및 설치된 모든 업데이트 목록도 확인할 수 있습니다. 이는 사이트의 성능에 영향을 주는 패치를 확인하고 추적할 수 있는 좋은 방법입니다.
결론적으로 웹 사이트 인프라를 관리하는 경우, WCAT 유틸리티를 사용하면 추후 중요한 코드가 출시되기 전에 플랫폼이 부하 상태를 어떻게 처리하는지 손쉽게 확인할 수 있습니다.

Greg Steen은 사업가이자 열성적인 기술 전문가로, IT 전문가의 운영, QA 및 개발 작업에 도움을 줄 수 있는 새로운 도구를 끊임없이 연구하고 있습니다.


 The Cable Guy: NAP 적용 문제 해결
The Cable Guy
NAP 적용 문제 해결
Joseph Davies

Windows Vista, Windows Server 2008 및 Windows XP SP3에서 기본 제공되는 새로운 NAP(네트워크 액세스 보호) 플랫폼을 사용하면 컴퓨터 상태 요구 사항을 준수하도록 함으로써 개인 인트라넷을 보호할 수 있습니다. NAP의 주요 구성 요소는 NAP 클라이언트, NAP 적용 지점 및 NAP 상태 정책 서버입니다.
NAP 클라이언트는 시스템 상태 평가를 위한 상태 정보를 제공할 수 있는 컴퓨터입니다. NAP 적용 지점은 NAP를 사용하거나, NAP 클라이언트의 상태 평가를 요구하고 제한된 네트워크 액세스나 통신을 제공하기 위해 NAP와 함께 사용할 수 있는 컴퓨터 또는 네트워크 액세스 장치입니다. NAP 상태 정책 서버는 Windows Server® 2008과 상태 요구 사항 정책을 저장하고 NAP 클라이언트의 상태 평가를 수행하는 NPS(네트워크 정책 서버) 서비스를 실행하는 컴퓨터입니다. NAP 상태 정책 서버와 NAP 적용 지점에서는 RADIUS(Remote Authentication Dial-In User Service) 서버 및 프록시 메시지를 통해 시스템 상태 정보와 제한된 액세스 명령을 교환합니다.
이 칼럼에서는 상태 요구 사항 정책의 구성 요소, NPS 서비스에서 NAP 평가를 위해 들어오는 요청을 처리하는 방법, 그리고 NAP 적용과 관련된 가장 일반적인 문제를 해결하는 방법에 대해 설명합니다.

상태 요구 사항 정책
NAP 상태 평가 작동 방식
NAP 상태 정책 서버에서 실행되는 NPS 서비스는 다음과 같은 프로세스를 사용하여 상태 평가를 수행합니다.
  1. NPS 서비스가 들어오는 요청 메시지를 구성된 연결 요청 정책 집합과 비교합니다. NAP의 경우 NPS 서비스가 로컬에서 인증 및 승인을 수행하도록 지정하는 연결 요청 정책과 요청 메시지가 일치해야 합니다.
    2. 연결 요청 정책에 연결 요구 사항이 포함될 수도 있습니다. 예를 들어 802.1X 및 VPN 적용의 경우 연결 요청 정책이 PEAP(Protected Extensible Authentication Protocol) 기반 인증 방법을 사용하도록 요구합니다. 연결하는 클라이언트가 PEAP를 사용하지 않으면 연결 요청이 거부됩니다.
  2. NPS 서비스는 요청 메시지에서 SSoH(시스템 상태 설명)에 포함된 상태 정보를 평가합니다. NPS 서비스는 상태 정보를 설치된 SHV에 전달합니다. 그러면 SHV에서 상태 평가 정보를 NPS 서비스로 반환합니다.
  3. NPS 서비스는 요청 메시지와 SHV에서 반환하는 상태 평가 정보를 해당하는 네트워크 정책 집합과 비교합니다. 상태 평가 정보는 NAP 기반 네트워크 정책의 상태 정책 조건과 비교됩니다. 상태 정책 조건은 상태 정책 준수 여부에 대한 조건을 지정합니다. NPS 서비스는 처음 일치하는 네트워크 정책을 요청 메시지에 적용합니다.
  4. 일치하는 NAP 기반 네트워크 정책과 관련 NAP 설정을 기반으로 NPS 서비스는 SSoHR(시스템 상태 설명 응답)을 만듭니다. 이 응답은 SHV에서 반환된 상태 평가 정보를 포함하고 NAP 클라이언트의 액세스 제한 여부와 NAP 클라이언트가 자동으로 상태를 업데이트하는지 여부를 나타냅니다.
  5. NPS 서비스는 SSoHR을 포함한 RADIUS 응답 메시지를 NAP 적용 지점으로 보냅니다. 클라이언트에 제한된 액세스가 부여된 경우 이 응답 메시지에 NAP 클라이언트의 액세스를 제한하는 방법을 지정하는 명령이 포함될 수 있습니다.
  6. NAP 적용 지점은 SSoHR을 NAP 클라이언트로 보냅니다.

상태 요구 사항 정책은 연결 요청 정책, 하나 이상의 네트워크 정책, 하나 이상의 상태 정책, 그리고 NAP 적용 방법에 대한 NAP 설정의 조합입니다. 상태 요구 사항 정책을 만들려면 네트워크 정책 서버 스냅인의 NAP 구성 마법사를 사용하십시오. 평가 프로세스에 대한 자세한 내용은 "NAP 상태 평가 작동 방식" 추가 기사를 참조하십시오.
연결 요청 정책 연결 요청 정책은 NPS 서비스가 들어오는 연결 요청을 로컬로 처리할지 또는 다른 RADIUS 서버로 전달할지를 결정할 수 있는 순서가 지정된 규칙 집합입니다. NAP 상태 정책 서버는 연결 요청을 로컬로 처리합니다.
Windows® 기반 NAP 적용 지점에서 들어오는 RADIUS 요청에는 DHCP(Dynamic Host Configuration Protocol) 서버 또는 VPN(가상 사설망) 서버 같은 NAP 적용 지점 유형을 지정하는 소스 태그가 포함될 수 있습니다.
들어오는 요청 메시지에 소스 태그가 포함되어 있는 경우 NAP 상태 정책 서버의 NPS 서비스는 다른 모든 연결 요청 정책은 무시하고 일치하는 소스가 있는 연결 요청 정책에 대해서만 요청을 일치시키려고 합니다. 이와 반대로 들어오는 요청 메시지에 소스 태그가 포함되어 있지 않은 경우 NPS 서비스는 소스를 지정하는 다른 모든 연결 요청 정책은 무시하고 소스를 지정하지 않은 연결 요청 정책에 대해서만 요청을 일치시키려고 합니다.
예를 들어 NAP 사용 DHCP 서버에서 들어오는 요청은 소스 태그를 DHCP로 지정합니다. NPS 서비스는 DHCP 서버에서 들어오는 요청을 소스가 DHCP인 연결 요청 정책과 일치시키려고 시도합니다. 802.1X 지원 스위치 및 무선 액세스 지점에서 들어오는 요청은 소스 태그를 지정하지 않습니다. NPS 서비스는 이러한 요청을 소스를 지정하지 않은 연결 요청 정책과 일치시키려고 시도합니다.
로컬 또는 원격 처리 평가에 사용되는 연결 요청 정책은 들어오는 요청에 적용되는 정책 하위 집합의 순서가 지정된 목록에서 처음 일치하는 연결 요청 정책입니다. 일치하는 연결 요청 정책이 없는 요청은 거부됩니다.
네트워크 정책 네트워크 정책은 들어오는 요청 메시지에 해당하는 연결 시도를 승인하거나 거부하는 상황을 지정하는 순서가 지정된 규칙 집합입니다. 각 규칙에는 액세스를 부여하거나 거부하는 액세스 권한, 조건 집합, 제약 조건 집합 및 네트워크 정책 설정이 있습니다. 연결이 승인되면 네트워크 정책 제약 조건과 설정에 따라 연결 제한 집합이 지정될 수 있습니다. NAP의 경우 네트워크 정책에서 상태 요구 사항과 적용 동작 설정을 확인하는 상태 정책 조건을 지정할 수 있습니다.
연결 요청 정책과 마찬가지로 네트워크 정책은 소스 태그를 사용하여 들어오는 요청과 일치시킬 네트워크 정책을 결정합니다. 들어오는 요청 메시지에 소스 태그가 포함되어 있는 경우 NPS 서비스는 다른 모든 네트워크 정책은 무시하고 일치하는 소스가 있는 네트워크 정책에 대해서만 요청을 일치시키려고 합니다. 이와 반대로 들어오는 요청 메시지에 소스 태그가 포함되어 있지 않은 경우 NPS 서비스는 소스를 지정하는 다른 모든 네트워크 정책은 무시하고 소스를 지정하지 않은 네트워크 정책에 대해서만 요청을 일치시키려고 합니다.
승인 또는 상태 평가에 사용되는 네트워크 정책은 연결 시도에 적용되는 정책 하위 집합의 순서가 지정된 목록에서 처음 일치하는 네트워크 정책입니다. 연결 시도에 일치하는 네트워크 정책이 없는 경우 해당 요청은 거부됩니다.
상태 정책 상태 정책을 사용하면 상태 평가에 사용되는 설치된 SHV(시스템 상태 검사기)에서 상태 요구 사항을 지정할 수 있으며 선택한 SHV 중 일부 또는 전체에 대한 NAP 클라이언트 통과 여부도 지정할 수 있습니다. 예를 들어 정책을 준수하는 NAP 클라이언트에 대한 상태 정책에서는 클라이언트가 모든 상태 검사를 통과하도록 지정할 수 있으며 정책을 준수하지 않는 NAP 클라이언트에 대한 상태 정책에서는 클라이언트가 적어도 하나의 상태 검사나 모든 상태 검사를 통과하지 못하도록 지정할 수 있습니다.
네트워크 액세스 보호 설정 이 설정은 NAP 상태 정책 서버에 설치된 상태 요구 사항과 오류 조건에 대한 SHV의 구성과 DHCP 및 VPN 적용 방법에 대해 제한된 네트워크 액세스로 정책을 준수하지 않는 NAP 클라이언트에 액세스할 수 있는 서버 집합을 지정하는 업데이트 관리 서버 그룹으로 구성됩니다.

NAP 적용 문제의 범위 확인
문제를 해결할 때에는 논리적인 접근 방식이 도움이 됩니다. 문제 해결에서 자주 묻는 질문은 다음과 같습니다. 작동하는 것은 무엇입니까? 작동하지 않는 것은 무엇입니까? 작동하는 것과 작동하지 않는 것은 어떤 관계가 있습니까? 작동하던 것 중에 작동하지 않게 된 것이 있습니까? 그렇다면 마지막으로 작동한 후에 변경된 것은 무엇입니까?
NAP 적용 문제를 해결할 때에는 이러한 질문에 더 집중해야 합니다. NAP 적용 방법을 배포하기 전에는 연결 또는 연결 기능이 작동했습니까? 예를 들어 IPsec(인터넷 프로토콜 보안) 적용을 배포하기 전에는 IPsec 서버나 도메인 격리가 작동했습니까? 802.1X 적용을 배포하기 전에는 802.1X 인증이 작동했습니까? VPN 적용을 배포하기 전에는 VPN 원격 액세스가 작동했습니까? DHCP 적용을 배포하기 전에는 DHCP가 작동했습니까?
이전에는 특정 NAP 적용 방법이 작동했습니까? 그렇다면 NAP 클라이언트, NAP 적용 지점 또는 NAP 상태 정책 서버에서 변경된 것은 무엇입니까? 이러한 질문에 대한 답을 통해 어디에서부터 문제 해결을 시도해야 할지 알 수 있으며 문제를 일으킨 구성 요소, 계층 또는 구성을 찾을 수 있습니다.
NAP 적용 문제의 일반적인 해결 방법에서는 문제의 범위를 결정해야 합니다. 첫 번째 단계는 NAP 적용 자체가 문제가 아닌지 확인하는 것입니다. IPsec 적용의 경우에는 NAP 클라이언트에 IPsec 피어 협상과 데이터 보호를 위한 올바른 IPsec 정책 집합이 있는지 여부를 확인합니다. DHCP 적용의 경우에는 NAP 클라이언트가 DHCP 서버와 DHCP 메시지를 교환할 수 있는지 여부를 확인합니다. 802.1X 및 VPN 적용의 경우에는 NAP 클라이언트가 인증할 수 있는지 여부를 확인합니다. 예를 들어 VPN 클라이언트가 VPN 연결에 대한 인증을 수행할 수 없다면 VPN 클라이언트의 인증 설정과 자격 증명을 확인합니다.
NAP 적용이 문제라는 것을 확인했으면 이제 문제가 영향을 미치는 범위를 확인합니다. 모든 NAP 적용 방법의 모든 NAP 클라이언트가 영향을 받습니까? 특정 적용 방법의 모든 NAP 클라이언트가 영향을 받습니까? 특정 적용 방법의 모든 NAP 클라이언트와 NAP 적용 지점이 영향을 받습니까? 특정 그룹의 구성원인 모든 NAP 클라이언트가 영향을 받습니까? 특정 NAP 클라이언트만 문제의 영향을 받습니까?
예를 들어 모든 유형의 NAP 적용 방법에 대해 모든 NAP 클라이언트에서 문제가 발생한다면 NAP 상태 정책 서버에 구성 문제가 있는 것일 수 있습니다. 특정 NAP 적용 방법에 대해 모든 NAP 클라이언트에서 문제가 발생한다면 NAP 클라이언트에 대한 그룹 정책 설정에 구성 문제가 있거나 NAP 상태 정책 서버의 특정 NAP 적용 방법에 대한 상태 요구 사항 정책에 구성 문제가 있는 것일 수 있습니다. 특정 NAP 클라이언트에서만 NAP 적용 문제가 발생한다면 해당 NAP 클라이언트에만 NAP 적용 관련 구성 문제가 있는 것일 수 있습니다.

공통적인 NAP 적용 문제
NAP 리소스
  • 네트워크 액세스 보호 소개
  • 네트워크 액세스 보호 플랫폼 아키텍처
  • Windows Server 2008의 네트워크 액세스 보호 정책
  • NPS 네트워크 액세스 보호

무제한 액세스 NAP 클라이언트가 무제한으로 액세스할 수 있는 경우(액세스가 제한되지 않는 경우) NAP 클라이언트가 NAP 상태 정책 서버에 의해 정책을 준수하는 것으로 평가되었기 때문일 수 있습니다. 이것이 바로 사용자가 원하는 것입니다. 하지만 NAP 클라이언트가 SSoHR을 받지 못해 무제한 액세스가 부여된 것일 수도 있습니다. 일반적으로 NAP 클라이언트에 대한 상태 평가가 수행되지 않는 경우 이러한 문제가 발생합니다. NAP 상태 평가가 수행되지 않으면 NAP 클라이언트로 반환되는 SSoHR이 없으므로 NAP 클라이언트가 무제한으로 액세스할 수 있습니다.
예를 들어 DHCP 적용에 대해 구성된 NAP 클라이언트는 SSoHR을 해당 DHCP 서버로 보냅니다. Windows Server 2008을 실행하는 DHCP 서버가 NAP에 대해 구성되어 있지 않으면 NAP 상태 정책 서버로 상태 평가 요청 메시지를 보내지 않습니다. 뿐만 아니라 Windows Server 2008을 실행하는 DHCP 서버가 NAP에 대해 구성되어 있어도 NAP 상태 정책 서버에 연결할 수 없으면 기본적으로 액세스가 제한되지 않는 주소 구성을 할당합니다.
들어오는 요청이 NAP 상태 평가를 요구하지 않는 네트워크 정책과 일치하기 때문에 NAP 상태 정책 서버가 상태 평가를 수행하지 않는 경우에도 무제한 액세스가 부여될 수 있습니다. NAP 클라이언트의 요청과 일치하는 네트워크 정책을 확인하는 방법에 대한 자세한 내용은 이 칼럼의 "단계별 NAP 적용 문제 해결" 단원을 참조하십시오.
제한된 액세스 액세스가 제한된 NAP 클라이언트는 NAP 상태 정책 서버에 의해 정책을 준수하지 않는 것으로 평가된 것입니다. 무제한 액세스가 필요하지만 액세스가 제한된 NAP 클라이언트가 있다면 NAP 클라이언트의 요청과 일치하는 네트워크 정책에 해당하는 상태 정책 설정과 비교하여 NAP 클라이언트의 상태를 확인하십시오.
자동 업데이트 관리 수행 안 됨 올바르게 구성한 경우 NAP 클라이언트는 자신의 상태를 자동으로 업데이트할 수 있습니다. NAP 클라이언트가 자동 업데이트를 수행하지 못하면 NAP 클라이언트의 요청과 일치하는 네트워크 정책의 NAP 적용 설정에서 클라이언트 컴퓨터의 자동 업데이트 관리 사용 확인란이 선택되어 있는지 확인하십시오.
자동 업데이트 관리에 영향을 줄 수 있는 다른 문제는 제한된 NAP 클라이언트가 자동 업데이트 서버에 연결하여 업데이트를 다운로드할 수 없는 경우입니다. IPsec 적용의 경우에는 자동 업데이트 관리 서버에 올바른 IPsec 정책이 적용되었는지 확인하십시오. 802.1X 적용의 경우에는 일치하는 네트워크 정책에서 ACL(액세스 제어 목록) 또는 VLAN ID(가상 LAN 식별자)를 지정하는 설정을 확인하고 스위치나 무선 AP(액세스 지점)에 대한 ACL 또는 VLAN 구성을 확인하십시오. VPN 또는 DHCP 적용의 경우에는 일치하는 네트워크 정책에서 업데이트 관리 서버 그룹에 대한 설정을 확인하고 모든 업데이트 관리 서버가 그룹의 구성원으로 구성되어 있는지 확인하십시오. DHCP 적용의 경우에는 NAP 클라이언트에 대한 DHCP 범위 옵션이 올바르게 구성되어 있는지 확인하십시오(예: NAP 사용자 클래스의 기본 게이트웨어 옵션).
NAP 불가능 평가 모든 NAP 적용 방법의 경우 NAP 클라이언트에서 해당하는 적용 클라이언트가 설정되어 있는지 확인합니다. 802.1X 및 VPN 적용의 경우에는 NAP 클라이언트에 PEAP 인증 방법에 대한 시스템 상태 검사가 연결 요청 정책과 NAP 클라이언트 모두에 설정되어 있는지 확인합니다(보호된 EAP 속성 대화 상자에서 격리 확인 사용 확인란이 선택되어 있는지 확인함).
제한되지 않지만 인트라넷에 연결할 수 없는 NAP 클라이언트 IPsec 적용의 경우에는 정책을 준수하는 NAP 클라이언트의 IPsec 정책과 인트라넷 컴퓨터의 IPsec 정책에 협상 및 보호 설정이 공통적으로 지정되어 있는지 확인합니다. 802.1X 적용의 경우에는 정책을 준수하는 NAP 클라이언트에 대한 네트워크 정책이 제한된 네트워크가 아니라 인트라넷에 대한 ACL 또는 VLAN ID를 지정하는지 확인합니다. 또한 스위치나 무선 AP에서 인트라넷에 대한 ACL 또는 VLAN ID 구성을 확인합니다. VPN 적용의 경우에는 정책을 준수하는 NAP 클라이언트에 대한 네트워크 정책에 VPN 클라이언트의 트래픽을 제한하는 IP 패킷 필터가 구성되어 있지 않은지 확인합니다.

단계별 NAP 적용 문제 해결
특정 NAP 클라이언트와 관련된 NAP 적용 문제를 단계별로 해결하는 한 가지 방법은 NAP 클라이언트를 구성하고, NAP 클라이언트 이벤트 로그를 확인한 다음 NAP 상태 정책 서버로 이동하여 NPS 서비스에서 NAP 클라이언트의 요청을 어떻게 처리했는지 확인하는 것입니다.
1단계: NAP 클라이언트 구성 확인 NAP 클라이언트 구성은 Windows 서비스, 적용 클라이언트, NAP 적용별 설정으로 이루어져 있습니다. NAP 클라이언트 상태와 구성 정보를 표시하려면 netsh nap client show state 및 netsh nap client show configuration 명령을 사용합니다.
NAP 클라이언트 설정이 그룹 정책으로 제공되면 NAP 클라이언트의 모든 설정이 그룹 정책으로 지정되고 로컬 NAP 클라이언트 설정은 모두 무시됩니다. 이 경우에는 netsh nap client show grouppolicy 명령을 사용하여 그룹 정책 기반 NAP 클라이언트 구성을 표시하고 그룹 정책을 통해 변경합니다.
Windows Vista®를 실행하는 컴퓨터에 IPsec를 적용하는 경우에는 net start 명령을 사용하여 네트워크 액세스 보호 에이전트, IKE 및 AuthIP IPsec 키 지정 모듈, 그리고 IPsec 정책 에이전트 서비스가 시작되었는지 확인합니다. netsh nap client show configuration 명령을 사용하여 IPsec 신뢰 당사자 적용 클라이언트가 사용되는지 확인합니다. 필요한 경우 NAP 클라이언트 구성 스냅인을 사용하여 IPsec 신뢰 당사자 적용 클라이언트를 사용하도록 설정하거나 netsh nap client set enforcement 79619 enabled 명령을 사용합니다. netsh nap client set enforcement 명령은 상승된 권한으로 명령 프롬프트에서 실행해야 합니다.
Windows Vista를 실행하는 컴퓨터에 802.1X를 적용하는 경우에는 net start 명령을 사용하여 확장할 수 있는 인증 프로토콜, 네트워크 액세스 보호 에이전트, 유선 자동 구성(유선 연결에서 802.1X를 적용하는 경우) 및 WLAN 자동 구성(무선 연결에서 802.1X를 적용하는 경우) 서비스가 시작되었는지 확인합니다.
netsh nap client show configuration 명령을 다시 사용하여 EAP 격리 적용 클라이언트가 사용되는지 확인합니다. 필요한 경우 NAP 클라이언트 구성 스냅인을 사용하여 EAP 격리 적용 클라이언트를 사용하도록 설정하거나 netsh nap client set enforcement 79623 enabled 명령을 사용합니다. 유선 또는 무선 연결의 보호된 EAP 인증 방법 속성에서 격리 확인 사용 확인란이 선택되어 있는지 확인합니다.
Windows Vista를 실행하는 컴퓨터에 VPN을 적용하는 경우에는 net start 명령을 사용하여 확장할 수 있는 인증 프로토콜, 네트워크 액세스 보호 에이전트 및 원격 액세스 연결 관리자 서비스가 시작되었는지 확인합니다.
netsh nap client show configuration 명령의 출력에서 원격 액세스 격리 적용 클라이언트가 사용되는지 확인합니다. 필요한 경우 NAP 클라이언트 구성 스냅인을 사용하여 원격 액세스 격리 적용 클라이언트를 사용하도록 설정하거나 netsh nap client set enforcement 79618 enabled 명령을 사용합니다. VPN 연결의 보호된 EAP 인증 방법 속성에서 격리 확인 사용 확인란이 선택되어 있는지 확인합니다.
Windows Vista를 실행하는 컴퓨터에 DHCP를 적용하는 경우에는 net start 명령을 사용하여 네트워크 액세스 보호 에이전트 및 DHCP 클라이언트 서비스가 시작되었는지 확인합니다. 필요한 경우 서비스 스냅인이나 Sc.exe 도구를 사용하여 이러한 서비스를 시작하고 자동으로 시작되도록 구성합니다.
netsh nap client show configuration 명령의 출력에서 DHCP 격리 적용 클라이언트가 사용되는지 확인합니다. 필요한 경우 NAP 클라이언트 구성 스냅인을 사용하여 DHCP 격리 적용 클라이언트를 사용하도록 설정하거나 netsh nap client set enforcement 79617 enabled 명령을 사용합니다.
2단계: NAP 클라이언트 이벤트 로그 확인 이벤트 뷰어 스냅인을 사용하여 이벤트 로그에서 네트워크 액세스 보호 에이전트 서비스가 생성한 이벤트를 확인합니다. Windows Vista를 실행하는 컴퓨터에서는 이벤트 뷰어 스냅인을 사용하여 응용 프로그램 및 서비스 로그\Microsoft\Windows\Network Access Protection\Operational에서 이벤트를 확인합니다. Windows XP SP3을 실행하는 컴퓨터에서는 이벤트 뷰어 스냅인을 사용하여 시스템 이벤트 로그에서 NAP 이벤트를 확인합니다.
NAP 클라이언트 이벤트에서 NAP 클라이언트 상태 평가에 대한 상관 관계 ID를 확인합니다. 이 상관 관계 ID나 NAP 클라이언트의 컴퓨터 이름을 사용하여 NAP 상태 정책 서버에서 해당하는 상태 평가 이벤트를 찾을 수 있습니다. 그림 1에서는 상관 관계 ID가 있는 정책을 준수하지 않는 NAP 클라이언트에 대한 이벤트의 예를 보여 줍니다.
그림 1 Windows Vista NAP 클라이언트 이벤트의 예
그림 1 Windows Vista NAP 클라이언트 이벤트의 예
3단계: NPS 이벤트 로그 확인 NAP 상태 정책 서버에서 이벤트 뷰어 스냅인을 사용하여 Windows 로그\보안 로그에서 NPS 서비스가 생성한 이벤트를 확인합니다. NPS 이벤트를 보려면 이벤트 뷰어에서 사용자 지정 보기, 서버 역할을 차례로 연 다음 네트워크 정책 및 액세스 서비스를 클릭합니다. 이벤트와 관련된 온라인 도움말 항목을 보려면 이벤트의 일반 탭에서 "이벤트 로그 온라인 도움말" 링크를 클릭합니다.
일반적인 NAP 상태 평가 이벤트는 이벤트 ID 6278(무제한 액세스 관련) 또는 6276(제한된 액세스 관련)입니다. NAP 클라이언트의 컴퓨터 이름(이벤트 설명의 클라이언트 컴퓨터 섹션에서 계정 이름 필드)이나 상관 관계 ID(이벤트 설명의 격리 정보 섹션에서 세션 식별자 필드)를 기준으로 해당하는 NAP 상태 정책 서버 이벤트를 찾습니다.
NPS 이벤트 로그의 이벤트 6278과 6276에는 NAP 상태 평가에 대한 정보가 포함됩니다. 즉, 일치하는 연결 요청 정책 이름(이벤트 설명의 인증 정보 섹션에서 프록시 정책 이름 필드), 일치하는 네트워크 정책 이름(이벤트 설명의 인증 정보 섹션에서 네트워크 정책 이름 필드) 등이 포함됩니다. 그림 2는 이벤트 ID 6276의 자세히 탭을 보여 주는 예입니다. 여기에는 프록시 정책 이름, 네트워크 정책 이름, 상관 관계 ID(QuarantineSessionID) 등이 나와 있습니다. 이는 그림 1의 Windows Vista NAP 클라이언트 이벤트에 해당하는 NAP 상태 정책 이벤트입니다.
그림 2 NAP 상태 정책 서버 이벤트의 예
그림 2 NAP 상태 정책 서버 이벤트의 예
NAP 클라이언트 이벤트에 해당하는 이벤트가 없으면 네트워크 정책 서버 서비스가 시작되었는지, NAP에 대한 NAP 적용 지점이 올바르게 구성되었는지, NAP 상태 정책 서버를 RADIUS 서버로 사용하는지 확인합니다. NAP 적용 지점과 NAP 상태 정책 서버 간에 RADIUS 메시지를 전송할 수 있는지도 확인합니다.
이러한 세 가지 단계를 따르면 NAP 적용이 예상대로 작동하지 않는 이유를 쉽게 확인할 수 있습니다. NAP에 대한 자세한 내용은 "NAP 리소스" 추가 기사를 참조하십시오.

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


 Windows PowerShell: 여기 서명해 주세요
Windows PowerShell
여기 서명해 주세요
Don Jones

지난 2008년 1월 Windows PowerShell 칼럼에서 Windows PowerShell 스크립트에 있어서 디지털 서명이 얼마나 중요한지에 대해서는 이미 강조한 바 있습니다. 그리고 AllSigned 외에 다른 실행 정책을 사용할 경우 사용자 환경에 중대한 보안 취약점이 발생할 수 있는 몇 가지 시나리오에 대해서도 설명했습니다.
자세히 설명하지 않은 내용을 들라면 실제로 스크립트에 서명하는 방법이 있습니다. 이 내용은 technetmagazine.com/issues/2008/01/PowerShell을 참조하면 됩니다. 그렇다면 이번 달에는 어떤 내용을 다룰까요?

서명 이상의 그 무엇
서명이라는 단어는 여기서 다루려는 내용에 알맞은 기술 용어이지만 그 자체로는 실제 기능을 제대로 나타내지 못합니다. 스크립트에 서명한다고 해서 계약서 또는 신용 카드 전표의 경우처럼 스크립트를 승인하거나 인증하는 것은 아니기 때문입니다. 디지털 보안에서 서명은 어떤 항목에 자신의 ID를 첨부하여 해당 항목이 수정되지 않은 원본 그대로의 상태 또는 조건임을 보증하는 프로세스를 말합니다. 그리고 이러한 프로세스는 암호화를 기반으로 하며, 적어도 이 시나리오의 경우 암호화는 한 쌍의 암호화 키로 시작됩니다.
이러한 한 쌍의 키는 서로 다르기 때문에 비대칭 키라고도 합니다. 즉, 서명한 사용자만 액세스할 수 있는 개인 키와 누구나 액세스할 수 있는 공개 키의 쌍으로 이루어집니다. 간단하게 설명하자면 개인 키를 사용해 암호화한 모든 항목은 기본적으로 일치하는 공개 키로만 암호를 해독할 수 있습니다.
이러한 암호화가 어떻게 작동하는지 알아보겠습니다. 이번에도 칼럼을 진행하는 데 필요한 내용만 최대한 간단히 설명하겠습니다. 필자는 인증서에 들어 있는 개인 키를 사용하여 Windows PowerShell® 스크립트에 서명하려 합니다. Windows PowerShell 자체에는 스크립트와 인증서를 가져와서 실제 서명을 수행하는 cmdlet이 있습니다. 이 cmdlet에 대해서는 잠시 후에 설명하겠습니다. Windows PowerShell에서는 이러한 프로세스를 수행할 때 스크립트를 가져와서 필자의 개인 키를 통해 암호화합니다. 이렇게 암호화된 복사본은 스크립트 아래쪽에 알아볼 수 없는 텍스트 형식의 일련의 주석으로 추가됩니다(그림 1 참조). 필자의 ID도 이러한 주석으로 인코딩되지만 암호화되지는 않습니다. 따라서 ID 자체는 암호화 기술 없이도 읽을 수 있습니다.
그림 1 스크립트 맨 아래에 저장된 서명 블록
그림 1 스크립트 맨 아래에 저장된 서명 블록
그리고 나중에 Windows PowerShell은 서명을 찾아 필자의 ID를 디코딩하여 공개 키를 얻는 데 사용합니다. 서명의 나머지 부분은 필자의 공개 키로만 해독할 수 있으므로 Windows PowerShell에서 서명을 해독할 수 있다면 필자가 스크립트에 서명했다는 사실이 자연스럽게 증명됩니다. 다른 사람이 서명했다면 필자의 공개 키로는 서명을 해독할 수 없기 때문입니다. 서명이 해독되면 Windows PowerShell은 서명으로 암호화된 복사본과 스크립트를 비교합니다. 두 스크립트가 일치하면 서명이 변조되지 않은 것으로 간주됩니다. 그런데 두 스크립트가 서로 다르면 서명이 손상되어 잘못된 것으로 간주됩니다.
서명은 이러한 방식으로 다른 사람의 눈에 띄지 않게 일반 텍스트 스크립트가 수정되지 않도록 보호합니다. 스크립트 자체는 쉽게 수정할 수 있지만 서명은 필자의 개인 키 없이는 수정된 스크립트에 맞게 변경할 수 없습니다. 그리고 이러한 개인 키는 필자만 소유합니다.
여기서는 기본적인 기술 프로세스만 아주 간략하게 설명했습니다. 실제로는 서명에 공개 키의 복사본, 키를 발급한 CA(인증 기관)에 대한 정보 등 훨씬 많은 정보가 포함될 수 있습니다. 그러나 여기서 설명하는 내용만으로도 이 프로세스의 핵심적인 부분을 개괄하고 서명이 실질적으로 스크립트의 무단 수정을 방지하는 데 효과가 있음을 강조하는 데에는 충분하리라 생각합니다.
개인 키가 다른 사람의 손에 들어가면 이러한 프로세스는 의미가 없기 때문에 개인 키의 보호야말로 중요한 보안 요소라 할 수 있습니다. Windows에 키를 설치할 때에는 즉시 암호로 보호하여 악의적인 프로세스에 키가 무단으로 사용되는 일이 없도록 해야 합니다. 이 경우 개인 키를 스마트 카드에 보관하면 보다 효과적으로 보호할 수 있습니다. 스마트 카드의 개인 키는 절대 외부로 유출되지 않기 때문입니다. 대신 암호화할 데이터가 판독기 하드웨어를 통해 카드로 전송되고, 카드 자체의 회로에서 암호화를 수행한 후 결과를 다시 전송합니다.

인증서 얻기
이달의 Cmdlet: Export-CSV
PowerShellCommunity.org 포럼 참가자들은 Windows PowerShell에서 Microsoft Excel®로 데이터를 내보낼 수 있는지 많이 묻곤 합니다. 당연히 가능합니다. Excel은 기본적으로 CSV 파일을 열고 편집하고 저장할 수 있으므로 Export-CSV cmdlet을 사용하면 됩니다. 예를 들어 서비스 목록을 내보내려면 Get-Service | Export-CSV MyServices.csv를 실행하면 됩니다. 사실 Export-CSV는 모든 파이프라인의 끝에 첨부할 수 있으며 해당 파이프라인의 모든 개체가 지정한 CSV 파일로 내보내집니다. 기본적으로 Export-CSV는 파일의 맨 위에 헤더 줄을 추가합니다. 이 헤더는 내보낸 개체의 형식을 지정하는 데 사용됩니다. 그리고 이 줄은 주석으로 처리되므로 Excel에서 파일을 여는 데 방해가 되지 않습니다. 형식 정보를 내보내지 않으려면 Export-CSV에 -notype 매개 변수를 추가하면 됩니다. 또한 -force 매개 변수를 추가하여 기본적으로 표시되는 확인 메시지를 표시하지 않고 같은 이름의 기존 CSV 파일을 덮어쓰거나, 이름에서 잘 알 수 있듯이 -noClobber라는 매개 변수를 추가하여 기존 파일을 덮어쓰지 않도록 할 수 있습니다.

스크립트에 서명하려면 Class III Authenticode 코드 서명 인증서라는 특별한 인증서가 필요합니다. 이 인증서는 주로 세 가지 방법으로 얻을 수 있습니다. 첫째로, 조직의 내부 PKI(공개 키 인프라)가 있으면 해당 PKI를 사용합니다. 잘 구현된 PKI의 경우 루트 CA가 조직의 모든 컴퓨터에서 신뢰됩니다. 이는 CA에서 발급한 인증서를 조직 내에서 사용하기 위한 필수 조건입니다.
Windows® 2000부터 Windows Server®에는 자체 인증서 서버 소프트웨어가 포함되어 있는데, 이 소프트웨어를 사용하면 직접 PKI를 만들 수 있습니다. PKI를 완벽하게 구현하려면 치밀하게 계획해야 하지만 단지 코드 서명 인증서 발급 때문에 PKI가 필요한 경우에는 복잡한 계획 작업을 굳이 거치지 않아도 됩니다. 즉, 그룹 정책을 사용하여 CA의 루트 인증서를 컴퓨터에 배포하여 해당 컴퓨터에서 신뢰되도록 하기만 하면 됩니다.
둘째로, 상용 CA를 사용할 수 있습니다. 상용 CA를 사용할 경우 주요 CA 중 하나를 선택하면 해당 CA가 발급한 인증서를 신뢰하도록 조직의 컴퓨터가 이미 구성되어 있을 가능성이 크다는 장점이 있습니다. 한 가지 유의할 것은 Windows XP에서는 기본적으로 신뢰되는 CA 수가 많지만 Windows Vista®에서는 그 수가 훨씬 적다는 것입니다. 많이 사용되는 상용 CA로는 VeriSign(verisign.com)이 있습니다. 그 외에도 CyberTrust(cybertrust.com), Thawte (thawte.com) 등 고려할 만한 상용 CA가 많습니다.
코드 서명 인증서를 얻는 세 번째 방법은 Makecert.exe와 같은 도구를 사용해 자체 서명된 인증서를 만드는 것입니다. Windows Platform SDK와 함께 제공되는 Makecert.exe는 몇 가지 Microsoft® Office 버전에 설치되며 다른 곳에도 많이 사용됩니다. 자체 서명된 인증서의 장점은 무료로 사용할 수 있고 인프라가 필요 없다는 점입니다. 반면 해당 컴퓨터에서만 사용 가능하다는 단점도 있지만, 자신의 컴퓨터에서 스크립트를 실행(코드 서명 테스트 또는 일반적인 실험용으로)하는 데에만 사용하려는 경우에는 Makecert.exe가 바람직한 선택이 될 수 있습니다. 이 도구에 대한 자세한 내용은 go.microsoft.com/fwlink/?LinkId=108538에서 확인할 수 있습니다. 지난 수년 동안 이 도구의 여러 버전이 발표되었기 때문에 현재 사용자의 컴퓨터에서 실행하는 버전이 설명서의 내용과 다르게 작동할 수도 있다는 점을 유의하십시오.
Makecert.exe가 준비되면 Windows PowerShell 명령줄에서 다음과 같은 코드를 실행하여 자체 서명된 인증서를 만들 수 있습니다. 이 칼럼에서는 cmd.exe를 사용하는 경우는 설명하지 않겠습니다.
makecert -n "CN=MyRoot" -a sha1 –eku
1.3.6.1.5.5.7.3.3 -r -sv root.pvk root.cer
–ss Root -sr localMachine
그리고 다음 코드를 실행합니다.
makecert -pe -n "CN=MyCertificate" -ss MY
–a sh1 -eku 1.3.6.1.5.5.7.3.3 -iv root.pvk
–c root.cer
그러면 Makecert.exe가 키를 보호하는 데 사용할 암호를 묻고 인증서를 만듭니다. Windows PowerShell에서 다음 코드를 실행하면 설치 여부를 확인할 수 있습니다.
gci cert:\CurrentUser\My -codesigning
이 코드를 실행하면 CERT: 드라이브(Windows 인증서 저장소)의 모든 항목, 즉 코드 서명 인증서의 목록이 표시됩니다. Windows PowerShell에는 이러한 모든 프로세스에 대한 설명도 포함되어 있습니다. 이러한 설명을 보려면 About_Signing 도움말을 실행하고 화면에 표시되는 내용을 어느 정도 읽어 보십시오.

스크립트 서명
이제 인증서와 스크립트가 준비되었으므로 실제로 스크립트에 서명할 차례입니다. 마땅한 스크립트가 없다면 테스트용으로 간단히 하나를 만들면 됩니다. Windows PowerShell에서 다음 코드를 입력하기만 하면 됩니다.
$cert = @(gci cert:\currentuser\my
-codesigning)[0]
Set-AuthenticodeSignature myscript.ps1 $cert
첫 부분에서는 먼저 설치된 코드 서명 인증서를 검색합니다. 여러 인증서가 설치되어 있는 경우 첫 번째 인증서 외에 다른 인증서를 사용하려면 "0"을 해당 번호로 바꾸면 됩니다. 두 번째 부분에서는 파일에 서명합니다. 물론 이때에는 파일 이름을 서명하려는 파일 이름으로 변경해야 합니다. 매우 간단하지 않습니까? 이 과정에서 약간의 수고가 들어간 부분을 솔직히 밝히자면 Set-AuthenticodeSignature라는 cmdlet 이름이 너무 길어서 Sign이라는 별칭을 만든 것입니다. 이제 다음 코드를 실행하면 됩니다.
Sign myscript.ps1 $cert
해당 스크립트를 열면 맨 아래에 서명 블록이 삽입된 것을 확인할 수 있습니다. 그리고 실행 정책을 AllSigned(Set-ExecutionPolicy AllSigned)로 설정하고 스크립트를 실행해보면 문제 없이 작동하는 것을 확인할 수 있습니다. 이제 스크립트를 수정하고 저장할 수 있는데, 이 경우 다시 서명하지 않도록 주의해야 합니다. 다시 서명하면 서명이 손상되어 Windows PowerShell에서 수정된 버전의 실행이 거부됩니다.

약간의 수고와 큰 효과
이러한 프로세스가 그 효과에 비해 너무 번거롭다고 생각하십니까? 인증서에 500달러를 투자하거나 완전히 새로운 인프라 요소를 구현하지 않고 몇 가지 관리 작업을 스크립팅할 수 있다면 좋겠는데 요구 사항이 너무 많습니까? 필자 자신도 관리자의 입장에서 여러분의 생각은 충분히 이해할 수 있습니다. 그러나 단언컨대 여기서 설명하는 내용은 그만한 가치가 있습니다.
사실 보안과 관련해서는 항상 어느 정도의 노력과 비용이 뒤따릅니다. 바이러스 백신 소프트웨어가 골칫거리일 수도 있지만 그렇다고 바이러스 백신 소프트웨어를 사용하지 않을 수는 없습니다. 방화벽 소프트웨는 확실히 귀찮고 번거롭지만 방화벽 없이 안전을 보장할 수는 없습니다. 그리고 Windows Vista UAC(사용자 계정 컨트롤)도 번거롭게 여겨질 수 있지만 컴퓨터의 보안을 강화하기 위한 약간의 수고일 따름입니다. 어쨌든 우리의 궁극적인 목표가 바로 이렇게 강화된 보안이 아닙니까?
Windows PowerShell은 강력한 도구이지만 다른 도구와 마찬가지로 악의적인 사용자에 의해 보안 취약점으로 악용될 소지를 항상 가지고 있습니다. 따라서 이러한 악의적인 사용자를 막기 위한 조치가 중요합니다.
그러한 맥락에서 코드 서명은 가장 효과적인 방법이며 번거로운 작업이 많이 요구되지도 않습니다. 예를 들어 필자의 경우에는 저장 단추를 누를 때마다 스크립트에 자동으로 서명하는 그래픽 스크립트 편집기를 사용하기 때문에 코드 서명 프로세스에 신경을 쓰지 않아도 됩니다.
그래픽 편집기 없이 훨씬 간편하게 처리할 수 있는 방법도 있습니다. 예를 들어 고유한 Windows PowerShell 프로필(문서 폴더의 WindowsPowerShell 폴더에 Microsoft.PowerShell_profile.ps1이라는 파일을 생성)을 만들고 거기에 다음 함수를 추가하면 됩니다.
function sign ($filename) {
  $cert = @(gci cert:\currentuser\my
-codesigning)[0]
Set-AuthenticodeSignature $filename $cert
}
그리고 다음을 입력하여 간단히 스크립트에 서명할 수 있습니다.
Sign c:\scripts\myscript.ps1
물론, 이 경우 해당 프로필 스크립트를 가장 먼저 서명해야 합니다. 여기서 핵심은 가능한 한 편리하게 스크립트에 서명할 수 있도록 하자는 것입니다.
코드 서명 인증서를 발급하는 용도로만 사용할 단일 서버 PKI를 배포하는 일을 그리 어렵지 않습니다. 그러나 특히 다른 용도로도 사용하는 경우에는 루트 CA를 보호하고 재해 복구 기능을 제공하는 등 PKI에 대해 철저히 연구하고 계획해야 합니다. 환경에서 스크립트를 실행하는 사용자가 여러분 혼자라면 언제든 Makecert.exe를 사용할 수 있습니다. Makecert.exe로 만든 인증서를 보호하는 방법에 대한 자세한 내용은 About_Signing Windows PowerShell 도움말 항목에서도 제공됩니다.

Don Jones는 Windows PowerShell: TFM and VBScript, WMI, and ADSI Unleashed의 저자입니다. 문의 사항이 있으면 PowerShellCommunity.org 웹 사이트를 통해 연락하시기 바랍니다.


 Hey, Scripting Guy!: 데이터베이스 스크립트의 귀환
Hey, Scripting Guy!
데이터베이스 스크립트의 귀환
Microsoft Scripting Guys
이 기사의 코드 다운로드: HeyScriptingGuy2008_04.exe (151KB)

Scripting Guy의 약점을 굳이 한 가지 들자면(물론 여러분도 우리가 약점이 없다는 건 잘 아시겠지만) 항상 어떤 일을 하거나 하지 않은 데 따른 결과에 너무 신경을 쓴다는 정도일 겁니다. 덕분에 늘 자신이 원하는 일보다는 다른 사람들이 원하는 일이 무엇일까를 먼저 생각하게 됩니다. 그리고 우리 자신에게 어떤 결과로 돌아올지는 생각하지 않습니다.
데이터베이스 스크립팅에 대한 기사를 예로 들어 보겠습니다. 솔직히 데이터베이스 스크립팅에 대한 기사는 쓰기가 까다롭습니다. 데이터베이스 스크립팅 자체가 어려워서가 아닙니다. 사실 상당히 쉽습니다. 문제는 Scripting Guy는 데이터베이스 관련 작업을 할 기회가 별로 없기 때문에 데이터베이스에 대한 내용을 쓸 때마다 한 번씩 더 생각해야 한다는 데 있습니다. 이미 오래전에 알았겠지만 Scripting Guy를 뽑을 때 '생각하는 능력' 같은 건 신경도 쓰지 않습니다.
사실 우리 중 애당초 깊이 생각하는 사람이 있었다면 아마 지금 Scripting Guy는 한 명도 없겠죠.
Scripting Guy는 데이터베이스 스크립팅에 대한 기사가 이렇게 쓰기 힘든데도 왜 계속 쓰고 있을까요? 대답은 간단합니다. 우리가 이런 기사를 중단하면 세상이 어떤 혼란에 빠질지 걱정되기 때문입니다. 셜록 홈즈라는 주인공에 싫증을 느낀 아서 코난 도일 경은 "마지막 사건(The Final Problem)"이라는 작품에서 절벽에서 떨어뜨려 그를 죽이기로 결심합니다. 그런데 전 세계에서 항의가 빗발치기 시작했습니다. 일부 보도에 따르면 뉴스를 접한 런던 시민들이 실제로 모자와 소매에 애도의 표시를 달았다고 합니다. "마지막 사건"이 1893년 The Strand Magazine에 실리자 20,000명이 구독을 중단했다고 전해집니다.
혹독한 대가를 치렀군요.
Scripting Guy가 데이터베이스 스크립팅에 대한 기사를 죽이면 전 세계에 이와 같은 반향을 불러오지 않을까 우려하는 것입니다. 우리 때문에 사람들이 두통과 절망에 시달리고 독자 20,000명이 TechNet Magazine 구독을 중단하게 되는 일은 절대로 원하지 않으니까요. 따라서 Scripting Guy는 데이터베이스 스크립팅에 대한 기사를 계속 쓸 것을 공표하는 바입니다. 언제 쓸 거냐고요? 지금 바로 쓴다면 어떻겠습니까?

데이터베이스에 레코드 추가
이번 달 기사에서는 몇 가지 유용한 데이터베이스 작업 비법을 소개하겠습니다. 그렇습니다. 2007년 9월 칼럼(technetmagazine.com/issues/2007/09/HeyScriptingGuy)에서 소개한 비법에 추가로 몇 가지 더 소개하는 것입니다. Scripting Guy라도 똑같은 기사를 두 번이나 우려먹고 싶지는 않으니까요.
그렇게 해서 이번 달은 얼렁뚱땅 넘어갈 수 있을 텐데도 말입니다.
먼저 데이터베이스에 레코드를 추가하는 간단한 방법을 한 가지 소개하겠습니다. C:\Scripts\Inventory.mdb라는 데이터베이스에 Computers라는 테이블이 있고, Computers 테이블에는 다음 필드가 포함되어 있다고 가정해 봅니다.
  • ComputerName
  • SerialNumber
  • UserName
  • Department
자, 이제 이 데이터베이스에 새 컴퓨터를 추가하려면 어떻게 해야 할까요? 그림 1의 코드를 살펴보겠습니다.
Figure 1 Computers 테이블에 레코드 추가 (Close Figure 1)
Const adOpenStatic = 3
Const adLockOptimistic = 3

Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")

objConnection.Open _
    "Provider = Microsoft.Jet.OLEDB.4.0; " & _
        "Data Source = C:\Scripts\Inventory.mdb"

objRecordSet.Open "INSERT INTO Computers (ComputerName, SerialNumber, UserName, Department)" &  _
    "VALUES ('atl-ws-07', '11234', 'Ken Myer', 'Finance')", _
        objConnection, adOpenStatic, adLockOptimistic
이 스크립트의 첫 번째 줄에 대해서는 자세히 설명하지 않겠습니다. 관련 배경 지식이 필요한 독자는 스크립트 센터(microsoft.com/technet/scriptcenter)의 리소스를 참조하시기 바랍니다. 여기서는 adOpenStatic과 adLockOptimistic이라는 상수를 사용해 레코드 집합의 커서 형식과 레코드 잠금을 제어한다는 정도만 이야기하겠습니다. 대단하게 들리지만 사실 간단한 내용입니다. ADODB.Connection 및 ADODB.Recordset 개체의 인스턴스를 만든 후에는 다음 명령을 사용하여 데이터베이스를 엽니다.
objConnection.Open _
"Provider = Microsoft.Jet.OLEDB.4.0; " & _
"Data Source = C:\Scripts\Inventory.mdb"
이것은 Microsoft® Access® 2003 데이터베이스를 여는 명령입니다. Access 2007 데이터베이스를 열려면 다음 명령을 사용해야 합니다.
objConnection.Open _
"Provider = Microsoft.ACE.OLEDB.12.0; " & _
"Data Source = C:\Scripts\Inventory.accdb"
주제에서 다소 벗어난 이야기지만, 다음과 같은 유사한 명령으로 SQL Server® 데이터베이스를 열 수도 있습니다.
objConnection.Open _
"Provider=SQLOLEDB;" & _
"Data Source=atl-sql-01;" & _
"Trusted_Connection=Yes;" & _ "InitialCatalog=Inventory;" & _
"User ID=fabrikam\kenmyer;Password=34DE6t4G!;"
지금까지 살펴본 내용은 앞으로 설명할 모든 데이터베이스 스크립트의 기반이 되는 기본적인 코드입니다. 실제로 여기서 강조하고 싶은 코드 부분은 다음입니다.
objRecordSet.Open _
  "INSERT INTO Computers " & _
  "(ComputerName, SerialNumber, " & _
  "UserName, Department) " & _
    "VALUES ('atl-ws-07', 'A14B1234', " & _
      "'Ken Myer', 'Finance')", _
        objConnection, adOpenStatic, _
        adLockOptimistic
이 코드에서는 INSERT INTO 쿼리를 사용하여 Computers 테이블에 새 레코드를 삽입합니다. 테이블 이름 다음에 값이 들어가는 모든 필드의 이름을 쉼표로 구분하고 전체를 괄호로 묶어 삽입한 것을 알 수 있습니다.
여기서 "값이 들어가는 모든 필드"가 대체 무슨 뜻인지 궁금해 하는 독자도 있을 것입니다. 좋은 질문입니다. 새로 추가하는 컴퓨터에 아직 Department가 할당되지 않았다고 가정해 봅시다. 데이터베이스에서 Department 필드에 Null 값이 허용된다면 Department에 값을 할당하지 않은 채로 그냥 두어도 됩니다. 즉, 다음과 같이 쿼리를 작성할 수 있습니다.
objRecordSet.Open _
  "INSERT INTO Computers " & _
  "(ComputerName, SerialNumber, " & _
  "UserName) " & _
    "VALUES ('atl-ws-07', 'A14B1234', " & _
      "'Ken Myer')", _
        objConnection, adOpenStatic, _
        adLockOptimistic
값 할당과 관련하여 필드 이름 뒤에 어떤 항목이 오는지 살펴보십시오. VALUES 키워드와 각 필드에 할당할 값(역시 괄호로 묶임)이 옵니다. 필드 이름을 나열할 때 순서는 관계가 없습니다. 예를 들어 ComputerName이 데이터베이스에서 첫 번째 필드가 아닐 수도 있지만 맨 먼저 나열할 수 있습니다. 필드 이름은 이렇게 순서에 관계없이 나열할 수 있지만 값의 경우는 이와 다릅니다. 값은 필드와 동일한 순서로 나열해야 합니다. 첫 번째로 나열하는 필드가 ComputerName이면 첫 번째 값은 컴퓨터의 이름이 되어야 합니다. 그렇지 않으면 ComputerName 필드에 사용자 이름이나 일련 번호가 할당되는 등의 문제가 발생합니다.
보다시피 값을 할당하는 방법은 그다지 복잡하지 않습니다. 값의 형식을 데이터 형식에 맞추는 데만 유의하면 됩니다. 즉, 날짜 값과 문자열 값은 작은따옴표로 묶어야 하고 숫자 값과 부울 값은 작은따옴표로 묶어서는 안 됩니다.
아! 그리고 O'Brien이라는 이름처럼 값 자체에 작은따옴표가 들어 있는 경우에는 다음과 같이 작은따옴표를 하나 더 추가해 "이스케이프" 문자로 사용해야 합니다.
'O''Brien'
뭐, 이상하지만 사실이 그런 것을 어쩌겠습니까.

데이터베이스에서 레코드 삭제
SQL 쿼리를 하나만 실행하면 데이터베이스에 레코드가 추가된다니, 멋지지 않습니까? 이보다 간단한 방법은 없을 것 같습니다. 적어도 우리가 아는 한은 말이죠.
그런데 이보다 더 멋진 것은 쿼리 하나로 데이터베이스에서 여러 레코드를 삭제할 수 있다는 사실입니다.
회사에서 인사(Human Resources) 부서를 없애기로 결정했다고 가정해 봅시다. 농담이 아니라 솔직히 Microsoft HR 부서가 존재한다는 자체만으로도 신경이 쓰이니, 없으면 좋겠지만 말입니다. 어쨌든 Inventory 데이터베이스에서 Human Resources 컴퓨터를 모두 삭제하려면 어떻게 해야 할까요? 그 방법은 그림 2에서 확인할 수 있습니다.
Figure 2 여러 레코드 삭제 (Close Figure 2)
Const adOpenStatic = 3
Const adLockOptimistic = 3

Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")

objConnection.Open _
    "Provider = Microsoft.Jet.OLEDB.4.0; " & _
        "Data Source = C:\Scripts\Inventory.mdb"

objRecordSet.Open "DELETE * FROM Computers Where Department='Human Resources'", _
    objConnection, adOpenStatic, adLockOptimistic
보다시피 이 스크립트의 시작 부분은 새 레코드를 추가하는 스크립트와 동일합니다. 다시 말해 상수를 몇 가지 정의하여 개체를 만들고 Inventory.mdb 데이터베이스에 연결하는 것입니다. 그런 다음 DELETE 쿼리를 사용해 Computers 테이블에서 모든 레코드(*) 또는 Department 필드가 Human Resources인 레코드를 모두 삭제하면 됩니다.
objRecordSet.Open _
  "DELETE * FROM Computers " & _
   "Where Department='Human Resources'", _
    objConnection, adOpenStatic, _
    adLockOptimistic
절벽에서 뛰어내리는 일만큼 쉽지 않습니까?
셜록 홈즈를 비꼬려는 의도는 전혀 없습니다.

데이터베이스의 레코드 업데이트
Human Resources 부서의 흔적을 모두 지워버리는 것만큼 신나는 일도 없을 겁니다. (Microsoft HR 부서에 전하는 말: 다른 회사 직원들과 그 HR 부서에 대한 이야기입니다. 당연히 우리 회사는 아니죠. 우리 회사 HR 부서가 없어진다면 정말 슬픈 일일 겁니다.) 어쨌든 Inventory 데이터베이스에서 HR 컴퓨터를 모두 삭제하는 것은 최선의 방법이라 할 수 없습니다. 왜냐고요? HR 부서 직원이 사용하던 하드웨어를 모두 가지고 종적을 감추지 않는 한(흠, 실제로 그럴 것도 같은데) 해당 컴퓨터는 여전히 회사 소유이고, 따라서 데이터베이스에 포함되어 있어야 합니다. 이러한 사실을 고려하여 다음과 같이 해보겠습니다. 데이터베이스에서 해당 레코드를 삭제하는 대신 각 레코드를 업데이트하는 것입니다. 각 컴퓨터의 부서 이름을 Human Resources에서 None으로 바꾸기만 하면 됩니다. 다시 말해 그림 3의 스크립트를 실행하는 것이지요.
Figure 3 레코드 업데이트 (Close Figure 3)
Const adOpenStatic = 3
Const adLockOptimistic = 3

Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")

objConnection.Open _
    "Provider = Microsoft.Jet.OLEDB.4.0; " & _
        "Data Source = C:\Scripts\Inventory.mdb"

objRecordSet.Open "UPDATE Computers Set Department = 'None' " & _
    "Where Department = 'Human Resources'", _
    objConnection, adOpenStatic, adLockOptimistic
이 스크립트도 SQL 쿼리를 제외하면 앞서 살펴본 스크립트와 다를 바가 없습니다. 여기서는 UPDATE 쿼리를 사용하여 Computers 테이블의 레코드를 업데이트합니다. UPDATE 키워드와 함께 레코드를 업데이트하는 방법과 업데이트할 레코드를 쿼리에 지정하는 매개 변수 2개를 추가해야 합니다.
  • Set Department = 'None'. 이 매개 변수는 Department 필드의 값을 새로 지정합니다. 사실 Set Department = 'None', UserName = 'None'과 같은 구문을 사용하면 한 번에 여러 필드의 값을 설정할 수 있습니다. 이 경우 Department 필드와 UserName 필드가 모두 None으로 설정됩니다.
  • Where Department = 'Human Resources'. 이 매개 변수는 업데이트할 레코드를 지정하는 표준 Where 절입니다. 예제의 경우 Department 필드가 Human Resources인 모든 레코드가 해당합니다. 이 매개 변수를 사용하는 이유는 데이터베이스의 모든 레코드를 수정하는 것이 아니라 이전에 Human Resources 부서에 속해 있던 레코드(컴퓨터)만 수정해야 하기 때문입니다.
Update 쿼리를 다른 용도로 유용하게 활용할 수도 있습니다. 회사에서 모든 직원의 급여를 10% 인상하기로 결정했다고 가정해 봅니다. (흠, 적어도 한 가지 측면에서 Scripting Guy와 아서 코난 도일 경은 공통점이 있군요. 바로, 글 속에서 허구의 세계를 창조한다는 점이죠.) 다음 스크립트는 Employees라는 테이블을 열고 각 직원의 Salary 필드를 수정합니다. 그러면 Salary 필드가 어떻게 설정되는 걸까요? 이 쿼리는 해당 필드를 직원의 현재 급여에 1.1을 곱한 값으로 설정합니다. 즉, 각 직원의 급여가 10% 인상되는 것이죠. (아, 현실에서도 급여 인상이 이렇게만 쉽다면 얼마나 좋겠습니까!) 쿼리는 다음과 같습니다.
objRecordSet.Open _
  "Update Employees " & _
  "Set Salary = (Salary * 1.1)", _
    objConnection, adOpenStatic, _
    adLockOptimistic
이게 뭐가 그렇게 멋지다는 말이냐고요? 보다시피 Update 쿼리에서 계산을 실행할 수 있습니다. 모든 계약직 직원의 계약 기간을 60일 연장한다고 생각해 보십시오. 이 경우 다음과 같은 쿼리를 유용하게 사용할 수 있을 겁니다.
objRecordSet.Open _
  "Update TempEmployees " & _
  "Set ContractExpirationDate = " & _
  "(ContractExpirationDate + 60)", _
    objConnection, adOpenStatic, _
    adLockOptimistic

유용한 데이터 검색 방법
유용한 쿼리에 대해서 이야기가 나온 김에, 마지막으로 데이터베이스에서 데이터를 검색하는 몇 가지 유용한 방법을 살펴보는 것으로 칼럼을 마치도록 하겠습니다. 간단하지만 매우 유용한 스크립트 하나를 예로 들어 보겠습니다. Inventory 데이터베이스에 Price라는 필드가 있다고 가정합니다. 이름에서 알 수 있듯이 이 필드는 컴퓨터의 가격을 나타냅니다. 회사에서 가장 고가의 컴퓨터 5대를 알고 싶다면 그림 4의 샘플 스크립트를 실행하면 됩니다.
Figure 4 레코드 집합 정렬 (Close Figure 4)
Const adOpenStatic = 3
Const adLockOptimistic = 3

Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")

objConnection.Open _
    "Provider = Microsoft.Jet.OLEDB.4.0; " & _
        "Data Source = C:\Scripts\Test.mdb"

objRecordSet.Open "SELECT Top 5 * FROM Computers Order By Price", _
     objConnection, adOpenStatic, adLockOptimistic

objRecordSet.MoveFirst

Do Until objRecordset.EOF
    Wscript.Echo objRecordset.Fields.Item("ComputerName")
    objRecordset.MoveNext
Loop

objRecordSet.Close
objConnection.Close
그림에서 볼 수 있듯이 이 SQL 쿼리는 두 가지 작업을 실행합니다. 즉, Price를 기준으로 레코드 집합을 정렬(Order By Price)하고, SELECT Top 5로 최상위 컴퓨터 5대(가장 고가의 컴퓨터 5대)만 결과로 반환합니다. 가장 고가의 컴퓨터 10대의 목록을 표시하려면 다음 쿼리를 사용하면 됩니다.
objRecordSet.Open _
  "SELECT Top 10 * FROM Computers " & _
  "Order By Price", _
    objConnection, adOpenStatic, _
    adLockOptimistic
참고로, 레코드 집합에서 반복 실행하고 각 컴퓨터의 이름을 표시하는 코드도 추가했습니다. 이전 스크립트의 경우에는 데이터를 반환하고 표시하지 않기 때문에 이러한 코드가 필요 없었습니다.
또는 다음 쿼리로 상위 10%에 해당하는 결과를 반환할 수도 있습니다.
objRecordSet.Open _
  "SELECT Top 10 PERCENT * " & _
  "FROM Computers Order By Price", _
    objConnection, adOpenStatic, _
    adLockOptimistic
그렇다면 가장 저가의 컴퓨터를 알아보려면 어떻게 해야 할까요? 이 경우에도 문제 없습니다. 같은 방법을 사용하되, 가장 저가에서 가장 고가의 순서(내림차순)로 레코드 집합을 정렬하기만 하면 됩니다. 다시 말하면 같은 쿼리에 레코드 집합을 내림차순으로 정렬하도록 지정하는 DESC를 사용하는 것입니다.
objRecordSet.Open _
  "SELECT Top 5 * FROM Computers " & _
  "Order By Price DESC", _
    objConnection, adOpenStatic, _
    adLockOptimistic
이제 아시겠죠? 왜 유용하다고 했는지를 말입니다.
흥미로운 스크립트를 두 가지만 더 소개하겠습니다. 데이터베이스에 원래 컴퓨터 예산으로 책정된 금액을 추적하는 Budgeted라는 필드가 있다고 가정해 보겠습니다. 그리고 실제 비용과 예산 금액을 비교하려는 경우 다음 쿼리를 실행하면 예산 금액보다 비용이 많이 소요된 컴퓨터의 목록이 반환됩니다.
objRecordSet.Open _
  "SELECT * FROM Computers " & _
  "Where (Budgeted < Price)", _
    objConnection, adOpenStatic, _
    adLockOptimistic
반면, 다음 쿼리는 모든 컴퓨터의 평균 가격을 계산(SELECT AVG(Price) FROM Computers)한 다음 평균 가격보다 저렴한 모든 컴퓨터의 목록을 반환합니다.
objRecordSet.Open _
  "SELECT * FROM Computers " & _
  "WHERE Price < " & _
  "(SELECT AVG(Price) FROM Computers)", _
    objConnection, adOpenStatic, _
    adLockOptimistic
예, 맞습니다. Where 절에 SELECT 쿼리를 사용한 것입니다. 이 스크립트가 어떻게 작동하냐고요? 이는 칼럼 주제를 벗어난 또 다른 내용이므로 다음을 기약해야 할 것 같습니다. 단, 보다시피 SQL 쿼리를 사용하여 모든 유용한 정보를 검색할 수 있는 길을 열어 준다는 정도만 말하겠습니다.

이야기의 교훈
이번 달 칼럼을 시작하면서 밝혔듯이 Scripting Guy에게 데이터베이스 스크립팅에 대한 기사는 상당히 부담스럽습니다. 그러나 독자 여러분에게 유용한 쿼리를 소개할 수 있었다는 점에서 기사를 작성한 것에 대해 뿌듯하게 생각합니다. 그뿐만 아니라 이번이 아니더라도 언젠가는 다루어야 할 내용이니까요. 아서 코난 도일 경도 결국 팬들의 성화에 못이겨 셜록 홈즈를 되살려내지 않았습니까. 아서 코난 도일 경은 셜록 홈즈가 죽기 전의 이야기라는 설정하에 새로운 셜록 홈즈 소설을 조심스럽게 시작했습니다. 그러나 결국 독자의 압력에 손을 들고 셜록 홈즈가 일부러 죽은 척한 것이라는 다소 억지스러운 설정과 함께 그를 살려내기에 이르렀습니다. 그런데 이에 대해 모두가 만족했고 더 이상 불만은 없었죠.
재미있게도 마지막 셜록 홈즈 이야기가 발표되었을 때 30,000명의 신규 구독자가 The Strand Magazine을 구독하기 시작했습니다. 이에 영국과 미국의 출판사들은 아서 코난 도일 경의 소설을 출판하면서 그를 전 세계에서 가장 몸값이 비싼 작가의 반열에 올렸습니다.
흠, 아서 코난 도일 경은 독자에게 사랑받던 주인공을 다시 살려낸 대가로 세계 최고의 대우를 받는 작가 반열에 올랐는데, 죽음을 가장했다는 억지스러운 이야기를 동원하지 않고도 독자의 사랑을 받는 주제를 다시 살려낸 Scripting Guy는 TechNet Magazine 관계자에게 인정이라도 받게 될지 모르겠군요.

Dr. Scripto의 Scripting Perplexer
매달 퍼즐 풀이 실력뿐만 아니라 스크립팅 기술까지 시험해 볼 수 있는 문제입니다.

2008년 4월: 문자 고르기
이번 달 문제는 파란색 빈칸에 A에서 O 사이의 문자를 삽입해 VBScript 함수 이름을 완성하는 퍼즐입니다. 각 문자(A ~ O)는 한 번만 사용해야 합니다. 각 문자가 사전순으로 나타나지는 않습니다. 삽입한 문자는 함수 이름의 첫 글자나 마지막 글자가 될 수도 있고 중간에 오는 어떤 위치의 글자도 될 수 있습니다. 예를 들어 다음 줄에는 문자 D를 삽입하여 IsDate라는 함수 이름을 완성할 수 있습니다.
이제 다음 표에 A부터 O 사이의 문자를 삽입하여 VBScript 함수 이름을 완성해 보십시오.

Dr. Scripto의 Scripting Perplexer
답: 문자 고르기, 2008년 4월

Microsoft Scripting Guys는 Microsoft에 고용되어 일하고 있는 Microsoft의 직원들입니다. 이들은 좋아하는 야구 경기와 기타 여러 활동을 하는 시간을 제외하고는 항상 TechNet 스크립트 센터를 운영합니다. 자세한 내용은 www.scriptingguys.com에서 확인하십시오.


 Security Watch: 내 PII는 어디에 있을까요?
Security Watch
내 PII는 어디에 있을까요?
Frank Simorjay

사람들은 하나같이 PII(개인 식별이 가능한 정보) 보호의 중요성에 대해 말합니다. 그러나 PII를 보호하려면 PC에 어떤 PII가 수집되는지부터 완전히 이해해야 합니다. 컴퓨터에 저장된 정보가 모두 중요하다고 하면 할 말이 없지만, 그렇다면 그 모든 정보란 무엇인지는 정확히 알고 있습니까?
문제의 심각성을 강조하기 위해 중요한 정보일 수 있는 데이터를 유형별로 나누어 자세히 살펴보고 이러한 데이터가 컴퓨터의 어디에 저장되는지 알아보겠습니다. 우선 짚고 넘어갈 점은 중요한 정보라는 것이 개인적인 판단을 근거로 하는 경우가 많다는 사실입니다. 예를 들어 검색 결과에 자신의 이름만 나와도 소스라치게 놀라는 사람도 있습니다. 물론 동굴에 숨어 살지 않는 한 누군가 어떤 형태로든 여러분의 이름을 인터넷에 게시하는 일은 다반사입니다. 자주 사용하는 검색 엔진에서 직접 자신의 이름을 검색해 보십시오. 평범한 이름일수록 정확히 자신을 지칭하는 경우를 찾기가 어려울 겁니다. 그러면 어느 정도 안심이 되겠지요.
인터넷에서 자신에 대한 정보를 검색하는 경우 싸이월드, 다음, 네이버 같은 유명 커뮤니티 사이트에서 확인할 수도 있습니다. 과거에는 쉽게 검색되지 않던 개인 정보가 인터넷에서 얼마나 쉽게 저장되고 전파되는지를 보고 있자면 놀랍기까지 합니다.
따라서 보호해야 할 정보를 파악하려면 과거에 비해 과학적인 접근이 필요합니다. 이런 점에서 보호해야 할 개인 정보이지만 컴퓨터에 저장되어 있는지조차 잘 모르는 정보를 알아보면 도움이 되리라 생각합니다. 개인의 ID를 도용하는 데 사용 가능한 개인 정보는 모두 중요하다고 생각하겠지만, 사실 정보는 두 가지 수준으로 나눌 수 있습니다. 즉, 쉽게 얻을 수 있는 정보가 있고 보다 개인적이고 일반적으로 개인 신원에 중요하다고 여겨지는 정보가 있습니다.
쉽게 얻을 수 있는 정보는 대개 PII로 취급하지 않습니다. 이러한 정보에는 실명은 물론, 전화 번호, 주소, 전자 메일 주소, 성별 등이 포함될 수 있고 직장과 학력 정보도 여기에 포함되는 경우가 많습니다. 이러한 항목은 인터넷과 전화번호부 같은 공개 인명록에서 쉽게 얻을 수 있습니다. 실수로 스패머에게 전자 메일 주소를 노출하는 경우와 같이 이러한 정보가 노출되면 귀찮기는 하지만 그 자체만으로는 신원 도용으로 이어지지 않습니다.
중요한 정보는 신원과 직결되는 보다 개인적인 데이터로 이루어집니다. 사회 보장 번호 또는 기타 정부가 발급한 고유 ID, 은행 계좌번호, 신용카드 번호(특히 만료 날짜와 카드 회원 ID가 함께 노출되는 경우), 운전면허 번호, 지문 또는 기타 생체 인식 관련 정보 등이 공개적으로 노출해서는 안 되는 정보에 속합니다. 이러한 정보가 다른 사람 손에 들어가 악용되면 막대한 피해를 입을 수 있습니다. 그래서 인터넷이나 PC에서 이러한 정보가 기록되고 저장되는 방식과 위치를 제어하는 것이 중요합니다. 이런 맥락에서 시스템의 하드 드라이브에 저장된 모든 PII를 찾는 몇 가지 간단한 방법을 지금부터 살펴보겠습니다.

컴퓨터에서 PII 데이터 찾기
PII 정보는 곳곳에 산재해 있습니다. 사실 PII는 쓰레기만 뒤져 봐도 쉽게 찾을 수 있을 겁니다. 때문에 이러한 정보를 보호하려면 노력과 주의가 필요합니다. 좋은 서류 파쇄기를 구입하여 개인 정보가 있는 모든 것들을 파쇄하는 것이 좋습니다.
하지만 PC에 숨어 있는 PII는 어떻게 처리해야 할까요? 이 데이터는 안전하게 저장하는 것만큼이나 찾기도 어렵습니다. Windows Vista®와 몇 가지 데스크톱 검색 도구를 사용하면 시스템에서 정보를 찾는 데 도움이 될 수 있습니다. 단, 찾고자 하는 정보가 무엇인지 알고 있다는 전제 하에 말이지요.
단적인 예로 두 가지 간단한 도구를 통해 실제로 어떤 문제가 있는지 살펴보겠습니다. 우선 Windows PowerShell®에서 스크립트를 사용합니다. Windows PowerShell이 제공하는 수많은 기능 중에는 뛰어난 문자열 검색 기능도 포함되어 있습니다. 여기서는 정규식 검색 기능을 중점적으로 설명하겠습니다. microsoft.com/powershell에서 다운로드할 수 있는 Windows PowerShell은 순식간에 관리 작업의 표준으로 자리 잡은 강력한 도구입니다.
또한 가양성을 관리하기 위해, 즉 이진 파일에 있는 데이터 문자열의 임의성으로 인해 의미 있는 문자열이 포함된 것처럼 보이지만 실제로 여기서는 아무 쓸모 없는 파일을 무시하기 위해 findstr.exe도 사용하겠습니다. 다시 말해 이 예제에서 텍스트 이외의 파일은 무시할 수 있습니다.
대표적인 PII 데이터 유형인 사회 보장 번호와 신용카드 정보를 검색하도록 하겠습니다. 이들 데이터는 실제로 하드 드라이브에 일반 텍스트로 저장되었을 때 쉽게 검색됩니다. 두 가지 데이터 유형은 모두 구조와 패턴이 고유하기 때문에 간단한 스크립트 하나로 정보를 찾을 수 있습니다. 그러나 동시에 이러한 데이터는 굳이 PC에 저장할 필요가 있는지 의문이 들 정도로 중요한 데이터입니다. 따라서 이러한 정보를 저장할 때에는 정보 보호에 각별히 신경 써야 합니다. PII 정보를 보호하는 방법은 잠시 후에 설명하도록 하겠습니다. 여기서 다루는 항목은 확실히 한정적입니다. 여기서 다루지 않는 사용자 이름이나 암호 같은 다른 중요한 PII 데이터 유형도 많다는 것을 유의하십시오.

사회 보장 번호 검색
파일에서 XXX XX XXXX 또는 XXX-XX-XXXX 형식의 미국의 표준 사회 보장 번호로 구성된 정보를 찾는 간단한 문자열을 소개하겠습니다. Windows PowerShell을 사용하는 경우 다음 코드 줄만 입력하면 됩니다.
Get-ChildItem  -rec -exclude *.exe,*.dll |
select-string " [0-9]{3}[-| ][0-9]{2}[-| ]
[0-9]{4}"
또는 findstr.exe와 다음 코드를 사용하여 검색 시 이진 파일을 읽지 않도록 할 수도 있습니다.
Get-ChildItem  -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
" [0-9]{3}[-| ][0-9]{2}[-| ][0-9]{4}"
이 샘플 코드에서 Get-ChildItem –rec는 명령을 실행한 디렉터리에서 시작하여 파일에 대해 재귀 디렉터리 검색을 실행합니다. findstr.exe는 파일에서 문자열을 검색하며 Select-string은 Windows PowerShell 문자열 검색 함수입니다. 여기서는 설명하지 않지만 findstr.exe도 Select-string과 유사한 기능을 제공합니다. 정규식에 선행 공백을 일부러 삽입했다는 점도 잘 살펴보십시오. 이렇게 하면 HKLM\SOFTWARE\tool\XXX-XX-XXXX와 같은 레지스트리 문자열 등 불필요한 정보가 제거되어 가양성을 줄일 수 있습니다.
샘플 코드를 실행하면 필자가 하위 디렉터리에 저장한 테스트 샘플 파일이 검색 패턴의 결과로 반환되고 XML 파일에서 신용카드 번호와 사회 보장 번호의 파일 패턴을 보여 주는 샘플도 검색됩니다(그림 1 참조).
그림 1 번호 패턴 검색 결과
그림 1 번호 패턴 검색 결과
첫 번째 예제에서는 exclude 기능을 사용하여 불필요한 결과를 생성할 수 있는 .exe 파일과 .dll 파일을 모두 제외했습니다. 가양성의 원인이 되는 다른 파일 형식이 더 있을 수 있습니다. 이러한 파일 형식이 있는 경우 exclude를 사용하여 검색 프로세스를 더 세부적으로 조정할 수 있습니다.
특정 사회 보장 번호만 검색하려는 경우에는 다음과 같이 하면 됩니다. 실제에서는 "123 45 6789"를 본인의 사회 보장 번호로 바꾸면 됩니다.
Get-ChildItem  -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
"123 45 6789","123-45-6789"
이 코드 실행에 따른 검색 결과는 그림 2에 나와 있습니다.
그림 2 특정 번호 검색
그림 2 특정 번호 검색

신용카드 정보 검색
신용카드 정보는 형식이 다양하기 때문에 검색하기가 다소 까다롭습니다. 그리고 가양성도 제한해야 합니다. 다시 말해 우연적으로 신용카드 번호처럼 보이는 형식이 검색되는 것을 줄여야 합니다. 가양성을 제한해도 신용카드 번호와 유사한 임의의 시퀀스가 검색될 것입니다.
여기서는 Michael Gilleland의 에세이, "Anatomy of Credit Card Numbers"(merriampark.com/anatomycc.htm)를 참조해 이러한 문자열을 작성하도록 하겠습니다. 예를 들어 첫 번째 숫자가 업계에서 주요 신용카드 식별자로 사용되는 4, 5, 6이 되어야 한다는 조건을 검색 문자열에 지정합니다.
이런 방법으로 Discover, MasterCard 및 Visa 카드의 번호를 검색하는 간단한 문자열을 작성했습니다. Windows PowerShell에서 작성한 검색 문자열은 다음과 같습니다.
Get-CchildItem  -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
 "[456][0-9]{15}","[456][0-9]{3}[-| ][0-9]{4}
[-| ][0-9]{4}[-| ][0-9]{4}"
그림 3의 샘플에는 .rtf, .rbl 및 .h 파일 형식에서 필요 없는 결과가 검색되는 것을 제거하기 위해 exclude 함수를 사용했습니다. 또한 이 샘플 코드는 공백이나 대시가 없는 신용카드 문자열을 검색합니다. 그런데 이렇게 하면 검색 결과가 너무 방대해집니다. 같은 기능의 명령을 다음과 같이 작성하여 문제를 해결할 수도 있지만, 이 경우 공백이나 대시가 없는 신용카드 번호는 검색되지 않습니다.
그림 3 필요 없는 결과를 제거하도록 exclude 사용
그림 3 필요 없는 결과를 제거하도록 exclude 사용
Get-ChildItem  -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
"[456][0-9]{3}[-| ][0-9]{4}[-| ][0-9]{4}
[-| ][0-9]{4}"
American Express 카드 번호는 형식이 많이 다르기 때문에 해당 카드 패턴을 검색하기 위해 검색 문자열을 수정했습니다. Windows PowerShell에서 새로 수정한 검색 문자열은 다음과 같습니다.
Get-ChildItem -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
"3[47][0-9]{13}","3[47][0-9]{2}[-| ][0-9]{6}
[-| ][0-9]{5}"
데이터가 방대하면 이 검색 결과에도 영향을 미칠 수 있습니다. 다음 명령을 대신 사용할 수 있지만, 이 경우 공백이나 대시가 없는 신용카드 번호는 검색되지 않습니다.
Get-childitem -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
"3[47][0-9]{2}[-| ][0-9]{6}[-| ][0-9]{5}"
이 칼럼을 쓰면서 시스템에서 직접 검색을 실행해 보았는데 전혀 뜻밖의 위치에 사회 보장 번호가 저장되어 있는 것을 발견하고 적잖이 놀랐습니다. 예전에 적어놓고 잊어버린 메모에 사회 보장 번호 정보가 들어 있었던 것입니다. 필자 개인적으로도 이를 계기로 다시는 중요한 정보를 기록해 두지 않겠다고 다짐하게 되었습니다.
이러한 정보를 안전하게 저장하려면 Password Safe(passwordsafe.sourceforge.net) 같은 도구를 사용해 보십시오. 또한 BitLockerTM 드라이브 암호화 같은 도구로 하드 드라이브를 암호화하는 것도 한 방법이 될 수 있습니다. 마지막으로 모바일 PC에서 데이터 보호에 대한 검증된 지침을 제공하는 모바일 PC용 데이터 암호화 도구 키트를 사용할 수도 있습니다. 이러한 솔루션은 적어도 다른 사람이 쉽게 PC에서 개인 정보를 빼가지 못하도록 하는 효과가 있습니다.

결론
PII 정보는 비교적 간단하게 찾을 수 있습니다. 반면 정보를 제대로 파악하는 일은 쉽지 않습니다. 어쨌든 맬웨어나 악의적인 사용자가 여러분의 시스템에 액세스하여 이와 유사한 검색 기법으로 시스템에서 손쉽게 정보를 빼낼 수 있다는 사실을 명심하십시오. 언제 어디에 자신이 PII 정보를 입력하는지 항상 주의를 기울이고 정보를 저장해야 할 경우에는 항상 암호화하십시오.
Windows PowerShell 스크립트 작성 시 문제 해결에 도움을 준 Matt Hainje에게 감사를 전합니다.

Frank Simorjay는 Microsoft Solution Accelerator 보안 및 규정 준수 그룹의 기술 프로그램 관리자로, Microsoft 고객을 위한 보안 솔루션 설계를 담당하고 있으며, 그 외에도 직접 창립한 Secure World Exposition 같은 이벤트에서 강연을 하기도 하고 보안 교육을 제공하거나 보안과 관련한 다양한 백서와 서적을 기고하는 등 왕성한 활동을 펼치고 있습니다. 최근에는 "맬웨어 제거 시작 키트" 관련 업무를 담당했습니다.


 The Desktop Files: WAIK를 사용한 Windows XP 배포
The Desktop Files
WAIK를 사용한 Windows XP 배포
Wes Miller

다양한 고객의 요구 사항을 접하다보면 항상 놀라고 두렵기까지 합니다. 모든 고객이 동시에 같은 버전의 Windows를 배포하고, 항상 같은 배포 단계를 진행한다면 이상적이겠지요. 테스트도 훨씬 쉬워질 겁니다. 물론 그런 세상은 꿈에서나 가능하겠죠. 실제로는 이미 Windows Vista® 배포 프로젝트를 진행 중이거나 완료한 고객
또는 Windows Server® 2008 RODC(읽기 전용 도메인 컨트롤러)를 프로덕션 환경에 처음으로 배포하기 위한 준비를 한창 진행하는 고객도 있지만, 장기적인 Windows® XP 및/또는 Windows Server 2003 R2 배포 계획을 수행 중이어서 고맙게도 정기적으로 필자를 일깨워주는 고객도 많습니다.
얼마 전에 한 독자로부터 "WAIK(Windows 자동 설치 키트)를 Windows XP에 사용할 수 있는지, Windows XP를 배포할 때 WAIK를 사용하려면 어떻게 해야 하는지"를 묻는 전자 메일 메시지를 받았습니다. 이 칼럼에서는 이 질문에 최대한 성실히 답해 드리도록 하겠습니다.

WAIK 재조명
Windows Vista를 쉽게 배포할 수 있도록 설계된 강력한 도구 집합인 WAIK에 대해서는 1년쯤 전에 이미 칼럼(technetmagazine.com/issues/2007/01/DesktopFiles)에서 다룬 적이 있습니다. WAIK는 이제 Windows Server 2008 배포에도 사용할 수 있습니다. 이 두 운영 체제에는 새로운 설치 인프라가 공통적으로 사용되었고, WAIK의 도구는 주로 이러한 인프라를 이용하도록 설계되었습니다. 또한 잘된 일인지 아닌지는 모르겠지만 무인 설치 파일이나 Sysprep를 사용하는 Windows Vista 이전 버전의 Windows의 경우 특별히 설계된 전용 도구를 사용해야 합니다. 하지만 이 칼럼에서는 Windows XP 배포에 사용할 수 있는 도구를 중심으로 WAIK를 재조명해보겠습니다.
Windows PE 2.0 일단 공통되는 부분이 있으므로 Windows PE 2.0과 Windows XP의 이중 부팅에 관한 필자의 2008년 2월 칼럼(technetmagazine.com/issues/2008/02/DesktopFiles)을 살펴보겠습니다. 기본적으로 그러한 시나리오에서 Windows PE 2.0이 작동했다면 여기서도 작동할 것입니다. 여기서 한 가지, "Windows XP를 배포할 시스템 중에 RAM이 512MB 미만이거나 Windows Vista의 ACPI(고급 구성 및 전원 인터페이스)를 지원하지 않는 시스템이 있는지"를 확인해야 합니다. 두 경우 중 하나에 해당한다면 Windows PE 1.6을 사용해야 하고 Software Assurance의 일부로 제공되는 Windows PE 1.6에 액세스할 권한이 있는지 확인해야 합니다. 현재 Windows PE 2.0 및 2.1만 무료로 제공되고, 1.6 이하 버전은 Software Assurance 멤버 자격이 있어야 사용할 수 있습니다.
ImageX/WIM ImageX와 WIM(Windows 이미징 형식)은 원래 NTFS 볼륨이든, FAT 볼륨이든 관계없이 Windows 2000 이상 모든 버전의 Windows에서 작동하도록 설계되었습니다. 따라서 Windows XP(또는 Windows Server 2003)를 배포하는 데에도 사용할 수 있습니다.
Windows 배포 서비스 RIS(원격 설치 서비스)를 대체하는 WDS(Windows 배포 서비스)는 원래 WAIK 1.0에서 OOB(Out-Of-Band) 릴리스로 제공되다가 업데이트되어 Windows Server 2003 SP2에 통합되었습니다. 이제는 Windows Server 2008에서 기능이 향상된 버전이 제공되지만 이 서비스를 Windows XP 배포에 여전히 유용하게 사용할 수 있습니다.
RIS 서버나 레거시 모드로 실행되는 WDS 서버가 있으면 WDS가 그렇게 유용하지는 않습니다. 그러나 혼합 모드나 기본 모드로 실행되는 WDS로 전환한 경우라면 Windows XP 배포 시나리오에 WDS를 활용할 수 있습니다.
WSIM(Windows 시스템 이미지 관리자) WSIM은 Windows Vista와 Windows Server 2008 배포에만 적용할 수 있습니다. Windows Server 2003 이하 버전을 배포하는 경우에는 WSIM이 별로 도움이 되지 않습니다.

Windows XP 배포 도구
Windows NT® 4.0부터 Windows Server 2003까지 모든 버전의 Windows가 그렇듯 Windows XP도 unattend.txt 파일이나 "이미지"를 통해 배포할 수 있습니다. 그 중 무인 설치의 경우 이제는 정말 과거의 것이 되었으므로 여기서 다루지 않겠습니다. WAIK, 특히 ImageX를 활용하려면 이미지 기반 배포 방식을 선택해야 합니다. 즉, unattend.txt 파일 대신에 Sysprep에 사용할 수 있는 응답 파일 형식인 Sysprep.inf가 필요합니다.
여기서 '이미징'이라는 용어는 OS 이미지를 만드는 방식을 통칭합니다. 과거에는 대개 Ghost, PQDI 같은 이미징 도구를 사용했을 것입니다. Microsoft에서는 ImageX를 발표하기 전까지 Sysprep에 사용할 OS와 응용 프로그램의 이미지를 만들어 하나 이상의 대상 컴퓨터에 복사하는 도구를 제공하지 않았습니다.
Windows의 이미지를 만들 때에는 다음 두 가지 중요 사항을 유의해야 합니다.
  • 단일 프로세서 시스템과 다중 프로세서 시스템 사이를 전환하는 경우 외에는 HAL(하드웨어 추상화 계층)을 변경할 수 없습니다. 이전에 게시했던 칼럼에서 언급했듯이 ACPI 아키텍처와 비ACPI 아키텍처 사이를 전환하는 경우에는 이미지를 안전하게 변경할 수 없습니다.
  • 대용량 저장 컨트롤러는 변경할 수 있습니다. 대용량 저장 컨트롤러 변경이 불가능하다는 것은 잘못 알려진 상식입니다. 그러나 이를 위해서는 Sysprep를 사용하여 대상 컴퓨터에 필요할 수 있는 대용량 저장 컨트롤러를 모두 설치하고 배포 후에 Sysprep로 대상 시스템에 실제로 사용되는 드라이버를 제외한 드라이버를 모두 제거해야 합니다. 이에 대해서는 잠시 후에 자세히 설명하도록 하겠습니다.
위 두 가지 문제만 신경 쓰면 한 시스템에서 이미지를 준비하여 HAL이 동일하거나 호환되는 다른 대상 시스템에 사용할 수 있습니다.

필요한 도구
이미지 기반 배포 시나리오로 Windows XP를 배포할 때에는 다음 세 가지 항목을 사용할 수 있도록 준비해야 합니다.
Ref.chm 무인 설치 텍스트 파일 참조입니다. Windows Vista 이전 버전의 Windows에서 선택적 구성 요소는 이미지를 만들기 전에 구성하는 것이 바람직합니다. 그러나 Windows 설치 후에 선택적 구성 요소를 설치해야 하는 경우 support.microsoft.com/ kb/222444에서 설명하듯이 sysocmgr.exe를 실행하면 됩니다. Windows XP Tablet PC Edition을 배포하는 경우 go.microsoft.com/fwlink/?LinkId=108589에서 설명하는 단계에 따라 단일 이미지를 만들어 해당하는 시스템에 Tablet PC 구성 요소를 설치합니다.
Sysprep Microsoft에서 지원하는 디스크 복제 시스템 작성 도구입니다. 타사 SID(보안 식별자) 교환기 사용을 권장하는 경우도 종종 볼 수 있지만 다른 도구는 중요한 Windows SID 위치, 특히 외부로 드러나지 않는 위치를 놓치기 쉬우므로 Sysprep만 사용하는 것이 좋습니다.
설치 관리자 sysprep.inf 파일을 가장 빠르고 쉽게 만들 수 있는 도구입니다. 언제나 그렇듯이 올바른 버전(대개 배포하는 Windows와 동일한 버전)을 사용해야 합니다. 예를 들어 Windows XP SP2에는 Windows XP SP2 배포 도구를 사용합니다.
이 세 가지 항목은 모두 Windows XP CD에 들어 있으며 업데이트된 버전은 go.microsoft.com/fwlink/?LinkId=107541에서 다운로드할 수 있습니다.
tap.exe 파일도 준비해 두는 것이 좋습니다. 이 유틸리티는 무료 평가판을 비롯한 Windows XP Embedded 도구(go.microsoft.com/fwlink/?LinkId=108590)에 포함되어 있습니다. Windows PE에서 tap.exe는 Windows PE가 검색한 모든 PnP(플러그 앤 플레이) 장치에 대한 정보를 반환합니다. 특히 Windows PE에서 장치에 대해 선택한 HAL을 알려 줍니다(그림 1 참조). 이러한 기능은 Windows PE에서 HAL을 선택하는 데 사용하는 논리가 전체 Windows 설치에서 사용할 HAL을 결정하는 데 사용하는 논리와 같다는 점에서 중요합니다. 즉, Windows PE에서 tap.exe를 사용하면 특정 시스템에 대해 Windows가 추천하는 HAL을 간편하게 확인할 수 있습니다.
그림 1 특정 시스템에 대해 Windows PE에서 선택한 HAL을 알려 주는 tap.exe 유틸리티
그림 1 특정 시스템에 대해 Windows PE에서 선택한 HAL을 알려 주는 tap.exe 유틸리티

이미지 만들기
다음 단계에 따라 ImageX를 사용하여 배포할 Windows XP 이미지를 직접 만들 수 있습니다. 물론 다른 이미징 도구를 사용할 수도 있지만 이 워크플로에 왜 ImageX가 가장 적합한지는 곧 알 수 있을 것입니다.
우선 Sysprep, 설치 관리자, ImageX, Windows PE 등 필요한 도구와 구성 요소를 모두 준비합니다. Windows PE는 요구 사항이나 액세스 가능 여부에 따라 버전 2.0과 1.6 중 하나를 선택합니다. 단, 버전 2.0을 ImageX와 사용하는 경우에는 부팅 코드가 Windows XP와 호환되도록 파티션을 만들 때 /nt52 스위치를 사용하여 bootsect.exe를 실행해야 합니다.
당연히 PC에는 Windows XP(SKU는 관계없음)와 Windows의 최신 업데이트, 그리고 필요한 다른 소프트웨어도 설치되어 있어야 합니다. 이상적으로 이 시스템은 이전에 도메인에 가입된 적이 없어야 합니다. 그래야 나중에 도메인/네트워크 문제가 발생할 가능성이 적습니다. 시스템에는 안전하게 이미징할 수 있는 응용 프로그램만 설치되어 있어야 하고, SID 변경 시 Sysprep가 놓치거나 바꿀 수 없는 컴퓨터 이름, SID, 도메인 또는 사용자별 정보를 개별적으로 저장하는 응용 프로그램이 있어서는 안 됩니다. 또한 가장 자주 배포할 것으로 예상되는 HAL을 사용해야 합니다. 최신 하드웨어에는 ACPI와 다중 코어(MP HAL을 사용한 이전의 하이퍼스레딩)가 모두 사용되기 때문에 ACPI MP(다중 프로세서) HAL이 주로 사용됩니다.
이제 최종 사용자에게 제공하려는 구성대로 Windows XP 시스템을 구성합니다. 대부분의 사용자에게 제공할 응용 프로그램과 무인으로 설치할 수 없는 응용 프로그램을 모두 설치합니다. 선택적 Windows 구성 요소를 설치하거나 제거하여 최종 사용자에게 제공할 시스템을 설정합니다. 그런 다음 바탕 화면을 구성합니다. Administrator로 로그인하여 바탕 화면 배경, 화면 보호기, 시작 메뉴 등 프로필 항목을 적절하게 수정합니다. Windows XP SP2부터는 기본적으로 Sysprep에서 Administrator 계정의 설정을 Default User 계정으로 자동 복사합니다.
다음으로 설치 관리자(그림 2 참조)를 실행하여 새 Sysprep 무인 파일을 만들고 설치 과정을 완전히 자동화하도록 지정합니다. 설치 관리자에서 작업을 진행하는 과정에서는 제품 키를 입력해야 합니다. 제품 키가 없거나 나중에 스크립팅하려면(볼륨 라이선스 키도 없는 경우) Windows XP 또는 Windows Server 2003 CD의 기본 unattend.txt 파일에서 제공되는 키를 지정하여 설치를 완료할 수 있지만 정품 인증은 받을 수 없습니다.
그림 2 설치 관리자를 사용하여 Sysprep 응답 파일 만들기
그림 2 설치 관리자를 사용하여 Sysprep 응답 파일 만들기
컴퓨터 이름도 지정해야 합니다. 나중에 SQL이나 기타 메커니즘을 사용하여 이 작업을 자동화할 수 있지만 여기서는 특정 값을 입력한 다음 컴퓨터에 WIM이 배포된 후, Sysprep를 실행하기 전에 스크립팅을 통해 컴퓨터 이름을 바꾸도록 하겠습니다.
Administrator 계정의 암호를 지정하면 이미지의 기존 Administrator 계정에 암호가 없는 경우에만 적용됩니다. 또한 도메인 가입 섹션에서 도메인 가입 자격 증명을 암호화할 수 없다는 사실도 유의해야 합니다. 컴퓨터 계정을 설정할 수 있는 최소 권한 계정을 사용해야 합니다. 마지막으로 설치 관리자의 Version String(버전 문자열) 옵션을 사용하여 새로 만든 이미지의 "버전"을 관리하는 것이 좋습니다.
이제 Sysprep.inf 파일을 sysprep.exe 및 setupcl.exe 파일이 있는 C:\Sysprep 디렉터리에 넣고 .inf 파일에 다음을 추가합니다.
[Sysprep]
BuildMassStorageSection = Yes

[SysprepMassStorage]
그런 다음 Sysprep –bmsd를 실행합니다. 그러면 그림 3과 같이 sysprep.inf 파일이 수정되고 Windows 설치에서 인식되는 모든 대용량 저장소 ID가 추가됩니다. 다른 장치를 추가하려는 경우 직접 추가할 수도 있고 Windows 설치에 추가한 다음 sysprep –bmsd를 다시 실행할 수도 있습니다.
그림 3 sysprep.inf에 대용량 저장소 ID 추가
그림 3 sysprep.inf에 대용량 저장소 ID 추가
다음으로 sysprep.inf 파일을 공유 위치에 복사하고 sysprep.exe –factory를 실행한 다음 시스템을 종료합니다. Windows PE로 다시 부팅하고 다음을 사용해 UNC 공유(권장)에 연결합니다.
NET USE Y: \\myserver\myshare
/USER:DOMAIN\USER password
이제 다음 코드를 사용해 이미지를 캡처합니다.
ImageX /capture C: Y:\NewImage.wim
"Factory Mode capture from 4/1/2008"
그런 다음 시스템을 종료합니다.
이제 공장 모드를 통해 업데이트할 이미지가 준비되었습니다. 자세한 사항은 여기서 설명하지 않겠지만 한 마디로 공장 모드는 배포를 위해 이미징할 준비가 될 때까지 이미지를 유지할 수 있는 가장 안전한 모드입니다. 자세한 내용은 앞서 소개한 Windows XP deploy.cab 설명서를 참조하십시오.
배포할 이미지에 대해 prep를 실행할 준비가 되었으면, 즉 롤아웃할 준비가 되면 Windows PE로 부팅하고 Diskpart를 사용하여 원하는 파티션을 만듭니다. format 명령을 사용하여 파티션을 포맷하고 필요에 따라 bootsect.exe를 사용하여 Windows Vista 이전의 부팅 코드(/nt52)를 적용합니다. 이제 다음 코드를 사용하여 UNC 공유에 연결하거나 이미지가 있는 위치로 디렉터리를 변경합니다.
NET USE Y: \\myserver\myshare
/USER:DOMAIN\USER password
그런 후 다음과 같이 이미지를 적용합니다.
ImageX /apply Y:\NewImage.wim C: 1
마지막으로 Windows 공장 모드로 다시 부팅하고 필요에 따라 이미지를 업데이트합니다. 이때 winbom.ini 파일을 사용해야 하므로 자세한 내용은 deploy.cab의 ref.chm을 참조하십시오. winbom.ini에는 항상 다음 코드 줄이 포함됩니다. 이 코드는 다음에 다시 부팅할 때 최소 설치를 실행할 수 있게 이미지를 다시 봉인하여 준비하도록 합니다.
[FACTORY]
ResealMode = Mini
작업을 마쳤으면 시스템을 종료합니다. 이미지를 캡처하는 데 수행한 이전 단계를 다시 반복합니다. 단, 이번에는 다음과 같이 캡처 명령을 수정합니다.
ImageX /append C: Y:\NewImage.wim "Resealed
and ready for deployment – captured 4/4/2008"
/append 스위치를 사용하면 공간을 많이 절약할 수 있습니다. 그리고 공장 모드에서 이미지를 다시 봉인했으므로 손쉽게 이미지를 전환할 수 있습니다. 또한 /delete 스위치를 사용하여 사용하지 않을 이미지를 삭제할 수도 있습니다. 그러나 이렇게 하면 지정된 볼륨 이미지에 대한 참조만 삭제되므로 공간이 절약되지는 않습니다. 사용되지 않는 공간을 정리하려면 유지하려는 모든 볼륨 이미지를 내보내야 합니다.
지금까지 주로 Windows Vista 및 Windows Server 2008용으로 설계되고 지원되는 WAIK가 최신 Windows 버전뿐만 아니라 이전 버전의 배포 시에도 어떤 식으로 도움이 되는지를 살펴보았습니다. Windows XP 도구와 WAIK 도구(주로 ImageX와 경우에 따라 Windows PE 2.0)를 함께 사용해야 하지만 이제는 Microsoft에서 모든 버전의 Windows를 롤아웃하는 데 필요한 도구를 완벽하게 제공합니다.

Wes Miller는 텍사스주 오스틴에 위치한 CoreTrace(www.CoreTrace.com)에서 기술 제품 수석 관리자로 일하고 있습니다. 이전에는 Winternals Software에서 Microsoft 프로그램 관리자로 근무했습니다. 문의 사항이 있으면 technet@getwired.com으로 연락하시기 바랍니다.


 Field Notes: 놀라운 MAR 이니셔티브
Field Notes
놀라운 MAR 이니셔티브
Neil Fawcett

여러분의 집 지하실에 5,000여 대의 재활용한 PC가 있고, 이를 구입하기 위해 고객들이 집 앞에 장사진을 이루었다고 상상해 보십시오. 하드웨어의 수명은 연장되었으나 운영 체제의 경우는 어떠한가요? 하드웨어와는 완전히 별개의 문제이지요. 운영 체제는 정품인가요? 각 PC에 OS는 설치되어 있나요? 다시 판매할 수는 있나요?
새로운 상용 MAR(Microsoft Authorized Refurbisher: Microsoft 공인 재활용) 프로그램을 통해 이러한 모든 문제를 해결할 수 있습니다. 이러한 새로운 프로그램은 언뜻 봐서는 영리 업체가 중고 PC를 구입하여 정품 OS를 설치한 후 판매하도록 지원하는 상당히 단순한 개념으로 보일 수 있습니다.
하지만 MAR 프로그램은 이보다 깊은 목적을 추구합니다. 실용적인 관점에서 볼 때 이 프로그램을 통해 Microsoft와 상업적 PC 재활용업체 모두를 위한 사업 기회가 창출됩니다. 법적인 관점에서 볼 때 이 프로그램을 통해 의도하거나 의도하지 않은 소프트웨어 불법 복제를 모두 방지할 수 있습니다. 환경적인 측면으로는 사용 가능한 하드웨어가 폐기 처분되지 않도록 하기도 합니다. 또한 마지막으로 기업에서는 이 프로그램을 통해 Microsoft의 라이선스 정책이 어떤 식으로 적용되는지 잘 이해할 수 있습니다. 특히 이전 사용자로부터 다른 사용자로 인계된 PC를 다루는 경우 그렇습니다.
Microsoft뿐만 아니라 PC 재활용업체에도 도움이 되는 이 프로그램은 고객에게도 많은 혜택을 제공합니다. 즉, 고객은 전문가가 데이터를 모두 제거하고 정품 버전의 Windows® XP Home Edition 또는 Windows XP Professional을 사전 설치한 PC를 구입할 수 있으므로 다운로드, 업데이트 및 향상된 기능을 사용할 수 있으며 Windows의 향후 릴리스도 사용할 수 있습니다. 또한 이 모두는 손쉽게 폐기 처분되어 유해 폐기물에 대한 통계치를 올릴 뻔한 컴퓨터에서 이루어집니다.
MAR는 매달 평균 5,000여 대의 재활용 PC를 공급할 수 있는 기업을 대상으로 합니다. 프로그램에 참여하려면 5,000여 대 이상의 PC를 재활용한 기록을 제출해야 합니다. MAR는 전 세계적인 프로그램으로 주요 OEM 재활용업체뿐만 아니라 자격 요건을 충족하고 미국 또는 캐나다 지역에 본사를 둔 재활용업체라면 이 프로그램에 참여할 수 있습니다. 현재 참여 중인 재활용업체는 Redemtech, Techturn 및 Apto Solutions입니다.
새로운 소프트웨어 제품의 라이선스 정책이 가끔씩 판매자와 구매자 모두에게 혼동을 줄 수는 있지만 재활용 PC 시장에는 중고 Windows를 사용하여 수행할 수 있는 작업과 수행할 수 없는 작업에 대한 새로운 수준의 복잡한 문제가 있습니다. MAR는 재활용업체가 겪는 이러한 복잡한 문제를 줄여 줍니다. MAR는 기본 사양이 다양한 재활용된 PC에 Windows XP를 사전 설치하는 작업을 용이하게 하는 RPK(Refurbisher Preinstallation Kit)와 같은 설치 도구 집합을 제공합니다. 각 라이선스는 Microsoft의 COA(정품 인증서)와 함께 제공됩니다. 재활용된 PC에 COA가 남아 있고 기업에서 원본 복구 미디어 또는 하드 디스크 기반 복구 이미지를 보유한 경우 새 Windows 라이선스가 필요하지 않습니다. 하지만 상업적 재활용업체에 복구 미디어나 이미지가 없는 경우 MAR를 통해 필요한 작업을 간단하게 수행할 수 있습니다.
기부, 재활용 또는 재판매를 통한 컴퓨터 재사용을 통해 기술의 혜택을 받지 못하는 사람들에게 이를 사용할 수 있는 커다란 기회를 제공할 수 있습니다. 또한 기술 산업과 관련하여 날로 늘어가는 환경 파괴를 줄이는 데도 도움이 됩니다. 사실 "제2의 PC 시장"이라 불리는 중고 PC 시장은 이미 여러 개발 경제국의 기술 확산에 도움이 되고 있습니다.
재활용 PC 시장은 계속 성장하고 있으므로 PC 처분에 대한 대체 방안을 모색하는 기업의 경우 앞으로 수백만 대의 PC를 폐기 처분하지 않아도 될 것입니다. MAR는 Microsoft 내에서 전략상 중요한 역할을 수행할 뿐 아니라 대기업에서 저렴한 가격의 하드웨어 솔루션을 배포할 수 있도록 지원함으로써 여러 사람들에게 큰 혜택을 제공합니다. 지구에 영향을 미치는 환경 문제에 더 많은 관심이 주목됨에 따라 올바른 PC 처분에 대한 중요성이 그 어느 때보다 강조되고 있습니다. MAR 프로그램과 같은 이니셔티브는 중고 PC 재활용뿐만 아니라 저렴한 가격의 기술을 찾고 유해물 폐기를 지양하는 사람들에게 지속적인 혜택을 제공하는 데 도움이 됩니다. 또한 MAR 프로그램은 소프트웨어 라이선스를 간단하게 확인할 수 있도록 지원하므로 재활용 PC를 보다 매력적인 제품으로 만드는 데에도 크게 기여합니다. microsoft.com/oem/mar에서 이 프로그램에 대한 자세한 정보를 확인할 수 있습니다.

Neil Fawcett은 지난 20년 간 IT 분야에서 여러 발행물을 집필하고 편집해 왔습니다. 또한 여러 행사에서 강연도 했으며 IT 관련 주제에 대한 13권의 서적을 출간하기도 했습니다. 집필을 하기 전에는 실리콘 밸리에서 소프트웨어 개발자이자 하드웨어 엔지니어로 근무했습니다.


 Windows Confidential: 균등한 공유
Windows Confidential
균등한 공유
Raymond Chen

프로그램을 제거할 때 Windows®에서 "다른 응용 프로그램이 올바르게 실행되지 않도록 중지할 수 있는" 파일의 삭제 여부를 묻는 메시지를 표시하는 이유가 무엇인지 생각해 본 적이 있나요? 사실 이러한 메시지(스크린샷 참조)는 Windows에서 표시하는 것이 아니라 제거 프로그램에서 표시하는 것입니다. 따라서 정확하게 말하자면 "응용 프로그램 제거 프로그램에서 이러한 대화 상자를 표시하는 이유가 무엇인가요?"라고 해야 옳을 텐데요. 이것이야말로 사용자에게 대답할 수 없는 질문을 하는 가장 좋은 예라 할 수 있습니다. 왜 이러한 질문에 제대로 대답할 수 없는지에 대해 알아보도록 하겠습니다.
설치 관리자는 여러 관련 없는 프로그램에서 사용하는 MFC 런타임 라이브러리와 같이 여러 응용 프로그램에서 사용하는 파일에 대한 참조 횟수를 관리하기 위해 SharedDLLs 레지스트리 키에 항목을 만듭니다. 이 항목에는 파일 및 해당 파일의 참조 횟수가 기록됩니다. 파일에 대한 항목이 이미 있는 경우 참조 횟수가 증가하며, 파일에 대한 항목이 아직 없는 경우 참조 횟수가 1로 설정됩니다. 반대로 프로그램이 제거되면 참조 횟수가 감소하고 0이 되면 해당 파일을 사용하는 프로그램이 더 이상 존재하지 않는 것이므로 파일이 삭제됩니다. 일단 이론은 이와 같습니다.
삭제 여부를 묻는 메시지
삭제 여부를 묻는 메시지
그런데 이러한 모델에는 심각한 문제가 있습니다. 바로 모든 사용자가 규칙을 준수한다고 가정한다는 것인데요. 사실 이러한 규칙은 어긴다고 해도 위반한 사용자에게 벌칙이 주어지는 것도 아니므로 지켜지지 않을 가능성이 매우 높습니다.
예를 들어 MFC 런타임 라이브러리를 사용하는 프로그램의 경우 해당 설치 관리자가 참조 횟수를 업데이트하지 않고 시스템 디렉터리로 이러한 라이브러리를 복사한다고 가정해 봅시다. 이런 경우 이 프로그램을 제거할 때 라이브러리만 삭제됩니다. 그렇다면 이제 이 프로그램과 규칙을 준수하는 프로그램을 같은 시스템에 설치하는 경우 어떠한 상황이 벌어지는지 살펴봅시다. 기본적인 예를 들면 다음과 같습니다.
  1. 좋은 프로그램 설치: 라이브러리가 설치되고 참조 횟수가 1로 설정됩니다.
  2. 나쁜 프로그램 설치: 라이브러리가 설치되나 참조 횟수가 변경되지 않습니다.
  3. 나쁜 프로그램 제거: 라이브러리가 삭제됩니다.
결과적으로 라이브러리가 삭제되므로 좋은 프로그램이 작동하지 않게 됩니다.
또 다른 예를 들어 보겠습니다.
  1. 좋은 프로그램 설치: 라이브러리가 설치되고 참조 횟수가 1로 설정됩니다.
  2. 나쁜 프로그램 설치: 라이브러리가 설치되나 참조 횟수가 변경되지 않습니다.
  3. 좋은 프로그램 제거: 참조 횟수가 0이 되고 라이브러리가 삭제됩니다.
위 예에서는 나쁜 프로그램의 작동이 중지됩니다.
좋은 프로그램 작성자는 나쁜 프로그램으로 인해 좋은 프로그램의 사용이 중지되는 것을 막을 수는 없지만 최소한 자신으로 인해 나쁜 프로그램이 중지되는 것을 막을 수는 있겠다는 사실을 깨달았습니다. 따라서 프로그램에서 파일을 삭제하기 전 "저기요, 제가 지금 파일을 삭제하려 하거든요? 이 파일을 사용 중인 나쁜 프로그램이 있으면 나쁜 프로그램의 사용이 중지될 거에요. 나쁜 프로그램을 사용 중이라면 삭제 안 함을 클릭하세요."라는 내용의 경고 메시지를 표시합니다. 정확한 표현은 아니지만 설명하는 대화 상자가 어떤 것인지는 알 수 있을 겁니다. 이 방법은 유명한 Jeffrey Richter가 1996년 Microsoft Systems Journal 문서에서 권장한 방법이기도 합니다.
그러나 유감스럽게도 이러한 메시지를 표시함으로써 사용자는 올바르게 대답할 수 없는 질문을 받게 되는 것입니다.
물론 일일이 참견해야 직성이 풀리는 지배광들은 Windows에서 이전의 모든 항목 각각을 무시할 수 있는 옵션을 제공하도록 요구하므로 모두 이러한 대화 상자에 찬사를 보낼 것입니다. 실제로 제거 프로그램에서는 제거 프로세스를 파일 단위로 제어할 수 있습니다. 따라서 무엇을 바랄 때에는 신중하십시오. 혹시 그대로 될지도 모르니까요.

Raymond Chen은 자신의 웹 사이트 The Old New Thing에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있으며 동명의 저서에서도 이에 대해 다루었습니다. Chen은 자신의 생애에 핵융합이 실용화되지 않을까 생각하기도 합니다.