Fehler beim Start des integrierten WebLogic Servers vom JDeveloper unter Windows 7

Ich hatte bereits in einem vorherigen Post eine Möglichkeit beschrieben, wie vorgegangen werden kann, falls sich der lokale WebLogic Server unter Windows 7 nicht mehr vom JDeveloper aus starten lässt. Die ursprüngliche Lösung hatte den Nachteil, dass der Zwischenschritt über das Deployment der .ear Datei nötig war.

Eine weitere Lösungsmöglichkeit stellt das setzen einer neuen JDeveloper Home Variable dar. Dies kann ganz einfach über zwei Wege gemacht werden.

1.  Setzen der Systemvariable JDEV_USER_DIR:
   
   Start -> Rechtsklick Computer -> Eigenschaften
   

   ErweiterteSystemeinstellungen im linken Bereich

   

    Umgebungsvariablen...
   

   

    Im Bereich Benutzervariablen -> Neu...
   

   

   
   

   Wert der Variablen entspricht dem Pfad zum gewünschten Verzeichnis (um den Fehler zu umgehen sollte ein Pfad ohne Leerzeichen und Sonderzeichen gewählt werden)

   

   
   

   
   
2. Starten des JDeveloper Mittels Kommandozeilenparameter:
   
   
   Rechtsklick auf Verknüpfung -> Eigenschaften
   
   
   
   Einfügen des Parameters -J -Dide.user.dir="Pfad zum gewünschten Verzeichnis"
   
   
   

Der Vorteil der unteren Variante ist sicherlich, dass die Variable nicht für alle installierten JDeveloper Versionen allgemeingültig ist, sondern nur eine Instanz abdeckt, während erstere Variante eine Variable schreibt, die im Standardfall von allen JDeveloper Versionen ausgelesen wird. Will man dies unterdrücken, kann in der JDeveloper boot Datei ($JDEV_HOME/jdev/bin/jdev.boot) der Wert entsprechend geändert werden.

In dem nun gesetzten User Dir wird eine neue Instanz des integrierten WLS installiert, welcher sich nun auch wieder über den JDeveloper starten lassen sollte.

Data Pump Export mit Flashback-Zeit über Enterprise Manager

Im Database Control einer 11.2.0.2 Datenbank habe ich versucht einen lesekonsistenten Data Pump Export auf eine Flashback-Zeit als Job zu konfigurieren. Dabei bin ich auf zwei Probleme getroffen:

1. Bei der Auswahl der Flashback-Zeit kann keine volle Stunde gewählt werden, da als Minuten 5 bis 60 in Fünferschritten angeboten werden. 00 Minuten fehlen und 60 Minuten ist ja Unsinn bei einer Zeitangabe. Siehe auch folgenden Bildschirmabzug:
   
2. Wenn eine sinnvolle Flashback-Zeit (z.B. 11.03.2013 15:05 Uhr) angegeben ist, dann führt das Weiterleiten des Jobs zum Fehler ORA-39001, ORA-39150, ORA-08186:
    

Den ersten Fehler kann ich in anderen Installationen (10gR2, 11gR1 und 11gR2) nicht nachvollziehen. Das kann also eventuell an einer ungünstigen Kombination der NLS Parameter liegen.

Den zweiten Fehler habe ich auch in anderen Installationen, so auch beim Database Control einer 10.2.0.3 Datenbank als auch im Grid Control 11g bei einer 11.1.0.7 und einer 11.2.0.1 Datenbank. Das scheint also ein Bug zu sein.
Der eigentliche Fehler ORA-08186 resultiert aus dem generierten Data Pump Script, speziell aus der folgenden Zeile:
  dbms_datapump.set_parameter(handle => h1, name => 'FLASHBACK_TIME', value => '11-03-13 15.05');
Es wird implizite und keine explizite Typkonvertierung durchgeführt. Das Format der Datum/Zeitangabe, endspricht nicht dem Default. Dieser kann ermittelt werden mit dem folgenden Select (siehe MOS Note ID 464132.1):
  SELECT * FROM V$NLS_PARAMETERS where parameter = 'NLS_TIMESTAMP_FORMAT';
In meinem Fall ist das Ergebnis:
  PARAMETER VALUE
  NLS_TIMESTAMP_FORMAT DD.MM.RR HH24:MI:SSXFF
Das Format entspricht der deutschen Territory Einstellung. Diese wird aber weder im Database Control noch im Grid Control berücksichtigt.

Wenn man den Data Pump Export mit Flashback-Zeitpunkt über den Enterprise Manager machen möchte, bleibt also nichts anderes übrig als einen manuellen SQL-Skript Job anzulegen und darin dann entweder den Zeitpunkt im zum Default korrekten Format anzugeben oder aber eine explizite Typkonvertierung durchzuführen, z.B.:
  dbms_datapump.set_parameter(handle => h1, name => 'FLASHBACK_TIME', value => '11.03.13 15:00:00');

Ich hoffe diese Information hilft anderen bei der Problemanalyse.

Neue Veranstaltungsreihe zum Thema "Oracle Hardware und Software"

Die Produktstrategie von Oracle bietet Unternehmen eine hohe Flexibilität und Auswahl für die gesamte IT-Infrastruktur. Dabei ist es nicht ganz leicht den Überblick über die verschiedenen Möglichkeiten zu behalten. Deswegen hat TEAM in Zusammenarbeit mit Oracle eine kostenlose Veranstaltung ins Leben gerufen, die Interessierten den Einstieg in die Hardware-Welt von Oracle erleichtern soll. 

Die Veranstaltung soll zunächst einen Überblick über die verschiedenen Einstiegsmöglichkeiten bieten. Von der Standardlösung mit Oracle on Oracle, über spezielle Lösungen für den Mittelstand bis hin zu Highend-Lösungen mit Oracle Exadata - alle Modelle werden anschaulich und von den Oracle-Experten erklärt. 

Melden Sie sich doch gleich unter www.team-pb.de/Hardware-Software zu der kostenlosen Veranstaltung in Düsseldorf (14.02.) oder Paderborn (21.02.) an. Weitere Informationen und die Agenda der Veranstaltung finden Sie hier.

Melden Sie sich jetzt an unter: www.team-pb.de/Hardware-Software

Oracle Text Composite Domain Index

Bei Nutzung der Oracle Text Volltextsuche kann es oft vorkommen, dass in der WHERE-Bedingung eines SQL-Query sowohl gegen die indizierte Textspalte (mit CONTAINS), als auch gegen eine oder mehrere normale relationale Spalten gefiltert wird, man also eine gemischte Abfrage oder auch „Mixed Query“ hat. Eine solche Abfrage ist womöglich nicht optimal, da sie zu Performanceproblemen führen kann. Was ist in einem solchen Fall zu tun?

Seit Oracle 11g kann man unter Verwendung von z.B. Multi-Column-Datastores, die zusätzlich die relationalen Spalten enthalten, sowie passenden SDATA-Sections die strukturellen Informationen mit in den Volltextindex holen. Die relationalen Abfragen werden dann mit dem SDATA-Operator innerhalb des CONTAINS ausgeführt.

Diese Vorgehensweise hatte bei einem Kunden nicht zum erwünschten Erfolg geführt, was mich zu einer anderen Maßnahme greifen liess:

Ebenfalls seit Oracle 11g gibt es noch eine weitere Möglichkeit, mit „Mixed Queries“ umzugehen: Den Composite-Domain-Index (CDI). Hierbei kann man sich das Anlegen des Multi-Column-Datastore und der SDATA-Sections sparen. Man gibt einfach beim Anlegen des Volltext-Indexes die entsprechenden Where-Filter-Spalten als FILTER BY Spalten und/oder die entsprechenden Sortier-Spalten als ORDER BY Spalten an. An der Struktur, die der Index anlegt kann man erkennen, dass hier im Hintergrund eine SDATA-ähnliche Technik arbeitet.

CREATE INDEX mein_index ON meine_tabelle(meine_textspalte)    INDEXTYPE IS ctxsys.context    FILTER BY suchspalte1, suchspalte2, ...    ORDER BY sortierspalte1, sortierspalte2, ...

Dies brachte eine deutliche Performance-Verbesserung gegenüber der „manuellen“ SDATA-Anwendung. Ein weiterer Vorteil: Man muss die SQL-Queries nicht umstellen, die relationalen Abfragen werden bei Verwendung eines CDI wie gehabt verwendet und müssen nicht mit in den CONTAINS-Ausdruck.