20. 11. 10

Oracle 11g – Never change a running system, oder doch?

Never change a running system – eine mit einiger Berechtigung immer wieder gern bemühte Argumentation, um mit dem Upgrade auf ein neues Softwarerelease noch abzuwarten, bis tatsächliche oder vermutete Kinderkrankheiten ausgemerzt sind.

Offensichtlich verhalten sich viele Anwender genau so abwartend bezüglich eines Upgrades auf die bereits seit einiger Zeit verfügbare Version 11g der Oracle Datenbank – im Feld begegnen uns überwiegend 9i- und 10g-Versionen, das aktuelle Release ist bisher noch spärlich vertreten.
Unter den vielen Neuerungen, Optionen und Features gibt es dabei einige, die es durchaus wert sind, einen baldigen Umstieg in Betracht zu ziehen. Eines der Top Features ist dabei sicherlich “Database Replay”, Bestandteil der “Real Application Testing” Option.
Wenn man bisher eine geänderte Anwendung einem realistischen Lasttest unterziehen wollte, war man auf die bekannten Werkzeuge von Drittherstellern angewiesen. Dies bedeutete eine Analyse von Anwenderverhalten, Erstellung von Benutzerprofilen, Analyse von bisherigen Belastungen über die Zeit und letztendlich die Zusammenstellung einer Simulation. Trotz des nicht unerheblichen Aufwands stand am Ende immer noch eine Simulation, als solche weiterhin mit dem Risiko behaftet, die Realität dann doch nicht ganz zu treffen.
Und – Hand auf’s Herz – in wie vielen Fällen wurde auf den Lasttest ganz verzichtet, wenn Aufwand und Kosten für eine einigermaßen realistische Simulation erst einmal bekannt waren?
Mit “Database Replay” gibt es nunmehr die Möglichkeit, alle Datenbankaktivitäten auf dem bisherigen System zu loggen, diese Logdateien auf das neue System zu transferieren und dort gegen die Datenbank “abzuspielen”.

“Database Replay” besteht dabei aus 4 Schritten:

  • Workload Capture
  • Workload Processing
  • Workload Replay
  • Analyse und Reporting

Workload Capture: Alle Datenbankaktivitäten werden aufgezeichnet und in spezielle binäre, sog. “capture files” in einem eigenen Verzeichnis geschrieben. Neben Start- und Stoppzeit für die Aufzeichnung lassen sich hier bereits bestimmte Aktivitäten ein- oder ausschließen. Für den Capture-Prozess muss das Package “DBMS_WORKLOAD_CAPTURE” installiert sein.

Der nächste Schritt ist CPU-intensiv und sollte daher nach dem Transfer auf die Test-Plattform erfolgen.
Workload Processing: Ein Arbeitsschritt, in dem die in den “capture files” enthaltenen Informationen aufbereitet, mit Metadaten ergänzt und in die sog. “replay files” umgewandelt werden. Die “replay files” sind wieder verwendbar und können somit für multiple Tests gegen eine mit “lash back” in den Ausgangszustand zurück versetzte Datenbank angewendet werden.

Workload Replay: Hierzu müssen ein oder mehrere “Replay Clients” aufgesetzt werden. Dazu ist das Programm “wrc.exe” im Oracle Home Verzeichnis notwendig. Für den eigentlichen Replay-Prozess muss das Package “DBMS_WORKLOAD_REPLAY” installiert sein.

Analyse und Reporting: Es werden bereits vorgefertigte Reports mitgeliefert, die z.B. Fehler während der Verarbeitung der replay files ausweisen und Hinweise auf die Performance auf Quell- und Zielsystem liefern.

Sie wollen wissen, ob ein neuer Patch bestehende Probleme behebt – oder neue schafft? Sie fragen sich, ob Konfigurationsparameter, die nach Richtwertempfehlungen gesetzt werden (z.B. sga_max_size ca. 50% des freien Hauptspeichers) für Ihre reale Instanz und Anwendung optimal sind? Sie fragen sich, welche Auswirkungen ein zusätzlicher Index oder ein Wechsel des Indextyps hat? Was bringt die nächst größere Hardware? Sie planen einen Plattformwechsel?
Bei all diesen Aufgaben und Fragestellungen liefert “Database Replay” wertvolle Antworten und reduziert Risiken. Der Capture-Prozess kann auch auf früheren Versionen als 11g eingerichtet und gestartet werden, z.B. auf einer 10gR2. Den Replay-Prozess gibt es jedoch erst mit der Version 11g. Sozusagen ein “rekursiver” Grund mehr, Bedenken gegen ein Upgrade zu überdenken – schließlich kann man mit dem Upgrade selbst Risiken reduzieren.
Mehr Informationen bei: frankfurt@its-people.de

In: OracleAuthor: Robert MarzComments (0)
06. 10. 10

Stolpersteine bei der Migration auf Oracle 11g (R2)

Dass sich in Oracle 11g Sicherheitseinstellungen geändert haben, hat sich zu den meisten ja bereits herumgesprochen.

Mit Änderungen, die sofort auffallen, kann man ja bei der Migration umgehen:
als Beispiel sei hier die plötzlich relevante Groß/Kleinschreibung von Kennwörtern genannt. Dieses Verhalten kann man zum Glück ja wieder deaktivieren (gut) oder betroffene Anwendungen rechtzeitig Anpassen (besser) …

Heute morgen bekam ich aber von einem Skript, dass sich auch an die Datenbank anmeldet, eine E-Mail, mit folgendem Fehler:

ORA-28002: the password will expire within 7 days

Eine kurzer Check ergab, dass die zugehörige Datenbank vor 181 Tagen aufgebaut wurde und die Default-Profile jetzt mit einer Password Liftime von 180 und einer Password Grace Time von 7 Tagen angelgt wird.

Die Fehlermeldung besagt einfach nur, dass die 180 Tage jetzt vorbei sind und der Benutzer sich in der “grace period” befindet und doch gefälligst sein Kennwort ändern soll.

Ich wage gar nicht zu schätzen, wieviel Anwendungen da draußen existieren, die mit dieser Fehlermeldung nicht umgehen können, von den Zahllosen Batch-Jobs (wie meinem) ganz zu schweigen.

Dem Spuk kann man mit

ALTER PROFILE "DEFAULT" LIMIT
    PASSWORD_LIFE_TIME UNLIMITED;

ein Ende bereiten.

Damit ist das alte Verhalten wieder hergestellt.

In: Administration, OracleAuthor: Robert MarzComments (3)