2016-04-18 7 views
0

Wir haben ein System, das eine Datenbank View verwendet, die Daten aus einigen Referenztabellen (Lookups) nimmt und dann viel Pivotieren und komplexe Arbeit an einer Hierarchietabelle von (ziemlich viel feste und statische) Standorte, die eine Ansicht der Daten an die Anwendung zurückgeben.Generated de-normalisiert View-Tabelle

Diese Ansicht wird langsam, da neue Anforderungen hinzugefügt werden.

Eine Lösung, die eine Option wäre, würde eine normale Tabelle zu erstellen, und wählen Sie aus der Ansicht in diese Tabelle, und lassen Sie die Anwendung diese hoch indizierte und schnelle Tabelle für die Abfrage verwenden.

Problem ist, ich denke, wenn die zugrunde liegenden Tabellen ändern, zeigt die neue Tabelle alte Ergebnisse. Aber die Daten, die diese Tabelle steuern, ändern sich sehr selten. Und wenn dies der Fall ist, könnte ein geschäftlicher/technischer Prozess durchgeführt werden, der bedeutet, dass eine Aktualisierung der Tabelle ausgeführt wird, um diese Daten zu aktualisieren. Oder sogar einen Aktualisierungs-/Einfüge-Trigger auf dem primären Fahrtisch?

Ist diese Praxis ratsam/schlecht beraten? Und gibt es Möglichkeiten, es sicherer zu machen?

+2

Sie können sich das als Caching vorstellen. Ich aktualisiere/aktualisiere eine Tabelle/einen Cache mit dem Ergebnis einer komplexen Abfrage alle paar Minuten, so dass Benutzer Daten sehen, die wenige Minuten alt sind. Es kann für Sie akzeptabel sein. Sehen Sie sich auch [indizierte Sichten] an (https://msdn.microsoft.com/en-AU/library/ms191432.aspx). Aber sie haben eher [strenge Beschränkungen] (https://www.brentozar.com/archive/2013/11/what-you-can-and-cant-do-with-indexed-views/). –

+0

Danke @VladimirBaranov - Das ist hilfreich. Ich wollte indizierte Ansichten verwenden, aber da ich ein Pivot innerhalb der Ansicht oder innerhalb einer von der Ansicht verwendeten Funktion ausführen muss, überschreite ich die Einschränkungen. Meine einzige Option scheint die zwischengespeicherte Tabelle zu sein. – Craig

Antwort

0

Die ideale Lösung besteht darin, die zugrunde liegenden Abfragen zu optimieren.

Führen Sie in SSMS die langsame Abfrage aus und fügen Sie den tatsächlichen Ausführungsplan (Strg + M) ein. Dadurch erhalten Sie eine grafische Darstellung der Ausführung der Abfrage für Ihre Datenbank. Ein weiteres hilfreiches Werkzeug auf IO-Statistiken zu drehen ist, ist dies in der Regel der Hauptengpass bei Abfragen, setzen Sie diese Zeile an der Spitze der Anfrage Fenster:

SET STATISTICS IO ON; 
  1. Überprüfen Sie, ob SQL alle fehlenden Indizes empfiehlt (angezeigt in grün im Ausführungsplan), wie Sie sagen, die Daten ändern sich selten, so dass es sicher sein sollte, bei Bedarf weitere Indizes hinzuzufügen.
  2. Im Ausführungsplan können Sie den Mauszeiger über ein beliebiges Element bewegen, um den Wert für geschätzte Zeilen im Vergleich zu tatsächlichen Zeilen zu überprüfen. Wenn dies stark variiert, können Sie die Statistiken für die Tabellen aktualisieren bester Ausführungsplan. diese in einer Datenbank für alle Tabellen zu tun:

    USE [Database_Name]

    GO

    exec sp_updatestats

Noch kein Glück in der Ansicht/Abfrage optimieren?

Seien Sie vorsichtig mit Update-Triggern, als ob sich das Schema in der Ansicht/Tabelle ändert (sagen Sie eine neue Spalte zur Quellentabelle hinzufügen). Die neue Spalte wird nicht in Ihre 'optimierte' Tabelle eingefügt, wenn Sie den Trigger nicht aktualisieren. Wenn es keine geschäftliche Anforderung ist, über Echtzeitdaten zu berichten, ist es nicht allzu schädlich, eine separate optimierte Tabelle für das Reporting zu haben (ähnlich wie bei einem DataMart), verwenden Sie einfach einen SQL Agent-Job, um ihn nachts während des Nichtaktualisierens zu aktualisieren -Stoßzeiten. Es gibt ein paar Nachteile, obwohl zu diesem Ansatz:

  • Mehr Stauraum/duplizierten Daten

  • Komplexere Datenbank

  • Zusätzliche Arbeitsbelastung während des Auffrischungs

  • Cache-Hits Verminderte