Wysoka Dostępność SQL Server 2008 w kontekscie umów SLATobias Koprowski
To druga prezentacja w cztero-częściowym cyklu omawiającym znaczenie wysokiej dostepności w kontekście umów SLA. Prezentacje przeznaczone są dla odbiorców z kręgu ITPro, a publikowane na zywo na portalu VirtualStudy.pl
***
This is second part of my four-parts cycle about Service Level Agreement for ITPros. It a session for Virtualstudy.pl education portal.
Prezentacja przedstawia case study zarządzania kontami urzytkowników Active Directory w Urzędzie Miasta Stołeczenego Warszawy, z wykorzystaniem narzędzi ManageEngine
Wysoka Dostępność SQL Server 2008 w kontekscie umów SLATobias Koprowski
To druga prezentacja w cztero-częściowym cyklu omawiającym znaczenie wysokiej dostepności w kontekście umów SLA. Prezentacje przeznaczone są dla odbiorców z kręgu ITPro, a publikowane na zywo na portalu VirtualStudy.pl
***
This is second part of my four-parts cycle about Service Level Agreement for ITPros. It a session for Virtualstudy.pl education portal.
Prezentacja przedstawia case study zarządzania kontami urzytkowników Active Directory w Urzędzie Miasta Stołeczenego Warszawy, z wykorzystaniem narzędzi ManageEngine
Prezentacja z konferencji SQLDay 2017, Wrocław 16.05.2017.
Wdrażanie kolejnych wersji projektów SSIS jest dość monotonną ręczną pracą z poziomu SQL Server Data Tools. Rebuild/Deploy/Validate/Execute. Kiedy dochodzi do tego system kontroli wersji, branch, merge, dodawanie pakietów do projektów i przełączanie się między środowiskami DEV/TEST/PROD to robi się jeszcze nudniej.
Na sesji zaprezentuję jak można przerzucić te wszystkie czynności na serwer. Zobaczysz jak wykorzystać do tego Powershell i dostępne API .NET. Dodam do tego kontrolę wersji w TFS i przekonasz się, że testowanie i dostarczanie kolejnych wersji projektów wcale nie musi być tak uciążliwe. Zobaczysz na co zwrócić uwagę projektując własne rozwiązanie, z których zasobów skorzystać, jakie są ograniczenia i ich próby obejścia.
Prezentacja z konferencji SQLDay 2017, Wrocław 16.05.2017.
Wdrażanie kolejnych wersji projektów SSIS jest dość monotonną ręczną pracą z poziomu SQL Server Data Tools. Rebuild/Deploy/Validate/Execute. Kiedy dochodzi do tego system kontroli wersji, branch, merge, dodawanie pakietów do projektów i przełączanie się między środowiskami DEV/TEST/PROD to robi się jeszcze nudniej.
Na sesji zaprezentuję jak można przerzucić te wszystkie czynności na serwer. Zobaczysz jak wykorzystać do tego Powershell i dostępne API .NET. Dodam do tego kontrolę wersji w TFS i przekonasz się, że testowanie i dostarczanie kolejnych wersji projektów wcale nie musi być tak uciążliwe. Zobaczysz na co zwrócić uwagę projektując własne rozwiązanie, z których zasobów skorzystać, jakie są ograniczenia i ich próby obejścia.
3. O czym będzie?
O przechowywaniu danych, które zmieniają się w czasie
Jak to obsługujemy teraz
Jak będziemy to mogli zrobić za pomocą Temporal Tables
Czy to ma sensowną wydajność?
Przydaje się?
4. O mnie
Bartosz Ratajczyk
Programista baz danych
(i aplikacji)
czasem też administrator
MCTS SQL Server 2008, MCSA SQL Server 2012, MCT
http://bartekr.net | b.ratajczyk@gmail.com
5. Dane zmienne w czasie
SYSTEM VERSIONING – zarejestrowano zmianę
BUSINESS VERSIONING – ważne biznesowo od - do
(Dane) ValidFrom ValidTo
(…) 2015-10-01 10:21:15 2015-10-10 18:11:24
(Dane) DateFrom DateTo
(…) 2015-10-01 2015-10-10
6. Dlaczego je przechowujemy?
Bo wymagają tego przepisy
Bo chcemy wiedzieć kiedy dane się zmieniły (audyt)
Bo chcemy znać poprzednie wersje danych (SCD)
Bo chcemy móc szybko przywrócić poprzednią wersję danych (oops!)
Bo nasze dane mają okres obowiązywania w czasie (cennik)
BO TAK! (BO TAK!)
7. Jak sobie radzimy teraz?
• Własna logika w aplikacji, procedury składowane, klauzula OUTPUT
• Wyzwalacze
• Change Tracking
• Change Data Capture
8. Nowa możliwość
Temporal Tables, czyli tabele z definicją OKRESU
Mechanizm samodzielny, bez zależności od innych komponentów
Automatycznie tworzy poprzednie wersje danych i dodaje nowe
Obsługuje tylko wersjonowanie systemowe
(co oczywiście nie wyklucza wersjonowania biznesowego we własnym
zakresie)
10. Testujemy wydajność
Zbiór wejściowy: 10 mln rekordów
Cztery zbiory pomocnicze po 1 mln rekordów losowane ze zbioru
wejściowego
Cztery kolejne operacje: UPDATE, DELETE, UPDATE, DELETE na zbiorze
wejściowym z wykorzystaniem zbiorów pomocniczych
Cztery zapytania sumujące dane w zbiorze wejściowym:
Sumowanie danych z wyszukiwaniem po kluczu głównym
Sumowanie danych z klauzulą AS OF z wyszukiwaniem po kluczu głównym
Sumowanie danych z wyszukiwaniem po kolumnie spoza PK
Sumowanie danych z klauzulą AS OF z wyszukiwaniem po kolumnie spoza PK
Trzy przypadki testowe – indeksy rowstore i columnstore
11. Czy to zajmie dużo miejsca?
3479
2560
355
454
90
98
0 500 1000 1500 2000 2500 3000 3500 4000 4500
Scenariusz 1: rowstore/rowstore
Scenariusz 2: rowstore/columnstore
Scenariusz 3: columnstore/columnstore
Zajętość dysku (MB)
Tabela główna Tabela historyczna
12. A szybkie to jest? (1)
1717
1762
498
0 200 400 600 800 1000 1200 1400 1600 1800 2000
Scenariusz 1: rowstore/rowstore
Scenariusz 2: rowstore/columnstore
Scenariusz 3: columnstore/columnstore
Czasy trwania operacjiUPDATE/DELETE (w sekundach)
Całkowity czas trwania
13. A szybkie to jest? (2)
220121
95120
841
0 50000 100000 150000 200000 250000
Scenariusz 1: rowstore/rowstore
Scenariusz 2: rowstore/columnstore
Scenariusz 3: columnstore/columnstore
Czasy zapytań (w milisekundach)
14. A szybkie to jest? (3)
907
231
102738
116246
664
284
51868
42304
454
263
63
61
0 20000 40000 60000 80000 100000 120000 140000
SELECT 1 (SUM, WHERE PK)
SELECT 2 (SUM, WHERE PK, AS OF)
SELECT 3 (SUM, WHERE)
SELECT 4 (SUM, WHERE, AS OF)
SELECT 1 (SUM, WHERE PK)
SELECT 2 (SUM, WHERE PK, AS OF)
SELECT 3 (SUM, WHERE)
SELECT 4 (SUM, WHERE, AS OF)
SELECT 1 (SUM, WHERE PK)
SELECT 2 (SUM, WHERE PK, AS OF)
SELECT 3 (SUM, WHERE)
SELECT 4 (SUM, WHERE, AS OF)
Scenariusz1:
rowstore/rowstore
Scenariusz2:
rowstore/columnstore
Scenariusz3:
columnstore/columnstore
Czasy zapytań (w milisekundach)
15. O czym jeszcze warto wspomnieć?
Możliwość odmiennego partycjonowania tabeli głównej i historycznej
Wsparcie dla In-Memory OLTP od wersji 3.0
16. Obecne ograniczenia
Nie można zrobić TRUNCATE TABLE
Nie można przełączyć partycji między tabelą główną a historyczną
Do historii trafiają wszystkie zmiany
(UPDATE T1 SET k = 1 WHERE k = 1)
Nie możemy ręcznie modyfikować danych historycznych
Nie możemy ustawić śledzenia zmian tylko dla części kolumn
Nie można przenieść danych historycznych do chmury (Stretch
Database)
Nie można używać wyzwalaczy INSTEAD OF
Nie wiadomo w których edycjach będzie dostępne
17. No dobrze, ale po co mi one?
Kolejne narzędzie do monitorowania zmian rekordów
Zgodne ze standardem SQL:2011
Szybsze od samodzielnych implementacji na wyzwalaczach
18. Gdzie poczytać więcej na ten temat?
Alex Volok – blog: http://www.alexvolok.com
Itzik Ben-Gan – artykuły na SQL Server Pro: http://sqlmag.com/sql-
server/first-look-system-versioned-temporal-tables-part-1-creating-
tables-and-modifying-data
Channel9 – nagranie o Temporal Tables + dyskusja pod nim
https://channel9.msdn.com/Shows/Data-Exposed/Temporal-in-SQL-
Server-2016
Dokumentacja – Books OnLine