Schlagwort-Archive: unbekannt oder unterbewertet

NVL-st Du noch oder COALESCE-t Du schon?

NULL-„Werte“ an sich können dem DB-Entwickler genug Kopfzerbrechen bereiten, um alleine damit ganze Artikelserien zu füllen. Hier möchte ich mich lediglich auf einen kleinen Ausschnitt der Problematik beschränken, nämlich der Performance beim Vergleichen und Ersetzen von NULLs. Zum Ersetzen von NULLs in Abfragen wird zumeist die Funktion NVL() verwendet. Diese Funktion hat jedoch zwei entscheidende Nachteile:

  1. Sie bietet nur die Möglichkeit, genau einen Ausdruck mit einem anderen zu ersetzen. Will man mehr als zwei Ausdrücke gegeneinander vergleichen, muss die Funktion kaskadiert werden.

  2. Der zweite Ausdruck wird immer ausgewertet, auch dann, wenn der erste Ausdruck bereits NOT NULL ist.

Weiterlesen

Werbeanzeigen

DOAG2011 – Addenda

Sodele, eine interessante DOAG-Konferenz liegt hinter mir, und in der Nachbetrachtung meines Vortrages „Oracle Old Features“ ist mir aufgefallen, daß in den Unterlagen die Quellen- und Literaturhinweise fehlten. Diese möchte ich hier nachliefern, und zwar umfangreicher als geplant.
Wer nicht auf der Konferenz war und daher auch nicht die Vortragsunterlagen herunterladen kann: Nicht traurig sein, ich werde in diesem Blog noch einiges über wichtige, oft unterbewertete „Old Features“ veröffentlichen!

Constraints

Fremdschlüssel, Query Rewrite

RELY-Constraints

  • RELY wieder entfernen, bevor „enable validate“ durchgeführt wird! Siehe hier.

Deferred Constraints

COALESCE, ANSI-Joins, WITH-Clause etc.

SQL*Plus, AUTOCOMMIT und EXIT

Auch wenn das eigentlich ein Grundlagenthema sein sollte — gerade heute durfte ich selbst mal wieder erfahren, daß es folgenreiche Unterschiede zwischen dem kontrollierten Abbruch eines Skriptes in SQL*Plus und dem Abbruch einer Server-seitigen Session gibt.

Mythos: Ein „quit“ oder ein „whenever sqlerror exit“ bewirken ein Rollback beim Beenden eines Skriptes.

Tatsache: Ein „exit“ in SQL*Plus impliziert ein COMMIT und kein ROLLBACK!

Weiterlesen

Fundstück: Oracle 10.2 auf dem Commodore 64

Eigentlich will ich hier ja ausschließlich Artikel mit Praxisnutzen veröffentlichen und Scherz-, Boulevard- und Wirtschaftsmeldungen außen vor lassen. Andererseits… vielleicht verhilft diese Meldung alter Hardware nochmal zu einem Revival — in Zeiten von „Green IT“ durchaus wünschenswert:

Auszug aus dem Dokument „Oracle Database 10.2 End of Premier Support – Frequently Asked Questions (Doc ID 1130327.1)“ von Oracle Support:

8. Will I get more time to install 10.2.0.5 if it is released on my platform close to April 30, 2011?

Yes. We will always support the previous patch set for at least 3 months, even if it is released after the one year to install the new patch set is up.  For example, patching for 10.2.0.4 generally expires on April 30, 2011.  If you are running 10.2.0.4 on the Commodore 64 platform and Oracle releases it after April 30, 2011, we will still patch 10.2.0.4 for you for 3 months following the 10.2.0.5 release on your platform.

Also dann: Holt den C64 vom Dachboden, da geht noch was! :-)

Vielleicht können wir in der Diskussion zu diesem Artikel noch klären,

  • wie man den C64 ans Internet bekommt, um das Oracle-Patch 10.2.0.5 herunterzuladen
  • wie man ein DVD-Laufwerk anschließt, um die Software von dort einzuspielen
  • wie man den C64 auf 512 MB RAM aufrüsten kann
  • wie man den SYSTEM-Tablespace auf einer 1541-Floppy unterbringt
  • und was sonst noch so an kleinen Problemchen auftauchen könnte…

Weblinks

Unbekannt oder unterbewertet: IFILE-Direktive in tnsnames.ora

Man lernt ja bekanntlich nie aus… gestern habe ich jedenfalls gelernt, daß es auch in der „tnsnames.ora“ möglich ist, eine weitere Datei einzubinden, wie das auch in der init.ora möglich ist. Der magische Parameter hierfür lautet „IFILE=<Pfad>“. Mit diesem Praxistip will ich meine Artikelreihe „Unbekannt oder unterbewertet“ beginnen.

Weiterlesen

Unix-Umgebung einrichten mit oraenv

Heute ist mir bei der Lektüre eines Leitfadens zum DB-Upgrade unter Unix ein Klassiker aufgefallen: Das Tool „oraenv“, das vielen Unix-Oraclern nicht bekannt ist oder nicht verwendet wird, weil die Systemumgebung (namentlich die Datei „oratab“) nicht richtig gepflegt ist.

Wird eine Datenbank unter Unix mit dem Database Configuration Assistant (DBCA) angelegt, dann pflegt der DBCA auch die Datei „/etc/oratab“ (auf manchen Unixen auch „/var/opt/oracle/oratab“). Diese folgt dem Format

SID:ORACLE_HOME:[Y|N]

Ist die Datei korrekt gepflegt, können alle notwendigen Umgebungsvariablen zur Benutzung weiterer Oracle-Tools wie sqlplus, expdp, impdp etc. direkt mit oraenv eingestellt werden. oraenv fragt dann nach der einzustellenden SID und – falls es diese in der oratab nicht findet – auch nach dem passenden Home-Verzeichnis.

Damit entfällt die Notwendigkeit, mit eigenen Skripten ORACLE_HOME, ORACLE_SID und PATH explizit zu setzen. Stattdessen kann jeder OS-Benutzer „. oraenv“ oder „. coraenv“ (C-Shell) aufrufen und diese Werte setzen lassen. Die Pfade einer Oracle-Installation lassen sich damit zentral in der oratab verwalten.

Soll das ganze skriptgesteuert ohne Interaktion laufen, kann die Umgebungsvariable ORAENV_ASK eingesetzt werden:

export ORACLE_SID=ORCL
export ORAENV_ASK=NO
. oraenv

Nicht davon berührt werden andere, eventuell notwendige Einstellungen, wie z.B. NLS_LANG, ORACLE_BASE oder ORACLE_ADMIN. Diese müssen weiterhin explizit gesetzt werden. Allerdings ist NLS_LANG anwendungsspezifisch und muss nicht zentral verwaltet werden. Und die beiden anderen Beispiele werden selbst bei administrativen Aufgaben eher selten benötigt.

Weblinks