Statement läuft ewig

[DaBe1812]

Hi,

ich habe ein recht einfaches Statement, dass ich per JPA an die Datenbank schicke und es dauert ewig, bis ich eine Antwort habe.
Das ist das Statement an sich, dass von JPA (eclipseLink) generiert wird:

SELECT ID, RSP_DURATION, EID_VERWEIS, RSP_ERROR, INST_NR, RSP_TIME, RSP_REFSYSTEM, REGION, RSP_STATE, RSP_SYSTEM, RSP_QUERY FROM RESPONSE_TIMES WHERE RSP_REFSYSTEM IN ('KV', 'AM') AND RSP_TIME BETWEEN '22.04.2024' AND '28.04.2024';

Auf der Datenbank dauert die Abfrage 0,16 Sekunden.
In der Anwendung dauert die Abfrage ca. 40 Sekunden.

Ich habe schon alle möglichen Sachen ausprobiert:
Aus der NamedQuery eine Native Query gemacht.
Ich habe mal das Typed weggelassen, falls die Konvertierung das Problem ist und mir nur eine

List<Object[]>

zurückgeben lassen.
Die Abfrage liegt immer so um die 39 - 41 Sekunden.

Als letzte Idee hatte ich jetzt mal bei EclipseLink das Logging auf FINE gestellt, aber da sehe ich auch nichts, weil er nur das PreparedStatement anzeigt und mehr nicht.
Woran kann es noch liegen, bzw. kann ich noch etwas mehr Debuggen, um das Problem zu finden?

Gibt es vielleicht noch Einstellungen in der Persistence.xml oder in der Server.xml (Websphere) die man machen könnte, damit es schneller geht?

 

[HerrInfo]

Dies stellt kein Allheilmittel dar und ist nur bedingt nützlich. Dennoch könnte man das Statement in kleinere Understatements aufteilen und diese parallel in mehreren Threads ausführen. Anschließend müssten die Ergebnisse wieder zusammengeführt werden. Das Problem lag dort im

AND

Statement

 

[Dukel]

Moderne DB führen Abfragen ja Paralell aus. Aber hier sollte es ja nicht an der DB liegen, da die Db Abfrage selber 1/5 sek braucht.

Wenn du die Abfrage "manuell" per Java JDBC aufrufst, braucht es dann genauso lange?

 

[Oneixee5]

Um welche DB geht es und wie sehen die Entities aus? Werden mehrere Anfragen ausgeführt?
0,16 ist schon recht langsam. Wie groß ist die Ergebnismenge?

 

[Marinek]

Ich hatte so ein Fall schon mal da war das ORM auf Trace gestellt. Je nachdem wie groß die Anzahl der Elemente ist und ob es da noch Referenzen gibt, kann das schon dauern.

 

[Oneixee5]

Ich hatte so ein Fall schon mal da war das ORM auf Trace gestellt. Je nachdem wie groß die Anzahl der Elemente ist und ob es da noch Referenzen gibt, kann das schon dauern.

Es kann auch einfach der Speicher knapp werden, wenn es recht viele Datensätze sind. Aber - alles nur Spekulation und Ferndiagnose. Details bitte!

 

[DaBe1812]

Hi,
Also zu den Rückfragen:

Um welche DB geht es

Oracle 19, Patchstand hab ich gerade nicht im Kopf, glaube 20.

Werden mehrere Anfragen ausgeführt?

In genau dem Moment nur eine Einzige (laut Logging) Im Anschluss dann noch zwei, ich betrachte aber genau die Laufzeit von der einen Abfrage. Die anderen beiden sind schnell.

Wie groß ist die Ergebnismenge?

2.263 Zeilen. Muss auch die Zeit von gestern korrigieren. Ich hatte nicht mehr dran gedacht, dass der Oracle SQL-Viewer mit Shift+F5 nur 50 Zeilen anzeigt und nicht alle, also wenn ich nur F5 mache, dann sind es 2,15 Sekunden. Indices sind noch keine auf die Tabelle, falls die Frage dann als nächstes kommt, bin aber dahingehend gerne bereit welche an zu legen.

Es kann auch einfach der Speicher knapp werden

Nope, der liegt im entspannten Bereich, da ist genug da.

wie sehen die Entities aus?

@Entity
@Table(name = "RESPONSE_TIMES")
@NamedQueries ( value={
        @NamedQuery(name = "ResponseTime.responseTimeByDateAndSystems", query = "SELECT a FROM ResponseTime a WHERE a.refSystem IN :refSystems AND a.queryTime between :dateA AND :dateB"),
    })
public class ResponseTime implements Serializable, Comparable<ResponseTime> {

    private static final long serialVersionUID = -4623289064357915802L;

    @Id
    @Column(name = "ID")
    private String id;

    @Column(name = "RSP_REFSYSTEM")
    @Enumerated(EnumType.STRING)
    private ReferenceSystem refSystem;

    @JoinColumn(name = "RSP_QUERY", referencedColumnName = "ID")
    private ResponseTimeQuery query;

    @Column(name = "RSP_DURATION")
    private long duration;

    @Column(name = "RSP_STATE")
    @Enumerated(EnumType.STRING)
    private QueryTimeResponseState respState;

    @Column(name = "RSP_TIME")
    private LocalDateTime queryTime;

    @Column(name = "RSP_ERROR")
    private String errMsg;
    
    @Column(name = "RSP_SYSTEM")
    private String system;
    
    @Column(name = "INST_NR")
    private int instNr;

    @Column(name = "REGION")
    private String region;

    @Column(name = "EID_VERWEIS")
    private String eidVerweis;

    public ResponseTime() {
    }

    public ResponseTime(ReferenceSystem refsystem) {
        this.queryTime = LocalDateTime.now();
        this.id = UUID.randomUUID().toString();
        this.refSystem = refsystem;
        this.respState = QueryTimeResponseState.OK;
        this.system = AtcConfiguration.serverName;
    }

    public ResponseTime(ReferenceSystem pRefSystem, ResponseTimeQuery pId, int pInstNr, String pRegion,
            String pEidVerweis) {
        this.refSystem = pRefSystem;
        this.id = UUID.randomUUID().toString();
        this.queryTime = LocalDateTime.now();
        this.respState = QueryTimeResponseState.OK;
        this.instNr = pInstNr;
        this.region = pRegion;
        this.eidVerweis = pEidVerweis;
        this.query = pId;
    }

    @Override
    public int compareTo(ResponseTime o) {// TODO wird die Methode benötigt?
        return 0;
    }

    public long getDurationMs() {
        return (duration / 1000000);
    }
    //Getter und Setter
}

Wenn du die Abfrage "manuell" per Java JDBC aufrufst, braucht es dann genauso lange?

Was meinst du mit "manuell"? Ich steh gerade auf dem Schlauch.

 

[M.L.]

manuell

wohl ohne JPA-Framework (als zusätzliche Schicht, die leistungsmindernd sein könnte)

 

[DaBe1812]

Achso. Reicht da der Test über die Datasource-Option in Eclipse, oder in der Anwendung manuell eine DB-Verbindung hoch ziehen und verwenden?

 

[M.L.]

manuell eine DB-Verbindung hoch ziehen und verwenden

Es wäre wohl einen Versuch wert (Code-Vorschlag von Gemini als txt-Anhang)

 

[Oneixee5]

JoinColumn sollte lazy sein, ansonsten werden auf jeden Fall mehrere Abfragen ausgeführt.

@ManyToOne(fetch = FetchType.LAZY)   
@JoinColumn(name = "RSP_QUERY", referencedColumnName = "ID")
private ResponseTimeQuery query;

Ich würde auf jeden Fall einen Index auf RSP_REFSYSTEM testen. Auch ein zweispaltiger Index kann sinnvoll sein: RSP_REFSYSTEM, RSP_TIME.
Aber das hängt alles von den Daten ab. Wenn die Abfrage >1% der Tabelle zurück gibt, ist ein vollständiger Scan höchstwahrscheinlich schneller. Es besteht also keine Notwendigkeit, einen Index zu erstellen. Wenn RSP_REFSYSTEM eine schlechte Selektivität hat, kann ein Index auf RSP_TIME ähnliche Ergebnisse erzielen. Jeder Index erhöht aber den Overhead bei DML-Operationen. Neben der Änderung der Daten muss Oracle auch alle Indizes ändern und alles in Redo-Logs protokollieren.

2,15 Sekunden für 2.263 Zeilen irritiert mich, das ist viel zu langsam, selbst für eine schlecht optimierte DB. Möglicherweise wäre es besser die Tabelle noch einmal neu anzulegen - ohne diese durch die Entity zu generieren.

 

[Marinek]

Naja. Wenn insgesamt Millionen Datensätze da drin sind, dann muss er ohne Index ein Full table Scan machen.

Vielleicht doch mal die Indizes setzen für die Felder über die gesucht wird.

 

[DaBe1812]

Es wäre wohl einen Versuch wert

Okay, Ergebnis ist erschreckend:
Das reine statement.execute() dauert 189 Millis.
Die Ausgabe aus deinem Code 37.728 Millis.
Ohne SysOut, also das reine durchlaufen des ResultSet dauert ähnlich lange.
Also ich gehe mal davon aus, dass auch das JPA Framework alle Datensätze durchlaufen muss, um sie in ein Objekt zu packen. Oder denke ich hier falsch?
Also sollte ich richtig denken, dann ist die Zeit in meiner Anwendung ja realistisch mit 40 Sekunden.

2,15 Sekunden für 2.263 Zeilen irritiert mich, das ist viel zu langsam, selbst für eine schlecht optimierte DB. Möglicherweise wäre es besser die Tabelle noch einmal neu anzulegen - ohne diese durch die Entity zu generieren.

Die Tabelle hatte ich selbst angelegt, in der Datenbank lege ich nicht direkt durch die Entität an, der Weg war mir da zu unsicher.
Blöd ist nur, dass wenn ich die Tabelle lösche, dann habe ich nicht mehr die Datenmenge, wie jetzt. Wäre dann aber einen Test wert, ob die Daten dann schneller geladen werden, bei kleinerer Datenmenge.

Naja. Wenn insgesamt Millionen Datensätze

Ich denke wir sind noch weit entfernt von der Millionen-Marke genau 490.953 Sätze.

Ich würde auf jeden Fall einen Index auf RSP_REFSYSTEM testen. Auch ein zweispaltiger Index kann sinnvoll sein: RSP_REFSYSTEM, RSP_TIME.

Die Indices werde ich nach dem Feiertag mal anlegen, jetzt mach ich erstmal Feierabend. Aber gibt es in Oracle auch so ein Statement mit dem einem die Datenbank Indices empfiehlt, so wie in MSSQL?

 

[mrBrown]

Du könntest mal testweise die Fetch Size höher setzen, erstmal auch einfach auf irgendwas größer als die erwartete Ergebnisanzahl.

 

[mihe7]

Blöd ist nur, dass wenn ich die Tabelle lösche, dann habe ich nicht mehr die Datenmenge, wie jetzt.

RENAME TABLE RESPONSE_TIMES TO RESPONSE_TIMES_OLD;
CREATE TABLE RESPONSE_TIMES ( ... );
INSERT INTO RESPONSE_TIMES SELECT * FROM RESPONSE_TIMES_OLD;