本文永久地址：https://www.askmac.cn/archives/oracle-补丁管理.html
- 补丁的种类
- 补丁发布前测试的种类
- 定期性的补丁适用测试
- 总结
补丁的种类
| 补丁名称 | 适用对象 | 发行周期 |
| Interim Patch (One-off, PSE) | Oracle Database | 不定期 |
| Security Patch Update (SPU)＊ | Oracle Database | 每季度 |
| Patch Set Updates (PSU) | Oracle Database,
Grid Infrastructure |
每季度 |
| Patch Set Release (PSR) | Oracle Database,
Grid Infrastructure |
一年一次或者多年一次 |
- ＊ 至此都称为 CPU (Critical Patch Update)
- 除了上述4种补丁，在Windows环境下还提供Bundle Patch 。
补丁种类～Exadata
| 补丁名称 | 适用对象 | 发行周期 | |
| Exadata Storage Server patch | Exadata Storage Server (SW/OS/HW)
Database Server (OS/HW) |
每季度 | |
| Bundle Patch
(BP) |
Quarterly Database Patch for Exadata (QDPE)＊ | Oracle Database,
Grid Infrastructure |
每季度 |
| Interim Database Patch for Exadata (Interim BP) | 同上 | 每个月或两个月 | |
- ＊11.2.0.3以后的推荐补丁包称为「Quarterly Database Patch for Exadata (QDPE)」，配合SPU以及PSU的发行，每季度都发行一次。
- QDPE是适用于许多客户的Bundle Patch。除QDPE以外、每个月或者每两个月都会发行一般的Bundle Patch。
- 这些Bundle Patch适用于情况不好的需要修正，却又等不到下一个QDPE的情况。
- 所有CPU的修正都包含PSU。所有的PSU、BP都是累积型。
补丁制作流程（以One-off Patch 为例）
补丁发布前的测试种类
- 功能测试（功能回归测试）
- 系统测试
- 性能测试（ Performance Regression test ）
- 其他测试
补丁发布前的测试种类（１）
| 功能测试（功能回归测试） |
| §每个功能区都被分组，所有数据库功能的回归测试～例）OPTIMIZER
§测试案例通过会因为追加检查项目以及追加功能而增加～例）11gR2增加了10gR2的80%、10gR2增加了10gR1的40% §新开发的版本，每天都会执行回归测试 §新建的代码需要在开发中被merge之前，回归测试合格。 |
| 系统测试 |
| §可扩展性、高可用性、高可信性、性能的观点开始直到Oracle Database、Exadata的极限为止，进行drive～ 例）同时执行用户，并列度，cursor、分区、磁盘、stand by system、REDO适用速度、复杂的topology等。
§硬件的极限性能～内存, CPU, I/O, 网络 §由于同时执行性较高的worklord，对Oracle Database施压 §根据现实世界中的客户的工作负载来决定的现实世界的测试 §高负荷环境下的障碍测试 |
| 性能测试
（Performance regression test） |
| §工作量决定的Performance regression test
§为了确认整合性/功能性的Performance regression test §SQLstatement的instruction trace、每个Instruction的内存分配的确认 §Oracle Database的高位Stack是否受到性能影响的确认 §Fusion Middleware、EBS、Siebel、PeopleSoft、Fusion Application等等 |
| 其他测试 |
| §Beta测试
§认证测试 §安装（适用于补丁）、升级降级测试 §内部系统的使用与反馈 |
补丁发布前的测试种类（３）
- 功能回归测试的数量一般是增加的，11gR2增加了10gR2 的80%，10gR2 增加了10gR1 的50%
- 要变更所有的代码需要在产品发行之前，对这些功能进行回归测试
补丁的种类与测试内容
- 补丁直到发布所要经历的测试的内容，对应补丁的种类如下所示。
| 个别补丁 | SPU, PSU, BP | PSR | |
| 回归测试 | §确认修正bug
§受到了影响的区域的回归测试 |
§完全的回归测试 | §完全的回归测试 |
| 系统测试 | §N/A | §系统测试的子菜单 | §完全的系统测试 |
| 性能测试 | §N/A | §工作量所决定的性能回归测试 | §完全的性能测试 |
| 其他测试 | §安装（适用于补丁）测试
§EM决定的补丁适用测试 |
§安装（适用于补丁）测试
§从SPU, PSU, BP之前的版本开始的升级 §EM决定的补丁适用 |
§由各种各样脚本来进行的安装/升级测试
§适用于公司内部系统 §认证测试 |
Exadata发布前测试的区域
各个区域各自的子区域（各个项目）中所包含的测试案例很多，但还是需要连续执行回归测试
定期性补丁适用测试
定期性补丁适用测试计划的必要性
- 想获得定期性补丁适用测试的背景
- 全球范围内大部分的Exadata都适用特定的补丁包
- 万一发生故障可以迅速做出反应
- 可以获得Exadata关键问题信息（Doc ID 1270094.1）
每个季度都可以使用得到品质担保的历史补丁
- 提供Quarterly Full Stack Download Patch (QFSDP)
- 清除被重新定义的功能测试以及压力测试的Exadata 的各个组成部分补丁
- 用户可以从全栈下载补丁中使用必须的补丁
Exadata Bundle Patch(BP) 与 SPU, PSU的关系
Database 相关补丁的发行日程例 11.2.0.3的情况下
- SPU、PSU、BP 对于 PSR (Patch Set Release）会被发行。
- 立足于QDPE的适用计划，请考虑每个季度都会发行的Exadata Storage Server patch也同时适用的计划
在补丁适用时想获得的测试内容
| Interim Patch | SPU, PSU | BP, QDPE | PSR | |
| 安装测试 | ○ | ○ | ○ | ○ |
| 确认不良情况～
作为回避方案适用补丁时 |
§在可能的情况下执行 | §相关地址在可以进行验证的情况下实施 | §相关地址在可以进行验证的情况下实施 | §相关地址在可以进行验证的情况下实施 |
| DB基本操作确认、
基本的应用操作、 代表性的負荷主导的性能测试 |
§不要 | §选项 | §必要 | §必要 |
| 应用全功能测试、
性能测试 |
§不要 | §不要 | §不要 | §必要 |
测试项目与高效化方案
确认使用RAT的执行计划是否会有影响
直到适用与现实环境补丁的流程
开发环境、QA环境、现实环境中的补丁适用
选择补丁适用策略
测试日程表的计划
- 确认补丁修正内容
–确认提供补丁的修正信息，确认是否对补丁适用有影响
- 案例讨论
–从修正内容开始考虑，计划覆盖范围，讨论案例。
- 功能测试
–确认有代表性的应用的操作，另外，进行画面迁移测试以及全键控测试。
- 性能测试
–测试高负荷环境下系统的稳定性
- QA系统中的周期测试
–验证运行脚本，批量工作
总结
- 补丁的种类有PSE, SPU, PSU, PSR。还提供作为Exadata的累积补丁的Bundle Patch (QDPE)、Storage Server Patch 。
- 在补丁发布前的测试中，有功能测试、系统测试、性能测试等领域，昼夜自动执行的回归测试也被实施，由此可以确保品质。
- 全球范围内，大部分Exadata用户都使用特定的补丁包，万一发生故障，可以迅速做出反应。
- 请大家开路实现定期的补丁适用的补丁适用计划、测试计划。
Leave a Reply