복제 관리자를 위한 질문과 대답Frequently Asked Questions for Replication Administrators

다음 질문과 대답은 복제 데이터베이스 관리자의 다양한 태스크에 대한 지침을 제공합니다.The following questions and answers provide guidance on a variety of tasks faced by administrators of replicated databases.

복제 구성Configuring Replication

작업을 게시할 때 데이터베이스에서 해당 작업을 중지해야 합니까?Does activity need to be stopped on a database when it is published?

아니요.No. 게시를 만드는 동안에도 데이터베이스에서 작업을 계속할 수 있습니다.Activity can continue on a database while a publication is being created. 스냅숏을 생성하는 작업에는 리소스가 많이 사용될 수 있으므로 데이터베이스에 작업량이 적은 시간을 이용하여 스냅숏을 생성하는 것이 가장 좋습니다. 기본적으로 스냅숏은 새 게시 마법사를 완료하면 생성됩니다.Be aware that producing a snapshot can be resource-intensive, so it is best to generate snapshots during periods of lower activity on the database (by default a snapshot is generated when you complete the New Publication Wizard).

스냅숏 생성 중에 테이블이 잠깁니까?Are tables locked during snapshot generation?

사용하는 복제 유형에 따라 잠금이 수행되는 기간이 달라집니다.The length of time that the locks are taken depends on the type of replication used:

  • 병합 게시의 경우 스냅숏 에이전트는 잠금을 수행하지 않습니다.For merge publications, the Snapshot Agent does not take any locks.

  • 트랜잭션 게시의 경우 기본적으로 스냅숏 에이전트는 스냅숏 생성의 초기 단계에서만 잠금을 수행합니다.For transactional publications, by default the Snapshot Agent takes locks only during the initial phase of snapshot generation.

  • 스냅숏 게시의 경우 스냅숏 에이전트는 전체 스냅숏 생성 프로세스 동안 잠금을 수행합니다.For snapshot publications the Snapshot Agent takes locks during the entire snapshot generation process.

    잠금을 수행하면 다른 사용자가 테이블을 업데이트할 수 없기 때문에 특히 스냅숏 게시의 경우 데이터베이스에 작업량이 적을 때 스냅숏 에이전트가 실행되도록 예약해야 합니다.Because locks prevent other users from updating the tables, the Snapshot Agent should be scheduled to execute during periods of lower activity on the database, especially for snapshot publications.

언제 구독을 사용할 수 있습니까? 구독 데이터베이스는 언제 사용할 수 있습니까?When is a subscription available; when can the subscription database be used?

스냅숏이 구독 데이터베이스에 적용된 다음에 구독을 사용할 수 있습니다.A subscription is available after the snapshot has been applied to the subscription database. 그 전에도 구독 데이터베이스에 액세스할 수 있지만 스냅숏이 적용될 때까지 데이터베이스를 사용하면 안 됩니다.Even though the subscription database is accessible prior to this, the database should not be used until after the snapshot has been applied. 다음과 같이 복제 모니터를 사용하여 스냅숏 생성 및 적용 상태를 확인합니다.Use Replication Monitor to check the status of snapshot generation and application:

배포 에이전트나 병합 에이전트가 시작할 때 스냅숏 에이전트가 완료되지 않은 경우 문제가 발생합니까?What happens if the Snapshot Agent has not completed when the Distribution or Merge Agent starts?

배포 에이전트나 병합 에이전트가 스냅숏 에이전트와 동시에 실행되면 오류가 발생하지 않습니다.It will not cause an error if the Distribution Agent or Merge Agent runs at the same time as the Snapshot Agent. 그러나 다음과 같은 사항에 유의하십시오.However, you must be aware of the following:

  • 배포 에이전트나 병합 에이전트가 계속 실행되도록 구성된 경우 해당 에이전트는 스냅숏 에이전트가 완료된 다음 자동으로 스냅숏을 적용합니다.If the Distribution Agent or Merge Agent is configured to run continuously, the agent applies the snapshot automatically after the Snapshot Agent completes.

  • 배포 에이전트나 병합 에이전트가 일정대로 또는 요청 시 실행되도록 구성된 경우 해당 에이전트가 실행될 때 사용 가능한 스냅숏이 없으면 아직 사용할 수 있는 스냅숏이 없다는 메시지와 함께 에이전트가 종료됩니다.If the Distribution Agent or Merge Agent is configured to run on a schedule or on-demand, and there is no snapshot available when the agent runs, the agent will shut down with a message stating that a snapshot is not yet available. 이 경우 스냅숏 에이전트가 완료된 다음 에이전트를 다시 실행하여 스냅숏을 적용해야 합니다.You must run the agent again to apply the snapshot after the Snapshot Agent has completed. 에이전트 실행에 대한 자세한 내용은 밀어넣기 구독 동기화, 끌어오기 구독 동기화복제 에이전트 실행 파일 개념을 참조하세요.For more information on running agents, see Synchronize a Push Subscription, Synchronize a Pull Subscription, and Replication Agent Executables Concepts.

복제 구성을 스크립팅해야 합니까?Should I script my replication configuration?

Yes. 복제 구성 스크립팅은 복제 토폴로지에 대한 모든 재해 복구 계획의 핵심입니다.Scripting the replication configuration is a key part of any disaster recovery plan for a replication topology. 스크립링에 대한 자세한 내용은 Scripting Replication을 참조하십시오.For more information on scripting, see Scripting Replication.

복제된 데이터베이스에는 어떤 복구 모델이 필요합니까?What recovery model is required on a replicated database?

복제는 단순 복구 모델, 대량 로그 복구 모델, 전체 복구 모델 중 어느 모델을 사용해도 제대로 작동합니다.Replication functions properly using any of the recovery models: simple, bulk-logged, or full. 병합 복제는 메타데이터 테이블에 정보를 저장하여 변경 내용을 추적합니다.Merge replication tracks change by storing information in metadata tables. 트랜잭션 복제는 트랜잭션 로그를 표시하여 변경 내용을 추적하지만 이렇게 표시하는 프로세스는 복구 모델의 영향을 받지 않습니다.Transactional replication tracks changes by marking the transaction log, but this marking process is not affected by the recovery model.

복제 작업에서 복제된 테이블에 열을 추가하는 이유는 무엇입니까? 테이블이 게시되지 않으면 해당 열이 제거됩니까?Why does replication add a column to replicated tables; will it be removed if the table isn't published?

변경 내용을 추적하기 위해 병합 복제와 지연 업데이트 구독이 있는 트랜잭션 복제는 게시된 모든 테이블에 있는 모든 행을 고유하게 식별할 수 있어야 합니다.To track changes, merge replication and transactional replication with queued updating subscriptions must be able to uniquely identify every row in every published table. 이를 위해 다음 작업이 수행됩니다.To accomplish this:

  • 테이블에 ROWGUIDCOL 속성이 설정된 uniqueidentifier 데이터 형식의 열이 없는 경우(있으면 이 열이 사용됨) 병합 복제는 모든 테이블에 rowguid 열을 추가합니다.Merge replication adds the column rowguid to every table, unless the table already has a column of data type uniqueidentifier with the ROWGUIDCOL property set (in which case this column is used). 게시에서 테이블이 삭제되면 rowguid 열이 제거됩니다. 추적 작업에 기존 열이 사용되면 해당 열은 제거되지 않습니다.If the table is dropped from the publication, the rowguid column is removed; if an existing column was used for tracking, the column is not removed.

  • 트랜잭션 게시가 지연 업데이트 구독을 지원하는 경우 복제가 모든 테이블에 msrepl_tran_version 열을 추가합니다.If a transactional publication supports queued updating subscriptions, replication adds the column msrepl_tran_version to every table. 게시에서 테이블을 삭제해도 msrepl_tran_version 열은 제거되지 않습니다.If the table is dropped from the publication, the msrepl_tran_version column is not removed.

  • 필터는 행 식별을 위해 복제에 사용된 rowguidcol 을 포함하지 않아야 합니다.A filter must not include the rowguidcol used by replication to identify rows. 기본적으로 이 열은 병합 복제를 설정할 때 추가된 열이며 이름은 rowguid입니다.By default this is the column added at the time you set up merge replication and is named rowguid.

게시된 테이블에서 제약 조건을 어떻게 관리합니까?How do I manage constraints on published tables?

게시된 테이블의 제약 조건에 대해 다음과 같은 사항에 유의하십시오.There are a number of issues to consider regarding constraints on published tables:

  • 트랜잭션 복제에는 게시된 각 테이블에 대해 PRIMARY KEY 제약 조건이 필요합니다.Transactional replication requires a primary key constraint on each published table. 병합 복제에는 기본 키가 필요하지 않지만 있는 경우 복제되어야 합니다.Merge replication does not require a primary key, but if one is present, it must be replicated. 스냅숏 복제에는 기본 키가 필요하지 않습니다.Snapshot replication does not require a primary key.

  • 기본적으로 PRIMARY KEY 제약 조건, 인덱스 및 CHECK 제약 조건은 구독자로 복제됩니다.By default, primary key constraints, indexes, and check constraints are replicated to Subscribers.

  • FOREIGN KEY 제약 조건과 CHECK 제약 조건에 대해서는 NOT FOR REPLICATION 옵션이 기본적으로 지정됩니다. 이러한 제약 조건은 사용자 작업에는 적용되지만 에이전트 작업에는 적용되지 않습니다.The NOT FOR REPLICATION option is specified by default for foreign key constraints and check constraints; the constraints are enforced for user operations but not agent operations.

    제약 조건 복제 여부를 제어하는 스키마 옵션 설정 방법은 Specify Schema Options을 참조하십시오.For information on setting the schema options that control whether constraints are replicated, see Specify Schema Options.

ID 열을 어떻게 관리합니까?How do I manage identity columns?

복제는 구독자에서의 업데이트 내용을 포함하는 복제 토폴로지에 대한 자동 ID 범위 관리를 제공합니다.Replication provides automatic identity range management for replication topologies that include updates at the Subscriber. 자세한 내용은 ID 열 복제를 참조하세요.For more information, see Replicate Identity Columns.

동일한 개체를 다른 여러 게시에 게시할 수 있습니까?Can the same objects be published in different publications?

예. 하지만 몇 가지 제한 사항이 있습니다.Yes, but with some restrictions. 자세한 내용은 데이터 및 데이터베이스 개체 게시 항목에서 "둘 이상의 게시에 테이블 게시" 섹션을 참조하세요.For more information, see the section "Publishing Tables in More Than One Publication" in the topic Publish Data and Database Objects.

여러 게시에서 동일한 배포 데이터베이스를 사용할 수 있습니까?Can multiple publications use the same distribution database?

Yes. 동일한 배포 데이터베이스를 사용할 수 있는 게시의 수나 유형에 대한 제한은 없습니다.There are no restrictions on the number or types of publications that can use the same distribution database. 지정된 게시자의 모든 게시는 동일한 배포자와 배포 데이터베이스를 사용해야 합니다.All publications from a given Publisher must use the same Distributor and distribution database.

여러 게시가 있는 경우 여러 배포 데이터베이스 사이를 이동하는 데이터가 단일 게시의 데이터가 되도록 배포자에서 각 배포 데이터베이스를 구성할 수 있습니다.If you have multiple publications, you can configure multiple distribution databases at the Distributor to ensure that the data flowing through each distribution database is from a single publication. 배포자 속성 대화 상자나 sp_adddistributiondb(Transact-SQL)를 사용하여 배포 데이터베이스를 추가합니다.Use the Distributor Properties dialog box or sp_adddistributiondb (Transact-SQL) to add a distribution database. 이러한 대화 상자에 액세스하는 방법은 배포자 및 게시자 속성 보기 및 수정을 참조하세요.For more information about accessing the dialog box, see View and Modify Distributor and Publisher Properties.

배포자와 게시자에 대한 정보, 즉 데이터베이스에서 어떤 개체가 게시되었는지 등과 같은 정보를 어떻게 찾습니까?How do I find information on the Distributor and Publisher, such as which objects in a database are published?

이러한 정보는 SQL Server Management StudioSQL Server Management Studio와 여러 복제 저장 프로시저를 통해 얻을 수 있습니다.This information is available through SQL Server Management StudioSQL Server Management Studio, and a number of replication stored procedures. 자세한 내용은 Distributor and Publisher Information Script를 참조하세요.For more information, see Distributor and Publisher Information Script.

복제 작업에서 데이터를 암호화합니까?Does replication encrypt data?

아니요.No. 복제 작업에서는 데이터베이스에 저장되어 있거나 네트워크를 통해 전송되는 데이터를 암호화하지 않습니다.Replication does not encrypt data that is stored in the database or transferred over the network. 자세한 내용은 보안 개요(복제) 항목의 "암호화" 섹션을 참조하세요.For more information, see the "Encryption" section of the topic Security Overview (Replication).

인터넷을 통해 데이터를 어떻게 복제합니까?How do I replicate data over the Internet?

다음을 사용하여 인터넷을 통해 데이터를 복제합니다.Replicate data over the Internet using:

연결이 끊어진 경우 복제를 재개할 수 있습니까?Does replication resume if a connection is dropped

Yes. 연결이 끊어지면 중단된 시점에서부터 복제 처리가 재개됩니다.Replication processing resumes at the point at which it left off if a connection is dropped. 불안정한 네트워크에서 병합 복제를 사용하는 경우 관련 변경 내용이 한 단위로 처리되는 논리적 레코드를 사용해 보십시오.If you are using merge replication over an unreliable network, consider using logical records, which ensures related changes are processed as a unit. 자세한 내용은 논리적 레코드를 사용하여 관련된 행의 변경 내용 그룹화를 참조하세요.For more information, see Group Changes to Related Rows with Logical Records.

느린 대역폭 연결을 통해서도 복제를 수행할 수 있습니까?Does replication work over low bandwidth connections? 복제 작업에서 압축을 사용합니까?Does it use compression?

예. 느린 대역폭 연결을 통해서도 복제를 수행할 수 있습니다.Yes, replication does work over low bandwidth connections. TCP/IP를 통한 연결의 경우 복제는 프로토콜에서 제공하는 압축을 사용하지만 추가 압축은 제공하지 않습니다.For connections over TCP/IP, it uses the compression provided by the protocol but does not provide additional compression. HTTPS를 통한 웹 동기화 연결의 경우 복제는 프로토콜에서 제공하는 압축과 변경 내용을 복제하는 데 사용되는 XML 파일의 추가 압축도 사용합니다.For Web synchronization connections over HTTPS, it uses the compression provided by the protocol and also additional compression of the XML files used to replicate changes.

로그인 및 개체 소유권Logins and Object Ownership

로그인과 암호도 복제됩니까?Are logins and passwords replicated?

아니요.No. DTS 패키지를 만들어 한 게시자에서 하나 이상의 구독자로 로그인과 암호를 전송할 수 있습니다.You could create a DTS package to transfer logins and passwords from a Publisher to one or more Subscribers.

스키마란 무엇이며 어떻게 복제됩니까?What are schemas and how are they replicated?

MicrosoftMicrosoft SQL Server 2005SQL Server 2005, 스키마 는 다음 두 가지 의미를 갖습니다.Beginning with MicrosoftMicrosoft SQL Server 2005SQL Server 2005, schema has two meanings:

  • CREATE TABLE 문과 같은 개체의 정의입니다.The definition of an object, such as a CREATE TABLE statement. 기본적으로 복제는 복제된 모든 개체의 정의를 구독자로 복사합니다.By default, replication copies the definitions of all replicated objects to the Subscriber.

  • 개체가 만들어진 네임스페이스 <Database>.<Schema>.<Object>입니다.The namespace within which an object is created: <Database>.<Schema>.<Object>. 스키마는 CREATE SCHEMA 문을 사용하여 정의됩니다.Schemas are defined using the CREATE SCHEMA statement.

  • 복제는 새 게시 마법사에서 스키마 및 개체 소유권에 대해 기본적으로 다음과 같이 작동합니다.Replication has the following default behavior in the New Publication Wizard with respect to schemas and object ownership:

  • 호환성 수준이 90 이상인 병합 게시, 스냅숏 게시, 트랜잭션 게시의 아티클에 대해 기본적으로 구독자의 개체 소유자는 게시자에 있는 해당 개체의 소유자와 동일합니다.For articles in merge publications with a compatibility level of 90 or higher, snapshot publications, and transactional publications: by default, the object owner at the Subscriber is the same as the owner of the corresponding object at the Publisher. 개체를 소유한 스키마가 구독자에 없으면 자동으로 생성됩니다.If the schemas that own objects do not exist at the Subscriber, they are created automatically.

  • 호환성 수준이 90 이하인 병합 게시의 아티클에 대해 기본적으로 소유자는 빈 상태였다가 구독자에서 개체를 생성하는 중에 dbo 로 지정됩니다.For articles in merge publications with a compatibility level lower than 90: by default, the owner is left blank and is specified as dbo during the creation of the object on the Subscriber.

  • Oracle 게시의 아티클에 대해 기본적으로 소유자는 dbo로 지정됩니다.For articles in Oracle publications: by default, the owner is specified as dbo.

  • 문자 모드 스냅숏( SQL ServerSQL Server 이외 구독자 및 SQL Server CompactSQL Server Compact 구독자에 사용됨)을 사용하는 게시의 아티클에 대해 기본적으로 소유자는 빈 상태입니다.For articles in publications that use character mode snapshots (which are used for non- SQL ServerSQL Server Subscribers and SQL Server CompactSQL Server Compact Subscribers): by default, the owner is left blank. 소유자는 기본적으로 배포 에이전트 또는 병합 에이전트를 구독자에 연결하는 데 사용하는 계정과 연결된 소유자입니다.The owner defaults to the owner associated with the account used by the Distribution Agent or Merge Agent to connect to the Subscriber.

    개체 소유자는 아티클 속성 - <Article> 대화 상자와 sp_addarticle, sp_addmergearticle, sp_changearticlesp_changemergearticle 저장 프로시저를 통해 변경할 수 있습니다.The object owner can be changed through the Article Properties - <Article> dialog box and through the following stored procedures: sp_addarticle, sp_addmergearticle, sp_changearticle, and sp_changemergearticle. 자세한 내용은 게시 속성 보기 및 수정, 아티클 정의아티클 속성 보기 및 수정을 참조하세요.For more information, see View and Modify Publication Properties, Define an Article, and View and Modify Article Properties.

구독 데이터베이스에 부여된 권한을 게시 데이터베이스에 부여된 권한과 일치시키려면 어떻게 해야 합니까?How can grants on the subscription database be configured to match grants on the publication database?

기본적으로 복제는 구독 데이터베이스에서 GRANT 문을 실행하지 않습니다.By default, replication does not execute GRANT statements on the subscription database. 구독 데이터베이스에 대한 사용 권한을 게시 데이터베이스의 사용 권한과 일치시키려면 다음 방법 중 하나를 사용하십시오.If you want the permissions on the subscription database to match those on the publication database, use one of the following methods:

구독을 다시 초기화하면 구독 데이터베이스에 부여된 사용 권한은 어떻게 됩니까?What happens to permissions granted in a subscription database if a subscription is reinitialized?

기본적으로 구독이 다시 초기화되면 구독자의 개체가 삭제되고 다시 생성되므로 해당 개체에 부여된 모든 사용 권한도 삭제됩니다.By default, objects at the Subscriber are dropped and recreated when a subscription is reinitialized, which causes all granted permissions for those objects to be dropped. 이러한 문제는 다음과 같이 처리할 수 있습니다.There are two ways to handle this:

  • 다시 초기화한 후 이전 섹션에서 설명한 기술을 사용하여 권한을 다시 적용합니다.Reapply the grants after the reinitialization using the techniques described in the previous section.

  • 구독을 다시 초기화할 때 해당 개체를 삭제하지 않도록 지정합니다.Specify that objects should not be dropped when the subscription is reinitialized. 다시 초기화하기 전에 다음 중 하나를 수행합니다.Prior to reinitialization, either:

    • sp_changearticle 또는 sp_changemergearticle을 실행할 때Execute sp_changearticle or sp_changemergearticle. @property 매개 변수에 'pre_creation_cmd'(sp_changearticle) 또는 'pre_creation_command'(sp_changemergearticle)를 지정하고 @value 매개 변수에 'none', 'delete' 또는 'truncate' 값을 지정합니다.Specify a value of 'pre_creation_cmd' (sp_changearticle) or 'pre_creation_command' (sp_changemergearticle) for the parameter @property and a value of 'none', 'delete' or 'truncate' for the parameter @value.

    • 아티클 속성 - <Article> 대화 상자의 대상 개체 섹션에서 기존 개체를 변경하지 않고 유지, 데이터를 삭제합니다. 아티클에 행 필터가 있으면 필터에 대응하는 데이터만 삭제합니다.In the Article Properties - <Article> dialog box in the Destination Object section, select a value of Keep existing object unchanged, Delete data. If article has a row filter, delete only data that matches the filter. 또는 기존 개체의 모든 데이터를 잘라냅니다. 값을 이름이 사용 중일 때 수행할 동작를 참조하세요.or Truncate all data in the existing object for the option Action if name is in use. 이 대화 상자에 액세스하는 방법은 게시 속성 보기 및 수정을 참조하세요.For more information on accessing this dialog box, see View and Modify Publication Properties.

데이터베이스 유지 관리Database Maintenance

게시된 테이블에서 TRUNCATE TABLE이 실행되지 않는 이유는 무엇입니까?Why can't I run TRUNCATE TABLE on a published table?

TRUNCATE TABLE은 트리거를 발생시키지 않는 로그되지 않은 작업입니다.TRUNCATE TABLE is a non-logged operation that does not fire triggers. 복제가 해당 작업으로 인한 변경 내용을 추적할 수 없으므로 TRUNCATE TABLE은 허용되지 않습니다. 트랜잭션 복제는 트랜잭션 로그를 통해 변경 내용을 추적하고 병합 복제는 게시된 테이블의 트리거를 통해 변경 내용을 추적합니다.It is not permitted because replication cannot track the changes caused by the operation: transactional replication tracks changes through the transaction log; merge replication tracks changes through triggers on published tables.

복제된 데이터베이스에서 BULK INSERT 명령을 실행하면 어떻게 됩니까?What is the effect of running a bulk insert command on a replicated database?

트랜잭션 복제의 경우 다른 삽입처럼 대량 삽입도 추적되어 복제됩니다.For transactional replication, bulk inserts are tracked and replicated like other inserts. 병합 복제의 경우 변경 내용 추적 메타데이터를 적절하게 업데이트해야 합니다.For merge replication, you must ensure that change tracking metadata is updated properly.

백업 및 복원에 대한 복제 고려 사항이 있습니까?Are there any replication considerations for backup and restore?

Yes. 복제에 관련된 데이터베이스에 대해 특별히 고려해야 할 사항이 많이 있습니다.There are a number of special considerations for databases that are involved in replication. 자세한 내용은 복제된 데이터베이스 백업 및 복원을 참조하세요.For more information, see Back Up and Restore Replicated Databases.

복제가 트랜잭션 로그의 크기에 영향을 미칩니까?Does replication affect the size of the transaction log?

병합 복제 및 스냅숏 복제는 트랜잭션 로그 크기에 영향을 주지 않지만 트랜잭션 복제는 영향을 줄 수 있습니다.Merge replication and snapshot replication do not affect transaction log size, but transactional replication can. 데이터베이스에 하나 이상의 트랜잭션 게시를 포함하는 경우 로그는 게시와 관련된 모든 트랜잭션이 배포 데이터베이스에 배달될 때까지 잘리지 않습니다.If a database includes one or more transactional publications, the log is not truncated until all transactions relevant to the publications have been delivered to the distribution database. 로그 판독기 에이전트가 일정에 따라 실행되는 경우 트랜잭션 로그가 너무 방대해지면 일정 실행 간격을 좁히거나If the transaction log is growing too large, and the Log Reader Agent is running on a scheduled basis, consider shortening the interval between runs. 일정이 연속 모드에서 실행되도록 설정하십시오.Or, set it to run in continuous mode. 연속 모드에서 실행되도록 설정(기본값)한 경우 로그 판독기 에이전트가 실행되고 있는지 확인하십시오.If it is set to run in continuous mode (the default), ensure that it is running. 로그 판독기 에이전트 상태 확인에 대한 자세한 내용은 게시 관련 에이전트에 대한 정보 보기 및 태스크 수행(복제 모니터)을 참조하세요.For more information on checking Log Reader Agent status, see View Information and Perform Tasks for the Agents Associated With a Publication (Replication Monitor).

또한 게시 데이터베이스나 배포 데이터베이스에서 'sync with backup' 옵션을 설정한 경우 트랜잭션이 모두 백업될 때까지 트랜잭션 로그가 잘리지 않습니다.Additionally, if you have set the option 'sync with backup' on the publication database or distribution database, the transaction log is not truncated until all transactions have been backed up. 이 옵션을 설정한 경우 트랜잭션 로그가 너무 방대해지면 트랜잭션 로그 백업 간격을 좁히십시오.If the transaction log is growing too large, and you have this option set, consider shortening the interval between transaction log backups. 백업 및 트랜잭션 복제와 관련된 데이터베이스 복원에 대한 자세한 내용은 스냅숏 및 트랜잭션 복제의 백업 및 복원을 위한 전략을 참조하세요.For more information on backing up and restoring databases involved in transactional replication, see Strategies for Backing Up and Restoring Snapshot and Transactional Replication.

복제된 데이터베이스에서 인덱스나 테이블을 어떻게 다시 작성합니까?How do I rebuild indexes or tables in replicated databases?

인덱스를 다시 작성하는 메커니즘은 다양합니다.There are a variety of mechanisms for rebuilding indexes. 이러한 메커니즘은 복제에 대한 특별한 고려 사항 없이 모두 사용 가능합니다. 한 가지 예외는 트랜잭션 게시의 테이블에는 기본 키가 필요하므로 이러한 테이블에서는 기본 키를 삭제하고 다시 만들 수 없다는 것입니다.They can all be used with no special considerations for replication, with the following exception: primary keys are required on tables in transactional publications, so you cannot drop and recreate primary keys on these tables.

게시 및 구독 데이터베이스에서 인덱스를 어떻게 추가하고 변경합니까?How do I add or change indexes on publication and subscription databases?

복제에 대한 특별한 고려 사항 없이 인덱스를 게시자나 구독자에 추가할 수 있습니다. 그러나 인덱스는 성능에 영향을 미칠 수 있습니다.Indexes can be added at the Publisher or Subscribers with no special considerations for replication (be aware that indexes can affect performance). CREATE INDEX와 ALTER INDEX는 복제되지 않으므로 예를 들어 게시자에서 인덱스를 추가하거나 변경하는 경우 구독자에 이러한 내용을 반영하려면 구독자에서도 동일한 작업을 수행해야 합니다.CREATE INDEX and ALTER INDEX are not replicated, so if you add or change an index at, for example, the Publisher, you must make the same addition or change at the Subscriber if you want it reflected there.

복제에 관련된 데이터베이스의 파일은 어떻게 이동하며 이름은 어떻게 바꿉니까?How do I move or rename files for databases involved in replication?

SQL ServerSQL Server 이전 버전의 SQL Server 2005SQL Server 2005에서는 데이터베이스 파일을 이동하거나 이름을 바꾸려면 해당 데이터베이스를 분리하고 다시 연결해야 했습니다.In versions of SQL ServerSQL Server prior to SQL Server 2005SQL Server 2005, moving or renaming database files required detaching and reattaching the database. 그러나 복제된 데이터베이스는 분리할 수 없으므로 먼저 이러한 데이터베이스에서 복제를 제거해야 했습니다.Because a replicated database cannot be detached, replication had to be removed from these databases first. SQL Server 2005SQL Server 2005부터는 데이터베이스를 분리하거나 다시 연결하지 않고도 복제에 아무런 영향을 미치지 않으면서 파일을 이동하거나 이름을 바꿀 수 있습니다.Beginning with SQL Server 2005SQL Server 2005, you can move or rename files without detaching and re-attaching the database, with no effect on replication. 파일을 이동하고 이름을 바꾸는 방법은 ALTER DATABASE(Transact-SQL)를 참조하세요.For more information about moving and renaming files, see ALTER DATABASE (Transact-SQL).

복제 중인 테이블을 어떻게 삭제합니까?How do I drop a table that is being replicated?

먼저 sp_droparticle, sp_dropmergearticle 또는 게시 속성 - <게시> 대화 상자를 사용하여 게시에서 아티클을 삭제한 다음 DROP <Object>를 사용하여 데이터베이스에서 아티클을 삭제합니다.First drop the article from the publication using sp_droparticle, sp_dropmergearticle, or the Publication Properties - <Publication> dialog box, and then drop it from the database using DROP <Object>. 구독이 추가된 후에는 스냅숏 또는 트랜잭션 게시에서 아티클을 삭제할 수 없습니다. 따라서 먼저 구독을 삭제해야 합니다.You cannot drop articles from snapshot or transactional publications after subscriptions have been added; you must drop the subscriptions first. 자세한 내용은 기존 게시에 대한 아티클 추가 및 삭제를 참조하세요.For more information, see Add Articles to and Drop Articles from Existing Publications.

게시된 테이블에서 열을 어떻게 추가하고 삭제합니까?How do I add or drop columns on a published table?

SQL ServerSQL Server 에서는 열 추가 및 삭제를 비롯하여 게시된 개체에 대한 다양한 스키마 변경을 수행할 수 있습니다. supports a wide variety of schema changes on published objects, including adding and dropping columns. 예를 들어 게시자에서 ALTER TABLE ...For example, execute ALTER TABLE … DROP COLUMN을 실행하면 해당 문이 구독자로 복제된 다음 실행되어 해당 열을 삭제합니다.DROP COLUMN at the Publisher, and the statement is replicated to Subscribers and then executed to drop the column. SQL ServerSQL Server 이전 버전의 SQL Server 2005SQL Server 2005 를 실행하는 구독자는 sp_repladdcolumnsp_repldropcolumn저장 프로시저를 통해 열을 추가 및 삭제할 수 있습니다.Subscribers running versions of SQL ServerSQL Server prior to SQL Server 2005SQL Server 2005 support adding and dropping columns through the stored procedures sp_repladdcolumn and sp_repldropcolumn. 자세한 내용은 게시 데이터베이스의 스키마 변경을 참조하세요.For more information, see Make Schema Changes on Publication Databases.

복제 유지 관리Replication Maintenance

구독자의 데이터가 게시자의 데이터와 동기화되었는지 어떻게 확인합니까?How do I determine if the data at Subscribers is synchronized with data at the Publisher?

유효성 검사를 사용합니다.Use validation. 유효성 검사는 지정된 구독자가 게시자와 동기화되었는지 여부를 보고합니다.Validation reports on whether a given Subscriber is synchronized with the Publisher. 자세한 내용은 복제된 데이터의 유효성 검사를 참조하세요.For more information, see Validate Replicated Data. 유효성 검사는 올바르게 동기화되지 않은 행이 있는 경우 해당 행에 대한 정보를 제공하지 않지만 tablediff 유틸리티 에서는 이러한 정보를 제공합니다.Validation does not provide information on which rows if any are not synchronized correctly, but the tablediff utility does.

기존 게시에 어떻게 테이블을 추가합니까?How do I add a table to an existing publication?

테이블이나 다른 개체를 추가하기 위해 게시 또는 구독 데이터베이스의 작업을 중지하지 않아도 됩니다.It is not necessary to stop activity on the publication or subscription databases in order to add a table (or another object). 게시 속성 - <Publication> 대화 상자나 sp_addarticlesp_addmergearticle 저장 프로시저를 통해 게시에 테이블을 추가합니다.Add a table to a publication through the Publication Properties - <Publication> dialog box or the stored procedures sp_addarticle and sp_addmergearticle. 자세한 내용은 기존 게시에 대한 아티클 추가 및 삭제를 참조하세요.For more information, see Add Articles to and Drop Articles from Existing Publications.

게시에서 테이블을 어떻게 제거합니까?How do I remove a table from a publication?

먼저 sp_droparticle, sp_dropmergearticle 또는 게시 속성 - <게시> 대화 상자를 사용하여 게시에서 테이블을 제거합니다.Remove a table from the publication using sp_droparticle, sp_dropmergearticle, or the Publication Properties - <Publication> dialog box. 구독이 추가된 후에는 스냅숏 또는 트랜잭션 게시에서 아티클을 삭제할 수 없습니다. 따라서 먼저 구독을 삭제해야 합니다.You cannot drop articles from snapshot or transactional publications after subscriptions have been added; you must drop the subscriptions first. 자세한 내용은 기존 게시에 대한 아티클 추가 및 삭제를 참조하세요.For more information, see Add Articles to and Drop Articles from Existing Publications.

구독을 다시 초기화해야 하는 동작에는 어떤 것이 있습니까?What actions require subscriptions to be reinitialized?

일부 아티클 및 게시를 변경하면 구독을 다시 초기화해야 합니다.There are a number of article and publication changes that require subscriptions to be reinitialized. 자세한 내용은 게시 및 아티클 속성 변경을 참조하세요.For more information, see Change Publication and Article Properties.

스냅숏을 무효화하는 동작에는 어떤 것이 있습니까?What actions cause snapshots to be invalidated?

일부 아티클 및 게시를 변경하면 스냅숏이 무효화되어 새 스냅숏을 생성해야 합니다.There are a number of article and publication changes that invalidate snapshots and require a new snapshot to be generated. 자세한 내용은 게시 및 아티클 속성 변경을 참조하세요.For more information, see Change Publication and Article Properties.

복제를 어떻게 제거합니까?How do I remove replication?

데이터베이스에서 복제를 제거하는 데 필요한 동작은 데이터베이스가 게시 데이터베이스 역할을 하는지 구독 데이터베이스 역할을 하는지 아니면 두 역할을 다 하는지에 따라 달라집니다.The actions required to remove replication from a database depend on whether the database served as a publication database, subscription database, or both.

복제할 트랜잭션이나 행이 있는지 여부를 어떻게 확인합니까?How do I determine whether there are transactions or rows to be replicated?

트랜잭션 복제의 경우 저장 프로시저를 사용하거나 복제 모니터에서 배포되지 않은 명령 탭을 사용합니다.For transactional replication, use stored procedures or the Undistributed Commands tab in Replication Monitor. 자세한 내용은 배포 데이터베이스의 복제된 명령 및 기타 정보 보기(복제 Transact-SQL 프로그래밍)구독 관련 에이전트에 대한 정보 보기 및 태스크 수행(복제 모니터)을 참조하세요.For more information, see View Replicated Commands and Other Information in the Distribution Database (Replication Transact-SQL Programming) and View Information and Perform Tasks for the Agents Associated With a Subscription (Replication Monitor).

병합 복제의 경우 sp_showpendingchanges저장 프로시저를 사용합니다.For merge replication, use the stored procedure sp_showpendingchanges. 자세한 내용은 sp_showpendingchanges(Transact-SQL)를 참조하세요.For more information, see sp_showpendingchanges (Transact-SQL).

배포 에이전트가 얼마나 오래 되었는지 어떻게 확인합니까?How far behind is the Distribution Agent? 다시 초기화해야 합니까?Should I reinitialize?

sp_replmonitorsubscriptionpendingcmds 저장 프로시저를 사용하거나 복제 모니터에서 배포되지 않은 명령 탭을 사용합니다.Use the sp_replmonitorsubscriptionpendingcmds stored procedure or the Undistributed Commands tab in Replication Monitor. 저장 프로시저와 탭에는 다음 내용이 표시됩니다.The stored procedure and tab display:

복제 및 기타 데이터베이스 기능Replication and Other Database Features

복제가 로그 전달 및 데이터베이스 미러링과 함께 작동합니까?Does replication work in conjunction with log shipping and database mirroring?

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

복제가 클러스터링과 함께 작동합니까?Does replication work in conjunction with clustering?

Yes. 모든 데이터가 클러스터의 한 디스크 세트에 저장되므로 특별히 고려해야 할 사항은 없습니다.No special considerations are required because all data is stored on one set of disks on the cluster.

참고 항목See Also

관리(복제) Administration (Replication)
Best Practices for Replication AdministrationBest Practices for Replication Administration