SQL Server
Wysyłanie dziennika
Autor: Krzysztof Kapustka
Opublikowano: 14.06.2017, 00:00
Liczba odsłon: 5207
Wysyłanie dziennika (ang. log shipping) jest jedną z podstawowych technik ochrony i odzyskiwania danych po awarii (ang. distaster recovery, DR), jakie dostępne są w systemie SQL Server od kilkunastu lat. Niektóre źródła ukazują wysyłanie dziennika również jako prostą realizację wysokiej dostępności (ang. high availability, HA), jednak to, czy wysyłanie dziennika uznawać będziemy jako rozwiązanie DR czy HA, podyktowane jest głównie fizycznym położeniem naszych serwerów - jeśli funkcję Log shipping wykorzystywać będziemy lokalnie, możemy o niej wówczas mówić w kontekście wysokiej dostępności, natomiast dla serwerów rozstawionych od siebie w dużych odległościach narzędzie to przyjmować będzie formę rozwiązania DR. W obu tych przypadkach funkcja ta działa dokładnie tak samo, a jedyną różnicą jest tu zmiana charakteru rezerwowego serwera bazy danych. Serwer ten może więc odgrywać rolę serwera aktywnej kopii zapasowej, zdolnego do przejęcia pracy po serwerze głównym w przypadku jego awarii, serwera do odzyskiwania danych z innej lokalizacji lub serwera raportowania.
Dublowanie bazy danych
Autor: Krzysztof Kapustka
Opublikowano: 7.06.2017, 00:00
Liczba odsłon: 5778
Dublowanie bazy danych (ang. database mirroring) jest jedną z podstawowych strategii realizacji wysokiej dostępności w środowisku wykorzystującym system SQL Server. Należy jednak zaznaczyć, że funkcja ta, wprowadzona po raz pierwszy w wersji SQL Server 2005, w kolejnych wydaniach tego produktu wypierana była stopniowo przez tzw. grupy dostępności AlwaysOn (ang. AlwaysOn Availability Groups), zaś od wersji SQL Server 2016 rozwiązanie to nie jest już dłużej dostępne. Mimo wszystko uważamy, że funkcja dublowania baz danych nadal jest warta poznania, jako że w większości środowisk produkcyjnych będzie ona stosowana jeszcze przez wiele lat, zaś jej zgłębienie ułatwi nam zrozumienie różnic występujących pomiędzy nią a wspomnianą technologią będącą jej bezpośrednim następcą.
Grupy dostępności Always On
Autor: Krzysztof Kapustka
Opublikowano: 31.05.2017, 00:00
Liczba odsłon: 6165
Funkcjonalność Grup dostępności Always On (ang. Always On Availability Groups) - będąca jednocześnie rozwiązaniem wysokiej dostępności (HA) i odzyskiwania danych po awarii (DR), przez co określana jest niekiedy akronimem HADRON - została wprowadzona w systemie SQL Server 2012 jako rozwiązanie alternatywne dla funkcji dublowania bazy danych. Należy jednak zaznaczyć, że z uwagi na swoją złożoność i wysokie koszty implementacji rozwiązanie to przeznaczone jest głównie dla dużych środowisk klasy enterprise. Zanim przejdziemy do omawiania tego zagadnienia warto nadmienić, że kluczem do pełnego zrozumienia tematu grup dostępności jest dobre zapoznanie się z obowiązującą w nim terminologią.
Tworzenie nowej grupy dostępności
Autor: Krzysztof Kapustka
Opublikowano: 24.05.2017, 00:00
Liczba odsłon: 4861
Wiemy już mniej więcej czym są i jak działają grupy dostępności Always On, tak więc przyszedł teraz czas na zaprezentowanie sposobu tworzenia takiej grupy w przykładowym środowisku. Jak już wspominaliśmy w poprzedniej publikacji, działanie tego rozwiązania opiera się bezpośrednio na funkcjonalności klastra pracy awaryjnej systemu Windows Server, tak więc zanim w ogóle rozpoczniemy proces tworzenia nowej grupy dostępności musimy uprzednio zdefiniować sobie taki klaster. Jako że funkcja klastra pracy awaryjnej nie jest częścią systemu SQL Server, lecz należy do systemu operacyjnego Windows Server, dokładne informacje w zakresie działania tej technologii i sposobów jej implementacji przedstawiliśmy w dziale poświęconym produktowi Windows Server.
Instalator SQL Server - strona Database Engine Configuration
Autor: Krzysztof Kapustka
Opublikowano: 17.05.2017, 00:00
Liczba odsłon: 4801
Jeśli na ekranie Feature Selection instalatora SQL Server na liście funkcji do zainstalowania zaznaczyliśmy komponent silnika bazy danych realizowany przez usługę Database Engine Service, wówczas jednym z kolejnych kroków instalatora będzie strona Database Engine Configuration, w ramach której będziemy musieli tę funkcję skonfigurować.
Wprowadzenie do wysokiej dostępności i odzyskiwania danych
Autor: Krzysztof Kapustka
Opublikowano: 10.05.2017, 00:00
Liczba odsłon: 7430
W dzisiejszych czasach nowoczesne technologie stanowią podstawę działania praktycznie każdej prosperującej na rynku firmy. Z tego powodu ważne jest, aby technologie te, a w szczególności napędzająca je infrastruktura, były dostępne dla pracowników i klientów przez cały czas. Kto zalicza tzw. downtime, czyli czas, w którym jego firma z powodu problemów technicznych przestaje chwilowo świadczyć swoje usługi, może narazić się na poważne straty finansowe, a nawet ostatecznie wypaść z rynku. Niestety, jako że stosowane na świecie oprogramowanie nie jest pozbawione wad, a wykorzystywany na co dzień sprzęt nie jest niezawodny, do tego rodzaju sytuacji dochodzi na świecie dziesiątki razy każdego dnia.
Zaawansowane ustawienia nowej bazy danych
Autor: Krzysztof Kapustka
Opublikowano: 3.05.2017, 00:00
Liczba odsłon: 6613
Podczas omawiania procesu tworzenia nowej bazy danych z ustawieniami domyślnymi, wykonywanego z poziomu narzędzia zarządzania SQL Server Management Studio, wspomnieliśmy tylko o podstawowych własnoścach bazy danych, których konfiguracja jest niezbędna do tego, aby nowa baza danych mogła zostać pomyślnie utworzona na serwerze. W początkującym okresie nauki obsługi systemu SQL Server odpowiadające tym własnościom ustawienia, zgrupowane na stronie General okna tworzenia nowej bazy danych New Database, są na ogół wystarczające do opanowania podstaw w zakresie działania i tworzenia baz danych, tak więc nie zachodzi potrzeba zagłębiania się w bardziej zaawansowane opcje baz danych. Z czasem jednak będziemy poznawać coraz bardziej złożone zagadnienia, dla których opcje te staną się niezwykle ważne. W części Select a Page okna dialogowego New Database dostępne są jeszcze dwie dodatkowe strony z wieloma innymi ustawieniami zawansowanymi - są to odpowiednio strony Options oraz Filegroups . Przyjrzymy się teraz zawartym w nim ustawieniom, które pomogą nam doprecyzować charakter tworzonej bazy danych.
Łączenie tabel - podstawowe informacje
Autor: Krzysztof Kapustka
Opublikowano: 26.04.2017, 00:00
Liczba odsłon: 6715
Dzięki temu, że na wybranych kolumnach w poszczególnych tabelach danych wprowadzamy ograniczenie klucza podstawowego, możemy od tej pory jednoznacznie identyfikować i odnosić się do konkretnych rekordów danych w tych tabelach. Aby umożliwić nam wykorzystanie maksymalnego potencjału systemu zarządzania relacyjną bazą danych, system SQL Server, zgodnie z relacyjnym modelem danych i stosowanymi w tym modelu zasadami normalizacji tabel, zachęca nas do skrupulatnego rozdzielania przechowywanych informacji do postaci osobnych tabel, nazywanych formalnie relacjami. Po takim podziale danych informacje te zostają zazwyczaj pozbawione początkowego kontekstu i sensu, w jakim występowały przed ich rozdzieleniem, tak więc same w sobie stają się poniekąd mniej lub bardziej użytecznymi wykazami danych.
Pliki i grupy plików
Autor: Krzysztof Kapustka
Opublikowano: 19.04.2017, 00:00
Liczba odsłon: 4970
Podczas omawiania procesu tworzenia nowej bazy danych z ustawieniami domyślnymi wspomnieliśmy krótko o tzw. grupach plików (ang. filegroups). Domyślnie nowa baza danych tworzona jest z wykorzystaniem dwóch plików fizycznych: pliku wierszy danych (.MDF) oraz pliku dziennika transakcji (.LDF), dla których w oknie tworzenia nowej bazy danych lub w ramach odpowiedniego zapytania T-SQL z grupy zapytań CREATE określamy wartości rozmiaru początkowego, wartości automatycznego przyrostu oraz ich docelowe lokalizacje.
Typy i konwersje danych
Autor: Krzysztof Kapustka
Opublikowano: 12.04.2017, 00:00
Liczba odsłon: 17138
W systemie SQL Server typ danych określa rodzaj informacji, jakie mogą być przechowywane w kolumnie tabeli, zmiennej, wyrażeniu czy parametrze, co z kolei pośrednio wyznaczać będzie dopuszczalne operacje, jakie mogą być na tych danych wykonywane. Ilekroć zechcemy zaprojektować nową tabelę do przechowywania nowych danych, dla każdej kolumny tej tabeli będziemy musieli jawnie określić rodzaj gromadzonych w niej informacji. Bez jawnego podawania typów dla przechowywanych wartości system bazy danych nie tylko nie byłby w stanie osiągnąć odpowiedniego poziomu wydajności działania, ale przede wszystkim nie mógłby realizować podstawowych założeń z zakresu integralności danych, takich jak sprawdzanie spójności i poprawności wprowadzonych informacji.