Partycjonowanie tabel do archiwizacji danych

Scenariusz:

• dwie bazy danych: DB_A i DB_Archive z jedną bardzo dużą tabelą o nazwie tableA.
• każdego dnia rekordy starsze niż 60 dni są usuwane z DB_A i przenoszone do DB_Archive głównie po to, aby pozostawić „oddzieloną” rzecz, ponieważ tabela A jest bardzo pytana w DB_A o rekordy z ostatnich 2 miesięcy.

Chcę pozbyć się tego procesu, ponieważ jest on powolny i zużywa dużo zasobów. Zastanawiam się nad implementacją partycjonowania tabeli na DB_A z funkcją partycji w kolumnie daty i przechowywaniem wszystkich rekordów <2 miesiące na jednej partycji i wszystkich rekordów> 2 miesiące na innej partycji. Moje pytania:

• czy ten scenariusz będzie się zachowywał tak, jak gdybym miał 2 różne bazy danych? Jeśli zapytam moją tabelę A o rekordy> getdate () - 30, czy będzie ona czytać partycję archiwizującą?
• Miałem też podzielić indeksy, prawda?
• Jak mam poradzić sobie z tym, że jutro moja funkcja partycji „zmieni się”, to znaczy, jeśli utworzę ją dzisiaj (2 lipca, jej zakres będzie 2 maja, ale jutro będzie 3 maja). Czy mogę utworzyć funkcję dynamicznej partycji?

W przypadku partycjonowania musiałbyś robić partycję dziennie, co stawia nowy limit 1000 1000 parowań przed SQL 2012, ponieważ pozwala to na archiwizację tylko przez 3 lata. SQL Server 2012 daje 15000 partycji, co wystarcza na 1 partycję dziennie.

Codziennie dodajesz nową partycję. Jeśli chcesz przenieść partycję z 61 dnia poprzedniego, możesz to zrobić wydajnie, ale nadal jest to operacja offline. Zobacz Efektywne przenoszenie partycji do innej grupy plików .

Wszystkie indeksy musiałyby zostać wyrównane, patrz Specjalne wytyczne dotyczące indeksów podzielonych na partycje .

Kupowanie partycjonowania nie jest łatwą decyzją i może być dość dużym kęsem do żucia ... zobacz, jak zdecydować, czy powinieneś użyć partycjonowania tabel . W szczególności nie należy oczekiwać poprawy wydajności po partycjonowaniu. Do problemów z wydajnością należy podchodzić najpóźniej w czasie, grupując według datetime.

Nie wiem, czy funkcja partycji może być dynamiczna, ale wątpię w to. Niektóre opcje dla Ciebie bez wybrania tej trasy:

1 - Podziel na partycje według kalendarza DATE i codziennie usuwaj najstarszą partycję

2 - Utwórz widok, który będzie filtrował według daty, i wskaż tam wszystkie istniejące zapytania (można to łatwo zarządzać, zmieniając nazwę podstawowej tabeli na inną i nadając widokowi nazwę bieżącej tabeli). Można to również zoptymalizować poprzez zmiany indeksu.

Pamiętaj, że pierwsza opcja powyżej będzie działała O wiele lepiej, jeśli użyjesz pola daty w zapytaniach. Jeśli tego nie zrobisz, nadal będzie to szybsze niż bieżący proces, ale zapytania nie będą miały znacznej poprawy. Partycjonowanie ogólnie działa najlepiej, jeśli można filtrować według pola partycji, a optymalizator wie, na którą partycję należy patrzeć.

Oto, co powinno działać dla Ciebie: DB_A - tabela A z inną partycją dla każdego z ostatnich 60 dni - stagingTable do przenoszenia danych z najstarszej partycji

DB_Archive tableA - przechowuje wszystkie dane starsze niż 60 dni. (niepodzielony na partycje)

Proces: 1. przed końcem dnia: zmień funkcję partycji - podziel zakres, aby dodać nową partycję na nowy dzień. (Uwaga: zamiast tworzyć partycje dla „dzisiejszej daty + 1 dzień”, możesz chcieć być o kilka kroków do przodu, np .: „dzisiejsza data + 5 dni”

1. Po zakończeniu każdego dnia najpierw przełączasz najstarszą partycję w DB_A.tableA na DB_A.stagingTable; Scal najstarsze partycje.

2. Zaimportuj dane z DB_A.stagingTable do DB_Archive.tableA. Wreszcie skróć tabelę DB_A.stagingTable

Powyższe nazywa się Rolling Window i jest dość powszechnym scenariuszem dla VLDB. Zobacz ten artykuł autorstwa Microsoft na temat partycjonowania: Tabela partycji i strategie indeksowania lub wypróbuj to w scenariuszu Przesuwne okno

Możesz użyć dynamicznego podejścia do archiwizacji i usuwania danych w SQL Server. Aby to zrobić, kliknij poniższy link.

http://www.sqlscientist.com/2012/09/auto-maintain-archival-process.html