Dieser Beitrag stellt einige wichtige Hinweise für eine Neuinstallation, das Patchen oder den Releasewechsel zur Verfügung.

Für weitere Details gibt es die ORACLE Dokumentation oder einige gute Blogs im Internet.

Neuinstallation

ORACLE Repository Creation Utility (RCU)

Vor der ORACLE BI EE Installtion muss das ORACLE BI Metadaten-Repository über den RCU Installer auf einer Datenbank installiert werden. 
Wird das Repository in eine ORACLE DB mit 8K Blöcken installiert, so kann das RCU zwei Indizes nicht anlegen.
Dies kann man bedenkenlos im Assistent igonorieren oder im SQL-Skript auskommentieren. Eine Installation auf einer ORACLE DB mit 16K 
Blöcken funktioniert ohne Fehler.

ORACLE BI Setup

Die Installation der ORACLE BI EE Suite ist eine relativ einfache Angelegenheit. 
Nach dem Aufruf der Setup Datei leitet ein Assistent durch die Installation.

Bei der Auswahl der Komponenten (z.B. Real-Time Decision), Lizenzen beachten!

Eine wichtige Entscheidung die bei der Installation getroffen werden muss ist, ob man sich für eine Einfache Installation (Simple Install) oder 
eine Enterprise(Enterprise Install) entscheidet.

Enterprise(Enterprise Install)
Sieht die Planung ein für die Zukunft skaliebares ORACLE BI EE Landschaft vor, empfiehlt sich die Enterprise Installation. Bei der Enterprise Installation wird im Weblogic-Server für die Anwendung ein 
eigener Managed Server angelegt. In Weblogic gibt es dann den Administration Server (der ja auch wie ein Managed Server behandet wird) und für die ORACLE BI EE Domäne einen Managed Server. Der Vorteil ist, 
dass es leichter möglich ist die ORACLE BI Domäne zu Clustern. Ein zweiter Vorteil liegt beim Versions-Upgrade. ORACLE liefert nur für die Enterise Installation eine Upgrade Dokumentation.

Einfache Installation (Simple Install)
Die einfache Installation sollte für single Server mit wenig Ressourcen verwendet werden, z.B. zur Demonstration (PC's und Notebooks) oder für die Entwicklung. In Weblogic wird die ORACLE BI Domäne in den Administrations Server installiert.
Das hat für die Funktionalität und Stabilität keinen Nachteil. Beim Versions-Upgrade ist es am einfachsten eine Neu-Installation durchzuführen und den Katalog, Messages (Mehrsprachigkeit), das Repository in die neue 
Installation zu kopieren, die Konfigurationseinträge (z.B. NQSConfig.ini und instanceconfig.xml) manuell nachtragen und ggf. das Custom Layout neu zu deployen. Das hört sich sehr aufwendig an, dauert bei 
guter Dokumention genauso lange wie der Upgrade bei einer Enterprise Installation und man hat erstmal ein sauberes System.

Patch (11.1.1.7 -> 11.1.1.7.131017)

Ein Patch beinhaltet Fehlerkorrekturen, kleinere Verbesserungen und Funktionalitäten.

Das einspielen eines Patchset ist doch relativ unkompliziert. In der mitgelieferten Readme Datei steht detailiert drin wie das Patch eingespielt werden muss.

Da ein Patchset in der Regel auf mehreren Patches besteht, empfielt sich zur Vereinfachung folgendes Vorgehen:

1) Patch Install Verzeichnis anlegen, z.B. C:\Install_Files_OBI\OBIEE_11.1.1.7\PATCH\17530796 für Patchset 17530796

2) Umgebungsvariablen setzen, das ORACLE_HOME ist individuell zu setzen

set PATCH_FOLDER=C:\Install_Files_OBI\OBIEE_11.1.1.7\PATCH\17530796
set ORACLE_HOME=D:\oracle\middleware\Oracle_BI1
set JAVA_HOME=%ORACLE_HOME%\jdk
set PATH=%ORACLE_HOME%\OPatch;%JAVA_HOME%\bin;%ORACLE_HOME\bin%;%PATH%

3) mit OPATCH alle PAtches auf einmal einspielen

opatch napply -silent %PATCH_FOLDER% -id 16913445,17463314,17300417,17463395,17463376,17300045,16997936,17463403

4) mit OPATCH lsinventory die korrekte Installation prüfen

5) entsprechend der Redme Datei die manuellen Post-Installation Schritte durchführen

Releasewechsel (11.1.1.6 -> 11.1.1.7)

Ein neues Release beinhaltet Fehlerkorrekturen und viele neuen Features. Das Einspielen eines neuen Release lohnt sich in der Regel, stellt aber auch eine größere Herausforderung da.

Es gibt zwei Möglichkeiten für eine Enterprise Installation einen Release-Wechsel durchzuführen

1) komplette Neu-Installation (für eine Simple Installation zwingend erforderlich)

Vorgehen:

1) Dienste alle runterfahren

2) altes Middleware Verzeichnis umbenennen, z.B. middelware_save

3) Deinstallation

4) Neuinstallation

5) Katalog, Repository aus dem Sicherungsverzeichnis zurückkopieren

6) Konfigurationsdateien basierend auf den Ursprünglichen Konfig-Dateien manuell anpassen (nicht kopieren)

7) Deployments neu durchführen

2) Upgrade bzw. Migration

Vorgehen:

siehe Dokumentation ORACLE

Vom zeitlichen Aufwand liegen beide auf gleicher Höhe, allerdings kommt es schon darauf an wieviel manuelle Änderungen und Deployments gibt es und sind diese gut dokumentiert.

Für eine im Cluster betriebene Installation ist die Migration der beste Weg, für eine single Node Installation muss man abwägen und für eine Simple Installation ist eine Neu-Installation ein muß.

Wichtig: Es sollte immer sichergestellt werden, dass eine Backup und ein Fallback-Plan existiert.