Konserwacja baz danych systemu SQL Server

Instalacja SQL Server domyślnie tworzy kilka systemowych baz danych na instancję w celu utrzymania i administrowania tą instancją. W tym artykule przyjrzymy się tym systemowym bazom danych i zrozumiemy ich obowiązki.

Systemowe bazy danych SQL Server

W programie SQL Server podczas procesu instalacji tworzone są systemowe bazy danych w celu przechowywania szczegółów konfiguracji specyficznych dla instancji programu SQL Server, aby działały normalnie. Każda instalacja SQL Server tworzy co najmniej 5 systemowych baz danych i 1 systemową bazę danych związaną z replikacją o nazwie dystrybucyjna baza danych który zostanie utworzony przez użytkowników, jeśli w tej instancji skonfigurowana jest replikacja. Każda baza danych systemu ma swój cel i zbadamy to szczegółowo w dalszej części tego artykułu.

Bazy danych systemu to:

Master – instalowany domyślnie
Msdb — Instalowany domyślnie
Model — Instalowany domyślnie
Tempdb — Instalowany domyślnie
Zasób – Instalowany domyślnie . Wprowadzony w SQL Server 2005 i dostępny w późniejszych wersjach SQL Server, a zatem niedostępny w SQL Server 2000 i wcześniejszych wersjach.
Dystrybucja – Utworzony przez działanie użytkownika . Użytkownicy mogą utworzyć bazę danych dystrybucji, aby skonfigurować replikację.

Aby wyświetlić systemową bazę danych zainstalowaną w SQL Server, możemy użyć SSMS.

Połącz się z instancją SQL Server, rozwiń Bazy danych > Systemowe bazy danych :

Czy zauważyłeś, że Zasób bazy danych brakuje na powyższej liście? Chodzi o to, że baza danych zasobów to specjalna systemowa baza danych, która nie jest wymieniona w Eksploratorze obiektów SSMS. Możemy jednak wysłać zapytanie o szczegóły bazy danych zasobów z systemowego DMV o nazwie sys.sysaltfiles i wykonaj zapytanie:

SELECT dbid, db_name(dbid) database_name, fileid, name, filename
FROM sys.sysaltfiles
WHERE dbid NOT BETWEEN 5 AND 11

W wynikach możemy zobaczyć bazy danych systemu w kolejności:master, tempdb, model, msdb, dystrybucja i wreszcie dbid 32767 który jest bazą danych zasobów. Jednak ta baza danych zasobów nie wyświetla żadnej nazwy bazy danych, ponieważ nie ma wpisu w sys.databases . Wykluczyłem kilka baz danych użytkowników między dbid 5 a 11 i uwzględniłem AdventureWorks_REPL jako przykład, aby pokazać, że DMV może wyświetlać również bazy danych użytkowników. Więcej szczegółów na temat bazy danych zasobów i innych systemowych baz danych omówimy później.

Ograniczenia dotyczące baz danych systemu SQL

Ponieważ bazy danych systemu zawierają krytyczne szczegóły konfiguracji systemu, należy zastosować odpowiednie środki bezpieczeństwa, aby uniknąć przypadkowego usunięcia danych. Dlatego bazy danych systemu mają następujące ograniczenia w porównaniu z bazami danych użytkowników:

Systemowych baz danych nie można przenieść do trybu offline

Możemy przełączyć bazę danych użytkowników w tryb offline za pomocą polecenia ALTER DATABASE, jak pokazano poniżej:

ALTER DATABASE AdventureWorks SET OFFLINE WITH ROLLBACK IMMEDIATE
GO

Jeśli jednak spróbujemy przełączyć którąkolwiek z systemowych baz danych do trybu OFFLINE za pomocą powyższego polecenia, otrzymamy błąd, jak pokazano poniżej:

Systemowych baz danych nie można usunąć

Chociaż możemy usunąć bazy danych użytkowników, wykonując polecenie DROP DATABASE

DROP DATABASE AdventureWorks

Jeśli spróbujemy USUNĄĆ którąkolwiek z systemowych baz danych, otrzymamy błąd, jak pokazano poniżej:

Nie można zmienić właściciela systemowych baz danych

Właścicielem bazy danych systemu jest sa domyślnie. Nie można tego zmienić. Próby zmiany nazwy właściciela bazy danych systemu spowodują błędy.

Jest jednak wyjątek. Możliwe jest zmodyfikowanie właściciela msdb baza danych.

use [master];
GO
ALTER AUTHORIZATION ON DATABASE::[master] TO [RRJ\RRJ]
GO

Nazwa bazy danych systemowych baz danych nie może zostać zmieniona

Jeśli spróbujemy zmienić nazwy baz danych systemu, otrzymamy komunikat o błędzie, jak pokazano poniżej:

ALTER DATABASE master MODIFY NAME = RRJ_master;
GO

Składania systemowych baz danych nie można zmienić

Systemowe bazy danych są tworzone z nazwą sortowania wybraną podczas instalacji programu SQL Server. Po zainstalowaniu nie można zmienić sortowania systemowych baz danych. Jedynym sposobem na zmianę sortowania systemowych baz danych jest ponowna instalacja instancji SQL Server z poprawnym sortowaniem.

Podstawowa grupa plików systemowych baz danych nie może być ustawiona na tryb READ_ONLY

Ponieważ systemowa baza danych przechwytuje krytyczne informacje związane z instancjami SQL Server, SQL Server nie zezwala na ustawienie podstawowych plików danych znajdujących się w podstawowej grupie plików jako tylko do odczytu .

Zmiana funkcji przechwytywania danych nie może być włączona w systemowych bazach danych

Ta funkcja służy do śledzenia każdej zmiany DML zachodzącej w bazie danych w śledzonych tabelach. Jeśli spróbujemy włączyć funkcję zmiany przechwytywania danych w dowolnej systemowej bazie danych, wystąpi błąd:

use master
GO
exec sys.sp_cdc_enable_db

Teraz, gdy mamy jasność co do różnicy między systemowymi bazami danych a bazami danych użytkowników, możemy bardziej szczegółowo zbadać cele każdej systemowej bazy danych.

Baza danych główna w serwerze SQL

Baza danych systemu głównego zawiera kluczowe szczegóły konfiguracji związane z instancją SQL Server . SQL Server polega na nich podczas uruchamiania konkretnej instancji. Jeśli z jakiegoś powodu nie można uruchomić głównej bazy danych, instancja SQL Server również się nie uruchomi.

Te kluczowe szczegóły przechowywane w głównej bazie danych obejmują konta logowania, szczegóły serwera połączonego, punkty końcowe, ustawienia konfiguracji systemu i szczegóły dotyczące wszystkich baz danych użytkowników.

Teraz pojawia się pytanie. Skąd usługa SQL Server wie, gdzie są dostępne pliki danych i dzienników głównej bazy danych? Odpowiedź leży w parametrach konfiguracji startowej usługi SQL Server.

Aby wyświetlić parametry konfiguracji startowej instancji SQL Server, powinniśmy najpierw wiedzieć o wbudowanym narzędziu o nazwie Menedżer konfiguracji SQL Server . Pomaga zarządzać wszystkimi usługami związanymi z SQL Server we wszystkich instancjach dostępnych na danym serwerze. Aby wyświetlić te dane, otwórz Menedżera konfiguracji serwera SQL, który wyświetli listę, jak pokazano poniżej:

Kliknij Usługi serwera SQL aby wyświetlić listę usług dostępnych na tym serwerze lub komputerze:

Poczekaj sekundę! Wygląda znajomo z services.msc wyświetla listę wszystkich usług dostępnych na serwerze, ale wyświetla tylko usługi związane z serwerem SQL.

Otwórzmy services.msc aby zobaczyć, jak to wygląda i zweryfikować różnice między Menedżerem konfiguracji programu SQL Server i services.msc aby porównać, który z nich jest lepszy.

Menedżer konfiguracji programu SQL Server wyświetla identyfikator procesu aktualnie uruchomionych usług. Nie mogliśmy tego znaleźć w services.msc . Oczywiście możemy uzyskać te informacje z Menedżera zadań systemu Windows, ale Menedżer konfiguracji serwera SQL pomógł nam wyświetlić je w jednym miejscu.

Przyjrzyjmy się teraz szczegółowemu widokowi. Kliknij prawym przyciskiem myszy usługę SQL Server z services.msc . Zobaczysz następujące menu:Ogólne , Zaloguj się , Odzyskiwanie i Zależności .

W Menedżerze konfiguracji SQL Server kliknij prawym przyciskiem myszy SQL Server(MSSQLSERVER) usługa> Właściwości . Zawiera listę poniższych menu — Logowanie, Serwis. FileStream, Advanced, Alwayson OnHigh dostępność i Parametry uruchamiania .

Parametry uruchamiania Usługi przechowującej lokalizację plików danych i dzienników głównej bazy danych była dostępna tylko w Menedżerze konfiguracji SQL Server .

Kliknij Parametry uruchamiania aby wyświetlić szczegóły – dla istniejącego Parametry . Zobaczysz następujące informacje:

Fizyczna lokalizacja głównej bazy danych Plik danych
Fizyczna lokalizacja głównej bazy danych Plik dziennika transakcji
Fizyczna lokalizacja Folderu ErrorLog gdzie znajdują się błędy związane z usługą SQL Server.

Możemy dodać więcej parametrów startowych, takich jak Tryb pojedynczego użytkownika (-m) itp. W tym celu musimy określić niezbędne wartości w Określ parametr startowy i kliknij Dodaj .

Zauważyliśmy, że SQL Server Configuration Manager nie tylko wyświetla zaawansowane szczegóły, ale także pozwala na wiele zaawansowanych konfiguracji związanych z usługą SQL Server. Dlatego osobiście polecam użycie SQL Server Configuration Manager do zatrzymywania/uruchamiania usług związanych z SQL Server w porównaniu z domyślną opcją Services.msc.

Zalecane praktyki dotyczące głównej bazy danych

Ponieważ główna baza danych przechowuje krytyczne szczegóły dotyczące instancji SQL Server, zaleca się przestrzeganie najlepszych praktyk podczas obsługi tej bazy danych.

Każda zmiana konfiguracji na instancji SQL Server będzie przechowywana w głównej bazie danych. Dlatego zawsze musisz wykonać pełną kopię zapasową bazy danych master, aby przywrócić najnowszy stan w przypadku, gdy przywracamy bazę danych master z pełnej kopii zapasowej, zgodnie z wymaganiami.

Mimo że SQL Server pozwala użytkownikom tworzyć tabele użytkowników lub inne obiekty w głównej bazie danych, nie jest to zalecane. Główna baza danych powinna pozostać prosta i czysta. Jeśli potrzebujesz utworzyć obiekty użytkownika w bazie danych master, powinieneś częściej wykonywać pełne kopie zapasowe bazy danych master.

SQL Server obsługuje opcję procedury uruchamiania do wykonywania określonych procedur składowanych po uruchomieniu instancji programu SQL Server. Używa sp_procoption procedura. Zachowaj ostrożność podczas korzystania z tej opcji, ponieważ posiadanie nieoptymalnego kodu lub logiki rekurencyjnej może wpłynąć na czas uruchamiania instancji SQL Server.

Jeśli SQL Server nie mógł się uruchomić z powodu jakichkolwiek problemów z bazą danych master, musimy przywrócić bazę danych master z ostatniej znanej dobrej kopii zapasowej.

Model bazy danych w SQL Server

Jak sama nazwa wskazuje, Baza danych systemu modeli działa jako model lub szablon do tworzenia dowolnej bazy danych użytkownika pod względem ścieżki do pliku, początkowego rozmiaru, ustawień automatycznego wzrostu, modelu odzyskiwania i innych opcji konfiguracyjnych .

Wszelkie obiekty użytkownika, takie jak tabele, procedury itp., które są tworzone w modelowych bazach danych, będą również tworzone automatycznie w nowych bazach danych użytkowników w tej instancji SQL Server.

Zweryfikujmy to, tworząc nową tabelę w bazie danych modelu:

Sprawdźmy, czy ta tabela jest obecna w bazie danych modelu:

Baza danych modelu przechowuje również domyślną ścieżkę pliku baz danych użytkownika, jak pokazano poniżej we Właściwościach bazy danych msdb baza danych.

Zgodnie z obecną konfiguracją Początkowy rozmiar pliku obu Danych i Pliki dziennika jest ustawiony na 8 MB z automatycznym wzrostem dla obu ustawionym na 64 MB.

Jeśli potrzebujesz utworzyć bazę danych użytkownika w innej ścieżce pliku zamiast lokalizacji pliku bazy danych modelu, możemy ją zmodyfikować w Właściwościach serwera tej instancji serwera SQL.

W programie SSMS kliknij prawym przyciskiem myszy Serwer > Właściwości > Ustawienia bazy danych . Wyświetl domyślne lokalizacje bazy danych:

Zmień ścieżkę pliku na żądaną ścieżkę i kliknij OK . Baza danych użytkowników Dane i Dziennik pliki zostaną utworzone w nowej podanej ścieżce.

Utwórzmy nową bazę danych o nazwie model_test i sprawdź nowe ścieżki plików danych i dziennika bazy danych wraz z właściwościami plików Initial i Autogrowth oraz model_verify tabela w nowej bazie danych.

Zweryfikujmy test_modelu Ścieżki plików danych i dziennika. Kliknij prawym przyciskiem myszy test_modelu baza danych> Właściwości > Pliki :

Jak widać, Dane i Dziennik pliki model_test bazy danych tworzone są zgodnie ze ścieżką dostępną w bazie danych modelu. Wartość początkowego rozmiaru pliku danych i dziennika wynosi 8 MB. Wartość Autowzrostu to 64 MB. Te wartości są zgodne z konfiguracją bazy danych modelu.

Teraz sprawdzimy, czy model_verify tabela jest tworzona w model_test Baza danych. Możemy zobaczyć tę nową bazę danych.

Oprócz tabel dotyczy to widoków, procedur składowanych, funkcji i wszelkich obiektów utworzonych w bazach danych modelu.

Zalecane praktyki dotyczące bazy danych modeli

Ponieważ modelowa baza danych działa jako szablon dla każdego nowego tworzenia bazy danych użytkownika, powinniśmy zastosować poniższe praktyki, gdy mamy do czynienia z nią:

Za każdym razem, gdy chcesz wprowadzić jakiekolwiek zmiany w konfiguracji bazy danych modelu (np. początkowy rozmiar pliku, rozmiar autowzrostu, tworzenie, modyfikowanie lub usuwanie obiektów użytkownika), natychmiast wykonaj pełną kopię zapasową bazy danych modelu.

Ponieważ wszelkie obiekty użytkownika utworzone w bazach danych modelu są tworzone w dowolnych bazach danych użytkownika, pamiętaj, aby dodać tylko wymagane obiekty. W przeciwnym razie we wszystkich bazach danych użytkowników zostanie utworzonych wiele niepotrzebnych obiektów, a Ty spędzisz dużo czasu na ich sortowaniu i czyszczeniu baz danych.

Skonfiguruj parametry początkowego rozmiaru pliku i automatycznego wzrostu dla plików danych i dziennika. Pomaga lepiej zarządzać rozmiarami plików danych i dzienników w bazach danych użytkowników i poprawiać wydajność.

Baza danych MSDB

Baza danych systemu msdb przechowuje poniższe krytyczne informacje w tabelach systemowych:

Pozycje związane z agentem SQL Server, takie jak zadania, historie zadań, alerty, operatorzy, proxy itp.
Funkcje SQL Server, takie jak Service Broker i Database Mail ze szczegółami konfiguracji i historii.
Szczegóły tworzenia kopii zapasowych i przywracania serwera SQL Server są przechowywane w tabelach bazy danych msdb.
Konfiguracje przesyłania dziennika, profile agenta replikacji i konfiguracje modułu zbierającego dane.
Plany konserwacji, pakiety SSIS i kilka innych szczegółów.

Innymi słowy, baza danych systemu msdb przechowuje wszystkie krytyczne informacje związane z usługami SQL Server Agent Services i niektórymi innymi powiązanymi usługami.

Zalecane praktyki dotyczące bazy danych msdb

Baza danych msdb przechowuje wiele krytycznych informacji konfiguracyjnych związanych z agentami SQL Server, zadaniami i pocztą bazy danych. Przechowuje również szczegóły historyczne. Dlatego powinniśmy zastosować poniższe praktyki podczas pracy z bazą danych msdb:

W instancji SQL Server z wieloma skonfigurowanymi bazami danych lub zadaniami rozmiar bazy danych msdb będzie stale wzrastał przez pewien czas. W związku z tym należy codziennie wdrażać pełne kopie zapasowe baz danych msdb wraz z innymi bazami danych użytkowników. Jeśli msdb otrzyma wiele krytycznych informacji, możemy zmienić model odzyskiwania bazy danych msdb na pełny, a następnie zaimplementować również kopię zapasową dziennika transakcji.

Chociaż SQL Server pozwala użytkownikom tworzyć obiekty użytkownika w bazie danych msdb, nie zaleca się tworzenia żadnych tabel użytkowników ani obiektów w bazie danych msdb i dalszego zwiększania rozmiaru bazy danych msdb.

Przeprowadzaj regularne czyszczenie tabel systemowych msdb, aby utrzymać kontrolę nad rozmiarem bazy danych msdb i uniknąć wpływu na wydajność posiadania ogromnych danych w kilku tabelach.

Baza danych Tempdb

Baza danych systemu tempdb można uznać za globalny obszar roboczy dostępny dla wszystkich użytkowników podłączonych do instancji SQL Server w celu wykonywania operacji SELECT lub innych .

Baza danych Tempdb będzie przechowywać poniższe typy obiektów, podczas gdy użytkownicy wykonują swoje operacje:

Obiekty tymczasowe utworzone jawnie przez użytkowników mogą być lokalnymi lub globalnymi tabelami i indeksami tymczasowymi, zmiennymi tabel, tabelami używanymi w funkcjach o wartościach przechowywanych w tabeli i kursorami.
Obiekty wewnętrzne utworzone przez silnik bazy danych, takie jak:
- Tabele robocze używane do wyników pośrednich dla buforowania, kursorów, sortowania i tymczasowych dużych obiektów (LOB)
- Pliki robocze dla operacji agregujących Hash Join lub Hash
- Wyniki sortowania pośredniego podczas tworzenia lub odbudowywania indeksów, jeśli SORT_IN_TEMPDB jest ustawiona na ON i inne operacje, takie jak zapytania GROUP BY, ORDER BY lub UNION
Sklepy wersji, które obsługują wersjonowanie wierszy, obsługują albo wspólny magazyn wersji, albo magazyn wersji kompilacji indeksu online.

Za każdym razem, gdy usługa SQL Server zostanie uruchomiona lub ponownie uruchomiona, baza danych tempdb zostanie utworzona od nowa za pomocą bazy danych modelu. Dlatego tempdb jest jedyną systemową bazą danych, której nie można wykonać kopii zapasowej .

Jeśli spróbujemy wykonać kopię zapasową, otrzymamy błędy:

Ponieważ używamy tempdb w prawie wszystkich operacjach użytkownika, ta baza danych stanowi poważne wąskie gardło wydajności w kilku wersjach SQL Server. Począwszy od SQL Server 2016, Microsoft wdrożył kilka technik optymalizacji – omówimy je później.

Zanim przejdziemy do zalecanych praktyk dotyczących bazy danych tempdb, rzućmy okiem na jej pliki danych w domyślnej konfiguracji, jak pokazano poniżej:

W mojej obecnej instancji SQL Server mamy 4 pliki danych i jeden plik dziennika dla bazy danych tempdb.

Począwszy od SQL Server 2016, mamy instalator SQL Server, który pozwala nam dodawać wiele plików do tempdb. Powyższe 4 pliki o początkowym rozmiarze 8 MB i rozmiarze autowzrostu 64 MB zostały utworzone przy użyciu domyślnych opcji pokazanych poniżej.

Jeśli mamy pojedynczy plik danych w bazie danych tempdb, wszystkie rdzenie logiczne dostępne na serwerze próbują uzyskać dostęp do tego samego pliku danych tempdb, co powoduje wąskie gardło wydajności.

Posiadanie wielu plików danych logicznie kojarzy niektóre rdzenie z jednym plikiem. W związku z tym mamy mniejszą rywalizację o pliki danych tempdb. Poprawi to wpływ wydajności na pliki danych tempdb.

Zalecane praktyki dla bazy danych tempdb

Ponieważ baza danych tempdb jest jak globalny obszar roboczy dla wszystkich działań użytkownika, rozmiar tempdb wzrasta w zależności od działań użytkownika. Może to być wąskie gardło wydajności dla całej instancji SQL Server.

Dlatego powinniśmy wdrożyć następujące praktyki:

Umieść pliki danych i dziennika tempdb w magazynie o wysokiej wydajności, aby uzyskać wyższe IOPS dla lepszej wydajności.
Upewnij się, że baza danych tempdb jest podzielona na wiele plików danych, aby zmniejszyć rywalizację i uniknąć wąskich gardeł wydajności w bazie danych tempdb.
- Jeśli liczba rdzeni logicznych jest mniejsza niż 8, możemy mieć jeden plik danych tempdb na rdzeń logiczny. W naszej instancji testowej mieliśmy 4 rdzenie logiczne. Dlatego 4 pliki danych w tempdb powinny wystarczyć.
- Jeśli liczba rdzeni logicznych jest większa niż 8, zacznij od 8 plików danych i zwiększ o 4 pliki danych, jeśli w bazie danych tempdb zaobserwowano problemy z rywalizacją i wydajnością.
- Jeśli liczba rdzeni logicznych w serwerze wynosi 32 lub 64, możemy zacząć od 8 plików danych. Oznacza to, że 4 rdzenie lub 8 rdzeni są powiązane logicznie z jednym plikiem danych.
  
  Aby uzyskać więcej jasności na temat wielu plików danych tempdb, polecam doskonały artykuł Paula Randala.
Upewnij się, że pliki danych tempdb są skonfigurowane z optymalnym początkowym rozmiarem pliku. W idealnym przypadku powinno to zostać osiągnięte poprzez podejście prób i błędów. Tempdb z optymalnym początkowym rozmiarem pliku zwykle rośnie mniej razy w porównaniu do tempdb skonfigurowanego z mniejszym początkowym rozmiarem pliku, który zwykle rośnie kilka razy, co prowadzi do fragmentacji. Na przykład w bieżącej konfiguracji wszystkie pliki są skonfigurowane z początkowym rozmiarem pliku 8 MB, który jest zbyt mały, aby obsłużyć obciążenia SQL. Dlatego zastosuj podejście Trial and Error i ustaw początkowy rozmiar pliku na 512 MB lub 1 GB lub inną wartość.
Upewnij się, że wszystkie pliki danych tempdb są ustawione na taki sam rozmiar pliku. Właściwości automatycznego wzrostu muszą być jednakowo zdefiniowane. W naszym scenariuszu wszystkie pliki są ustawione na autorozrost 64 MB. Ustawienie rozmiaru autowzrostu na 512 MB lub 1 GB, lub jakakolwiek inna odpowiednia wartość pomaga zmniejszyć częsty autorozrost w plikach danych tempdb.
Upewnij się, że początkowy rozmiar pliku i autorozrost dla pliku dziennika tempdb są skonfigurowane do optymalnej wartości podobnej do plików danych tempdb. Ponieważ model odzyskiwania tempdb jest domyślnie ustawiony na Prosty i nie można go modyfikować, skonfigurowanie początkowego rozmiaru pliku i właściwości autogrowth pliku dziennika tempdb powinno wystarczyć.

Tempdb ma kluczowe znaczenie dla wydajności instancji SQL Server. W następnych artykułach szczegółowo przyjrzymy się częstym problemom, z jakimi borykają się tempdb i jak optymalnie je zmniejszyć.

Baza danych zasobów w SQL Server

Baza danych systemu zasobów jest jedyną systemową bazą danych tylko do odczytu, która nie jest wymieniona w systemowych bazach danych w SSMS, jak widzieliśmy wcześniej.

Identyfikator bazy danych (dbid) baz danych zasobów we wszystkich instancjach wyniesie 32767, co jest również maksymalną liczbą baz danych obsługiwaną w ramach instancji SQL Server. Można go pobrać z sys.sysaltfiles systemowy DMV. Wykonanie poniższego zapytania SELECT na sys.sysaltfiles zwróci zestaw wyników pokazujące, gdzie znajdują się pliki danych i dzienników bazy danych zasobów:

Widzimy fizyczne pliki bazy zasobów dostępne we wspomnianej ścieżce. Data modyfikacji wskazuje czas instalacji instancji SQL Server lub ostatni czas zastosowania dodatków Service Pack (SP) lub aktualizacji zbiorczej (CU) w tej instancji.

Baza danych zasobów zawiera wszystkie obiekty systemowe, takie jak sys.objects , sys.bazy danych , sys.sysaltfiles , itp. fizycznie w nim. Ta baza danych logicznie wyświetla wszystkie te obiekty w schemacie sys we wszystkich bazach danych dostępnych w instancji . Ponieważ baza danych zasobów jest tylko do odczytu, nie można w niej tworzyć obiektów ani danych użytkownika.

Baza danych systemu zasobów została wprowadzona począwszy od programu SQL Server 2005, aby przyspieszyć aktualizację programu SQL Server do nowej wersji SP lub CU. Przed wprowadzeniem tej opcji wszystkie takie uaktualnienia i aktualizacje oznaczały, że zmiany będą obowiązywać we wszystkich bazach danych, czyniąc proces aktualizacji bardziej skomplikowanym i czasochłonnym. Teraz każda aktualizacja wersji SQL Server lub aktualizacja SP lub CU po prostu aktualizuje lub zastępuje bazę danych zasobów.

Ponieważ baza danych zasobów jest tylko do odczytu i nie jest widoczna dla użytkowników, nie wymaga żadnej interwencji użytkownika. Jeśli chcesz uwzględnić kopię zapasową bazy danych zasobów w planowaniu wysokiej dostępności lub odzyskiwania po awarii, po prostu wykonaj kopię zapasową plików mssqlsystemresource.mdf i mssqlsystemresource.ldf po zatrzymaniu usług SQL Server (usługa SQL Server nie pozwoli na kopiowanie plików podczas Usługa SQL Server jest już uruchomiona) i zapisz ją w bezpiecznej lokalizacji. Zwróć szczególną uwagę, aby nie aktualizować go na żadnej instancji SQL Server działającej z inną wersją poziomów SP lub CU, ponieważ może to spowodować nieoczekiwane problemy.

Dystrybucyjna baza danych w SQL Server

Baza danych systemu dystrybucji jest sercem replikacji. Użytkownicy mogą tworzyć lub konfigurować dystrybucyjną bazę danych w ramach instalacji replikacji za pomocą Kreatora konfiguracji dystrybucji lub Kreatora tworzenia publikacji. Szczegółowo opisaliśmy kroki tworzenia dystrybucyjnej bazy danych w ramach mojego poprzedniego artykułu o wewnętrznych mechanizmach replikacji transakcyjnej serwera SQL.

Zalecane praktyki dotyczące bazy danych dystrybucji

Ponieważ baza danych dystrybucji jest niezbędna dla funkcjonalności replikacji, powinniśmy wdrożyć następujące praktyki:

Przenieś bazę danych dystrybucji i pliki dziennika na dysk z dobrym IOPS, aby uniknąć problemów z wydajnością dystrybucji.

Skonfiguruj właściwości początkowego rozmiaru pliku i automatycznego wzrostu bazy danych dystrybucji do lepszej wartości, aby uniknąć problemów z fragmentacją.

Dołącz dystrybucyjną bazę danych do zadań konserwacji pełnej kopii zapasowej bazy danych.

Dołącz dystrybucyjne bazy danych do zadań konserwacji indeksu, aby uniknąć fragmentacji i problemów z wydajnością.

W moim artykule na temat wewnętrznych funkcji replikacji transakcyjnej SQL Server znajdziesz również zalecenia dotyczące innych skutecznych praktyk.

Wniosek

Dziękujemy za przeczytanie kolejnego, pełnego mocy artykułu!

Mam nadzieję, że pomogło to w wyjaśnieniu istoty i celów baz danych systemu SQL Server oraz poznaniu najlepszych praktyk, aby uniknąć problemów z wydajnością w tych bazach danych.