Mam bardzo duże tabele w mojej bazie danych, ale znaczna część tych danych jest „stara”.
Ze względu na okoliczności, na które nie mam wpływu, nie mogę usunąć tych „starych” danych. Drugim ograniczeniem jest to, że nie mogę modyfikować bazy danych, co oznacza dodawanie do niej grup plików. W obecnej sytuacji wszystko znajduje się w PRIMARY
grupie plików.
Myślałem o podzieleniu tych tabel na kilka partycji, takich jak „nowa”, „stara”, „zarchiwizowana” i podobne. Mam kolumnę „status”, której chciałbym użyć do tego celu.
Biorąc pod uwagę opisany scenariusz i ograniczenia, zastanawiałem się, czy partycjonowanie ma tu sens. Innymi słowy, jeśli moja tabela jest podzielona na partycje w ten sposób, ale wszystkie partycje znajdują się w tej samej grupie plików, SQL Server będzie wystarczająco inteligentny, aby znaleźć ten specjalny obszar w pliku źródłowym, w którym znajdują się moje „nowe” dane, i nie dotykać obszar ze „starymi” danymi?
Innymi słowy, jeśli, powiedzmy, 80% moich danych jest „starych”. Czy SQL Server ma mechanizm pozwalający uniknąć dostępu do 100% bazowych plików i dostęp tylko do 20%, który zawiera „nowe” dane (zakładając, oczywiście, że kolumnę partycjonowania określam w WHERE
klauzuli zapytań).
Myślę, że aby na to odpowiedzieć, trzeba zrozumieć, w jaki sposób partycjonowanie jest realizowane wewnętrznie. Doceniam wszelkie wskazówki.
źródło
Odpowiedź brzmi tak". Ma mechanizm dla każdego zapytania filtrującego dane wejściowe na podstawie logiki użytej do zdefiniowania partycji.
Musisz mieć jednak odpowiedni filtr, inaczej cała partycja zostanie przeskanowana. Zazwyczaj wymagałoby to posiadania filtrów daty (w twoim przypadku) do wyboru partycji.
Jednym ze sposobów wymuszenia tego jest posiadanie widoków, które mają dostęp tylko do jednej partycji, z odpowiednią logiką w widoku.
źródło