Datenbank Abfragen sehr langsam

[dabadepdu]

Für die Linux OS bekommen wir vom Support monatlich einen Report, der zeigt, daß es keine Hardwareängpässe gibt.

Für die Linux VM oder für den Host? So oder so, wenn 8 Kerne da sind und 7 rumidlen, einer aber permanent auf 100 läuft, hat man ne Auslastung von 13%, oder 25 ist auch ne schöne Zahl, dann sind es ca 2 Kerne. Und wenn ein Kern oder 2 ein paar SSD nicht ausreizen, dann wundert das auch nicht.

was meinst Du mit Statistiken bzw. Aktualisierung dieser?

Oracle kann Buch führen über die Häufigkeit der Wert in den Spalten jeder Tabelle. Diese Daten sind sehr wichtig, damit eine Abfrage richtig geplant und ausgeführt wird. Fehlende Statistiken sind eigentlich der Worstcase, wenn man -wie Du sagst- ausreichend Hardware hat (und die auch genutzt wird.
Fehlende Indizes wären eigentlich noch schlimmer, aber das kann ich mir fast nicht vorstellen, dass sowas passiert, wenn man ein ERP einsetzt.

Die Abfrage oben liefert zu jeder Tabelle das Datum, wann die letzte Statistikaktualisierung gemacht wurde. Das Ganze gibt es noch mal für die zugehörigen Indizes.
Fehlendes Datum = nie
altes Datum = veraltet (abhängig vom Migrationszeitpunkt, anschließend vom Datenzuwachs)

hier ist Doku dazu, kannst Du auch selbst lang und schmutzig googlen, ist ein weites Feld:

How to create statistics in Oracle

How to create CBO statistics for Oracle

www.oradev.com

Ich würde sagen, das sind Grundlagen, die der Anbieter regeln muss.

Meinerseits ist es eine reine Vermutung, dass die fehlen. Das wäre zumindest die erste Erklärung, die mir für die Probleme einfällt.

 

[Nobody007]

Für die Linux VM oder für den Host? So oder so, wenn 8 Kerne da sind und 7 rumidlen, einer aber permanent auf 100 läuft, hat man ne Auslastung von 13%, oder 25 ist auch ne schöne Zahl, dann sind es ca 2 Kerne. Und wenn ein Kern oder 2 ein paar SSD nicht ausreizen, dann wundert das auch nicht.

Oracle kann Buch führen über die Häufigkeit der Wert in den Spalten jeder Tabelle. Diese Daten sind sehr wichtig, damit eine Abfrage richtig geplant und ausgeführt wird. Fehlende Statistiken sind eigentlich der Worstcase, wenn man -wie Du sagst- ausreichend Hardware hat (und die auch genutzt wird.
Fehlende Indizes wären eigentlich noch schlimmer, aber das kann ich mir fast nicht vorstellen, dass sowas passiert, wenn man ein ERP einsetzt.

Die Abfrage oben liefert zu jeder Tabelle das Datum, wann die letzte Statistikaktualisierung gemacht wurde. Das Ganze gibt es noch mal für die zugehörigen Indizes.
Fehlendes Datum = nie
altes Datum = veraltet (abhängig vom Migrationszeitpunkt, anschließend vom Datenzuwachs)

hier ist Doku dazu, kannst Du auch selbst lang und schmutzig googlen, ist ein weites Feld:

How to create statistics in Oracle

How to create CBO statistics for Oracle

www.oradev.com

Ich würde sagen, das sind Grundlagen, die der Anbieter regeln muss.

Meinerseits ist es eine reine Vermutung, dass die fehlen. Das wäre zumindest die erste Erklärung, die mir für die Probleme einfällt.

Vielen Vielen Dank für die Hinweise.
Dann habe ich wohl ein paar Sachen zu prüfen.

Na klar kann man googlen. Aber nicht wirklich, wenn man nicht so richtig weiß wo man da ansetzen muß.

 

[dabadepdu]

Na klar kann man googlen. Aber nicht wirklich, wenn man nicht so richtig weiß wo man da ansetzen muß.

Die gezeigte Abfrage liefert die Antwort, ob hier Handlungsbedarf besteht. Wenn ja, kannst Du dir den Link zu Oracle Statistiks oder 1000 andere ähnliche ansehen. Datenbanken, die große Datenmengen verwalten können, kommen ohne Statistiken nicht aus. (Bzw. liefern nicht die Performance, die Du für selbstverständlich hälst)

 

[Dukel]

Evtl. kann man hier einen Oracle Dienstleister dazu ziehen, der sich das anschaut und analysiert.

Aber wenn der Hersteller dir nicht helfen kann, würde ich mir überlegen diesen noch weiter zu nutzen. Man kann auch sicher zurück migireren.

 

[akretschmer]

Es gibt auch OpenSource-Datenbanken bzw. auch andere kommerzielle Systeme, die relativ kompatibel zu Ora sind, NULL (bei OpenSource) oder weniger (EPAS) kosten und es dazu fähige Dienstleister (uns).

 

[Nobody007]

Evtl. kann man hier einen Oracle Dienstleister dazu ziehen, der sich das anschaut und analysiert.

Aber wenn der Hersteller dir nicht helfen kann, würde ich mir überlegen diesen noch weiter zu nutzen. Man kann auch sicher zurück migireren.

Bei dem Invest in einer 7 stelligen Höhe und was dafür schon verbraten wurde ist das nicht mehr möglich. Der Point of no return ist erreicht.
Das System ist nun fast 2 Jahre in der Umsetzung und läuft immer noch unrund

Meines Erachtens ein Witz in der Preisklasse.

 

[castorp]

Der erste Schritt beim Analysieren von Performance Problemen ist eigentlich immer die Analyse des Execution Plans

 

[Nobody007]

Es gibt auch OpenSource-Datenbanken bzw. auch andere kommerzielle Systeme, die relativ kompatibel zu Ora sind, NULL (bei OpenSource) oder weniger (EPAS) kosten und es dazu fähige Dienstleister (uns).

Das wäre noch eine Möglichkeit einen externen Dienstleister drüber schauen zu lassen.
In die Quellcodes kommt man denke ich aber leider nicht so ohne weiteres rein.

Alles andere auf Datenbankebene ist durch den Admin Zugang erreichbar.

 

[ukulele]

Ich finde das ganze muss man erstmal etwas grundsätzlicher angehen.

Du hast die Software beibehalten, genauso das OS. Die Version von beidem hat sich vermutlich geändert. Das läßt sich auch nicht einfach Rückabwickeln weil die alte Software vermutlich nicht mehr supported ist und das damit eine Sackgasse darstellt - so weit so gewöhnlich. Ihr habt die Hardware erneuert und das DBMS gewechselt.

Die Hardware hat jemand anders geliefert? Läuft da noch mehr drauf? Kann man irgendwie leicht feststellen ob hier irgendwo ein Konfig Fehler vorliegt (z.B. im Hypervisor)? - Das ganze ist unwahrscheinlich aber nicht unmöglich. Ansonsten würde ich sagen Hardware ist eher nicht das Problem sondern i.d.R. schneller als vorher.

Warum habt ihr das DBMS gewechselt, wer hat das geliefert? Vermutlich Empfehlung vom Softwarehersteller, Begründung? Das ist eher ungewöhnlich, nach meiner Erfahrung ist das zusätzliche Arbeit und das macht man ja nicht weil man Spass dran hat.

Die Performance ist nicht nur schlecht sondern unterirdisch, das schon seit zwei Jahren? Wie wichtig ist diese Software für euer Geschäft? Ihr habt eine 7-stellige Summe investiert... Für mich ist das keine Frage für ein Forum sondern erstmal ein Chef-Thema. Wenn es nicht schon zu spät ist müsste da längst massiv Druck auf den Dienstleister / Lieferanten ausgeübt werden. Eventuell sollte sich ein (Fach)Anwalt mit den Geschehnissen auseinander setzen und beraten. Es muss klar sein wer der Verantwortung und damit die Kosten zu tragen hat, die erbrachte Leistung bei der Umstellung scheint mir mangelhaft, das Produkt nicht lauffähig.

Ich habe auch schon den Klassiker erlebt, SAP kommt mit vollmundingen Versprechen daher, es gibt kein ordentliches Pflichtenheft, die Einführung kostet das doppelte (auch 7-stellig) und dauerte 3x länger als geplant. Aber sowas muss dann auch als Problem entsprechend behandelt werden und es muss Konsequenzen geben. Es gibt vermutlich mehrere Wege aus dem Desaster aber darüber muss strategisch beraten und entschieden werden, vor allem muss man wissen wie die rechtliche Ausgangslage aussieht und welche Folgen die einzelnen Optionen für den Geschäftsbetrieb haben würden:

a) Weiter frickeln wie bisher
b) ursprünglicher Dienstleister ist verpflichtet seinen ursprünglichen Auftrag zu erfüllen und kommt dem nach (weigert er sich weiter kann er eventuell juristisch angegangen werden)
c) Verantwortung liegt juristisch bei euch, ursprünglicher Dienstleister wird mit neuem Auftrag bedacht das zu fixen
d) einen zusätzlichen Dienstleister hinzu ziehen, z.B. nur für die Datenbank
e) Wechsel des Dienstleisters
f) Wechsel der Software

Ich kenne euer Unternehmen und die Software nicht aber mir scheint das es bei dem Investitionsvolumen allen Beteiligten irgendwie an Professionalität und Ernsthaftigkeit mangelt. Nicht nur die Investion ist gefährdet sondern auch der laufende Betrieb müsste doch enorm leiden. Wenn das nicht der Fall ist warum schmeist man dann den Lieferanten nicht aus dem nächsten Fenster und stampft die Software komplett ein?

 

[Walter]

warum schmeist man dann den Lieferanten nicht aus dem nächsten Fenster und stampft die Software komplett ein?

Sunken costs.

 

[Nobody007]

Ich finde das ganze muss man erstmal etwas grundsätzlicher angehen.

Du hast die Software beibehalten, genauso das OS. Die Version von beidem hat sich vermutlich geändert. Das läßt sich auch nicht einfach Rückabwickeln weil die alte Software vermutlich nicht mehr supported ist und das damit eine Sackgasse darstellt - so weit so gewöhnlich. Ihr habt die Hardware erneuert und das DBMS gewechselt.

Die Hardware hat jemand anders geliefert? Läuft da noch mehr drauf? Kann man irgendwie leicht feststellen ob hier irgendwo ein Konfig Fehler vorliegt (z.B. im Hypervisor)? - Das ganze ist unwahrscheinlich aber nicht unmöglich. Ansonsten würde ich sagen Hardware ist eher nicht das Problem sondern i.d.R. schneller als vorher.

Warum habt ihr das DBMS gewechselt, wer hat das geliefert? Vermutlich Empfehlung vom Softwarehersteller, Begründung? Das ist eher ungewöhnlich, nach meiner Erfahrung ist das zusätzliche Arbeit und das macht man ja nicht weil man Spass dran hat.

Die Performance ist nicht nur schlecht sondern unterirdisch, das schon seit zwei Jahren? Wie wichtig ist diese Software für euer Geschäft? Ihr habt eine 7-stellige Summe investiert... Für mich ist das keine Frage für ein Forum sondern erstmal ein Chef-Thema. Wenn es nicht schon zu spät ist müsste da längst massiv Druck auf den Dienstleister / Lieferanten ausgeübt werden. Eventuell sollte sich ein (Fach)Anwalt mit den Geschehnissen auseinander setzen und beraten. Es muss klar sein wer der Verantwortung und damit die Kosten zu tragen hat, die erbrachte Leistung bei der Umstellung scheint mir mangelhaft, das Produkt nicht lauffähig.

Ich habe auch schon den Klassiker erlebt, SAP kommt mit vollmundingen Versprechen daher, es gibt kein ordentliches Pflichtenheft, die Einführung kostet das doppelte (auch 7-stellig) und dauerte 3x länger als geplant. Aber sowas muss dann auch als Problem entsprechend behandelt werden und es muss Konsequenzen geben. Es gibt vermutlich mehrere Wege aus dem Desaster aber darüber muss strategisch beraten und entschieden werden, vor allem muss man wissen wie die rechtliche Ausgangslage aussieht und welche Folgen die einzelnen Optionen für den Geschäftsbetrieb haben würden:

a) Weiter frickeln wie bisher
b) ursprünglicher Dienstleister ist verpflichtet seinen ursprünglichen Auftrag zu erfüllen und kommt dem nach (weigert er sich weiter kann er eventuell juristisch angegangen werden)
c) Verantwortung liegt juristisch bei euch, ursprünglicher Dienstleister wird mit neuem Auftrag bedacht das zu fixen
d) einen zusätzlichen Dienstleister hinzu ziehen, z.B. nur für die Datenbank
e) Wechsel des Dienstleisters
f) Wechsel der Software

Ich kenne euer Unternehmen und die Software nicht aber mir scheint das es bei dem Investitionsvolumen allen Beteiligten irgendwie an Professionalität und Ernsthaftigkeit mangelt. Nicht nur die Investion ist gefährdet sondern auch der laufende Betrieb müsste doch enorm leiden. Wenn das nicht der Fall ist warum schmeist man dann den Lieferanten nicht aus dem nächsten Fenster und stampft die Software komplett ein?

Das klingt zwar ziemlich hart was Du schreibst aber leider hast Du auch absolut Recht damit.
Die alte ERP Software mußte ausgetauscht werden, da sie nicht mehr den Anforderungen entsprach und zusätzlich zu alt geworden ist.


Die Neue ERP Lösung wurde umfangreich über einen sehr bekannten externen Dienstleister (der sich um den ERP Auswahlprozess kümmert) inkl. Anforderungs- und Pflichtenhefterstellung ausgewählt.
Nach mehreren Präsentationsworkshops mit den favorisierten Anbietern wurde sich wohl für den aktuellen entschieden.

Aber nu... Ändern wird man da nichts mehr können, weil auch eine Menge individuell für z.B. Intercompanyprozesse zuprogrammiert wurde.
Die Option eines Wechsels entfällt somit.

In Teilbereichen läuft es ja auch ganz gut.
Wenn allerdings BI-Analysen mit dem hauseigenen Programm durchgeführt werden sollen sind diese halt auch extrem langsam.
Bei einer Abfrage für eine Jahresübersicht mit 1821 Datensätzen benötigt das Ganze ca. 8 Minuten.
Aussage des Dienstleisters: "Die Abfrage ist ja auch sehr komplex."
Da ich kein Oracle Spezialist bin mußte ich das erst einmal glauben. Aber irgendwas sagt mir, daß das nur eine dumme Ausrede ist.
Deswegen habe ich mein Anliegen hier mal publiziert.

Ich könnte auch gerne mal die Abfrage posten.
Bin auf Eure Meinungen gespannt, ob dies wirklich so eine komplexe Geschichte ist.

 

[Nobody007]

Laut Auftrag ist es eine Oracle ASFU.

und mit der Abfrage
SELECT * FROM v$version;
bekomme ich folgendes Ergebnis:

Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production




SELECT comp_name, version_full, status
FROM dba_registry;

Oracle Database Catalog Views 19.19.0.0.0 VALID
Oracle Database Packages and Types 19.19.0.0.0 VALID
JServer JAVA Virtual Machine 19.19.0.0.0 VALID
Oracle XDK 19.19.0.0.0 VALID
Oracle Database Java Packages 19.19.0.0.0 VALID
Oracle Real Application Clusters 19.19.0.0.0 OPTION OFF
Oracle Workspace Manager 19.19.0.0.0 VALID
Oracle Text 19.19.0.0.0 VALID
Oracle XML Database 19.19.0.0.0 VALID
Oracle Multimedia 19.19.0.0.0 VALID

 

[ukulele]

Das klingt zwar ziemlich hart was Du schreibst aber leider hast Du auch absolut Recht damit.
Die alte ERP Software mußte ausgetauscht werden, da sie nicht mehr den Anforderungen entsprach und zusätzlich zu alt geworden ist.

Dann wurde also nicht einfach eine neue Version von der alten Software genommen sondern eine komplett andere Software eingesetzt, korrekt? Das erklärt auch den Wechsel des DBMS und deutet eher auf ein generelles Problem der Software hin (z.B. bei besonders großen Datenmengen mit denen man vorher vielleicht nicht getestet hat) und nicht zwingend ein Problem mit der DB. Natürlich kann die Handbremse in der DB liegen aber dann nicht nur bei euch sondern eher bei allen Kunden mit dieser Software.

Die Neue ERP Lösung wurde umfangreich über einen sehr bekannten externen Dienstleister (der sich um den ERP Auswahlprozess kümmert) inkl. Anforderungs- und Pflichtenhefterstellung ausgewählt.
Nach mehreren Präsentationsworkshops mit den favorisierten Anbietern wurde sich wohl für den aktuellen entschieden.

Hm ja sowas ist scheiße, der hat seinen Job scheinbar nicht gut gemacht. Es sind also mehrere DL involviert die sich mit Sicherheit gegenseitig die Schuld zuschieben.

Aber nu... Ändern wird man da nichts mehr können, weil auch eine Menge individuell für z.B. Intercompanyprozesse zuprogrammiert wurde.
Die Option eines Wechsels entfällt somit.

Naja das sollte man so nicht ausschließen, ist natürlich finanziell ein Totalschaden und das ist sicherlich der letzte Schritt.

In Teilbereichen läuft es ja auch ganz gut.
Wenn allerdings BI-Analysen mit dem hauseigenen Programm durchgeführt werden sollen sind diese halt auch extrem langsam.

Dann kann man vielleicht nur auf die Analyse-Tools verzichten und mit einer anderen Lösung auf die Daten zugreifen.

Bei einer Abfrage für eine Jahresübersicht mit 1821 Datensätzen benötigt das Ganze ca. 8 Minuten.
Aussage des Dienstleisters: "Die Abfrage ist ja auch sehr komplex."
Da ich kein Oracle Spezialist bin mußte ich das erst einmal glauben. Aber irgendwas sagt mir, daß das nur eine dumme Ausrede ist.

Der Verdacht liegt nahe Aber so einfach ist es dann halt auch nicht. Könnt ihr die Abfragen direkt einsehen und selbst testweise in einem SQL Client laufen lassen? Leider bin ich so gar nicht mit Oracle bewandert aber darüber könnte man sich wirklich mal angucken wo die Zeit bei drauf geht.

Ich könnte auch gerne mal die Abfrage posten.

Ja man könnte sich die Qualität mal anhand einer Abfrage angucken. Am besten eine möglichst simple Abfrage die dennoch lange Laufzeiten hat.

Aber sich das selber anzusehen und im Forum Tipps zu holen ist das eine, wenn hier wirklich ein Qualitätsproblem vorliegt und vielleicht Schadenersatzansprüche eine Rolle spielen sollte man sowas gut dokumentieren und vielleicht auch von absolut unabhängigen DL machen lassen.

 

[Nobody007]

Hab das hier auch noch mit Google gefunden:
SELECT namespace,version,comments
FROM dba_registry_history;

SERVER 11.2.0.4 PSU 11.2.0.4.4
SERVER 11.2.0.4.1OJVMBP APPLIED jvmpsu.sql
SERVER 11.2.0.4 PSU 11.2.0.4.160419
SERVER 11.2.0.4.160419OJVMPSU RAN jvmpsu.sql
SERVER 11.2.0.4.160419OJVMPSU OJVM PSU post-install
SERVER 11.2.0.4 PSU 11.2.0.4.160719
SERVER 11.2.0.4.160719OJVMPSU RAN jvmpsu.sql
SERVER 11.2.0.4.160719OJVMPSU OJVM PSU post-install
SERVER 11.2.0.4 PSU 11.2.0.4.161018
SERVER 11.2.0.4.170117OJVMPSU RAN jvmpsu.sql
SERVER 11.2.0.4.170418OJVMPSU RAN jvmpsu.sql
SERVER 11.2.0.4 PSU 11.2.0.4.170418 view invalidation
DATAPATCH 12.1.0.2 RDBMS_12.1.0.2.0DBPSU_LINUX.X64_161210
SERVER 12.1.0.2.170418OJVMPSU RAN jvmpsu.sql
SERVER 12.1.0.2.171017OJVMPSU RAN jvmpsu.sql
SERVER 12.1.0.2.180116OJVMPSU RAN jvmpsu.sql
SERVER 12.1.0.2.180417OJVMPSU RAN jvmpsu.sql
SERVER 12.1.0.2.180717OJVMPSU RAN jvmpsu.sql
SERVER 12.1.0.2.181016OJVMPSU RAN jvmpsu.sql
SERVER 12.1.0.2.190115OJVMPSU RAN jvmpsu.sql
DATAPATCH 18 RDBMS_18.5.0.0.0DBRU_LINUX.X64_181215
view invalidation
SERVER 18.0.0.0.0 Upgraded from 12.1.0.2.0 to 18.3.0.0.0
SERVER 18.3.0.0.180717OJVMRU RAN jvmpsu.sql
SERVER 18.3.0.0.180717OJVMRU OJVM RU post-install
view invalidation
SERVER 18.0.0.0.0 Upgraded from 12.1.0.2.0 to 18.3.0.0.0
SERVER 18.0.0.0.0 Patch applied from 18.3.0.0.0 to 18.5.0.0.0
SERVER 18.5.0.0.190115OJVMRU RAN jvmpsu.sql
SERVER 18.5.0.0.190115OJVMRU OJVM RU post-deinstall
SERVER 18.5.0.0.190115OJVMRU RAN jvmpsu.sql
SERVER 18.5.0.0.190115OJVMRU OJVM RU post-install
DATAPATCH 19 RDBMS_19.19.0.0.0DBRU_LINUX.X64_230321.1
SERVER 19.0.0.0.0 Patch applied on 19.3.0.0.0: Release_Update - 190410122720
SERVER 19.0.0.0.0 Upgraded from 18.5.0.0.0 to 19.3.0.0.0
SERVER 19.0.0.0.0 Patch applied from 19.3.0.0.0 to 19.13.0.0.0
SERVER 19.13.0.0.211019OJVMRU RAN jvmpsu.sql
SERVER 19.13.0.0.211019OJVMRU OJVM RU post-install
SERVER 19.14.0.0.220118OJVMRU RAN jvmpsu.sql
SERVER 19.14.0.0.220118OJVMRU OJVM RU post-deinstall
SERVER 19.14.0.0.220118OJVMRU RAN jvmpsu.sql
SERVER 19.14.0.0.220118OJVMRU OJVM RU post-install
SERVER 19.0.0.0.0 Patch applied from 19.13.0.0.0 to 19.14.0.0.0
SERVER 19.15.0.0.220419OJVMRU RAN jvmpsu.sql
SERVER 19.15.0.0.220419OJVMRU OJVM RU post-deinstall
SERVER 19.15.0.0.220419OJVMRU RAN jvmpsu.sql
SERVER 19.15.0.0.220419OJVMRU OJVM RU post-install
SERVER 19.0.0.0.0 Patch applied from 19.14.0.0.0 to 19.15.0.0.0
SERVER 19.17.0.0.221018OJVMRU RAN jvmpsu.sql
SERVER 19.17.0.0.221018OJVMRU OJVM RU post-deinstall
SERVER 19.17.0.0.221018OJVMRU RAN jvmpsu.sql
SERVER 19.17.0.0.221018OJVMRU OJVM RU post-install
SERVER 19.0.0.0.0 Patch applied from 19.15.0.0.0 to 19.17.0.0.0
SERVER 19.17.0.0.221018OJVMRU RAN jvmpsu.sql
SERVER 19.17.0.0.221018OJVMRU OJVM RU post-deinstall
SERVER 19.18.0.0.230117OJVMRU RAN jvmpsu.sql
SERVER 19.18.0.0.230117OJVMRU OJVM RU post-install
SERVER 19.0.0.0.0 Patch applied from 19.17.0.0.0 to 19.18.0.0.0
SERVER 19.18.0.0.230117OJVMRU RAN jvmpsu.sql
SERVER 19.18.0.0.230117OJVMRU OJVM RU post-deinstall
SERVER 19.19.0.0.230418OJVMRU RAN jvmpsu.sql
SERVER 19.19.0.0.230418OJVMRU OJVM RU post-install
SERVER 19.0.0.0.0 Patch applied from 19.18.0.0.0 to 19.19.0.0.0

 

[dabadepdu]

Der erste Schritt beim Analysieren von Performance Problemen ist eigentlich immer die Analyse des Execution Plans

Sehe ich auch so, dazu muss man natürlich die Queries kennen. Ist bei einem Kaufsystem nicht selbstverständlich.

Alles, was gerade länger als 5 Minuten läuft. Dazu musst Du als sysdba angemeldet sein schätze ich.

select s.username,
       s.sid,
       s.serial#,
       s.last_call_et / 60 minutes_running,
       q.sql_text
  from v$session s
  join v$sqltext_with_newlines q
    on s.sql_address = q.address
 where status = 'ACTIVE'
   and type <> 'BACKGROUND'
   and last_call_et > 300