Analisi delle prestazioni di I/O (anteprima) - SQL Server in macchine virtuali di Azure

Si applica a: SQL Server su VM di Azure

Questo articolo illustra come analizzare le prestazioni di I/O per SQL Server in Azure Macchine virtuali (VM) per individuare i problemi derivanti dal superamento dei limiti di macchine virtuali e dischi dati.

Nota

Al momento l’analisi di I/O per SQL Server in macchine virtuali di Azure nel portale di Azure è in anteprima.

Panoramica

Nonostante vari strumenti consentano di risolvere i problemi di prestazioni di SQL Server, per farlo in modo efficace all’interno di una VM di Azure è importante comprendere cosa accade sia a livello di host che nella propria istanza di SQL Server in cui, spesso, la correlazione tra le metriche host e i carichi di lavoro di SQL Server può rappresentare un problema. Il SQL Server nelle VM di Azure permette di identificare con facilità i problemi di prestazione causati dalle operazioni di I/O al secondo (input/output al secondo) e dalla limitazione della velocità effettiva causata dal superamento dei limiti delle macchine virtuali e dei dischi dati.

Nel portale di Azure è possibile trovare le metriche delle prestazioni che illustrano il problema e i possibili passaggi per risolverlo. Inoltre, è possibile eseguire query con l'interfaccia della riga di comando di Azure.

Il riquadro Archiviazione della risorsa macchine virtuali SQL all’interno del portale di Azure consente di:

• Gestire la configurazione dell’archiviazione
• Identificare la limitazione delle richieste di I/O
• Valutare le procedure consigliate correlate all'I/O del sistema

Comprendere le metriche

La scheda Analisi I/O sfrutta le metriche di Azure per identificare la latenza del disco e la limitazione delle operazioni di I/O su VM o disco. Le metriche di Azure vengono campionate ogni 30 secondi e aggregate a un minuto.

Il sistema monitora la limitazione e la latenza del disco. È previsto che ci sia un certo grado di limitazione il quale, a meno che non sia presente anche una latenza nel disco, verrà ignorato. Se si rilevano più di 500 millisecondi di latenza del disco in un periodo consecutivo di 5 minuti, il sistema:

• Approfondisce le metriche delle prestazioni
• Identifica la risorsa limitata
• Fornisce possibili cause e illustra i passaggi per la risoluzione

La seguente tabella illustra le metriche di Azure usate per identificare problemi di limitazione delle richieste:

Metriche di Azure	Descrizione della metrica	Condizione problematica	Conclusioni sulla limitazione delle richieste di I/O
Latenza del disco (anteprima)	Tempo medio di completamento delle operazioni di I/O per il disco dati durante il periodo monitorato. I valori sono espressi in millisecondi.	> 500 millisecondi in un periodo consecutivo di 5 minuti	Esiste un problema di latenza per il sistema per analizzare ulteriormente la potenziale limitazione.
Percentuale di utilizzo operazioni di I/O al secondo della cache della macchina virtuale	Percentuale calcolata dal totale di operazioni di I/O al secondo completate rispetto al limite massimo di operazioni di I/O al secondo della macchina virtuale memorizzata nella cache.	>= 95% in un periodo consecutivo di 5 minuti	È presente una limitazione delle VM. L'applicazione in esecuzione nella macchina virtuale SQL sfrutta al massimo la capacità massima di IOPS memorizzata nella cache disponibile per la macchina virtuale. Le richieste di archiviazione dell'applicazione superano le operazioni di I/O al secondo memorizzate nella cache fornite dalla configurazione di archiviazione sottostante della macchina virtuale.
Percentuale di utilizzo larghezza di banda della cache della macchina virtuale	Percentuale calcolata ottenuta dividendo la velocità effettiva totale del disco completata per la velocità effettiva massima della macchina virtuale memorizzata nella cache.	>= 95% in un periodo consecutivo di 5 minuti	È presente una limitazione delle VM. L'applicazione in esecuzione nella macchina virtuale SQL usa la larghezza di banda massima disponibile per il trasferimento dei dati. Le richieste di trasferimento dei dati dell'applicazione superano le risorse della larghezza di banda memorizzate nella cache fornite dalla configurazione di archiviazione sottostante della macchina virtuale.
Percentuale di utilizzo operazioni di I/O al secondo non della cache della macchina virtuale	Percentuale calcolata dalle operazioni di I/O al secondo su una macchina virtuale completate rispetto al limite massimo di operazioni di I/O al secondo non memorizzate nella cache.	>= 95% in un periodo consecutivo di 5 minuti	È presente una limitazione delle VM. L'applicazione in esecuzione nella macchina virtuale SQL utilizza la capacità massima consentita di operazioni di I/O al secondo non memorizzata nella cache disponibile per la macchina virtuale. Le richieste di archiviazione dell'applicazione superano le risorse di operazioni di I/O al secondo non memorizzate fornite dalla configurazione di archiviazione sottostante della macchina virtuale.
Percentuale di utilizzo larghezza di banda non della cache della macchina virtuale	Percentuale calcolata dividendo la produttività totale del disco su una macchina virtuale completata per la produttività massima della macchina virtuale di cui è stato effettuato il provisioning.	>= 95% in un periodo consecutivo di 5 minuti	È presente una limitazione delle VM. L'applicazione in esecuzione nella macchina virtuale SQL usa la larghezza di banda massima consentita del disco non memorizzato nella cache per il trasferimento dei dati. Le richieste di trasferimento dei dati dell'applicazione superano le risorse di larghezza di banda non memorizzate nella cache fornite dalla configurazione di archiviazione sottostante della macchina virtuale.
Percentuale di utilizzo operazioni di I/O al secondo del disco dati	Percentuale calcolata dividendo il numero di operazioni di I/O al secondo per il disco dati per le operazioni di I/O al secondo del disco dati di cui è stato eseguito il provisioning.	>= 95% in un periodo consecutivo di 5 minuti	È presente una limitazione del disco dati. L'applicazione in esecuzione nella macchina virtuale SQL raggiunge il limite di operazioni di I/O al secondo per il disco dati di cui è stato effettuato il provisioning. Le richieste di archiviazione dell'applicazione superano le funzionalità di prestazioni della configurazione del disco scelta.
Percentuale di utilizzo della larghezza di banda del disco dati	Percentuale calcolata dividendo la produttività del disco dati completata per la produttività del disco dati per cui è stato effettuato il provisioning.	>= 95% in un periodo consecutivo di 5 minuti	È presente una limitazione del disco dati. L'applicazione in esecuzione nella macchina virtuale SQL raggiunge il limite di operazioni di I/O al secondo per il disco dati di cui è stato effettuato il provisioning. Le richieste di archiviazione dell'applicazione superano le funzionalità di prestazioni della configurazione del disco scelta.

Risultati dell'analisi di I/O

In base all'analisi delle metriche delle prestazioni nelle ultime 24 ore, l'analisi di I/O determina che:

• Non è presente alcuna limitazione
• È presente una limitazione a livello di macchina virtuale
• È presente una limitazione azione delle operazioni di I/O a livello di disco

Non è presente nessun problema di limitazione delle richieste di I/O

Se si verifica un problema di prestazioni ma il disco non presenta alcuna latenza, il problema di prestazioni non è dovuto a un problema di limitazione delle operazioni di I/O. È necessario analizzare altre aree. È possibile usare l'elenco di controllo Procedure consigliate per SQL Server nelle VM di Azure per assicurarsi che il sistema sia configurato in modo efficiente o trovare collegamenti utili per la risoluzione dei problemi relativi alle prestazioni di SQL Server. Se si abilita la funzionalità di valutazione delle procedure consigliate di SQL, è possibile visualizzare l'elenco completo delle raccomandazioni per la VM di SQL Server.

Problema di limitazione delle richieste di I/O a livello di VM

Le macchine virtuali Azure sono risorse di calcolo basate sul cloud disponibili in serie e dimensioni diverse per vari carichi di lavoro, ognuna con funzionalità e caratteristiche di prestazioni diverse. Per i carichi di lavoro di SQL Server, in genere, la serie consigliata per i carichi di lavoro di SQL Server sono quelle ottimizzate per la memoria, ad esempio la serie Ebdsv5, M e Mv2.

Le dimensioni della VM determinano il numero di vCPU, memoria e archiviazione disponibili per l'istanza di SQL Server. Rispetto all'archiviazione, è relativamente facile per i clienti ridimensionare le macchine virtuali e ridimensionare la VM in base alle esigenze delle risorse dell'applicazione. Poiché è possibile limitare le operazioni di I/O al secondo e la velocità effettiva a livello di VM, scegliere una dimensione della macchina virtuale appropriata in base alle esigenze di prestazioni e ai costi del carico di lavoro.

Se si esegue la migrazione ad Azure, è possibile usare strumenti come Data Migration Assistant e Consigli SKU, per analizzare la configurazione e l'utilizzo correnti di SQL Server e suggerire le dimensioni migliori della VM per il carico di lavoro in Azure.

Le seguenti metriche di Azure vengono usate per determinare che il carico di lavoro è limitato dal superamento dei limiti imposti dalla macchina virtuale:

• Percentuale di utilizzo operazioni di I/O al secondo della cache della macchina virtuale
• Percentuale di utilizzo larghezza di banda della cache della macchina virtuale
• Percentuale di utilizzo operazioni di I/O al secondo non della cache della macchina virtuale
• Percentuale di utilizzo larghezza di banda non della cache della macchina virtuale

Considerare i seguenti punti chiave sulla limitazione delle VM:

• È possibile aumentare la memoria, i vCore, la velocità effettiva e le operazioni di I/O al secondo ridimensionando la macchina virtuale all'interno di una serie di macchine virtuali.
• Non è possibile ridurre le dimensioni della VM a un livello in cui il numero di dischi dati supera il limite massimo di dischi dati per le dimensioni della VM di destinazione.
• È importante determinare il modello di limitazione. Ad esempio, è possibile risolvere i picchi sporadici di limitazione ottimizzando il carico di lavoro, mentre dei picchi prolungati potrebbero indicare che l'archiviazione sottostante non sia in grado di gestire il carico di lavoro.

Problema di limitazione di I/O a livello di disco

Per i clienti delle macchine virtuali SQL, l'archiviazione è di fondamentale importanza per configurare in modo appropriato le prestazioni ottimizzate, poiché modificare l'archiviazione rappresenta un’operazione molto più complessa rispetto al ridimensionamento di una macchina virtuale. Se, ad esempio, eventuali modifiche per aumentare le operazioni di I/O al secondo o la velocità effettiva per i dischi SSD Premium richiedono la creazione di un nuovo pool di archiviazione. Di conseguenza, è fondamentale ottimizzare la configurazione dell'archiviazione sia per il prezzo che per le prestazioni durante la fase di pianificazione, così da evitare che una volta effettuata la distribuzione si verifichino problemi relativi alle prestazioni.

Le seguenti metriche di Azure vengono usate per determinare che il carico di lavoro è limitato dal superamento dei limiti imposti dal disco:

• Percentuale di utilizzo operazioni di I/O al secondo del disco dati

• Percentuale di utilizzo della larghezza di banda del disco dati Considerare i seguenti punti chiave sulla limitazione delle operazioni di I/O a livello di disco:

• Il disco dati è fondamentale per le prestazioni di SQL Server. Si consiglia di inserire file di dati di SQL Server (.mdf) e di log (con estensione df) nel disco dati.

• Per una limitazione a livello di disco dati, abilitare, laddove disponibile, la memorizzazione nella cache in lettura.

Percentuale di utilizzo operazioni di I/O al secondo del disco dati

La metrica Percentuale utilizzo disco dati misura il consumo di operazioni di I/O al secondo a livello di disco. In genere, elevate esigenze di I/O al secondo sono associate ad applicazioni e carichi di lavoro basati su OLTP altamente transazionali.   Gli scenari o le condizioni seguenti possono superare i limiti di operazioni di I/O al secondo del disco dati:

• Carico di lavoro transazionale elevato (operazioni di I/O al secondo): se l'applicazione sta elaborando un volume elevato di transazioni di database che coinvolgono operazioni di lettura e scrittura frequenti, rischia di consumare rapidamente le operazioni di I/O al secondo allocate. 
• Query inefficienti: le query SQL non ottimizzate correttamente o le operazioni di recupero dei dati possono causare un'attività di I/O eccessiva, che richiede più operazioni di I/O al secondo del previsto. 
• Utenti simultanei: se più utenti o sessioni accedono simultaneamente al database e generano richieste di I/O, l'effetto cumulativo può comportare il raggiungimento del limite di operazioni di I/O al secondo. 
• Risorse condivise: se l'infrastruttura fisica sottostante è fortemente condivisa con altri tenant o carichi di lavoro, può influire sulle operazioni di I/O al secondo disponibili per la macchina virtuale. 
• Picchi temporanei: i picchi temporanei del carico di lavoro, ad esempio l'elaborazione o migrazione di dati in batch, possono portare ad aumenti improvvisi della domanda di I/O che superano le operazioni di I/O allocate. 
• Dimensioni ridotte del disco: se le dimensioni del disco dati di cui è stato effettuato il provisioning sono relativamente ridotte, la capacità di I/O al secondo potrebbe essere limitata. I singoli dischi più piccoli hanno limiti di I/O al secondo inferiori e, se le richieste dell'applicazione superano questo limite, la "Percentuale utilizzo operazioni di I/O al secondo del disco dati" raggiunge il 100%. 
• Tipo di disco insufficiente: la scelta di un tipo di disco con prestazioni inferiori (ad esempio un HDD Standard) per un'applicazione con utilizzo intensivo di I/O può causare limitazioni delle operazioni di I/O al secondo. 
• Dimensioni di striping del disco non ottimizzate: se la configurazione di archiviazione non è ottimizzata per il carico di lavoro, potrebbe causare prestazioni non ottimali per quanto riguarda le operazioni di I/O al secondo. 

Considerare i passaggi seguenti per evitare di superare il limite di operazioni di I/O al secondo del disco dati:

• Ottimizzare le query SQL e la progettazione del database per ridurre al minimo le operazioni di I/O non necessarie. 
• Scegliere un tipo di disco appropriato (SSD Standard o SSD Premium) che soddisfi i requisiti delle operazioni di I/O al secondo dell'applicazione. 
• Usare dimensioni del disco maggiori per aumentare la capacità di I/O al secondo disponibile. 
• Distribuire l'I/O tra più dischi dati usando configurazioni RAID. 

Percentuale di utilizzo della larghezza di banda del disco dati

La metrica Percentuale utilizzo larghezza di banda del disco dati di Azure misura l'utilizzo della larghezza di banda a livello di disco. In genere, le esigenze di velocità effettiva elevata sono associate ad archiviazione dati, data mart, reporting, ETL e altri carichi di lavoro di analisi dei dati.

Di seguito è possibile trovare scenari o condizioni in cui si rischia di superare i limiti di larghezza di banda del disco dati:

• Trasferimenti di dati di grandi dimensioni: i trasferimenti frequenti di dati delle applicazioni su larga scala tra il disco e il database SQL possono usare rapidamente la larghezza di banda del disco dati disponibile. 
• Caricamento dei dati in bulk: le attività di trasferimento del disco associate a inserimenti, aggiornamenti o importazioni in bulk possono comportare un utilizzo elevato della larghezza di banda. 
• Archiviazione o analisi dei dati: le applicazioni che comportano un’elevata archiviazione, analisi o creazione di report per i dati possono generare un notevole spostamento dei dati, causando potenzialmente il superamento dei limiti di larghezza di banda.
• Tecnologia/replica con ridondanza dei dati elevata: la copia dei dati associata utilizza la replica basata su disco, il mirroring dei dati o altri meccanismi di ridondanza possono contribuire alla saturazione della larghezza di banda. 
• Backup e ripristino dei dati: i backup, gli snapshot o i processi di ripristino frequenti possono utilizzare una porzione significativa della larghezza di banda del disco dati. 
• Esecuzione di query parallele: le query parallele che coinvolgono analisi o join di dati di grandi dimensioni possono causare un notevole spostamento dei dati e un conseguente utilizzo della larghezza di banda. 
• Traffico di rete con privilegi elevati: l'attività di rete elevata, ad esempio i trasferimenti di dati tra la macchina virtuale e altre risorse, può influire indirettamente sulla disponibilità della larghezza di banda del disco dati. 
• Tipo di disco insufficiente: la scelta di un tipo di disco con prestazioni inferiori per un'applicazione con requisiti elevati di trasferimento dei dati può causare un superamento del limite di larghezza di banda. 
• Operazioni simultanee a elevato utilizzo di dati: l'effetto combinato di più processi simultanei o sessioni che accedono e trasferiscono dati sullo stesso disco può comportare il raggiungimento del limite di larghezza di banda. 
• Query non ottimizzate o processi ETL: le query SQL ottimizzate in modo non corretto o i processi Extract, Transform, Load (ETL) possono comportare uno spostamento dei dati eccessivo con conseguente utilizzo eccessivo della larghezza di banda. 

Considerare i passaggi seguenti per evitare di superare il limite di larghezza di banda del disco dati:

• Ottimizzare le operazioni di trasferimento dei dati per ridurre al minimo lo spostamento dei dati non necessario. 
• Prendere in considerazione l'uso di dischi con prestazioni più elevate che offrono una maggiore capacità di larghezza di banda, come ad esempio SSD Premium o SSD Premium v2.
• Distribuire i dati tra più dischi usando tecniche come il partizionamento o il partizionamento orizzontale.
• Ottimizzare e parallelizzare le query e l'elaborazione dei dati per ridurre lo spostamento dei dati.
• Usare meccanismi di compressione e archiviazione dei dati efficienti per ridurre il volume di dati trasferiti.
• Monitorare le metriche delle prestazioni e aumentare le configurazioni di archiviazione in base alle esigenze. I dischi SSD Premium v2 consentono ai clienti di ridimensionare le operazioni di I/O al secondo e la velocità effettiva in base alle esigenze.
• È importante monitorare e analizzare regolarmente le metriche delle prestazioni per identificare la causa delle limitazioni delle operazioni di I/O al secondo ed eseguire azioni appropriate per ottimizzare le prestazioni di archiviazione per la macchina virtuale SQL.

Suggerimento

Monitorando regolarmente le metriche delle prestazioni e ottimizzando le operazioni di trasferimento dei dati e le configurazioni dei dischi, le prestazioni del disco dati per la macchina virtuale SQL resteranno ottimali senza superare i limiti.

Procedure consigliate correlate all'I/O

Poiché i sistemi di archiviazione configurati in modo non corretto possono causare problemi di prestazioni, è possibile usare il riquadro Archiviazione nel portale di Azure per eseguire un subset specifico del disco delle regole di valutazione delle procedure consigliate di SQL per identificare i problemi di configurazione dell'archiviazione con SQL Server nelle macchine virtuali di Azure. La funzionalità procedure consigliate per SQL si basa sull'API Valutazione SQL.

È possibile visualizzare un elenco completo delle raccomandazioni in GitHub. Filtrando la colonna id sulle regole in GitHub, è possibile visualizzare le regole di configurazione del disco della macchina virtuale SQL convalidate nella scheda Procedure consigliate per la configurazione di I/O del riquadro Archiviazione per la risorsa macchine virtuali SQL nel portale di Azure.

• AzSqlVmSize
• AzDataDiskCache
• AzDataDiskStriping
• AzDataOnDataDisks
• AzDbDefaultLocation
• AzDiskColumnCount

• AzErrorLogLocation
• AzPremSsdDataFiles
• AzTempDbFileLocation
• AzTranLogDiskCache
• NtfsBlockSizeNotFormatted
• LockedPagesInMemory

Nella scheda Procedure consigliate correlate all'I/O, usare Esegui valutazione per avviare una valutazione della configurazione, la quale dovrebbe richiedere alcuni minuti (a meno che non esista un numero elevato di database e oggetti). In alternativa, se viene visualizzato un timestamp per i risultati disponibili più recenti, è possibile usare Recupera i risultati più recenti per esaminare i risultati delle valutazioni precedenti.

Analizzare I/O con PowerShell

È inoltre possibile usare lo script di analisi I/O di PowerShell per analizzare le prestazioni di I/O del VM di SQL Server:

# Enter parameters
$subscriptionId = Read-Host "<Subscription ID>"
$resourceGroup = Read-Host "<Resource Group>"
$vmName = Read-Host "<Virtual machine name>"

# Set resource details
$resourceType = "Microsoft.Compute/virtualMachines"
$resourceId = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/$resourceType/$vmName"

# Get Azure access token
$accessToken = az account get-access-token --query accessToken -o tsv

# Invoke Azure Monitor Metrics API
function Get-Metrics {
    [CmdletBinding()]
    param (
        [string]$accessToken,
        [string]$resourceId,
        [string]$metricNames,
        [string]$apiVersion = "2023-10-01"
    )
    try {
        $startTime = (Get-Date).AddHours(-24).ToUniversalTime().ToString('yyyy-MM-ddTHH:mm:ssZ')
        $endTime = (Get-Date).ToUniversalTime().ToString('yyyy-MM-ddTHH:mm:ssZ')
        $timespan = "$startTime/$endTime"
        Write-Verbose "Evaluating timespan: $timespan"
        $uri = "https://management.azure.com$resourceId/providers/Microsoft.Insights/metrics?api-version=$apiVersion&metricnames=$metricNames&aggregation=maximum&interval=PT1M&timespan=$timespan"
        $headers = @{ "Authorization" = "Bearer $accessToken"; "Content-Type" = "application/json" }
        
        $response = Invoke-RestMethod -Uri $uri -Headers $headers -Method Get
        if ($response) {
            Write-Verbose "API response successfully retrieved."
            return $response
        } else {
            Write-Error "No response from API."
        }
    } catch {
        Write-Error "Error retrieving metrics: $_"
    }
}

# Check if data disk latency violates thresholds
function Check-Latency {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true)]
        [Object]$metrics,

        [Parameter()]
        [int]$latencyThreshold = 500,

        [Parameter()]
        [int]$consecutiveCount = 5
    )
    $violationTimes = @()
    foreach ($metric in $metrics.value) {
        if ($metric.name.value -eq "Data Disk Latency") {
            $count = 0
            foreach ($dataPoint in $metric.timeseries[0].data) {
                if ($dataPoint.maximum -gt $latencyThreshold) {
                    $count++
                    if ($count -ge $consecutiveCount) {
                        $violationTimes += $dataPoint.timeStamp
                        $count = 0  # Reset count after recording a violation
                    }
                } else {
                    $count = 0  # Reset count if the sequence is broken
                }
            }
        }
    }
    if ($violationTimes.Count -gt 0) {
        Write-Verbose "Latency violations detected."
        return @{ "Flag" = $true; "Times" = $violationTimes }
    } else {
        Write-Verbose "No latency violations detected."
        return @{ "Flag" = $false }
    }
}

# Check metrics other than latency to evaluate for throttling
function Check-OtherMetricsThrottled {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true)]
        [Object]$metrics,

        [Parameter()]
        [int]$PercentageThreshold = 90,

        [Parameter()]
        [int]$consecutiveCount = 5
    )
    $violatedMetrics = @()
    foreach ($metric in $metrics.value) {
        $count = 0
        foreach ($dataPoint in $metric.timeseries[0].data) {
            if ($dataPoint.maximum -gt $PercentageThreshold) {
                $count++
                if ($count -ge $consecutiveCount) {
                    $violatedMetrics += @{ "Metric" = $metric.name.localizedValue; "Time" = $dataPoint.timeStamp; "Value" = $dataPoint.maximum }
                    break
                }
            } else {
                $count = 0
            }
        }
    }
    if ($violatedMetrics.Count -gt 0) {
        Write-Verbose "Other metrics violations detected."
    } else {
        Write-Verbose "No other metrics violations detected."
    }
    return $violatedMetrics
}

# Compare times for latency & other throttled metrics. Logs the volations with values & timestamps
function CompareTimes {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true)]
        [Hashtable]$latencyResult,
        
        [Parameter(Mandatory = $true)]
        [Array]$otherMetrics
    )
    foreach ($metric in $otherMetrics) {
        $otherDateTime = [DateTime]$metric["Time"]
        $isWithinFiveMinutes = $false
        $closestLatencyTime = $null
        $closestTimeDifference = [int]::MaxValue

        foreach ($latencyTime in $latencyResult.Times) {
            $latencyDateTime = [DateTime]$latencyTime
            $timeDifference = [Math]::Abs(($otherDateTime - $latencyDateTime).TotalMinutes)
            
            if ($timeDifference -le 5) {
                $isWithinFiveMinutes = $true
                if ($timeDifference -lt $closestTimeDifference) {
                    $closestTimeDifference = $timeDifference
                    $closestLatencyTime = $latencyTime
                }
            }
        }

        if ($isWithinFiveMinutes) {
            if ($otherDateTime -lt $closestLatencyTime) {
                Write-Host "`n $($metric["Metric"]) limit was hit before latency spiked at $closestLatencyTime with value $($metric["Value"]). `n"
            } else {
                Write-Host "`n $($metric["Metric"]) hit its limit with value $($metric["Value"]) at $($metric["Time"])."
                Write-Host "Latency spiked at $closestLatencyTime before $($metric["Metric"]) hit its limit `n"
            }
        } else {
            Write-Host "`n Metric: $($metric["Metric"]) exceeded its threshold with a value of $($metric["Value"]) at $($metric["Time"]), but this was not within 5 minutes of any latency spikes."
        }
    }
}

# Prompt user for latency threshold
$latencyThreshold = Read-Host "Enter Latency Threshold (default is 500)"
if (-not [int]::TryParse($latencyThreshold, [ref]0)) {
    $latencyThreshold = 500 # Use default if invalid input
    Write-Host "No valid input provided. Using Default 500ms for disk latency threshold"
}

# Execute main logic
$latencyMetrics = Get-Metrics -accessToken $accessToken -resourceId $resourceId -metricNames "Data Disk Latency"
$latencyResult = Check-Latency -metrics $latencyMetrics -latencyThreshold $latencyThreshold

if ($latencyResult.Flag) {
    
    # If latency is flagged, check for other metrics. If there is no disk latency, machine is likely not throttled but only at high consumption
    Write-Verbose "Checking the following metrics: Data Disk Bandwidth Consumed Percentage,Data Disk IOPS Consumed Percentage,VM Cached Bandwidth Consumed Percentage,VM Cached IOPS Consumed Percentage,VM Uncached Bandwidth Consumed Percentage,VM Uncached IOPS Consumed Percentage"
    
    $DiskVMMetrics = Get-Metrics -accessToken $accessToken -resourceId $resourceId -metricNames "Data Disk Bandwidth Consumed Percentage,Data Disk IOPS Consumed Percentage,VM Cached Bandwidth Consumed Percentage,VM Cached IOPS Consumed Percentage,VM Uncached Bandwidth Consumed Percentage,VM Uncached IOPS Consumed Percentage"
    
    $additionalMetrics = Check-OtherMetricsThrottled -metrics $DiskVMMetrics
    
    if ($additionalMetrics.Count -gt 0) {
        CompareTimes $latencyResult $additionalMetrics
    } else {
        Write-Host "No metrics violations detected besides latency."
    }
} else {
    Write-Host "No latency issues detected."
}

Passaggi successivi

• Eseguire una valutazione delle procedure consigliate di SQL per identificare potenziali errori di configurazione che potrebbero causare problemi di prestazioni.