Home > Datenbanken > Blog 
Inhaltsbereich

Alle Artikel [+]





Kategorie: Datenbank News
16.07.2014

Hohe Datenbank I/O-Performance mit SSD-Storage

Wir haben ein System untersucht, das als Storage für eine Oracle-Datenbank ein RAID aus SSD-Modulen nutzt und wollten wissen, wie viel I/O-Performance man damit erreicht.

Wir waren begeistert!

Eine Beschreibung des Tests und der Ergebnisse steht als PDF zum Download bereit.




Kategorie: Datenbank News
02.07.2014

ORACLE-Tipp: Tatsächlicher Ausführungsweg eines SQL-Statements

DBMS_XPLAN.DISPLAY_CURSOR zeigt den tatsächlichen Ausführungweg

Sich den Ausführungsplan eines SQLs anzeigen zu lassen, ist wohl ein alter Hut (z.B. mittels EXPLAIN PLAN oder einfach im SQL Developer (z.B. Taste F10)). Auch TRACE und TKPROF um Informationen über die Ausführung von SQLs zu ermitteln, ist eine altbewährte Methode.

Ein nicht ganz so alter Hut, aber immerhin schon seit 9i verfügbar, ist das Package DBMS_XPLAN, das meiner Meinung nach mit Version 11g fast unverzichtbar geworden ist: Es zeigt uns auf einfache Weise den tatsächlichen Ausführungsweg eines SQLs, der völlig oder in Teilen von dem Ausführungsplan abweichen kann.

Was kann eine abweichende Ausführung verursachen:

  • "Cardinality Feedback“ (seit Version 11gR2):
    Wird ein SQL zum wiederholten Male ausgeführt, kann der Optimizer Kardinalitäts-Informationen (= Anzahl Datensätze aus einer Datenquelle) von früheren Ausführungen heranziehen um seine Schätzung zu korrigieren und so einen besseren Plan zu erarbeiten.
  •  „Adaptive Plans“ (seit Version 12c):
    Der Optimizer ermittelt neben einem „Standard“ Ausführungsplan einige mögliche Alternativen für Teil-Ausführungspläne. Erkennt er bei Ausführung, dass bestimmte Schätzungen bezüglich der Kardinalitäten nicht zutreffend waren, kann er auf einen alternativen Teil-Plan umschalten.

Man sieht, dass Oracle den Optimizer immer robuster gegen schlechte Statistiken bzw. schlechte Schätzungen macht.

Ein SQL-Entwickler, der ein SQL optimieren will, kann sich also nicht mehr auf den einfachen Ausführungsplan verlassen, da dieser zur Ausführungszeit des SQLs getroffene Entscheidungen nicht wiederspiegeln kann.

Hilfe bietet das bereits erwähnte Package DBMS_XPLAN mit seiner Funktion DISPLAY_CURSOR. Es erlaubt die Anzeige der tatsächlichen Ausführung eines zuvor ausgeführten SQLs, das sich noch im Cursor Cache befindet. (Es werden wohl die Informationen der Views V$SQL, V$SQL_PLAN und V$SQL_PLAN_STATISTICS_ALL ausgewertet.)

Die Ausgabe enthält den Ausführungsweg und ggf. den Hinweis, ob z.B. Dynamic Sampling*, Cardinality Feedback oder Adaptive Plans zur Anwendung kamen. Darüber hinaus können in die Ausgabe neben den geschätzten Kardinalitäten aus dem Plan auch die tatsächlichen Kardinalitäten bei der Ausführung angezeigt werden. Dies ist enorm hilfreich um fehlerhafte Statistiken oder „schlechte“ Schätzungen des Optimizers (z.B. aufgrund zu komplexer Prädikate) zu erkennen.

1.    SQL ausführen, z.B.:

select * from locations_med where city_id = 29;

2.    Aufruf DBMS_XPLAN (es handelt sich um eine table function, deshalb per select from table(..)):

select * from table(dbms_xplan.display_cursor(format => 'IOSTATS TYPICAL'));

Beispiel-Ausgabe

PLAN_TABLE_OUTPUT

---------------------------------------------------------------------------------------------------------------------

SQL_ID  d0gkrtrf91wgr, child number 0

-------------------------------------

select count(*) from test where city_id = 29

 

Plan hash value: 1950795681 

---------------------------------------------------------------------------------------------------------------------

| Id  | Operation          | Name | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |

---------------------------------------------------------------------------------------------------------------------    

|   0 | SELECT STATEMENT   |      |      1 |        |       |   682 (100)|          |      1 |00:00:00.04 |    2427 |   

|   1 |  SORT AGGREGATE    |      |      1 |      1 |    13 |            |          |      1 |00:00:00.04 |    2427 |   

|*  2 |   TABLE ACCESS FULL| TEST |      1 |  35193 |   446K|   682   (2)| 00:00:09 |  30720 |00:00:00.04 |    2427 |   

---------------------------------------------------------------------------------------------------------------------

 

Predicate Information (identified by operation id):

---------------------------------------------------

   2 - filter("CITY_ID"=29)

 

Note
----- 

   - dynamic sampling used for this statement (level=2)

Hilfreiche Informationen

Man beachte die Spalten E-Rows (estimated, also geschätzte Zeilenanzahl) und A-Rows (actual, also tatsächliche Zeilenanzahl). Unter "Note" sieht man den Hinweis auf "dynamic sampling". Dort würde ggf. auch auf die beiden anderen beschriebenen Features hingewiesen.

In der Handhabung zu beachten: Der Aufruf von display_cursor ohne Angabe einer SQL_ID zeigt immer das zuletzt ausgeführte SQL an (der bequemste Weg). Der SQL Developer oder ähnliche Tools setzen im Hintergrund aber selbst SQLs ab, so dass man ggf. nicht das gewünschte Ergebnis erhält.
Entweder ermittelt man also die SQL_ID aus den o.g. V$-Views oder benutzt aus Bequemlichkeit einen Trick: Im SQL Developer kann man das zu betrachtende SQL und den Aufruf von DBMS_XPLAN zusammen als Skript ausführen (Taste F5), so dass dazwischen keine anderen SQLs abgesetzt werden. Aber dabei ist zu beachten, dass eine umfangreiche Ausgabe des SQLs erst in die Skriptausgabe gespoolt wird und bei 5000 Zeilen (Default-Einstellung des SQL Developer) abbricht. Dies wiederum kann man umgehen, indem man einfach um das zu untersuchende SQL ein äußeres SQL mit select count(*) from (…) setzt. (Warum einfach, wenn's auch kompliziert geht :-)

Für Details zu verschiedenen Ausgabeformaten und zu anderen Funktionen des Packages verweise ich auf die Oracle Doku.

 

*Dynamic Sampling: Bei fehlenden oder unbrauchbaren Statistiken einer Tabelle kann der Optimizer vor Erarbeitung des Plans eine Stichprobe nehmen.

(stefan-hild)Kommentare 0Gravatar:
Tags: oracle, sql, tuning, optimierung, datenbank
Views: 494



Kategorie: Datenbank News
18.06.2014

Baldiges Support-Ende Oracle Database 11g Release 2

In knapp 6 Monaten (Januar 2015) endet der sog. Premier Support für Oracle 11g und ab diesem Zeitpunkt bekommt man ohne den kostspieligen Extended Support keine weiteren Updates für die eigene 11er Datenbank. Aber was genau bedeutet das? Muss jetzt schnellstmöglich auf Oracle 12c umgestellt werden?

Zunächst einmal kann die 11er Datenbank natürlich weiterverwendet werden. Der jährlich zu zahlende Support ist weiterhin zu entrichten, jedoch hat man keinen Anspruch auf eine Fehlerkorrektur beim Auftreten eines internen Oracle Bugs oder einer Sicherheitslücke. Die Frage, ob man nun auf Oracle 12c migriert oder weiterhin die Oracle 11g nutzt, sollte in jedem Fall überdacht werden. Entscheidet man sich dafür, die finale Version 11.2.0.4 weiterhin zu nutzen, hat man eine stabile und ausgereifte Version in welcher es unwahrscheinlich ist, dass produktionskritische Fehler auftreten. Migriert man auf Oracle 12, hat man Anspruch auf den vollen Support und die Möglichkeit, die Neuerungen in Oracle 12c zu nutzen. Jedoch mit einem etwas größeren Risiko, den Support in Anspruch nehmen zu müssen, da eine neuere Datenbankversion meißt noch nicht so stabil ist, wie ein "alt gediente". Unbedingt zu klären ist jedoch, ob denn die eingesetzte Anwendungssoftware bereits für Oracle 12 freigegeben ist.

Zu welcher Entscheidung sie auch kommen, wir bieten ihnen Unterstützung  rund um die Oracle Datenbank an.

Kommentare 0
Tags: oracle, support
Views: 447


Rechter Inhaltsbereich

eXirius IT Dienstleistungen GmbH
Juchem-Straße 24
66571 Eppelborn

Telefon: +49 (6881) 99 99 5 - 0
Fax:        +49 (6881) 99 99 5 - 77

E-Mail: info(at)exirius.de