Widziałem, że nasza baza danych ma pełny model odzyskiwania i ma dziennik transakcji 3GB.Hows czy duży dziennik transakcji wpływa na wydajność?
W miarę jak log staje się większy, jak to wpłynie na wydajność bazy danych i wydajność aplikacji uzyskujących dostęp do bazy danych?
JD
Zalecaną najlepszą praktyką jest przypisanie pliku dziennika transakcji SQL Server jako "własnego dysku lub jednostki LUN.
Pozwala to uniknąć fragmentacji pliku dziennika transakcji na dysku, o czym wspomniały inne plakaty, a także uniknąć/zminimalizować rywalizację o dysk.
Idealny scenariusz polega na tym, aby administrator bazy danych przydzielił wystarczającą ilość miejsca w dzienniku dla środowiska bazy danych z wyprzedzeniem, tj. Aby przydzielić dane x GB danych za jednym razem. Na dedykowanym dysku stworzy to przylegającą alokację, unikając w ten sposób fragmentacji.
Jeśli potrzebujesz rozbudować swój dziennik transakcji, ponownie powinieneś spróbować zrobić to w dużych porcjach, aby starać się przydzielić w sposób ciągły.
Należy również sprawdzić, czy NIE zmniejszać pliku dziennika transakcji, ponieważ powtarzające się kurczenie i automatyczny wzrost mogą prowadzić do fragmentacji pliku danych na dysku.
Uważam, że najlepiej jest pomyśleć o właściwości bazy danych autogrowth jako niezawodne, tj. DBA powinien proaktywnie monitorować przestrzeń dziennika transakcji (być może poprzez ustawienie alertów), aby zwiększyć rozmiar pliku dziennika transakcji w celu obsługi wykorzystania bazy danych wymagania, ale właściwość autogrowth może być stosowana w celu zapewnienia normalnej pracy bazy danych w przypadku wystąpienia nieoczekiwanego wzrostu.
Większy plik dziennika transakcji sam w sobie, jeśli nie jest szkodliwy dla wydajności, ponieważ serwer SQL zapisuje w dzienniku sekwencyjnie, więc pod warunkiem, że zarządzasz całkowitym rozmiarem dziennika i przydzielaniem dodatkowej przestrzeni odpowiednio, nie powinieneś się martwić.
Jeśli dziennik zostaje rozdrobniony lub musi wzrastać będzie spowolnić aplikację.
Jeśli okresowo nie czyścisz dziennika transakcji, wykonując kopie zapasowe, dziennik zostanie zapełniony i zajmie całe dostępne miejsce na dysku.
Na kilka sposobów.
Jeśli system jest skonfigurowany do automatycznego powiększania dziennika transakcji, gdy plik się powiększy, serwer SQL będzie musiał wykonać więcej pracy, a Ty możesz uzyskać spowolnienie. Kiedy w końcu zabraknie Ci miejsca, nie masz szczęścia, a twoja baza danych przestanie brać nowe transakcje.
Musisz dostać się z DBA (lub może jesteś DBA?) I wykonywać częste, okresowe kopie zapasowe dziennika. Zapisz je z serwera na innym dedykowanym systemie kopii zapasowych. Podczas tworzenia kopii zapasowej dziennika, miejsce w istniejącym pliku dziennika zostanie odzyskane, dzięki czemu dziennik nie będzie dużo większy. Tworzenie kopii zapasowej dziennika transakcji pozwala również przywrócić bazę danych do określonego punktu w czasie po ostatniej pełnej lub różnicowej kopii zapasowej, co znacznie zmniejsza straty danych w przypadku awarii serwera.
Jeśli plik dziennika będzie powiększać się małymi krokami, otrzymasz wiele wirtualnych plików dziennika te wirtualne pliki dziennika spowolnią uruchamianie, przywracanie i tworzenie kopii zapasowej bazy danych.
tutaj jest artykuł, który pokazuje, jak rozwiązać ten problem: http://www.sqlserveroptimizer.com/2013/02/how-to-speed-up-sql-server-log-file-by-reducing-number-of-virtual-log-file/
To mylący tytuł. Jestem pewien, że to tylko literówka, ale "duża transakcja" i "duży dziennik transakcji" to zupełnie inne rzeczy, bo jestem pewien, że wiesz! –