vorheriger Artikel
Der Teufel steckt im Detail - welche Kleinigkeiten über die Effektivität von Partition Pruning entscheiden
In dem vorhergehenden Artikel dieser Serie wurde ein praxisnaher und effektiver Ansatz zur Nutzung von Partition Pruning eingehend erläutert. Mit Hilfe dieser einfach umzusetzenden Methode können die Abfragezeiten deutlich optimiert werden. Um jedoch die effiziente und effektive Nutzung der vorgestellten Methode zu gewährleisten, müssen, wie so häufig, einige Details beachtet werden. In diesem Aspekt halten wir es mit Theodor Fontane, der schon im 19. Jahrhundert festgehalten hat, dass der Zauber immer im Detail steckt.
Im Folgenden werden deshalb einige essentielle Details näher erläutert, die beim Einsatz von Partition Pruning beachtet werden müssen:
- History Depth: Da die Historie länger wird, wird Partitionierung effektiver.
- Alte Berichte: Wenn Sie eine Änderung von einer Intervalltabelle zu einer partitionierten Intervalltabelle vornehmen, bleiben alle Abfragen dieser Tabelle gültig. (Um die Leistungsvorteile zu erkennen, müssen selbstverständlich die Filterbedingungen angepasst werden.)
- Veraltete Schlüssel: Die Anzahl an Schlüsseln in der historischen Tabelle ändert sich üblicherweise im Laufe der Zeit. In unserem Beispiel werden neue Konten eröffnet und andere werden aufgelöst. Allerdings konnten die Salden für die aufgelösten Konten nicht geändert werden. Aufgrund der beschriebenen Logik sollten jedoch die entsprechenden Zeilen in jeden neuen Monat kopiert werden, was zu einer unnötigen Vergrößerung der Tabelle führt. Um diesen Effekt zu minimieren, kann ein Standardwert für historisierte Attribute definiert werden. Ist eine Zeile nicht vorhanden, sollte dies so ausgelegt werden, dass das Attribut diesen Wert hat. In unserem Beispiel kann vernünftigerweise angenommen werden, dass ein aufgelöstes Konto einen Saldo von null aufweist. Aus diesem Grund können wir eine Logik implementieren, gemäß der Zeilen mit einem Nullsaldo nicht beibehalten werden. Stattdessen sollten wir immer, wenn wir eine Auswahl treffen, das Fehlen einer Zeile als null zählen. Ein weiteres Beispiel: Wenn wir den Status eines Kontos verfolgen, könnte "Inaktiv" einen solchen Standardwert darstellen.
- ETL-Leistung: ETL ist für partitionierte Tabellen etwas komplizierter. Es ist jedoch nicht notwendigerweise langsamer, da nicht die gesamte Zieltabelle gelesen werden muss, um Unterschiede festzustellen.
- Bestimmtes Datum in der Zukunft: Wenn Sie Salden für ein Datum auswählen, das in einem Monat liegt, der noch nicht in die Tabelle geladen wurde, erhalten Sie keine Zeilen. Wenn Sie herkömmliche Intervalltabellen verwenden, erhalten Sie als Ergebnis Salden für das zuletzt geladene Datum. "Keine Zeilen" ist meiner Ansicht nach genauer, da wir den künftigen Status nicht kennen, tatsächlich sollte jedoch die Differenz berücksichtigt werden.
- ETL für partitionierte Intervalltabellen sollte die Situation "wenn am ersten Tag eines neuen Monats keine Änderungen vorgenommen wurden" richtig verarbeiten. Aktuelle Werte aus dem Vormonat sollten auf jeden Fall kopiert werden.
- Lokaler Index für den Primärschlüssel: Sie können den lokalen Index für den Primärschlüssel verwenden, wenn Sie die Tabelle partitionieren. Dies beschleunigt die Pflege der Tabelle und ermöglicht es Ihnen, während eines ETL-Durchlaufs einzelne Partitionen anstelle des gesamten Indexes aufzugeben/zu rekonstruieren.
- Partitionsstatistiken: Für den Fall von partitionierten Intervalltabellen können Optimierer von Oracle Partitionsstatistiken verwenden, da jedes Mal nur auf eine Partition zugegriffen wird. Aus diesem Grund können Sie bei der Erhebung von Tabellenstatistiken für sehr große Tabellen Ressourcen sparen.
