SQL Server Standard 64bit - czy dziś znów się wyłoży?

Załóżmy, że spotykam na ulicy zwykłego człowieka i zadaję mu pytanie:

Dzień dobry. Otóż albowiem mam 2 samochody marki TheHighestLevelOfReliability. W ciągu ostatnich 2-3 tygodni jeden zepsuł mi się raz, a drugi - dwa razy. Jeździmy tymi samochodami po Saharze, przyłączy się Pan(i)?

To jakiej odpowiedzi mogę się spodziewać? Wszystkich, którzy zakładają odpowiedź twierdzącą zapraszam na przejażdżkę :) i przypominam o zabraniu ze sobą kremu z filtrem, dobrej książki i czarnego foliowego worka dostosowanego do rozmiarów ciała.

Natomiast pozostałym chciałbym zadać jeszcze jedno pytanie. Czy następujące zdanie znajdujące się na stronach http://microsoft.com/sqlserver:

SQL Server 2008 provides the highest levels of security, reliability, and scalability for your business-critical applications.

należy uznać za prawdziwe, skoro wymieniony SQL Server 2008 (konkretnie SQL Server 2008 64bit Standard Edition, ale też SQL Server 2005 64bit Standard Edition) może w praktycznie dowolnym momencie przestać odpowiadać, zablokować serwer, na którym pracuje i czasem nawet nie dać się zrestartować? To retoryczne i nie pozbawione ironii pytanie jest wstępem do tego, co chciałem napisać o ostatnich wydarzeniach związanych z utratą mojego zaufania do stabilności systemu SQL Server.

Na początek małe case study:

W godzinach wieczornych jeden z systemów masowego przetwarzania danych zaczął rozsyłać powiadomienia (SMS, mail) o problemach. Jako że system ten pracuje w architekturze rozproszonej na 9 nodach, a każdy z nich miał bardzo niepokojące informacje, którymi chciał się pochwalić, to na komórkach i skrzynkach pocztowych kilku osób znalazł się pokaźny ładunek informacji dających się podsumować statusem NIC_NIE_DZIAŁA. Jedną z tych osób, byłem ja, gdyż odpowiadam za produkcję tego systemu. Pomyślałem sobie wtedy, że jak dostałem 60 SMSów, że niby jest problem, to może rzeczywiście warto to&owo sprawdzić. Zalogowałem się więc przez RDP na serwer, na którym pracuje baza danych SQL Server 2008 64bit Standard, z której to bazy korzysta głównie nod centralny oraz czasami pozostałe nody w miarę potrzeby. "Zalogowałem się" to trochę za szybkie słowo jak na określenie tego, co rzeczywiście miało miejsce, gdyż owo logowanie zajęło niewiele mniej niż 2 minuty. Kolejną minutę "klikał" mi się windowsowy guzik Start. Po kilku (dłuższych) chwilach udało mi się ustalić, że proces sqlsrvr.exe zaalokował sobie 15,2 GB pamięci wirtualnej. Serwer posiadał natomiast tylko 8 GB RAMu.



Co się więc stało z brakującymi GB? Otóż poleciały do pliku stron na dysk, zapewne razem z innymi stronami zaalokowanymi przez pozostałe aplikacje czy moduły systemu operacyjnego działające na serwerze. Ciągłe obciążenie IO na bardzo wysokim poziomie i kompletny brak wolnej przestrzeni w RAMie spowodował, że nawet nie należąca do najsłabszych maszyna (2 4-korowe procesory 2 GHz, 8 GB RAM) o mało co nie wyzionęła ducha. SQL Server oczywiście przestał reagować na cokolwiek - ani nie można się było do niego zalogować (nawet przez DAC), ani restart usługi się nie powiódł. Pozostało więc tylko ubicie procesu, po którym oczywiście wszystko wróciło do normy.

A propos case study, z tego co pamiętam ostatnio Mariusz Kędziora z MS zachęcał we wpisie na łamach swojego bloga do nadsyłania wrażeń z wdrożeń technologii Microsoft. Ciekawe czy opublikowałby moje case study... W razie czego, to mam jeszcze kilka podobnych.

Clue problemu polega na tym, że w pewnym warunkach SQL Server potrafi wykończyć zarówno siebie, jak i wszystko na tym samym serwerze. Jak już sygnalizowałem na początku posta, opisywana sytuacja nie jest odosobniona i występowała w przeciągu ostatnich kilku tygodni także na innym serwerze.

W czym rzecz z technicznego punktu widzenia? W tym, że cywilizowany silnik bazodanowy nie powinien dopuszczać, żeby jego buffer pool został zestronicowany na dysk. Nawet jeśli założymy, że część stron może trafić na dysk, to i tak nie może to powodować wyżej opisanych problemów. Najciekawsze jest to, że znane jest zabezpieczenie przez omawianymi problemami. Zaimplementował je także Microsoft. Lock pages in memory - bo o nie chodzi, dostępne jest jednak wyłącznie w wersji Enterprise (sic!)... Wersja Standard ignoruje to ustawienie i w określonych warunkach obciążeniowych dochodzi do opisywanych przeze mnie skutków. Problem omówił m.in. Paweł Potasiński we wpisie na swoim blogu. Dla mnie sytuacja wygląda następująco: idę do sklepu i chę kupić krzesło. Sprzedawca mówi mi, że krzesło kosztuje 100zł. Dokonuję zakupu, po czym przy pierwszej próbie skorzystania z niego spadam na podłogę. Okazuje się że w momencie siadania krzesło składa się jak domek z kart. Wracam do sklepu z pozdrowieniami na ustach, a sprzedawca mi mówi:

A nie nie, to jak chce Pan na nim siedzieć, to o tu jest wersja DELUXE za 1000zł, zapakować?

Co na to wszystko Microsoft? Raz już odmówił dodania stosownej obsługi do wersji Standard. Teraz trwa kolejna batalia o tą funkcjonalność, prowadzona m.in. przez Maćka Pileckiego:

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=422322

Zastanawiam się cały czas, jak w ogóle można wypuszczać na rynek upośledzoną wersję systemu i jeszcze odmawiać naprawy problemu. Dla mnie sytuacja jest nieakceptowalna. Mamy tutaj do czynienia z błędem, który godzi w stabilność produktu, a nie z żadną enterprisową funkcjonalnością, za którą powinno się płacić kilka razy więcej.