Partycjonowanie tabel do archiwizacji danych

13

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?
sql-server sql-server-2005 partitioning Diego
źródło
Nie sądzę, aby funkcja dynamiczna była dobrym pomysłem, nawet gdyby była dozwolona (nie sądzę, że tak jest) ... możemy przejść do bardziej szczegółowych informacji, ale myślę, że prawdopodobnie powinieneś podzielić partycje na podstawie daty kalendarza i wyjść jedna partycja na raz ... Ale jest tu wiele opcji.
JNK
Skryptowałem przykład zgodny z tym, co chcesz robić w zeszłym roku. Był to dość szczególny przypadek, w którym chcieliśmy przechowywać x dni danych w szybkiej (drogiej) macierzy i przenieść dane archiwalne do tańszego miejsca do przechowywania. Jeśli mogę zdezynfekować przykładowy skrypt, opublikuję go, w przeciwnym razie będzie to tylko podsumowanie procesu.
Mark Storey-Smith
cześć znak, tak, proszę, i jeśli możesz podzielić się swoim doświadczeniem. czy to się udało?
Diego
Działa, ale ostatecznie nie był potrzebny (wybraliśmy prostszą trasę). Może mógłbyś wyjaśnić, dlaczego w twoim przypadku istnieje 60-dniowa granica? Pomógłby wszystkim skierować Cię we właściwym kierunku.
Mark Storey-Smith

Odpowiedzi:

6

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.

Remus Rusanu
źródło
Nowy limit jest dostępny w 2008 SP2 i 2008 R2 SP1. blogs.msdn.com/b/hanspo/archive/2010/11/29/…
Jon Seigel
@Jon: wdrożenie w 2008 SP2, 2008R2 SP1 zawiera duże ostrzeżenie . As explained in this white paper, there are implications on certain features, including performance. . Obsługa SQL 2012 nie zawiera ostrzeżeń.
Remus Rusanu
Dzięki za zwrócenie na to uwagi; to prawda, że ​​istnieją pewne zastrzeżenia dotyczące używania go w 2008/2008 R2, ale w razie potrzeby jest to dostępna opcja.
Jon Seigel
Dzięki za komentarz. Później przeczytam komentarz do materiału
Diego,
2

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ć.

JNK
źródło
Chciałbym uniknąć ręcznych operacji „każdego dnia”
Diego
2

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

Dharmendar Kumar „DK”
źródło
0

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

Asif Ghanchi
źródło
1
Czy możesz podać w swojej odpowiedzi główne punkty tego postu? Wiesz, linki przychodzą i odchodzą, a kiedy odejdą, twój post będzie miał tylko martwy link.
dezso