Denali CTP 1 – co nowego nie tylko dla deweloperów – cz. 1

Udostępnij na: Facebook

Autor: Damian Widera, Łukasz Grala

Opublikowano: 2010-11-22

Wstęp

Na początku listopada, podczas konferencji PASS 2010, ogłoszono pierwszą publiczną wersję SQL Server „Denali” CTP 1. Jest to nietypowa sytuacja, ponieważ nigdy przedtem tak wczesna wersja serwera nie została przedstawiona szerszemu gronu. Dla przypomnienia – SQL Server 2008 został zaprezentowany publicznie od wersji CTP 3.

W niniejszym artykule chcemy pokazać nowości związane z T-SQL, które zostały udostępnione w listopadowej wersji SQL Server „Denali”. Nie ma oczywiście gwarancji, że obecnie istniejąca składnia nie ulegnie zmianie lub nawet nie zostanie wycofana. Warto jednak śledzić już teraz pojawiające się nowości, ponieważ znaczna ich część na pewno będzie dostępna w finalnej wersji produktu.

Co nowego w TSQL, czyli pierwszy rzut oka na Denali

SQL Server „Denali” oferuje nowości na wielu płaszczyznach. Nie dotyczą one tylko i wyłącznie języka TSQL, ale nimi postanowiliśmy zająć się w pierwszej kolejności.  Kolejne części artykułu będą poświęcone nowemu spojrzeniu na BI, w tym nowemu rozwiązaniu zaimplementowanemu w usługach analitycznych, które jest znane i wykorzystywane we wcześniejszej wersji systemu – VertiPaq. Będzie też okazja zaprezentować znaczne ułatwienia w budowaniu rozwiązań wysokiej dostępności, które są oferowane w CTP1.  Na początek spójrzmy do konsoli PowerShell.

Konsola PowerShell

Uruchamiając konsolę PowerShell i listując obiekty dostępne z poziomu SQL Server, można stwierdzić, że dodano dwa główne katalogi:

  • XEvents, czyli możliwość programowania mechanizmu rozszerzonych zdarzeń, których liczba wynosi teraz 450 (zamiast 254 w poprzedniej wersji systemu, w tym wszystkie zdarzenia dostępne w SQL Server Profiler),
  • Intergation Services, czyli możliwość zarządzania usługą za pomocą skryptów.

Rys.  1. Konsola PowerShell.

Mechanizm XEvents jest znany deweloperom i administratorom od wersji SQL Server 2008, jednakże wtedy można było korzystać z niego tylko za pomocą języka T-SQL. Używając konsoli PowerShell, można wylistować zawartość katalogu XEvents, jak pokazano na rysunku 2:

Rys.  2. Zawartość katalogu XEvents.

Wykonując proste operacje, można dowiedzieć się, jak jest skonstruowana domyślna sesja SQL Server „Denali”, która zbiera informacje diagnostyczne o stanie serwera. Informacje te można wykorzystać np. w sytuacji kontaktu z obsługą klienta, ponieważ informacje przechowywane w tej sesji zostały tak dobrane, aby ułatwić wstępną diagnozę serwera:

Rys.  3. Konfiguracja domyślne sesji System_Health.

W celu odnalezienia zdarzeń związanych z SQL Server Profiler należy przejść do paczki sql_server i odczytać jej zawartość. W obecnej chwili funkcjonalność XEvents nie jest dobrze udokumentowana i należy samodzielnie zaznajomić się z możliwościami oferowanymi w konsoli PowerShell.

Instrukcja THROW

Wcześniejsze wersje SQL Server nie dają programistom możliwości wyrzucenia wyjątku po przejściu określonego punktu kodu. Do dyspozycji była (i nadal obowiązuje) składnia TRY-CATCH, jednak zastosowanie nowej instrukcji THROW otwiera zupełnie inne możliwości sterowania przepływem kodu aplikacji. Wywołując poniższy kod z instrukcją THROW, można:

  • wywołać określony wyjątek w kodzie TSQL,
  • wpisać komentarz błędu,
  • określić parametr State.

Rys.  4. Przykład użycia instrukcji THROW.

Instrukcja THROW może być również odpowiednio sformatowana, co pozwala na zachowanie odpowiedniej czystości i przejrzystości kodu aplikacji. Formatowanie to odbywa się tak, jak to miało miejsce dotychczas – czyli należy zdefiniować własny komentarz błędu i zapisać go za pomocą  procedury składowanej sp_addmessage:

Use tempdb go sp_addmessage @msgnum = 52501, @severity = 16, @msgtext = N'To jest tekst bledu'; DECLARE @msg NVARCHAR(200); SELECT @msg = FORMATMESSAGE(52501,'format'); THROW 52501, @msg,1

Najciekawszym użyciem instrukcji THROW jest jednak możliwość zgłaszania wyjątków bez konieczności budowania własnego łańcucha znaków zawierającego informację o wyjątku. Rozważmy zatem poniższy fragment kodu:

use tempdb go CREATE TABLE PK_VIOLATION (                 ID INT NOT NULL PRIMARY KEY CLUSTERED ); GO CREATE PROCEDURE PKFAIL AS BEGIN                 BEGIN TRY                                 INSERT INTO PK_VIOLATION VALUES (1);                                 INSERT INTO PK_VIOLATION VALUES (1);                 END TRY                 BEGIN CATCH                                 THROW;                 END CATCH END GO EXEC PKFAIL;

W pierwszym kroku utworzona zostaje tabela zawierająca jedno pole będące kluczem głównym. Następnie w procedurze składowanej PKFAIL zostaje umieszczony kod, który narusza ograniczenie wynikające z zastosowania klucza głównego – podczas uruchomienia procedury zostanie wykonana akcja wstawienia dwóch rekordów o identycznym kluczu głównym do tabeli. Kod aplikacji zostanie wtedy przeniesiony do bloku CATCH, gdzie znajduje się instrukcja THROW, której zadaniem jest wyrzucenie odpowiedniego wyjątku. Wyjątek ten nie jest formatowany w żaden sposób w powyższym kodzie, a jednak informacje przekazywane do aplikacji są poprawnie wyświetlone (rysunek 5).

Rys.  5. Wynik wyrzucenia wyjątku instrukcją THROW.

Uwaga – przed użyciem instrukcji THROW należy wcześniejszą komendę zakończyć średnikiem (;).