Model odzyskiwania programu SQL Server 2008 / R2

Prawie wszystkie nasze bazy danych na niektórych serwerach nie wymagają modelu pełnego odzyskiwania (nie wykonujemy kopii zapasowych dzienników transakcji), a domyślnie powinno zawsze być tworzone bazy danych i określany model prostego odzyskiwania.

Dość często i z pewnych praktycznych powodów wiele baz danych tworzy się za pomocą SSMS. Można jednak popełnić błędy, a operator może zapomnieć o określeniu modelu prostego odzyskiwania. Prowadzi to do „niespodzianki” kilka dni później, gdy pudełko ma problemy z miejscem na dysku z powodu trzech lub czterech plików dziennika 60 GB, które nigdy nie zostały obcięte.

Mogę ustawić model Simple Recovery jako domyślne ustawienie dla nowych baz danych, konfigurując model odzyskiwania w modelbazie danych. Czy jest to jednak zalecane, jeśli to zrobię, czy może wrócić i ugryźć mnie w jakikolwiek sposób w przyszłości?

Widzę tutaj jedną z trzech opcji:

1) możesz mieć szablonowy skrypt do tworzenia baz danych, które jawnie obejmują model odzyskiwania.

2) możesz ustawić modelbazę danych na prostą i nie musisz się tym martwić.

3) możesz mieć nadzieję, że wszyscy pamiętają, co wydaje się być tym, co robisz. (Niepolecane)

Osobiście wybrałbym numer dwa. Po to jest baza danych modeli.

Dodawanie do @ Surfer513

4) Zasady zarządzania oparte na zasadach albo w celu wymuszenia prostego modelu odzyskiwania, albo co najwyżej powiadomienia, gdy baza danych nie jest

Chociaż preferuję ustawienie prostego modelu, nie uniemożliwia to użycia polecenia T-SQL i ustawienia go na coś innego. Możesz użyć zasady, aby ocenić, czy model odzyskiwania nie jest prosty, i zdecydować się na zmianę zasad przez Ciebie.

Ten artykuł MSSQLTip.com dotyczy sprawdzania pełnej, ale możesz łatwo sprawdzić, czy Twoja jest prosta. Możesz także sprawdzić, czy w bazie danych kiedykolwiek miała miejsce kopia zapasowa.

Bezpiecznym zakładem jest przejście do trybu pełnego DB, ale wtedy masz problem z logowaniem wzrostu. Teraz jest kilka opcji:

• Ogranicz maksymalny rozmiar pliku dziennika. Wpłynie to na operacje po osiągnięciu tego limitu. Korzyścią jest to, że zapobiegnie to sytuacjom, w których na dysku zabraknie miejsca, a następnie wystąpią większe problemy.
• Twórz alerty, które będą uruchamiane, gdy plik dziennika wzrośnie powyżej znaku wodnego, a następnie zarządzaj nim.
• Zaplanuj zadania zmniejszania dziennika. Zmniejszanie dzienników szkodzi wydajności twojego DB. Nie sugerowałbym tego.

Będąc DBA powinieneś korzystać ze wszystkich opcji, które pomagają w odzyskiwaniu. To zależy również od Twojej umowy SLA z firmą.

Mimo to zarządzam kilkoma bazami danych w trybie prostym. Wynika to z zastrzeżeń zawartych w umowie SLA. Firma zdecydowała się nie wydawać na dyski z plikami dziennika (możesz zabrać konia do wody, ale nie możesz go pić). Firma zarządza tworzeniem kopii zapasowych, przywracaniem i odzyskiwaniem danych. Wystąpił błąd DR, a utracone pieniądze były większe niż to, co kosztowałoby dodatkowe miejsce na dysku.