Azure SQL Managed Instance의 Fabric 미러링된 데이터베이스에 대한 자동 시드 리셋

이 문서에서는 Azure SQL Managed Instance에서 데이터베이스를 미러링하기 위한 자동 다시 설정에 대해 설명합니다.

패브릭에 대한 미러링이 지연되는 경우 특정 조건에서 트랜잭션 로그 파일 사용량이 증가할 수 있습니다. 커밋된 변경 내용이 미러된 데이터베이스에 복제될 때까지 트랜잭션 로그를 잘라낼 수 없습니다. 트랜잭션 로그 크기가 정의된 최대 한도에 도달하면 데이터베이스에 대한 쓰기가 실패합니다.

중요한 OLTP 트랜잭션에 대한 쓰기 오류로부터 운영 데이터베이스를 보호하기 위해 Azure SQL Database 및 Azure SQL Managed Instance의 미러링에서는 트랜잭션 로그를 잘라내고 데이터베이스 미러링을 Fabric으로 다시 초기화할 수 있는 자동 실행 기능을 사용합니다.

다시 시딩하면 미러된 데이터베이스에서 Microsoft Fabric으로의 트랜잭션 흐름이 중지되고 현재 상태에서 미러링이 다시 초기화됩니다. 다시 시드에는 미러링용으로 구성된 테이블의 새 초기 스냅샷을 생성하고 이를 Microsoft Fabric에 복제하는 작업이 포함됩니다. 스냅샷 후에는 증분 변경 내용이 복제됩니다.

Azure SQL Database 및 Azure SQL Managed Instance에서 reseed는 데이터베이스 수준 또는 테이블 수준에서 발생할 수 있습니다.

데이터베이스 수준 다시 설정: 미러링을 사용하도록 설정된 데이터베이스의 모든 테이블에 대해 지속적인 데이터 미러링이 중지되고, 트랜잭션 로그가 잘리고, 미러링에 사용하도록 설정된 모든 테이블의 초기 스냅샷을 다시 게시하여 데이터베이스에 대한 미러링이 다시 초기화됩니다. 그런 다음, 증분 변경이 지속적으로 복제를 계속합니다.
테이블 수준 다시 설정: 데이터의 지속적인 미러링이 다시 필요한 테이블에 대해서만 중지됩니다. 미러링이 영향을 받는 테이블에 대해 초기 스냅샷을 다시 게시하여 다시 초기화됩니다. 그런 다음, 증분 변경이 지속적으로 복제를 계속합니다.

데이터베이스 수준 자동 다시 설정의 원인

데이터베이스 수준에서 다시 설정하면 트랜잭션 로그가 최대 크기로 증가하지 않도록 하여 데이터베이스 쓰기 가용성을 보호합니다. 최대 트랜잭션 로그 크기는 Azure SQL Database 또는 Azure SQL Managed Instance의 데이터베이스 서비스 수준 목표를 기반으로 합니다. 패브릭 미러링에 사용하도록 설정된 데이터베이스에 대한 트랜잭션 로그 사용량은 계속 증가하고 로그 잘림을 유지할 수 있습니다. 트랜잭션 로그 크기가 정의된 최대 한도에 도달하면 데이터베이스에 대한 쓰기가 실패합니다.

미러링으로 인한 로그 잘림 방지는 여러 가지 이유로 발생할 수 있습니다.
- 원본에서 미러된 데이터베이스로 데이터를 미러링하는 대기 시간으로 인해 트랜잭션 로그에서 복제 보류 중인 트랜잭션이 잘리지 않습니다.
- 복제가 대기 중인 장기 복제 트랜잭션은 트랜잭션 로그 공간을 차지하여 삭제할 수 없습니다.
- OneLake의 랜딩 존에 쓰는 영구 오류는 복제를 방지할 수 있습니다.
  - 이 시나리오는 권한이 부족하여 발생할 수 있습니다. 패브릭 미러링에서는 SAMI(시스템 할당 관리 ID) 또는 UAMI(사용자 할당 관리 ID)를 사용하여 One Lake의 랜딩 존에 씁니다. 올바르게 구성되지 않은 경우 트랜잭션 복제가 반복적으로 실패할 수 있습니다.
    
    비고
    
    UAMI(사용자 할당 관리 ID)에 대한 지원은 현재 미리 보기로 제공됩니다.
패브릭 용량이 일시 중지되고 다시 시작되면 미러된 데이터베이스 상태가 일시 중지된 상태로 유지됩니다. 따라서 원본에서 변경된 내용은 OneLake에 복제되지 않습니다. 미러링을 다시 시작하려면 패브릭 포털에서 미러된 데이터베이스로 이동하여 복제 다시 시작을 선택합니다. 미러링이 일시 중지된 위치에서 계속됩니다.

패브릭 용량이 오랫동안 일시 중지된 상태로 유지되는 경우 미러링이 중지 지점에서 다시 시작되지 않을 수 있으며 처음부터 데이터를 다시 설정합니다. 오랫동안 미러링을 일시 중지하면 원본 데이터베이스 트랜잭션 로그 사용량이 증가하고 로그 잘림이 유지될 수 있기 때문입니다. 미러링을 재개할 때, 사용된 트랜잭션 로그 파일 공간이 거의 꽉 차 있는 경우 유지된 로그 공간을 해제하여 데이터베이스의 재시작이 실행됩니다.

테이블 수준 자동 다시 설정의 원인

미러링을 사용하도록 설정된 원본 테이블에서 스키마 변경이 발생하면 Fabric의 미러된 테이블에 대한 스키마가 더 이상 원본과 일치하지 않습니다. 이 문제는 원본의 다음 ALTER TABLE DDL(데이터 정의 언어) T-SQL 문으로 인해 발생할 수 있습니다.

열 추가/삭제/변경/이름 바꾸기
테이블 자르기/이름 바꾸기
비클러스터형 기본 키 추가

Reseed는 영향을 받은 테이블에 대해서만 트리거됩니다.

진단

패브릭 미러링이 미러된 데이터베이스에 대한 로그 잘림을 방지하는지 확인하려면 시스템 카탈로그 뷰의 log_reuse_wait_desc 열을 확인 sys.databases 하여 이유가 REPLICATION있는지 확인합니다. 로그 재사용 대기 유형에 대한 자세한 내용은 트랜잭션 로그 잘림을 지연시키는 요인을 참조하세요. 다음은 그 예입니다.

SELECT [name], log_reuse_wait_desc 
FROM sys.databases 
WHERE is_data_lake_replication_enabled = 1;

쿼리에 로그 재사용 대기 유형이 표시 REPLICATION 되면 패브릭 미러링으로 인해 트랜잭션 로그가 커밋된 트랜잭션을 비울 수 없으며 계속 채워질 수 있습니다. Azure SQL Database의 로그 사용량에 대한 추가 문제 해결은 Azure SQL Database를 사용한 트랜잭션 로그 오류 문제를 참조하세요.

다음 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];

새로 시드하는 중

다시 시딩하는 동안 Microsoft Fabric의 미러된 데이터베이스 항목을 사용할 수 있지만 다시 시작이 완료될 때까지 증분 변경 내용을 수신하지 않습니다. 열은 reseed_statesys.sp_help_change_feed_settings 다시 시드 상태를 나타냅니다.

패브릭 미러링에서 원본 SQL 데이터베이스 트랜잭션 로그가 모니터링됩니다. autoreseed는 다음 세 가지 조건이 true인 경우에만 트리거됩니다.

트랜잭션 로그가 꽉 찼습니다 @autoreseedthreshold (예: 70.).
로그 재사용 이유는 .입니다 REPLICATION.
REPLICATION 트랜잭션 복제 또는 CDC와 같은 다른 기능에 대해 로그 재사용 대기를 발생시킬 수 있으므로 자동 실행은 = 1일 때만 sys.databases.is_data_lake_replication_enabled 발생합니다. 이 값은 패브릭 미러링에 의해 구성됩니다.

데이터베이스 수준에서 재시드가 트리거되었는지 확인합니다.

전체 데이터베이스가 다시 설정되는 경우, 다음 조건을 확인하십시오.

원본 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 참조하세요.

테이블 레벨 재시드가 트리거되었는지 확인합니다.

다시 시드할 테이블의 경우, 7에서 state 열이 sys.sp_help_change_feed_table 값을 갖는지 확인하십시오.

자세한 내용은 sys.sp_help_change_feed_table 참조하세요.

Azure SQL Managed Instance에서 패브릭 미러된 데이터베이스 문제 해결

피드백

이 페이지가 도움이 되었나요?

Last updated on 2025-12-03