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

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

 

Oracle Apex Dictionary

APEX_DICTIONARY – ein kleines (häufig unbekanntes) Helferlein

Irgendwann einmal kommt wohl jeder APEX-Entwickler an einen Punkt, an dem ihm die deklarativen Wizards innerhalb des Application Builders nicht mehr ausreichen.

Beispielsweise dann, wenn man eine ganze Reihe von Reports auf einer Page definiert hat, deren Inhalte man nun möglichst einfach exportieren will (die DSGVO lässt an dieser Stelle schön grüßen).

Wahrscheinlich hat auch jeder bis dahin einmal mitbekommen, dass APEX-Views gibt, die man zu diesem Zweck konsultieren kann – wenn man nur nicht ständig vergessen würde wie die Views heißen (bei aktuell deutlich über 100 Views aber auch nicht weiter verwunderlich).

In diesem Fall kann einem das Apex Dictionary helfen.

Selbst ein View funktioniert das Dictionary ähnlich wie der allgemeinere View DICT bzw. DICTIONARY – geht in der Funktionalität aber weiter. Wo das allgemeine Dictionary nur View-Namen und Kommentare enthält, stellt das APEX Dictionary einige sehr interessante zusätzliche Informationen zur Verfügung – Spaltennamen zum Beispiel oder den Namen des übergeordneten Views.

Das hat zwar zur Folge, dass man für eine einfache View-Suche…

SELECT *
FROM   apex_dictionary
WHERE  comment_type = 'View'

…absetzen oder zumindest einen Filter …

WHERE column_id = 0 

… verwenden sollte – ermöglicht andererseits in Verbindung mit den aufgelisteten Daten-Views selbst aber sehr einfache Möglichkeiten, um umfangreiche Qualitätssicherungs-Abfragen zu erststellen.

Die Suche nach Pages ohne Checksum Protection gerät so fast schon zum Kinderspiel.

Das APEX Dictionary ist übrigens auch im Application Builder selbst integriert und dort direkt in den Workspace Utilities zu finden.

Es kann auch nicht schaden, nach Erscheinen neuer APEX-Versionen einfach mal so einen Blick in das Apex Dictionary zu werfen um sich über Neuerungen zu informieren.

Von Version 5.0 zu 18.2 sind beispielsweise 32 neue Views hinzugekommen – primär für das Interactive Grid und die neuen Web-Service-Tools.

Oracle ZFS Einführungspromotion

Die Oracle ZFS Storage Appliance – Einführungspromotion

Die extrem schnelle Backup- und Restore-Appliance für Oracle EXADATA, Oracle PCA oder wahlweise auch als Online-Storage Erweiterung für Oracle Engineered Systems.

Die Oracle ZFS Storage Appliance bietet gegenüber anderen Lösungen unschlagbare Vorteile, wenn es darum geht, geschäftskritische Anwendungen zu beschleunigen, die Produktivität zu steigern und dabei gleichzeitig Ressourcen zu sparen, Risiken zu reduzieren und die Gesamtbetriebskosten (TCO) zu senken.

Von anspruchsvollen Oracle-Datenbankumgebungen, über große virtualisierte Umgebungen bis hin zu traditionellen Serverumgebungen spannen sich die empfohlenen Einsatzgebiete.

Maximale Performance

Profitieren Sie von der schnellen, vollständig auf Flash basierenden Performance dank des Hybrid Storage Pools für dynamische Workloads, von effizienter Konsolidierung und vielen einzigartigen Funktionen wie zum Beispiel der „Hybrid Columnar Compression“, oder dem einzigartigen „Oracle Intelligent Storage Protocol“, durch die Sie Ihre Oracle Datenbanken schneller denn je ausführen können und gleichzeitig einen besonders attraktiven TCO erzielen können

Konfigurationen

Die Oracle Oracle ZFS Storage ZS7-2 ist in den Konfigurationen „Mid-range“ und „High-End“ erhältlich.

Beide Konfigurationen sind wirtschaftlich überzeugende Enterprise-Speicherlösungen, die für hohe Workloads mit extrem hohen Leistungsanforderungen ausgelegt sind.

Im Backup Umfeld glänzt die Storage Appliance durch unterschiedliche Block basierende „Data Reduction“ Funktionen wie „Inline Compression“ oder „inline Deduplication“, transparent zur Applikation oder der eingesetzten Backup-Software.

Einführungspromotion

Ab sofort bis zum 27.Februar 2019 ist für die neue Generation ZS7 eine Einführungspromotion mit 40% Discount erhältlich.
Dafür gelten besonderen Bedingungen, über die wir Sie gerne persönlich informieren.

 

Video: Erfahrungen mit der Oracle Private Cloud Appliance -aka Oracle PCA

Aus unserer YouTube Serie:

Kurz&Knackig: Unsere Erfahrungen mit der Oracle Private Cloud Appliance.

10 Minuten Bericht über ein aktuelles Kunden-Projekt, bei dem wir als PCA – Implementierungspartner mitgewirkt haben.

Welche Vorteile und Einsatzgebiete sprechen für die Oracle Private Cloud Appliance.

Details zur Oracle PCA

Oracle Private Cloud Appliance ist ein konvergentes Infrastruktursystem, das entwickelt wurde um schnelle und effiziente Private Cloud Lösungen zu einem attrakiven Preis bereitzustellen.
Unabhängig davon, ob Kunden mit Linux-, Microsoft Windows- oder Oracle Solaris-Anwendungen arbeiten, unterstützt die Oracle PCA die Konsolidierung für eine Vielzahl von gemischten Workloads in mittleren bis großen Rechenzentren.

Weiterführende Informationen:

Oracle Private Cloud Appliance: Cloud-fähige Infrastruktur der Unternehmensklasse

Oracle Private Cloud Appliance Data Sheet download

 

Veranstaltung: Datenbank Performance Killer aufspüren und beseitigen

Vielleicht kennen Sie das: Ihre Datenbank wird ohne ersichtliche Gründe immer langsamer.
Die Nutzer beschweren sich über immer länger dauernde Abfragen?

In vielen Fällen sind die Gründe für Performance-Einbruche tief in der Datenbank-Logik versteckt, sodass auch Hardware Upgrades nur für kurze Zeit eine Verbesserung bringen können.

Oracle stellt mit dem Diagnostic Pack und Tuning Pack zwei sehr gute Tools zur Verfügung. Allerdings sind diese ausschließlich für die Enterprise Edition der Datenbank erhältlich und müssen analog zur Datenbank lizenziert werden.

Lernen Sie zwei sehr interessante Lösungen kennen

Quest hat seit vielen Jahren mit der Toad DBA Suite und mit Foglight zwei sehr beeindruckende Lösungen im Angebot, die auf allen Oracle Datenbank Editionen eingesetzt werden können und im Leistungsumfang das Diagnostic und Tuning Pack sogar übertreffen.

Noch dazu zu wesentlich geringeren Lizenzkosten!

In diesem Vortrag stellen wir gemeinsam mit einem Spezialisten von Quest die Stärken der beiden Lösungen Toad DBA Suite und Foglight im Detail vor.

Wir zeigen Ihnen, wie Sie damit Performance Probleme sehr einfach aufspüren, analysieren und beheben können, um Ihre Datenbank wieder auf die gewohnte Geschwindigkeit zu beschleunigen.

Details zur Veranstaltung

Ort der Veranstaltung: DBconcepts GmbH, Lassallestraße 7a Unit5, 1020 Wien

Der Eingang zur Unit5 befindet sich auf der Lassallestraße genau zwischen den Eingängen zu den Hotels Ibis und Ibis Budget Hotel.

Datum: 11. Dezember 2018

Beginn: 15:30h

Im Anschluss laden wir Sie sehr herzlich auf heiße (Punsch) Getränke und kleine Speisen zum Adventmarkt im Alten AKH ein. Für den Transport von der Veranstaltung zum Adventmarkt ist gesorgt. Bitte geben Sie bei der Anmeldung bekannt, ob Sie beim Punschtrinken teilnehmen werden.

Die Teilnahme zur Veranstaltung und zum Punschtrinken ist kostenlos.

 

Zur Veranstaltung anmelden:

8 + 0 = ?

 

 

Weiterführende Informationen zu den oben genannten Lösungen:

Toad DBA Suite for Oracle Whitepaper  |  Quest Foglight – DE Webseite