Oracle 补丁管理

 

本文永久地址:https://www.askmaclean.com/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 )
  • 其他测试

 

补丁发布前的测试种类(1)

功能测试功能回归测试
§每个功能区都被分组,所有数据库功能的回归测试~例)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测试

§认证测试

§安装(适用于补丁)、升级降级测试

§内部系统的使用与反馈

补丁发布前测试种类(3)

  • 功能回归测试的数量一般是增加的,11gR2增加了10gR2 的80%,10gR2 增加了10gR1 的50%
  • 要变更所有的代码需要在产品发行之前,对这些功能进行回归测试

 

补丁发布前的测试种类

补丁的种类与测试内容

  • 补丁直到发布所要经历的测试的内容,对应补丁的种类如下所示。
个别补丁 SPU, PSU, BP PSR
回归测试 §确认修正bug

§受到了影响的区域的回归测试

§完全的回归测试 §完全的回归测试
系统测试 §N/A §系统测试的子菜单 §完全的系统测试
性能测试 §N/A §工作量所决定的性能回归测试 §完全的性能测试
其他测试 §安装(适用于补丁)测试

§EM决定的补丁适用测试

§安装(适用于补丁)测试

§从SPU, PSU, BP之前的版本开始的升级

§EM决定的补丁适用

§由各种各样脚本来进行的安装/升级测试

§适用于公司内部系统

§认证测试

 

Exadata发布前测试的区域

各个区域各自的子区域(各个项目)中所包含的测试案例很多,但还是需要连续执行回归测试

 

exadata_测试

 

 

exadata_测试1

exadata_测试2

 

定期性补丁适用测试

定期性补丁适用测试计划的必要性

 

  • 想获得定期性补丁适用测试的背景
  • 全球范围内大部分的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也同时适用的计划

exadata_bundle_patch

 

在补丁适用时想获得的测试内容

 

Interim Patch SPU, PSU BP, QDPE PSR
安装测试
确认不良情况~

作为回避方案适用补丁时

§在可能的情况下执行 §相关地址在可以进行验证的情况下实施 §相关地址在可以进行验证的情况下实施 §相关地址在可以进行验证的情况下实施
DB基本操作确认、

基本的应用操作、

代表性的負荷主导的性能测试

§不要 §选项 §必要 §必要
应用全功能测试、

性能测试

§不要 §不要 §不要 §必要

 

 

测试项目与高效化方案

测试项目与高效化方案

 

测试项目与高效化方案1

确认使用RAT的执行计划是否会有影响

确认使用RAT的执行计划是否会有影响

 

直到适用与现实环境补丁的流程

开发环境、QA环境、现实环境中的补丁适用

 

开发环境、QA环境、现实环境中的补丁适用

选择补丁适用策略

选择补丁适用策略

测试日程表的计划

  • 确认补丁修正内容

–确认提供补丁的修正信息,确认是否对补丁适用有影响

  • 案例讨论

–从修正内容开始考虑,计划覆盖范围,讨论案例。

  • 功能测试

–确认有代表性的应用的操作,另外,进行画面迁移测试以及全键控测试。

  • 性能测试

–测试高负荷环境下系统的稳定性

  • QA系统中的周期测试

–验证运行脚本,批量工作

 

测试日程表的计划

总结

  • 补丁的种类有PSE, SPU, PSU, PSR。还提供作为Exadata的累积补丁的Bundle Patch (QDPE)、Storage Server Patch 。
  • 在补丁发布前的测试中,有功能测试、系统测试、性能测试等领域,昼夜自动执行的回归测试也被实施,由此可以确保品质。
  • 全球范围内,大部分Exadata用户都使用特定的补丁包,万一发生故障,可以迅速做出反应。
  • 请大家开路实现定期的补丁适用的补丁适用计划、测试计划。

 

Comment

*

沪ICP备14014813号

沪公网安备 31010802001379号