SentryOne-gegevens verzenden naar de Azure SQL Database DTU-calculator

Heb je ooit contact opgenomen met Microsoft of een Microsoft-partner en met hen besproken wat het zou kosten om naar de cloud te verhuizen? Als dat het geval is, heeft u misschien gehoord van de Azure SQL Database DTU-calculator en hebt u misschien ook gelezen hoe deze is reverse-engineered door Andy Mallon. De DTU-calculator is een gratis hulpprogramma dat u kunt gebruiken om prestatiestatistieken van uw server te uploaden en de gegevens te gebruiken om de juiste servicelaag te bepalen als u die server naar een Azure SQL Database (of naar een elastische SQL Database-pool) zou migreren.

Om dit te doen, moet u een script plannen of handmatig uitvoeren (opdrachtregel of Powershell, beschikbaar om te downloaden op de DTU-calculatorwebsite) tijdens een periode van een typische productiebelasting.

Als u een grote omgeving probeert te analyseren, of gegevens van specifieke tijdstippen wilt analyseren, kan dit een hele klus worden. In veel gevallen hebben veel DBA's een soort monitoringtool die al prestatiegegevens voor hen vastlegt. In veel gevallen legt het waarschijnlijk al de benodigde statistieken vast of kan het eenvoudig worden geconfigureerd om de gegevens vast te leggen die u nodig hebt. Vandaag gaan we kijken hoe we gebruik kunnen maken van SentryOne, zodat we de juiste gegevens aan de DTU-calculator kunnen leveren.

Laten we om te beginnen eens kijken naar de informatie die wordt opgehaald door het opdrachtregelhulpprogramma en het PowerShell-script dat beschikbaar is op de DTU-calculatorwebsite; er zijn 4 prestatiemetertellers die het vastlegt:

• Processor – % processortijd
• Logische schijf – Schijf leest/sec
• Logische schijf – Schijf schrijft/sec
• Database – Logbytes gewist/sec

De eerste stap is bepalen of deze metrische gegevens al zijn vastgelegd als onderdeel van het verzamelen van gegevens in SQL Sentry. Voor ontdekking raad ik u aan deze blogpost van Jason Hall te lezen, waar hij vertelt hoe de gegevens zijn ingedeeld en hoe u deze kunt opvragen. Ik ga hier niet elke stap doornemen, maar moedig je aan om die hele blogreeks te lezen en er een bladwijzer van te maken.

Toen ik door de SentryOne-database keek, ontdekte ik dat 3 van de 4 tellers al standaard werden vastgelegd. De enige die ontbrak was [Database – Log Bytes Flushed/sec] , dus ik moest dat kunnen inschakelen. Er was nog een blogpost van Justin Randall die uitlegt hoe je dat moet doen.

Kortom, u kunt de [PerformanceAnalysisCounter] . opvragen tafel.


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

U zult merken dat standaard de [PerformanceAnalysisSampleIntervalID] is ingesteld op 0 – dit betekent dat het is uitgeschakeld. U moet de volgende opdracht uitvoeren om dit in te schakelen. Haal gewoon de ID uit de SELECT-query die u zojuist hebt uitgevoerd en gebruik deze in deze UPDATE:


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

Nadat u de update heeft uitgevoerd, moet u de voor dit doel relevante SentryOne-bewakingsservice(s) opnieuw starten, zodat de nieuwe tellergegevens kunnen worden verzameld.

Merk op dat ik de [PerformanceAnalysisSampleIntervalID] op 1, zodat de gegevens elke 10 seconden worden vastgelegd, maar u kunt deze gegevens minder vaak vastleggen om de grootte van de verzamelde gegevens te minimaliseren ten koste van minder nauwkeurigheid. Zie de [PerformanceAnalysisSampleInterval] tabel voor een lijst met waarden die u kunt gebruiken.

Verwacht niet dat de gegevens onmiddellijk in de tabellen zullen stromen; dit zal enige tijd duren om zijn weg door het systeem te vinden. U kunt de populatie controleren met de volgende vraag:


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

Zodra u hebt bevestigd dat de gegevens worden weergegeven, zou u gegevens moeten hebben voor elk van de metrische gegevens die door de DTU-calculator worden vereist, hoewel u misschien wilt wachten met extraheren totdat u een representatief voorbeeld hebt van een volledige werklast of bedrijfscyclus.

Als je de blogpost van Jason doorleest, zul je zien dat de gegevens zijn opgeslagen in verschillende rollup-tabellen en dat elk van deze rollup-tabellen verschillende retentiepercentages heeft. Veel hiervan zijn lager dan wat ik zou willen als ik de werkbelasting over een bepaalde periode analyseer. Hoewel het mogelijk is om deze te veranderen, is het misschien niet de verstandigste. Omdat wat ik u laat zien niet wordt ondersteund, kunt u beter niet teveel sleutelen aan de instellingen van SentryOne, omdat dit een negatieve invloed kan hebben op de prestaties, de groei of beide.

Om dit te compenseren, heb ik een script gemaakt waarmee ik de gegevens die ik nodig heb voor de verschillende rollup-tabellen kan extraheren en die gegevens op hun eigen locatie kan opslaan, zodat ik mijn eigen retentie kan regelen en de SentryOne-functionaliteit niet verstoort.

TABEL:dbo.AzureDatabaseDTUData

Ik heb een tabel gemaakt met de naam [AzureDatabaseDTUData] en opgeslagen in de SentryOne-database. De procedure die ik heb gemaakt, genereert deze tabel automatisch als deze niet bestaat, dus het is niet nodig om dit handmatig te doen, tenzij u wilt aanpassen waar deze wordt opgeslagen. Je kunt dit desgewenst in een aparte database opslaan, je hoeft alleen het script te bewerken om dit te doen. De tabel ziet er als volgt uit:

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)
);

Procedure:dbo.Custom_CollectDTUDataForDevice

Dit is de opgeslagen procedure die u kunt gebruiken om alle DTU-specifieke gegevens in één keer op te halen (op voorwaarde dat u de logbytes-teller voldoende lang hebt verzameld), of om deze periodiek aan de verzamelde gegevens toe te voegen totdat u bent klaar om de uitvoer naar de DTU-calculator te verzenden. Net als in de bovenstaande tabel wordt de procedure gemaakt in de SentryOne-database, maar u kunt deze ook gemakkelijk ergens anders maken, door gewoon drie- of vierdelige namen toe te voegen aan objectverwijzingen. De interface naar de procedure is als volgt:

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
...

Opmerking :De hele procedure is een beetje lang, dus het is bijgevoegd aan dit bericht (dbo.Custom_CollectDTUDataForDevice.sql_.zip).

Er zijn een aantal parameters die u kunt gebruiken. Elk heeft een standaardwaarde, dus u hoeft ze niet op te geven als u akkoord gaat met de standaardwaarden.

• @DeviceID – Hiermee kunt u aangeven of u gegevens wilt verzamelen voor een specifieke SQL Server of alles. De standaardwaarde is -1, wat betekent dat alle bewaakte SQL-servers worden gekopieerd. Als u alleen informatie voor een specifieke instantie wilt exporteren, zoek dan de DeviceID corresponderend met de host in de [dbo].[Device] tabel, en geef die waarde door. U kunt slechts één @DeviceID . doorgeven tegelijk, dus als u een reeks servers wilt passeren, kunt u de procedure meerdere keren aanroepen, of u kunt de procedure wijzigen om een ​​reeks apparaten te ondersteunen.
• @DaysToPurge – Dit staat voor de leeftijd waarop u gegevens wilt verwijderen. De standaardwaarde is 14 dagen, wat betekent dat u alleen gegevens van maximaal 14 dagen oud ophaalt en dat alle gegevens die ouder zijn dan 14 dagen in uw aangepaste tabel worden verwijderd.

De andere vier parameters zijn er voor toekomstbestendigheid, voor het geval de SentryOne-opsommingen voor teller-ID's ooit veranderen.

Een paar opmerkingen over het script:

1. Wanneer de gegevens worden opgehaald, wordt de maximale waarde van de ingekorte minuut genomen en geëxporteerd. Dit betekent dat er één waarde per metriek per minuut is, maar dit is de maximale vastgelegde waarde. Dit is belangrijk vanwege de manier waarop de gegevens moeten worden gepresenteerd aan de DTU-rekenmachine.
2. De eerste keer dat u de export uitvoert, kan het wat langer duren. Dit komt omdat het alle gegevens ophaalt die het kan op basis van uw parameterwaarden. Elke extra run, de enige data die wordt geëxtraheerd is wat er nieuw is sinds de laatste run, dus zou veel sneller moeten zijn.
3. U moet deze procedure zo plannen dat deze wordt uitgevoerd volgens een tijdschema dat het opschoonproces van SentryOne voorblijft. Wat ik heb gedaan, is zojuist een SQL Agent-taak gemaakt om 's nachts uit te voeren en die alle nieuwe gegevens van de avond ervoor verzamelt.
4. Omdat het opschoonproces in SentryOne kan variëren op basis van metrische gegevens, zou je kunnen eindigen met rijen in je kopie die gedurende een bepaalde periode niet alle vier de tellers bevatten. Misschien wilt u pas beginnen met het analyseren van uw gegevens vanaf het moment dat u het extractieproces start.
5. Ik heb een codeblok uit bestaande SentryOne-procedures gebruikt om de rollup-tabel voor elke teller te bepalen. Ik had de huidige namen van de tabellen hard kunnen coderen, maar door de SentryOne-methode te gebruiken, zou deze compatibel moeten zijn met eventuele wijzigingen in de ingebouwde rollup-processen.

Zodra uw gegevens naar een zelfstandige tabel zijn verplaatst, kunt u een PIVOT-query gebruiken om deze om te zetten in de vorm die de DTU-calculator verwacht.

Procedure:dbo.Custom_ExportDataForDTUCalculator

Ik heb een andere procedure gemaakt om de gegevens in CSV-indeling te extraheren. De code voor deze procedure is ook bijgevoegd (dbo.Custom_ExportDataForDTUCalculator.sql_.zip).

Er zijn drie parameters:

• @DeviceID – Smallint die overeenkomt met een van de apparaten die u verzamelt en die u wilt indienen bij de rekenmachine.
• @BeginTime – Datetime die de starttijd vertegenwoordigt, in lokale tijd; bijvoorbeeld '2018-12-04 05:47:00.000' . De procedure wordt vertaald naar UTC. Als het wordt weggelaten, wordt het verzameld vanaf de vroegste waarde in de tabel.
• @EndTime – Datetime representeert de eindtijd, wederom in lokale tijd; bijvoorbeeld '2018-12-06 12:54:00.000' . Als het wordt weggelaten, wordt het verzameld tot de laatste waarde in de tabel.

Een voorbeelduitvoering om alle gegevens op te halen die zijn verzameld voor SQLInstanceA tussen 4 december om 5:47 uur en 6 december om 12:54 uur.

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

De gegevens moeten worden geëxporteerd naar een CSV-bestand. Maak je geen zorgen over de gegevens zelf; Ik heb ervoor gezorgd dat de resultaten worden weergegeven zodat er geen identificerende informatie over uw server in het csv-bestand staat, alleen datums en statistieken.

Als u de query uitvoert in SSMS, kunt u met de rechtermuisknop klikken en resultaten exporteren; je hebt hier echter beperkte opties en je zult de uitvoer moeten manipuleren om het formaat te krijgen dat door de DTU-calculator wordt verwacht. (Probeer het gerust en laat het me weten als je een manier vindt om dit te doen.)

Ik raad aan om gewoon de exportwizard te gebruiken die in SSMS is ingebakken. Klik met de rechtermuisknop op de database en ga naar Taken -> Gegevens exporteren. Gebruik voor uw gegevensbron "SQL Server Native Client" en wijs deze naar uw SentryOne-database (of waar u uw kopie van de gegevens ook hebt opgeslagen). Voor uw bestemming wilt u 'Flat File Destination' selecteren. Blader naar een locatie, geef het bestand een naam en sla het bestand op als CSV.

Zorg ervoor dat u de codepagina met rust laat; sommige kunnen fouten retourneren. Ik weet dat 1252 prima werkt. De rest van de waarden blijven als standaard.

Selecteer op het volgende scherm de optie Schrijf een query om de gegevens op te geven die moeten worden overgedragen .

Kopieer in het volgende venster de procedure-aanroep met uw parameters erin. Druk op volgende.

Wanneer u bij de Configure Flat File Destination komt, laat ik de opties standaard. Hier is een screenshot voor het geval de jouwe anders is:

Druk op volgende en ren meteen weg. Er wordt een bestand gemaakt dat u bij de laatste stap zult gebruiken.

OPMERKING :U kunt een SSIS-pakket maken om hiervoor te gebruiken en vervolgens uw parameterwaarden doorgeven aan het SSIS-pakket als u dit veel gaat doen. Zo voorkom je dat je elke keer door de wizard moet.

Navigeer naar de locatie waar u het bestand hebt opgeslagen en controleer of het daar is. Als je het opent, zou het er ongeveer zo uit moeten zien:

Open de website van de DTU-calculator en scrol omlaag naar het gedeelte met de tekst 'Upload het CSV-bestand en bereken'. Voer het aantal kernen in dat de server heeft, upload het CSV-bestand en klik op Berekenen. U krijgt een reeks resultaten zoals deze (klik op een afbeelding om te vergroten):

Aangezien de gegevens afzonderlijk worden opgeslagen, kunt u werkbelastingen van verschillende tijden analyseren, en u kunt dit doen zonder handmatig het commando utility\powershellscript te hoeven uitvoeren voor een server die u al gebruikt om te bewaken.

Om de stappen kort samen te vatten, moet u het volgende doen:

1. Schakel de [Database – Logbytes Flushed/sec]-teller in en controleer of de gegevens worden verzameld
2. Kopieer de gegevens van de SentryOne-tabellen naar uw eigen tabel (en plan die waar nodig).
3. Exporteer de gegevens uit de nieuwe tabel in het juiste formaat voor de DTU-rekenmachine
4. Upload de CSV naar de DTU-calculator

Voor elke server/instantie die u overweegt naar de cloud te migreren en die u momenteel bewaakt met SQL Sentry, is dit een relatief pijnloze manier om in te schatten welk type servicelaag u nodig heeft en hoeveel dat gaat kosten. Je moet het echter nog steeds in de gaten houden als het daarboven is; kijk daarvoor op SentryOne DB Sentry.

Over de auteur