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

Da ich keine tiefgreifende Erfahrung in der Verwaltung von Datenbanken habe, suche ich nach den besten Möglichkeiten, um alte Daten zu archivieren.

Info

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

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

• Die Serverversion ist SQL Server 2008 mit der Kompatibilitätsstufe SQL Server 2005 (90). In Kürze ist jedoch ein Upgrade auf SQL Server 2012 geplant

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, z. B. [hist], mit denselben Tabellen wie in der Produktionsdatenbank. Fügen Sie alle alten Daten in diese neuen Tabellen im neuen Schema ein.

• Vorteil: Einfaches Zusammenfügen, wenn in Zukunft alte Daten benötigt werden

• Ziehen Sie eine der Lösungen der anderen vor?
  • Warum?
• Gibt es bessere Möglichkeiten?
• Gibt es Tools, mit denen diese Aufgabe problemlos 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?

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 eine Größe von 250 GB anwächst.

Möglicherweise führen Ihre Abfragen Tabellensuchen für die gesamte Faktentabelle durch, auch 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 in Betracht ziehen, Ihr Schema, Ihre Abfrage und einen tatsächlichen Ausführungsplan in einer anderen Frage zu veröffentlichen, um zu prüfen, ob sie optimiert werden kann.

Ziehen Sie eine der Lösungen der anderen vor?

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

Der Hauptnachteil einer Verlaufsdatenbank (im Gegensatz zu einem Schema) besteht darin, dass Sie keine Fremdschlüssel mehr für Ihre Archivtabelle verwenden können. Dies mag für Sie in Ordnung sein, aber es ist etwas, das Sie beachten müssen.

Der Nachteil, den Sie für diesen Ansatz angegeben haben, ist nicht korrekt. Sie können problemlos datenbankübergreifende Abfragen auf demselben Server durchführen, 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 es sinnvoll sein, die Tabelle nach Datum zu partitionieren . Dies ist jedoch eine große Änderung, die viele Auswirkungen auf die Leistung haben kann, sowohl positive (z. B. Beseitigung 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 Datenintegritätsvorteile nutzen können, die sie bieten. Dies verhindert beispielsweise, dass Sie versehentlich ein Jahr Daten zweimal in die Verlaufstabelle einfügen. Als Nebeneffekt kann dies die Leistung verbessern, wenn Sie die Verlaufstabelle abfragen müssen.

Irgendwelche anderen Gedanken?

Da Sie Enterprise Edition verwenden und ein Upgrade auf SQL 2008+ planen, sollten Sie möglicherweise die Datenkomprimierung für diese Tabelle in Betracht ziehen . Durch die Komprimierung wird zwar der Festplattenspeicherplatz verringert, aber je nach 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 wird (mehr Daten passen gleichzeitig in den Cache).

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, um die Datenbank zu verkleinern

Da Sie jedoch über die Enterprise-Edition verfügen, haben Sie die dritte Möglichkeit, Ihre Tabellen zu partitionieren . Wenn diese eingerichtet sind, ist die Archivierung der Daten und die Abfrage der alten Daten für Ihre Benutzer transparent, und Sie müssen keine Änderungen an der Anwendung vornehmen .

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 Tabellen und Indizes löschen, die Sie nicht benötigen.
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.

Ich ignoriere die Lizenz vorerst, 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 die Leistung zu verbessern, und die Kosten sind kein großes Problem. Beachten Sie, dass am einfachsten! = Billigsten oder geringsten Aufwand. Eigentlich hat es 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 weiterhin von OLEDB abhängen, das veraltet ist. Dies 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 Archivschema 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 laufende 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?
• 310m Zeilen sind "moderat" (vorausgesetzt, alle in einer Tabelle), abhängig von der Zeilengröße. Haben Sie Daten zur Zeilengröße? Wie viele GB hat diese 310-Meter-Reihe?
• Was 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 beispielsweise Ihre historischen Daten regelmäßig (mehr als einmal pro Woche) geändert / aktualisiert werden, müssen Sie bei Verwendung einer separaten Datenbank entweder DTC für diese Abfragen verwenden oder die Transaktionssicherheit manuell verwalten (nicht trivial, um immer die Richtigkeit zu gewährleisten). Die Kosten sind erheblich höher als bei unveränderlichen historischen Daten.

Wenn Sie ein Upgrade in Betracht ziehen, sollten Sie 2016 und die neue Stretch-Datenbankfunktion in Betracht ziehen: https://msdn.microsoft.com/en-us/library/dn935011.aspx

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 diese auf einem anderen Laufwerk gespeichert und mit einer anderen Geschwindigkeit als die Hauptproduktionsdaten überwacht werden.

2. Leistung

Durch Aufteilen der Daten auf eine separate Datenbank wird die Größe der Hauptproduktionsdatenbank verringert, was die Gesamtleistung verbessert.

3. Einfachere Backups

Das Sichern von archivierten Daten ist möglicherweise nicht so wichtig wie die "Live / Current" -Datensätze in der SQL-Hauptdatenbank. Dies kann dazu führen, dass archivierte Daten seltener gesichert werden. Aufgrund der Abfolge der Protokollierung archivierter Daten ist es möglicherweise auch möglich, Abschnitte der archivierten Datenbank einmal und nie wieder zu sichern. Wenn beispielsweise einmal Archivdaten für 2014 in die Änderungsarchivdatenbank geschrieben wurden, werden diese Daten nie mehr 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.