Clustered Index in SQL Server im Vergleich zu indexorganisierten Tabellen in Oracle

Ich mache den Übergang als Datenbankentwickler von SQL Server zu Oracle und habe hier bereits einige fantastische Ressourcen gefunden ( Wie mache ich einen Übergang von SQL Server DBA zu Oracle? Und wie würde ich als DBA von Oracle zu SQL Server wechseln? ? ), aber es fällt mir schwer, gute Informationen zur Verwendung von indexorganisierten Tabellen in Oracle zu finden.

In meinem früheren Leben haben wir Clustered-Indizes in SQL Server in unserem OLTP-ish-Datamart mit großem Erfolg ausgiebig verwendet. Sind indexorganisierte Tabellen ein nützliches Werkzeug in Oracle?

Wenn Sie von SQL Server zu Oracle wechseln, würde ich empfehlen, zunächst Heap-Tabellen zu verwenden, da diese die Standardform zum Speichern von Daten in Oracle sind. Für die meisten Workloads sind Heap-Tabellen mit regulären Indizes in Oracle die ausgewogensten Speicherformen in Bezug auf DML und Abfrageleistung.

Wenn Sie später feststellen, dass Sie Leistungsprobleme oder Engpässe haben, sollten Sie sich mit speziellen erweiterten Speichermethoden wie IOT, Partitionierung, Clustern, Reverse-Key-Indizes usw. befassen.

Insbesondere in Bezug auf IOT würde ich von ihrer allgemeinen Verwendung abraten, da es viele "Fallstricke" gibt, auf die Sie als Anfänger möglicherweise nicht eingehen möchten:

• IOT haben keine echte Rowid (weil es an sich keine Tabelle gibt).
• Folglich haben Sekundärindizes auf IOT keine echten Zeiger auf die Zeilen, sondern nur Vermutungen, die zu ineffizienten Indexscans führen können.
• Einige Funktionen sind auf IOTs deaktiviert, z. B. virtuelle Spalten , Tabellenkomprimierung und zusammengesetzte Partitionierung.
• Sie müssen bei der Erstellung entscheiden, wo die Nicht-Index-Spalten (Inline oder in einem Überlaufsegment) gespeichert werden sollen, was bei einigen Abfragen möglicherweise zu einer katastrophalen Leistung führt.

IOTs in Oracle sind nicht ganz dasselbe wie Clustered-Indizes in SS, da Oracle-Statistiken die physische Streuung von Zeilen enthalten, während SS keinen physischen Speicherort in seinen Statistiken enthält. Weitere Informationen finden Sie in dieser Debatte zwischen Lewis und Fritchey über Statistiken in Oracle und SQL Server. ( http://www.red-gate.com/products/oracle-development/deployment-suite-for-oracle/education/webinars/webinar-statistics-oracle-sql-server-jonathan-lewis ) Aus diesem Grund wird ein Cluster erstellt Index in SS ist besser als ein Haufen. Der Clustered-Index fügt den Statistiken physische Standortdaten hinzu. IOTs sind gut, wenn Sie wissen, dass der Index eine Colocation von Datenzeilen bietet, die durchsucht werden sollen, z. B. würde ein Index für order_date und der Kunde für eine Auftragstabelle ein gutes IOT ergeben.

Vincent macht einige großartige Punkte aus den Vorbehalten von IOTs, aber Sie können auch einige signifikante Vorteile daraus ziehen.

Persönlich denke ich, dass sie in Oracle erheblich zu wenig genutzt werden und viel weiter betrachtet werden sollten - nicht nur als mögliche Lösung für Leistungsprobleme. Da Sie die Tabelle neu erstellen müssen, um zwischen IOT und Heap zu konvertieren, ist dies eine Änderung, die in einer immer aktiven, stark genutzten Datenbank wahrscheinlich nicht auftritt, es sei denn, die Leistungsprobleme sind schwerwiegend.

Martin Widlake hat eine großartige Reihe von Posts über IOTs. Es gibt einige bedeutende Vorteile, die Sie durch ihre Verwendung erzielen können:

• Reduzieren Sie physische und logische E / A-Lesevorgänge erheblich
• Effizientere Nutzung des Puffercaches, was die systemweite Leistung verbessern kann
• Platz gespart, da Sie nur einen Index verwalten, nicht auch eine Tabelle (es sei denn, Sie haben Überlaufsegmente).

Um diese Vorteile zu erzielen, benötigen Sie jedoch Tabellen, in denen Sie (fast) immer die führenden Spalten des Primärschlüssels in Abfragen einschließen und wahrscheinlich mehrere Zeilen gleichzeitig abrufen. Einige gängige Beispiele für solche Tabellen sind:

• Master-Multiple-Details, wie sie häufig in Bestellungen zu finden sind - Bestellpositionen, Rechnungen - Rechnungspositionen usw.
• Viele-zu-viele-Auflösungstabellen, die normalerweise "in eine Richtung" abgefragt werden. Beispielsweise ist es in einer customer_addressesTabelle weitaus üblicher, alle Adressen für einen Kunden zu finden, als alle Kunden für eine Adresse.

Ein Nachteil ist, dass das Einfügen von Daten langsamer ist, sodass Sie Kosten und Nutzen abwägen müssen. Letztendlich kommt es darauf an, Ihre Daten zu kennen und zu verstehen, wie sie verwendet werden sollen, um die Entscheidung zu treffen.