Enterprise Manager 12c 数据库生命周期管理

2. Enterprise Manager 12c 数据库生命周期管理 ShaileshDwivedi Oracle 产品管理总监

3. 说明 专题讲座：CON1454 标题：EnterpriseManager 12c 数据库生命周期管理 说明：Enterprise Manager 数据库生命周期管理可帮助 DBA 自动执行数百或数千个数据库的日常管理任务。在本专题讲座中，您将了解一些在生产中运行 Enterprise Manager 12c 并使用自动发现、供应、修补、变更管理和合规性等特性的客户。

4. 免责声明 以下内容旨在概述产品的总体发展方向。该内容仅供参考，不可纳入任何合同。其内容不构成提供任何材料、代码或功能的承诺，并且不应该作为制定购买决策的依据。此处所述有关 Oracle 产品的任何特性或功能的开发、发布以及相应的日程安排均由 Oracle 自行决定。

5. 生命周期管理概述 • Verizon Wireless 案例 • Qualcomm 案例 • 问答 议题仅用于准备

6. 十大数据库管理挑战 IOUG 调查 (2011) 跟踪配置 的合规性 45% 26% 采用最新补丁 开发或测试环境中的更改 传播到生产环境 42% 21% 性能诊断 处理不断增长 的安全威胁 供应测试或 开发系统 35% 21% 实时识别资源密集型 SQL 语句 管理快速增长的 数据和系统 33% 17% 使用分级资源管理数据中心增长 执行重复 任务和流程 33% 13%

7. 十大数据库管理挑战 生命周期管理面临的挑战 跟踪配置 的合规性 采用最新补丁 开发或测试环境中的更改传播到生产环境 性能诊断 处理不断增长的 安全威胁 供应测试或 开发系统 实时识别资源密集型 SQL 语句 管理快速增长的 数据和系统 使用分级资源管理数据中心的增长 执行重复 任务和流程

8. 数据库生命周期管理 发现和 初始供应 持续 变更管理 持续配置 和合规性管理 1 2 3 供应 补丁 跟踪合规性 传播、部署 管理增长 安全和审计 重复、自动化 重复、自动化 重复、自动化

9. 数据库生命周期管理 发现和供应 补丁和 变更管理 配置 和合规性管理 1 2 3 端到端管理补丁、升级和模式变更 发现资产并供应相关软件 跟踪资产清单、配置偏差和合规性

10. 发现 生命周期 管理 1 了解现状 不使用 Enterprise Manager 的流程 • 使用独立网络发现工具 • 使用主机名从名称服务器中去发现 挑战与问题 • 流程繁琐： • 清除非关键性目标 • 使用单独的流程将发现的目标上传到监视工具 • 遗漏风险： • 新数据库不受管理，带来潜在的合规性风险

11. 自动发现 了解现状 Enterprise Manager 12c 解决方案 挑战与问题 对已知软件和端口执行基于代理的 IP 扫描 1 流程繁琐 无代理和基于代理的自动发现 遗漏风险

12. 对已知软件和端口执行基于代理的 IP 扫描 从代理自动扫描 IP 范围 扫描已知软件签名，用户可以进一步扩展。

13. 无代理和基于代理的自动发现 将目标分为主机和非主机类别 忽略监视目标

14. 供应数据库 生命周期 管理 1 供应测试、开发或生产系统 不使用 Enterprise Manager 的流程 • 手动或基于脚本的安装 • 使用响应/模板文件的静默模式安装 挑战与问题 • 时间长且容易出错： • 对于 RAC 等复杂配置，处理时间长 • 大多数安装没有预先打补丁 • 缺乏标准化： • 由于 DBA 各有喜好，部署不尽相同 • 需要频繁修改脚本以支持新版本 “标准化也非常重要，不仅指技术和流程，还包括方法的标准化”，BT Operate 核心技术 CTO SurrenPartabh指出

15. 供应数据库 供应测试、开发或生产系统 Enterprise Manager 12c 解决方案 自动化大规模部署 挑战与问题 1 使用供应配置文件进行标准化 流程时间长且容易出错 缺乏标准化 角色与访问隔离

16. 自动化大规模部署数据库 自动数据库软件部署的部署过程

17. 使用供应配置文件进行标准化 从现有预打补丁、已批准的安装中捕获黄金映像和配置属性以部署随时准备使用的标准化软件

18. 设计人员和运营商之间的角色和访问隔离 运营商视图 作为设计人员，指定和锁定输入值 尽量减少运营商所需的输入 减少错误和配置变化 设计人员视图 设计人员视图

19. 打补丁 生命周期 管理 2 维护补丁级别 不使用 Enterprise Manager 的流程 • 直接或使用脚本手动安装 • 覆盖一个环境需要多人多个工时 挑战或问题 • 可预测性： • 在修补过程之前无法识别问题和补丁冲突。 • 停机管理： • 需要执行维护时难以管理不同团队之间的停机时段 • 可伸缩性和跟踪： • 将多个补丁应用到大量数据库 • 难以跟踪已打补丁和未打补丁的数据库清单

20. 打补丁 2 维护补丁级别 Enterprise Manager 12c 解决方案 挑战与问题 自动化大规模部署 可预测性 尽量缩短停机时间，通过先决条件检查识别问题 停机管理 补丁模板和合规性标准 可伸缩性

21. 识别 Oracle 推荐的补丁 针对 Oracle 推荐的补丁（包括 CPU、PSU……）的主动修补建议 支持： 在线模式（与 My Oracle Support 直接连接） 离线模式（不与 My Oracle Support 连接），用户可以上传目录以生成建议。 提供有关补丁的丰富信息，如修复的错误、相关 KM 文章、下载次数、趋势等。

22. 批量部署以避开时间限制 简化的基于向导的方法 用户可以对多个目标应用多个补丁

23. 使用分析模式执行运行前检查 自动补丁冲突解决流程 全面的运行前检查

24. 缩短停机时间、更好地管理维护计划 “异地”修补，能够： • 缩短停机时间 • 灵活管理维护时段 • 出现问题时切换回原来的配置

25. 补丁推出的自动化和跟踪 使用补丁计划中的补丁创建补丁模板和合规性标准 使用补丁模板和合规性标准管理和监视补丁推出

26. 主要版本自动升级 • 使用升级计划程序计划升级 • 将所需软件和补丁下载到软件库 • 大规模自动升级

27. 变更管理 生命周期 管理 2 将开发环境中的数据库模式变更应用到生产环境 不使用 Enterprise Manager 的流程： • 使用 SQL 脚本 • 手动操作以验证和传播变更 挑战与问题： • 缺乏预览： • 在应用之前无法执行预览和编辑更改，除非从头返工 • 可伸缩性： • 无法将变更推出到多个数据库

28. 变更管理 2 将开发环境中的数据库模式变更应用到生产环境 Enterprise Manager 12c 解决方案 挑战与问题 数据比较与基准制定 手动 验证和传播计划更改 缺乏预览 可伸缩性

29. 模式和数据比较 基准： • 捕获数据库和模式定义 • 确定基准版本 • 变更历史 比较 • 基准与数据库 • 数据库与数据库 • 模式与模式 • 数据比较 自动传播 • 传播所需更改 － 变更计划

30. 模式和数据比较 基准： • 捕获数据库和模式定义 • 确定基准版本 • 变更历史 比较 • 基准与数据库 • 数据库与数据库 • 模式与模式 • 数据比较 自动传播 • 传播所需更改 － 变更计划

31. 传播计划更改 • 验证计划的更改，识别是否存在冲突或为以前应用过的更改 • 在应用之前，预览并编辑已验证的更改。 • 生成最终验证更改集的 SQL 脚本。 • 应用经过验证的计划更改

32. 配置管理 生命周期 管理 3 确保配置的一致性 不使用 Enterprise Manager 的流程： • 以电子表格的形式维护详细信息 • 通过上传到数据库人工比较配置 挑战与问题： • 费时： • 配置比较耗时且容易出错 • 非常被动： • 过程是被动的，不能自动捕获配置随时间的偏差 • 可伸缩性： • 比较通常不是一揽子性的，必须在应用程序的上下文环境中进行

33. 配置管理 3 确保配置的一致性 Enterprise Manager 12c 解决方案 挑战与问题 识别和跟踪资产 费时 比较资产和配置 完全被动 跟踪和解决偏差 可伸缩性

34. 识别和跟踪资产 资产清单和使用详情信息板 使用趋势信息进行计划

35. 配置比较模板 • Oracle 预配置模板 • 自定义用于各特定案例的模板（黄金、基准） • 为需要通知的对象配置属性差异 • 可以忽略某些差异

36. 跟踪和解决与标准的偏差 识别整个环境体系中的偏差。 采取纠正措施解决问题。

37. 合规性管理 生命周期 管理 3 确保所有数据库的合规性 不使用 Enterprise Manager 的流程： • 对配置的人工审计耗时长，每个审计周期重复进行 挑战与问题： • 高成本： • 资源消耗巨大、审计成本高 • 高风险因素： • 公司存在违反法定标准的风险

38. 合规性管理 3 确保所有数据库的合规性 Enterprise Manager 12c 解决方案 挑战与问题 现成的合规性库 高成本 监视和管理合规性 高风险 遵守合规性并生成报表

39. 使用仪表盘监视和管理合规性

40. 遵守合规性并生成报表

41. 集成化的系统管理 Exadata 管理 ? = 基准 黄金映像 当前 异地应用推荐的补丁，无需停机 识别整个系统中的偏差

42. 使用 Enterprise Manager 12c 为数据库打补丁

43. 议题 • VZW DBA 面临的挑战 • Enterprise Manger 12c 环境 • 补丁用例 • 特性和计划 • 优势

44. VZW DBA 面临的挑战 修补/升级 • 规则要求每季度打一次补丁 • 在极短的维护时间内修补/升级大量数据库 • 要求系统管理员参与修补/升级过程 可管理性 • 资产清单跟踪 • 向非生产数据库部署更改 • 合规性管理和管理报表

45. VZW 业务要求 • 每年必须为 520 多个数据库应用 2 次补丁集更新 (PSU) • 400 个非生产数据库以及 120 多个生产数据库。 • DBA 每年需要打 4 个月的补丁（两个 90 天的修补时段） • 在此期间，DBA经常需要加班加点，尤其是在晚上和周末时间。 • 要求系统管理员参与修补过程。修补过程中还涉及其他团队。 • 团队主管、项目经理、应用程序测试人员和系统管理员。 • 这些人员在修补时段都需要加班。

46. 为什么选择 Oracle Enterprise Manager 12c？ 补丁管理（修补/升级） 每季度对 RAC 环境应用一次 GI PSU 补丁 同时对网格基础架构和 RAC 数据库打补丁 修补单实例数据库 变更管理（可管理性） 由应用程序团队跟踪跨非生产环境和生产环境的变更。 覆盖： 跨多个平台的 RAC 数据库和单实例数据库 我们的团队内就有约 30 个 RAC 集群（包括单一实例）

47. Enterprise Manager 12c 前景 • 测试环境 EM12c － 已安装且正在运行。 版本：12.1.0.1（包括补丁包 1） 平台：Linux x86-64 OMS 数： 1 信息库数据库：11.2.0.3 单实例数据库 • 生产环境：正在进行版本： 12.1.0.1       平台：SPARC T4（每台有 8 个 CPU，32G 内存）上的 Solaris 10 OMS 数：2信息库：2 节点 RAC 数据库

48. 试点用例：在 RAC 上应用 GI PSU 案例： • 第 1 轮：在 RAC 上应用 2012 年 1 月的 PSU。 • 第 2 轮：在 RAC 上应用 2012 年 7 月的 PSU。 • 2 节点RAC，带 Solaris 平台上的 15 个 11.2.0.2 RAC 数据库 方法： • 从补丁建议识别补丁和受影响的目标 • 使用补丁和目标创建补丁计划 • 提前通过分析模式运行先决条件检查 • 与应用程序团队沟通确定非高峰使用期间 • 转到滚动模式部署补丁 重要的先决条件： • 所有 RAC 实例必须均已启动运行。 • 所有 RAC 数据库在 EM 中标识为目标

49. 试点用例：结果 • 成功修补 2 节点 RAC 上的 15 个数据库 • 包括使用 SQL 应用程序修补 GI 和 RAC DB OH • 修补时间 － 手动（6 至 8 小时），EM (1:48:58) • 使用 EM 的参与时间可以只要几分钟（第一次 15 分钟） • 通过 EM，SQL 是并行应用的 • 其他事项： • 需要以最新补丁设置 EM（……） • 创建了命名凭证，对于ROOT，我们从 SA 获得了临时口令（进一步处理的领域） • 作为先决条件，所有实例必须均已启动运行：有助于提前发现问题。

50. 第 1 步/共 5 步：识别推荐的补丁 全面的补丁建议：直接识别补丁集更新建议