 Microsoft SQL Server 2000 Analysis Services 운영 가이드저자: Carl Rabeler/Dave Wickert 공저 발행일: 2004년 1월 요약: 본 가이드에서는 Microsoft SQL Server 2000 Analysis Services 데이터 웨어하우스를 운영 및 유지 관리하는 데 사용할 수 있는 기술에 대해 설명하고 있습니다.
데이터 웨어하우스의 Microsoft SQL Server 2000 Analysis Services 부분을 운영하는 모든 관리자는 공통된 운영 상의 여러 문제에 직면하고 있습니다. Analysis Services 및 해당 환경을 적절하게 구성해야 하며, Analysis Services 응용 프로그램을 개발 환경에서 생산 환경으로 배포해야 합니다. 변경 제어가 이루어지도록 함으로써 기존 환경에 대한 변경 사항이 완벽히 테스트되었으며, 승인된 변경 사항이 제대로 배포되도록 보장해야 합니다. 용량 문제를 사전 대처적으로 예상해야 하며, 문제를 신속하고 일관되게 해결해야 합니다. 쿼리를 위한 Analysis Services 큐브의 동의에 기반한 가용성이 보장되어야 합니다. 본 가이드는 Analysis Services 데이터베이스의 운영 및 유지 관리를 기존 IT 및 데이터베이스 인프라 내의 구성 요소로서 관리자에게 지원하기 위한 지침을 제공합니다. Analysis Services에만 해당되는 새 프로세스를 개발하기 보다는 Analysis Services의 운영 상의 문제를 해결하기 위해 기존 구조 및 기법을 통합해야 합니다. 예를 들어, 관계형 데이터베이스에서 사용하는 것과 동일한 문제 추적 및 문제 해결 기법을 채택하고, 동일한 자동화 기법을 사용해 작업 및 스크립트의 일정을 설정하고, 동일한 변경 사항 관리 기법을 채용해 변경 사항이 관리, 테스트 및 문서화되도록 보장해야 합니다. 본 가이드에서 제공되는 지침은 MOF(Microsoft Operations Framework) 방법론의 구조로 서술되어 있습니다. MOF는 변경, 작동, 지원, 최적화의 네 단계로 구분되는 모든 작업의 주기적 프로세스를 나타냅니다. 본 가이드는 다음 섹션에서 변경, 운영 및 지원 단계에 대해 다루고 있습니다.
MOF의 네 번째 사분면인 최적화에 대한 내용은 Microsoft Technet 웹 사이트(http://www.microsoft.com/korea/technet/)에서 확인하거나 "Microsoft Analysis Services Performance Guide"를 참조하십시오 여기에 제공되는 지침은 Microsoft BI(Business Intelligence) Practices 팀과 Analysis Services 개발 팀이 그 동안 축적한 경험을 토대로 합니다. 본 문서에서 설명한 기법 이외에도, Analysis Services가 실행되고 있는 컴퓨터에 SQL Server 2000 Service Pack 3 (SP3)를 적용하고 각 Analysis Services 클라이언트 컴퓨터의 Microsoft Pivottable Service (PTS)를 업데이트해야 합니다(SP3의 경우 ..\Msolap\install\pts 폴더에서 Ptslite.exe 실행). 각 클라이언트 컴퓨터 상에서 PTS를 업데이트하는 것이 특히 중요하며, 이는 PTS의 클라이언트-서버 아키텍처의 경우, 각 클라이언트 컴퓨터가 PTS 코드의 상당 부분을 차지하고 있으며, SP3가 PTS의 클라이언트측 구성 요소에 대한 중요한 성능 및 보안 개선 기능을 포함하고 있기 때문입니다. Analysis Services 설치 또는 클라이언트 컴퓨터에 적용된 서비스 팩의 등급 확인에 대한 내용은 본 문서의 후반부에 다루게 될 "Verifying the Appropriate Service Pack Level"을 참조하십시오. 각 클라이언트 컴퓨터 상의 SP3 설치 자동화에 대한 내용은 Microsoft Knowledge Base(support.microsoft.com)에서 확인하거나 "Ptssetup.exe Sample Automatically Downloads and Installs OLAP Client" 기사를 참조하십시오.
BI 응용 프로그램을 출시 및 배포하기 전에 응용 프로그램을 호스팅할 컴퓨터에 적절한 버전의 Windows 운영 체제 및 Analysis Services를 설치 및 구성해야 합니다. 이 컴퓨터의 실제 구성, 운영 체제, 설치된 서비스 및 응용 프로그램에 대한 레코드를 하나의 런 북(run book)에서 유지 관리해야 합니다. 이러한 구성 정보가 들어 있는 문서 기록이 있으면 재난 발생 시 서버를 재구축하는 데 도움이 됩니다. 또한 문제 해결을 위해 구성 정보가 필요할 때마다 이 문서 기록을 참조할 수도 있습니다. 이 런 북에는 데이터가 검색되는 시스템 정보와 긴급 상황 발생 시 문의할 수 있는 담당자의 연락처 정보도 포함되어 있어야 합니다. 런 북에서 유지해야 하는 상세 정보에 대한 내용은 Microsoft Technet 웹 사이트(http://www.microsoft.com/korea/technet/default.asp)에서 확인하거나 Microsoft SQL Server 2000 High Availability Series, Volume 1: Planning Guide에 있는 "Appendix: Contents of a Run Book"을 참조하십시오. Planning Guide에서 다루는 항목들은 주로 Microsoft SQL Server 2000의 RDBMS 구성 요소에 관한 것이지만, 특별히 SQL Server Analysis Services에 대한 항목도 포함되어 있습니다. 뿐만 아니라 리소스 및 연락처 정보, 하드웨어 구성 상세 정보, 일부 운영 및 응급 작업 등과 같은 일반적인 사항들이 포함되어 있습니다. BI 응용 프로그램을 출시 및 배포한 후에는 상황 변화에 따라 수정이 필요한지 여부를 확인하기 위해 많은 구성 설정을 모니터링해야 합니다. 임의의 구성 설정을 변경한 경우 런 북의 정보를 업데이트하여 모든 관리 팀 구성원들이 Analysis Services 및 Microsoft Windows 운영 체제의 현재 구성을 신속하게 확인할 수 있도록 해야 합니다. 변경 사항 관리에 대한 자세한 내용은 본 문서의 후반부에 다루어질 "변경 사항 관리"를 참조하십시오.
또한 Analysis Services의 모든 개체를 문서화해야 합니다. 예를 들어, DSO(Decision Support Objects)를 사용하여 Analysis Services의 완벽한 문서를 작성할 수 있도록 하는 Microsoft Word 템플릿인 OLAP Scribe를 사용할 수 있습니다. http://go.microsoft.com/fwlink/?LinkId=22012 Windows 운영 체제 구성최적의 Analysis Services 성능을 구현하도록 Windows 운영 체제를 구성하기 위해서는 주로 프로세서, Windows 페이징 파일 및 메모리를 구성하는 작업이 이루어져야 합니다. 필요 없는 서비스를 비활성화할 수도 있습니다. 참고 Microsoft는 도메인 컨트롤러에 Analysis Services를 설치하지 않을 것을 권장합니다. Analysis Services가 Microsoft Small Business Server 또는 독립 실행형 도메인에 설치되지만 일반적으로 가능하면 이 구성을 피해야 하는 경우와 같이, 이러한 조치가 필요한 구성이 있습니다. 자세한 내용은 Microsoft Knowledge Base(support.microsoft.com)에서 확인하거나 "INF: Running OLAP Services on a Domain Controller" 기사를 참조하십시오. 프로세서다중 프로세서 컴퓨터에서 Analysis Services를 실행하는 경우 Analysis Services는 컴퓨터에서 사용 가능한 모든 프로세서의 스레드의 일정을 설정합니다. SQL Server 서비스와 달리, Analysis Services는 원래 스레드가 실행될 프로세서를 제어하는 프로세서 선호도를 지원하지 않습니다. 이 때문에, 대개의 경우 Analysis Services를 위한 전용 서버를 사용해야 합니다. 다른 서버 응용 프로그램과 컴퓨터 리소스를 공유해야 하는 경우 SQL Server와 같이 프로세서 선호도를 지원하는 서버 응용 프로그램을 선택해야 합니다. SQL Server에서 프로세서 선호도를 설정하면, SQL Server 스레드를 실행하는 프로세서와 이들 스레드의 우선 순위를 제어함으로써, Analysis Services 스레드가 사용할 수 있는 충분한 프로세서 리소스를 유지할 수 있습니다. Analysis Services 스레드가 실행될 프로세서를 제어해야 하는 경우 Microsoft Windows ServerTM 2003 Enterprise Edition 또는 Windows Server 2003 Database Edition을 사용하는 방법도 고려해 보십시오. 이러한 Windows Server 2003 버전에는 관리자가 서버에서 실행되는 응용 프로그램에 대한 프로세서 및 메모리 할당 정책을 설정할 수 있는 WSRM(Windows System Resources Manager)이 포함됩니다. WSRM을 사용하면 Analysis Services 프로세스를 선택하고, Analysis Services 스레드를 특정 CPU 또는 프로세서 리소스의 특정 임계값으로 제한할 수 있습니다. WSRM에 대한 자세한 내용은 Windows Server 2003 웹 사이트(http://www.microsoft.com/korea/windowsserver2003/default.mspx)에서 확인하거나 "Windows System Resource Manager-Fast Facts"를 참조하십시오. 페이징 파일기본적으로, Windows는 컴퓨터의 물리적 메모리량의 약 1.5배에 상응하는 단일 페이징 파일을 사용합니다. 그러나 Analysis Services가 Windows 페이징 파일을 폭 넓게 사용하기 때문에 컴퓨터의 물리적 메모리량에 상응하는 두 번째 페이징 파일을 항상 추가해야 합니다. SQL Server의 관계형 및 다차원 런타임 엔진은 메모리와 매우 상이하게 연동됩니다. SQL Server의 관계형 엔진은 물리적 메모리 사용을 직접 매핑하고 제어하는 반면, Analysis Services의 다차원 엔진은 Windows 운영 체제에 의존하여 필요 시 Analysis Services 주소 공간에 추가 메모리(물리적 또는 가상 메모리)를 할당합니다. 결과적으로, 다른 응용 프로그램에서 물리적 메모리 할당을 요구하기 때문에 Windows 운영 체제가 Analysis Services 작업 집합을 줄이면 Analysis Services는 메모리 요구에 대해 페이징 파일을 사용할 수도 있습니다. Windows 운영 체제에 충분한 메모리 공간이 없을 경우 Analysis Services가 충분한 가상 메모리를 가지도록 하려면 전체 페이징 파일 공간이 기본적으로 구성된 공간 이상이 되어야 합니다. Windows 운영 체제에는 일반적인 메모리 사용을 효과적으로 제어하기 위한 규정이 있지만, Microsoft는 광범위한 페이징이 발생하지 않도록 고객이 적절한 양의 메모리로 서버를 구성할 것을 적극 권장합니다. Analysis Services의 기본 처리 구성 요소인 msmdsrv 프로세스가 광범위한 페이징을 유발하는 경우 처리 성능이 저하됩니다. 메모리Windows 2000 Server 또는 Windows Server 2003 Standard Edition에서 실행되는 Analysis Services과 같은 프로세스는 기본 프로세스 공간에서 최대 2GB의 RAM을 처리할 수 있습니다. 대형 또는 복잡한 큐브에 대한 작업을 수행하는 경우, Analysis Services는 차원(dimension)들을 메모리로 로드하고, 차원들을 처리하며, 복제 차원들을 로드하는데 2GB 이상을 필요로 할 수도 있지만, 여전히 유효한 쿼리 결과 캐시를 위해 사용할 수 있는 충분한 메모리를 보존하게 됩니다. Analysis Services가 단일 프로세스에서 2GB 이상의 RAM을 처리할 수 있도록 하려면 Windows 2000 Advanced Server, Windows 2000 Datacenter Server, Windows Server 2003 Enterprise Edition 또는 Windows Server 2003 Datacenter Edition을 설치해야 합니다. Windows Server 2003 Enterprise Edition 및 Windows Server 2003 Datacenter Edition은 32비트 또는 64비트 버전으로 사용 가능합니다. 64비트 버전은 64비트 버전의 Analysis Services를 지원합니다. Windows 2000 Advanced Server 및 Windows 2000 Datacenter Server가 32비트 운영 체제이므로, 32비트 버전의 Analysis Services만 설치할 수 있습니다.
/3GB 스위치 설정에 대한 자세한 내용은 Microsoft Knowledge Base(support.microsoft.com)에서 확인하거나 "INT: How to Enable Analysis Server To Use 3 GB of RAM" 기사를 참조하십시오. 메모리 보존 임계값 설정에 대한 자세한 내용은 다음 섹션인 "Analysis Services 구성"에서 바로 확인할 수 있습니다. 불필요한 서비스 비활성화Analysis Services 컴퓨터에서 필요 없는 Windows 서비스의 전체 목록은 없지만 불필요한 서비스를 해제하면 Analysis Services에 사용될 메모리가 절약됩니다. 이러한 가능성이 있는 서비스는 다음과 같습니다.
서비스를 비활성화하거나, 수동으로 시작하도록 설정함으로써 서비스를 해제할 수 있습니다. 서비스를 수동으로 시작하도록 설정하면 Windows는 필요한 경우에 서비스를 시작합니다. 참고 바이러스로 인해 수동으로 설정되지 않은 서비스가 시작될 수도 있습니다. 서비스를 비활성화하면 Windows는 서비스를 시작할 수 없게 됩니다. Windows 2000 서비스와 그 기능에 대한 전체 목록은 Microsoft Windows 2000 웹 사이트(http://www.microsoft.com/korea/windows2000/)에서 확인하거나 "Glossary of Windows 2000 Services" 기사를 참조하십시오. 참고 SQL Server 7.0을 실행하고 있다면 원격 레지스트리 서비스를 비활성화하지 마십시오. 이 서비스는 원격 Analysis Services 설치 관리에 필요합니다. 중요 처리 중에 발생할 수 있는 손상과 잠금 문제를 방지하려면 Indexing Service를 비활성화해야 합니다. 또한 시스템에 바이러스 백신 소프트웨어를 구성하여 Analysis Services 폴더나 임시 파일 폴더를 스캔하지 못하게 해야 합니다. Analysis Manager를 사용하여 이들 폴더의 위치를 찾으려면 서버를 마우스 오른쪽 단추로 누르고 속성을 선택한 다음 일반 탭에 나타나는 정보를 확인하십시오. Analysis Services 구성Analysis Services를 설치하고 나면 항상 확인해야 하는 구성 설정이 많이 생깁니다(일반적으로 그 중 몇 가지는 변경해야 하는 사항임). 직접 Windows 레지스트리를 편집하여 변경해야 하는 설정이 몇 가지 있기는 하지만 대부분의 구성 설정은 Analysis Manager를 통해 변경할 수 있습니다. 본 문서에서는 가장 중요한 구성 설정에 대해 설명합니다. 성능과 관련된 추가 구성 설정에 대한 내용은 Technet 웹 사이트(http://www.microsoft.com/korea/technet/default.asp)에서 확인하거나 "Microsoft Analysis Services Performance Guide"를 참조하십시오. Analysis Services에 대한 전범위의 레지스트리 항목에 대한 내용은 Microsoft MSDN 라이브러리(msdn.microsoft.com)에서 확인하거나 "Registry Entries for Microsoft SQL Server 2000 Analysis Services"를 참조하십시오. Analysis Services(또는 다른 Windows 응용 프로그램)로 작성된 레지스트리 키를 모니터링하려는 경우 Windows 플랫폼에 사용 가능한 여러 유틸리티를 사용할 수 있습니다. 일반적으로 사용되는 유틸리티는 Sysinternals(http://www.sysinternals.com 참고 Analysis Services의 일부 기능은 Enterprise Edition에서만 사용 가능합니다. 본 문서 후반부에 수록된 부록 J, "Sample Script to Determine the Analysis Services Edition"을 참조하여 사용 중인 Analysis Services의 버전을 확인하십시오. 메모리 설정Analysis Services를 위한 충분한 메모리를 가지게 되면 쿼리 응답성과 처리 성능이 향상됩니다. 사용 가능한 메모리를 적절하게 구성하면 메모리 사용이 극대화되고, 처리를 위한 디스크 리소스 사용이 제한되며, 클리너 스레드가 캐시 항목을 너무 빨리 제거할 수 없게 됩니다. 다양한 목적으로 Analysis Services에 의해 사용되는 메모리량은 여러 메모리 설정에 따라 규제됩니다.
이러한 설정은 기본값을 사용하여 구성되거나 설치 중 컴퓨터의 물리적 메모리량에 따라 구성됩니다. 일반적으로 이러한 메모리 설정의 일부를 변경하는 것이 좋습니다. 최대/최소 메모리 수준 설정Analysis Services는 Analysis Manager의 서버 속성(Server Properties) 대화 상자의 환경(Environment) 탭에 있는 두 가지 설정, 즉 메모리 보존 임계값(Memory conservation threshold)과 최소 할당 메모리(Minimum allocated memory)(레지스트리의 HighMemoryLimit 및 LowMemoryLimit 값)에 의해 정의되는 범위 내에서 할당된 메모리량을 유지하기 위해 여러 메커니즘을 채택하고 있습니다. 메모리 보존 임계값 설정의 기본값은 설치 당시 컴퓨터의 물리적 메모리량입니다. 최소 할당 메모리 설정의 기본값은 설치 당시 컴퓨터의 물리적 메모리량의 절반입니다. 설치한 후 컴퓨터의 메모리량을 변경하면 이들 값을 수동으로 수정해야 합니다. 그렇지 않으면 Analysis Services가 컴퓨터의 실제 물리적 메모리량을 제대로 사용하지 못하게 됩니다. Analysis Services는 할당된 메모리량이 메모리 보존 임계값 설정과 최소 할당 메모리 설정 사이의 중간 지점에 도달하면 클리너 스레드를 사용하여 Analysis Services에 할당된 메모리량을 감소시킵니다. 클리너 스레드가 활성화되면 쿼리 결과 캐시의 데이터가 사용되는 빈도, 항목을 확인하는 데 필요한 리소스량, 관련 항목에 의해 소모되는 공간량 등의 다양한 요인을 고려한 비용/수익 알고리즘에 따라 클리너 스레드는 쿼리 결과 캐시에서 항목을 제거하기 시작합니다. 기본적으로, 클리너 스레드는 일반보다 낮은 우선 순위로 실행됩니다. 실행 빈도는 BackgroundInterval 레지스트리 설정에 따라 결정됩니다. 실제로 이 설정에 따라 클리너 스레드, 쿼리 로깅 및 지연 처리 등의 다양한 백그라운드 작업에 대한 처리 기간 사이의 초 수치가 제어됩니다. 이러한 다른 백그라운드 작업과 별도로 클리너 스레드에 대한 간격을 설정하려면 CleanerInterval 레지스트리 키를 추가하고 클리너 스레드에만 해당되는 값을 설정하십시오. Analysis Services에 의해 사용되는 메모리량이 메모리 보존 임계값 설정을 초과하면 Analysis Services는 할당된 메모리를 최소 할당 메모리 설정으로 빠르게 줄이기 위해 클리너 스레드의 우선 순위를 일반으로 늘립니다. 모든 Analysis Services에 할당된 전체 메모리가 메모리 보존 임계값을 약 6.25% 정도 초과하면 Analysis Services는 사용되는 메모리량을 줄이기 위해 전체 큐브에 대한 캐시 항목을 즉시 삭제하기 시작합니다. 이 시나리오에서, Analysis Services는 메모리를 매우 빠르게 줄이기 때문에 전체 할당된 메모리량은 최소 할당 메모리 설정 이하로 감소할 수 있습니다. 최소 할당 메모리 설정을 너무 낮게 설정하면 클리너 스레드가 쿼리 결과 캐시에서 캐시된 항목을 너무 많이 제거하게 됩니다. 그러면 쿼리 응답 시간이 줄어들고 쿼리 결과를 다시 채우기 위해 추가 리소스가 필요합니다. 예를 들어, 컴퓨터의 물리적 메모리가 2GB이고 메모리 보존 임계값 설정을 1.4GB로, 최소 할당 메모리 설정을 100MB로 설정한다고 가정해봅시다. 메모리 사용이 1.4GB를 훨씬 초과하면 클리너 스레드는 100MB 이하로 내려갈 때까지 쿼리 결과 캐시에서 항목을 빨리 제거합니다. 이 시스템에 보다 적절한 최소 할당 메모리 설정은 약 1GB이며, 이는 할당된 메모리량이 메모리 보존 임계값 설정을 초과할 때 불필요하게 캐시 항목을 제거하지 않고도 작업을 수행할 수 있는 공간을 클리너 스레드에 제공합니다. 확인되는 바대로, 메모리 보존 임계값 설정을 너무 낮게 설정하면 전체 성능이 저하되며 메모리 부족 오류가 발생할 수 있습니다. 메모리 보존 임계값 설정을 컴퓨터의 물리적 메모리량 이상으로 설정해서는 안됩니다(반대의 경우 페이징 파일이 과잉 사용됨). /3 GB 스위치를 활성화하는 경우 메모리 보존 임계값 설정을 약 2.7GB 이상으로 설정해서는 안됩니다. 이 값을 3GB 메모리 제한보다 약간 낮게 설정하면 Analysis Services가 전체 3GB 주소 공간을 사용하기 전에 낮은 메모리 상황에 응답하고 할당된 메모리를 줄일 수 있는 충분한 시간을 가지게 됩니다. 메모리 보존 임계값은 Analysis Services에 의해 사용되는 메모리량을 직접 제한하지는 않습니다. 즉, Analysis Services는 기본 프로세스 공간에서 주소 공간을 모두 소모하거나 컴퓨터의 실제 물리적 메모리보다 많은 메모리를 사용할 수 있습니다. 팁 메모리를 추가하거나 boot.ini 파일에서 /3GB 스위치를 활성화하는 경우 Analysis Manager에서 메모리 보존 임계값과 최소 할당 메모리 설정을 증가시키십시오. Manager. 참고 Analysis Services Service Pack 3을 설치하지 않았을 경우 Analysis Manager에서 메모리 보존 임계값 설정을 사용하는 대신 Analysis Services를 통해 2GB 이상의 메모리를 처리할 수 있도록 레지스트리를 직접 편집하여 HighMemoryLimit 값을 수정해야 합니다. SP3에서, Analysis Manager는 관리자가 2GB 이상(최고 3GB)의 숫자를 입력할 수 있도록 변경되었습니다. SP2 및 이전 버전의 경우 Analysis Manager에는 1~2047MB 사이의 설정만이 허용됩니다. 자세한 내용은 Microsoft Knowledge Base(support.microsoft.com)에서 확인하거나 "INF: How to Enable Analysis Server To Use 3 GB of RAM" 기사를 참조하십시오. VLDM(Very Large Dimension Memory) 임계값32비트 버전의 Analysis Services(64비트 버전은 VLDM을 사용하지 않음)는 시작 시 각각의 초대형 차원(very large dimension)을 자체 가상 메모리 주소 공간과 함께 자체 프로세스 공간으로 로드함으로써 대형 차원(large dimension)이 모든 가상 메모리 주소 공간을 사용하는 것을 막게 됨니다. 초대형 차원은 레지스트리의 VLDMThreshold 설정값을 초과하는 값입니다. 기본 VLDM 임계값은 64MB입니다. VLDM 임계값을 초과하는 각 차원에 대해 별도의 주소 공간을 사용하면 기본 프로세스에서 다른 용도의 가상 메모리 주소 공간이 절약되지만, 하나 이상의 차원이 VLDM 임계값을 초과하면 전체 성능이 저하됩니다. 모든 차원을 기본 프로세스 공간으로 로드하면(가능한 경우) 보다 나은 성능을 내게 되지만, 다음과 같은 작업을 수행하기에 충분한 가상 메모리 공간이 있도록 보장해야 합니다.
Analysis Services가 기본 프로세스 공간에 충분한 가상 메모리 주소 공간을 가지고 있지 않을 경우 가장 큰 차원 만 별도의 주소 공간으로 로드되도록 VLDM 임계값을 설정하십시오. Analysis Services가 메모리를 사용하는 방식과 필요한 메모리량을 계산하는 방법에 대해서는 본 문서의 후반부에 다루어질 "용량 관리"를 참조하십시오. Analysis Services가 기본 프로세스 공간에 충분한 가상 메모리 주소 공간을 가지고 있는 경우 Bin 폴더에 있는 msmdvldm.exe 파일 이름을 다른 이름(예: msmdvldm-disabled.exe)으로 변경하여 VLDM을 비활성화하십시오. 서비스가 시작될 때 VLDM 실행 파일을 찾지 못하면 서비스는 해당 파일을 비활성화합니다. VLDM은 64비트 시스템에서 자동으로 비활성화됩니다. VLDM을 비활성화하면 모든 차원이 기본 프로세스 공간으로 로드됩니다. VLDM과 관련된 모든 성능 및 제한 사항을 고려할 때, 일반적인 최상의 방법은 응용 프로그램이 VLDM을 강제로 사용하게 될 만큼 큰 경우, SQL Server 2000(64비트)이 보다 강력한 성능을 제공하는지 여부를 평가하는 것입니다. 중요 일반적으로 다음과 같은 경우 64비트 버전의 Analysis Services의 사용을 고려해야 합니다. 자세한 내용은 Technet 웹 사이트(http://www.microsoft.com/korea/technet/default.asp)에서 확인하거나"Microsoft SQL Server 2000 (64-bit) Analysis Services: Why Migrate, and What to Expect If You Do"를 참조하십시오. 참고 VLDM 임계값이 큰 차원에 사용되면 Analysis Services는 처리 중에 기본 주소 공간에 이들 큰 차원에 대한 섀도우 차원을 만듭니다. 따라서 VLDM을 사용하는 경우에도 기본 프로세스의 가상 주소 공간에 상당한 영향을 미치게 됩니다. 프로세스 버퍼Analysis Services는 처리하는 각 파티션을 위해 메모리에 프로세스 버퍼를 만듭니다. 필요할 때 각 버퍼에 메모리를 할당하고 파티션 처리가 완료되면 각 버퍼에서 이 메모리를 해제합니다. Analysis Services는 별도의 두 작업에 대해 각각 버퍼를 사용합니다.
Analysis Manager의 프로세싱(Processing) 탭에 있는 프로세스 버퍼 크기(Process buffer size) 설정(레지스트리의 ProcessReadSegmentSize 값)에 따라 각 프로세스 버퍼의 최대 크기가 결정됩니다. 기본적으로 각 프로세스 버퍼의 최대 크기는 약 32MB입니다. 대부분의 응용 프로그램의 경우 32MB는 너무 작을 수 있으므로 바로 크기를 늘려야 합니다. 최소한 150~200MB 사이로 설정하는 것이 더욱 효과적입니다. 팩트 데이터가 파티션 파일의 세그먼트로 작성되기 전에 팩트 데이터의 상당 부분을 효율적으로 분류 및 인덱싱할 수 있을 정도로 각 프로세스 버퍼가 클 경우, 전체 데이터 구성 및 쿼리 응답성이 향상됩니다. 뿐만 아니라, 팩트 테이블에 많은 중복 레코드가 들어 있을 경우, 큰 프로세스 버퍼를 통해 Analysis Services는 메모리의 중복 레코드를 병합할 수 있게 되며, 이에 따라 공간이 절약되고 쿼리 성능이 향상됩니다. Analysis Services가 집계를 생성하는 동안 프로세스 버퍼의 크기를 초과하는 경우 Analysis Services는 알고리즘을 변경하여 프로세스 버퍼에 할당된 메모리를 확대하는 임시 파일을 사용합니다. 임시 파일이 사용되면 Analysis Services는 집계가 계산되고 있을 때 이들 임시 파일과 프로세스 버퍼에 할당된 메모리 간에 집계를 전달합니다. 이러한 임시 파일을 읽고 쓰는 것은 메모리 내의 계산보다 훨씬 속도가 느리며, 매우 I/O 집약적인 작업입니다. 가능하면 프로세스 버퍼 크기 설정을 증가시켜서 이러한 임시 파일 사용을 제거하도록 시스템을 조정해야 합니다. 파티션에 대한 모든 집계는 동시에 계산되며 메모리가 충분해야 합니다. 그렇지 않으면 임시 파일이 사용됩니다. 여러 파티션을 병렬로 처리하거나, 전체 큐브를 단일 트랜잭션으로 처리하는 경우 프로세스 버퍼, 차원, 섀도우 차원, 복제본 및 기타 메모리 요구 사항에 필요한 전체 메모리가 메모리 보존 임계값 설정을 초과하지 않도록 해야 합니다. Analysis Services가 이러한 동시 작업을 위한 가상 주소 공간을 모두 소모하면 메모리 부족 오류가 발생합니다. 가상 메모리를 지원하기에 충분한 물리적 메모리가 없을 경우 Windows 운영 체제는 가상 메모리 페이징 파일을 사용하여 사용 가능한 물리적 메모리를 보충합니다. 초과 페이징이 발생하면 페이징 파일 사용이 성능 결과에 영향을 미치는 반면, 필요한 경우 작은 크기의(약 100~200MB) 페이징은 통상적으로 허용됩니다. 반면, 프로세스 버퍼 설정이 너무 크고 총계(aggregate)의 수 및 크기가 처리 중에 프로세스 버퍼를 채울 수 있을 만큼 크면 Analysis Services는 메모리 보존 임계값을 초과할 수도 있습니다(쿼리 응답 캐시가 지워지거나 덤프됨). 처리 중에 메모리 보존 임계값을 초과하면 임시 파일이 사용되기 시작합니다. 파티션을 병렬로 처리하면 각 파티션이 별도의 프로세스 버퍼를 사용한다는 점에 유의하십시오. 팁 충분한 메모리가 있을 경우 프로세스 버퍼 크기 설정을 최소한 150~200MB로 증가시켜서 처리 중 임시 파일의 사용을 제거하십시오. 대형 큐브를 사용해 서버 상의 프로세스 버퍼 크기를 300 또는 500MB로 설정하는 것은 일반적입니다. 적절한 프로세스 버퍼 크기를 결정하려면 본 가이드의 후반부에 있는 부록 C, "프로세스 버퍼 크기 조정 방법"을 참조하십시오. 데이터 및 임시 파일 위치Analysis Services 인스턴스는 데이터 폴더와 임시 폴더를 가지고 있습니다. Analysis Services는 데이터 폴더를 사용하여 Analysis Services 인스턴스에서 정의된 모든 개체에 대한 다차원 구조를 저장합니다. 또한 임시 폴더를 사용하여 처리 중인 집계에 비해 프로세스 버퍼가 너무 작을 때 각 프로세스 버퍼에 할당된 메모리를 보충합니다. 이들 폴더의 기본 위치는 C:\Program Files\Microsoft Analysis Services\Data입니다. 설치 중일 때 또는 설치한 후에 이들 폴더의 위치를 변경할 수 있습니다. 설치 후에 위치를 변경하려면 Analysis Manager에서 Analysis 서버 개체를 마우스 오른쪽 단추로 누른 다음 속성을 누르십시오. 또한, 데이터 폴더를 프로그래밍 방식으로 변경하려면 부록 D, "데이터 폴더 위치 변경을 위한 샘플 스크립트"에 나오는 샘플 스크립트를 사용할 수도 있습니다. 참고 Analysis Services 컴퓨터에서 백신 검사 소프트웨어를 사용하는 경우 Analysis Services의 데이터, 임시 및 휴지통 폴더에 대한 검사를 해제해야 합니다. 데이터 폴더를 자체 RAID 어레이에 배치해야 합니다. RAID 10 또는 RAID 1 + 0은 최상의 성능을 제공하지만 RAID 5는 종종 많은 Analysis Services를 설치하기에 충분할 정도로 속도가 빠릅니다. Analysis Services의 주요 작업은 데이터 폴더에 있는 파일에 쓰는 것이 아니라, 사용자 쿼리에 대한 응답으로 데이터 폴더에 있는 데이터 파일을 읽는 것입니다. 일단 데이터, 인덱스 및 집계 구조에 필요한 공간의 양이 결정되면 디스크 공간의 약 두 배를 할당해 처리 중에 데이터를 새로 고치고, 섀도우 파일(shadow file)을 저장할 수 있도록 충분한 공간을 허용해야 합니다. 데이터 폴더에 필요한 공간 계산에 대한 자세한 내용은 본 가이드의 후반부에 나오는 "용량 관리" 섹션의 "디스크"를 참조하십시오. 데이터 폴더에 저장되는 각 파일 유형에 대한 자세한 내용은 부록 K, "데이터 폴더 구조"를 참조하십시오. 참고 데이터 폴더는 일반 사용자의 Analysis Services 개체에 대한 액세스를 제어하는 보안 파일을 저장하기 때문에, 권한없는 사용자가 데이터 폴더에 액세스할 수 없도록 안전하게 보호해야 합니다. OLAP 관리자 그룹 및 관리자 그룹의 구성원 만이 데이터 폴더에 액세스할 수 있어야 합니다. 설치 후 데이터 폴더의 위치를 이동하려면 이러한 보안 설정을 수동으로 구성해야 합니다. OLAP 보안에 대한 자세한 내용은 본 문서의 후반부에 나오는 "보안 관리"를 참조하십시오. 임시 폴더임시 폴더가 실제로 사용되는 경우, 훌륭한 쓰기 성능을 제공하며 데이터 폴더와는 다른 물리적 드라이브에 있는 RAID 어레이에 임시 폴더를 배치해야 합니다. 예산 요건과 사용량에 따라 RAID 0, 1, 0+1 또는 10을 사용하는 방안을 고려해 보십시오. 그러나 최고의 성능을 위해 보다 중요한 것은 충분히 큰 프로세스 버퍼를 할당해 처리 중에 임시 파일이 필요하지 않도록 하는 것입니다. 처리 중에 임시 파일이 필요하면, 알고리즘은 메모리 내에서 처리가 완벽하게 수행될 수 있을 정도로 충분히 큰 프로세스 버퍼가 사용된 경우보다 현격히 느려지게 됩니다. 임시 폴더 구조에 있는 파일이 광범위하게 사용되고 있으며 이러한 사용을 없앨 수 없다는 것을 발견했다면, TempDirectory2 레지스트리 키(HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLAP Server\Current Version)를 추가하고 두 번째 임시 폴더에 대해 별도의 물리적 드라이브 상의 위치를 지정함으로써 다른 물리적 드라이브 상의 두 번째 임시 파일 폴더를 추가할 수 있습니다. 임시 파일을 사용해야 하는 경우, 두 개의 임시 폴더를 사용하면 하나의 임시 폴더에 있는 데이터가 순차적으로 읽히고 새로운 세그먼트 데이터와 병합된 다음 두 번째 임시 폴더(64KB 세그먼트에 있음)에 기록되므로 처리 성능이 향상됩니다. 그 다음 두 번째 임시 폴더에 있는 데이터가 읽히고, 새로운 세그먼트 데이터와 병합되고, 첫 번째 임시 폴더에 기록됩니다. 이 프로세스는 집계의 계산이 완료될 때까지 계속됩니다. 임시 폴더의 사용 여부를 확인하려면 본 문서의 후반부에 있는 부록 C, "프로세스 버퍼 크기 조정 방법"을 참조하십시오. 데이터 소스 구성Analysis Services 인스턴스 내에 새로운 데이터베이스를 만드는 경우, 처음으로 해야 할 작업 중의 하나는 데이터베이스에 대한 데이터 소스를 정의하는 것입니다. 데이터 소스에는 데이터베이스 개체의 소스 데이터에 액세스하는 데 필요한 정보가 들어 있습니다. "데이터 소스"라는 용어는 사실 소스 데이터 자체가 아니라 생성되는 데이터 소스 개체를 말합니다. Analysis Manager에서 데이터 소스를 정의할 때 개체에 주어지는 이름은 <server_name>-<database_name> 또는 <localhost>-<database_name>입니다. 그러나 데이터베이스를 다른 서버로 이동할 때 혼동되지 않게 하려면 데이터베이스가 처음 생성된 원본 컴퓨터의 이름과 관련이 없는 데이터 소스의 논리적 이름을 만들어 기본 명명 규칙을 변경해야 합니다. Analysis Manager에서 데이터 소스 개체에 대한 논리적 이름을 만들려면 데이터 소스 개체를 만든 다음, 새로운 데이터 소스 개체를 잘라내 동일한 Analysis Services 데이터베이스에 붙여 넣습니다. 그러면 데이터 소스 개체에 대한 새 이름을 지정하라는 메시지가 나타납니다. 판매 데이터(Sales Data) 또는 개인 데이터(Personal Data)와 같이 데이터의 논리적 유형을 반영한 이름을 선택해야 합니다. 새 논리적 이름을 지정한 다음 원본 데이터 소스 개체를 삭제합니다. 그 후로는, 컴퓨터 간에 Analysis Services 데이터베이스를 이동할 때 Analysis Manager(또는 스크립트)에서 데이터 소스 개체의 속성을 수정하여 연결 스트링의 기본 서버 및 데이터베이스를 간단하게 변경할 수 있습니다. 데이터 소스의 이름을 물리적 이름 대신 논리적 이름으로 변경하는 것 외에도, 배포 컴퓨터가 동일한 이름을 사용하도록 해야 합니다. 개발 컴퓨터에 판매 데이터라는 이름의 데이터 소스가 있을 경우 QA 컴퓨터와 생산 컴퓨터에도 판매 데이터라는 이름의 데이터 소스가 있어야 합니다. 개발, QA 및 생산 컴퓨터에 일관된 이름을 사용하면 Analysis Services 데이터베이스 간에 잘라내기 및 붙여넣기 작업을 함으로써 개별 시스템을 더욱 쉽게 마이그레이션할 수 있습니다. 데이터베이스에서 개체를 만들기 전에 데이터 소스 개체의 이름을 변경하지 않으면 타사 유틸리티를 사용하지 않고는 데이터 소스의 이름을 변경할 수 없게 될 것입니다. Analysis Services 인스턴스 간에 데이터베이스를 이동할 때 사용할 수 있는 도구에 대해서는 본 가이드의 후반부에 설명되는 "릴리스 관리"를 참조하십시오. 서비스 계정MSSQLServerOLAPService 및 SQL Server Agent 서비스 계정에 필요한 권한을 이해하려면 다양한 작업이 실행되는 보안 컨텍스트를 이해해야 합니다. 특정 작업은 로그온된 사용자의 컨텍스트에서 수행되며, 다른 작업은 MSSQLServerOLAPService 서비스 계정의 보안 컨텍스트에서 수행됩니다.
사용자가 개체를 생성할 수 있다면 이 개체를 처리할 수도 있다고 가정하는 것이 일반적입니다. 이것이 단순한 단일 컴퓨터 개발 환경에서 가능한 경우인 반면, 다중 컴퓨터 생산 부서에서는 여러 문제를 겪게 될 수 있습니다. 소스 데이터베이스가 Analysis Services 데이터베이스와는 별도의 서버에 있고 Analysis Services 인스턴스가 원격에서 관리되는 상황에서, 이들 응용 프로그램을 현업 환경에 공개할 때 가장 자주 겪게 되는 문제는 권한 부족 문제입니다. MSSQLServerOLAPService 및 SQL Server Agent 서비스 계정이 수행해야 할 작업에 대한 권한을 갖도록 해야 합니다. 최소한 서비스 계정은 OLAP 관리자 그룹의 구성원이어야 합니다. 이 권한은 Analysis Services 서버를 관리하는 모든 사용자(또는 사용자 역할을 대신하고 있는 서비스)에게 필요합니다. MSSQLServerOLAPService기본적으로, MSSQLServerOLAPService 서비스는 로컬 컴퓨터에 대한 전체 관리자 권한은 있으나 원격 컴퓨터에 대한 액세스 권한이 없는 로컬 시스템 계정 하에서 실행됩니다. 로컬 시스템 계정에는 네트워크 액세스 권한이 없기 때문에, 대부분의 경우 네트워크 액세스 권한이 부여될 수 있는 계정으로 서비스 계정을 변경해야 합니다. Windows 2000에서는 이 계정이 도메인 사용자 계정입니다. Windows Server 2003을 사용하는 경우 NetworkService 계정을 사용할 수 있습니다. MSSQLServerOLAPService 서비스가 실행되는 계정에는 몇 가지 상이한 작업을 수행할 수 있는 권한이 있어야 합니다. MSSQLServerOLAPService 서비스는 Analysis Services 개체를 처리하고, 처리 중에 소스 데이터를 액세스하며, 다중 계층 환경에서 보안 자격 증명을 받을 수 있어야 합니다. 팁 이름이 지정된 파이프 네트워크 프로토콜을 사용하는 경우, 원격 컴퓨터에 있는 응용 프로그램(예: SQL Server)에 액세스하려고 하는 프로세스(예: Analysis Services 처리 작업)가 SQL Server의 인증을 받기 전에 Windows 운영 체제의 인증을 받아야 합니다. TCP/IP 소켓을 사용하는 경우에는 일반적으로 인증 자격 증명을 SQL Server에 제공하기 전에 프로세스가 Windows 운영 체제의 인증을 받을 필요가 없습니다. SQL Server AgentSQL Server Agent를 사용하여 개체 생성 작업(예: 파티션 생성 작업)이나 개체 처리를 자동화할 때, SQL Server Agent에 의해 사용되는 서비스 계정은 개체를 생성하거나 처리할 수 있는 권한이 있어야 합니다. 처리도메인 사용자 계정(또는 NetworkService 계정) 하에서 MSSQLServerOLAPService 서비스를 실행할 때, 이 계정을 Analysis Services 컴퓨터의 OLAP 관리자 로컬 그룹에 추가하여 Analysis Services가 해당 컴퓨터에서 차원, 파티션 및 마이닝 롤을 사용할 수 있도록 해야 합니다. OLAP 관리자 그룹에 있는 이 계정의 구성원 자격을 통해 MSSQLServerOLAPService 서비스는 레지스트리, 데이터 폴더 및 임시 폴더에 액세스할 수 있습니다. OLAP 관리자 그룹의 구성원이 아닌 사용자 계정으로는 이러한 위치에 액세스하지 않아야 합니다. 소스 데이터 액세스MSSQLServerOLAPServer 서비스 계정은 소스 데이터를 액세스하는데 신뢰할 수 있는 연결을 사용할 경우 소스 데이터베이스에서 소스 데이터에 액세스할 수 있는 로그온 계정 권한을 보유해야 합니다. 신뢰할 수 있는 연결을 통해 MSSQLSererOLAPService 서비스 계정은 데이터 소스로 연결하는 데 사용됩니다. 신뢰할만한 연결이 사용되지 않을 경우 사용자 이름 및 암호를 지정할 수 있습니다. 데이터 소스로 연결할 경우 요구되는 권한은 Analysis Services 파티션을 위해 사용되는 스토리지 구조 유형에 따라 좌우됩니다. MOLAP 스토리지가 사용될 경우 서비스 계정은 소스 데이터베이스에서 최소한 SELECT 권한을 보유하고 있어야만 합니다. 만일 ROLAP 또는 HOLAP 스토리지가 사용될 경우 서비스 계정은 소스 데이터베이스에 대한 최소 SELECT 및 CREATE table 권한을 보유하고 있어야만 합니다. 또한 여타 Analysis Services 서버의 자원을 사용할 경우 필요한 권한이 있습니다. 만일 연결된 큐브를 사용할 경우 MSSQLServerOLAPService 서비스 계정은 큐브에 대한 읽기 액세스 권한을 보유하고 있어야 하며 셀 레벨 보안을 정의해서는 안됩니다. 만일 Analysis Services가 원격 파티션 퍼블리셔일 경우 MSSQLServerOLAPService 서비스 계정은 원격 파티션이 위치되는 머신 상의 OLAP Administrator 그룹에 포함되어야 합니다. 만일 Analysis Services가 원격 파티션 서브스크라이브일 경우 MSSQLServerOLAPService 서비스 계정은 큐브에서 읽기 액세스 권한을 보유해야 합니다. 미들 티어 응용 프로그램을 통한 클라이언트 보안 자격 증명 받기MSSQLServerOLAPService 서비스 계정은 일반적인 클라이언트-서버 환경과 관계가 없습니다. 이러한 환경에서 사용자 응용 프로그램은 Analysis Services 컴퓨터로 직접 연결되어 질의를 실행하거나 개체를 생성하며 사용자의 자격 증명을 Analysis Services로 직접 전달하여 평가합니다. 또한 셀 및 차원 레벨 보안을 기반으로 Analysis Services를 통해 액세스를 승인하거나, 거부합니다. 그러나 만일 클라이언트 응용 프로그램이 미들티어 서버를 통해 Analysis Services로 연결을 시도할 경우 인증 프로세스가 다소 복잡해집니다. 일반적으로 보안 자격 증명은 여러 대의 컴퓨터를 통해 전달될 수 없습니다. 그러나 미들티어 응용 프로그램 서버 및 Analysis Services 컴퓨터가 Kerberos 인증 및 위임을 지원할 경우 본 클라이언트의 보안 자격 증명은 미들티어 응용 프로그램을 통해 Analysis Services로 전달될 수 없습니다. Kerberos 인증, 위임, 가장 및 상호 인증을 실행하기 위해서 MSSQLServerOLAPService 서비스는 다음의 계정으로 실행해야만 합니다.
참고 Kerberos 인증, 위임, 가장 및 상호 인증을 지원하기 위해서는 여러 단계를 반드시 거쳐야 합니다. 이러한 단계에 대한 자세한 내용은 SQL Server 온라인 설명서의 "Security Account Delegation"를 참조하십시오. 또한 Knowledge Base (support.microsoft.com)에서 제공되는 "Use Kerberos Authentication for Microsoft SQL Server 2000 Analysis Services." 기사를 참조하십시오. SQL Server Agent 서비스SQL Server Agent 서비스는 DTS(Data transformation Services) 패키지에서 Analysis Services Processing 작업을 실행하는 데 사용되며 Microsoft Visual Basic Scripting Edition(VBScript) 스크립트를 통해 실행되는 DSO 작업을 포함하고 있는 작업들을 수행하는 데 사용됩니다. SQL Server Agent 서비스 계정이 이러한 작업을 적절히 수행할 수 있도록 권한을 확보하기 위해서는 도메인 사용자 계정(또는 Windows Server 2003의 NetworkService 계정)으로 SQL Server Agent 서비스를 실행한 다음 이 계정을 Analysis Services 컴퓨터의 OLAP Administrators 그룹으로 추가하십시오. 만일 SQL Server Agent 작업을 상호적으로 수행할 경우(SQL Server Enterprise Manager의 해당 작업에서 마우스의 오른쪽을 클릭한 다음 Run을 클릭하면 됩니다) 사용된 보안 자격 증명이 SQL Server Agent 서비스 계정의 자격 증명이 아니라는 사실을 이해하지 못한다면 SQL Server Agent와 관련된 권한 문제를 해결하는 데 다소 혼란스러울 수 있습니다. SQL Server Agent 작업을 상호적으로 수행할 경우 해당 작업을 개시한 사용자의 보안 자격 증명이 사용됩니다. SQL Server Agent 서비스 계정의 자격 증명은 해당 작업이 실제로 진행되는 경우에만 사용됩니다(SQL Server Agent가 사용하는 도메인 사용자 계정을 사용하여 로그온하지 않을 경우). 리포지토리 마이그레이션Analysis Services 인스턴스에서 생성된 개체를 위한 메타 데이터(큐브, 차원 등)는 Analysis Services 리포지토리에 저장됩니다. 이러한 리포지토리는 기본값으로 msmdrep.mdb이라는 Microsoft Access 데이터베이스로 지정되며 Analysis Services 컴퓨터의 ..\Microsoft Analysis Services\Bin 폴더에 저장됩니다. 이러한 Access 형식은 관계형 데이터를 위해 SQL 서버를 사용하지 않는 사용자들이 Analysis Services를 사용할 수 있도록 하기 위해 지원합니다. 그러나 만일 SQL 서버를 사용할 경우 리포지토리를 SQL Server 데이터베이스로 마이그레이션함으로써 엔터프라이즈 레벨 확장성, 지원 및 보안을 강화할 수 있게 됩니다. 또한 이러한 리포지토리를 마이그레이션함으로써 Data 폴더의 파일 기반 백업을 통해 리포지토리 데이터베이스의 백업을 일관적으로 수행할 수 있게 됩니다. 자세한 정보는 본 가이드 후반부 "백업 및 복구(Backup and Recovery)"를 참조하십시오. 리포지토리로 마이그레이션하기에 앞서 대소문자를 구분하지 못하는 데이터 정렬 기능을 사용하여 전용 데이터베이스(OLAPRepository 데이터베이스 등)를 생성하십시오. 전용 데이터베이스는 자체 계획에 따라 리포지토리 데이터베이스를 백업할 수 있도록 지원합니다. 원격 컴퓨터에 위치된 SQL Server 인스턴스에서 이러한 전용 데이터베이스를 생성할 수 있는 반면, 최상의 성능을 끌어내기 위해서는 로컬 SQL Server 인스턴스에서 이러한 데이터베이스를 생성해야 합니다. 이 리포지토리를 SQL Server로 마이그레이션하기 위해서는 Migrate Repository Wizard를 사용하고 Analysis Services 기본 형식을 선택하십시오. 중요 대부분의 환경에서는 리포지토리를 Migrate Repository Wizard가 선택한 기본값 데이터베이스인 msdb 데이터베이스로 마이그레이션해서는 안됩니다. Msdb 데이터베이스는 Analysis Services 리포지토리 전용의 단일 SQL Server 인스턴스에 적합한 반면, 일반적인 공유 환경에는 적합하지 않습니다. Msdb 데이터베이스를 선택할 경우 Analysis Services 포지토리는 데이터베이스 유지보수 작업, 복제 정의, DTS 패키지 및 모든 유형의 실행 로그 등과 같이 해당 인스턴스의 모든 여타 SQL Server 시스템 레벨 자원과 공유됩니다. 전용 데이터베이스를 사용함으로써 자체 계획에 따라 리포지토리를 백업 및 복구할 수 있으며 msdb 데이터베이스에 저장된 여타 개체와는 독립적으로 운영됩니다. 리포지토리를 SQL Server 데이터베이스로 마이그레이션한 후에는 Microsoft Access 데이터베이스로 다시 마이그레이션할 수 없습니다. 마이그레이션 작업으로 msmdrep.mdb 데이터베이스가 제거되지는 않습니다. 보안을 강화하기 위해 마이그레이션 작업을 성공적으로 완료한 후 msmdrep.mdb 데이터베이스를 제거해야 합니다(Windows Explorer를 사용하여 파일을 제거). 만일 마이그레이션 작업이 실패한 경우 Analysis Services는 모든 변경 작업을 포기하고 msmdrep.mdb 데이터베이스의 사용을 재개합니다. 팁 친숙하지 않은 Analysis Services 인스턴스에서 리포지토리의 위치를 파악하기 위해서는 Analysis Manager의 서버 개체에서 마우스 오른쪽을 클릭하고 Edit Repository Connection String을 클릭합니다. 이러한 옵션은 SP3에 추가되었습니다. SP3 도입 이전에는 레지스트리에서 연결 문자열을 검토할 수 있었습니다. 그러나 SP 3 도입 이후 레지스트리의 이러한 연결 문자열을 암호화하여 Analysis Manager에서 Edit Repository Connection String 명령어를 사용하는 것이 현 리포지토리를 뷰잉하는 유일한 방법입니다. 로깅 및 오류 리포팅Analysis Services는 쿼리 로그를 기록함으로써 쿼리 패턴을 분석하고 집계 설계를 개선할 수 있도록 지원합니다. 이러한 쿼리 로그의 속성들을 구성할 수 있습니다. 또한 프로세싱 로그를 지원할 뿐만 아니라 Analysis Services 오류 리포팅을 지원할 수 있습니다. 쿼리 로그Usage Based Optimization Wizard를 통해 과거 사용 패턴을 기반으로 집계를 계획하고, Usage Analysis Wizard를 통해 쿼리 사용을 분석하는 리포트를 생성할 수 있도록 하기 위해 Analysis Services는 Microsoft Access 데이터베이스에 저장된 쿼리 로그의 모든 N번째 쿼리가 실행된 레벨을 기록합니다. 기본 값으로 모든 10번째 쿼리가 로깅됩니다. 이러한 쿼리 로그의 기본 위치는 C:\Program Files\Microsoft Analysis Services\Bin\msmdqlog.mdb입니다. 모든 로그 파일과 마찬가지로 이들 파일은 인증받지 않은 사용자가 액세스할 수 없도록 보호되어야 합니다. 로깅 간격(예, 모든 N번째 퀴리)을 변경하고 모든 쿼리 로깅을 중단하거나 쿼리 로그를 제거할 수 있습니다. 로깅 빈도를 너무 낮게 설정하는 것은 성능에 악영향을 미칠 수 있습니다. 특히 초당 많은 수의 쿼리를 생성하는 수백 명의 동시 사용자들을 보유하고 있는 시스템에서 작업을 하고 있다면 로깅 빈도를 10 이상으로 높임으로써 성능을 향상시킬 수 있습니다. 이러한 시스템에서 Analysis Services는 다수의 쿼리를 신속하게 로깅하도록 지원하지만 Access는 고성능 데이터베이스 시스템만큼 신속하게 이러한 대량의 정보를 작성할 수 없습니다. 만일 쿼리 로그의 작업 부담이 커지거나 안정성 및 복구 기능을 강화하려면 쿼리 로그를 전용 SQL Server 데이터베이스로 마이그레이션하는 것을 고려해 보십시오. Analysis Services 내에 내장 마이그레이션 기능이 장착되어 있지 않지만 이 작업은 상당히 손쉬운 작업입니다. Msmdplog.mdb Access 데이터베이스 내의 QueryLog 테이블을 SQL Server 데이터베이스로 내보내고 QueryLogConnectionString 레지스트리 설정을 편집하고 난 후 Analysis Services를 재시작하십시오. 이러한 방식으로 쿼리 로그를 마이그레이션한 경우 이에 따라 백업 및 복구 프로시저를 변경하는 것을 잊지 마십시오. 또한 Usage-Based Optimization Wizard를 서버의 모든 큐브에서 연속적으로 실행한 후 쿼리 로그를 제거해야 한다는 것을 유념해야 합니다. 이러한 쿼리 로그 속성을 수정하기 위해서는 Analysis Manager의 Analysis 서버 개체에서 마우스 오른쪽을 클릭하고 Properties를 클릭한 다음 Logging 탭을 클릭하십시오. 참고 쿼리 로그는 큐브 당 기준이 아니라 서버 와이드 기준으로 쿼리를 기록합니다. 프로세싱 로그 파일Analysis Services는 기본값으로 프로세싱 로그를 기록하지 않습니다. 여러분은 프로세싱 로그 파일을 기록해야만 합니다. 프로세싱 로그 파일은 파티션, 차원 또는 마이닝 모델을 처리할 때 Analysis Manager의 Process 대화 상자에 전시된 모든 프로세싱 정보를 포함하는 시스템 차원의 텍스트 파일입니다. 프로세싱 로그 파일을 기록함으로써 다음과 같은 업무를 수행할 수 있도록 지원합니다.
프로세싱 로그 파일을 지원하기 위해서는 Analysis Manager의 Analysis 서버 개체에서 마우스 오른쪽을 클릭하고 Properties를 클릭하고 난 후 Logging 탭을 클릭합니다. 프로세싱 로그가 상당히 커질 수 있기 때문에 기존 로그의 이름을 주기적으로 변경해야 하며 Analysis Services는 새로운 이름을 개시하도록 해야 합니다(월별, 분기별 또는 개체를 선택하는 빈도에 따라). 기존의 프로세싱 로그 파일의 이름을 주기적으로 변경함으로써 적절한 크기의 파일 내에 실행 기록을 유지할 수 있게 됩니다. 시스템 와이드 프로세싱 로그는 일반적으로 대부분의 응용 프로그램(Analysis Manager 등)을 위해 사용되지만, DSO 레벨에서 출력을 여타 위치로 재지정하도록 응용 프로그램을 구성할 수 있습니다. 이에 따라 프로세싱 로그가 시스템에서 실행되는 모든 프로세싱 요청을 포함할 수 없다는 것을 인지해야 합니다. 예를 들면 DTS OLAP Processing 작업을 통해 생성된 프로세싱 로그는 DTS 로그 파일로 재지정되며 이러한 프로세싱은 시스템 와이드 프로세싱 로그에서 캡처되지 않을 것입니다. DTS OLAP Processing 작업은 작업을 개별 로그 파일로 재지정하는 유일한 마이크로소프트 응용 프로그램입니다. 팁 관리 중인 각 Analysis Services 컴퓨터 상에서 파일을 손쉽게 찾을 수 있게 하기 위해서는 모든 서버 상에서 동일한 위치를 선택해야 합니다. 참고 Analysis Services 파티션을 처리하기 위해 Parallel Processing Utility(SQL Server 2000 Resource Kit)를 사용할 경우, ProcessPartition.exe 명령줄(날짜 시간 스탬프 등)에서 로그 파일 이름을 지정할 수 있으며 이러한 로그 파일을 저장하여 문제해결을 위해 사용할 수 있습니다. 오류 리포팅Analysis Services에서 치명적인 오류가 발생될 경우 Analysis Services가 자동으로 오류 리포트를 마이크로소프트로 발송하도록 지정할 수 있습니다. 마이크로소프트는 이러한 정보를 사용하여 Analysis Services를 정정하고 모든 사용자 정보를 기밀로 관리하게 됩니다. 오류 리포팅을 수행하기 위해서는 Analysis Manager의 Analysis 서버 개체에서 마우스의 오른쪽을 클릭하고 Properties를 클릭한 다음 Error Reporting 탭을 클릭하십시오. 참고 이 옵션은 SP3에서만 제공되고 있습니다. 성능 구성 문제운영 측면에서 볼 때, 파티션 크기를 적절하게 유지하고 파티션 데이터 조각을 설정하며 모든 파티션에 적절한 집계를 정의하고 큐브 편집기(cube editor)에서 스키마 최적화 마법사(Optimize Schema Wizard)를 작동함으로써 Analysis Services 성능을 향상시킬 수 있습니다. 이러한 구성 문제에 대해 자세히 사항은 Technet 웹 사이트(http://www.microsoft.com/korea/technet/default.asp)의 "Microsoft Analysis Services 성능 안내서(Microsoft Analysis Services Performance Guide)"를 참조하십시오. 파티션 크기SQL Server 2000 Enterprise Edition(또는 SQL Server 7.0 Enterprise Edition)을 사용하고 있을 경우, 큐브를 여러 파티션으로 나눠서 쿼리 및 처리 성능을 높일 수 있습니다. 일반적으로, 파티션 파일이 5 GB나 2천만 레코드를 초과한 경우에는 파티션의 수를 늘려야 합니다. 파티션 크기가 작을수록 파티션 검색 시 읽어 들이는 데이터 양을 최소화 할 수 있기 때문에 쿼리 시간을 줄일 수 있습니다. 파티션이 여러 개이면 각 파티션이 더 작아질 뿐만 아니라 새로운 데이터의 영향을 받지 않는 파티션은 처리할 필요가 없기 때문에 총 처리 시간이 단축됩니다. 각 파티션의 크기를 결정하려면 데이터 폴더의 파티션 파일을 검토하십시오. 데이터 폴더의 각 파일 유형에 대한 자세한 사항은 본 가이드 뒷부분에 있는 부록 K "데이터 폴더 구조"를 참조하십시오. 데이터 조각큐브를 파티션으로 만들 때는 파티션 마법사(Partition Wizard)를 사용해 각 파티션에 대해 데이터 조각을 정의해야 합니다. 파티션 마법사를 사용하면 파티션을 만들 때 데이터 조각을 설정할 필요가 없습니다. 따라서, 데이터 조각 설정 없이도 파티션을 훨씬 손쉽게 만들 수 있습니다. 실제로, 파티션 마법사 페이지를 클릭해 기본값을 가져오기만 하면 데이터 조각 설정 없이도 파티션을 만들 수 있습니다. 각 Analysis Services 데이터베이스에서 각 큐브의 모든 파티션이 데이터 조각을 정의했는지 확인해야 합니다. 유일한 예외는 단 1개의 파티션 만을 가진 큐브입니다. 이 경우, 1 개의 파티션에 모든 큐브 데이터를 두고 싶다면, 데이터 조각을 설정해서는 안됩니다. 데이터 조각이 정의되어 있는지 확인하기 위해서는 분석 관리자(Analysis Manager)에서 파티션을 편집한 다음 파티션 마법사 페이지를 단계별로 실행하십시오. 부록 I "데이터 조각 설정 여부 확인을 위한 샘플 스크립트"에 나와 있는 샘플 스크립트를 사용해 Analysis Services 인스턴스의 각 다중 파티션 큐브에 데이터 조각이 설정되어 있는지 여부를 확인할 수 있습니다. 데이터 조각을 정의하면 Analysis Services가 관련 없는 파티션을 쿼리 처리에서 신속하게 제거할 수 있습니다. 데이터 조각은 각 파티션에 포함되어 있는 데이터의 실제 하위 집합(subset)을 확인합니다. Analysis Services가 각 파티션에 포함된 데이터의 범위를 모르는 경우에는 각 파티션을 쿼리해야 하기 때문에 파티션의 쿼리 성능 향상이 상당 부분이 무위로 돌아가게 됩니다. SQL Server를 이용해 유추를 이끌어 내기 위해서는 CHECK 구문 없이 분할된 뷰를 만드는 것과 마찬가지로 데이터 조각 없이 파티션을 만들어야 합니다. 쿼리 발급 시 액세스 할 쿼리를 파악하기에 충분한 메타 데이터를 제공하지 않았기 때문에 이 동안에 쿼리 최적화 프로그램이 뷰의 모든 파티션을 검색하도록 만들어야 합니다. Analysis Services의 런타임 엔진은 관계형 쿼리 최적화 프로그램(유사한 기능을 수행하는 자체 구성 요소 보유)을 사용하지 않지만, 데이터 조각을 모으는데 사용할 수 없는 경우 어떤 파티션을 검색해야 하는 지 알려주는 메타 데이터와 거의 같은 방식으로 데이터 조각을 사용합니다. 월 단위로 큐브를 파티션으로 만들고, 36개월 동안의 데이터를 보유하고 있으며(36개의 파티션에서) 데이터 조각을 지정하지 않은 경우, 런타임 엔진은 쿼리 응답을 위해 36개의 파티션 모두를 검색해야 합니다. 데이터 조각을 지정하면 1/36개의 데이터를 검색하기만 하면 되기 때문에 확실한 성능 개선을 경험할 수 있습니다. 데이터 조각을 설정하면 Analysis Services가 처리 작업 동안 소스 데이터베이스에서 데이터를 검색하는데 사용되는 SQL 문에 조인(join) 및 WHERE 구문을 추가하게 됩니다. WHERE 구문은 SQL 문이 검색하는 데이터를 데이터 조각에 속한 데이터로 제한합니다. 한 예로, 파티션의 데이터 조각이 2003년 6월 것이라고 알려주면 Analysis Services는 시간 차원(time dimension)에 조인을 추가하고 다음과 같은 WHERE 구문을 추가하거나 해당되는 모든 구성원/수준 이름을 추가합니다. WHERE <month field> = 'June' AND <year field> = '2003' 데이터 조각이 정의되지 않고 여러 개의 파티션이 존재하는 경우, Analysis Services는 소스 데이터베이스에서 검색되는 데이터를 제한하지 않습니다. 데이터 조각이 없으면 6월 파티션에 2003년 7월 데이터를 가지고 있더라도 Analysis Services가 오류 메시지를 보내지 않고 단순히2003년 7월 데이터를 두 번 계산합니다(자세한 사항은 SQL Server 온라인 설명서의 "파티션 관리"를 참조하십시오.). 시스템은 데이터 조각을 지정함으로써 이들 JOIN 및 WHERE 구문을 추가할 수 있으며, 이를 통해 데이터의 무결성을 유지하게 됩니다. DataCompressionSettings 레지스트리 설정을 변경함으로써 분석 서버 상의 모든 파티션에 대한 WHERE 구문의 자동 생성을 억제하고 이 키에 대한 기존 값에 0x00100000라는 16진 값을 추가할 수 있습니다. Analysis Services가 소스 데이터베이스에 있는 별도의 테이블에서 각 파티션에 대해 데이터를 로드하고 있는 경우에 몇 가지 성능 상의 이점을 경험할 수 있습니다. 하지만, 데이터 로드 시 관계형 데이터베이스 파티션 생성이 100% 옳게 진행된다고 확신하지 않는 한 WHERE 구문의 자동 생성을 비활성화 해서는 안됩니다. 중요 DataCompressionSettings 레지스트리 설정이 서버 차원의 설정이라는 점은 아무리 강조해도 지나치지 않습니다. 이러한 설정을 안전하게 사용하기 위해서는 서버에 있는 모든 큐브의 모든 데이터에 대해 데이터의 정확성을 100% 확신해야 합니다. 보호를 위한 WHERE 구문이 없다면, 데이터를 2회 중복(또는 여러 번) 계산이 발생할 수 있으며, 이로 인해 일관성 없는 데이터가 처리됨에 따라 서버 중지가 발생할 수 있습니다. WHERE 구문 생성을 비활성화 하면 데이터 소스와 데이터 조각 간의 데이터 무결성 보장에 대한 모든 책임은 당사자가 져야 합니다. 팁 매월 단위로 파티션을 생성하는 경우, 새로운 파티션을 생성한 다음, 각각에 대해 데이터 조각을 설정해야 합니다. 집계전체적인 쿼리 응답 능력 향상을 위해 사용할 수 있는 가장 효과적인 방법은 (Analysis Services 컴퓨터가 충분한 메모리와 하드 디스크 자원을 가지고 있다고 가정) 각 큐브 파티션에서 사실 데이터의 효과적인 집계를 설계하는 것입니다. 하지만, 너무 많은 집계는 쿼리 성능을 대폭 개선하지 못하면서도 처리 시간은 불필요하게 늘리게 됩니다. 여러 개의 파티션을 사용해서 쿼리 및 처리 성능을 높이면 집계 없이도 새로운 파티션을 배치할 수 있습니다. 다양한 집계 설계를 통한 파티션 배치는 일반적인 최적화 방법이기는 하지만, 집계 없이 파티션을 배치한다는 것은 성능 문제를 야기할 수 있는 배치 상의 오류를 의미합니다. 각 파티션에 최소한의 집계가 존재하는지 확인해야 합니다. 각 파티션에서 <partition>.agg.flex.data와 <partition>.agg.rigid.data 파일을 합한 크기를 확인함으로써 집계의 정의 여부를 신속하게 파악할 수 있습니다. 데이터 집합의 규모에 따라 분명히 차이가 있기는 하지만, 대부분의 데이터 집합에서 최소 크기는 최소한 100 KB가 되어야 합니다. 크기가 100 KB 이하인 경우에는 설계된 집계가 없거나 너무 적은 경우일 가능성이 높습니다. 팁 집계를 너무 많이 설계하면 처리 속도가 느려지고 너무 적게 설계하면 쿼리 속도가 느려집니다. 모든 파티션이 10% 정도의 최소 집계를 갖도록 해야 합니다. . 스키마 최적화큐브에서 스키마 최적화 도구를 사용하면 특정 조건이 충족될 때 차원 테이블과 팩트 테이블 간의 불필요한 조인(join)을 제거할 수 있습니다. 기본적으로, 처음으로 큐브를 생성하면 Analysis Services가 "N+1"-방향 조인(N은 차원의 수)인 팩트 테이블과 비교해 SQL 쿼리를 구성합니다. 5개의 차원을 가지고 있으면 6-방향 조인(팩트 테이블과 5개의 최저 수준 차원 테이블 간에)이 가능합니다. Analysis Services 쿼리는 이러한 조인으로부터 최저 수준 키를 추출합니다. Analysis Services는 이 키에서 집계 프로세스를 시작합니다. 6-방향 조인 구현은 최첨단 관계형 데이터베이스 시스템에서 있어서는 중요한 성능 문제가 안됩니다. 하지만, 큐브가 15개나 20개의 차원을 가지고 있으면 그 결과로 구현된 다중 테이블 조인은 심각한 성능 문제를 겪을 수 있습니다. 큐브의 차원 개수에 관계없이 관계형 데이터베이스에 대한 Analysis Services 쿼리는 훨씬 신속하게 처리되며 이러한 조인의 일부를 제거하면 처리 작업 동안 Analysis Services로의 데이터 흐름이 보다 빨라집니다. 다행히도, 이러한 상황에 큰 도움이 될 수 있는 일반적인 설계 기법이 있습니다. 수많은 별 모양(star) 또는 눈송이(snowflake) 스키마 설계가 구성되어 있기 때문에 팩트 테이블에서 최저 수준 차원 테이블로 향하는 외래 키는 난수(random number)가 아닌 구성원 키 그 자체가 될 수도 있습니다. 이 경우, Analysis Services는 "조인을 최적화" 해서 최저 수준 차원 테이블로의 조인을 사용하지 않고 팩트 테이블에서 직접 구성원 키를 가져올 수 있습니다. 한편, Analysis Services가 차원 테이블과 팩트 테이블 간의 조인을 제거하기 위해서는 아래와 같은 특정 조건이 만족되어야 합니다.
큐브에서 사용되는 차원과 관련해 이러한 조건이 만족되고 Optimize Schema 명령어를 통해 큐브의 스키마가 최적화 되어 있는 경우, Analysis Services는 큐브가 처리될 때 데이터베이스의 차원 테이블에 대한 조인을 포함하지 않은 쿼리를 구성합니다. 큐브의 모든 차원에 대해 이러한 조건이 만족된 경우, 분석 서버는 큐브 처리를 위해 팩트 테이블만 읽어야 합니다. 이러한 최적화 기법을 사용할 경우 처리 시간을 대폭 단축시킬 수 있습니다. 참고 큐브 스키마 최적화는 파티션이 개별적으로, 또는 그룹으로 처리되는지 여부에 관계 없이 큐브의 모든 파티션에 적용됩니다. 따라서, 일반적으로 큐브에 대해 스키마를 설계한 이후에는 Optimize Schema 명령어를 실행해야 합니다. 이로써 앞서 말한 조건을 만족하는 조인을 제거합니다. 그 다음에는 조인에서 어떤 차원을 제거하지 않을 것인지 결정한 다음, 조인에서 차원 테이블을 제거하기 위해 필요한 조건을 어떻게 만족할 것인지 결정해야 합니다. 큐브를 파티션으로 만들고 데이터 조각을 지정한 경우에는 데이터 조각에 사용된 차원 테이블을 제거할 수 없습니다. 이 조인은 보호를 목적으로 설정되었기 때문에 파티션에는 추가 비데이터(non-data) 조각 데이터가 포함되어 있지 않습니다. 차원을 최적화 한 경우에는 제거한 내부 조인이 소스 데이터에 문제를 야기할 수 있는 부작용을 안고 있다는 사실을 인식해야 합니다. 차원 테이블에 대한 내부 조인은 차원 테이블 레코드에 맞지 않은 팩트 테이블 레코드를 제거합니다(내부 조인이 수행하게 될 작업). 따라서, 내부 조인을 제거하고 팩트 테이블 구성원 키를 사용하기 시작하면 이전에는 확인할 수 없었던 처리 오류를 볼 수 있습니다. Analysis Services가 해당 차원 테이블에 해당하는 항목을 가지고 있지 않은 팩트 테이블의 레코드를 처리하면 오류가 발생합니다. 중요 큐브를 생성해서 큐브에 차원을 추가하거나 그 이후에 차원을 다시 추가한 경우에는 Optimize Schema 명령어를 반환해서 큐브를 다시 최적화 해야 합니다. 새로운 차원은 항상 최적화 되지 않은 상태로 추가됩니다. 적합한 서비스 팩 또는 핫픽스 수준 확인최신 서비스 팩(또는 핫픽스)을 갖춘 Analysis Services 인스턴스에서 작업을 하면 문제 해결에 도움이 될 수 있습니다. 마찬가지로, Analysis Services 클라이언트 컴퓨터에서 작업을 할 때도 최신 서비스 팩(또는 사용할 수 있는 모든 핫픽스)이 클라이언트 컴퓨터에 적용해야 합니다. 안타깝게도 Analysis Services 인스턴스나 Analysis Services 클라이언트 컴퓨터에 적용된 서비스 팩 수준(또는 핫픽스)을 신속하면서도 손쉽게 확인할 수 있는 방법은 없습니다. 모든 핫픽스를 포함해서 서비스 팩 수준을 확인하기 위해서는 서버 수준을 결정하는 4개의 파일을 검토해야 합니다.
Microsoft가 지원하는 3개의 메커니즘이나 Microsoft가 배포한 지원되지 않는 DSO/XML 스크립트 유틸리티 가운데 하나를 선택해서 Analysis Services 데이터베이스를 개발 환경에서 QA 및 제품 환경으로 이동할 수 있습니다. Microsoft 지원 메커니즘Analysis Services는 1개의 인스턴스에 Analysis Services 데이터베이스를 보관하고 다른 Analysis Services 인스턴스에 이 데이터베이스를 복원할 수 있도록 지원합니다. 또한, Analysis Services 데이터베이스에 대한 메타 데이터를 복사해서 새로운 데이터베이스에 붙여넣을 수 있도록 지원합니다. 마지막으로, 데이터 폴더 및 리포지토리를 백업해서 대상 서버에서 이를 복원할 수도 있습니다. 참고 Analysis Services 데이터베이스를 다른 서버에 배치한 이후에는 데이터 소스 연결 속성 및 리포지토리 연결 문자열을 변경해야 할 수도 있습니다. 보관 및 복원분석 관리자를 사용하거나 msmdarch.exe 명령어를 직접 사용해서 Analysis Services 데이터베이스를 보관할 수 있습니다(데이터베이스 내에 단일 큐브를 보관할 수 없습니다.). Analysis Services 데이터베이스의 보관 파일은 보관 중인 데이터베이스 폴더의 전체 콘텐트와 Analysis Services 리포지토리의 데이터베이스 및 그 개체에 대한 메타 데이터를 포함하고 있는 1개 이상의 .cab 파일로 이루어져 있습니다. 원격 파티션(거의 사용하지 않는 기능) 및 다시 쓰기 테이블의 데이터는 보관 파일에 저장되지 않습니다. 파일 기반의 백업 방식을 사용해 원격 파티션에 데이터를 백업해야 합니다. 즉, SQL Server 백업을 통해 다시 쓰기 테이블을 백업해야 합니다. .cab 파일의 최대 크기는 2 GB이고 파일은 .cab 파일을 검색할 수 없기 때문에(두 가지 모두 .cab 파일 기술의 제한이라 할 수 있지만 Analysis Services와는 관련이 없음) 데이터 폴더에 보관할 수 있는 최대 파일 크기는 2 GB가 됩니다. 단일 파일이 2 GB가 넘지 않는 경우에는 2 GB 이상의 데이터를 보관할 수 있습니다. msmdarch.exe 명령어는 여러 개의 .cab 파일을 만들게 됩니다. MOLAP 팩트 테이블을 저장하는데 사용되는 파티션 파일은 단연 최대 데이터 파일이기 때문에 파티션 크기가 주로 제약 요소가 됩니다. 따라서, 2 GB 이상의 개별 파티션 파일을 하나라도 가지고 있으면 Analysis Services 데이터베이스를 보관할 수 없습니다. SQL Server 2000의 Enterprise Edition을 사용하고 있는 경우에는 파티션 사용을 늘림으로써(즉, 보다 작은 파티션 추가) 각 파티션 파일의 크기를 2 GB 이하로 줄여서 전체 데이터베이스를 보관할 수 있습니다. (사용하고 있는 Analysis Services의 버전을 확인하기 위해서 부록 J "Analysis Services 버전 확인을 위한 샘플 스크립트"에 나오는 스크립트를 사용할 수 있습니다.) 분석 관리자나 msmdarch.exe를 직접 사용해서 보관된 데이터베이스를 Analysis Services 인스턴스에 복원하면 Analysis Services 파일 집합과 그 메타 데이터는 보관 파일이 생성되었던 당시의 상태로 반환됩니다. 원격 파티션을 가진 데이터베이스를 복원한 경우에는 원격 파티션을 처리해야 합니다. 쓰기 지원 큐브에서 데이터베이스를 복원했지만 다시 쓰기 테이블을 사용할 수 없는 경우에는 큐브를 먼저 처리해야만 사용할 수 있습니다 참고 보관 및 복원은 메타 데이터와 함께 해당 데이터를 복사하는 것이기 때문에 시간이 오래 걸릴 수 있습니다. 팁 테스트 서버에 복원하는 방법으로 백업 미디어를 정기적으로 확인하십시오. 백업 미디어 품질 확인 이외에도 정기적인 테스트를 통해 백업 및 복원 절차가 제대로 진행되고 있는지 확인하십시오. 정기적인 확인이 없는 백업은 아무런 의미가 없으며 보안에 대한 그릇된 인식을 심어줄 수 있습니다. 적어도 1달 또는 4달에 한번씩 백업 미디어를 확인해야 합니다. 복사 및 붙여 넣기분석 관리자를 사용해서 Analysis Services 데이터베이스에 대한 메타 데이터를 하나의 Analysis Services 인스턴스에서 다른 인스턴스로 복사할 수 있습니다. 이 때, 두 인스턴스는 모두 분석 관리자에 등록되어 있어야 합니다. 릴리스 관리를 위해 이러한 방법을 사용하면 메타 데이터만 대상 서버에 복사되기 때문에 대상 서버에서 Analysis Services 데이터베이스를 처리해야 합니다(필요할 경우 데이터 소스 속성을 업데이트 한 이후에). 그래야만 사용자가 새로운 위치에서 데이터를 쿼리할 수 있습니다. 복사 및 붙여 넣기는 쉽고 빠르게 수행할 수 있고 개발자 환경에서는 데이터의 하위 집합 만을 가지고 작업을 하는 경우가 많기 때문에, 복사 및 붙여 넣기를 수행하는 것이 다른 서버에 Analysis Services 데이터베이스를 배치할 수 있는 가장 빠른 방법입니다. 모든 차원, 큐브 및 파티션을 처리해야 한다는 단점이 있습니다(데이터 집합이 서로 다르면 언제든지 발생). 어떤 방식을 사용할 것인지 결정하기 위해서는 msmdarch.exe 보관 및 복원 시간에서 데이터베이스를 완전 재처리 하는데 소요되는 시간과 오버헤드를 비교해야 합니다. 대부분의 경우에 있어 완전 재처리는 가장 빠른 방법이긴 합니다. 하지만, 기반 인프라(예: 분석 서버와 소스 데이터베이스 간의 신속한 네트워크)와 기타 소스 데이터베이스(예: 다른 응용 프로그램에 의해 사용될 수 있기 때문에 80%가 이미 로드 되어 있는 상태)의 사용에 따라 달라질 수 있습니다. 파일 기반의 백업 및 복원앞의 두 가지 방법 가운데 어느 것도 상황에 적합하지 않으면, 파일 기반의 백업 프로그램을 사용해서 전체 데이터 폴더를 백업한 다음, 이를 대상 폴더에 복원할 수도 있습니다. 이 방법의 경우, Analysis Services 인스턴스 내에 단일 데이터베이스가 아닌 모든 데이터베이스를 배치해야 합니다. 이러한 방법을 사용하면 리포지토리를 백업해서 대상 서버에 복원할 수도 있습니다. OLAP 서비스 작동을 위해서는 기술적으로 리포지토리가 필요하지 않지만, 분석 관리자를 작동해서 해당 서버를 적절하게 관리해야 합니다. 리포지토리의 메타 데이터는 데이터 폴더의 콘텐트 및 구조에 맞아야 합니다. 원격 파티션(거의 사용하지 않는 기능)과 다시 쓰기 테이블에 데이터를 가지고 있는 경우에는 먼저 파일 기반의 백업 방식을 통해 원격 파티션의 데이터를, SQL Server 백업을 통해 다시 쓰기 테이블 백업한 다음, 데이터베이스를 다시 온라인 상태로 만들기 전에 이를 복원해야 합니다. DSO/XML 스크립트 유틸리티XML 파일에 저장된 정의를 사용해서 개체를 생성할 수 있는 지원되지 않는 유틸리티인 DSO/XML을 사용해서 Analysis Services 개체를 배치할 수도 있습니다. 이 유틸리티는 DSO를 사용해서 Analysis Services 인스턴스를 쿼리하고 인스턴스의 Analysis Services 개체에 대한 XML 정의를 XML 파일로 저장합니다. 이렇게 되면 DSO/XML을 통해XML 파일에서 이러한 Analysis Services 개체의 정의를 읽고 다른 Analysis Services 인스턴스에서 이를 다시 생성할 수 있습니다. 이렇게 저장된 정의를 배치하기에 앞서, 모든 텍스트 편집기를 통해 XML 파일을 편집해 개체 이름, 데이터 소스 이름, 연결 문자열 등 Analysis Services 개체의 정의를 변경할 수 있습니다. Microsoft는 관리 응용 프로그램으로 직접 기능을 포함시킬 수 있도록 이 유틸리티에 소스 코드를 제공합니다. DSO/XML을 다운로드 하거나 자세한 내용을 보고 싶으면 http://go.microsoft.com/fwlink/?LinkId=21979을 클릭하십시오. 참고 DSO/XML은 개체 정의를 배치만 합니다. 데이터 소스에서 실제 데이터를 로드하기 위해서는 개체를 처리해야 합니다.
변경 관리는 새로운 오류 발생을 피하고 서비스 수준에서 그로 인한 피해를 최소화 할 수 있도록 테스트를 거친 방법 및 기술의 도움을 받아 변경을 관리하는 것을 말합니다. 변경을 수행할 때는 DSO(Decision Support Objects)를 가진 Microsoft VBScript(Visual Basic Scripting Edition)를 사용함으로써 변경 수행 시 작업자 실수가 발생할 가능성을 최소화 해야 합니다. 차선의 방법으로는 DTS Analysis Services 처리 작업이 있습니다. 이 두 가지 방법 가운데 어떤 것도 사용할 수 없는 경우에는, 분석 관리자를 사용해서 수동으로 변경을 수행할 수 있습니다. 변경 내용이 제품 환경에 구현되기 위해서는 개발 환경과 QA 환경에서 차례로 테스트를 거쳐야 합니다. 각 변경 내용은 업데이트 된 상태를 유지할 수 있도록 런 북(run book)에 문서화 되어 있습니다. 중요 변경 관리 부족의 가장 큰 원인은 오류 및 서비스 중단입니다. 스크립트와 DTS 패키지를 사용해서 변경을 수행하면 버전 관리를 위해 Microsoft Visual SourceSafe 같은 소스 코드 제어 솔루션을 채용할 수 있습니다. 소스 코드 제어 솔루션은 필요할 경우 이전 버전의 스크립트나 패키지를 검색하고 손쉬운 팀 개발을 지원할 수 있도록 합니다. 많은 Analysis Services 시스템이 여러 사람이 Analysis Services 데이터베이스를 관리할 수 있는 권한을 가지도록 하고 있습니다. 모든 관리자가 Analysis Services 내에서 모든 작업을 수행하고 모든 개체를 변경할 수 있기 때문에, 언제 Analysis Services 개체가 변경되었는지 추적하는 것이 유용할 수 있습니다. Microsoft는 이러한 정보를 얻기 위한 직접적인 방법을 제공하지는 않지만, Analysis Services 리포지토리를 SQL Server로 마이그레이션 하면 리포지토리 데이터베이스에 대한 트리거를 추가해 Analysis Services 개체에 대한 메타 데이터가 언제 변경되었는지 알아내고 감사 테이블이 변경되기 전에 모든 개체의 값을 얻을 수 있습니다. 부록 E "리포지토리 감사 트리거를 만들기 위한 샘플 스크립트"에 나와 있는 샘플 스크립트는 이러한 리포지토리 감사 트리거를 어떻게 만들 수 있는지 보여줍니다. 참고 일부 클라이언트 도구는 자체 메타 데이터를 캐시합니다. 이 경우, Analysis Services의 메타 데이터(수준의 고유한 값 같은)를 변경하면 클라이언트 도구에 변경이 이루어졌으며 캐시된 메타 데이터를 업데이트해야 한다는 것을 통지해야 하 수도 있습니다. 팁 변경을 위해(또는 일부 유지 보수를 위해) 큐브를 신속하게 오프라인으로 전환하기를 원하는 경우에는 가상 큐브를 사용할 수 있습니다. 클라이언트를 가상 큐브에 연결한 다음, 변경 수행을 위해 액세스를 일시 중단하고 싶을 때 가상 큐브의 연결을 끊을 수 있습니다. 그 다음, 사용자가 큐브에 다시 액세스 할 수 있는 상태가 되면, 가상 큐브를 신속하게 재성성 할 수 있습니다.
Analysis Services 관리자의 주된 임무 가운데 하나는 Analysis Services를 통해 노출되는 데이터를 보호하는 것입니다. 관리자냐, 최종 사용자냐에 관계없이 모든 사용자는 Microsoft Windows 운영 체제의 인증을 받아야만 Analysis Services 개체에 액세스 할 수 있습니다. 사용자들은 직접, 또는 Microsoft IIS(Internet Information Services)를 통해 인증을 받을 수 있습니다. 관리자 보안Analysis Services가 설치되면 설정 프로그램이 Analysis Services 컴퓨터에 OLAP 관리자 로컬 그룹을 만들고 이 그룹에 Analysis Services를 설치하는 사람의 사용자 계정을 추가합니다. 로컬 관리자 그룹의 모든 구성원은 OLAP 관리자 그룹에 명시적으로 추가되었느냐 여부에 관계없이 자동으로 OLAP 관리자 그룹의 구성원이 됩니다. OLAP 관리자 그룹은 Analysis Services 컴퓨터에 대해 아래와 같은 권한을 허가 받습니다.
따라서, OLAP 관리자 로컬 그룹의 구성원은 분석 관리자를 통해서나 DSO에서 프로그래밍 방식으로 Analysis Services 관리 기능을 액세스 할 수 있습니다. 보다 자세한 내용은 기술 자료(support.microsoft.com)의 "INF: OLAP 서버를 관리해야 하는 권한" 기사를 참조하십시오. Analysis Services에 대한 관리 액세스는 단일 수준에서 이루어집니다. OLAP 관리자 그룹의 구성원은 Analysis Services 개체에 대한 모든 관리 액세스 권한과 모든 큐브 및 차원에 대한 모든 읽기 액세스 권한, 그리고 모든 쓰기 지원 큐브 및 차원에 대한 모든 쓰기 액세스 권한을 가집니다(모든 반대되는 역할 정의에 무관하게). OLAP 관리자 그룹의 구성원이 아닌 도메인 또는 로컬 사용자는 관리 작업을 수행할 수 없으며, 차원 수준이나 셀 수준 보안을 기반으로 허용된 범위에 대해 읽기 또는 쓰기 액세스 권한을 가집니다. 참고 OLE DB 공급자(provider)에게 MDX 쿼리를 발급함으로써 OLAP 분석을 수행하는 클라이언트는 Analysis Services 컴퓨터의 레지스트리를 읽을 수 없으며 MsOLAPRepository$ hidden share에 대한 권한을 요구하지 않습니다. 최종 사용자 보안Analysis Services에서의 최종 사용자 보안은 Windows 사용자 계정 및 그룹을 기반으로 이루어집니다. Analysis Services에서 최종 사용자 보안을 구성하기 앞서 먼저 Active Directory 내에서 사용자 계정 및 그룹을 만들어야 합니다. 자주 듣는 질문의 하나가 바로 "Analysis Services가 다른 유형의 인증을 지원하는가?" 입니다. "예"와 "아니오" 모두가 대답이 될 수 있습니다. HTTP 액세스 및 IIS(IIS 6.0은 일부 새로운 인증 옵션을 포함)를 통해 다른 유형을 지원할 수 있기 때문에 "예"가 대답이 될 수 있습니다. 하지만, 이러한 모든 인증 유형은 궁극적으로 도메인 계정, 로컬 계정, 퀘스트 계정(사용 가능한 경우) 또는 기본으로 제공되는 NT AUTHORITY\ANONYMOUS LOGON 계정 등을 포함한Windows 사용자 계정에 매핑되어야 합니다. 따라서, Analysis Services가 SQL 기본 보안이나 인증이 Windows 사용자 계정을 기반으로 하지 않는 모든 유사 기술을 지원할 수 없다는 점에서는 "아니오"가 대답이 될 수도 있습니다. 인증을 위해 Analysis Services는 SSPI(Security Support Provider Interface)를 응용 프로그램 보안을 위한 인터페이스로 사용하고 있습니다. 연결 문자열(SQL Server 온라인 설명서의 "직접 연결에 대한 인증" 참조)로 Analysis Services에 쿼리를 발급할 때 아래와 같은 SSPI 옵션 가운데 하나를 지정할 수 있습니다.
보안 역할해당되는 Windows 사용자 및 그룹 계정을 만든 후에는 Windows 사용자 및 그룹 계정을 포함하고 있는 Analysis Services 내 보안 역할을 만들고, 각 역할이 Analysis Services 데이터에 대해 가지는 액세스 권한을 정의하십시오. 데이터베이스 역할, 큐브 역할 및 마이닝 모델 역할을 사용할 수 있습니다.
참고 도메인 사용자나 그룹은 Analysis Services 내의 여러 역할의 구성원이 될 수 있습니다. 이 경우, 이러한 역할에 지정된 액세스 특성의 조합이 사용자의 유효 권한이 됩니다. 차원, 셀 또는 응용 프로그램 수준의 보안차원 수준 보안을 사용해서 확인 또는 업데이트가 가능한 차원 구성원을 제한할 경우, Analysis Services는 사용자 접속 시, 메모리에 복제 차원을 만들어야 하며, 이는 자신이 볼 수 있도록 허용된 차원 구성원을 반영하고 있습니다. 한 예로, 최상위 수준에서 북미, 유럽, 아시아, 기타 국가 등 4개의 지역을 가진 계정 차원을 가지고 있다고 생각해 보십시오. 4개의 역할을 만들면 각 사용자에게 4개 역할 가운데 하나를 할당함으로써 사용자가 볼 수 있는 계정을 지정할 수 있습니다(총 16개의 역할 조합).
수많은 사용자가 재사용 할 수 있는 기본 역할을 만듦으로써 Analysis Services가 메모리에 저장된 복제 차원을 재사용 하도록 할 수 있습니다. 하지만, 사용자가 자신이 액세스 권한을 가지고 있는 차원 구성원을 서로 다르게 조합해서 큐브를 액세스 할 때 마다 Analysis Services는 메모리에 새로운 복제 차원을 만들게 됩니다(위의 예에서는 최고 15개의 복제 차원 생성). 복제는 Analysis Services가 다시 시작되거나, 기본 차원이 처리(전체 또는 단계적으로)될 때까지 메모리에 남아 있습니다. 메모리에서 복제 차원을 언로드(unload) 할 수 있는 방법은 없습니다. 셀 수준 보안은 차원 보안에 대한 대안입니다. 셀 수준 보안을 사용할 경우, 최종 사용자는 모든 차원 구성원을 볼 수 있습니다. 위의 예에서는 모든 계정을 볼 수 있습니다. 하지만, 보호되는 셀도 있습니다(사용자가 해당 셀에 대한 액세스 권한을 가진 어떠한 역할의 구성원도 아닌 경우). 별도의 차원 복사(복제 차원)가 필요하지 않다는 점에서 셀 수준 보안은 이러한 메모리 오버헤드가 없습니다. 셀 수준 보안은 메모리 사용 측면에서 이점이 있는 반면, 차원 수준 보안은 전체 성능을 향상시킵니다. 셀 수준 보안 식은 쿼리 시 모든 셀에 대해 평가되지만 캐시 되지는 않습니다. MDX 식이 신속하게 실행될 수 있으면 성능이 향상됩니다. 아래 예에서 MDX 식은 단순히 현재 구성원과 상수("유럽"의 고객만)를 비교합니다. IIF(Ancestor(Customers.CurrentMember, Region).Name = "EUROPE", 1, 0) 분명한 사실은 식이 복잡하고 수많은 처리 작업이 연관되어 있을수록 셀 수준 보안은 성능이 저하되고 수많은 클라이언트 자원을 사용하게 된다는 것입니다. 셀 수준 보안 식은 쿼리 시 모든 셀에 대해 평가되지만 캐시 되지는 않습니다. 보다 포괄적인 일대일 보안 요구 사항에 대해서는 MDX 문의 UserName 기능을 통해 보안 설정을 하는 등 동적 보안을 사용하십시오. 동적 보안을 사용하면 최종 사용자에게 단일 역할을 할당할 수 있습니다. 이는 UserName 기능을 사용해서 '사용자 이름 대 사용자 이름' 기준으로 사용자가 볼 수 있는 구성원을 확인할 수 있는 역할입니다. 하지만, 모든 사용자 이름이 서로 다른 구성원 집합을 가지고 있는 경우에는 동적 보안을 위해 엄청난 양의 복제가 필요할 수 있습니다. 차원 보안(기본 역할 기반 보안 및 동적 보안 모두)은 항상 서버 상에서 이루어지며 클라이언트에게는 완전 투명하게 진행됩니다. 셀 수준 보안은 항상 클라이언트 시스템 상에서 이루어집니다. 실제로는 기본 역할 기반의 차원 보안과 셀 수준 보안, 동적 차원 보안 등 서로 다른 역할 기법을 조합해서 사용해야 합니다. 요구 사항이 간단한 경우에는 셀 수준 보안을 사용하십시오. 메모리 오버헤드를 최소화 할 수 있습니다. 하지만, 차원 구성원의 노출을 보안 위반으로 보기 때문에 많은 영역에서 셀 수준 보안을 사용할 수 없습니다. 한 예로, 귀사가 아시아의 특정 고객을 보유하고 있다는 사실을 안다는 것은 해당 고객을 담당하는 영업팀(또는 셀)이 누구든 관계 없이 기밀 정보로 간주될 수 있습니다. 이 때는 차원 수준 보안을 사용해야 합니다. 이 경우, 최소한의 고정 역할 만으로 차원 수준 보안의 오버헤드를 줄일 수 있습니다. 역할을 설계할 때는 가능한 구성원의 중복을 최소화 할 수 있도록 구성원을 그룹화 하십시오. 사용자를 단 하나의 역할로 제한하십시오. 이러한 지시 사항을 모두 따르면(가능한 철저하게) 복제의 전체 통합 크기는 기본 차원 크기의 2배가 됩니다. 실제로 사용자 이름에 따라 구성원 별 제어가 필요한 사용자의 하위 집합에서는 동적 보안 만 사용하십시오. 보다 철저한 제어를 위해 응용 프로그램 수준의 보안을 사용할 수 있습니다. 한 예로, 3-계층 웹 기반 응용 프로그램을 구현하고 있다고 가정해 보겠습니다. 모든 데이터 액세스는 중간 계층 응용 프로그램으로 들어가기 때문에 Analysis Services가 직접 지원하는 것 보다 광범위한 비즈니스 규칙을 추가할 수 있습니다. 월 단위로 지정된 일자 동안 특정 유형의 작업 만을 허용하도록 선택할 수도 있습니다. 또는, 최종 사용자가 형식 기반 인증 데이터베이스, LDAP(Lightweight Directory Access Protocol) 서버, 기타 외부 업체 도구 등 다른 일부 보안 시스템에서 자격 증명을 가지고 있는 경우 특정 유형의 데이터 액세스 만을 허용하도록 선택할 수 있습니다. 일반적으로 이러한 유형의 응용 프로그램 수준 보안은 자체적으로 응용 프로그램을 작성하고 있는 경우에 한해 사용할 수 있습니다. 하지만, 일부 타사 OLAP 도구는 자체 보안 시스템도 제공합니다. 한 예로, Panorama의 Software's Novaview(웹 사이트 http://www.panoramasoftware.com 도메인 구조 문제Analysis Services 연결에 앞서 사용자가 인증을 받아야 하기 때문에 일반적으로 Analysis Services 컴퓨터와 클라이언트 간의 공통 도메인 구조가 필요합니다. 하지만, 공통 도메인 구조를 가지고 있지 않은 경우에는 몇 가지 옵션을 통해 이러한 제약을 극복할 수 있습니다.
Analysis Services 관리자는 최종 사용자가 항상 Analysis Services와 데이터를 검색할 수 있도록 가용성을 보장해야 하는 책임이 있습니다. 가용성 요구 수준(용인할 수 있는 고장 시간)은 Analysis Services 큐브의 데이터를 사용할 수 없을 경우, 비즈니스에 미치게 되는 영향 정도에 따라 결정됩니다. 필요한 가용성 수준은 일반적으로 SLA(service level agreement)에 정의되며, 합의된 가용성 수준을 보장하기 위해 반드시 포함되어야 할 요소들을 결정하게 됩니다. 합의된 가용성 수준을 보장하기 위해서는, 반드시 가용성 계획을 수립해야 합니다. 가용성 계획을 수립할 때, 시스템 전반에 걸친 총체적인 접근 방식을 취해야 하며 Analysis Services를 전체 IT 인프라를 구성하는 일부분으로 간주해야 합니다. 또한, 컴퓨터의 하드웨어 컴포넌트, 컴퓨터에 필요한 모든 소프트웨어, Analysis Services 설치를 지원하는 Microsoft Active Directory 인프라는 물론 필요한 인력을 고려해야 합니다. 뿐만 아니라, 사용자 이름 및 암호와 같은 임시 정보는 물론 CD 키, 배포 지점 및 최초 설치 미디어와 같은 제품 설치 정보도 함께 고려해야 합니다. 가용성 계획에 추가할 적절한 Analysis Services 컴포넌트를 결정할 때, 다음 사항을 평가해야 합니다.
이들 요소를 각각 검토함으로써, 필요한 가용성 수준을 달성할 수 있는 방법을 규명해야 합니다. 가용성 계획의 요소를 규명한 다음, 계획의 각 요소를 테스트함으로써, 예상된 및 예기치 못한 가용성 위협에도 효과적이고 효율적으로 계획을 수행해 가용성 목표를 달성할 수 있도록 해야 합니다. 어떠한 비상 사태도 해결할 수 있도록 만반의 준비를 갖춘 숙련된 직원 역시 모든 장애 복구 계획에 있어서 핵심 구성 요소입니다. 서비스 연속성Analysis Services의 실행이 중단되는 사태를 감지할 수 있는 방법을 마련함으로써, 사용자가 문제를 감지하기 전에 서비스 중단에 신속하게 대처할 수 있도록 해야 합니다. 자체 고유의 감지 메커니즘을 개발하고자 할 경우, 다음의 3가지 옵션 중 1개 이상을 사용해 Analysis Services가 실행되고 있는지 여부를 판단할 수 있습니다.
또한, NetIQ (http://www.netiq.com 서비스 관리가용성 계획의 다음 단계로서, SLA(service level agreement)에 가용성을 어떻게 정의할 것인지를 고려해야 합니다. 예를 들어, 재구성으로 인해 차원이 처리 중일 때에는 쿼리 수행을 위해 Analysis Services를 사용하지 못할 수 있습니다. 이러한 경우 서비스 중단으로 간주해야 할까요? Analysis Services와 관련된 고유한 서비스 문제는 다음을 포함합니다.
그 외 '이와 같은 사용자 변경에 의해 발생하는 가용성 문제를 SLA가 어떻게 처리할 것인가?', '이와 같은 상황으로 인해 발생한 가용성 문제 해결을 위해 하루 24시간 지속적인 솔루션이 반드시 필요한 시점은 언제인가?' 등을 고려해야 합니다. 지속적인 솔루션에 대한 자세한 정보는, 본 가이드 후반부의 "지속적인 Analysis Services 솔루션 구현"를 참조하십시오. 백업 및 복구가용성 계획의 다른 구성 요소와 관계 없이, 정기적인 백업은 가용성 계획의 핵심 구성 요소입니다. 또한, 필요할 경우, 이들 백업을 신속하게 복원할 수 있도록 보장해야 합니다. Analysis Services 데이터를 복구하기 전에, Analysis Services가 그 어떠한 차원, 파티션 또는 마이닝 모델도 처리해서는 안됩니다. Analysis Services가 일부 처리 작업을 백그라운드 프로세스로 수행하기 때문에, 때로 모든 처리가 언제 완료됐는지를 파악하는 것이 어려울 수도 있습니다. 또한, 백업을 수행하고 있는 동안, 다른 관리자가 어떠한 메타 데이터도 변경하지 않도록 해야 합니다. Analysis Services가 중지 상태가 되도록 보장할 수 있는 한가지 방법은 백업을 수행하기 전에 Analysis Services를 중단하는 것입니다. 부록 H, "지연(lazy) 처리의 완료 시기를 확인하기 위한 샘플 스크립트"에서 제공되는 샘플 스크립트를 사용해 모든 백그라운드 처리가 완료되는 시점을 파악할 수 있습니다. 백업 옵션Analysis Services는 Analysis Services 데이터베이스를 백업하기 위한 2가지 기술, 즉 아카이빙 및 파일 복사 기술을 제공합니다. 아카이빙Analysis Manager 내에서 또는 명령어 프롬프트에서, msmdarch 명령어(msmdarch.exe)를 사용해 Analysis Services 데이터베이스 및 리포지토리를 1개 이상의 .cab 파일에 아카이빙할 수 있습니다. Msmdarch는 .cab 리포지토리 알고리즘을 사용해 모든 단일 .cab 파일의 크기를 2GB로 제한합니다. 따라서, 데이터 폴더에 있는 모든 개별 파일들(모든 단일 파티션 등)은 2GB를 초과할 수 없으며, 그렇지 않을 경우, msmdarch은 백업에 사용할 수 없습니다. Msmdarch를 사용할 경우, 항상 로그 파일 위치를 지정해 아카이브 프로세스 동안 생성되는 모든 메시지를 캡처할 수 있도록 해야 합니다. 아카이브 프로세스가 실패할 경우, 이들 메시지를 통해 아키이브 프로세스가 실패한 이유를 규명할 수 있게 됩니다. 그러나, msmdarch는 쿼리 로그를 백업하지 않기 때문에, 쿼리 로그를 백업하려면, MSMDQLOG.mdb 파일에 대한 파일 기반 백업을 수행해야 합니다. 그렇지 않을 경우, 복원된 인스턴스를 시작할 때 새로운 쿼리 로그를 처음부터 만들어야 합니다. 파일 복사msmdarch를 사용할 수 없을 경우, Windows Backup과 같은 파일 복사 프로그램을 사용해 데이터 폴더의 모든 파일을 벡업할 수 있습니다. 파일 복사 백업을 통해, 서버의 모든 데이터베이스를 백업합니다. msmdarch를 사용해 단일 Analysis Services 데이터베이스를 백업할 수 있습니다. 한편, 파일 복사 기술은 리포지토리 또는 로그 파일을 백업하지 않습니다. 파일 복사 기술을 사용할 경우, 데이터 폴더를 백업함과 동시에 리포지토리를 백업함으로써, 리포지토리와 데이터 폴더 데이터가 동기화될 수 있도록 해야 합니다. 또한, 쿼리 로그를 백업하거나(MSMDQLOG.mdb 파일) 또는 처음부터 쿼리 정보를 캡처하기 시작해야 합니다. 단순히 개별 데이터베이스 만을 백업하는 것이 가능하지만(데이터 하위폴더의 내용물과 .DBO 파일을 복사함으로써), 리포지토리의 개별 부분을 백업하는 것은 불가능합니다. 전체 복구 시 또는 마지막 백업 이후 메타 데이터가 변경되었을 경우, 리포지토리가 필요합니다. 따라서, Microsoft는 파일 복사 기술을 사용할 경우, 전체 데이터 폴더를 백업하는 동시에 모든 데이터베이스를 백업할 것을 권장합니다. SAN(Storage Area Network)를 보유하고 있는 경우, 다음의 조치를 수행함으로써, 쿼리에 사용될 데이터의 가용성을 극대화하는 동시에 백업할 수 있는 쿼리 로그, 리포지토리 및 데이터 폴더의 오프라인 이미지를 만들 수 있습니다.
그 다음, 미러 이미지를 별도의 드라이브로 마운트한 다음, 일관성에 대한 걱정 없이 거기에서 파일 레벨 백업을 수행할 수 있습니다. 참고 EMC는 이와 같은 오프라인 이미지를 Business Continuance Volume (BCV)라는 용어로 사용합니다. 복구 옵션복구는 전부 아니면 무(all-or-nothing) 프로세스이며, 본질적으로 많은 위험성이 수반되는 작업입니다. 따라서, 실제 위기 시에 그와 같은 복구를 성공적으로 수행할 수 있기 위해서는, 사전에 테스트나 QA 환경에서 철저하게 테스트를 수행하고 만반의 준비를 갖추어야 합니다. 훈련이 부족하거나 사전 준비가 미진할 경우, 문제가 더욱 복잡해지고 장기화 될 수 있습니다.
이 2가지 백업 방법을 사용할 경우, 쿼리 로그 파일을 백업 버전으로 대체해야 합니다. 참고 msmdarch 명령을 사용하는지 또는 파일 복사 기술을 사용하는지에 관계 없이, 백업 이후 역할에 배정된 사용자 이름이 변경되었을 경우 보안 매핑과 관련된 문제가 발생할 수 있습니다. 지속적인 Analysis Services 솔루션 구현가용성 계획에서 사용자가 하루 24시간 지속적으로 큐브 및 차원 쿼리를 수행할 수 있는 능력을 요구 조건으로 할 경우, 다음과 같은 많은 문제를 반드시 해결해야 합니다.
Microsoft는 지속적인 Analysis Services 솔루션을 구현할 때 이러한 목표를 달성할 수 있도록 돕는 MSCS(Microsoft Cluster Services) 및 NLB(Network Load Balancing) 기술을 제공합니다. 다음에서 설명하겠지만, 이들 기술은 Analysis Services 컴퓨터를 위한 서로 다른 종류의 가용성을 제공합니다. MSCS(Microsoft Cluster Services)MSCS(Microsoft Cluster Services)는 하드웨어 및 소프트웨어 오류 시 Analysis Services 설치를 보호할 수 있도록 합니다. MSCS를 사용해, 데이터 폴더, 리포지토리 및 쿼리 로그를 담고있는 공유 파일 리포지토리 서브시스템(일부 RAID 버전과 함께)으로 구성된 클러스터의 2개 노드에 Analysis Services를 설치하십시오. 클러스터에서 오직 1개의 노드 만이 항상 활성 상태입니다. 활성 노드에 오류가 발생하면, MSCS는 수동 노드로의 장애 조치(fail over)를 수행하고 해당 노드에서 Analysis Services를 시작합니다. 장애 조치용 노드에서 Analysis Services는 공유 파일 리포지토리 시스템에 위치한 데이터 폴더, 리포지토리 및 쿼리 로그를 사용합니다. 이 클러스터링 솔루션은 어떤 이유로 인해 클러스터의 주 서버에 오류가 발생할 경우, Analysis Services를 쿼리를 위해 사용할 수 있도록 보장합니다. 그러나, MSCS는 지속적인 쿼리 솔루션을 제공하진 않기 때문에, 여전히 처리로 인한 시스템 고장 문제에 직면할 수 있습니다. 뿐만 아니라, MSCS는 로드 균형 조정 기능을 전혀 제공하지 않기 때문에, 수동 노드의 자원은 오직 장애 조치 동안에만 사용되게 됩니다. MSCS는 특수 하드웨어를 요구하지만, 대부분의 데이터 센터 운영 직원에게 익숙한 입증된 기술입니다. 보다 자세한 정보는, Knowledge Base (support.microsoft.com) 및 기사 "HOW TO: Cluster SQL Server 2000 Analysis Services in Windows 2000"를 참조하십시오. NLB(Network Load Balancing)Analysis Services 설치를 보호할 수 있도록 합니다. 또한 다중 서버에 걸쳐 쿼리를 로드 균형 조정하고 지속적인 쿼리 가용 솔루션을 제공합니다. NLB를 사용해, 별도 컴퓨터에 Analysis Services의 여러 인스턴스를 설치한 다음, 각 인스턴스가 데이터 폴더와 동일한 복사본과 리포지토리를 포함하도록 하십시오. 그리고 각 인스턴스는 별도의 쿼리 로그를 보유하고 있어야 합니다. NLB 서비스는 쿼리 요청을 NLB 클러스터 내 Analysis Services 인스턴스 전반에 걸쳐 자동으로 로드 균형을 조정합니다. 이들 서버 중 하나에 오류가 발생하면, NLB는 오류를 탐지하고, 실행되고 있는 서버로 사용자 쿼리를 라우팅합니다. 더욱 빠른 응답 시간으로 더욱 많은 사용자를 지원하고자 할 경우, 더 많은 서버를 추가하면 로드를 분산시키고 가용성을 향상시킬 수 있습니다. NLB를 이용해 지속적인 쿼리 기능을 실현하려면, 다음 단계를 수행해야 합니다.
NLB는 특수 하드웨어를 요구하지 않지만, NLB 클러스터 구성을 위해선 네트워크 전문 지식(예, TCP/IP 구성 문제)을 요구합니다. 보다 자세한 정보는 Microsoft Technet 웹 사이트(http://www.microsoft.com/korea/technet/default.asp) 및 "Creating Large-Scale, Highly Available OLAP Sites: A Step-by-Step Guide."를 참조하십시오. 장애 복구 문제가용성 솔루션에는 반드시 장애 복구 계획이 포함되어 있어야 합니다. 이 계획은 장애가 발생할 경우 근무 중인 직원이 필요로 하는 모든 정보를 제공함으로써, 예상할 수 있는 모든 비상 사태를 해결할 수 있도록 해야 합니다. 운영 담당 직원이 각 장애 유형에 대해 어떻게 대처해야 하는지 그리고 어떠한 조치를 취해야 하는지는 물론, IT 시스템의 다른 부분을 담당하고 있는 지원 직원의 연락처 정보를 제공해야 합니다. 예를 들어, 다음과 같은 사항을 해결해야 합니다.
Analysis Services 관리자는 Analysis Services가 어떻게 메모리, 디스크, 프로세서 및 네트워크 자원을 사용하는지를 파악해야 합니다. 시간이 지남에 따라, Analysis Services의 자원 사용이 변동될 수 있으며, 이는 추가 자원 또는 기존 자원의 재구성의 필요성을 예측하기 위해서는 시간 경과에 따른 시스템의 자원 사용을 지속적으로 기록해야 한다는 것을 의미합니다. 메모리Analysis Services는 Windows 운영 체제를 사용해 가상 메모리 주소를 물리적 메모리에 매핑함으로써, 필요에 따라 가상 메모리 주소 공간을 사용합니다. Analysis Services는 시작할 때 메모리를 사용해 모든 MOLAP 차원 구성원을 메모리에 로드합니다. 그 이후, 모든 남아있는 메모리 사용은 쿼리 용량, 메모리 내 복제 차원의 수, 처리를 위해 필요한 메모리 용량에 따라서 변동되게 됩니다. 시간이 지나면서, 차원 증가, 공유 차원을 재사용하는 새로운 데이터베이스, 메모리에 저장되는 복제 차원의 수 증가로 인해 메모리 사용이 증가할 수 있습니다. 본 섹션은 메모리 용량 문제를 설명하고 있습니다. 메모리 구성에 대한 설명은 본 백서의 앞 부분에 있는 "메모리 설정"을 참조하십시오. 차원에 의한 메모리 사용Analysis Services는 시작할 때 Analysis 서버 상의 모든 데이터베이스에 대한 모든 MOLAP 차원 구성원과 함께 이들 구성원의 모든 속성을 메모리에 로드함으로써, 쿼리 응답성을 향상시킵니다. 기본적으로, MOLAP, HOLAP 및 ROLAP 큐브는 MOLAP 차원을 담고 있습니다. ROLAP 큐브를 만들고 ROLAP 차원을 지정할 경우, 이들 차원은 메모리에 로드되지 않습니다. 새로운 차원 및 차원 구성원이 생성되면 메모리에 추가됩니다. 메모리 내 기존 차원에 의해 사용되는 메모리 양은 오직 차원 처리 동안에만 조정됩니다. 이는 대형 MOLAP 차원이 Analysis 서버의 가상 메모리를 많이 사용함으로써, 다른 작업을 위해 남아 있는 주소 공간이 줄어들 수 있다는 것을 의미합니다. 차원 메모리가 필요로 하는 메모리 양은 시간이 지남 에 따라 새로운 차원과 차원 구성원이 Analysis Services 인스턴스의 큐브에 추가됨에 따라 증가하는 경향이 있습니다.각 차원을 저장하기 위해 필요한 예상 메모리 공간은 파일 시스템의 차원 구조를 저장하고 있는 파일의 크기를 통해 알 수 있습니다. 공유 차원의 경우, 이 차원 구조 정보는 .dim, .dimcr, .dimprop 및 .dimtree 등 4가지 유형의 파일에 저장됩니다. 이 파일들은 Analysis Services 데이터 폴더에 저장되어 있는 큐브용 데이터베이스 폴더에서 발견할 수 있습니다. 차원 메모리를 위해 필요한 메모리 양은 이 파일들의 크기 합계와 거의 동일합니다. 이들 파일 유형에 대한 보다 자세한 정보는 부록 K: "데이터 폴더 구조"를 참조하십시오. 하드웨어 구매 계획 등과 같이, 차원을 정의하기 전에 필요한 공간을 예상하고자 할 경우, 다음의 공식을 이용해 대략의 공간을 계산할 수 있습니다. DimSize = CMembers*(61 + 4*CLevels + Size(name) + Size(key)) + 4*CProps + Size(props) 조건: CMembers 차원의 구성원 총 수 CLevels All 레벨을 포함해, 차원의 레벨 수 Size(name) 구성원 이름을 저장하는데 필요한 평균 크기. 예를 들어, 10개 문자열을 유니코드로 저장하기 위해서는 20 byte가 요구됨. Size(key) 구성원 키를 저장하는데 필요한 크기. 예: 1개의 정수 키는 4 byte가 요구됨. 구성원 이름이 구성원 키와 동일할 경우, Size(key)는 0 입니다. CProps 모든 레벨에 대한 차원의 구성원 속성 설정 수. 예를 들어, 1천 개의 구성원을 가진 레벨이 각 구성원마다 2개의 속성을 가지고 있을 경우, 이 레벨에 대한 속성 설정 수는 200개입니다. 구성원 속성 설정을 사용해 어떤 구성원 속성 값이 구성원에 의해 참조되는지를 식별할 수 있습니다. Size(props) 모든 구성원 레벨에 대해 다른 구성원 속성 값을 저장하기 위해 필요한 크기. 구성원 속성은 유니코드로 저장되며, 각 고유한 문자열은 오직 한번만 저장된다는 사실을 명심하십시오. 예를 들어, 참조 횟수에 관계 없이, Male, Female 및 Unknown의 가능한 값을 가진 고객 성 속성의 경우, 오직 34 byte의 저장 공간(유니코드 저장을 위해 17개 문자 x 2)만을 요구합니다. 참조 64 비트 Analysis Services 버전의 경우, 정수가 8 byte이기 때문에(32 비트 시스템에서의 4 byte 대신), 위 공식은 Analysis Services는 차원 메모리에 필요한 메모리 양 만큼이나 많은 메모리를 사용합니다. 불필요한 차원, 레벨 및 구성원 속성을 제거함으로써, 차원 메모리로 사용되는 메모리 양을 제어할 수 있습니다. 뿐만 아니라, Analysis Services가 시작될 때 Analysis 서버의 모든 큐브에 있는 모든 차원 정보가 메모리에 로드되기 때문에, 불필요한 테스트 큐브와 Analysis 서버의 모든 데이터베이스에서 사용되지 않는 차원을 제거함으로써 메모리를 절약할 수 있습니다. Analysis Services는 자체 가상 메모리 주소 공간을 가진 별도의 프로세스 공간의 초대용량 차원을 로드함으로써, 대용량 차원이 모든 가용 가상 메모리 주소 공간을 사용하는 것을 방지하게 됩니다. 초대용량 차원은 레지스트리의 VLDMThreshold 값을 초과합니다. 기본 VLDM 임계값은 64 megabytes (MB)입니다. VLDM 임계값을 초과하는 차원을 위해 별도의 주소 공간을 사용하면, 다른 주 프로세스가 사용할 수 있도록 가상 메모리 주소 공간을 절약할 수 있게 되지만, 1개 이상의 차원이 VLDM 임계값을 초과할 경우 전체적인 성능이 저하됩니다. 가상 메모리 주소 공간이 충분할 경우, VLDMThreshold 값을 늘려야 합니다. SQL Server 2000 (64-bit)는 3 gigabyte (GB) 가상 주소 한계가 없기 때문에, 이 버전에서 Analysis Services는 VLDM 임계값을 사용하지 않습니다. VLDM에 대한 보다 자세한 정보는, 본 가이드 앞부분의 "VLDM(Very Large Dimension Memory) 임계값"을 참조하십시오. 쿼리 결과 캐시Analysis Services는 쿼리 결과 캐시의 클라이언트 쿼리가 반환한 (그러나 계산된 데이터는 아님) 데이터를 저장합니다. 클리너 스레드(cleaner thread)는 Analysis Services 프로세스가 사용한 메모리가 메모리 보존 임계값 (Memory conservation threshold) 및 최소 할당 메모리 (Minimum allocated memory) 설정 값의 중간 지점을 초과할 경우, 쿼리 결과 캐시에서 엔트리를 제거합니다. 다른 Analysis Services를 위한 메모리 할당량이 증가함에 따라, 쿼리 결과 캐시에 대한 메모리 양은 감소하게 됩니다. 적은 메모리 자원으로 실행할 경우, 쿼리 결과 캐시가 작기 때문에 쿼리 응답 시간이 증가하게 됩니다. 연결에 의한 메모리 사용Analysis Services가 다수의 연결을 지원할 경우, 각 연결에 필요한 메모리 할당으로 인해 쿼리 결과 캐시에 사용될 수 있는 메모리 양이 감소하게 됩니다. 클라이언트가 쿼리의 실행 위치를 Analysis 서버로 지정할 경우 (이를 원격 쿼리라고 함), 쿼리 실행을 위해 추가 메모리가 요구됩니다. 원격 쿼리에 할당될 수 있는 메모리 양은 AgentCacheSize 레지스트리 키 값에 의해 결정됩니다. 기본적으로, Analysis 서버에서 최고 10%의 메모리를 각 에이전트 캐시에 할당할 수 있습니다. 그러나, 이들 캐시가 1개 이상 동시에 할당될 수 있기 때문에 (원격 쿼리를 발행하는 다중 클라이언트를 지원하기 위해), 쿼리 결과 캐시용 메모리 예약을 위해 다수의 원격 쿼리가 예상될 경우 이 값을 줄여야 합니다. 원격 쿼리에 대한 보다 자세한 정보는 Microsoft Technet 웹사이트 (http://www.microsoft.com/korea/technet/default.asp) 및 "Microsoft SQL Server 2000 Analysis Services Performance Guide."를 참조하십시오. 복제 차원에 의한 메모리 사용사용자가 차원 보안에 의해 보호된 큐브를 쿼리할 경우, Analysis Services는 클라이언트가 실제로 사용하고 있는 보안 역할의 각각의 고유한 결합에 대한 복제 차원을 계산하고 로드합니다. 예를 들어, 사용자가 공장 사용자 및 공장 관리자라는 2가지 역할의 구성원일 경우, 그렇다면, 권한이 허용되거나 거부된 구성원의 최종 목록이 곧 통합 목록이 됩니다. 복제 차원은 권한이 허용된 모든 구성원과 함께 그 형제, 조상 및 조상의 형제를 포함하며, 클라이언트에게 보는 것이 허용되지 않는 구성원의 이름과 속성은 제거됩니다. 복제 차원은 차원(또는 차원을 담고 있는 큐브)가 처리되거나, Analysis Services가 재시작되거나, 또는 역할 구성원이 변경될 경우 언로드됩니다. 복제 차원은 클라이언트가 연결 해제될 경우에도 언로드되지 않습니다. 메모리에 복제본을 저장하면, 동일한 권한을 가진 클라이언트 전반에 걸쳐 복제본이 재사용될 수 있습니다. Analysis Services는 새로운 복제본을 만들기 전에, 허용 및 거부 목록에 복제본이 이미 존재하는지 여부를 확인합니다. 존재할 경우, 해당 복제본이 재사용되지만, 그렇지 않을 경우, 새로운 복제본이 생성됩니다. 수 많은 보안 역할이 존재하기 때문에(예를 들어, 100개), Analysis Services가 여러 다른 복제본을 만들어야 하는 경우가 아니거나, 또는 동적 보안이 사용되며 각 사용자가 다른 허용 및 거부 세트를 갖고 있을 경우, 이러한 설계는 무척 효과적입니다. 동적 보안에서, 허용 및 거부 사용자 목록은 USERNAME 함수를 포함하는 커스텀 MDX 문을 토대로 작성됩니다. 허용 및 거부 구성원 세트 목록이 동일할 경우, 보안 역할을 토대로, 복제본이 여러 사용자들에게 공유되게 됩니다. 큐브가 다수의 보안 역할을 담고 있고, 사용자별로 역할을 통합하고, 거의 모든 구성원이 볼 수 있는 수 많은 역할을 갖추고 있을 경우, 복제본은 Analysis 서버의 메모리를 많이 사용할 수 있습니다. 본 시나리오에서는, 보안이 메모리 사용 및 성능에 미치는 영향을 제한할 수 있도록 차원 레벨 보안 대신 셀-레벨 보안을 사용하십시오. 섀도 차원(Shadow Dimensions)에 의한 메모리 사용Analysis Services가 차원을 처리할 경우, 처리가 완료될 때까지 메모리 내에 차원에 대한 섀도 차원이 생성됩니다. 반면, Analysis Services가 이전에 처리된 차원을 처리할 경우, 처리 중인 트랜잭션이 커밋할 때까지 메모리 내의 기존 차원을 토대로 사용자 쿼리를 해결합니다. 차원이 처리된 후에는, 기존 차원이 메모리에서 해제되며, 새롭게 처리된 차원을 토대로 사용자 쿼리가 해결됩니다. 차원이 큐브 처리의 일환으로 처리될 경우(단일 트랜잭션으로), 섀도 차원의 생성은 큐브가 대용량 차원을 갖고 있을 경우 메모리에 엄청난 영향을 미칠 수 있습니다. 큐브의 차원이 단일 트랜잭션으로 처리될 경우, 각 차원의 섀도 복사본은 트랜잭션이 커밋할 때까지 메모리에 저장됩니다. Analysis Services는 VLDM 임계값 보다 더 큰 대용량 차원을 별도의 프로세스 주소 공간에 로드하지만, 섀도 차원은 항상 주 프로세스 주소 공간(대용량 차원의 경우 많은 메모리 양을 사용할 수 있는) 내에 만들어집니다. Analysis 서버의 메모리가 부족할 경우, 단일 트랜잭션으로 기존 차원을 모두 처리하는 것이 실패할 수 있습니다. Analysis Manager에서 Process all dimensions 또는 Process the database을 클릭하거나 또는 Decision Support Objects (DSO)을 사용해 모든 차원을 처리하도록 지정하면, 단일 트랜잭션으로 모든 차원이 처리됩니다. 메모리 자원이 부족할 경우, 단일 트랜잭션으로 처리하는 것이 아니라, 개별적으로 처리하는데 필요한 개체를 처리함으로써 메모리를 보존하게 됩니다. 디스크데이터 폴더는 1개의 Analysis Services 인스턴스에 모든 데이터베이스 데이터를 저장합니다. 이 임시 폴더(또는 여러 폴더)는 처리 동안에 사용되는 임시 파일을 저장합니다. 데이터 폴더의 디스크 공간 사용량은 큐브 파티션 분할이 필요한 시점을 파악하는데 도움이 됩니다. 임시 폴더의 디스크 공간 사용량은 메모리 자원 공급 부족을 나타내게 됩니다. 데이터 폴더Analysis Services는 데이터 폴더 내에 각 Analysis Services 데이터베이스에 대한 별도의 하위 폴더를 만듭니다. 각 데이터베이스 폴더 내에서, Analysis Services는 해당 데이터베이스 내 각 큐브에 대한 별도의 하위 폴더를 만듭니다. 각 큐브의 하위 폴더에 여러 유형의 수 많은 파일이 생성되지만, 그 중 특별히 모니터링을 해야 하는 파일 유형은 다음 2가지입니다.
임시 폴더없을 경우, 임시 폴더가 처리 동안 집계를 위한 임시 리포지토리로 사용됩니다. 처리 동안 성능을 극대화하려면, 가능한 임시 폴더 사용을 피해야 합니다. 그러나, Analysis Services는 프로세스 버퍼 메모리가 부족해 파티션을 처리할 수 없을 경우, 자동으로 임시 폴더를 사용하게 됩니다. 따라서, 임시 폴더 사용을 모니터링함으로써 메모리가 부족하게 될 시점을 감지해야 합니다. 임시 파일 사용을 모니터링하려면, Analysis Services:Proc Aggs 개체에 대한 Temp file bytes written/sec 카운터를 수집해 이를 로그 파일에 기록하도록 Performance Monitor를 설정해야 합니다. 병렬로 파티션을 처리할 경우 전체적인 성능을 향상시키려면, 병렬로 처리하는 파티션 수를 줄이거나, 직렬로 파티션을 처리함으로써 메모리를 보존하고 임시 파일의 사용을 피해야 합니다. 병렬로 파티션을 처리할 경우, 이와 같은 동시 연산에 필요한 가상 주소 공간이 부족해질 수 있습니다. 그럴 경우, 메모리 부족 오류가 발생합니다. 할당된 가상 메모리를 지원할 물리적 메모리가 부족할 경우, 메모리 페이징이 발생합니다. 프로세서프로세서 용량 문제를 분석할 경우, 쿼리(querying)와 처리를 모두 검토해야 합니다. 쿼리Analysis Services는 사용자가 제출한 질의를 자동으로 병렬화함으로써 모든 가용 프로세서의 사용을 극대화합니다. 복잡한 쿼리는 간단한 쿼리보다 많은 프로세서 자원을 필요로 하며, 팩트(fact) 레벨에서 Analysis Services가 해결하는 쿼리는 Analysis Services가 기존 집계 기능을 사용해 해결하는 쿼리보다 많은 프로세서 자원을 요구합니다. 단순한 쿼리가 어떻게 집계 기능을 활용하는지는 매우 쉽게 이해할 수 있지만, 단순해 보이는 쿼리가 실제로는 상당히 자원 집약적인 경우가 종종 있습니다. TOPCOUNT(), AGGREGATE() 및 MEDIAN()과 같은 일부 MDX 함수는 쿼리 해결을 위해 수 많은 셀을 검색(touch)하지만, 소수의 값만을 반환합니다(이를 와이드 쿼리(wide queries) 라고 함). 예를 들어, Analysis Services가 당해 년도 판매고 3대 고객(사)를 반환하는 쿼리 또는 당해 년도 고객 당 평균 판매량을 반환하는 쿼리를 대형 큐브에서 해결하려면 많은 시간이 소요될 수 있습니다. 쿼리와 관련된 차원 레벨과 집계 설계에 따라 다르긴 하지만, 집계 기능이 도움이 될 수 있습니다. 그러나, 이런 유형의 쿼리의 경우, 반환된 쿼리 결과를 통해 Analysis Services가 이런 유형의 쿼리를 해결하는데 왜 많은 시간이 소요되는지 이유를 분명하게 파악할 수는 없습니다. 쿼리 성능에 문제가 있을 경우, 병목 여부를 규명해야 합니다.
처리처리 중 Analysis Services는 각 파티션의 처리를 병렬화하지만, 기본적으로, Analysis Services는 큐브의 각 파티션을 연속적으로 처리합니다. 병렬 처리는 대용량 큐브의 경우, Analysis 서버가 임시 파일을 사용하지 않고도 병렬로 여러 파티션을 처리할 만큼 충분한 메모리를 보유하고 있을 경우 (그리고 처리 버퍼가 적절한 메모리 양을 사용하도록 구성된 경우), 처음 데이터 웨어하우스를 로드하는 동안, 전체 큐브를 처리하는 동안 그리고 큐브 새로 고치기를 실행하는 동안, 성능을 획기적을 향상시키게 됩니다. 각 파티션의 집계가 처리되는 동안 Analysis Services 컴퓨터에 이들 집계를 저장할 만큼 충분한 메모리가 없을 경우, Analysis Services는 임시 파일을 사용해 가용 메모리를 보충하게 되는데, 이는 병렬 처리를 통해 달성하려 했던 성능 이점을 무위로 돌리게 됩니다. 유연한 집계(저속(lazy) 집계)는 우선 순위가 낮은 백그라운드 스레드에서 재계산되는데, 유연한 집계가 재계산될 때까지 많은 프로세서 자원을 사용할 수 있습니다. 스레드가 낮은 우선 순위에서 실행되기 때문에, 저속(lazy) 어그리게이터는 쿼리 응답 시간에 영향을 주지 않습니다. 그러나, 이들 집계는 백그라운드 스레드에서 계산되기 때문에, 이전 요청이 완료되기 전에 다른 요청이 발생할 경우 지연(lazy) 처리가 영원히 완료되지 않거나, 서버가 쿼리 또는 Analysis Services이외의 다른 처리에 의해 오버로드될 경우 매우 오랜 시간이 걸릴 수 있습니다. 일반적으로 유연한 집계의 재계산은 변경 차원에 대한 증분 업데이트에 의해 발생됩니다. 개체를 처리할 때 Analysis Services 컴퓨터의 메모리 자원 및 프로세서 사용을 고립시키고자 할 경우, 이 백그라운드 프로세스가 사용하는 자원을 결코 간과해서는 안됩니다. 네트워크네트워크 대역폭이 부족한 경우, 쿼리 응답성 및 처리 성능 모두에 영향을 줄 수 있습니다. 저속 연결을 사용해 Analysis Services에 연결되는 클라이언트는 고속 연결을 사용하는 클라이언트보다 훨씬 느린 Analysis Services 쿼리 응답 시간을 경험하게 됩니다. 관계형 데이터베이스가 Analysis 서버와 다른 서버에 위치할 경우, 네트워크 정체 시 처리 성능에 부정적인 영향을 줄 수 있습니다. 저속 네트워크 연결 시 쿼리 응답 최적화 또는 아키텍처가 처리 성능에 미치는 영향에 대한 자세한 정보는, Technet 웹 사이트에서 제공되는 "Microsoft SQL Server 2000 Analysis Services Performance Guide" (http://www.microsoft.com/korea/technet/default.asp)를 참조하십시오. SQL Server와 관련된 네트워크 문제에 대한 자세한 정보는 Microsoft SQL Server 2000 Administrator's Companion, Chapter 11, "Configuring Microsoft SQL Server on the Network"를 참조하십시오. 그 이외에, Microsoft System Monitor 온라인 도움말의 "Monitoring Network Activity"를 참조하십시오.
Analysis Services에서의 문제 관리는 여타 서버 응용 프로그램 또는 Windows 운영 체제 인프라 자체에 대한 문제 관리와 유사합니다. Analysis Services 관리자는 심각한 문제로 악화되기 전에 문제를 탐지함으로써 실제 문제가 발생할 때 해결할 수 있는 최상의 방법을 활용해야 합니다. Analysis Services 프로세스 로그 파일(항상 사용할 수 있어야 함), DTS 오류 및 실행 로그, Windows 응용 프로그램 로그를 정기적으로 검사함으로써, 더욱 심각한 문제로 발전하기 전에 잠재적 문제를 탐지해야 합니다. 문제가 발생한 후에도 이들 로그를 다시 검사함으로써, 이벤트와 문제를 연관시켜 오류로 이어지는 패턴을 규명해야 합니다. 문제 해결을 문서화함으로써, 향후 문제가 발생했을 때 해결하는데 활용하는 것은 물론 문제 해결 및 증상 이해를 위한 직원 교육에 활용해야 합니다. Analysis Services와 관련된 문제 관리 사안은 다음을 포함합니다.
문제 해결 팁Analysis Services 인스턴스를 운영할 때 직면하게 되는 문제 목록과 그 해결책은 다음과 같습니다.
파티션을 처리할 때, 먼저 차원을 완전히 처리한 후, 이를 토대로 파티션을 처리해야 합니다. 차원 중 하나라도 처리되고 있는 동안 파티션을 처리할 경우, 문제가 발생할 수 있습니다. SQL Server 2000 Resource Kit의 병렬 처리 유틸리티는 2개의 경로로 처리함으로써 이런 문제를 방지합니다. 첫 번째 경로는 차원을 위한 경로입니다(지정된 순서로). 그 다음, 유틸리티가 동일한 작업량으로 파티션을 위한 두 번째 스캔을 하게됩니다. 파티션을 처리하는 동안 또는 처리한 이후에 차원을 처리할 경우, 큐브가 쿼리할 수 없는 상태가 될 수 있습니다. 또한, 관계형 데이터베이스에서 모든 백그라운드 작업이 완전히 완료된 후에, 이를 토대로 차원을 처리해야 합니다. 차원 업데이트를 수행하는 동안 기본 차원 테이블이 변경될 경우, 문제가 발생할 수 있습니다. 이러한 제약 사항은, 기본적인 추출, 변환 및 차원 테이블을 업데이트하는 로드 프로세스(ETL 프로세스) 작업 시에도 반드시 준수되어야 합니다. 마지막으로, 변경 차원의 증분 프로세스는 저속 어그리게이터 백그라운드 프로세서를 개시하게 됩니다. 여러 변경 차원을 한번에 증분 처리할 경우, 오랜 기간 동안 시스템 응답성에 심각한 부작용을 줄 수 있습니다. 보다 자세한 정보는 Technet 웹 사이트의 "Microsoft SQL Server 2000 Analysis Services Performance Guide" (http://www.microsoft.com/korea/technet/default.asp)를 참조하십시오. 사용자 액세스 모니터링사용자 당 기반으로 실행되고 있는 쿼리를 모니터링할 수 있는 유일한 방법은 Analysis Manager의 Server Properties 대화 상자에서 쿼리 로그 횟수를 1로 설정한 다음, 쿼리 로그의 내용을 검사함으로써, 문제가 되고 있는 쿼리에 의해 검색된 레벨을 파악하는 것입니다. 이 방법은 손 쉽게 구성할 수 있는 장점은 있지만, 특히 다음과 같은 상황을 포함해, 사용자 쿼리를 항상 정확하게 측정할 수 있도록 보장하진 않습니다.
쿼리 활동을 모니터링하는 것 이외에, 사용자가 서버에 연결 및 연결 해제할 시점을 파악해야 할 것입니다. Windows 응용프로그램 로그에서 연결 및 연결 해제 이벤트를 로그하려면, 레지스트리에서 AuditEvents 키를 편집하고 (\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLAP Server\CurrentVersion) 기본 값을 0xd (13)에서0xf (15)로 변경해야 합니다. 실제 사용자 연결(SQL Server sp_who 저장 프로시저에 해당)은 시스인터널즈(Sysinternals) (http://www.sysinternals.com 이러한 접근 방식은 Analysis Services에 대한 클라이언트 서버 직접 연결이 존재할 경우 가장 효과적입니다(Analysis Services은 포트 2725 상에서 수신함). 이런 경우, 원격 컴퓨터 이름은 연결 자체 목록에 존재하게 됩니다. 또한, 사용되는 도구에 따라서, 유틸리티는 기존 세션을 연결 해제함으로써, 클라이언트 및 서버 간의 네트워크 중단을 에뮬레이트합니다. 이로 인해 Analysis Services는 연결을 정리하고 포착한 모든 자원을 해제하게 됩니다
다음은 본 백서에서 설명한 유용한 정보들을 모두 정리한 통합 목록으로, 상세한 내용이 다루어진 페이지 번호도 함께 나와 있습니다.
다음 책자, 문서, 웹 사이트 및 교육과정은 Analysis Services 설치의 운영 및 유지 관리에 대한 추가 정보를 제공하는 업계 최고의 자원입니다. 책자
문서 및 링크
웹 사이트
Microsoft Official Curriculum Courses
다음과 같은 단계를 통해 Analysis 서버의 프로세스 버퍼 크기를 조정할 수 있습니다.
Call changeOLAPDataFolder("G:\AS Data")
Sub changeOLAPDataFolder(strDF)
Dim objWSHShell
Dim strKey
strKey = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft"
strKey = strKey & "\OLAP Server\CurrentVersion\Rootdir"
Set objWSHShell = CreateObject("WScript.Shell")
Call objWSHShell.RegWrite (strKey, strDF, "REG_SZ")
End Sub
/*
Analysis Services Repository Audit triggers (unsupported, for sample use
ONLY)
Dave Wickert, Microsoft
May 19, 2003
Note: This information is provided "AS IS" with no warranties, and confers
no rights.
Warning: Expect to see the following error,
"Cannot add rows to sysdepends for the current stored procedure because it
depends on the missing object 'dbo.LookupHierarchyName'. The stored
procedure will still be created."
This is expected because of the recursive nature of LookupHierarchyName
stored procedure. You can safely ignore the error message.
*/
SET QUOTED_IDENTIFIER OFF
GO
SET ANSI_NULLS ON
GO
-- Change repository name (as appropriate) in next line
USE AS_Repository
-- Change above line
GO
---------------------------------------
/* Audit table */
IF EXISTS (SELECT *, name FROM sysobjects WHERE id =
OBJECT_ID(N'dbo.OlapObjectsAudit') AND OBJECTPROPERTY(id, N'IsUsertable')
= 1)
DROP table dbo.OlapObjectsAudit
GO
CREATE table dbo.OlapObjectsAudit
( Reason VARCHAR (10) NOT NULL ,
ObjectName NVARCHAR (3000) NOT NULL ,
ObjectType VARCHAR(50) NOT NULL ,
Objectdefinition [ntext] NULL ,
Updated datetime NOT NULL DEFAULT GEtdATE() ,
ByUser varchar(30) NOT NULL DEFAULT SYSTEM_USER )
ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
---------------------------------------
/* LookupHierarchyName function */
---------------------------------------
IF EXISTS (SELECT *, name FROM sysobjects WHERE id =
OBJECT_ID(N'dbo.LookupHierarchyName') AND OBJECTPROPERTY(id,
N'IsProcedure') = 1)
DROP PROCEDURE dbo.LookupHierarchyName
GO
CREATE PROCEDURE dbo.LookupHierarchyName
( @ID VARCHAR (36) , @FullName NVARCHAR (3000) OUTPUT ) AS
BEGIN
DECLARE @ParentID VARCHAR (36)
DECLARE @ObjectName NVARCHAR (150)
DECLARE @ClassType INT
-- try and look up ID, first in OlapObjects, then the inserted temporary
-- table, then finally the deleted temporary table
SELECT @ParentID = ParentID, @ObjectName = ObjectName, @ClassType =
ClassType FROM OlapObjects WHERE ID = @ID
IF @@ROWCOUNT = 0
BEGIN
SELECT @ParentID = ParentID,
@ObjectName = ObjectName,
@ClassType = ClassType
FROM #inserted WHERE ID = @ID
IF @@ROWCOUNT = 0
BEGIN
SELECT @ParentID = ParentID, @ObjectName = ObjectName, @ClassType =
ClassType FROM #deleted WHERE ID = @ID
IF @@ROWCOUNT = 0
BEGIN
SET @FullName = N'-parent not found-'
RETURN -- give up -- return not found marker
END
END
END
-- cannot detect an arbitrary loop in directed graph, but can detect a
-- parent=self
IF @ParentID = @ID RETURN (N'-self loop-') -- @ObjectName if so, return
object name
SET @FullName = @ObjectName -- return value when ClassType = 2 (database),
which is always top of the object name hierarchy
IF @ClassType <> 2 -- if not database, then recurse down
BEGIN
EXEC dbo.LookupHierarchyName @ParentID, @FullName OUTPUT
SET @FullName = @FullName + ' / ' + @ObjectName
END
END
GO
---------------------------------------
/* LookupClassType function */
---------------------------------------
IF EXISTS (SELECT *, name FROM sysobjects WHERE id =
OBJECT_ID(N'dbo.LookupClassType') AND OBJECTPROPERTY(id,
N'IsScalarFunction') = 1)
DROP FUNCTION dbo.LookupClassType
GO
CREATE FUNCTION dbo.LookupClassType (@ClassType INT)
RETURNS VARCHAR(50) AS
BEGIN
DECLARE @ObjectType VARCHAR(50)
SET @ObjectType = CASE @ClassType
WHEN 1 THEN 'Server'
WHEN 2 THEN 'Database'
WHEN 3 THEN 'DatabaseRole'
WHEN 4 THEN 'DatabaseCommand'
WHEN 5 THEN '-not used-'
WHEN 6 THEN 'Datasource'
WHEN 7 THEN 'DatabaseDimension'
WHEN 8 THEN 'DatabaseLevel'
WHEN 9 THEN 'Cube'
WHEN 10 THEN 'CubeMeasure'
WHEN 11 THEN 'CubeDimension'
WHEN 12 THEN 'CubeLevel'
WHEN 13 THEN 'CubeCommand'
WHEN 14 THEN 'CubeRole'
WHEN 15 THEN 'VirtualCube'
WHEN 16 THEN 'VirtualCubeMeasure'
WHEN 17 THEN 'VirtualCubeDImension'
WHEN 18 THEN 'VirtualCubeLevel'
WHEN 19 THEN 'Partition'
WHEN 20 THEN 'PartitionMeasure'
WHEN 21 THEN 'PartitionDimension'
WHEN 22 THEN 'PartitionLevel'
WHEN 23 THEN 'Aggregation'
WHEN 24 THEN 'AggregationMeasure'
WHEN 25 THEN 'AggregationDimension'
WHEN 26 THEN 'AggregationLevel'
WHEN 27 THEN 'DatabaseAnalyzer'
WHEN 28 THEN 'CubeAnalyzer'
WHEN 29 THEN 'PartitionAnalyzer'
WHEN 30 THEN 'Collection'
WHEN 31 THEN 'MemberProperty'
WHEN 32 THEN 'RoleCommand'
WHEN 33 THEN 'MiningModel'
WHEN 34 THEN 'Column'
WHEN 35 THEN 'MiningModelRole'
ELSE '-unknown-'
END
RETURN (@ObjectType)
END
GO
---------------------------------------
/* InsertedRecord function */
---------------------------------------
IF EXISTS (SELECT *, name FROM sysobjects WHERE id =
OBJECT_ID(N'dbo.InsertedRecord') AND OBJECTPROPERTY(id,
N'IsInlineFunction') = 1)
DROP FUNCTION dbo.InsertedRecord
GO
CREATE FUNCTION dbo.InsertedRecord (
@ID VARCHAR (36) ,
@Reason VARCHAR (10) ,
@FullName NVARCHAR (3000) ,
@ObjectType VARCHAR (50) )
RETURNS table AS
RETURN (SELECT @ID as ID, @Reason as Reason, @FullName as FullName,
@ObjectType as ObjectType)
GO
---------------------------------------
/* UPDATE trigger */
---------------------------------------
IF EXISTS (SELECT *, name FROM sysobjects WHERE id =
OBJECT_ID(N'dbo.OlapObjects_Update_Audit') AND OBJECTPROPERTY(id,
N'Istrigger') = 1)
DROP trIGGER dbo.OlapObjects_Update_Audit
GO
CREATE trIGGER dbo.OlapObjects_Update_Audit
ON dbo.OlapObjects
AFTER UPDATE AS
BEGIN
SET NOCOUNT ON
DECLARE @ID VARCHAR (36)
DECLARE @ParentID VARCHAR (36)
DECLARE @ObjectName NVARCHAR (150)
DECLARE @ClassType INT
DECLARE @ObjectType VARCHAR (50)
DECLARE @FullName NVARCHAR (3000)
IF UPDATE(Objectdefinition)
BEGIN
SELECT ID, ParentID, ObjectName, ClassType INTO #deleted from deleted
SELECT ID, ParentID, ObjectName, ClassType INTO #inserted from
inserted
DECLARE inserted_cursor CURSOR FOR SELECT ID, ParentID, ObjectName,
ClassType FROM inserted
OPEN inserted_cursor
FETCH NEXT FROM inserted_cursor INTO @ID, @ParentID, @ObjectName,
@ClassType
WHILE @@FETCH_STATUS = 0
BEGIN
-- Get the required data
EXEC dbo.LookupHierarchyName @ID, @FullName OUTPUT
SET @ObjectType = dbo.LookupClassType(@ClassType)
-- Insert the audit record
INSERT INTO dbo.OlapObjectsAudit (Reason, ObjectName, ObjectType,
Objectdefinition)
SELECT i.Reason, i.FullName, i.ObjectType, olapo.Objectdefinition
FROM dbo.InsertedRecord(@ID, 'UPDATE', @FullName, @ObjectType) i
INNER JOIN dbo.OlapObjects olapo ON i.ID = olapo.ID
-- next item in inserted rowset
FETCH NEXT FROM inserted_cursor INTO @ID, @ParentID, @ObjectName,
@ClassType
END
CLOSE inserted_cursor
DEALLOCATE inserted_cursor
END
END
GO
---------------------------------------
/* INSERT trigger */
---------------------------------------
IF EXISTS (SELECT *, name FROM sysobjects WHERE id =
OBJECT_ID(N'dbo.OlapObjects_Insert_Audit') AND OBJECTPROPERTY(id,
N'Istrigger') = 1)
DROP trIGGER dbo.OlapObjects_Insert_Audit
GO
CREATE trIGGER dbo.OlapObjects_Insert_Audit
ON dbo.OlapObjects
AFTER INSERT AS
BEGIN
SET NOCOUNT ON
DECLARE @ID VARCHAR (36)
DECLARE @ParentID VARCHAR (36)
DECLARE @ObjectName NVARCHAR (150)
DECLARE @ClassType INT
DECLARE @ObjectType VARCHAR (50)
DECLARE @FullName NVARCHAR (3000)
SELECT ID, ParentID, ObjectName, ClassType INTO #deleted from deleted
SELECT ID, ParentID, ObjectName, ClassType INTO #inserted from inserted
DECLARE inserted_cursor CURSOR FOR SELECT ID, ParentID, ObjectName,
ClassType FROM inserted
OPEN inserted_cursor
FETCH NEXT FROM inserted_cursor INTO @ID, @ParentID, @ObjectName,
@ClassType
WHILE @@FETCH_STATUS = 0
BEGIN
-- Get the required data
EXEC dbo.LookupHierarchyName @ID, @FullName OUTPUT
SET @ObjectType = dbo.LookupClassType(@ClassType)
-- Insert the audit record
INSERT INTO dbo.OlapObjectsAudit (Reason, ObjectName, ObjectType,
Objectdefinition)
SELECT i.Reason, i.FullName, i.ObjectType, olapo.Objectdefinition
FROM dbo.InsertedRecord(@ID, 'INSERT', @FullName, @ObjectType) i INNER
JOIN dbo.OlapObjects olapo ON i.ID = olapo.ID
-- next item in inserted rowset
FETCH NEXT FROM inserted_cursor INTO @ID, @ParentID, @ObjectName,
@ClassType
END
CLOSE inserted_cursor
DEALLOCATE inserted_cursor
END
GO
---------------------------------------
/* DELETE trigger */
---------------------------------------
IF EXISTS (SELECT *, name FROM sysobjects WHERE id =
OBJECT_ID(N'dbo.OlapObjects_Delete_Audit') AND OBJECTPROPERTY(id,
N'Istrigger') = 1)
DROP trIGGER dbo.OlapObjects_Delete_Audit
GO
CREATE trIGGER dbo.OlapObjects_Delete_Audit
ON dbo.OlapObjects
AFTER DELETE AS
BEGIN
SET NOCOUNT ON
DECLARE @ID VARCHAR (36)
DECLARE @ParentID VARCHAR (36)
DECLARE @ObjectName NVARCHAR (150)
DECLARE @ClassType INT
DECLARE @ObjectType VARCHAR (50)
DECLARE @FullName NVARCHAR (3000)
SELECT ID, ParentID, ObjectName, ClassType INTO #deleted from deleted
SELECT ID, ParentID, ObjectName, ClassType INTO #inserted from inserted
DECLARE deleted_cursor CURSOR FOR SELECT ID, ParentID, ObjectName,
ClassType FROM deleted
OPEN deleted_cursor
FETCH NEXT FROM deleted_cursor INTO @ID, @ParentID, @ObjectName,
@ClassType
WHILE @@FETCH_STATUS = 0
BEGIN
-- Get the required data
EXEC dbo.LookupHierarchyName @ID, @FullName OUTPUT
SET @ObjectType = dbo.LookupClassType(@ClassType)
-- Insert the audit record
INSERT INTO dbo.OlapObjectsAudit (Reason, ObjectName, ObjectType)
VALUES ('DELETE', @FullName, @ObjectType)
-- next item in inserted rowset
FETCH NEXT FROM deleted_cursor INTO @ID, @ParentID, @ObjectName,
@ClassType
END
CLOSE deleted_cursor
DEALLOCATE deleted_cursor
END
GO
USE master
GO
/* Additional examples are available at: */
/* http://support.microsoft.com/default.aspx?scid=kb;enus;218592 */
/* --------------------------------------------------------------*/
/* Remove any previous references to the linked server */
EXEC sp_dropserver 'LINKED_OLAP'
EXEC sp_addlinkedserver
@server='LINKED_OLAP', -- local SQL name given to the linked server
@srvproduct='', -- not used
@provider='MSOLAP.2', -- OLE DB provider (.2 means the SQL2K version)
@datasrc='localhost', -- analysis server name (machine name)
@catalog='Foodmart 2000'-- default catalog/database
select * from openquery
( LINKED_OLAP, 'Select {[Measures].[Unit Sales]} on columns from [Sales]
')
select * from openquery
( LINKED_OLAP, ' with member [Measures].[Store Profit Rate] as
''([Measures].[Store Sales]-[Measures].[Store Cost])/[Measures].[Store
Cost]'', format = ''#.00%'' select {[Measures].[Store
Cost],[Measures].[Store Sales],[Measures].[Store Profit Rate]} on columns,
Order([Product].[Product Department].members, [Measures].[Store Profit
Rate], BDESC) on rows from Sales where ([Time].[1997]) ')
select * from sysobjects order by name
USE master
GO
/* Remove any previous references to the linked server */
EXEC sp_dropserver 'LINKED_OLAP'
EXEC sp_addlinkedserver
@server='LINKED_OLAP', -- local SQL name given to the linked server
@srvproduct='', -- not used
@provider='MSOLAP.2', -- OLE DB provider (.2 means the SQL2K version)
@datasrc='localhost', -- analysis server name (machine name)
@catalog='Foodmart 2000'-- default catalog/database
select * from openquery
( LINKED_OLAP, 'Select {[Measures].[Unit Sales]} on columns from [Sales]
')
select * from openquery
( LINKED_OLAP, ' with member [Measures].[Store Profit Rate] as
''([Measures].[Store Sales]-[Measures].[Store Cost])/[Measures].[Store
Cost]'', format = ''#.00%'' select {[Measures].[Store
Cost],[Measures].[Store Sales],[Measures].[Store Profit Rate]} on columns,
Order([Product].[Product Department].members, [Measures].[Store Profit
Rate], BDESC) on rows from Sales where ([Time].[1997]) ')
select * from sysobjects order by name
다음 스크립트를 배치 파일에서 호출하여 지연 처리가 완료되는 시기를 확인할 수 있습니다. 예를 들어, 배치 파일에는 다음과 같은 배치가 포함될 수 있습니다. CScript LazyProcessing.vbs "Localhost" "Foodmart 2000" "HR" 배치는 다음 .vbs 파일을 호출하여 로컬 컴퓨터의 Foodmart 2000 데이터베이스에 있는 HR 큐브에서 지연 처리가 완료된 시기를 확인합니다. 'File: LazyProcessing.vbs
Option Explicit
'/*********************************************************************
' File: LazyProcessing.vbs
' Desc: This sample script displays the lazy aggregator's progress
' for a specified cube (all partitions)
' Parameters: "Server_Name" "Database_Name" "Cube_Name"
'*********************************************************************
Call GetLazyProcessing
'*********************************************************************
' Helper functions
Function ConvertState(dsoState)
Const olapStateNeverProcessed = 0
Const olapStateStructureChanged = 1
Const olapStateMemberPropertiesChanged = 2
Const olapStateSourceMappingChanged = 3
Const olapStateCurrent = 4
Select Case dsoState
Case olapStateCurrent
ConvertState = "Current"
Case olapStateMemberPropertiesChanged
ConvertState = "Properties changed"
Case olapStateNeverProcessed
ConvertState = "Never processed"
Case olapStateSourceMappingChanged
ConvertState = "Source mapping changed"
Case olapStateStructureChanged
ConvertState = "Structure changed"
Case Else
ConvertState = "Unknown state"
End Select
End Function
Sub GetLazyProcessing()
Dim bResult
Dim strMsg
If Wscript.Arguments.Count <> 3 Then
strMsg = "Invalid number of arguments."
strMsg = strMsg & "This script must be called with 3 arguments."
strMsg = strMsg & VbCRLF & VbCRLF
strMsg = strMsg & "Usage is: (DOS prompt) CScript LazyProcessing.vbs"
strMsg = strMsg & " ""Server"" ""Db"" ""Cube"" " & VbCRLF
strMsg = strMsg & "e.g. CScript LazyProcessing.vbs "
strMsg = strMsg & """Localhost'' ""Foodmart 2000"" ""HR"" "
Msgbox strMsg,, "Invalid LazyProcessing.vbs Calling Arguments"
Exit Sub
End If
Dim sServer : sServer = Wscript.Arguments(0)
Dim sDb : sDb = Wscript.Arguments(1)
Dim sCube : sCube = Wscript.Arguments(2)
bResult = LazyProcessing(sServer,sDb, sCube, strMsg)
If bResult Then
Msgbox strMsg, , "Get Lazy Processing information"
Else
Msgbox "Error-" & strMsg, , "Error - Get Lazy Processing information"
End If
End Sub
'*********************************************************************
' The real work . . .
Function LazyProcessing(strAnalysisServer, strOlapDb, strCube, strMsg)
Dim dsoServer : Set dsoServer = CreateObject("DSO.Server")
Dim dsoDB, dsoCube, dsoPartition
LazyProcessing = False
' assume we fail (strMsg will contain the error text)
strMsg = ""
' VBScript does not support direct use of enumerated constants.
' However, constants can be defined to supplant enumerations.
Const olapStateCurrent = 4
' Connect to the Analysis server.
On Error Resume Next
dsoServer.Connect strAnalysisServer
' If connection failed, then end the script.
If Err.Number <> 0 Then
strMsg = Err.Description
Err.Clear
Exit Function
End if
On Error Goto 0
' Find the database on the server.
If (dsoServer.mdStores.Find(strOlapDB)) = 0 Then
strMsg = "Database '" & strOlapDB & "' not found on '" & _
strAnalysisServer & "'."
Err.Clear
Exit Function
End If
Set dsoDB = dsoServer.mdStores(strOlapDB)
' Find the cube.
If (dsoDB.mdStores.Find(strCube)) = 0 then
strMsg = "Cube '" & strCube & "' not found in database '" & _
strOlapDB & "'."
Err.Clear
Exit Function
End If
Set dsoCube = dsoDB.MDStores(strCube)
' Validate the state of the cube
if dsoCube.State <> olapStateCurrent Then
strMsg = " Cube '" & strCube & "' state is: " & _
ConvertState(dsoCube.State) & VbCRLF
strMsg = strMsg & " Which cannot be checked." & VbCRLF
Err.Clear
Exit Function
End If
' Loop through each partition in the cube
strMsg = ""
For Each dsoPartition in dsoCube.Partitions
' Only check if the partition's state is current and, then, if lazy
' processing is ongoing.
' Normally, since the lazy aggregator is single threaded, only one
' partition is being processed at a time,
' but we won't assume that at this point.
If dsoPartition.State = olapStateCurrent Then
If dsoPartition.LazyOptimizationProgress <> 100 Then
' We are in-progress -- output the % complete
strMsg = strMsg & " Partition: " & dsoPartition.Name & " is " & _
CStr(dsoPartition.LazyOptimizationProgress) & "% complete." & _
vbCRLF
End If
End If
Next
If Len(strMsg) = 0 Then
strMsg = "Cube: " & dsoCube.Name & " is complete." & vbCRLF
Else
strMsg = "Cube: " & dsoCube.Name & vbCRLF & strMsg
End If
LazyProcessing = true ' we succeeded !
Set dsoCube = Nothing
Set dsoDB = Nothing
dsoServer.CloseServer
Set dsoServer = Nothing
End Function
Option Explicit
'/*********************************************************************
' File: CheckDataSlice.vbs
'
'Desc: This sample script scans through each database, each cube, looking
' for multi-partition cubes for which partition data slices have
' not been defined. It doesn't validate that the slice makes any
' sense or is consistent across all partitions -- just that
' partition slices are defined for all multi-partition cubes.
'
'Parameters: None
'*********************************************************************/
Call CheckDataSlice
Sub CheckDataSlice()
Dim strResults : strResults = ""
Dim strAnalysisServer
Dim dsoServer, dsoDB, dsoCube
Dim strMsg
' Initialize server name you could modify this script to pass the
' server name as a parameter from the command line
strAnalysisServer = "LocalHost"
' VBScript does not support direct use of enumerated constants.
' However, constants can be defined to supplant enumerations.
Const stateFailed = 2
Const olapEditionUnlimited = 0
' Connect to the Analysis server.
Set dsoServer = CreateObject("DSO.Server")
On Error Resume Next ' disable vbs error handling
dsoServer.Connect strAnalysisServer
' If connection failed, then end the script.
If dsoServer.State = stateFailed Then
strMsg = "Error-Not able to connect to '"
strMsg = strMsg & strAnalysisServer
strMsg = strMsg & "' Analysis server."
Msgbox strMsg,, "CheckDataSlice.vbs"
Err.Clear
Exit Sub
End if
On Error Goto 0 ' enable vbs error handling
' Certain partition management features are available only
' in the Enterprise Edition and Developer Edition releases
' of Analysis Services.
If dsoServer.Edition <> olapEditionUnlimited Then
strMsg = "Error-This feature requires Enterprise or Developer"
strMsg = strMsg & "Edition of SQL Server to manage partitions."
MsgBox strMsg,, "CheckDataSlice.vbs"
Exit Sub
End If
' Ok -- now do the real work -- accumulating the results for each cube
For Each dsoDB in dsoServer.mdStores
For Each dsoCube in dsoDB.mdStores
strResults = CheckCube (dsoCube, strResults)
Next
Next
If Len(strResults) = 0 Then strResults = " None found." & VbCrLf
strResults = "Partitions missing a data slice: " & VbCrLf & _
strResults
strResults = strResults & "On " & strAnalysisServer
MsgBox strResults, , "CheckDataSlice.vbs"
End Sub
Function CheckCube (dsoCube, strResults)
CheckCube = strResults
Const clsCube = 9
Const sbclsRegular= 0
If (dsoCube.ClassType <> clsCube) Then Exit Function
' Must be a cube
If (dsoCube.SubClassType <> sbclsRegular) Then Exit Function
' Must be regular cube
If (dsoCube.mdStores.Count < 2) Then Exit Function
' Only continue if this is a multi-partition cube
Dim dsoPartition
For Each dsoPartition in dsoCube.mdStores
If Not AnySlice(dsoPartition) Then
CheckCube = CheckCube & " " & dsoPartition.Name & " in Cube '" _
& dsoPartition.Parent.Name _
& "' (Database: " & dsoPartition.Parent.Parent.Name & _
")" & VbCrLf
End If
Next
End Function
Function AnySlice (dsoPartition)
Dim dsoDimension, dsoLevel
AnySlice = False ' assume we fail
For Each dsoDimension in dsoPartition.Dimensions
For Each dsoLevel in dsoDimension.Levels
If Len(dsoLevel.SliceValue) <> 0 Then
AnySlice = true ' we found a slice !
Exit Function
End If
Next
Next
End Function
다음 코드 예제는 clsServer 개체의 Edition 속성을 확인하여 기능 지원 여부를 확인합니다. 'VB syntax:
' Dim dsoServer As New DSO.Server
' Enumerated olapXXXXXXX constants already defined when
' you added the DSO COM object to your project
'VBS syntax:
Dim dsoServer
Set dsoServer = CreateObject("DSO.Server")
Const olapEditionUnlimited = 0
Const olapEditionPivotOnly = 1
Const olapEditionNoPartitions = 2
Const olapEditionError = &HFFFFFFFF
'-------------------------------------------------------
' Connect to the local Analysis server.
dsoServer.Connect "LocalHost"
' Check the Edition property.
Select Case 0 'dsoServer.Edition
Case olapEditionUnlimited
' Insert code for Enterprise Edition features.
Msgbox "EE"
Case olapEditionPivotOnly
' Reserved for future use.
Msgbox "Reserved"
Case olapEditionNoPartitions
' Insert code for Standard Edition features.
Msgbox "Standard Edition"
Case olapEditionError
' An error occurred while retrieving this information.
Msgbox "An error occurred"
Case Other
' Invalid return value
Msgbox "Invalid return value seen"
End Select
dsoServer.CloseServer
Set dsoServer = Nothing
Analysis Services 데이터 폴더는 Analysis Services 컴퓨터에서 정의된 개체에 대한 다차원 구조를 저장합니다. 데이터 폴더 내에서, Analysis Services는 각 데이터베이스에 대한 ODB 파일과 폴더를 만듭니다. ODB 파일에는 Analysis Services가 시작될 때 리포지토리에서 추출된 데이터베이스에 대한 런타임 데이터베이스 정보가 포함되어 있습니다. 파일 확장자는 "개체 데이터베이스"의 약자입니다. Analysis Services 런타임 엔진(msmdsrv.exe)은 Analysis Services가 실행되는 동안 리포지토리가 아닌 ODB 파일에서 데이터베이스 정보를 읽습니다. 데이터베이스 폴더다음 표에서는 각 데이터베이스 폴더 내의 데이터베이스 개체 파일에 대해 설명합니다.
또한, 각 데이터베이스 내에 물리적 또는 가상 큐브에 대해 폴더가 생성됩니다. 참고 "최소 정보"란 리포지토리에 저장되는 사용 가능한 메타 데이터의 하위 집합을 의미합니다. 이것은 Analysis Services가 처리 작업을 수행하고 쿼리에 응답하는 데 필요한 정보입니다. 큐브 폴더다음 표에서는 각 큐브 폴더 내에 생성된 파일에 대해 설명합니다.
저작권 이 설명서에 포함된 정보는 문서 발행 시에 논의된 문제들에 대한 Microsoft Corporation의 당시 관점을 반영하고 있습니다. Microsoft는 변화하는 시장 상황에 부응해야 하므로 이를 Microsoft 측의 공약으로 해석해서는 안되며, 발행일 이후 소개된 어떠한 정보에 대해서도 Microsoft는 그 정확성을 보증하지 않습니다. 이 백서는 오직 정보를 제공하기 위한 것입니다. Microsoft는 본 문서를 있는 그대로 제공하며 그 어떠한 명시적 또는 묵시적 보증도 제공하지 않습니다. 해당 저작권법을 준수하는 것은 사용자의 책임입니다. 저작권에서의 권리와 별도로, 이 설명서의 어떠한 부분도 Microsoft의 명시적인 서면 승인 없이는 어떠한 형식이나 수단(전기적, 기계적, 복사기에 의한 복사, 디스크 복사 또는 다른 방법) 또는 목적으로도 복제되거나 검색 시스템에 저장 또는 도입되거나, 전송될 수 없습니다. Microsoft가 이 설명서 본안에 관련된 특허권, 상표권, 저작권 또는 기타 지적 재산권 등을 보유할 수도 있습니다. 서면 사용권 계약에 따라 Microsoft로부터 귀하에게 명시적으로 제공된 권리 이외에, 이 설명서의 제공은 귀하에게 이러한 특허권, 상표권, 저작권 또는 기타 지적 재산권 등에 대해 어떠한 사용권도 제공하지 않습니다. © 2003 Microsoft Corporation. All rights reserved. Microsoft, Active Directory, Office 로고, Outlook, SharePoint, SQL Server, Windows NT, Windows Server 및 Windows는 미국, 대한민국, 및/또는 기타 국가에서의 Microsoft Corporation 등록 상표 또는 상표입니다. 여기에 인용된 실제 회사와 제품 이름은 해당 소유자의 상표일 수 있습니다.
최종 수정일 : 2004년 2월 3일 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
소개
에서 이 템플릿을 구할 수 있습니다.