활성 보조: 읽기 가능한 보조 복제본(Always On 가용성 그룹)Active Secondaries: Readable Secondary Replicas (Always On Availability Groups)

이 항목은 다음에 적용됩니다. 예SQL Server(2016부터 시작)아니요Azure SQL 데이터베이스아니요Azure SQL 데이터 웨어하우스아니요병렬 데이터 웨어하우스THIS TOPIC APPLIES TO: yesSQL Server (starting with 2016)noAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

Always On 가용성 그룹Always On availability groups 활성 보조 기능에는 하나 이상의 보조 복제본(읽기 가능한 보조 복제본)에 대한 읽기 전용 액세스 지원이 포함됩니다.The Always On 가용성 그룹Always On availability groups active secondary capabilities include support for read-only access to one or more secondary replicas (readable secondary replicas). 읽기 가능한 보조 복제본은 해당 보조 데이터베이스 모두에 대한 읽기 전용 액세스를 허용합니다.A readable secondary replica allows read-only access to all its secondary databases. 하지만 읽기 가능한 보조 데이터베이스는 읽기 전용으로 설정되지 않습니다.However, readable secondary databases are not set to read-only. 이러한 데이터베이스는 동적입니다.They are dynamic. 해당 주 데이터베이스에서 변경 내용이 발생하면 보조 데이터베이스도 변경됩니다.A given secondary database changes as changes on the corresponding primary database are applied to the secondary database. 일반적인 보조 복제본의 경우 보조 데이터베이스의 내구성이 있는 메모리 액세스에 최적화된 테이블을 포함한 데이터는 거의 실시간 데이터입니다.For a typical secondary replica, the data, including durable memory optimized tables, in the secondary databases is in near real time. 또한 전체 텍스트 인덱스는 보조 데이터베이스와 동기화됩니다.Furthermore, full-text indexes are synchronized with the secondary databases. 대부분의 경우 주 데이터베이스와 해당하는 보조 데이터베이스 간의 데이터 대기 시간은 몇 초 이내입니다.In many circumstances, data latency between a primary database and the corresponding secondary database is only a few seconds.

주 데이터베이스에서 적용되는 보안 설정은 보조 데이터베이스에서도 유지됩니다.Security settings that occur in the primary databases are persisted to the secondary databases. 여기에는 사용자, 데이터베이스 역할 및 응용 프로그램 역할과 함께 각각의 사용 권한이 포함되며 주 데이터베이스에 TDE(투명한 데이터 암호화)가 설정되어 있는 경우 TDE도 포함됩니다.This includes users, database roles, and applications roles together with their respective permissions and transparent data encryption (TDE), if enabled on the primary database.

참고

보조 데이터베이스에 데이터를 쓸 수는 없지만 tempdb와 같은 시스템 데이터베이스, 사용자 데이터베이스를 비롯하여 보조 복제본을 호스트하는 서버 인스턴스의 읽기/쓰기 데이터베이스에는 데이터를 쓸 수 있습니다.Though you cannot write data to secondary databases, you can write to read-write databases on the server instance that hosts the secondary replica, including user databases and system databases such as tempdb.

Always On 가용성 그룹Always On availability groups 은 읽기 전용 연결 요청을 읽기 가능한 보조 복제본으로 다시 라우팅하는 기능(읽기 전용 라우팅)도 지원합니다. also supports the re-routing of read-intent connection requests to a readable secondary replica (read-only routing). 읽기 전용 라우팅에 대한 자세한 내용은 수신기를 사용하여 읽기 전용 보조 복제본(읽기 전용 라우팅)에 연결을 참조하세요.For information about read-only routing, see Using a Listener to Connect to a Read-Only Secondary Replica (Read-Only Routing).

항목 내용In this Topic:

이점 Benefits

읽기 가능한 보조 복제본에 대한 읽기 전용 연결을 허용하면 다음과 같은 이점이 있습니다.Directing read-only connections to readable secondary replicas provides the following benefits:

  • 주 복제본에서 보조 읽기 전용 작업을 줄여 주므로 중요한 작업을 위해 주 복제본의 리소스를 절약할 수 있습니다.Offloads your secondary read-only workloads from your primary replica, which conserves its resources for your mission critical workloads. 매우 중요한 읽기 작업이 있거나 대기 시간을 허용할 수 없는 작업이 있으면 주 복제본에서 실행해야 합니다.If you have mission critical read-workload or the workload that cannot tolerate latency, you should run it on the primary.

  • 읽기 가능한 보조 복제본을 호스팅하는 시스템에 대한 투자 수익을 향상시킵니다.Improves your return on investment for the systems that host readable secondary replicas.

    또한 읽기 가능한 보조 복제본은 다음과 같이 읽기 전용 작업을 지원합니다.In addition, readable secondaries provide robust support for read-only operations, as follows:

  • 읽기 가능한 보조 데이터베이스에 대한 자동 임시 통계를 통해 디스크 기반 테이블의 읽기 전용 쿼리를 최적화할 수 있습니다.Automatic temporary statistics on readable secondary database optimize read-only queries on disk-based tables. 메모리 액세스에 최적화된 테이블의 경우 누락 통계가 자동으로 생성됩니다.For memory-optimized tables, the missing statistics are created automatically. 하지만 부실 통계의 자동 업데이트는 없습니다.However, there is no auto-update of stale statistics. 주 복제본에서 통계를 수동으로 업데이트해야 합니다.You will need to manually update the statistics on the primary replica. 자세한 내용은 이 항목 뒷부분에 있는 읽기 전용 액세스 데이터베이스에 대한 통계를 참조하세요.For more information, see Statistics for Read-Only Access Databases, later in this topic.

  • 디스크 기반 테이블에 대한 읽기 전용 작업에서는 행 버전 관리를 사용하여 보조 데이터베이스에 대한 차단 경합을 제거합니다.Read-only workloads for disk-based tables use row versioning to remove blocking contention on the secondary databases. 보조 데이터베이스에 대해 실행되는 모든 쿼리는 스냅숏 격리 트랜잭션 수준에 자동으로 매핑되며, 이는 다른 트랜잭션 격리 수준이 명시적으로 설정되어 있는 경우에도 해당됩니다.All queries that run against the secondary databases are automatically mapped to snapshot isolation transaction level, even when other transaction isolation levels are explicitly set. 또한 모든 잠금 힌트가 무시됩니다.Also, all locking hints are ignored. 따라서 읽기/쓰기 경합이 없어집니다.This eliminates reader/writer contention.

  • 메모리 액세스에 최적화된 지속성 테이블에 대한 읽기 전용 작업은 동일한 트랜잭션 격리 수준 제한이 있는 네이티브 저장 프로시저 또는 SQL 상호 운용성을 사용하여 주 데이터베이스에서 액세스하는 것과 정확히 동일한 방법으로 데이터에 액세스합니다( 데이터베이스 엔진의 격리 수준참조).Read-only workloads for memory-optimized durable tables access the data in exactly the same way it is accessed on the primary database, using native stored procedures or SQL Interoperability with the same transaction isolation level limitations (See Isolation Levels in the Database Engine). 주 복제본에서 실행하는 보고 작업이나 읽기 전용 쿼리는 변경할 필요 없이 보조 복제본에서 실행할 수 있습니다.Reporting workload or read-only queries running on the primary replica can be run on the secondary replica without requiring any changes. 마찬가지로, 보조 복제본에서 실행하는 보고 작업이나 읽기 전용 쿼리는 변경할 필요 없이 주 복제본에서 실행할 수 있습니다.Similarly, a reporting workload or read-only queries running on a secondary replica can be run on the primary replica without requiring any changes. 디스크 기반 테이블과 유사하게 보조 데이터베이스에 대해 실행되는 모든 쿼리는 스냅숏 격리 트랜잭션 수준에 자동으로 매핑되며, 이는 다른 트랜잭션 격리 수준이 명시적으로 설정되어 있는 경우에도 해당됩니다.Similar to disk-based tables, all queries that run against the secondary databases are automatically mapped to snapshot isolation transaction level, even when other transaction isolation levels are explicitly set.

  • 보조 복제본에서는 디스크 기반 및 메모리 액세스에 최적화된 테이블 유형 모두에 대해 테이블 변수에서 DML 작업이 허용됩니다.DML operations are allowed on table variables both for disk-based and memory-optimized table types on the secondary replica.

가용성 그룹에 대한 필수 구성 요소 Prerequisites for the Availability Group

  • 읽기 가능한 보조 복제본(필수)Readable secondary replicas (required)

    데이터베이스 관리자는 하나 이상의 복제본을 보조 역할로 실행할 때 모든 연결을 허용하거나(읽기 전용 액세스의 경우에만) 읽기 전용 연결만 허용하도록 구성해야 합니다.The database administrator needs to configure one or more replicas so that, when running under the secondary role, they allow either all connections (just for read-only access) or only read-intent connections.

    참고

    필요한 경우 데이터베이스 관리자는 임의의 가용성 복제본을 주 역할로 실행할 때 읽기 전용 연결을 제외하도록 구성할 수도 있습니다.Optionally, the database administrator can configure any of the availability replicas to exclude read-only connections when running under the primary role.

    자세한 내용은 이 항목 뒷부분에 있는 가용성 복제본에 대한 클라이언트 연결 액세스 정보(SQL Server)와 같은 시스템 데이터베이스, 사용자 데이터베이스를 비롯하여 보조 복제본을 호스트하는 서버 인스턴스의 읽기/쓰기 데이터베이스에는 데이터를 쓸 수 있습니다.For more information, see About Client Connection Access to Availability Replicas (SQL Server).

  • 가용성 그룹 수신기Availability group listener

    읽기 전용 라우팅을 지원하려면 가용성 그룹에 가용성 그룹 수신기가 있어야 합니다.To support read-only routing, an availability group must possess an availability group listener. 읽기 전용 클라이언트는 해당 연결 요청을 이 수신기에 전달해야 하며, 클라이언트의 연결 문자열에서는 응용 프로그램 의도를 "읽기 전용"으로 지정해야 합니다.The read-only client must direct its connection requests to this listener, and the client's connection string must specify the application intent as "read-only." 즉, 해당 연결 요청은 읽기 전용 연결 요청이어야 합니다.That is, they must be read-intent connection requests.

  • 읽기 전용 라우팅Read only routing

    읽기 전용 라우팅 이란 가용성 그룹 수신기에 전달된 들어오는 읽기 전용 연결 요청을 사용 가능하고 읽기 가능한 보조 복제본으로 라우팅하는 SQL Server 기능을 말합니다.Read-only routing refers to the ability of SQL Server to route incoming read-intent connection requests, that are directed to an availability group listener, to an available readable secondary replica. 읽기 전용 라우팅을 위한 필수 구성 요소은 다음과 같습니다.The prerequisites for read-only routing are as follows:

    • 읽기 전용 라우팅을 지원하려면 읽기 가능한 보조 복제본에 읽기 전용 라우팅 URL이 있어야 합니다.To support read-only routing, a readable secondary replica requires a read-only routing URL. 이 URL은 로컬 복제본이 보조 역할로 실행되는 경우에만 적용됩니다.This URL takes effect only when the local replica is running under the secondary role. 필요에 따라 복제본별로 읽기 전용 라우팅 URL을 지정해야 합니다.The read-only routing URL must be specified on a replica-by-replica basis, as needed. 각 읽기 전용 라우팅 URL은 읽기 전용 연결 요청을 지정된 읽기 가능한 보조 복제본으로 라우팅하는 데 사용됩니다.Each read-only routing URL is used for routing read-intent connection requests to a specific readable secondary replica. 일반적으로 모든 읽기 가능한 보조 복제본에는 읽기 전용 라우팅 URL이 할당됩니다.Typically, every readable secondary replica is assigned a read-only routing URL.

    • 주 복제본으로 사용될 때 읽기 전용 라우팅을 지원하도록 할 각 가용성 복제본에 읽기 전용 라우팅 목록이 있어야 합니다.Each availability replica that is to support read-only routing when it is the primary replica requires a read-only routing list. 지정된 읽기 전용 라우팅 목록은 로컬 복제본이 주 역할로 실행되는 경우에만 적용됩니다.A given read-only routing list takes effect only when the local replica is running under the primary role. 필요에 따라 복제본별로 이 목록을 지정해야 합니다.This list must be specified on a replica-by-replica basis, as needed. 일반적으로 각 읽기 전용 라우팅 목록의 끝에는 로컬 복제본의 URL과 함께 모든 읽기 전용 라우팅 URL이 포함됩니다.Typically, each read-only routing list would contain every read-only routing URL, with the URL of the local replica at the end of the list.

      참고

      읽기 전용 연결 요청은 복제본에 부하를 분산할 수 있습니다.Read-intent connection requests can be load-balanced across replicas. 자세한 내용은 읽기 전용 복제본에 대한 부하 분산 구성을 참조하세요.For more information, see Configure load-balancing across read-only replicas.

      자세한 내용은 이 항목 뒷부분에 있는 가용성 그룹에 대한 읽기 전용 라우팅 구성(SQL Server)와 같은 시스템 데이터베이스, 사용자 데이터베이스를 비롯하여 보조 복제본을 호스트하는 서버 인스턴스의 읽기/쓰기 데이터베이스에는 데이터를 쓸 수 있습니다.For more information, see Configure Read-Only Routing for an Availability Group (SQL Server).

참고

가용성 그룹 수신기 및 읽기 전용 라우팅에 대한 자세한 내용은 가용성 그룹 수신기, 클라이언트 연결 및 응용 프로그램 장애 조치(failover)(SQL Server)와 같은 시스템 데이터베이스, 사용자 데이터베이스를 비롯하여 보조 복제본을 호스트하는 서버 인스턴스의 읽기/쓰기 데이터베이스에는 데이터를 쓸 수 있습니다.For information about availability group listeners and more information about read-only routing, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

제한 사항 Limitations and Restrictions

일부 작업은 다음과 같이 완전히 지원되지 않습니다.Some operations are not fully supported, as follows:

  • 읽기 가능한 복제본이 읽기에 대해 활성화되는 즉시 보조 데이터베이스에 대한 연결 수락을 시작할 수 있습니다.As soon as a readable replica is enabled for read, it can start accepting connections to its secondary databases. 하지만 주 데이터베이스에 활성 트랜잭션이 있는 경우 해당 보조 데이터베이스에서 행 버전을 완전히 사용할 수 없습니다.However, if any active transactions exist on a primary database, the row versions will not be fully available on the corresponding secondary database. 보조 복제본을 구성할 때 주 복제본에 있던 활성 트랜잭션은 커밋하거나 롤백해야 합니다.Any active transactions that existed on the primary replica when the secondary replica was configured must commit or roll back. 이 프로세스가 완료될 때까지 보조 데이터베이스의 트랜잭션 격리 수준 매핑은 완전하지 않으며 쿼리가 일시적으로 차단됩니다.Until this process completes, the transaction isolation level mapping on the secondary database is incomplete and queries are temporarily blocked.

    경고

    디스크 기반 테이블과 메모리 액세스에 최적화된 테이블 모두, 경우 장기 트랜잭션을 실행하면 유지되는 버전 관리 행 수에 영향을 줍니다.Running long transactions impacts the number of versioned rows kept, both for disk-based and memory-optimized tables.

  • 메모리 액세스에 최적화된 테이블이 있는 보조 데이터베이스에서는 메모리 액세스에 최적화된 테이블에 대해 행 버전이 항상 생성되더라도 보조 복제본이 활성화될 때 주 복제본에 있던 모든 활성 트랜잭션이 완료될 때까지 쿼리가 차단됩니다.On a secondary database with memory-optimized tables, even though row versions are always generated for memory-optimized tables, queries are blocked until all active transactions that existed in the primary replica when the secondary replica was enabled for read complete. 그러면 디스크 기반 테이블과 메모리 액세스에 최적화된 테이블을 보고 작업과 읽기 전용 쿼리에 모두 동시에 사용할 수 있습니다.This ensures that both disk-based and memory-optimized tables are available to the reporting workload and read-only queries at the same time.

  • 읽기 가능한 보조 복제본에 속하는 보조 데이터베이스에서는 변경 내용 추적 및 변경 데이터 캡처가 지원되지 않습니다.Change tracking and change data capture are not supported on secondary databases that belong to a readable secondary replica:

    • 변경 내용 추적은 보조 데이터베이스에서 명시적으로 해제되고Change tracking is explicitly disabled on secondary databases.

    • 변경 데이터 캡처는 보조 복제본 데이터베이스에서만 사용할 수 없습니다.Change Data Capture cannot be enabled only on a secondary replica database. 주 복제본 데이터베이스에서는 변경 데이터 캡처를 사용할 수 있고 보조 복제본 데이터베이스의 함수를 사용하여 CDC 테이블에서 변경 내용을 읽을 수 있습니다.Change Data Capture can be enabled on the primary replica database and the changes can be read from the CDC tables using the functions on the secondary replica database.

  • 읽기 작업은 스냅숏 격리 트랜잭션 수준으로 매핑되므로 주 복제본에서 삭제할 레코드의 삭제 작업이 하나 이상의 보조 복제본의 트랜잭션에 의해 차단될 수 있습니다.Because read operations are mapped to snapshot isolation transaction level, the cleanup of ghost records on the primary replica can be blocked by transactions on one or more secondary replicas. 삭제할 레코드 정리 태스크는 주 복제본에 있는 디스크 기반 테이블에 대한 삭제할 레코드가 보조 복제본에 더 이상 필요하지 않을 때 해당 레코드를 자동으로 정리합니다.The ghost record cleanup task will automatically clean up the ghost records for disk-based tables on the primary replica when they are no longer needed by any secondary replica. 이러한 동작은 주 복제본에서 트랜잭션을 실행할 때 수행되는 동작과 유사합니다.This is similar to what is done when you run transaction(s) on the primary replica. 극단적인 경우에는 보조 데이터베이스에서 삭제할 레코드 정리를 차단하는 장기 실행 읽기 쿼리를 중지해야 할 수 있습니다.In the extreme case on the secondary database, you will need to kill a long running read-query that is blocking the ghost cleanup. 삭제할 레코드 정리는 보조 복제본의 연결이 끊어지거나 보조 데이터베이스에서 데이터 이동이 일시 중지되는 경우 차단될 수 있습니다.Note, the ghost clean can be blocked if the secondary replica gets disconnected or when data movement is suspended on the secondary database. 이 상태에서는 로그 잘림이 방지되므로 이 상태가 지속될 경우 가용성 그룹에서 이 보조 데이터베이스를 제거하는 것이 좋습니다.This state also prevents log truncation, so if this state persists, we recommend that you remove this secondary database from the availability group. 행 버전이 메모리 내에 유지되고 주 복제본의 행 버전과 독립적이기 때문에 메모리 액세스에 최적화된 테이블에는 삭제할 레코드 정리 문제가 없습니다.There is no ghost record cleanup issue with memory-optimized tables because the row versions are kept in memory and are independent of the row versions on the primary replica.

  • 주 복제본에서 디스크 기반 테이블이 포함된 파일에 대해 DBCC SHRINKFILE 작업을 수행할 경우 해당 파일에 삭제할 레코드가 포함되어 있고 이 레코드가 보조 복제본에서 여전히 필요하면 작업이 실패할 수 있습니다.The DBCC SHRINKFILE operation on files containing disk-based tables might fail on the primary replica if the file contains ghost records that are still needed on a secondary replica.

  • SQL Server 2014SQL Server 2014부터 사용자 동작 또는 실패로 인해 주 복제본이 오프라인인 경우에도 읽기 가능한 보조 복제본은 온라인 상태를 유지할 수 있습니다.Beginning in SQL Server 2014SQL Server 2014, readable secondary replicas can remain online even when the primary replica is offline due to user action or a failure. 하지만 이 상황에서는 가용성 그룹 수신기도 오프라인 상태가 되므로 읽기 전용 라우팅이 작동하지 않습니다.However, read-only routing does not work in this situation because the availability group listener is offline as well. 클라이언트는 읽기 전용 작업을 위해 읽기 전용 보조 복제본에 직접 연결해야 합니다.Clients must connect directly to the read-only secondary replicas for read-only workloads.

참고

읽기 가능한 보조 복제본을 호스트하는 서버 인스턴스에서 sys.dm_db_index_physical_stats 동적 관리 뷰를 쿼리할 경우 REDO 차단 문제가 발생할 수 있습니다.If you query the sys.dm_db_index_physical_stats dynamic management view on a server instance that is hosting a readable secondary replica, you might encounter a REDO blocking issue. 이는 이 동적 관리 뷰가 지정된 사용자 테이블 또는 뷰에 대한 IS 잠금을 획득하여 REDO 스레드에서의 해당 사용자 테이블 또는 뷰에 대한 X 잠금 요청이 차단되기 때문입니다.This is because this dynamic management view acquires an IS lock on the specified user table or view that can block requests by a REDO thread for an X lock on that user table or view.

성능 고려 사항 Performance Considerations

이 섹션에서는 읽기 가능한 보조 데이터베이스에 대한 몇 가지 성능 고려 사항에 설명합니다.This section discusses several performance considerations for readable secondary databases

섹션 내용In This Section:

데이터 대기 시간 Data Latency

읽기 전용 작업에 약간의 데이터 대기 시간을 허용할 수 있는 경우 보조 복제본에 대한 읽기 전용 액세스를 구현하는 것이 좋습니다.Implementing read-only access to secondary replicas is useful if your read-only workloads can tolerate some data latency. 데이터 대기 시간이 허용 가능하지 않은 경우에는 주 복제본에 대해 읽기 전용 작업을 실행하는 것이 좋습니다.In situations where data latency is unacceptable, consider running read-only workloads against the primary replica.

주 복제본은 주 데이터베이스의 변경 내용에 대한 로그 레코드를 보조 복제본으로 보냅니다.The primary replica sends log records of changes on primary database to the secondary replicas. 각 보조 데이터베이스에서 전용 다시 실행 스레드가 이 로그 레코드를 적용합니다.On each secondary database, a dedicated redo thread applies the log records. 읽기 액세스 보조 데이터베이스에서는 변경 내용이 포함된 로그 레코드가 보조 데이터베이스에 적용되고 트랜잭션이 주 데이터베이스에서 커밋될 때까지는 쿼리 결과에 지정된 데이터 변경 내용이 나타나지 않습니다.On a read-access secondary database, a given data change does not appear in query results until the log record that contains the change has been applied to the secondary database and the transaction has been committed on primary database.

이로 인해 주 복제본과 보조 복제본 사이에는 대개 몇 초 내외의 대기 시간이 있습니다.This means that there is some latency, usually only a matter of seconds, between the primary and secondary replicas. 하지만 네트워크 문제로 인해 처리량이 줄어드는 경우와 같은 특수한 경우에는 대기 시간이 중요할 수 있습니다.In unusual cases, however, for example if network issues reduce throughput, latency can become significant. I/O 병목이 발생하고 데이터 이동이 일시 중지되면 대기 시간이 증가합니다.Latency increases when I/O bottlenecks occur and when data movement is suspended. 일시 중지된 데이터 이동을 모니터링하려면 Always On 대시보드 또는 sys.dm_hadr_database_replica_states 동적 관리 뷰를 사용하면 됩니다.To monitor suspended data movement, you can use the Always On Dashboard or the sys.dm_hadr_database_replica_states dynamic management view.

메모리 액세스에 최적화된 테이블이 포함된 데이터베이스의 데이터 대기 시간 Data Latency on databases with memory-optimized tables

SQL Server 2014SQL Server 2014에서는 활성 보조 데이터베이스의 데이터 대기 시간과 관련된 특별한 고려 사항이 있었습니다( SQL Server 2014SQL Server 2014 활성 보조: 읽기 가능한 보조 복제본 참조).In SQL Server 2014SQL Server 2014 there were special considerations around data latency on active secondaries - see SQL Server 2014SQL Server 2014 Active Secondaries: Readable Secondary Replicas. SQL Server 2016SQL Server 2016 시작에는 메모리 액세스에 최적화된 테이블의 데이터 대기 시간과 관련된 특별 고려 사항이 없습니다.Starting SQL Server 2016SQL Server 2016 there are no special considerations around data latency for memory-optimized tables. 메모리 액세스에 최적화된 테이블의 예상 데이터 대기 시간은 디스크 기반 테이블의 대기 시간과 비슷합니다.The expected data latency for memory-optimized tables is comparable to the latency for disk-based tables.

읽기 전용 작업의 영향 Read-Only Workload Impact

읽기 전용 액세스를 사용하도록 보조 복제본을 구성하면 특히 디스크 기반 테이블의 읽기 전용 작업이 I/O를 매우 많이 사용하는 경우 보조 데이터베이스의 읽기 전용 작업은 다시 실행 스레드의 CPU 및 I/O(디스크 기반 테이블의 경우)와 같은 시스템 리소스를 소비합니다.When you configure a secondary replica for read-only access, your read-only workloads on the secondary databases consume system resources, such as CPU and I/O (for disk-based tables) from redo threads, especially if the read-only workloads on disk-based tables are highly I/O-intensive. 모든 행이 메모리 내에 상주하기 때문에 메모리 액세스에 최적화된 테이블에 액세스할 때 IO의 영향이 없습니다.There is no IO impact when accessing memory-optimized tables because all the rows reside in memory.

또한 보조 복제본에 대한 읽기 전용 작업은 로그 레코드를 통해 적용되는 DDL(데이터 정의 언어) 변경을 차단할 수도 있습니다.Also, read-only workloads on the secondary replicas can block data definition language (DDL) changes that are applied through log records.

  • 행 버전 관리로 인해 읽기 작업에서는 공유 잠금을 사용하지는 않지만, DDL 변경을 적용하는 다시 실행 작업을 차단할 수 있는 스키마 안정성(Sch-S) 잠금을 사용합니다.Even though the read operations do not take shared locks because of row versioning, these operations take schema stability (Sch-S) locks, which can block redo operations that are applying DDL changes. DDL 작업에는 ALTER/DROP 테이블과 뷰가 포함되지만 저장 프로시저의 DROP 또는 ALTER는 포함되지 않습니다.DDL operations include ALTER/DROP tables and Views but not DROP or ALTER of stored procedures. 따라서 예를 들어 주 에서 디스크 기반 또는 메모리 액세스에 최적화된 테이블을 삭제할 경우,So for example, if you drop a table disk-based or memory-optimized, on primary. REDO 스레드가 테이블을 삭제하기 위한 로그 레코드를 처리할 때는 테이블에서 SCH_M 잠금을 획득해야 하며 테이블에 액세스하는 실행 중인 쿼리를 통해 차단될 수 있습니다.When REDO thread processes the log record to drop the table, it must acquire a SCH_M lock on the table and can get blocked by a running query accessing table. 테이블의 삭제가 사용자 세션의 일부로 수행되고 RODO 스레드가 아닌 경우를 제외하고 이 동작은 주 복제본에서도 동일합니다.This is the same behavior on primary replica except that the drop of the table is done as part of a user session and not REDO thread.

  • 추가로 차단하는 메모리 액세스에 최적화된 테이블이 있습니다.There is additional blocking Memory-Optimized Tables. 보조 복제본에 네이티브 저장 프로시저의 동시 실행이 있는 경우 네이티브 저장 프로시저를 삭제하면 REDO 스레드가 차단될 수 있습니다.A drop of native stored procedure can cause REDO thread to block if there is a concurrent execution of the native stored procedure on the secondary replica. 저장 프로시저의 삭제가 사용자 세션의 일부로 수행되고 RODO 스레드가 아닌 경우를 제외하고 이 동작은 주 복제본에서도 동일합니다.This is the same behavior on the primary replica except that the drop of the stored procedure is done as part of a user session and not REDO thread.

    쿼리 작성에 대한 최선의 방법을 알고 보조 데이터베이스에서 이러한 최선의 방법을 따라야 합니다.Be aware of best practices around building queries, and exercise those best practices in the secondary databases. 예를 들어 데이터 집계와 같은 장기 실행 쿼리는 작업량이 적은 시간에 예약합니다.For example, schedule long-running queries such as aggregations of data during times of low activity.

참고

다시 실행 스레드가 보조 복제본에 대한 쿼리에 의해 차단되면 sqlserver.lock_redo_blocked XEvent가 발생합니다.If a redo thread is blocked by queries on a secondary replica, the sqlserver.lock_redo_blocked XEvent is raised.

인덱싱 Indexing

읽기 가능한 보조 복제본에서 읽기 전용 작업을 최적화하기 위해 보조 데이터베이스의 테이블에 인덱스를 만들 수 있습니다.To optimize read-only workloads on the readable secondary replicas, you may want to create indexes on the tables in the secondary databases. 보조 데이터베이스의 스키마나 데이터는 변경할 수 없으므로 주 데이터베이스에 인덱스를 만들고 다시 실행 프로세스를 통해 변경 내용이 보조 데이터베이스에 전송될 수 있도록 합니다.Because you cannot make schema or data changes on the secondary databases, create indexes in the primary databases and allow the changes to transfer to the secondary database through the redo process.

보조 복제본의 인덱스 사용 동작을 모니터링하려면 sys.dm_db_index_usage_stats동적 관리 뷰의 user_seeks, user_scansuser_lookups 열을 쿼리합니다.To monitor index usage activity on a secondary replica, query the user_seeks, user_scans, and user_lookups columns of the sys.dm_db_index_usage_stats dynamic management view.

읽기 전용 액세스 데이터베이스에 대한 통계 Statistics for Read-Only Access Databases

테이블 및 인덱싱된 뷰의 열에 대한 통계는 쿼리 계획을 최적화하는 데 사용됩니다.Statistics on columns of tables and indexed views are used to optimize query plans. 가용성 그룹의 경우 주 데이터베이스에 만들어져 유지 관리되는 통계는 트랜잭션 로그 레코드가 적용되는 도중 보조 데이터베이스에 자동 보존됩니다.For availability groups, statistics that are created and maintained on the primary databases are automatically persisted on the secondary databases as part of applying the transaction log records. 그러나 보조 데이터베이스에 대한 읽기 전용 작업에는 주 데이터베이스에 만들어지는 통계와 다른 통계가 필요할 수 있습니다.However, the read-only workload on the secondary databases may need different statistics than those that are created on the primary databases. 하지만 보조 데이터베이스는 읽기 전용 액세스로 제한되므로 보조 데이터베이스에는 통계를 만들 수 없습니다.However, because secondary databases are restricted to read-only access, statistics cannot be created on the secondary databases.

이 문제를 해결하기 위해 보조 복제본은 tempdb에 보조 데이터베이스에 대한 임시 통계를 만들어 유지 관리합니다.To address this problem, the secondary replica creates and maintains temporary statistics for secondary databases in tempdb. 주 데이터베이스에 보존되는 영구적 통계와 구별하기 위해 임시 통계의 이름에는 _readonly_database_statistic라는 접미사가 추가됩니다.The suffix _readonly_database_statistic is appended to the name of temporary statistics to differentiate them from the permanent statistics that are persisted from the primary database.

SQL ServerSQL Server 에서만 임시 통계를 만들고 업데이트할 수 있습니다.Only SQL ServerSQL Server can create and update temporary statistics. 하지만 영구적 통계에 사용하는 것과 동일한 도구를 사용하여 임시 통계를 삭제하고 해당 속성을 모니터링할 수 있습니다.However, you can delete temporary statistics and monitor their properties using the same tools that you use for permanent statistics:

  • DROP STATISTICS Transact-SQLTransact-SQL 문을 사용하여 임시 통계를 삭제합니다.Delete temporary statistics using the DROP STATISTICS Transact-SQLTransact-SQL statement.

  • sys.statssys.stats_columns 카탈로그 뷰를 사용하여 통계를 모니터링합니다.Monitor statistics using the sys.stats and sys.stats_columns catalog views. sys_stats 에는 영구적 통계와 임시 통계를 나타내는 is_temporary열이 포함되어 있습니다.sys_stats includes a column, is_temporary, to indicate which statistics are permanent and which are temporary.

    주 복제본이나 보조 복제본에는 메모리 액세스에 최적화된 테이블의 자동 통계 업데이트에 대한 지원이 없습니다.There is no support for auto-statistics update for memory-optimized tables on the primary or secondary replica. 보조 복제본에서 쿼리 성능과 계획을 모니터링하고 필요한 경우 주 복제본에서 통계를 수동으로 업데이트해야 합니다.You must monitor query performance and plans on the secondary replica and manually update the statistics on the primary replica when needed. 하지만 주 복제본 및 보조 복제본 모두에서 누락 통계는 자동으로 생성됩니다.However, the missing statistics are automatically created both on primary and secondary replica.

    SQL Server 통계에 대한 자세한 내용은 통계를 참조하세요.For more information about SQL Server statistics, see Statistics.

    섹션 내용In This Section:

  • 보조 데이터베이스의 유효하지 않은 영구적 통계Stale Permanent Statistics on Secondary Databases

  • 제한 사항Limitations and Restrictions

보조 데이터베이스의 유효하지 않은 영구적 통계 Stale Permanent Statistics on Secondary Databases

SQL ServerSQL Server 에서는 보조 데이터베이스에 대한 영구적 통계가 유효하지 않은 경우 이를 감지합니다. detects when permanent statistics on a secondary database are stale. 그러나 주 데이터베이스의 변경을 통하지 않고는 영구적 통계를 변경할 수 없습니다.But changes cannot be made to the permanent statistics except through changes on the primary database. 쿼리 최적화를 위해 SQL ServerSQL Server 에서는 보조 데이터베이스에 디스크 기반 테이블에 대한 임시 통계를 만들고 이 통계를 유효하지 않은 영구적 통계 대신 사용합니다.For query optimization, SQL ServerSQL Server creates temporary statistics for disk-based tables on the secondary database and uses these statistics instead of the stale permanent statistics.

주 데이터베이스에서 영구적 통계가 업데이트되면 이 통계는 자동으로 보조 데이터베이스에 저장됩니다.When the permanent statistics are updated on the primary database, they are automatically persisted to the secondary database. 그런 다음 SQL ServerSQL Server 는 임시 통계보다 최신 상태인 업데이트된 영구적 통계를 사용합니다.Then SQL ServerSQL Server uses the updated permanent statistics, which are more current than the temporary statistics.

가용성 그룹에서 장애 조치(failover)가 수행되면 모든 보조 복제본에서 임시 통계가 삭제 됩니다.If the availability group fails over, temporary statistics are deleted on all of the secondary replicas.

제한 사항 Limitations and Restrictions

  • 임시 통계는 tempdb에 저장되므로 SQL ServerSQL Server 서비스를 다시 시작하면 모든 임시 통계가 사라집니다.Because temporary statistics are stored in tempdb, a restart of the SQL ServerSQL Server service causes all temporary statistics to disappear.

  • 접미사 _readonly_database_statistic은 SQL ServerSQL Server에서 생성하는 통계용으로 예약되어 있습니다.The suffix _readonly_database_statistic is reserved for statistics generated by SQL ServerSQL Server. 따라서 주 데이터베이스에서 통계를 만들 때 이 접미사를 사용할 수 없습니다.You cannot use this suffix when creating statistics on a primary database. 자세한 내용은 Statistics을(를) 참조하세요.For more information, see Statistics.

보조 복제본에서 메모리 액세스에 최적화된 테이블 액세스 Accessing memory-optimized tables on a Secondary Replica

보조 복제본의 메모리 액세스에 최적화된 테이블에 사용할 수 있는 트랜잭션 격리 수준은 주 복제본의 경우와 동일합니다.The transaction isolation levels that can be used with memory-optimized tables on a secondary replica are the same as on the primary replica. 세션 수준 격리 수준을 READ COMMITTED로 설정하고 데이터베이스 수준 옵션 MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT을 ON으로 설정하는 것이 좋습니다.The recommendation is to set the session-level isolation level to READ COMMITTED and set the database-level option MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT to ON. 예를 들어For example:

ALTER DATABASE CURRENT SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT=ON  
GO  
SET TRANSACTION ISOLATION LEVEL READ COMMITTED  
GO  
SELECT SUM(UnitPrice*OrderQty)   
FROM Sales.SalesOrderDetail_inmem  
GO  

용량 계획 고려 사항 Capacity Planning Considerations

  • 디스크 기반 테이블의 경우 다음 두 가지 이유로 읽기 가능한 보조 복제본에는 tempdb 에 공간이 필요할 수 있습니다.In the case of disk-based tables, readable secondary replicas can require space in tempdb for two reasons:

    • 스냅숏 격리 수준은 행 버전을 tempdb로 복사합니다.Snapshot isolation level copies row versions into tempdb.

    • 보조 데이터베이스의 임시 통계는 tempdb에 생성되고 유지 관리됩니다.Temporary statistics for secondary databases are created and maintained in tempdb. 임시 통계로 인해 tempdb의 크기가 약간 증가할 수 있습니다.The temporary statistics can cause a slight increase in the size of tempdb. 자세한 내용은 이 섹션 뒷부분에 있는 읽기 전용 액세스 데이터베이스에 대한 통계를 참조하세요.For more information, see Statistics for Read-Only Access Databases, later in this section.

  • 디스크 기반 테이블의 경우 하나 이상의 보조 복제본에 대해 읽기 액세스를 구성하면 주 데이터베이스에서는 삭제, 수정 또는 삽입된 데이터 행에 14바이트의 오버헤드를 추가하여 보조 데이터베이스의 행 버전에 대한 포인터를 저장합니다.When you configure read-access for one or more secondary replicas, the primary databases add 14 bytes of overhead on deleted, modified, or inserted data rows to store pointers to row versions on the secondary databases for disk-based tables. 이 14바이트 오버헤드는 보조 데이터베이스에 전달됩니다.This 14-byte overhead is carried over to the secondary databases. 14바이트의 오버헤드가 데이터 행에 추가되므로 페이지 분할이 발생할 수 있습니다.As the 14-byte overhead is added to data rows, page splits might occur.

    행 버전 데이터는 주 데이터베이스에 의해 생성되지 않습니다.The row version data is not generated by the primary databases. 대신 보조 데이터베이스는 행 버전을 생성합니다.Instead, the secondary databases generate the row versions. 하지만 행 버전 관리는 주 데이터베이스와 보조 데이터베이스 모두의 데이터 저장소를 늘립니다.However, row versioning increases data storage in both the primary and secondary databases.

    행 버전 데이터 추가는 주 데이터베이스의 스냅숏 격리 또는 RCSI(읽기 커밋된 스냅숏 격리) 수준에 따라 달라집니다.The addition of the row version data depends on the snapshot isolation or read-committed snapshot isolation (RCSI) level setting on the primary database. 다음 표에서는 디스크 기반 테이블에서 여러 설정에 따른 읽기 가능한 보조 데이터베이스의 버전 관리 동작에 대해 설명합니다.The table below describes the behavior of versioning on a readable secondary database under different settings for disk based tables.

    읽기 가능한 보조 복제본인지 여부Readable secondary replica? 스냅숏 격리 또는 RCSI 수준이 설정되었는지 여부Snapshot isolation or RCSI level enabled? 주 데이터베이스Primary Database 보조 데이터베이스Secondary Database
    아니요No 아니요No 행 버전이 없거나 14바이트 오버헤드임No row versions or 14-byte overhead 행 버전이 없거나 14바이트 오버헤드임No row versions or 14-byte overhead
    아니요No Yes 행 버전이 있고 14바이트 오버헤드임Row versions and 14-byte overhead 행 버전이 없지만 14바이트 오버헤드임No row versions, but 14-byte overhead
    Yes 아니요No 행 버전이 없지만 14바이트 오버헤드임No row versions, but 14-byte overhead 행 버전이 있고 14바이트 오버헤드임Row versions and 14-byte overhead
    Yes Yes 행 버전이 있고 14바이트 오버헤드임Row versions and 14-byte overhead 행 버전이 있고 14바이트 오버헤드임Row versions and 14-byte overhead

참고 항목See Also

Always On 가용성 그룹 개요(SQL Server) Overview of Always On Availability Groups (SQL Server)
가용성 복제본에 대한 클라이언트 연결 액세스 정보(SQL Server) About Client Connection Access to Availability Replicas (SQL Server)
가용성 그룹 수신기, 클라이언트 연결 및 응용 프로그램 장애 조치(failover)(SQL Server) Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server)
통계Statistics