Gibt es signifikante Unterschiede zu mehr als 500 Millionen Zeilentabellen in Oracle?

Ich bin in einem Datenbankdesigner in einer Data Warehouse-Umgebung. Ich bin es gewohnt, mit Tabellen mit maximal 1 Million Zeilen umzugehen, und bin jetzt mit Tabellen mit mehr als einer halben Milliarde Zeilen konfrontiert. Gibt es signifikante Unterschiede zu den Tools in der "Effizienz-Toolbox"? Kann ich meinem Vorwissen über Indizes, Partitionen und dergleichen vertrauen oder sind einige dieser spezifischen Tools eher ein Hindernis als eine Hilfe bei so großen Datenmengen? Irgendwelche anderen Tipps zum Umgang mit den Tabellen?

(Es wurde bereits ein großartiger Beitrag zum Aktualisieren von 700 Millionen Zeilen auf denselben Wert gefunden. )

Die Grundlagen der Indizierung usw. funktionieren alle genau gleich. Der einzige Unterschied besteht also streng genommen darin, dass die Kosten dafür falsch sind!

Das heißt, hier ist eine (nicht unbedingt vollständige) Liste von Dingen, die es wert sind, berücksichtigt zu werden:

• B-Tree-Indizes enthalten wahrscheinlich eine zusätzliche Ebene, sodass die Kosten für deren Verwendung etwas höher sind. In einem DW sollten Sie jedoch Bitmap-Indizes verwenden (vorausgesetzt, Sie haben eine Enterprise Edition).
• Die Berechnung der Statistiken für die gesamte Tabelle dauert viel länger - bis zu dem Punkt, an dem dies im normalen Nachtfenster möglicherweise nicht mehr möglich ist. Dies kann überwunden werden durch
  • Verwenden Sie estimate_percentbeim Sammeln von Statistiken eine kleinere , damit weniger von der Tabelle abgetastet wird.
  • Verwenden der Erfassung inkrementeller Statistiken (nur relevant, wenn Sie jedoch globale Indizes für partitionierte Tabellen haben)
• Histogramme für Indizes sind auf 254 Buckets begrenzt. Mehr Zeilen bedeuten wahrscheinlich eindeutigere Werte, was bedeutet, dass "fast beliebte" Werte ein größeres Problem für verzerrte Daten sein können.
• Die Wahrscheinlichkeit, dass Ihre gesamte Tabelle in den Puffercache passt, nähert sich Null, was bedeutet, dass Sie mit größerer Wahrscheinlichkeit mehr physische (Festplatten-) Lesevorgänge haben. Ihr normaler Arbeitssatz ist möglicherweise auch zu groß, um zwischengespeichert zu werden.
• Partitionierung kann dein Freund sein - wenn du es richtig machst! Wenn Sie normalerweise Daten über mehrere Partitionen hinweg ändern und abfragen, kann dies mehr kosten als einfache Tabellen.
• Materialisierte Ansichten können sehr nützlich sein, um Ihren Arbeitssatz zu reduzieren. Wenn Sie beispielsweise Daten im Wert von mehr als 10 Jahren haben, die überwiegende Mehrheit der Benutzeranfragen jedoch nur gegen die letzten 2 Jahre gerichtet ist, kann die Erstellung eines MV, das nur auf diese Daten beschränkt ist, eine große Hilfe sein.
• Je größer die Datenbank ist, desto unwahrscheinlicher ist es, dass das Unternehmen eine Testdatenbank finanzieren kann (kann), die ein vollständiges Duplikat der Live-Umgebung darstellt. Dies macht es schwieriger, Leistungsprobleme im Test zu reproduzieren, da langsame Abfragen auf den Umfang und / oder die physische Speicherung der Daten zurückzuführen sein können. Sie können sich nicht darauf verlassen, dass Sie Abfrageergebnisse aus einer viel kleineren Test-DB auf die entsprechende Leistung im Live-Modus extrapolieren können.

Wenn Sie noch nicht mit dem Lesen und Verstehen von Ausführungsplänen vertraut sind, würde ich einige Zeit damit verbringen, diese zu lernen: Sie müssen irgendwann auf Leistungsprobleme stoßen, sodass es wichtiger wird, zu wissen, wie das Problem richtig diagnostiziert werden kann, da es schwieriger ist, neue hinzuzufügen indiziert oder nimmt Schemaänderungen vor, wenn Ihre Zeilenanzahl größer ist.

Quantität hat eine ganz eigene Qualität.

Wenn Sie mit Tabellen dieser Größe arbeiten, ist es hilfreich, die Faktentabelle nicht als Tabelle, sondern auf Segmentebene oder als Sammlung diskreter Tabellen zu betrachten. (Es hilft, alt genug zu sein, um sich daran zu erinnern, wie ich meine eigene Partitionierung mit Partitionsansichten gerollt habe.)

Tim Gormans Artikel " Scaling to Infinity" ist eine unschätzbare Ressource.