Archiv der Kategorie: Performance

Daten blitzschnell nach CSV entladen mit dem Pro*C-unloader

Heute möchte ich auf ein altes, aber bewährtes Tool von Tom Kyte verweisen, das nach meiner Erfahrung weitgehend unbekannt oder unterbewertet ist, das aber extrem hilfreich ist, wenn man Daten aus Oracle mit bestmöglichem Durchsatz entladen will: Auftritt „unloader“!

Weiterlesen

Werbeanzeigen

Neues vom Clustering Factor

Richard Foote (der „Index-Guru“) hat auf seinem Blog in mittlerweile drei Artikeln Neues zur Berechnung des Clustering Factors (CF) verkündet:

  1. Erster Artikel: Ein Patch für Oracle 11.2 führt eine neue Option „TABLE_CACHED_BLOCKS“ für die Berechnung mit DBMS_STATS ein. Dieser kann von 0-255 oder auf AUTO gesetzt werden und sorgt für eine Berücksichtigung von Caching-Effekten, die bislang nicht in die Berechnung des Clustering Factors eingegangen sind. Dadurch können unberechtigt zu hohe CFs deutlich reduziert werden, wenn die indizierten Rows innerhalb der nächsten n Blöcke der Zieltabelle liegen. n wird bei AUTO auf 1% der Tabellengröße in Blöcken gesetzt.
  2. Im zweiten Artikel geht Richard Foote auf Bedenken aus den Kommentaren zu Teil 1 ein, speziell die Bedenken, daß der CF nunmehr zu niedrig werden könnte. Ein ausführlicher Testfall mit einer großen Tabelle zeigt, daß hier selbst das Maximum von TABLE_CACHED_BLOCKS=255 keine gravierende Änderung zur Folge hat.
  3. Im dritten Artikel wird als Gegenbeispiel die maximale Einstellung auf eine kleine Tabelle angewendet und dargestellt, dass in solchen Fällen ein hoher Wert für TABLE_CACHED_BLOCKS, der nahe an der Anzahl an Datenblöcken der Tabelle liegt, kontraproduktiv sein kann.

Eine „Best Practice“ wird sich wohl erst noch herauskristallisieren müssen. Meine persönliche Vermutung anhand der bislang diskutierten Testfälle geht dahin:

  • TABLE_CACHED_BLOCKS = AUTO als DB-weite Einstellung
  • Wo es dann immer noch Probleme mit einem zu hohen CF gibt, Objekt-spezifische Einstellung dieser Option.

Weiterlesen

Alt, aber bezahlt: Oracle Disk Manager auf VxFS

Neues aus den Rubriken „Old Feature“ und „unbekannt oder unterbewertet„: Der Oracle Disk Manager (ODM)!

Nicht immer hat man als DBA in einem Unternehmen die Wahl, welche Speichersysteme man für die Datenbank einsetzt, und seien sie auch noch so effizient: Es gibt oft altertümliche Standards, gerne auch als „Best Practice“ bezeichnet (um sie über jeden Zweifel, jedes Gegenargument und jegliche Innovation erhaben zu machen), an die man sich halten muss. Ein solcher Standard ist die zwingende Nutzung von Dateisystemen anstelle von ASM und/oder Raw Volumes.

Worin aber sollen denn die Nachteile von Dateisystemen liegen? Sie sind doch so schön bequem handhabbar?

Weiterlesen

Bug: Basic Table Compression und lang laufende UPDATEs

Im Rahmen eines Projektes, in dem Basic Table Compression eingesetzt wird, bin ich offensichtlich in einen Bug gelaufen. Umgebung:

  • Oracle 11.2.0.3.0, Enterprise Edition
  • Solaris 10

Ziel war die Maskierung von Daten auf einer großen, partitionierten Tabelle, die mit dem Attribut COMPRESS erstellt wurde. Gegenüber einer unkomprimierten Version waren die Laufzeiten für ein Update allerdings zehn- bis zwanzigmal länger und mit 100% CPU-Last während der vollen Laufzeit verbunden.

Hier ein Testfall, der auch ohne Partitionierung (und im Prinzip auch ohne die hier verwendeten Regular Expressions) auskommt: Weiterlesen

RELY-Constraints als Hilfe für den Optimizer und die Datenmodellierung

Oft werden dem unbestrittenen Nutzen von Constraints Nachteile im Zeitbedarf für deren Einsatz gegenüber gestellt, dabei lassen sich diese Nachteile oftmals leicht umschiffen. Zudem kann die Geschwindigkeit von Abfragen wesentlich schlechter werden, wenn keine Constraints eingesetzt werden!

„Wir setzen keine Constraints in unserer [großen Datenbank|DWH-DB|…] ein, weil die Performance bei der Beladung dann zu schlecht ist.“
Diese Ausrede gilt spätestens seit der Verfügbarkeit von RELY-Constraints nicht mehr! Weiterlesen

Unterbewertet oder unbekannt: Deferred Constraints

Über Nutzen und Nachteile von Constraints wird gerne und leidenschaftlich gestritten. Auf der Seite der Nachteile wird oft angeführt, daß die zeilenweise Verifizierung (im Englischen auch gerne als „slow-by-slow“ verballhornt) ein Performance-Killer ist. Es wäre also durchaus praktisch, wenn auch Constraints stapelweise, z.B. pro Transaktion, abgearbeitet werden könnten. Auftritt der Deferred Constraints!

Weiterlesen

NVL-st Du noch oder COALESCE-t Du schon?

NULL-„Werte“ an sich können dem DB-Entwickler genug Kopfzerbrechen bereiten, um alleine damit ganze Artikelserien zu füllen. Hier möchte ich mich lediglich auf einen kleinen Ausschnitt der Problematik beschränken, nämlich der Performance beim Vergleichen und Ersetzen von NULLs. Zum Ersetzen von NULLs in Abfragen wird zumeist die Funktion NVL() verwendet. Diese Funktion hat jedoch zwei entscheidende Nachteile:

  1. Sie bietet nur die Möglichkeit, genau einen Ausdruck mit einem anderen zu ersetzen. Will man mehr als zwei Ausdrücke gegeneinander vergleichen, muss die Funktion kaskadiert werden.

  2. Der zweite Ausdruck wird immer ausgewertet, auch dann, wenn der erste Ausdruck bereits NOT NULL ist.

Weiterlesen