Ustawienia zabezpieczeń logowania I użytkownika



Pobieranie 159,6 Kb.
Data08.02.2018
Rozmiar159,6 Kb.

Ćwiczenie 4

Odtwarzanie bazy danych.


Wprowadzenie teoretyczne. 2

Odtwarzanie bazy danych 2

Odzyskiwanie automatyczne 2

Konfiguracja odzyskiwania automatycznego 3

Odzyskiwanie ręczne 3

Odtwarzanie z plików (ponowne łączenie bazy danych w całość) 4

Znalezienie poprawnego zestawu kopii bezpieczeństwa 4

Sprawdzenie użyteczności zestawu kopii bezpieczeństwa 6

Wykonywanie pełnego odtwarzania bazy danych 6

Odtwarzanie z kopii różnicowej 8

Odtwarzanie z dziennika transakcji 8

Odtwarzanie plików lub grup plików 9

Treść sprawozdania: 15

Przykładowe pytania kontrolne 15





Wprowadzenie teoretyczne.

Odtwarzanie bazy danych


Kopie bezpieczeństwa nie mają wartości same w sobie. Jednak, są bardzo pożyteczne w przypadku problemów z serwerem. Jeżeli dysk przestaje działać prawidłowo lub plik bazy danych zostanie uszkodzony, zachodzi potrzeba odtworzenia baz danych, których pliki uległy uszkodzeniu.

Inną przyczyną odtwarzania bazy danych z kopii bezpieczeństwa jest odtworzenie jej do logicznie spójnego punktu w czasie. Przypuśćmy, że szef usuwa całą sprzedaż z danego dnia o piątej po południu. Można odzyskać dane z wcześniejszej pełnej kopii bezpieczeństwa bazy danych a następnie zastosować wszystkie kopie dziennika transakcji (lub kopię różnicową i kopie dziennika transakcji) aż do momentu zaraz przed tym, jak szef uruchomił polecenie usunięcia danych. Tym sposobem, można odzyskać dane minimalnym nakładem pracy.


Odzyskiwanie automatyczne


Odzyskiwanie automatyczne jest procesem, przez który SQL Server przechodzi za każdym razem, gdy uruchamiana jest usługa SQL Server. Nie można wyłączyć tego procesu i nie potrzeba wykonywać żadnych specjalnych czynności, aby proces nastąpił — dlatego zwany jest procesem automatycznym.

Przy każdym ponownym uruchomieniu SQL Servera, stosowany jest zbiór kroków, które wykonują ponownie (roll forward) wszelkie zatwierdzone transakcje z dziennika transakcji, wykonane od czasu ostatniego punktu kontrolnego (checkpoint). Rolling forward transakcji oznacza, że wszelkie zatwierdzone transakcje bazy danych są ponownie wykonywane w tej bazie danych. SQL Server wycofuje z dziennika transakcji wszystkie transakcje, które nie zostały wcześniej zatwierdzone. Wycofanie (roll back) oznacza, że wszelkie częściowo wykonane — ale nie zatwierdzone transakcje — są usuwane z bazy danych. Po zakończeniu procesu automatycznego odzyskiwania, każda baza danych jest pozostawiana w formie logicznie spójnej i ustawiany jest punkt kontrolny.

Proces odzyskiwania automatycznego gwarantuje, że bez względu na to, jak i dlaczego SQL Server został zatrzymany, zostanie on uruchomiony w stanie logicznie spójnym. Nawet jeśli serwer uległ nagłej awarii, można bez problemów odtworzyć dane. Strony dziennika dla wszystkich zatwierdzonych transakcji są zapisywane na dysk natychmiast (zapis synchroniczny). Dlatego, wszelkie trwałe zmiany w bazie danych są z powodzeniem kopiowane na dysk i używane podczas procesu odtwarzania.


Można prześledzić cały proces odtwarzania przeglądając dziennik błędów (Error Log) SQL Servera:


  1. Należy uruchomić SQL Server Enterprise Manager, jeżeli nie jest otwarty, połączyć się do odpowiedniego serwera, rozwinąć folder Management i rozwinąć opcję SQL Server Logs. Ukaże się lista zawierająca bieżący dziennik błędów i na ogół także ostatnie sześć dzienników błędów.

  2. Należy podświetlić dziennik błędów, który ma być przeglądany. Dziennik pojawi się w prawym panelu SQL Server Enterprise Managera

Można również przeglądać te pliki bezpośrednio przy pomocy edytora takiego jak Notatnik. Pliki te można znaleźć w katalogu \mssql\log, posiadają nazwy errorlog.*, gdzie * jest numerem kopii bezpieczeństwa. Nazwą bieżącego dziennika błędów jest errorlog. (z kropką, ale bez rozszerzenia). Poprzednie dzienniki błędów noszą nazwy odpowiednio errorlog.1, errorlog.2 itd.

  1. Należy rozpocząć od znalezienia wpisu Starting Up Database Master.

Dziennik błędów informuje, że baza danych master została otworzona (pliki są otwarte przez SQL Server) a następnie odzyskana do odpowiedniego logicznego punktu spójności.

Następnie otwierana i odtwarzana jest baza danych model; potem kolejno odtwarzane są — baza danych MSDB i bazy stworzone przez użytkownika (włączając w to bazę pubs i Northwind). Następnie czyszczona i uruchamiana jest baza tempdb (kopiowana z bazy model). Wiadomo, że odzyskiwanie zakończyło się pomyślnie jeżeli w dzienniku błędów pojawi się wpis Recovery Complete ).


Konfiguracja odzyskiwania automatycznego


Istotną rzeczą jaką należy wykonać, aby skonfigurować automatyczne odzyskiwanie jest konfiguracja opcji Recovery Internal. Opcja ta określa maksymalną ilość czasu, jaką SQL Server poświęci na automatyczne odzyskiwanie każdej z baz danych. Wartością domyślną jest 0, oznacza to, że SQL Server będzie automatycznie decydował jak często wstawiać punkt kontrolny.

Parametr konfiguracyjny Recovery Internal wpływa na to, jak często pojawiają się punkty kontrolne. Punkt kontrolny (checkpoint) jest procesem, który wykonuje kopiowanie na dyski stron danych i wpisów dziennika, które były modyfikowane w pamięci. Jeżeli punkt kontrolny jest ukończony, transakcje zatwierdzone przed punktem kontrolnym nie będą już później automatycznie odtwarzane.

Parametr Recovery Interval można skonfigurować przy pomocy procedury systemowej sp_configure. Przykładowo, aby zmienić czas odtwarzania do trzech minut należy uruchomić następujący kod Transact-SQL:
Exec sp_configure 'Recovery Interval',3

Go

Reconfigure with Override



Go

Nie należy zmieniać domyślnego ustawienia Recovery Interval konfiguracji automatycznej. Zmiana tego parametru może grozić spadkiem wydajności z powodu zbyt wielu punktów kontrolnych.

Recovery Interval nie pomaga w przypadku długo trwających transakcji. Załóżmy, że istnieje proces systemowy, który rozpoczyna transakcję a następnie rozpoczyna uruchamianie serii uaktualnień, trwających godzinami, a w pewnym momencie serwer ulega awarii. Jeżeli nie ma wystarczającej ilości pamięci aby przechować w niej wszystkie zmiany i niektóre ze zmian zostają zapisane na dysk, zachodzi potrzeba wycofania tych zmian z bazy danych. Jeżeli wcześniej Recovery Interval został ustawiony na trzy minuty (jak w powyższym kodzie źródłowym), odzyskiwanie bazy danych będzie zapewne trwało dłużej niż trzy minuty. Aby uniknąć tego problemu, należy tworzyć niewielkie transakcje, tak aby było możliwe szybkie odzyskanie poprawnego stanu w przypadku wystąpienia problemów.

Odzyskiwanie ręczne


Odzyskiwanie ręczne — temat kolejnej części tego rozdziału — jest procesem odzyskiwania bazy danych. Proces ten może zawierać odzyskiwanie z pełnej kopii bazy danych, możliwe jest również odzyskiwanie z kopii różnicowej oraz odtwarzanie kopii jednego lub więcej dzienników transakcji z nośników archiwizujących. Szczegóły procesu odtwarzania różnią się w zależności od przyczyn odzyskiwania.

Można odtworzyć bazę danych a następnie zastosować dzienniki transakcji dla pełnego odtworzenia utraconej bazy danych lub odtwarzać do punktu w czasie aby cofnąć zmiany wprowadzone w bazie danych. Można odtworzyć bazę nawet do określonej (zwanej marked transaction) transakcji. Można również użyć różnicowych kopii bazy danych (jeżeli zostały wykonane) co pozwoli na odtworzenie mniejszej ilości dzienników transakcji. SQL Server 2000 posiada nawet opcje do odtwarzania zbioru grup plików (aby przeprowadzić częściowe odtwarzania).

Odtwarzanie bazy danych z kopii bezpieczeństwa ma następujące ograniczenia:


  • Baza danych nie może być używana. Baza danych jest używana jeżeli ktokolwiek zastosował polecenie USE i wskazał tę bazę danych lub jest uruchomione dowolne zapytanie dotyczące tej bazy.

  • Należy posiadać odpowiednie uprawnienia. Bazę danych mogą odtwarzać jedynie użytkownicy należący do roli serwera sysadmin lub dbcreator lub użytkownik dbo. Prawo do wykonywania tego procesu nie może być przekazywane dalej (grant). Prawo do odtwarzania bazy danych jest bardzo istotnym i odpowiedzialnym uprawnieniem.

  • Dzienniki transakcji muszą być odtwarzane w kolejności, w jakiej były tworzone. Każdy dziennik transakcji ma skojarzony ze sobą kolejny numer. Należy odtwarzać kopie dziennika transakcji w prawidłowej kolejności. Nie przestrzeganie tego może zakończyć się nieudanym odtworzeniem bazy. Przed przystąpieniem do odtwarzania kopii dziennika transakcji zostanie przedstawionych wiele rozważań dotyczących warunków odtwarzania.

Odtwarzanie z plików (ponowne łączenie bazy danych w całość)


Przed omówieniem procesów odtwarzania należy rozważyć jedną z możliwych opcji odtwarzania. Można ponownie połączyć bazę danych w całość jeżeli posiada się kopie wszystkich skojarzonych z nią plików danych. SQL Server 2000 może rozdzielić a następnie połączyć ponownie bazy danych przy pomocy procedur składowych Transact-SQL oraz opcji CREATE DATABASE z opcją FOR_ATTACH.

Na początek zostanie omówiona opcja CREATE DATABASE. Poniższy przykładowy kod źródłowy pokazuje tworzenie bazy danych, posiadającej dwa pliki, test_data.mdf oraz test_log.ldf:


create database test

on (filename = 'd:\program files\Microsoft SQL Server\mssql\data\test_data.mdf')

log on (filename = 'd:\program files\Microsoft SQL Server\mssql\data\test_log.ldf')

Kod ten powinien zwrócić komunikat:

Succesfully attached database 'test'.
Warto zauważyć, że jedyne, co należy podać, to nazwa pliku. Kiedy SQL Server znajdzie pliki, może zbudować wszystkie inne informacje jakich potrzebuje, przy pomocy tabel systemowych SQL Servera przechowywanych w bazie danych.

Można również skorzystać z procedury systemowej sp_attach_db. Można wypróbować procedurę poprzez stworzenie na początek bazy danych test (jak w przykładzie) a następnie uruchomienie procedury systemowej sp_detach_db:


Exec sp_detach_db 'test'

Go

Kod ten powinien zwrócić komunikat:



Succesfully detached database 'test'.

DBCC execution completed. If DBCC printed error messages,

contact your system administrator.
Procedura ta „oddziela” bazę danych test od serwera. Można następnie wysłać pliki dowolnej osobie, a odbiorca może uruchomić następujący kod źródłowy (lub można to zrobić własnoręcznie):
EXEC sp_attach_db @dbname = 'test',

@filename1 = 'd:\program files\Microsoft SQL Server\mssql\data\test.mdf',

@filename2 = 'd:\program files\Microsoft SQL Server\mssql\data\test_log.ldf'

Warto zauważyć, że systemowa procedura składowa sp_attach_db zasadniczo wykonuje polecenie CREATE DATABASE FOR ATTACH. Nie ma żadnej różnicy w funkcjonalności tych dwóch opcji (create database i sp_attach_db).


Znalezienie poprawnego zestawu kopii bezpieczeństwa


Pierwszym krokiem jest znalezienie poprawnego zestawu kopii bezpieczeństwa. Można postępować w tym przypadku na dwa sposoby: trudny i łatwy. Powinno się zacząć (jak zwykle) od sposobu trudnego, ponieważ można nauczyć się w ten sposób jakie operacje są wykonywane. Można skorzystać z poniższych trzech poleceń Transact - SQL aby zorientować się (w różnym stopniu szczegółowości) co znajduje się na poszczególnych urządzeniach archiwizacyjnych:

  • RESTORE LABELONLY dostarcza informacji w postaci pojedynczego wiersza na temat całego zbioru kopii bezpieczeństwa.

  • RESTORE HEADONLY dostarcza podsumowania informacji na temat każdego elementu w zestawie kopii bezpieczeństwa.

  • RESTORE FILELISTONLY dostarcza listę baz danych i dzienników zarchiwizowanych na określonym urządzeniu archiwizacyjnym.


RESTORE LABELONLY Jeżeli zostanie uruchomione polecenie RESTORE LABELONLY, nagłówek napędu urządzenia archiwizacyjnego (na ogół polecenie to używane jest w odniesieniu do taśm) jest czytany i podsumowywany w postaci pojedynczego wiersza. Wiersz zawiera nazwę nośnika, określonego podczas tworzenia kopii bezpieczeństwa, opis podany podczas tworzenie kopii bazy danych i datę ostatniej kopii bezpieczeństwa na tym urządzeniu archiwizacyjnym. Zwracane są również inne informacje, ale dopóki nie tworzy się zaawansowanej strategii archiwizacji, nie ma potrzeby zgłębiania szczegółów tych informacji.
RESTORE LABELONLY FROM backup_device

[WITH {NOUNLOAD | UNLOAD } ] [[,] MEDIAPASSWORD = {mediapwd | @mediapwd_var}]


Składnia:

  • backup_device jest nazwą nośnika archiwizującego lub nazwą zmiennej dla tego nośnika archiwizującego. Można określić tutaj w razie potrzeby nazwę pliku, taśmy lub Named Pipe, które mają być używane do odtwarzania bazy (można określić ten parametr jako zmienną). W poprzednim rozdziale w opisie składni polecenia BACKUP można znaleźć szczegółowy opis, co może występować w miejscu backup_device.

  • NOUNLOAD | UNLOAD określa czy taśma zostanie wyjęta gdy zakończy się proces RESTORE LABELONLY.

  • MEDIAPASSWORD jest używany, gdy tworzy się kopię bezpieczeństwa (jeżeli jest w ogóle używany). Jeżeli hasło nie jest znane, a nośnik z kopią bezpieczeństwa jest zabezpieczony hasłem, nie można uruchomić tego polecenia. Posiadanie hasła na indywidualne kopie bezpieczeństwa nie chroni przed wykonaniem polecenia RESTORE LABELONLY; jedynie hasła na cały nośnik chronią przed udanym wykonaniem polecenia dopóki nie zostanie podane prawidłowe hasło.

RESTORE HEADERONLY Polecenie RESTORE HEADERONLY pobiera informację o każdej z kopii bezpieczeństwa znajdują się na nośniku archiwizacyjnym. Polecenie zwraca jeden wiersz dla każdej kopii jaka istnieje dla danej bazy ponieważ, inaczej niż polecenie RESTORE LABELONLY, polecenie RESTORE HEADERONLY czyta pojedynczo informacje z każdej zarchiwizowanej. Proces ten może zabierać dużo czasu jeżeli na taśmie znajduje się kilka kopii bezpieczeństwa. Dla plików kopii bezpieczeństwa na dysku proces ten działa na ogół bardzo szybko.
RESTORE HEADERONLY FROM backup_device

[WITH {NOUNLOAD | UNLOAD } ] [[,] FILE = file_num]

[[,] PASSWORD = { pwd | @pwd_var}]

[[,] MEDIAPASSWORD = {mediapwd | @mediapwd_var}]


Składnia ta używa tych samych opcji co RESTORE LABELONLY, z wyjątkiem przedstawionych poniżej:

  • FILE określa, który zestaw kopii bezpieczeństwa z taśmy ma być testowany. Przykładowo, jeżeli taśma zawiera dwa zestawy kopii bezpieczeństwa, można określić ten parametr jako 1 (pierwszy zbiór) lub jako 2 (drugi zbiór).

  • PASSWORD jest hasłem, podawanym podczas tworzenia kopii bezpieczeństwa.

Wyniki tego polecenia zawierają nazwy kopii bezpieczeństwa (oraz opis) oraz datę ważności danego zestawu. Zawierają również informacje o tym, kto tworzył kopię bezpieczeństwa, z jakiego serwera ona pochodzi, jakie dane zostały zarchiwizowane, jak duża jest kopia bezpieczeństwa oraz kiedy rozpoczęło się i zakończyło tworzenie tej kopii. Wyniki uwzględniają również stronę kodową i kolejność sortowania (używaną w SQL Server 7.0), sposób kodowania (collation —odpowiednik w SQL Server 2000 kolejności sortowania/strony kodowej/Unicode LocalID), tryb zgodności bazy danych i wersję SQL Servera użytą do wykonania kopii bezpieczeństwa. Można uzyskać również wewnętrzną informację o sekwencyjnych numerach dzienników (zakres tej książki nie obejmuje tego tematu).
RESTORE FILELISTONLY Polecenie RESTORE FILELISTONLY zwraca listę plików bazy danych i dziennika, które zostały zarchiwizowane na określonym nośniku archiwizacyjnym. Jednocześnie można uzyskać informację tylko na temat jednej kopii, dlatego w przypadku, gdy nośnik archiwizacyjny zawiera wiele kopii bezpieczeństwa, należy określić, o którą kopię chodzi.

Informacja ta jest szczególnie przydatna w sytuacji odzyskiwania po awarii. Jeżeli baza danych ma być odtworzona a nie jest znane poprzednie położenie plików, można je odnaleźć przy pomocy polecenia


RESTORE FILEONLY:

RESTORE FILEONLY FROM backup_device

[WITH {NOUNLOAD | UNLOAD } ] [[,] FILE = file_num]

[[,] PASSWORD = { pwd | @pwd_var}]

[[,] MEDIAPASSWORD = {mediapwd | @mediapwd_var}]
Składnia jest taka sama jak składnia polecenia RESTORE HEADERONLY.

Jeżeli nie jest znany numer pliku, jaki ma być odnaleziony, należy uruchomić polecenie RESTORE HEADERONLY aby uzyskać listę numerów plików oraz informację, do której kopii bezpieczeństwa należy każdy z plików. Jeżeli nie zostanie określony parametr FILE, polecenie dotyczy pierwszej kopii bezpieczeństwa.


Sprawdzenie użyteczności zestawu kopii bezpieczeństwa


Można przyjąć, że zostały uruchomione odpowiednie procedury sprawdzające DBCC, zanim została stworzona kopia bazy danych. Można również przyjąć, że przy tworzeniu kopii skorzystano z zalet dostępnej opcji Verify. Czy to jednak oznacza, że kopia bezpieczeństwa jest gotowa do odtwarzania?

Odpowiedź "tak", nie do końca odzwierciedla prawdę. Firma Microsoft również ma tą świadomość o czym świadczy polecenie RESTORE VERIFYONLY. Polecenie to sprawdza czy wszystkie taśmy lub pliki dyskowe są dostępne do odtwarzania, i że wszystkie niezbędne informacje mogą być odczytane. Nie jest uruchamiane sprawdzanie DBCC kopii bezpieczeństwa; jest jedynie sprawdzane, czy taśma lub plik dyskowy mogą być odczytane.


RESTORE VERIFYONLY FROM backup_device [,...n]

[WITH [FILE = filen_um] [[,] {NOUNLOAD | UNLOAD } ]

[[,]LOADHISTORY ] [[,] { NOREWIND | REWIND } ]

[[,] PASSWORD = { pwd | @pwd_var}]

[[,] MEDIAPASSWORD = {mediapwd | @mediapwd_var}]
Składnia tego polecenie jest podobna do omówionych wcześniej, z wyjątkiem poniższych parametrów:


  • LOADHISTORY określa czy informacja na temat sprawdzanej kopii bezpieczeństwa zostanie dodana do tabel z historią kopii w bazie danych MSDB. Tabele te zostaną krótko omówione później.

  • NOREWIND | REWIND określa czy taśma powinna być przewinięta po wykonaniu polecenia RESTORE VERIFYONLY.


Wykonywanie pełnego odtwarzania bazy danych


Pełne odtwarzanie bazy danych korzysta z pełnej kopii bezpieczeństwa (można traktować ją jako „normalną” kopię bezpieczeństwa) i umieszcza tę kopię na serwerze. Używa dziennika transakcji, który został zarchiwizowany wraz z kopią bazy danych, aby odtworzyć bazę, wykonać wszystkie zatwierdzone transakcje i wycofać wszelkie nie zatwierdzone transakcje do czasu zakończenia kopii bazy danych. Podobnie jak w przypadku poleceń kopii bezpieczeństwa, polecenie Transact-SQL RESTORE ma więcej funkcji niż polecenie SQL Server Enterprise Managera, a okna SQL Server Enterprise Managera są znacznie łatwiejsze do zrozumienia, gdy widoczne są polecenia uruchamiane na SQL Serverze.

Gdy baza danych jest odzyskiwana dostępnych jest kilka opcji. Można :



  • przesunąć pliki z miejsca, w którym znajdowały się podczas tworzenia kopii bezpieczeństwa

  • ustawić opcję bazy danych RESTRICTED_USER podczas odtwarzania, w przypadku gdy nie zostało jeszcze ukończone odtwarzanie lub dostęp do bazy danych ma zostać ograniczony.

  • wybrać opcję aby odtwarzać lub nie — do określonego, spójnego punktu w czasie (w zależności czy będą stosowane kopie dziennika transakcji) lub do określonej, zaznaczonej transakcji.

  • tworzyć plik wstrzymany( standby). Można tworzyć tego rodzaju plik w przypadku, gdy ma być kontynuowane stosowanie kopii dziennika transakcji ale ma być przetestowany stan bazy danych w trybie „tylko-do-odczytu” pomiędzy odtwarzaniami z tych kopii. Sytuacja ta zostanie krótko omówiona.

  • ponownie uruchomić odtwarzanie, które zostało przerwane w danym punkcie (przykładowo — w przypadku awarii zasilania, która nastąpiła podczas operacji odtwarzania).
Wykonywanie pełnego odtwarzania bazy danych przy pomocy polecenia języka Transact-SQL RESTORE

Można korzystać z polecenia RESTORE aby odtworzyć bazę danych z pełnej kopii bezpieczeństwa. Składnia tego polecenia jest następująca:
RESTORE DATABASE databasename FROM backup_device [,...n]

[WITH [RESTRICTED_USER] [[,] FILE = file_num]

[[,] PASSWORD = { pwd | @pwd_var } ]

[[,] MEDIANAME = { media_name | @media_name_var } ]

[[,] MEDIAPASSWORD = { mediapwd | @mediapwd_var } ]

[[,] MOVE 'logical_file_name' TO 'new_file_name'] [,...n]

[[,] KEEP_REPLICATION]

[[,] {NORECOVERY | RECOVERY | STANDBY = undo_file_name}]

[[,] {NOUNLOAD | UNLOAD}] [[,] REPLACE] [[,] RESTART]

[[,] {NOREWIND | REWIND} ]

[[,] STATS [= percentage]]]

Znaczenie składni:



  • databasename jest nazwą bazy danych, która ma być odtwarzana.

  • backup_device jest nazwą nośnika archiwizacyjnego lub nazwą zmiennej dla nośnika archiwizacyjnego. Można również określić nazwę pliku, taśmy lub Named Pipe jaka ma zostać użyta do odtwarzania — także w postaci zmiennej.

  • RESTRICTED_USER określa, że jedynie członkowie roli serwera sysadmin lub dbcreator lub roli bazy danych db_owner mogą mieć dostęp do bazy danych po wykonaniu odtwarzania.

  • FILE określa, która kopia ma być odtworzona.

  • PASSWORD jest hasłem, które zostało określone podczas tworzenia zestawu archiwizacyjnego.

  • MEDIANAME określa, czy zachowana nazwa nośnika kopii bezpieczeństwa ma być porównywana z daną nazwą nośnika. Jeżeli nazwy do siebie nie pasują, odtwarzanie nie powiedzie się.

  • MEDIAPASSWORD jest hasłem, jakie zostało podane podczas tworzenia kopii bezpieczeństwa (jeżeli zostało określone jakiekolwiek hasło). Jeżeli hasło nie jest znane, a nośnik kopii bezpieczeństwa jest zabezpieczony hasłem, nie można uruchomić tego polecenia.

  • MOVE określa, że dla każdej logicznej nazwy pliku, do której wystąpi odniesienie, operacja odtwarzania powinna znaleźć logiczny plik w zestawie archiwizacyjnym i odtworzyć go do alternatywnej ścieżki i nazwy pliku, jaka została wskazana.

  • KEEP_REPLICATION informuje, że konfiguracja replikacji bazy danych ma być zachowana podczas odtwarzania. Opcja ta jest dostępna do obsługi mechanizmu log shipping, zaawansowanej techniki, nie opisywanej w tej książce.

  • RECOVERY oznacza, że odtwarzanie powinno wycofać wszystkie nie zakończone transakcje i przywrócić bazę danych do spójnego stanu. Po wykonaniu polecenia RECOVERY nie można odtworzyć żadnej kopii dziennika transakcji lub kopii różnicowych bazy danych. Opcja ta występuje domyślnie jeśli nie została określona żadna inna opcja odzyskiwania (NORECOVERY lub STANDBY).

  • NORECOVERY informuje, że odtwarzanie nie powinno wycofywać żadnych nie zachowanych transakcji oraz, że odtwarzanie nie doprowadzi bazy do spójnego punktu. Opcji tej należy używać podczas odtwarzania bazy danych, gdy mają być zastosowane kopie dziennika transakcji lub kopie różnicowe do bazy danych po zastosowaniu pełnego odtwarzania bazy.

  • STANDBY określa ścieżkę i nazwę pliku wycofania (undo file), który przetrzymuje wystarczającą ilość informacji do ponownego uruchomienia transakcji wycofanych podczas procesu odtwarzania. Należy skorzystać z polecenia STANDBY gdy zamierza się testować bazę danych (w trybie do-odczytu) pomiędzy odtwarzaniami różnicowymi lub odtwarzaniami dzienników transakcji. Jeżeli plik, który został określony nie istnieje, SQL Server stworzy wymagany plik.

  • NOUNLOAD | UNLOAD określa czy taśma ma być wyjęta po zakończeniu polecenia RESTORE DATABASE.

  • REPLACE oznacza, że odtwarzanie powinno zastąpić każdą bazę danych o tej samej nazwie istniejącą na danym serwerze. Normalne odtwarzanie bez tej opcji oznacza, że w przypadku gdy nazwa bazy danych różni się od nazwy zarchiwizowanej bazy danych lub gdy zbiór plików z kopii bezpieczeństwa nie pasuje do istniejącej bazy danych, odtwarzanie nie powiedzie się. Jest to opcja związana z bezpieczeństwem.

  • RESTART ponownie uruchamia odtwarzanie kopii bezpieczeństwa od miejsca, w którym zostało ostatnio przerwane. Jak wspomniano wcześniej, opcja ta jest stosowana gdy następuje odtwarzanie z kopii na wielu taśmach, podczas wykorzystywania drugiej lub późniejszej taśmy.

  • NOREWIND | REWIND określa, czy taśma powinna zostać przewinięta po ukończeniu polecenia RESTORE.

Odtwarzanie z kopii różnicowej


Odtwarzania z kopii różnicowej działa podobnie jak odtwarzanie z pełnej kopii bezpieczeństwa. Nie ma różnic w składni polecenia. Należy określić prawidłowy numer pliku z urządzenia archiwizacyjnego.

Można odtworzyć kopię różnicową tylko po odtworzeniu z pełnej kopii bezpieczeństwa. Należy również określić opcję STANDBY lub NORECOVERY podczas odtwarzania z pełnej kopii aby mieć możliwość zastosowania kopii różnicowej.

Kopie różnicowe mogą się kumulować, więc jeśli zostały wykonane trzy kopie różnicowe od czasu wykonania ostatniej pełnej kopii, trzeba odtworzyć jedynie ostatnią z tych trzech kopii różnicowych.

Odtwarzanie z dziennika transakcji


Odtwarzanie z dziennika transakcji nie jest skomplikowane, dopóki ma się na uwadze pewne reguły. Można odtwarzać dzienniki transakcji jedynie w kolejności, w której zostały zarchiwizowane. Inaczej, niż w przypadku kopii różnicowych, kopie dziennika transakcji nie kumulują się, więc potrzeba żeby wszystkie były nienaruszone, aby było możliwe całkowite odtworzenie bazy danych.

W przypadku odtwarzań dziennika transakcji, inaczej niż w przypadku odtwarzania kopii bazy danych lub kopii różnicowych, które pozwalają na odtwarzania jedynie do punktu w czasie gdy kopia była tworzona; można odtwarzać do wybranego punktu w czasie, jak również odtwarzać do nazwanego znacznika w dzienniku transakcji.


Używanie Transact-SQL do odtwarzania dzienników transakcji

Można wykonać polecenie RESTORE LOG aby odtworzyć kopię dziennika transakcji:


RESTORE LOG databasename FROM backup_device [,...n]

[WITH [RESTRICTED_USER] [[,] FILE = file_num]

[[,] PASSWORD = { pwd | @pwd_var } ]

[[,] MEDIANAME = { media_name | @media_name_var } ]

[[,] MEDIAPASSWORD = { mediapwd | @mediapwd_var } ]

[[,] MOVE 'logical_file_name' TO 'new_file_name'] [,...n]

[[,] KEEP_REPLICATION]

[[,] {NORECOVERY | RECOVERY | STANDBY = undo_file_name}]

[[,] {NOUNLOAD | UNLOAD}] [[,] {NOREWIND | REWIND} ]

[[,] RESTART] [[,] STATS [= percentage]]

[[,] STOPAT = datetime]

| [,] STOPATMARK = 'markname' [AFTER datetime]

| [,] STOPBEFOREMARK = 'markname' [AFTER datetime]]]
Składnia ta używa tych samych opcji co składnia dotycząca pełnego odtwarzania bazy danych, z wyjątkiem następujących:


  • STOPAT określa datę i czas, które zostały wybrane jako punkt spójności podczas odtwarzania dziennika transakcji. Dowolne transakcje, które były aktywne (nie zatwierdzone) w tym czasie, zostają wycofane.

  • STOPATMARK wyznacza znacznik (określający zaznaczoną nazwę wpisu) przy którym następuje zatrzymanie.

  • STOPBEFOREMARK pozwala na zatrzymanie zaraz przed określonym znacznikiem.

Po odtworzeniu z pełnej kopii bazy danych (i określeniu opcji STANDBY lub NORECOVERY) można zastosować dziennik transakcji (przyjmując, że istnieje nośnik archiwizacyjny pubs_log_backup i zawiera jedną lub więcej kopii dziennika transakcji):
RESTORE LOG pubs from pubs_log_backup
To wszystko co trzeba wykonać. Dziennik został odtworzony. Całkowite odtworzenie pełnej kopii i kopii dziennika transakcji wygląda w następujący sposób:
RESTORE DATABASE pubs FROM pubs_backup WITH NORECOVERY

RESTORE LOG from pubs_log_backup WITH RECOVERY


RECOVERY jest opcją domyślną, więc nie ma potrzeby stosować jej w odtwarzaniu dziennika transakcji, ale została umieszczona tutaj dla zachowania przejrzystości.

Odtwarzanie plików lub grup plików


W razie potrzeby można odtworzyć również indywidualne pliki lub grupy plików. Dla zachowania spójności tematu niniejszy rozdział zawiera składnię odpowiedniego polecenia dotyczącego odtwarzania plików oraz przykład. Pomimo tego, że tworzenie kopii plików i grup plików to bardzo użyteczne cechy SQL Servera, wymagają one złożonego planowania, aby zapewnić udane korzystanie z tych mechanizmów i są poza zakresem tej książki.

RESTORE DATABASE databasename file_or_filegroup [,...n]

[FROM backup_device [,...n]]

[WITH [RESTRICTED_USER] [[,] FILE = file_num]

[[,] PASSWORD = { pwd | @pwd_var } ]

[[,] MEDIANAME = { media_name | @media_name_var } ]

[[,] MEDIAPASSWORD = { mediapwd | @mediapwd_var } ]

[[,] NORECOVERY ] [[,] {NOUNLOAD | UNLOAD}] [[,] {NOREWIND | REWIND} ]

[[,] REPLACE] [[,] RESTART] [[,] STATS [= percentage]]]
Składnia:
file_or_filegroup : : =

{FILE = {logical_file_name | @logical_file_name_var} |

FILEGROUP = {logical_filegroup_name | @logical_filegroup_name_var}}
Jedyną różnicą pomiędzy tą składnią a składnią polecenia dotyczącego odtwarzania pełnej kopii bazy danych jest to, że w tym poleceniu można określić nazwę pliku lub nazwę grupy plików.

Jeżeli na nośniku archiwizacyjnym został zarchiwizowany plik test_data bazy danych o nazwie o nazwie test_file_backup, można odtworzyć ten plik przy pomocy następujących poleceń:


RESTORE DATABASE test FILE = 'test_data'

FROM test_file_backup WITH NORECOVERY

RESTORE LOG test

FROM test_log_backup WITH RECOVERY

Nie można odtworzyć pliku lub grupy plików bez zastosowania, następnie odtworzenia dziennika transakcji aby doprowadzić bazę danych do spójnego stanu. Przykład ten jest jedynie podpowiedzią w całej złożonej strategii tworzenia kopii bezpieczeństwa plików lub grup plików.

Przebieg ćwiczenia:


Uwaga: wszystkie kody wykonywane w programie Query Analizer zapisywać do plików, gdyż ułatwi to sporządzanie sprawozdania.


  1. Przeniesienie testowej bazy danych „Samochody” do SQL serwera.
    W celu realizacji ćwiczenia Należy pobrać testową bazę „samochod.BAK” ze strony internetowej. W tym punkcie w SQL serwerze będzie odtwarzana ta baza. Plik „samochod.BAK” jest kopią bezpieczeństwa (Backup Device) która została wcześniej stworzona na innym komputerze.

    - Stwórz na dysku c:\ katalog C:\BACKUP. Zapisz ze strony internetowej do tego katalogu plik „samochod.BAK”, zawierający kopie bazy danych.
    - Uruchom program QUERY ANALYZER. Sprawdź poprawność pliku „samochod.BAK” przez instrukcje RESTORE VERIFYONLY. Komunikat „
    The backup set is valid” świadczy o poprawności pliku.
    - Sprawdź treść Backup Device przez instrukcje RESTORE HEADERONLY. Kopia bezpieczeństwa musi zawierać jedną kopie o nazwie „samochody backup”.
    - Uruchom program Enterprise Manager. Kliknji katalog „Data Base”. Wybrać „DataBase->Wszystkie zadania-> Restore Data Base.
    Uruchom okno „Restore Data Base”. W zakładce „General” ustal następujące wartości pól:



Pole

Wartość

Opis pola

Restore as database

Samochody

Nazwa BD serwerze SQL po odtwarzaniu

Restore

From device

Odtwarzanie odbędzie się przez plik Backup Device

Device

C:\BACKUP\ samochod.BAK

Ścieżkę dostępu do Backup Device. Ścieżkę dostępu trzeba ustalić się przez przycisk „Select Device”.

Restore Backup set

True




Database complete

True



W zakładce „Option” musi być ustalona wartość „Leave database operational. No additional transaction logs can be restored” co oznacza, że odtwarzanie odbędzie się bez wykorzystania dziennika transakcji. Kliknij OK. Po otrzymaniu komunikatu „Restore of database „samochody” completed successfully”, kliknij OK.

- W programie Enterprise Manager sprawdź obecność bazy danych, obecność tabel użytkownika: „Klienci”, „Miejsca”, „Samochody”, „Pracownicy”, „Wypozyczenia”.

- Stwórz w QUERY ANALYZER polecenia SQL w celu sprawdzenia obecności danych w każdej z tych tabel.





  1. Tworzenie diagramu związków w programie Enterprise Manager.
    W programie Enterprise Manager stwórz diagram związków pomiędzy tabelami bazy danych samochody: „Klienci”, „Miejsca”, „Samochody”, „Pracownicy”, „Wypozyczenia”. Diagram ten jest schematem fizycznego modelu danych i będzie potrzebny przy konstruowaniu poleceń SQL w następnych punktach ćwiczenia.

    Odtwórz ikonę bazy danych „Samochody”. Kliknji prawym przyciskiem myszy ikonę „Diagrams”, wybierz opcję „New Database diagram”, uruchom wizard „Create database diagram”, gdzie trzeba wybrać potrzebne do diagramu tabele bazy danych: „Klienci”, „Miejsca”, „Samochody”, „Pracownicy”, „Wypozyczenia”.





  2. Modyfikacja bazy danych.
    W tym punkcie baza danych zostanie zmodyfikowana przez dodawanie nowych rekordów do tabel.
    Wpisz w QUERY ANALYZER po jednym nowym rekordzie do każdej z tabel: „Klienci”, „Miejsca”, „Samochody”.
    Sprawdź przez polecenie SQL czy te rekordy zostały wpisane.
    W celu wpisania nowych rekordów może być wykorzystana instrukcja SQL :
    INSERT INTO ... VALUES (...);




  1. Tworzenie urządzenia archiwizacyjnego “Backup Device”.
    Wykorzystując wiedzę z poprzedniego ćwiczenia stwórz nowy „Backup Device” w katalogu C:\BACKUP o nazwie „samochody_backup_1” dla bazy danych „Samochody”. W tym celu można wykorzystać systemową procedurę sp_addumpdevice lub program Enterprice Manager.




  1. Tworzenie kopii bazy danych.
    Wykorzystując wiedzę z poprzedniego ćwiczenia stwórz nową kopię bazy danych „Samochody” na „Backup Device” o nazwie „samochody_backup_1”.
    Nowa kopia musi stworzona z następującymi opcjami:



Opcja

Wartość

NAME

‘Samochody-Full’

DESCRIPTION

‘Druga kopia Full-backup po dodawaniu nowych danych’

Backup

DataBase-complete

Overwrite

Overwrite existing media

Zanotuj datę oraz czas stworzenia kopii. Sprawdź w Enterprise Manager obecność kopii na nośniku archiwizacyjnym „samochody_backup_1”.




  1. Modelowanie nieprawidłowych czynności użytkownika.
    W tym punkcie do bazy danych będą wprowadzone „uszkodzone” dane. Taka sytuacja może zaistnieć w realnych warunkach przy nieprawidłowych czynnościach użytkownika. Administrator bazy danych musi później naprawić uszkodzoną bazę danych.


- Zmodyfikuj tabele do których zostały wpisane nowe dane w p.3., instrukcją Update z grupową modyfikacją danych. Np.:

UPDATE klienci SET nazwisko = 'Kowalski'

- Sprawdź zawartość „zmodyfikowanych” tabel. Dane zostały „uszkodzone”, ponieważ pola jednej kolumny w różnych rekordach tabeli mają tą samą wartość (dla tabeli „Klienci” to jest nazwisko 'Kowalski').





  1. Odtwarzanie bazy danych.
    W tym punkcie baza danych „Samochody” będzie odtwarzana z kopii 'Samochody-Full', która została utworzona w p.5.

- Uruchom Enterprise Manager. Rozwiń „SQL Server Group”->Database”, klinj prawym przyciskiem myszy „Samochody”, klinji „Properties”. Wybierz zakładkę „Option”. Ogranicz dostęp do bazy innym użytkownikom, wybierając „Restrict Access” , „Members of db_owner, dbcreator, or sysadmin” . Kliknji OK. Sprawdź w lewym panelu Enterprise Manager obecność ograniczonego trybu dostępu do bazy”Samochody” „DBO Use Only”.

- Kliknji prawą myszą na lewej konsoli ikonę bazy „Samochody”. Wybierz tryb „Wszystkie zadania”, wybierz opcję ”Restore DataBase”. W oknie „General” ustal następujące parametry:





Pole

Wartość

Restore Database

Samochody

First backup to restore

'Samochody-Full'

Restore (list)

Wybierz potrzebny Backup Device z listy nośników archiwalnych

- Wybierz zakładkę „Option”. Ustaw tryb „Leave database operational. No additional transaction logs can be restored”. Ten tryb ustawi odtwarzanie bazy danych bez wykorzystania dzienników transakcji. Kliknji OK.

- Uruchom QUERY ANALYZER. Sprawdzić tabele, które byli „uszkodzone” w p. 6.


W kolejnych punktach ćwiczenia będą realizowane różne modyfikacje bazy danych, będą tworzone kopie różnicowe oraz kopie „logów” tych modyfikacji. Będzie modelowana sytuacja awaryjna oraz będzie pokazane w jaki sposób należy wykorzystać kopie bezpieczeństwa do odtwarzania bazy danych.



  1. Stworzenie nowego nośnika archiwizacyjnego (Backup Device) , który będzie przeznaczony do jednoczesnego przechowywania pełnej kopii (Full) oraz kopii różnicowych (Differential copies).
    W tym punkcie będzie stworzony nowy nośnik archiwalny (Backup Device) oraz kopia Full bazy danych „samochody”.



- Uruchom QUERY ANALYZER. Stwórz przez procedurę systemową „sp_addumpdevice” nowy nośnik archiwalny z nazwą logiczną „Samochody_backup_2” oraz plikiem C:\Backup\Samochody_backup_2.bak

- Wykorzystując wiedzę z poprzedniego ćwiczenia stwórz nową kopię bazy danych „Samochody” na Backup Device „samochody_backup_2” z następnymi opcjami:




Opcja

Wartość

NAME

'Samochody-Full'

DESCRIPTION

„Kopia Full-backup DB Samochody”

Backup

DataBase-complete

Overwrite

Overwrite existing media




  1. Pierwsza modyfikacja bazy danych. Stworzenie kopii dziennika transakcji.

W tym punkcie będą zmodyfikowane tabele bazy danych w sposób analogiczny do p.3. Do przechowywania zmian w porównaniu z „Kopią Full-backup...” będzie utworzony nowy nośnik archiwizacyjny „Samochody Changes” i do tego nośnika zostanie zapisany dziennik transakcji(log). Na nowym nośniku archiwizacyjnym będą kopie różnicowe (differential backup) oraz kopi logów(dzienników transakcji).

- Wpisz wykorzystując QUERY ANALYZER nowe rekordy do tabel: „Klienci”, „Miejsca”, „Samochody”. Sprawdź wykorzystując polecenia SQL czy te rekordy zostały wpisane.

Do wpisania nowych rekordów może być wykorzystana instrukcja SQL :

INSERT INTO ... VALUES (...);

- Wykorzystując wiedzę z poprzedniego ćwiczenia utwórz nowy „Backup Device” o nazwie „samochody_change” do przechowywania zmian w bazie danych „Samochody”. Plik „samochody_change.bak” musi być w katalogu C:\BACKUP.

- Wykorzystując wiedzę z poprzedniego ćwiczenia utwórz nową kopię dziennika transakcji bazy danych „Samochody” na urządzeniu „Backup Device” „samochody_change” z następującymi opcjami:





Opcja

Wartość

NAME

‘Samochody Changes '

DESCRIPTION

' 1-a modyfikacja - Log and Differential backups BD samochody'

Backup

Transaction Log

Overwrite

Append to media

Sprawdź obecność kopii. Zwracaj uwagę na typ i czas stworzenia kopii.




  1. Druga modyfikacja bazy danych. Stworzenie kopii różnicowej (differential backup).

W tym punkcie będą zmodyfikowane tabele bazy danych w sposób analogiczny pp.3,9. Do przechowywania zmian w porównaniu z „Trzecią kopią Full-backup...” w nośniku archiwizującym będzie stworzona kopia różnicowa (differential backup).

- Wpisz w QUERY ANALYZER nowe rekordy do tabel: „Klienci”, „Miejsca”, „Samochody”. Sprawdź przez polecenie SQL czy te rekordy zostali wpisane.

Dla wpisania nowych rekordów może być wykorzystana instrukcja SQL :

INSERT INTO ... VALUES (...);

- Wykorzystując wiedzę z poprzedniego ćwiczenia stwórz w QUERY ANALYZER za pomocą instrukcji BACKUP DATABASE kopię różnicową bazy danych „Samochody” na „Backup Device” „samochody_change” z opcjami „with DIFFERENTIAL, NOINIT”.

Sprawdź obecność kopii. Zwracaj uwagę na typ i czas stworzenia kopii.




  1. Trzecia modyfikacja danych. Stworzenie kopii dziennika transakcji (logu).

W tym punkcie będą znowu zmodyfikowane tabele bazy danych. Do przechowywania zmian w porównaniu z „Kopią Full-backup...” będzie stworzona druga kopia dziennika transakcji(logu).

- Wpisz w QUERY ANALYZER nowe rekordy do tabel: „Klienci”, „Miejsca”, „Samochody”. Sprawdź przez polecenie SQL czy te rekordy zostały wpisane.

Do wpisania nowych rekordów może być wykorzystana instrukcja SQL :

INSERT INTO ... VALUES (...);

- Wykorzystując wiedzę z poprzedniego ćwiczenia w QUERY ANALYZER przy pomocy instrukcji BACKUP LOG stwórz kopię dziennika transakcji (logu) bazy danych „Samochody” na „Backup Device” „samochody_change” z opcją „with NOINIT”.

Sprawdź obecność kopii. Zwracaj uwagę na typ, czas stworzenia kopii oraz rozmiary wszystkich kopii na urządzniu archiwizacyjnym (Backup Device).




  1. Modelowanie sytuacji awaryjnej.

W tym punkcie będzie modelowana sytuacja gdy serwer SQL nie może uruchomić bazę danych.

- Zamknij programy „Enterprise Manager” oraz „Query Analyzer”. Uruchom program „SQL Server service” oraz zatrzymaj SQL Server.

- Odszukaj w „Windows Explorer” plik bazy danych „Samochody” w katalogu C:\Program Files\Microsoft SQL Server\MSSQL\Data. Zmień nazwę pliku Samochody.mdf na Samochody.bad.

- Zrestartuj SQL Server w programie “SQL Server service”.

- Uruchom „Enterprise Manager”. Rozwiń katalog „Databases”. Zwróć uwagę na komunikat obok ikony „samochody”.

- Rozwiń katalog „Management -> SQL Server Logs”. Odczytaj ostatni „log” SQL serwera. Odszukaj w tym „logu” rekord „Starting up database 'samochody'”. Przeanalizuj komunikaty o błędach, które są w tym logu.

Przed realizacją następnych punktów przeanalizuj zawartość nośników archiwizacyjnych (Backup Device) „Samochody_backup_2” oraz „Samochody_change”. Zwróć uwagę jakie modyfikacje danych są zawarte w tych kopiach.


  1. Odtwarzanie bazy danych z wykorzystaniem kopii różnicowych.

W tym punkcie będzie odtwarzana baza danych z istniejących kopii: kopii Full-Beckup oraz kopii różnicowej.

- Uruchom „Enterprise Manager”. Rozwiń katalog Databases. Kliknij prawym przyciskiem myszy na bazę „Samochody”. Wybierz „Wszystkie zadania ->Restore Database”. W polu „Restore as database” wybierz „Samochody”. W polu „First backup to restore” wybierz ostatnią kopię Full bazy danych „Samochody”. Na liście „Restore” wybierz tylko dwie kopie: „Full” oraz kopię różnicową. Na zakładce „Option” ustaw tryb „Leave database read-only and able to restore additional transaction logs.” Kliknji OK.

Przeanalizuj komunikat obok ikony „samochody”.

- Uruchom Query Analyzer. Utwórz polecenie SQL do odczytania zawartości tabel. Sprawdź czy zostały odtworzone dane w tych tabelach.




  1. Odtwarzanie bazy danych z wykorzystaniem kopii logów.

W tym punkcie będzie odtwarzana baza danych z istniejących kopii: kopii Full-Beckup oraz kopii dziennika transakcji (logu).

- Uruchom „Enterprise Manager”. Rozwiń katalog Databases. Kliknij prawym przyciskiem myszy na bazę „Samochody”. Wybierz „Wszystkie zadania ->Restore Database”. W polu „Restore as database” wybierz „Samochody”. W polu „First backup to restore” wybierz ostatnią kopię Full bazy danych „Samochody”. Na liście „Restore” wybierz tylko jedną kopię: ostatnią kopie dziennika transakcji (logu). W zakładce „Option” ustaw tryb „Leave database operational. No additional transaction logs can be restored.” Kliknji OK.

- Uruchom Query Analyzer. Utwórz polecenie SQL do odczytania zawartości tabel. Sprawdź czy zostały odtworzone dane w tych tabelach.

Treść sprawozdania:


  1. Odnośnie do każdego punktu ćwiczenia umieścić kod Transact-SQl oraz wyniki .

  2. Do kilku wybranych punktów zademonstrować własne przykłady

Przykładowe pytania kontrolne


1. Jaka jest różnica pomiędzy kopiami dziennika transakcji bazy danych oraz kopiami różnicowymi?

2. Została przypadkowo usunięta tabela bazy danych. W jaki sposób można ją odtwarzać?



3. Dlaczego przy odtwarzaniu bazy danych musi być ustalona opcja Restrict Access?

4. Omów zawartość różnych plików przechowywanych w urządzeniach archiwalnych w tym ćwiczeniu.




©operacji.org 2019
wyślij wiadomość

    Strona główna