it-swarm.com.de

Archivierung alter Daten

Wir haben derzeit einige Leistungsprobleme, da unsere Datenbank zu groß wird. Es sind Daten aus den letzten 10 Jahren gespeichert, und ich sehe keinen Grund, warum Daten, die älter als 2 Jahre sind, in denselben Tabellen wie die neuen Daten gespeichert werden müssen.

Da ich keine tiefgreifenden Erfahrungen mit der Verwaltung von Datenbanken habe, suche ich nach den besten Möglichkeiten, alte Daten zu archivieren.


Die Info

  • Insgesamt befinden sich ca. 310'000'000 Datensätze in der Datenbank.

  • Die Datenbank benötigt 250 GB auf der Festplatte.

  • Die Serverversion ist SQL Server 2008 mit der Kompatibilitätsstufe SQL Server 2005 (90). Wir planen jedoch, bald ein Upgrade auf SQL Server 2012 durchzuführen

Ich habe über zwei Möglichkeiten nachgedacht:

Neue Datenbank

Erstellen Sie eine Datenbank ähnlich der auf dem Produktionsserver und fügen Sie alle alten Daten in die neue Datenbank ein.

  • Nachteil: Da Verbindungsserver in unserer Umgebung nicht zulässig sind, ist es schwierig, bei Bedarf die alten Daten zusammenzuführen

Verlaufsschema

Erstellen Sie ein neues Schema f.e. [hist] mit denselben Tabellen wie in der Produktionsdatenbank. Fügen Sie alle alten Daten in diese neuen Tabellen im neuen Schema ein.

  • Vorteil: Einfaches Beitreten, wenn in Zukunft alte Daten benötigt werden


  • Bevorzugen Sie eine der Lösungen gegenüber der anderen?
    • Warum?
  • Gibt es bessere Möglichkeiten?
  • Gibt es vorhandene Tools, mit denen diese Aufgabe leicht möglich ist?
  • Irgendwelche anderen Gedanken?

Danke im Voraus

Bearbeiten

Zusätzliche Frage:

Würde die neu erstellte Archivtabelle auch Primär-/Fremdschlüssel benötigen?

Oder sollten sie nur die Spalten haben, aber ohne Schlüssel/Einschränkungen?

26
xeraphim

Ich denke, die Antwort auf viele Ihrer Fragen ist, dass es darauf ankommt. Welche Leistungsprobleme haben Sie? Es scheint ungewöhnlich, dass eine Datenbank Leistungsprobleme hat, wenn sie nur auf 250 GB wächst.

Vielleicht führen Ihre Abfragen Tabellenscans für die gesamte Faktentabelle durch, selbst wenn nur ein kleiner Teil (z. B. das letzte Jahr) des Datumsbereichs benötigt wird? Wenn es eine bestimmte Abfrage gibt, die für die Optimierung am wichtigsten ist, sollten Sie Ihr Schema, Ihre Abfrage und einen tatsächlichen Ausführungsplan in einer anderen Frage veröffentlichen, um zu prüfen, ob sie optimiert werden kann.

Bevorzugen Sie eine der Lösungen gegenüber der anderen?

Im Allgemeinen bevorzuge ich die Verlaufsdatenbank, und ich denke, Guy beschreibt gute Gründe dafür in seiner Antwort .

Der Hauptnachteil, den ich für eine Verlaufsdatenbank sehe (im Gegensatz zu einem Schema), ist, dass Sie keine Fremdschlüssel mehr für Ihre Archivtabelle verwenden können. Das mag für Sie in Ordnung sein, aber es ist etwas, das Sie beachten sollten.

Der Nachteil, den Sie für diesen Ansatz aufgeführt haben, ist nicht korrekt. Sie können problemlos datenbankübergreifend auf demselben Server abfragen, und das Abfrageoptimierungsprogramm verarbeitet datenbankübergreifende Abfragen im Allgemeinen sehr gut.

Gibt es bessere Möglichkeiten?

Wenn Sie die Archivdaten regelmäßig abfragen müssen, kann ich Partitionierung der Tabelle nach Datum in Betracht ziehen. Dies ist jedoch eine große Änderung, die viele positive Auswirkungen auf die Leistung haben kann, sowohl positive (z. B. Eliminierung von Partitionen, effizienteres Laden von Daten) als auch negative (z. B. langsamere Singleton-Suchvorgänge, größeres Potenzial für Thread-Versatz bei parallelen Abfragen). Daher würde ich diese Entscheidung nicht leichtfertig treffen, wenn es sich um eine stark genutzte Datenbank handelt.

Würde die neu erstellte Archivtabelle auch Primär-/Fremdschlüssel benötigen? Oder sollten sie nur die Spalten haben, aber ohne Schlüssel/Einschränkungen?

Ich würde empfehlen, mindestens den Primärschlüssel und eindeutige Indizes zu haben, damit Sie die Vorteile der Datenintegrität nutzen können, die sie bieten. Dies verhindert beispielsweise, dass Sie versehentlich zweimal ein Jahr Daten in die Verlaufstabelle einfügen. Als Nebeneffekt kann dies die Leistung verbessern, wenn Sie die Verlaufstabelle abfragen müssen.

Irgendwelche anderen Gedanken?

Da Sie die Enterprise Edition verwenden und ein Upgrade auf SQL 2008+ planen, sollten Sie Datenkomprimierung für diese Tabelle in Betracht ziehen. Durch die Komprimierung wird zwar der Speicherplatz reduziert, aber abhängig von den Festplatten- und CPU-Ressourcen Ihres Servers kann auch die Abfrageleistung für Lesevorgänge verbessert werden, indem die Festplatten-E/A reduziert und die Speichernutzung verbessert werden (mehr Daten passen gleichzeitig in den Cache).

12
Geoff Patterson

Ich würde es vorziehen, jeden Tag ein Verlaufsschema oder eine zweite Verlaufsdatenbank über einen Verbindungsserver zu haben. Es spart Lizenzkosten und ist einfacher zu verwalten und abzufragen. Sie können dann auch ein einfacheres Schema verwenden und einige der Indizes löschen, wodurch die Datenbank kleiner wird

Da Sie jedoch über die Enterprise Edition verfügen, haben Sie die dritte Option: Partitionieren Ihrer Tabellen , die das Archivieren der Daten erleichtert und das Abfragen der alten Daten für Ihre Benutzer und Sie transparent macht Es müssen keine Anwendungsänderungen vorgenommen werden.

9
Spörri

Nach meiner Erfahrung wäre eine zweite Datenbank aus zwei Gründen die bevorzugte Wahl.

  1. Sie können die Daten aus einer historischen Sicherung wiederherstellen und dann die nicht benötigten Tabellen und Indizes löschen.
  2. Sie können dies zu Berichtszwecken auf einen anderen Server verschieben. Dies hat den Vorteil, dass die Ressourcen des Primärservers nicht verwendet werden

Sie müssten weiterhin alle historischen Daten aus der Primärdatenbank löschen, dies könnte jedoch in geplant werden.

7
Guy

Lizenz vorerst ignorieren, da ich dort nicht meine Zeit verbringe.

IMHO, Archivdatenbank ist am einfachsten zu implementieren und zu pflegen. Sie sind verschiedene, lose gekoppelte Einheiten. Datenverschiebung und Lade-/Ressourcensteuerung haben klare Grenzen. Kann leicht auf eine andere Instanz oder einen anderen Server verschoben werden, um das Leistungsmanagement zu verbessern, und die Kosten sind kein großes Problem. Beachten Sie, dass am einfachsten! = Günstigster oder geringster Aufwand. Es hat tatsächlich einiges mehr Aufgaben, aber es sind alles einfache Aufgaben mit zwei wichtigen Ausnahmen:

  1. durchsetzung von Einschränkungen - In SQL Server gibt es keine datenbankübergreifenden Einschränkungen. Sie müssen also entscheiden, ob dies ein Deal Breaker ist.
  2. datenbankübergreifende Abfragen verwenden verteilte Abfragen, die immer noch von OLEDB abhängig sind, das veraltet ist. Das bedeutet, dass Sie möglicherweise auf Probleme mit neuen Datentypen stoßen. Wenn Sie auf Leistungsprobleme stoßen, ist es unwahrscheinlich, dass diese jemals behoben werden

Das Archivierungsschema oder nur die Archivtabelle ist etwas komplexer zu implementieren, aber viel einfacher zu verwenden. Alle Objekte in derselben Datenbank bedeuten, dass Sie keine Zugriffssteuerungen replizieren und verwalten müssen. Keine datenbankübergreifenden Abfragen zur einfacheren Leistungsoptimierung, Überwachung, Fehlerbehebung usw.

Die Tabellenpartitionierung ist eine großartige Lösung und bietet viele Vorteile einer Archivtabelle/eines Archivschemas, bietet jedoch Transparenz für Benutzer/Abfragen. Das heißt, es ist am komplexesten zu implementieren und erfordert eine fortlaufende Pflege, die für Anfänger nicht einfach ist.

Einige wichtige Überlegungen:

  • Geben Abfragen regelmäßig historische/kalte Daten zurück oder wird selten auf kalte Daten zugegriffen?
  • Sind die historischen Daten unveränderlich oder werden sie regelmäßig aktualisiert/gelöscht?
  • 310 m Zeilen sind abhängig von der Zeilengröße "moderat" (vorausgesetzt, alle in einer Tabelle). Haben Sie Daten zur Zeilengröße? Wie viele GB ist diese 310m Reihe?
  • Wie hoch ist die Wachstumsrate dieser Tabelle?
  • Können Sie den Anwendungscode und seine SQL-Abfragen ändern?

Dies sind wichtige Überlegungen, da sie erhebliche Auswirkungen auf die von Ihnen ausgewählte Lösung haben können oder bestimmte Lösungen möglicherweise nicht zulassen. Wenn Ihre Verlaufsdaten beispielsweise regelmäßig (mehr als einmal pro Woche) geändert/aktualisiert werden, bedeutet die Verwendung einer separaten Datenbank, dass Sie entweder DTC für diese Abfragen verwenden oder die Transaktionssicherheit manuell verwalten müssen (nicht trivial, um sicherzustellen, dass sie immer korrekt sind). Die Kosten sind erheblich höher als bei unveränderlichen historischen Daten.

Wenn Sie an ein Upgrade denken, sollten Sie auch 2016 und die neue Funktion "Stretch Database" in Betracht ziehen: https://msdn.Microsoft.com/en-us/library/dn935011.aspx

4
SQLmojoe

Ich würde es aus folgenden Gründen vorziehen, die Datenbank in eine separate logische Datenbank aufzuteilen:

1. Ressourcenanforderungen

Durch Aufteilen in eine separate Datenbank kann es auf einem anderen Laufwerk gespeichert und mit einer anderen Rate als die Hauptproduktionsdaten überwacht werden.

2. Leistung

Durch die Aufteilung der Daten in eine separate Datenbank wird die Größe der Hauptproduktionsdatenbank reduziert, was die Gesamtleistung verbessert.

. Einfachere Backups

Das Sichern archivierter Daten ist möglicherweise nicht so wichtig wie die "Live/Current" -Datensätze in der SQL-Hauptdatenbank. Dies kann bedeuten, dass archivierte Daten seltener gesichert werden. Aufgrund der sequentiellen Art der Protokollierung archivierter Daten ist es möglicherweise möglich, Abschnitte der archivierten Datenbank einmal und dann nie wieder zu sichern. Z.B. Sobald Archivdaten für 2014 in die Änderungsarchivdatenbank geschrieben wurden, werden diese Daten nie wieder geändert.

Hinweis : Ich denke, die Antwort auf viele Ihrer Fragen hängt von Ihren Umständen, der Art der Daten und den Leistungsproblemen ab, die Sie hatten.

1
Sathish