Condividi tramite

Ottimizzare le prestazioni per i database con mirroring di SQL Server

Questo articolo include passaggi importanti per ottimizzare le prestazioni del database di origine e del database con mirroring di SQL Server in Microsoft Fabric.

Controllare le prestazioni della scansione

Quando il mirroring è abilitato nelle tabelle di un database, un processo di analisi acquisisce periodicamente le modifiche raccogliendo il log delle transazioni. Questo processo inizia al LSN della transazione impegnata più vecchia non replicata e scansiona le transazioni replicate N-1 successive, dove N rappresenta il numero di transazioni specificato tramite il @maxtrans parametro in sys.sp_change_feed_configure_parameters. Il valore del maxtrans parametro indica il numero massimo di transazioni da elaborare in ogni ciclo di analisi.

Nelle situazioni in cui la latenza di analisi è molto elevata, l'uso di un valore più elevato maxtrans può essere vantaggioso, mentre nei casi che coinvolgono transazioni con replica sparse o relativamente grandi, un'impostazione inferiore maxtrans potrebbe essere preferibile. La funzionalità di transazioni massime dinamiche semplifica questo processo determinando automaticamente il valore ottimale maxtrans durante ogni analisi in base ad altri fattori, ad esempio l'utilizzo del log, la latenza di analisi e il carico di lavoro. Quando l'impostazione del dynamicmaxtrans feed di modifiche è abilitata, Fabric regola in modo dinamico il parametro maxtrans, assicurando prestazioni ottimali per la scansione.

Verificare l'impostazione della funzionalità delle transazioni massime dinamiche con sys.sp_help_change_feed_settings o usare repl_logscan_dynamic_maxtrans l'evento esteso per monitorare i valori di esecuzione di ogni scansione.

Per abilitare la funzionalità transazioni massime dinamiche, impostare su @dynamicmaxtrans1. Per esempio:

USE <Mirrored database name>
GO
EXECUTE sys.sp_change_feed_configure_parameters
  @dynamicmaxtrans=1;

Per modificare i limiti massimi e inferiori per la funzionalità di transazioni massime dinamiche, usare @maxtrans e @dynamicmaxtranslowerbound rispettivamente. Per esempio:

USE <Mirrored database name>
GO
EXECUTE sys.sp_change_feed_configure_parameters
  @dynamicmaxtrans=1
, @dynamicmaxtranslowerbound=5
, @maxtrans=5000;

Considerazioni per l'impostazione delle transazioni massime dinamiche

La funzionalità transazioni massime dinamiche è abilitata per impostazione predefinita in SQL Server 2025. La funzionalità numero massimo di transazioni dinamiche è abilitata e non può essere gestita o disabilitata nel database SQL di Azure e in Istanza gestita di SQL di Azure.

Quando è abilitato maxtrans dinamico, il mirroring elabora fino a 10.000 transazioni (per impostazione predefinita) o il valore massimo di transazioni configurato durante la fase di analisi del log. Per evitare che questa fase venga eseguita troppo a lungo, viene applicato un timeout di tre minuti. Tutte le transazioni elaborate prima della scadenza del timeout vengono pubblicate nel database con mirroring e le transazioni rimanenti verranno acquisite durante l'analisi successiva.

I valori ottimali per la funzionalità delle transazioni massime dinamiche variano in base al carico di lavoro, alla latenza e ad altri fattori. Valutare la possibilità di attivare la funzionalità maxtrans dinamica quando la latenza è superiore a quella desiderata e transaction_count in ogni batch è maggiore dell'impostazione del limite inferiore (200, per impostazione predefinita). Questa operazione può essere monitorata usando la colonna latency in sys.dm_change_feed_log_scan_sessions o utilizzando l'evento esteso repl_logscan_dynamic_maxtrans per verificare se l'oggetto current_maxtrans raggiunge l'insieme impostato maxtrans. Se la latenza è ancora elevata, è consigliabile aumentare il maxtrans limite superiore usando sys.sp_help_change_feed_settings.

Usare l'evento repl_logscan_dynamic_maxtrans esteso per monitorare se si verificano spesso timeout. Il campo prev_phase2_scan_termination_reason avrà un valore LogScanTerminationReason_MaxScanDurationReached quando si verifica un timeout dall'analisi. Valutare la possibilità di abbassare maxtrans o disabilitare dynamic maxtrans usando sys.sp_help_change_feed_settings se si notano timeout frequenti.

Resource Governor per il mirroring di SQL Server

In SQL Server 2025 è possibile creare un pool di Resource Governor per gestire e limitare il carico di lavoro del mirroring di Fabric sul proprio SQL Server. È possibile usare Resource Governor per gestire il consumo delle risorse del motore di database e applicare criteri per i carichi di lavoro degli utenti. Resource Governor consente di riservare o limitare varie risorse del server, tra cui la quantità di CPU, memoria e I/O fisica che i carichi di lavoro di query utente possono usare. In questo modo, è possibile proteggere i carichi di lavoro aziendali principali dal carico esercitato dalla raccolta dati del feed delle modifiche di Fabric Mirroring. Per altre informazioni, vedere Resource Governor.

Per iniziare a configurare i gruppi di carico di lavoro in SQL Server 2025 per il mirroring dell'infrastruttura, usare lo script di esempio e le istruzioni seguenti.

  • È possibile scegliere qualsiasi nome per il RESOURCE POOL.
  • Questo script di esempio configura un limite per una percentuale specifica di utilizzo della CPU per consentire il mirroring del Fabric. Nell'esempio seguente viene 50 usato per il 50%. Questo valore è la larghezza di banda media media della CPU che tutte le richieste nel pool di risorse possono ricevere quando è presente una contesa di CPU. Usare un valore inferiore per limitare ulteriormente il mirroring di Fabric.
  • I WORKLOAD GROUP nomi devono corrispondere ai valori nello script di esempio. Ogni gruppo di carico di lavoro è destinato a una fase specifica del mirroring. Ogni gruppo di carico di lavoro può trovarsi nello stesso pool o in un pool diverso a seconda del modo in cui si pianificano i pool e i carichi di lavoro di Resource Governor.
  • Prima di configurare Resource Governor per la prima volta nell'istanza di SQL Server, esaminare attentamente la documentazione, gli esempi e le procedure consigliate di Resource Governor.
--Create resource pool for Fabric mirroring
CREATE RESOURCE POOL [ChangeFeedPool] WITH (MAX_CPU_PERCENT = 50);

--Create workload groups for Fabric mirroring. Do not modify.
CREATE WORKLOAD GROUP [x_ms_reserved_changefeed_snapshot_group] USING [ChangeFeedPool];
CREATE WORKLOAD GROUP [x_ms_reserved_changefeed_capture_group] USING [ChangeFeedPool];
CREATE WORKLOAD GROUP [x_ms_reserved_changefeed_publish_group] USING [ChangeFeedPool];
CREATE WORKLOAD GROUP [x_ms_reserved_changefeed_commit_group] USING [ChangeFeedPool];
CREATE WORKLOAD GROUP [x_ms_reserved_changefeed_notification_group] USING [ChangeFeedPool];

Per applicare le modifiche e abilitare Resource Governor, come di consueto:

ALTER RESOURCE GOVERNOR RECONFIGURE

Contenuti correlati

  • Last updated on