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

Mechanizmy wewnętrzne baz danych – czyli co w bazach „piszczy”
Na przykładzie SQL Server 2008 Na hasło „relacyjna baza danych” pierwszym skojarzeniem jest zwykle tabela lub kilka tabel. Niestety w tym miejscu kończy się wiedza części programistów i w tworzonych przez nich aplikacjach baza danych jest wykorzystywana jedynie jako prymitywna składnica danych. Wszelkie operacje weryfikacji poprawności danych, zapewnienia im spójności i sensowności oraz samo przetwarzanie danych odbywa się w ramach logiki aplikacji. Taka architektura aplikacji nie jest dobrym pomysłem i bardzo szybko okazuje się być niewystarczająca a wręcz szkodliwa lub uniemożliwiająca korzystanie z aplikacji ze względu na skrajnie kiepską wydajność oraz, co ważniejsze, na błędy i niespójności w danych przechowywane w bazie. Co więc można zrobić, żeby zadbać nieco bardziej o cenne dane, które chcemy gromadzić w bazie? Przede wszystkim poznać nieco bliżej możliwości, które oferowane są przez relacyjne bazy danych w zakresie zapewnienia spójności przechowywanym danym. W ramach niniejszego wykładu postaramy się przybliżyć kilka takich mechanizmów, a także zaprezentować sporą ilość dodatkowych informacji, które pozwolą spojrzeć na bazę danych , jako na twór, który można w bardzo szerokim zakresie kształtować, wzbogacać jego funkcjonalność, definiować najprzeróżniejsze ograniczenia mające zastosowanie do przechowywanych danych tak, aby móc spełnić wymagania stawiane tworzonemu systemowi informatycznemu oraz zapewnić bezpieczeństwo i spójność przechowywanym danym. informatyka +

informatyka + Agenda Więzy integralności referencyjnej Transakcje
Poziomy izolacji transakcji Wyzwalacze Rodzaje wyzwalaczy Procedury składowane i funkcje użytkownika Indeksy Fizyczna organizacja danych w SQL Server 2008 Rodzaje indeksów (zgrupowane, niezgrupowane) Optymalizacja zapytań i plany wykonania Kopie bezpieczeństwa i odtwarzanie danych Podsumowanie Zakres wykładu obejmuje wybrane zagadnienia dotyczące mechanizmów dostępnych w ramach bazy danych. Omówione zostaną więzy integralności referencyjnej wraz z zaprezentowaniem przykładów i dobrych praktyk ich dotyczących. Drugim zagadnieniem będą transakcje – zapoznamy się z istota transakcyjności, trybami tworzenia transakcji oraz z poziomami izolacji i ich specyfiką. W ramach omawiania wyzwalaczy zademonstrowane zostaną poszczególne ich rodzaje oraz opisana zostanie ich specyfika. Kolejnym zagadnieniem będą indeksy. Zapoznamy się z fizyczną organizacją danych w SQL Serverze 2008 i z jej konsekwencjami. Omówiona zostanie też struktura różnych rodzajów indeksów, a także zaprezentowany zostanie proces optymalizacji zapytania z wykorzystaniem indeksu pokrywającego Istotnym zagadnieniem są też kwestie związane z wykonywaniem kopii bezpieczeństwa baz danych oraz z odtwarzaniem danych z takich kopii. informatyka + 2

Poziomy izolacji transakcji Wyzwalacze Rodzaje wyzwalaczy Procedury składowane i funkcje użytkownika Indeksy Fizyczna organizacja danych w SQL Server 2008 Rodzaje indeksów (zgrupowane, niezgrupowane) Optymalizacja zapytań i plany wykonania Kopie bezpieczeństwa i odtwarzanie danych Podsumowanie Rozpoczniemy od mechanizmu zwanego więzami integralności referencyjnej. Jest on istotnym mechanizmem, gdyż umożliwia definiowanie relacji pomiędzy tabelami oraz zapewnia spójność takiej relacji. informatyka + 3

Więzy integralności referencyjnej
W bazach danych często występuje konieczność zdefiniowana relacji pomiędzy dwoma tabelami np.: klient jest właścicielem rachunku bankowego rachunek jest określonego typu (oszczędnościowy, rozliczeniowy…) Do tego celu służą więzy integralności referencyjnej Chcemy powiązać klienta z rachunkiem bankowym: Wymaganie: Rachunek ma dokładnie jednego właściciela. JAK? Przy projektowaniu bazy danych standardową praktyką jest doprowadzenie struktury bazy do tzw. trzeciej postaci normalniej. Prowadzi to do powstania większej liczby mniejszych (zawierających mniej kolumn) tabel. Żeby w takiej sytuacj zapewnić spójność danych, potrzebny jest specjalny mechanizm, który po zdefiniowaniu reguł powiązań miedzy tabelami będzie pilnował ich spójności. Właśnie do tego celu stworzony został jeden z rodzajów ograniczeń(constraints) – klucz obcy. Za jego pomocą możemy w wygodny sposób definiować reguły spójności danych pomiędzy tabelami. Wykorzystanie klucza obcego najlepiej będzie prześledzić na przykładzie. Załóżmy, że mamy w bazie dwie tabele (takie jak na slajdzie). Jedna zawiera dane klientów banku, druga – informacje o rachunkach bankowych. Na chwile obecną tabele te nie są w żaden sposób powiązane. Zastosujemy ograniczenie typu klucz obcy do realizacji wymagania mówiącego, że każdy rachunek ma tylko jednego właściciela. informatyka + 4

Dodajmy kilku klientów i zobaczmy ich dane: Rezultat: Mamy troje klientów o identyfikatorach 1, 2 i 3. Pierwszym krokiem będzie dodanie danych kilku klientów. W tabeli klienci stworzony został klucz podstawowy na kolumnie KlientID. Dodatkowo kolumna ta sama dba o nadawanie klientom kolejnych, unikalnych wartości identyfikatora – poprzez ustawienie właściwości IDENTITY. W takim przypadku efektem wykonania trzech kolejnych poleceń INSERT będzie dodanie trzech wierszy w tabeli klienci. Każdy z nich będzie miał automatycznie nadany i unikalny identyfikator – KlientID. Jak teraz powiązać tych klientów z rachunkami (określić kto jest właścicielem rachunku)? Poprzez dodanie do tabeli rachunki nowej kolumny (klientID) przechowującej identyfikator klienta, który jest właścicielem rachunku. informatyka + 5

Dodajmy teraz kilka rachunków i zobaczmy ich dane: Rezultat: Rachunki zostały utworzone (automatycznie nadane numery i daty utworzenia) Mamy cztery rachunki. Trzy należą do naszych klientów. Czwarty rachunek – nie wiadomo do kogo! Utraciliśmy właśnie spójność danych :-( Nie ma takiego klienta! Kolejnym krokiem będzie dodanie danych kilku rachunków bankowych. W tabeli Rachunki stworzony został klucz podstawowy na kolumnie RachunekID. Dodatkowo kolumna ta sama dba o nadawanie kolejnych, unikalnych wartości identyfikatora rachunkom – poprzez ustawienie właściwości IDENTITY. Kolejne kolumny – Numer i DataOtwarcia maja przypisane wartości domyślne, więc jeśli nie podamy dla nich wartości, to zostaną wygenerowane automatycznie. W związku z tym, efektem wykonania czterech kolejnych poleceń INSERT będzie dodanie czterech wierszy w tabeli rachunki. Każdy z nich będzie miał automatycznie nadany identyfikator, numer i datę otwarcia. Jedyną wartością podawaną przez nas przy dodawaniu danych jest identyfikator klienta. Trzy pierwsze wiersze są jak najbardziej poprawne i jasno przypisane do istniejących klientów (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 właśnie przez zastosowanie klucza obcego. informatyka + 6

Jak zabezpieczyć się przed tego typu błędami? Klucz obcy – kolumna lub kombinacja kolumn, która jest używana do określenia i wymuszenia relacji pomiędzy danymi z dwóch tabel Kolumna z kluczem podstawowym lub unikalnym Kolumna tego samego typu! Stworzone ograniczenie – klucz obcy Żeby utworzyć klucz obcy muszą być spełnione warunki: kolumny w obu tabelach muszą być tego samego typu kolumna w tabeli „nadrzędnej” musi być kluczem podstawowym tabeli lub posiadać indeks lub ograniczenie unikalne (unique). Klucz obcy tak jak inne ograniczenia można tworzyć dla tabeli za pomocą polecenia ALTER TABLE. Przy tworzeniu klucza obcego, domyślnie sprawdzane są istniejące dane pod kątem zgodności z jego definicją. informatyka + 7

Spróbujmy więc utworzyć klucz obcy na naszej tabeli rachunki: Nic z tego! Nie udało się utworzyć ograniczenia ze względu na istniejące dane (feralny rachunek z błędnym identyfikatorem właściciela) Rezultat: Msg 547, Level 16, State 0, Line 1 The 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 błędnych danych. Niestety. Próba utworzenia klucza obcego na tabeli rachunki zakończyła się niepowodzeniem! Przyczyną jest oczywiście jeden z wierszy w tej tabeli – ten z identyfikatorem nieistniejącego klienta. Przy tworzeniu klucza obcego sprawdzane są istniejące dane pod kątem zgodności z regułą klucza. Można to sprawdzenie wyłączyć poprzez zastosowanie klauzuli WITH NOCHECK przy tworzeniu klucza. Należy ją stosować tylko wtedy, gdy reguły biznesowe dopuszczają błędne wartości klucza lub ich brak dla danych istniejących, natomiast dla danych nowododawanych lub modyfikowanych reguły mają być już stosowane. Drugim wyjściem z sytuacji jest „naprawienie” danych przed utworzeniem klucza obcego. Zastosujemy ten wariant. informatyka + 8

Naprawiamy błędne dane: Ponowne wykonanie polecenia tworzącego klucz obcy kończy się sukcesem! Od tej pory baza nie pozwoli na utworzenie rachunku dla nieistniejącego klienta: Rezultat: Msg 547, Level 16, State 0, Line 1 The INSERT statement conflicted with the FOREIGN KEY constraint "FK_Rachunki_Klienci". The conflict occurred in database "Bank", table "dbo.Klienci", column 'KlientID'. Zmodyfikujmy wiersz w tabeli Rachunki zawierający błędny identyfikator klienta i ustawmy jego wartość na 2 (taki klient istnieje). Po wykonaniu tej operacji możemy już śmiało ponowić próbę utworzenia klucza obcego. Tym razem wszystko się udaje i zostaje on utworzony. Sprawdźmy jeszcze czy działa – dodajmy nowy rachunek dla nieistniejącego klienta (klientID = 15). Tym razem operacja nie udaje się, mechanizm klucza obcego zadziałał i skutecznie uniemożliwił nam wprowadzenie niespójności do danych. informatyka + 9

Nie ma natomiast problemu z dodaniem rachunku dla istniejącego klienta: Rezultat: Luka w numeracji – ślad po nieudanej próbie dodania rachunku Jeżeli próbujemy dodawać dane poprawne, czyli podajemy identyfikator istniejącego klienta, to oczywiście nie ma żadnego problemu z dodaniem nowego rachunku. informatyka + 10

Przy tworzeniu klucza obcego można korzystać z opcji ON DELETE i ON UPDATE. Służą one do określenia reakcji na usunięcie lub zmodyfikowanie wiersza (z tabeli z kluczem podstawowym) do którego odnosi się klucz obcy. Isnieją cztery warianty dla każdej : No action (domyślna) Nie podejmuje żadnej akcji. Cascade Usuwa/modyfikuje wiersz z kluczem obcym Set null Ustawia wartość null jako wartość kolumn klucza obcego (działa jeżeli te kolumny dopuszczają wartość null!) Set default Ustawia wartość domyślną dla kolumn klucza obcego (działa jeśli te kolumny maja określona wartość domyślną i spełnia ona regułę klucza lub dopuszcza wartość null. UWAGA! Bardzo wygodne i bardzo niebezpiecznie!!! Przy tworzeniu ograniczeń typu klucz obcy należy wspomnieć o kaskadowych więzach integralności referencyjnej. Ich istota polega na zdefiniowaniu w jaki sposób maja się zachować wiersze (i kolumny) klucza obcego w reakcji na usunięcie (lub zmodyfikowanie) wiersza (lub wartości klucza podstawowego). Można wybrać jeden z czterech wariantów takiej reakcji dla każdej z dwóch opcji (ON DELETE i ON UPDATE): No Action – jest to domyślny wariant, który nie powoduje podjęcia jakichkolwiek działań w związku z usunięciem czy zmodyfikowaniem wiersza do którego odwołuje się klucz obcy Cascade – jak sama nazwa wskazuje, powoduje kaskadowe usunięcie wierszy odwołujących się poprzez klucz obcy do usuwanego wiersza, lub modyfikację wartości kolumn klucza obcego w przypadku zmodyfikowania wartości klucza podstawowego, do którego się on odwołuje. Jest to opcja z jednej strony bardzo wygodna, gdyż zwalnia nas z „ręcznego” usuwania wierszy skojarzonych przez klucz obcy. Z drugiej strony zaś, przy odrobinie pecha można wyczyścić niechcący sporą część danych jednym niewinnym poleceniem usunięcia jednego wiersza z tabeli… Set Null – polega na tym, że w przypadku usunięcia wiersza do którego odwoływał się klucz obcy, kolumnom tegoż klucza przypisywana jest wartość null. Żeby opcja ta zadziałała, kolumny klucza obcego musza dopuszczać wartość null. Set Default – działanie zbliżone do Set null, z ta różnicą, że kolumny klucza obcego są ustawiane na wartość domyślną. Żeby opcja ta zadziałała, kolumny klucza muszą mieć określona wartość domyślną lub dopuszczać wartość null (na którą będą ustawione w przypadku braku wartości domyślnej) informatyka + 11

Usuńmy nasz klucz obcy i stwórzmy go na nowo z opcją ON DELETE CASCADE: Usuńmy teraz jednego klienta (posiadającego dwa rachunki): Pobranie listy wszystkich rachunków daje teraz rezultat: Usunęliśmy jeden wiersz z tabeli Klienci, a automatycznie zostały usunięte dwa rachunki należące do usuniętego klienta Ta opcja jest bardzo niebezpieczna!!! Sprawdźmy teraz w ramach przykładu działanie opcji ON DELETE CASCADE. W tym celu usuniemy klucz obcy z tabeli Rachunki, a następnie odtworzymy go z opcją ON DELETE CASCADE. Po wykonaniu tej operacji spróbujmy usunąć jeden wiersz z tabeli Klienci. Niech będzie to klient o identyfikatorze 2, który z tego co pamiętamy posiada dwa Rachunki (dwa wiersze w tabeli Rachunki z jego identyfikatorem w kolumnie klucza obcego). Po wykonaniu tego polecenia i pobraniu pełnej listy rachunków okazuje się, że zgodnie z naszymi oczekiwaniami po usunięciu klienta usunięte zostały jego rachunki. W tym miejscu jeszcze raz warto podkreślić, że jest to opcja bardzo niebezpieczna i przy bardziej złożonej strukturze tabel polecenie usunięcia jednego wiersza może spowodować „czystkę” w bazie danych. informatyka + 12

Garść faktów na temat kluczy obcych: Klucz obcy może zawierać więcej niż jedna kolumnę Uwaga! Jeśli w takim przypadku choć jedna z kolumn ma wartość null, to pozostałe nie są sprawdzane pod kątem zgodności z regułą klucza! Klucz obcy może odwoływać się do tej samej tabeli (samozłączenie) Stosowane do budowania hierarchii Łatwe w implementacji, trudne w obsłudze Alternatywą jest typ danych HierarchyID lub XML. Klucz obcy (podobnie jak ograniczenia typu CHECK) można włączać i wyłączać za pomocą polecenia ALTER TABLE z opcją CHECK lub NOCHECK CONSTRAINT. [nie mylić z WITH CHECK/ WITH NOCHECK !] Podsumowując tę część wykładu warto wspomnieć o jeszcze kilku cechach kluczy obcych. Po pierwsze klucz obcy nie musi być pojedynczą kolumną. Można go zdefiniować na kilku kolumnach, lecz trzeba wtedy pamiętać, że jeżeli te kolumny dopuszczają wartość null, a którakolwiek z nich będzie miała tę wartość, to pozostałe nie będą sprawdzane pod kątem zgodności z regułą klucza. Klucz obcy nie musi odwoływać się do kolumny lub kolumn z innej tabeli. W pewnych przypadkach tworzy się klucze obce odwołujące się do kolumn w tej samej tabeli. Mówimy wtedy o samozłączeniu. Takie rozwiązanie bywa stosowane na przykład do budowania danych o strukturze hierarchicznej. Przykładowo weźmy tabelę pracownicy, która ma kolumny: PracownikID (klucz podstawowy), Nazwisko Imie kierownikID (klucz obcy, dopuszczalna wartość null) Tak prosta struktura tabeli pozwala na zdefiniowanie hierarchii pracowników poprzez określenie kto jest czyim kierownikiem za pomocą wartości kolumny KierownikID, która jest kluczem obcym odwołującym się do kolumny z tej samej tabeli. W takiej hierarchii „szef wszystkich szefów” będzie miał wartość null w kolumnie kierownikID :) Rozwiązania oparte o taki schemat są bardzo łatwe w implementacji, lecz nieco uciążliwe w obsłudze, szczególnie gdy próbujemy się poruszać po hierarchii w poziomie… Alternatywą dla takich rozwiązań jest typ danych hierarchyID lub XML. Posiadają one unikalne cechy, które predestynują je do stosowania w określonych scenariuszach. Warto o nich poczytać zanim zdecydujemy się na zastosowanie konkretnego pomysłu. Ograniczenie typu klucz obcy może być włączane/wyłączane za pomocą polecenia ALTER TABLE z opcją CHECK/NOCHECK CONSTRAINT. Ważne jest, aby nie mylić tych opcji z WITH CHECK/NOCHECK. Usystematyzujmy: CHECK/NOCHECK – włącza lub wyłącza ograniczenie WITH CHECK/NOCHECK – powoduje sprawdzanie bądź nie, istniejących danych przy tworzeniu/włączaniu ograniczenia informatyka + 13

Poziomy izolacji transakcji Wyzwalacze Rodzaje wyzwalaczy Procedury składowane i funkcje użytkownika Indeksy Fizyczna organizacja danych w SQL Server 2008 Rodzaje indeksów (zgrupowane, niezgrupowane) Optymalizacja zapytań i plany wykonania Kopie bezpieczeństwa i odtwarzanie danych Podsumowanie Bardzo istotnym zagadnieniem związanym z relacyjnymi bazami danych jest mechanizm transakcji. Jest on podstawą, która pozwala na korzystanie z takich baz danych w ramach „poważnych” systemów informatycznych, które nie mogą sobie pozwolić na pojawianie się stanów nieustalonych w ramach danych. informatyka + 14

informatyka + Transakcje
Dane w bazie reprezentują aktualną sytuację biznesową Mogą zawierać dane o zamówieniach, informacje o procesie produkcyjnym, o alokacji określonych zasobów i ich statusie itd., itp.. Zmiany sytuacji biznesowej (stanu) powodują zmiany w danych w bazie Pojawiają się nowe wiersze, modyfikowane są istniejące, zdarzają się też usunięcia wierszy. Zmiana stanu powinna prowadzić od jednego stabilnego stanu do drugiego Wszelkie stany „przejściowe” spowodowane dowolnym czynnikiem są niedopuszczalne! Zapisanie tylko części zamówienia??? Przelew bankowy wykonany połowicznie (środki pobrane, ale nie umieszczone na docelowym rachunku) ??? Przy tworzeniu aplikacji bazodanowych rzadko zastanawiamy się czy baza zapewnia nam stabilność i bezpieczeństwo danych. Przyjmujemy, że tak. Warto natomiast zdawać sobie sprawę jakie mechanizmy leżą u podstaw tego przekonania. W ramach wykładu omówimy jeden z podstawowych mechanizmów – transakcje. W systemie informatycznym dane w bazie reprezentują zwykle aktualny stan biznesu (procesu produkcji, stanów magazynowych, alokacji zasobów itp.) Jako, że sytuacja biznesowa jest zmienna, to dane w bazie także podlegają ciągłym zmianom. Każda z takich zmian stanowi swego rodzaju całość i składa się często z wielu elementarnych modyfikacji danych. Tylko prawidłowe wykonanie wszystkich kroków w ramach takiej zmiany ma sens z punktu widzenia biznesowego. W takiej sytuacji nietrudno wyobrazić sobie do czego może prowadzić przerwanie takiej złożonej operacji w trakcie jej realizacji – powstaje stan nieustalony. Jest to niedopuszczalna sytuacja, która może wprowadzać chaos. Na szczęście serwery baz danych potrafią sobie z nią radzić. Jak? Właśnie poprzez mechanizm transakcji. informatyka + 15

Transakcja to sekwencja logicznie powiązanych operacji na danych, których celem jest przejście bazy danych z jednego stanu spójnego do drugiego Właściwości transakcji – akronim ACID Atomicity (atomowość) Operacje w ramach transakcji są niepodzielne. Albo wykonają się w całości, albo wcale Consistency (spójność) Baza danych jest w stanie spójnym zarówno przed rozpoczęciem transakcji jak i po jej zakończeniu (nieważne czy transakcja zakończyła się sukcesem czy porażką) Isolation (odizolowanie) Transakcje są od siebie logicznie odseparowane. Z punktu widzenia transakcji – wykonywane sekwencyjnie Durability (trwałośc) Jeżeli transakcja została zatwierdzona, to niezależnie od awarii systemu nie może zostać cofnięta bądź utracona Transakcją nazywamy sekwencję logicznie powiązanych ze sobą operacji na danych zawartych w bazie, które przeprowadzają bazę danych z jednego stanu spójnego do drugiego. Na początku lat osiemdziesiątych XX wieku pojawił się akronim ACID (Atomicity, Consistency, Isolation, Durability) określający w zwięzły i łatwy do zapamiętania sposób podstawowe właściwości transakcji: Atomicity (atomowość) definiuje właściwość określającą, że transakcja jest niepodzielna. Oznacza to, że albo wszystkie operacje wchodzące w jej skład wykonają się poprawnie w całości, albo wcale. Nie istnieje możliwość wykonania części transakcji. Consistency (spójność) oznacza, że baza danych przed rozpoczęciem znajduje się w stanie stabilnym i po zakończeniu transakcji (niezależnie 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ą oddziaływać między sobą tak, jakby były wykonywane sekwencyjnie. Durability (trwałość) jest właściwością, która gwarantuje, że jeżeli transakcja została zatwierdzona, to nawet w przypadku awarii systemu lub zasilania, nie zostanie utracona lub wycofana Wszystkie te cechy zostały zaimplementowane w serwerach baz danych i dzięki temu mamy zapewniona spójność danych i gwarancję, że niezależnie od okoliczności baza danych będzie zawsze w stabilnym stanie. Ma to kluczowe znaczenie dla większości systemów informatycznych tworzonych na potrzeby biznesu i nie tylko. informatyka + 16

Skoro to takie ważne, to czy nie wystarczy kolejkowanie transakcji i sekwencyjnie ich wykonywanie? Nie. To kwestia wydajności! Takie podejście powodowałoby drastyczny spadek wydajności wraz ze wzrostem liczby transakcji (użytkowników) Zależnie od specyfiki operacji wykonywanych w ramach transakcji można starać się zrównoleglać wykonywanie innych transakcji i operacji odczytu danych. Możliwości „zrównoleglania” operacji sterowane są poprzez mechanizm blokad (locks). Pojęcie poziomu izolacji odnosi się właśnie do tego zagadnienia - jakie blokady i na jaki czas są konieczne, żeby zapewnić odpowiedni poziom bezpieczeństwa dla transakcji. Skoro istnieje problematyka spójności danych, to czy nie jest dobrym rozwiązaniem kolejkowanie transakcji i wykonywanie ich sekwencyjnie? Zapewniłoby to brak konfliktów przy modyfikacji danych z poziomu różnych transakcji. Niestety nie jest to jedyny problem. Równie istotna pozostaje kwestia wydajności, a przy zaproponowanym podejściu nie byłaby ona zadowalająca. Żeby móc podnieść wydajność i jednocześnie zachować wszystkie właściwości transakcji istnieje kilka tzw. poziomów izolacji. Każdy z nich korzysta z nieco innej strategii stosowania blokad, co pozwala na zrównoleglanie niektórych operacji modyfikacji danych i ich odczytu z poziomu innych transakcji. informatyka + 17

SQL Server obsługuje dwa tryby rozpoczynania transakcji: Jawny (explicit) Transakcja rozpoczyna się poleceniem BEGIN TRANSACTION Niejawny (implicit) Każde pierwsze polecenie modyfikujące dane( m.in. INSERT, UPDATE, DELETE) powoduje rozpoczęcie transakcji Transakcję należy zakończyć jawnie (COMMIT lub ROLLBACK) Wyłącza tryb autocommit! Domyślnie SQL Server działa w trybie autocommit Każde polecenie modyfikujące dane (m.in. INSERT, UPDATE, DELETE) powoduje rozpoczęcie transakcji. Poprawne wykonanie polecenia powoduje automatyczne zatwierdzenie (COMMIT) transakcji. Błąd w trakcie wykonania polecenia powoduje automatyczne wycofanie (ROLLBACK) transakcji Domyślnie SQL Server jest skonfigurowany w ten sposób, że transakcje obsługuje w trybie autocommit. Oznacza to, że transakcje są automatycznie rozpoczynane po natrafieniu na polecenie modyfikujące dane lub strukturę bazy, oraz zatwierdzane zaraz po poprawnym wykonaniu tego polecenia. Można oczywiście sterować procesem tworzenia i zatwierdzania transakcji. Realizuje się to poprzez korzystanie z trybu IMPLICIT TRANSACTION – w którym transakcje rozpoczynane są tak jak w trybie autocommit, ale wymagają „ręcznego” zakończenia poprzez wydanie polecenia COMMIT lub ROLLBACK. Drugim wariantem jest tryb EXPLICIT TRANSACTIONS, który polega na rozpoczynaniu transakcji poleceniem BEGIN TRANSACTION i kończeniu jej poleceniem COMMIT lub ROLLBACK(tak jak w IMPLICIT). informatyka + 18

informatyka + Transakcje 19 Transakcje mogą być zagnieżdżane: UWAGA!
COMMIT dla transakcji zagnieżdżonej tak naprawdę nie ma żadnego efektu… jedynie zmniejsza poziom zagnieżdżenia. ROLLBACK powoduje wycofanie wszystkich transakcji łącznie z główną (zawierającą zagnieżdżone pozostałe). Ustawia poziom zagnieżdżenia na 0 ROLLBACK z parametrem (nazwa punktu zapisu) wycofuje transakcje do tego punktu. Nie powoduje zmiany poziomu zagnieżdżenia. Transakcje mogą być zagnieżdżane. Może się to odbywać nie tylko w sposób pokazany na slajdzie, ale także w bardziej złożony – na przykład mamy rozpoczętą transakcję, a w jej ramach wywołujemy procedurę składowaną, która wewnątrz swojego kodu zawiera także transakcję. Procedura może próbować wykonać jakąś operację w ramach swojej transakcji, a w przypadku porażki wycofać ją, wykonać alternatywny kod i zakończyć działanie. W takiej sytuacji zewnętrzna transakcja może być kontynuowana i zatwierdzona poprawnie. Przy zagnieżdżaniu transakcji warto pamiętać, że mechanizm ten nie działa do końca w intuicyjny sposób – pary poleceń BEGIN TRANSACTION i COMMMIT (lub ROLLBACK) nie pełnią roli pary nawiasów. Żeby uniknąć problemów warto dokładnie się zapoznać z mechanizmem działania transakcji zagnieżdżonych i przećwiczyć go w praktyce. informatyka + 19

Aktualny poziom zagnieżdżenia transakcji można odczytać ze zmiennej Rozpoczynając transakcje można nadać jej nazwę. W trakcie transakcji można tworzyć za pomocą polecenia SAVE dodatkowe punkty zapisu (savepoint), do których będzie można wycofywać częściowo transakcję przez wywołanie polecenia ROLLBACK z parametrem – nazwą punktu zapisu. SQL Server posiada wbudowana zmienna w której przechowywany jest aktualny poziom zagnieżdżenia. Jeśli nie ma w danej chwili żadnej aktywnej transakcji – ma wartość 0. Każde polecenie BEGIN TRANSACTION zwiększa wartość zmiennej Dzięki temu przy tworzeniu kodu procedur składowanych możemy zawsze łatwo sprawdzić na jakim poziomie zagnieżdżenia jesteśmy i odpowiednio zareagować. Przy bardziej złożonych transakcjach można budować bardziej skomplikowany przebieg transakcji. Przeznaczone do tego celu jest polecenie SAVE, które tworzy w ramach transakcji punkt, do którego może być ona cofnięta bez konieczności wycofywania całej transakcji. Pozwala to na budowanie alternatywnych ścieżek realizacji transakcji. informatyka + 20

Poziomy izolacji transakcji Wyzwalacze Rodzaje wyzwalaczy Procedury składowane i funkcje użytkownika Indeksy Fizyczna organizacja danych w SQL Server 2008 Rodzaje indeksów (zgrupowane, niezgrupowane) Optymalizacja zapytań i plany wykonania Kopie bezpieczeństwa i odtwarzanie danych Podsumowanie informatyka + 21

Konflikty i problemy występujące przy dostępie do danych poziomu więcej niż jednej transakcji (w przykładach są to transakcje T1 i T2): Lost update (zgubiona modyfikacja) T1 i T2 modyfikują wartość kolumny jedna po drugiej. Tylko ostatnia modyfikacja (zatwierdzona transakcja) będzie widoczna w bazie. Dirty read (brudny odczyt) T1 modyfikuje dane. Przed jej zatwierdzeniem, T2 odczytuje zmodyfikowane dane i wykorzystuje je. Jeśli T1 zostanie wycofana to T2 pracuje na niepoprawnych lub nieistniejących danych – niespójność! Przy realizacji więcej niż jednej transakcji w tym samym czasie mogą pojawić się różne problemy związane z uzyskiwaniem przez nie dostępu do danych i modyfikowaniem ich. Typowe przykłady takich zjawisk to : Lost update (zgubiona modyfikacja). Zjawisko to można zilustrować przykładem, gdy dwie transakcje T1 i T2 odczytały wartość z bazy, następnie każda z nich próbuje zapisać tę wartość po modyfikacji. W takim przypadku transakcja, która zostanie zatwierdzona później, nadpisze modyfikacje dokonane przez transakcję zatwierdzoną wcześniej. Dirty read(brudny odczyt) .Typowy przykład to zliczanie odwiedzin strony przez użytkowników aplikacji. Polega ono na odczytaniu aktualniej liczby odwiedzin z bazy, powiększeniu jej o 1 i zapisaniu z powrotem do bazy. Jeśli 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), następnie inkrementuje ją. W tym momencie T1 zostaje wycofana (wartość powinna zostać ponownie zmieniona na 5). T2 zostaje zatwierdzona i w bazie ląduje wartość 7, co stanowi ewidentny błąd. informatyka + 22

Konflikty i problemy występujące przy dostępie do danych poziomu więcej niż jednej transakcji ( w przykładach są to transakcje T1 i T2): Nonrepeatable Read (niepowtarzalny odczyt) T1 odczytuje te same dane dwukrotnie w trakcie działania. Pomiędzy jednym a drugim odczytem T2 modyfikuje te dane i zostaje zatwierdzona. W związku z tym drugi odczyt danych z poziomu T1 pobiera inne wartości niż pierwszy! Może to prowadzić do niespójności. Phantom reads (odczyt – widmo) T1 modyfikuje dane z określonego zakresu i następnie pobiera je do dalszej analizy. Pomiędzy modyfikacją a odczytem, T2 dodaje nowe wiersze do modyfikowanego przez T1 zakresu. T1 odczytuje dane i uzyskuje wiersze, których nie było przy modyfikacji. Nonrepeatable reads (niepowtarzalny odczyt). Przykładem może być transakcja T1, w której pobierane są do modyfikacji wszystkie niezrealizowane zamówienia. W kolejnym kroku informacje te są przetwarzane. W tym czasie transakcja T2 modyfikuje status kilku zamówień (zmienia na zrealizowane) i zostaje zatwierdzona. Teraz z kolei T1 ponownie sięga do listy zamówień niezrealizowanych i… otrzymuje listę inną niż poprzednio, co może spowodować błędy w przetwarzaniu danych – załóżmy, że po pierwszym odczycie tworzone były zlecenia dla magazynierów (pobranie towarów dla zamówień), a przy drugim były generowane listy przewozowe. Efektem będzie niespójność - brak kilku listów przewozowych. Phantom reads (odczyt-widmo). Sytuacja może być podobna jak poprzednio. Transakcja T1 pobiera zamówienia 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 sięga po dane zamówień i otrzymuje dodatkowe dwa zamówienia, dla których nie zostały wykonane czynności z pierwszego etapu przetwarzania! Podobnie jak poprzednio nie jest to dobra sytuacja i prowadzi do powstania niespójności. informatyka + 23

informatyka + Transakcje 24
Standard ANSI definiuje cztery poziomy izolacji dla transakcji. Każdy z nich cechuje się eliminowaniem szans na wystąpienie kolejnego rodzaju konfliktu: [poziom domyślny został wyróżniony] SQL Server posiada dwa dodatkowe poziomy izolacji (bazujące na wersjonowaniu wierszy): jeden jest implementacją poziomu READ COMMITED, drugi to poziom SNAPSHOT (funkcjonalnie zbliżony do SERIALIZABLE) Poziom izolacji Dirty read Nonrepeatable read Phantom READ UNCOMMITED TAK READ COMMITED NIE REPEATABLE READ SERIALIZABLE W zależności od operacji wchodzących w skład transakcji oraz specyfiki aplikacji, która z bazy danych korzysta możemy stosować jeden z kilku poziomów izolacji transakcji. Każdy z nich cechuje się tym, że eliminuje możliwość wystąpienia kolejnego rodzaju konfliktu, przez co podnosi poziom bezpieczeństwa transakcji, ale jednocześnie powoduje obniżenie wydajności. Celem projektantów baz danych i aplikacji jest znalezienie rozsądnego kompromisu pomiędzy wydajnością a poziomem izolacji dla konkretnych transakcji przeprowadzanych w ramach działania aplikacji. Każdy rodzaj transakcji przeprowadzanej przez aplikację warto przeanalizować pod kątem wymaganego poziomu izolacji. Dąży się do tego, aby stosować możliwie najniższy poziom izolacji, aby móc zachować z jednej strony bezpieczeństwo i spójność danych, a z drugiej zadowalającą wydajność. informatyka + 24

Przy transakcjach warto wspomnieć o jeszcze jednym negatywnym zjawisku – zakleszczeniu. Rysowanie wykresu: - linijka - kreda Dwie osoby chcą narysować wykres. Potrzebne do tego są: linijka i kreda. Pierwsza osoba sięga po kredę, druga po linijkę… W efekcie pierwsza zaczyna czekać na linijkę, druga na kredę… Rozwiązanie – wylosować osobę (deadlock victim), zabrać jej linijkę lub kredę i oddać drugiej. Przy realizacji wielu transakcji jednocześnie 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 rozwiązaniem jest wycofanie jednej z zakleszczonych transakcji. Obrazowo problem zakleszczenia można przedstawić na przykładzie rysowania wykresu na tablicy. Potrzebne do tego są dwa zasoby: linijka i kreda. Przyjmijmy, że mamy dwóch chętnych do rysowania wykresu. Wiedzą oni co jest do tego potrzebne. Pierwszy ochotnik sięga po kredę i zaczyna rozglądać się za linijką. W tym samym czasie drugi ochotnik chwycił linijkę i szuka kredy. Dochodzi do sytuacji, w której obaj blokują sobie nawzajem potrzebne zasoby czekając 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 błędu. To pozwala drugiej z transakcji na uzyskanie wszystkich potrzebnych zasobów i zrealizowanie wszystkich zaplanowanych czynności. informatyka + 25

Minimalizowanie szansy na wystąpienie zakleszczenia Sięganie do zasobów wg tej samej kolejności! Rysowanie wykresu: - linijka - kreda Czekam na linijkę Chwyciłem linijkę  Teraz tylko kreda… Zakleszczenie jak już wspominaliśmy jest nie do uniknięcia. Jedyne co można zrobić to starać się minimalizować szanse jego wystąpienia. Wbrew pozorom nie musi to być strasznie skomplikowane zajęcie. Często sięganie do zasobów w tej samej kolejności pozwala na wyeliminowanie większości przypadków zakleszczeń w bazie danych. Takie podejście powoduje, że pierwsza transakcja, której uda się zdobyć pierwszy zasób ma gwarancję, że żadna inna transakcja tego samego typu nie zajmie innego zasobu potrzebnego do realizacji zaplanowanych operacji. informatyka + 26

informatyka + Transakcje Kilka dobrych rad dotyczących transakcji
Starajmy się budować transakcje tak krótkie jak się da! Pozwala to skrócić czas aktywności blokad i poprawić wydajność Planujmy kolejność uzyskiwania dostępu do zasobów w ramach transakcji aby unikać zakleszczeń Mimo, iż SQL Server daje nam możliwości sterowania mechanizmem blokad – jeśli nie wiemy na 100% co robimy – lepiej nie ingerować w tę dziedzinę. Mechanizm ten sam z siebie działa bardzo dobrze. Dobierajmy właściwy poziom izolacji transakcji dla konkretnych operacji. Korzystanie ze zbyt wysokiego powoduje spadek wydajności Przy korzystaniu z transakcji warto trzymać się kilku zasad, które pozwalają na wykonywanie transakcji w możliwie najwydajniejszy sposób. Przede wszystkim pilnujmy długości transakcji. Im dłuższa, tym dłużej aktywne są blokady przez nią utworzone i inne transakcje nie mogą korzystać z zasobów. Pod żadnym pozorem nie należy w ramach transakcji prowadzić jakiejkolwiek interakcji z użytkownikiem! Transakcja powinna zawierać jedynie kod, który musi być wykonany w jej ramach ze względów zachowania spójności danych. Wszelkie inne operacje mogą odbywać się przed lub po transakcji. Można tu zauważyć podobieństwo do programowania współbieżnego i sekcji krytycznej. W ramach transakcji warto zaplanować kolejność uzyskiwania dostępu do zasobów tak, aby minimalizować ryzyko wystąpienia zakleszczeń. Zagadnienie to staje się tym bardziej skomplikowane im więcej różnych operacji jest realizowanych z wykorzystaniem osobnych transakcji. W specyficznych przypadkach można podpowiedzieć serwerowi jakich rodzajów blokad ma użyć w ramach wykonywania transakcji. Jest to jednak zdecydowanie margines zastosowań. W miarę możliwości nie należy ingerować w ten mechanizm, gdyż sam z siebie działa bardzo dobrze. Nie w pełni przemyślana i świadoma ingerencja może drastycznie obniżyć wydajność. Dobranie odpowiedniego poziomu izolacji dla transakcji jest także bardzo istotne. W przypadkach gdy ryzyko wystąpienia konfliktów (dirty reads itp.) w ramach transakcji nie stanowi zagrożenia dla wykonywanej operacji warto obniżać poziom izolacji. Jedynie w przypadku krytycznych operacji sięgajmy po poziom SERIALIZABLE. Takie podejście pozwoli uzyskać lepszą wydajność bazy danych. informatyka + 27

Poziomy izolacji transakcji Wyzwalacze Rodzaje wyzwalaczy Procedury składowane i funkcje użytkownika Indeksy Fizyczna organizacja danych w SQL Server 2008 Rodzaje indeksów (zgrupowane, niezgrupowane) Optymalizacja zapytań i plany wykonania Kopie bezpieczeństwa i odtwarzanie danych Podsumowanie Kolejnym ciekawym mechanizmem stosowanym w bazach danych są wyzwalacze (triggers). W ramach wykładu zapoznamy się z poszczególnymi rodzajami wyzwalaczy oraz z typowymi scenariuszami korzystania z nich. informatyka + 28

informatyka + Wyzwalacze
Wyzwalacz to specjalny rodzaj procedury składowanej, która jest wywoływana automatycznie w reakcji na zajście określonego zdarzenia. Wyzwalacze to sztandarowy mechanizm pozwalający na implementowanie w bazie reguł biznesowych i zapewnienie spójności 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 dokładnie udokumentowane! W przeciwnym razie w przypadku wystąpienia problemów z logiką bazy bardzo trudno będzie dociec źródła problemu. Wyzwalacze są bardzo potężnym i wygodnym narzędziem służącym do implementowania reguł biznesowych i mechanizmów zapewnienia spójności danych. Powinny być stosowane tam, gdzie nie wystarczają możliwości ograniczeń (constraints). Specyfika działania wyzwalaczy polega na tym, że po pierwsze są one wywoływane automatycznie w reakcji na zajście określonego zdarzenia, a po drugie kod wykonywany w ramach wyzwalacza wchodzi w skład realizowanej transakcji. W SQL Serverze 2008 dostępne są wyzwalacze przeznaczone do reagowania na zdarzenia związane z językiem DML (INSERT, UPDATE, DELETE), jak i przeznaczone do reagowania na zdarzenia związane z językiem DDL (CREATE, ALTER, DROP). Istnieje również specjalny rodzaj wyzwalacza reagujący na zdarzenie LOGON – logowanie użytkownika do serwera. Bardzo istotną rzeczą przy pracy z wyzwalaczami jest to, że stosowanie ich w dużej liczbie może powodować znaczne zaciemnienie obrazu funkcjonowania bazy danych. Dlatego konieczną rzeczą jest skrupulatne dokumentowanie wyzwalaczy, żeby w razie problemów nie trzeba było przeczesywać bazy danych w poszukiwaniu winowajcy takiego czy innego zachowania. informatyka + 29

Poziomy izolacji transakcji Wyzwalacze Rodzaje wyzwalaczy Procedury składowane i funkcje użytkownika Indeksy Fizyczna organizacja danych w SQL Server 2008 Rodzaje indeksów (zgrupowane, niezgrupowane) Optymalizacja zapytań i plany wykonania Kopie bezpieczeństwa i odtwarzanie danych Podsumowanie Przyjrzyjmy się teraz poszczególnym rodzajom wyzwalaczy i ich zastosowaniu informatyka + 30

informatyka + Wyzwalacze DML
Wyzwalacze mogą reagować na zdarzenia: INSERT, UPDATE i DELETE Dwa rodzaje wyzwalaczy: AFTER i INSTEAD OF Wyzwalacze AFTER wykonują się po operacji, która spowodowała ich uruchomienie i wchodzą w skład realizowanej transakcji Wyzwalacze INSTEAD OF wykonują się zamiast wywołującej je operacji Można deklarować wiele wyzwalaczy na tej samej tabeli, dla tego samego zdarzenia. UWAGA! W takiej sytuacji nie mamy zbyt dużego wpływu na kolejność wykonania wyzwalaczy. Można jedynie określić, który wykona się jako pierwszy i jako ostatni. Wyzwalacze działające dla zdarzeń związanych poleceniami języka DML można podzielić na: wyzwalacze AFTER kod w nich zawarty jest wykonywany po operacji uruchamiającej wyzwalacz, ale, co istotne, w ramach tej samej transakcji wyzwalacze INSTEAD OF Ich kod jest wykonywany zamiast operacji uruchamiającej wyzwalacz. Właściwa operacja nie dochodzi do skutku. Dla jednego zdarzenia na jednej tabeli można tworzyć wiele wyzwalaczy. W takiej sytuacji ważne jest aby pamiętać, że kolejność ich wykonania jest nieokreślona. Jedyne co możemy w tej sprawie zrobić, to określić który z nich ma się wykonać jako pierwszy, a który jako ostatni. Realizuje się to za pomocą procedury składowanej sp_settriggerorder. informatyka + 31

Dodajmy do naszej bazy jeszcze jedną tabelę Będzie ona przechowywać informacje o operacjach wykonywanych na rachunku Wykorzystamy wyzwalacze do zaimplementowania reguł biznesowych: Nie można usunąć ani zmodyfikować raz wykonanej operacji Minimalna kwota wypłaty z rachunku musi być większa lub równa 10 zł W ramach przykładu wykorzystamy wyzwalacze do zaimplementowania kilku reguł biznesowych w naszej bazie danych. W tym celu musimy nieco ja rozbudować poprzez dodanie tabeli Operacje, która będzie przechowywała informacje o operacjach wykonywanych na rachunku (wpłaty i wypłaty). Załóżmy, że sformułowane zostały następujące reguły biznesowe: Nie można usunąć ani zmodyfikować raz wykonanej operacji Minimalna kwota wypłaty z rachunku musi być większa lub równa 10 zł Do zaimplementowania tych reguł wykorzystamy dwa rodzaje wyzwalaczy – AFTER i INSTEAD OF informatyka + 32

informatyka + Wyzwalacze DML 33
Na pierwszy ogień weźmy blokadę modyfikacji i usuwania wpisów w tabeli Operacje. Zrealizujemy to za pomocą wyzwalacza INSTEAD OF: Dodajmy parę wpisów: Spróbujmy teraz usunąć operację: Rezultat: Rozpoczniemy od zablokowania usuwania i modyfikacji wpisów w tabeli Operacje. Do tego celu wykorzystamy wyzwalacz INSTEAD OF przypisany do zdarzeń UPDATE i DELETE. Spowoduje on, że przy każdej próbie zmodyfikowania lub usunięcia wpisu w tabeli Operacje, zamiast wykonywanej operacji wykona się nasz wyzwalacz, którego jedyną funkcjonalnością jest wygenerowanie komunikatu o błędzie. Podobny efekt można byłoby osiągnąć stosując wyzwalacz AFTER. W takim przypadku w kodzie wyzwalacza powinno znaleźć się jeszcze polecenie ROLLLBACK. Byłoby to jednak rozwiązanie mniej efektywne, gdyż powodowałoby wykonanie operacji modyfikacji lub usunięcia wpisu, a dopiero po fakcie wycofania transakcji i anulowania dopiero co wykonanej operacji. informatyka + 33

Transakcja została wycofana
Wyzwalacze DML Następny krok to implementacja drugiej reguły biznesowej – minimalna kwota wypłaty musi być większa lub równa 10 zł Zrealizujemy to za pomocą wyzwalacza AFTER: Spróbujmy wykonać wypłatę zbyt małej kwoty: Rezultat: Transakcja została wycofana Druga reguła biznesowa do zaimplementowania ma ograniczyć minimalną kwotę wypłaty do 10 złotych. Każda operacja wypłaty kwoty mniejszej niż 10 zł powinna zostać zablokowana. Realizacja tej reguły zostanie wymuszona za pomocą wyzwalacza AFTER zdefiniowanego na zdarzeniu INSERT. Jego mechanizm działania jest prosty. Sprawdza, czy w danych dopisywanych w ramach transakcji występuje kwota wypłaty niższa niż 10 zł. Jeśli tak, to transakcja jest wycofywana i generowany jest błąd z odpowiednim komunikatem. Próba dopisania wiersza z kwotą wypłaty równą 5 zł kończy się zgodnie z oczekiwaniem – wycofaniem transakcji. informatyka + 34

W kodzie wyzwalacza mamy dostęp do dwóch specjalnych tabel : inserted i deleted Tabela inserted zawiera listę dodawanych wierszy w ramach wykonywanego polecenia INSERT Tabela deleted zawiera listę wierszy usuwanych w ramach wykonywanego polecenia DELETE W przypadku wykonywania modyfikacji danych,(UPDATE) tabela inserted zawiera nowe wartości wierszy, a deleted stare. Z tych tabel korzysta się przy tworzeniu kodu wyzwalaczy odwołującego się do modyfikowanych danych. SQL Server udostępnia dla kodu wyzwalaczy dwie specjalne tabele. Są to tabele inserted i deleted. Są one w pełni obsługiwane przez serwer i utrzymywane w pamięci, więc dostęp do nich jest szybki. Gdy rozpoczyna się wykonanie kodu wyzwalacza, tabele te są napełniane odpowiednimi danymi. W przypadku wyzwalacza skojarzonego z poleceniem INSERT – tabela inserted będzie zawierała dodawane wiersze. W przypadku wyzwalacza skojarzonego z poleceniem DELETE – tabela deleted będzie zawierała usuwane dane W przypadku wyzwalacza skojarzonego z poleceniem UPDATE – tabela deleted będzie zawierała oryginalne wartości modyfikowanych danych, a tabela inserted ich nowe wartości. informatyka + 35

Ważne! Nie należy zakładać, że wyzwalacz będzie wywoływany zawsze dla modyfikacji pojedynczego wiersza! TAK Istotną cechą wyzwalaczy jest fakt, że mogą one być uruchomione nie tylko dla operacji modyfikującej pojedynczy wiersz. Wyzwalacz jest uruchamiany w odpowiedzi na wykonanie jednego polecenia, ale to polecenie może na przykład dodać lub usunąć kilkaset wierszy jednocześnie. Dlatego właśnie budując kod wyzwalacza powinniśmy uwzględniać, że może on wykonywać się dla wielu wierszy modyfikowanych jednym poleceniem uruchamiającym wyzwalacz. Niepoprawne jest podejście zaprezentowane w drugim przykładzie wyzwalacza. Będzie ono funkcjonowało poprawnie jedynie dla modyfikacji dotyczącej jednego wiersza. NIE informatyka + 36

informatyka + Wyzwalacze DDL
Wraz z pojawieniem się SQL Servera 2005 pojawił się nowy rodzaj wyzwalacza – wyzwalacz DDL Wyzwalacze DDL mogą reagować na zdarzenia - wywołania poleceń DDL (CREATE, ALTER, DROP, GRANT, DENY, REVOKE, UPDATE STATISTICS ) Przeznaczone do wspomagania audytu zmian w strukturze bazy danych i śledzenia jej zmian Pozwalają też ograniczać swobodę modyfikowania struktury bazy danych lub tworzyć mechanizmy zabezpieczające przed przypadkową modyfikacją W kodzie wyzwalacza dostępna jest funkcja EVENTDATA() zwracająca szczegółowe informacje o zdarzeniu w formie XML Osobną grupą wyzwalaczy są wyzwalacze DDL. Jak sama nazwa wskazuje reagują one na zdarzenia związane z poleceniami języka DDL (Data Definition Language). Takimi poleceniami są:CREATE, ALTER, DROP, GRANT, DENY, REVOKE, UPDATE STATISTICS . Przeznaczenie wyzwalaczy DDL jest nieco inne niż wcześniej omawianych wyzwalaczy DML. Podstawową rolą wyzwalaczy DDL jest wspomaganie mechanizmów audytu i śledzenia zmian w strukturze bazy danych oraz ograniczanie możliwości manipulowania tą strukturą. W kodzie wyzwalacza DDL dostępna jest specjalna funkcja EVENTDATA(), która zwraca szczegółowe informacje o zdarzeniu w formie XML (zwraca wartość typu XML). Wyzwalacze DDL można tworzyć na poziomie bazy danych lub całego serwera. informatyka + 37

Próba usunięcia tabeli
Wyzwalacze DDL Stwórzmy wyzwalacz DDL, który zablokuje wszelkie modyfikacje tabel oraz próby ich usunięcia: Tabela testowa Wyzwalacz DDL Próba usunięcia tabeli Rezultat usuwania Jako przykład wyzwalacza DDL stworzymy prosty mechanizm blokujący przeprowadzanie modyfikacji tabel oraz ich usuwanie. Działanie wyzwalacza będzie polegało na wygenerowaniu komunikatu błędu informującego o blokadzie oraz na wycofaniu transakcji. Do potrzeb testowania wyzwalacza stworzymy najpierw tabele „Test”, którą będziemy później próbowali usunąć. informatyka + 38

Poziomy izolacji transakcji Wyzwalacze Rodzaje wyzwalaczy Procedury składowane i funkcje użytkownika Indeksy Fizyczna organizacja danych w SQL Server 2008 Rodzaje indeksów (zgrupowane, niezgrupowane) Optymalizacja zapytań i plany wykonania Kopie bezpieczeństwa i odtwarzanie danych Podsumowanie Kolejnym elementem dostępnym w ramach bazy danych, który pozwala na wzbogacanie logiki bazy danych o nawet bardzo złożone mechanizmy są procedury składowane oraz funkcje użytkownika. Pozwalają one grupować kod SQL w większe bloki, które realizują konkretne zadanie w ramach bazy danych. W ramach wykładu dokonamy krótkiego przeglądu możliwości oferowanych przez procedury składowane i funkcje użytkownika. informatyka + 39

Procedury składowane i funkcje użytkownika
Procedura składowana przypomina funkcję (metodę) znaną z języków programowania: Zawiera blok kodu, który jest wykonywany po jej wywołaniu\ Może przyjmować parametry wywołania (wejściowe oraz wyjściowe) a także zwracać wartość (kod powrotu – wartość całkowita) W jej kodzie można stosować instrukcje warunkowe i pętle Pozwala na odcięcie aplikacji od szczegółów implementacyjnych bazy danych – tworzy warstwę abstrakcji danych Można nadawać uprawnienia do jej wykonania Procedury składowane to bloki kodu (poleceń) SQL, które można wykonywać jako całość. Procedury składowane przypominają funkcje czy metody znane z języków programowania. Można przy ich wywołaniu przekazywać parametry wejściowe i wyjściowe, a także odbierać zwracany przez nie kod powrotu (liczba całkowita). Korzystanie z procedur składowanych ma wiele zalet. Przede wszystkim pozwala grupować polecenia SQL, których wykonanie jest potrzebne do realizacji operacji biznesowej. W połączeniu z możliwością nadawania uprawnień do wykonania procedury pozwala to na łatwe budowanie systemu uprawnień do realizacji określonych operacji biznesowych. Dodatkowym aspektem jest fakt, że budowanie logiki aplikacji w oparciu o wywołania procedur składowanych pozwala na odcięcie się od szczegółów implementacyjnych bazy danych. Aplikacja (lub użytkownik) nie musi np. wiedzieć, że dane klienta są przechowywane w trzech tabelach. Wystarczy, że przekaże je jako parametry wejściowe – resztę załatwi kod zawarty w procedurze. informatyka + 40

W naszej bankowej bazie danych możemy zastosować procedurę składowaną do utworzenia rachunku dla nowego klienta. Wymagania biznesowe: Klient podaje swój adres oraz imię i nazwisko Zostaje dla niego utworzone konto. Otrzymuje jego numer. Klient dostaje na dzień dobry 100 zł na swoje nowe konto Zrealizujemy te wymagania za pomocą procedury, która przyjmie na wejściu dane klienta. Numer nowootwartego rachunku zostanie zwrócony jako parametr wyjściowy Przykładowa procedura, która utworzymy w naszej bazie będzie służyła do obsługi zakładania kont bankowych przez nowych klientów w ramach promocji. Promocja polega na tym, że klient zakładający konto w banku dostaje na nim prezent w wysokości 100 zł. Gdyby chcieć realizować to za pomocą poleceń SQL, trzeba by wykonać trzy operacje – utworzenie klienta, utworzenie rachunku, wykonanie operacji wpłaty 100 zł na konto. Wymagałoby to od aplikacji znajomości szczegółów struktury bazy danych, a w przypadku zmiany tej struktury – dokonywania modyfikacji w aplikacji. Żeby tego uniknąć stworzymy naszą procedurę składowaną. informatyka + 41

Postać procedury zakładania promocyjnego konta: Procedura, którą utworzyliśmy posiada trzy parametry wejściowe (imie, nazwisko i ) oraz jeden parametr wyjściowy (numerRachunku). Działanie procedury polega na: Utworzeniu nowego klienta (na podstawie podanych parametrów) Utworzenie nowego rachunku i skojarzenie go z utworzonym klientem ( jego ID pobrane za pomocą funkcji SCOPE_IDENTITY() ) Wykonanie operacji wpłaty 100 zł na utworzony rachunek Pobranie numeru utworzonego rachunku i zwrócenie go przez parametr wyjściowy (numerRachunku) informatyka + 42

Wywołanie procedury: Rezultat: Sukces! Widać trzy udane wykonania polecenia insert oraz wygenerowany numer rachunku Spróbujmy teraz wywołać nasza procedurę. Zrobimy to w połączeniu z zadeklarowaniem zmiennej, która będzie wykorzystana w charakterze parametru wyjściowego. Po wywołaniu procedury wypiszemy wartość parametru wyjściowego (skonwertowana do postaci znakowej). Po wywołaniu procedury widać, że działa ona poprawnie – widać ślady trzech poleceń INSERT („1 row(s) affected”) oraz wypisany numer utworzonego rachunku. informatyka + 43

Funkcje użytkownika są podobne do procedur składowanych Różnią się tym, że ich wywołania mogą być wykorzystane w charakterze wartości w wyrażeniach i zapytaniach. Funkcje występują w dwóch wariantach (zależnie od typu zwracanej wartości): Skalarne (scalar functions) Tabelaryczne (mogą składać się z jednego zapytania SELECT lub z wielu wyrażeń) Korzystanie z funkcji skalarnej : SELECT funkcja(parametr) Korzystanie z funkcji tabelarycznej: SELECT * FROM funkcja(parametr) Funkcje użytkownika – UDF (User Defined Functions) są tworem zbliżonym do procedur składowanych. Podstawową różnica jest to, że można ich wywołania wykorzystywać w wyrażeniach i zapytaniach w miejscach wartości. Funkcje użytkownika mogą zwracać wartości skalarne lub tabelaryczne. W przypadku wartości tabelarycznych funkcja może być zbudowana w oparciu o pojedyncze zapytanie SELECT lub o wiele wyrażeń prowadzących do wygenerowania wynikowego zbioru wierszy (odpowiednio funkcje inline i multistatement) informatyka + 44

Funkcja obliczająca saldo wskazanego rachunku: Wywołanie: Rezultat: Stwórzmy przykładowe funkcje użytkownika w naszej bankowej bazie danych. Rozpoczniemy od funkcji skalarnej, która zwraca saldo wskazanego rachunku. Będzie ona przyjmowała parametr wejściowy - identyfikator rachunku. Zwracana będzie suma kwot operacji wykonanych na rachunku. informatyka + 45

Funkcja tabelaryczna (inline) zwracająca n ostatnich operacji wykonanych na rachunkach: Wywołanie: Rezultat: Funkcja użytkownika zwracająca wartość tabelaryczną będzie zwracała listę n ostatnich operacji wykonanych na rachunkach w bankach. Stworzymy ja najpierw jako funkcję typu „inline” – zbudowaną jako wynik jednego zapytania. informatyka + 46

Ta sama funkcja zrealizowana jako „multistatement” Wywołanie: Rezultat: Kolejna funkcja zwraca dokładnie takie samo zestawienie jak poprzednia, ale została zaimplementowana jako funkcja tabelaryczna wielowyrażeniowa (multistatement). Różni się od poprzedniczki tym, że w definicji funkcji podaje się definicje kolumn tabeli wyjściowej, a następnie w kodzie funkcji wstawia się dane do zmiennej tabelarycznej, która jest na koniec zwracana. informatyka + 47

Poziomy izolacji transakcji Wyzwalacze Rodzaje wyzwalaczy Procedury składowane i funkcje użytkownika Indeksy Fizyczna organizacja danych w SQL Server 2008 Rodzaje indeksów (zgrupowane, niezgrupowane) Optymalizacja zapytań i plany wykonania Kopie bezpieczeństwa i odtwarzanie danych Podsumowanie Zanim zaczniemy zgłębiać tematykę indeksów oraz ich wpływy na wydajność, wypadałoby zapoznać się choćby w niewielkim stopniu z mechanizmami leżącymi u podstaw działania SQL Servera. Jednym z istotnych zagadnień jest tu sposób w jaki dane są fizycznie przechowywane w bazie danych. informatyka + 48

Fizyczna organizacja danych w SQL Server 2008
Logicznie tabela składa się z wierszy, które składają się z kolumn. Jak te dane przechowywane są na dysku? Jakie są ograniczenia przy definiowaniu tabel? Jaki ma to wpływ na wydajność? Gdy myślimy o tabeli to od razu wizualizujemy sobie coś na kształt ilustracji ze slajdu. Zbiór wierszy składających się z kolumn zawierających dane różnego typu. Nie zastanawiamy się jak te dane są przechowywane fizycznie na dysku, ani jaki wpływ na wydajność mogą mieć nasze decyzje podjęte przy projektowaniu tabeli. Warto jednak zadać sobie nieco trudu i zapoznać się z fizycznym sposobem przechowywania danych w bazie. Zrozumienie podstaw pozwoli później zrozumieć dlaczego w takiej czy innej sytuacji wykonanie zapytania czy modyfikacji danych trwa długo. informatyka + 50

Podstawowa jednostka – strona (page) Rozmiar: 8 KB (dokładnie 8060 bajtów na dane) Jest to jednocześnie maksymalna długość wiersza (nie licząc kolumn przechowywanych na osobnych stronach) Wiersz nie może być podzielony pomiędzy strony. Rodzaje stron data (wszystkie dane z wyjątkiem kolumn typów: text, ntext, image, nvarchar(max), varchar(max), varbinary(max), xml ) index (wpisy indeksów) text/image (text, ntext, image, nvarchar(max), varchar(max), varbinary(max), xml oraz niemieszczące się w wierszu: varchar, nvarchar, varbinary) GAM, (Global Allocation Map) SGAM (Shared GAM), IAM (Index Allocation Map) – wrócimy do nich! Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Najmniejszą jednostką przechowywania danych jest w SQL Serverze strona (page). Jest to 8 KB blok składający się z nagłówka i 8060 bajtów na dane z wiersza(-y). Przy założeniu, że wiersz tabeli musi się zmieścić na stronie jasno widać, że maksymalny rozmiar wiersza to 8060 bajtów. Trochę mało? Niekoniecznie. Część danych o rozmiarze przekraczającym 8KB jest zapisywana na innych stronach, a w samym wierszu umieszczany jest tylko wskaźnik do pierwszej z tych stron. SQL Server rozróżnia 9 rodzajów stron przechowujących informacje o rozmaitym znaczeniu. Strony danych (data) zawierają wszystkie dane z wiersza, z wyjątkiem kolumn typów: text, ntext, image, nvarchar(max), varchar(max), varbinary(max), xml. Jeżeli wiersz nie mieści się w limicie długości 8060 bajtów, to najdłuższa z kolumn jest przenoszona do tzw. strony przepełnienia (strona danych), a w jej miejscu w wierszu zostaje 24 bajtowy wskaźnik Strony indeksów (index) zawierają poszczególne wpisy indeksu. W ich przypadku istotny jest limit długości klucza indeksu – 900 bajtów Strony obiektów BLOB/CLOB (Binary /Character Large Object) (text/image) służą do przechowywania danych o rozmiarze do 2 GB. Do stron GAM, SGAM i IAM wrócimy na kolejnych slajdach, gdy poznamy kolejne pojęcia dotyczące fizycznego przechowywania danych. Wymieniliśmy tylko 6 rodzajów, żeby niepotrzebnie nie komplikować dalszych rozważań. Dla uporządkowania warto wspomnieć o pozostałych trzech: Page Free Space , Bulk Changed Map, Differential Changed Map. Pierwsza zawiera informacje o zaalokowanych stronach i wolnym miejscu na nich. Pozostałe dwa rodzaje wykorzystywane są do oznaczania danych zmodyfikowanych w ramach operacji typu bulk oraz do oznaczania zmian od ostatnio wykonanej kopii zapasowej. informatyka + 51

8 KB (strona) to trochę mało… 8 stron – 64 KB to w sam raz na jednostkę alokacji! Jednostka ta zwana jest obszarem (extent). Rodzaje obszarów Jednolite (uniform extent) Zawierają strony należące do jednego obiektu ( tabeli /indeksu ) Mieszane (mixed extent) Zawierają strony należące do więcej niż jednego obiektu Alokowane i odczytywane są zawsze całe obszary a nie pojedyncze strony Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Podstawową jednostką alokacji nie jest jednak w SQL Serverze strona, tylko zbiór ośmiu stron – obszar (extent). Jest tak ze względu na fakt, iż 8 KB to trochę za mało jak na operacje w systemie plików. 64 KB to akurat jednostka alokacji w systemie plików NTFS. Obszary mogą zawierać strony należące do jednego obiektu (tabeli czy indeksu) – nazywamy je wtedy jednolitymi (uniform), lub do wielu obiektów – stają się wtedy obszarami mieszanymi (mixed). Jeżeli SQL Server alokuje miejsce na nowe dane to najmniejszą jednostką jest właśnie obszar. informatyka + 52

Sterta (heap) – zbiór obszarów zawierających dane z jednej tabeli (lub partycji w przypadku tabel partycjonowanych) Dane nie są ze sobą powiązane w żaden sposób Wyszukiwanie wymaga przejrzenia wszystkich stron … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 2 Wiersz 3 … Nagłówek Wiersz 1 Wiersz 6 Wiersz 3 … Nagłówek Wiersz 31 Wiersz 72 Wiersz 13 … Nagłówek Wiersz 51 Wiersz 32 Wiersz 93 … Nagłówek Wiersz 4 Wiersz 98 Wiersz 62 … Jeżeli tabela nie zawiera żadnego indeksu, to jej dane tworzą stertę – nieuporządkowaną listę stron należących do tej tabeli. Wszelkie operacje wyszukiwania na stercie odbywają się wolno, gdyż wymagają zawsze przejrzenia wszystkich stron. … informatyka + 53

Tabela może składać się z jednej lub więcej partycji Sterta jest tworzona osobno dla każdej partycji Tabela Tabela może zostać podzielona na partycje (względy wydajnościowe – zrównoleglenie operacji wejścia wyjścia). W takim przypadku każda z partycji posiada własną stertę. Wszystkie razem tworzą zbiór danych tabeli. Partycja 1 Partycja 3 Partycja 2 informatyka + 54

Skąd wiadomo które obszary są wolne, które są zajęte, do których obiektów należą obszary czy strony? Ze stron GAM, SGAM i IAM ;-) GAM (Global Allocation Map) – informacje o zajętych obszarach jednolitych (uniform) SGAM (Shared GAM) - informacje o zajętych obszarach mieszanych (mixed) IAM (Index Allocation Map) – informacje o przynależności obszarów do obiektów Gdy SQL Server alokuje miejsce w plikach bazy danych, wypełnia je obszarami, które wstępnie są oznaczone jako wolne. Podobnie wszystkie strony w obszarach są oznaczone jako puste. W jaki sposób przechowywane są informacje na temat tego czy dany obszar lub strona są wolne lub należą do jakiegoś obiektu? Służą do tego specjalne strony – GAM, SGAM i IAM. Zawierają one informacje o zajętości poszczególnych obszarów w postaci map bitowych (GAM,SGAM) lub o przynależności obszarów do obiektów (tabel,indeksów) – IAM. IAM informatyka + 55

No dobrze, ale jak trafić do odpowiedniej strony IAM? Każdy obiekt (tabela / indeks) ma wpisy w tabelach systemowych dotyczące alokacji jego danych Dostęp do tych informacji – widok sys.partitions Każda sterta, indeks, obszar LOB mają odpowiadający im wpis. Wpis ten zawiera wskaźnik do IAM Wartośc kolumny index_id: 0 – sterta 1 – indeks zgrupowany – indeksy niezgrupowane 255 – dane LOB Kluczem do uzyskania dostępu do danych z tabeli jest możliwość dostania się do strony IAM tej tabeli. Informacje na temat lokalizacji stron IAM dla poszczególnych obiektów znajdują się we wpisach w tabelach systemowych. Jako, że nie zaleca się „grzebania” bezpośrednio w tych tabelach, zostały udostępnione specjalne widoki, które zawierają potrzebne nam dane. W przypadku stron IAM jest to widok sys.partitions. Wpisy w nim zawarte składają się m.in. z kolumny index_id określającej rodzaj obiektu (sterta, indeks zgrupowany, indeks niezgrupowany, obiekty LOB), kolumn określających id obiektu i partycji oraz wskaźnika do strony IAM obiektu. sys.partitions id Index_id=0 IAM informatyka + 56

Poziomy izolacji transakcji Wyzwalacze Rodzaje wyzwalaczy Procedury składowane i funkcje użytkownika Indeksy Fizyczna organizacja danych w SQL Server 2008 Rodzaje indeksów (zgrupowane, niezgrupowane) Optymalizacja zapytań i plany wykonania Kopie bezpieczeństwa i odtwarzanie danych Podsumowanie Poznaliśmy już sposób przechowywania danych w tabeli, dla której nie stworzono indeksów. Cechą charakterystyczną był fakt nieuporządkowania stron i wierszy należących do jednej tabeli, co wymuszało przy każdej operacji wyszukiwania danych w tabeli przeszukanie wszystkich wierszy. Taka operacja nosi nazwę skanowania tabeli (table scan). Jest ona bardzo kosztowna (w sensie zasobów) i wymaga częstego sięgania do danych z dysku tym częściej im więcej danych znajduje się w tabeli. Taki mechanizm jest skrajnie nieefektywny, więc muszą istnieć jakieś inne pozwalające na przeprowadzanie efektywnego wyszukiwania. Rzeczywiście takowe istnieją. Są to indeksy występujące w dwóch podstawowych wariantach jako indeksy: zgrupowane (clustered) i niezgrupowane (nonclustered) informatyka + 57

informatyka + Indeks zgrupowany 58 korzeń gałęzie liście
sys.partitions id Index_id=1 Root page korzeń gałęzie Indeks zgrupowany ma postać drzewa zrównoważonego (B-tree). Na poziomie korzenia i gałęzi znajdują się strony indeksu zawierające kolejne wartości klucza indeksu uporządkowane rosnąco. Na poziomie liści znajdują się podobnie uporządkowane strony z danymi tabeli. To właśnie jest cechą charakterystyczną indeksu zgrupowanego – powoduje on fizyczne uporządkowanie wierszy w tabeli, rosnąco według wartości klucza indeksu (wskazanej kolumny lub kolumn). Z tego względu oczywiste jest ograniczenie do jednego indeksu zgrupowanego dla tabeli. liście informatyka + 58

informatyka + Indeks zgrupowany 59
Struktura drzewiasta (B-tree) – drzewo zrównoważone Na poziomie korzenia i gałęzi – strony indeksu Na poziomie liści – właściwe strony z danymi z tabeli Dane fizycznie uporządkowane rosnąco wg klucza indeksu Tylko jeden indeks zgrupowany dla tabeli! Unikalność kluczy zapewniona wewnętrznie Jeśli w tabeli występują dwie takie same wartości klucza, dodawana do nich jest losowa liczba i taki klucz staje się wewnętrznie rozpoznawany jako unikalny Kiedy stosowanie jest szczególnie uzasadnione Operowanie na zakresach danych i danych grupowanych Pobieranie danych w określonym porządku Zapytania korzystające z wielu kolumn tabeli Lepsza wydajność przy dodawaniu nowych wierszy Na jakich kolumnach tworzyć indeks zgrupowany? Mała długość Wysoka selektywność (mało powtarzających się wartości klucza indeksu) Rzadko bądź wcale nie zmieniane wartości Wartości klucza dla kolejno dodawanych wierszy są rosnące Specyfika indeksu zgrupowanego polega jak już wspomnieliśmy na fizycznym porządkowaniu danych z tabeli według wartości klucza indeksu. W związku z tym jasne jest, że indeks ten będzie szczególnie przydatny przy zapytaniach operujących na zakresach danych, grupujących dane, oraz korzystających z danych z wielu kolumn. W takich przypadkach indeks zgrupowany zapewnia znaczny wzrost wydajności w stosunku do sterty lub indeksu niezgrupowanego. Istotna rzeczą przy podejmowaniu decyzji o utworzeniu indeksu zgrupowanego jest wybranie właściwej kolumny (kolumn). Długość klucza powinna być jak najmniejsza, co umożliwia zmieszczenie większej ilości wpisów indeksu na jednej stronie, co z kolei przenosi się na zmniejszenie ilości stron całości indeksu i w efekcie mniej operacji wejścia/wyjścia do wykonania przez serwer. Żeby indeks zgrupowany korzystnie wpływał na wydajność przy dodawaniu nowych wierszy do mocno wykorzystywanej tabeli, klucz powinien przyjmować dla kolejnych wpisów wartości rosnące (zwykle stosowana jest tu kolumna z cechą IDENTITY). Indeks daje duży zysk wydajności gdy jego klucz jest możliwie wysoko selektywny (co oznacza mniejszą liczbę kluczy o tej samej wartości – duplikatów). Istotny jest także fakt, że kolumny klucza indeksu zgrupowanego nie powinny być raczej modyfikowane, gdyż pociąga to za sobą konieczność modyfikowania nie tylko stron indeksu ale także porządkowania stron danych. informatyka + 59

Indeks niezgrupowany (budowany na stercie)
sys.partitions id Index_id=2 Root page korzeń gałęzie liście Indeksy zgrupowane nie wyczerpują możliwości budowania tego typu struktur w SQL Serverze Drugim typem indeksów 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 istniejący indeks zgrupowany. Dla jednej tabeli można utworzyć do 248 indeksów niezgrupowanych. Indeks niezgrupowany różni się od zgrupowanego przede wszystkim tym, że w swojej strukturze na poziomie liści ma także strony indeksu (a nie strony danych). W przypadku budowania indeksu niezgrupowanego na stercie, strony te oprócz wartości klucza indeksu zawierają wskaźniki do konkretnych stron na stercie, które dopiero zawierają odpowiednie dane. sterta informatyka + 60

Indeks niezgrupowany (budowany na stercie)
Struktura drzewiasta (B-tree) – drzewo zrównoważone Na poziomie korzenia, gałęzi i liści – strony indeksu Liście zawierają wskaźniki do właściwych stron na stercie Można tworzyć do 248 indeksów niezgrupowanych na tabeli Stosowane są gdy dane wyszukiwane są według wielu kryteriów (różne zapytania) Maksymalna długość klucza – 900 bajtów Maksymalnie 16 kolumn w kluczu Indeksy niezgrupowane mają strukturę zbliżoną do zgrupowanych. Zasadnicza różnica polega na zawartości liści indeksu. O ile indeksy zgrupowane mają w tym miejscu strony danych, to indeksy niezgrupowane – strony indeksu. Strony te zależnie od wariantu indeksu niezgrupowanego zawierają oprócz klucza różne informacje. Indeksy niezgrupowane mogą być tworzone w oparciu o stertę. Jest to możliwe tylko w przypadku, gdy tabela nie posiada indeksu zgrupowanego. W takim przypadku liście indeksu zawierają wskaźniki do konkretnych stron na stercie. informatyka + 61

Indeks niezgrupowany (budowany na zgrupowanym)
sys.partitions id Index_id=2 Root page korzeń gałęzie liście Indeks niezgrupowany tworzony na tabeli posiadającej już indeks zgrupowany tworzony jest nieco inaczej. Korzeń, gałęzie i liście zawierają strony indeksu, ale liście zamiast wskaźników do stron na stercie zawierają wartości klucza indeksu zgrupowanego. Każde wyszukanie w oparciu o indeks niezgrupowany, po dojściu do poziomu liści, zaczyna dalsze przetwarzanie od korzenia indeksu zgrupowanego (wyszukiwany jest klucz zawarty w liściu). Indeks zgrupowany informatyka + 62

Indeks niezgrupowany (budowany na zgrupowanym)
Praktycznie wszystko tak samo jak w budowanym na stercie. Z wyjątkiem dwóch rzeczy: Liście zawierają wartości klucza z indeksu zgrupowanego Wskaźnik zawsze ustawiony jest na korzeń indeksu zgrupowanego Jeśli indeks zgrupowany zostanie usunięty – niezgrupowany zostanie przebudowany (na wariant oparty o stertę) Jeśli indeks zgrupowany zostanie utworzony – indeksy niezgrupowane zostaną także przebudowane (ze sterty na zgrupowany) W przypadku budowania indeksów niezgrupowanych, szczególnie na dużych tabelach warto dobrze zaplanować tę czynność, szczególnie gdy planowane jest też utworzenie indeksu zgrupowanego. Niewzięcie tego pod uwagę może powodować konieczność przebudowywania indeksów niezgrupowanych w związku z dodaniem lub usunięciem indeksu zgrupowanego. informatyka + 63

Poziomy izolacji transakcji Wyzwalacze Rodzaje wyzwalaczy Procedury składowane i funkcje użytkownika Indeksy Fizyczna organizacja danych w SQL Server 2008 Rodzaje indeksów (zgrupowane, niezgrupowane) Optymalizacja zapytań i plany wykonania Kopie bezpieczeństwa i odtwarzanie danych Podsumowanie Gdy zlecamy serwerowi wykonanie zapytania rozpoczyna się dość złożony proces prowadzący do określenia sposobu realizacji zapytania. Zależnie od konstrukcji samego zapytania, rozmiarów tabel, istniejących indeksów, statystyk itp. serwer tworzy kilka planów wykonania zapytania. Następnie spośród nich wybierany jest ten, który cechuje się najniższym kosztem wykonania ( wyrażanym przez koszt operacji wejścia/wyjścia oraz czasu procesora). Tak wybrany plan jest następnie kompilowany (przetwarzany na postać gotową do wykonania przez silnik bazodanowy) i przechowywany w buforze w razie gdyby mógłby się przydać przy kolejnym wykonaniu podobnego zapytania. W ramach tego punktu zajmiemy się nieco dokładniej procesem wykonania zapytania przez SQL Server. informatyka + 64

informatyka + Wykonywanie zapytań
Zapytanie zostało przekazane do wykonania …co dzieje się dalej? Całość procesu można opisać kilkoma etapami: Parsowanie zapytania (błędy składniowe). Efektem jest drzewo zapytania. Standaryzacja zapytania (drzewa). Usuwanie nadmiarowości, standaryzowanie podzapytań itp.. Optymalizacja zapytania .Wieloetapowy proces prowadzący do wyboru sposobu realizacji zapytania Kompilacja wygenerowanego planu (zapisanie w cache) Określenie metod fizycznego dostępu do danych Wykonanie zapytania zgodnie ze stworzonym planem Cały proces przebiegający od momentu przekazania zapytania do wykonania do odebrania jego rezultatów jest dość złożony i może stanowić temat niejednego wykładu. Postaramy się choć z grubsza zasygnalizować najistotniejsze etapy tego procesu. Parsowanie zapytania – polega na zweryfikowaniu składni polecenia, wychwyceniu błędów i nieprawidłowości w jego strukturze. Jeżeli takowe błędy nie występują, to efektem parsowania jest tak zwane drzewo zapytania (postać przeznaczona do dalszej obróbki) 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 planów wykonania zapytania oraz przeprowadzeniu ich analizy kosztowej zakończonej wybraniem najtańszego planu wykonania. Kompilacja polega na przetłumaczeniu wybranego planu wykonania do postaci kodu wykonywalnego przez silnik bazodanowy Określenie metod fizycznego dostępu do danych ( skanowanie tabel, skanowanie indeksów, wyszukiwanie w indeksach itp..) informatyka + 65

Wykonywanie zapytań – optymalizacja zapytania
Optymalizacja zapytania polega na: Dokonaniu analizy zapytania (pod kątem kryteriów wyszukiwania oraz złączeń) Dobraniu indeksów, które mogą okazać się pomocne przy realizacji zapytania (kryteria wyszukiwania, kolumny wyjściowe) Określeniu strategii realizacji złączeń (selektywność, potrzebna pamięć) Generowanych jest kilka wariantów, dla każdego szacowany jest koszt wyrażony w operacjach wejścia/wyjścia (I/O) i czasie rocesora (CPU). Wybierany jest najtańszy wariant i przekazywany do kompilacji Plan wykonania można podejrzeć za pomocą włączenia jednej z opcji: SET SHOWPLAN_TEXT ON, SET SHOWPLAN_XML ON , SET SHOWPLAN_ALL ON Proces optymalizacji zapytania składa się z kilku etapów. W ich skład wchodzą: analizowanie zapytania pod kątem kryteriów wyszukiwania i złączeń, dobranie indeksów mogących wspomóc wykonanie zapytania, oraz określenie sposobów realizacji złączeń. W ramach realizacji poszczególnych etapów optymalizator zapytań może korzystać z istniejących statystyk indeksów, generować je dla wybranych indeksów lub wręcz tworzyć nowe indeksy na potrzeby wykonania zapytania. Efektem tego procesu jest plan wykonania o najniższym koszcie, który jest następnie przekazywany do kompilacji i wykonania. Plan wykonania dla zapytania można podejrzeć w formie tekstowej, XML bądź zbioru wierszy. Realizuje się to za pomocą ustawienia na „ON” jednej z opcji SHOWPLAN_TEXT, SHOWPLAN_XML, SHOWPLAN_ALL. informatyka + 66

Optymalizacja zapytań - wykorzystanie indeksów
Zakładamy, że zapytania będą tworzone w oparciu o tabelę: W celu zwiększenia rozmiaru wiersza i liczby stron:) Nie ma żadnych indeksów na tabeli Klienci Zapytanie, którym się zajmiemy jest proste: Na kolejnych przykładach postaramy się zademonstrować wpływ indeksów na plan wykonania zapytania i jego całkowity koszt. Zapytania będą dotyczyły tabeli Klienci, w której na chwilę obecną nie ma żadnego indeksu. Z tego powodu można przewidywać, że operacją wykorzystaną do realizacji zapytania będzie skanowanie tabeli (table scan). informatyka + 67

Wykorzystanie indeksów
Pierwsze wykonanie zapytania – plan wykonania Brak indeksów – skanowanie sterty Pierwsze wykonanie: strony pobierane z dysku Kolejne wykonania: strony znajdują się w cache Zgodnie z oczekiwaniami, do realizacji zapytania wykorzystana została operacja skanowania tabeli. Przy pierwszym wykonaniu konieczne było pobranie stron danych z dysku (liczba fizycznych odczytów większa od 0). Każde następne wykonanie korzysta już ze stron umieszczonych w cache, czego przejawem jest zerowa wartość fizycznych odczytów. Całkowity koszt zapytania realizowanego według tego planu jest równy 2,1385. Koszt zapytania (estimated subtree cost) : 2,1385 informatyka + 68

Stwórzmy najpierw indeks zgrupowany na kolumnie ID. Zrealizujemy to przez utworzenie klucza podstawowego na tej kolumnie (prowadzi to do utworzenia indeksu) Wykonanie naszego zapytania po utworzeniu indeksu przebiega według planu: Stworzyliśmy indeks zgrupowany, więc nie ma już sterty. Pierwszym etapem naszych działań jest utworzenie indeksu zgrupowanego na kolumnie ID. Nie przyczyni się to w znaczącym stopniu do zwiększenia wydajności, ale spowoduje zmianę planu wykonania. Skoro utworzenie indeksu zgrupowanego powoduje fizyczne uporządkowanie 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 wydajnościowy, bo tak czy siak przejrzeć trzeba wszystkie strony danych, gdyż nasze kryterium wyszukiwania nie jest kolumna zawartą w indeksie. Koszt zapytania pozostał bez zmian : 2,1385 informatyka + 69

Spróbujmy teraz popracować nad wydajnością Stwórzmy indeks niezgrupowany na kolumnie, której używamy jako kryterium wyszukiwania Skoro istnieje indeks na kolumnie Nazwisko, to powinien zostać użyty do wyszukiwania? Sprawdźmy… Nic z tego! Nasz indeks nie został wykorzystany Dlaczego? Bo na wyjściu zapytania mamy jeszcze kolumnę Imie! Optymalizator stwierdził, iż nie warto korzystać z indeksu niezgrupowanego, skoro i tak trzeba pobrać strony danych, żeby uzyskać wartości z tej kolumny Koszt zapytania ciągle bez zmian : 2,1385 Rozpocznijmy teraz działania ukierunkowane na obniżenie kosztów realizacji zapytania. Pierwszy pomysł – stwórzmy indeks niezgrupowany na kolumnie nazwisko, która jest wykorzystywana jako kryterium wyszukiwania. Powinno to spowodować wykorzystanie tego indeksu do wyszukania wierszy z nazwiskami z określonego przez nas zakresu. Niestety po wykonaniu zapytania doznaliśmy rozczarowania. Plan wykonania się nie zmienił! Dlaczego? Z powodu umieszczenia na liście kolumn wyjściowych kolumny Imie. Optymalizator zapytań stwierdził, że mimo istnienia indeksu niezgrupowanego na kolumnie po której wyszukujemy, nie warto z niego korzystać, gdyż i tak trzeba sięgnąć do stron danych, żeby pobrać wartości kolumny Imie. Z tego powodu plan wykonania nie uległ zmianie. informatyka + 70

Zróbmy w końcu coś co przyniesie efekt! Wiemy dlaczego nasz indeks był nieprzydatny Uczyńmy go przydatnym! Dodajmy kolumnę Imie do indeksu Wykonajmy kolejny raz nasze zapytanie Sukces :-) Skoro przemyśleliśmy już mechanizm działania zapytania i role indeksu, doprowadźmy sprawę do końca. Usuńmy istniejący indeks niezgrupowany, utwórzmy go na nowo z dodaną kolumną Imie. Po wykonaniu zapytania po raz kolejny, okazuje się, że tym razem indeks został wykorzystany. Odpowiednie wiersze spełniające kryteria wyszukiwania zostały zlokalizowane bardzo łatwo dzięki indeksowi niezgrupowanemu. Dodatkowo nie było konieczności sięgania do stron danych, gdyż indeks zawierał także kolumnę Imie, która była potrzebna do realizacji zapytania. Efekt jest widoczny. Koszt realizacji zapytania spadł z 2,1385 do 0,0453! Wcześniej było 2862 ! Koszt wykonania: 0,0453 Wcześniej było: 2,1385 informatyka + 71

Poziomy izolacji transakcji Wyzwalacze Rodzaje wyzwalaczy Procedury składowane i funkcje użytkownika Indeksy Fizyczna organizacja danych w SQL Server 2008 Rodzaje indeksów (zgrupowane, niezgrupowane) Optymalizacja zapytań i plany wykonania Kopie bezpieczeństwa i odtwarzanie danych Podsumowanie Dla zapewnienia bezpieczeństwa danych istotne jest także wykonywanie ich kopii zapasowych. SQL Server posiada oczywiście zestaw poleceń i narzędzi, które służą do tego celu. Mimo możliwości oferowanych przez narzędzia, największa odpowiedzialność leży i tak po stronie człowieka. Nawet najlepsze narzędzia nie zagwarantują sprawnego odtworzenia stanu systemu po awarii jeżeli wcześniej zabrakło planu zarówno wykonywania kopii zapasowych jak i odtwarzania stanu systemu po awarii. informatyka + 72

Kopie bezpieczeństwa i odtwarzanie danych
Baza danych może być skonfigurowana do pracy w trzech trybach: Simple Recovery Bulk logged Recovery (nieomawiany w ramach wykładu) Full Recovery Zależnie od wybranego trybu mamy różne możliwości wykonywania kopii zapasowych. W trybie Simple Recovery można wykonywać jedynie pełne i różnicowe kopie zapasowe. Pozwala to w razie awarii odtworzyć stan bazy do stanu na chwilę wykonania ostatniej kopii zapasowej. W trybie Full Recovery można dodatkowo wykonywać kopie logu transakcji. Pozwala to praktycznie na odtworzenie stanu bazy bezpośrednio sprzed awarii Pierwszym zagadnieniem, które trzeba rozważyć przy planowaniu strategii wykonywania kopii zapasowych bazy danych jest model odtwarzania (recovery model). Od niego zależy jakie rodzaje kopii zapasowych będziemy mogli wykonywać oraz w jakim stopniu odtwarzać system po awarii. Najprostszym trybem odtwarzania jest tryb Simple Recovery. W tym trybie osoba administrująca bazą danych jest zwolniona z obowiązków związanych z utrzymaniem logu transakcji (kopie zapasowe, obcinanie i kontrolowanie rozmiaru). Kosztem jest natomiast możliwość odtworzenia stanu systemu po awarii jedynie do stanu z ostatniej kopii zapasowej (pełnej lub pełnej i różnicowej). Tryb Full Recovery daje pełne możliwości w zakresie wykonywania i odtwarzania kopii zapasowych. Oprócz kopii pełnych i różnicowych można wykonywać kopie logu transakcji. Daje to znacznie większe możliwości przy odtwarzaniu stanu systemu po awarii. Z drugiej strony administrator jest obarczony dodatkowymi obowiązkami wynikającymi z konieczności dbania o log transakcji. informatyka + 73

Wykonanie kopii zapasowej odbywa się za pomocą polecenia BACKUP: BACKUP DATABASE – kopia zapasowa całej bazy danych BACKUP LOG – kopia zapasowa logu transakcji BACKUP FILE – kopia zapasowa pliku wchodzącego w skład bazy danych Polecenie BACKUP DATABASE wykonuje domyślnie pełną kopię bazy danych Wywołane z opcją WITH DIFFERENTIAL – wykonuje kopię różnicową (zmiany danych od ostatniej kopii pełnej) Opcja ta zadziała pod warunkiem, że wcześniej wykonaliśmy kopię pełną! Do wykonywania kopii zapasowych służy polecenie BACKUP. Za jego pomocą można wykonywać kopie całej bazy (BACKUP DATABASE), logu transakcji (BACKUP LOG) lub poszczególnych plików wchodzących w skład bazy danych (BACKUP FILE). Kopia zapasowa całej bazy danych może być wykonana jako kopia pełna (full backup) lub kopia różnicowa (differential backup). Wykonywanie kopii zapasowej logu transakcji jest możliwe tylko przy bazie działającej w trybie full recovery. informatyka + 74

Odtwarzanie bazy z kopii zapasowej realizowane jest za pomocą polecenia RESTORE Posiada ono takie same warianty jak polecenie BACKUP (DATABASE, LOG, FILE) W przypadku konieczności odtworzenia stanu z kilku kolejnych kopii (kopia pełna, kopia różnicowa oraz log transakcji) można wykorzystać opcję NORECOVERY, która powoduje , że baza utrzymywana jest w stanie niespójności i pozwala na odtwarzanie kolejnych kopii. Ostatnie polecenie odtworzenia bazy powinno być wywołane z opcją RECOVERY (domyślna), żeby baza wróciła do stanu stabilnego (wycofanie niezatwierdzonych transakcji sprzed awarii) Wykonywanie kopii zapasowych nie jest celem samym w sobie. Jego istotą jest umożliwienie odtworzenia stanu systemu sprzed awarii. Polecenie, które służy do odtwarzania danych (RESTORE) z kopii zapasowej posiada takie same warianty jak polecenie BACKUP (DATABASE, LOG, FILE). Przy odtwarzaniu danych z więcej niż jednej kopii zapasowej trzeba pamiętać, by wszystkie kopie z wyjątkiem ostatniej odtwarzane były z opcją NORECOVERY, która pozostawia bazę w stanie niespójności i umożliwia odtwarzanie danych z kolejnych kopii. Dopiero ostatnia kopia jest odtwarzana z opcją RECOVERY (jest to domyślne działanie polecenia RESTORE) co powoduje wycofanie niezatwierdzonych transakcji i powrót bazy danych do stanu stabilnego . informatyka + 75

Wykonywanie kopii zapasowych i ich odtwarzanie można wykonywać także z poziomu narzędzia SQL Server Management Studio. Dodatkowo tworząc tzw. Maintenance Plan można stworzyć harmonogram wykonywania kopii zapasowych, który będzie realizowany automatycznie. Istnieją także narzędzia produkowane przez inne firmy, które pozwalają planować i realizować strategie wykonywania kopii zapasowych baz danych. Najważniejsze jednak jest sensowne zaplanowanie strategii wykonywania kopii zapasowych. Powinna zapewnić możliwość odtworzenia danych z założoną dokładnością Powinna zapewnić akceptowalny czas odtworzenia bazy i przywrócenia gotowości do pracy Powinna być skrupulatnie realizowana Powinna zawierać dokładnie opisane procedury odtwarzania danych po awarii! Sama umiejętność korzystania z poleceń czy narzędzi do wykonywania kopii zapasowych i odtwarzania z nich baz danych nie wystarczy, żeby móc powiedzieć, że nasze dane są bezpieczne. Istotniejszym elementem jest właściwie opracowana i dopasowana do wymagań strategia wykonywania kopii zapasowych i odtwarzania danych po awarii. Zaplanowanie takiej strategii nie jest bynajmniej zadaniem trywialnym i często zdarza się, że po awarii, mimo posiadania całego zestawu kopii zapasowych nie udaje się odtworzyć danych i doprowadzić ich do wymaganego stanu. Podstawą planowania strategii są wymagania dotyczące bezpieczeństwa danych: Jak długo może trwać proces przywracania bazy danych do stanu używalności? Na utratę ilu danych można sobie pozwolić (z ostatniej godziny, trzech godzin, kwadransa, czy najlepiej bez strat danych) Duży wpływ na postać strategii ma rozmiar bazy danych. Im większy tym trudniej osiągnąć zgodność z wymaganiami. Integralnym składnikiem strategii jest plan (procedura) odtwarzania bazy po awarii. Bez takiego dokumentu bardzo łatwo doprowadzić do sytuacji, w której nerwy i stres towarzyszące awarii spowodują, że administrator popełni błąd, który może zniweczyć szanse na odtworzenie danych do wymaganej postaci. Nie bez kozery administratorzy mawiają, że jeżeli dojdzie do awarii to pierwsza rzecz, którą należy 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 kroków. Jeżeli są one precyzyjnie opisane i najlepiej przećwiczone praktycznie to szanse na odzyskanie danych znacząco rosną. informatyka + 76

informatyka + Podsumowanie Baza danych to nie tylko zbiór tabel
Istnieje wiele mechanizmów wewnątrz bazy danych, które służą zapewnieniu spójności danych, definiowaniu różnego rodzaju ograniczeń, implementowaniu złożonej logiki aplikacji itp. Warto te mechanizmy stosować, gdyż takie podejście skutkuje zwykle wyższą wydajnością aplikacji oraz wyższym poziomem bezpieczeństwa danych. Możliwości drzemiące w mechanizmach bazy danych są wystarczające, żeby projektować bazy „hermetyczne” i „idiotoodporne” w postaci czarnej skrzynki, która udostępnia na zewnątrz tylko listę operacji (procedur składowanych) Warto zapoznać się z tymi mechanizmami praktycznie! informatyka + 78

KONIEC … czy są jakieś pytania? informatyka + 79

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

Podobne prezentacje

Prezentacja na temat: "Mechanizmy wewnętrzne baz danych – czyli co w bazach „piszczy”"— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres

Wejść

Zaloguj się poprzez sieć społeczną:

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

Podobne prezentacje

Prezentacja na temat: "Mechanizmy wewnętrzne baz danych – czyli co w bazach „piszczy”"— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres