Niekompletny Activity Monitor

SSMS ma nowy Activity Monitor, zapewniający informacje, które do tej pory DBA musiał zbierać z wielu źródeł. Są to przede wszystkim wykresy, na których można śledzić użyteczne statystyki, takie jak: wykorzystanie CPU, zadania oczekujące czy zlecenia wsadowe. Pod wykresami znajdują się szczegółowe informacje o procesach, oczekujących zasobach, ostatnie obciążające kwerendy i we/wy plików danych.

Chociaż Activity Monitor prezentuje się dobrze, to jego użyteczność jest ograniczona. Statystyki najwyższego poziomu dotyczące serwerów można uzyskiwać bezproblemowo z wykresów: wykres ładuje się dostatecznie szybko i informacja jest użyteczna. Kłopoty zaczynają się, kiedy trzeba zajrzeć głębiej do informacji. W rzeczywiście obciążonym systemie trwa to zbyt długo. Podczas testów na 64-bitowym systemie hurtowni danych zapuszczono 1500 raportów i kilkanaście kwerend ad hoc. Oczekiwanie na wyniki trwało ponad pięć minut, co jest czasem zbyt długim w razie potrzeby szybkiego zlokalizowania problemu.

Ponadto nie ma tu wielu oczekiwanych informacji. W rozwijanej wiadomości można było zobaczyć, że serwer wykorzystał ok. 67% CPU. Jednak następnego fragmentu potrzebnej informacji (o użytkowaniu pamięci, dysków) - już brak. Można oglądać przepustowość dysków, ale w praktyce nie wnosi to nic istotnego, jeśli pojawią się problemy z dyskiem.

Podsumowując: można uznać te serwerowe statystyki za użyteczne, ale jednak nie całkiem kompletne. Jeżeli trzeba posłużyć się innym narzędziem do oglądania statystyk pamięci i dysków, to także z powodzeniem można zrezygnować z Activity Monitor i zdać się na inne narzędzia o podobnej funkcjonalności.

Szczegóły procesów, oczekujące zasoby i we/wy plików danych są bardziej użyteczne. Monitor oczekujących zasobów pokazuje wszystkie zasoby poziomu serwera według typów i podaje statystyki o każdym z nich. Również statystyki we/wy plików danych zawierają ważne informacje.

Interfejs graficzny jest tu bardziej przyjazny niż manualne kwerendy. Można łatwo filtrować dane, które chce się oglądać, co z kolei pomaga przy lokalizowaniu problemów, zwłaszcza gdy poszukuje się specyficznych użytkowników lub blokującego procesu. Jedna uwaga: chociaż można przestawiać wyświetlane kolumny, to przy kolejnym otwarciu Activity Monitor trzeba to zrobić od nowa.

Autoodświeżanie rozwijanych szczegółów to jeden z efektów graficznego interfejsu. Częstotliwość odświeżania można skonfigurować, ale nie można zrobić tego na stałe. Problemem jest zdolność zbierania potrzebnych danych wydajnościowych w czasie odświeżania, zwłaszcza dla systemów mocno obciążonych, które gromadzą dużo danych o wydajności.

Wyciągnięcie informacji o operacjach we/wy plików danych dla kilkunastu plików może zabrać więcej niż 10 sekund domyślnej częstotliwości odświeżania. I chociaż częstotliwość odświeżania można zmienić, np. do jednej minuty, wykres CPU będzie odświeżany również tylko raz w ciągu tej minuty. Niestety, nie można ustawiać różnych interwałów odświeżania dla różnych monitorów.

Podsumowując: Activity Monitor w obecnej postaci nie jest dość użyteczny. Uzyskanie potrzebnych informacji nie tylko zabiera zbyt dużo czasu, ale dostarczane informacje są pobieżne i potrzebne jest kolejne narzędzie, aby je skompletować.

Resource Governor

Microsoft reklamuje Resource Governor jako jedno z największych ulepszeń w tym wydaniu i niewątpliwie będzie on przydatny w środowiskach, które muszą utrzymać niezależność jednych procesów od innych. Jednym z najlepszych zastosowań tego mechanizmu może być system OLTP, gdzie trzeba wymuszać raporty na żywych danych.

Jednak jest to pierwsze podejście Microsoftu do precyzyjnego zarządzania zasobami, i chociaż jest to dobry początek, prawdopodobnie ten mechanizm nie będzie natychmiast tak użyteczny, jak się tego spodziewają użytkownicy. Przede wszystkim można specyfikować tylko dwa rodzaje zasobów przy definiowaniu grup limitowania zasobów: CPU i pamięć. Można też specyfikować wartości minimalne i maksymalne dla każdego z nich, ale jest to niewystarczające do definiowania kłopotliwych procesów w silnie obciążonym systemie. Procesy kłopotliwe przybierają wiele form i przechwytywanie ich wymaga określenia dodatkowych (obok CPU i pamięci) parametrów: liczby we/wy, zakres czasu itp.

Z chwilą zdefiniowania procesu przynależnego do danej grupy zasobów, pozostaje on w tej grupie. Nadmiernie obciążające kwerendy nie mogą być przesuwane dynamicznie do różnych grup, jak to można robić w Oracle Database. Aby przydzielić kwerendy do innej grupy zasobów, konieczne jest skasowanie procesu, przydzielenie go do tej innej grupy i następnie restartowanie Resource Governor.

Trzeba też zachować ostrożność przy ustawianiu grup. Zdefiniowanie np. trzech grup, z których każda ma jako maksimum 50% pamięci, prowadzi do oczywistego problemu.

Trudno nie porównywać Microsoft Resource Governor z rozwiązaniem Oracle. Oracle Database ma taki mechanizm dłużej i jest on bogatszy oraz bardziej dojrzały. Jest jednak jedna zaleta rozwiązania Microsoftu, której nie można ignorować: dostaje się je w ramach licencji, podczas gdy w przypadku Oracle jest to dość kosztowny dodatek.

Change Data Capture i nierejestrowane wstawianie danych

Change Data Capture (CDC) i nierejestrowane wstawianie danych to dwa przydatne ulepszenia w silniku SQL Server. Dotyczą głównie hurtowni danych, ale mogą być również użyteczne dla niektórych systemów OLTP. CDC zapewne zmieni sposób pisania procesów ETL dla hurtowni danych. Pozwala na łatwe ładowanie do hurtowni danych tylko tych tablic, które zawierają zmienione dane - nie trzeba już modyfikować aplikacji dziedziczonych czy procesów ETL o uaktualnione kolumny we wszystkich tablicach, aby zapewnić tę funkcjonalność. Można także z dużą precyzją śledzić zmiany wykonywane w bazie danych bez podmiany schematu lub wykonywania kłopotliwych i mocno obciążających kwerend, aby odfiltrować takie różnice.

Odzyskanie tych zmian z tablic CDC jest również stosunkowo proste. Microsoft zapewnił zestaw funkcji, które wyszukują te dane i wszystko, co trzeba zrobić, to po prostu je wywołać.

Nierejestrowane wstawianie danych pozwala SQL Server na wykonywanie minimalnej rejestracji przy wstawianiu dużych porcji danych do tabeli. Nie rejestrując dodawania każdego wiersza danych, można znacznie przyspieszyć ładowanie danych.

Nierejestrowane wstawianie danych pozwala na dokładanie wierszy do istniejących tablic, utrzymanie kontroli, jaką się ma nad własną przestrzenią pamięci, wydajnością i bezpieczeństwem, a także zachowanie korzyści z szybkiego ładowania danych. Nie trzeba już usuwać i odtwarzać trwałych obiektów każdego dnia, co generuje błędy i wprowadza nadmierne komplikacje do systemu.

Podczas testów nierejestrowane wstawianie danych przebiegało poprawnie. Mechanizm ten może okazać się bardzo przydatny zwłaszcza dla administratorów dużych hurtowni danych.