h41msh1c0r
Goto Top

Oracle 10g Fulltablescan Problem

Hi@All,

die Oracle DB sorgt ja selber für die Suchstrategien. Wir haben nun eine Stammdatentabelle die die mio Einträge bereits überschritten hat. Wird nun über diese Tabelle ein fulltablescan gemacht dauert das natürlich seine Zeit.

Jetzt haben wir einen Bereich im Haus wo 5 Leute mit Hauseigener Anwendung X arbeiten und bei 3 Leuten geht es fix und bei 2 macht die Oracle DB über besagte Stammdatentabelle einen fulltablescan.

Alle machen das gleiche mit der Anwendung.

Wir haben bis jetzt keinen Kniff gefunden wie und ob man diese Suchstrategien beeinflussen kann.

Wer stand bereits vor solch einem Fall und hätte einen Tipp parat?

VG

Content-ID: 167164

Url: https://administrator.de/forum/oracle-10g-fulltablescan-problem-167164.html

Ausgedruckt am: 23.12.2024 um 14:12 Uhr

db-wizard
db-wizard 30.05.2011 um 11:13:52 Uhr
Goto Top
Hallo


Ein Fulltablescan ist prinzipiell weder gut noch schlecht, es kommt auf den Umstand an. Abhängig von den verwendeten Suchkriterien kann ein Fulltabslescan deutlich performanter sein als ein Index Scan.


Gruss, Ueli
H41mSh1C0R
H41mSh1C0R 30.05.2011 um 11:20:10 Uhr
Goto Top
Hallo,

mit verwendeten Suchkriterien meinst du den Select Aufruf selber oder kann man Oracle noch selber Parameter für seine Suchstrategie mitgeben bzw. gibt es Stellschrauben an denen wir drehen können?


VG
db-wizard
db-wizard 30.05.2011 um 11:30:48 Uhr
Goto Top
- Ob Oracle eine FTS oder Index Scan verwendet, ist unter anderem abhängig von der Anzahl der zurückgelieferten Datensätzte in Relation zur Gesamtmenge. Es gibt dabei einige Stellschrauben, welche das Verhalten beinflussen können, ausserdem natürlich das Vorhandensein von passenden Indizies und aktuellen Statistiken.
- Ein guter Startpunkt zur Analyse solcher Probleme wäre ein Tracen der Session's, welche die Benutzer ausführen. In den dabei entstehenden TRACE Files, siehst du exakt, was die DB bei den ein einzelnen Statements gemacht hat.


Gruss
H41mSh1C0R
H41mSh1C0R 30.05.2011 um 13:32:46 Uhr
Goto Top
Index ist vorhanden.

Langsamer Ablauf:

Hier geht er NICHT über den Index.

11bb33f6720196d81500a5b75f470595


Schneller Ablauf:

Hier geht er über den Index so wie er soll.

1049f7e9aa81a4eaac9a3208860b245a

vg

EDIT:

Käme man hier mit der Benutzung von HINTs weiter?
db-wizard
db-wizard 30.05.2011 um 14:55:14 Uhr
Goto Top
Kannst du mal die beiden SQL posten ? Einmal "schnell", einmal langsam" ?


Danke und Gruss
H41mSh1C0R
H41mSh1C0R 30.05.2011 um 15:01:44 Uhr
Goto Top
SELECT CASE WHEN substr(xd_az,1,2) = 'SR' THEN to_char(sysdate,'YYYY') ELSE to_char(to_date(substr(xd_az,1,2),'RRRR'),'YYYY') END, 1,   
to_char(xd_eingang,'yyyymmdd'), day(vs_gebdat), month(vs_gebdat), year(vs_gebdat), '',   
xd_dok_typ, xd_az, vs_udat, xd_personal_unfall, '', vs_gebdat,   
CASE WHEN vs_abgabe IN (' ','997','998') THEN '' ELSE   
CASE WHEN xd_sammelrechnung = '0' AND substr(vs_mglnr,2,4) = '9999'   
THEN vs_abgabe ELSE '' END END, xd_ident,   
CASE WHEN xd_archiv_dok_id IS NULL THEN 0 ELSE xd_archiv_dok_id END, 
CASE WHEN xd_archiv_vorgang_id IS NULL THEN 0 ELSE xd_archiv_vorgang_id END, 
xd_dok_typ, xd_verfahren, xd_eingang, xd_post_eingang, xd_dok_name, vs_name, 
vs_vname, vs_hmkm, vs_bstand, vs_mglnr, vs_betr, vs_uart, vs_akz, 
CASE WHEN vs_abgabe IN (' ','997') THEN '' ELSE vs_abgabe END,   
pwf_ident, pwf_aktion, pwf_aktion_teil, pwf_datum_ende, pwf_datum_beginn, pwf_user_eingang, 
xd_ablage_datum, xd_sammelrechnung, '', ''   
from   xml_dokumente, verl_stamm, prog_work_flow, work_flow_aktion, term_zust 

where xd_az = vs_az AND tz_zust = 'xxxxxxxxxxx'  
 
AND (tz_sachgeb = 10 AND tz_tag2 = 0 AND tz_tag1 = day(vs_gebdat) 
AND tz_monat1v <= month(vs_gebdat) AND tz_monat1b >= month(vs_gebdat) 
OR tz_sachgeb = 9 AND tz_tag2 > 0 AND tz_tag1 <= day(vs_gebdat) 
AND tz_tag2 >= day(vs_gebdat) AND tz_monat1v <= month(vs_gebdat) 
AND tz_monat2b >= month(vs_gebdat)) 
AND xd_ident = pwf_vorgang_ident AND xd_verfahren = pwf_verfahren AND pwf_aktion = wa_ident 
AND wa_prog_modul IS NOT NULL AND wa_prog_modul = 'prog_erf'   
AND xd_ident NOT IN (SELECT dz_ident FROM dok_zust WHERE (dz_sachgeb = 10 OR dz_sachgeb = 10)) 
AND xd_az IS NOT NULL AND (pwf_aktion_teil IS NULL OR pwf_aktion_teil = 2) 
AND (vs_abgabe IS NULL OR vs_abgabe = ' ' OR vs_abgabe <> '999' )   
AND (pwf_datum_ende IS NULL OR to_char(pwf_datum_ende,'dd.mm.yyyy') = '30.05.2011')   
AND xd_az NOT IN (SELECT vm_az FROM verl_sonder)

Beide Selects unterscheiden sich nur im Nutzernamen der in der mitte statt 'xxxxxxx' steht.

vg
db-wizard
db-wizard 30.05.2011 um 15:03:45 Uhr
Goto Top
Wieviele Datensätze geben die beiden Varianten jeweils zurück ?
H41mSh1C0R
H41mSh1C0R 30.05.2011 um 15:07:10 Uhr
Goto Top
Da wo es schnell geht 287.

Bei dem wo es "lange" (durchaus bis zu 30 Minuten) dauert ca. 150 Datensätze mehr.
db-wizard
db-wizard 30.05.2011 um 15:11:13 Uhr
Goto Top
Das dürfte kein Problem sein. Ich glaube, du solltest einen Trace machen und via TKPROF mal anschauen, was genau gemacht wird, also mit ALTER SESSION SET SQL_TRACE = TRUE; und dann das Statement laufenlassen, am besten direkt im SQL PLUS, Du weisst wie das funktioniert ? face-smile
H41mSh1C0R
H41mSh1C0R 30.05.2011 um 15:16:22 Uhr
Goto Top
^^ Sry leider weiß ich noch nicht wie das geht. Aber ich kann ja nur dazulernen. Aus dem SQL Developer heraus kann ich das nicht anstoßen und überprüfen?
db-wizard
db-wizard 30.05.2011 um 16:04:39 Uhr
Goto Top
Ja, es geht auch pe SQL Developer, jedenfalls beinahe.

Ich gehe von der aktuellen Version 3.x aus


1. Connecte auf die Instanz und mache ein SQL Worksheet auf
2. Paste dort dein gewünschtes SQL hinein
3. VOR deinem SQL fügst du ALTER SESSION SET SQL_TRACE = TRUE
/
ein (mit dem Slash)
4. NACH deinem SQL : ALTER SESSION SET SQL_TRACE = FALSE
/

Lasse alle 3 Statements laufen (F5)

5. Das Tracefile findest du nun auf dem Server, in der Regel unter folgendem Pfad (Linux, bei Windows ist es ähnlich): /opt/oracle/admin/THLTST10/udump/
(THLTST10 ist meine SID)

Es sollte etwa so heissen : SID_ora_10007.trc, wobei SID dein Oacle SID ist...schaue einfach auf das aktuelle Filedatum,es sollte eh nicht allzuviel im Verzeichnis haben

6 .Kopiere dir dieses File auf deinen PC
7. Per Drag und Drop kannst du es nun direkt in den SQLDev ziehen

Hoffe das hilft face-smile
H41mSh1C0R
H41mSh1C0R 30.05.2011 um 16:51:22 Uhr
Goto Top
Danke, ich glaube ich sollte erstmal die SQL Developer Version updaten =). Hocke hier auf dem 1.0.0.14er Stand.

Mein Kollege hat zwar das Problem bereits gelöst, durch einen Schalter bei dem Oracle die Reihenfolge wie er durch die Tabellen geht nicht selber verändern darf und schon geht das fix.

Das Problem ist das er bei den letzten Tabellen noch fts macht und deren Inhalt nimmt täglich rasant zu also früher oder später gibts an der Stelle verbesserungsbedarf.

Ich werde das mit dem Tracen dennoch ausprobieren, kann nicht schaden.

Viele Grüße

EDIT:

Die Reihenfolge scheint das Problem nur verlagert zu haben. Gelöst wurde es jetzt durch ein Analyse Table auf die Term.Zust. Somit wird das Tracen auch nichts mehr bringen, da es jetzt nun wieder rennt.
db-wizard
db-wizard 30.05.2011 um 18:51:32 Uhr
Goto Top
Na ja, die Statistiken müssen schon da und auch aktuell sein, hatte ich weiter oben ja auch geschrieben. Im übrigen solltest du das ANALYZE TABLE nicht mehr verwenden, siehe dazu dazu folgenden Link:

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:434 ...

Für folgendes Problem :

<<<<
Das Problem ist das er bei den letzten Tabellen noch fts macht und deren Inhalt nimmt täglich rasant zu also früher oder später gibts an der Stelle verbesserungsbedarf.
>>>>>

In solch einem Fall würde sich eventuell eine Partitionierung der Tabelle aufdrängen und zwar nach dem Key, nach dem in deinem Fall gesucht wird
H41mSh1C0R
H41mSh1C0R 30.05.2011 um 19:03:40 Uhr
Goto Top
Die Statistiken werden per Job erstellt, wir haben das jetzt nur manuell für diese eine Tabelle angestoßen.

Danke für den Tipp mit dem Partitionieren das werden wir ausprobieren.

vg