r07 05

[ Pobierz całość w formacie PDF ]
.Inne sposoby sprawdzenia integralnościNastępne trzy polecenia DBCC CHECKCATALOG, DBCC CHECKALLOC i DBCC CHECKTABLE są podzbiorem DBCC CHECKDB.Polecenia te wymagają, aby użytkownik należał do roli serwera sysadmin lub roli baz danych db_owner.Te same warunki stosują się do używania DBCC CHECKDB.DBCC CHECKCATALOG Polecenie DBCC CHECKCATALOG sprawdza integralność referencyjną tabel systemowych.Więcej informacji na ten temat zostało przedstawionych w rozdziale 14.DBCC CHECKCATALOG ( 'database_name') [WITH NO_INOFMSGS]W tej składni database_name oznacza nazwę bazy danych, której integralność na być sprawdzona.Poniżej przedstawiono przykład użycia tego polecenia:DBCC CHECKCATALOG ('Pubs')Wynik:DBCC results for 'pubs'.DBCC execution completed.If DBCC printed error messages, contact your system administrator.Warto zauważyć, że pojawiają się tylko dwie linie wynikowe.Dla tego polecenia, opcja NO_INFOMSGS eliminuje jedynie pierwszą linię:DBCC Results for 'databasename'.DBCC CHECKALLOC DBCC CHECKALLOC sprawdza, czy informacje na temat alokacji (oznaczającej — jakie rozszerzenia są własnością jakich tabel) w bazie danych są poprawne.DBCC CHECKALLOC ('database_name' [, NOINDEX |{ REPAIR_ALLOW_DATA_LOSS |REPAIR_FAST | REPAIR_REBUILD }] )[WITH {[ALL_ERRORMSGS | NO_INFOMSGS], [TABLOCK] [,ESTIMATEONLY][, TABLERESULTS]}]Wszystkie parametry w tej składni mają takie samo znaczenie jak w przypadku DBCC CHECKDB.DBCC CHECKTABLE Polecenie DBCC CHECKTABLE wykonuje te same operacje co DBCC CHECKDB ale jest ograniczone do pojedynczej tabeli.Jest to bardzo przydatne jeżeli ma zostać sprawdzona jedna duża tabela ale nie ma potrzeby sprawdzania całej bazy danych.DBCC CHECKTABLE ('table_name' [, NOINDEX | index_id|{ REPAIR_ALLOW_DATA_LOSS |REPAIR_FAST | REPAIR_REBUILD }] )[WITH {[ALL_ERRORMSGS | NO_INFOMSGS],[TABLOCK] [,ESTIMATEONLY], [PHYSICAL_ONLY].[TABLERESULTS]}]W przypadku tej składni wszystkie opcje są takie same jak dla DBCC CHECKDB z wyjątkiem dwóch:ltable_name jest nazwą tabeli, której integralność ma zostać sprawdzonallindex_id oznacza, że ma zostać sprawdzona integralność pojedynczego indeksu (Identyfikatory indeksów — ID zostaną omówione w rozdziale 13).lTworzenie kopii bezpieczeństwa bazy danychJest wiele do zrobienia zanim stworzy się kopię bezpieczeństwa bazy danych.Nie jest to nigdy sprawa trywialna, nawet w przypadku niewielkiego systemu.Po utworzeniu nośników archiwizacyjnych i sprawdzeniu poprawności baz danych, nadszedł czas na stworzenie kopii bezpieczeństwa każdej bazy danych.Pierwszym krokiem jest sprawdzenie jakie nośniki archiwizujące będą używane i jak należy używać te nośniki.Opcje nośnika archiwizacyjnegoMożna stworzyć kopię bezpieczeństwa na pojedynczym nośniku archiwizacyjnym lub na wielu nośnikach; można także umieścić wiele kopii bezpieczeństwa na pojedynczym nośniku archiwizacyjnym.Za każdym razem, odwołując się do nośnika archiwizacyjnego, należy określić nazwę pliku zamiast polecenia BACKUP.Kopie bezpieczeństwa na pojedynczym nośniku archiwizującym (single-device)Kopia na pojedynczym nośniku jest domyślnym i najczęstszym sposobem archiwizacji.Jeżeli każda baza danych jest archiwizowana na odrębnym nośniku, można przeprowadzić strategię kopiowania jeden-do-jednego.Jeżeli kopia bezpieczeństwa ma być na dyskach, podejście to jest zalecane.Jeżeli z pewnych przyczyn został utracony plik, została w związku z tym utracona pojedyncza kopia bezpieczeństwa pojedynczej bazy danych a nie wiele kopii bezpieczeństwa zawartych w pojedynczym pliku.Jeżeli kopia bezpieczeństwa jest na taśmie, tworzenie kopii wielu baz danych na pojedynczej taśmie jest bardziej akceptowalne (i mniej kosztowne).Kopie bezpieczeństwa równolegle rozproszone (parallel striped)Kopie bezpieczeństwa równolegle rozproszone pozwalają na tworzenie kopii pojedynczej bazy danych na wielu nośnikach archiwizacyjnych.Wystarczy podać więcej niż jeden nośnik archiwizacyjny w poleceniu BACKUP.SQL Server 2000 inicjuje wątek dla każdego wybranego nośnika w kopii równolegle rozproszonej.Istnieje możliwość używania w tym przypadku do 24 nośników (oraz wynikających z tego wątków).Silnym argumentem za używaniem kopii bezpieczeństwa równolegle rozproszonych są kopie na taśmach.Można podłączyć wiele taśm w tym samym czasie.Jeżeli tworzenie kopii bazy danych zajmuje trzy godziny, a zakupi się dwa dodatkowe napędy taśmowe (czyli w sumie trzy), można z dużym prawdopodobieństwem przyjąć, że tworzenie kopii bezpieczeństwa zakończy się w godzinę.Istotną sprawą jest to, że nie potrzeba tej samej ilości napędów taśmowych do odtworzenia bazy danych z kopii bezpieczeństwa.Jest to szczególnie istotne w przypadku odtwarzania po awarii.Nie ma gwarancji, że posiada się taką samą ilość napędów taśmowych na serwerze odtwarzającym.Jednak, nadal potrzeba posiadać wszystkie taśmy aby odtworzyć bazę danych.Jeżeli w przypadku kopii równolegle rozproszonej wykorzystywana jest taśma, nie może być ona wykorzystana do innych celów jak tylko do kolejnej kopii równolegle rozproszonej z tą samą ilością napędów taśmowych aż do czasu ponownego sformatowania taśmy.Wiele kopii bezpieczeństwa na pojedynczym nośnikuMożna również umieścić wiele kopii bezpieczeństwa na pojedynczym nośniku archiwizacyjnym.Jest to domyślna konfiguracja w przypadku korzystania z taśm.Należy się spodziewać, ze użytkownik będzie chciał umieścić tak wiele kopii bezpieczeństwa na pojedynczej taśmie jak to jest możliwe.Można również zastosować tę metodę w przypadku dysków; jednak to podejście nie jest polecane dla dysków — jeżeli pojedynczy plik zostanie utracony lub ulegnie uszkodzeniu, wszystkie kopie bezpieczeństwa na tym nośniku są stracone.Polecenie BACKUP DATABASE dla całej bazy danychTworzenie bazy danych jest następnym logicznym krokiem (końcowym) [ Pobierz całość w formacie PDF ]

�

Podobne