Monthly Archives: Styczeń 2012

Porada na temat SSIS

Właśnie ukazała się porada mojego autorstwa na temat konfiguracji usług integracyjnych dla instancji nazwanej SQL Server.

Jeżeli ktoś z was miał problem ze skonfigurowaniem SSIS-a w sposób pozwalający na przechowywanie paczek po stronie serwera, to zapraszam do lektury dostępnej na portalu wss.pl  🙂

Reklamy

Ilość VLF a wydajność SQL Server cz. 1

Jakiś czas temu na forum portalu wss.pl padło pytanie o optymalny rozmiar VLF (Virtual Log File). Niestety, z uwagi na to, że każde środowisko bazodanowe jest inne, to nie ma uniwersalnej odpowiedzi na tego typu pytanie. W kolejnych wpisach mojego blogu chciałbym pokazać czym są pliki VLF,  jakie czynniki należy wziąć pod uwagę dobierając wielkość wirtualnych plików logu do potrzeb konkretnej bazy oraz w jaki sposób sprawić by nasz log transakcyjny spełniał oczekiwania wydajnościowe.

Czym jest Virtual Log File?

Każda baza danych zarządzana przez SQL Server musi mieć przynajmniej jeden plik, na którym przechowywany jest jej log transakcyjny. Wewnętrzna struktura tego pliku jest podzielona na logicznie części, które noszą nazwę VLF (Virtual Log File).

Dzięki takiemu podziałowi SQL Server może wydajnie zarządzać logiem transakcyjnym bazy. Jedynym warunkiem jest odpowiedni dobór wielkości VLF 🙂

Jak sprawdzić ile mamy VLF-ów?

W tym celu powinniśmy posłużyć się nieudokumentowaną instrukcją DBCC LOGINFO, której jako parametr możemy podać nazwę interesującej nas bazy:

DBCC LOGINFO ('tempdb')

Na przedstawionym powyżej zrzucie ekranu można zobaczyć, że log transakcyjny wybranej bazy ma 8 VLF-ów, z czego każdy ma wielkość około 32MB.

Czas na test:  wstawianie dużych ilości danych 

Najlepszym sposobem aby zobrazować jaką różnicę wydajnościową można uzyskać dobierając odpowiednia ilość/wielkość VLF-ów jest przeprowadzenie odpowiednich testów. Do tego celu może nadać się dowolna operacja generująca znaczną ilość wpisów w dzienniku transakcji, np. duży INSERT.

Na potrzeby testu stworzyłem dwie bazy danych (testA i testB). Obie mają zadeklarowaną tę samą wielkość pliku baz (2500MB) oraz logu transakcyjnego (6000MB). Jedyną różnicą miedzy tymi nimi jest ilość VLF-ów, z którego składa się ich dziennik transakcji. TestA ma 24000 VLF-ów po około 250KB każdy, zaś testB 16 VLF po około 375MB.

Na początek wykonajmy kilkukrotnie zapytanie testowe:

-- niech dane do zapisu będą w buforze
SELECT m1.*
FROM sys.messages m1
CROSS JOIN (SELECT TOP 10 * FROM sys.messages) m2
GO 10

Różnicę w wydajności sprawdzimy wstawiając jego wynik do tabel w obu bazach danych:

-- sprawdzamy czas wykonania instrukcji przy małych VLF-ach
SET STATISTICS TIME ON

SELECT m1.*
INTO testA.dbo.tblMessages
FROM sys.messages m1
CROSS JOIN (SELECT TOP 10 * FROM sys.messages) m2

Dla bazy z małymi VLF-ami czas wykonania wynosi 13,731 sekundy. Zobaczmy jak poradzi sobie serwer przy insercie do drugiej bazy:

-- sprawdzamy czas wykonania instrukcji przy dużych VLF-ach
SET STATISTICS TIME ON

SELECT m1.*
INTO testB.dbo.tblMessages
FROM sys.messages m1
CROSS JOIN (SELECT TOP 10 * FROM sys.messages) m2

Gdy tę samą instrukcję wykonaliśmy zapisując dane do bazy o większych VLF-ach, to czas wykonania wsadu skrócił się do 12,732 sek. dając tym samym zysk wydajnościowy około 7 procent.

Podsumowanie

Ilość plików VLF wewnątrz logu transakcyjnego ma znaczenie wydajnościowe. Większe pliki wirtualne dziennika transakcji pozwalają na szybsze wykonanie operacji zapisujących, kasujących lub zmieniających dane.  Zanim jednak podejmiemy decyzję co do wielkości VLF-ów naszych baz produkcyjnych przeanalizujmy jakie wady niesie ze sobą zwiększenie ich rozmiaru:

Ilość VLF a wydajność SQL Server cz. 2

Rozwiązywanie referencji kolumn w usługach integracyjnych SQL Server 2012

W przeciągu ostatnich kilku dni zacząłem odkrywać nowości w usługach integracyjnych SQL Server Denali.  Jedną z nich jest rozwiązywanie referencji kolumn podczas projektowania paczki SSIS. Z uwagi na to, że funkcjonalność ta jest o wiele przyjemniejsza w użyciu niż rozwiązania dostępne we wcześniejszych wersjach tego produktu, to stwierdziłem, że dobrym pomysłem jest opisanie jej na moim blogu 🙂

Najpierw przykładowy problem

Załóżmy, że stworzyliśmy prostą paczkę SSIS. Jej zadaniem jest pobranie danych z jednej tabeli, dokonanie transformacji i zapis danych do miejsca docelowego. Data Flow takiej paczki mógłby wyglądać następująco:

Jedna z niedogodności związanych z tworzeniem tego typu rozwiązania jest to, że gdy zechcemy zmienić tabelę źródłową, to niestety możemy otrzymać informacje o błędach podczas przepływu danych:

Jeżeli zbadamy przyczynę problemu, to w stworzonej przeze mnie paczce okaże się, że jedna z kolumn nie jest „zamapowana”. Stało się tak ponieważ w nowo wybranej tabeli nie ma kolumny o nazwie „a”.

A teraz rozwiązanie 🙂

Jeżeli używamy SQL Server 2012 (a w szczególności BIDS-a związanego z tą bazą danych) to najprostszym rozwiązaniem jest wybranie ścieżki danych przy której wystąpił pierwszy z wyświetlanych błędów, kliknięcie prawym przyciskiem w celu rozwinięcia menu kontekstowego i posłużenie się nową opcją o nazwie „Resolve References”.

Dzięki temu zabiegowi zostaniemy przeniesieni do nowego okna, w którym można dopasować kolumny obu komponentów, a tym samym pozbyć się błędów.

Okno kreatora jest bardzo przejrzyste. Z jego lewej strony mamy niedopasowane kolumny z naszego wyjścia, a z prawej wejścia kolejnego komponentu SSIS (w naszym przypadku transformacji typu DERIVED COLUMN). Za pomocą mechanizmu DRAG AND DROP dopasowujemy je przenosząc do części o nazwie „Mapped Columns”, po czym zatwierdzamy wszystko przyciskiem OK. Okno ze stworzonym dopasowaniem przedstawiam poniżej:

Dzięki temu zabiegowi wszelkie błędy związane z brakiem odpowiedniej kolumny zostały zniwelowane, paczka daje się zbudować oraz działa według naszych zamierzeń 🙂

Podsumowanie

Jednym z udogodnień, na jakie możemy się natknąć używając Business Intelligence Development Studio w wersji SQL Server 2012 jest rozwiązywanie referencji kolumn. Na pewno wiele osób tworzących paczki SSIS ucieszy się z tej funkcjonalności, gdyż w fazie developerskiej zmiany w danych wejściowych są dość częste. Opcja RESOLVE REFERENCES pozwoli oszczędzić nie tylko czas, ale i także (przede wszystkim) palec klikającego po BIDS programisty 🙂

Nowy artykuł na wss.pl – tym razem o uprawnieniach w AD

W dniu dzisiejszym na portalu wss.pl ukazał się drugi artykuł mojego autorstwa 🙂

Tym razem opisałem problem nadawania uprawnień dla wielu użytkowników ACTIVE DIRECTORY do zainstalowanej instancji SQL Server. Jeżeli chcielibyście się dowiedzieć jak można zmierzyć się z tego typu sytuacją, zapraszam do lektury:

Ustawienie dostępu do SQL Server dla wielu użytkowników AD