oracle19c for Linux的 2024.10补丁集19.25发布了

微信号oracle19c

已于 2024-11-25 15:15:04 修改

阅读量1.6k

点赞数 14

文章标签： linux 运维服务器

于 2024-11-25 12:15:00 首次发布

本文链接：https://blog.csdn.net/qq_26339287/article/details/144024197

版权

原文

提供更好的翻译建议

Oracle® 数据库

补丁 36912597 - 数据库版本更新 19.25.0.0.241015

本文档在发布时准确无误。有关数据库版本更新 19.25.0.0.241015 的任何更改和附加信息，请参阅 My Oracle Support ( http://support.oracle.com/) 中提供的以下相关文档：

文档19202410.9 Oracle DB/GI/OJVM 更新/修订 R19 2024 年 10 月已知问题
文档555.1 Oracle Database 19c 重要推荐一次性补丁
文档888.1 数据库主动补丁程序主要说明
文档1919.2 19c 数据库升级 - 最佳实践自助协助

本文档包括以下部分：

第 1 节“补丁信息”
第 2 节“先决条件”
第 3 节“安装”
第 4 节“卸载”
第 5 节“已知问题”
第 6 节“参考文献”
第 7 节“此补丁修复的错误”
第 8 节“文档可访问性”

1补丁信息

数据库版本更新 19.25.0.0.241015 补丁是累积的。也就是说，所有以前的数据库捆绑包的内容都包含在最新的数据库捆绑包补丁中。
要安装数据库版本更新 19.25.0.0.241015 补丁，Oracle 主目录必须安装 Oracle 数据库版本 19c。
该补丁是 Oracle RAC 滚动安装的。
此修补程序可安装 Database Vault。查看 My Oracle Support 文档1195205.1 Oracle Database Vault 主要说明，了解有关如何将此补丁应用到 Database Vault 环境的详细信息。
该补丁是 Data Guard 待机优先安装的。有关应用此补丁时如何消除风险和减少停机时间的详细信息，请参阅 My Oracle Support 文档1265700.1 Oracle 补丁保证 - Data Guard 备用优先补丁应用。
此补丁包含上一个周期中发布的 JDK 修复，并将更新 Oracle 主目录中的 JDK。对于最新的 JDK 修复，有一个单独的补丁可用，并且除了此补丁之外还需要安装。有关 JDK 补丁号，请参阅 My Oracle Support 文档888.1 数据库主动补丁程序主要说明。
从 2023 年 10 月 21 日开始，UTL_URI.ESCAPE函数现在符合 RFC 3896 并将“#”视为保留字符。有关更多详细信息，请参阅 My Oracle Support 说明 2981395.1 。
从 2024 年 1 月 22 日 RU 开始，19c 数据库现已在 Oracle Linux 9.x 和 RHEL9 上获得认证。x。
从 2023 年 1 月 19 日 RU 开始，DBRU 包含 CORE DST 时区补丁。应用此版本更新 (RU) 不会更改任何数据库中的 DST 版本。 DST 补丁仅被复制 $ORACLE_HOME/oracore/zoneinfo，不会执行 DST 升级。您可以随时决定将数据库中的 DST 版本升级到较新的 DST 版本，而无需应用 RU。请注意，这会导致停机。

此 DBRU 包含以下 CORE DST 补丁：
- 28852325 - DSTV33 更新 - TZDATA2018G
- 29997937 - DSTV34 更新 - TZDATA2019B
- 31335037 - DSTV35 更新 - TZDATA2020A
- 32327201 - DSTV36 更新 - TZDATA2020E
- 33613829 - DSTV37 更新 - TZDATA2021E
- 34006614 - DSTV38 更新 - TZDATA2022A
- 34533061 - DSTV39 更新 - TZDATA2022C
- 34698179 - DSTV40 更新 - TZDATA2022E
- 35099667 - DSTV41 更新 - TZDATA2022G
- 35220732 - DSTV42 更新 - TZDATA2023C
- 36260493 - DSTV43 更新 - TZDATA2024A
如果您计划调整数据库的 DST 版本，Oracle 建议将其调整为最新的可用 DST 版本。然后按照 Oracle 19c Oracle 数据库升级指南中的说明进行操作。

有关各种 DST 补丁版本的更多信息，请参阅 My Oracle Support 文档 412160.1主要说明 DST 常见问题：更新了 Oracle RDBMS 和 OJVM 时区文件补丁中的 DST 转换和新时区。
可能包含在季度补丁包中的任何新的或更改的数据库初始化参数都将记录在 Oracle 数据库参考手册中有关初始化参数的部分中。对于 Oracle Database 19c，请参阅 Oracle 数据库参考。
有关仅客户端安装中应使用的最新安全修复更新，请参阅 Oracle 数据库上您感兴趣的周期的关键补丁更新 (CPU) 程序补丁可用性文档 (PAD) 部分。
应用数据库版本更新数据库版本更新 19.25.0.0.241015 与 Oracle JavaVM 19.x 更新
- 对于想要在单个停机时间窗口内同时安装两个补丁的客户，请遵循 My Oracle Support 文档中列出的修补选项之一：
  - 1929745.1 - Oracle 推荐的补丁 - “Oracle JavaVM 组件数据库 PSU 和更新”（OJVM PSU 和 OJVM 更新）补丁。
- Oracle JavaVM 19.x 版本更新作为单独的补丁提供。如果要以 RAC 滚动方式安装该单独的补丁，则有一些额外的要求，如 My Oracle Support 文档中所述：
  - 2217053.1 - “Oracle JavaVM 组件数据库 PSU/RU”(OJVM PSU/RU) 补丁的 RAC 滚动安装过程。

2先决条件

强烈建议在应用补丁之前备份 Oracle_Home 二进制文件和 Central Inventory。有关更多信息，请参阅 My Oracle Support 文档565017.1 如何执行 ORACLE_HOME 备份？。

本节包括以下部分：

第 2.1 节 “OPatch 实用程序”

2.1 OPatch 实用程序

您必须使用 OPatch 实用程序版本 12.2.0.1.43 或更高版本来应用此修补程序。 Oracle 建议您使用最新发布的 12.2 OPatch 版本，可以通过选择 12.2.0.1.0 OPatch 版本的 ARU 链接从 My Oracle Support 补丁6880880下载该版本。建议您将 OPatch 实用程序和补丁下载到共享位置，以便能够从集群中的任何节点访问它们，以便在每个节点上应用补丁。

修补 GI home 时，只需在要修补 GI home 的节点上卸载 Oracle ACFS 上的共享位置即可。

应在所有正在修补的 Oracle RAC 数据库主目录和 GI 主目录中更新新的 OPatch 实用程序。

对于正在修补的每个 Oracle RAC 数据库主目录和 GI 主目录，作为主目录所有者，提取 OPatch 实用程序。

有关安装 OPatch 的确切说明，请遵循 OPatch 自述文件。

OPatch 中添加了一项新功能，通过删除不活动的补丁来提高性能。请参阅 My Oracle Support 文档 2942102.1 OPatch 12.2.0.1.37+ 引入了删除目录中非活动补丁的新功能ORACLE_HOME/.patch_storage。

有关 OPatch 文档的信息（包括任何已知问题），请参阅 My Oracle Support 文档293369.1 OPatch 的主要说明。

3安装

这些说明适用于所有 Oracle 数据库安装。

第 3.1 节 “补丁预安装说明”
第 3.2 节 “补丁安装说明”
第 3.3 节 “补丁安装后说明”
第 3.4 节 “在 Oracle 主目录中安装此补丁后创建或升级的数据库的补丁安装后说明”

3.1补丁预安装说明

在安装数据库版本更新 19.25.0.0.241015 之前，请执行以下操作来检查环境并检测和解决任何临时补丁冲突。

3.1.1具有网格基础设施的环境

此补丁不应安装到具有网格基础设施主目录的环境中。请参阅以下 My Oracle Support 文档888.1 以确定要安装的适当的网格基础设施补丁。

3.1.2环境检查

确保 $PATH 定义具有以下可执行文件：make、ar、 ld和nm。

这些可执行文件的位置取决于您的操作系统。在许多操作系统上，它们位于中/usr/ccs/bin，在这种情况下，您可以按如下方式设置 PATH 定义：
```
导出 PATH=$PATH:/usr/ccs/bin

```

3.1.3临时补丁冲突检测和解决

确定 Oracle 主目录中是否有与数据库版本更新 19.25.0.0.241015 冲突的临时补丁并获取必要的冲突解决补丁的最快、最简单的方法是使用补丁上的补丁建议 和补丁计划功能My Oracle Support 中的“& 更新”选项卡。这些功能与 My Oracle Support 配置管理器结合使用。有关这些功能的录制培训课程可在 My Oracle Support 文档603505.2 My Oracle Support 操作方法视频培训系列中找到。

但是，如果您没有使用 My Oracle Support 补丁计划，则可以使用 My Oracle Support 冲突检查器工具上传 OPatch 清单并检查要应用于环境的补丁是否存在冲突。

如果没有发现冲突，您可以下载补丁。如果发现冲突，该工具会查找现有的解决方案进行下载。如果未找到解决方案，它将自动请求解决方案，您可以在“补丁和更新”选项卡的“计划和补丁请求”区域中监视该解决方案。

有关更多信息，请参阅知识文档1091294.1， 如何使用 My Oracle Support 冲突检查器工具来检查随 OPatch 安装的补丁。

或者，使用以下步骤手动发现冲突和解决方案：

确定当前安装的临时补丁是否与正在安装的补丁冲突，36912597：

<span style="color:#000000">解压 p36912597_<版本>_<平台>.zip
光盘36912597
opatch 先决条件 CheckConflictAgainstOHWithDetail -ph ./
</span>

该报告指出冲突的补丁以及超集的补丁。
使用 My Oracle Support 文档1321267.1 数据库补丁冲突解决方案 来确定每个冲突补丁的冲突解决补丁是否已经可用，以及您是否需要请求新的冲突解决补丁或者冲突是否可以被忽略。
当 My Oracle Support 上提供了您请求的所有临时补丁后，请继续执行第 3.2 节“补丁安装说明”。

3.2补丁安装说明

请按照下列步骤操作：

如果您使用的是 Data Guard 物理备用数据库，则必须在主数据库和物理备用数据库上安装此补丁，如 My Oracle Support 文档278641.1 How do you apply a Patchset, PSU or CPU in a Data Guard Physical待机配置。
如果这是 Oracle RAC 环境，请使用 OPatch 滚动（无停机）安装方法安装此补丁，因为此补丁是可滚动 RAC 安装的。请参阅 My Oracle Support 文档244241.1 Rolling Patch-OPatch Support for RAC。
如果这不是 RAC 环境，请关闭与您正在更新的 Oracle 主目录关联的所有实例和侦听器。有关详细信息，请参阅Oracle 数据库管理员指南。

将当前目录设置为补丁所在的目录，然后输入以下命令运行 OPatch 实用程序：

<span style="color:#000000">unzip -d <PATCH_TOP_DIR> p36912597_<版本>_ <em><平台></em> .zip
cd <补丁顶部目录> 36912597
应用补丁
</span>

如果有错误，请参阅第 5 节“已知问题”。

3.3补丁安装后说明

在Oracle数据库服务器上，安装补丁后，执行以下操作。 Oracle 数据库客户端不需要这样做。

3.3.1应用冲突解决补丁

应用执行第 3.1.4 节 “临时补丁冲突检测和解决”中的步骤时确定需要的补丁冲突解决临时补丁。

3.3.2将修改后的SQL文件加载到数据库中

以下步骤将修改后的 SQL 文件加载到数据库中。对于 Oracle RAC 环境，仅在一个节点上执行这些步骤。

Datapatch is run to complete the post-install SQL deployment for the patch being installed. For further details about Datapatch, including Known Issues and workarounds to common problems, see My Oracle Support document 1585822.1 Datapatch: Database 12c or later Post Patch SQL Automation and My Oracle Support document 2680521.1 Datapatch User Guide.

For each separate database running on the same shared Oracle home being patched, run the datapatch utility as described in Table 2.

表 2 针对非 CDB 或非 PDB 数据库与多租户（CDB 或 PDB）Oracle 数据库运行 Datapatch 实用程序的步骤

步骤	非 CDB 或非 PDB 数据库	步骤	多租户 (CDB/PDB) Oracle 数据库
1	`sqlplus /nolog`	1	`sqlplus /nolog`
2	`SQL> Connect / as sysdba`	2	`SQL> Connect / as sysdba`
3	`SQL> startup`	3	`SQL> startup`
4	`SQL> quit`	4	`SQL> alter pluggable database all` `open;`脚 1
5	`cd $ORACLE_HOME/OPatch`	5	`SQL> quit`
6	`./datapatch -sanity_checks (optional)`	6	`cd $ORACLE_HOME/OPatch`
7	`./datapatch -verbose`	7	`./datapatch -sanity_checks (optional)`
		8	`./datapatch -verbose`

Footnote 1 It is recommended the Post Install step be run on all pluggable databases; however, the following command (SQL> alter pluggable database PDB_NAME open ) could be substituted to only open certain PDBs in the single or multitenant database. Doing so will result in the Post Install step only being run on the CDB and opened PDB's. To update a pluggable database at a later date (skipped or newly plugged in), open the database using the alter pluggable database command mentioned previously and rerun the datapatch utility.
- See My Oracle Support document 1935365.1 Multitenant Unplug/Plug Best Practices for more information about the procedure for unplugging/plugging with different patch releases (in both directions).

Recommended: The datapatch -sanity_checks optional step runs a series of environment and database checks to validate if conditions are optimal for patching. Results are shown on screen with severity and potential actions to take.
- For more information, refer to My Oracle Support document 2680521.1 Datapatch User Guide for additional information and actions. Oracle highly recommends that you perform this step.

The datapatch utility runs the necessary apply scripts to load the modified SQL files into the database. An entry is added to the dba_registry_sqlpatch view reflecting the patch application. In the dba_registry_sqlpatch view, verify that the status for the APPLY is SUCCESS.
- For any other status, refer to My Oracle Support document 2335899.2 Troubleshooting Assistant: 12c Datapatch Issues for additional information and actions.

Check the following log files in $ORACLE_BASE/cfgtoollogs/sqlpatch/36912597/<unique patch ID> for errors:
```
36912597_apply_<database SID>_<CDB name>_<timestamp>.log

```
where database SID is the database SID, CDB name is the name of the multitenant container database, and timestamp is of the form YYYYMMMDD_HH_MM_SS.

Any (pluggable) database that has invalid objects after the execution of datapatch should have catcon.pl run to revalidate those objects. For example:

<span style="color:#000000">export PATH=$PATH:$ORACLE_HOME/bin
cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -e -b utlrp -d $ORACLE_HOME/rdbms/admin utlrp.sql</span>

3.3.3 Upgrade Oracle Recovery Manager Catalog

If you are using the Oracle Recovery Manager, the catalog needs to be upgraded. Enter the following command to upgrade it. The UPGRADE CATALOG command must be entered twice to confirm the upgrade.

<span style="color:#000000">$ rman catalog username/password@alias
RMAN> UPGRADE CATALOG;
RMAN> UPGRADE CATALOG;
RMAN> EXIT;
</span>

3.3.4 Bug Fixes That May Change an Existing Optimizer Execution Plan

At the successful conclusion of the patching event, none of the database bug fixes that may change an existing optimizer execution plan are delivered with the bug fix disabled by default. The status of any module bug fixes (which cause an execution plan change) that were in an enabled state prior to starting the patching event are preserved, but no new module bug fixes (which cause an execution plan change) are activated automatically.

Details on this, including the commands to explicitly enable such bug fixes are present in My Oracle Support document 2147007.1 Managing "installed but disabled" bug fixes in Database Release Updates using DBMS_OPTIM_BUNDLE.

3.3.5 Update Permissions for extjob

Database release update patch installation involves relinking of libraries and executables to be updated. This can sometimes result in permissions changing and needing to be updated. Execute the following as root user:

<span style="color:#000000"># chown root $ORACLE_HOME/bin/extjob
# chmod 4750 $ORACLE_HOME/bin/extjob</span>

3.4 Patch Post-Installation Instructions for Databases Created or Upgraded after Installation of this patch in the Oracle Home

On Oracle Database server, you must execute the steps in Section 3.3.2, "Load Modified SQL Files into the Database" for any new database. There are no actions required for databases that have been upgraded. This is not required on Oracle Database client.

4 Deinstallation

These instructions apply if you need to deinstall the patch.

Section 4.1, "Patch Deinstallation Instructions for a Non-RAC Environment"
Section 4.2, "Patch Post-Deinstallation Instructions for a Non-RAC Environment"
Section 4.3, "Patch Deinstallation Instructions for Oracle RAC Environment"
Section 4.4, "Patch Post-Deinstallation Instructions for Oracle RAC Environment"

4.1 Patch Deinstallation Instructions for a Non-RAC Environment

Follow these steps:

Shut down all instances and listeners associated with the Oracle home that you are updating. For more information, see Oracle Database Administrator's Guide.
Run the OPatch utility specifying the rollback argument as follows.
```
opatch rollback -id 36912597

```
If there are errors, refer to Section 5, "Known Issues".

4.2 Patch Post-Deinstallation Instructions for a Non-RAC Environment

On Oracle Database server, after deinstalling the patch, perform the following actions. This is not required on Oracle Database client.

Rollback SQL changes from the the Database, as explained in Section 4.2.1.
Upgrade Oracle Recovery Manager Catalog, as explained in Section 4.2.2.

4.2.1 Load Modified SQL Files into the Database

Datapatch is run to complete the post-deinstall SQL deployment for the patch being deinstalled. For further details about Datapatch, including Known Issues and workarounds to common problems, see My Oracle Support document 1585822.1 Datapatch: Database 12c or later Post Patch SQL Automation and My Oracle Support document 2680521.1 Datapatch User Guide.

Follow these steps:

For each separate database running on the same shared Oracle home being patched, run the datapatch utility as described in Table 3. If this is Oracle RAC, run datapatch on only one instance.

Table 3 Steps to Run the datapatch Utility for Non-CDB or Non-PDB Database Versus Multitenant (CDB or PDB) Database

Steps	Non-CDB or Non-PDB Database	Steps	Multitenant (CDB/PDB) Oracle Database
1	`sqlplus /nolog`	1	`sqlplus /nolog`
2	`SQL> Connect / as sysdba`	2	`SQL> Connect / as sysdba`
3	`SQL> startup`	3	`SQL> startup`
4	`SQL> quit`	4	`SQL> alter pluggable database all open`Foot 1
5	`cd $ORACLE_HOME/OPatch`	5	`SQL> quit`
6	`./datapatch -sanity_checks (optional)`	6	`cd $ORACLE_HOME/OPatch`
7	`./datapatch -verbose`	7	`./datapatch -sanity_checks (optional)`
		8	`./datapatch -verbose`

Footnote 1 It is recommended the Post Install step be run on all pluggable databases; however, the following command (SQL> alter pluggable database PDB_NAME open ) could be substituted to only open certain PDBs in the single/multitenant database. Doing so will result in the Post Install step only being run on the CDB and opened PDB's. To update a pluggable database at a later date (skipped or newly plugged in), open the database using the alter pluggable database command mentioned previously and rerun the datapatch utility.
- See My Oracle Support document 1935365.1 Multitenant Unplug/Plug Best Practices for more information about the procedure for unplugging/plugging with different patch releases (in both directions).

Recommended: The datapatch -sanity_checks optional step runs a series of environment and database checks to validate if conditions are optimal for patching. Results are shown on screen with severity and potential actions to take.
- For more information, refer to the My Oracle Support document 2680521.1 Datapatch User Guide for additional information and actions. Oracle highly recommends that you perform this step.

The datapatch utility runs the necessary rollback scripts. An entry is added to the dba_registry_sqlpatch view reflecting the patch application. In the dba_registry_sqlpatch view, verify the Status for the ROLLBACK is SUCCESS.
- For any other status, refer to My Oracle Support document 2335899.2 Troubleshooting Assistant: 12c Datapatch Issues for additional information and actions.

Check the following log files in $ORACLE_BASE/cfgtoollogs/sqlpatch/36912597/<unique patch ID> for errors:
```
36912597_rollback_<database SID>_<CDB name>_<timestamp>.log

```
where database SID is the database SID, CDB name is the name of the multitenant container database, and timestamp is of the form YYYYMMMDD_HH_MM_SS.

Any (pluggable) database that has invalid objects after the execution of datapatch should have catcon.pl run to revalidate those objects. For example:

<span style="color:#000000">cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -e -b utlrp -d $ORACLE_HOME/rdbms/admin utlrp.sql</span>

4.2.2 Upgrade Oracle Recovery Manager Catalog

If you are using the Oracle Recovery Manager, the catalog needs to be upgraded. Enter the following command to upgrade it. The UPGRADE CATALOG command must be entered twice to confirm the upgrade.

<span style="color:#000000"><code>$ rman catalog username/password@alias
RMAN> UPGRADE CATALOG;
RMAN> UPGRADE CATALOG;
RMAN> EXIT;
</code></span>

`4.3 Patch Deinstallation Instructions for Oracle RAC Environment`

Patch deinstallation instructions for Oracle RAC includes these environments:

Follow these steps for each node in the cluster, one node at a time.

Shut down the instance on the node.
Run the OPatch utility specifying the rollback argument as follows.
```
<code>opatch rollback -id 36912597
</code>
```
If there are errors, refer to Section 5, "Known Issues".

Start the instance on the node as follows:

<span style="color:#000000"><code>srvctl start instance
</code></span>

`4.4 Patch Post-Deinstallation Instructions for Oracle RAC Environment`

On Oracle Database server, follow the instructions listed in Section Section 4.2, "Patch Post-Deinstallation Instructions for a Non-RAC Environment" only on the node for which the steps in Section 3.3.2, "Load Modified SQL Files into the Database" were executed during the patch application. This is not required on Oracle Database client.

All other instances can be started and accessed as usual while you are executing the deinstallation steps.

`5 Known Issues`

For information about OPatch issues, see My Oracle Support document 293369.1 Primary Note For OPatch.

For issues documented after the release of this patch, see My Oracle Support document 19202410.9 Oracle DB/GI/OJVM Update/Revision R19 Oct 2024 Known Issues

Other issues are as follows.

Issue 1

The following ignorable errors may be encountered while running the datapatch/catbundle.sql script or its rollback script:

<span style="color:#000000"><code>ORA-00942: table or view does not exist
ORA-00955: name is already used by an existing object
ORA-01430: column being added already exists in table
ORA-01432: public synonym to be dropped does not exist
ORA-01434: private synonym to be dropped does not exist
ORA-01435: user does not exist
ORA-01917: user or role 'XDB' does not exist
ORA-01920: user name '<user-name>' conflicts with another user or role name
ORA-01921: role name '<role name>' conflicts with another user or role name
ORA-01927: cannot REVOKE privileges you did not grant
ORA-01952: system privileges not granted to 'WKSYS'
ORA-02289: sequence does not exist 
ORA-02303: cannot drop or replace a type with type or table dependents
ORA-02443: Cannot drop constraint - nonexistent constraint
ORA-04043: object <object-name> does not exist
ORA-06512: at line <line number>. If this error follow any of above errors, then can be safely ignored.
ORA-14452: attempt to create, alter or drop an index on temporary table already in use
ORA-29809: cannot drop an operator with dependent objects
ORA-29830: operator does not exist
ORA-29832: cannot drop or replace an indextype with dependent indexes
ORA-29844: duplicate operator name specified 
ORA-29931: specified association does not exist
</code></span>

`6 References`

The following documents are references for this patch.

Document 36912597.8 Database Release Update 19.25.0.0.241015

Document 1919.2 19c Database Upgrade - Self Guided Assistance with Best Practices

Document 888.1 Primary Note for Database Proactive Patch Program

Document 1585822.1 Datapatch: Database 12c or later Post Patch SQL Automation

Document 293369.1 Primary Note for OPatch

Document 412160.1 Primary Note DST FAQ: Updated DST Transitions and New Time Zones in Oracle RDBMS and OJVM Time Zone File Patches

Document 1321267.1 Database Patch Conflict Resolution

Document 2523220.1 Database 19 Release Updates and Revisions Bugs Fixed Lists

Document 1561792.2 Troubleshooting Assistant: Patching Oracle Database/Client