Oracle 8i - trunc()

[Nic_21cf50]

Hallo Oracle-Experten,

hier mal etwas kniffliges:

Ich habe folgendes select:

select …
from…
where
trunc(sysdate,‚dd‘) between VON and BIS

VON und BIS sind von Type Date und es sollen nur die Datensätze selektiert werden, die das heutige Datum einschließen. Gerundet wird auf volle Tage.
Bei mehreren tausend Sätzen steigt die Laufzeit plötzlich in den Minutenbereich, oder schlimmer. Schuld soll das TRUNC() sein (hab ich gehört), das bei 8i problematisch sein soll.
Ohne das trunc() in der where-Klausel ist die Performace gut, also im Sekundenbereich.

Kennt jemand das Problem? Gibt es eine Lösung/Workaround?

Vielen Dank
Nic

[Tomh]

hi!

select …
from…
where
trunc(sysdate,‚dd‘) between VON and BIS

Bei mehreren tausend Sätzen steigt die Laufzeit plötzlich in
den Minutenbereich, oder schlimmer.

das es so extrem wird, ist mir neu

.Schuld soll das TRUNC()

sein (hab ich gehört), das bei 8i problematisch sein soll.

trunc war schon immer „problematisch“

Ohne das trunc() in der where-Klausel ist die Performace gut,
also im Sekundenbereich.

genau DAS kann ich mir irgendwie nicht erklären

Kennt jemand das Problem? Gibt es eine Lösung/Workaround?

du kannst es ja versuchen, indem du das trunc(sysdate,[FORMAT]) in eine variable reingibst, die du dann anstelle des trunc ins select-statement übernimmst

grüße,
tomh

by the way: das between ist auch ein ganz gehöriger performance-killer

[Nic_21cf50]

Hi tomh,

ja, das mit der Variable wollte ich auch mal versuchen.
Oder eine temporäre Hilfstabelle mit einer Spalte und einem Satz, die beim login gefüllt wird.

Benutzt du das between nicht? Nimmst du lieber = ?
Ich habe das bestimmt an 1000 Stellen verbaut. F**k.

Danke auf jeden Fall
Nic

[Tomh]

hi!

Benutzt du das between nicht? Nimmst du lieber = ?
Ich habe das bestimmt an 1000 Stellen verbaut. F**k.

g’hupft wie g’hatscht - ein between ist ja nix anderes als ein =, „früher“ benutzte ich die größer-kleiner operatoren, da ich mir einbildete, daß die schneller sind (zur zeit, als ich ein select 2x tracen ließ, und erstaunt war, wie schnell es beim zweiten mal ging - jedoch bin ich derzeit auch aufs between umgestiegen - weil’s weniger schreibarbeit ist

so wurde aus einem
where (trunc(von) = trunc(sysdate) or bis is null)

ein

where trunc(sysdate) between trunc(nvl(von,sysdate)) and trunc(nvl(bis,sysdate))

-> beides gleich „langsam“ … und wie ich jetzt grad sehe, beinahe überhaupt keine schreibersparnis *grmpf*

grüße,
tomh

ps: mit variablen ist es zwar noch mehr schreibaufwand, dafür wesentlich performanter …

[TheBeast]

Hallo Oracle-Experten,

select …
from…
where
trunc(sysdate,‚dd‘) between VON and BIS

Bei mehreren tausend Sätzen steigt die Laufzeit plötzlich in
den Minutenbereich, oder schlimmer. Schuld soll das TRUNC()
sein (hab ich gehört), das bei 8i problematisch sein soll.
Ohne das trunc() in der where-Klausel ist die Performace gut,
also im Sekundenbereich.

Kennt jemand das Problem? Gibt es eine Lösung/Workaround?

Vielen Dank
Nic

Hallo Nic!

Falls du Zugang zu Metalink hast sieh dir mal Doc 57838.996 an. Das Problem ist, dass durch den TRUNC() ein eventuell vorhandener Index nicht mehr verwendet werden kann (ausser ein function-based Index). Mit TO_CHAR sollte sich das Problem umgehen lassen.

Gruß,
TheBeast

[Tomh]

hi!

Falls du Zugang zu Metalink hast sieh dir mal Doc 57838.996
an. Das Problem ist, dass durch den TRUNC() ein eventuell
vorhandener Index nicht mehr verwendet werden kann (ausser ein
function-based Index). Mit TO_CHAR sollte sich das Problem
umgehen lassen.

hm, so wie ich das dokument und das problem verstehe, wird’s wohl kaum einen index auf sysdate geben … aber ev. wäre es einen versuch wert, auf die datums-bereich (von-bis) jeweils einen index zu legen (warum fiel mir das nicht eigentlich nicht schon vorher ein???)

grüße,
tomh

ps: seit gestern bin ich am durchstöbern des metalinks bzgl. replication und stöbere sämtliche dokumente durch - weiß vielleicht irgendwer eines, daß einen schönen strukturierten (technischen) ablauf wiedergibt, wie ich so eine f**king replikation erstelle? (theoretisches verkaufsgefasel hab ich schon zur genüge gefunden)

[TheBeast]

Hallo tomh!

hm, so wie ich das dokument und das problem verstehe, wird’s
wohl kaum einen index auf sysdate geben … aber ev. wäre es
einen versuch wert, auf die datums-bereich (von-bis) jeweils
einen index zu legen (warum fiel mir das nicht eigentlich
nicht schon vorher ein???)

Hast recht, ich habe übersehen, dass nur sysdate, nicht aber die beiden Tabellenspalten „getrunct“ werden.

ps: seit gestern bin ich am durchstöbern des metalinks bzgl.
replication und stöbere sämtliche dokumente durch - weiß
vielleicht irgendwer eines, daß einen schönen strukturierten
(technischen) ablauf wiedergibt, wie ich so eine f**king
replikation erstelle? (theoretisches verkaufsgefasel hab ich
schon zur genüge gefunden)

Was hast denn vor (etwas genauer, meine ich)?

Gruß,
TheBeast

[Tomh]

hi!

ps: seit gestern bin ich am durchstöbern des metalinks bzgl.
replication und stöbere sämtliche dokumente durch - weiß
vielleicht irgendwer eines, daß einen schönen strukturierten
(technischen) ablauf wiedergibt, wie ich so eine f**king
replikation erstelle? (theoretisches verkaufsgefasel hab ich
schon zur genüge gefunden)

Was hast denn vor (etwas genauer, meine ich)?

eine ganz _normale_ replikation: master-db, „slave“-db: nur die stammdaten werden bei änderung von einer in die andere db reingeschaufelt (hab mittlerweile zumindest in den tech-docs was gefunden)

grüße,
tomh

[TheBeast]

Hallo tomh!

eine ganz _normale_ replikation: master-db, „slave“-db: nur
die stammdaten werden bei änderung von einer in die andere db
reingeschaufelt (hab mittlerweile zumindest in den tech-docs
was gefunden)

Klingt eigentlich nach einer klassischen Anwendung für materialized views, ob read-only oder updateable (writeable kann man hier ja eher ausschliessen, oder?) musst du natürlich selbst entscheiden. Im Fall einer read-only replication ist das Konzept ja relativ einfach: Die Master-Site hält die Daten und entscheidet (per Trigger) wann die Slave-Daten aktualisiert werden müssen. Konflikte können eigentlich nur beim Löschen oder beim Ändern eines Primary Key entstehen, wenn es auf der Slave-Instance Daten gibt, die den ursprünglichen Satz referenzieren. Die Konfliktbehebung sollte aber hier immer noch recht einfach zu beheben sein.
Bei updateable MV’s gibt’s dann die volle Latte an Synchronisationsproblemen (update-update/update-delete/insert-insert). Ich persönlich finde allerdings die Doku von Oracle 9.2 („Advanced Replication“) durchaus hilfreich, auch wenn man sich dabei durch den ganzen Multi-Master Krams durchlesen muss (solltest du nicht überspringen, auch wenn du eine reine Master-Slave Repl. brauchst, weil da auch für deinen Fall hilfreiche Hinweise drinstehen).
Was ich auch gerne mache: Ich verwende die Oracle Tools (in dem Fall den Enterprise Manager) um mir einen Testfall zusammenzubasteln und sehe dann nach (weil der ja auch nur mit Wasser kocht), was er für Aktionen setzt, die ich dann (meist leicht modifiziert) in eigene SQL Scripts einbaue.

Allzu hilfreich war ich wohl nicht, aber vielleicht kann ich DIr ja bei konkreten Fragen noch den einen oder anderen Tipp geben.

Gruß,
TheBeast

[Tomh]

hi beast!

Klingt eigentlich nach einer klassischen Anwendung für
materialized views

aaaargh - ich hoffte, ich könnte dieses thema umgehen (es sind reine read-only-stammdatentabellen; änderungen sind nur in der master-db erlaubt)

Im Fall einer read-only replication ist
das Konzept ja relativ einfach: Die Master-Site hält die Daten
und entscheidet (per Trigger) wann die Slave-Daten
aktualisiert werden müssen. Konflikte können eigentlich nur
beim Löschen oder beim Ändern eines Primary Key entstehen,
wenn es auf der Slave-Instance Daten gibt, die den
ursprünglichen Satz referenzieren. Die Konfliktbehebung sollte
aber hier immer noch recht einfach zu beheben sein.

pk’s dürfen grundsätzlich nicht geändert werden (id’s per sequences)

Bei updateable MV’s gibt’s dann die volle Latte an
Synchronisationsproblemen
(update-update/update-delete/insert-insert).

brauch ich zum glück nicht …

Ich persönlich
finde allerdings die Doku von Oracle 9.2 („Advanced
Replication“) durchaus hilfreich, auch wenn man sich dabei
durch den ganzen Multi-Master Krams durchlesen muss (solltest
du nicht überspringen, auch wenn du eine reine Master-Slave
Repl. brauchst, weil da auch für deinen Fall hilfreiche
Hinweise drinstehen).

da bin ich grad dabei, hab aber eine 8.1.6er-db als master-db und eine 8.1.7.1 als slave-db - ich muß erst rausfinden, ob das überhaupt zusammenfunktioniert *hoff*

Was ich auch gerne mache: Ich verwende die Oracle Tools (in
dem Fall den Enterprise Manager) um mir einen Testfall
zusammenzubasteln und sehe dann nach (weil der ja auch nur mit
Wasser kocht), was er für Aktionen setzt, die ich dann (meist
leicht modifiziert) in eigene SQL Scripts einbaue.

ich HASSE den enterprise- und alle anderen „manager“ (dürfte an meiner java-allergie liegen

Allzu hilfreich war ich wohl nicht

doch, doch - immerhin weiß ich jetzt, wo ich nachschaun muß/kann

, aber vielleicht kann ich
DIr ja bei konkreten Fragen noch den einen oder anderen Tipp
geben.

ich schick dir die exports und du machst mir schnell die replikation?

grüße,
tomh

ps: catrep ist bereits korrekt ausgeführt *hurrrrrra* (ist bei äußerst vielen oracle-installationen nicht immer so, daß der erste schritt fehlerfrei durchgeführt wird

[TheBeast]

hi beast!

Klingt eigentlich nach einer klassischen Anwendung für
materialized views

aaaargh - ich hoffte, ich könnte dieses thema umgehen (es sind
reine read-only-stammdatentabellen; änderungen sind nur in der
master-db erlaubt)

Na dann isses ja einfach . Wirst sehen Materialized Views sind gar net so schlimm (der alte Ausdruck Snapshot könnte Dir übrigens u.U. beim Suchen in der Doku helfen). Natürlich kann man den ganzen Käse auch händisch machen, aber das halte ich für weitaus aufwändiger (und vermutlich weniger sicher und/oder weniger performant, hab’s aber noch nicht ausprobiert).

hab eine 8.1.6er-db als master-db
und eine 8.1.7.1 als slave-db - ich muß erst rausfinden, ob
das überhaupt zusammenfunktioniert *hoff*

Weis ich leider auch nicht…

Was ich auch gerne mache: Ich verwende die Oracle Tools (in
dem Fall den Enterprise Manager) um mir einen Testfall
zusammenzubasteln und sehe dann nach (weil der ja auch nur mit
Wasser kocht), was er für Aktionen setzt, die ich dann (meist
leicht modifiziert) in eigene SQL Scripts einbaue.

ich HASSE den enterprise- und alle anderen „manager“ (dürfte
an meiner java-allergie liegen

Da kann ich Dir nur recht geben, die Dinger sind durch die Bank benutzerunfreundlich und noch dazu schweinisch langsam. Ich frag’ mich immer wieder, warum Oracle überhaupt irgendwelche Tools mitliefert. Allein das SQL-Worksheet ist ja einer der miesesten SQL-Clients, die am Markt erhältlich sind.
Die von mir angesprochene Vorgangsweise habe ich allerdings z.B. verwendet, um mir mal (vom DB-Manager) eine Instance anlegen zu lassen, dann hab’ ich mir die verwendeten Scripts angeschaut und meinen Bedürfnissen angepasst. Die angepassten Scripts starte ich jetzt aus einem Batch direkt mit SQL*Plus (Command line), seither kann man das Ganze auch in einer _vernünftigen_ Zeit machen.

, aber vielleicht kann ich
Dir ja bei konkreten Fragen noch den einen oder anderen Tipp
geben.

ich schick dir die exports und du machst mir schnell die
replikation?

OK, wann soll’s denn fertig sein (so 10 Minuten oder so brauch ich schon) *lol*

Gruß,
TheBeast

[Tomh]

hi!

kurzer zwischenstand:

alles verlief anständig; werd wohl doch mit materialized views („snapshot“ war einfacher auszusprechen arbeiten - nur zwei oracle bugs machten mir kurz zu schaffen (vielleicht schaff ich’s doch heute noch, die replikation zu starten

grüße und danke,
tomh

ps: „global_names=true“ - der schrecken aller kraut-und-rüben-vernetzten

[Tomh]

*verzweiflung*

snapshots funktionieren nicht, da es felder in den zu replizierenden tabellen gibt, die in der ziel-db beibehalten werden sollten (ich war schon kurz vor meiner 1. replizierung, als dieses problem auftauchte)

nun: wie gebe ich dem master bekannt, was repliziert werden soll (genauso wie bei snapshots?) UND wie erklär ich das dann der 2.„master“ (der ursprünglich ein snapshot-slave war)?

dbms_repcat…??

(eine enterprise-manager-installation schwirrt mir ständig bei 96% ab)

verzweifelnde grüße,
tomh