Ändern des Passwort Hash Algorithmus in PostgreSQL

PostgreSQL: Ändern des Passwort Hash Algorithmus

Standardmäßig verwendet PostgreSQL den MD5-Algorithmus, um Passwörter von Benutzern in der Datenbank abzulegen.

Da MD5 mittlerweile nicht mehr als all zu sicher gilt, wird empfohlen, andere Hash Algorithmen für die Passwortablage zu verwenden.
PostgreSQL hat dazu ab Version 10 die Möglichkeit geschaffen, auf den SCRAM-SHA-256-Algorithmus umzustellen.

Wichtig ist, wie bereits erwähnt, dass die PostgreSQL Datenbank Version 10 oder höher ist, sowie, dass die Programme, die auf die Datenbank zugreifen, diesen Algorithmus unterstützen.

Sind die Bedingungen erfüllt, kann man den Default-Algorithmus in der Datenbankkonfiguration umstellen.

Dies muss an zwei Stellen getan werden:

1.       In der postgresql.conf (per Default im Verzeichnis /etc/postgresql/10/main/postgresql.conf) muss der Parameter password_encryption auf ’scram-sha-256′ gesetzt werden.
Die resultierende Zeile muss in der postgresql.conf folgendermaßen aussehen:
password_encryption = ’scram-sha-256′

2.  Außerdem muss in der pg_hba.conf (per Default im Verzeichnis /etc/postgresql/10/main/pg_hba.conf) der gewünschte Algorithmus für die gewünschte Socketmethode angepasst werden. Die Konfiguration befindet sich am Ende der Datei, für IPv4 müsste die Zeile danach so aussehen:
# IPv4 local connections:

host    all             all             127.0.0.1/32            scram-sha-256

Ist dies getan, werden alle zukünftigen Passwörter nun mit dem SCRAM-SHA-256-Algorithmus gehashed.

WICHTIG: Alle bereits gesetzten Passwörter von Datenbankbenutzern bleiben in dem zum jeweiligen Zeitpunkt konfigurierten Hash-Algorithmus bestehen.

Wenn also bereits vorhandene User in der Datenbank existieren, müssen die Passwörter dieser User neu gesetzt werden, um mit dem neuen Hashalgorithmus abgespeichert zu werden.

Ansonsten würde ein Login via PSQL auf die Datenbank den Hashwert des eingegebenen Passwortes mittels SCRAM-SHA-256 ermitteln und diesen Wert mit dem MD5-gehashten abgelegten Passwort in der Datenbank vergleichen.
Da diese Werte nicht übereinstimmen, würde der Zugriff verweigert werden.

NEU: Java Delvelopment Kit Java SE 8u211 / Java SE 8u212 verfügbar

Die beiden Java Delvelopment Kit Java SE 8u211 / Java SE 8u212 sind seit kurzer Zeit erhältlich und enthalten wichtige Fehlerbehebungen.

Oracle empfiehlt dringend, dass alle Java SE 8-Benutzer ein Upgrade auf diese Version durchführen.

Leider ist dieses Update für Unternehmen bereits mit dem Erwerb der Java Subscription verbunden. Details zur kostenpflichtigen Java Subscription finden Sie hier.

Für Unternehmen ist es jetzt an der Zeit, eine sinnvolle Strategie für den Umgang mit Java zu haben um die Sicherheit der Applikationen zu gewährleisten.

Die auf der Hand liegenden Möglichkeiten wie…

  • Umstieg auf OpenJDK
  • Isolierung der Applikation
  • Erwerb der Subscription

…sollten nun gemeinsam mit den Applikationsverantwortlichen evaluiert werden.

Wie wichtig die Fehlerbehebungen sind werden die nächsten Monate zeigen, indem es Meldungen über Hacks gibt – oder auch nicht.

Auf jeden Fall bleibt es spannend!

Oracle 19c SE2 ohne RAC Funktionalität

Das (faule) Oracle19c SE2 Osterei – Standard Edition 2 ohne RAC

Die neue Oracle19c Datenbank ist gleichzeitig die Long Term Support Release bzw. das Terminal Patch Set für die Oracle Datenbank Version 12.2.

Anders als bei der Annual Release Oracle18c (2 Jahre ab Release von Oracle19c) wird es für diese Version Support bis zum 31. März 2026 geben.

Oracle 19c SE2 ohne RAC

Ein Blick in den aktuellen Oracle Lizenz Guide der Long Term Version 19c bringt Ernüchterung – der Einsatz von Oracle Real Application Clusters (RAC) ist ab Oracle19c in der Standard Edition 2 (SE2) nicht mehr erlaubt.

Oracle SE2 RAC Kunden, die ein Software Upgrade auf Oracle19c durchführen, dürfen dann die RAC Funktionalität nicht mehr einsetzen.

SE2 RAC Kunden, die bereits auf der wesentlich kürzeren Annual Release 18c sind, stehen damit auf einem bereits sehr kurzen Abstellgleis für Standard Edition 2 RAC.

Unklare Strategie

Welche Oracle Strategie hinter dieser Entscheidung steckt ist unklar.

Eventuell will man die Oracle Kunden mit sanftem Druck in die Oracle Autonomous Database Cloud bewegen indem man die On-Premise Lösungen für die Kunden nicht unmöglich, aber zunehmend unbequem macht.

Ob solch eine Strategie aufgehen würde ist fraglich, weil Oracle damit den Kunden wieder ein klares Zeichen der Unberechenbarkeit gäbe.

Die Kunden verlieren zunehmend das Vertrauen in die Kontinuität der Lizenzgewährung des Herstellers und der eine oder andere wird sich wohl oder übel dadurch nach Alternativen zu Oracle umsehen.

Offene Fragen aus lizenzrechtlicher Sicht

Aus lizenzrechtlicher Sicht ist diese Entwicklung ebenfalls fragwürdig.

Aus unserer Sicht stellen sich folgende Fragen bzw. Überlegungen:
Oracle SE2 Bestandskunden haben mit Oracle in der Vergangenheit vertraglich (Oracle TOMA und LDR – Lizenz Definitionen und Regeln) vereinbart, dass die Verwendung von Oracle RAC in der SE2 Lizenz unter definierten Regeln erlaubt ist!

Die Version 19c ist aber kein neues Produkt mit neuem Oracle LDR Vertrag, somit müsste der damals akzeptierte LDR gelten und die Verwendung von SE2 RAC für alle Bestandskunden weiterhin möglich sein.
Auch dann, wenn der aktuelle 19c Lizenz-Guide es für Neukunden nicht mehr vorsieht.

Fazit

Die obigen Schlussfolgerungen und Überlegungen basieren auf dem aktuellen Stand der uns zugänglichen Informationen.
Ausgelöst durch ein simples „N“ wo im Lizenz-Guide der Datenbank früher ein „Y“ stand.

Derzeit ist noch vieles unklar und es gilt abzuwarten, wie Oracle diese doch sehr eingreifende Änderung letztendlich präsentieren wird.

APEX-Version 19.1 veröffentlicht

Am 29. März 2019 wurde die angekündigte APEX-Version 19.1 von Joel Kallmann offiziell vorgestellt und zum Download freigegeben.

Gegenüber dem letzten Blog-Eintrag ist vor allem ein weiteres Feature erwähnenswert: Die Möglichkeit Daten aus unterschiedlichen Datei-Formaten direkt zu integrieren.

Deklarativ steht diese Möglichkeit vorerst nur über den SQL Workshop im Data Workshop innerhalb der Utilities zur Verfügung.
Wie genau dieser Prozess ausschaut hat Carsten Czarski in seinem Blog-Eintrag Quick and Easy Data Loading with APEX 19.1 vorgestellt.

Der für das Parsen und den Import verwendete Code steht Entwicklern allerdings auch in Form des Packages APEX_DATA_PARSER zur Verfügung – und kann damit beispielsweise in eigene Applikationsteile integriert werden. Auch für die Nutzung dieses Packages gibt es bereits einen entsprechenden Blog-Beitrag.

Außerdem wurde mittlerweile in einem Statement of Direction ein Ausblick auf die in APEX 19.2 zu erwartenden Features gewährt.

Neben der Erweiterung der neuen Daten-Parser- und -Importe werden vor allem verbesserte Popup LOVs und erweiterte Shared LOVs die Usability für Endanwender erhöhen – und auch die angekündigte Überarbeitung der Filtermöglichkeiten von Reports wird vor allem unter all jenen Applikations Usern Freude verursachen, die SQL nicht oder nur eingeschränkt beherrschen und daher mit den aktuellen Möglichkeiten beispielsweise eines Interactive Reports wenig anfangen können.

 

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 |            |       |       |          |
------------------------------------------------------------------------------------------------------------------------------------------------
*/

DBConcepts Business Breakfast 2019 – Jetzt anmelden

Es ist uns wieder gelungen, sehr interessante und kurzweilige Vorträge mit folgenden Titeln für unser Business Breakfast zu bündeln:

  • 24 – 7 – 365 Verfügbarkeit für Unternehmen mit Veeam
  • Das Sherlock Holmes SQL Mystery
  • Wann lohnt sich der Einsatz von Postgres/EnterpriseDB?
  • Datenbank Evangelist challenges Autonomous Database
  • So messen Sie die Java Nutzung in Ihrem Unternehmen

Termine & Locations:
02. April, Dornbirn
03. April, Innsbruck
04. April, Salzburg
09. April, Linz
10. April, Graz
11. April, Wien

Bitte melden Sie sich so bald wie möglich an, da nur eine sehr begrenzte Anzahl an Plätzen zur Verfügung steht und bereits nach der „Save the Date“ Aussendung viele Anmeldungen erfolgt sind.

Alle weiteren Details sowie die Excerpts zu den Vorträgen und die Anmeldung finden Sie auf der Webseite des Events.

 

Oracle Apex 19.1 Early Adopter

Oracle APEX 19.1 – Early Adopter

Eine gute Nachricht für alle APEX-Fans, die ihre Software aktuell halten wollen und/oder auf neue Features warten:
Seit kurzem gibt es die Early Adopter von APEX 19.1. Unter 19.1 Early Adopter – Features gibt es erste Informationen zu den kommenden Inhalten, wie etwa:

  • REST Enabled Forms (Anzeigen und Bearbeiten von Daten aus Remote-Quellen),
  • Upgrades von jQuery und JET Charts,
  • Deklarative Erweiterungen des Interactive Grid oder auch
  • ein dunkles Layout für die APEX-Entwicklungsumgebung.

Aktuell gibt es noch keinen Download, sodass man sich die Änderungen momentan in einem Workspace bei Oracle anschauen muss. Und auch die verfügbaren Informationen sind noch etwas spärlich – werden aber üblicherweise sukzessive erweitert.

Oracle Java Subscription

Oracle Java Subscription – was ist das und wer ist davon betroffen?

Für kommerzielle Anwender von Oracle Java ist ab Jänner 2019 für Updates und Support eine kostenpflichtige Subscription notwendig.

Die Java SE Subscription beinhaltet den Premier Support für aktuelle und frühere Java SE Versionen, sowie kommerzieller Funktionen und Tools wie die Java Advanced Management Console.

10min Video: Anworten auf die wichtigsten Fragen

Für einen kurzen Überblick zum Thema „Oracle Java Subscription – was ist das und wer ist davon betroffen?“ inklusive Antworten auf die wichtigsten Fragen informieren wir in folgendem 10-minütigen Video:

Weiterführender Artikel: Oracle JAVA ab 2019 für kommerzielle Nutzung lizenzpflichtig

Noch Fragen?

Falls Sie noch Fragen zu diesem Thema haben oder ein Angebot erhalten möchten, stehen wir Ihnen gerne zur Verfügung.
Bitte nutzen Sie folgendes Kontaktformular.

Kontaktformular

2 + 1 = ?

select * from dual in Postgres

Select * from DUAL in Postgres

Wann immer ein simpler Wert per SQL gesetzt oder abgefragt werden soll, wird die Pseudotabelle DUAL dafür herangezogen.

Einer der populärsten Einsatzzwecke dafür war bis Oracle Version 10 die Nutzung von Sequences in PL/SQL.
Sequences mussten in diesen Oracle Versionen immer über eine SQL-Query abgefragt werden, der folgende Code funktionierte:

select my_seq.nextval from dual;

Der folgende Code funktionierte allerdings nicht:

v_myvar := my_seq.nextval;

Die DUAL Tabelle ist eine tatsächlich existierende physische Tabelle in der Datenbank welche im SYS-Schema liegt.

Sie verfügt über eine Spalte mit der Bezeichnung „DUMMY“ welche den Datentyp VARCHAR2(1) hat.
Die Zeile hat eine Zeile mit dem Wert ‚X‘, das kann mit folgendem Statment abgefragt werden:

select * from dual;

Theoretisch kann diese Tabelle auch verändert werden.
Natürlich rät Oracle streng davon ab das zu tun da eine Fülle an unvorhersehbaren Fehlern entstehen kann und wird.

Das grundlegende Verhalten könnte auch mit einer eigenen 1-Spalten-1-Zeilen-Tabelle simuliert werden, doch der Oracle Optimizer erkennt DUAL auch als Keyword und verfährt beim Execution Plan dann entsprechend.

Wie läuft das nun in Postgres?

Wenn Sie Code von Oracle auf Postgres portieren dann werden sie feststellen, dass das Statement von oben …

select 1 from dual;

…nicht funktioniert!
Postgres kennt keine DUAL Tabelle.

Nun gibt es zwei Möglichkeiten, je nachdem was die Ausgangslage und das Ziel ist:

  1. Man legt die DUAL Tabelle in Postgres als „Dummy“-View an
  2. Man passt das Statement an

Die erste Variante ist simpel und vor allem bei größeren Portierungen empfohlen, wo mehrere dutzend oder sogar hunderte Statements angepasst werden müssten.

Die zweite Variante ist bei wenigen Statements zu empfehlen, da sie dem Postgres Standard entspricht. Das entsprechende Statement in Postgres würde dann wie folgt aussehen:

select 1

Die komplette FROM-Klausel verschwindet hier!

Postgres macht durch diese Syntax die Verwendung einer Dummy-Tabelle unnötig um einen einzelnen Wert per SQL zu setzen oder abzufragen (z.B. auch das SYSDATE).

Das ist deutlich simpler.

 

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).