SQL Server-Datenbankdesign für archivierte, aber verfügbare Daten

Wir haben diese große Datenbank (> 1 TB), die wir "verkleinern" möchten. Die Datenbank dreht sich um eine Hauptentität, nennen wir sie "Besuch". Angenommen, es handelt sich um eine Datenbank für eine medizinische Praxis.

Es gibt insgesamt 30 "Besuchstypen", wie z. B. Verfahren, jährliche Besuche, Nachsorgeuntersuchungen, Impfungen usw., von denen jeder eine Hilfstabelle für "Besuch" ist, z. B. "visit_immuno".

Die Datenbank hat seit dem Jahr 2000 ungefähr 12 Jahre an Daten gesammelt. Jemand hat vorgeschlagen, dass wir ungefähr 3 Jahre an Daten in der "Live" -Version aufbewahren und den Rest in einer "old_data" -Datenbank. Das Datum wird NUR in der Tabelle "Besuch" gespeichert, da es normalisiert ist. Die Visit-Tabelle enthält auch eine ROWVERSIONSpalte und eine BIGINTPseudoidentitätsspalte (gruppiert). Nehmen wir in jeder Hinsicht an, der Clustering-Schlüssel wird von einer SEQUENCE (SQL Server 2012 Enterprise) gefüllt - wir werden ihn benennen cid.

Das visit.dateist nicht immer in der gleichen Reihenfolge wie der Clustering-Schlüssel. Wenn ein Arzt beispielsweise längere Besuche durchführt und mit seinem "Aktenkoffer" Daten zurückgibt, werden diese in der Haupttabelle zusammengeführt. Es gibt auch einige Aktualisierungen an der Tabelle "visit", die dazu führen, dass die ROWVERSIONSpalte nicht mehr mit den Spalten cidund synchron dateist. Einfach gesagt, es werden aus diesem Grund weder geeignete Partitionsschlüssel erstellt ROWVERSIONnoch erstellt cid.

Die Geschäftsregel zum Entfernen von Daten aus dem "Live" lautet, dass der visit.dateZeitraum länger als 36 Monate sein muss und ein untergeordneter visit_paymentDatensatz vorhanden sein muss. Die Datenbank "old_data" enthält außer keine der Basistabellen visit%.

Am Ende haben wir also:

Live DB (täglicher Gebrauch) - Alle Tabellen Old-Data DB - ältere Daten für die visit%Tabellen

Der Vorschlag sieht eine kombinierte Datenbank vor , bei der es sich um eine Shell handelt, die Synonyme für ALLE Basistabellen in den Live DB(Ausnahme- visit%) Plus- Ansichten enthält , die ALLE in den visit%Tabellen in den beiden Datenbanken vereinen.

Unter der Annahme, dass die gleichen Indizes in der Old-DataDatenbank erstellt werden, funktionieren die Abfragen in den UNION-ALL- Ansichten einwandfrei ? Welche Art von Abfragemustern kann den Ausführungsplan für die UNION-ALL- Ansichten auslösen ?

LiveDbNehmen Sie zur Vereinfachung an, dass die Live-Datenbank und die Archivdatenbank aufgerufen werdenArchiveDb

• Fügen Sie eine UNION ALL-Ansicht hinzu, LiveDbindem Sie ArchiveDbüber ein Synonym auf die Tabellen in der Datenbank verweisen. (Es ist nicht erforderlich, eine kombinierte Datenbank mit Synonymen zu erstellen.)
• "Partitionieren" Sie visit.datediese Spalte ein und denormalisieren Sie sie visit_paymentsauch, wenn sie noch nicht vorhanden ist (dies verbessert die Leistung der gemeinsamen Verknüpfung).
• Archivieren Sie nach Möglichkeit nur die beiden großen Tabellen (verringert die Wahrscheinlichkeit, dass der Optimierer ausgelöst wird). Behalten Sie die Ansicht UNION ALL und die anderen Tabellen bei, LiveDbdamit alle Verknüpfungen mit den kleineren Tabellen lokal bleiben
• Fügen Sie eine CHECK - Einschränkung auf den Tischen in den beiden LiveDbund ArchiveDb das beschreibt den Bereich der visit.datein der Tabelle enthalten. Auf diese Weise kann das Optimierungsprogramm die Archivtabelle sowohl bei Suchvorgängen als auch bei Überprüfungen, die die Spalte enthalten, entfernen visit.data. Sie müssen diese Einschränkung regelmäßig aktualisieren.
• Fügen Sie in der Ansicht UNION ALL ein WHERE-Kriterium hinzu, nach dem gefiltert wird visit.data. Dies ist zusätzlich zu dem Hinweis, den Sie bereits in der Check-Einschränkung angegeben haben. Dies maximiert die Wahrscheinlichkeit, dass Filter heruntergedrückt werden
• Wenn Sie EE haben, partitionieren Sie die Tabelle in der Archivdatenbank (aber NICHT in der Live-Datenbank). Wenn Sie wirklich ausgefallen sein möchten, verwenden Sie das Sichern / Wiederherstellen der Archivdatenbanken auf Dateigruppenebene, um Sicherungszeiten zu sparen.
• Ziehen Sie AchiveDbin Betracht, den SIMPLE-Wiederherstellungsmodus zu aktivieren, falls dies noch nicht geschehen ist. Es ist unwahrscheinlich, dass Sie Transaktionsprotokollsicherungen von benötigenArchiveDb
• Verwenden Sie INSERT ... WITH (TABLOCK) SELECT ... WITH (ROWLOCK), um eine minimale Protokollierung des Ziels beim Verschieben von Daten zwischen LiveDbund zu erzwingen ArchiveDb

All dies garantiert nicht, dass das Optimierungsprogramm die Archivtabellen aus Such- und Scanvorgängen entfernt, erhöht jedoch die Wahrscheinlichkeit.

Wenn die Beseitigung nicht geschieht. Dies ist der Effekt, den Sie möglicherweise sehen (diese Liste ist möglicherweise unvollständig). Bei Suchvorgängen erhalten Sie bei jeder Abfrage einen zusätzlichen Suchvorgang (dies führt zu IOPS). Bei Überprüfungen kann die Leistung desaströs sein, da Sie möglicherweise sowohl die Archiv- als auch die Livetabellen überprüfen. Hier sind die typischen Möglichkeiten, wie Sie den Optimierer auslösen können:

• Wenn Sie die visit%Tabellen zusammenfügen und die visit.datain den Verknüpfungskriterien nicht enthalten (aus diesem Grund möchten Sie denormalisieren). Aus diesem Grund möchten Sie möglicherweise einige Ihrer Abfragen ändern
• Wenn Sie eine Hashverknüpfung zwischen visit.dataund einer anderen Tabelle erhalten (zum Beispiel eine Datumsdimension), erhalten Sie möglicherweise nicht die richtige Eliminierung von Tabellen
• Wenn Sie versuchen, Daten über die archivierten Tabellen zu aggregieren
• Wenn Sie jedoch nach etwas filtern visit.data, suchen Sie beispielsweise direkt nach dem Schlüssel der Ansicht.

Für das letzte Szenario können Sie sich gegen die schlimmsten Auswirkungen schützen, indem Sie eine weitere Prüfbedingung für cid- hinzufügen, wenn dies möglich ist. Sie haben erwähnt, dass die Reihenfolge der cidnicht "sauber" in Bezug auf die Daten und den Fortschritt der Zeilen in der Tabelle. Könnten Sie jedoch eine Tabelle pflegen, die folgende Informationen enthält: "Seitdem gibt es cidüber dieser Nummer keine mehr visit.data" oder ähnliches? Dies könnte dann zu einer zusätzlichen Einschränkung führen.

Eine andere Sache, die Sie beachten sollten, ist, dass parallele Abfragen möglicherweise VIEL mehr Threads erzeugen, wenn Sie die partitionierte Ansicht abfragen (da beide "Untertabellen" denselben parallelen Optimierungen ausgesetzt sind). Aus diesem Grund möchten Sie möglicherweise MAXDOP auf dem Server oder die parallelen Abfragen einschränken.

Übrigens, wenn Sie die Abfragen gut kennen - Sie benötigen möglicherweise nicht einmal dieselben Indizes in den beiden Datenbanken (dies setzt voraus, dass Sie zu 100% sicher sind, dass Sie die richtige Eliminierung von Tabellen erreichen). Sie könnten sogar die Verwendung von Spaltenspeichern für in Betracht ziehen ArchiveDb.

Wir haben die alten Daten stapelweise in eine neu erstellte Datenbank geschrieben und die alten Daten aus der Live-Datenbank gelöscht. Auf diese Weise sind beide DB zugänglich. Sie können die neu erstellte Datenbank auch sichern und an einer anderen Stelle wiederherstellen, um den großen Platzbedarf der Produktionsserver zu verringern. Hoffe, das ist eine akzeptable Lösung für Ihre Bedürfnisse.