Schlagwort-Archive: Best Practice

Windows Large Pages

Vor einiger Zeit hatte ich hier über Linux HugePages geschrieben. Die sind ja mittlerweile kein Geheimtipp mehr, und ab Oracle 12.2 lässt sich mit dem DBCA sogar eine Datenbank bei einem RAM > 4GB nur noch mit HugePages anlegen (oder es erscheint die Fehlermeldung „[DBT-11211]“).

Etwas anders scheint es nach meinem Eindruck um die Windows Large Pages bestellt zu sein. Da Oracle jedoch ab 4 GB SGA empfiehlt, auch unter Windows die größeren Speicherseiten zu nutzen, möchte ich hier eine kurze Einführung dazu schreiben.

Weiterlesen

Advertisements

Linux Huge Pages: Schnellstart

If you’re not using HugePages, you’re doing it wrong!  (Mark J. Bobak)

Sie haben eine SGA von mehreren GB Größe, dazu mehrere Hundert Sessions auf der Datenbank? Ihr DB-Server läuft unter Linux, aber ohne Einsatz von HugePages? Dann verschenken Sie RAM und CPU-Leistung, und zwar nicht zu knapp!

Über Linux HugePages wurde schon viel geschrieben (s. Literaturliste unten), jedoch hauptsächlich auf Englisch und meist sehr ausgedehnt. Dieser Artikel soll die wichtigsten Fakten und Maßnahmen in Kürze aufzeigen.

Szenario

Ein Praxisbeispiel vorweg: Eine Data Warehouse-DB mit 20 GB SGA und etwa 300 Sessions läuft auf einem Server mit 32 GB RAM. Gelegentlich gerät der Server unter höhere Last und fängt daraufhin an, massiv zu swappen; die Performance geht in die Knie. Was ist passiert?

Weiterlesen

SYSDATE in SQL und PL/SQL

Heute fühle ich mich genötigt, ein Thema anzusprechen, das zwar ein Grundlagenthema ist, das aber immer wieder gerne in Vergessenheit gerät. ;-)

Anlass ist ein Fund in einer Produktionsumgebung, in der eine Überlastung der CPU bei sehr hoher Anzahl an SQL-Ausführungen zu beobachten war. Die Umgebung basiert sehr stark auf PL/SQL, wobei häufig verwendete SQL-Abfragen gerne in einer Function gekapselt und dann aus SQL heraus aufgerufen werden. Weiterlesen

PL/SQL Injection in Oracle 12c

David Litchfield, der bereits andere Injection-Lücken in Oracle gefunden hatte (s. meine anderen Artikel der Kategorie „Sicherheit“), hat wieder zugeschlagen und eine Injection-Methode unter 12c aufgedeckt:
http://www.davidlitchfield.com/Exploiting_PLSQL_Injection_on_Oracle_12c.pdf

Sehr kurze Zusammenfassung des Dokuments:

  • Ein User mit Execute-Recht auf DBMS_SQL und DBMS_JAVA_TEST kann damit SQL Injections durchführen.
  • Der Entzug von Execute auf DBMS_JAVA_TEST und DBMS_JAVA wirkt dem entgegen.
  • Wenn Java in der DB nicht benötigt wird, sollten diese Packages gleich ganz deinstalliert werden, um die Angriffsfläche zu verringern.

Oracle 12c / Java7: setEndToEndMetrics() deprecated

Dies ist eine kurze Aktualisierung zu meinem früheren Artikel „DBMS_SESSION: Anwender und Sessions mehrschichtiger Anwendungen in der DB identifizieren„, der sich auf Oracle 11.2 nebst der damals unterstützten JDBC-Version bezog.

Die Oracle 12c JDBC-Treiber unterstützen JDBC 4.1 über das JDK 7 und damit auch die JDBC DMS Metrics, wenn entsprechende Treiber-Packages (z.B. ojdbc7dms.jar) verwendet werden. Die in meinem damaligen Beispiel verwendete Methode setEndToEndMetrics schließt allerdings die wechselseitige Verwendung mit DMS-Methoden aus. Daher empfiehlt es sich auf die neue Methode setClientInfo umzustellen. Ein Codefragment mit der neuen Methode kann dann so aussehen:

...
Connection conn = DriverManager.getConnection(myUrl, myUsername, myPassword);
conn.setClientInfo("E2E_CONTEXT.DBOP", "MeinTag");
Statement stmt = conn.createStatement();
// DBOP-Tag wird mit dem naechsten DB-Aufruf gesetzt:
stmt.execute("select 1 from dual");
...

Dem Nachteil, dass schon wieder eine andere Methode als bisher verwendet werden soll, steht der Vorteil gegenüber, dass man sich mit DMS Metrics in einem standardisierten Umfeld bewegt und auch nicht mehr zwingend eine OracleConnection verwenden muss; eine einfache Connection reicht aus.

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

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