mechanizmy wewnętrzne baz danych – czyli co w bazach „piszczy”

Mechanizmy wewntrzne baz danych czyli co w bazach piszczyNa przykadzie SQL Server 2008*informatyka +

informatyka +

AgendaWizy integralnoci referencyjnejTransakcjePoziomy izolacji transakcjiWyzwalaczeRodzaje wyzwalaczyProcedury skadowane i funkcje uytkownikaIndeksyFizyczna organizacja danych w SQL Server 2008Rodzaje indeksw (zgrupowane, niezgrupowane) Optymalizacja zapyta i plany wykonaniaKopie bezpieczestwa i odtwarzanie danychPodsumowanie

*informatyka +

Wizy integralnoci referencyjnej W bazach danych czsto wystpuje konieczno zdefiniowana relacji pomidzy dwoma tabelami np.: klient jest wacicielem rachunku bankowego rachunek jest okrelonego typu (oszczdnociowy, rozliczeniowy)Do tego celu su wizy integralnoci referencyjnej Chcemy powiza klienta z rachunkiem bankowym:

Wymaganie: Rachunek ma dokadnie jednego waciciela.*informatyka +

Wizy integralnoci referencyjnejDodajmy kilku klientw i zobaczmy ich dane:

Rezultat:

Mamy troje klientw o identyfikatorach 1, 2 i 3.*informatyka +

Wizy integralnoci referencyjnejDodajmy teraz kilka rachunkw i zobaczmy ich dane:

Rezultat:

Rachunki zostay utworzone (automatycznie nadane numery i daty utworzenia)Mamy cztery rachunki. Trzy nale do naszych klientw.Czwarty rachunek nie wiadomo do kogo! Utracilimy wanie spjno danych :-(*informatyka +

Wizy integralnoci referencyjnejJak zabezpieczy si przed tego typu bdami?Klucz obcy kolumna lub kombinacja kolumn, ktra jest uywana do okrelenia i wymuszenia relacji pomidzy danymi z dwch tabel

*informatyka +

Wizy integralnoci referencyjnejSprbujmy wic utworzy klucz obcy na naszej tabeli rachunki:

Nic z tego! Nie udao si utworzy ograniczenia ze wzgldu na istniejce dane (feralny rachunek z bdnym identyfikatorem waciciela)Rezultat:Msg 547, Level 16, State 0, Line 1The ALTER TABLE statement conflicted with the FOREIGN KEY constraint "FK_Rachunki_Klienci". The conflict occurred in database "Bank", table "dbo.Klienci", column 'KlientID'.Jak to naprawi? Opcja WITH NOCHECK lub poprawienie bdnych danych.*informatyka +

Wizy integralnoci referencyjnejNaprawiamy bdne dane:

Ponowne wykonanie polecenia tworzcego klucz obcy koczy si sukcesem! Od tej pory baza nie pozwoli na utworzenie rachunku dla nieistniejcego klienta:

Rezultat:Msg 547, Level 16, State 0, Line 1The INSERT statement conflicted with the FOREIGN KEY constraint "FK_Rachunki_Klienci". The conflict occurred in database "Bank", table "dbo.Klienci", column 'KlientID'.*informatyka +

Wizy integralnoci referencyjnejNie ma natomiast problemu z dodaniem rachunku dla istniejcego klienta:

Rezultat:*informatyka +

Wizy integralnoci referencyjnejPrzy tworzeniu klucza obcego mona korzysta z opcji ON DELETE i ON UPDATE.Su one do okrelenia reakcji na usunicie lub zmodyfikowanie wiersza (z tabeli z kluczem podstawowym) do ktrego odnosi si klucz obcy. Isniej cztery warianty dla kadej :No action (domylna)Nie podejmuje adnej akcji.CascadeUsuwa/modyfikuje wiersz z kluczem obcymSet nullUstawia warto null jako warto kolumn klucza obcego (dziaa jeeli te kolumny dopuszczaj warto null!)Set defaultUstawia warto domyln dla kolumn klucza obcego (dziaa jeli te kolumny maja okrelona warto domyln i spenia ona regu klucza lub dopuszcza warto null.*informatyka +UWAGA! Bardzo wygodne i bardzo niebezpiecznie!!!

Wizy integralnoci referencyjnejUsumy nasz klucz obcy i stwrzmy go na nowo z opcj ON DELETE CASCADE:

Usumy teraz jednego klienta (posiadajcego dwa rachunki):

Pobranie listy wszystkich rachunkw daje teraz rezultat:

Usunlimy jeden wiersz z tabeli Klienci, a automatycznie zostay usunite dwa rachunki nalece do usunitego klientaTa opcja jest bardzo niebezpieczna!!!

*informatyka +

Wizy integralnoci referencyjnejGar faktw na temat kluczy obcych:Klucz obcy moe zawiera wicej ni jedna kolumnUwaga! Jeli w takim przypadku cho jedna z kolumn ma warto null, to pozostae nie s sprawdzane pod ktem zgodnoci z regu klucza!Klucz obcy moe odwoywa si do tej samej tabeli (samozczenie)Stosowane do budowania hierarchiiatwe w implementacji, trudne w obsudzeAlternatyw jest typ danych HierarchyID lub XML.Klucz obcy (podobnie jak ograniczenia typu CHECK) mona wcza i wycza za pomoc polecenia ALTER TABLE z opcj CHECK lub NOCHECK CONSTRAINT. [nie myli z WITH CHECK/ WITH NOCHECK !]*informatyka +


*informatyka +

TransakcjeDane w bazie reprezentuj aktualn sytuacj biznesowMog zawiera dane o zamwieniach, informacje o procesie produkcyjnym, o alokacji okrelonych zasobw i ich statusie itd., itp..Zmiany sytuacji biznesowej (stanu) powoduj zmiany w danych w baziePojawiaj si nowe wiersze, modyfikowane s istniejce, zdarzaj si te usunicia wierszy.Zmiana stanu powinna prowadzi od jednego stabilnego stanu do drugiegoWszelkie stany przejciowe spowodowane dowolnym czynnikiem s niedopuszczalne!Zapisanie tylko czci zamwienia???Przelew bankowy wykonany poowicznie (rodki pobrane, ale nie umieszczone na docelowym rachunku) ???*informatyka +

TransakcjeTransakcja to sekwencja logicznie powizanych operacji na danych, ktrych celem jest przejcie bazy danych z jednego stanu spjnego do drugiegoWaciwoci transakcji akronim ACIDAtomicity (atomowo)Operacje w ramach transakcji s niepodzielne. Albo wykonaj si w caoci, albo wcaleConsistency (spjno)Baza danych jest w stanie spjnym zarwno przed rozpoczciem transakcji jak i po jej zakoczeniu (niewane czy transakcja zakoczya si sukcesem czy porak)Isolation (odizolowanie)Transakcje s od siebie logicznie odseparowane. Z punktu widzenia transakcji wykonywane sekwencyjnieDurability (trwaoc)Jeeli transakcja zostaa zatwierdzona, to niezalenie od awarii systemu nie moe zosta cofnita bd utracona

*informatyka +

TransakcjeSkoro to takie wane, to czy nie wystarczy kolejkowanie transakcji i sekwencyjnie ich wykonywanie?Nie. To kwestia wydajnoci! Takie podejcie powodowaoby drastyczny spadek wydajnoci wraz ze wzrostem liczby transakcji (uytkownikw)Zalenie od specyfiki operacji wykonywanych w ramach transakcji mona stara si zrwnolegla wykonywanie innych transakcji i operacji odczytu danych.Moliwoci zrwnoleglania operacji sterowane s poprzez mechanizm blokad (locks). Pojcie poziomu izolacji odnosi si wanie do tego zagadnienia - jakie blokady i na jaki czas s konieczne, eby zapewni odpowiedni poziom bezpieczestwa dla transakcji.*informatyka +

TransakcjeSQL Server obsuguje dwa tryby rozpoczynania transakcji:Jawny (explicit)Transakcja rozpoczyna si poleceniem BEGIN TRANSACTIONNiejawny (implicit)Kade pierwsze polecenie modyfikujce dane( m.in. INSERT, UPDATE, DELETE) powoduje rozpoczcie transakcjiTransakcj naley zakoczy jawnie (COMMIT lub ROLLBACK)Wycza tryb autocommit!Domylnie SQL Server dziaa w trybie autocommitKade polecenie modyfikujce dane (m.in. INSERT, UPDATE, DELETE) powoduje rozpoczcie transakcji.Poprawne wykonanie polecenia powoduje automatyczne zatwierdzenie (COMMIT) transakcji.Bd w trakcie wykonania polecenia powoduje automatyczne wycofanie (ROLLBACK) transakcji

*informatyka +

TransakcjeTransakcje mog by zagniedane:

UWAGA!COMMIT dla transakcji zagniedonej tak naprawd nie ma adnego efektu jedynie zmniejsza poziom zagniedenia.ROLLBACK powoduje wycofanie wszystkich transakcji cznie z gwn (zawierajc zagniedone pozostae). Ustawia poziom zagniedenia na 0ROLLBACK z parametrem (nazwa punktu zapisu) wycofuje transakcje do tego punktu. Nie powoduje zmiany poziomu zagniedenia.

*informatyka +

TransakcjeAktualny poziom zagniedenia transakcji mona odczyta ze zmiennej @@TRANCOUNTRozpoczynajc transakcje mona nada jej nazw. W trakcie transakcji mona tworzy za pomoc polecenia SAVE dodatkowe punkty zapisu (savepoint), do ktrych bdzie mona wycofywa czciowo transakcj przez wywoanie polecenia ROLLBACK z parametrem nazw punktu zapisu.

*informatyka +


*informatyka +

TransakcjeKonflikty i problemy wystpujce przy dostpie do danych poziomu wicej ni jednej transakcji (w przykadach s to transakcje T1 i T2):

Lost update (zgubiona modyfikacja)T1 i T2 modyfikuj warto kolumny jedna po drugiej. Tylko ostatnia modyfikacja (zatwierdzona transakcja) bdzie widoczna w bazie.Dirty read (brudny odczyt) T1 modyfikuje dane. Przed jej zatwierdzeniem, T2 odczytuje zmodyfikowane dane i wykorzystuje je. Jeli T1 zostanie wycofana to T2 pracuje na niepoprawnych lub nieistniejcych danych niespjno!*informatyka +

TransakcjeKonflikty i problemy wystpujce przy dostpie do danych poziomu wicej ni jednej transakcji ( w przykadach s to transakcje T1 i T2):

Nonrepeatable Read (niepowtarzalny odczyt)T1 odczytuje te same dane dwukrotnie w trakcie dziaania. Pomidzy jednym a drugim odczytem T2 modyfikuje te dane i zostaje zatwierdzona. W zwizku z tym drugi odczyt danych z poziomu T1 pobiera inne wartoci ni pierwszy! Moe to prowadzi do niespjnoci.Phantom reads (odczyt widmo) T1 modyfikuje dane z okrelonego zakresu i nastpnie pobiera je do dalszej analizy. Pomidzy modyfikacj a odczytem, T2 dodaje nowe wiersze do modyfikowanego przez T1 zakresu. T1 odczytuje dane i uzyskuje wiersze, ktrych nie byo przy modyfikacji.*informatyka +

TransakcjeStandard ANSI definiuje cztery poziomy izolacji dla transakcji. Kady z nich cechuje si eliminowaniem szans na wystpienie kolejnego rodzaju konfliktu: [poziom domylny zosta wyrniony]

SQL Server posiada dwa dodatkowe poziomy izolacji (bazujce na wersjonowaniu wierszy): jeden jest implementacj poziomu READ COMMITED, drugi to poziom SNAPSHOT (funkcjonalnie zbliony do SERIALIZABLE)

*informatyka +

Poziom izolacjiDirty readNonrepeatable readPhantom readREAD UNCOMMITEDTAKTAKTAKREAD COMMITEDNIETAKTAKREPEATABLE READNIENIETAKSERIALIZABLENIENIENIE

TransakcjePrzy transakcjach warto wspomnie o jeszcze jednym negatywnym zjawisku zakleszczeniu.

*informatyka +Dwie osoby chc narysowa wykres. Potrzebne do tego s: linijka i kreda.Pierwsza osoba siga po kred, druga po linijkW efekcie pierwsza zaczyna czeka na linijk, druga na kredRozwizanie wylosowa osob (deadlock victim), zabra jej linijk lub kred i odda drugiej.

TransakcjeMinimalizowanie szansy na wystpienie zakleszczenia

Siganie do zasobw wg tej samej kolejnoci!

*informatyka +

TransakcjeKilka dobrych rad dotyczcych transakcjiStarajmy si budowa transakcje tak krtkie jak si da! Pozwala to skrci czas aktywnoci blokad i poprawi wydajnoPlanujmy kolejno uzyskiwania dostpu do zasobw w ramach transakcji aby unika zakleszczeMimo, i SQL Server daje nam moliwoci sterowania mechanizmem blokad jeli nie wiemy na 100% co robimy lepiej nie ingerowa w t dziedzin. Mechanizm ten sam z siebie dziaa bardzo dobrze.Dobierajmy waciwy poziom izolacji transakcji dla konkretnych operacji. Korzystanie ze zbyt wysokiego powoduje spadek wydajnoci

*informatyka +


*informatyka +

WyzwalaczeWyzwalacz to specjalny rodzaj procedury skadowanej, ktra jest wywoywana automatycznie w reakcji na zajcie okrelonego zdarzenia.Wyzwalacze to sztandarowy mechanizm pozwalajcy na implementowanie w bazie regu biznesowych i zapewnienie spjnoci danych w zakresie szerszym ni ograniczenia (constraints)SQL Server posiada mechanizm wyzwalaczy dla DML (Data Manipulation Language) oraz DDL (Data Definition Language)Korzystanie z wyzwalaczy jest przyjemne, ale musz by one dokadnie udokumentowane! W przeciwnym razie w przypadku wystpienia problemw z logik bazy bardzo trudno bdzie dociec rda problemu.

*informatyka +


*informatyka +

Wyzwalacze DMLWyzwalacze mog reagowa na zdarzenia: INSERT, UPDATE i DELETEDwa rodzaje wyzwalaczy: AFTER i INSTEAD OFWyzwalacze AFTER wykonuj si po operacji, ktra spowodowaa ich uruchomienie i wchodz w skad realizowanej transakcjiWyzwalacze INSTEAD OF wykonuj si zamiast wywoujcej je operacjiMona deklarowa wiele wyzwalaczy na tej samej tabeli, dla tego samego zdarzenia. UWAGA! W takiej sytuacji nie mamy zbyt duego wpywu na kolejno wykonania wyzwalaczy. Mona jedynie okreli, ktry wykona si jako pierwszy i jako ostatni.*informatyka +

Wyzwalacze DMLDodajmy do naszej bazy jeszcze jedn tabelBdzie ona przechowywa informacje o operacjach wykonywanych na rachunkuWykorzystamy wyzwalacze do zaimplementowania regu biznesowych:Nie mona usun ani zmodyfikowa raz wykonanej operacjiMinimalna kwota wypaty z rachunku musi by wiksza lub rwna 10 z

*informatyka +

Wyzwalacze DMLNa pierwszy ogie wemy blokad modyfikacji i usuwania wpisw w tabeli Operacje.Zrealizujemy to za pomoc wyzwalacza INSTEAD OF:

Dodajmy par wpisw:

Sprbujmy teraz usun operacj:

Rezultat:

*informatyka +

Wyzwalacze DMLNastpny krok to implementacja drugiej reguy biznesowej minimalna kwota wypaty musi by wiksza lub rwna 10 zZrealizujemy to za pomoc wyzwalacza AFTER:

Sprbujmy wykona wypat zbyt maej kwoty:

Rezultat:

*informatyka +Transakcja zostaa wycofana

Wyzwalacze DMLW kodzie wyzwalacza mamy dostp do dwch specjalnych tabel : inserted i deletedTabela inserted zawiera list dodawanych wierszy w ramach wykonywanego polecenia INSERTTabela deleted zawiera list wierszy usuwanych w ramach wykonywanego polecenia DELETEW przypadku wykonywania modyfikacji danych,(UPDATE) tabela inserted zawiera nowe wartoci wierszy, a deleted stare.Z tych tabel korzysta si przy tworzeniu kodu wyzwalaczy odwoujcego si do modyfikowanych danych.*informatyka +

Wyzwalacze DMLWane! Nie naley zakada, e wyzwalacz bdzie wywoywany zawsze dla modyfikacji pojedynczego wiersza!*informatyka +TAKNIE

Wyzwalacze DDLWraz z pojawieniem si SQL Servera 2005 pojawi si nowy rodzaj wyzwalacza wyzwalacz DDLWyzwalacze DDL mog reagowa na zdarzenia - wywoania polece DDL (CREATE, ALTER, DROP, GRANT, DENY, REVOKE, UPDATE STATISTICS )Przeznaczone do wspomagania audytu zmian w strukturze bazy danych i ledzenia jej zmianPozwalaj te ogranicza swobod modyfikowania struktury bazy danych lub tworzy mechanizmy zabezpieczajce przed przypadkow modyfikacjW kodzie wyzwalacza dostpna jest funkcja EVENTDATA() zwracajca szczegowe informacje o zdarzeniu w formie XML*informatyka +

Wyzwalacze DDLStwrzmy wyzwalacz DDL, ktry zablokuje wszelkie modyfikacje tabel oraz prby ich usunicia:

*informatyka +


*informatyka +

Procedury skadowane i funkcje uytkownikaProcedura skadowana przypomina funkcj (metod) znan z jzykw programowania:Zawiera blok kodu, ktry jest wykonywany po jej wywoaniu\Moe przyjmowa parametry wywoania (wejciowe oraz wyjciowe) a take zwraca warto (kod powrotu warto cakowita)W jej kodzie mona stosowa instrukcje warunkowe i ptlePozwala na odcicie aplikacji od szczegw implementacyjnych bazy danych tworzy warstw abstrakcji danychMona nadawa uprawnienia do jej wykonania

*informatyka +

Procedury skadowane i funkcje uytkownikaW naszej bankowej bazie danych moemy zastosowa procedur skadowan do utworzenia rachunku dla nowego klienta.Wymagania biznesowe: Klient podaje swj adres email oraz imi i nazwiskoZostaje dla niego utworzone konto. Otrzymuje jego numer.Klient dostaje na dzie dobry 100 z na swoje nowe kontoZrealizujemy te wymagania za pomoc procedury, ktra przyjmie na wejciu dane klienta.Numer nowootwartego rachunku zostanie zwrcony jako parametr wyjciowy*informatyka +

Procedury skadowane i funkcje uytkownikaPosta procedury zakadania promocyjnego konta:*informatyka +

Procedury skadowane i funkcje uytkownikaWywoanie procedury:

Rezultat:

Sukces! Wida trzy udane wykonania polecenia insert oraz wygenerowany numer rachunku*informatyka +

Procedury skadowane i funkcje uytkownikaFunkcje uytkownika s podobne do procedur skadowanychRni si tym, e ich wywoania mog by wykorzystane w charakterze wartoci w wyraeniach i zapytaniach.Funkcje wystpuj w dwch wariantach (zalenie od typu zwracanej wartoci):Skalarne (scalar functions)Tabelaryczne (mog skada si z jednego zapytania SELECT lub z wielu wyrae)Korzystanie z funkcji skalarnej : SELECT funkcja(parametr)Korzystanie z funkcji tabelarycznej: SELECT * FROM funkcja(parametr)

*informatyka +

Procedury skadowane i funkcje uytkownikaFunkcja obliczajca saldo wskazanego rachunku:

Wywoanie:

Rezultat:

*informatyka +

Procedury skadowane i funkcje uytkownikaFunkcja tabelaryczna (inline) zwracajca n ostatnich operacji wykonanych na rachunkach:

Wywoanie:

Rezultat:

*informatyka +

Procedury skadowane i funkcje uytkownikaTa sama funkcja zrealizowana jako multistatement

Wywoanie: Rezultat:

*informatyka +


*informatyka +

Fizyczna organizacja danych w SQL Server 2008Logicznie tabela skada si z wierszy, ktre skadaj si z kolumn.

Jak te dane przechowywane s na dysku?Jakie s ograniczenia przy definiowaniu tabel?Jaki ma to wpyw na wydajno?*informatyka +

Fizyczna organizacja danych w SQL Server 2008Podstawowa jednostka strona (page)Rozmiar: 8 KB (dokadnie 8060 bajtw na dane)Jest to jednoczenie maksymalna dugo wiersza (nie liczc kolumn przechowywanych na osobnych stronach)Wiersz nie moe by podzielony pomidzy strony.Rodzaje strondata (wszystkie dane z wyjtkiem kolumn typw: text, ntext, image, nvarchar(max), varchar(max), varbinary(max), xml ) index (wpisy indeksw)text/image (text, ntext, image, nvarchar(max), varchar(max), varbinary(max), xml oraz niemieszczce si w wierszu: varchar, nvarchar, varbinary)GAM, (Global Allocation Map) SGAM (Shared GAM), IAM (Index Allocation Map) wrcimy do nich!

*informatyka +

Nagwek Wiersz 1Wiersz 2Wiersz 3

Fizyczna organizacja danych w SQL Server 20088 KB (strona) to troch mao8 stron 64 KB to w sam raz na jednostk alokacji!Jednostka ta zwana jest obszarem (extent).Rodzaje obszarwJednolite (uniform extent)Zawieraj strony nalece do jednego obiektu ( tabeli /indeksu )Mieszane (mixed extent)Zawieraj strony nalece do wicej ni jednego obiektuAlokowane i odczytywane s zawsze cae obszary a nie pojedyncze strony*informatyka +









Fizyczna organizacja danych w SQL Server 2008Sterta (heap) zbir obszarw zawierajcych dane z jednej tabeli (lub partycji w przypadku tabel partycjonowanych)Dane nie s ze sob powizane w aden sposbWyszukiwanie wymaga przejrzenia wszystkich stron

*informatyka +

































Tabela Fizyczna organizacja danych w SQL Server 2008Tabela moe skada si z jednej lub wicej partycjiSterta jest tworzona osobno dla kadej partycji

*informatyka +Partycja 1Partycja 2Partycja 3

Fizyczna organizacja danych w SQL Server 2008Skd wiadomo ktre obszary s wolne, ktre s zajte, do ktrych obiektw nale obszary czy strony?Ze stron GAM, SGAM i IAM ;-)GAM (Global Allocation Map) informacje o zajtych obszarach jednolitych (uniform)SGAM (Shared GAM) - informacje o zajtych obszarach mieszanych (mixed)IAM (Index Allocation Map) informacje o przynalenoci obszarw do obiektw*informatyka +IAM

Fizyczna organizacja danych w SQL Server 2008No dobrze, ale jak trafi do odpowiedniej strony IAM?Kady obiekt (tabela / indeks) ma wpisy w tabelach systemowych dotyczce alokacji jego danychDostp do tych informacji widok sys.partitionsKada sterta, indeks, obszar LOB maj odpowiadajcy im wpis. Wpis ten zawiera wskanik do IAM Wartoc kolumny index_id:0 sterta1 indeks zgrupowany2..250 indeksy niezgrupowane255 dane LOB

*informatyka +

sys.partitionsidIndex_id=0IAM


*informatyka +

Indeks zgrupowany*informatyka +korzegazielicie

sys.partitionsidIndex_id=1Root page

Indeks zgrupowanyStruktura drzewiasta (B-tree) drzewo zrwnowaoneNa poziomie korzenia i gazi strony indeksu Na poziomie lici waciwe strony z danymi z tabeliDane fizycznie uporzdkowane rosnco wg klucza indeksuTylko jeden indeks zgrupowany dla tabeli!Unikalno kluczy zapewniona wewntrznieJeli w tabeli wystpuj dwie takie same wartoci klucza, dodawana do nich jest losowa liczba i taki klucz staje si wewntrznie rozpoznawany jako unikalnyKiedy stosowanie jest szczeglnie uzasadnioneOperowanie na zakresach danych i danych grupowanychPobieranie danych w okrelonym porzdkuZapytania korzystajce z wielu kolumn tabeliLepsza wydajno przy dodawaniu nowych wierszyNa jakich kolumnach tworzy indeks zgrupowany?Maa dugoWysoka selektywno (mao powtarzajcych si wartoci klucza indeksu)Rzadko bd wcale nie zmieniane wartociWartoci klucza dla kolejno dodawanych wierszy s rosnce

*informatyka +

Indeks niezgrupowany (budowany na stercie)*informatyka +korzegazieliciesterta


Indeks niezgrupowany (budowany na stercie)Struktura drzewiasta (B-tree) drzewo zrwnowaoneNa poziomie korzenia, gazi i lici strony indeksu Licie zawieraj wskaniki do waciwych stron na stercieMona tworzy do 248 indeksw niezgrupowanych na tabeliStosowane s gdy dane wyszukiwane s wedug wielu kryteriw (rne zapytania)Maksymalna dugo klucza 900 bajtwMaksymalnie 16 kolumn w kluczu

*informatyka +

Indeks niezgrupowany (budowany na zgrupowanym)*informatyka +korzegazielicieIndeks zgrupowany


Indeks niezgrupowany (budowany na zgrupowanym)Praktycznie wszystko tak samo jak w budowanym na stercie.Z wyjtkiem dwch rzeczy:Licie zawieraj wartoci klucza z indeksu zgrupowanegoWskanik zawsze ustawiony jest na korze indeksu zgrupowanegoJeli indeks zgrupowany zostanie usunity niezgrupowany zostanie przebudowany (na wariant oparty o stert)Jeli indeks zgrupowany zostanie utworzony indeksy niezgrupowane zostan take przebudowane (ze sterty na zgrupowany)

*informatyka +


*informatyka +

Wykonywanie zapytaZapytanie zostao przekazane do wykonania co dzieje si dalej?Cao procesu mona opisa kilkoma etapami:Parsowanie zapytania (bdy skadniowe). Efektem jest drzewo zapytania.Standaryzacja zapytania (drzewa). Usuwanie nadmiarowoci, standaryzowanie podzapyta itp..Optymalizacja zapytania .Wieloetapowy proces prowadzcy do wyboru sposobu realizacji zapytaniaKompilacja wygenerowanego planu (zapisanie w cache)Okrelenie metod fizycznego dostpu do danychWykonanie zapytania zgodnie ze stworzonym planem*informatyka +

Wykonywanie zapyta optymalizacja zapytaniaOptymalizacja zapytania polega na:Dokonaniu analizy zapytania (pod ktem kryteriw wyszukiwania oraz zcze)Dobraniu indeksw, ktre mog okaza si pomocne przy realizacji zapytania (kryteria wyszukiwania, kolumny wyjciowe)Okreleniu strategii realizacji zcze (selektywno, potrzebna pami)Generowanych jest kilka wariantw, dla kadego szacowany jest koszt wyraony w operacjach wejcia/wyjcia (I/O) i czasie rocesora (CPU).Wybierany jest najtaszy wariant i przekazywany do kompilacjiPlan wykonania mona podejrze za pomoc wczenia jednej z opcji:SET SHOWPLAN_TEXT ON, SET SHOWPLAN_XML ON , SET SHOWPLAN_ALL ON*informatyka +

Optymalizacja zapyta - wykorzystanie indekswZakadamy, e zapytania bd tworzone w oparciu o tabel:*informatyka +Nie ma adnych indeksw na tabeli Klienci Zapytanie, ktrym si zajmiemy jest proste:

Wykorzystanie indekswPierwsze wykonanie zapytania plan wykonania *informatyka +Brak indeksw skanowanie stertyKoszt zapytania (estimated subtree cost) : 2,1385Pierwsze wykonanie: strony pobierane z dysku Kolejne wykonania: strony znajduj si w cache

Wykorzystanie indekswStwrzmy najpierw indeks zgrupowany na kolumnie ID.Zrealizujemy to przez utworzenie klucza podstawowego na tej kolumnie (prowadzi to do utworzenia indeksu)

*informatyka +Wykonanie naszego zapytania po utworzeniu indeksu przebiega wedug planu:

Koszt zapytania pozosta bez zmian : 2,1385

Stworzylimy indeks zgrupowany, wic nie ma ju sterty.

Wykorzystanie indekswSprbujmy teraz popracowa nad wydajnociStwrzmy indeks niezgrupowany na kolumnie, ktrej uywamy jako kryterium wyszukiwania

*informatyka +Skoro istnieje indeks na kolumnie Nazwisko, to powinien zosta uyty do wyszukiwania? Sprawdmy

Dlaczego?Bo na wyjciu zapytania mamy jeszcze kolumn Imie!Optymalizator stwierdzi, i nie warto korzysta z indeksu niezgrupowanego, skoro i tak trzeba pobra strony danych, eby uzyska wartoci z tej kolumny Koszt zapytania cigle bez zmian : 2,1385

Nic z tego! Nasz indeks nie zosta wykorzystany

Wykorzystanie indekswZrbmy w kocu co co przyniesie efekt!Wiemy dlaczego nasz indeks by nieprzydatnyUczymy go przydatnym! Dodajmy kolumn Imie do indeksu*informatyka +Wykonajmy kolejny raz nasze zapytanieSukces :-)Wczeniej byo 2862 !Koszt wykonania: 0,0453Wczeniej byo: 2,1385


*informatyka +

Kopie bezpieczestwa i odtwarzanie danychBaza danych moe by skonfigurowana do pracy w trzech trybach:Simple RecoveryBulk logged Recovery (nieomawiany w ramach wykadu)Full RecoveryZalenie od wybranego trybu mamy rne moliwoci wykonywania kopii zapasowych.W trybie Simple Recovery mona wykonywa jedynie pene i rnicowe kopie zapasowe. Pozwala to w razie awarii odtworzy stan bazy do stanu na chwil wykonania ostatniej kopii zapasowej.W trybie Full Recovery mona dodatkowo wykonywa kopie logu transakcji. Pozwala to praktycznie na odtworzenie stanu bazy bezporednio sprzed awarii*informatyka +

Kopie bezpieczestwa i odtwarzanie danychWykonanie kopii zapasowej odbywa si za pomoc polecenia BACKUP:BACKUP DATABASE kopia zapasowa caej bazy danychBACKUP LOG kopia zapasowa logu transakcjiBACKUP FILE kopia zapasowa pliku wchodzcego w skad bazy danychPolecenie BACKUP DATABASE wykonuje domylnie pen kopi bazy danychWywoane z opcj WITH DIFFERENTIAL wykonuje kopi rnicow (zmiany danych od ostatniej kopii penej)Opcja ta zadziaa pod warunkiem, e wczeniej wykonalimy kopi pen!*informatyka +

Kopie bezpieczestwa i odtwarzanie danychOdtwarzanie bazy z kopii zapasowej realizowane jest za pomoc polecenia RESTOREPosiada ono takie same warianty jak polecenie BACKUP (DATABASE, LOG, FILE)W przypadku koniecznoci odtworzenia stanu z kilku kolejnych kopii (kopia pena, kopia rnicowa oraz log transakcji) mona wykorzysta opcj NORECOVERY, ktra powoduje , e baza utrzymywana jest w stanie niespjnoci i pozwala na odtwarzanie kolejnych kopii. Ostatnie polecenie odtworzenia bazy powinno by wywoane z opcj RECOVERY (domylna), eby baza wrcia do stanu stabilnego (wycofanie niezatwierdzonych transakcji sprzed awarii)*informatyka +

Kopie bezpieczestwa i odtwarzanie danychWykonywanie kopii zapasowych i ich odtwarzanie mona wykonywa take z poziomu narzdzia SQL Server Management Studio.Dodatkowo tworzc tzw. Maintenance Plan mona stworzy harmonogram wykonywania kopii zapasowych, ktry bdzie realizowany automatycznie.Istniej take narzdzia produkowane przez inne firmy, ktre pozwalaj planowa i realizowa strategie wykonywania kopii zapasowych baz danych.Najwaniejsze jednak jest sensowne zaplanowanie strategii wykonywania kopii zapasowych.Powinna zapewni moliwo odtworzenia danych z zaoon dokadnociPowinna zapewni akceptowalny czas odtworzenia bazy i przywrcenia gotowoci do pracyPowinna by skrupulatnie realizowanaPowinna zawiera dokadnie opisane procedury odtwarzania danych po awarii!

*informatyka +


*informatyka +

PodsumowanieBaza danych to nie tylko zbir tabelIstnieje wiele mechanizmw wewntrz bazy danych, ktre su zapewnieniu spjnoci danych, definiowaniu rnego rodzaju ogranicze, implementowaniu zoonej logiki aplikacji itp.Warto te mechanizmy stosowa, gdy takie podejcie skutkuje zwykle wysz wydajnoci aplikacji oraz wyszym poziomem bezpieczestwa danych.Moliwoci drzemice w mechanizmach bazy danych s wystarczajce, eby projektowa bazy hermetyczne i idiotoodporne w postaci czarnej skrzynki, ktra udostpnia na zewntrz tylko list operacji (procedur skadowanych)Warto zapozna si z tymi mechanizmami praktycznie!

*informatyka +

KONIEC

*informatyka + czy s jakie pytania?

Na haso relacyjna baza danych pierwszym skojarzeniem jest zwykle tabela lub kilka tabel. Niestety w tym miejscu koczy si wiedza czci programistw i w tworzonych przez nich aplikacjach baza danych jest wykorzystywana jedynie jako prymitywna skadnica danych. Wszelkie operacje weryfikacji poprawnoci danych, zapewnienia im spjnoci i sensownoci oraz samo przetwarzanie danych odbywa si w ramach logiki aplikacji. Taka architektura aplikacji nie jest dobrym pomysem i bardzo szybko okazuje si by niewystarczajca a wrcz szkodliwa lub uniemoliwiajca korzystanie z aplikacji ze wzgldu na skrajnie kiepsk wydajno oraz, co waniejsze, na bdy i niespjnoci w danych przechowywane w bazie.Co wic mona zrobi, eby zadba nieco bardziej o cenne dane, ktre chcemy gromadzi w bazie? Przede wszystkim pozna nieco bliej moliwoci, ktre oferowane s przez relacyjne bazy danych w zakresie zapewnienia spjnoci przechowywanym danym. W ramach niniejszego wykadu postaramy si przybliy kilka takich mechanizmw, a take zaprezentowa spor ilo dodatkowych informacji, ktre pozwol spojrze na baz danych , jako na twr, ktry mona w bardzo szerokim zakresie ksztatowa, wzbogaca jego funkcjonalno, definiowa najprzerniejsze ograniczenia majce zastosowanie do przechowywanych danych tak, aby mc speni wymagania stawiane tworzonemu systemowi informatycznemu oraz zapewni bezpieczestwo i spjno przechowywanym danym.*Zakres wykadu obejmuje wybrane zagadnienia dotyczce mechanizmw dostpnych w ramach bazy danych.

Omwione zostan wizy integralnoci referencyjnej wraz z zaprezentowaniem przykadw i dobrych praktyk ich dotyczcych.

Drugim zagadnieniem bd transakcje zapoznamy si z istota transakcyjnoci, trybami tworzenia transakcji oraz z poziomami izolacji i ich specyfik.

W ramach omawiania wyzwalaczy zademonstrowane zostan poszczeglne ich rodzaje oraz opisana zostanie ich specyfika.

Kolejnym zagadnieniem bd indeksy. Zapoznamy si z fizyczn organizacj danych w SQL Serverze 2008 i z jej konsekwencjami. Omwiona zostanie te struktura rnych rodzajw indeksw, a take zaprezentowany zostanie proces optymalizacji zapytania z wykorzystaniem indeksu pokrywajcego

Istotnym zagadnieniem s te kwestie zwizane z wykonywaniem kopii bezpieczestwa baz danych oraz z odtwarzaniem danych z takich kopii.

*Rozpoczniemy od mechanizmu zwanego wizami integralnoci referencyjnej. Jest on istotnym mechanizmem, gdy umoliwia definiowanie relacji pomidzy tabelami oraz zapewnia spjno takiej relacji.*Przy projektowaniu bazy danych standardow praktyk jest doprowadzenie struktury bazy do tzw. trzeciej postaci normalniej. Prowadzi to do powstania wikszej liczby mniejszych (zawierajcych mniej kolumn) tabel. eby w takiej sytuacj zapewni spjno danych, potrzebny jest specjalny mechanizm, ktry po zdefiniowaniu regu powiza miedzy tabelami bdzie pilnowa ich spjnoci. Wanie do tego celu stworzony zosta jeden z rodzajw ogranicze(constraints) klucz obcy. Za jego pomoc moemy w wygodny sposb definiowa reguy spjnoci danych pomidzy tabelami.Wykorzystanie klucza obcego najlepiej bdzie przeledzi na przykadzie. Zamy, e mamy w bazie dwie tabele (takie jak na slajdzie). Jedna zawiera dane klientw banku, druga informacje o rachunkach bankowych. Na chwile obecn tabele te nie s w aden sposb powizane. Zastosujemy ograniczenie typu klucz obcy do realizacji wymagania mwicego, e kady rachunek ma tylko jednego waciciela.*Pierwszym krokiem bdzie dodanie danych kilku klientw. W tabeli klienci stworzony zosta klucz podstawowy na kolumnie KlientID. Dodatkowo kolumna ta sama dba o nadawanie klientom kolejnych, unikalnych wartoci identyfikatora poprzez ustawienie waciwoci IDENTITY.

W takim przypadku efektem wykonania trzech kolejnych polece INSERT bdzie dodanie trzech wierszy w tabeli klienci. Kady z nich bdzie mia automatycznie nadany i unikalny identyfikator KlientID.Jak teraz powiza tych klientw z rachunkami (okreli kto jest wacicielem rachunku)? Poprzez dodanie do tabeli rachunki nowej kolumny (klientID) przechowujcej identyfikator klienta, ktry jest wacicielem rachunku.*Kolejnym krokiem bdzie dodanie danych kilku rachunkw bankowych. W tabeli Rachunki stworzony zosta klucz podstawowy na kolumnie RachunekID. Dodatkowo kolumna ta sama dba o nadawanie kolejnych, unikalnych wartoci identyfikatora rachunkom poprzez ustawienie waciwoci IDENTITY. Kolejne kolumny Numer i DataOtwarcia maja przypisane wartoci domylne, wic jeli nie podamy dla nich wartoci, to zostan wygenerowane automatycznie.

W zwizku z tym, efektem wykonania czterech kolejnych polece INSERT bdzie dodanie czterech wierszy w tabeli rachunki. Kady z nich bdzie mia automatycznie nadany identyfikator, numer i dat otwarcia. Jedyn wartoci podawan przez nas przy dodawaniu danych jest identyfikator klienta.

Trzy pierwsze wiersze s jak najbardziej poprawne i jasno przypisane do istniejcych klientw (identyfikatory od 1 do 3). Czwarty natomiast jest zdecydowanie bezsensowny! Nie mamy klienta o identyfikatorze 4, a mamy rachunek przypisany do tego klienta. To niedopuszczalna sytuacja. Jak jej zaradzi? Ano wanie przez zastosowanie klucza obcego.*eby utworzy klucz obcy musz by spenione warunki:

kolumny w obu tabelach musz by tego samego typu kolumna w tabeli nadrzdnej musi by kluczem podstawowym tabeli lub posiada indeks lub ograniczenie unikalne (unique).

Klucz obcy tak jak inne ograniczenia mona tworzy dla tabeli za pomoc polecenia ALTER TABLE.

Przy tworzeniu klucza obcego, domylnie sprawdzane s istniejce dane pod ktem zgodnoci z jego definicj.*Niestety. Prba utworzenia klucza obcego na tabeli rachunki zakoczya si niepowodzeniem! Przyczyn jest oczywicie jeden z wierszy w tej tabeli ten z identyfikatorem nieistniejcego klienta. Przy tworzeniu klucza obcego sprawdzane s istniejce dane pod ktem zgodnoci z regu klucza. Mona to sprawdzenie wyczy poprzez zastosowanie klauzuli WITH NOCHECK przy tworzeniu klucza. Naley j stosowa tylko wtedy, gdy reguy biznesowe dopuszczaj bdne wartoci klucza lub ich brak dla danych istniejcych, natomiast dla danych nowododawanych lub modyfikowanych reguy maj by ju stosowane.

Drugim wyjciem z sytuacji jest naprawienie danych przed utworzeniem klucza obcego. Zastosujemy ten wariant.*Zmodyfikujmy wiersz w tabeli Rachunki zawierajcy bdny identyfikator klienta i ustawmy jego warto na 2 (taki klient istnieje).Po wykonaniu tej operacji moemy ju miao ponowi prb utworzenia klucza obcego. Tym razem wszystko si udaje i zostaje on utworzony.

Sprawdmy jeszcze czy dziaa dodajmy nowy rachunek dla nieistniejcego klienta (klientID = 15). Tym razem operacja nie udaje si, mechanizm klucza obcego zadziaa i skutecznie uniemoliwi nam wprowadzenie niespjnoci do danych.*Jeeli prbujemy dodawa dane poprawne, czyli podajemy identyfikator istniejcego klienta, to oczywicie nie ma adnego problemu z dodaniem nowego rachunku.*Przy tworzeniu ogranicze typu klucz obcy naley wspomnie o kaskadowych wizach integralnoci referencyjnej. Ich istota polega na zdefiniowaniu w jaki sposb maja si zachowa wiersze (i kolumny) klucza obcego w reakcji na usunicie (lub zmodyfikowanie) wiersza (lub wartoci klucza podstawowego).Mona wybra jeden z czterech wariantw takiej reakcji dla kadej z dwch opcji (ON DELETE i ON UPDATE):No Action jest to domylny wariant, ktry nie powoduje podjcia jakichkolwiek dziaa w zwizku z usuniciem czy zmodyfikowaniem wiersza do ktrego odwouje si klucz obcy

Cascade jak sama nazwa wskazuje, powoduje kaskadowe usunicie wierszy odwoujcych si poprzez klucz obcy do usuwanego wiersza, lub modyfikacj wartoci kolumn klucza obcego w przypadku zmodyfikowania wartoci klucza podstawowego, do ktrego si on odwouje. Jest to opcja z jednej strony bardzo wygodna, gdy zwalnia nas z rcznego usuwania wierszy skojarzonych przez klucz obcy. Z drugiej strony za, przy odrobinie pecha mona wyczyci niechccy spor cz danych jednym niewinnym poleceniem usunicia jednego wiersza z tabeli

Set Null polega na tym, e w przypadku usunicia wiersza do ktrego odwoywa si klucz obcy, kolumnom tego klucza przypisywana jest warto null. eby opcja ta zadziaaa, kolumny klucza obcego musza dopuszcza warto null.

Set Default dziaanie zblione do Set null, z ta rnic, e kolumny klucza obcego s ustawiane na warto domyln. eby opcja ta zadziaaa, kolumny klucza musz mie okrelona warto domyln lub dopuszcza warto null (na ktr bd ustawione w przypadku braku wartoci domylnej)*Sprawdmy teraz w ramach przykadu dziaanie opcji ON DELETE CASCADE. W tym celu usuniemy klucz obcy z tabeli Rachunki, a nastpnie odtworzymy go z opcj ON DELETE CASCADE. Po wykonaniu tej operacji sprbujmy usun jeden wiersz z tabeli Klienci. Niech bdzie to klient o identyfikatorze 2, ktry z tego co pamitamy posiada dwa Rachunki (dwa wiersze w tabeli Rachunki z jego identyfikatorem w kolumnie klucza obcego). Po wykonaniu tego polecenia i pobraniu penej listy rachunkw okazuje si, e zgodnie z naszymi oczekiwaniami po usuniciu klienta usunite zostay jego rachunki. W tym miejscu jeszcze raz warto podkreli, e jest to opcja bardzo niebezpieczna i przy bardziej zoonej strukturze tabel polecenie usunicia jednego wiersza moe spowodowa czystk w bazie danych.*Podsumowujc t cz wykadu warto wspomnie o jeszcze kilku cechach kluczy obcych. Po pierwsze klucz obcy nie musi by pojedyncz kolumn. Mona go zdefiniowa na kilku kolumnach, lecz trzeba wtedy pamita, e jeeli te kolumny dopuszczaj warto null, a ktrakolwiek z nich bdzie miaa t warto, to pozostae nie bd sprawdzane pod ktem zgodnoci z regu klucza.Klucz obcy nie musi odwoywa si do kolumny lub kolumn z innej tabeli. W pewnych przypadkach tworzy si klucze obce odwoujce si do kolumn w tej samej tabeli. Mwimy wtedy o samozczeniu. Takie rozwizanie bywa stosowane na przykad do budowania danych o strukturze hierarchicznej. Przykadowo wemy tabel pracownicy, ktra ma kolumny: PracownikID (klucz podstawowy), Nazwisko Imie kierownikID (klucz obcy, dopuszczalna warto null)

Tak prosta struktura tabeli pozwala na zdefiniowanie hierarchii pracownikw poprzez okrelenie kto jest czyim kierownikiem za pomoc wartoci kolumny KierownikID, ktra jest kluczem obcym odwoujcym si do kolumny z tej samej tabeli. W takiej hierarchii szef wszystkich szefw bdzie mia warto null w kolumnie kierownikID :) Rozwizania oparte o taki schemat s bardzo atwe w implementacji, lecz nieco uciliwe w obsudze, szczeglnie gdy prbujemy si porusza po hierarchii w poziomieAlternatyw dla takich rozwiza jest typ danych hierarchyID lub XML. Posiadaj one unikalne cechy, ktre predestynuj je do stosowania w okrelonych scenariuszach. Warto o nich poczyta zanim zdecydujemy si na zastosowanie konkretnego pomysu.

Ograniczenie typu klucz obcy moe by wczane/wyczane za pomoc polecenia ALTER TABLE z opcj CHECK/NOCHECK CONSTRAINT. Wane jest, aby nie myli tych opcji z WITH CHECK/NOCHECK. Usystematyzujmy:CHECK/NOCHECK wcza lub wycza ograniczenieWITH CHECK/NOCHECK powoduje sprawdzanie bd nie, istniejcych danych przy tworzeniu/wczaniu ograniczenia

*Bardzo istotnym zagadnieniem zwizanym z relacyjnymi bazami danych jest mechanizm transakcji. Jest on podstaw, ktra pozwala na korzystanie z takich baz danych w ramach powanych systemw informatycznych, ktre nie mog sobie pozwoli na pojawianie si stanw nieustalonych w ramach danych.*Przy tworzeniu aplikacji bazodanowych rzadko zastanawiamy si czy baza zapewnia nam stabilno i bezpieczestwo danych. Przyjmujemy, e tak. Warto natomiast zdawa sobie spraw jakie mechanizmy le u podstaw tego przekonania. W ramach wykadu omwimy jeden z podstawowych mechanizmw transakcje. W systemie informatycznym dane w bazie reprezentuj zwykle aktualny stan biznesu (procesu produkcji, stanw magazynowych, alokacji zasobw itp.) Jako, e sytuacja biznesowa jest zmienna, to dane w bazie take podlegaj cigym zmianom. Kada z takich zmian stanowi swego rodzaju cao i skada si czsto z wielu elementarnych modyfikacji danych. Tylko prawidowe wykonanie wszystkich krokw w ramach takiej zmiany ma sens z punktu widzenia biznesowego. W takiej sytuacji nietrudno wyobrazi sobie do czego moe prowadzi przerwanie takiej zoonej operacji w trakcie jej realizacji powstaje stan nieustalony. Jest to niedopuszczalna sytuacja, ktra moe wprowadza chaos. Na szczcie serwery baz danych potrafi sobie z ni radzi. Jak? Wanie poprzez mechanizm transakcji.*Transakcj nazywamy sekwencj logicznie powizanych ze sob operacji na danych zawartych w bazie, ktre przeprowadzaj baz danych z jednego stanu spjnego do drugiego. Na pocztku lat osiemdziesitych XX wieku pojawi si akronim ACID (Atomicity, Consistency, Isolation, Durability) okrelajcy w zwizy i atwy do zapamitania sposb podstawowe waciwoci transakcji:

Atomicity (atomowo) definiuje waciwo okrelajc, e transakcja jest niepodzielna. Oznacza to, e albo wszystkie operacje wchodzce w jej skad wykonaj si poprawnie w caoci, albo wcale. Nie istnieje moliwo wykonania czci transakcji.

Consistency (spjno) oznacza, e baza danych przed rozpoczciem znajduje si w stanie stabilnym i po zakoczeniu transakcji (niezalenie czy przez zatwierdzenie czy wycofanie) te ma pozosta w stanie stabilnym.

Isolation (odizolowanie) odnosi si do faktu, i transakcje s od siebie logicznie odseparowane. Mog oddziaywa midzy sob tak, jakby byy wykonywane sekwencyjnie.

Durability (trwao) jest waciwoci, ktra gwarantuje, e jeeli transakcja zostaa zatwierdzona, to nawet w przypadku awarii systemu lub zasilania, nie zostanie utracona lub wycofana

Wszystkie te cechy zostay zaimplementowane w serwerach baz danych i dziki temu mamy zapewniona spjno danych i gwarancj, e niezalenie od okolicznoci baza danych bdzie zawsze w stabilnym stanie. Ma to kluczowe znaczenie dla wikszoci systemw informatycznych tworzonych na potrzeby biznesu i nie tylko.*Skoro istnieje problematyka spjnoci danych, to czy nie jest dobrym rozwizaniem kolejkowanie transakcji i wykonywanie ich sekwencyjnie? Zapewnioby to brak konfliktw przy modyfikacji danych z poziomu rnych transakcji. Niestety nie jest to jedyny problem. Rwnie istotna pozostaje kwestia wydajnoci, a przy zaproponowanym podejciu nie byaby ona zadowalajca. eby mc podnie wydajno i jednoczenie zachowa wszystkie waciwoci transakcji istnieje kilka tzw. poziomw izolacji. Kady z nich korzysta z nieco innej strategii stosowania blokad, co pozwala na zrwnoleglanie niektrych operacji modyfikacji danych i ich odczytu z poziomu innych transakcji.*Domylnie SQL Server jest skonfigurowany w ten sposb, e transakcje obsuguje w trybie autocommit. Oznacza to, e transakcje s automatycznie rozpoczynane po natrafieniu na polecenie modyfikujce dane lub struktur bazy, oraz zatwierdzane zaraz po poprawnym wykonaniu tego polecenia. Mona oczywicie sterowa procesem tworzenia i zatwierdzania transakcji. Realizuje si to poprzez korzystanie z trybu IMPLICIT TRANSACTION w ktrym transakcje rozpoczynane s tak jak w trybie autocommit, ale wymagaj rcznego zakoczenia poprzez wydanie polecenia COMMIT lub ROLLBACK. Drugim wariantem jest tryb EXPLICIT TRANSACTIONS, ktry polega na rozpoczynaniu transakcji poleceniem BEGIN TRANSACTION i koczeniu jej poleceniem COMMIT lub ROLLBACK(tak jak w IMPLICIT).*Transakcje mog by zagniedane. Moe si to odbywa nie tylko w sposb pokazany na slajdzie, ale take w bardziej zoony na przykad mamy rozpoczt transakcj, a w jej ramach wywoujemy procedur skadowan, ktra wewntrz swojego kodu zawiera take transakcj. Procedura moe prbowa wykona jak operacj w ramach swojej transakcji, a w przypadku poraki wycofa j, wykona alternatywny kod i zakoczy dziaanie. W takiej sytuacji zewntrzna transakcja moe by kontynuowana i zatwierdzona poprawnie. Przy zagniedaniu transakcji warto pamita, e mechanizm ten nie dziaa do koca w intuicyjny sposb pary polece BEGIN TRANSACTION i COMMMIT (lub ROLLBACK) nie peni roli pary nawiasw. eby unikn problemw warto dokadnie si zapozna z mechanizmem dziaania transakcji zagniedonych i przewiczy go w praktyce.*SQL Server posiada wbudowana zmienna @@TRANCOUNT, w ktrej przechowywany jest aktualny poziom zagniedenia. Jeli nie ma w danej chwili adnej aktywnej transakcji ma warto 0. Kade polecenie BEGIN TRANSACTION zwiksza warto zmiennej @@TRANCOUNT. Dziki temu przy tworzeniu kodu procedur skadowanych moemy zawsze atwo sprawdzi na jakim poziomie zagniedenia jestemy i odpowiednio zareagowa. Przy bardziej zoonych transakcjach mona budowa bardziej skomplikowany przebieg transakcji. Przeznaczone do tego celu jest polecenie SAVE, ktre tworzy w ramach transakcji punkt, do ktrego moe by ona cofnita bez koniecznoci wycofywania caej transakcji. Pozwala to na budowanie alternatywnych cieek realizacji transakcji.**Przy realizacji wicej ni jednej transakcji w tym samym czasie mog pojawi si rne problemy zwizane z uzyskiwaniem przez nie dostpu do danych i modyfikowaniem ich.

Typowe przykady takich zjawisk to :

Lost update (zgubiona modyfikacja). Zjawisko to mona zilustrowa przykadem, gdy dwie transakcje T1 i T2 odczytay warto z bazy, nastpnie kada z nich prbuje zapisa t warto po modyfikacji. W takim przypadku transakcja, ktra zostanie zatwierdzona pniej, nadpisze modyfikacje dokonane przez transakcj zatwierdzon wczeniej.

Dirty read(brudny odczyt) .Typowy przykad to zliczanie odwiedzin strony przez uytkownikw aplikacji. Polega ono na odczytaniu aktualniej liczby odwiedzin z bazy, powikszeniu jej o 1 i zapisaniu z powrotem do bazy. Jeli teraz transakcja T1 odczytuje dane (np. warto 5), dokonuje ich inkrementacji i zapisuje w bazie, ale nie zostaje zatwierdzona. W tym samym czasie T2 odczytuje dane zapisane przez T1 (warto 6), nastpnie inkrementuje j. W tym momencie T1 zostaje wycofana (warto powinna zosta ponownie zmieniona na 5). T2 zostaje zatwierdzona i w bazie lduje warto 7, co stanowi ewidentny bd.

*Nonrepeatable reads (niepowtarzalny odczyt). Przykadem moe by transakcja T1, w ktrej pobierane s do modyfikacji wszystkie niezrealizowane zamwienia. W kolejnym kroku informacje te s przetwarzane. W tym czasie transakcja T2 modyfikuje status kilku zamwie (zmienia na zrealizowane) i zostaje zatwierdzona. Teraz z kolei T1 ponownie siga do listy zamwie niezrealizowanych i otrzymuje list inn ni poprzednio, co moe spowodowa bdy w przetwarzaniu danych zamy, e po pierwszym odczycie tworzone byy zlecenia dla magazynierw (pobranie towarw dla zamwie), a przy drugim byy generowane listy przewozowe. Efektem bdzie niespjno - brak kilku listw przewozowych.

Phantom reads (odczyt-widmo). Sytuacja moe by podobna jak poprzednio. Transakcja T1 pobiera zamwienia przeznaczone do realizacji na dzi. Zaczyna je przetwarza. W tym czasie transakcja T2 przekazuje jeszcze dwa zlecenia do realizacji na dzi i zostaje zatwierdzona. T1 ponownie siga po dane zamwie i otrzymuje dodatkowe dwa zamwienia, dla ktrych nie zostay wykonane czynnoci z pierwszego etapu przetwarzania! Podobnie jak poprzednio nie jest to dobra sytuacja i prowadzi do powstania niespjnoci.*W zalenoci od operacji wchodzcych w skad transakcji oraz specyfiki aplikacji, ktra z bazy danych korzysta moemy stosowa jeden z kilku poziomw izolacji transakcji. Kady z nich cechuje si tym, e eliminuje moliwo wystpienia kolejnego rodzaju konfliktu, przez co podnosi poziom bezpieczestwa transakcji, ale jednoczenie powoduje obnienie wydajnoci. Celem projektantw baz danych i aplikacji jest znalezienie rozsdnego kompromisu pomidzy wydajnoci a poziomem izolacji dla konkretnych transakcji przeprowadzanych w ramach dziaania aplikacji. Kady rodzaj transakcji przeprowadzanej przez aplikacj warto przeanalizowa pod ktem wymaganego poziomu izolacji. Dy si do tego, aby stosowa moliwie najniszy poziom izolacji, aby mc zachowa z jednej strony bezpieczestwo i spjno danych, a z drugiej zadowalajc wydajno.*Przy realizacji wielu transakcji jednoczenie czasem dochodzi do jeszcze jednego zjawiska zakleszczenia (deadlock). Jest to zjawisko zdecydowanie negatywne i nie ma uniwersalnego sposobu, eby je na 100% wyeliminowa. Do tego jest to problem nieodwracalny i jedynym rozwizaniem jest wycofanie jednej z zakleszczonych transakcji. Obrazowo problem zakleszczenia mona przedstawi na przykadzie rysowania wykresu na tablicy. Potrzebne do tego s dwa zasoby: linijka i kreda. Przyjmijmy, e mamy dwch chtnych do rysowania wykresu. Wiedz oni co jest do tego potrzebne. Pierwszy ochotnik siga po kred i zaczyna rozglda si za linijk. W tym samym czasie drugi ochotnik chwyci linijk i szuka kredy. Dochodzi do sytuacji, w ktrej obaj blokuj sobie nawzajem potrzebne zasoby czekajc na zwolnienie przez konkurenta drugiego potrzebnego do rysowania wykresu zasobu. Sytuacja jest patowa. W takiej sytuacji SQL Server korzysta z prostego i brutalnego mechanizmu. Losuje jedn z zakleszczonych transakcji (staje si ona ofiar deadlock victim) i wycofuje j z odpowiednim komunikatem bdu. To pozwala drugiej z transakcji na uzyskanie wszystkich potrzebnych zasobw i zrealizowanie wszystkich zaplanowanych czynnoci.

*Zakleszczenie jak ju wspominalimy jest nie do uniknicia. Jedyne co mona zrobi to stara si minimalizowa szanse jego wystpienia. Wbrew pozorom nie musi to by strasznie skomplikowane zajcie. Czsto siganie do zasobw w tej samej kolejnoci pozwala na wyeliminowanie wikszoci przypadkw zakleszcze w bazie danych. Takie podejcie powoduje, e pierwsza transakcja, ktrej uda si zdoby pierwszy zasb ma gwarancj, e adna inna transakcja tego samego typu nie zajmie innego zasobu potrzebnego do realizacji zaplanowanych operacji.

*Przy korzystaniu z transakcji warto trzyma si kilku zasad, ktre pozwalaj na wykonywanie transakcji w moliwie najwydajniejszy sposb.Przede wszystkim pilnujmy dugoci transakcji. Im dusza, tym duej aktywne s blokady przez ni utworzone i inne transakcje nie mog korzysta z zasobw. Pod adnym pozorem nie naley w ramach transakcji prowadzi jakiejkolwiek interakcji z uytkownikiem! Transakcja powinna zawiera jedynie kod, ktry musi by wykonany w jej ramach ze wzgldw zachowania spjnoci danych. Wszelkie inne operacje mog odbywa si przed lub po transakcji. Mona tu zauway podobiestwo do programowania wspbienego i sekcji krytycznej.

W ramach transakcji warto zaplanowa kolejno uzyskiwania dostpu do zasobw tak, aby minimalizowa ryzyko wystpienia zakleszcze. Zagadnienie to staje si tym bardziej skomplikowane im wicej rnych operacji jest realizowanych z wykorzystaniem osobnych transakcji.

W specyficznych przypadkach mona podpowiedzie serwerowi jakich rodzajw blokad ma uy w ramach wykonywania transakcji. Jest to jednak zdecydowanie margines zastosowa. W miar moliwoci nie naley ingerowa w ten mechanizm, gdy sam z siebie dziaa bardzo dobrze. Nie w peni przemylana i wiadoma ingerencja moe drastycznie obniy wydajno.

Dobranie odpowiedniego poziomu izolacji dla transakcji jest take bardzo istotne. W przypadkach gdy ryzyko wystpienia konfliktw (dirty reads itp.) w ramach transakcji nie stanowi zagroenia dla wykonywanej operacji warto obnia poziom izolacji. Jedynie w przypadku krytycznych operacji sigajmy po poziom SERIALIZABLE. Takie podejcie pozwoli uzyska lepsz wydajno bazy danych.*Kolejnym ciekawym mechanizmem stosowanym w bazach danych s wyzwalacze (triggers). W ramach wykadu zapoznamy si z poszczeglnymi rodzajami wyzwalaczy oraz z typowymi scenariuszami korzystania z nich.*Wyzwalacze s bardzo potnym i wygodnym narzdziem sucym do implementowania regu biznesowych i mechanizmw zapewnienia spjnoci danych. Powinny by stosowane tam, gdzie nie wystarczaj moliwoci ogranicze (constraints). Specyfika dziaania wyzwalaczy polega na tym, e po pierwsze s one wywoywane automatycznie w reakcji na zajcie okrelonego zdarzenia, a po drugie kod wykonywany w ramach wyzwalacza wchodzi w skad realizowanej transakcji.W SQL Serverze 2008 dostpne s wyzwalacze przeznaczone do reagowania na zdarzenia zwizane z jzykiem DML (INSERT, UPDATE, DELETE), jak i przeznaczone do reagowania na zdarzenia zwizane z jzykiem DDL (CREATE, ALTER, DROP). Istnieje rwnie specjalny rodzaj wyzwalacza reagujcy na zdarzenie LOGON logowanie uytkownika do serwera.

Bardzo istotn rzecz przy pracy z wyzwalaczami jest to, e stosowanie ich w duej liczbie moe powodowa znaczne zaciemnienie obrazu funkcjonowania bazy danych. Dlatego konieczn rzecz jest skrupulatne dokumentowanie wyzwalaczy, eby w razie problemw nie trzeba byo przeczesywa bazy danych w poszukiwaniu winowajcy takiego czy innego zachowania.*Przyjrzyjmy si teraz poszczeglnym rodzajom wyzwalaczy i ich zastosowaniu*Wyzwalacze dziaajce dla zdarze zwizanych poleceniami jzyka DML mona podzieli na:

wyzwalacze AFTER kod w nich zawarty jest wykonywany po operacji uruchamiajcej wyzwalacz, ale, co istotne, w ramach tej samej transakcjiwyzwalacze INSTEAD OFIch kod jest wykonywany zamiast operacji uruchamiajcej wyzwalacz. Waciwa operacja nie dochodzi do skutku.

Dla jednego zdarzenia na jednej tabeli mona tworzy wiele wyzwalaczy. W takiej sytuacji wane jest aby pamita, e kolejno ich wykonania jest nieokrelona. Jedyne co moemy w tej sprawie zrobi, to okreli ktry z nich ma si wykona jako pierwszy, a ktry jako ostatni. Realizuje si to za pomoc procedury skadowanej sp_settriggerorder.*W ramach przykadu wykorzystamy wyzwalacze do zaimplementowania kilku regu biznesowych w naszej bazie danych.W tym celu musimy nieco ja rozbudowa poprzez dodanie tabeli Operacje, ktra bdzie przechowywaa informacje o operacjach wykonywanych na rachunku (wpaty i wypaty).Zamy, e sformuowane zostay nastpujce reguy biznesowe:

Nie mona usun ani zmodyfikowa raz wykonanej operacjiMinimalna kwota wypaty z rachunku musi by wiksza lub rwna 10 z

Do zaimplementowania tych regu wykorzystamy dwa rodzaje wyzwalaczy AFTER i INSTEAD OF

*Rozpoczniemy od zablokowania usuwania i modyfikacji wpisw w tabeli Operacje. Do tego celu wykorzystamy wyzwalacz INSTEAD OF przypisany do zdarze UPDATE i DELETE. Spowoduje on, e przy kadej prbie zmodyfikowania lub usunicia wpisu w tabeli Operacje, zamiast wykonywanej operacji wykona si nasz wyzwalacz, ktrego jedyn funkcjonalnoci jest wygenerowanie komunikatu o bdzie.

Podobny efekt mona byoby osign stosujc wyzwalacz AFTER. W takim przypadku w kodzie wyzwalacza powinno znale si jeszcze polecenie ROLLLBACK. Byoby to jednak rozwizanie mniej efektywne, gdy powodowaoby wykonanie operacji modyfikacji lub usunicia wpisu, a dopiero po fakcie wycofania transakcji i anulowania dopiero co wykonanej operacji.

*Druga regua biznesowa do zaimplementowania ma ograniczy minimaln kwot wypaty do 10 zotych. Kada operacja wypaty kwoty mniejszej ni 10 z powinna zosta zablokowana. Realizacja tej reguy zostanie wymuszona za pomoc wyzwalacza AFTER zdefiniowanego na zdarzeniu INSERT.

Jego mechanizm dziaania jest prosty. Sprawdza, czy w danych dopisywanych w ramach transakcji wystpuje kwota wypaty nisza ni 10 z. Jeli tak, to transakcja jest wycofywana i generowany jest bd z odpowiednim komunikatem.

Prba dopisania wiersza z kwot wypaty rwn 5 z koczy si zgodnie z oczekiwaniem wycofaniem transakcji.

*SQL Server udostpnia dla kodu wyzwalaczy dwie specjalne tabele. S to tabele inserted i deleted. S one w peni obsugiwane przez serwer i utrzymywane w pamici, wic dostp do nich jest szybki. Gdy rozpoczyna si wykonanie kodu wyzwalacza, tabele te s napeniane odpowiednimi danymi.W przypadku wyzwalacza skojarzonego z poleceniem INSERT tabela inserted bdzie zawieraa dodawane wiersze.W przypadku wyzwalacza skojarzonego z poleceniem DELETE tabela deleted bdzie zawieraa usuwane daneW przypadku wyzwalacza skojarzonego z poleceniem UPDATE tabela deleted bdzie zawieraa oryginalne wartoci modyfikowanych danych, a tabela inserted ich nowe wartoci.

*Istotn cech wyzwalaczy jest fakt, e mog one by uruchomione nie tylko dla operacji modyfikujcej pojedynczy wiersz. Wyzwalacz jest uruchamiany w odpowiedzi na wykonanie jednego polecenia, ale to polecenie moe na przykad doda lub usun kilkaset wierszy jednoczenie.Dlatego wanie budujc kod wyzwalacza powinnimy uwzgldnia, e moe on wykonywa si dla wielu wierszy modyfikowanych jednym poleceniem uruchamiajcym wyzwalacz. Niepoprawne jest podejcie zaprezentowane w drugim przykadzie wyzwalacza. Bdzie ono funkcjonowao poprawnie jedynie dla modyfikacji dotyczcej jednego wiersza.

*Osobn grup wyzwalaczy s wyzwalacze DDL. Jak sama nazwa wskazuje reaguj one na zdarzenia zwizane z poleceniami jzyka DDL (Data Definition Language). Takimi poleceniami s:CREATE, ALTER, DROP, GRANT, DENY, REVOKE, UPDATE STATISTICS . Przeznaczenie wyzwalaczy DDL jest nieco inne ni wczeniej omawianych wyzwalaczy DML. Podstawow rol wyzwalaczy DDL jest wspomaganie mechanizmw audytu i ledzenia zmian w strukturze bazy danych oraz ograniczanie moliwoci manipulowania t struktur. W kodzie wyzwalacza DDL dostpna jest specjalna funkcja EVENTDATA(), ktra zwraca szczegowe informacje o zdarzeniu w formie XML (zwraca warto typu XML). Wyzwalacze DDL mona tworzy na poziomie bazy danych lub caego serwera.

*Jako przykad wyzwalacza DDL stworzymy prosty mechanizm blokujcy przeprowadzanie modyfikacji tabel oraz ich usuwanie. Dziaanie wyzwalacza bdzie polegao na wygenerowaniu komunikatu bdu informujcego o blokadzie oraz na wycofaniu transakcji. Do potrzeb testowania wyzwalacza stworzymy najpierw tabele Test, ktr bdziemy pniej prbowali usun.

*Kolejnym elementem dostpnym w ramach bazy danych, ktry pozwala na wzbogacanie logiki bazy danych o nawet bardzo zoone mechanizmy s procedury skadowane oraz funkcje uytkownika. Pozwalaj one grupowa kod SQL w wiksze bloki, ktre realizuj konkretne zadanie w ramach bazy danych. W ramach wykadu dokonamy krtkiego przegldu moliwoci oferowanych przez procedury skadowane i funkcje uytkownika.

*Procedury skadowane to bloki kodu (polece) SQL, ktre mona wykonywa jako cao. Procedury skadowane przypominaj funkcje czy metody znane z jzykw programowania. Mona przy ich wywoaniu przekazywa parametry wejciowe i wyjciowe, a take odbiera zwracany przez nie kod powrotu (liczba cakowita). Korzystanie z procedur skadowanych ma wiele zalet. Przede wszystkim pozwala grupowa polecenia SQL, ktrych wykonanie jest potrzebne do realizacji operacji biznesowej. W poczeniu z moliwoci nadawania uprawnie do wykonania procedury pozwala to na atwe budowanie systemu uprawnie do realizacji okrelonych operacji biznesowych. Dodatkowym aspektem jest fakt, e budowanie logiki aplikacji w oparciu o wywoania procedur skadowanych pozwala na odcicie si od szczegw implementacyjnych bazy danych. Aplikacja (lub uytkownik) nie musi np. wiedzie, e dane klienta s przechowywane w trzech tabelach. Wystarczy, e przekae je jako parametry wejciowe reszt zaatwi kod zawarty w procedurze.

*Przykadowa procedura, ktra utworzymy w naszej bazie bdzie suya do obsugi zakadania kont bankowych przez nowych klientw w ramach promocji.Promocja polega na tym, e klient zakadajcy konto w banku dostaje na nim prezent w wysokoci 100 z.Gdyby chcie realizowa to za pomoc polece SQL, trzeba by wykona trzy operacje utworzenie klienta, utworzenie rachunku, wykonanie operacji wpaty 100 z na konto. Wymagaoby to od aplikacji znajomoci szczegw struktury bazy danych, a w przypadku zmiany tej struktury dokonywania modyfikacji w aplikacji. eby tego unikn stworzymy nasz procedur skadowan.*Procedura, ktr utworzylimy posiada trzy parametry wejciowe (imie, nazwisko i email) oraz jeden parametr wyjciowy (numerRachunku).Dziaanie procedury polega na: Utworzeniu nowego klienta (na podstawie podanych parametrw) Utworzenie nowego rachunku i skojarzenie go z utworzonym klientem ( jego ID pobrane za pomoc funkcji SCOPE_IDENTITY() )Wykonanie operacji wpaty 100 z na utworzony rachunekPobranie numeru utworzonego rachunku i zwrcenie go przez parametr wyjciowy (numerRachunku)*Sprbujmy teraz wywoa nasza procedur. Zrobimy to w poczeniu z zadeklarowaniem zmiennej, ktra bdzie wykorzystana w charakterze parametru wyjciowego. Po wywoaniu procedury wypiszemy warto parametru wyjciowego (skonwertowana do postaci znakowej).

Po wywoaniu procedury wida, e dziaa ona poprawnie wida lady trzech polece INSERT (1 row(s) affected) oraz wypisany numer utworzonego rachunku.*Funkcje uytkownika UDF (User Defined Functions) s tworem zblionym do procedur skadowanych. Podstawow rnica jest to, e mona ich wywoania wykorzystywa w wyraeniach i zapytaniach w miejscach wartoci.Funkcje uytkownika mog zwraca wartoci skalarne lub tabelaryczne. W przypadku wartoci tabelarycznych funkcja moe by zbudowana w oparciu o pojedyncze zapytanie SELECT lub o wiele wyrae prowadzcych do wygenerowania wynikowego zbioru wierszy (odpowiednio funkcje inline i multistatement)*Stwrzmy przykadowe funkcje uytkownika w naszej bankowej bazie danych. Rozpoczniemy od funkcji skalarnej, ktra zwraca saldo wskazanego rachunku.Bdzie ona przyjmowaa parametr wejciowy - identyfikator rachunku. Zwracana bdzie suma kwot operacji wykonanych na rachunku.*Funkcja uytkownika zwracajca warto tabelaryczn bdzie zwracaa list n ostatnich operacji wykonanych na rachunkach w bankach. Stworzymy ja najpierw jako funkcj typu inline zbudowan jako wynik jednego zapytania.*Kolejna funkcja zwraca dokadnie takie samo zestawienie jak poprzednia, ale zostaa zaimplementowana jako funkcja tabelaryczna wielowyraeniowa (multistatement). Rni si od poprzedniczki tym, e w definicji funkcji podaje si definicje kolumn tabeli wyjciowej, a nastpnie w kodzie funkcji wstawia si dane do zmiennej tabelarycznej, ktra jest na koniec zwracana.*Zanim zaczniemy zgbia tematyk indeksw oraz ich wpywy na wydajno, wypadaoby zapozna si choby w niewielkim stopniu z mechanizmami lecymi u podstaw dziaania SQL Servera. Jednym z istotnych zagadnie jest tu sposb w jaki dane s fizycznie przechowywane w bazie danych.

**Gdy mylimy o tabeli to od razu wizualizujemy sobie co na ksztat ilustracji ze slajdu. Zbir wierszy skadajcych si z kolumn zawierajcych dane rnego typu.Nie zastanawiamy si jak te dane s przechowywane fizycznie na dysku, ani jaki wpyw na wydajno mog mie nasze decyzje podjte przy projektowaniu tabeli.Warto jednak zada sobie nieco trudu i zapozna si z fizycznym sposobem przechowywania danych w bazie. Zrozumienie podstaw pozwoli pniej zrozumie dlaczego w takiej czy innej sytuacji wykonanie zapytania czy modyfikacji danych trwa dugo.*Najmniejsz jednostk przechowywania danych jest w SQL Serverze strona (page). Jest to 8 KB blok skadajcy si z nagwka i 8060 bajtw na dane z wiersza(-y). Przy zaoeniu, e wiersz tabeli musi si zmieci na stronie jasno wida, e maksymalny rozmiar wiersza to 8060 bajtw. Troch mao? Niekoniecznie. Cz danych o rozmiarze przekraczajcym 8KB jest zapisywana na innych stronach, a w samym wierszu umieszczany jest tylko wskanik do pierwszej z tych stron. SQL Server rozrnia 9 rodzajw stron przechowujcych informacje o rozmaitym znaczeniu.

Strony danych (data) zawieraj wszystkie dane z wiersza, z wyjtkiem kolumn typw: text, ntext, image, nvarchar(max), varchar(max), varbinary(max), xml.Jeeli wiersz nie mieci si w limicie dugoci 8060 bajtw, to najdusza z kolumn jest przenoszona do tzw. strony przepenienia (strona danych), a w jej miejscu w wierszu zostaje 24 bajtowy wskanik

Strony indeksw (index) zawieraj poszczeglne wpisy indeksu. W ich przypadku istotny jest limit dugoci klucza indeksu 900 bajtw

Strony obiektw BLOB/CLOB (Binary /Character Large Object) (text/image) su do przechowywania danych o rozmiarze do 2 GB.

Do stron GAM, SGAM i IAM wrcimy na kolejnych slajdach, gdy poznamy kolejne pojcia dotyczce fizycznego przechowywania danych.

Wymienilimy tylko 6 rodzajw, eby niepotrzebnie nie komplikowa dalszych rozwaa. Dla uporzdkowania warto wspomnie o pozostaych trzech: Page Free Space , Bulk Changed Map, Differential Changed Map. Pierwsza zawiera informacje o zaalokowanych stronach i wolnym miejscu na nich. Pozostae dwa rodzaje wykorzystywane s do oznaczania danych zmodyfikowanych w ramach operacji typu bulk oraz do oznaczania zmian od ostatnio wykonanej kopii zapasowej.

*Podstawow jednostk alokacji nie jest jednak w SQL Serverze strona, tylko zbir omiu stron obszar (extent). Jest tak ze wzgldu na fakt, i 8 KB to troch za mao jak na operacje w systemie plikw. 64 KB to akurat jednostka alokacji w systemie plikw NTFS.

Obszary mog zawiera strony nalece do jednego obiektu (tabeli czy indeksu) nazywamy je wtedy jednolitymi (uniform), lub do wielu obiektw staj si wtedy obszarami mieszanymi (mixed).Jeeli SQL Server alokuje miejsce na nowe dane to najmniejsz jednostk jest wanie obszar.*Jeeli tabela nie zawiera adnego indeksu, to jej dane tworz stert nieuporzdkowan list stron nalecych do tej tabeli. Wszelkie operacje wyszukiwania na stercie odbywaj si wolno, gdy wymagaj zawsze przejrzenia wszystkich stron.*Tabela moe zosta podzielona na partycje (wzgldy wydajnociowe zrwnoleglenie operacji wejcia wyjcia). W takim przypadku kada z partycji posiada wasn stert. Wszystkie razem tworz zbir danych tabeli.*Gdy SQL Server alokuje miejsce w plikach bazy danych, wypenia je obszarami, ktre wstpnie s oznaczone jako wolne. Podobnie wszystkie strony w obszarach s oznaczone jako puste. W jaki sposb przechowywane s informacje na temat tego czy dany obszar lub strona s wolne lub nale do jakiego obiektu? Su do tego specjalne strony GAM, SGAM i IAM. Zawieraj one informacje o zajtoci poszczeglnych obszarw w postaci map bitowych (GAM,SGAM) lub o przynalenoci obszarw do obiektw (tabel,indeksw) IAM.

*Kluczem do uzyskania dostpu do danych z tabeli jest moliwo dostania si do strony IAM tej tabeli.Informacje na temat lokalizacji stron IAM dla poszczeglnych obiektw znajduj si we wpisach w tabelach systemowych. Jako, e nie zaleca si grzebania bezporednio w tych tabelach, zostay udostpnione specjalne widoki, ktre zawieraj potrzebne nam dane. W przypadku stron IAM jest to widok sys.partitions.

Wpisy w nim zawarte skadaj si m.in. z kolumny index_id okrelajcej rodzaj obiektu (sterta, indeks zgrupowany, indeks niezgrupowany, obiekty LOB), kolumn okrelajcych id obiektu i partycji oraz wskanika do strony IAM obiektu.*Poznalimy ju sposb przechowywania danych w tabeli, dla ktrej nie stworzono indeksw. Cech charakterystyczn by fakt nieuporzdkowania stron i wierszy nalecych do jednej tabeli, co wymuszao przy kadej operacji wyszukiwania danych w tabeli przeszukanie wszystkich wierszy. Taka operacja nosi nazw skanowania tabeli (table scan). Jest ona bardzo kosztowna (w sensie zasobw) i wymaga czstego sigania do danych z dysku tym czciej im wicej danych znajduje si w tabeli.Taki mechanizm jest skrajnie nieefektywny, wic musz istnie jakie inne pozwalajce na przeprowadzanie efektywnego wyszukiwania. Rzeczywicie takowe istniej. S to indeksy wystpujce w dwch podstawowych wariantach jako indeksy: zgrupowane (clustered) i niezgrupowane (nonclustered)

*Indeks zgrupowany ma posta drzewa zrwnowaonego (B-tree). Na poziomie korzenia i gazi znajduj si strony indeksu zawierajce kolejne wartoci klucza indeksu uporzdkowane rosnco. Na poziomie lici znajduj si podobnie uporzdkowane strony z danymi tabeli. To wanie jest cech charakterystyczn indeksu zgrupowanego powoduje on fizyczne uporzdkowanie wierszy w tabeli, rosnco wedug wartoci klucza indeksu (wskazanej kolumny lub kolumn).Z tego wzgldu oczywiste jest ograniczenie do jednego indeksu zgrupowanego dla tabeli.

*Specyfika indeksu zgrupowanego polega jak ju wspomnielimy na fizycznym porzdkowaniu danych z tabeli wedug wartoci klucza indeksu. W zwizku z tym jasne jest, e indeks ten bdzie szczeglnie przydatny przy zapytaniach operujcych na zakresach danych, grupujcych dane, oraz korzystajcych z danych z wielu kolumn. W takich przypadkach indeks zgrupowany zapewnia znaczny wzrost wydajnoci w stosunku do sterty lub indeksu niezgrupowanego. Istotna rzecz przy podejmowaniu decyzji o utworzeniu indeksu zgrupowanego jest wybranie waciwej kolumny (kolumn). Dugo klucza powinna by jak najmniejsza, co umoliwia zmieszczenie wikszej iloci wpisw indeksu na jednej stronie, co z kolei przenosi si na zmniejszenie iloci stron caoci indeksu i w efekcie mniej operacji wejcia/wyjcia do wykonania przez serwer. eby indeks zgrupowany korzystnie wpywa na wydajno przy dodawaniu nowych wierszy do mocno wykorzystywanej tabeli, klucz powinien przyjmowa dla kolejnych wpisw wartoci rosnce (zwykle stosowana jest tu kolumna z cech IDENTITY).Indeks daje duy zysk wydajnoci gdy jego klucz jest moliwie wysoko selektywny (co oznacza mniejsz liczb kluczy o tej samej wartoci duplikatw).Istotny jest take fakt, e kolumny klucza indeksu zgrupowanego nie powinny by raczej modyfikowane, gdy pociga to za sob konieczno modyfikowania nie tylko stron indeksu ale take porzdkowania stron danych.

*Indeksy zgrupowane nie wyczerpuj moliwoci budowania tego typu struktur w SQL Serverze 2008. Drugim typem indeksw s indeksy niezgrupowane (nonclustered). Ich budowa odbiega nieco od budowy indeksu zgrupowanego, a do tego indeksy niezgrupowane mog by tworzone w oparciu o stert lub istniejcy indeks zgrupowany. Dla jednej tabeli mona utworzy do 248 indeksw niezgrupowanych.

Indeks niezgrupowany rni si od zgrupowanego przede wszystkim tym, e w swojej strukturze na poziomie lici ma take strony indeksu (a nie strony danych).W przypadku budowania indeksu niezgrupowanego na stercie, strony te oprcz wartoci klucza indeksu zawieraj wskaniki do konkretnych stron na stercie, ktre dopiero zawieraj odpowiednie dane. *Indeksy niezgrupowane maj struktur zblion do zgrupowanych. Zasadnicza rnica polega na zawartoci lici indeksu. O ile indeksy zgrupowane maj w tym miejscu strony danych, to indeksy niezgrupowane strony indeksu. Strony te zalenie od wariantu indeksu niezgrupowanego zawieraj oprcz klucza rne informacje. Indeksy niezgrupowane mog by tworzone w oparciu o stert. Jest to moliwe tylko w przypadku, gdy tabela nie posiada indeksu zgrupowanego. W takim przypadku licie indeksu zawieraj wskaniki do konkretnych stron na stercie. *Indeks niezgrupowany tworzony na tabeli posiadajcej ju indeks zgrupowany tworzony jest nieco inaczej. Korze, gazie i licie zawieraj strony indeksu, ale licie zamiast wskanikw do stron na stercie zawieraj wartoci klucza indeksu zgrupowanego. Kade wyszukanie w oparciu o indeks niezgrupowany, po dojciu do poziomu lici, zaczyna dalsze przetwarzanie od korzenia indeksu zgrupowanego (wyszukiwany jest klucz zawarty w liciu).*W przypadku budowania indeksw niezgrupowanych, szczeglnie na duych tabelach warto dobrze zaplanowa t czynno, szczeglnie gdy planowane jest te utworzenie indeksu zgrupowanego. Niewzicie tego pod uwag moe powodowa konieczno przebudowywania indeksw niezgrupowanych w zwizku z dodaniem lub usuniciem indeksu zgrupowanego.*Gdy zlecamy serwerowi wykonanie zapytania rozpoczyna si do zoony proces prowadzcy do okrelenia sposobu realizacji zapytania. Zalenie od konstrukcji samego zapytania, rozmiarw tabel, istniejcych indeksw, statystyk itp. serwer tworzy kilka planw wykonania zapytania. Nastpnie spord nich wybierany jest ten, ktry cechuje si najniszym kosztem wykonania ( wyraanym przez koszt operacji wejcia/wyjcia oraz czasu procesora). Tak wybrany plan jest nastpnie kompilowany (przetwarzany na posta gotow do wykonania przez silnik bazodanowy) i przechowywany w buforze w razie gdyby mgby si przyda przy kolejnym wykonaniu podobnego zapytania. W ramach tego punktu zajmiemy si nieco dokadniej procesem wykonania zapytania przez SQL Server.

*Cay proces przebiegajcy od momentu przekazania zapytania do wykonania do odebrania jego rezultatw jest do zoony i moe stanowi temat niejednego wykadu. Postaramy si cho z grubsza zasygnalizowa najistotniejsze etapy tego procesu. Parsowanie zapytania polega na zweryfikowaniu skadni polecenia, wychwyceniu bdw i nieprawidowoci w jego strukturze. Jeeli takowe bdy nie wystpuj, to efektem parsowania jest tak zwane drzewo zapytania (posta przeznaczona do dalszej obrbki) Standaryzacja zapytania. Na tym etapie drzewo zapytania jest doprowadzane do postaci standardowej usuwana jest ewentualna nadmiarowo, standaryzowana jest posta podzapyta itp.. Efektem tego etapu jest ustandaryzowane drzewo zapytania.Optymalizacja zapytania. Polega na wygenerowaniu kilku planw wykonania zapytania oraz przeprowadzeniu ich analizy kosztowej zakoczonej wybraniem najtaszego planu wykonania.Kompilacja polega na przetumaczeniu wybranego planu wykonania do postaci kodu wykonywalnego przez silnik bazodanowyOkrelenie metod fizycznego dostpu do danych ( skanowanie tabel, skanowanie indeksw, wyszukiwanie w indeksach itp..)*Proces optymalizacji zapytania skada si z kilku etapw. W ich skad wchodz: analizowanie zapytania pod ktem kryteriw wyszukiwania i zcze, dobranie indeksw mogcych wspomc wykonanie zapytania, oraz okrelenie sposobw realizacji zcze. W ramach realizacji poszczeglnych etapw optymalizator zapyta moe korzysta z istniejcych statystyk indeksw, generowa je dla wybranych indeksw lub wrcz tworzy nowe indeksy na potrzeby wykonania zapytania.Efektem tego procesu jest plan wykonania o najniszym koszcie, ktry jest nastpnie przekazywany do kompilacji i wykonania.

Plan wykonania dla zapytania mona podejrze w formie tekstowej, XML bd zbioru wierszy. Realizuje si to za pomoc ustawienia na ON jednej z opcji SHOWPLAN_TEXT, SHOWPLAN_XML, SHOWPLAN_ALL.*Na kolejnych przykadach postaramy si zademonstrowa wpyw indeksw na plan wykonania zapytania i jego cakowity koszt. Zapytania bd dotyczyy tabeli Klienci, w ktrej na chwil obecn nie ma adnego indeksu. Z tego powodu mona przewidywa, e operacj wykorzystan do realizacji zapytania bdzie skanowanie tabeli (table scan).*Zgodnie z oczekiwaniami, do realizacji zapytania wykorzystana zostaa operacja skanowania tabeli. Przy pierwszym wykonaniu konieczne byo pobranie stron danych z dysku (liczba fizycznych odczytw wiksza od 0). Kade nastpne wykonanie korzysta ju ze stron umieszczonych w cache, czego przejawem jest zerowa warto fizycznych odczytw.Cakowity koszt zapytania realizowanego wedug tego planu jest rwny 2,1385.*Pierwszym etapem naszych dziaa jest utworzenie indeksu zgrupowanego na kolumnie ID. Nie przyczyni si to w znaczcym stopniu do zwikszenia wydajnoci, ale spowoduje zmian planu wykonania. Skoro utworzenie indeksu zgrupowanego powoduje fizyczne uporzdkowanie stron danych (i likwidacje sterty), to plan wykonania powinien zawiera wykonanie innej operacji ni skanowanie tabeli. Po wykonaniu zapytania stwierdzamy, e faktycznie tak jest. Tym razem serwer skorzysta z operacji skanowania indeksu zgrupowanego. Nie jest to aden skok wydajnociowy, bo tak czy siak przejrze trzeba wszystkie strony danych, gdy nasze kryterium wyszukiwania nie jest kolumna zawart w indeksie.*Rozpocznijmy teraz dziaania ukierunkowane na obnienie kosztw realizacji zapytania. Pierwszy pomys stwrzmy indeks niezgrupowany na kolumnie nazwisko, ktra jest wykorzystywana jako kryterium wyszukiwania. Powinno to spowodowa wykorzystanie tego indeksu do wyszukania wierszy z nazwiskami z okrelonego przez nas zakresu. Niestety po wykonaniu zapytania doznalimy rozczarowania. Plan wykonania si nie zmieni! Dlaczego? Z powodu umieszczenia na licie kolumn wyjciowych kolumny Imie. Optymalizator zapyta stwierdzi, e mimo istnienia indeksu niezgrupowanego na kolumnie po ktrej wyszukujemy, nie warto z niego korzysta, gdy i tak trzeba sign do stron danych, eby pobra wartoci kolumny Imie. Z tego powodu plan wykonania nie uleg zmianie.*Skoro przemylelimy ju mechanizm dziaania zapytania i role indeksu, doprowadmy spraw do koca. Usumy istniejcy indeks niezgrupowany, utwrzmy go na nowo z dodan kolumn Imie. Po wykonaniu zapytania po raz kolejny, okazuje si, e tym razem indeks zosta wykorzystany. Odpowiednie wiersze speniajce kryteria wyszukiwania zostay zlokalizowane bardzo atwo dziki indeksowi niezgrupowanemu. Dodatkowo nie byo koniecznoci sigania do stron danych, gdy indeks zawiera take kolumn Imie, ktra bya potrzebna do realizacji zapytania. Efekt jest widoczny. Koszt realizacji zapytania spad z 2,1385 do 0,0453!*Dla zapewnienia bezpieczestwa danych istotne jest take wykonywanie ich kopii zapasowych. SQL Server posiada oczywicie zestaw polece i narzdzi, ktre su do tego celu. Mimo moliwoci oferowanych przez narzdzia, najwiksza odpowiedzialno ley i tak po stronie czowieka. Nawet najlepsze narzdzia nie zagwarantuj sprawnego odtworzenia stanu systemu po awarii jeeli wczeniej zabrako planu zarwno wykonywania kopii zapasowych jak i odtwarzania stanu systemu po awarii.

*Pierwszym zagadnieniem, ktre trzeba rozway przy planowaniu strategii wykonywania kopii zapasowych bazy danych jest model odtwarzania (recovery model). Od niego zaley jakie rodzaje kopii zapasowych bdziemy mogli wykonywa oraz w jakim stopniu odtwarza system po awarii.Najprostszym trybem odtwarzania jest tryb Simple Recovery. W tym trybie osoba administrujca baz danych jest zwolniona z obowizkw zwizanych z utrzymaniem logu transakcji (kopie zapasowe, obcinanie i kontrolowanie rozmiaru). Kosztem jest natomiast moliwo odtworzenia stanu systemu po awarii jedynie do stanu z ostatniej kopii zapasowej (penej lub penej i rnicowej).

Tryb Full Recovery daje pene moliwoci w zakresie wykonywania i odtwarzania kopii zapasowych. Oprcz kopii penych i rnicowych mona wykonywa kopie logu transakcji. Daje to znacznie wiksze moliwoci przy odtwarzaniu stanu systemu po awarii. Z drugiej strony administrator jest obarczony dodatkowymi obowizkami wynikajcymi z koniecznoci dbania o log transakcji.

*Do wykonywania kopii zapasowych suy polecenie BACKUP. Za jego pomoc mona wykonywa kopie caej bazy (BACKUP DATABASE), logu transakcji (BACKUP LOG) lub poszczeglnych plikw wchodzcych w skad bazy danych (BACKUP FILE).Kopia zapasowa caej bazy danych moe by wykonana jako kopia pena (full backup) lub kopia rnicowa (differential backup).Wykonywanie kopii zapasowej logu transakcji jest moliwe tylko przy bazie dziaajcej w trybie full recovery.*Wykonywanie kopii zapasowych nie jest celem samym w sobie. Jego istot jest umoliwienie odtworzenia stanu systemu sprzed awarii. Polecenie, ktre suy do odtwarzania danych (RESTORE) z kopii zapasowej posiada takie same warianty jak polecenie BACKUP (DATABASE, LOG, FILE).

Przy odtwarzaniu danych z wicej ni jednej kopii zapasowej trzeba pamita, by wszystkie kopie z wyjtkiem ostatniej odtwarzane byy z opcj NORECOVERY, ktra pozostawia baz w stanie niespjnoci i umoliwia odtwarzanie danych z kolejnych kopii. Dopiero ostatnia kopia jest odtwarzana z opcj RECOVERY (jest to domylne dziaanie polecenia RESTORE) co powoduje wycofanie niezatwierdzonych transakcji i powrt bazy danych do stanu stabilnego .*Sama umiejtno korzystania z polece czy narzdzi do wykonywania kopii zapasowych i odtwarzania z nich baz danych nie wystarczy, eby mc powiedzie, e nasze dane s bezpieczne. Istotniejszym elementem jest waciwie opracowana i dopasowana do wymaga strategia wykonywania kopii zapasowych i odtwarzania danych po awarii. Zaplanowanie takiej strategii nie jest bynajmniej zadaniem trywialnym i czsto zdarza si, e po awarii, mimo posiadania caego zestawu kopii zapasowych nie udaje si odtworzy danych i doprowadzi ich do wymaganego stanu.Podstaw planowania strategii s wymagania dotyczce bezpieczestwa danych: Jak dugo moe trwa proces przywracania bazy danych do stanu uywalnoci? Na utrat ilu danych mona sobie pozwoli (z ostatniej godziny, trzech godzin, kwadransa, czy najlepiej bez strat danych)Duy wpyw na posta strategii ma rozmiar bazy danych. Im wikszy tym trudniej osign zgodno z wymaganiami.Integralnym skadnikiem strategii jest plan (procedura) odtwarzania bazy po awarii. Bez takiego dokumentu bardzo atwo doprowadzi do sytuacji, w ktrej nerwy i stres towarzyszce awarii spowoduj, e administrator popeni bd, ktry moe zniweczy szanse na odtworzenie danych do wymaganej postaci. Nie bez kozery administratorzy mawiaj, e jeeli dojdzie do awarii to pierwsza rzecz, ktr naley wykona to usi z dala od klawiatury i uspokoi si. Kolejnym krokiem jest zwykle wykonanie kopii zapasowej logu transakcji. Dopiero potem przechodzi si do dalszych krokw. Jeeli s one precyzyjnie opisane i najlepiej przewiczone praktycznie to szanse na odzyskanie danych znaczco rosn.****

mechanizmy wewnętrzne baz danych – czyli co w bazach „piszczy”

Documents