Poniżej przedstawiam kilka dobrych ogólnie znanych praktyk kierowanych do administratorów baz danych MS SQL Server związanych z utrzymaniem środowiska.
- Tworzenie i utrzymywanie standaryzowanego środowiska – jeżeli tylko mamy taką możliwość starajmy się doprowadzić do ujednolicenia konfiguracji używanych serwerów MS SQL Server. Należy również starać się używać tego samego systemu Windows Server OS i wersji i wydań SQL Server. Podobnie należy starać się utrzymywać wszystkie swoje zadania utrzymania baz danych i zadania SQL Agent tak samo (przyjęta konwencja nazewnicza, konta techniczne itp.). Jeśli to jest tylko możliwe ustawiajmy te same parametry serwera czy też baz danych (Collation, Ansi Nulls, Arithmetic abort itp., unifikacja ścieżek dla data, logu i backupu). Utrzymanie standaryzowanego środowiska zmniejszy złożoność operacyjną i zmniejszy ryzyko wystąpienia błędów.
- Twórzmy serwery baz danych jako dedykowane tylko do usług SQL Server – instancje SQL Server powinny zawsze działać na dedykowanym serwerze, nie powinny być na tych serwerach instalowane dodatkowe aplikacje czy usługi nie związane z SQL. Podobnie najlepiej unikać uruchamiania wielu instancji SQL Server na tym samym serwerze. Istnieją wyjątki od tego, w dzisiejszych czasach zazwyczaj lepiej jest uruchomić różne instancje w oddzielnych maszynach wirtualnych. Należy również wyłączyć wszelkie niepotrzebne usługi Windows Server i SQL Server (np. dla czystej instancji SQL jako Database Engine należy powyłączać / lub nie instalować wszystkie nieużywane usługi np. SSAS, SSRS itp.).
- Nadawaj uprawnienia zgodnie z zasadą najmniejszego uprzywilejowania – nadaj tylko uprawnienia zgodnie z regułami bezpieczeństwa, jakie musi posiadać każdy użytkownik i administrator. Nie nadawaj programistom uprawnień administratora. Nie używaj konta SA do uruchamiania usług ani wykonywania czynności. Najlepiej konto SA wyłączyć, a w to miejsce założyć inne konto techniczne. Najlepiej uruchomiać usługi SQL Server przy użyciu konta domenowego. Najlepiej jest tworzyć konta na podstawie grup domenowych, gdzie użytkownikami takich Loginów będą grupy domenowe. Uprawnienia dla użytkowników baz danych nadajemy poprzez uprzednio ustawione role bazodanowe. Dzięki temu, gdy np. przychodzi do pracy nowy deweloper, wystarczy tylko dodać konto nowego dewelopera do z góry ustalonej grupy domenowej. W ten sposób z automatu nowy użytkownik ma nadane wszystkie uprawnienia. Inny aspekt tej sprawy to np. szybka zmiana uprawnień poprze rolę bazodanową.
- Zarządzanie plikami danych i plikiem loga transakcyjnego – w prawie wszystkich przypadkach AUTOGROW powinien być włączony w plikach danych i plikach dziennika. Podobnie należy wyłączyć AUTOSHRINK unikając dzięki temu cyklicznemu shrinkowaniu plików. Podczas tworzenia plików danych i plików dzienników należy tak planować wielkość tworzonych plików, aby była zapewniona wystarczającą ilość miejsca, aby zminimalizować zdarzenia AUTOGROW. Pliki danych MDF powinny znajdować się na różnych dyskach niż pliki dziennika LDF. Ustawienia te dotyczą również TempDB.
- Wdrażanie i testowanie planów tworzenia kopii zapasowych i przywracania – Zazwyczaj należy zaplanować pełne tworzenie kopii zapasowych codziennie na wszystkich bazach danych produkcyjnych. Zalecaną najlepszą praktyką jest utworzenie zadania agenta SQL, aby zautomatyzować proces tworzenia kopii zapasowych. Zadania tworzenia kopii zapasowych powinny korzystać z funkcji RESTORE WITH VERIFYONLY w celu sprawdzenia integralności kopii zapasowej. Należy również regularnie przeprowadzać testowe odtwarzanie baz danych z kopi zapasowych, aby zweryfikować ich poprawność. W tym procesie najlepiej mieć przygotowane skrypty go backupu i restore. Warto też zaplanować odtwarzanie całego środowiska (OS , SQL i bazy).
