DBConcepts auf den DOAG Datenbank Tagen in Düsseldorf

Zum ersten Mal war heuer DBConcepts auf den DOAG Datenbank Tagen als Sponsor vertreten, welche vom 3. Juni bis 4. Juni in Düsseldorf stattgefunden haben.

In Summe über 200 Teilnehmer/innen informierten sich in zahlreichen Vorträgen über aktuelle Entwicklungen und Trends im Oracle Datenbank Umfeld.

Unser Kollege und Oracle Performance Tuning Spezialist Lothar Flatz gab in seinem Vortrag mit dem Titel „Trouble im Shared Pool“ seine sehr interessanten Einblicke und Erfahrungen preis.

Durch den hohen Bekanntheitsgrad und seine besonders geschätzte Expertise kam es zur erwarteten Überlastung des Vortragraumes.

Leider konnten die Veranstalter nicht rechtzeitig reagieren, woduch circa 30 Teilnehmer den Ausführungen stehend folgen mussten.
Dieser Umstand tat aber der Begeisterung über den Vortrag keinen Abbruch.

Viele Besucher am DBConcepts Ausstellerstand informierten sich über das Leistungsspektrum der „Oracle Experten“ aus Österreich und meldeten sich zusätzlich zum DBConcepts Newsletter an.

Bei den zahlreichen Gesprächen kristallisierte sich heraus, dass der Großteil der Besucher DBConcpts bereits kannten und als Experten im Oracle Technologie Umfeld in Verbindung bringen.

Wir halten allen Teilnehmer/innen unseres Euromillionen-Gewinnspiel die Daumen, dass die Glücksfee bei ihnen vorbei kommt 🙂

DOAG Datenbank Tag 2019 Messestand von DBConcepts

 

Überfüllter Vortrag von Lothar Flatz Trouble im Shared Pool

 

 

Datenbank Performance Problem und Lösung

Performance Problem: Eine parallele Abfrage stellt ihre Arbeit ein

Kürzlich traf ich bei einem Kunden auf einen ungewöhnlichen Bug der Oracle Version 12.2.
Es handelt sich um eine parallele Abfrage, die scheinbar einfach anhält und ihre Arbeit einstellt. 🙁

Bei näherer Betrachtung erkennt man eine interne Verklemmung zwischen den Koorditinatorprozess und einem der Parallelprozesse. Das Ganze ähnelt einem Dead Lock!

Problem Analyse

Beide Prozesse warten auf „table queue“ Kommunikation.

Der Query Coordinator wartet mit „PX Deq: Execute Reply“ und der blockiernde Parallel Process wartet mit „PX Deq: Table Q Normal“.

Der Rest der Parallelprozesse warten mit dem event „PX Deq: Execution Msg“.

Damit es zum besagten Problem kommt, muß auch eine analytic_function beteiligt sein.

Im Kern geht es darum, wie Oracle den Window Sort parallelisiert, der mit einer analytic function zwangsweise verbunden ist.

In früheren Oracle Versionen war dieser Sort of weniger effizient als ein regulärer Sort und daher entsprechend langsamer.

In dem sehr gute Post von Phythian’s Christo Kutrovsky wird das Thema im Detail beschrieben: Oracle parallel query hints reference – part 5: PQ_DISTRIBUTE_WINDOW

Problem Lösung

Für unsere Zwecke genügt es zunächst festzuhalten, dass es drei Methoden gibt, wie ein Window Sort parallelisiert werden kann.

Methode 3 ist die bisher verwendete Methode, Methode 1 und 2 sind neu in Version 12. Wenn Methode 2 verwendet wird, kann es zum oben beschriebenen Bug kommen.

Mein Kollege Andreas Schlögl hat einen Testcase erstellt und gezeigt, dass man mittels des neuen  PQ_DISTRIBUTE_WINDOW Hint den Bug umgehen kann, in dem man auf Methode 1 umstellt.

Den Code des Testcases finden Sie hier. Viel Spass beim ausprobieren!

rem ##################################
rem # Objects                        #
rem ##################################

alter session set optimizer_adaptive_plans = false;
alter system flush shared_pool;

drop table asc_dmy1;
drop table asc_dmy3;

create table asc_dmy1
parallel 8
as 
select 'AAA' f001
  from xmltable('1 to 300');
  
--note: this table has no parallel degree
create table asc_dmy3
as
select 'AAA' f001, 1 acc206
  from dual;

rem #############################################
rem # SORT then distribute by HASH (Bug)        #
rem #############################################  
/*
   leads to a HASH JOIN in Line 7, which imo must be a HASH JOIN BUFFERED (due to 2 active PX SENDs at 9 and 13) 
   This SQL hangs and never finishes 
   
   https://oracle-randolf.blogspot.com/2012/12/hash-join-buffered.html
   "At most one data distribution can be active at the same time"
   
   "Since it doesn't seem to be supported to have two PX SEND operations active at the same time, 
    some artificial blocking operation needs to be introduced, in this case the HASH JOIN BUFFERED, 
	that first consumes the second row source completely before starting the actual probe phase"
*/
select /*+ pq_distribute_window(@"SEL$1" 2) */
       max(v.acc206) over (partition by v.f001) max_bew
  from asc_dmy3 v,
       asc_dmy1 e
 where e.f001 = v.f001
   and v.f001 = e.f001;  

/*   
-----------------------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name     | E-Rows |E-Bytes| Cost (%CPU)| E-Time   |    TQ  |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |          |      1 |   419 |     6  (17)| 00:00:01 |        |      |            |
|   1 |  PX COORDINATOR              |          |        |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)        | :TQ10003 |      1 |   419 |     6  (17)| 00:00:01 |  Q1,03 | P->S | QC (RAND)  |
|   3 |    WINDOW CONSOLIDATOR BUFFER|          |      1 |   419 |     6  (17)| 00:00:01 |  Q1,03 | PCWP |            |
|   4 |     PX RECEIVE               |          |      1 |   419 |     6  (17)| 00:00:01 |  Q1,03 | PCWP |            |
|   5 |      PX SEND HASH            | :TQ10002 |      1 |   419 |     6  (17)| 00:00:01 |  Q1,02 | P->P | HASH       |
|   6 |       WINDOW SORT            |          |      1 |   419 |     6  (17)| 00:00:01 |  Q1,02 | PCWP |            |
|*  7 |        HASH JOIN             |          |      1 |   419 |     5   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|   8 |         PX RECEIVE           |          |      1 |   415 |     3   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|   9 |          PX SEND HASH        | :TQ10000 |      1 |   415 |     3   (0)| 00:00:01 |  Q1,00 | S->P | HASH       |
|  10 |           PX SELECTOR        |          |        |       |            |          |  Q1,00 | SCWC |            |
|  11 |            TABLE ACCESS FULL | ASC_DMY3 |      1 |   415 |     3   (0)| 00:00:01 |  Q1,00 | SCWP |            |
|  12 |         PX RECEIVE           |          |    300 |  1200 |     2   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|  13 |          PX SEND HASH        | :TQ10001 |    300 |  1200 |     2   (0)| 00:00:01 |  Q1,01 | P->P | HASH       |
|  14 |           PX BLOCK ITERATOR  |          |    300 |  1200 |     2   (0)| 00:00:01 |  Q1,01 | PCWC |            |
|  15 |            TABLE ACCESS FULL | ASC_DMY1 |    300 |  1200 |     2   (0)| 00:00:01 |  Q1,01 | PCWP |            |
-----------------------------------------------------------------------------------------------------------------------   
*/

rem #############################################
rem # distribute by HASH then SORT  (Success)   #
rem #############################################  
/*
   leads to a HASH JOIN *BUFFERED* in Line 6, which is inevitably necessary imo
   This SQL finishes immediately
*/ 
select /*+ pq_distribute_window(@"SEL$1" 1) */
       max(v.acc206) over (partition by v.f001) max_bew
  from asc_dmy3 v,
       asc_dmy1 e
 where e.f001 = v.f001
   and v.f001 = e.f001;    

/*
------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                  | Name     | E-Rows |E-Bytes| Cost (%CPU)| E-Time   |    TQ  |IN-OUT| PQ Distrib |  OMem |  1Mem |  O/1/M   |
------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |          |        |       |     6 (100)|          |        |      |            |       |       |          |
|   1 |  PX COORDINATOR            |          |        |       |            |          |        |      |            | 73728 | 73728 |          |
|   2 |   PX SEND QC (RANDOM)      | :TQ10003 |      1 |   419 |     6  (17)| 00:00:01 |  Q1,03 | P->S | QC (RAND)  |       |       |          |
|   3 |    WINDOW SORT             |          |      1 |   419 |     6  (17)| 00:00:01 |  Q1,03 | PCWP |            | 20480 | 20480 |     8/0/0|
|   4 |     PX RECEIVE             |          |      1 |   419 |     5   (0)| 00:00:01 |  Q1,03 | PCWP |            |       |       |          |
|   5 |      PX SEND HASH          | :TQ10002 |      1 |   419 |     5   (0)| 00:00:01 |  Q1,02 | P->P | HASH       |       |       |          |
|*  6 |       HASH JOIN BUFFERED   |          |      1 |   419 |     5   (0)| 00:00:01 |  Q1,02 | PCWP |            |  3400K|  3091K|     8/0/0| 
|   7 |        PX RECEIVE          |          |      1 |   415 |     3   (0)| 00:00:01 |  Q1,02 | PCWP |            |       |       |          |
|   8 |         PX SEND HASH       | :TQ10000 |      1 |   415 |     3   (0)| 00:00:01 |  Q1,00 | S->P | HASH       |       |       |          |
|   9 |          PX SELECTOR       |          |        |       |            |          |  Q1,00 | SCWC |            |       |       |          |
|  10 |           TABLE ACCESS FULL| ASC_DMY3 |      1 |   415 |     3   (0)| 00:00:01 |  Q1,00 | SCWP |            |       |       |          |
|  11 |        PX RECEIVE          |          |    300 |  1200 |     2   (0)| 00:00:01 |  Q1,02 | PCWP |            |       |       |          |
|  12 |         PX SEND HASH       | :TQ10001 |    300 |  1200 |     2   (0)| 00:00:01 |  Q1,01 | P->P | HASH       |       |       |          |
|  13 |          PX BLOCK ITERATOR |          |    300 |  1200 |     2   (0)| 00:00:01 |  Q1,01 | PCWC |            |       |       |          |
|* 14 |           TABLE ACCESS FULL| ASC_DMY1 |    300 |  1200 |     2   (0)| 00:00:01 |  Q1,01 | PCWP |            |       |       |          |
------------------------------------------------------------------------------------------------------------------------------------------------
*/

ORACLE Datenbank Performance Tuning. Ein Überblick

In unserer Video-Serie „Kurz&Knackig“ sprechen wir mit unserem Kollegen  Lothar Flatz, der als Oracle Performance Architekt in zahlreichen Tuning-Projekten große Erfolge erzielen konnte.

Als unser ausgewiesener TOP-Experte im Bereich Performance Tuning wird er gerufen, um die Effizienz von langsamen Applikationen wesentlich zu steigern.

13min Kurz-Interview zum Thema Oracle Datenbank Performance Tuning

Vorteile von Code-Tuning vs. Hardware

Während bei Performance Problemen Investitionen in Hardware in den meisten Fällen nur einen Wirkungsfaktor im einstelligen Bereich aufweisen, können Verbesserungen im Code eine Effizienzsteigerung um einen vielfachen Faktor bewirken.

Beim Code-Tuning wird das verursachende Problem in der Applikation aufgespürt und beseitigt.
Im Gegensatz dazu bleibt beim Hardware-Tuning das Problem im Code bestehen, wodurch so gut wie immer das Problem zu einem späteren Zeitpunkt wiederholt auftritt.  

In der Regel ist Code-Tuning noch dazu deutlich preiswerter als ein Hardware-Investment und auch in kürzerer Zeit umgesetzt.

Vorträge und Einblicke

Lothar ist „Oracle ACE“ und „Oak Table Member“ und neben seiner Tätigkeit bei uns als Oracle Performance Architekt ein viel gefragter Redner auf Oracle User Konferenzen im deutschsprachigen- und europäischen Raum.

Bei seinen kurzweiligen Vorträgen lässt er seine Expertise zum Thema Performance Optimierung auf unterhaltsame Weise einfließen.

Fragen & Antworten

Falls Sie Fragen zum Thema Datenbank Performance Tuning haben, nutzen Sie bitte unser Kontaktformular (Link).

 

Dimensio Performance Vergleich

Dimensio – der Datenbankturbo

Die neue Softwarelösung Dimensio beschleunigt die Antwortzeiten bestehender Datenbanksysteme durch einen mehrdimensionalen, semantischen Index auf einen Bruchteil der Zeit, ohne direkt in die Datenbank oder in die Applikation einzugreifen.

Aufgrund stetig wachsender Datenmengen geraten Unternehmen bei der Analyse der gesammelten Daten immer öfter an die Grenze der Möglichkeiten ihrer IT Landschaft. Dies führt zwangsläufig dazu, dass in bestehenden Anwendungen die Ausführung geschäftskritischer Auswertungen oft viele Stunden bis Tage in Anspruch nimmt.

In vielen Fällen wird versucht dieses Performanceproblem durch neue, leistungsstärkere Hardware in den Griff zu bekommen. Dieser Ansatz führt aber nur zu einem Verschieben der Grenzen ohne die eigentliche Problematik zu lösen und kann neben den zusätzlichen Betriebskosten auch eine wesentliche Erhöhung der Lizenzkosten für die Datenbanksoftware notwendig machen.

Klaus-Michael Hatzinger von DBConcepts ist von der Leistung von Dimensio begeistert und sieht für viele leidgeprüfte Anwender von altgedienten Anwendungen ein Ende der langen Wartezeiten gekommen.

„Dimensio erstellt einen mehrdimensionalen, semantischen Index. Das Verfahren verwendet künstliche neuronale Netze zur parameterlosen Klassifikation und ist dadurch in der Lage, die Datensätze in einer Datenbank gemäß deren inhaltlichem Zusammenhang zu gruppieren und in einer sogenannten V-Baum Struktur zu verwalten. erklärt Klaus-Michael Hatzinger die technische Besonderheit der Lösung.

„Dabei erkennt Dimensio alle für seinen Index passenden Abfragen, ergänzt diese durch die eindeutigen Primärschlüssel der betroffenen Datensätze und gibt sie an die Datenbank weiter“, führt der Datenbankexperte und Geschäftsführer von DBConcepts weiter aus.

„Die Datenbank muss nur noch einen Bruchteil der Datensätze auswählen und benötigt daher auch wesentlich weniger Zeit. Komplexe Abfragen werden nur noch ein Tausendstel der Zeit benötigen und ihren Schrecken verlieren“, ist sich Klaus-Michael Hatzinger sicher.

„Die Integration von Dimensio erfolgt auf Netzwerkebene und ist mit sehr geringem Aufwand verbunden. Befürchtungen hinsichtlich langwieriger Projektlaufzeiten oder eventueller Garantieverletzungen sind mit dieser Methode unbegründet“, freut sich Klaus-Michael Hatzinger über die einfache und rasche Möglichkeit die Software zu implementieren.

Dimensio kann neben Oracle auch für jede andere Datenbank unabhängig vom Hersteller eingesetzt werden. Selbst kundenspezifische Speicherlösungen oder auch Flat Files sind möglich.

Zahlreiche Beispiele aus der Praxis belegen die hohen Erwartungen, die an die Dimensio gestellt werden können. Bei einem Anwendungsbeispiel in der Automobilindustrie wurde ein wöchentlicher Materialnachweis mit circa 4.000 Anfragen erstellt. Der Datenbestand umfasste rund 25.000 Produkte mit ungefähr 250 Dimensionen. Die bisher eingesetzte Lösung benötigte am Mainframe in Summe mehr als sechs Stunden Laufzeit, die auf einem einfachen Desktop PC eingesetzte Dimensio Lösung konnte das gleiche Ergebnis bereits in drei Minuten und zwanzig Sekunden liefern.

Wie bei allen großen Performance Sprüngen könnte Dimensio durch den erheblichen Zeitgewinn bei vielen Anwendern die Begehrlichkeiten nach immer komplexeren Abfragen erst so richtig anfeuern.