이 문서에서는 SQL Server 인스턴스에서 데이터베이스를 미러링하기 위한 자동 다시 설정에 대해 설명합니다.
특정 상황에서는 Microsoft Fabric과의 미러링이 지연되어 트랜잭션 로그 파일 사용량이 증가할 수 있습니다. 이 증가는 커밋된 변경 사항이 미러 데이터베이스에 복제된 후에야 트랜잭션 로그를 잘라낼 수 있기 때문에 발생합니다. 트랜잭션 로그 크기가 정의된 최대 한계에 도달하면 데이터베이스에 대한 쓰기가 실패합니다. 중요한 OLTP 트랜잭션에 대한 쓰기 오류로부터 운영 데이터베이스를 보호하기 위해 트랜잭션 로그를 잘라내고 데이터베이스 미러링을 Fabric으로 다시 초기화할 수 있는 자동 실행 메커니즘을 설정할 수 있습니다.
재시드는 미러링 데이터베이스에서 Fabric으로 가는 트랜잭션 흐름을 중단하고 현재 상태에서 미러링을 재초기화합니다. 이 과정은 미러링용으로 구성된 테이블의 새로운 초기 스냅샷을 생성하고, 그 스냅샷을 Fabric에 복제하는 것을 포함합니다. 스냅샷 후에는 증분 변경 내용이 복제됩니다.
재시드 중에는 Fabric 내 미러된 데이터베이스 항목이 사용 가능하지만, 재시드가 완료될 때까지 점진적인 변경은 받지 않습니다.
reseed_state의 sys.sp_help_change_feed_settings 열은 재시드 상태를 나타냅니다.
SQL Server 2025에서는 자동 재시드 기능이 기본적으로 비활성화되어 있습니다. 이를 활성화하려면 자동 재시드 활성화를 참조하세요. Azure SQL Database와 Azure SQL Managed Instance에서는 이 기능이 활성화되어 있으며, 관리하거나 비활성화할 수 없습니다.
패브릭 미러링에서 원본 SQL 데이터베이스 트랜잭션 로그가 모니터링됩니다. 자동 재시드는 다음 세 가지 조건이 성립할 때만 작동합니다:
- 트랜잭션 로그가
@autoreseedthreshold%를 초과하여 찼습니다. 예를 들어,70. SQL Server에서는 기능을 활성화할 때 sys.sp_change_feed_configure_parameters를 사용해 이 값을 설정하세요. - 로그 재사용 이유는 .입니다
REPLICATION. -
REPLICATION로그 재사용 대기는 트랜잭션 복제 또는 CDC와 같은 다른 기능 때문에 발생할 수 있으므로, 자동 재시드는sys.databases.is_data_lake_replication_enabled= 1인 경우에만 발생합니다. 이 값은 패브릭 미러링에 의해 구성됩니다.
Diagnose
Fabric 미러링이 미러링된 데이터베이스의 로그 절단을 방지하는지 확인하려면 log_reuse_wait_desc 시스템 카탈로그 뷰에서 sys.databases 열을 확인하여 그 이유가 REPLICATION인지 확인하세요. 로그 재사용 대기 유형에 대한 자세한 내용은 트랜잭션 로그 잘림을 지연시키는 요인을 참조하세요. 다음은 그 예입니다.
SELECT [name], log_reuse_wait_desc
FROM sys.databases
WHERE is_data_lake_replication_enabled = 1;
쿼리에 REPLICATION 로그 재사용 대기 유형이 표시되면, Fabric 미러링으로 인해 트랜잭션 로그에서 커밋된 트랜잭션이 비워지지 않아 로그가 계속 차게 됩니다.
다음 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 참조하세요.
소스 데이터베이스에서는 재시드 과정이 미러링으로 인해 잡혀 있는 트랜잭션 로그 공간을 해제해야 합니다. 지연 사유가 여전히 REPLICATION 미러링 때문인 경우, 로그 공간이 강제로 해제되도록 소스 SQL Server 데이터베이스에서 수동 CHECKPOINT 실행하세요. 자세한 내용은 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 데이터베이스에 있는 시스템 저장 프로시저
reseed_state의sys.sp_help_change_feed_settings열은 현재 재시드 상태를 나타냅니다.-
0= 보통입니다. -
1= 데이터베이스가 Fabric으로 다시 초기화하는 프로세스를 시작했습니다. 전환 상태입니다.-
2= 데이터베이스가 Fabric으로 재초기화되고 복제가 재시작되기를 기다리고 있습니다. 전환 상태입니다. 복제가 성립되면 재시드 상태는 로 변경0됩니다.
-
자세한 내용은 sys.sp_help_change_feed_settings 참조하세요.
-
데이터베이스에서 미러링이 사용 설정된 모든 테이블은
7의state열에sys.sp_help_change_feed_table값을 가집니다.자세한 내용은 sys.sp_help_change_feed_table 참조하세요.