W tym artykule przyjrzymy się błędom DBA, których konsekwencje były dość zauważalne i z którymi musiałem się zmierzyć.
Celem artykułu jest uniemożliwienie użytkownikom powtarzania tych błędów. Czasami złe doświadczenie jest nawet cenniejsze niż pozytywne.
- Procent przyrostu plików bazy danych
Ponieważ wzrost plików bazy danych jest operacją dość zasobożerną, może się wydawać, że określenie tego wzrostu w procentach może być dobrym pomysłem. Zgadzam się, że wiele wytycznych zaleca ustawienie stałego przyrostu w MB, a nie procentu. Nie wyjaśniają jednak przyczyn. Zgodnie z praktyką nie zaleca się ustawiania przyrostu pliku bazy danych powyżej 1 GB, ponieważ MS SQL Server przydzieli 1 GB 2 razy, a nie 2 GB naraz.
Ponadto, jeśli przydzielisz mniej niż 32 MB , prędzej czy później baza danych po prostu zwolni. Dlatego lepiej ustawić stały przyrost plików bazy danych od 32 do 1024 MB. Dlaczego jednak nie można określić przyrostu plików bazy danych w procentach? Okazuje się, że jak tylko plik ma mniej niż 1 MB, DBMS zaokrągla tę wartość do 0 MB i przestaje powiększać ten plik. W rezultacie system nie działa. Aby dowiedzieć się, o ile potrzebujemy powiększyć plik, wystarczy wykonać codzienną analizę, aby sprawdzić, o ile każdy plik zyskuje w MB i ustawić odpowiednią liczbę w zakresie od 32 do 1024 MB. Możemy zbierać statystyki dotyczące wzrostu plików bazy danych w następujący sposób. - Istnieje wiele kluczy obcych dla tabeli
Czy kiedykolwiek próbowałeś sprawdzić plan, usuwając przynajmniej jeden wiersz z tabeli, do której odwołują się prawie setki innych tabel? Będziesz zaskoczony, gdy dowiesz się, ile jest zagnieżdżonych pętli. Wszystkie są weryfikacjami kluczy obcych. Dlatego jeśli tabele są duże (ponad milion rekordów), lepiej wyłączyć klucze obce dla tabeli, w której dane będą usuwane. Następnie musisz usunąć wszystkie niezbędne i powiązane dane. Następnie włącz klucze obce. Podobna sytuacja ma miejsce w przypadku kaskadowych aktualizacji i usuwania. Jeśli jest dużo linków zewnętrznych (setki), usunięcie nawet jednego wiersza może prowadzić do długiego i bardzo rozległego blokowania. - Wiele niepotrzebnych indeksów
Bardzo często można zauważyć we wskazówkach, że przy tworzeniu kluczy obcych konieczne jest budowanie indeksów, zwłaszcza gdy używa się tych kluczy do złączeń. Musisz sprawdzić, czy indeksy są używane, w przeciwnym razie te niepotrzebne indeksy spowalniają tylko operacje modyfikacji danych. Aby to sprawdzić, użyj następującego zapytania:select DB_NAME(t.database_id) as [DBName] , SCHEMA_NAME(obj.schema_id) as [SchemaName] , OBJECT_NAME(t.object_id) as [ObjectName] , obj.Type as [ObjectType] , obj.Type_Desc as [ObjectTypeDesc] , ind.name as [IndexName] , ind.Type as IndexType , ind.Type_Desc as IndexTypeDesc , ind.Is_Unique as IndexIsUnique , ind.is_primary_key as IndexIsPK , ind.is_unique_constraint as IndexIsUniqueConstraint , t.[Database_ID] , t.[Object_ID] , t.[Index_ID] , t.Last_User_Seek , t.Last_User_Scan , t.Last_User_Lookup , t.Last_System_Seek , t.Last_System_Scan , t.Last_System_Lookup from sys.dm_db_index_usage_stats as t inner join sys.objects as obj on t.[object_id]=obj.[object_id] inner join sys.indexes as ind on t.[object_id]=ind.[object_id] and t.index_id=ind.index_id where (last_user_seek is null or last_user_seek <dateadd(year,-1,getdate())) and (last_user_scan is null or last_user_scan <dateadd(year,-1,getdate())) and (last_user_lookup is null or last_user_lookup <dateadd(year,-1,getdate())) and (last_system_seek is null or last_system_seek <dateadd(year,-1,getdate())) and (last_system_scan is null or last_system_scan <dateadd(year,-1,getdate())) and (last_system_lookup is null or last_system_lookup <dateadd(year,-1,getdate())) and t.database_id>4 and t.[object_id]>0 -- system databases are excluded
- Nieefektywne wykorzystanie zasobów
Często zaleca się przechowywanie dziennika transakcji i pliku bazy danych na różnych urządzeniach pamięci masowej. Jeśli używasz RAID 10 z 4 i więcej dyskami SSD, nie ma sensu izolować plików od siebie. W razie potrzeby, aby uzyskać większą szybkość, baza danych tempdb może być przechowywana na dysku, który jest podzielony z pamięci RAM. Ponadto zbyt duże ilości pamięci RAM dostarczonej do DBMS sprawią, że ten ostatni wypełni całą pamięć nieistotnymi planami zapytań. - Złe kopie zapasowe
Zawsze konieczne jest nie tylko sprawdzenie utworzonych kopii zapasowych, ale także przeniesienie ich na stanowisko testowe i ich odtworzenie. Wszystko to musi zostać zautomatyzowane z dalszym powiadamianiem administratorów o zarówno problematycznych, jak i udanych odzyskaniach. - Zła odporność na awarie
Przed utworzeniem klastra składającego się z dwóch lub więcej serwerów należy upewnić się, że system przechowywania danych jest również odporny na awarie. Jeśli to drugie zawiedzie, cała tolerancja na błędy zostanie zredukowana do zera. - Skomplikowane diagnostyka bez prostych kontroli
Jeśli nastąpi awaria systemu, najpierw musisz sprawdzić logi MS SQL Server, a następnie poszukać głębiej. Powinieneś najpierw przeprowadzić proste kontrole, a następnie przejść do złożonej diagnostyki. - Zagubione stoły
Tabele można rozbudować o niepotrzebne dane, które należy zarchiwizować w osobnej bazie danych lub usunąć. Ponadto tabele nie mogą być dłużej używane.
To są sytuacje, z którymi się spotkałem. Dlatego polecam, aby nie powtarzać powyższych błędów.
Jeśli chciałbyś podzielić się swoimi doświadczeniami lub takimi błędami podczas administrowania bazami danych, daj mi znać – chętnie o nich porozmawiam.
