Aufgabe: Eine Datenbank 10g R2 (Version 10.2.0.5) soll auf die Version 11g R2 mit aktuellem CPU Patch upgegradet werden.
Ablauf:
Die Installation der Oracle Datenbank Software erfolgt in ein neues Oracle Home parallel zu dem bereits existierenden Oracle Home und unter dem gleichen Solaris User.
Um den Upgrade zu beschleunigen, wird empfohlen die DBConsole/Grid Control zuvor auf der DB zu deinstallieren und nach dem Upgarde neu aufzusetzen.
Im Beispiel ist die ORACLE_SID = GPI !
Quellen:
User: root
Bzgl. der Voraussetzungen siehe auch die Anleitung bei einer neuen Installation: Installationsanleitung 11g R2
# Version uname -a SunOS db5 5.10 Generic_142900-04 sun4u sparc SUNW,Sun-Fire-xxx # Version über /etc/release cat /etc/release Solaris 10 5/08 s10s_u5wos_10 SPARC Copyright 2008 Sun Microsystems, Inc. .. # Version showrev ... Kernel version: SunOS 5.10 Generic_142900-04 ... #Bit Version prüfen /bin/isainfo -kv 64-bit sparcv9 kernel modules # Version über Metalink prüfen pkginfo -l SUNWsolnm | grep VERSION VERSION: 10,REV=2008.03.24.13.19
Um die Ausgabe von „pkginfo -l SUNWsolnm | grep VERSION“ zu interpretieren siehe die Liste: How to Determine the Release and Default Kernel Version in the Solaris Operating System [ID 1002239.1]
Was sagt uns nun diese Ausgaben:
Der OUI (der Installer) erkennt aber in dieser Installation nun nur den Kernel 5.10-2008.5.
ABER ⇒ Oracle 11g benötigt 5.10-2008.10 bzw. das Update 6 oder höher D.h. das Update wurde nicht „komplett“ eingespielt. Ein Workaround: Neuinstallation des SUNWsolnm Packages mit Hilfe des zuletzt gewählten Update Paket und testen ob nun die Version richtig angezeigt wird.
Oracle warnt allerdings, dass wenn /etc/relase nicht aktualisiert wurde, wurde auch das Update nicht „richtig“ bzw. vollständig durchgeführt/eingespielt, es wurden nur für die bestehenden Pakete ein Update durchgeführt, ein vollständiges Update kann auch neue Pakete enthalten! Siehe auch das FAQ unter ⇒ "FAQ - 11gR2 requires Solaris 10 update 6 or greater [ID 971464.1]"
Bzgl. der Solaris Versionen siehe auch:
⇒ Solaris 10 Kernel PatchID Sequence
#Package Info: pkginfo -i SUNWarc SUNWbtool SUNWhea SUNWlibC SUNWlibms SUNWsprot SUNWtoo SUNWi1of SUNWi1cs SUNWi15cs SUNWxwfnt
Den Patch Stand von Solaris überprüfen (für eine Standard DB reichen die folgenden Patch, je nach Anwendung die Original Anleitung sorgfältig prüfen!):
\
Patches for Oracle Solaris 10:
/usr/sbin/patchadd -p | grep 120753 /usr/sbin/patchadd -p | grep 139574 /usr/sbin/patchadd -p | grep 141414 /usr/sbin/patchadd -p | grep 141444 # alternativ showrev -a | grep 119963
Überprüfen das die Patche wie besonders der 120753 mindestens in der angegebenen Version (06 oder höher) vorliegen!
Ziel ist es die neuen DB Software „neben“ der bestehenden Software d.h. in der gleichen Struktur zu installieren.
cd /opt/oracle/product/ df -h . #Hier sollten mindestens noch 5 GB Plattenplatz frei sein. cd /tmp df -h . Hier sollten mindestens noch 2 GB Plattenplatz frei sein.
In der Datei /etc/system die Kernel Parameter überpüfen, hier ist dann allerdings später ein Reboot notwendig!
Für die TCP Settings:
Angepasst werden mussten:
Dazu:
# als root vi /etc/init.d/ndd #!/bin/sh # TCP Setting for the Oracle Cluster ndd -set /dev/tcp tcp_smallest_anon_port 9000 ndd -set /dev/tcp tcp_largest_anon_port 65500 ndd -set /dev/udp udp_smallest_anon_port 9000 ndd -set /dev/udp udp_largest_anon_port 65500 chmod 744 /etc/init.d/ndd chown root:sys /etc/init.d/ndd ln /etc/init.d/ndd /etc/rc2.d/S70ndd
Angepasst werden mussten:
Siehe auch Metalink node „Kernel setup for Solaris 10 using project files [ID 429191.1]“
Hardlimits:
Über den „project“ Mechanismus setzen ( in diesem Fall auf die group.dba oder evlt. auch user.oracle ):
# user root projmod -s -K "process.max-file-descriptor=(priv,65536,deny)" group.dba
Über „/etc/system“ setzen:
# als root vi /etc/system .. set maxuprc=16384 set rlim_fd_max=65536 set max_nprocs=30000 ..
Softlimit: * Soft limits for „maximum open file descriptors“ = 1024 oder höher
Kann in der .bash_profile angepasst werden:
vi ~/.bash_profile # .bash_profile umask 0022 ulimit -n 1024
In einer cluster Umgebung Zeitdienst pürfen:
# als root diese beiden Parameter in die ntp.conf einfügen! vi /etc/inet/ntp.conf .. slewalways yes disable pll ..
User: oracle
Für die Installation der eigentlichen Datenbank Software die beiden ersten Zip Files (1,4GB, 1.1GB) vom Patch 10404530 „11.2.0.3.0 PATCH SET FOR ORACLE DATABASE SERVER“ auf den Server in das Verzeichnis /export/oracle/home/install laden.
Md5 Checksumme überprüfen:
digest -v -a md5 p10404530_112030_SOLARIS64_1of7.zip md5 (p10404530_112030_SOLARIS64_1of7.zip) = 9f8bf7879870520a87ec95a1746fe693 digest -v -a md5 p10404530_112030_SOLARIS64_2of7.zip md5 (p10404530_112030_SOLARIS64_2of7.zip) = 18c91b60cad09bb2f33a2da64dd62a57
Mit dem Screen bei Metalink vergleichen:
Sind weiter Patche für die Datenbank notwendig, diese ebenfalls von Metalink laden. Wichtig ist immer der Patch des Patch Installers (Path Nummer 6880880). Dieser wird immer benötigt! Typische weitere Patche:
Den Datenbank Patch mit „unzip“ extrahieren.
User: oracle
Für den Start des Oracle Installers benötigen sie eine graphische Oberfläche bzw. ein passendes X forwarding. Ich empfehle für die Wartung NoMachine NX (siehe http://www.nomachine.com/ ).
Testen Sie diese zuvor mit „xclock &“.
Wechsel Sie in das /export/home/oracle/install/database Verzeichnis.
Prüfen ob die Befehle make, ar, ld, und nm im Pfad stehen. Falls nicht Pfad erweitern:
export PATH=$PATH:/usr/ccs/bin
Starten Sie dort ./runInstaller.sh und die gewünschte Datenbank Version wird installieren. Wählen Sie die Option „Nur die DB Software installieren“!
Prüfen der Ausgaben des „Perform Prerequisite Checks“ Screen und fixen der dort angezeigten Fehler. Mit den „Ignore“ Button können Sie die Fehler auch überspringen.
Auf den Plattenplatz achten, evtl. nach der Installation das Database Installations-Verzeichnis löschen! (gibt immer hin 2,4GB wieder frei!)
User: oracle
Je nachdem wie die Datenbankumgebung eingerichtet ist, (zum Beispiel so: Arbeitsumgebung setzen und einrichten unter Windows und Linux das neuen Oracle Home mitaufnehmen.
User: oracle
Vor dem Patch der DB Software muss der Patch Installer OPatch aktualisiert werden.
Test der aktuellen Version:
cd $ORACLE_HOME/OPatch ./opatch version ./opatch: whereis: not found Invoking OPatch 11.2.0.1.7 OPatch Version: 11.2.0.1.7
Der Fehler whereis kann ignoriert werden.
Die Aktualisierung besteht darin, das komplette Verzeichnis OPatch auszutauschen, den OPatch Patch auspacken und dann in das OPatch Verzeichnis unter $ORACLE_HOME ersetzen.
# altes OPatch sichern cd $ORACLE_HOME/OPatch mv OPatch OPatch_OLD # neues OPatch auspacken cd /export/home/oracle/install unzip p6880880_112000_SOLARIS64.zip -d $ORACLE_HOME # testen cd $ORACLE_HOME/OPatch ./opatch version OPatch Version: 11.2.0.3.2
Prüfen ob die Befehle make, ar, ld, und nm im Pfad stehen. Falls nicht Pfad erweiter:
export PATH=$PATH:/usr/ccs/bin
# Neues Oracle Home setzen export $ORACLE_HOME=/opt/oracle/product/11.2.0.3/dbhome_1 # Patch auspacken cd /export/home/oracle/install unzip p14038787_112030_SOLARIS64.zip cd 14038787 # Patch anwenden $ORACLE_HOME/OPatch/opatch napply -skip_subset -skip_duplicate
Sind noch weitere Patche notwendig, diese nach diesem Muster einspielen.
User: oracle
Aktuelle DB unter 10g komplett sichern.
# Editor setzen export EDITOR=vi # crontab zum bearbeiten öffenen und mit # auskommentieren crontab -e
User: oracle
In der bestehenden Datenbank auf Fehler prüfen wie: siehe auch Ungültige Objekte in der DB "reparieren"
sqlplus / as sysdba SQL> select owner ,object_type ,count(*) as anzahl from all_objects where status!='VALID' group by rollup (owner,object_type) / # falls viele Fehler auftauchen # ungültige Objekte in der Datenbank neu übersetzen sql>@?/rdbms/admin/utlrp.sql
Papierkorb der DB Löschen
sqlplus / as sysdba SQL>PURGE DBA_RECYCLEBIN;
Überprüfen ob die Audit log Tabelle aud$ sehr viele Einträge enthält:
SELECT COUNT(*) FROM aud$; -- falls ja und die Daten NICHT benötigt werden, löschen TRUNCATE TABLE aud$;
User: oracle
Mit dem Script /opt/oracle/product/11.2.0.3/dbhome_1/rdbms/admin/utlu112i.sql (Script aus den neuen Oracle Home!) wird in der zu aktualisierenden Datenbank geprüft welche Schritte VOR dem Upgrade auf der DB durchgeführt werden müssen.
Es wird empfohlen die aktuellest Version des Pre-Upgrade Scripts über „How to Download and Run Oracle's Database Pre-Upgrade Utility (Doc ID 884522.1)„ vom Oracle Support Portal zu verwenden.
# DB umgebung auf die "Alte" Datenbank setzen sqlplus / as sysdba sql>spool upgrade_info.log sql>@/opt/oracle/product/11.2.0.3/dbhome_1/rdbms/admin/utlu112i.sql SQL>spool off
Für den Upgrade der Zeitzonen Dateien auf V14 siehe auch Applying the DSTv14 update for the Oracle Database [ID 1109924.1]
von dieser Seite für den Test die Datei „utltzuv14.sql“ laden.
Test:
sqlplus / AS sysdba sql>SELECT version FROM v$timezone_file; 4 sql>@utltzuv14.sql sql>SELECT * FROM sys.sys_tzuv2_temptab
Falls keine Zeilen bzgl. der Nutzdaten der Applikation ausgegeben werden kann ein Upgrade erfolgen. Falls Daten aktualisiert werden müssten, sollte der Patch 9742718 auf der alten DB eingespielt werden und mit DBMS_DST Package die Daten angepasst werden.
Ergebnisse auswerten und Vorschläge durchführen.
Siehe auch About the Output of the Pre-Upgrade Information Tool
Falls sehr viele Einträge im Audit log sind Metalink Node Oracle Support Document 1329590.1 (How to Pre-Process SYS.AUD$ Records Pre-Upgrade From 10.1 or later to 11gR1 or later.) beachten.
siehe auch http://docs.oracle.com/cd/E11882_01/server.112/e23633/statistics.htm für ein komplettes Script.
sql>exec DBMS_STATS.gather_dictionary_stats; sql>exec DBMS_STATS.gather_fixed_objects_stats; sql>exec DBMS_STATS.gather_schema_stats ('SYS', options => 'GATHER', estimate_percent => DBMS_STATS.auto_sample_size, cascade => TRUE); sql>exec DBMS_STATS.gather_schema_stats ('SYSMAN', options => 'GATHER', estimate_percent => DBMS_STATS.auto_sample_size, cascade => TRUE); # Optional! # für alles IN der DB was noch nicht ermittelt wurde! Kann dauern! sql>exec DBMS_STATS.GATHER_DATABASE_STATS (degree=>4,options=>'GATHER AUTO' );
SPfile in eine text basierende init.ora exportieren um später eine Vorlage für das Anpassen von Parameter für das erste Starten der DB beim Upgrade zuhaben.
sql>CREATE pfile='/export/home/oracle/init.ora' FROM spfile;
Meist testen man tagsüber und vergisst das nachts so einiges in der Datenbank loss sein kann.
Lieder können die Autotasks der DB erst ab 11g mit DBMS_AUTO_TASK_ADMIN.DISABLE deaktiviert werden.
Sheduler daher komplett ausschalten:
sqlplus / AS sysdba SET serveroutput ON DECLARE v_info varchar2(100); BEGIN dbms_output.put_line('-- Info -> Set SCHEDULER_DISABLED to disabled = TRUE '); dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED','TRUE'); dbms_scheduler.get_scheduler_attribute('SCHEDULER_DISABLED', v_info); dbms_output.put_line('-- Info -> SCHEDULER_DISABLED :: ' || nvl(v_info,'NOT SET')); END; /
Mit RMAN nochmals alle Archive und das Controlfile seit dem letzen Backup sichern um den letzen Stand vor dem Upgrade zu haben.
# alte Umgebung! rman rman>connect target / rman>backup archivelog all not backed up 1 times; rman>backup spfile; rman>backup current controlfile;
User : oracle
SELECT * FROM v$recover_file;
SELECT * FROM v$backup WHERE STATUS != 'NOT ACTIVE';
SELECT * FROM sys.obj$ o, sys.user$ u, sys.sum$ s WHERE o.type# = 42 AND bitand(s.mflags, 8) = 8;
SQL> SELECT * FROM dba_2pc_pending; # falls IN USE SQL> SELECT local_tran_id FROM dba_2pc_pending; SQL> EXECUTE dbms_transaction.purge_lost_db_entry(''); SQL> COMMIT;
Mit dem Tool DBVERIFY: Offline Database Verification Utility werden die Datendateien der Datenbank auf Blockfehler überprüft.
Wie: „dbv BLOCKSIZE=8192 file=/opt/oracle/oradata/gpi/system01.dbf FEEDBACK=1000“
Die Befehle über die Liste der Datendateien aus dem DD erzeugen:
sqlplus / as sysdba sql>set pagesize 100 sql>column dbvcommand format a100 sql>select 'dbv file='||name||' BLOCKSIZE='||block_size as dbvcommand from v$datafile; DBVCOMMAND -------------------------------------------------------------------------------- dbv file=/opt/oracle/oradata/GPI/system01.dbf BLOCKSIZE=8192 ... sql>exit
Erzeugte Befehle ausführen und auf Fehler achten.
Datenbank stoppen
sql>shutdown IMMEDIATE
DBV Befehle ausführen
dbv file=/opt/oracle/oradata/TNGIP5/system01.dbf BLOCKSIZE=8192
Die audit Dateien und die Alert.log der alten Datenbank mit Tar einpacken und zippen, originale löschen. Struktur NICHT löschen!
cd /opt/oracle tar cfv admin.tar ./admin gzip admin.tar
Alle alten Traces in der Admin 10g Struktur löschen.
cd ./admin du -h . find . -type f -name "*.trc" -exec rm {} \; find . -type f -name "*.aud" -exec rm {} \; find . -type f -name "*.log" -exec rm {} \; du -h .
Listener log ebenfalls zippen und original löschen.
# Altes Home einstellen # Listener Status abfragen lsnrctl status # Listner.ora Datei merken! # Log location merken! # Listner stoppen lsnrctl stop # Listener log bei Bedarf zippen und löschen
Alte Listener Konfiguration in das neue Oracle Home kopieren ( oder falls gesetzt in des Verzeichnis auf das TNS_ADMIN zeigt!)
cp /opt/oracle/product/10.2.0/db_1/network/admin/listener.ora /opt/oracle/product/11.2.0.3/dbhome_1/network/admin
Listener.ora öffnen und evtl. Oracle Home Einträge anpassen
ADR Home angeben
.. ADR_BASE_LISTENER = /opt/oracle ..
Neues Oracle Home in der Umgebung setzen und dort den Listener starten
# Oracle Home einstellen
lsnrctl start
User : oracle
Password Datei vom alten Oracle Home in das neue Home kopieren
cp /opt/oracle/product/10.2.0/db_1/dbs/orapwGPI /opt/oracle/product/11.2.0.3/dbhome_1/dbs
Erzeugte ini.ora Parameter Datei aus Schritt zuvor auf die gewünschten Parameter für 11g optimieren Datei in das 11g Home als opt/oracle/product/11.2.0.3/dbhome_1/dbs/initGPI.ora kopieren.
Minum: obsolete Paramter background_dump_dest und user_dump_dest entfernen und Parameter diagnostic_dest dafür aufnehmen, diagnostic_dest=/opt/oracle ( damit wird das ADR Home definiert um das 11g Tool adrci zu nützen).
cp initTNGIP5.ora /opt/oracle/product/11.2.0.3/dbhome_1/dbs
Nach den ora_ Prozessen im Hauptspeicher suchen
ps -Af | grep ora_
# Neues Oracle Home setzen sqlplus / AS sysdba SQL> STARTUP UPGRADE SQL> exit
2. Session als Oracle User starten, Parameter ADR_BASE auf das DIAG Home setzen, mit adrci alert.log überwachen
export ADR_BASE=/opt/oracle adrci adrci> show homes ADR Homes: diag/rdbms/GPI/GPI adrci> set home diag/rdbms/GPI/GPI adrci> show alert -tail -f
in das Verzeichnis $ORACLE_HOME/rdbms/admin wechseln
# auf die richtige Oracle Umgebung achten sqlplus / AS sysdba SQL> SPOOL /export/home/oracle/upgrade.log SQL> @catupgrd.sql
Diese kann zwischen 45 bis 90 Minuten dauern!
Datenbank neu starten und Post Upgrade Utility starten
# auf gültiges Oracle Home prüfen! sqlplus / AS sysdba sql>startup sql>@utlu112s.sql exit sqlplus / AS sysdba # weiter Upgrades durchführen SQL>@catuppst.sql #Fixed Object Statistiken erneuern: SQL>EXEC DBMS_STATS.gather_fixed_objects_stats; # ungültiges neu übersetzen SQL>@utlrp.sql # auf ungültige Objekte testen SQL> SELECT COUNT(*) FROM dba_invalid_objects; SQL> SELECT DISTINCT object_name FROM dba_invalid_objects; #Prüfen ob diese auch zuvor schon ungültig waren SQL>@?/rdbms/admin/utluiobj.sql
Noch ist die Datenbank mit der init.ora aus vorherigen Schritt gestartet. Spfile erzeugen:
CREATE spfile FROM pfile;
prüfen:
„ls /opt/oracle/product/11.2.0.3/dbhome_1/dbs/SPFILEGPI.ora“ muss vorhanden sein.
Datei /etc/oratab öffnen und Oracle Home anpassen
Pfade im Start Script der Datenbank anpassen, oft in /etc/init.d/oracle oder ähnlich
System neu starten und testen
tnsname.ora und sqlnet.ora aus alten Home nach $ORACLE_HOME/network/admin kopieren
Backup Scripte auf richtiges Oracle Home prüfen und in der Crontab wieder aktivieren.
Nach der Installation können die Installatonsdateien auf dem Server gelöscht werden.
Nagios Überwachung anpassen.
Sheduler für alle Taks wie das Erstellen der Statistik in den AutoTaks wieder einschalten:
sqlplus / AS sysdba SET serveroutput ON DECLARE v_info varchar2(100); BEGIN dbms_output.put_line('-- Info -> Set SCHEDULER_DISABLED to enabled = FALSE '); dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED','FALSE'); dbms_scheduler.get_scheduler_attribute('SCHEDULER_DISABLED', v_info); dbms_output.put_line('-- Info -> SCHEDULER_DISABLED :: ' || nvl(v_info,'NOT SET => FALSE = ENABLED')); END; /
Per Default ist die Password Lifetime der 11g auf 180 Tage gesetzt, Einstellungen auf der DB überprüfen und entsprechende den Sicherheitsrichtlinien nach Firmenstandard einstellen.
Überprüfen mit:
#profile Settings SELECT profile ,LIMIT FROM dba_profiles WHERE resource_name ='PASSWORD_LIFE_TIME' ORDER BY profile / # Einstellungen COLUMN username format a22 COLUMN account_status format a18 COLUMN profile format a10 SELECT username, profile, account_status,expiry_date FROM dba_users ORDER BY 1 /
Passwörter sind Case Sensitiv, falls das nicht gewünscht ist kann diese mit dem init.ora Parameter „sec_case_sensitive_logon=FALSE“ deaktiviert werden.
Vorbereiten Betriebssystem | 60 Minuten |
Installation Oracle 11g Software | 30 Minuten |
Patch Oracle 11g Software | 30 Minuten |
Vorbereitung Upgrade DB | 30 Minuten |
Upgrade Script | 90 Minuten |
Post Upgrade und Test | 60 Minuten |
Gesamt | 300 Minuten |
Davon Downtime für die Applikation 120 Minuten