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

편집자: Nancy Michell

일광 절약 시간제

Q: 포괄적 에너지법안(Energy Policy Act of 2005)에 따라 곧 미국의 DST(일광 절약 시간제)가 바뀌게 될 텐데 이에 맞춰 SQL Server™를 업데이트해야 합니까?

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

Windows Vista에 연결

Q: Windows Vista를 설치한 후부터 시스템의 SQL Server 2005에 연결할 수 없습니다. 로컬 관리자이며 지금까지는 아무런 문제 없이 연결할 수 있었습니다. 무엇이 문제일까요?

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

SP2가 설치되지 않은 SQL Server 2005는 Windows Vista에서 실행이 지원되지 않으며, SP2에는 사용자 계정을 추가하는 도구가 포함되어 있습니다. 아직 SP2가 제공되지 않은 경우에는 다른 방법으로 이 문제를 간단히 해결할 수 있습니다. 개별 Windows 사용자 계정을 SQL Server 시스템 관리자 역할에 추가하면 됩니다. SQL Server Management Studio를 마우스 오른쪽 단추로 클릭하고 관리자 권한으로 실행을 선택하여 SQL Server에 연결한 다음 시스템 관리자 역할에 Windows 계정을 추가하기만 하면 됩니다. 이에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

뷰를 사용한 트랜잭션 복제

Q: 뷰를 게시하고 업데이트한 경우에는 트랜잭션이 복제된다는 것을 알고 있습니다. 하지만 이 뷰의 기본 테이블을 업데이트한 경우에도 트랜잭션이 복제됩니까? 마지막으로, 테이블을 게시하고 테이블의 뷰를 만든 다음 기본 테이블 대신 이 뷰를 업데이트했습니다. 이 경우에도 트랜잭션이 복제됩니까?

A: 기본 테이블이 게시의 아티클로 구성되어 있으면, 즉 기본 테이블을 복제되도록 구성한 경우에는 기본 테이블에 대한 모든 업데이트가 복제됩니다.

뷰를 복제할 때는 인덱싱된 뷰를 제외하고는 기본적으로 뷰의 스키마 부분만 또는 뷰의 코드만 뷰의 일부로 복제되고 뷰의 기본이 되는 데이터는 복제되지 않습니다. 그러므로 복제를 수행하지 않더라도 뷰를 업데이트하면, 즉 해당 뷰를 대상으로 사용하여 DML(데이터 조작 언어) 문을 실행하면 뷰가 아니라 기본 테이블의 데이터가 업데이트됩니다. 인덱싱된 뷰를 제외하고 모든 뷰는 쿼리 문의 논리적 저장소일 뿐이지 실제 저장소가 연결되어 있는 것은 아닙니다.

최대 서버 메모리

Q: RAM 크기가 5GB이고 Windows Server® 2003과 SQL Server 2000이 실행되는 컴퓨터가 있습니다. /3GB 스위치를 사용하여 사용자 모드 가상 주소 공간을 늘리고, /PAE 스위치를 사용하여 Windows 커널 PAE(Physical Address Extensions) 버전을 로드하고, AWE(Address Windowing Extensions)를 1로 설정하여 메모리의 페이지 잠금을 활성화하려고 합니다. AWE가 활성화된 경우에는 최대 서버 메모리 옵션으로 데이터 캐시 크기만 구성할 수 있습니까, 아니면 데이터, 프로세스, 세션 등의 전체 버퍼 캐시 크기를 구성할 수 있습니까? 데이터 캐시만 AWE로 매핑된 메모리를 사용할 수 있습니다. 그렇다면 최대 서버 메모리를 4GB로 구성할 경우 데이터 캐시가 AWE로 매핑된 1GB만 사용합니까, 아니면 이 추가 1GB를 사용하면서 다른 메모리 소비 항목과 함께 표준 주소 공간도 계속해서 사용할 수 있습니까?

A: 최대 서버 메모리는 항상 전체 버퍼 풀 크기를 제한합니다. 하지만 AWE로 매핑된 메모리를 사용할 수 있는 메모리 소비 항목은 데이터 캐시뿐입니다.

먼저 첫 번째 질문에 대한 답변입니다. AWE가 활성화되어 있더라도 최대 서버 메모리 옵션으로 전체 버퍼 풀 크기를 제한할 수 있습니다. 하지만 데이터 캐시 이외의 메모리 소비 항목은 AWE로 매핑된 메모리를 사용할 수 없습니다.

두 번째 질문에 대한 답입니다. 데이터 캐시는 AWE로 매핑된 메모리와 함께 SQL Server에서 적합성을 확인한 버퍼 풀의 다른 메모리를 사용합니다. 데이터 캐시가 사용하는 메모리는 AWE 메모리로만 제한되지 않으며 데이터 캐시는 AWE 메모리를 사용할 수 있는 유일한 메모리 소비 항목이기도 합니다. /3GB 스위치의 기능에 대해 자세히 알아보려면 Raymond Chen의 블로그를 참조하십시오.

프로파일링 및 성능

Q: 프로덕션 환경에서 SQL Server 2005를 미러링했습니다. 데이터베이스 컴퓨터에서 SQL Server 프로파일러를 시작하고 파일에 추적 데이터를 쓰기 시작하면 성능이 급격하게 저하됩니다. 왜일까요?

A: 성능이 저하되는 이유는 프로파일러를 어디에서 실행하는지에 따라 다릅니다. 서버 컴퓨터에서 대화형으로 프로파일러를 실행하면 프로파일러 UI가 서버의 메모리와 CPU를 모두 사용하게 되므로 성능에 영향을 줍니다.

워크스테이션에서 대화형으로 프로파일러를 실행하면 네트워크를 통해 이벤트 정보가 이동되어 처리량에 영향을 줍니다. 이 네트워크가 미러링에 사용되는 네트워크라면 미러링에도 성능 저하가 발생합니다. 또한 프로파일러 출력을 네트워크 공유에 저장하는 경우에도 네트워크를 통해 데이터가 이동되므로 성능에 좋지 않은 영향을 주게 됩니다.

성능에 미치는 이러한 영향을 완화할 수 있는 가장 좋은 방법은 프로파일링할 인스턴스가 실행되는 서버에서 프로파일러를 비대화형으로 실행한 다음 출력을 로컬 파일에 연결하는 것입니다. 이때도 서버 리소스는 사용되지만 대체적으로 성능에 미치는 영향은 가장 적습니다. 이 방법이 메모리 내 프로파일러 추적보다 훨씬 낫습니다. 파일 추적의 경우 버퍼 크기가 크고 버퍼가 더 효율적으로 디스크로 플러시되기 때문에 시스템 메모리를 보다 효과적으로 사용합니다. 또한 파일 추적은 SQL Server 프로파일러와 같은 외부 프로세스에 종속되지도 않습니다.

마지막으로 추적 데이터는 프로파일러가 프로파일링을 수행하는 동안 디스크 파일에 기록됩니다. 추적 파일은 공유되므로 다른 사용자가 원격으로 실시간 프로파일링 데이터를 볼 수 있습니다. 추적 파일을 대화형으로 호출할 경우 수동으로 프로파일러를 호출하고 화면에서 출력을 봅니다. 시각적 출력 없이 프로그래밍 방식으로 출력을 만들 수도 있는데 대개 프로그램을 비대화형으로 실행하는 경우는 이 때문입니다.

일반적으로 로컬 디렉터리의 최상위 수준에 공유를 만들어 다른 사용자가 이곳의 파일에 액세스하도록 하는 것이 적절한 방법입니다. 앞에서도 설명했듯이 원격 공유, 특히 미러링에 사용된 것과 동일한 네트워크 파이프를 통해 액세스되는 원격 공유의 파일로 추적 출력을 보내는 것은 바람직하지 않습니다.

또한 검토가 반드시 필요한 최소한의 이벤트 집합만 선택해야 합니다. 추적 파일의 위치로는 시스템에서 가장 빠른 드라이브를 선택해야 하며 SQL Server 데이터베이스 및 트랜잭션 로그 드라이브가 아니면 더욱 좋습니다. 이렇게 했는데도 성능 저하 문제가 해결되지 않으면 이벤트를 분할하여 서로 다른 하드 드라이브를 대상으로 하도록 지정합니다. 추적이 동일한 하드 드라이브를 대상으로 하더라도 추적마다 자체의 버퍼 집합을 사용하게 되므로 분할로 인한 장점을 누릴 수 있습니다. 자세한 내용은 SQL Server 온라인 설명서에서 sp_trace_create 및 모든 관련 명령문을 참조하십시오.

클러스터링 문제

Q: Windows Server 2003을 실행하는 클러스터에 SQL Server를 설치하려고 할 때마다 "클러스터 노드에 필요한 작업을 수행하지 못했습니다."라는 오류 메시지가 나타납니다. sqlstp.log에는 다음과 같은 내용만 제공됩니다.

Script file copied to '\\SERVER01\ADMIN$\SERVER01_MSSQLSERVER.iss' successfully.
Installing remote service (SERVER01)...
An error occured in the service create (SERVER01): 1069...

무엇이 문제일까요?

A: 이 오류가 발생한 데는 몇 가지 이유가 있을 수 있습니다. 설치 프로그램에서는 개별 컴퓨터의 설치 프로세스를 원격으로 관리하기 위해 선택된 모든 노드에 Windows NT® Service를 설치하는데, 이 과정에서 몇 가지 문제에 직면할 수 있습니다.

첫째, 도메인 계정 사용자에게 "서비스로 로그온" 권한을 거부하는 그룹 정책이 적용되어 있을 수 있습니다. 도메인 정책은 로컬 컴퓨터 정책보다 우선하므로 이와 같은 제한이 없는 계정을 사용해야 합니다.

둘째, 설치 프로그램을 실행 중인 컴퓨터에 로그온한 계정은 모든 노드에 대한 관리 권한을 가지고 있어야 하는데 그 이유는 다음과 같습니다. 마스터 설치 프로세스에서 모든 컴퓨터의 레지스트리에 원격으로 액세스해야 하거나, 설치 프로그램에서 원격 컴퓨터의 Windows 디렉터리에 cnvsvc.exe를 복사하거나, 설치 프로그램에서 로그온한 계정의 권한만 사용하여 원격 컴퓨터에 액세스하는 표준 Windows API를 사용합니다. 이러한 이유로 모든 노드에는 기본적으로 관리자로 로그온해야 합니다.

장애 복구 계획

Q: SAP 데이터베이스에 DR(장애 복구) 전략을 구현하기 위해 데이터베이스 미러링(비동기 모드)을 사용할지 또는 로그 전달을 사용할지 고려 중입니다. 프로덕션 사이트와 DR 사이트에는 100Mb의 광대역 연결이 지원될 예정이지만 미러링 세션 전용은 아니며, 다른 미러링 세션이나 DR 서버와도 연결을 공유하려고 합니다.

로그 레코드가 미러 데이터베이스로 전송되는 것을 방해하는 네트워크 문제가 있을 경우 다시 시도가 이루어집니까?

미러링 세션이 일시 중지될 때 보존 기간이 있습니까? 그리고 시스템 뷰 외에 미러링 트래픽과 로그 레코드 전송을 모니터링하는 데 사용할 수 있는 로깅 정보가 있습니까?

A: 먼저 데이터베이스 미러링의 다시 시도 논리에 관한 질문에 답을 드리겠습니다. 이 문제는 두 가지 방법으로 살펴볼 수 있습니다. 첫째, 일시적인 네트워크 문제가 있는 경우에는 미러링 세션의 상태가 연결이 끊긴 상태입니다. 기본적으로 네트워크 시간 초과 값은 10초인데 이는 주 데이터베이스에서 미러 데이터베이스로 로그 레코드를 보낼 수 없음을 의미합니다. 이러한 경우에는 주 데이터베이스가 계속해서 "노출된" 상태로 실행되므로 트랜잭션이 클라이언트 쪽에서 커밋됩니다. 네트워크 문제가 해결되면 사용자가 관여하지 않아도 미러링 세션이 자동으로 다시 시도됩니다. 먼저 로그 레코드를 사용하여 격차를 만회하고 파트너가 먼저 동기화되어 격차를 만회하면 상태가 동기화됩니다.

둘째, 다시 실행 문제가 있는 경우에는 미러링 세션의 상태가 일시 중지됩니다. 다시 실행 문제는 미러 데이터베이스가 자체 데이터베이스에서 로그 레코드를 커밋할 수 없음을 의미합니다. 다시 실행 문제는 대개 실제 파일을 찾을 수 없거나 디스크 공간이 부족하여 발생합니다. 이러한 경우에는 주 데이터베이스가 계속해서 노출된 상태로 실행되므로 트랜잭션이 클라이언트 쪽에서 커밋됩니다. 미러 서버에서 다시 실행 문제를 수동으로 수정한 후 미러 세션에 대해 다음과 같은 작업을 수행해야 합니다.

ALTER DATABASE <db> SET PARTNER RESUME; 

보존 기간에 대해 답하자면, 미러 세션이 연결이 끊긴 상태인지 또는 일시 중지된 상태인지 여부에 관계없이 로그 레코드는 세션이 복원될 때까지 보존되며, 세션이 일시 중지되었을 때부터 다시 시작될 때까지의 모든 레코드는 미러 데이터베이스에서 확정됩니다. 기본적으로 미러링 세션이 연결이 끊기거나 일시 중지된 동안에는 주 데이터베이스의 로그를 자를 수 없습니다. 이를 자르게 되면 다시 실행 체인이 끊기기 때문입니다. 따라서 세션이 복원될 때까지 주 데이터베이스의 로그가 무한정 커집니다. 따라서 미러링 세션에서는 보존과 관련된 어떠한 제한도 없습니다. 로그를 자를 수는 없으므로 주 서버에서 로그를 저장하는 데 사용할 수 있는 디스크 공간이 제한될 뿐입니다.

마지막으로, 미러링을 모니터링하는 데 사용할 수 있는 별도의 로그 파일은 없습니다. SQL Server 2005에서는 이러한 목적으로 사용할 수 있는 데이터베이스 미러링 모니터라는 GUI 도구를 제공합니다. 시스템 관리자는 이 도구를 사용하여 상태를 보거나 업데이트하고 몇 가지 핵심 성능 메트릭에 대한 경고 임계값을 구성하여 미러링이 제대로 수행되지 않을 경우 경고 메시지를 받을 수 있습니다. 데이터베이스 미러링과 관련하여 고려하게 되는 주요 성능 문제는 로그 레코드가 적시에 처리되느냐의 여부입니다. 데이터베이스 미러링을 모니터링하는 방법에 대한 자세한 내용은 미러링 상태 모니터링(msdn2.microsoft.com/en-us/library/ms365781.aspx)을 참조하십시오.

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

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..