Datenbank Abfragen sehr langsam

Nobody007 schrieb:
SELECT namespace,version,comments
FROM dba_registry_history;

SERVER 11.2.0.4 PSU 11.2.0.4.4
Zum Vergrößern anklicken....
Interessant, ich kenne das Statement nicht und weiß nicht, was "normalerweise" rauskommt. Aber es sieht so aus, also ob es eine alte 11er Installation ist, die auf 18 und dann auf 19 gepatcht wurde? (Vielleicht sieht das immer so aus, keine Ahnung, ich finds komisch)

Aber wenn ihr schon seit ein paar Jahren mit der Umstellung zugange seid, wäre es ja vielleicht wirklich so (wobei 11 echt schon was älter ist als 2 Jahre)
Du kannst noch

Code: 
select version from v$instance;

laufen lassen. Das Ergebnis ist etwas übersichtlicher.

Oder mit dem hier kommt vielleicht auch die mit Edition raus:

Code: 
select * from v$version where banner like 'Oracle%';
 
Werbung:
akretschmer schrieb:
Hat denn Ora nicht etwas vergleichbares zu pg_stat_statements in PG? Also eine Möglichkeit, oft und/oder lang laufende Abfragen zu identifizieren?
Zum Vergrößern anklicken....
Ja und nein. In der [active session history](https://oracle-base.com/articles/10g/active-session-history) steht sowas extrem detailliert drin (mit einem Detailgrad für den Postgres vermutlich noch ein paar Jahre braucht) incl. aller Execution Pläne pro Statement und sonstige Wait Events im System.

Aber: die ASH Informationen darf man nur verwenden wenn man die Enterprise Edition zusammen mit dem Performance Pack lizenziert hat. Verwendet man die Standard Edition, kann man darauf auch zugreifen, aber beim nächsten Audit durch Oracle wird das eine saftige Rechnung zur Folge haben.

Man kann das gute alte statspack aktivieren - das ist der Vorläufer von ASH (<= Oracle 10) und ist auch in der 19er noch enthalten. Das setzt aber schon ziemlich detaillierte Kenntnisse über Oracle voraus.
 
castorp schrieb:
v$version enthält immer nur eine Zeile, das WHERE ist also nicht wirklich notwendig.

Am übersichtlichsten ist meiner Meinung nach:
Zum Vergrößern anklicken....
Ja, kann sein, ich hab im Kopf, das spuckt mehrere Zeilen aus. Ist aber was her, hab aktuell kein Oracle am Start.
akretschmer schrieb:
Hat denn Ora nicht etwas vergleichbares zu pg_stat_statements in PG?
Zum Vergrößern anklicken....
Ich sehe kein Problem, sich die lang laufenden Queries anzuschauen, Timing kann man ja einstellen, wie man möchte.
Dann kann man mit den Queries dort ein analyze laufen lassen. Das war ja der Vorschlag von @castorp.

Wenn es generell so bescheiden läuft, muss man dabei irgendwas finden. Falsche oder fehlende Statistiken, fehlende Indizes, ..
Wenn nicht, ist das System falsch konfiguriert.
 
dabadepdu schrieb:
Wenn es generell so bescheiden läuft, muss man dabei irgendwas finden. Falsche oder fehlende Statistiken, fehlende Indizes, ..
Wenn nicht, ist das System falsch konfiguriert.
Zum Vergrößern anklicken....
Ja, sowas habe ich auch in Verdacht, da ich die nachträgliche Indizierung auch von dem alten ERP-System her kenne. Danach rannte das System wieder richtig gut.
 
Aber dafür braucht es den Hersteller, der die Abfragen kennt oder einen Dienstleister, der das selbe herausbekommt.
 
dabadepdu schrieb:
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.
Code: 
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
Zum Vergrößern anklicken....

Wenn ich das richtig lese braucht der aktuell über 71 Minuten bei einer Abfrage....
Uff...


1685971532391.png
 
Die werte in v$ sind alle kumulativ, d.h. Du musst die Gesamtdauer in den V$ Views durch die Anzahl der Ausführungen dividieren.

Ich verwende z.B. so eine Abfrage um die langsamsten Abfragen zu finden:

Code: 
select *
from (
  select (elapsed_time / 1000000) as "Total Seconds",
         (elapsed_time - cpu_time) / 1000000 as "Wait (s)",
         user_io_wait_time / 1000000 as "IO Waits (s)",
         (cpu_time / 1000000) as "CPU Seconds",
         disk_reads "Disk Reads",
         executions as "Executions",
         concurrency_wait_time / 1000000 as "Concurrency Wait (s)",
         buffer_gets as "Total Gets",
         rows_processed as "Total Rows",
         round(buffer_gets / nullif(rows_processed,0)) as "Gets/Row",
         round(buffer_gets / nullif(executions,0))  as "Gets/Exec",
         (elapsed_time/1000)/ nullif(executions,0) as "ms/exec",
         s.sql_id,
         s.child_number as child#,
         au.username as parsing_user,
         s.last_active_time,
         s.first_load_time,
         s.sql_fulltext
  from v$sql s
    join all_users au on au.user_id = s.parsing_user_id 
  where au.username not in ('SYS', 'SYSTEM', 'SYSMAN', 'DBSNMP', 'EXFSYS')
  order by elapsed_time desc nulls last
)
where rownum <= 100;
 
Nobody007 schrieb:
da ich die nachträgliche Indizierung auch von dem alten ERP-System her kenne
Zum Vergrößern anklicken....
Und hast Du mal die Indizierung angeschaut?

Dukel schrieb:
Aber dafür braucht es den Hersteller, der die Abfragen kennt oder ..
Zum Vergrößern anklicken....
Nein, die Abfragen kann man auslesen wie das Statement zeigt. Der HErsteller "versucht" ja seit 2 Jahren, das System ans Laufen zu bringen, eine Indizierung dürfte zwischenzeitlich gelungen sein..
Nobody007 schrieb:
Wenn ich das richtig lese braucht der aktuell über 71 Minuten bei einer Abfrage
Zum Vergrößern anklicken....
Jein, ist eher ein Insert. Das braucht normalerweise kaum Zeit. Kann natürlich sein, dass es so viele Inserts sind, dass es so lange dauert, aber der Verdacht ist da eher, dass irgendetwas gelockt ist. Du könntest Dir auch mal die Sperren anschauen, die auf den Tabellen liegen.
 
Vorweg ich bin kein Oracle User.
Ich vermute dass es auch hier etwas wie die Maintenance Tasks / Jobs gibt.
Aufräumen bzw. Defragmentieren von Indexen & Tabellen, erneuern von Statistiken, Rekompilieren von SP's nach langen Laufzeiten kann kleine Wunder wirken. Nicht nur einmal sie die Jobs bzw. Tasks hängen geblieben oder laufen gar nicht.
Gerade bei Umzügen wird sowas gerne übersehen.
 
Werbung:
Zurück
Oben