다음을 통해 공유


다른 서버 인스턴스에서 데이터베이스를 사용할 수 있도록 할 때 메타데이터 관리(SQL Server)

이 항목은 다음과 같은 상황과 관련이 있습니다.

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

  • 데이터베이스에 대한 데이터베이스 미러링 설정

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

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

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

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

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

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

이 항목의 나머지 부분에서는 다른 서버 인스턴스에서 사용할 수 있는 데이터베이스에 영향을 줄 수 있는 잠재적인 문제를 요약합니다. 다음 목록에 나열된 정보, 엔터티 또는 개체 유형 중 하나 이상을 다시 만들어야 할 수 있습니다. 요약을 보려면 항목의 링크를 클릭합니다.

서버 구성 설정

SQL Server 2005 이상 버전은 선택적으로 주요 서비스 및 기능을 설치하고 시작합니다. 이렇게 하면 시스템의 공격 가능한 노출 영역을 줄일 수 있습니다. 새 설치의 기본 구성에서는 많은 기능을 사용할 수 없습니다. 데이터베이스가 기본적으로 꺼져 있는 서비스 또는 기능을 사용하는 경우 대상 서버 인스턴스에서 이 서비스 또는 기능을 사용하도록 설정해야 합니다.

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

[위쪽]

자격 증명

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

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

비고

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

[위쪽]

데이터베이스 간 쿼리

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

연결 및 분리 작업은 데이터베이스에 대한 데이터베이스 간 소유권 체인을 사용하지 않도록 설정합니다. 체인을 사용하도록 설정하는 방법에 대한 자세한 내용은 교차 db 소유권 체인 서버 구성 옵션을 참조하세요.

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

[위쪽]

데이터베이스 소유권

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

분산 쿼리 및 연결된 서버

분산 쿼리 및 연결된 서버는 OLE DB 애플리케이션에 대해 지원됩니다. 분산 쿼리는 동일하거나 다른 컴퓨터에서 여러 다른 유형의 데이터 원본의 데이터에 액세스합니다. 연결된 서버 구성을 사용하면 SQL Server가 원격 서버의 OLE DB 데이터 원본에 대해 명령을 실행할 수 있습니다. 이러한 기능에 대한 자세한 내용은 연결된 서버(데이터베이스 엔진)를 참조하세요.

[위쪽]

암호화된 데이터

다른 서버 인스턴스에서 사용할 수 있는 데이터베이스에 암호화된 데이터가 포함되어 있고 데이터베이스 마스터 키가 원래 서버의 서비스 마스터 키로 보호되는 경우 서비스 마스터 키 암호화를 다시 만들어야 할 수 있습니다. 데이터베이스 마스터 키는 암호화된 데이터베이스에서 인증서 및 비대칭 키의 프라이빗 키를 보호하는 데 사용되는 대칭 키입니다. 데이터베이스 마스터 키를 만들면 Triple DES 알고리즘 및 사용자가 제공한 암호를 사용하여 암호화됩니다.

서버 인스턴스에서 데이터베이스 마스터 키의 자동 암호 해독을 사용하도록 설정하려면 서비스 마스터 키를 사용하여 이 키의 복사본을 암호화합니다. 이 암호화된 복사본은 데이터베이스와 마스터 모두에 저장됩니다. 일반적으로 마스터에 저장된 복사본은 마스터 키가 변경될 때마다 자동으로 업데이트됩니다. SQL Server는 먼저 인스턴스의 서비스 마스터 키를 사용하여 데이터베이스 마스터 키의 암호를 해독하려고 시도합니다. 암호 해독에 실패하면 SQL Server는 자격 증명 저장소에서 마스터 키가 필요한 데이터베이스와 동일한 패밀리 GUID를 가진 마스터 키 자격 증명을 검색합니다. 그런 다음 SQL Server는 암호 해독이 성공하거나 더 이상 자격 증명이 없을 때까지 일치하는 각 자격 증명으로 데이터베이스 마스터 키의 암호를 해독하려고 시도합니다. 서비스 마스터 키로 암호화되지 않은 마스터 키는 OPEN MASTER KEY 문과 암호를 사용하여 열어야 합니다.

암호화된 데이터베이스를 SQL Server의 새 인스턴스에 복사, 복원 또는 연결하면 서비스 마스터 키로 암호화된 데이터베이스 마스터 키의 복사본이 대상 서버 인스턴스의 마스터 에 저장되지 않습니다. 대상 서버 인스턴스에서 데이터베이스의 마스터 키를 열어야 합니다. 마스터 키를 열려면 다음 문을 실행합니다. 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 카탈로그 뷰에 있습니다. 이 카탈로그 뷰는 마스터에 저장됩니다. 데이터베이스 애플리케이션이 사용자 정의 오류 메시지에 따라 달라지고 다른 서버 인스턴스에서 데이터베이스를 사용할 수 있는 경우 sp_addmessage 사용하여 대상 서버 인스턴스에 해당 사용자 정의 메시지를 추가합니다.

[위쪽]

이벤트 알림 및 WMI(Windows Management Instrumentation) 이벤트(서버 수준)

Server-Level 이벤트 알림

서버 수준 이벤트 알림은 msdb에 저장됩니다. 따라서 데이터베이스 애플리케이션이 서버 수준 이벤트 알림을 사용하는 경우 대상 서버 인스턴스에서 해당 이벤트 알림을 다시 만들어야 합니다. 서버 인스턴스에서 이벤트 알림을 보려면 sys.server_event_notifications 카탈로그 뷰를 사용합니다. 자세한 내용은 이벤트 알림을 참조하세요.

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

윈도우 관리 도구(Windows Management Instrumentation, WMI) 이벤트

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

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

미러된 데이터베이스에 대해 이벤트 알림이 작동하는 방식

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

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

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

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

  • 초기자 서비스가 미러된 데이터베이스에 있는 경우 대상 서비스에 승인 및 회신을 전달하려면 초기자로 돌아가는 미러된 경로가 있어야 합니다. 그러나 초기자는 대상에 대한 일반 경로를 가질 수 있습니다.

[위쪽]

확장 저장 프로시저

중요합니다

이 기능은 이후 버전의 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 속성에 대한 Full-Text 엔진

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

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

비고

전체 텍스트 카탈로그 파일이 포함된 SQL Server 2005 데이터베이스를 SQL Server 2014 서버 인스턴스에 연결하면 카탈로그 파일이 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 인스턴스에 로그인하려면 유효한 SQL Server 로그인이 필요합니다. 이 로그인은 사용자가 SQL Server 인스턴스에 연결할 수 있는지를 확인하는 인증 프로세스에 사용됩니다. 해당 SQL Server 로그인이 정의되지 않거나 서버 인스턴스에서 잘못 정의된 데이터베이스 사용자는 인스턴스에 로그인할 수 없습니다. 이러한 사용자는 해당 서버 인스턴스에서 데이터베이스의 분리된 사용자 라고 합니다. 데이터베이스를 복원, 연결 또는 다른 SQL Server 인스턴스에 복사한 후 데이터베이스 사용자는 분리될 수 있습니다.

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

비고

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

[위쪽]

권한

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

  • 시스템 개체의 권한을 부여, 취소 또는 거부

  • 서버 인스턴스에서 서버 수준 권한의 GRANT, REVOKE 또는 DENY 권한을 설정하기

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

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

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

중요합니다

로그인을 스크립깅하는 경우 암호는 스크립깅되지 않습니다. SQL Server 인증을 사용하는 로그인이 있는 경우 대상에서 스크립트를 수정해야 합니다.

시스템 개체는 sys.system_objects 카탈로그 뷰에 표시됩니다. 시스템 개체에 대한 사용 권한은 master 데이터베이스의 sys.database_permissions 카탈로그 뷰에 표시됩니다. 이러한 카탈로그 뷰를 쿼리하고 시스템 개체 사용 권한을 부여하는 방법에 대한 자세한 내용은 GRANT System Object Permissions(Transact-SQL)를 참조하세요. 자세한 내용은 REVOKE 시스템 개체 사용 권한(Transact-SQL)DENY 시스템 개체 사용 권한(Transact-SQL)을 참조하세요.

서버 인스턴스에 대한 설정, 철회 및 거부 권한 제공

서버 범위의 사용 권한은 master 데이터베이스에 저장되며 대상 서버 인스턴스에서 구성해야 합니다. 서버 인스턴스의 서버 사용 권한에 대한 정보는 sys.server_permissions 카탈로그 뷰를 쿼리하고, 서버 보안 주체에 대한 정보는 sys.server_principals 카탈로그 뷰를 쿼리하며, 서버 역할 멤버 자격에 대한 정보는 sys.server_role_members 카탈로그 뷰를 쿼리합니다.

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

인증서 또는 비대칭 키에 대한 Server-Level 권한

서버 수준 권한은 인증서 또는 비대칭 키에 직접 부여할 수 없습니다. 대신 특정 인증서 또는 비대칭 키에 대해 독점적으로 만들어진 매핑된 로그인에 서버 수준 권한이 부여됩니다. 따라서 서버 수준 권한이 필요한 각 인증서 또는 비대칭 키에는 자체 인증서 매핑 로그인 또는 비대칭 키 매핑 로그인이 필요합니다. 인증서 또는 비대칭 키에 대한 서버 수준 권한을 부여하려면 매핑된 로그인에 대한 권한을 부여합니다.

비고

매핑된 로그인은 해당 인증서 또는 비대칭 키로 서명된 코드의 권한 부여에만 사용됩니다. 매핑된 로그인은 인증에 사용할 수 없습니다.

매핑된 로그인과 해당 사용 권한은 모두 마스터에 상주합니다. 인증서 또는 비대칭 키가 마스터가 아닌 데이터베이스에 있는 경우 마스터 에서 다시 만들고 로그인에 매핑해야 합니다. 데이터베이스를 다른 서버 인스턴스로 이동, 복사 또는 복원하는 경우 대상 서버 인스턴스의 마스터 데이터베이스에 해당 인증서 또는 비대칭 키를 다시 만들고, 로그인에 매핑하고, 필요한 서버 수준 권한을 로그인에 부여해야 합니다.

인증서 또는 비대칭 키를 만들려면

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

매핑된 로그인에 권한을 할당하려면

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

[위쪽]

복제 설정

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

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

[위쪽]

서비스 브로커 애플리케이션

Service Broker 애플리케이션의 여러 측면이 데이터베이스와 함께 이동합니다. 그러나 애플리케이션의 일부 측면은 새 위치에서 다시 만들거나 다시 구성해야 합니다.

[위쪽]

시작 절차

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

[위쪽]

트리거(서버 수준)

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

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

[위쪽]

또한 참조하십시오

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