Po pierwszym artykule wprowadzającym nas w tematykę kontynuujemy poznawanie nowego narzędzia jakim jest Azure Data Studio. Dziś powiemy sobie w jaki sposób działają Dashboardy oraz dodamy do nich swoje własne elementy, zaczynajmy!
Dashboard w zamierzeniu ma być miejscem gdzie zaglądamy zaraz po włączeniu narzędzia. To właśnie w tym miejscu możemy zobaczyć podstawowe informacje na temat instancji lub bazy danych do której się łączymy. Najciekawsze w tym wszystkim jest to, że mamy możliwość dostosowania tego miejsca do własnych potrzeb tak aby przedstawić interesujące nas dane biznesowe lub (albo nawet przede wszystkim) dane diagnostyczne. Przejdźmy zatem do tworzenia naszego kokpitu.
O tym jak nawiązać połączenie z bazą danych nie będę pisał, odsyłam do pierwszego artykułu w którym to omówiłem (link). Po połączeniu do instancji naszym oczom powinien ukazać się wspomniany Dashboard. W moim przypadku wygląda on następująco:
Warto wspomnieć, że w przypadku gdy w definicji połączenia nie podamy bazy danych to zostanie nawiązane połączenia do serwera. To z kolei da nam możliwość stworzenia tzw. Server Dashboard, którego zarządzanie nie różni się za wiele od omawianego w tym artykule Database Dashboard dlatego pozwolę sobie go pominąć. Dodam tylko, że w założeniu ma on pokazywać dane dla całego serwera a nie tylko dla wybranej bazy danych. Poniżej znajdziecie zrzut ekranu gdzie możecie rozróżnić połączenie do bazy danych oraz do serwera oraz wspomniany Server Dashboard:
Wróćmy do databse dashboard. Jeśli nie jesteśmy na ekranie startowym to aby zobaczyć Dashboard wystarczy kliknąć prawym przyciskiem myszy na wybrane połączenie i z menu kontekstowego wybrać opcję Manage:
Database Dashboard ukazuje (jak sama nazwa wskazuje) informacje na temat bazy danych, którą wskazaliśmy w połączeniu. W górnej części ekranu dostajemy informacje o ostatnio wykonanej kopii zapasowej bazy danych oraz dziennika transakcyjnego. Ponadto widzimy jaki jest Compatibility Level naszej bazy danych. Poniżej tych informacji mamy do dyspozycji dwa okna gdzie pierwsze zawiera swoistego rodzaju skrót do typowych zadań (Tasks) takich jak np. Backup, Restore oraz możliwość napisania nowego zapytania. Drugie okno to coś na wzór wyszukiwarki bądź eksplorator obiektów z poziomu którego możemy znaleźć określony obiekt i go odpytać, edytować dane lub wygenerować skrypt:
I to by było na tyle jeśli chodzi o to co dostajemy w domyślnym widoku. Co jeżeli chcielibyśmy dodać coś od siebie? Nie jest to takie trudne! W tym konkretnym miejscu najczęściej chcemy dodać graficzną reprezentację danych będących wynikiem wykonania przygotowanego przez nas zapytania. Stwórzmy zatem takie zapytanie na naszej bazie danych. Dla przykładu wybrałem jedno z zapytań diagnostycznych, które przygotował Glenn Berry:
SELECT SERVERPROPERTY('MachineName') AS [MachineName], SERVERPROPERTY('ServerName') AS [ServerName], SERVERPROPERTY('InstanceName') AS [Instance], SERVERPROPERTY('IsClustered') AS [IsClustered], SERVERPROPERTY('ComputerNamePhysicalNetBIOS') AS [ComputerNamePhysicalNetBIOS], SERVERPROPERTY('Edition') AS [Edition], SERVERPROPERTY('ProductLevel') AS [ProductLevel], SERVERPROPERTY('ProductUpdateLevel') AS [ProductUpdateLevel], SERVERPROPERTY('ProductVersion') AS [ProductVersion], SERVERPROPERTY('ProductMajorVersion') AS [ProductMajorVersion], SERVERPROPERTY('ProductMinorVersion') AS [ProductMinorVersion], SERVERPROPERTY('ProductBuild') AS [ProductBuild], SERVERPROPERTY('ProductBuildType') AS [ProductBuildType], SERVERPROPERTY('ProductUpdateReference') AS [ProductUpdateReference], SERVERPROPERTY('ProcessID') AS [ProcessID], SERVERPROPERTY('Collation') AS [Collation], SERVERPROPERTY('IsFullTextInstalled') AS [IsFullTextInstalled], SERVERPROPERTY('IsIntegratedSecurityOnly') AS [IsIntegratedSecurityOnly], SERVERPROPERTY('FilestreamConfiguredLevel') AS [FilestreamConfiguredLevel], SERVERPROPERTY('IsHadrEnabled') AS [IsHadrEnabled], SERVERPROPERTY('HadrManagerStatus') AS [HadrManagerStatus], SERVERPROPERTY('InstanceDefaultDataPath') AS [InstanceDefaultDataPath], SERVERPROPERTY('InstanceDefaultLogPath') AS [InstanceDefaultLogPath], SERVERPROPERTY('BuildClrVersion') AS [Build CLR Version], SERVERPROPERTY('IsXTPSupported') AS [IsXTPSupported], SERVERPROPERTY('IsPolybaseInstalled') AS [IsPolybaseInstalled], SERVERPROPERTY('IsAdvancedAnalyticsInstalled') AS [IsRServicesInstalled];
Po wykonaniu powyższego kodu TSQL otrzymaliśmy kilka podstawowych informacji na temat instancji SQL Server. Postanowiłem nieco zmodyfikować zapytanie aby uzyskać formę, która nieco bardziej będzie pasować na moim kokpicie:
with cte AS ( SELECT SERVERPROPERTY('MachineName') AS [Value], 'MachineName' AS [Server Property] UNION ALL SELECT SERVERPROPERTY('ServerName') , 'ServerName' UNION ALL SELECT SERVERPROPERTY('InstanceName') , 'Instance' UNION ALL SELECT SERVERPROPERTY('IsClustered') , 'IsClustered' UNION ALL SELECT SERVERPROPERTY('ComputerNamePhysicalNetBIOS') , 'ComputerNamePhysicalNetBIOS' UNION ALL SELECT SERVERPROPERTY('Edition') , 'Edition' UNION ALL SELECT SERVERPROPERTY('ProductLevel') , 'ProductLevel' UNION ALL SELECT SERVERPROPERTY('ProductUpdateLevel') , 'ProductUpdateLevel' UNION ALL SELECT SERVERPROPERTY('ProductVersion') , 'ProductVersion' UNION ALL SELECT SERVERPROPERTY('ProductMajorVersion') , 'ProductMajorVersion' UNION ALL SELECT SERVERPROPERTY('ProductMinorVersion') , 'ProductMinorVersion' UNION ALL SELECT SERVERPROPERTY('ProductBuild') , 'ProductBuild' UNION ALL SELECT SERVERPROPERTY('ProductBuildType') , 'ProductBuildType' UNION ALL SELECT SERVERPROPERTY('ProductUpdateReference') , 'ProductUpdateReference' UNION ALL SELECT SERVERPROPERTY('ProcessID') , 'ProcessID' UNION ALL SELECT SERVERPROPERTY('Collation') , 'Collation' UNION ALL SELECT SERVERPROPERTY('IsFullTextInstalled') , 'IsFullTextInstalled' UNION ALL SELECT SERVERPROPERTY('IsIntegratedSecurityOnly') , 'IsIntegratedSecurityOnly' UNION ALL SELECT SERVERPROPERTY('FilestreamConfiguredLevel') , 'FilestreamConfiguredLevel' UNION ALL SELECT SERVERPROPERTY('IsHadrEnabled') , 'IsHadrEnabled' UNION ALL SELECT SERVERPROPERTY('HadrManagerStatus') , 'HadrManagerStatus' UNION ALL SELECT SERVERPROPERTY('InstanceDefaultDataPath') , 'InstanceDefaultDataPath' UNION ALL SELECT SERVERPROPERTY('InstanceDefaultLogPath') , 'InstanceDefaultLogPath' UNION ALL SELECT SERVERPROPERTY('BuildClrVersion') , 'Build CLR Version' UNION ALL SELECT SERVERPROPERTY('IsXTPSupported') , 'IsXTPSupported' UNION ALL SELECT SERVERPROPERTY('IsPolybaseInstalled') , 'IsPolybaseInstalled' UNION ALL SELECT SERVERPROPERTY('IsAdvancedAnalyticsInstalled') , 'IsRServicesInstalled' ) SELECT [Server Property],[Value] FROM cte
Rezultat (a raczej jego część) prezentuje się w następujący sposób:
Mamy już dane, które będziemy chcieli osadzić na naszym kokpicie. Aby wybrać graficzną formę dla tychże danych musimy kliknąć widoczną po prawej stronie ikonę wykresu:
W oknie definiowania wizualizacji możemy dokonać wyboru pomiędzy róznego rodzaju wykresami lub m.in prostą tabelą. W moim przypadku wybrałem tą drugą opcję, która według mnie najlepiej sprawdzi się w przedstawieniu kilkudziesięciu własciwości opisowych bazy danych. Tabela, jak można zauważyć poniżej, na moment pisania tego artykułu nie ma absolutnie żadnych możliwości dostosowaniaczy też customizacji:
Dlatego też wiecie już czemu dostosowałem wcześniej zapytanie TSQL i doprowadziłem dane do określonego formatu – ponieważ jest to jedyna dostępna możliwość. Gdy już mamy wszystko co chcemy umieścić na kokpicie musimy kliknąć przycisk nazwany “Create Insight” gdzie Insight to nic innego jak gotowy do osadzenia widget:
Kliknięcie przycisku spowodowało wygenerowanie kodu JSON z całą konfiguracją naszej wizualizacji. Aby kod był nieco bardziej czytelny możemy go sformatować – pamiętajmy o opcji Format Document dostępnej pod prawym przyciskiem myszy:
W samym kodzie warto zwrócić uwagę na parametr queryFile, który jest niczym innym jak ścieżką, która wskazuje na plik zawierający zapytanie dostarczające danych do wizualizacji. Warto zatem zapisać go w dedykowanej lokalizacji z odpowiednią nazwą, następnie powstałą ścieżkę podać w wygenerowanym pliku JSON:
Mając już gotowy plik z zapytaniem możemy wejść do konfiguracji dashboardu. Mamy kilka możliwości aby się tam dostać, jedną z nich jest wybór przycisku ustawień w lewym dolnym rogu ekranu:
W oknie opcji musimy wyszukać opcję widgetów dla dashbordu bazy danych (Dashboard-> Database: Widgets) i kliknąć opcję edycji pliku json:
W otwartym pliku ustawień to co musimy zrobić to odnaleźć gałąź odpowiedzialną za ustawienie dashboard.database.widgets i kliknąć ikonę edycji zaznaczoną na poniższym zrzucie ekranowym:
Po prawej stronie otwartego okna mamy możliwość wklejenia wygenerowanego wcześniej kodu:
Pamiętajmy aby definicję naszego widgetu oddzielić przecinkiem od pozostałych elementów pliku json. Po zapisaniu ustawień (CTRL+S) możemy raz jeszcze otworzyć dashboard gdzie w losowej lokalizacji powinien znaleźć się nasz nowy widget:
Aby go przenieść we własciwe miejsce po raz kolejny możemy kliknąć na przycisk edycji dostępny w prawym górnym rogu:
Położenie naszego nowego obiektu dostosujemy metodą przeciągnij – upuść. Po prawidłowym ułożeniu powinniśmy użyć tego samego przycisku aby potwierdzić czy też zapisać nasze zmiany:
Warto odnotować fakt, że z tego miejsca nie będziemy mogli zmienić nazwy ani rozmiaru naszego widgetu. Jedyne miejsce gdzie możemy tego dokonać znany już jsonowy plik ustawień. Odpowiadają za to samoopisujące ustawienia name oraz sizex i sizey. Rozmiar generowany jest horyzontalnie (sizex) oraz wertykalnie (sizey) gdzie wyjściową jednostką rozmiaru jest 1:
Po zapisaniu pliku ustawień i ponownym otwarciu zmiany powinny być odzwierciedlone na kokpicie. Mamy do dyspozycji również przycisk odświeżenia, który po prostu wykona znajdujące się pod spodem zapytanie:
Nie ma tutaj problemu z tym, że podmienimy kod w pliku z TSQL, Azure Data Studio po prostu wykona to co znajduje się w pliku i wrzuci to do widgetu (w tym wypadku tabeli).
Jakie są zastosowania takiego dashboardu? Jest ich naprawdę całkiem dużo od typowo administracyjnych takich jak informacje o ostatnich kopiach zapasowych, fragmentacji indeksów, statystk oczekiwań czy użycia zasobów po bardziej deweloperskie jak poprawność wykonania określonych zadań, paczek SSIS i innych. Poświęcając trochę czasu możemy zbudować naprawdę fajne rzeczy. Oczywiście ilość widgetów jest nieograniczona i możemy ich mieć tyle ile tylko chcemy, zarówno w formie tabelarycznej jak i graficznej. Jak widzicie dostosowanie ekranu do własnych potrzeb w cale nie jest takie trudny i daje nam dosyć ciekawe możliwości. Jestem pewny, że z czasem narzędzie zostanie wzbogacone o kolejne udogodnienia i możliwości. Na ten moment warto testować i sprawdzić czy narzędzie wpisuje się w nasze potrzeby i rozwiązuje problemy lub ułatwia codzienną pracę.
Link do dokumentacji: https://docs.microsoft.com/en-us/sql/azure-data-studio/tutorial-build-custom-insight-sql-server?view=sql-server-2017
- Avoiding Issues: Monitoring Query Pushdowns in Databricks Federated Queries - October 27, 2024
- Microsoft Fabric: Using Workspace Identity for Authentication - September 25, 2024
- Executing SQL queries from Azure DevOps using Service Connection credentials - August 28, 2024
Last comments