• 아티클

SQL Q&A클러스터링의 작동 원리, 원인을 알 수 없는 지연, SA 계정 외

편집자: Nancy Michell

Q: 클러스터링의 작동 원리에 대해 자세히 알고 싶습니다. SQL Server™ 2005를 실행하는 64비트 Windows Server® 2003, SQL Server Reporting Services(SSRS) 웹 팜(보고서 서버의 수평 확장 배포), SSRS TempDB 카탈로그 서버, 연결된 서버를 통해 타사 데이터베이스에서 데이터를 가져와 SSRS용으로 저장하는 SQL Server로 환경을 구성하려고 합니다.

또한 3노드 액티브/액티브/패시브 클러스터를 사용하려고 합니다. 노드 1은 액티브 노드로 설정하여 타사 데이터베이스에서 가져온 데이터를 저장하고, 노드 2도 액티브 노드로 설정하여 SSRS 카탈로그를 저장하려고 합니다. 마지막으로 노드 3은 패시브 노드로 설정하여 노드 1이나 노드 2에 오류가 발생할 경우 장애 조치용으로 사용하려고 합니다. 도움을 주실 수 있을까요?

A: 안타깝게도 많은 사람들이 SQL Server 클러스터링과 관련하여 액티브/액티브 및 액티브/패시브의 개념을 잘못 이해하고 있는 것 같습니다. 대부분 SQL 클러스터링이 데이터베이스나 SQL 인스턴스 하나를 여러 서버에 "수평 확장"하도록 지원하는 것으로 이해하고 있지만 사실은 그렇지 않습니다. SQL Server에 액티브/액티브 데이터베이스나 인스턴스라는 것은 없습니다. "인스턴스"란 관련 데이터베이스와 함께 설치된 SQL Server를 의미합니다. SQL Server 인스턴스 하나당 지원되는 클러스터링은 액티브(1) 대 패시브(n)입니다. 이때 n은 1에서 7까지의 값이며 설치된 SQL Server 버전에 따라 다릅니다. 바로 이 때문에 SQL Server 클러스터링을 장애 조치 클러스터링이라고 하는 것입니다.

이러한 개념을 이해하고 나면 한 노드 집합에 장애 조치 클러스터링의 여러 인스턴스를 설치하는 것을 고려해 볼 수 있습니다. 예를 들어 공유 디스크를 사용하는 세 개의 물리적 서버가 있는 경우 기본적으로 액티브 상태인 인스턴스 하나를 노드 1에 두고 기본적으로 액티브 상태인 두 번째 인스턴스를 노드 2에 둘 수 있으며, 두 노드 모두 노드 3으로 장애 조치가 이루어지도록 할 수 있습니다. 이 두 인스턴스는 완전히 별개이며 서로 데이터를 공유하지 않으므로 액티브/액티브가 아닙니다. 두 인스턴스는 모두 액티브/패시브며 동일한 장애 조치 인스턴스를 공유합니다. 두 인스턴스 모두 노드 3으로 장애 조치가 수행되는 경우 시간이 경과되면서 이러한 로드로 인해 노드 3의 성능이 저하되는지 확인해야 합니다. 본래 장애 조치는 장애 조치 노드의 처리 성능에 의존합니다. 로드가 가장 많을 때 정상적인 작동 상태에서 처리를 위해 두 개의 노드가 필요하다고 가정할 경우 노드 3은 두 노드에 일반적으로 할당되는 최대 로드를 감당하기가 어렵습니다.

하지만 클러스터를 실행할 수 있는 하드웨어의 가격이 상대적으로 고가인 점을 감안하면 사람들이 두 개의 주 노드에서 동시에 오류가 발생하여 전체 로드를 한 노드에 넘겨야 하는 가능성에 그다지 무게를 두고 있지 않다는 것을 이해할 수 있습니다. 이러한 생각으로 100% 장애 조치 성능을 갖춘 하드웨어를 구입하는 대신 위험을 감수하는 결정을 내리게 되는 것입니다.

몇 가지 좋은 소식도 있습니다. SQL Server 2005는 단일 SAN을 사용하는 클러스터링을 통해 클러스터보다 빠르게 장애 조치를 수행하고 데이터 복사본까지 유지할 수 있는 대체 기술을 포함하여 보다 다양한 HA(고가용성) 옵션을 제공합니다. 이러한 옵션으로는 미러링, 피어 투 피어 복제 등이 있습니다. 이러한 새 대체 기술과 함께, 다양한 HA 기능을 조합할 수 있는 몇몇 기술을 비롯하여 모든 종류의 요구 사항을 충족시킬 수 있는 훨씬 더 다양한 옵션을 사용할 수 있습니다.

이제 Microsoft® Cluster Configuration Validation Wizard(ClusPrep)를 다운로드하여 HCL(Hardware Certification List) 테스팅 대신 사용할 수 있습니다. HCL을 사용하는 경우 구성이 클러스터링에서 지원 가능한지 확인하는 데 몇 달이 소요될 수도 있었습니다. 이제 이 하드웨어 유효성 검사 도구를 통해 DBA는 인증된 하드웨어를 적절히 배치하는 데 드는 시간과 비용을 크게 줄일 수 있게 되었습니다. 이 도구는 이기종 하드웨어의 유효성을 검사하여 이러한 하드웨어를 한 클러스터 노드 집합 내에 배포하는 것도 가능하게 합니다.

Q: 제 컴퓨터 중 하나에서 삭제 프로시저를 실행했는데 12시간이 지난 후에도 완료되지 않고 있습니다. 작업이 차단된 것은 아닙니다. 가장 느린 쿼리 계획을 살펴보니 한 트리거가 87,327초 동안 실행 중인데 이 트리거에서 프로시저가 지연되고 있는 것 같습니다. 어떻게 하면 지연되고 있는 문을 확인할 수 있을까요?

A: 여러 가지 이유로 트리거 내의 루프가 종료되지 않고 있을 가능성이 높습니다. 오랜 시간 동안 작업이 지연되는 경우 현재 실행 중인 문을 보려면 그림 1의 코드를 실행해 보십시오. 그러면 현재 실행 중인 문을 확인할 수 있는데, 이 문으로 인해 컴퓨터가 지연되고 있을 가능성이 큽니다.

Figure 1 현재 실행 중인 문 찾기

-- Look at the current statement being run:
-- Put results to text (Ctrl + T)
DECLARE @Handle binary(20), 
        @start int, 
        @end int,
        @SPID int

SET    @SPID = spid

SELECT @Handle = sql_handle, 
        @start = stmt_start, 
        @end = stmt_end 
FROM Master..sysProcesses(NOLOCK) 
WHERE SPID = @SPID

IF NOT EXISTS (SELECT * FROM ::fn_get_sql(@Handle))PRINT ‘Handle not found in cache’
ELSE
   SELECT ‘Current Statement’= substring(text, (@start + 2)/2, CASE @end WHEN -1 THEN (datalength(text))
       ELSE (@end -@start + 2)/2 END)
       FROM ::fn_get_sql(@Handle)

Q: 방화벽을 통해 트랜잭션 복제를 지원해야 합니다. 게시자와 배포자는 방화벽 외부에 있고 구독자는 방화벽 내부에 있습니다. 구독자는 1433 포트에서 수신하도록 설정되어 있으며, 컴퓨터 이름은 게시자의 경우 PUBMACHINE, 배포자의 경우 DISTMACHINE, 구독자의 경우 SUBMACHINE입니다. 초기 스냅숏 및 게시 밀어넣기에 성공하려면 어떤 포트를 열어야 합니까?

A: 밀어넣기 구독을 사용하는 경우 배포 에이전트가 배포자 컴퓨터(방화벽 외부)에서 실행되고 스냅숏 에이전트에 의해 생성된 스냅숏 파일에 로컬로 액세스할 수 있으므로 SQL Server 포트(이 경우 1433)만 열어도 충분합니다. 그러나 끌어오기 구독을 사용하는 경우에는 구독자 컴퓨터에서 실행되는 배포자 에이전트가 방화벽을 통해 스냅숏 파일에 액세스할 수 있어야 합니다. 다음과 같은 옵션을 고려할 수 있습니다.

방화벽 외부의 파일 공유에서 스냅숏 파일에 액세스할 수 있다고 가정할 경우, 방화벽을 통해 Windows® 파일 공유 포트를 열어 방화벽 내부에서 실행되는 배포 에이전트가 방화벽 외부에 있는 스냅숏 파일에 액세스하도록 할 수 있습니다. 단, 이 경우 인프라의 다른 부분에서 발생할 수 있는 보안 문제를 고려해야 합니다. 기본 스냅샷 위치(SSMS 기본값)로 로컬 경로를 구성한 경우 배포 에이전트의 /AltSnapshotFolder 옵션을 사용하여 스냅샷 파일 선택 위치를 다시 정의해야 할 수도 있습니다.

스냅샷 파일 전송 시 FTP를 사용하도록 복제를 구성할 수도 있습니다. 이 경우 포트 21을 열어야 합니다.

Q: SQL Server 2005의 SA 계정을 사용하지 않을 경우의 단점과 이렇게 하면 정말로 보안에 도움이 되는지 알고 싶습니다. 이 질문과 관련된 백서가 있을까요?

A: SQL Server 2005를 새로 설치한 경우, 혼합 모드를 사용하지 않으면 SA 계정이 기본적으로 사용되지 않도록 설정되며 이를 위한 임의 암호가 생성됩니다. 이 계정을 사용하지 않도록 직접 설정할 수도 있습니다. 이 질문과 관련된 백서는 없습니다. 하지만 최상의 구현 사례 백서에서 로그인을 사용하지 않도록 설정하거나 이름을 바꾸는 자세한 내용을 볼 수 있습니다.

SA 계정을 손상시키려는 시도로부터 컴퓨터를 보호하려면 계정 이름을 바꿔 보십시오. 단, 사용하지 않도록 설정한 계정을 나중에 사용하는 경우 암호를 새로 설정해야 합니다.

SA 계정을 사용하지 않을 경우 보안에 정말로 도움이 되는지에 대해 말씀드리겠습니다. 이 계정을 사용하지 않음으로써 보안이 개선되는 까닭은 계정이 사용되지 않는 동안에는 암호 추측 시도가 아무런 효과가 없기 때문입니다. 해커나 바이러스가 어떤 방법을 사용하더라도 잠긴 계정에 대한 무작위 공격은 성공하지 못합니다. SA 계정의 이름을 바꾸거나 사용하지 않도록 설정하면 SA 계정을 통해 연결하는 응용 프로그램이 제대로 작동하지 않게 됩니다. 따라서 먼저 이러한 응용 프로그램을 찾아서 수정하거나 제거해야 합니다. 앞에서도 언급했듯이 계정을 다시 사용하도록 설정하기 전까지는 해당 계정으로 데이터베이스에 연결할 수 없습니다. 또한 이전에 인증 절차가 실패했으므로 실패한 시도는 공격받은 시스템에 별로 해가 되지 않습니다.

Q: 대용량 OLTP(Online Transaction Processing) 데이터베이스 중 하나에 데이터 파일 크기의 두 배인 로그 파일이 있습니다. 다음 명령을 사용하여 로그 파일의 크기를 어느 정도 줄였는데 이보다 더 줄이고 싶습니다.

backup database syslogs to backupfile
DBCC SHRINKFILE (syslogs_log)

A: backup database 문을 backup log 문으로 변경해야 합니다. 또는 데이터베이스를 단순 복구 모드로 설정한 다음 shrinkfile 문을 실행할 수도 있습니다. 로그 축소가 끝나면 데이터베이스를 다시 이전 복구 모드로 설정한 다음 데이터베이스를 백업합니다. 이렇게 해도 원하는 크기로 축소되지 않으면 dbcc opentran 문을 사용하여 열려 있는 트랜잭션이 있는지 확인하십시오. 자세한 내용은 다음 기술 자료 문서를 참조하십시오. support.microsoft.com/kb/907511.

Q: 예약된 SQL Server 에이전트 작업 중 장애 조치가 수행될 경우 장애 조치가 끝난 후에 이 작업은 어떻게 됩니까? 수동으로 다시 시작해야 합니까?

A: 다른 프로세스가 실행 중인 경우가 아니면 작업을 수동으로 시작해야 합니다. 작업을 수동으로 다시 시작하지 않으려면 작업 완료 시 테이블을 업데이트하는 스크립트를 작성해 보십시오. 값이 1이면 작업이 실행되었음을 나타내고, 값이 1이 아니면 작업이 완료되지 않았으며 나중에 두 번째 작업이 발생하고 시작 명령을 실행함을 나타냅니다. 따라서 작업이 실행되는 동안 장애 조치가 수행되어 작업을 다시 실행해야 하는 경우 스크립트를 작성하면 다음 업무일 이전에 반드시 완료되어야 하는 중요한 야간 작업에 대해 염려할 필요가 없습니다.

팁: 업그레이드 및 DBCC UPDATEUSAGE

SQL Server 2000에서 SQL Server 2005로 업그레이드할 계획입니까?

그렇다면 데이터베이스를 업그레이드한 후 바로 DBCC UPDATEUSAGE를 실행하십시오.

DBCC UPDATEUSAGE는 카탈로그 뷰의 잘못된 페이지 및 행 개수를 보고하고 수정합니다. 정확하지 않은 수치가 있으면 sp_spaceused 시스템 저장 프로시저가 잘못된 공간 사용률 보고서를 반환할 수 있으므로 반드시 수정해야 합니다. SQL Server 2005에서는 이러한 값이 항상 올바르게 유지되므로 데이터베이스에서 잘못된 개수가 발견되는 일이 없습니다. 그러나 SQL Server 2005로 업그레이드된 데이터베이스에는 잘못된 개수가 포함될 수 있으므로 업그레이드 후 DBCC UPDATEUSAGE를 실행해야 합니다.

DBCC UPDATEUSAGE의 작동 원리는 다음과 같습니다. DBCC UPDATEUSAGE는 테이블 또는 인덱스에 있는 각 파티션의 행 수, 사용된 페이지 수, 예약된 페이지 수, 리프 페이지 수 및 데이터 페이지 수를 수정합니다. 시스템 테이블에 개수 오류가 없으면 DBCC UPDATEUSAGE는 데이터를 반환하지 않습니다. 개수 오류가 발견되고 수정되었으며 사용자가 WITH NO_INFOMSGS를 사용하지 않은 경우에는 DBCC UPDATEUSAGE는 시스템 테이블의 업데이트된 행과 열을 반환합니다.

DBCC UPDATEUSAGE는 공간 사용률 카운터를 동기화하는 데도 사용할 수 있습니다. 대용량 테이블이나 데이터베이스에 대해 DBCC UPDATEUSAGE를 실행하는 경우 시간이 많이 걸릴 수 있으므로 일반적으로 sp_spaceused가 잘못된 값을 반환한다고 의심되는 경우에만 DBCC UPDATEUSAGE를 사용하는 것이 좋습니다. 선택적 매개 변수를 사용하면 sp_spaceused에서 테이블이나 인덱스의 공간 정보를 반환하기 전에 DBCC UPDATEUSAGE를 실행하도록 할 수 있습니다.

SQL Server 2005의 DBCC CHECKDB는 페이지 또는 행 개수가 음수일 경우 이를 감지하도록 향상되었습니다. DBCC CHECKDB는 음수를 감지하면 DBCC UPDATEUSAGE를 실행하여 이 문제를 해결하라는 권장 메시지와 경고를 출력합니다. SQL Server 2005로 업그레이드했기 때문에 이 문제가 발생한 것처럼 보일 수도 있지만, 업그레이드 전부터 잘못된 개수가 있었는지 확인해야 합니다.

다음 예제는 현재 데이터베이스의 모든 개체에 대해 페이지나 행 개수 또는 둘 모두를 업데이트하는 방법을 보여 줍니다. 다음 명령에서는 데이터베이스 이름으로 0을 지정하고 DBCC UPDATEUSAGE는 현재 데이터베이스에 대해 업데이트된 정보를 보고합니다.

DBCC UPDATEUSAGE (0);
GO

예를 들어 AdventureWorks의 페이지나 행 개수 또는 둘 모두를 업데이트하되 정보 메시지를 표시하지 않으려면 다음과 같이 데이터베이스 이름으로 AdventureWorks를 지정하고 모든 정보 메시지를 표시하지 않도록 설정하는 다음과 유사한 명령을 실행하십시오.

USE AdventureWorks;
GO
DBCC UPDATEUSAGE (‘AdventureWorks’) WITH NO_INFOMSGS; GO

자세한 내용은 SQL Server 온라인 설명서의 DBCC UpdateUsage를 참조하십시오.

Thanks to the following Microsoft IT pros for their technical expertise: Ken Adamson, Sunil Agarwal, Siggi Bjarnason, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Lucien Kleijkers, Raymond Mak, Chat Mishra (MSLI), Niraj Nagrani, Rick Salkind, Jacco Schalkwijk, Vijay Sirohi, Vijay Tandra Sistla, Matthew Stephen, and Buck Woody. Thanks to Saleem Hakani for this month's tip.

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