Hallo DBA’s ,

bin ich doch fast auf die Schnauze gefallen bei einem manuellem Update von Oracle 9.2.0.8 auf 11.1.0.7 unter Solaris 64-Bit (was bitte sonst, bei SPARC schon seit Jahrzehnten). Aber der Reihe nach:

Installation von 11.1.06 plus Patch auf 11.1.07 völlig problemlos.

Dann die alte Instanz mit utlu111i.sql aus der neuen Installation getestet und schön brav alle Hinweise beachtet. In der Database Section findet sich auch schon die Feststellung: –> timezone file: V1 . Aber keine weiteren Hinweise darauf das nur ab V4 auch ein upgrade möglich ist!!!!

Pfile erstellt und editiert (create pfile from spfile;) , STARTUP UPGRADE , Tablespace sysaux angelegt und bei catupgrd.sql kracht es dann … Falsche Timezone Files!

Die Timezone muss natürlich schon in der alten Version 9.2.0.8 gepatched werden.

Also Backup zurück und dann den richtigen OPATCH finden:

Für Solaris 64-Bit und 9.2.0.8 müssen zwei Patches eingespielt werden:

p5632264_92080_SOLARIS64.zip enthält die eigentlichen neuen Timezone Files

p5726045_92080_GENERIC.zip enthält das Upgrade Skript utltzuv2.sql

Danach wirft utlu111i.sql auch brav die V4 als Timezone Files aus und der Upgrade funktioniert:

• BACKUP erstellen!
• SQL> CREATE pfile FROM spfile; und editieren falls nötig
• SQL> STARTUP UPGRADE
• sysaux tablespace anlegen: SQL> CREATE TABLESPACE sysaux DATAFILE ‘sysaux01.dbf’ SIZE 500M REUSE EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGMENT AUTO ONLINE;
• SQL> SPOOL upgrade.log
• SQL> @catupgrd.sql
• SQL> STARTUP
• @utlu111s.sql; mal schauen ob alles OK ist
• SQL> catuppst.sql
• SQL> utlrp.sql
• SQL> exec DBMS_STATS.GATHER_DATABASE_STATS ( estimate_percent => 3, cascade  => true); Statistiken generieren könnte gut sein.

Das war es. catupgrd.sql ist dabei das Skript mit der längsten Laufzeit. Natürlich abhängig von der Datenbank Größe und der Rechner Geschwindigkeit.

Im Oracle Databse Upgrade Guide 11g Release 1 (11.1) steht es auch alles drin. Ich sollte mir dann beim nächsten mal auch die Mühe machen alles zu lesen, nicht nur den Teil mit dem Manually Upgrade

Viele Grüße

Michael Zimmer

Hallo,

heute gibt’s ne große Show von Oracle zur Übernahme von SUN.

Wer Spaß dran hat kann auch die Zwitscherreien online verfolgen. Hier die Twitterwal!

Viele Grüße

Michael

Hi,

und weiter geht der Spaß:

Allerdings glaube ich, das Oracle hier noch was ändern muß: “We didn’t have to buy more hardware”. Passt das noch nach dem Kauf von SUN? Ok, einmal kann man komprimieren – danach heißt es wieder: “Kauf mehr Blech”

Viel Spaß

Michael

PS: ja ja – ich hör jetzt auf ….

Hallo!

Haha die Videos von Oracle auf YouTube fangen an mir zu gefallen.  Hier noch eins:

Da fällt mir sofort der Kunde ein, der meint seine DBA’s können das alles auch per SSH / SQLPlus. Und was soll ich sagen: ja wir können es natürlich auch. Dauert nur ein bisschen länger ….

Scheiß auf Produktivität: Nieder mit den Maus – Schubsern!

Mehr davon gibt es hier!

Viel Spaß

Michael

Hallo,

da flimmert mir doch dieses schöne Video von ORACLE über meinen Bildschirm:

Sie benötigen also zukünftig keinerlei Downtimes mehr für Ihr Datenbanksystem. Oder?

Ich hoffe Oracle selber gestaltet seine Patches für ASM so, das es niemals die Situation gibt, das beide (es könnten auch mehr als zwei sein) Seiten offline sein müssen.

Einige Installationen die ich kenne beruhen auf einer Architektur die auf Clusterfilesysteme zurückgreift (statt ASM). Bei Patches für diese Produkte kommt es sehr wohl zu Downtimes für beide Seiten gleichzeitig. Vielleicht nicht für einen gewöhnlichen Patch, aber bei einem Versions Update fast mit Sicherheit. Wenn ich davon ausgehe, das Systeme für eine Lebensdauer von ca. 4 Jahren geplant werden, haben Sie eine sehr reelle Chance für mindestens ein bis zwei große Updates mit ordentlicher Downtime.

Planen Sie also besser für mindestens zwei mal im Jahr ein Wochenende Downtime für Ihre Datenbank Systme ein. Wenn die nicht gebraucht werden, sind Ihre Kunden auch nicht sauer. Umgekehrt schon eher…

Können Sie grundsätzlich nicht auf Downtimes verzichten, benötigen Sie etwas anderes als RAC: eine Standby Database mit ORACLE Data Guard. Dann aber haben Sie trotzdem noch geringe Umschaltzeiten und wirklich alle DB Systeme doppelt.

Aber immerhin: für alle kleineren Patches braucht man mit Oracle RAC tatsächlich keine kompletten Downtimes der gesamten Architektur mehr.  Und nichts mehr oder weniger verspricht uns ORACLE hier.

Ach so – für Ihre Applikation sind Sie selber verantwortlich. Wenn dort neue Versionen Datenbank Änderungen benötigen, haben Sie schon wieder eine Gelegenheit für eine Downtime: aber natürlich nur für Ihre Anwendung – die DB läuft ja weiter …

Viele Grüße

Michael Zimmer

Hallo,

Oracle schläft natürlich auch nicht.

Oracle Database 11g Release 2 ist für Linux und Solaris erschienen. What’s New gibt es natürlich auch.

Sehr interessant dazu auch eine der letzten DOAG News. Ein ganzes Heft zum 11gR2. Könnte also auch ein 12g sein

Sie wissen nicht was die Deutsche ORACLE-Anwendergruppe e.V. (DOAG) ist? Ab auf die Seite und Mitglied werden!

Viele Grüße

Michael

Hallo,

kommen Sie auch durcheinander bei den Begriffen: Datenbank, Instanz, Server Prozesse, Listener oder Datenfiles? Besteht eine RAC (Real Application Cluster) nun aus zwei Datenbanken oder aus einer Datenbank mit zwei oder mehreren Instanzen?

Versuchen wir uns mal an einer Begriffsbestimmung (keine Sorge, es wird gelingen und sogar richtig sein):

Bei Oracle besteht ein Datenbanksystem aus zwei Teilen:

• Datenbank mit Data-, Control- und Redo Log Files
• Datenbankmanagementsystem (DBMS)

Datenbank Dateien:

Die Dateien liegen im Dateisystem, werden in RAW Devices abgelegt oder auch durch Automatic Storage Managment (ASM) in verwalteten Disk-Gruppen bearbeitet.

• Control-Files

Davon gibt es mehrere mit selbem Inhalt: Pfade und Namen aller Data-Files und Redo-Log-Files, System-Change-Number (SCN) und alle Informationen zur Struktur und zum Zustand der DB. Eventuel auch Infos zum RecoveryManager (RMAN).

• Data-Files

Das sind die eigentlichen Datendateien mit allen Inhalten der Datenbank.

• Redo-Log-Files

Das sind die Transaktions-Logs in die alle Änderungen geschrieben werden. Beim Crash der DB werden hieraus (rollforward) alle Info’s zur Wiederherstellung nach dem letzten Check-Point gezogen.

Datenbankmanagementsystem:

• Instanz: mindesten eine ist für eine offene DB nötig. Zwei oder mehrere gibt es nur im RAC.

Die Instanz besteht aus Arbeitsspeicher im Shared Memory sowie aus zahlreichen Hintergrundprozessen. Als da währen:

• Database Writer (DBWR): Schreibt Änderungen der Daten Blockweise in die Data-Files
• Log Writer (LGWR): Schreibt die Redo-Log-Files
• Archiver (ARCH): wenn die DB im Archive-Log-Modus betrieben wird, schreibt er die Redo-Logs in die Archive Logs
• System Monitor (SMON): Sorgt für die Konsistenz der DB. Control Files, Header der DB Files und der Redo Files werden geschrieben und beim Start der DB kontrolliert und ein eventuell nötiges Crash Recovery eingeleitet.
• Prozess Monitor (PMON): überwacht alle Oracle Prozesse.

• Listener-Prozesse

bearbeiten Verbindungsanfragen und starten Server Prozesse.

• Oracle Server Prozesse

diese nehmen die Anweisungen durch Data Manipulation Language (DML) in SQL (Structured Query Language) oder anderen Sprachen entgegen, führen sie aus und liefern Ergebnisdaten zurück. Entweder greifen die Server Prozesse direkt auf die Datafiles zu, oder es werden Hintergrundprozesse der Instanz verwendet.

So, jetzt wissen Sie, das eine Instanz nur ein Teil eines Datenbank Systems bei Oracle ist. Natürlich werden die Begriffe bei anderen Datenbank Systemen wie zum Beispiel DB2 anders benutzt. Sonst macht’s ja keinen Spaß und ich hab nichts mehr zu schreiben

Viele Grüße

Michael Zimmer

Eine Oracle DB zu kopieren ist schwer?

Nö – kleines Beispiel:

Die orginal DB wird heruntergefahren und die DB Files (Datafiles, Redologs) werden an eine neue Stelle kopiert. Dann erstellt man eine neue init$SID.ora Datei (kann man auch kopieren, aber die Einträge müssen sowohl vom Namen der DB, als auch vom neuen Ort angepasst werden). Jetzt erzeuge ich ein neues Password File:

orapwd file=<location> entries=10 password=<sollten sie sich merken>

Datenbank hochfahren und Skript ausführen:

sqlplus “/ as sysdba”

SQL>@create-db.sql

Das Skript könnte folgendermaßen aussehen:

STARTUP NOMOUNT
CREATE CONTROLFILE SET DATABASE “PWLTUA”  RESETLOGS  ARCHIVELOG
MAXLOGFILES 192
MAXLOGMEMBERS 3
MAXDATAFILES 1024
MAXINSTANCES 32
MAXLOGHISTORY 3403
LOGFILE
GROUP 1 ‘/oradata/ts/PWLTUA/redo1-1.log’  SIZE 50M,
GROUP 2 ‘/oradata/ts/PWLTUA/redo3-1.log’  SIZE 50M,
GROUP 3 ‘/oradata/ts/PWLTUA/redo5-1.log’  SIZE 50M
DATAFILE
‘/oradata/ts/PWLTUA/system01.dbf’,
‘/oradata/ts/PWLTUA/undotbs01.dbf’,
‘/oradata/ts/PWLTUA/plink_inq_01.dbf’,
‘/oradata/ts/PWLTUA/tools01.dbf’,
‘/oradata/ts/PWLTUA/undotbs02.dbf’,
‘/oradata/ts/PWLTUA/users01.dbf’

CHARACTER SET WE8ISO8859P1 ;
alter database open resetlogs ;

ALTER TABLESPACE TEMP ADD TEMPFILE ‘/oradata/ts/PWLTUA/temp01.dbf’ SIZE 62915379
2 REUSE AUTOEXTEND OFF;

Im ersten Teil werden die Control Files neu generiert. Die Tablespaces in der alten DB muss man sich natürlich vorher rausschreiben:

select file_name from dba_data_files;

listet sie alle auf.

Jetzt sollte man die DB stoppen und im Mount Status wieder öffnen und dann die DB-Id ändern:

SQL> shutdown immediate;

SQL> startup mount;

nid TARGET=sys/<passwort>@PWLTUA

Und zu guter Letzt noch die DB neu starten mit open resetlogs, ganz so wie es die Ausgabe von nid wünscht.

SQL> startup mount;

SQL> alter database open resetlogs
Und schon haben wir eine neue Kopie einer alten Datenbank.

Hi,

ein kleiner Tip zu Oracle und Objekten:

Wie finde ich heraus, ob in der DB Objekte invalid sind:

select owner, object_type, object_name, status from dba_objects where status = ‘INVALID’ order by owner, object_type, object_name;

oder auch so:

select count(*) from obj$ where status in (4, 5, 6);

Zum compilieren gibt es wie immer mehrere Möglichkeiten:

Wenn es nur wenige Objekte sind:

ALTER PACKAGE my_package COMPILE;

ALTER PACKAGE my_package COMPILE BODY;

ALTER PROCEDURE my_procedure COMPILE;

ALTER FUNCTION my_function COMPILE;

ALTER TRIGGER my_trigger COMPILE;

ALTER VIEW my_view COMPILE;

Alle Objekte eines Schemas:

EXEC DBMS_UTILITY.compile_schema(schema => ‘SCOTT’);

Alles auf einen Schlag:

Als User “sys” Skript in rdbms/admin aufrufen:

\?/rdbms/admin/utlrp.sql

so viele wurden dann von utlrp compiliert:

select count(*) from UTL_RECOMPILED;

so long

Mike