SQL Q&A: Preventing Reboots, Installing Multiple Updates, and More

아티클
08/24/2016

SQL Q+A재부팅 방지, 여러 업데이트 설치 및 기타 질문

Nancy Michell 편집

재부팅 방지

Q: 핫픽스 등을 SQL Server 및 서버 운영 체제에 일반적으로 적용할 때 재부팅 횟수를 제한할 수 있는 방법이 있습니까?

A: 먼저, 설치 후 발생하는 재부팅은 대부분의 경우 설치 프로그램에 하드 코드되어 있지 않다는 점을 알아 두는 것이 좋습니다. 재부팅은 대개 파일이 잠겨 있기 때문에 발생합니다. 즉, 다른 응용 프로그램이나 운영 체제에서 현재 사용하고 있는(잠겨 있는) 파일을 설치 프로그램에서 업데이트하려고 하기 때문에 발생합니다. 따라서 이러한 재부팅을 막는 간단한 방법은 문제가 되는 파일을 사용 중인 프로세스가 없도록 하는 것입니다. 그러기 위해선 어떻게 해야 할까요?

첫 단계는, 설치 중에 사용 중이거나 잠겨 있는 파일을 파악하는 것입니다. 가장 쉬운 방법은 HKLM\system\currentcontrolset\control\sessionmanager\pendingfilerenameoperations의 레지스트리에서 찾아보는 것입니다. 이 레지스트리 키를 검사하는 목적은 두 가지입니다. 하나는 재부팅 요청이 정말로 잠긴 파일에 의해 발생한 것인지 확인하는 것이고 또 하나는 잠겨 있는 파일이 무엇인지 확인하는 것입니다. 설치 후 다시 부팅하기 전에 이 레지스트리 키를 조회해 보면 재부팅 요구가 발생한 원인을 알 수 있으며, 이후의 다른 설치 작업에서 재부팅이 발생하지 않도록 조치를 취할 수 있습니다.

이 레지스트리 키에는 두 가지 유형의 항목이 있습니다. 파일이 읽기 작업으로 잠긴 경우 파일당 한 줄로 항목이 표시되는데, 이는 업데이트된 파일이 이미 디스크에 있지만 아직까지 사용 중인 임시 복사본을 제거해야 함을 나타냅니다. 파일이 쓰기 작업으로 잠긴 경우 파일당 두 줄로 항목이 표시되며, 이는 업데이트가 아직 발생하지 않았고 응용 프로그램의 상태를 알 수 없기 때문에 해당 파일을 사용해서는 안 된다는 것을 나타냅니다. 말 그대로 설치 중에 중지된 경우입니다. 이 경우 한 줄은 실제 파일을 나타내고 다른 줄은 재부팅 중에 실제 파일이 될 임시 파일을 가리킵니다.

다음 단계는 여러 요인에 따라 달라질 수 있지만, 기본적인 아이디어는 잠긴 파일을 사용하고 있는 소프트웨어를 식별하는 것입니다. 종속성 검사기(가능한 경우)나 MSDN®의 DLL HELP 데이터베이스(support.microsoft.com/kb/815065(영문) 참조)를 사용하십시오.

확인한 소프트웨어에 서비스가 있으면 해당 서비스를 수동으로 중지한 다음 다시 테스트합니다. 응용 프로그램인 경우에는 응용 프로그램을 닫고 다시 시도합니다. 여러 응용 프로그램에서 단일 파일을 사용하고 있는 경우에는 해당 응용 프로그램을 모두 종료해야 합니다.

이러한 테스트를 테스트 환경에서 수행하면 프로덕션 환경에서 중지해야 하는 응용 프로그램 및 서비스 목록을 설치 전에 얻을 수 있습니다. 이 목록을 활용하면 어떠한 소프트웨어도 설치 프로그램에서 설치하는 파일을 잠그지 않게 되므로 프로덕션 환경에서 재부팅이 발생하지 않게 됩니다. 물론 설치가 완료된 후에는 각 응용 프로그램을 다시 시작해야 합니다.

이와 관련하여 한 가지 반가운 점은 잠금은 거의 변경되지 않으므로 일단 사용자 시스템의 패턴을 파악하고 나면 시스템을 사용하는 동안 내내 수많은 재부팅을 방지할 가능성이 큽니다.

알려 드리고 싶은 유용한 방법이 하나 더 있습니다. 여러 버전의 SQL Server™나 다른 제품이 함께 설치되어 있을 수 있으며, 심지어 설치된 제품의 버전 레벨이 서로 다를 수 있습니다. 이런 경우에는 항상 최신 버전을 먼저 업데이트해야 합니다. 이렇게 하면 업데이트로 인해 최신 버전의 모든 요소가 교체되기 때문에 그 외의 다른 인스턴스에서는 잠금을 신경 쓰지 않아도 될 확률이 큽니다. 예를 들어 세 개의 SQL Server 2000 SP3 인스턴스가 있는 경우 SP4로 업그레이드하는 첫 번째 인스턴스는 MSXML3.dll 파일을 업그레이드하고 재부팅을 수행해야 합니다. 만약 지금 재부팅을 수행했다면, 다음 두 인스턴스를 SP4로 업그레이드할 때는 업데이트된 MSXML3.dll 파일이 이미 존재하기 때문에 다시 부팅할 필요가 없습니다. 이는 SQL Server 2005 인스턴스를 업그레이드한 후 SQL Server 2000 인스턴스를 업그레이드하는 경우나 SQL Server 2000 인스턴스를 업그레이드한 후 SQL Server 7.0 인스턴스를 업그레이드하는 경우에도 마찬가지입니다. 이 방법은 실제로 효과가 있는 일반적인 재부팅 최소화 전략입니다.

뒤돌아 보면, Microsoft 개발 팀은 다양한 시나리오에서 재부팅 횟수를 줄이거나 없애기 위해 많은 노력을 기울여 왔습니다. 이 칼럼은 SQL Q&A 칼럼이므로 SQL Server를 예로 들겠습니다.

SQL Server 2005의 경우 SQL Server 팀은 Microsoft® Data Access Components(MDAC) 자체를 업데이트하지 않고 SQL Server에 필요한 MDAC 코드를 SQLNCLI(새 파일)로 분리하고, MDAC를 OS와 인밴드(in-band)된 상태로 되돌려 놓았습니다. 이 방법의 장점은 무엇일까요? Windows® 운영 체제는 자체적으로 MDAC를 사용하기 때문에 이들 파일을 잠긴 상태로 유지합니다. 바로 이 이유 때문에 대부분의 SQL Server 서비스 팩 및 기타 패키지에서 재부팅이 발생하는 것입니다. 하지만 이제는 SQL Server에서 OS의 사용 중인 MDAC 파일을 건드리지 않고 MDAC 버전을 업데이트할 수 있기 때문에, 재부팅이 필요 없어졌습니다.

또한 SQL Server 2005 SP1 설치 프로그램은 이제 종속성 검사기와 일시 중지 기능을 기본적으로 제공합니다. 이 기능을 사용하면 잠겨 있는 파일과 이 파일을 잠근 프로그램을 확인하고 바로 그 곳에서 파일을 잠근 응용 프로그램을 중지할 수 있으므로 재부팅 없이 설치 작업을 계속할 수 있습니다. 즉, 실시간으로 이 기능을 사용할 수 있기 때문에 테스트 환경이 필요하지 않습니다. 물론, 항상 계속해서 진행하다가 원할 경우 또는 무인 모드로 실행 중인 경우 재부팅을 수행할 수 있습니다. 이 기능을 사용하면 파일을 잠근 응용 프로그램을 파악하기가 무척 쉽다는 것을 알 수 있습니다.

또한 Microsoft Installer 기술은 기존 PFR(PendingFileRenameOperations)도 더욱 효과적으로 처리합니다. SQL Server 2000 설치 프로그램은 앞에서 설명한 레지스트리 키에 파일이 있는 경우 중단된다는 점을 기억하고 있을 것입니다. SQL Server 2005 설치 프로그램은 상당히 지능적이어서 해당 파일이 SQL Server에 속한 파일인 경우(충돌이 발생할 가능성이 있음을 나타냄)에만 중단되며, 이 경우에도 대개는 PFR 키에 접근하여 재부팅 없이 해당 키를 직접 업데이트할 수 있습니다. 이 기술의 일부는 모든 업데이트 수행에 사용되는 현재의 표준 Microsoft 설치 관리자인 MSI와 update.exe에 포함되어 있습니다.

현재 재부팅을 일으키는 것으로 알려진 파일로는 어떤 파일들이 있을까요? 가장 중요한 파일 중 하나는 MSXML3.dll입니다. 이 파일은 항상 Windows SVCHost 서비스에 의해 잠기므로 이 서비스를 포함하는 모든 프로그램은 다시 부팅해야 합니다. MDAC 스택(mdac_typ.exe) 역시 재부팅을 유발하는 주요 원인입니다. 다행히 MDAC는 Windows Server® 2003 및 Windows XP SP2 이상에서 "인밴드"되어 있습니다. SQL Server 개발 팀에서 SQL Server 업데이트로 인해 재부팅이 발생하지 않도록 msxmlsql.dll을 분리해 내는 훌륭한 성과를 이룩했지만 아직까지는 가끔씩 재부팅이 발생할 수도 있습니다. 이 경우 사용자가 할 수 있는 일은 없습니다. 즉, SVCHost를 종료하고 업데이트를 계속 실행할 수 있는 방법은 없습니다.

또한 update.exe 패키지의 제거 프로세스에 약간의 문제가 있습니다. 응용 프로그램을 제거할 경우 설치 관리자의 현재 위치에서 파일이 잠깁니다(물론 PFR 키의 파일은 아님). 이렇게 되면 재부팅을 통해 해당 잠금이 풀릴 때까지 다른 update.exe 패키지가 실행되지 않습니다. 이런 상황에서 실제로 할 수 있는 일이라고는 이 문제를 인식하고 핫픽스 제거 후 재부팅할 계획을 세우는 것뿐입니다.

간헐성 또한 문제입니다. 모든 프로그램이 파일을 일정 시간 내내 사용하는 것은 아닙니다. 실제로 공유 DLL 대부분은 특정 시점에만 사용됩니다. 즉, 공유 DLL은 다른 프로그램에서 프로그램의 작업과 코드 경로에 따라 필요한 경우에만 액세스됩니다. 다시 말해서 10번을 테스트해서 잠겨 있는 파일이 없었다고 해도, 프로덕션 배포 시점에는 잠겨 있는 파일이 있을 수 있습니다. 안타깝게도 이 문제를 해결할 수 있는 방법은 아직 없습니다. 프로덕션 환경과 되도록 동일하게 테스트 환경을 구축하고(작업 부하까지도 고려) 충분한 테스트를 수행하여 이러한 문제를 테스트 과정에서 발견해 내는 것만이 최선의 방법입니다.

OS 서비스 팩을 설치하거나 업그레이드하면 재부팅이 필요합니다. 또한 Windows 2000, Windows XP 및 그 이전 버전인 경우 pendingfilerenameoperations 레지스트리 키가 비어 있더라도 재부팅을 해야만 설치가 완료됩니다. 재부팅 중에 코드를 설치하기 위해 실행될 수 있는 예외 패키지 등록 작업이 있습니다. 이러한 작업은 서비스 팩 설치 과정의 일부는 아니지만, 사용 중인 특정 코드를 존속시키기 위해 업그레이드 시나리오에 의해 실행된, 현재 운영 체제에 포함된 명령입니다.

마지막으로 PFR 키는 파일 버전을 검사하지 않으며 직렬화를 통해 정렬을 강제로 수행하지도 않습니다. 즉, 파일의 나열 순서에 따라 파일 교체가 이루어집니다. 그러나 하드 디스크에 적용되는 순서는 마지막 파일이 완료되는 시점(첫 번째 파일이 시작되는 시점이 아님)으로 확인되었습니다. 이는 납득할 만한 시나리오지만, 만약 같은 경로에 같은 파일에 대한 두 개의 복사본이 있고 각 복사본이 다른 버전을 가리킨다면 재부팅 후의 결과를 예측하기가 어렵습니다. 따라서 이런 경우가 발생하면 올바로 수정되었는지 확인해야 합니다. 확실하지 않은 경우에는 재부팅 후에 두 설치 프로그램을 다시 실행하여 확인합니다. 올바른 파일이 설치되었으면 추가 작업은 필요하지 않습니다. 잘못된 파일이 설치된 경우에는 올바른 파일을 갖고 있는 패키지가 문제를 해결하게 됩니다. 솔직히, 이 방법이 원하는 결과를 파악하려고 시도하는 것보다 더 빠르고 안전합니다.

서비스 팩을 여러 번 설치

Q: 4 노드 클러스터에 SQL Server 2000의 클러스터형 인스턴스 8개가 있는데 최소한의 재부팅으로 SP4를 설치하고 싶습니다. 8개의 인스턴스에 차례로 SP4를 설치한 다음 마지막에 모든 노드를 재부팅할 수 있는 방법이 있습니까?

A: 클러스터형인지에 관계없이 일단 지정된 Windows 서버에 하나의 SQL Server SP4 인스턴스를 완전히 설치했다면(이때는 재부팅 필요) 같은 시스템에 있는 다른 SQL Server 인스턴스에 SQL Server SP4를 설치해도 재부팅이 발생하지 않아야 합니다. 그 이유는 모든 공유 파일(도구, MDAC, MSXML 등)이 이미 올바른 버전이므로 잠금 여부에 상관없이 추가 업데이트가 필요하지 않기 때문입니다. 모든 비공유 파일은 첫 번째 인스턴스에서만 사용되며 설치 프로그램에 의해 종료됩니다. 여러 버전의 여러 인스턴스가 존재하는 경우에는 SQL Server 의 최신 인스턴스를 가장 먼저 업데이트해야 한다는 점을 기억해 두는 것이 좋습니다.

네트워크 서비스로 실행

Q: NT AUTHORITY\NETWORK SERVICE 계정은 무엇이며 이 계정의 기본 용도는 무엇입니까? 또한 보안적인 면에서 이 계정은 어떤 의미가 있으며, 특히 sysadmin(sa) 권한이 이 계정에 부여되었다면 특별한 의미가 있는 것입니까?

A: 네트워크 서비스 계정은 네트워크에서 시스템과 동일한 ID(컴퓨터 ID)를 갖지만 로컬 시스템에 대한 권한은 제한되어 있습니다. 따라서 네트워크 리소스에 액세스해야 하는 서비스의 경우 아마도 도메인 컨트롤러를 사용하여 계정 이름을 확인하기 위해, 시스템(도메인 계정) 또는 네트워크 서비스로 실행되어야 합니다. 이 경우 네트워크 서비스는 그 범위가 로컬 시스템으로만 제한되고 해당 범위 내에서도 축소된 권한만을 가지므로 이를 선택하는 것이 일반적으로 가장 안전합니다.

SQL Server에서 네트워크 서비스에 sysadmin 권한을 부여한다는 것은 로컬 시스템에서 네트워크 서비스로 실행되는 다른 모든 서비스가 서버에 대해 모든 권한을 갖게 된다는 것을 의미합니다. 예를 들어 SQL Server 서비스 계정이 네트워크 서비스로 실행되도록 구성된 경우 이런 상황이 발생합니다. SQL Server 서비스 계정을 sysadmin의 구성원으로 만들려면 서버 기능이 필요합니다(예: 루프백 연결 허용). 네트워크 서비스를 SQL Server의 admin으로 실행하는 것이 보안상 그다지 좋은 방법은 아니지만, 같은 용도로 도메인 계정을 사용하는 것보다는 바람직할 가능성이 크며 SQL Server를 LocalSystem으로 실행하는 것보다는 훨씬 더 안전합니다.

네트워크 서비스에 sysadmin 권한을 부여하고 싶지 않을 경우 그 다음으로 선택할 수 있는 방법은 하나 이상의 Windows NT® 설치에서 SQL Server를 실행하도록 전적으로 특별히 지정된 도메인 계정을 사용하는 것입니다.

자세한 내용은 msdn.microsoft.com/library/en-us/dnpag2/html/paght000009.asp(영문) 및 microsoft.com/technet/security/topics/serversecurity/serviceaccount(영문)를 참조하십시오.

여러 데이터베이스 만들기

Q: 데이터를 개별 데이터베이스로 분할하여 최대 250개의 데이터베이스를 동시에 온라인으로 사용하려고 합니다. 이 중 20%만이 특정 시점에 활성 쿼리에 사용될 것으로 예상되는데, 데이터베이스가 많을수록 더 좋습니까?

A: 데이터베이스 서버 인스턴스 내의 데이터베이스 수는 비즈니스 요구과 관리 요인에 따라 결정해야 합니다. 단일 서버 인스턴스 내에 여러 데이터베이스를 만드는 데 들어가는 오버헤드는 거의 없지만, 데이터베이스가 많아지면 백업 및 복원, 미러링, 사용자 계정 및 사용자 역할 등의 유지 관리 작업을 위해 더 많은 관리 오버헤드가 필요합니다. 관리 작업이 복잡해진다는 바로 이 점이 추가된 데이터베이스의 장점보다 클 수 있습니다.

일반적으로 하나의 응용 프로그램과 관련된 모든 데이터는 하나의 데이터베이스에 저장해야 장애가 발생했을 때 복구하기가 쉽습니다. 응용 프로그램의 데이터가 여러 데이터베이스에 분산되어 있으면 장애 조치 중에 모든 데이터베이스를 복구해야 합니다. 이로 인해 복구가 지연될 수 있으며, 데이터베이스 중 하나가 복구하기 어려운 경우 심지어 복구 자체가 불가능할 수도 있습니다.

즉, 다음과 같이 타당한 이유가 있을 때만 데이터베이스를 여러 데이터베이스로 분리하는 것이 좋습니다.

일부 데이터의 백업 요구 사항이 다른 데이터와 다른 경우
특정 데이터에 별도의 보안 컨텍스트가 필요한 경우, 즉 데이터베이스 소유자가 다른 경우
데이터의 용도가 기록용이어서 데이터를 읽기 전용 모드로 유지해야 하는 경우

기술적 자문을 주신 Microsoft IT 전문가: Ramon Arjona, Frank De Waelle, Robert Djabarov, Herman Learmond-Criqui, Maxwell Myrick, Ruslan Ovechkin, Uttam Parui, Shashi Ramaka, Gary Roos, Gavin Sharpe, Vijay Sirohi, Jimmie Thompson 및 Madhusudhanan Vadlamaani

Nancy Michell 편집

추가 리소스