SQL Server: grupa plików tylko dla tabel systemowych?


11

Jednym z naszych standardów korporacyjnych jest oddzielna grupa plików / plik dla tabel użytkowników / indeksów. Jest to ustawione jako domyślne, więc nie ma potrzeby kwalifikowania instrukcji CREATE TABLE.

Tak to wygląda

  • fileid 1 = tabele systemowe, MDF
  • fileid 2 = t-log = LDF
  • fileid 3 = rzeczy użytkownika = NDF

Czy ktoś może mi pomóc w zrozumieniu pierwotnego uzasadnienia, dlaczego nakazano to?


Przyjdę czysty i stwierdzę, że myślę, że to voodoo. Am I nie tak ...?

Edycja: Wiem, jak korzystać z aplikacjami do oddzielania indeksów / partycji / archiwów, a także jak przywracać fragmentarycznie. To pytanie dotyczy użycia oddzielnej grupy plików na tym samym woluminie tylko dla tabel systemowych.

Odpowiedzi:


9

W książce szkoleniowej Microsoft 70-432 napisano: „Głównym powodem, dla którego nie należy umieszczać żadnych obiektów w podstawowej grupie plików, jest zapewnienie jak największej izolacji we / wy. Dane w obiektach systemowych nie zmieniają się tak często, jak dane w swoich obiektach. Minimalizując aktywność zapisu do podstawowego pliku danych, zmniejszasz możliwość wprowadzenia uszkodzeń spowodowanych awariami sprzętowymi. Ponadto, ponieważ stan podstawowej grupy plików determinuje również stan bazy danych, możesz zwiększyć dostępność bazy danych, minimalizując zmiany wprowadzone w podstawowej grupie plików. ”

Więc weź to tak, jak chcesz. Inni twierdzą, że nie jest to konieczne w pewnych okolicznościach i oczywiście jest bardziej do utrzymania. Pomyślałem, że przedstawię rozumowanie Microsoftu.


Rozsądne, jakieś pisemne uzasadnienie. Ja przyjmuję to
gbn

1
Innym powodem jest to, że częściowe przywracanie bazy danych umożliwia przywrócenie podstawowej grupy plików oraz wybranych innych grup plików, co umożliwia szybsze odzyskiwanie poprawnie zaprojektowanego VLDB. Zezwolenie na późniejsze przywrócenie zarchiwizowanych / dodatkowych grup plików.
MartinC

@MartinC: Wiem o częściowym przywracaniu itp., Ale nigdy nie zrozumiałem logiki jawnego oddzielania tabel systemowych. Grupy plików do wykonywania, archiwizacji, konserwacji, partycjonowania itp. Ale tabele systemowe? Jared oferuje najlepsze wyjaśnienie tej pory ..
gbn

Jeśli baza danych jako całość jest bardzo duża, podstawowa grupa plików może mieć bardziej regularną kopię zapasową niż główne dane. Przywracanie wymagałoby tylko kopii zapasowej dziennika ogona i przywracania podstawowej grupy plików i dzienników transakcji, ponieważ kopia zapasowa grupy plików plus ogon. Ponieważ tabele systemowe są małe, proces odzyskiwania byłby szybszy niż w przypadku całej bazy danych, co może skrócić czas przestoju w przypadku wystąpienia problemu.
MartinC

12

Nie jest to wzrost wydajności, można odzyskać zysk. Jeśli nastąpi uszkodzenie plików w tabelach systemowych, baza danych zostanie utracona. Jeśli przechowujesz dane użytkownika w oddzielnej grupie plików (lub grupach), możesz przywrócić tylko te pliki, utrzymując resztę bazy danych w trybie online podczas przywracania (przy założeniu Enterprise Edition tutaj).

Jeśli dlatego właśnie to stwierdzają, nie mogę powiedzieć, ale byłoby to korzystne, gdyby wiele grup plików zawierało tylko obiekty systemowe w grupie plików PODSTAWOWEJ.

Powinieneś jednak wykopać śmieci, mówiąc, że AutoShrink powinien być włączony.


Aby dowiedzieć się więcej na ten temat, możesz wyszukać Online Pieceemeal Restore w Books Online.
Brent Ozar

1
Zawsze myślałem, że to również voodoo, biorąc pod uwagę, że 2 aplikacjami są na tym samym wolumenie (w sieci SAN). Czy ryzyko korupcji jest tak wysokie? (Rzeczywiste operacyjne DBA ustawiają wartość AutoShrink na false)
gbn

Istnieje prawdopodobieństwo, że jeśli dojdzie do uszkodzenia, będzie to pojedyncza strona w jednym pliku, ponieważ pamięć będzie miała problemy z zapisaniem strony na dysk. Coś w rodzaju 99,9999% uszkodzenia bazy danych to problem z pamięcią masową. 1/2 reszty problemów to zła pamięć, reszta to błędy SQL. Ponieważ bazy danych stają się większe (wiele TB), staje się to ważniejsze, ponieważ przywracanie bazy danych o wielu TB zajmie kilka dni.
mrdenny

Czy nie miałbym racji, sądząc, że jeśli obiekty systemowe znajdują się tylko w podstawowej grupie plików, jeśli zajdzie taka potrzeba, będziesz w stanie wykonać następujące czynności. Utwórz x dodatkowych plików w innej grupie plików. Proporcjonalnie wypełnić te pliki, migrując dane z istniejącego pliku danych?
Ally Reilly

4

Nie jestem pewien, czy rozumiem, czy prosisz o usprawiedliwienie twojego standardu korporacyjnego? Sądzę, że ktokolwiek napisał ten dokument dotyczący standardów dla twojej firmy, byłby w stanie rzucić nieco światła na to, dlaczego tak się dzieje.

Biorąc to pod uwagę, niektóre sklepy często wybierają dane systemowe z danych użytkowników. A jeśli jest używany w połączeniu z dedykowanymi zestawami dysków, możesz osiągnąć pewien wzrost wydajności.


Dzięki. Nie uzasadniaj tego, ale wyjaśnij to. To ten sam zespół DB Engineering, który mówi AutoShrink włączony. Biorąc pod uwagę, że tabele systemowe zajmują kilka MB i i tak będą w pamięci, czy wierzysz w jakiś wzrost wydajności?
gbn
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.