.:: strefa ::.

Tytuł sugeruje, że SQL Server 2005 SP3 powstał lub ma powstać. Tymczasem sytuacja jest wręcz przeciwna. Jak wiadomo, od czasów dostarczenia SP2 pojawiło się całe mnóstwo hotfixów, cumulative fixów, cumulative updatów tudzież innych update packagów. Nie znam już nikogo, kto by się w tym dobrze orientował (buildy mylą się nawet ludziom z MS...). W takiej sytuacji wiele osób nieśmiało oczekiwało na pojawienia się wybawcy, czyli dobrze przygotowanego i gruntownie przetestowanego SP3, który zawierałby remedium na wszystkie zidentyfikowane błędy i problemy. Byłby ponadto poprawką o statusie publicznym, a nie - dostępną na żądanie, jak w przypadków praktycznie wszystkich ostatnio wypuszczonych bugfixów.

Jak na to wszystko patrzy Microsoft? Zupełnie odmiennie. Na forum dla MVP padło następujące stwierdzenie ze strony MS: Good, but honestly, at least our management says, we're not getting feedback requesting SP3 from enough customers to require it. Sprawa jest więc prosta - koncern z Redmond wypuści SP3 dopiero w momencie, w którym wymuszą to na nim klienci. Na moment obecny nie ma żadnych planów dostarczenia kolejnego service packa do SQL Server 2005. Z pewnych źródeł wiem (nie powiem z jakich, bo musiałbym zostać zlikwidowany), że w SQL Server Teamie trwają prace nad przebudową modelu testowego (i kodu z nim związanego), ale odbywa się to z myślą o SQL Server 2008, a nie 2005. Pewnie MS liczy na to, że uda mu się gładko zastąpić przynajmniej część instancji SQL Server 2005 nową wersją, której istotnie dużo bliżej do 2005, niż w przypadku problematycznej migracji SQL Server 2000 do 2005. Oczywiście nie jest to koncepcja zupełnie pozbawiona sensu, ale rynek ma swoją bezwładność i może powstać spory problem, jeżeli na produkcji pozostanie całkiem sporo Yukonów.

Oczywiście od razu znajdzie się ktoś, kto powie - ale w czym problem, przecież można poinstalować wszystkie cumulative updaty i problem z głowy. Otóż niezupełnie (już nawet pomijając problemy logistyczne z tym związane). Wszystkie ostatnie fixy powinny być instalowane jedynie w przypadku wystąpienia określonych problemów. Service pack natomiast instaluje się przede wszystkim po to, aby tych problemów uniknąć, zanim się pojawią.

Więcej informacji:
Connect: Release Service Pack 3 for SQL Server 2005
Hugo Kornelis: Want a Service Pack? Ask for it!

Buffer cache to specjalny kontener rezydujący wyłącznie w pamięci RAM, który przechowuje odczytane z dysku strony danych. Zawartość bufora jest natomiast odczytywana przez procesor kwerend i przetwarzana zgodnie z logiką zapytania. Odczyt jednej strony danych do bufora to tzw. odczyt fizyczny (physical read), natomiast odczyt jednej strony danych z bufora do przestrzeni zapytania to tzw. odczyt logiczny (logical read). Procesor kwerend nigdy bezpośrednio nie sięga do dysku (każda strona danych musi być najpierw odczytana do buffer cache). Po co to wszytko? Przede wszystkim po to, aby minimalizować obciążenie podsystemu IO (czyli dysków), gdyż odczyty logiczne są bardzo szybkie i nieobciążające, czego nie można powiedzieć o odczytach fizycznych. Jeżeli więc jakaś strona danych trafi do bufora, to kolejne zapytania nie będą musiały żądać pobrania tych danych z dysku. Naturalnie nie wszystkie strony danych mogą znaleźć się w buffer cache na dowolnie długi czas, ale przecież nie wszystkie strony są w danym momencie potrzebne. Drugim istotnym powodem istnienia bufora danych są kwestie związane z mechanizmem blokad niskopoziomowych typu latch i ogólnie mówiąc - z implementacją współbieżności i transakcyjności. W systemie SQL Server mamy jeden buffer cache (zwany także buforem danych lub cachem danych) dla całej instancji, podobnie z resztą jak w przypadku tzw. procedure cache, który to z kolei przechowuje plany zapytań kwerend ad-hoc i innych obiektów (jak procedury, triggery czy wydoki). Często możemy być zainteresowani uzyskaniem informacji na temat tego, jakie ilości danych przechowywane są w buforze danych w określonym momencie oraz tego, ile MB bufora przypada na strony danych pochodzące z poszczególnych baz. Do takich celów możemy wykorzystać poniższe zapytanie do widoku sys.dm_os_buffer_descriptors:

SELECT CASE
   WHEN (GROUPING(database_id) = 1) THEN '-- TOTAL --'
   ELSE DB_NAME(database_id)
END as 'Database name',
CAST(COUNT(page_id)/128.0 as numeric(8,2)) as MB
FROM sys.dm_os_buffer_descriptors
WHERE database_id !=32767
GROUP BY database_id
WITH ROLLUP
ORDER BY COUNT(page_id) DESC;

Trzeba pamiętać, że ilość pamięci RAM jest ograniczona i często procedure cache będzie rywalizował z buffer cache o przestrzeń do zaalokowania. Jeśli więc nagle z procedure cache wypadło nam większość planów zapytań, to warto ustalić przy pomocy powyższego zapytania, co dzieje się w buforze danych. Potencjalnie może się okazać, że tzw. wild query (np. przypadkowy CROSS JOIN na wielkich zbiorach) spowodowało wrzucenie do buffer cache gigabajtów danych, co w konsekwencji nadmiernie ograniczyło przestrzeń dostępną dla procedure cache.

Wczoraj udostępniona została kolejna wersja Community Technology Preview systemu SQL Server 2008, oznaczona jako CTP6 lub February CTP. Na pierwszy rzut oka lista zmian nie jest w przypadku nowego CTP tak imponująca, jak przy CTP5 - co nie oznacza, że brakuje ciekawych ulepszeń. Dodano np. funkcjonalność indeksów filtrowanych, kompresję danych i indeksów, a z rzeczy praktycznych - lepsze Intellisense. Pełna lista improvements obejmuje 15 pozycji:
- Read-only SSAS shared scaleout,
- Support for Microsoft Word rendering,
- Data visualization enhancements,
- Report design enhancements in BI Development Studio,
- Throughput enhancements,
- Full-text Search (iFTS),
- Filtered indexes,
- Sparse columns,
- Microsoft Sync support,
- Policy-Based Mamanagement completeness,
- Performance Data Collection,
- Intellisense enhancements,
- Failover cluster,
- SQL Audit,
- Data compression.

Po raz pierwszy do wersji CTP Microsoft udostępnił także Feature Pack CTP, czyli zestaw dodatkowych komponentów, które rozszerzają możliwości środowiska. W jego skład wchodzą:
- Microsoft SQL Server 2008 Native Client,
- Microsoft SQL Server 2005 Backward Compatibility Components,
- Microsoft SQL Server 2008 Reporting Services Add-in for Microsoft SharePoint Technologies.

Obraz z SQL Server 2008 CTP6 zajmuje około 1.3 GB, natomiast Feature Pack to maksymalnie 140 MB.

Więcej informacji:
SQL Server 2008 CTP
Download: Microsoft SQL Server 2008 CTP, February 2008
Download: Microsoft SQL Server 2008 Feature Pack CTP, February 2008

Dnia 04 marca 2008 roku planowane jest IV spotkanie grupy PLSSUG Lublin. Godziny spotkania (17:00-19:00 z możliwością przedłużenia) oraz miejsce (siedziba firmy Anica System S.A.) nie zmieniają się. Jeżeli chodzi o meritum spotkania, to rozpoczniemy od niezakończonej na poprzednim spotkaniu sesji Bartka Matosiuka dotyczącej data minigu. Następnie Marcin Borecki opowie o Language Integrated Query (LINQ). Obydwie sesje zapowiadają się bardzo ciekawie. Prelegenci IV spotkania - podobnie jak prowadzący sesję na trzech pierwszych spotkaniach - otrzymają nagrody. Na pewno przeprowadzimy także co najmniej jeden konkurs, w którym będzie można wygrać oryginalne gadżety. Zainteresowanych serdecznie zapraszam, przypominając jednocześnie o konieczności rejestracji na każde spotkanie PLSSUG. Na moment obecny na IV spotkanie zarejestrowanych jest 12 osób na nieco ponad 30 dostępnych miejsc. Przy okazji informuję, że kilka dni temu Culminis przysłał certyfikat członkowski dla PLSSUG Lublin. Wygląda on tak:


Agenda spotkania:
17:00-17:15 - Kwestie organizacyjne (Marcin Guzowski)
17:15-18:05 - Wprowadzenie do data miningu (Bartosz Matosiuk)
18:05-19:00 - LINQ (Marcin Borecki)

Więcej informacji:
Strona informacyjna PLSSUG Lublin
PLSSUG Lublin: Rejestracja na spotkanie

Pytanie: czy na SQL Server 2005 da się zobaczyć, jaki jest postęp operacji ROLLBACK?

Odpowiedź brzmi: tak. Niektóre operacje (DBCC CHECKDB, DBCC SHRINKDATABASE, DBCC SHRINKFILE, BACKUP DATABASE, ROLLBACK) wewnętrznie notyfikują postęp operacji. Do informacji tej można dotrzeć przy pomocy odpowiednich kolumn widoku systemowego sys.dm_exec_requests:

SELECT start_time, percent_complete, estimated_completion_time
FROM sys.dm_exec_requests;

W powyższy sposób nie da się natomiast określić postępu zwracania danych działającego zapytania. Jeżeli chodzi o postęp transakcji, to można różnymi wysoce niestandardowymi i przybliżonymi metodami próbować szacować ilość rekordów, jaka pojawia się w dzienniku transakcyjnym. Na tej podstawie możemy wnioskować, czy dana transakcja rzeczywiście modyfikuje w danym momencie dane i jakie jest względne tempo tych modyfikacji. Wykorzystamy do tego celu funkcję fn_dblog().

Jak nie od dziś wiadomo, SQL Sever 2008 November CTP (CTP5) wprowadził szereg nowych funkcjonalności, jak choćby Resource Governor, SSMS z Intelli Sense dla składni T-SQL, FILESTREAM, plan freezing czy kompresja backupów. Są to nowości bardzo medialne i informacja o nich pojawia się praktycznie na wszystkich blogach, stronach, webcastach itd. Warto jednak wspomnieć, że w najnowszej wersji silnika SQL Server mamy także do czynienia z dużą grupą zmian wewnętrznych, mniej widowiskowych, które jednak są równie istotne. W tym poście chciałbym się przyjrzeć ulepszeniom i modyfikacjom, jakie dotyczą statystyk stanów oczekiwań.

Zacznijmy od rzeczy oczywistych, czyli od centralnego widoku systemowego sys.dm_os_wait_stats. Pierwsza różnica polega na tym, że znacznie przybyło nowych stanów oczekiwań. Liczba typów stanów oczekiwań w SQL Server 2005 wynosiła 201 (250 po włączeniu specjalnej flagi 8001 - DBCC TRACEON (8001,-1) ), natomiast w November CTP typów stanów oczekiwań jest aż 463, czyli ponad 200 więcej. Flaga 8001 już nie powoduje pojawienia się dodatkowych rekordów w widoku. Rola i struktura samego widoku pozostała bez zmian. Nadal agreguje on informacje o globalnych stanach oczekiwań od początku działania instancji lub ostatniego resetu na zasadzie przyrostowej. Nowe stany oczekiwań wiążą się po części z nowymi mechanizmami, jakie funkcjonują w Katmai. Ale to nie wszystko - jest też druga grupa. Nazwy 189 nowych stanów oczekiwań zaczynają się od przedrostka PREEMPTIVE_. Nie są to bynajmniej stany "martwe" (agregują konkretne oczekiwania). Wydaje się, że dotyczą bardzo wewnętrznych kwestii systemu operacyjnego SQL Server - SQLOS (m.in. PREEMPTIVE_OS_WAITFORSINGLEOBJECT, PREEMPTIVE_OS_WRITEFILEGATHER). Jeżeli stany te nie zostaną usunięte w wersji RTM, to będziemy mogli oglądać ciekawe informacje statystyczne, o ile tylko stany typu PREEMPTIVE zostaną dobrze opisane.

Jeżeli chodzi o statystyki globalnych stanów oczekiwań (wypadkowych dla danej instancji - widok DMV sys.dm_os_wait_stats), to w SQL Server 2008 stosujemy dokładnie taką samą metodę, jak w przypadku SQL Server 2005. Możemy więc wykorzystać choćby ten skrypt, który przygotowałem specjalnie dla SQL Server 2005. Uruchomienie go na odciążonych instancjach SQL Server 2008 i SQL Server 2005 pokazuje ciekawe różnice. Dla Katmai otrzymamy następujące niezerowe stany oczekiwań:


Podczas gdy na SQL Server 2005 sytuacja wygląda następująco:


Jak widać, różnice są dość zasadnicze. Analizując statystyki stanów oczekiwań na SQL Server 2008, więcej stanów oczekiwań należy rozpatrywać jako nieszkodliwe (m.in. REQUEST_FOR_DEADLOCK_SEARCH, BROKER_TO_FLUSH).

Istotne ulepszenie dotyczy pewnej niedogodności związanej z widokiem sys.dm_os_waiting_tasks. W SQL Server 2005 widok ten dawał informacje o statystykach oczekiwania sesji, które aktualnie na coś czekają. Były to więc informacje niezmiernie ulotne - oczekiwania są przecież bardzo chwilowe, jeśli więc sesja przestawała czekać lub zmieniała typ oczekiwania, to albo znikała z widoku, albo statystyki oczekiwań resetowały się. Nie było więc łatwego sposobu, żeby w środowisku produkcyjnym uzyskać informacje o tym, jakie są statystyki stanów oczekiwań konkretnego zapytania. Co prawda w SQL Server 2008 widok DMV sys.dm_os_waiting_tasks działa na takiej samej zasadzie, mamy jednak do dyspozycji nowy mechanizm - Extended Events wraz ze zdarzeniem rozszerzonym wait_info:

SELECT
o.name as event_name,
c.name as column_name,
c.column_id,
c.column_type
FROM sys.dm_xe_objects o JOIN sys.dm_xe_object_columns c
ON (o.name = c.object_name)
WHERE o.name = 'wait_info';

Powyższe zapytania pokazuje, jakie informacje możemy uzyskiwać o stanach oczekiwań przy pomocy XEvents:


Wykorzystanie XEvents nie jest może najwygodniejsze, bo to zupełnie nowy framework współpracujący z ETW (Event Tracing for Windows), poniższy skrypt powinien jednak trochę rozjaśnić całą koncepcję:

BEGIN TRY
DROP EVENT SESSION waitinfo_session ON SERVER;
END TRY
BEGIN CATCH END CATCH
GO

CREATE EVENT SESSION waitinfo_session ON SERVER
ADD EVENT sqlos.wait_info
ADD TARGET package0.etw_classic_sync_target
(SET default_etw_session_logfile_path = N'C:\temp\waitinfo.etl');
GO

ALTER EVENT SESSION waitinfo_session ON SERVER STATE = START;
GO

-- workload
-- (..)

ALTER EVENT SESSION waitinfo_session ON SERVER STATE = STOP;
GO

Aby powyższy skrypt zadziałał, trzeba kilku rzeczy dopilnować. Co oczywiste, konto, na którym działa usługa SQL Server, musi mieć dostęp do katalogu C:\temp. Co mniej oczywiste, konto powinno także należeć do dwóch grup - Performance Monitor Users i Performance Log Users. Niestety standardowa instalacja November CTP nie dodaje konta do drugiej grupy. Po dodaniu konta do odpowiednich grup może być wymagany restart instancji.

Kiedy zagregujemy już odpowiednie dane do pliku waitinfo.etl, warto je jakoś odczytać. W tym celu należy skonwertować plik ETL do bardziej przyjaznego formatu - CSV. Wykonamy więc następującą operację:

tracerpt waitinfo.etl

Otrzymamy dwa pliki: dumpfile.csv oraz summary.txt, z nich łatwiej odczytamy interesujące nas informacje. Dane te będzie jeszcze trzeba wrzucić do tabeli i odpowiednio powiązać, aby dostarczyły nam tego, czego oczekujemy. Widać więc, że badanie stanów oczekiwań z XEvents jest jeszcze niedopracowane i wymaga szeregu poprawek i uproszczeń. W każdym razie mi nie udało się w prosty sposób zmusić tego do efektywnej pracy zgodnej z moimi oczekiwaniami, ale pożyjemy - zobaczymy.

To tyle na moment obecny, jeśli zauważę jakieś dodatkowe ulepszenia lub różnice w obszarze tematyki stanów oczekiwań w SQL Server 2008, to w pierwszej wolnej chwili o tym napiszę.

Trzecie spotkanie PLSSUG Lublin odbędzie się 05 lutego 2008 roku w standardowych godzinach 17:00-19:00 (z możliwością przedłużenia). Jak zwykle spotykamy się w siedzibie firmy Anica System S.A. Tym razem planujemy dwie sesje tematyczne - jedną z obszaru optymalizacji zapytań (Sebastiana) i drugą, stanowiącą wstęp do tematyki data miningu (Bartka). Na spotkaniu zostaną także przeglądowa zaprezentowane produkty jednego z naszych sponsorów (RedGate Software), a zasłużonym uczestnikom grupy (przede wszystkim prelegentom) zostaną rozdane nagrody nadesłane przez Microsoft i firmę RedGate (książki i różnego rodzaju gadżety - od koszulek po pendrivy). Wszystkich zainteresowanych serdecznie zapraszam, jednocześnie przypominając o konieczności każdorazowej rejestracji na spotkanie. Jak widać spotykamy się mniej więcej raz na miesiąc, więc nie jest to chyba dla nikogo specjalnie uciążliwe i tym bardziej namawiam do zaangażowania w działalność grupy. Zachęcam przede wszystkim do prowadzenia sesji, ale prosiłbym także o kontakt wszystkich chętnych, którzy chcą pomóc w organizacyjnej stronie przedsięwzięcia. Posiadanie olbrzymiej wiedzy nie jest wcale wymagane, aby zaistnieć na grupie.

Agenda spotkania:
17:00-17:15 - Kwestie organizacyjne (Marcin Guzowski)
17:15-18:05 - Dobry plan to podstawa - plan forcing, plan guides, parametryzacja (Sebastian Bratko)
18:05-18:15 - Produkty RedGate (Marcin Guzowski)
18:15-19:00 - Wprowadzenie do data miningu (Bartosz Matosiuk)

Więcej informacji:
Strona informacyjna PLSSUG Lublin
PLSSUG Lublin: Rejestracja na spotkanie