Invio di dati SentryOne al calcolatore DTU del database SQL di Azure

Hai mai contattato Microsoft o un partner Microsoft e discusso con loro quanto costerebbe passare al cloud? In tal caso, potresti aver sentito parlare del calcolatore DTU del database SQL di Azure e potresti anche aver letto come è stato decodificato da Andy Mallon. Il calcolatore DTU è uno strumento gratuito che puoi usare per caricare le metriche delle prestazioni dal tuo server e usare i dati per determinare il livello di servizio appropriato se dovessi migrare il server in un database SQL di Azure (o in un pool elastico di database SQL).

Per fare ciò, devi pianificare o eseguire manualmente uno script (riga di comando o Powershell, disponibile per il download sul sito Web del calcolatore DTU) durante un periodo di un carico di lavoro di produzione tipico.

Se stai cercando di analizzare un ambiente di grandi dimensioni o desideri analizzare i dati da momenti specifici, questo può diventare un lavoro ingrato. In molti casi, molti DBA dispongono di uno strumento di monitoraggio che sta già acquisendo dati sulle prestazioni per loro. In molti casi, probabilmente sta già acquisendo le metriche necessarie o può essere facilmente configurato per acquisire i dati necessari. Oggi vedremo come sfruttare SentryOne in modo da poter fornire i dati appropriati al calcolatore DTU.

Per iniziare, diamo un'occhiata alle informazioni estratte dall'utilità della riga di comando e dallo script di PowerShell disponibili sul sito Web del calcolatore DTU; ci sono 4 contatori di monitoraggio delle prestazioni che acquisisce:

• Processore – % tempo di elaborazione
• Disco logico:letture disco/sec
• Disco logico:scritture disco/sec
• Database – Byte di registro scaricati/sec

Il primo passaggio consiste nel determinare se queste metriche sono già state acquisite come parte della raccolta dati in SQL Sentry. Per la scoperta, suggerisco di leggere questo post sul blog di Jason Hall, in cui parla di come sono disposti i dati e di come è possibile interrogarli. Non esaminerò ogni passaggio di questo qui, ma ti incoraggio a leggere e aggiungere l'intera serie di blog ai segnalibri.

Quando ho esaminato il database SentryOne, ho scoperto che 3 dei 4 contatori erano già stati acquisiti per impostazione predefinita. L'unico che mancava era [Database – Log Bytes Flushed/sec] , quindi dovevo essere in grado di attivarlo. C'era un altro post sul blog di Justin Randall che spiega come farlo.

In breve, puoi interrogare il [PerformanceAnalysisCounter] tabella.


  SELECT  ID, 
    PerformanceAnalysisCounterCategoryID, 
    PerformanceAnalysisSampleIntervalID, 
    CounterResourceName, 
    CounterName
  FROM dbo.PerformanceAnalysisCounter
  WHERE CounterResourceName = N'LOG_BYTES_FLUSHED_PER_SEC';

Noterai che per impostazione predefinita [PerformanceAnalysisSampleIntervalID] è impostato su 0 – questo significa che è disabilitato. Sarà necessario eseguire il comando seguente per abilitarlo. Basta estrarre l'ID dalla query SELECT che hai appena eseguito e utilizzarlo in questo UPDATE:


  UPDATE dbo.PerformanceAnalysisCounter 
    SET PerformanceAnalysisSampleIntervalID = 1 
    WHERE ID = 166;

Dopo aver eseguito l'aggiornamento, sarà necessario riavviare i servizi di monitoraggio SentryOne rilevanti per questo target, in modo che i nuovi dati del contatore possano essere raccolti.

Nota che ho impostato il [PerformanceAnalysisSampleIntervalID] a 1 in modo che i dati vengano acquisiti ogni 10 secondi, tuttavia, è possibile acquisire questi dati meno spesso per ridurre al minimo le dimensioni dei dati raccolti al costo di una minore precisione. Vedi [PerformanceAnalysisSampleInterval] tabella per un elenco di valori che puoi utilizzare.

Non aspettarti che i dati inizino a fluire nelle tabelle immediatamente; ci vorrà del tempo per farsi strada attraverso il sistema. Puoi controllare la popolazione con la seguente query:


  SELECT TOP (100) *
    FROM dbo.PerformanceAnalysisDataDatabaseCounter
    WHERE PerformanceAnalysisCounterID = 166;

Dopo aver confermato che i dati vengono visualizzati, dovresti avere i dati per ciascuna delle metriche richieste dal calcolatore DTU, anche se potresti voler attendere la parte superiore dell'estrazione fino a quando non avrai un campione rappresentativo da un carico di lavoro completo o da un ciclo economico.

Se leggi il post del blog di Jason, vedrai che i dati sono archiviati in varie tabelle di rollup e che ciascuna di queste tabelle di rollup ha tassi di conservazione variabili. Molti di questi sono inferiori a quelli che vorrei se analizzo i carichi di lavoro per un periodo di tempo. Sebbene sia possibile modificarli, potrebbe non essere il più saggio. Poiché ciò che ti sto mostrando non è supportato, potresti voler evitare di armeggiare troppo con le impostazioni di SentryOne poiché potrebbe avere un impatto negativo sulle prestazioni, sulla crescita o su entrambi.

Per compensare ciò, ho creato uno script che mi consente di estrarre i dati di cui ho bisogno per le varie tabelle di rollup e di archiviarli nella propria posizione, in modo da poter controllare la mia conservazione e non interferire con la funzionalità di SentryOne.

TABELLA:dbo.AzureDatabaseDTUData

Ho creato una tabella chiamata [AzureDatabaseDTUData] e archiviato nel database SentryOne. La procedura che ho creato genererà automaticamente questa tabella se non esiste, quindi non è necessario farlo manualmente a meno che non si desideri personalizzare la posizione in cui è archiviata. Puoi archiviarlo in un database separato, se lo desideri, per farlo devi solo modificare lo script. La tabella si presenta così:

CREATE TABLE dbo.AzureDatabaseDTUdata
(
      ID           bigint identity(1,1) not null,
      DeviceID     smallint not null,
      [TimeStamp]  datetime not null,
      CounterName  nvarchar(256) not null,
      [Value]      float not null,
      InstanceName nvarchar(256) not null,
      CONSTRAINT   PK_AzureDatabaseDTUdata PRIMARY KEY (ID)
);

Procedura:dbo.Custom_CollectDTUDataForDevice

Questa è la procedura memorizzata che puoi utilizzare per estrarre tutti i dati specifici della DTU contemporaneamente (a condizione che tu abbia raccolto il contatore dei byte di registro per un periodo di tempo sufficiente) o programmarlo per aggiungerlo periodicamente ai dati raccolti fino a quando sei pronto per inviare l'output al calcolatore DTU. Come la tabella sopra, la procedura viene creata nel database SentryOne, ma puoi facilmente crearla altrove, basta aggiungere nomi in tre o quattro parti ai riferimenti agli oggetti. L'interfaccia per la procedura è la seguente:

CREATE PROCEDURE [dbo].[Custom_CollectDTUDataForDevice]
    @DeviceID     smallint = -1,
    @DaysToPurge  smallint = 14,

    -- These define the CounterIDs in case they ever change. 
    @ProcessorCounterID     smallint = 1858, -- Processor (Default)
    @DiskReadCounterID      smallint = 64,   -- Disk Read/Sec (DiskCounter)
    @DiskWritesCounterID    smallint = 67,   -- Disk Writes/Sec (Diskcounter)
    @LogBytesFlushCounterID smallint = 166,  -- Log Bytes Flushed/Sec (DatabaseCounter)
AS
...

Nota :L'intera procedura è un po' lunga, quindi è allegata a questo post (dbo.Custom_CollectDTUDataForDevice.sql_.zip).

Ci sono un paio di parametri che puoi usare. Ognuno ha un valore predefinito, quindi non devi specificarlo se stai bene con i valori predefiniti.

• @ID dispositivo – Ciò consente di specificare se si desidera raccogliere dati per uno specifico SQL Server o altro. Il valore predefinito è -1, che significa copiare tutti i server SQL controllati. Se desideri esportare solo le informazioni per un'istanza specifica, trova il DeviceID corrispondente all'host nel [dbo].[Device] tabella e passare quel valore. Puoi passare solo un @DeviceID alla volta, quindi se vuoi passare attraverso un insieme di server, puoi chiamare la procedura più volte, oppure puoi modificare la procedura per supportare un insieme di dispositivi.
• @DaysToPurge – Questo rappresenta l'età in cui si desidera rimuovere i dati. L'impostazione predefinita è 14 giorni, il che significa che verranno estratti solo dati fino a 14 giorni prima e tutti i dati più vecchi di 14 giorni nella tabella personalizzata verranno eliminati.

Gli altri quattro parametri sono a prova di futuro, nel caso in cui l'enumerazione SentryOne per gli ID contatore cambi mai.

Un paio di note sulla sceneggiatura:

1. Quando i dati vengono estratti, prende il valore massimo dal minuto troncato e lo esporta. Ciò significa che esiste un valore per metrica al minuto, ma è il valore massimo acquisito. Questo è importante per il modo in cui i dati devono essere presentati al calcolatore DTU.
2. La prima volta che esegui l'esportazione, potrebbe volerci un po' più di tempo. Questo perché estrae tutti i dati che può in base ai valori dei parametri. Ad ogni corsa aggiuntiva, l'unico dato estratto è quello che è nuovo dall'ultima corsa, quindi dovrebbe essere molto più veloce.
3. Dovrai pianificare questa procedura per l'esecuzione in base a una pianificazione temporale che precede il processo di eliminazione di SentryOne. Quello che ho fatto è appena stato creato un processo di SQL Agent da eseguire ogni notte che raccoglie tutti i nuovi dati dalla sera prima.
4. Poiché il processo di eliminazione in SentryOne può variare in base alla metrica, potresti ritrovarti con righe nella tua copia che non contengono tutti e 4 i contatori per un periodo di tempo. Potresti voler iniziare ad analizzare i tuoi dati solo dal momento in cui avvii il processo di estrazione.
5. Ho usato un blocco di codice dalle procedure SentryOne esistenti per determinare la tabella di rollup per ogni contatore. Avrei potuto codificare i nomi correnti delle tabelle, tuttavia, utilizzando il metodo SentryOne, dovrebbe essere compatibile con eventuali modifiche ai processi di rollup integrati.

Dopo aver spostato i tuoi dati in una tabella autonoma, puoi utilizzare una query PIVOT per trasformarli nel modulo previsto dal calcolatore DTU.

Procedura:dbo.Custom_ExportDataForDTUCalculator

Ho creato un'altra procedura per estrarre i dati in formato CSV. Viene allegato anche il codice per questa procedura (dbo.Custom_ExportDataForDTUCalculator.sql_.zip).

Ci sono tre parametri:

• @ID dispositivo – Smallint corrispondente a uno dei dispositivi che stai raccogliendo e che desideri inviare al calcolatore.
• @BeginTime – Datetime che rappresenta l'ora di inizio, in ora locale; ad esempio, '2018-12-04 05:47:00.000' . La procedura si tradurrà in UTC. Se omesso, raccoglierà dal primo valore nella tabella.
• @EndTime – Datetime che rappresentano l'ora di fine, sempre in ora locale; ad esempio, '2018-12-06 12:54:00.000' . Se omesso, raccoglierà fino all'ultimo valore nella tabella.

Un'esecuzione di esempio, per ottenere tutti i dati raccolti per SQLInstanceA tra il 4 dicembre alle 5:47 e il 6 dicembre alle 12:54.

EXEC SentryOne.dbo.custom_ExportDataForDTUCalculator 
    @DeviceID    = 12, 
    @BeginTime   = '2018-12-04 05:47:00.000', 
    @EndTime     = '2018-12-06 12:54:00.000';

I dati dovranno essere esportati in un file CSV. Non preoccuparti dei dati stessi; Mi sono assicurato di produrre risultati in modo che non ci siano informazioni identificative sul tuo server nel file CSV, solo date e metriche.

Se esegui la query in SSMS, puoi fare clic con il pulsante destro del mouse ed esportare i risultati; tuttavia, hai opzioni limitate qui e dovrai manipolare l'output per ottenere il formato previsto dal calcolatore DTU. (Sentiti libero di provare e fammi sapere se trovi un modo per farlo.)

Raccomando semplicemente di utilizzare la procedura guidata di esportazione integrata in SSMS. Fai clic con il pulsante destro del mouse sul database e vai su Attività -> Esporta dati. Per la tua origine dati usa "SQL Server Native Client" e puntalo al tuo database SentryOne (o ovunque tu abbia la tua copia dei dati archiviata). Per la tua destinazione, dovrai selezionare "Destinazione file flat". Individua una posizione, assegna un nome al file e salva il file come CSV.

Fare attenzione a lasciare la codepage da sola; alcuni potrebbero restituire errori. So che 1252 funziona bene. Il resto dei valori rimane come predefinito.

Nella schermata successiva, seleziona l'opzione Scrivi una query per specificare i dati da trasferire .

Nella finestra successiva, copia la chiamata alla procedura con i tuoi parametri impostati. Premi Avanti.

Quando arrivi a Configura destinazione file flat, lascio le opzioni come predefinite. Ecco uno screenshot nel caso in cui i tuoi siano diversi:

Premi il prossimo e corri immediatamente. Verrà creato un file che utilizzerai nell'ultimo passaggio.

NOTA :potresti creare un pacchetto SSIS da utilizzare per questo e quindi passare i valori dei parametri al pacchetto SSIS se lo farai molto. Ciò ti eviterebbe di dover eseguire la procedura guidata ogni volta.

Vai alla posizione in cui hai salvato il file e verifica che sia lì. Quando lo apri, dovrebbe assomigliare a questo:

Apri il sito Web del calcolatore DTU e scorri verso il basso fino alla parte che dice "Carica il file CSV e calcola". Immettere il numero di core del server, caricare il file CSV e fare clic su Calcola. Otterrai una serie di risultati come questo (fai clic su qualsiasi immagine per ingrandire):

Dal momento che i dati vengono archiviati separatamente, puoi analizzare i carichi di lavoro in tempi diversi e puoi farlo senza dover eseguire manualmente\programmare l'utilità di comando\script powershell per qualsiasi server che stai già utilizzando SentryOne per monitorare.

Per ricapitolare brevemente i passaggi, ecco cosa è necessario fare:

1. Abilita il contatore [Database – Log Byte scaricati/sec] e verifica che i dati vengano raccolti
2. Copia i dati dalle tabelle SentryOne nella tua tabella (e programmala dove appropriato).
3. Esportare i dati dalla nuova tabella nel formato corretto per il calcolatore DTU
4. Carica il CSV nel calcolatore DTU

Per qualsiasi server/istanza di cui stai pensando di migrare al cloud e che stai attualmente monitorando con SQL Sentry, questo è un modo relativamente indolore per stimare sia il tipo di livello di servizio di cui avrai bisogno sia il costo. Dovrai comunque monitorarlo una volta che è lassù; per questo, dai un'occhiata a SentryOne DB Sentry.

Informazioni sull'autore