다른 서버에서 데이터베이스를 사용할 수 있도록 할 때 메타데이터 관리Manage Metadata When Making a Database Available on Another Server

이 항목에는 다음과 관련된 내용이 포함되어 있습니다.This topic is relevant in the following situations:

  • Always On 가용성 그룹Always On availability groups 가용성 그룹의 가용성 복제본을 구성하는 경우Configuring the availability replicas of an Always On 가용성 그룹Always On availability groups availability group.

  • 데이터베이스에 대해 데이터베이스 미러링을 설정하는 경우Setting up database mirroring for a database.

  • 로그 전달 구성에서 주 서버와 보조 서버 간에 역할 변경을 준비하는 경우When preparing to change roles between primary and secondary servers in a log shipping configuration.

  • 데이터베이스를 다른 서버 인스턴스로 복원하는 경우Restoring a database to another server instance.

  • 다른 서버 인스턴스에서 데이터베이스 복사본을 연결하는 경우Attaching a copy of a database on another server instance.

    일부 응용 프로그램은 단일 사용자 데이터베이스 범위 밖에 있는 정보, 엔터티 및/또는 개체에 따라 달라집니다.Some applications depend on information, entities, and/or objects that are outside of the scope of a single user database. 일반적으로 응용 프로그램은 mastermsdb 데이터베이스뿐만 아니라 사용자 데이터베이스에 따라 달라집니다.Typically, an application has dependencies on the master and msdb databases, and also on the user database. 사용자 데이터베이스의 올바른 작동을 위해 해당 데이터베이스 외부에 저장되어 있는 모든 요소는 대상 서버 인스턴스에서 사용할 수 있어야 합니다.Anything stored outside of a user database that is required for the correct functioning of that database must be made available on the destination server instance. 예를 들어 응용 프로그램에 대한 로그인은 master 데이터베이스에서 메타데이터로 저장되어 있으며 대상 서버에서 다시 생성되어야 합니다.For example, the logins for an application are stored as metadata in the master database, and they must be re-created on the destination server. 메타데이터가 SQL ServerSQL Server msdb 데이터베이스에 저장되어 있는 에이전트 작업에 따라 응용 프로그램이나 데이터베이스 유지 관리 계획이 달라지는 경우 대상 서버 인스턴스에서 이러한 작업을 다시 만들어야 합니다.If an application or database maintenance plan depends on SQL ServerSQL Server Agent jobs, whose metadata is stored in the msdb database, you must re-create those jobs on the destination server instance. 마찬가지로 서버 수준 트리거에 대한 메타데이터는 master에 저장되어 있습니다.Similarly, the metadata for a server-level trigger is stored in master.

    응용 프로그램에 대한 데이터베이스를 다른 서버 인스턴스로 이동할 경우 대상 서버 인스턴스의 mastermsdb 에서 종속 개체와 엔터티의 모든 메타데이터를 다시 만들어야 합니다.When you move the database for an application to another server instance, you must re-create all the metadata of the dependant entities and objects in master and msdb on the destination server instance. 예를 들어 데이터베이스 응용 프로그램이 서비스 수준 트리거를 사용하는 경우 단순히 새 시스템에서 데이터베이스를 연결하거나 복원하는 것만으로 충분하지 않습니다.For example, if a database application uses server-level triggers, just attaching or restoring the database on the new system is not enough. master 데이터베이스에서 이러한 트리거에 대한 모든 메타데이터를 수동으로 다시 만들지 않으면 데이터베이스가 예상대로 작동하지 않습니다.The database will not work as expected unless you manually re-create the metadata for those triggers in the master database.

사용자 데이터베이스의 외부에 저장된 정보, 엔터티 및 개체 Information, Entities, and Objects That Are Stored Outside of User Databases

이 항목의 나머지에서는 다른 서버 인스턴스에서 사용되는 데이터베이스에 영향을 줄 수 있는 발생 가능한 문제에 대해 요약합니다.The remainder of this topic summarizes the potential issues that might affect a database that is being made available on another server instance. 다음 목록에 나열된 하나 또는 그 이상의 정보, 엔터티 또는 개체 유형을 다시 만들어야 할 수 있습니다.You might have to re-create one or more of the types of information, entities, or objects listed in the following list. 요약을 보려면 항목의 링크를 클릭합니다.To see a summary, click the link for the item.

서버 구성 설정 Server Configuration Settings

SQL Server 2005SQL Server 2005 이상 버전에서는 키 서비스 및 기능을 필요에 따라 설치하고 시작합니다. and later versions selectively install and starts key services and features. 이를 통해 시스템이 공격 받을 수 있는 노출 영역을 줄일 수 있습니다.This helps reduce the attackable surface area of a system. 새 설치의 기본 구성에서는 많은 기능이 활성화되지 않습니다.In the default configuration of new installations, many features are not enabled. 데이터베이스가 기본적으로 해제된 서비스나 기능을 사용하는 경우 대상 서버 인스턴스에서 이 서비스나 기능을 설정해야 합니다.If the database relies on any service or feature that is off by default, this service or feature must be enabled on the destination server instance.

이러한 설정에 대한 자세한 내용과 설정을 지정하거나 해제하는 방법은 서버 구성 옵션(SQL Server)을 참조하세요.For more information about these settings and enabling or disabling them, see Server Configuration Options (SQL Server).

자격 증명 Credentials

자격 증명은 SQL ServerSQL Server외부의 리소스에 연결하는 데 필요한 인증 정보가 포함된 레코드입니다.A credential is a record that contains the authentication information that is required to connect to a resource outside SQL ServerSQL Server. 대부분의 자격 증명은 Windows 로그인 및 암호로 구성됩니다.Most credentials consist of a Windows login and password.

이 기능에 대한 자세한 내용은 자격 증명(데이터베이스 엔진)을 참조하세요.For more information about this feature, see Credentials (Database Engine).

참고: SQL ServerSQL Server 에이전트 프록시 계정은 자격 증명을 사용합니다.NOTE: SQL ServerSQL Server Agent Proxy accounts use credentials. 프록시 계정의 자격 증명 ID를 확인하려면 sysproxies 시스템 테이블을 사용하십시오.To learn the credential ID of a proxy account, use the sysproxies system table.

데이터베이스 간 쿼리 Cross-Database Queries

DB_CHAINING 및 TRUSTWORTHY 데이터베이스 옵션은 기본적으로 OFF입니다.The DB_CHAINING and TRUSTWORTHY database options are OFF by default. 원래 데이터베이스에 대해 이러한 옵션 중 하나가 ON으로 설정되어 있으면 대상 서버 인스턴스의 데이터베이스에서 해당 옵션을 설정해야 할 수도 있습니다.If either of these is set to ON for the original database, you may have to enable them on the database on the destination server instance. 자세한 내용은 ALTER DATABASE(Transact-SQL)를 참조하세요.For more information, see ALTER DATABASE (Transact-SQL).

연결 및 분리 작업을 수행하면 해당 데이터베이스의 데이터베이스 간 소유권 체인을 사용할 수 없게 됩니다.Attach-and-detach operations disable cross-database ownership chaining for the database. 체인을 사용하도록 설정하는 방법은 cross db ownership chaining 서버 구성 옵션을 참조하세요.For information about how to enable chaining, see cross db ownership chaining Server Configuration Option.

자세한 내용은 Trustworthy 속성을 사용하도록 미러 데이터베이스 설정(Transact-SQL)을 참조하세요.For more information, see also Set Up a Mirror Database to Use the Trustworthy Property (Transact-SQL)

데이터베이스 소유권 Database Ownership

데이터베이스를 다른 컴퓨터에서 복원하는 경우 복원 작업을 시작한 Windows 사용자 또는 SQL ServerSQL Server 로그인이 자동으로 새 데이터베이스 소유자가 됩니다.When a database is restored on another computer, the SQL ServerSQL Server login or Windows user who initiated the restore operation becomes the owner of the new database automatically. 데이터베이스를 복원할 때 시스템 관리자나 새 데이터베이스 소유자는 데이터베이스 소유권을 변경할 수 있습니다.When the database is restored, the system administrator or the new database owner can change database ownership.

분산 쿼리 및 연결된 서버 Distributed Queries and Linked Servers

분산 쿼리와 연결된 서버는 OLE DB 응용 프로그램에 대해 지원됩니다.Distributed queries and linked servers are supported for OLE DB applications. 분산 쿼리는 같은 컴퓨터나 다른 컴퓨터에 있는 유형이 다른 여러 데이터 원본의 데이터에 액세스합니다.Distributed queries access data from multiple heterogeneous data sources on either the same or different computers. 연결된 서버를 구성하면 SQL ServerSQL Server에서 원격 서버에 있는 OLE DB 데이터 원본에 대해 명령을 실행할 수 있습니다.A linked server configuration enables SQL ServerSQL Server to execute commands against OLE DB data sources on remote servers. 이러한 기능에 대한 자세한 내용은 연결된 서버(데이터베이스 엔진)를 참조하세요.For more information about these features, see Linked Servers (Database Engine).

암호화된 데이터 Encrypted Data

다른 서버 인스턴스에서 사용할 수 있도록 할 데이터베이스에 암호화된 데이터가 있으며 데이터베이스 마스터 키가 원래 서버의 서비스 마스터 키로 보호되는 경우 서비스 마스터 키 암호화를 다시 만들어야 할 수도 있습니다.If the database you are making available on another server instance contains encrypted data and if the database master key is protected by the service master key on the original server, it might be necessary to re-create the service master key encryption. 데이터베이스 마스터 키 는 암호화된 데이터베이스에 있는 인증서의 개인 키와 비대칭 키를 보호하는 데 사용되는 대칭 키입니다.The database master key is a symmetric key that is used to protect the private keys of certificates and asymmetric keys in an encrypted database. 데이터베이스 마스터 키는 생성 시에 Triple DES 알고리즘 및 사용자 제공 암호를 사용하여 암호화됩니다.When created, the database master key is encrypted by using the Triple DES algorithm and a user-supplied password.

서버 인스턴스에서 데이터베이스 마스터 키의 자동 암호 해독을 설정하기 위해 서비스 마스터 키를 사용하여 이 키의 복사본을 암호화합니다.To enable the automatic decryption of the database master key on a server instance, a copy of this key is encrypted by using the service master key. 이 암호화된 복사본은 해당 데이터베이스와 master에 모두 저장됩니다.This encrypted copy is stored in both the database and in master. 일반적으로 master 에 저장된 복사본은 마스터 키가 변경될 때마다 자동으로 업데이트됩니다.Typically, the copy stored in master is silently updated whenever the master key is changed. SQL ServerSQL Server 는 먼저 인스턴스의 서비스 마스터 키로 데이터베이스 마스터 키의 암호를 해독하려고 시도합니다. first tries to decrypt the database master key with the service master key of the instance. 암호 해독에 실패하면 SQL ServerSQL Server 는 마스터 키가 필요한 데이터베이스와 패밀리 GUID가 동일한 마스터 키 자격 증명을 자격 증명 저장소에서 검색합니다.If that decryption fails, SQL ServerSQL Server searches the credential store for master key credentials that have the same family GUID as the database for which it requires the master key. SQL ServerSQL Server 는 암호 해독이 성공하거나 남은 자격 증명이 없을 때까지 일치하는 각 자격 증명을 사용하여 데이터베이스 마스터 키의 암호화를 해독하려고 시도합니다. then tries to decrypt the database master key with each matching credential until the decryption succeeds or there are no more credentials. 서비스 마스터 키를 사용하여 암호화되지 않은 마스터 키는 OPEN MASTER KEY 문과 암호를 사용하여 열어야 합니다.A master key that is not encrypted by the service master key must be opened by using the OPEN MASTER KEY statement and a password.

암호화된 데이터베이스를 복사 또는 복원하거나 새로운 SQL ServerSQL Server인스턴스에 연결할 때는 서비스 마스터 키로 암호화된 데이터베이스 마스터 키의 복사본이 대상 서버 인스턴스의 master 에 저장되지 않습니다.When an encrypted database is copied, restored, or attached to a new instance of SQL ServerSQL Server, a copy of the database master key encrypted by the service master key is not stored in master on the destination server instance. 대상 서버 인스턴스에서 해당 데이터베이스의 마스터 키를 열어야 합니다.On the destination server instance, you must open the master key of the database. 마스터 키를 열려면 다음 문을 실행합니다. OPEN MASTER KEY DECRYPTION BY PASSWORD ='password'.To open the master key, execute the following statement: OPEN MASTER KEY DECRYPTION BY PASSWORD ='password'. 그런 다음 ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY 문을 실행하여 데이터베이스 마스터 키의 자동 암호 해독을 설정하는 것이 좋습니다.We recommend that you then enable automatic decryption of the database master key by executing the following statement: ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY. 이 ALTER MASTER KEY 문은 서비스 마스터 키로 암호화된 데이터베이스 마스터 키의 복사본을 서버 인스턴스에 제공합니다.This ALTER MASTER KEY statement provisions the server instance with a copy of the database master key that is encrypted with the service master key. 자세한 내용은 OPEN MASTER KEY(Transact-SQL)ALTER MASTER KEY(Transact-SQL)를 참조하세요.For more information, see OPEN MASTER KEY (Transact-SQL) and ALTER MASTER KEY (Transact-SQL).

미러 데이터베이스의 데이터베이스 마스터 키 자동 암호 해독을 설정하는 방법은 암호화된 미러 데이터베이스 설정을 참조하세요.For information about how to enable automatic decryption of the database master key of a mirror database, see Set Up an Encrypted Mirror Database.

자세한 내용은 다음 항목을 참조하십시오.For more information, see also:

사용자 정의 오류 메시지 User-defined Error Messages

사용자 정의 오류 메시지는 sys.messages 카탈로그 뷰에 있습니다.User-defined error messages reside in the sys.messages catalog view. 이 카탈로그 뷰는 master에 저장됩니다.This catalog view is stored in master. 데이터베이스 응용 프로그램이 사용자 정의 오류 메시지를 사용하며 다른 서버 인스턴스에서 데이터베이스를 사용할 수 있는 경우 sp_addmessage 를 사용하여 대상 서버 인스턴스에서 이러한 사용자 정의 메시지를 추가합니다.If a database application depends on user-defined error messages and the database is made available on another server instance, use sp_addmessage to add those user-defined messages on the destination server instance.

이벤트 알림 및 WMI(Windows Management Instrumentation) 이벤트(서버 수준) Event Notifications and Windows Management Instrumentation (WMI) Events (at Server Level)

서버 수준 이벤트 알림Server-Level Event Notifications

서버 수준 이벤트 알림은 msdb에 저장됩니다.Server-level event notifications are stored in msdb. 그러므로 데이터베이스 응용 프로그램이 서버 수준 이벤트 알림을 사용하는 경우 대상 서버 인스턴스에서 해당 이벤트 알림을 다시 만들어야 합니다.Therefore, if a database application relies on a server-level event notifications, that event notification must be re-created on the destination server instance. 서버 인스턴스의 이벤트 알림을 보려면 sys.server_event_notifications 카탈로그 뷰를 사용합니다.To view the event notifications on a server instance, use the sys.server_event_notifications catalog view. 자세한 내용은 Event Notifications을 참조하세요.For more information, see Event Notifications.

또한 이벤트 알림은 Service BrokerService Broker를 사용하여 배달됩니다.Additionally, event notifications are delivered by using Service BrokerService Broker. 들어오는 메시지에 대한 경로는 서비스가 포함된 데이터베이스에 포함되지 않습니다.Routes for incoming messages are not included in the database that contains a service. 대신 명시적인 경로는 msdb에 저장됩니다.Instead, explicit routes are stored in msdb. 서비스가 msdb 데이터베이스에서 명시적인 경로를 사용하여 들어오는 메시지를 서비스에 라우팅하는 경우 다른 인스턴스에서 데이터베이스를 연결할 때 이 경로를 다시 만들어야 합니다.If your service uses an explicit route in the msdb database to route incoming messages to the service, when you attach a database in a different instance, you must re-create this route.

WMI(Windows Management Instrumentation) 이벤트Windows Management Instrumentation (WMI) Events

서버 이벤트용 WMI 공급자는 WMI(Windows Management Instrumentation)를 사용하여 SQL ServerSQL Server의 이벤트를 모니터링할 수 있도록 합니다.The WMI Provider for Server Events lets you use the Windows Management Instrumentation (WMI) to monitor events in SQL ServerSQL Server. 데이터베이스가 사용하는 WMI 공급자를 통해 표시된 서버 수준 이벤트를 사용하는 응용 프로그램은 대상 서버 인스턴스의 컴퓨터에서 정의해야 합니다.Any application that relies on server-level events exposed through the WMI provider on which a database relies must be defined the computer of the destination server instance. WMI 이벤트 공급자는 msdb에서 정의한 대상 서비스로 이벤트 알림을 만듭니다.WMI Event provider creates event notifications with a target service that is defined in msdb.

참고: 자세한 내용은 서버 이벤트용 WMI 공급자 개념을 참조하세요.NOTE: For more information, see WMI Provider for Server Events Concepts.

SQL Server Management Studio를 사용하여 WMI 경고를 만들려면To create a WMI alert using SQL Server Management Studio

미러된 데이터베이스에 대한 이벤트 알림의 작동 방식How Event Notifications Work for a Mirrored Database

미러된 데이터베이스를 포함하는 이벤트 알림의 데이터베이스 간 배달은 미러된 데이터베이스가 장애 조치(Failover)될 수 있으므로 정의상 원격일 수밖에 없습니다.Cross-database delivery of event notifications that involves a mirrored database is remote, by definition, because the mirrored database can fail over. Service BrokerService Broker미러된 경로의 형태로 미러된 데이터베이스에 대해 특별한 지원을 제공합니다. provides special support for mirrored databases, in the form of mirrored routes. 미러된 경로에는 두 개의 주소가 있습니다. 하나는 주 서버 인스턴스에 대한 주소이며 다른 하나는 미러 서버 인스턴스에 대한 주소입니다.A mirrored route has two addresses: one for the principal server instance and one for the mirror server instance.

미러된 경로를 설정하여 Service BrokerService Broker 라우팅에서 데이터베이스 미러링을 인식하도록 지정할 수 있습니다.By setting up mirrored routes, you make Service BrokerService Broker routing aware of database mirroring. 미러된 경로를 사용하여 Service BrokerService Broker 에서 현재 주 서버 인스턴스에 대화를 투명하게 리디렉션할 수 있습니다.The mirrored routes enable Service BrokerService Broker to transparently redirect conversations to the current principal server instance. 예를 들어 미러된 데이터베이스인 Database_A가 Service_A라는 서비스를 호스팅하는데For example, consider a service, Service_A, which is hosted by a mirrored database, Database_A. 이 Service_A와 대화를 하기 위해 Database_B가 호스팅하는 Service_B라는 다른 서비스가 필요한 경우Assume that you need another service, Service_B, which is hosted by Database_B, to have a dialog with Service_A. 이 대화를 가능하게 하려면 Database_B에 Service_A에 대해 미러된 경로가 포함되어야 합니다.For this dialog to be possible, Database_B must contain a mirrored route for Service_A. 또한 Database_A에 로컬 경로와는 달리 장애 조치 후에 유효한 상태로 남아 있는 Service_B에 대한 미러되지 않은 TCP 전송 경로가 포함되어야 합니다.In addition, Database_A must contain a nonmirrored TCP transport route to Service_B, which, unlike a local route, remains valid after failover. 이러한 경로로 인해 ACK가 장애 조치 후에 원래 상태로 돌아옵니다.These routes enable ACKs to come back after a failover. 보낸 사람의 서비스는 항상 동일한 방식으로 명명되므로 경로는 Broker 인스턴스를 지정해야 합니다.Because the service of the sender is always named in the same manner, the route must specify the broker instance.

미러된 경로에 대한 요구 사항은 미러된 데이터베이스의 서비스가 시작자 서비스인지 대상 서비스인지에 관계없이 적용합니다.The requirement for mirrored routes applies for regardless of whether the service in the mirrored database is the initiator service or the target service:

  • 대상 서비스가 미러된 데이터베이스에 있으면 시작자 서비스는 미러된 경로를 대상으로 되돌려야 합니다.If target service is in the mirrored database, the initiator service must have a mirrored route back to the target. 그러나 대상이 정규 경로를 시작자로 되돌릴 수 있습니다.However, the target can have a regular route back to initiator.

  • 시작자 서비스가 미러된 데이터베이스에 있으면 대상 서비스는 승인 및 응답을 배달하기 위해 미러된 경로를 시작자로 되돌려야 합니다.If initiator service is in the mirrored database, the target service must have a mirrored route back to initiator to deliver acknowledgements and replies. 그러나 시작자가 정규 경로를 대상으로 되돌릴 수 있습니다.However, the initiator can have a regular route to the target.

확장 저장 프로시저 Extended Stored Procedures

중요!IMPORTANT! Microsoft SQL Server의 이후 버전에서는 이 기능이 제거됩니다.This feature will be removed in a future version of Microsoft SQL Server. 새 개발 작업에서는 이 기능을 사용하지 않도록 하고, 현재 이 기능을 사용하는 응용 프로그램은 수정하세요.Avoid using this feature in new development work, and plan to modify applications that currently use this feature. 대신 [CLR 통합](../../relational-databases/clr-integration/common-language-runtime-integration-overview.md) 을 사용하세요.(../../relational-databases/clr-integration/common-language-runtime-integration-overview.md) instead.

확장 저장 프로시저는 SQL ServerSQL Server 확장 저장 프로시저 API를 사용하여 프로그래밍합니다.Extended stored procedures are programmed by using the SQL ServerSQL Server Extended Stored Procedure API. sysadmin 고정 서버 역할의 멤버는 SQL ServerSQL Server 인스턴스에 확장 저장 프로시저를 등록하고 사용자에게 이 프로시저를 실행할 권한을 부여할 수 있습니다.A member of the sysadmin fixed server role can register an extended stored procedure with an instance of SQL ServerSQL Server and grant permission to users to execute the procedure. master 데이터베이스에만 확장 저장 프로시저를 추가할 수 있습니다.Extended stored procedures can be added only to the master database.

확장 저장 프로시저는 SQL ServerSQL Server인스턴스의 주소 공간에서 직접 실행되며 메모리 손실 및 서버의 성능과 안정성을 저하시키는 다른 문제를 유발할 수 있습니다.Extended stored procedures run directly in the address space of an instance of SQL ServerSQL Server, and they may produce memory leaks or other problems that reduce the performance and reliability of the server. 참조되는 데이터가 들어 있는 인스턴스와는 별도의 SQL ServerSQL Server 인스턴스에 확장 저장 프로시저를 저장해야 합니다.You should consider storing extended stored procedures in an instance of SQL ServerSQL Server that is separate from the instance that contains the referenced data. 또한 분산 쿼리를 사용하여 데이터베이스에 액세스해야 합니다.You should also consider using distributed queries to access the database.

중요!!IMPORTANT!! 시스템 관리자는 확장 저장 프로시저를 서버에 추가하고 다른 사용자에게 EXECUTE 권한을 부여하기 전에 각 확장 저장 프로시저를 철저히 검토하여 유해한 악성 코드가 포함되지는 않았는지를 확인해야 합니다.Before adding extended stored procedures to the server and granting EXECUTE permissions to other users, the system administrator should thoroughly review each extended stored procedure to make sure that it does not contain harmful or malicious code.

자세한 내용은 GRANT 개체 사용 권한(Transact-SQL), DENY 개체 사용 권한(Transact-SQL)REVOKE 개체 사용 권한(Transact-SQL)을 참조하세요.For more information, see GRANT Object Permissions (Transact-SQL), DENY Object Permissions (Transact-SQL), and REVOKE Object Permissions (Transact-SQL).

SQL Server용 전체 텍스트 엔진 속성 Full-Text Engine for SQL Server Properties

속성은 sp_fulltext_service에 의해 전체 텍스트 엔진에 설정됩니다.Properties are set on the Full-Text Engine by sp_fulltext_service. 대상 서버 인스턴스에 해당 속성에 필요한 설정이 있는지 확인합니다.Make sure that the destination server instance has the required settings for these properties. 이러한 속성에 대한 자세한 내용은 FULLTEXTSERVICEPROPERTY(Transact-SQL)를 참조하세요.For more information about these properties, see FULLTEXTSERVICEPROPERTY (Transact-SQL).

또한 원래 서버 인스턴스와 대상 서버 인스턴스에 있는 단어 분리기 및 형태소 분석기 구성 요소 또는 전체 텍스트 검색 필터 구성 요소의 버전이 서로 다르면 전체 텍스트 인덱스 및 쿼리가 다르게 동작할 수 있습니다.Additionally, if the word breakers and stemmers component or full-text search filters component have different versions on the original and destination server instances, full-text index and queries may behave differently. 또한 동의어 사전 은 인스턴스별 파일에 저장됩니다.Also, the thesaurus is stored in instance-specific files. 이러한 파일의 복사본을 대상 서버 인스턴스의 해당 위치로 전송하거나 새 인스턴스에서 다시 만들어야 합니다.You must either transfer a copy of those files to an equivalent location on the destination server instance or re-create them on new instance.

참고: SQL Server 2005SQL Server 2005 서버 인스턴스에 전체 텍스트 카탈로그 파일이 포함된 SQL Server 2017SQL Server 2017 데이터베이스를 연결할 경우 SQL Server 2005SQL Server 2005에서와 같이 다른 데이터베이스 파일과 함께 이전 위치에서 카탈로그 파일이 연결됩니다.NOTE: When you attach a SQL Server 2005SQL Server 2005 database that contains full-text catalog files onto a SQL Server 2017SQL Server 2017 server instance, the catalog files are attached from their previous location along with the other database files, the same as in SQL Server 2005SQL Server 2005. 자세한 내용은 전체 텍스트 검색 업그레이드를 참조하세요.For more information, see Upgrade Full-Text Search.

자세한 내용은 다음 항목을 참조하십시오.For more information, see also:

작업 Jobs

데이터베이스에서 SQL ServerSQL Server 에이전트 작업을 사용하는 경우 대상 서버 인스턴스에서 해당 작업을 다시 만들어야 합니다.If the database relies on SQL ServerSQL Server Agent jobs, you will have to re-create them on the destination server instance. 작업은 해당 환경에 따라 달라집니다.Jobs depend on their environments. 대상 서버 인스턴스에서 기존 작업을 다시 만드는 경우 원래 서버 인스턴스의 작업 환경과 일치하도록 대상 서버 인스턴스를 수정해야 할 수도 있습니다.If you plan to re-create an existing job on the destination server instance, the destination server instance might have to be modified to match the environment of that job on the original server instance. 중요한 환경 요소는 다음과 같습니다.The following environmental factors are significant:

  • 작업에 사용되는 로그인The login used by the job

    SQL ServerSQL Server 에이전트 작업을 만들거나 실행하려면 먼저 작업에 필요한 모든 SQL ServerSQL Server 로그인을 대상 서버 인스턴스에 추가해야 합니다.To create or execute SQL ServerSQL Server Agent jobs, you must first add any SQL ServerSQL Server logins required by the job to the destination server instance. 자세한 내용은 SQL Server 에이전트 작업을 만들고 관리하도록 사용자 구성을 참조하세요.For more information, see Configure a User to Create and Manage SQL Server Agent Jobs.

  • SQL ServerSQL Server 에이전트 서비스 시작 계정 Agent service startup account

    서비스 시작 계정은 MicrosoftMicrosoft 에이전트를 실행하는 SQL ServerSQL Server Windows 계정과 해당 네트워크 사용 권한을 정의합니다.The service startup account defines the MicrosoftMicrosoft Windows account in which SQL ServerSQL Server Agent runs and its network permissions. SQL ServerSQL Server 에이전트는 지정된 사용자 계정으로 실행됩니다. Agent runs as a specified user account. 에이전트 서비스의 컨텍스트는 작업과 실행 환경에 대한 설정에 영향을 줍니다.The context of the Agent service affects the settings for the job and its run environment. 계정이 작업에 필요한 네트워크 공유 등의 리소스에 액세스할 수 있어야 합니다.The account must have access to the resources, such as network shares, required by the job. 서비스 시작 계정을 선택하고 수정하는 방법은 SQL Server 에이전트 서비스의 계정 선택을 참조하세요.For information about how to select and modify the service startup account, see Select an Account for the SQL Server Agent Service.

    서비스 시작 계정이 올바르게 작동하려면 올바른 도메인, 파일 시스템 및 레지스트리 권한을 구성해야 합니다.To operate correctly, the service startup account must be configured to have the correct domain, file system, and registry permissions. 서비스 계정에 대해 구성해야 하는 공유 네트워크 리소스가 작업에 필요할 수도 있습니다.Also, a job might require a shared network resource that must be configured for the service account. 자세한 내용은 Windows 서비스 계정 및 권한 구성을 참조하세요.For information, see Configure Windows Service Accounts and Permissions.

  • SQL ServerSQL Server 인스턴스에 연결된 SQL ServerSQL Server에이전트 서비스에는 자체 레지스트리 하이브가 있으며 일반적으로 해당 작업은 이 레지스트리 하이브의 하나 또는 그 이상의 설정에 종속되어 있습니다., has its own registry hive, and its jobs typically have dependencies on one or more of the settings in this registry hive. 작업이 의도한 대로 동작하려면 이러한 레지스트리 설정이 필요합니다.To behave as intended, a job requires those registry settings. 스크립트를 사용하여 다른 SQL ServerSQL Server 에이전트 서비스에서 작업을 다시 만들면 해당 작업에 대한 레지스트리 설정이 올바르지 않을 수 있습니다.If you use a script to re-create a job in another SQL ServerSQL Server Agent service, its registry might not have the correct settings for that job. 다시 만든 작업이 대상 서버 인스턴스에서 올바르게 동작하려면 원래 SQL ServerSQL Server 에이전트 서비스와 대상 SQL Server 에이전트 서비스의 레지스트리 설정이 같아야 합니다.For re-created jobs to behave correctly on a destination server instance, the original and destination SQL ServerSQL Server Agent services should have the same registry settings.

    주의

    현재 설정이 다른 작업에 필요한 경우 다시 만든 작업을 처리하기 위해 대상 SQL ServerSQL Server 에이전트 서비스의 레지스트리 설정을 변경하는 것이 문제가 될 수 있습니다.Changing registry settings on the destination SQL ServerSQL Server Agent service to handle a re-created job could be problematic if the current settings are required by other jobs. 또한 레지스트리를 올바르게 편집하지 않으면 시스템에 심각한 손상을 줄 수 있습니다.Furthermore, incorrectly editing the registry can severely damage your system. 따라서 레지스트리를 변경하기 전에 컴퓨터의 중요한 데이터는 백업해 두는 것이 좋습니다.Before you make changes to the registry, we recommend that you back up any valued data on the computer.

  • SQL ServerSQL Server 에이전트 프록시 Agent Proxies

    SQL ServerSQL Server 에이전트 프록시는 지정된 작업 단계의 보안 컨텍스트를 정의합니다.A SQL ServerSQL Server Agent proxy defines the security context for a specified job step. 작업이 대상 서버 인스턴스에서 실행되려면 해당 인스턴스에서 수동으로 필요한 모든 프록시를 다시 만들어야 합니다.For a job to run on the destination server instance, all the proxies it requires must be manually re-created on that instance. 자세한 내용은 SQL Server 에이전트 프록시 만들기프록시를 사용하는 다중 서버 작업 문제 해결을 참조하세요.For more information, see Create a SQL Server Agent Proxy and Troubleshoot Multiserver Jobs That Use Proxies.

    자세한 내용은 다음 항목을 참조하십시오.For more information, see also:

  • 작업 구현Implement Jobs

  • 역할 전환 후 로그인 및 작업 관리(SQL Server)(데이터베이스 미러링의 경우)Management of Logins and Jobs After Role Switching (SQL Server) (for database mirroring)

  • Windows 서비스 계정 및 권한 구성( SQL ServerSQL Server 인스턴스를 설치하는 경우)Configure Windows Service Accounts and Permissions (when you install an instance of SQL ServerSQL Server)

  • SQL Server 에이전트 구성 ( SQL ServerSQL Server인스턴스를 설치하는 경우)Configure SQL Server Agent (when you install an instance of SQL ServerSQL Server)

  • SQL Server 에이전트 보안 구현Implement SQL Server Agent Security

    기존 작업과 해당 속성을 보려면To view existing jobs and their properties

  • 작업 활동 모니터링Monitor Job Activity

  • sp_help_job(Transact-SQL)sp_help_job (Transact-SQL)

  • 작업 단계 정보 보기View Job Step Information

  • dbo.sysjobs(Transact-SQL)dbo.sysjobs (Transact-SQL)

    작업을 만들려면To create a job

  • 작업 만들기Create a Job

  • 작업 만들기Create a Job

스크립트를 사용하여 작업을 다시 만드는 최상의 방법Best Practices for Using a Script to Re-create a Job

먼저 간단한 작업을 스크립팅하고 다른 SQL ServerSQL Server 에이전트 서비스에서 작업을 다시 만든 다음 작업을 실행하여 의도한 대로 작동하는지 확인하는 것이 좋습니다.We recommend that you start by scripting a simple job, re-creating the job on the other SQL ServerSQL Server Agent service, and running the job to see whether it works as intended. 이렇게 하면 비호환성을 확인하고 해결할 수 있습니다.This will let you to identify incompatibilities and try to resolve them. 스크립팅한 작업이 새 환경에서 의도한 대로 작동하지 않을 경우 이와 동등하면서 해당 환경에서 올바르게 작동하는 작업을 만드는 것이 좋습니다.If a scripted job does not work as intended in its new environment, we recommend that you create an equivalent job that works correctly in that environment.

로그인 Logins

SQL ServerSQL Server 인스턴스에 로그인하려면 올바른 SQL ServerSQL Server 로그인이 필요합니다.Logging into an instance of SQL ServerSQL Server requires a valid SQL ServerSQL Server login. 이 로그인은 보안 주체가 SQL ServerSQL Server인스턴스에 연결할 수 있는지 여부를 확인하는 인증 프로세스에서 사용됩니다.This login is used in the authentication process that verifies whether the principal can connect to the instance of SQL ServerSQL Server. 해당 SQL ServerSQL Server 로그인이 서버 인스턴스에서 정의되지 않았거나 잘못 정의되어 있는 데이터베이스 사용자는 이 인스턴스에 로그인할 수 없습니다.A database user for which the corresponding SQL ServerSQL Server login is undefined or is incorrectly defined on a server instance cannot log in to the instance. 이러한 사용자는 해당 서버 인스턴스에 있는 데이터베이스의 분리된 사용자 라고 합니다.Such a user is said to be an orphaned user of the database on that server instance. 데이터베이스가 다른 SQL ServerSQL Server인스턴스에 복원, 연결 또는 복사된 후에도 데이터베이스 사용자가 분리될 수 있습니다.A database user can become orphaned if after a database is restored, attached, or copied to a different instance of SQL ServerSQL Server.

데이터베이스의 원래 복사본에 있는 일부 또는 모든 개체에 대해 스크립트를 생성하려면 스크립트 생성 마법사를 사용하고 스크립트 옵션 선택 대화 상자에서 로그인 스크립팅 옵션을 True로 설정합니다.To generate a script for some or all the objects in the original copy of the database, you can use the Generate Scripts Wizard, and in the Choose Script Options dialog box, set the Script Logins option to True.

참고: 미러된 데이터베이스에 대한 로그인을 설정하는 방법은 데이터베이스 미러링 또는 Always On 가용성 그룹에 대한 로그인 계정 설정(SQL Server)역할 전환 후 로그인 및 작업 관리(SQL Server)를 참조하세요.NOTE: For information about how to set up logins for a mirrored database, see Set Up Login Accounts for Database Mirroring or Always On Availability Groups (SQL Server) and Management of Logins and Jobs After Role Switching (SQL Server).

사용 권한 Permissions

데이터베이스를 다른 서버 인스턴스에서 사용할 수 있을 때 다음의 사용 권한 유형이 영향을 받을 수 있습니다.The following types of permissions might be affected when a database is made available on another server instance.

  • 시스템 개체에 대한 GRANT, REVOKE 또는 DENY 권한GRANT, REVOKE, or DENY permissions on system objects

  • 서버 인스턴스에 대한 GRANT, REVOKE 또는 DENY 권한(서버 수준 사용 권한)GRANT, REVOKE, or DENY permissions on server instance (server-level permissions)

시스템 개체에 대한 GRANT, REVOKE 또는 DENY 권한GRANT, REVOKE, and DENY Permissions on System Objects

저장 프로시저, 확장 저장 프로시저, 함수 및 뷰와 같은 시스템 개체에 대한 사용 권한은 master 데이터베이스에 저장되며 대상 서버 인스턴스에서 구성해야 합니다.Permissions on system objects such as stored procedures, extended stored procedures, functions, and views, are stored in the master database and must be configured on the destination server instance.

데이터베이스의 원래 복사본에 있는 일부 또는 모든 개체에 대해 스크립트를 생성하려면 스크립트 생성 마법사를 사용하고 스크립트 옵션 선택 대화 상자에서 개체 수준 사용 권한 스크립팅 옵션을 True로 설정합니다.To generate a script for some or all the objects in the original copy of the database, you can use the Generate Scripts Wizard, and in the Choose Script Options dialog box, set the Script Object-Level Permissions option to True.

중요!!IMPORTANT!! 로그인을 스크립팅하는 경우 암호는 스크립팅되지 않습니다.If you script logins, the passwords are not scripted. SQL ServerSQL Server 인증을 사용하는 로그인이 있으면 대상에서 스크립트를 수정해야 합니다.If you have logins that use SQL ServerSQL Server Authentication, you have to modify the script on the destination.

시스템 개체는 sys.system_objects 카탈로그 뷰에 표시됩니다.System objects are visible in the sys.system_objects catalog view. 시스템 개체에 대한 사용 권한은 master 데이터베이스의 sys.database_permissions 카탈로그 뷰에 표시됩니다.The permissions on system objects are visible in the sys.database_permissions catalog view in the master database. 이러한 카탈로그 뷰를 쿼리하고 시스템 개체 사용 권한을 부여하는 방법은 GRANT 시스템 개체 사용 권한(Transact-SQL)을 참조하세요.For information about querying these catalog views and granting system-object permissions, see GRANT System Object Permissions (Transact-SQL). 자세한 내용은 REVOKE 시스템 개체 사용 권한(Transact-SQL)DENY 시스템 개체 사용 권한(Transact-SQL)을 참조하세요.For more information, see REVOKE System Object Permissions (Transact-SQL) and DENY System Object Permissions (Transact-SQL).

서버 인스턴스에 대한 GRANT, REVOKE 또는 DENY 권한GRANT, REVOKE, and DENY Permissions on a Server Instance

서버 범위의 사용 권한은 master 데이터베이스에 저장되며 대상 서버 인스턴스에서 구성해야 합니다.Permissions at the server scope are stored in the master database and must be configured on the destination server instance. 서버 인스턴스의 서버 사용 권한에 대한 자세한 내용을 보려면 sys.server_permissions 카탈로그 뷰를 쿼리하세요. 서버 보안 주체에 대한 자세한 내용을 보려면 sys.server_principals 카탈로그 뷰를 쿼리하세요. 서버 역할의 멤버 자격에 대한 자세한 내용을 보려면 sys.server_role_members 카탈로그 뷰를 쿼리하세요.For information about the server permissions of a server instance, query the sys.server_permissions catalog view, for information about server principals query the sys.server_principalss catalog view, and for information about membership of server roles query the sys.server_role_members catalog view.

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

인증서 또는 비대칭 키에 대한 서버 수준 사용 권한Server-Level Permissions for a Certificate or Asymmetric Key

인증서 또는 비대칭 키에 직접 서버 수준 사용 권한을 부여할 수는 없습니다.Server-level permissions cannot be granted directly to a certificate or asymmetric key. 대신 서버 수준 사용 권한은 특정 인증서나 비대칭 키 전용으로 만든 매핑된 로그인에 부여됩니다.Instead, server-level permissions are granted to a mapped login that is created exclusively for a specific certificate or asymmetric key. 그러므로 서버 수준 사용 권한이 필요한 각 인증서 또는 비대칭 키에 해당 인증서 매핑 로그인 이나 비대칭 키 매핑 로그인이 필요합니다.Therefore, each certificate or asymmetric key that requires server-level permissions, requires its own certificate-mapped login or asymmetric key-mapped login. 인증서나 비대칭 키에 서버 수준 사용 권한을 부여하려면 해당 매핑된 로그인에 사용 권한을 부여합니다.To grant server-level permissions for a certificate or asymmetric key, grant the permissions to its mapped login.

참고: 매핑된 로그인은 해당 인증서나 비대칭 키로 서명된 코드의 권한 부여를 위해서만 사용됩니다.NOTE: A mapped login is used only for authorization of code signed with the corresponding certificate or asymmetric key. 매핑된 로그인은 인증에 사용할 수 없습니다.Mapped logins cannot be used for authentication.

매핑된 로그인과 해당 사용 권한은 모두 master에 있습니다.The mapped login and its permissions both reside in master. 인증서나 비대칭 키가 master이외의 데이터베이스에 있을 경우 master 에서 다시 만들어 로그인에 매핑해야 합니다.If a certificate or asymmetric key resides in a database other than master, you must re-create it in master and map it to a login. 데이터베이스를 다른 서버 인스턴스로 이동, 복사 또는 복원하는 경우 대상 서버 인스턴스의 master 데이터베이스에서 해당 인증서나 비대칭 키를 다시 만들어 로그인에 매핑한 다음 필요한 서버 수준 사용 권한을 로그인에 부여해야 합니다.If you move, copy, or restore the database to another server instance, you must re-create its certificate or asymmetric key in the master database of the destination server instance, map to a login, and grant the required server-level permissions to the login.

인증서나 비대칭 키를 만들려면To create a certificate or asymmetric key

복제 설정 Replication Settings

복제된 데이터베이스의 백업을 다른 서버 또는 데이터베이스로 복원할 경우 복제 설정은 유지되지 않습니다.If you restore a backup of a replicated database to another server or database, replication settings cannot be preserved. 이 경우 백업 복원 후 모든 게시 및 구독을 다시 만들어야 합니다.In this case, you must re-create all publications and subscriptions after backups are restored. 이 프로세스를 간단하게 하려면 현재 복제 설정과 복제 설정 및 해제에 대한 스크립트를 만듭니다.To make this process easier, create scripts for your current replication settings and, also, for the enabling and disabling of replication. 편리하게 복제 설정을 다시 만들려면 이러한 스크립트를 복사하고 대상 서버 인스턴스에서 작동하도록 서버 이름 참조를 변경합니다.To help re-create your replication settings, copy these scripts and change the server name references to work for the destination server instance.

자세한 내용은 복제된 데이터베이스 백업 및 복원, 데이터베이스 미러링 및 복제(SQL Server), 로그 전달 및 복제(SQL Server)를 참조하세요.For more information, see Back Up and Restore Replicated Databases, Database Mirroring and Replication (SQL Server), and Log Shipping and Replication (SQL Server).

Service Broker 응용 프로그램 Service Broker Applications

Service BrokerService Broker 응용 프로그램의 많은 부분이 데이터베이스와 함께 이동됩니다.Many aspects of a Service BrokerService Broker application move with the database. 그러나 응용 프로그램의 일부분은 새 위치에서 다시 만들거나 다시 구성해야 합니다.However, some aspects of the application must be re-created or reconfigured in the new location.

시작 프로시저 Startup Procedures

시작 프로시저는 자동 실행되도록 표시되었으며 SQL ServerSQL Server 가 시작될 때마다 실행되는 저장 프로시저입니다.A startup procedure is a stored procedure that is marked for automatic execution and is executed every time SQL ServerSQL Server starts. 데이터베이스가 시작 프로시저에 따라 달라지는 경우 대상 서버 인스턴스에서 해당 프로시저를 정의하고 시작 시 자동으로 실행되도록 구성해야 합니다.If the database depends on any startup procedures, they must be defined on the destination server instance and be configured to be automatically executed at startup.

트리거(서버 수준) Triggers (at Server Level)

DDL 트리거는 다양한 DDL(데이터 정의 언어) 이벤트에 대한 응답으로 저장 프로시저를 실행합니다.DDL triggers fire stored procedures in response to a variety of Data Definition Language (DDL) events. 이러한 이벤트는 주로 CREATE, ALTER 및 DROP 키워드로 시작하는 Transact-SQLTransact-SQL 문에 해당합니다.These events primarily correspond to Transact-SQLTransact-SQL statements that start with the keywords CREATE, ALTER, and DROP. DDL과 같은 작업을 수행하는 특정 시스템 저장 프로시저에서 DDL 트리거가 발생할 수도 있습니다.Certain system stored procedures that perform DDL-like operations can also fire DDL triggers.

이 기능에 대한 자세한 내용은 DDL Triggers를 참조하십시오.For more information about this feature, see DDL Triggers.

관련 항목:See Also

포함된 데이터베이스 Contained Databases
데이터베이스를 다른 서버로 복사 Copy Databases to Other Servers
데이터베이스 분리 및 연결(SQL Server) Database Detach and Attach (SQL Server)
로그 전달 보조 데이터베이스로 장애 조치(failover)(SQL Server) Fail Over to a Log Shipping Secondary (SQL Server)
데이터베이스 미러링 세션 중 역할 전환(SQL Server) Role Switching During a Database Mirroring Session (SQL Server)
암호화된 미러 데이터베이스 설정 Set Up an Encrypted Mirror Database
SQL Server 구성 관리자 SQL Server Configuration Manager
분리된 사용자 문제 해결(SQL Server) Troubleshoot Orphaned Users (SQL Server)