当前位置:
文档之家› 玩转Oracle EM12c-数据库生命周期管理篇
玩转Oracle EM12c-数据库生命周期管理篇
▪ 锁定过程是什么? ▪ 将部署过程的必要交互步骤的输入结果进行锁 定,使其他操作人员和查询人员无法编辑
▪ 通常两者共同使用来确保标准化的部署新的数据库
概要文件
锁定输入的过程
部署过程
概要文件和锁定
捕获供应的概要文件
锁定的值以只读模式显示
数据库生命周期管理
1
发现与供应
发现企业资产 并在其上供应 软件
例如TNS监听器) • 使目标从“未管理状态” 变为 “管理状
态” • 统一的代理部署流程-目标变为管理状态
后自动进行代理部署
基于Nmap的发现
▪ 什么是Nmap? ▪ IP网络发现工具
▪ 它能发现什么? ▪ 未管理状态的主机和操作系统 (即无代理) ▪ 网络服务(例如TNS监听器)
▪ 使用端口扫描技术 (TCP和UDP协议) ▪ 扫描定义任务中定义端口 ▪ 由管理状态的目标进行扫描 ▪ 非认证的(无需用户名/密码)
1
发现与供应
发现企业资产 并在其上供应 软件
2
补丁与变更管理
对打补丁, 升 级, 和 schema 变更 进行端到端的 管理
3
配置与合规性管 理
跟踪清单, 配 置偏差与合规 性
配置管理
保证配置一致性
如果没有EM,你将: • 在一个类似Excel表格工具中去维护配置细节 • 通过登录数据库操作来手工进行配置对比
生命周期管理 1
挑战和问题 • 长时间的运行与错误检测: • 对诸如RAC类的复杂配置需要较长时间 • 大部分安装并没有预先打好补丁 • 缺乏标准化: • 由于DBA个人习惯不同,部署方式也各种各样 • 安装脚本需要不断修正/修改以适应新版本的需要
供应数据库
供应测试、开发或生产系统
挑战与问题 运行时间长与错误检测
RAC的Rolling模式打补丁
• 在RAC上以Rolling模式打补丁不需要停机 • 补丁支持GI (或Clusterware) Bundles, 一次性将补丁应用到RAC的一个节点的GI和RAC
家目录或者同时在所有节点上全部应用 • 支持对Clusterware或GI和ASM的补丁修补 • 支持10.2.0.x及以上版本
网络发现结果
找到未管理状态的数据库
• 结果以列表形式展示了未安装代理的主 机和网络服务
• 搜寻安装了DB的主机 • 服务= TNS监听器 • 推送 – 将代理推送到主机上 • 忽略 – 异常的结果
Oracle TNS监听器= 未管理状态的DB主机
供应数据库
供应测试、开发或生产系统
如果没有EM,你需要 • 用手工或脚本的方式安装 • 使用响应文件/模板文件的静默安装
• 从My Oracle Support下载元数据并在EM中对目 标端进行应用
• 丰富的信息显示: 如bugs的修复, 相关知识共 享文章, 下载的数量, 趋势
简单的补丁修补过程示例
• 步骤 1: 选择补丁和目标端 • 步骤 2: 选择部署选项
(*部署过程是自动选择的)
• (In-Place模式, Out-of-Place模式, Rolling模式, NonRolling模式)
• 无法在跨多个数据库实施变更
生命周期管理 2
变更管理
2
从测试系统到生产系统的数据库Schema变更
挑战和问题 手工方式 缺乏预览 可扩展性
Enterprise Manager 12c 的解决方案 数据比对和基线 验证并发布有计划的变更
Schema和数据比对
基线 : • 捕获数据库和schema的定义 • 基线版本化 • 变更历史
级
• 支持Exadata 集群数据库的打补丁
补丁修补
• 支持基于补丁的分组
• 操作员只要按补丁“推送按钮”即可进行打补丁过程
• 基于配置的建议/推荐的补丁 • 提供补丁级别与社区反馈
补丁计划
• 在单个停机窗口创建补丁计划和模 板来应用多个补丁
• 冲突检测与补丁合并请求
• 进行预打补丁的独立性与影响分析
自动发现
了解你有什么
挑战与问题 冗长的过程 遗漏的风险
1
Enterprise Manager 12c 的方案 对已知的软件和端口使用基于代理 的IP地址扫描 无代理(网络的)和基于代理 的自动发现
自动发现
无代理的发现
• 使用IP扫描技术( Nmap ) • 发现服务器和在一个端口上的服务监听 (12cNmap
Nmap
配置网络发现
无代理的发现-设置方法
每个代理配置一个IP段
• 选择其中的一个或多个代理来运行 Nmap
• 每个代理都有唯一的IP地址段以进行扫 描
• 用缺省的端口配置服务以进行扫描 (可用 的范围也可)
• 即刻运行或者定制一个计划任务在特定 的时间进行扫描
每个代理 要配置端 口号来进 行扫描
搜索配置信息
对复杂的问题快速寻找答案
• 强大的搜索界面
– 在一个目标端搜索配置属性信息及其与其他目 标端的关联关系
– 之前的EM版本仅支持预定义的搜索 – 利用目标属性
• 用户和多个搜索条件可以创建并保存最新的 配置搜索定义
• 搜索定义组合可以囊括开箱即用的普通/有 利用价值的搜索结果
资产跟踪
• 显示如下的分布信息:
新的或重要的增强
补丁建议
• 连接到My Oracle Support官方网站 – 在线模式
• 直接通过EM访问 • 与My Oracle Support完美结合
• 支持离线的数据中心
– 离线模式
• 不连接到My Oracle Support
• 对Oracle官方推荐的补丁提出预先补丁建议 ( 包括CPU,PSU..)
– 在补丁计划中的补丁
• 实时的目标端检查:
– 目标状态和配置检测 – Opatch版本和 OUI 检测 – 锁,有无用户访问等检测 – 系统空间检测 – 集群验证检测( 利用cluvfy, srvctl
config等工具) – 在sqlplus中运行一些sql进行检测
等
Out-of-Place模式打补丁– 最少的停机时间
供应开发/测试系统
33% 33%
管理高速增长的数据量和 系统
执行重复的任务和流程
26% 21% 21% 17% 13%
数据库管理十大挑战
生命周期管理挑战
保持 补丁 最新 诊断性能
处理日益增长的 安全 威胁
找到最耗资源的SQL语句 管理数据中心不断增长的资
源数量
为合规性需求跟踪配 置变化
将开发/测试环境中进行 的变更应用到生产环境中
2
补丁与变更管理
对打补丁, 升 级, 和 schema 变更 进行端到端的 管理
3
配置与合规性管 理
跟踪清单, 配 置偏差与合规 性
补丁管理
维护补丁级别
如果没有EM,你需要 • 直接用手工安装的方式或用脚本安装 • 需要消耗大量人力精力实现企业级补丁的实施
挑战或者问题 • 预测性: • 在真正打补丁之前无法预测问题与补丁冲突 • 停机时间管理: • 很难跨越多个团队管理停机时间窗口 • 可伸缩性与跟踪: • 在多套数据库上应用多个补丁 • 难于跟踪企业数据库清单的补丁修复情况
• 步骤 3: 运行检测 – 综合分析补丁冲突及目标级别 • 步骤 4: 复查 -> 准备-> 应用
• 在停机前准备要打补丁的系统 • 对于在新文件系统目录安装补丁的情况,则需要克隆一个
Oracle HOME目录并在克隆的数据库上打补丁 • 准备好停机时间.
补丁预修补检测
• 补丁冲突检查
– 选择位于Oracle Home目录的补 丁
挑战和问题: • 时间消耗:
• 在配置比较方面花费了大量时间,且不够准确 • 非常被动:
• 被动方式,无法自动捕获随时间变化的配置偏差 • 可扩展性:
• 比较通常是基于应用上下文的,而不是一成不变的
生命周期管理 3
配置管理
保证配置一致性
挑战与问题 时间消耗 总是被动 可扩展性
3
Enterprise Manager 12c 的解决方案 识别并跟踪资产 比较资产与配置 跟踪和补救偏差
供应开发/测试系统
管理高速增长的数据量和 系统
执行重复的任务和流程
数据库生命周期管理
1
发现与供应
发现企业资产 并在其上供应 软件
2
补丁与变更管理
对打补丁, 升 级, 和 schema 变更 进行端到端的 管理
3
配置与合规性管 理
跟踪清单, 配 置偏差与合规 性
数据库生命周期管理
1
发现与供应
发现企业资产 并在其上供应 软件
比对 • 数据库的基线 • 数据库之间比对 • Schema之间比对 • 数据比对
自动化的发布 • 发布变更 – 变更计划
发布计划的变更
1. 验证计划的变更来检测冲突 或之前应用的变更.
2. 在应用变更之前先预览并编 辑认证的变更.
3. 将最终的认证变更生成SQL 脚本.
4. 应用有效的变更计划
数据库生命周期管理
2
补丁与变更管理
对打补丁, 升 级, 和 schema 变更 进行端到端的 管理
3
配置与合规性管 理
跟踪清单, 配 置偏差与合规 性
发现
了解你有什么
如果没有EM,你需要 • 使用独立的网络发现工具 • 在DNS中使用主机名手工发现
生命周期管理 1
挑战与问题 • 冗长的过程:
• 需要清理非关键性目标 • 需要一个独立的过程上载目标到监控工具中 • 遗漏的风险: • 新创建的数据库可能疏于管理而引发潜在的合规性风险
EM 12c 的补丁管理
• 检测并验证补丁是否修复成功