다른 서버 인스턴스에서 데이터베이스를 사용할 수 있도록 할 때 메타데이터 관리(SQL Server)
이 항목에는 다음과 관련된 내용이 포함되어 있습니다.
AlwaysOn 가용성 그룹 가용성 그룹의 가용성 복제본을 구성하는 경우
데이터베이스에 대해 데이터베이스 미러링을 설정하는 경우
로그 전달 구성에서 주 서버와 보조 서버 간에 역할 변경을 준비하는 경우
데이터베이스를 다른 서버 인스턴스로 복원하는 경우
다른 서버 인스턴스에서 데이터베이스 복사본을 연결하는 경우
일부 응용 프로그램은 단일 사용자 데이터베이스 범위 밖에 있는 정보, 엔터티 및/또는 개체에 따라 달라집니다. 일반적으로 응용 프로그램은 master 및 msdb 데이터베이스뿐만 아니라 사용자 데이터베이스에 따라 달라집니다. 사용자 데이터베이스의 올바른 작동을 위해 해당 데이터베이스 외부에 저장되어 있는 모든 요소는 대상 서버 인스턴스에서 사용할 수 있어야 합니다. 예를 들어 응용 프로그램에 대한 로그인은 master 데이터베이스에서 메타데이터로 저장되어 있으며 대상 서버에서 다시 생성되어야 합니다. 메타데이터가 msdb 데이터베이스에 저장되어 있는 SQL Server 에이전트 작업에 따라 응용 프로그램이나 데이터베이스 유지 관리 계획이 달라지는 경우 대상 서버 인스턴스에서 이러한 작업을 다시 만들어야 합니다. 마찬가지로 서버 수준 트리거에 대한 메타데이터는 master에 저장되어 있습니다.
응용 프로그램에 대한 데이터베이스를 다른 서버 인스턴스로 이동할 경우 대상 서버 인스턴스의 master 및 msdb에서 종속 개체와 엔터티의 모든 메타데이터를 다시 만들어야 합니다. 예를 들어 데이터베이스 응용 프로그램이 서비스 수준 트리거를 사용하는 경우 단순히 새 시스템에서 데이터베이스를 연결하거나 복원하는 것만으로 충분하지 않습니다. master 데이터베이스에서 이러한 트리거에 대한 모든 메타데이터를 수동으로 다시 만들지 않으면 데이터베이스가 예상대로 작동하지 않습니다.
사용자 데이터베이스의 외부에 저장된 정보, 엔터티 및 개체
이 항목의 나머지에서는 다른 서버 인스턴스에서 사용되는 데이터베이스에 영향을 줄 수 있는 발생 가능한 문제에 대해 요약합니다. 다음 목록에 나열된 하나 또는 그 이상의 정보, 엔터티 또는 개체 유형을 다시 만들어야 할 수 있습니다. 요약을 보려면 항목의 링크를 클릭합니다.
서버 구성 설정
자격 증명
데이터베이스 간 쿼리
데이터베이스 소유권
분산 쿼리/연결된 서버
암호화된 데이터
사용자 정의 오류 메시지
이벤트 알림 및 WMI(Windows Management Instrumentation) 이벤트(서버 수준)
확장 저장 프로시저
SQL Server용 전체 텍스트 엔진 속성
작업
로그인
사용 권한
복제 설정
Service Broker 응용 프로그램
시작 프로시저
트리거(서버 수준)
서버 구성 설정
SQL Server 2005 이상 버전에서는 키 서비스 및 기능을 필요에 따라 설치하고 시작합니다. 이를 통해 시스템이 공격 받을 수 있는 노출 영역을 줄일 수 있습니다. 새 설치의 기본 구성에서는 많은 기능이 활성화되지 않습니다. 데이터베이스가 기본적으로 해제된 서비스나 기능을 사용하는 경우 대상 서버 인스턴스에서 이 서비스나 기능을 설정해야 합니다.
이러한 설정에 대한 자세한 내용과 설정을 지정하거나 해제하는 방법은 서버 구성 옵션을 참조하십시오.
[맨 위]
자격 증명
자격 증명은 SQL Server 외부의 리소스에 연결하는 데 필요한 인증 정보가 포함된 레코드입니다. 대부분의 자격 증명은 Windows 로그인 및 암호로 구성됩니다.
이 기능에 대한 자세한 내용은 자격 증명(데이터베이스 엔진)을 참조하십시오.
[!참고]
SQL Server 에이전트 프록시 계정은 자격 증명을 사용합니다. 프록시 계정의 자격 증명 ID를 확인하려면 sysproxies 시스템 테이블을 사용하십시오.
[맨 위]
데이터베이스 간 쿼리
DB_CHAINING 및 TRUSTWORTHY 데이터베이스 옵션은 기본적으로 OFF입니다. 원래 데이터베이스에 대해 이러한 옵션 중 하나가 ON으로 설정되어 있으면 대상 서버 인스턴스의 데이터베이스에서 해당 옵션을 설정해야 할 수도 있습니다. 자세한 내용은 ALTER DATABASE(Transact-SQL)를 참조하십시오.
연결 및 분리 작업을 수행하면 해당 데이터베이스의 데이터베이스 간 소유권 체인을 사용할 수 없게 됩니다. 체인을 사용하도록 설정하는 방법은 cross db ownership chaining 서버 구성 옵션을 참조하십시오.
자세한 내용은 Trustworthy 속성을 사용하도록 미러 데이터베이스 설정(Transact-SQL)을 참조하십시오.
[맨 위]
데이터베이스 소유권
데이터베이스를 다른 컴퓨터에서 복원하는 경우 복원 작업을 시작한 Windows 사용자 또는 SQL Server 로그인이 자동으로 새 데이터베이스 소유자가 됩니다. 데이터베이스를 복원할 때 시스템 관리자나 새 데이터베이스 소유자는 데이터베이스 소유권을 변경할 수 있습니다.
분산 쿼리 및 연결된 서버
분산 쿼리와 연결된 서버는 OLE DB 응용 프로그램에 대해 지원됩니다. 분산 쿼리는 같은 컴퓨터나 다른 컴퓨터에 있는 유형이 다른 여러 데이터 원본의 데이터에 액세스합니다. 연결된 서버를 구성하면 SQL Server에서 원격 서버에 있는 OLE DB 데이터 원본에 대해 명령을 실행할 수 있습니다. 이러한 기능에 대한 자세한 내용은 연결된 서버(데이터베이스 엔진)을 참조하십시오.
[맨 위]
암호화된 데이터
다른 서버 인스턴스에서 사용할 수 있도록 할 데이터베이스에 암호화된 데이터가 있으며 데이터베이스 마스터 키가 원래 서버의 서비스 마스터 키로 보호되는 경우 서비스 마스터 키 암호화를 다시 만들어야 할 수도 있습니다. 데이터베이스 마스터 키는 암호화된 데이터베이스에 있는 인증서의 개인 키와 비대칭 키를 보호하는 데 사용되는 대칭 키입니다. 데이터베이스 마스터 키는 생성 시에 Triple DES 알고리즘 및 사용자 제공 암호를 사용하여 암호화됩니다.
서버 인스턴스에서 데이터베이스 마스터 키의 자동 암호 해독을 설정하기 위해 서비스 마스터 키를 사용하여 이 키의 복사본을 암호화합니다. 이 암호화된 복사본은 해당 데이터베이스와 master에 모두 저장됩니다. 일반적으로 master에 저장된 복사본은 마스터 키가 변경될 때마다 자동으로 업데이트됩니다. SQL Server는 먼저 인스턴스의 서비스 마스터 키로 데이터베이스 마스터 키의 암호를 해독하려고 시도합니다. 암호 해독에 실패하면 SQL Server는 마스터 키가 필요한 데이터베이스와 패밀리 GUID가 동일한 마스터 키 자격 증명을 자격 증명 저장소에서 검색합니다. 그런 다음 SQL Server는 암호 해독이 성공하거나 남은 자격 증명이 없을 때까지 일치하는 각 자격 증명을 사용하여 데이터베이스 마스터 키의 암호화를 해독하려고 시도합니다. 서비스 마스터 키를 사용하여 암호화되지 않은 마스터 키는 OPEN MASTER KEY 문과 암호를 사용하여 열어야 합니다.
암호화된 데이터베이스를 복사 또는 복원하거나 새로운 SQL Server 인스턴스에 연결할 때는 서비스 마스터 키로 암호화된 데이터베이스 마스터 키의 복사본이 대상 서버 인스턴스의 master에 저장되지 않습니다. 대상 서버 인스턴스에서 해당 데이터베이스의 마스터 키를 열어야 합니다. 마스터 키를 열려면 OPEN MASTER KEY DECRYPTION BY PASSWORD = **'password'**를 실행합니다. 그런 다음 ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY 문을 실행하여 데이터베이스 마스터 키의 자동 암호 해독을 설정하는 것이 좋습니다. 이 ALTER MASTER KEY 문은 서비스 마스터 키로 암호화된 데이터베이스 마스터 키의 복사본을 서버 인스턴스에 제공합니다. 자세한 내용은 OPEN MASTER KEY(Transact-SQL) 및 ALTER MASTER KEY(Transact-SQL)를 참조하십시오.
미러 데이터베이스의 데이터베이스 마스터 키 자동 암호 해독을 설정하는 방법은 암호화된 미러 데이터베이스 설정을 참조하십시오.
자세한 내용은 다음 항목을 참조하십시오.
[맨 위]
사용자 정의 오류 메시지
사용자 정의 오류 메시지는 sys.messages 카탈로그 뷰에 있습니다. 이 카탈로그 뷰는 master에 저장됩니다. 데이터베이스 응용 프로그램이 사용자 정의 오류 메시지를 사용하며 다른 서버 인스턴스에서 데이터베이스를 사용할 수 있는 경우 sp_addmessage를 사용하여 대상 서버 인스턴스에서 이러한 사용자 정의 메시지를 추가합니다.
[맨 위]
이벤트 알림 및 WMI(Windows Management Instrumentation) 이벤트(서버 수준)
서버 수준 이벤트 알림
서버 수준 이벤트 알림은 msdb에 저장됩니다. 그러므로 데이터베이스 응용 프로그램이 서버 수준 이벤트 알림을 사용하는 경우 대상 서버 인스턴스에서 해당 이벤트 알림을 다시 만들어야 합니다. 서버 인스턴스의 이벤트 알림을 보려면 sys.server_event_notifications 카탈로그 뷰를 사용합니다. 자세한 내용은 이벤트 알림을 참조하십시오.
또한 이벤트 알림은 Service Broker를 사용하여 배달됩니다. 들어오는 메시지에 대한 경로는 서비스가 포함된 데이터베이스에 포함되지 않습니다. 대신 명시적인 경로는 msdb에 저장됩니다. 서비스가 msdb 데이터베이스에서 명시적인 경로를 사용하여 들어오는 메시지를 서비스에 라우팅하는 경우 다른 인스턴스에서 데이터베이스를 연결할 때 이 경로를 다시 만들어야 합니다.
WMI(Windows Management Instrumentation) 이벤트
서버 이벤트용 WMI 공급자는 WMI(Windows Management Instrumentation)를 사용하여 SQL Server의 이벤트를 모니터링할 수 있도록 합니다. 데이터베이스가 사용하는 WMI 공급자를 통해 표시된 서버 수준 이벤트를 사용하는 응용 프로그램은 대상 서버 인스턴스의 컴퓨터에서 정의해야 합니다. WMI 이벤트 공급자는 msdb에서 정의한 대상 서비스로 이벤트 알림을 만듭니다.
[!참고]
자세한 내용은 서버 이벤트용 WMI 공급자 개념를 참조하십시오.
SQL Server Management Studio를 사용하여 WMI 경고를 만들려면
미러된 데이터베이스에 대한 이벤트 알림의 작동 방식
미러된 데이터베이스를 포함하는 이벤트 알림의 데이터베이스 간 배달은 미러된 데이터베이스가 장애 조치(Failover)될 수 있으므로 정의상 원격일 수밖에 없습니다. Service Broker는 미러된 경로의 형태로 미러된 데이터베이스에 대해 특별한 지원을 제공합니다. 미러된 경로에는 두 개의 주소가 있습니다. 하나는 주 서버 인스턴스에 대한 주소이며 다른 하나는 미러 서버 인스턴스에 대한 주소입니다.
미러된 경로를 설정하여 Service Broker 라우팅에서 데이터베이스 미러링을 인식하도록 지정할 수 있습니다. 미러된 경로를 사용하여 Service Broker에서 현재 주 서버 인스턴스에 대화를 투명하게 리디렉션할 수 있습니다. 예를 들어 미러된 데이터베이스인 Database_A가 Service_A라는 서비스를 호스팅하는데 이 Service_A와 대화를 하기 위해 Database_B가 호스팅하는 Service_B라는 다른 서비스가 필요한 경우 이 대화를 가능하게 하려면 Database_B에 Service_A에 대해 미러된 경로가 포함되어야 합니다. 또한 Database_A에 로컬 경로와는 달리 장애 조치(Failover) 후에 유효한 상태로 남아 있는 Service_B에 대한 미러되지 않은 TCP 전송 경로가 포함되어야 합니다. 이러한 경로로 인해 ACK가 장애 조치 후에 원래 상태로 돌아옵니다. 보낸 사람의 서비스는 항상 동일한 방식으로 명명되므로 경로는 Broker 인스턴스를 지정해야 합니다.
미러된 경로에 대한 요구 사항은 미러된 데이터베이스의 서비스가 시작자 서비스인지 대상 서비스인지에 관계없이 적용합니다.
대상 서비스가 미러된 데이터베이스에 있으면 시작자 서비스는 미러된 경로를 대상으로 되돌려야 합니다. 그러나 대상이 정규 경로를 시작자로 되돌릴 수 있습니다.
시작자 서비스가 미러된 데이터베이스에 있으면 대상 서비스는 승인 및 응답을 배달하기 위해 미러된 경로를 시작자로 되돌려야 합니다. 그러나 시작자가 정규 경로를 대상으로 되돌릴 수 있습니다.
[맨 위]
확장 저장 프로시저
.gif "중요 정보") 중요 |
|---|
Microsoft SQL Server의 이후 버전에서는 이 기능이 제거됩니다. 새 개발 작업에서는 이 기능을 사용하지 않도록 하고, 현재 이 기능을 사용하는 응용 프로그램은 수정하십시오. 대신 CLR 통합을 사용하십시오. |
확장 저장 프로시저는 SQL Server 확장 저장 프로시저 API를 사용하여 프로그래밍합니다. sysadmin 고정 서버 역할의 멤버는 SQL Server 인스턴스에 확장 저장 프로시저를 등록하고 사용자에게 이 프로시저를 실행할 권한을 부여할 수 있습니다. master 데이터베이스에만 확장 저장 프로시저를 추가할 수 있습니다.
확장 저장 프로시저는 SQL Server 인스턴스의 주소 공간에서 직접 실행되며 메모리 손실 및 서버의 성능과 안정성을 저하시키는 다른 문제를 유발할 수 있습니다. 참조되는 데이터가 들어 있는 인스턴스와는 별도의 SQL Server 인스턴스에 확장 저장 프로시저를 저장해야 합니다. 또한 분산 쿼리를 사용하여 데이터베이스에 액세스해야 합니다.
| 중요 |
|---|
시스템 관리자는 확장 저장 프로시저를 서버에 추가하고 다른 사용자에게 EXECUTE 권한을 부여하기 전에 각 확장 저장 프로시저를 철저히 검토하여 유해한 악성 코드가 포함되지는 않았는지를 확인해야 합니다. |
자세한 내용은 GRANT 개체 사용 권한(Transact-SQL), DENY 개체 사용 권한(Transact-SQL) 및 REVOKE 개체 사용 권한(Transact-SQL)을 참조하십시오.
[맨 위]
SQL Server용 전체 텍스트 엔진 속성
속성은 sp_fulltext_service에 의해 전체 텍스트 엔진에 설정됩니다. 대상 서버 인스턴스에 해당 속성에 필요한 설정이 있는지 확인합니다. 이러한 속성에 대한 자세한 내용은 FULLTEXTSERVICEPROPERT(Transact-SQL)를 참조하십시오.
또한 원래 서버 인스턴스와 대상 서버 인스턴스에 있는 단어 분리기 및 형태소 분석기 구성 요소 또는 전체 텍스트 검색 필터 구성 요소의 버전이 서로 다르면 전체 텍스트 인덱스 및 쿼리가 다르게 동작할 수 있습니다. 또한 동의어 사전은 인스턴스별 파일에 저장됩니다. 이러한 파일의 복사본을 대상 서버 인스턴스의 해당 위치로 전송하거나 새 인스턴스에서 다시 만들어야 합니다.
[!참고]
SQL Server 2012 서버 인스턴스에 전체 텍스트 카탈로그 파일이 포함된 SQL Server 2005 데이터베이스를 연결할 경우 SQL Server 2005에서와 같이 다른 데이터베이스 파일과 함께 이전 위치에서 카탈로그 파일이 연결됩니다. 자세한 내용은 SQL Server 2005에서 전체 텍스트 검색 업그레이드를 참조하십시오.
자세한 내용은 다음 항목을 참조하십시오.
[맨 위]
작업
데이터베이스에서 SQL Server 에이전트 작업을 사용하는 경우 대상 서버 인스턴스에서 해당 작업을 다시 만들어야 합니다. 작업은 해당 환경에 따라 달라집니다. 대상 서버 인스턴스에서 기존 작업을 다시 만드는 경우 원래 서버 인스턴스의 작업 환경과 일치하도록 대상 서버 인스턴스를 수정해야 할 수도 있습니다. 중요한 환경 요소는 다음과 같습니다.
작업에 사용되는 로그인
SQL Server 에이전트 작업을 만들거나 실행하려면 먼저 작업에 필요한 모든 SQL Server 로그인을 대상 서버 인스턴스에 추가해야 합니다. 자세한 내용은 SQL Server 에이전트 작업을 만들고 관리하도록 사용자 구성을 참조하십시오.
SQL Server 에이전트 서비스 시작 계정
서비스 시작 계정은 SQL Server 에이전트를 실행하는 Microsoft Windows 계정과 해당 네트워크 사용 권한을 정의합니다. SQL Server 에이전트는 지정된 사용자 계정으로 실행됩니다. 에이전트 서비스의 컨텍스트는 작업과 실행 환경에 대한 설정에 영향을 줍니다. 계정이 작업에 필요한 네트워크 공유 등의 리소스에 액세스할 수 있어야 합니다. 서비스 시작 계정을 선택하고 수정하는 방법은 SQL Server 에이전트 서비스의 계정 선택을 참조하십시오.
서비스 시작 계정이 올바르게 작동하려면 올바른 도메인, 파일 시스템 및 레지스트리 권한을 구성해야 합니다. 서비스 계정에 대해 구성해야 하는 공유 네트워크 리소스가 작업에 필요할 수도 있습니다. 자세한 내용은 Windows 서비스 계정 및 권한 구성을 참조하십시오.
특정 SQL Server 인스턴스에 연결된 SQL Server 에이전트 서비스에는 자체 레지스트리 하이브가 있으며 일반적으로 해당 작업은 이 레지스트리 하이브의 하나 또는 그 이상의 설정에 종속되어 있습니다. 작업이 의도한 대로 동작하려면 이러한 레지스트리 설정이 필요합니다. 스크립트를 사용하여 다른 SQL Server 에이전트 서비스에서 작업을 다시 만들면 해당 작업에 대한 레지스트리 설정이 올바르지 않을 수 있습니다. 다시 만든 작업이 대상 서버 인스턴스에서 올바르게 동작하려면 원래 SQL Server 에이전트 서비스와 대상 SQL Server 에이전트 서비스의 레지스트리 설정이 같아야 합니다.
주의현재 설정이 다른 작업에 필요한 경우 다시 만든 작업을 처리하기 위해 대상 SQL Server 에이전트 서비스의 레지스트리 설정을 변경하는 것이 문제가 될 수 있습니다. 또한 레지스트리를 올바르게 편집하지 않으면 시스템에 심각한 손상을 줄 수 있습니다. 따라서 레지스트리를 변경하기 전에 컴퓨터의 중요한 데이터는 백업해 두는 것이 좋습니다.
SQL Server 에이전트 프록시
SQL Server 에이전트 프록시는 지정된 작업 단계의 보안 컨텍스트를 정의합니다. 작업이 대상 서버 인스턴스에서 실행되려면 해당 인스턴스에서 수동으로 필요한 모든 프록시를 다시 만들어야 합니다. 자세한 내용은 SQL Server 에이전트 프록시 만들기 및 프록시를 사용하는 다중 서버 작업 문제 해결을 참조하십시오.
자세한 내용은 다음 항목을 참조하십시오.
역할 전환 후 로그인 및 작업 관리(SQL Server)(데이터베이스 미러링)
Windows 서비스 계정 및 권한 구성(SQL Server 인스턴스를 설치하는 경우)
SQL Server 에이전트 구성(SQL Server 인스턴스를 설치하는 경우)
기존 작업과 해당 속성을 보려면
작업을 만들려면
스크립트를 사용하여 작업을 다시 만드는 최상의 방법
먼저 간단한 작업을 스크립팅하고 다른 SQL Server 에이전트 서비스에서 작업을 다시 만든 다음 작업을 실행하여 의도한 대로 작동하는지 확인하는 것이 좋습니다. 이렇게 하면 비호환성을 확인하고 해결할 수 있습니다. 스크립팅한 작업이 새 환경에서 의도한 대로 작동하지 않을 경우 이와 동등하면서 해당 환경에서 올바르게 작동하는 작업을 만드는 것이 좋습니다.
[맨 위]
로그인
SQL Server 인스턴스에 로그인하려면 올바른 SQL Server 로그인이 필요합니다. 이 로그인은 보안 주체가 SQL Server 인스턴스에 연결할 수 있는지 여부를 확인하는 인증 프로세스에서 사용됩니다. 해당 SQL Server 로그인이 서버 인스턴스에서 정의되지 않았거나 잘못 정의되어 있는 데이터베이스 사용자는 이 인스턴스에 로그인할 수 없습니다. 이러한 사용자는 해당 서버 인스턴스에 있는 데이터베이스의 분리된 사용자라고 합니다. 데이터베이스가 다른 SQL Server 인스턴스에 복원, 연결 또는 복사된 후에도 데이터베이스 사용자가 분리될 수 있습니다.
데이터베이스의 원래 복사본에 있는 일부 또는 모든 개체에 대해 스크립트를 생성하려면 스크립트 생성 마법사를 사용하고 스크립트 옵션 선택 대화 상자에서 로그인 스크립팅 옵션을 True로 설정합니다.
[!참고]
미러된 데이터베이스에 대한 로그인을 설정하는 방법은 데이터베이스 미러링 또는 AlwaysOn 가용성 그룹에 대한 로그인 계정 설정(SQL Server) 및 역할 전환 후 로그인 및 작업 관리(SQL Server)를 참조하십시오.
[맨 위]
사용 권한
데이터베이스를 다른 서버 인스턴스에서 사용할 수 있을 때 다음의 사용 권한 유형이 영향을 받을 수 있습니다.
시스템 개체에 대한 GRANT, REVOKE 또는 DENY 권한
서버 인스턴스에 대한 GRANT, REVOKE 또는 DENY 권한(서버 수준 사용 권한)
시스템 개체에 대한 GRANT, REVOKE 또는 DENY 권한
저장 프로시저, 확장 저장 프로시저, 함수 및 뷰와 같은 시스템 개체에 대한 사용 권한은 master 데이터베이스에 저장되며 대상 서버 인스턴스에서 구성해야 합니다.
데이터베이스의 원래 복사본에 있는 일부 또는 모든 개체에 대해 스크립트를 생성하려면 스크립트 생성 마법사를 사용하고 스크립트 옵션 선택 대화 상자에서 개체 수준 사용 권한 스크립팅 옵션을 True로 설정합니다.
| 중요 |
|---|
로그인을 스크립팅하는 경우 암호는 스크립팅되지 않습니다. SQL Server 인증을 사용하는 로그인이 있으면 대상에서 스크립트를 수정해야 합니다. |
시스템 개체는 sys.system_objects 카탈로그 뷰에 표시됩니다. 시스템 개체에 대한 사용 권한은 master 데이터베이스의 sys.database_permissions 카탈로그 뷰에 표시됩니다. 이러한 카탈로그 뷰를 쿼리하고 시스템 개체 사용 권한을 부여하는 방법은 GRANT 시스템 개체 사용 권한(Transact-SQL)을 참조하십시오. 자세한 내용은 REVOKE 시스템 개체 사용 권한(Transact-SQL) 및 DENY 시스템 개체 사용 권한(Transact-SQL)을 참조하십시오.
서버 인스턴스에 대한 GRANT, REVOKE 또는 DENY 권한
서버 범위의 사용 권한은 master 데이터베이스에 저장되며 대상 서버 인스턴스에서 구성해야 합니다. 서버 인스턴스의 서버 사용 권한에 대한 자세한 내용을 보려면 sys.server_permissions 카탈로그 뷰를 쿼리하십시오. 서버 보안 주체에 대한 자세한 내용을 보려면 sys.server_principals 카탈로그 뷰를 쿼리하십시오. 서버 역할의 멤버 자격에 대한 자세한 내용을 보려면 sys.server_role_members 카탈로그 뷰를 쿼리하십시오.
자세한 내용은 GRANT 서버 사용 권한(Transact-SQL), REVOKE 서버 사용 권한(Transact-SQL) 및 DENY 서버 사용 권한(Transact-SQL)을 참조하십시오.
인증서 또는 비대칭 키에 대한 서버 수준 사용 권한
인증서 또는 비대칭 키에 직접 서버 수준 사용 권한을 부여할 수는 없습니다. 대신 서버 수준 사용 권한은 특정 인증서나 비대칭 키 전용으로 만든 매핑된 로그인에 부여됩니다. 그러므로 서버 수준 사용 권한이 필요한 각 인증서 또는 비대칭 키에 해당 인증서 매핑 로그인이나 비대칭 키 매핑 로그인이 필요합니다. 인증서나 비대칭 키에 서버 수준 사용 권한을 부여하려면 해당 매핑된 로그인에 사용 권한을 부여합니다.
[!참고]
매핑된 로그인은 해당 인증서나 비대칭 키로 서명된 코드의 권한 부여를 위해서만 사용됩니다. 매핑된 로그인은 인증에 사용할 수 없습니다.
매핑된 로그인과 해당 사용 권한은 모두 master에 있습니다. 인증서나 비대칭 키가 master 이외의 데이터베이스에 있을 경우 master에서 다시 만들어 로그인에 매핑해야 합니다. 데이터베이스를 다른 서버 인스턴스로 이동, 복사 또는 복원하는 경우 대상 서버 인스턴스의 master 데이터베이스에서 해당 인증서나 비대칭 키를 다시 만들어 로그인에 매핑한 다음 필요한 서버 수준 사용 권한을 로그인에 부여해야 합니다.
인증서나 비대칭 키를 만들려면
인증서나 비대칭 키를 로그인에 매핑하려면
매핑된 로그인에 사용 권한을 할당하려면
인증서 및 비대칭 키에 대한 자세한 내용은 암호화 계층을 참조하십시오.
[맨 위]
복제 설정
복제된 데이터베이스의 백업을 다른 서버 또는 데이터베이스로 복원할 경우 복제 설정은 유지되지 않습니다. 이 경우 백업 복원 후 모든 게시 및 구독을 다시 만들어야 합니다. 이 프로세스를 간단하게 하려면 현재 복제 설정과 복제 설정 및 해제에 대한 스크립트를 만듭니다. 편리하게 복제 설정을 다시 만들려면 이러한 스크립트를 복사하고 대상 서버 인스턴스에서 작동하도록 서버 이름 참조를 변경합니다.
자세한 내용은 복제된 데이터베이스 백업 및 복원, 데이터베이스 미러링 및 복제(SQL Server) 및 로그 전달 및 복제(SQL Server)을 참조하십시오.
[맨 위]
Service Broker 응용 프로그램
Service Broker 응용 프로그램의 많은 부분이 데이터베이스와 함께 이동됩니다. 그러나 응용 프로그램의 일부분은 새 위치에서 다시 만들거나 다시 구성해야 합니다.
[맨 위]
시작 프로시저
시작 프로시저는 자동 실행되도록 표시되었으며 SQL Server가 시작될 때마다 실행되는 저장 프로시저입니다. 데이터베이스가 시작 프로시저에 따라 달라지는 경우 대상 서버 인스턴스에서 해당 프로시저를 정의하고 시작 시 자동으로 실행되도록 구성해야 합니다.
[맨 위]
트리거(서버 수준)
DDL 트리거는 다양한 DDL(데이터 정의 언어) 이벤트에 대한 응답으로 저장 프로시저를 실행합니다. 이러한 이벤트는 주로 CREATE, ALTER 및 DROP 키워드로 시작하는 Transact-SQL 문에 해당합니다. DDL과 같은 작업을 수행하는 특정 시스템 저장 프로시저에서 DDL 트리거가 발생할 수도 있습니다.
이 기능에 대한 자세한 내용은 DDL 트리거를 참조하십시오.
[맨 위]
참고 항목
개념
로그 전달 보조 데이터베이스로 장애 조치(Failover)(SQL Server)