다른 서버에서 데이터베이스를 사용할 수 있도록 지원할 때 메타데이터 관리

  • 아티클

적용 대상:SQL Server

이 문서는 다음과 같은 상황과 관련이 있습니다.

  • Always On 가용성 그룹 가용성 그룹의 가용성 복제본 구성

  • 데이터베이스에 대해 데이터베이스 미러링을 설정하는 경우

  • 로그 전달 구성에서 주 서버와 보조 서버 간에 역할 변경을 준비하는 경우

  • 데이터베이스를 다른 서버 인스턴스로 복원하는 경우

  • 다른 서버 인스턴스에 데이터베이스 복사본 연결

  • 메서드를 사용하여 데이터베이스 엔진 업그레이드 수행 - 새 설치로 마이그레이션

  • 데이터베이스를 Azure SQL로 마이그레이션(Virtual Machine 또는 Managed Instance)

일부 애플리케이션은 단일 사용자 데이터베이스 범위 밖에 있는 정보, 엔터티 및/또는 개체에 따라 달라집니다. 일반적으로 애플리케이션은 master 및 msdb 데이터베이스뿐만 아니라 사용자 데이터베이스에 따라 달라집니다. 사용자 데이터베이스의 올바른 작동을 위해 해당 데이터베이스 외부에 저장되어 있는 모든 요소는 대상 서버 인스턴스에서 사용할 수 있어야 합니다. 예를 들어 애플리케이션에 대한 로그인은 master 데이터베이스에서 메타데이터로 저장되어 있으며 대상 서버에서 다시 생성되어야 합니다. 메타데이터가 msdb 데이터베이스에 저장되어 있는 SQL Server 에이전트 작업에 따라 애플리케이션이나 데이터베이스 유지 관리 계획이 달라지는 경우 대상 서버 인스턴스에서 이러한 작업을 다시 만들어야 합니다. 마찬가지로 서버 수준 트리거에 대한 메타데이터는 master에 저장되어 있습니다.

애플리케이션의 데이터베이스를 다른 서버 인스턴스로 이동할 경우 대상 서버 인스턴스의 master 및 msdb에서 종속 개체와 엔터티의 모든 메타데이터를 다시 만들어야 합니다. 예를 들어 데이터베이스 애플리케이션이 서비스 수준 트리거를 사용하는 경우 단순히 새 시스템에서 데이터베이스를 연결하거나 복원하는 것만으로 충분하지 않습니다. master 데이터베이스에서 이러한 트리거에 대한 모든 메타데이터를 수동으로 다시 만들지 않으면 데이터베이스가 예상대로 작동하지 않습니다.

사용자 데이터베이스의 외부에 저장된 정보, 엔터티, 개체

이 문서의 나머지에서는 다른 서버 인스턴스에서 사용 가능한 데이터베이스에 영향을 줄 수 있는 발생 가능한 문제를 요약합니다. 다음 목록에 나열된 하나 또는 그 이상의 정보, 엔터티 또는 개체 유형을 다시 만들어야 할 수 있습니다. 요약 내용을 보려면 항목의 링크를 선택합니다.

서버 구성 설정

SQL Server 2005(9.x) 이상 버전에서는 주요 서비스 및 기능을 필요에 따라 설치하고 시작합니다. 이를 통해 시스템이 공격 받을 수 있는 노출 영역을 줄일 수 있습니다. 새 설치의 기본 구성에서는 많은 기능이 활성화되지 않습니다. 데이터베이스가 기본값으로 꺼져 있는 서비스 또는 기능을 사용하는 경우 대상 서버 인스턴스에서 이 서비스 또는 기능을 사용하도록 설정해야 합니다.

이러한 설정에 대한 자세한 내용과 설정의 활성화 또는 비활성화 방법은 서버 구성 옵션(SQL Server)을 참조하세요.

자격 증명

자격 증명은 SQL Server 외부의 리소스에 연결하는 데 필요한 인증 정보가 포함된 레코드입니다. 대부분의 자격 증명은 Windows 로그인과 비밀번호로 구성됩니다.

이 기능에 대한 자세한 내용은 자격 증명(데이터베이스 엔진)을 참조하세요.

참고 항목

SQL Server 에이전트 프록시 계정은 자격 증명을 사용합니다. 프록시 계정의 자격 증명 ID를 알아보려면 sysproxies 시스템 테이블을 사용합니다.

데이터베이스 간 쿼리

DB_CHAINING 및 TRUSTWORTHY 데이터베이스 옵션은 기본값으로 OFF입니다. 이 중 하나가 원래 데이터베이스에 대해 ON으로 설정된 경우 대상 서버 인스턴스의 데이터베이스에서 활성화해야 할 수 있습니다. 자세한 내용은 ALTER DATABASE(Transact-SQL)를 참조하세요.

연결 및 분리 작업을 수행하면 해당 데이터베이스의 데이터베이스 간 소유권 체인을 사용할 수 없게 됩니다. 체인 사용 설정 방법에 대한 자세한 내용은 데이터베이스 간 소유권 체인 서버 구성 옵션을 참조하세요.

자세한 내용은 Trustworthy 속성을 사용하도록 미러 데이터베이스 설정(Transact-SQL)을 참조하세요.

데이터베이스 소유권

데이터베이스가 다른 컴퓨터에서 복원되면 복원 작업을 시작한 SQL Server 로그인 또는 Windows 사용자가 자동으로 새 데이터베이스의 소유자가 됩니다. 데이터베이스가 복원되면 시스템 관리자 또는 새 데이터베이스 소유자가 데이터베이스 소유권을 변경할 수 있습니다.

분산 쿼리 및 연결된 서버

분산 쿼리와 연결된 서버는 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 카탈로그 뷰를 사용합니다. 자세한 내용은 Event Notifications을 참조하세요.

또한 이벤트 알림은 Service Broker를 사용하여 제공됩니다. 들어오는 메시지에 대한 경로는 서비스를 포함하는 데이터베이스에 포함되지 않습니다. 대신 명시적인 경로는 msdb에 저장됩니다. 서비스가 msdb 데이터베이스에서 명시적인 경로를 사용하여 들어오는 메시지를 서비스에 라우팅하는 경우 다른 인스턴스에서 데이터베이스를 연결할 때 이 경로를 다시 만들어야 합니다.

WMI(Windows Management Instrumentation) 이벤트

서버 이벤트용 WMI 공급자를 통해 WMI(Windows Management Instrumentation)를 사용하여 SQL Server의 이벤트를 모니터링할 수 있습니다. 데이터베이스가 사용하는 WMI 공급자를 통해 표시된 서버 수준 이벤트를 사용하는 애플리케이션은 대상 서버 인스턴스의 컴퓨터에서 정의해야 합니다. WMI 이벤트 공급자는 msdb에 정의된 대상 서비스를 사용하여 이벤트 알림을 만듭니다.

참고 항목

자세한 내용은 WMI Provider for Server Events 개념을 참조하세요.

SQL Server Management Studio를 사용하여 WMI 경고 만들기

미러 데이터베이스에 대한 이벤트 알림 작동 방식

미러 데이터베이스가 장애 조치(failover)될 수 있으므로 미러 데이터베이스와 관련된 이벤트 알림의 데이터베이스 간 제공은 정의상 원격입니다. Service Broker는 미러된 경로의 형태로 미러 데이터베이스에 대해 특별한 지원을 제공합니다. 미러 경로에는 주 서버 인스턴스용 주소와 미러 서버 인스턴스용 주소의 두 가지 주소가 있습니다.

미러 경로를 설정하면 Service Broker 라우팅에서 데이터베이스 미러링을 인식할 수 있습니다. 미러 경로를 사용하면 Service Broker가 대화를 현재 주 서버 인스턴스로 투명하게 리디렉션할 수 있습니다. 예를 들어 미러 데이터베이스(Database_A)에서 호스팅하는 서비스(Service_A)를 고려합니다. Database_B가 호스팅하는 다른 서비스(Service_B)는 Service_A와의 대화가 필요하다고 가정합니다. 이 대화가 가능하려면 Database_B에 Service_A에 대한 미러 경로가 포함되어야 합니다. 또한 Database_A는 장애 조치(failover) 후 유효한 상태로 유지되는 로컬 경로와 달리 Service_B에 대한 미러되지 않은 TCP 전송 경로를 포함해야 합니다. 이러한 경로를 사용하면 장애 조치(failover) 후 ACK가 다시 돌아올 수 있습니다. 보낸 사람의 서비스는 항상 동일한 방식으로 명명되므로 경로는 Broker 인스턴스를 지정해야 합니다.

미러 경로에 대한 요구 사항은 미러 데이터베이스의 서비스가 초기자 서비스인지 대상 서비스인지 여부와 관계없이 적용됩니다.

  • 대상 서비스가 미러 데이터베이스에 있는 경우 초기자 서비스에는 대상에 대한 미러 경로가 있어야 합니다. 그러나 대상은 초기자로 돌아가는 정규 경로를 포함할 수 있습니다.

  • 초기자 서비스가 미러 데이터베이스에 있는 경우 승인 및 회신을 전달하려면 대상 서비스에 초기자로 돌아가는 미러 경로가 있어야 합니다. 그러나 시작자가 정규 경로를 대상으로 되돌릴 수 있습니다.

확장 저장 프로시저

Important

SQL Server의 이후 버전에서는 이 기능이 제거됩니다. 새 개발 작업에서는 이 기능을 사용하지 않도록 하고, 현재 이 기능을 사용하는 애플리케이션은 수정하세요. 대신 CLR 통합을 사용하세요.

확장 저장 프로시저는 SQL Server 확장 저장 프로시저 API를 사용하여 프로그래밍됩니다. sysadmin 고정 서버 역할의 구성원은 SQL Server 인스턴스에 확장 저장 프로시저를 등록하고 사용자에게 프로시저를 실행할 수 있는 권한을 부여할 수 있습니다. master 데이터베이스에만 확장 저장 프로시저를 추가할 수 있습니다.

확장 저장 프로시저는 SQL Server 인스턴스의 주소 공간에서 직접 실행되며 메모리 누수 또는 서버의 성능 및 안정성을 저하시키는 기타 문제를 생성할 수 있습니다. 참조된 데이터가 포함된 인스턴스와 별개인 SQL Server 인스턴스에 확장 저장 프로시저를 저장하는 것이 좋습니다. 분산 쿼리를 사용하여 데이터베이스에 액세스하는 것도 고려해야 합니다.

Important

시스템 관리자는 확장 저장 프로시저를 서버에 추가하고 다른 사용자에게 EXECUTE 권한을 부여하기 전에 각 확장 저장 프로시저를 철저히 검토하여 유해한 악성 코드가 포함되지 않았는지를 확인해야 합니다.

자세한 내용은 GRANT 개체 사용 권한(Transact-SQL), DENY 개체 사용 권한(Transact-SQL), REVOKE 개체 사용 권한(Transact-SQL)을 참조하세요.

SQL Server용 전체 텍스트 엔진 속성

속성은 sp_fulltext_service의 전체 텍스트 엔진에서 설정됩니다. 대상 서버 인스턴스에 이러한 속성에 필요한 설정이 있는지 확인합니다. 이러한 속성에 대한 자세한 내용은 FULLTEXTSERVICEPROPERTY(Transact-SQL)를 참조하세요.

또한 단어 분리기 및 형태소 분석기 구성 요소 또는 전체 텍스트 검색 필터 구성 요소가 원본 서버 인스턴스와 대상 서버 인스턴스에서 다른 버전을 갖는 경우 전체 텍스트 인덱스와 쿼리가 다르게 동작할 수 있습니다. 또한 동의어 사전 은 인스턴스별 파일에 저장됩니다. 해당 파일의 복사본을 대상 서버 인스턴스의 해당 위치로 전송하거나 새 인스턴스에서 다시 만들어야 합니다.

참고 항목

SQL Server 서버 인스턴스에 전체 텍스트 카탈로그 파일이 포함된 SQL Server 2005(9.x) 데이터베이스를 연결할 경우 SQL Server 2005(9.x)에서와 같이 다른 데이터베이스 파일과 함께 이전 위치에서 카탈로그 파일이 연결됩니다. 자세한 내용은 전체 텍스트 검색 업그레이드를 참조하세요.

자세한 내용은 다음 항목을 참조하십시오.

작업

데이터베이스가 SQL Server 에이전트 작업을 사용하는 경우 대상 서버 인스턴스에서 다시 만들어야 합니다. 작업은 환경에 따라 달라집니다. 대상 서버 인스턴스에서 기존 작업을 다시 만들려는 경우 원본 서버 인스턴스에서 해당 작업의 환경과 일치하도록 대상 서버 인스턴스를 수정해야 할 수 있습니다. 중요한 환경 요인은 다음과 같습니다.

  • 작업에서 사용하는 로그인

    SQL Server 에이전트 작업을 만들거나 실행하려면 먼저 작업에 필요한 SQL Server 로그인을 대상 서버 인스턴스에 추가해야 합니다. 자세한 내용은 사용자가 SQL Server 에이전트 작업을 만들고 관리하도록 구성을 참조하세요.

  • SQL Server 에이전트 서비스 시작 계정

    서비스 시작 계정은 SQL Server 에이전트를 실행하는 Microsoft Windows 계정과 해당 네트워크 사용 권한을 정의합니다. SQL Server 에이전트는 지정된 사용자 계정으로 실행됩니다. 에이전트 서비스의 컨텍스트는 작업 및 해당 실행 환경의 설정에 영향을 줍니다. 계정에는 작업에 필요한 네트워크 공유와 같은 리소스에 대한 액세스 권한이 있어야 합니다. 서비서 시작 계정을 선택하고 수정하는 방법에 대한 자세한 내용은 SQL Server 에이전트 서비스의 계정 선택을 참조하세요.

    제대로 작동하려면 서비스 시작 계정을 올바른 도메인, 파일 시스템, 레지스트리 권한으로 구성해야 합니다. 또한 작업에는 서비스 계정에 대해 구성해야 하는 공유 네트워크 리소스가 필요할 수 있습니다. 자세한 내용은 Windows 서비스 계정 및 권한 구성을 참조하세요.

  • SQL Server의 특정 인스턴스와 연결된 SQL Server 에이전트 서비스에는 자체 레지스트리 하이브가 있으며 해당 작업에는 일반적으로 이 레지스트리 하이브의 설정 1개 이상에 대한 종속성이 있습니다. 의도한 대로 동작하려면 작업에 해당 레지스트리 설정이 필요합니다. 스크립트를 사용하여 다른 SQL Server 에이전트 서비스에서 작업을 다시 만드는 경우 레지스트리에 해당 작업에 대한 올바른 설정이 없을 수 있습니다. 다시 만든 작업이 대상 서버 인스턴스에서 올바르게 작동하려면 원본 및 대상 SQL Server 에이전트 서비스의 레지스트리 설정이 동일해야 합니다.

    주의

    대상 SQL Server 에이전트 서비스에서 다시 만든 작업을 처리하도록 레지스트리 설정을 변경하면 다른 작업에서 현재 설정이 필요한 경우 문제가 될 수 있습니다. 또한 레지스트리를 올바르게 편집하지 않으면 시스템에 심각한 손상을 줄 수 있습니다. 따라서 레지스트리를 변경하기 전에 컴퓨터의 중요한 데이터는 백업해 두는 것이 좋습니다.

  • SQL Server 에이전트 프록시

    SQL Server 에이전트 프록시는 지정된 작업 단계의 보안 컨텍스트를 정의합니다. 대상 서버 인스턴스에서 작업을 실행하려면 필요한 모든 프록시를 해당 인스턴스에서 수동으로 다시 만들어야 합니다. 자세한 내용은 SQL Server 에이전트 프록시 만들기 및 프록시를 사용하는 다중 서버 작업 문제 해결을 참조하세요.

자세한 내용은 다음 항목을 참조하십시오.

기존 작업 및 해당 속성 보기

작업을 만들려면

스크립트를 사용하여 작업을 다시 만들기 위한 모범 사례

먼저 간단한 작업을 스크립팅하고, 다른 SQL Server 에이전트 서비스에서 작업을 다시 만들고, 작업을 실행하여 의도한 대로 작동하는지 확인하는 것이 좋습니다. 이렇게 하면 비호환성을 식별하고 문제 해결을 시도할 수 있습니다. 스크립팅한 작업이 새 환경에서 의도한 대로 작동하지 않을 경우 이와 동등하면서 해당 환경에서 올바르게 작동하는 작업을 만드는 것이 좋습니다.

로그인

SQL Server 인스턴스에 로그인하려면 유효한 SQL Server 로그인이 필요합니다. 이 로그인은 보안 주체가 SQL Server 인스턴스에 연결할 수 있는지 여부를 확인하는 인증 프로세스에서 사용됩니다. SQL Server 로그인이 서버 인스턴스에서 정의되지 않았거나 잘못 정의되어 있는 데이터베이스 사용자는 해당 인스턴스에 로그인할 수 없습니다. 이러한 사용자는 해당 서버 인스턴스에 있는 데이터베이스의 분리된 사용자라고 합니다. 데이터베이스가 SQL Server의 다른 인스턴스에 복원, 연결 또는 복사된 후에도 데이터베이스 사용자가 분리될 수 있습니다.

데이터베이스의 원래 복사본에 있는 일부 또는 모든 개체에 대한 스크립트를 생성하려면 스크립트 생성 마법사를 사용하고 스크립트 옵션 선택 대화 상자에서 스크립트 로그인 옵션을 True로 설정할 수 있습니다.

참고 항목

미러 데이터베이스에 대한 로그인을 설정하는 방법에 대한 자세한 내용은 데이터베이스 미러링 또는 Always On 가용성 그룹에 대한 로그인 계정 설정(SQL Server) 및 역할 전환 후 로그인 및 작업 관리(SQL Server)를 참조하세요.

사용 권한

다른 서버 인스턴스에서 데이터베이스를 사용할 수 있게 되면 다음 유형의 사용 권한이 영향을 받을 수 있습니다.

  • 시스템 개체에 대한 GRANT, REVOKE 또는 DENY 사용 권한

  • 서버 인스턴스에 대한 GRANT, REVOKE 또는 DENY 사용 권한(서버 수준 권한)

시스템 개체에 대한 GRANT, REVOKE 및 DENY 사용 권한

저장 프로시저, 확장 저장 프로시저, 함수, 뷰와 같은 시스템 개체에 대한 권한은 master 데이터베이스에 저장되며 대상 서버 인스턴스에서 구성해야 합니다.

데이터베이스의 원래 복사본에 있는 일부 또는 모든 개체에 대한 스크립트를 생성하려면 스크립트 생성 마법사를 사용하고 스크립트 옵션 선택 대화 상자에서 스크립트 개체 레벨 사용 권한 옵션을 True로 설정할 수 있습니다.

Important

로그인을 스크립팅하는 경우 암호는 스크립팅되지 않습니다. 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 데이터베이스에 해당 인증서 또는 비대칭 키를 다시 만들고, 로그인에 매핑하고, 필요한 서버 수준 권한을 로그인에 부여해야 합니다.

인증서 또는 비대칭 키 만들기

인증서 또는 비대칭 키를 로그인에 매핑

매핑된 로그인에 사용 권한 할당

인증서 및 비대칭 키에 대한 자세한 내용은 암호화 계층 구조를 참조하세요.

TRUSTWORHTY 속성

TRUSTWORHTY 데이터베이스 속성은 SQL Server 인스턴스가 데이터베이스 및 그 내용을 신뢰하는지 여부를 나타내는 데 사용됩니다. 기본값으로 데이터베이스가 연결된 경우 보안을 위해 이 옵션은 원본 서버에서 ON으로 설정된 경우에도 OFF로 설정됩니다. 이 속성에 대한 자세한 내용은 TRUSTWORTHY 데이터베이스 속성, 이 옵션을 활성화하는 방법에 대한 자세한 내용은 ALTER DATABASE(Transact-SQL)를 참조하세요.

복제 설정

복제된 데이터베이스의 백업을 다른 서버 또는 데이터베이스로 복원할 경우 복제 설정은 유지되지 않습니다. 이 경우 백업이 복원된 후 모든 게시 및 구독을 다시 만들어야 합니다. 이 프로세스를 더 쉽게 만들려면 현재 복제본 설정을 위한 스크립트와 복제본 활성화 및 비활성화를 위한 스크립트를 만듭니다. 복제본 설정을 다시 만들려면 이러한 스크립트를 복사하고 대상 서버 인스턴스에 대해 작동하도록 서버 이름 참조를 변경합니다.

자세한 내용은 복제된 데이터베이스 백업 및 복원, 데이터베이스 미러링 및 복제(SQL Server), 로그 전달 및 복제(SQL Server)를 참조하세요.

Service Broker 애플리케이션

Service Broker 애플리케이션의 많은 부분이 데이터베이스와 함께 이동됩니다. 하지만 애플리케이션의 일부는 새 위치에서 다시 만들거나 다시 구성해야 합니다. 기본값으로 보안을 위해 데이터베이스가 다른 서버에서 연결되면 is_broker_enabled 및 is_honoor_broker_priority_on 옵션이 OFF로 설정됩니다. 이러한 옵션을 ON으로 설정하는 방법에 ALTER DATABASE(Transact-SQL)를 참조하세요.

시작 프로시저

시작 프로시저는 자동 실행을 위해 표시되고 SQL Server가 시작될 때마다 실행되는 저장 프로시저입니다. 데이터베이스가 시작 프로시저에 의존하는 경우 대상 서버 인스턴스에 정의되고 시작 시 자동으로 실행되도록 구성되어야 합니다.

트리거(서버 수준)

DDL 트리거는 몇 가지 DDL(데이터 정의 언어) 이벤트에 대한 응답으로 저장된 프로세스를 실행합니다. 이러한 이벤트는 주로 CREATE, ALTER, DROP 키워드로 시작하는 Transact-SQL 문에 해당합니다. DDL과 같은 작업을 수행하는 특정 시스템 저장 프로시저에서도 DDL 트리거가 발생할 수 있습니다.

이 기능에 대한 자세한 내용은 DDL 트리거를 참조하세요.

참고 항목

포함된 데이터베이스
데이터베이스를 다른 서버로 복사
데이터베이스 분리 및 연결(SQL Server)
로그 전달 보조 데이터베이스로 장애 조치(Failover)(SQL Server)
데이터베이스 미러링 세션 중 역할 전환(SQL Server)
암호화된 미러 데이터베이스 설정
SQL Server 구성 관리자
분리된 사용자 문제 해결(SQL Server)
새 설치로 마이그레이션마이그레이션 개요: SQL Server에서 Azure VM의 SQL Server로 마이그레이션