masz dobry powód do niepokoju, ponieważ DB kurczy się w SQL Server często „ssać”. Paul Randal, szef Storage Engine w SQL 2005, stwierdził, że ShrinkDB jest napisany bardzo słabo. Znajduje pustą przestrzeń, pobierając dane na samym końcu i umieszczając je na samym początku i robiąc to, aż będzie miało wolne miejsce na „końcu” plików DB. W tym momencie może zwolnić miejsce z SQL Servera i zwrócić go systemowi operacyjnemu. Skutecznie cofasz swoje pliki bazy danych, więc zwykle zobaczysz masywną fragmentację. O jego poglądach możesz przeczytać w tym poście na blogu lub w tym wideo MCM Internals
Tak jak w przypadku wszystkiego, naprawdę musisz najpierw przetestować je w swoim środowisku. Lepszym sposobem na to jest przeniesienie danych do innej grupy plików. Możesz wykonać przebudowę indeksu online za pomocą indeksu klastrowego, a następnie ponownieindeksować w nowej grupie plików. Następnie możesz upuścić starą i zwolnić miejsce i prawie nie mieć fragmentacji. Pamiętaj, że zajmie to około 120% dodatkowego miejsca podczas pracy. Problem polega na tym, że potrzebujesz nawet dodatkowego wolnego miejsca, które wygląda na to, że możesz go nie mieć. Jest to funkcja korporacyjna.
Jeśli wolna przestrzeń ma tak duże znaczenie, być może będziesz musiał ugryźć kulę i powoli zmniejszać DB małą porcję, aby uniknąć długotrwałych procesów. Pamiętaj, że twoje dane będą mocno pofragmentowane i będziesz chciał ponownie wszystko zindeksować. Zauważ, że po ponownym indeksowaniu wszystkiego nieco zwiększysz ilość zużytego miejsca i wrócisz do posiadania dodatkowego wolnego miejsca. Zobacz porady Brenta tutaj .
To, ile wolnego miejsca jest dla ciebie dobre, zależy od tego, ile możesz sobie pozwolić na fragmentację i działania związane z powiększaniem plików. Po włączeniu IFI wzrost pliku jest prawie natychmiastowy, ale nadal występuje fragmentacja. Dobrą zasadą jest wstępne przydzielanie tyle miejsca, ile potrzebujesz, lub monitorowanie wzrostu i okresowe dostosowywanie fragmentów, jeśli musisz. To ogranicza fragmentację fizyczną.
Również wzrost pliku dziennika jest o wiele ważniejszy. Dodatkowe pliki dziennika mogą powodować fragmentację VLF. To sprawia, że przywracanie jest dużo wolniejsze i może wpływać na punkty kontrolne / obcięte. Oto niektóre ryzyka związane z wydajnością, które podejmujesz przy pofragmentowanym dzienniku. Zrób DBCC LOGINFO();na każdej bazie danych. Staraj się utrzymać liczbę około 50ish na jednego Kim Trippa, ale jeśli zobaczysz setki, masz problemy z fragmentacją, co oznacza, że Twoje pliki dziennika musiały wzrosnąć, aby obsługiwać operacje. Dobrym sposobem, aby zobaczyć, jaki powinien być twój plik dziennika według Paula Randala, jest po prostu pozwolić mu rosnąć przez tydzień i ponownie indeksować. To może być dobry punkt, być może na wszelki wypadek możesz dodać trochę więcej wolnego miejsca. Upewnij się, że twoje dzienniki nie są pofragmentowane za pomocą DBCC LOGINFO (); znowu, a jeśli tak, to znaczy, że dużo urosły. Zmniejsz i ponownie rozwiń plik dziennika za pomocąta metoda .
