Sep 29
Hat man sich beim Programmieren auf ein Backend (sprich Datenbank) festgelegt, so kann man beim Programmieren bereits dort einige Aufgaben erledigen lassen.
Ein gutes Beispiel ist dafür die Datumsberechnung. Was in Java ein “Krampf” ist, lässt sich bei Oracle sehr einfach in der Datenbankanfrage (mittels SQL) erledigen.
Möchte man zum Beispiel die Zeitdifferenz von heute bis zum Monatsende ermitteln, wäre folgender Lösungsansatz möglich:
SELECT SYSDATE "heute",
LAST_DAY(SYSDATE) "Monatsende",
LAST_DAY(SYSDATE) - SYSDATE "Tage bis zum Monatsende"
FROM DUAL;
heute Monatsen Tage bis zum Monatsende
-------- -------- -----------------------
29.09.09 30.09.09 1
Einziger Nachteil, die SQL Funktion last_day steht nicht in jedem Datenbanksystem zur Verfügung.
Hat man sich beim Programmieren auf ein Backend (sprich Datenbank) festgelegt, so kann man beim Programmieren bereits dort einige Aufgaben erledigen lassen.
Ein gutes Beispiel ist dafür die Datumsberechnung. Was in Java ein "Krampf" ist, lässt sich bei Oracle sehr einfach in der Datenbankanfrage (mittels SQL) erledigen.
Möchte man zum Beispiel die Zeitdifferenz von heute bis zum Monatsende ermitteln, wäre folgender Lösungsansatz möglich:
SELECT SYSDATE "heute",
LAST_DAY(SYSDATE) "Monatsende",
LAST_DAY(SYSDATE) - SYSDATE "Tage bis zum Monatsende"
FROM DUAL;
heute Monatsen Tage bis zum Monatsende
-------- -------- -----------------------
29.09.09 30.09.09 1
Einziger Nachteil, die SQL Funktion last_day steht nicht in jedem Datenbanksystem zur Verfügung.
Ähnliche Artikel:
geschrieben von gklinkmann
\\ tags: Oracle
Sep 16
Eine der besten Eigenschaften der Oracle Datenbank ist die Möglichkeit zwei von einander entfernte Datenbanken über einen DB Link zu koppeln.
So sind Abfragen auf entfernten Tabelle kein Problem:
SELECT * FROM tabellenname@dblinkname;
Was ich bis heute nicht wusste ist, dass dies nur funktioniert solange in der Tabelle keine Lobs (Spalten vom Typ clob oder blob) enthalten sind. Wenn man es trotzdem tut, bekommt man einen ORA-22992 cannot use LOB locators selected from remote tables.
Laut Oracle sind mit entfernten Lobs nämlich nur folgende Statements erlaubt:
CREATE TABLE t AS SELECT * FROM table1@remote_site;
INSERT INTO t SELECT * FROM table1@remote_site;
UPDATE t SET lobcol = (SELECT lobcol FROM table1@remote_site);
INSERT INTO table1@remote_site ...
UPDATE table1@remote_site ...
DELETE FROM table1@remote_site ...
Verboten sind dagegen:
SELECT lobcol FROM table1@remote_site;
INSERT INTO lobtable SELECT type1.lobattr FROM
table1@remote_site;
SELECT DBMS_LOB.getlength(lobcol) FROM table1@remote_site;Was kann man tun?
Bei Binary Lobs (z.B. Bildern) hat man aus meiner Sicht keine andere Möglichkeit als sie sich mit den o.a. Statements (create as, update) in die lokale Datenbank zu kopieren.
Für den lesenden Zugriff auf Character Lobs (z.B. lange Texte) kann es ausreichen, die Daten auf der entfernten Datenbank mittels einer Funktion in den Datentyp varchar2 umzuwandeln und über eine View, die diese Funktion benutzt nach außen zu kapseln. Das könnte so aussehen:
entfernte Datenbank:
CREATE OR REPLACE VIEW viw_clob_tabelle
AS
SELECT spalte1
, dbms_lob.substr(clobSpalte,4000,1) clobText
FROM clobTabelle;
lokale Datenbank:
SELECT spalte1 , clobText FROM viw_clob_tabelle@dblinkname;
Allerdings werden dabei nur die ersten 4000 Zeichen des CLOB’s gelesen, da dass die Längenbeschränkung vom Datentyp varchar2 ist, der von dbms_lob.substr zurückgegeben wird. Aber oft reicht dies aus.
Eine der besten Eigenschaften der Oracle Datenbank ist die Möglichkeit zwei von einander entfernte Datenbanken über einen DB Link zu koppeln.
So sind Abfragen auf entfernten Tabelle kein Problem:
select * from tabellenname@dblinkname;
Was ich bis heute nicht wusste ist, dass dies nur funktioniert solange in der Tabelle keine Lobs (Spalten vom Typ clob oder blob) enthalten sind. Wenn man es trotzdem tut, bekommt man einen ORA-22992 cannot use LOB locators selected from remote tables.
Laut Oracle sind mit entfernten Lobs nämlich nur folgende Statements erlaubt:
CREATE TABLE t AS SELECT * FROM table1@remote_site;
INSERT INTO t SELECT * FROM table1@remote_site;
UPDATE t SET lobcol = (SELECT lobcol FROM table1@remote_site);
INSERT INTO table1@remote_site ...
UPDATE table1@remote_site ...
DELETE FROM table1@remote_site ...
Verboten sind dagegen:
SELECT lobcol FROM table1@remote_site;
INSERT INTO lobtable SELECT type1.lobattr FROM
table1@remote_site;
SELECT DBMS_LOB.getleng
Ähnliche Artikel:
geschrieben von gklinkmann
\\ tags: Oracle
May 07
Der Unix Timestamp (der in vielen Applikationen benutzt wird) und Oracles Datums Format sind leider sehr unterschiedlich. Während Unix die Sekunden ab dem 01.01.1970 zählt, beginnt bei Oracle die Zeitrechnung schon 4000 vor Christi Geburt. Ca. 2 mal im Jahr brauche ich diese Umrechnung und jedes Mal frage ich mich, wie war das noch. Heute ist es mir einen Blogeintrag wert.
Es gibt verschieden Ansätze um vom Unix Timestamp zum Oracle Date Format zu gelangen. Hier sind 2 zur Auswahl:
SELECT to_char(TO_DATE('19700101000000','YYYYMMDDHH24MISS')
+ NUMTODSINTERVAL(1094165422, 'SECOND'), 'dd.mm.yyyy hh24:mi') datum
FROM dual;
02.09.2004 22:50Eine fertige Funktion mit Fehlerbehandlung gibt es hier.
Fragt man Tom auf asktom.oracle.com, so findet man dort auch für verschiedene Zeitzonen eine Lösung:
-- normal
SELECT to_char(to_date('01011970','ddmmyyyy')
+ 1/24/60/60 * 1094165422, 'dd.mm.yyyy hh24:mi' ) FROM dual
02.09.2004 22:50
-- mit abweichender Zeitzone
SELECT to_char(new_time( to_date('01011970','ddmmyyyy')
+ 1/24/60/60 * 1094165422,'GMT', 'EDT' ), 'dd.mm.yyyy hh24:mi' ) FROM dual
02.09.2004 18:50geschrieben von gklinkmann
\\ tags: Linux, Oracle
