Zamieszczone przez Marcin Guzowski

Nie od dziś wiadomo, że SQL Server dostarcza sporej liczby niesupportowanych i nieudokumentowanych procedur, funkcji czy komend DBCC. Najnowsza wersja, a konkretnie CTP6, nie odbiega od tej praktyki. Jedną z ciekawszych funkcjonalności tego typu, którą chciałbym zaprezentować, jest %%physloc%%. Jest to specjalna właściwość systemowa (nazywana także wirtualną kolumną), zwracająca wartość typu binary(8), która działa wyłącznie w kontekście wiersza. Przy jej pomocy uzyskujemy tzw. physical row locator, czyli binarnie zapisany RID rekordu:

CREATE TABLE test
(
col int DEFAULT(0)
);

INSERT INTO test DEFAULT VALUES;

SELECT %%physloc%%, col FROM test;

Dostępne są także dwie nieudokumentowane funkcje - sys.fn_PhysLocFormatter i sys.fn_PhysLocCracker, które konwertują %%physloc%% na klasyczny RID. Różnica między wymienionymi funkcjami polega wyłącznie na tym, że pierwsza zwraca wartość skalarną, a druga - jako table valued function - tabelę (konkretnie - jeden rekord). W dalszych rozważaniach skupie się na pierwszej funkcji.

Fizyczny lokalizator nie jest najbardziej widowiskową funkcjonalnością produkcyjną, ale w głowie prawdziwego SQL developera lub DBA na pewno pojawi się cały szereg pomysłowych jego zastosowań, zwłaszcza podczas zgłębiania tajników storage engine'u, performance testów, czy zabaw z sortowaniem rekordów. Oczywiście nie ma gwarancji, że %%physloc%% będzie dostępny także w wersji RTM, ale na razie wszystko na to wskazuje. Funkcję sys.fn_PhysLocFormatter wywołujemy w następujący sposób:

SELECT %
%physloc%% as PhysicalLocator,
sys.fn_PhysLocFormatter(%%physloc%%) as RID
FROM test;

Powyższe zapytanie zwraca:


Dla przypomnienia: RID to numer składający się z 3 liczb całkowitych (file_id, page_id, slot_id).

Do czego można wykorzystać powyższą funkcję? Choćby do udowodnienia, że tabela tymczasowa jest serializowana na dysk. Dowód opiera się oczywiście na głęboko prawdziwym założeniu, że jeśli coś ma RID, to musi istnieć w pliku bazy danych. Poniższy skrypt tworzy tabelę tymczasową, napełnia ją jednym rekordem, a następnie zwraca RID wiersza:

CREATE TABLE #test
(
col int DEFAULT(0)
);

INSERT INTO #test DEFAULT VALUES;

SELECT sys.fn_PhysLocFormatter(%%physloc%%) FROM #test;

DROP TABLE #test;

Trzeba tylko pamiętać, że zwracana wartość, np. (1:206:0) dotyczy bazy tempdb, nawet jeśli skrypt został wywołany w kontekście innej bazy.

Świat IT rządzi się rozmaitymi prawami i zależnościami. Jedna z najbardziej podstawowych zasad mówi, że spośród trzech cech - szybko, tanio, dobrze - można wybrać jedynie dwie, które łącznie staną się przeciwieństwem trzeciej. Określamy to mianem prawa dwóch trzecich, które da się wizualizować w następujący sposób:

Tak więc:
1. Dobrze i tanio nie znaczy szybko.
2. Dobrze i szybko nie znaczy tanio.
3. Szybko i tanio nie znaczy dobrze.

Managerom pozostaje tylko wybór jednej z powyższych opcji.

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