Oracle Statspack verbessern: Schnellere Snapshots – Teil1

Oracle Statspack verbessern: Schnellere Snapshots – Teil1

Ausgangslage: Langsamer Statspack Snapshot

Auf verschiedenen Standard Edition Datenbanken sieht man immer wieder den Statspack Snapshot lange laufen.

Dies ist für mich als Consultant sehr unangenehm.
Oft muss ich den Kunden sagen, dass das Statspack auf einer Standard Edition Datenbank unverzichtbar ist.

Und dann sieht mein Kunde, wie der Statspack Snapshot minutenlang einen der kostbaren, limitierten Cores blockiert.

Ich beschloss, etwas dagegen zu unternehmen.
Bei näherer Betrachtung erkennt man zwei Statements, die die Datenbank belasten.

In erster Linie ist dies:

INSERT INTO stats$sql_plan

Aber auch dieser Befehl läuft lange:

INSERT INTO stats$seg_stat

Grundsätzliches: Hints im Statspack

Man hört oft, dass man Hints so wenig wie möglich machen soll und lieber andere Mittel verwenden soll, um den Optimizer zu steuern.

Gute Statistiken zum Beispiel.
Ich bin auch dieser Meinung.
Allerdings gibt es auch Ausnahmen.

Bei Tools wie Statspack kann man sich nicht darauf verlassen, dass die Statistiken immer aktuell sind.

Es werden auch interne Tabellen X$ verwendet. Nicht jeder DBA macht fixed table stats und selbst wenn, schwanken diese Statistiken oft stark.

Ein Tool wie Statspack muss immer zuverlässig laufen.
Glücklicherweise ist bei den zwei Statspack Queries die wir betrachten werden, ziemlich klar wie der Plan auszusehen hat.

Hints stellen also kein großes Risiko dar. Jedoch habe ich dennoch so wenig wie möglich festgelegt.

Statement : INSERT INTO stats$sql_plan

Das Problem wird in der MOS Note 2182680.1 behandelt.

In dieser Note wird vorgeschlagen eine alternative Implementation des Statspack Package (SCPPKG.SQL) herunter zu laden und zu implementieren.

Diese Implementation enthält einen geänderten Hint, den ich im folgenden Beispiel mit Rot hervorgehoben habe.

Vom ganzen Insert Statement zeige ich nur den SELECT Teil, weil der Eintrag sonst zu lange wird.
Auch vom Select Teil habe ich die Liste der Spalten gekürzt, damit der Code Teil übersichtlich bleibt.

SELECT /*+ no_merge(new_plan) leading(new_plan s sp) use_nl(s) use_nl(sp) */
new_plan.plan_hash_value,
sp.id,
MAX(sp.operation),
MAX(sp.options), 
. . .
MAX(new_plan.snap_id)
FROM
(
SELECT /*+ index(spu) */
spu.plan_hash_value,
spu.hash_value hash_value,
spu.address address,
spu.text_subset text_subset,
spu.snap_id snap_id
FROM
stats$sql_plan_usage spu
WHERE
spu.snap_id = :b3
AND spu.dbid = :b2
AND spu.instance_number = :b1
AND NOT EXISTS (
SELECT /*+ nl_aj */
*
FROM
stats$sql_plan ssp
WHERE
ssp.plan_hash_value = spu.plan_hash_value
)
) new_plan,

Wie unschwer zu erkennen ist, befinden sie relevanten Suchkriterien auf der Tabelle stats$sql_plan_usage mit dem Alias spu.

Es ist also wichtig, dass im Execution Plan mit dem Lesen dieser Tabelle begonnen wird.

Der Hint Leading(new_plan .. ist also folgerichtig.

Das Problem besteht jedoch darin, dass new_plan keine Tabelle, sondern der Name einer Unterfrage ist.
Obwohl Version 19c den Hint als korrekt meldet, wird er in tieferen Versionen oft nicht akzeptiert.

Der Alias für den Hint wäre eigentlich spu, jedoch ist dieser in der Hauptabfrage nicht zugänglich, weil die Tabelle stats$sql_plan_usage in einer Unterabfrage angesprochen wird. (Achtung: wenn ein Alias vorhanden ist, muss der Alias im Hint angegeben werden und nicht der Tabelle Name.)

Diese Unterabfrage bildet einen eigenen Queryblock und dessen Inhalt ist von der Hauptabfrage nicht direkt referenzierbar.

In der Tat zeigt der Plan des Insert Befehles, dass der Leading Hint ignoriert wird.

Hier ein Beispiel von einem unserer Kunden:

Operation | Name | A-Time 
-------------------------------------------------------------------------------
INSERT STATEMENT | |00:05:07.72
LOAD TABLE CONVENTIONAL | STATS$SQL_PLAN |00:05:07.72
SORT GROUP BY | |00:05:07.72
NESTED LOOPS | |00:05:07.71
NESTED LOOPS | |00:05:07.71
FIXED TABLE FULL | X$KGLCURSOR_CHILD |00:00:02.30
VIEW PUSHED PREDICATE | |00:05:05.33
NESTED LOOPS ANTI | |00:05:05.23
TABLE ACCESS BY INDEX ROWID BATCHED| STATS$SQL_PLAN_USAGE |00:03:42.53
INDEX RANGE SCAN | STATS$SQL_PLAN_USAGE_PK|00:02:22.49
INDEX RANGE SCAN | STATS$SQL_PLAN_PK |00:01:03.19
FIXED TABLE FIXED INDEX | X$KQLFXPL (ind:3) |00:00:00.01
-------------------------------------------------------------------------------

Wie man sieht, benötigt der Insert 5 Minuten und 8 Sekunden.

Queryblöcke

Um eine Queryblock in der Hauptabfrage referenzieren zu können, muss man dem untergeordneten Queryblock mit dem QB_NAME hint einen Namen geben.

Dann kann man die Tabellen des untergeordneten Queryblocks mittels „tabellenalias@queryblock“ ansprechen.
Dies ist ein dokumentiertes Vorgehen und sollte in allen Versionen stabil funktionieren.

In unserem Beispiel sieht das so aus:

SELECT /*+ leading(spu@np ssp@sq s sp) */
new_plan.plan_hash_value,
sp.id,
...
MAX(new_plan.snap_id)
FROM
(
SELECT /*+ QB_NAME(NP) */
spu.plan_hash_value,
spu.hash_value hash_value,
spu.address address,
spu.text_subset text_subset,
spu.snap_id snap_id
FROM
stats$sql_plan_usage spu
WHERE
spu.snap_id = :b3
AND spu.dbid = :b2
AND spu.instance_number = :b1
AND NOT EXISTS (
SELECT /*+ QB_NAME(SQ) */
*
FROM
stats$sql_plan ssp
WHERE
ssp.plan_hash_value = spu.plan_hash_value
)
) new_plan,

Diesmal hält der Optimzer sich an die Hints, das Ergebnis sieht wie folgt aus:

--------------------------------------------------------------------------------
Operation | Name | A-Time
--------------------------------------------------------------------------------
INSERT STATEMENT | |00:00:00.05
LOAD TABLE CONVENTIONAL | STATS$SQL_PLAN |00:00:00.05
SORT GROUP BY | |00:00:00.05
NESTED LOOPS | |00:00:00.05
NESTED LOOPS | |00:00:00.04
HASH JOIN ANTI | |00:00:00.04
TABLE ACCESS BY INDEX ROWID BATCHED| STATS$SQL_PLAN_USAGE |00:00:00.01
INDEX RANGE SCAN | STATS$SQL_PLAN_USAGE_PK |00:00:00.01
INDEX FAST FULL SCAN | STATS$SQL_PLAN_PK |00:00:00.01
FIXED TABLE FIXED INDEX | X$KGLCURSOR_CHILD (ind:1)|00:00:00.01
FIXED TABLE FIXED INDEX | X$KQLFXPL (ind:3) |00:00:00.01
--------------------------------------------------------------------------------

Also 5 hundertstel Sekunden statt 5 Minuten.

Das ist über 6000x schneller und kann sich sehen lassen.

Nachdem ich die Hints gefunden hatte, habe ich eine Sicherheitskopie des Scriptes SCPPKG.SQL angelegt und den neuen Hint in das Package kopiert.
Durch den Aufruf des Scriptes wurde das neue Package dann installiert.

Statement: INSERT INTO stats$seg_stat

Wie sieht nun das zweite Insert aus?

Diesmal gibt es keine MOS Note.

Auch hier zeige ich wieder den sql code, mit den hervorgehobenen Hints:

SELECT /*+ ordered use_nl(s1.gv$segstat.X$KSOLSFTS) */
:b3,
:b2,
...
SUM(decode(s1.statistic_name, 'row lock waits', value, 0))
FROM
v$segstat s1
WHERE
( s1.dataobj#,
s1.obj#,
s1.ts# ) IN (
SELECT /*+ unnest */
s2.dataobj#,
s2.obj#,
s2.ts#
FROM
v$segstat s2
WHERE
s2.obj# > 0
AND s2.obj# < 4254950912
AND ( decode(s2.statistic_name, 'logical reads', s2.value, 0) > :b10
OR decode(s2.statistic_name, 'physical reads', s2.value, 0) > :b9
OR decode(s2.statistic_name, 'buffer busy waits', s2.value, 0) > :b8
OR decode(s2.statistic_name, 'row lock waits', s2.value, 0) > :b7
OR decode(s2.statistic_name, 'ITL waits', s2.value, 0) > :b6
OR decode(s2.statistic_name, 'gc cr blocks received', s2.value, 0) > :b5
OR decode(s2.statistic_name, 'gc current blocks received', s2.value, 0) > :b4 )
)
GROUP BY
s1.ts#,
s1.obj#,
s1.dataobj#
;

Wieder sieht man hier ein sehr ungewöhnliches Hint Format.

Wieder meldet aber die Report Funktion in 19c keinen Fehler und in unseren Test hat der Optimizer den Hint befolgt.

Jedoch bin ich diesmal mit der Wirkung des Hints nicht einverstanden.

Sehen wir uns dazu Laufzeitstatitiken an:

------------------------------------------------------------------------------
Id | Operation | Name | Starts | A-Rows | A-Time
------------------------------------------------------------------------------
0 | INSERT STATEMENT | | 1 | 0 |00:01:16.83
1 | LOAD TABLE CONVENTIONAL | STATS$SEG_STAT| 1 | 0 |00:01:16.83
2 | HASH GROUP BY | | 1 | 746 |00:01:16.83
3 | NESTED LOOPS | | 1 | 19396 |00:01:16.81
4 | VIEW | VW_NSO_1 | 1 | 747 |00:00:00.19
5 | SORT UNIQUE | | 1 | 747 |00:00:00.19
6 | FIXED TABLE FULL | X$KSOLSFTS | 1 | 814 |00:00:00.19
7 | FIXED TABLE FULL | X$KSOLSFTS | 747 | 19396 |00:01:16.62
------------------------------------------------------------------------------

Immerhin läuft auch dieser Befehl noch über eine Minute.

Die Zeit fällt fast zu 100% in der Zeile 7 an und zwar deshalb, weil die Zeile 747 Mal wiederholt wird.

Ein Hash join wäre hier wesentlich Laufzeit stabiler.
Der Nested Loop join hat Vorteile bei kleinen Datenmengen.

Allerdings spielt es ohnehin keine Rolle, welchen Join man nimmt, bei kleinen Datenmengen sind alle schnell.

Ich habe also den use_nl hint gegen einen use_hash hint getauscht.

Das ist das Resultat:

-------------------------------------------------------------------------------
Id | Operation | Name | Starts | A-Rows | A-Time
-------------------------------------------------------------------------------
0 | INSERT STATEMENT | | 1 | 0 |00:00:00.39
1 | LOAD TABLE CONVENTIONAL | STATS$SEG_STAT | 1 | 0 |00:00:00.39
2 | HASH GROUP BY | | 1 | 748 |00:00:00.39
3 | HASH JOIN | | 1 | 19448 |00:00:00.38
4 | VIEW | VW_NSO_1 | 1 | 748 |00:00:00.19
5 | SORT UNIQUE | | 1 | 748 |00:00:00.19
6 | FIXED TABLE FULL | X$KSOLSFTS | 1 | 815 |00:00:00.19
7 | FIXED TABLE FULL | X$KSOLSFTS | 1 | 390K|00:00:00.13
-------------------------------------------------------------------------------

Insgesamt läuft der Snapshot jetzt in 6 Sekunden durch.

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.