일반적인 복제 성능 향상Enhance General Replication Performance

이 항목에서 설명하는 지침을 따르면 응용 프로그램 및 네트워크에서 모든 복제 유형의 일반적인 성능을 향상시킬 수 있습니다.You can enhance the general performance for all types of replication in your application and on your network by using the guidelines described in this topic.

서버 및 네트워크Server and Network

  • MicrosoftMicrosoft SQL Server 데이터베이스 엔진SQL Server Database Engine에 할당될 최소 및 최대 메모리 양을 설정합니다.Set the minimum and maximum amount of memory allocated to MicrosoftMicrosoft SQL Server 데이터베이스 엔진SQL Server Database Engine.

    기본적으로 데이터베이스 엔진Database Engine 은 사용할 수 있는 시스템 리소스에 따라 메모리 요구 사항을 동적으로 변경합니다.By default, the 데이터베이스 엔진Database Engine changes its memory requirements dynamically based on available system resources. 복제 작업 중 사용 가능한 메모리의 부족을 방지하기 위해 min server memory 옵션을 사용해서 사용 가능한 최소 메모리를 설정합니다.To avoid low memory availability during replication activities, use the min server memory option to set the minimum available memory. 메모리를 확보하기 위해 운영 체제가 디스크로 페이징하지 않도록 하기 위해 max server memory 옵션을 사용하여 최대 메모리를 설정할 수도 있습니다.To avoid having the operating system page to disc for memory, you can also set a maximum amount of memory with the max server memory option. 자세한 내용은 서버 메모리 서버 구성 옵션을 참조하세요.For more information, see Server Memory Server Configuration Options.

  • 데이터베이스 데이터 파일 및 로그 파일이 적절히 할당되도록 합니다.Ensure proper allocation of database data files and log files. 복제와 관련된 모든 데이터베이스의 트랜잭션 로그에 별도의 디스크 드라이브를 사용합니다.Use a separate disk drive for the transaction log for all databases involved in replication.

    데이터베이스를 저장하는 데 사용한 디스크 드라이브가 아닌 별개의 디스크 드라이브에 로그 파일을 기록해서 트랜잭션을 기록하는 데 필요한 시간을 줄일 수 있습니다.You can decrease the time it takes to write transactions by storing the log files on a disk drive different than the one used to store the database. 내결함성이 필요하다면 RAID(Redundant Array of Inexpensive Disks)-1을 사용하여 이 드라이브를 미러링할 수 있습니다.You can mirror that drive, using a Redundant Array of Inexpensive Disks (RAID)-1, if you require fault tolerance. 다른 데이터베이스 파일에 대해서는 내결함성에 대한 필요에 따라 RAID 0 또는 0+1을 사용합니다.Use RAID 0 or 0+1 (depending on your need for fault tolerance) for other database files. 이는 복제가 사용 중인지 여부에 상관없이 일반적으로 사용됩니다.This is a good practice regardless of whether or not replication is being used.

  • 복제에 사용하는 서버, 특히 배포자에 메모리를 추가해 봅니다.Consider adding memory to servers used in replication, particularly the Distributor.

  • 다중 프로세서 컴퓨터를 사용합니다.Use multiprocessor computers.

    서버에 프로세서를 추가하면 복제 에이전트의 성능이 향상됩니다.Replication agents can take advantage of additional processors on the server. CPU 사용량이 높은 경우 보다 빠른 CPU 하나를 설치하거나 CPU를 여러 개 설치해 봅니다.If you are running at high CPU usage, consider installing a faster CPU or multiple CPUs.

  • 빠른 네트워크를 사용합니다.Use a fast network.

    트랜잭션 복제의 경우 특히 네트워크로 인해 심각한 성능 병목 상태가 발생할 수 있습니다.The network can be a significant performance bottleneck, particularly for transactional replication. 100Mbps 이상의 빠른 네트워크를 사용하여 변경 내용을 구독자로 전파하는 기능을 크게 향상시킬 수 있습니다.The propagation of changes to Subscribers can be significantly enhanced by using a fast network of 100 megabits per second (Mbps) or faster. 네트워크 속도가 느린 경우 네트워크 설정 및 에이전트 매개 변수를 적절히 지정합니다.If the network is slow, specify appropriate network settings and agent parameters.

데이터베이스 디자인Database Design

  • 최상의 데이터베이스 디자인 방법을 따릅니다.Follow best practices for database design.

    일반적으로 복제된 데이터베이스에 대한 성능 최적화의 영향은 복제되지 않은 데이터베이스에 대한 성능 최적화의 영향과 거의 동일합니다.A replicated database generally benefits from the same performance optimizations as a non-replicated database. 그러나 구독자에서 인덱스를 사용할 때는 주의해야 합니다. 구독자의 기본 키 열을 인덱싱해야 하지만 추가 인덱스가 삽입, 업데이트 및 삭제 성능에 영향을 줄 수 있습니다.However, indexes should be used with caution at the Subscriber: the primary key column at the Subscriber should be indexed, but additional indexes can affect insert, update, and delete performance.

  • READ_COMMITTED_SNAPSHOT 데이터베이스 옵션을 설정해 봅니다.Consider setting the READ_COMMITTED_SNAPSHOT database option.

    사용자 작업과 복제 에이전트 작업 간 경합을 줄이려면 게시 및 구독 데이터베이스에 대해 이 옵션을 설정하십시오.To help reduce contention between user activity and replication agent activity, set this option for the publication and subscription databases:

    ALTER DATABASE AdventureWorks  
    SET READ_COMMITTED_SNAPSHOT ON  
    

    자세한 내용은 ALTER DATABASE(Transact-SQL)를 참조하세요.For more information, see ALTER DATABASE (Transact-SQL).

  • 트리거의 응용 프로그램 논리에 유의합니다.Be cautious with application logic in triggers.

    구독자의 사용자 정의 트리거에 있는 비즈니스 논리로 인해 구독자에 대한 변경 내용 복제의 속도가 느려질 수 있습니다.Business logic in user-defined triggers at the Subscriber can slow down the replication of changes to the Subscriber:

  • LOB(Large Object) 데이터 형식의 사용을 제한합니다.Limit the use of Large Object (LOB) data types.

    LOB은 다른 열 데이터 형식보다 많은 저장 공간과 처리 작업을 필요로 합니다.LOBs require more storage space and processing than other column data types. 응용 프로그램에 필요한 경우가 아니면 이러한 열을 아티클에 포함하지 마십시오.Do not include these columns in articles unless necessary for your application. text, ntextimage 데이터 형식은 사용되지 않습니다.The data types text, ntext, and image are deprecated. LOB를 포함시킬 경우 데이터 형식 varchar(max), nvarchar(max), varbinary(max)를 각각 사용하는 것이 좋습니다.If you do include LOBs, we recommend that you use the data types varchar(max), nvarchar(max), varbinary(max), respectively.

    트랜잭션 복제의 경우 OLEDB 스트리밍에 대한 배포 프로필이라고 하는 배포 에이전트 프로필을 사용해 보십시오.For transactional replication, consider using the Distribution Agent profile called Distribution Profile for OLEDB streaming. 자세한 내용은 Replication Agent Profiles을 참조하세요.For more information, see Replication Agent Profiles.

게시 디자인Publication Design

  • 필요한 데이터만 게시합니다.Publish only the data required.

    복제는 설정하기가 쉽기 때문에 실제로 필요한 것보다 많은 데이터를 게시하는 경향이 있습니다.Because replication is easy to set up, there is a tendency to publish more data than is actually required. 이로 인해 배포 데이터베이스 및 스냅숏 파일에서 리소스가 추가로 소모될 뿐만 아니라 필요한 데이터에 대한 처리량이 낮아질 수 있습니다.This can consume additional resources within the distribution databases and snapshot files, and can lower the throughput for required data. 불필요한 테이블 게시를 피하고 게시 업데이트 빈도를 줄일 것을 고려합니다.Avoid publishing unnecessary tables and consider updating publications less frequently.

  • 게시 디자인 및 응용 프로그램 동작을 통해 충돌을 최소화합니다.Minimize conflicts through publication design and application behavior.

    병합 복제, 업데이트할 수 있는 구독이 있는 트랜잭션 복제 또는 피어 투 피어 트랜잭션 복제를 사용하여 구독자에서 데이터를 변경할 수 있습니다.The following types of replication allow data to be changed at Subscribers: merge replication, transactional replication with updatable subscriptions, and peer-to-peer transactional replication. 병합 복제 및 업데이트할 수 있는 구독이 있는 트랜잭션 복제에서는 동기화 중 두 개 이상의 노드에서 지정된 행이 업데이트되는 경우 데이터 충돌이 지원됩니다.Merge replication and transactional replication with updatable subscriptions support data conflicts if a given row is updated at more than one node between synchronizations. 피어 투 피어 복제에서는 데이터 충돌이 지원되지 않으므로 데이터 변경 내용을 분할해야 합니다.Peer-to-peer replication does not support data conflicts; data changes must be partitioned. 사용된 복제 유형에 관계없이 가능하면 변경 내용을 분할하는 것이 좋습니다. 이렇게 하면 충돌 감지 및 해결 과정이 간단해집니다.Regardless of the type of replication used, we recommend that you partition changes whenever possible, because this reduces the processing required for conflict detection and resolution.

    데이터 하위 집합을 각 구독자에 게시하거나 응용 프로그램이 지정된 행의 변경 내용을 지정된 노드로 직접 게시하도록 하여 변경 내용을 분할할 수 있습니다.Changes can be partitioned by publishing subsets of data to each Subscriber or by having an application direct changes for a given row to a given node:

    • 병합 복제에서는 단일 게시에서 매개 변수가 있는 필터를 사용하여 데이터 하위 집합을 게시할 수 있습니다.Merge replication supports publishing subsets of data using parameterized filters with a single publication. 자세한 내용은 Parameterized Row Filters을 참조하세요.For more information, see Parameterized Row Filters.

    • 트랜잭션 복제에서는 여러 게시에서 정적 필터를 사용하여 데이터 하위 집합을 게시할 수 있습니다.Transactional replication supports publishing subsets of data using static filters with multiple publications. 자세한 내용은 게시된 데이터 필터링을 참조하세요.For more information, see Filter Published Data.

  • 행 필터를 주의해서 사용합니다.Use row filters judiciously.

    트랜잭션 게시에 행 필터를 사용하는 아티클이 하나 이상 있을 경우 로그 판독기 에이전트는 트랜잭션 로그를 검색할 때 테이블 업데이트에 의해 영향을 받는 각 행에 필터를 적용해야 합니다.When a transactional publication includes one or more articles that use row filters, the Log Reader Agent must apply the filter to each row affected by an update to the table as it scans the transaction log. 따라서 로그 판독기 에이전트의 처리량은 영향을 받게 됩니다.The throughput of the Log Reader Agent is therefore affected.

    마찬가지로 병합 에이전트는 변경되거나 삭제된 행을 평가하여 이러한 행을 받을 구독자를 결정해야 합니다.Similarly, merge replication must evaluate changed or deleted rows to determine which Subscribers should receive those rows. 구독자에 필요한 데이터를 줄이는 데 행 필터가 사용되면 이러한 처리는 모든 행을 한 테이블에서 게시할 때 보다 복잡해지고 느려질 수 있습니다.When row filters are employed to reduce the data required at a Subscriber, this processing is more complex and can be slower than when you publish all rows in a table. 각 구독자에서 저장소 요구 사항을 줄이는 것과 최대 처리량을 달성해야 할 필요성 간의 관계를 신중하게 고려합니다.Consider carefully the tradeoff between reduced storage requirements at each Subscriber and the need for achieving maximum throughput. 필터링에 대한 자세한 내용은 게시된 데이터 필터링을 참조하세요.For more information on filtering, see Filter Published Data.

구독 고려 사항Subscription Considerations

  • 다수의 구독자가 있을 경우 끌어오기 구독을 사용합니다.Use pull subscriptions when there are a large number of Subscribers.

    배포 에이전트와 병합 에이전트는 밀어넣기 구독의 경우에는 배포자에서, 끌어오기 구독의 경우에는 구독자에서 실행됩니다.The Distribution Agent and Merge Agent run at the Distributor for push subscriptions, and at Subscribers for pull subscriptions. 끌어오기 구독을 사용하면 배포자에서 구독자로 에이전트 처리를 이동하여 성능을 향상시킬 수 있습니다.Using pull subscriptions can improve performance by moving agent processing from the Distributor to Subscribers. 자세한 내용은 게시 구독을 참조하세요.For more information, see Subscribe to Publications.

  • 구독자가 너무 오래된 경우 구독을 다시 초기화합니다.Consider reinitialization of the subscription if Subscribers are too far behind.

    많은 양의 변경 내용을 구독자로 보내야 할 경우 이를 새 스냅숏과 함께 다시 초기화하면 복제를 사용하여 개별 변경 내용을 이동하는 것보다 빠르게 보낼 수 있습니다.When large amounts of changes need to be sent to Subscribers, reinitializing them with a new snapshot might be faster than using replication to move the individual changes. 자세한 내용은 구독 다시 초기화를 참조하세요.For more information, see Reinitialize Subscriptions.

    트랜잭션 복제의 경우 복제 모니터는 배포되지 않은 명령 탭에 구독자로 아직 배포되지 않은 배포 데이터베이스의 트랜잭션 수와 이러한 트랜잭션에 대한 예상 배포 시간 등을 표시합니다.For transactional replication, Replication Monitor displays on the Undistributed Commands tab information about: the number of transactions in the distribution database that have not yet been distributed to a Subscriber; and the estimated time for distributing these transactions. 자세한 내용은 구독 관련 에이전트에 대한 정보 보기 및 태스크 수행(복제 모니터)을 참조하세요.For more information, see View Information and Perform Tasks for the Agents Associated With a Subscription (Replication Monitor).

스냅숏 고려 사항Snapshot Considerations

  • 필요할 경우와 사용률이 낮은 시간에만 스냅숏 에이전트를 실행합니다.Run the Snapshot Agent only when necessary and at off-peak times.

    스냅숏 에이전트는 게시자에 있는 게시된 테이블의 데이터를 배포자에 있는 스냅숏 폴더의 파일에 대량 복사합니다.The Snapshot Agent bulk copies data from the published table on the Publisher to a file in the snapshot folder on the Distributor. 스냅숏 생성 프로세스는 리소스를 많이 소모할 수 있으며 사용률이 낮은 시간에 사용하는 것이 좋습니다.Generating a snapshot can be a resource intensive process and is best scheduled during off-peak times.

  • 문자 모드 스냅숏이 필요한 경우가 아니라면 기본 모드 스냅숏을 사용합니다.Use a native mode snapshot unless a character mode snapshot is required.

    문자 모드 스냅숏이 필요한 SQL ServerSQL Server 이외의 구독자와 SQL Server CompactSQL Server Compact를 실행하는 구독자를 제외하고 모든 구독자에 대해 기본값인 기본 모드 스냅숏을 사용합니다.Use the default native mode snapshot for all Subscribers except non- SQL ServerSQL Server Subscribers and Subscribers running SQL Server CompactSQL Server Compact, which require a character mode snapshot.

  • 게시에 대해 단일 스냅숏 폴더를 사용합니다.Use a single snapshot folder for a publication.

    스냅숏 위치와 관련된 게시 속성을 지정하는 경우 기본 스냅숏 폴더, 대체 스냅숏 폴더 또는 두 폴더 모두에 스냅숏 파일을 생성하도록 선택할 수 있습니다.When specifying the publication properties related to snapshot location, you can choose to generate snapshot files to the default snapshot folder, to an alternate snapshot folder, or to both. 두 위치 모두에 스냅숏 파일을 생성하려면 스냅숏 에이전트 실행 시 추가 디스크 공간 및 추가 처리가 필요합니다.Generating snapshot files in both locations requires additional disk space and more processing when the Snapshot Agent runs.

  • 데이터베이스 또는 로그 파일 저장에 사용되지 않는 배포자의 로컬 드라이브에 스냅숏 폴더를 둡니다.Place the snapshot folder on a drive local to the Distributor that is not used to store database or log files.

    스냅숏 에이전트는 스냅숏 폴더에 데이터를 순차적으로 씁니다.The Snapshot Agent performs a sequential write of data to the snapshot folder. 다른 데이터베이스나 로그 파일과 분리된 별도의 드라이브에 스냅숏 폴더를 두면 디스크 간 경합을 줄이고 스냅숏 과정을 좀 더 빠르게 완료할 수 있습니다.Placing the snapshot folder on a separate drive from any database or log files reduces contention among the disks and helps the snapshot process complete faster.

  • 구독자에서 구독 데이터베이스를 만들 때는 단순 또는 대량 로그 복구 모델을 지정합니다.When you create the subscription database at the Subscriber, consider specifying a recovery model of simple or bulk-logged. 이렇게 하면 구독자에서 스냅숏을 적용하는 동안 수행된 대량 삽입의 로깅이 최소화됩니다.This allows minimal logging of the bulk inserts performed during the application of the snapshot at the Subscriber. 스냅숏이 구독 데이터베이스에 적용된 후 필요에 따라 다른 복구 모델로 변경할 수 있습니다. 복제된 데이터베이스는 모든 복구 모델을 사용할 수 있습니다.After the snapshot has been applied to the subscription database, you can change to a different recovery model if necessary (replicated databases can use any of the recovery models). 복구 모델을 선택하는 방법은 복원 및 복구 개요(SQL Server)를 참조하세요.For more information about selecting a recovery model, see Restore and Recovery Overview (SQL Server).

  • 느린 대역폭 네트워크의 경우 이동식 미디어에서 대체 스냅숏 폴더와 압축 스냅숏을 사용해 봅니다.Consider using the alternate snapshot folder and compressed snapshots on removable media for low-bandwidth networks.

    대체 스냅숏 폴더의 스냅숏 파일을 압축하면 스냅숏에 필요한 디스크 용량을 줄일 수 있으며 이동식 미디어에서 스냅숏 파일을 보다 간단하게 전송할 수 있습니다.Compressing snapshot files in the alternate snapshot folder can reduce snapshot disk storage requirements and make it easier to transfer snapshot files on removable media.

    스냅숏을 압축하면 네트워크에서의 스냅숏 파일 전송 성능이 향상되는 경우도 있습니다.Compressed snapshots can, in some cases, improve the performance of transferring snapshot files across the network. 그러나 스냅숏 에이전트에서 스냅숏 파일을 생성하는 경우와 배포 에이전트 또는 병합 에이전트에서 스냅숏 파일을 적용하는 경우에 스냅숏 파일을 압축하려면 추가 처리 작업이 필요합니다.However, compressing the snapshot requires additional processing by the Snapshot Agent when generating the snapshot files, and by the Distribution Agent or Merge Agent when applying the snapshot files. 이 경우 스냅숏 생성 속도가 느려지거나 스냅숏 적용 시간이 늘어날 수 있습니다.This may slow down snapshot generation and increase the time it takes to apply a snapshot in some cases. 또한 네트워크 오류가 발생하면 압축 스냅숏은 재개할 수 없으므로 불안정한 네트워크에서는 압축 스냅숏이 적합하지 않습니다.Additionally, compressed snapshots cannot be resumed if a network failure occurs; therefore they are not suitable for unreliable networks. 네트워크에서 압축 스냅숏을 사용하는 경우 이러한 장단점을 신중하게 고려하여 균형을 맞추는 것이 좋습니다.Consider these tradeoffs carefully when using compressed snapshots across a network. 자세한 내용은 Alternate Snapshot Folder LocationsCompressed Snapshots를 참조하세요.For more information, see Alternate Snapshot Folder Locations and Compressed Snapshots.

  • 구독을 수동으로 초기화해 봅니다.Consider initializing a subscription manually.

    큰 초기 데이터 집합과 관련된 일부 시나리오에서는 스냅숏 대신 다른 방법을 사용하여 구독을 초기화하는 것이 좋습니다.In some scenarios, such as those involving large initial datasets, it is preferable to initialize a subscription using a method other than a snapshot. 자세한 내용은 스냅숏 없이 트랜잭션 구독 초기화를 참조하세요.For more information, see Initialize a Transactional Subscription Without a Snapshot.

에이전트 매개 변수Agent Parameters

  • 초기 테스트, 모니터링 또는 디버깅 도중을 제외하고 복제 에이전트의 정보 표시 수준을 줄입니다.Reduce the verbose levels of replication agents except during initial testing, monitoring, or debugging.

    배포 에이전트 및 병합 에이전트의 –HistoryVerboseLevel 매개 변수 및 –OutputVerboseLevel 매개 변수를 줄입니다.Reduce the –HistoryVerboseLevel parameter and the –OutputVerboseLevel parameter of the Distribution Agents or Merge Agents. 이렇게 하면 추적 에이전트 기록 및 출력에 삽입되는 새 행의 수가 줄어듭니다.This reduces the number of new rows inserted to track agent history and output. 대신 상태가 같은 이전 기록 메시지는 새 기록 정보로 업데이트됩니다.Instead, previous history messages with the same status are updated to the new history information. 에이전트 작업에 대한 정보를 최대한 많이 가질 수 있도록 테스트, 모니터링 및 디버깅의 정보 표시 수준을 늘립니다.Increase the verbose levels for testing, monitoring, and debugging so that you have as much information about agent activity as possible.

  • 스냅숏 에이전트, 병합 에이전트 및 배포 에이전트의 –MaxBCPThreads 매개 변수를 사용합니다. 지정된 스레드 수는 컴퓨터의 프로세서 수를 초과할 수 없습니다.Use the –MaxBCPThreads parameter of the Snapshot Agent, Merge Agent, and Distribution Agent (the number of threads specified should not exceed the number of processors on the computer). 이 매개 변수는 스냅숏이 생성되어 적용될 때 병렬로 수행할 수 있는 대량 복사 작업 수를 지정합니다.This parameter specifies the number of bulk copy operations that can be performed in parallel when the snapshot is created and applied.

  • 배포 에이전트와 병합 에이전트의 –UseInprocLoader 매개 변수를 사용합니다. 게시된 테이블에 XML 열이 있는 경우 이 매개 변수를 사용할 수 없습니다.Use the –UseInprocLoader parameter of the Distribution Agent and the Merge Agent (this parameter cannot be used if published tables include XML columns). 이 매개 변수를 사용할 경우 스냅숏이 적용되면 에이전트가 BULK INSERT 명령을 사용할 수 있습니다.This parameter causes the agent to use the BULK INSERT command when the snapshot is applied.

    에이전트 프로필 및 명령줄에서 에이전트 매개 변수를 지정할 수 있습니다.Agent parameters can be specified in agent profiles and on the command line. 참조 항목:For more information, see:

  • 복제 에이전트 프로필 작업Work with Replication Agent Profiles

  • 복제 에이전트의 명령 프롬프트 매개 변수 보기 및 수정(SQL Server Management Studio)View and Modify Replication Agent Command Prompt Parameters (SQL Server Management Studio)

  • Replication Agent Executables Concepts에 할당될 최소 및 최대 메모리 양을 설정합니다.Replication Agent Executables Concepts.