Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

OJVM+GI PSU patch upgrade

2025-01-17 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

Shulou(Shulou.com)06/01 Report--

Execute it on DataGuard first. After all the nodes of DataGuard are upgraded successfully, it will be executed on production. Dg does not need to run the script operation after upgrading. It only needs to be executed in a node of the main database after the patches of the master and backup libraries are finished.

When the master database needs to stop the log transfer to the standby database before upgrading, and the standby database needs to stop the log application.

When the upgrade is completed, check the application of the main and standby libraries.

The core steps are as follows:

1. The master library disables log shipping to the standby library.

two。 Close the standby library, apply patches, but do not execute scripts (catpatch.sql, etc.), start to mount, and do not enable log recovery

3. Close the main library, apply patches, execute scripts (run catpatch/catbundle/catcpu, etc.)

4. Start the main library and reopen log delivery to the standby database

5. Enable log recovery for standby database

6. Check the patch application

* * *

* first, check the main and standby database before upgrading and related operations *

* * *

This patch is Data Guard Standby First Installable-See My Oracle Support Document 1265700.1 Oracle Patch Assurance-Data Guard Standby-First Patch Apply for details on how to remove risk and reduce downtime when applying this patch.

-main database / DG slave database execution before upgrade

Stop transferring logs from the main library first

Alter system set log_archive_dest_state_2=defer

-- for the preparation of the database, see check the database status and role; then prepare the database modification, stop the log application, and close all nodes (see whether the database needs to be stopped according to the patches)

Select inst_id,host_name,instance_name,status from gv$instance

Select inst_id,database_role,switchover_status from gv$database

Recover managed standby database cancel

Shutdown immediate;-check whether the database needs to be stopped according to the patches made

-- Master / slave patches are applied as described in the following steps 12345. Note: you do not need to register after the update of the slave database:

* * *

* second, the following steps are performed on all nodes of RAC in turn *

* * *

1. Confirm the opatch version

Su-oracle

Opatch version-11.2.0.3.6 or above

Su-grid

Opatch version-11.2.0.3.6 or above

two。 Upgrade opatch (if step 1 is not satisfied, perform this step, otherwise ignore)

Su-oracle

Unzip p6880880_112000_Linux-x86-64.zip-d $ORACLE_HOME

Opatch version

Su-grid

Unzip p6880880_112000_Linux-x86-64.zip-d $GI_HOME

Opatch version

* * *

* third, the following steps are performed on all nodes of RAC in turn *

* * *

Play GI PSU

How to Create an OCM Response file to Apply a Patch in Silent Mode-opatch silent (document ID 966023.1)

2.1. Create an OCM file

Su-oracle

$ORACLE_HOME/OPatch/ocm/bin/emocmrsp-no_banner-output / home/oracle/ocm.rsp

Chmod 775 / home/oracle/ocm.rsp

-- Validation of Oracle Inventory (run as GI and DB users respectively)

/ OPatch/opatch lsinventory-detail-oh

$ORACLE_HOME/OPatch/opatch lsinventory-detail-oh $ORACLE_HOME

2.2 stop the EM process (ignore if EM is not installed)

Su-oracle

Emctl stop dbconsole

-- One-off Patch Conflict Detection and Resolution patch conflict detection

How to Use the My Oracle Support Conflict Checker Tool for Patches Installed with OPatch [Video] (document ID 1091294.1)

2.3 upgrade PSU (As root user, execute the following command on each node of the cluster: cannot be executed in parallel)

Su-root

Cd / tmp/patch

Unzip p26030870_112040_Linux-x86-64.zip

Opatch auto / tmp/patch/26030870/26030799-ocmrf / home/oracle/ocm.rsp

Use the opatch tool under GI

* * *

* fourth, OJVM patch upgrade *

* * *

3. OJVM patch upgrade (executed under db)

3.1 check for patch conflicts

$cd / tmp/patch/26030870/26027154

Opatch prereq CheckConflictAgainstOHWithDetail-ph. /

3.2 check the number of database connections, turn off listening, and finally shut down crs (all nodes execute)

-check the pmon process:

Ps-ef | grep pmon

-- check the number of connections, kill connections, and turn off monitoring

Ps-ef | grep LOCAL=NO | grep-v grep | wc-l

Ps-ef | grep LOCAL=NO | grep-v grep | awk'{print $2}'| xargs kill-9

Lsnrctl stop

-- stop crs:

Crsctl stop crs

3.3 apply patches:

Cd / tmp/patch/26030870/26027154

Opatch apply-local

3.4 confirm whether the patch database is applied

Opatch lsinventory

Opatch lspatches

3.5 start the crs of all patched nodes

Crsctl start crs

*

* 5. After the upgrade is successful, execute it on a node in the production (and hit it in a node in the main database, but not in the standby database *

*

-- For an Oracle RAC environment, perform these steps on only one node. (it can be executed on a node in the main database, but not in the slave database, and all the patches in the master and slave libraries have been successfully applied.)

SQL installation is performed after the primary database and all standby databases have the database home binaries patched to the same level .

4.1 Post-upgrade script for Big GI PSU

-- execute catbundle.sql file

Cd $ORACLE_HOME/rdbms/admin

Sqlplus / nolog

SQL > CONNECT / AS SYSDBA

SQL > STARTUP

SQL > @ catbundle.sql psu apply

SQL > QUIT

-- perform a recompilation

Cd $ORACLE_HOME/rdbms/admin

Sqlplus / nolog

SQL > CONNECT / AS SYSDBA

SQL > @ utlrp.sql

-Check the following log files in $ORACLE_BASE/cfgtoollogs/catbundle for any errors:

Catbundle_PSU__APPLY_.log

Catbundle_PSU__GENERATE_.log

-- upgrade RMAN CATALOG (ignore if Oracle Recovery Manager is not used)

Su-oracle

Rman catalog username/password@alias

RMAN > UPGRADE CATALOG

-- Verification: executed under both DB and GI

Opatch lspatches

4.2 Registration operation after OJVM patch upgrade

Install the SQL portion of the patch by running the following command against a single instance environment.

Note: this step is suitable for single instance playing OJVM PSU.

Cd $ORACLE_HOME/sqlpatch/26027154

Sqlplus / nolog

SQL > CONNECT / AS SYSDBA

SQL > startup upgrade

SQL > @ postinstall.sql

SQL > shutdown

SQL > startup

For the Oracle RAC environment, reload the package on one of the nodes using the following command. Ensure that no other database instance is started on the remote node.

Note: this step requires closing other instances of non-running scripts on rac

Cd $ORACLE_HOME/sqlpatch/26027154

Sqlplus / nolog

SQL > CONNECT / AS SYSDBA

SQL > STARTUP

SQL > alter system set cluster_database=false scope=spfile

SQL > SHUTDOWN

SQL > STARTUP UPGRADE

SQL > @ postinstall.sql

SQL > alter system set cluster_database=true scope=spfile

SQL > SHUTDOWN

SQL > STARTUP

After installing the SQL portion of the patch, some packages may become invalid. This will be recompiled on access, or you can run utlrp.sql to bring them back to a valid state.

Note: both RAC and single instance need to be executed.

Cd $ORACLE_HOME/rdbms/admin

Sqlplus / nolog

SQL > CONNECT / AS SYSDBA

SQL > @ utlrp.sql

* * *

* if an exception occurs, roll back and stop the upgrade, and analyze the reason *

* * *

Rollback (GI PUS)

Su-root

Opatch auto / tmp/patch/26030799-rollback-ocmrf / home/oracle/ocm.rsp

Rollback registration: note that you need to operate on the rac node that is registered after the patch is completed.

Step 1:Start all database instances running from the Oracle home. For more information, see Oracle Database Administrator's Guide.

Step 2:For each database instance running out of the ORACLE_HOME, connect to the database using SQL*Plus as SYSDBA and run the rollback script as follows:

Cd $ORACLE_HOME/rdbms/admin

Sqlplus / nolog

SQL > CONNECT / AS SYSDBA

SQL > STARTUP

SQL > @ catbundle_PSU__ROLLBACK.sql

SQL > QUIT

In an Oracle RAC environment, the name of the rollback script will have the format catbundle_PSU__ROLLBACK.sql.

Step 3:If the OJVM PSU was applied for a previous GI PSU patch, you may see invalid Java classes after execution of the catbundle.sql script in the previous step. If this is the case, run utlrp.sql to re-validate these Java classes.

Cd $ORACLE_HOME/rdbms/admin

Sqlplus / nolog

SQL > CONNECT / AS SYSDBA

SQL > @ utlrp.sql

Step 4:check

$opatch lsinventory

Rollback (OJVM patch)

Crsctl stop crs

Opatch rollback-id 26027154

Crsctl start crs

Opatch lsinventory

Register after rollback:

The following steps load modified SQL files into the database. For an Oracle RAC environment, perform these steps on only one node.

Step 1:Install the SQL portion of the patch by running the following command for a single instance environment.

Cd $ORACLE_HOME/sqlpatch/26027154

Sqlplus / nolog

SQL > CONNECT / AS SYSDBA

SQL > startup upgrade

SQL > @ postdeinstall.sql

SQL > shutdown

SQL > startup

For an Oracle RAC environment, reload the packages on one of the nodes using the following commands. Make sure no other instance of the database is up on the remote nodes.

Note: this step requires closing other instances of non-running scripts on rac

Cd $ORACLE_HOME/sqlpatch/26027154

Sqlplus / nolog

SQL > CONNECT / AS SYSDBA

SQL > STARTUP

SQL > alter system set cluster_database=false scope=spfile

SQL > SHUTDOWN

SQL > STARTUP UPGRADE

SQL > @ postdeinstall.sql

SQL > alter system set cluster_database=true scope=spfile

SQL > SHUTDOWN

SQL > STARTUP

Step 2:After installing the SQL portion of the patch, some packages could become INVALID. This will get recompiled upon access or you can run utlrp.sql to get them back into a VALID state.

Cd $ORACLE_HOME/rdbms/admin

Sqlplus / nolog

SQL > CONNECT / AS SYSDBA

SQL > @ utlrp.sql

* * *

* 7. Enable the slave database after the master and slave database is upgraded successfully, and check the synchronization situation *

* * *

-- after the master database log is successfully applied, modify the master database parameters and slave database application log, and check the synchronization:

Enable the transfer log in the main library first

Alter system set log_archive_dest_state_2=enable

Prepare the library to start and apply the log

Startup

Recover managed standby database using current logfile

Finally, check the synchronization:

Select process, sequence#, status, delay_mins from v$managed_standby

=

* * *

* sample procedure for GI PSU patch upgrade *

* * *

The GI PSU patch can apply GI HOME and DB HOME in a scrolling manner. Note that the location where the patch is downloaded should be the directory shared by GI and db.

1. Check that the opatch tool version of the rac node is greater than or equal to 11.2.0.3.6:

Update the opatch tools under db and GI:

$unzip-d

$/ OPatch/opatch version

Second, configure the response file

Su-oracle

$ORACLE_HOME/OPatch/ocm/bin/emocmrsp-no_banner-output / home/oracle/ocm.rsp

Chmod 775 / home/oracle/ocm.rsp

Third, verify the period of validity

-- Validation of Oracle Inventory (run as GI and DB users respectively)

$ORACLE_HOME/OPatch/opatch lsinventory-detail-oh $ORACLE_HOME

Stop the EM process before patching or rolling back the patch (ignore if EM is not installed)

Su-oracle

/ bin/emctl stop dbconsole

5. Upgrade PSU (As root user, execute the following command on each node of the cluster: cannot be executed in parallel)

-As root user, execute the following command on each node of the cluster:

As root, execute the following command on each node of the cluster:

Note: the location of the PSU patch should be the directory shared by GI and db, and be executed by the opatch tool under GI

$cd

$unzip p27107360_112040_.zip

# opatch auto / 27107360-ocmrf

6. Register the database after upgrade and run the script: for rac, you only need to operate on one node.

-- execute script catbundle.sql

Cd $ORACLE_HOME/rdbms/admin

Sqlplus / nolog

SQL > CONNECT / AS SYSDBA

SQL > STARTUP

SQL > @ catbundle.sql psu apply

SQL > QUIT

The catbundle.sql execution is reflected in the dba_registry_history view by a row associated with bundle series PSU.

-- compiling failed objects

Cd $ORACLE_HOME/rdbms/admin

Sqlplus / nolog

SQL > CONNECT / AS SYSDBA

SQL > @ utlrp.sql

-- check the log for errors

Catbundle_PSU__APPLY_.log

Catbundle_PSU__GENERATE_.log

-- if you are using rman to restore the directory, do the following:

$rman catalog username/password@alias

RMAN > UPGRADE CATALOG

7. Roll back PSU:

-- root identity execution:

As root user, execute the following command on each node of the cluster.

# opatch auto / 27107360-rollback-ocmrf

Registration after rollback: registration after rollback is performed on the node after patching registration

8.1 Start all database instances running from the Oracle home

8.2 execute script

Cd $ORACLE_HOME/rdbms/admin

Sqlplus / nolog

SQL > CONNECT / AS SYSDBA

SQL > STARTUP

SQL > @ catbundle_PSU__ROLLBACK.sql

SQL > QUIT

8.3 compilation failure object

Cd $ORACLE_HOME/rdbms/admin

Sqlplus / nolog

SQL > CONNECT / AS SYSDBA

SQL > @ utlrp.sql

8.4 Check the log file for any errors.

The log file is found in $ORACLE_BASE/cfgtoollogs/catbundle and is named catbundle_PSU__ROLLBACK_.log where TIMESTAMP is of the form YYYYMMMDD_HH_MM_SS. If there are error.

8.5 check

$opatch lsinventory

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Database

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report