Nach der Migration einer 10g-Datenbank nach 11g wurden bei mir auf einmal (ohne Parameteränderung) die Archivelogs gespiegelt.
log_archive_dest_n ist nicht gesetzt, damit wird (richtig) in db_recovery_file_dest (also in die Flash Recovery Area - FRA) archiviert - aber zusätzlich auch noch in $ORACLE_HOME/dbs!!

Im alert.log steht's:

Using LOG_ARCHIVE_DEST_1 parameter default value as /u00/app/oracle/product/11.1.0/dbs/arch
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST

Ist das nun Absicht? In der Dokumentation haben wir jedenfalls nichts darüber gefunden.

Zwei Tipps kamen von meinen Kollegen:

• Entweder Destination1 wirklich auf FRA setzen:

  ALTER SYSTEM SET log_archive_dest_1 = 'location=USE_DB_RECOVERY_FILE_DEST';
   

• Oder aber Destination1 ausschalten, indem ein Whitspace eingetragen wird (in der Doku wird dies ein Null-String genannt):

  ALTER SYSTEM SET log_archive_dest_1=' ';
   

Sollte man unbedingt beachten, damit nicht sehr schnell das ORACLE_HOME voll läuft...

... ist ab heute hier zum Download verfügbar (für Linux und Windows).

Zwei für mich sehr interessante Neuigkeiten habe ich auf Anhieb entdeckt:

• Support für 11g als Repository- und Target-Datenbank (siehe Metalink)
• Einige (mir) neue Plugins, z.B. für VMware ESX (den werde ich sicherlich mal austesten)

Das ZIP für Linux ist "nur" 1.4 GB gross...

Die 32bit Windows Version steht hier zum Download bereit.

Interessant finde ich schon, dass zuerst die Linux-Versionen, dann Windows und später irgendwann die restlichen Unix-Versionen kommen. Früher kam Windows immer viel später. Ist Microsoft für Oracle nun wichtiger geworden?

Also - happy download - wer unbedingt Windows möchte

Transparent Data Encryption wurde mit Oracle 10.2 eingeführt, hatte dort aber einige Einschränkungen:

• Es konnten nur einzelne Spalten verschlüsselt werden
• Nicht alle Datentypen konnten verschlüsselt werden (Long, LOB)
• Während Operationen waren die Daten nicht verschlüsselt, so dass eventuell unverschlüsselte und vertrauliche Daten im TEMP-Tablespace oder im REDO sichtbar waren
• Ausschliesslich B*Tree Indizes werden unterstützt (keine FBI)
• Index Range Scans werden nur bei Abfragen auf Gleichheit unterstützt
• Fremdschlüssel können nicht auf verschlüsselten Spalten definiert werden

Alle diese Einschränkungen wurden mit Oracle 11g aufgehoben
Read the rest of this entry »

Mit dem in Oracle 10g eingeführten Scheduler (der in der Datenbank, implementiert mit dem Package dbms_scheduler) ist es leicht möglich, externe Programme (z.B. OS-Scripts) zu starten. Innerhalb der Datenbank konnte aber nicht gesteuert werden, unter welchem Betriebssystembenutzer die Programme laufen. Dies konnte nur über eine Datei pro ORACLE_HOME gesteuert werden (siehe Metalink Note 391820.1) - d.h. alle externen Programme liefen immer unter dem gleichen Account.

Auch wenn es nicht im New Features Dokument steht - über das neue Objekt CREDENTIAL ist es nun in Oracle 11g einfach möglich, jedem Job (bei Bedarf) andere Usernamen/Passwort-Kombinationen zuzuweisen.
Read the rest of this entry »

Auch hier wieder ein Verweis auf den Artikel von Arup Nanda, der das "Doing" sehr gut beschreibt.

Das in meinem letzten Blog-Eintrag beschriebene Database Replay kann einiges nicht:

• Nur einzelne Statements analysieren
• Statements, die auf eine bestimmte Tabelle zugreifen, analysieren
• Zusätzliche (nicht aufgezeichnete) Statements analysieren
• Auf Detailebene Statistiken und Ausführungspläne analysieren

Genau diese Punkte sind die Stärken des SQL Performance Analyzer (SPA).
Read the rest of this entry »

Auch ich möchte mit einer Reihe über Features von 11g starten. Ich will dabei nicht berichten, wie einfach es ist, eine bestimmte Funktionalität einzusetzen (dafür gibt es viele andere Blogs, auf die ich gern verweisen werde). Mein Ziel ist es, das Feature zu bewerten und über mögliche Probleme zu informieren.

OK - starten wir mit Database Replay. Ein guter Einstieg dazu ist der Artikel von Arup Nanda. Empfehlen würde ich aber, nicht alles per Enterprise Manager zu "klicken", sondern sich etwas mit dem PL/SQL-API zu beschäftigen. Dies ist nicht so komplex - und wenn erst mal die Scripts existieren, ist alles viel leichter nachvollziehbar.

Ich habe nun viel Zeit investiert, um zu testen, ob die Ergebnisse wirklich aussagekräftig sind.

Management Summery:

• Reine Abfragen: perfekt
• Abfragen und DML-Operationen ohne Locking-Probleme: perfekt
• DML-Operationen mit vielen Locking-Problemen: in den ersten Versuchen nicht gut...

Read the rest of this entry »

In einem Artikel der Computerwoche wird beschrieben, dass die neue Version von Oracle Database 11g "dumme Programmierfehler" habe. Diese wären durch Schulungen zu vermeiden, da es sich um "simple Sicherheitslecks" handele.

Sicherlich hat Alexander Kornbrust damit Recht.

Es ist schon unverständlichen, dass Oracle immer wieder in dieselben Probleme hineinläuft. Meiner Meinung nach hätte man aber diese auch schon im Betaprogramm Oracle melden können und somit dem Endanwender viele Probleme (verzögerten Produktionseinsatz, Downtime durch patchen) ersparen können.

Wir als Trivadis haben uns als Betatester intensiv mit den Funktionalitätstests auseinander gesetzt und einige Fehler zurückgemeldet. Oracle hat z.T. sogar von uns gewünschte Features eingebaut. Nebst dem haben wir natürlich schon viel über Oracle 11g gelernt.

Nachdem ich bis jetzt 11g nur als Test installiert habe (Beta und auch Releaseversion) stand gestern der erste (kleine) Praxistest an.

Ich wollte 11g in unserer Schulungsumgebung zum Laufen bekommen, so dass unsere Oracle-Schulungsteilnehmer auch die Möglichkeit haben, für Übungen diese neue Version zu benutzen - oder einfach damit zu spielen (natürlich bleiben auch die 8i, 9i und 10g (10.1 und 10.2) Datenbanken).

Fazit: Problemlos.
Sowohl die Installation der Software, das Anlegen der Datenbanken als auch das Laden der Daten klappte.
Angenehmer Nebeneffekt: Zumindest beim Laden meiner Beispieldatenbank ist 11g im Durchschnitt 5% schneller als 10gR2. Dabei erzeuge ich eine Menge von Daten mit unterschiedlichsten Methoden ("alter" Import, Import per Datapump, External Table, Tabellen umkopieren, MViews anlegen, ...).
Einiger Ausreisser: Der klassische Import einer IOT mit ca. 1'000'000 Rows war 4% langsamer. Aber das Exportfile stammt aus Zeiten von Oracle8 - ist damit vielleicht nicht wirklich aussagekräftig.

Mir wurde häufig die Frage gestellt, ob die Management Packs von Oracle (Change Management Pack, Configuration Management Pack, Diagnostic Pack, Tuning Pack) auch mit Oracles Standard Edition oder Standard Edition One benutzt werden dürfen.

Dies war nicht so ganz klar dokumentiert, aber die Antwort war immer klar: Diese Packs können leider nicht lizenziert werden mit SE und SE1 (obwohl sie zum grossen Teil funktionieren).

Mit Oracle Database 11g hat sich dies geändert!
Aber freut euch nicht zu früh - die Packs dürfen immer noch nicht benutzt werden - es wurde aber klar dokumentiert, dass es so ist

Siehe dazu auch den Blog-Eintrag von Lutz Hartmann. Interessant darin ist für mich auch sein Interview mit Guenther Stuerner, Vice President Oracle Germany und dessen Aussage, dass hier keine Änderung geplant ist.

Vielleicht bringt der offene Brief der Pythian Group "An Open Letter to Larry Ellison on AWR and ASH Licensing" doch noch etwas?