Langsam, aber sicher, kommen die gewünschten Effekte bei der HDR Fotographie. Ja, ich weis, es ist noch Verbesserungsfähig, aber immerhin. Sieht aber doch schon ganz nett aus. Was mir irgendwie die ganze Zeit fehlt, ist ein vernünftiges Tutorial. Kennt da jemand was ?
Der Sommer ist da ? Also so dermassen wie hier alles am Blühen ist, kommt da meiner bescheidenen Meinung nach kein Schnee oder so etwas hinterher. Ich denke das Bild spricht für sich.
Oracle-Jobs via DBMS_JOB sind eine feine Sache. Würde nur nicht das Intervall erst am Ende, also nach der Ausführung des Jobs, gesetzt werden.
Das nervt. Also wenn man einen Job hat, der sagen wir alle 10 Minuten laufen soll, so verschiebt sich die Ausführung grundsätzlich um die Zeit, die der Job selbst zur Abarbeitung benötigt. Das heisst, bei einem 60sek. Job, der via Intervall “sysdate+(1/1440)” alle 10min laufen soll, und um, sagen wir 10:10 das erste mal rennt, beginnt dieser die nächsten Ausführungen um 10:21, 10:32 usw…
Abhilfe schafft ein wenig Mathematik im Intervall:
Man nehme:
to_date(
floor(
to_number(
to_char(sysdate,’YYYYMMDDHH24MI’)
)/10
)*10,’YYYYMMDDHH24MI’
)+10/1440
Was passiert hier ?
– Das Datum wird MSB -> LSB geholt und durch 10 geteilt. Bedeutet die “Minute” steht hinter dem Komma.
– Jetzt nutzen wir “FLOOR” um alles hinter dem Komma auf “0” zu setzen.
– Das ganze wieder mal 10 nehmen, um die 0 vor das Komma zu bekommen
– Jetzt noch in ein Datum konvertieren und das 10min. Intervall (+(10/1440)) draufschlagen
– Fertig.
Doch Vorsicht: Bei Jobs die länger als 10min. laufen, könnte das nächste Intervall in der Vergangenheit liegen ;-(
Böse Böse …
Ein netter Tip, der da von Muniqsoft publiziert wurde.
Kurzfassung: Mit Hilfe einer Materialized View, die “on Commit” refreshed wird, und auf die dann via “Query rewrite” zugegriffen wird, grosse Aggregationen etwas zügiger von Statten gehen zu lassen.
Irgendwie ging der Schuss bei mir allerdings VOLL nach hinten los. Die gute DB hat, gemäss Ihrem Auftrag, fein bei jedem Commit einen FULL TABLE SCAN (auf ‘ne halbe Mio. Rows) durchgeführt und damit die DB extremst in die Tiefe gezogen… Na super. Droppen liess sich das gute Stück auch nicht mehr, weil: War ja gelocked durch das andauernde Commit der User 😉
Was lernen wir daraus: Nicht alles was gut aussieht, tut auch gut…
