19 Patch for 35074478 for Linux-x86-64 Platforms

(IV) Bugs Fixed by This Patch 35074478

The following are the bugs fixed by this patch:
34286265: SAGEASM-E HIT ORA 800 [SET PRIORITY FAILED] WHEN STARTING LMS BACKGROUND PROCESS
34318125: ORA-00800: SOFT EXTERNAL ERROR, ARGUMENTS: [SET PRIORITY FAILED] ON BG PROCESSES

Oracle Database 19 Release 19.19.0.0.230418DBRU

This patch is RAC Rolling Installable - Please read My Oracle Support Document 244241.1 https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=244241.1
Rolling Patch - OPatch Support for RAC.

This patch is Data Guard Standby-First Installable - Please read My Oracle Support Note 1265700.1 https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=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.

Released: Tue Apl 11 11:52:45 2023

This document describes how you can install the overlay patch for bug# on your Automatic Storage Management 19 Release 19.19.0.0.230418DBRU
This Patch is applicable on Grid Infrastructure Home and Database Home

(I) Prerequisites

Before you install or deinstall the patch, ensure that you meet the following requirements:

Note: In case of an Oracle RAC environment, meet these prerequisites on each of the nodes.

Ensure that the Oracle home on which you are installing the patch or from which you are rolling back the patch is Oracle Database 19 Release 19.19.0.0.230418DBRU.
- For a Non-RAC environment, shut down all databases and listeners associated with the Oracle home that you are updating. For more information, see Oracle Database Administrator's Guide.
Ensure that 19 Release 19.19.0.0.230418DBRU Patch Set Update (PSU) 35042068 is already applied on the Oracle Database.
Oracle recommends you to use the latest version available for 19 Release 19.19.0.0.230418DBRU. If you do not have OPatch 19 Release 19.19.0.0.230418DBRU, then download it from patch# 6880880 for 19.19.0.0.230418DBRU release.

For information about OPatch documentation, including any known issues, see My Oracle Support Document 293369.1 OPatch documentation list:
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=224346.1
Ensure environment variable ORACLE_HOME is set correctly.
Ensure that the $PATH definition has the following executables: make, ar, ld and nm. The location of these executables depends on your operating system. On many operating systems, they are located in /usr/ccs/bin.
Before beginning patch application, check the consistency of inventory information for GI home and each database home to be patched. Run the following command as respective Oracle home owner to check the consistency.
% $ORACLE_HOME/OPatch/opatch lsinventory -detail -oh $ORACLE_HOME

Note:
- If this command succeeds, it lists the Oracle components that are installed in the home.
- Save the output so you have the status prior to the patch apply.
- If this command fails, contact Oracle Support Services for assistance.
(Only for Installation) Maintain a location for storing the contents of the patch ZIP file. In the rest of the document, this location (absolute path) is referred to as <PATCH_TOP_DIR>. Extract the contents of the patch ZIP file to the location (PATCH_TOP_DIR) you have created above. To do so, run the following command:
$ unzip -d <PATCH_TOP_DIR> p35074478_1919000DBRU_Linux-x86-64.zip
(Only for Installation) Determine whether any currently installed interim patches conflict with this patch 35074478 as shown below:
$ cd <PATCH_TOP_DIR>/35074478
$ opatch prereq CheckConflictAgainstOHWithDetail -ph ./

The report will indicate the patches that conflict with this patch and the patches for which the current 35074478 is a superset.

Note:
Upon execution of the Opatch command, it validates the patch and ensures that there are no conflicts with the software already installed in the ORACLE_HOME. OPatch categorizes conflicts into the following types:
- Conflicts with a patch already applied to the ORACLE_HOME that is a subset of the patch you are trying to apply - In this case, continue with the patch installation because the new patch contains all the fixes from the existing patch in the ORACLE_HOME. The subset patch will automatically be rolled back prior to the installation of the new patch.
- Conflicts with a patch already applied to the ORACLE_HOME - In this case, stop the patch installation and contact Oracle Support Services.
Ensure that you shut down all the services running from the Oracle home of Oracle Database home.
- Stopping services from Database home in Clustered Environments (Run as the database home owner)
  $ $ORACLE_HOME/bin/srvctl stop instance -d <db_unique_name> -n <node_name>
- Stopping services from Database home in Standalone Servers or Non-Clustered Environments (Run as the database home owner)
  $ $ORACLE_HOME/bin/srvctl stop home -o <ORACLE_HOME> -s <STAT_FILE_LOCATION>
<STAT_FILE_LOCATION> is a path to save the state of the database configuration temporarily. The previous command will stop the HA-managed clusterware resource for the specified database
home, and create a state file that can be used when restarting the same. Repeat the same command for all other database homes if you have more than one on the node, and make sure you
use different <STAT_FILE_LOCATION> each time.

Note:
- For a Non-RAC environment, shut down all databases and listeners associated with the ORACLE_HOME that you are updating. For more information, see Oracle Database Administrator's Guide.
- For a RAC environment, shut down all the services (database, ASM, listeners, nodeapps, and CRS daemons) running from the Oracle home of the node you want to patch. After you patch this node, start the services on this node. Repeat this process for each of the other nodes of the Oracle RAC system. OPatch is used on only one node at a time.
- If you are applying this patch to a database home, then shut down the services from the Oracle home of the database in the usual way. You do not have to use the srvctl command in that case.
- If the Oracle Database you are patching was installed with an operating system user account that is different from the user account used for installing the Oracle ASM, then run srvctl as the
  database home user (RDBMS home user) to stop the database instance on each node:
  $ $ORACLE_HOME/bin/srvctl stop instance -d <db_unique_name> -n <node_name>
Run the pre-root script as a root user from the Oracle home of Oracle Grid Infrastructure:

Running the Script for Grid Infrastructure Home in Clustered Environments (Run as root)
$<ORACLE_HOME>/crs/install/rootcrs.sh -prepatch
Running the Script for Grid Infrastructure Home on Standalone Servers or Non-Clustered Environments (Run as root)
$<ORACLE_HOME>/crs/install/roothas.sh -prepatch

(II) Installation

To install the patch, follow these steps:

 As root user, change oradism permissions    
    Pre-install    //these make the existing oradism owned by grid home owner and replaceable
    a.ls -ld $GI_HOME/bin/oradism
      i.-rwsr-x--- 1 root  dba  <GI_HOME>/bin/oradism   
    b.change owner to the GI home owner (i.e oracle)
      i.chown oracle $GI_HOME/bin/oradism
      ii.chmod 0750 $GI_HOME/bin/oradism
    c.ls -ld $GI_HOME/bin/oradism

Apply Patch to Grid Home as GI home owner :
$ <GI_HOME>/OPatch/opatch apply -oh <GI_HOME> -local <PATCH_TOP_DIR>/35074478

Apply Patch to DB home(s) as DB home owner :

Set your current directory to the directory where the patch is located
and then run the OPatch utility by entering the following commands:
As root user, change oradism permissions:

$ cd <PATCH_TOP_DIR>/35074478

  Pre-install    //these make the existing oradism owned by "oracle" user and replaceable
  a.ls -ld $ORACLE_HOME/bin/oradism
    i.-rwsr-x--- 1 root  dba  <ORACLE_HOME>/bin/oradism   
  b.change ownership to the DB home owner (i.e oracle)
    i.chown oracle $ORACLE_HOME/bin/oradism
    ii.chmod 0750 $ORACLE_HOME/bin/oradism
  c.ls -ld $ORACLE_HOME/bin/oradism
As DB home owner, apply the patch:

$ <ORACLE_HOME>/OPatch/opatch apply -oh <ORACLE_HOME> -local <PATCH_TOP_DIR>/35074478

Verify whether the patch has been successfully installed by running the following command:

As the Oracle Grid Infrastructure owner, run the following command:
$ opatch lsinventory -oh <GI_HOME>

As the Oracle Database home owner, run the following command:
$ opatch lsinventory -oh <ORACLE_HOME>

3b. Post-install
These make the new oradism binary owned by root with setuid, and executable by "oracle" user

3b.1 - For Grid Home as root user
    a.ls -ld $GI_HOME/bin/oradism
    b.change owner to 'root' and enable setuid bit
      i.chown root $GI_HOME/bin/oradism
      ii.chmod 4750 $GI_HOME/bin/oradism
    c.ls -ld $GI_HOME/bin/oradism

3b.2 - For DB home(s) as root user
    a.ls -ld $ORACLE_HOME/bin/oradism
    b.change owner to 'root' and enable setuid bit
      i.chown root $ORACLE_HOME/bin/oradism
      ii.chmod 4750 $ORACLE_HOME/bin/oradism
    c.ls -ld $ORACLE_HOME/bin/oradism

Run the post script as a root user from the Oracle home of Oracle Grid Infrastructure:
- Running the script for Grid Infrastructure home in Clustered Environments (Run as root)
  
  $ORACLE_HOME/crs/install/rootcrs.sh -postpatch
- Running the script for Grid Infrastructure home on Standalone Servers or Non-Clustered Environments (Run as root)
  
  $ORACLE_HOME/crs/install/roothas.sh -postpatch
Note: If you are applying this patch to a Database home, then skip this step.
Restart all the instances from the Oracle home.
- Restarting services from Database home in Clustered Environments (Run as the database home owner)
  $ $ORACLE_HOME/bin/srvctl start instance -d <db_unique_name> -n <node_name>
- Restarting services from Database home on Standalone Servers or Non-Clustered Environments (Run as the database home owner)
  $ $ORACLE_HOME/bin/srvctl start home -o <ORACLE_HOME> -s <STAT_FILE_LOCATION>
<STAT_FILE_LOCATION> refers to the absolute path leading up to the file name of the STAT_FILE that was created when you stopped the services.

Note:
- If you applied this patch to a database home, then start the services from the Oracle home of the database in the usual way. You do not have to use the srvctl command in that case.
- If the Oracle Database was installed with an operating system user account that is different from the user account used for installing the Oracle ASM, then run srvctl as the database home user
  (RDBMS home user) to start the database instance on each node:
  $ <ORACLE_HOME>/bin/srvctl start instance -d <db_unique_name> -n <node_name>

(III) Deinstallation

Ensure to follow the Prerequsites (Section I). To deinstall the patch, follow these steps:

 Change permisions to oradism on the GI_HOME and DB home

 i. For Grid Home as root user
    a.ls -ld $GI_HOME/bin/oradism
      i.-rwsr-x--- 1 root  dba  <GI_HOME>/bin/oradism   
    b.change owner to the GI home owner (i.e oracle)
      i.chown oracle $GI_HOME/bin/oradism
      ii.chmod 0750 $GI_HOME/bin/oradism
    c.ls -ld $GI_HOME/bin/oradism

ii. For DB home(s) as root user
    a.ls -ld $ORACLE_HOME/bin/oradism
      i.-rwsr-x--- 1 root  dba  <ORACLE_HOME>/bin/oradism   
    b.change ownership to the DB home owner (i.e oracle)
      i.chown oracle $ORACLE_HOME/bin/oradism
      ii.chmod 0750 $ORACLE_HOME/bin/oradism
    c.ls -ld $ORACLE_HOME/bin/oradism

Deinstall the patch from Grid Home as GI home owner :
$ <GI_HOME>/OPatch/opatch rollback -local -id 35074478 -oh <GI_HOME>
Deinstall the patch from DB home(s) as DB home owner :
$ <ORACLE_HOME>/OPatch/opatch rollback -local -id 35074478 -oh <ORACLE_HOME>

Post-install
These make the new oradism binary owned by root with setuid, and executable by "oracle" user
To be executed as root user:

i - For Grid Home as root user
a.ls -ld $GI_HOME/bin/oradism
b.change owner to 'root' and enable setuid bit
i.chown root $GI_HOME/bin/oradism
ii.chmod 4750 $GI_HOME/bin/oradism
c.ls -ld $GI_HOME/bin/oradism

ii - For DB home(s) as root user
a.ls -ld $ORACLE_HOME/bin/oradism
b.change owner to 'root' and enable setuid bit
i.chown root $ORACLE_HOME/bin/oradism
ii.chmod 4750 $ORACLE_HOME/bin/oradism
c.ls -ld $ORACLE_HOME/bin/oradism
Run the post script as a root user from the Oracle home of Oracle Grid Infrastructure:
- Running the script for Grid Infrastructure home in Clustered Environments (Run as root)
  
  $ORACLE_HOME/crs/install/rootcrs.sh -postpatch
- Running the script for Grid Infrastructure home on Standalone Servers or Non-Clustered Environments (Run as root)
  
  $ORACLE_HOME/crs/install/roothas.sh -postpatch
Note: If you are rolling back the patch from a Database home, then skip this step.
Restart all the services from the Oracle home.
- Restarting services from Database home in Clustered Environments (Run as the database home owner)
  $ $ORACLE_HOME/bin/srvctl start instance -d <db_unique_name> -n <node_name>
- Restarting services from Database home in Standalone Servers or Non-Clustered Environments (Run as the database home owner)
  $ $ORACLE_HOME/bin/srvctl start home -o <ORACLE_HOME> -s <STAT_FILE_LOCATION>
<STAT_FILE_LOCATION> refers to the absolute path leading up to the file name of the STAT_FILE that was created when you stopped the services.

Note:
- If you rolled back the patch to a database home, then start the services from the Oracle home of the database in the usual way. You do not have to use the srvctl command in that case.
- If the Oracle Database was installed with an operating system user account that is different from the user account used for installing the Oracle ASM, then run srvctl as the database home user
  (RDBMS home user) to start the database instance on each node:
  $ $ORACLE_HOME>/bin/srvctl start instance -d <db_unique_name> -n <node_name>
Ensure that you verify the Oracle Inventory and compare the output with the one run before the patch installation and re-apply any patches that were rolled back as part of this patch apply. To verify the inventory, run the following command:

As the Oracle Grid Infrastructure owner, run the following command:
$ opatch lsinventory -oh <GI_HOME>

As the Oracle Database home owner, run the following command:
$ opatch lsinventory -oh <ORACLE_HOME>

(IV) Bugs Fixed by This Patch

The following are the bugs fixed by this patch:
34286265: SAGEASM-E HIT ORA 800 [SET PRIORITY FAILED] WHEN STARTING LMS BACKGROUND PROCESS
34318125: ORA-00800: SOFT EXTERNAL ERROR, ARGUMENTS: [SET PRIORITY FAILED] ON BG PROCESSES

posted @ 2023-07-18 10:41 武汉OracleDBA 阅读(254) 评论(0) 编辑收藏举报

刷新页面返回顶部

武汉OracleDBA

欢迎联系交流--QQ:80184001 email:lipeng20004@126.com

19 Patch for 35074478 for Linux-x86-64 Platforms

(IV) Bugs Fixed by This Patch 35074478

The following are the bugs fixed by this patch:
34286265: SAGEASM-E HIT ORA 800 [SET PRIORITY FAILED] WHEN STARTING LMS BACKGROUND PROCESS
34318125: ORA-00800: SOFT EXTERNAL ERROR, ARGUMENTS: [SET PRIORITY FAILED] ON BG PROCESSES

(I) Prerequisites

(II) Installation

$ORACLE_HOME/crs/install/rootcrs.sh -postpatch

$ORACLE_HOME/crs/install/roothas.sh -postpatch

(III) Deinstallation

$ORACLE_HOME/crs/install/rootcrs.sh -postpatch

$ORACLE_HOME/crs/install/roothas.sh -postpatch

(IV) Bugs Fixed by This Patch

Copyright 2023, Oracle and/or its affiliates. All rights reserved.

公告

武汉OracleDBA

欢迎联系交流--QQ:80184001 email:lipeng20004@126.com

19 Patch for 35074478 for Linux-x86-64 Platforms

(IV) Bugs Fixed by This Patch 35074478

The following are the bugs fixed by this patch: 34286265: SAGEASM-E HIT ORA 800 [SET PRIORITY FAILED] WHEN STARTING LMS BACKGROUND PROCESS 34318125: ORA-00800: SOFT EXTERNAL ERROR, ARGUMENTS: [SET PRIORITY FAILED] ON BG PROCESSES

(I) Prerequisites

(II) Installation

$ORACLE_HOME/crs/install/rootcrs.sh -postpatch

$ORACLE_HOME/crs/install/roothas.sh -postpatch

(III) Deinstallation

$ORACLE_HOME/crs/install/rootcrs.sh -postpatch

$ORACLE_HOME/crs/install/roothas.sh -postpatch

(IV) Bugs Fixed by This Patch

Copyright 2023, Oracle and/or its affiliates. All rights reserved.

公告

The following are the bugs fixed by this patch:
34286265: SAGEASM-E HIT ORA 800 [SET PRIORITY FAILED] WHEN STARTING LMS BACKGROUND PROCESS
34318125: ORA-00800: SOFT EXTERNAL ERROR, ARGUMENTS: [SET PRIORITY FAILED] ON BG PROCESSES