이 문서에서는 SQL Server 인스턴스에서 데이터베이스를 미러링하기 위한 자동 다시 설정에 대해 설명합니다.
중요합니다
이 기능은 프리뷰 상태입니다.
패브릭에 대한 미러링이 지연되면 트랜잭션 로그 파일 사용량이 증가할 수 있는 특정 상황이 있습니다. 커밋된 변경 내용이 미러된 데이터베이스에 복제될 때까지 트랜잭션 로그를 잘라낼 수 없기 때문입니다. 트랜잭션 로그 크기가 정의된 최대 한도에 도달하면 데이터베이스에 대한 쓰기가 실패합니다. 중요한 OLTP 트랜잭션에 대한 쓰기 오류로부터 운영 데이터베이스를 보호하기 위해 트랜잭션 로그를 잘라내고 데이터베이스 미러링을 Fabric으로 다시 초기화할 수 있는 자동 실행 메커니즘을 설정할 수 있습니다.
다시 시딩하면 미러된 데이터베이스에서 Microsoft Fabric으로의 트랜잭션 흐름이 중지되고 현재 상태에서 미러링이 다시 초기화됩니다. 여기에는 미러링용으로 구성된 테이블의 새 초기 스냅샷을 생성하고 이를 Microsoft Fabric에 복제하는 작업이 포함됩니다. 스냅샷 후에는 증분 변경 내용이 복제됩니다.
다시 시딩하는 동안 Microsoft Fabric의 미러된 데이터베이스 항목을 사용할 수 있지만 다시 시작이 완료될 때까지 증분 변경 내용을 수신하지 않습니다. 열은 reseed_statesys.sp_help_change_feed_settings 다시 시드 상태를 나타냅니다.
자동 실행 기능은 SQL Server 2025(미리 보기)에서 기본적으로 사용하지 않도록 설정되어 있으며 자동 표시 사용(Enable autoreseed)을 사용하도록 설정합니다. 자동 복구 기능은 사용하도록 설정되어 있으며 Azure SQL Database 및 Azure SQL Managed Instance에서 관리하거나 사용하지 않도록 설정할 수 없습니다.
패브릭 미러링에서 원본 SQL 데이터베이스 트랜잭션 로그가 모니터링됩니다. autoreseed는 다음 세 가지 조건이 true인 경우에만 트리거됩니다.
- 트랜잭션 로그가 꽉 찼습니다
@autoreseedthreshold(예:70.). SQL Server에서 sys.sp_change_feed_configure_parameters 사용하여 기능을 사용하도록 설정할 때 이 값을 구성합니다. - 로그 재사용 이유는 .입니다
REPLICATION. -
REPLICATION트랜잭션 복제 또는 CDC와 같은 다른 기능에 대해 로그 재사용 대기를 발생시킬 수 있으므로 자동 실행은 = 1일 때만sys.databases.is_data_lake_replication_enabled발생합니다. 이 값은 패브릭 미러링에 의해 구성됩니다.
Diagnose
패브릭 미러링이 미러된 데이터베이스에 대한 로그 잘림을 방지하는지 확인하려면 시스템 카탈로그 뷰의 log_reuse_wait_desc 열을 확인 sys.databases 하여 이유가 REPLICATION있는지 확인합니다. 로그 재사용 대기 유형에 대한 자세한 내용은 트랜잭션 로그 잘림을 지연시키는 요인을 참조하세요. 다음은 그 예입니다.
SELECT [name], log_reuse_wait_desc
FROM sys.databases
WHERE is_data_lake_replication_enabled = 1;
쿼리에 로그 재사용 대기 유형이 표시 REPLICATION 되면 패브릭 미러링으로 인해 트랜잭션 로그가 커밋된 트랜잭션을 비울 수 없으며 계속 채워질 수 있습니다.
다음 T-SQL 스크립트를 사용하여 총 로그 공간과 현재 로그 사용량 및 사용 가능한 공간을 확인합니다.
USE <Mirrored database name>
GO
--initialize variables
DECLARE @total_log_size bigint = 0;
DECLARE @used_log_size bigint = 0;
DECLARE @size int;
DECLARE @max_size int;
DECLARE @growth int;
--retrieve total log space based on number of log files and growth settings for the database
DECLARE sdf CURSOR
FOR
SELECT SIZE*1.0*8192/1024/1024 AS [size in MB],
max_size*1.0*8192/1024/1024 AS [max size in MB],
growth
FROM sys.database_files
WHERE TYPE = 1
OPEN sdf
FETCH NEXT FROM sdf INTO @size,
@max_size,
@growth
WHILE @@FETCH_STATUS = 0
BEGIN
SELECT @total_log_size = @total_log_size +
CASE @growth
WHEN 0 THEN @size
ELSE @max_size
END
FETCH NEXT FROM sdf INTO @size,
@max_size,
@growth
END
CLOSE sdf;
DEALLOCATE sdf;
--current log space usage
SELECT @used_log_size = used_log_space_in_bytes*1.0/1024/1024
FROM sys.dm_db_log_space_usage;
-- log space used in percent
SELECT @used_log_size AS [used log space in MB],
@total_log_size AS [total log space in MB],
@used_log_size/@total_log_size AS [used log space in percentage];
자동 저항 사용
이전 T-SQL 스크립트에서 반환된 로그 사용량이 꽉 찼을 때(예: 70개%초과) 시스템 저장 프로시저를 사용하여 sys.sp_change_feed_configure_parameters 미러된 데이터베이스를 자동으로 다시 시딩하도록 설정하는 것이 좋습니다. 예를 들어 자동 실행 동작을 사용하도록 설정하려면 다음을 수행합니다.
USE <Mirrored database name>
GO
EXECUTE sys.sp_change_feed_configure_parameters
@autoreseed = 1
, @autoreseedthreshold = 70;
자세한 내용은 sys.sp_change_feed_configure_parameters 참조하세요.
원본 데이터베이스에서 reseed는 미러링으로 유지되는 트랜잭션 로그 공간을 해제해야 합니다. 보류 이유가 여전히 CHECKPOINT 미러링으로 인해 발생하는 경우 원본 SQL Server 데이터베이스에 대한 설명서를 REPLICATION 실행하여 로그 공간을 강제로 해제합니다. 자세한 내용은 CHECKPOINT(Transact-SQL)를 참조하세요.
수동 다시시드
다음 저장 프로시저를 사용하여 특정 데이터베이스에 대한 수동 다시 시딩을 테스트하여 자동 다시 크기 조정 기능을 켜기 전에 영향을 파악하는 것이 가장 좋습니다.
USE <Mirrored database name>
GO
EXECUTE sp_change_feed_reseed_db_init @is_init_needed = 1;
자세한 내용은 sys.sp_change_feed_reseed_db_init 참조하세요.
다시 동기화가 트리거되었는지 확인합니다.
원본 SQL Server 데이터베이스의 시스템 저장 프로시저 reseed_state 열은 sys.sp_help_change_feed_settings 현재 다시 시드된 상태를 나타냅니다.
-
0= 보통입니다. -
1= 데이터베이스가 Fabric으로 다시 초기화하는 프로세스를 시작했습니다. 전환 상태입니다. -
2= 데이터베이스를 Fabric으로 다시 초기화하고 복제가 다시 시작될 때까지 기다리고 있습니다. 전환 상태입니다. 복제가 설정되면 다시 설정된 상태가 .로0이동합니다.
자세한 내용은 sys.sp_help_change_feed_settings 참조하세요.