Najlepszy sposób na tworzenie kopii zapasowych i obcinanie dzienników transakcji zgodnie z harmonogramem

Nie jestem DBA, ale rzeczy są takie, jakie są, muszę nosić kapelusz DBA i skonfigurować plany konserwacji w mojej instancji SQL Server.

Tak więc przez pewien czas miałem nocny proces SSIS, aby uruchomić wykonywanie zadania SQL, aby wykonać kopie zapasowe - w zasadzie, master.dbo.xp_create_subdiraby upewnić się, że istnieją foldery docelowe, a następnie BACKUP DATABASE [DbName] TO DISK = 'G:\Backups\DbName\DbName.bak' WITH INIT.

Ilekroć to zadanie się nie udawało, reszta procesu przerywała się, a ja dostawałem powiadomienie i przychodziłem następnego ranka, aby zauważyć, że dysk dla dzienników transakcji jest zapełniony, więc ręcznie skróciłem je i ruszyłem dalej. .. dopóki historia się nie powtórzy i dzienniki transakcji ponownie nie przekroczą dostępnego miejsca na dysku.

Skrypt „ręcznego obcinania” wygląda następująco:

use Staging;
alter database Staging set recovery simple
alter database Staging set recovery full
dbcc shrinkfile ('Staging_log', 0, truncateonly);
go

Więc mam już tego dość i postanowiłem zamiast tego zrobić wszystko właściwie , i postępować zgodnie z instrukcjami tutaj i stworzyć rzeczywisty plan konserwacji :

Rzecz w tym, że nigdy wcześniej tego nie robiłem, więc mam kilka pytań:

• Czy tworzenie kopii zapasowej dzienników transakcji automatycznie skróci je, czy jest coś jeszcze, co muszę zrobić?
• Czy można jednocześnie wykonywać kopie zapasowe danych i dzienników transakcji? Jeśli nie, to jak to zrobić?
• Pliki kopii zapasowych są pobierane przez noc przez inny proces, który pobiera wszystkie pliki na serwerze i przechowuje je w innym miejscu - czy dobrym pomysłem byłoby wygaśnięcie zestawu kopii zapasowych po 2 dniach? Czy muszę w ogóle wygasać?
• Zadania czyszczenia odpowiednio usuwają „stare” pliki .bak i .trn z podfolderów G:\Backups. Czy to ma sens?
• Czy lepiej byłoby to zrobić w usłudze SSIS, abym mógł zawieść ETL, jeśli / kiedy kopia zapasowa się nie powiedzie? A może powinienem w ogóle obchodzić mój proces ETL?

Przepraszam, jeśli to zbyt wiele pytań do jednego postu, w razie potrzeby dokonam edycji i zadam wiele pytań - myślę, że wszystkie są ze sobą ściśle powiązane.

Tylko z dnia na dzień SSIS robi zapisy, dzień to wszystko czyta - Potrzebuję tylko codziennego odzyskiwania.

Wybierz model odzyskiwania na podstawie potrzeb biznesowych:

• Ile firm danych może stracić i jednocześnie przetrwać?

W oparciu o powyższą odpowiedź należy dokładnie wybrać model odzyskiwania bazy danych .

W prostych słowach (nie omawiając masowo rejestrowanego modelu odzyskiwania) ,

• Pełny model odzyskiwania umożliwia tworzenie kopii zapasowych dzienników, które umożliwiają odzyskiwanie w określonym czasie.
  • Obcinanie dziennika może wystąpić, gdy wykonujesz kopie zapasowe dziennika transakcji, tzn. Przestrzeń na pliki dziennika zostanie ponownie wykorzystana po każdej kopii zapasowej dziennika i nie będzie wzdęcia!
• Prosty model odzyskiwania pozwala tylko na PEŁNE kopie zapasowe. Odzyskiwanie punktu w czasie nie jest możliwe.
  • Obcinanie dziennika może wystąpić tylko wtedy, gdy wystąpi punkt kontrolny (ręcznie lub automatycznie), tzn. Ponieważ wykonujesz regularne pełne kopie zapasowe, nie musisz się martwić o dziennik transakcji, ponieważ PUNKT KONTROLNY zajmie się ponownym użyciem nieaktywnej części pliku dziennika.

Pamiętaj, że obcięcie dziennika NIE jest fizycznym zmniejszeniem rozmiaru pliku dziennika transakcji. Oznacza to, że nieaktywna część pliku dziennika transakcji jest oznaczona jako wielokrotnego użytku .

Dlatego należy odpowiednio ustawić plik dziennika transakcji (i pliki danych) odpowiednio. Powiększenie pliku dziennika spowoduje uruchomienie zdarzeń autogrowth (jeśli twoja baza danych jest ustawiona na autogrow w ostateczności). Sprawdź moją odpowiedź - Wzrost gospodarczy - Procent wykorzystania?

Gorąco polecam, abyś porzucił plany konserwacji i wdrożył [inteligentne rozwiązanie konserwacyjne - które jest łatwe, elastyczne i zgodne z najlepszymi praktykami] - 5 . - Rozwiązanie do tworzenia kopii zapasowych Oli (a także rozwiązanie do konserwacji indeksu ).

pozwala odpowiedzieć na twoje pytania:

Czy tworzenie kopii zapasowej dzienników transakcji automatycznie skróci je, czy jest coś jeszcze, co muszę zrobić?

Nie dołączaj kopii zapasowych ani nie wygasaj. Tworzą wielki bałagan. Używaj INITi wykonuj osobne kopie zapasowe dziennika ze znacznikiem daty i godziny. Łatwe w utrzymaniu. Użyj do tego rozwiązania do tworzenia kopii zapasowych Oli. Rozwiązanie jest elastyczne w usuwaniu również starych kopii zapasowych.

Czy można jednocześnie wykonywać kopie zapasowe danych i dzienników transakcji? Jeśli nie, to jak to zrobić?

Pełna kopia zapasowa nie ma wpływu na kopię zapasową w dzienniku T. Pełna kopia zapasowa zawiera tylko niezbędny dziennik transakcji, aby w przypadku przywracania baza danych mogła być transakcyjnie spójna z czasem, w którym zakończyła się część pełnej kopii zapasowej z odczytem danych. Sprawdź - ile dzienników transakcji zawiera pełna kopia zapasowa?

Ponadto wykonanie kopii zapasowej dziennika podczas pełnej kopii zapasowej nie obciąży dziennika transakcji. (Kilka) kopii zapasowej dziennika po zakończeniu pełnej kopii zapasowej spowoduje obcięcie dziennika.

Pliki kopii zapasowych są pobierane przez noc przez inny proces, który pobiera wszystkie pliki na serwerze i przechowuje je w innym miejscu - czy dobrym pomysłem byłoby wygaśnięcie zestawu kopii zapasowych po 2 dniach? Czy muszę w ogóle wygasać?

Zadania czyszczenia odpowiednio usuwają „stare” pliki .bak i .trn w podfolderach G: \ Backups. Czy to ma sens? Czy lepiej byłoby to zrobić w usłudze SSIS, abym mógł zawieść ETL, jeśli / kiedy kopia zapasowa się nie powiedzie? A może powinienem w ogóle obchodzić mój proces ETL?

W obu przypadkach użyj rozwiązania do konserwacji kopii zapasowych Oli. Zajmie się usuwaniem starych plików.