Tabellenpartitionierung zur Archivierung von Daten

13

Szenario:

  • zwei Datenbanken: DB_A und DB_Archive mit einer sehr großen Tabelle namens tableA.
  • Jeden Tag werden Datensätze, die älter als 60 Tage sind, aus DB_A gelöscht und in DB_Archive verschoben. Dies geschieht hauptsächlich, um die Sache "getrennt" zu lassen, da tableA in DB_A stark nach Datensätzen der letzten 2 Monate abgefragt wird.

Ich möchte diesen Prozess loswerden, weil er langsam ist und viele Ressourcen verbraucht. Ich denke an die Implementierung der Tabellenpartitionierung auf DB_A mit einer Partitionsfunktion für eine Datumsspalte und Speichern aller Datensätze <2 Monate auf einer Partition und aller Datensätze> 2 Monate auf einer anderen Partition. Meine Fragen:

  • Wird sich dieses Szenario so verhalten, als hätte ich zwei verschiedene Datenbanken? Wenn ich meine Tabelle A nach Datensätzen> getdate () - 30 abfrage, wird dann die Archivierungspartition gelesen?
  • Ich musste wohl auch die Indizes partitionieren, oder?
  • Wie gehe ich damit um, dass sich meine Partitionsfunktion morgen "ändert"? Ich meine, wenn ich die Funktion heute erstelle (2. Juli, der Bereich wird der 2. Mai sein, aber morgen der 3. Mai). Kann ich eine dynamische Partitionsfunktion erstellen?
sql-server  sql-server-2005  partitioning 
— Diego
quelle
Ich denke nicht, dass eine dynamische Funktion eine gute Idee ist, selbst wenn sie erlaubt wäre (ich glaube nicht) ... wir können in Kürze näher darauf eingehen, aber ich denke, Sie sollten wahrscheinlich basierend auf dem Kalenderdatum partitionieren und losfahren Eine Partition zu einer Zeit ... Aber es gibt hier eine Vielzahl von Optionen.
— JNK
Ich habe ein Beispiel geschrieben, wie Sie es letztes Jahr machen wollen. Es war ein etwas spezieller Fall, in dem wir x Tage Daten auf einem schnellen (teuren) Array speichern und Archivdaten in einen günstigeren Speicher verschieben wollten. Wenn ich ein Beispielskript bereinigen kann, werde ich es veröffentlichen, ansonsten ist es nur eine Zusammenfassung des Prozesses.
— Mark Storey-Smith
hi mark, ja bitte tu es und wenn du deine erfahrungen auch teilen kannst. war es erfolgreich
— Diego
Es funktioniert, war aber letztendlich unnötig (wir sind einen einfacheren Weg gegangen). Vielleicht könnten Sie erläutern, warum in Ihrem Fall die 60-Tage-Grenze besteht. Würde jedem helfen, Sie in die richtige Richtung zu weisen.
— Mark Storey-Smith

Antworten:

6

Bei der Partitionierung müssten Sie eine Partition pro Tag durchführen, wodurch das Pre-SQL 2012-Limit von 1000 Partitionen aus einer neuen Perspektive betrachtet wird, da nur eine Archivierungsdauer von 3 Jahren zulässig ist. Mit SQL Server 2012 erhalten Sie 15000 Partitionen, was für 1 Partition pro Tag ausreicht.

Jeden Tag würden Sie eine neue Partition hinzufügen. Wenn Sie die Partition der letzten 61 Tage verschieben möchten, können Sie dies effizient tun, sie ist jedoch immer noch ein Offline-Vorgang. Siehe Effizientes Verschieben einer Partition in eine andere Dateigruppe .

Alle Ihre Indizes müssten ausgerichtet werden (siehe Spezielle Richtlinien für partitionierte Indizes) .

Der Kauf einer Partitionierung ist keine einfache Entscheidung, und das Kauen kann ein ziemlicher Happen sein ... Weitere Informationen finden Sie unter Festlegen, ob Sie die Tabellenpartitionierung verwenden sollten . Insbesondere sollten Sie von der Partitionierung keine Leistungsverbesserungen erwarten. Sie sollten Leistungsprobleme rechtzeitig lösen, indem Sie nach Datum und Uhrzeit gruppieren.

— Remus Rusanu
quelle
Das neue Limit ist in 2008 SP2 und 2008 R2 SP1 verfügbar. blogs.msdn.com/b/hanspo/archive/2010/11/29/…
— Jon Seigel
@ Jon: Die Implementierung von 2008 SP2, 2008R2 SP1 ist mit einer großen Warnung versehen . As explained in this white paper, there are implications on certain features, including performance. . Die SQL 2012-Unterstützung wird ohne Warnungen ausgeliefert.
— Remus Rusanu
Vielen Dank, dass Sie darauf hingewiesen haben. Es ist wahr, dass es einige Einschränkungen bei der Verwendung in 2008/2008 R2 gibt, aber es ist eine verfügbare Option, falls erforderlich.
— Jon Seigel
vielen Dank für Ihren Kommentar. Ich werde den Materialkommentar später lesen
— Diego
2

Ich weiß nicht, ob die Partitionsfunktion dynamisch sein kann, bezweifle es aber. Einige Optionen für Sie, ohne diesen Weg zu gehen:

1 - Partition am Kalendertag und jeden Tag die älteste Partition entfernen

2 - Erstellen Sie eine Ansicht, die nach Datum filtert, und verweisen Sie auf alle vorhandenen Abfragen (dies kann einfach verwaltet werden, indem Sie die zugrunde liegende Tabelle in etwas anderes umbenennen und der Ansicht den Namen der aktuellen Tabelle geben). Dies kann auch bei Indexänderungen optimiert werden.

Bedenken Sie, dass die erste Option oben VIEL besser funktioniert, wenn Sie das Datumsfeld in Ihren Abfragen verwenden. Wenn Sie dies nicht tun, ist dies immer noch schneller als der aktuelle Prozess, aber Abfragen haben keine große Verbesserung. Partitionierung funktioniert im Allgemeinen am besten, wenn Sie nach Ihrem Partitionsfeld filtern können und der Optimierer weiß, welche Partition zu betrachten ist.

— JNK
quelle
Ich möchte "jeden Tag" manuelle Operationen vermeiden
— Diego
2

Folgendes sollte für Sie funktionieren: DB_A - tableA mit einer anderen Partition für jeden der letzten 60 Tage - stagingTable, um Daten von der ältesten Partition zu verschieben

DB_Archive tableA - speichert alle Daten, die älter als 60 Tage sind. (nicht partitioniert)

Vorgang: 1. Vor Tagesende: Partitionsfunktion ändern - Bereich teilen, um eine neue Partition für den neuen Tag hinzuzufügen. (Hinweis: Anstatt Partitionen für "heutiges Datum + 1 Tag" zu erstellen, möchten Sie möglicherweise ein paar Schritte voraus sein. Beispiel: "heutiges Datum + 5 Tage"

  1. Nach dem Ende eines jeden Tages wechseln Sie zuerst die älteste Partition in DB_A.tableA zu DB_A.stagingTable. Führen Sie die ältesten Partitionen zusammen.

  2. Importieren Sie Daten aus DB_A.stagingTable in DB_Archive.tableA. Zuletzt trunacte DB_A.stagingTable

Das obige wird als Rolling Window bezeichnet und ist ein recht verbreitetes Szenario für VLDBs. Lesen Sie dieses Whitepaper von Microsoft zum Thema Partitionierung: Partitionstabellen- und Indexstrategien, oder versuchen Sie dies speziell im Schiebefensterszenario

— Dharmendar Kumar 'DK'
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.