Oracle Mehrere Schemen Aggregate Echtzeit anzeigen

Question

Alle,

auf einer Oracle-Design-Entscheidung für einige Hinweise Suche ich zur Zeit zu bewerten, ich versuche:

Das Problem

Ich habe Daten in drei separaten Schemas auf demselben Oracle DB-Server. Ich möchte eine Anwendung erstellen, die Daten aus allen drei Schemas anzeigt. Die angezeigten Daten basieren jedoch auf Echtzeit-Sortier- und Priorisierungsregeln, die global auf die Daten angewendet werden (dh basierend auf den angewendeten Prioritätsgewichtungen) Ziehen Sie Daten von einem der drei Schemas zurück).

Vorläufiger Lösung

eine Ansicht in der DB erstellen, die auf die entsprechenden Spalten in den drei Schemata logische Verbindungen unterhalten, schreiben Sie eine gespeicherte Prozedur, die Priorität Gewichtungen parametrisiert akzeptiert. Anschließend ruft die Anwendung die gespeicherte Prozedur auf, um die "priorisierte" Zeile aus der Sicht auszuwählen, und fragt dann das zugeordnete Schema direkt nach zusätzlichen Daten ab, die auf der zurückgegebenen Zeile basieren.

Ich habe Bedenken in Bezug auf die Leistung, wo die Daten bei jeder durchgeführten Abfrage sortiert/priorisiert werden, aber keine Möglichkeit haben, dies zu sehen, da sich die Priorisierungsregeln häufig ändern. Wir sprechen von Datensätzen im Bereich von 2-3 Millionen Zeilen pro Schema.

Hat jemand alternative Vorschläge zur Bereitstellung einer aggregierten und sortierten Ansicht über die Daten?

Answer 1

Abfrage von mehreren Schemas (oder sogar multiple databases) ist nicht wirklich eine große Sache, auch innerhalb der gleichen Abfrage. Nur prepend die Tabellennamen mit dem Schema, das Sie interessiert sind, wie in

SELECT SOMETHING 
FROM 
    SCHEMA1.SOME_TABLE ST1, SCHEMA2.SOME_TABLE ST2 
WHERE ST1.PK_FIELD = ST2.PK_FIELD 

Wenn die Leistung zu einem Problem wird, dann ist das ein großes Thema ... optimale Abfragepläne, Indizes und Ihre Methode der Datenbankverbindung kann alle kommen ins Spiel. Eine Sache, die in den Sinn kommt ist, dass, wenn es nicht Echtzeit sein muss, könnten Sie materialized views (aka "snapshots") verwenden, um die Daten an einem einzigen Ort zu cachen. Dann könnten Sie das mit angemessener Leistung abfragen.

Legen Sie die Snapshots so fest, dass sie in einem Ihren Anforderungen entsprechenden Intervall aktualisiert werden.

Answer 2

Es spielt keine Rolle, dass die Daten von 3 Schemas sind, wirklich. Es ist wichtig zu wissen, wie häufig sich die Daten ändern, wie oft sich die Kriterien ändern und wie oft sie abgefragt werden.

Wenn es eine endliche Menge von Kriterien gibt (das heißt, die Daten werden auf eine beschränkte Anzahl von Arten betrachtet), die nur alle paar Tage wechseln und wie verrückt abgefragt werden, sollten Sie sich wahrscheinlich materialisierte Ansichten ansehen.

Wenn die Kriterien nahezu unbegrenzt sind, dann macht es keinen Sinn materialisierte Ansichten zu erstellen, da sie wahrscheinlich nicht wiederverwendet werden. Das gleiche gilt, wenn sich die Kriterien selbst extrem häufig ändern, die Daten in einer materialisierten Ansicht würden auch in diesem Fall nicht helfen.

Die andere Frage, die unbeantwortet ist, ist, wie oft die Quelldaten aktualisiert werden und wie wichtig es ist, die neuesten Informationen zu haben. Ein häufig aktualisierter Quellentag kann entweder bedeuten, dass eine materialisierte Ansicht für einige Zeit "veraltet" wird, oder Sie können viel Zeit darauf verwenden, die materialisierten Ansichten unnötig zu aktualisieren, um die Daten "frisch" zu halten.

Ehrlich, 2-3 Millionen Datensätze sind für Oracle nicht mehr genug, vorausgesetzt, es gibt genügend Hardware. Ich würde wahrscheinlich einfache dynamische Abfragen zuerst benchmarken, bevor ich eine anschauliche (materialisierte) Ansicht versuche.

Answer 3

Wie andere schon gesagt haben, ist die Abfrage von ein paar Millionen Zeilen in Oracle nicht wirklich ein Problem, aber das hängt davon ab, wie oft Sie es tun - jede Zehntelsekunde kann den db Server belasten!

Ohne weitere Details Ihrer Geschäftsanforderungen und ein gutes Modell Ihrer Daten ist es immer schwierig, gute Leistungsideen zu liefern. Es kommt in der Regel darauf an, eine Theorie zu entwickeln, die dann gegen Ihre Datenbank versucht und darauf zugreift, ob sie "schnell genug" ist.

Es kann sich auch lohnen, einen Schritt zurückzutreten und sich zu fragen, wie genau die Ergebnisse sein müssen. Braucht das Unternehmen wirklich genaue Werte für diese Abfrage oder sind gute Schätzungen akzeptabel

Tom Kyte (von Ask Tom Ruhm) hat immer einige interessante Ideen (und Fakten) in diesen Bereichen. This article describes generating a proper dynamic search query - but Tom points out that when you query Google it never tries to get the exact number of hits for a query - it gives you a guess. Wenn Sie einen guten Schätzwert anwenden können, können Sie die Abfrageleistungszeiten wirklich verbessern