slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
性能调优:有关活动会话历史记录和自动负载信息库的 10 个新技巧 PowerPoint Presentation
Download Presentation
性能调优:有关活动会话历史记录和自动负载信息库的 10 个新技巧

Loading in 2 Seconds...

play fullscreen
1 / 58

性能调优:有关活动会话历史记录和自动负载信息库的 10 个新技巧 - PowerPoint PPT Presentation


  • 213 Views
  • Uploaded on

性能调优:有关活动会话历史记录和自动负载信息库的 10 个新技巧. Deba Chatterjee 首席产品经理. 三种类型的性能管理. 被动式性能管理. 被动式性能管理. 不一致的性能 系统资源过度使用 高负载的即席查询占用了大量资源 查询的执行计划发生变化 并行执行出现降级. 比较两个时段的性能. 昨天我的应用程序性能还不错,可今天就变得很慢。. 技巧:比较时段 ADDM. SQL 通用性. SQL 性能回退. AWR 快照 第一时段. I/O 受限. 过小的 SGA. 比较时段 ADDM. 分析报告. AWR 快照

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '性能调优:有关活动会话历史记录和自动负载信息库的 10 个新技巧' - aidan-cochran


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide2
性能调优:有关活动会话历史记录和自动负载信息库的 10 个新技巧

DebaChatterjee

首席产品经理

slide6
不一致的性能

系统资源过度使用

高负载的即席查询占用了大量资源

查询的执行计划发生变化

并行执行出现降级

比较两个时段的性能
  • 昨天我的应用程序性能还不错,可今天就变得很慢。
slide7
技巧:比较时段 ADDM

SQL 通用性

SQL 性能回退

AWR 快照

第一时段

I/O 受限

过小的 SGA

比较时段 ADDM

分析报告

AWR 快照

第二时段

  • 两个 AWR 快照时段的完全 ADDM 分析
  • 检测原因、衡量结果,然后将它们关联
    • 原因:负载发生变化时,配置也会发生变化
    • 结果:SQL 性能回退、达到资源限制(CPU、I/O、内存、互连)
  • 给出可行的建议与量化的影响
slide8
比较时段 ADDM:方法
  • 缓冲区缓存减小了 30%
  • SQL 增加 10%
  • 首要 SQL 增加了 45%
  • 读取 I/O 增加了 55%
  • 缓冲区缓存减少导致读取 I/O 增加
slide10
数据库挂起状态

阻塞会话

内存分配问题

库缓存问题

存储不响应 (ASM)

互连问题

数据库挂起分析
  • 我的数据库挂起了。我不想重启数据库。
slide11
技巧:实时 ADDM

EM Agent

挂起

诊断连接

数据库不响应

JDBC 连接

实时分析

数据库

  • 对不响应的系统使用预先设定的诊断连接
  • 启动标准 JDBC 连接以进行实时分析
  • 诊断连接将会收集数据,在此过程中不会上锁或运行 SQL
  • 发生问题时,不论系统的状况有多糟,这都是诊断问题首选的智能顾问

死锁

闩锁

ADDM 分析

slide12
实时 ADDM
  • 实时分析挂起或缓慢的数据库系统
  • 从整体上识别全局资源争用和死锁
  • 量化的性能影响
  • 准确可行的建议
  • 为 RAC 提供群集范围的分析
slide14
我启用了并行查询,但这个查询还是花了很长的时间。我想知道这究竟是怎么回事。我启用了并行查询,但这个查询还是花了很长的时间。我想知道这究竟是怎么回事。

并行降级

不受控制的并行执行

并行服务器可用性

对象级设置

会话级设置

SQL 性能分析
slide15
技巧:实时 SQL 监视

使用并行提示执行的插入

slide16
实时 SQL 监视

“并行”选项卡

  • 并行协调器在整个期间都处于忙碌的状态!!
slide17
实时 SQL 监视

启用并行 DML 后

  • 并行从查询在整个期间都处于忙碌的状态!!!
slide18
简单查询却花费了很长的时间。数据库出了什么问题?简单查询却花费了很长的时间。数据库出了什么问题?

SQL 性能问题

统计信息

资源

应用程序问题

并行性

初始化参数

SQL 性能分析
slide19
技巧:实时 SQL 监视

带有 Count 和 Group By 的 SQL

slide20
实时 SQL 监视

带有 Count 和 Group By 的 SQL

slide21
实时 SQL 监视

PGA 大小增加

slide25
可以跟踪我的程序吗?

这种跟踪存在什么问题?

一种非常被动的观察问题的方式

需要额外的开销将数据写入跟踪文件

需要跟踪的程序通常都是存在问题的程序

影响生产系统的性能

被动跟踪长时间运行的程序?
slide26
监视复杂的数据库操作

数据库中实际发生的情况

挑战

解决方案

  • SQL 和 PL/SQL 监视仅监视单个执行
  • DBA 应当如何监视组合操作(如批处理作业)?
  • 实时数据库操作监视
  • 好处:DBA 可以分析和调优复杂的组合数据库操作
slide27
实时数据库操作监视

了解出现的问题,并以更迅速的方式解决问题。

  • 应用程序作业的数据库监视
    • 为应用程序作业分组 SQL、会话
    • 主要情形:ETL 操作、季末工作
  • 由应用程序指定的标签驱动的实时监视
    • 将会自动监视 Oracle 数据泵作业
    • PL/SQL、OCI 和 JDBC 中的标签功能
  • 避免 SQL*Trace 的开销
  • 可以看见首要 SQL 语句、系统和会话的性能指标
slide28
为数据库操作命名

DBOP 的设置方法

命名或括号结构

标签

隐式(用于 Java 和 OCI)

显式

DBOP (标签)

BEGIN_OPERATION

SQL

PL/SQL 块

SQL

SQL

SQL

PL/SQL 块

SQL

SQL

END_OPERATION

slide29
监视组合数据库操作
  • Oracle Database 11g:支持简单数据库操作
    • PL/SQL 过程/函数
  • Oracle Database 12c:支持组合操作(新增)
    • 应用程序代码或 DBA 定义的两个时间点之间的一个或多个会话活动
    • 例如:SQL*Plus 脚本、批处理作业或 ETL 处理
    • 每个 DB 会话最多可具有一个 DBOP
slide31
昨天晚上执行的批处理作业花了两倍的时间才完成,不知是哪里出了问题。昨天晚上执行的批处理作业花了两倍的时间才完成,不知是哪里出了问题。

无法检测瞬时问题

查看 AWR 数据

在快照窗口中会被平均值掩盖

磁盘上的 ASH 数据

每 10 秒采样一次

若要检测在“过去”时间内发生的此类问题,难度非常大

分析瞬时性能问题
slide32
自动性能诊断

ADDM 系列:

数据库性能管理的不断发展

比较时段 ADDM

比较时段 ADDM

实时 ADDM

实时 ADDM

增强的实时 ADDM

ADDM

ADDM

  • 诊断长期存在的性能问题
  • 使用 AWR 快照
  • 每小时自动运行一次
  • 深入比较两个时段的性能
  • 使用 AWR 数据
  • 手动触发
  • 挂起或速度极慢的数据库
  • 使用常规和诊断模式连接
  • 手动触发
  • 主动检测和诊断性能峰值
  • 使用内存中数据
  • 每 3 秒自动运行一次
slide33
增强的实时 ADDM

用于严重性能问题的数据库自我监视

  • 主动问题检测和分析
    • 每 3 秒运行非常轻量级(内存中、无闩锁)的检查
    • 检测到性能低下的趋势时,触发进一步的分析
    • 对高 CPU 占用、I/O 峰值、内存、互连、挂起和死锁进行分析
    • 在问题威胁到应用程序性能之前将其识别
  • 对于当前的峰值,可以手动触发实时 ADDM
    • 用于短时间(5 分钟以内)的性能峰值,如影响非常严重的瞬时问题
    • 提供对关键问题的可行建议
    • 可在分析中使用更丰富的数据集
  • 保存在 AWR 中用于历史分析的报告(分析和数据)
slide36
SQL 响应指标超过了警告阈值。出现了什么问题?

多种因素都会影响 SQL 响应时间

系统负载上升或异常

硬件问题

失控查询占用了大量系统资源

执行计划更改

对象统计信息缺失或陈旧

需要一种快速分析内存中性能数据的机制

了解负载情况
slide37
数据库响应时间分析—AWR
  • AWR 的“前 5”部分显示了对 DB 等待时间影响最大的 Wait 类
  • 可通过 AWR 中的“Segment Statistics”部分识别涉及 TX 行锁争用的对象

可通过 AWR 中的“Foreground Wait Class”部分查看 DB 等待在 Wait 类上的分布情况

awr ash
从 AWR 到 ASH
  • 针对应用程序等待增加时段的 ASH 报告将会显示出和 AWR 中所示相同的等待情况
  • 是否可以获取受此类争用影响的应用程序模块?
slide39
从 ASH 提取更多数据
  • 识别因等待“Application”Wait类而受影响的 SQL 语句和会话
slide40
从 ASH 提取更多数据
  • 获取阻塞会话和 DB 对象的列表!
slide41
了解负载情况
  • 用于高级分析的图形化 ASH 报告
  • 为递归下钻提供可视化过滤
  • 可以选择任何时间段来进行分析
  • 可以对性能进行多方面的分析
  • 不同的可视化:堆叠图表或树状图
  • 使用活动报告与他人协作
slide45

案例研究

数据库管理

1.87 亿名成员

年收入 2.52 亿美元800 个 Oracle 数据库

1400 个应用程序

关注

预防式性能管理

挑战:

  • LinkedIn 的 ERP 系统正从 DB10g 升级到 DB11g
  • 系统内存在大量定制代码
  • 可用于完成升级的时间很有限。
  • 管理人员对系统性能顾虑重重
  • 初始测试中未发现任何重大问题或顾虑
  • 就在上线的一周前,发现了多处致命的潜在性能问题。
  • 在如此短的时间窗口内,已经不可能再重新编写或调优涉及的数段代码。
  • 决定在过渡时期使用 SQL 配置文件或基准回退到 DB10g 计划

使用 Oracle Enterprise Manager:

  • 使用 EM 回退到旧计划以运行一项调用执行缓慢的 SQL 的作业
  • 使用 SQL Tuning Advisor 下钻到会话,识别出该 SQL ID
  • 此时可以在同一窗口中比较解释计划和查看新的解释计划
  • 通过鼠标单击完成指导性向导,以实施 SQL 配置文件
  • 完成!!!
sql tuning advisor
SQL Tuning Advisor

SQL 剖析

统计信息分析

访问路径分析

SQL 重构分析

备选计划分析

并行查询分析

收集缺少或陈旧的统计信息

创建 SQL 配置文件

添加缺少的访问结构

修改 SQL 构造

采用替代执行计划 (11.2)

创建并行 SQL 配置文件 (11.2)

SQL

SQL Tuning Advisor

SQL

自动调整优化程序

  • 分析统计信息以确保准确
  • 推荐用于透明应用程序调优的 SQL 配置文件
  • 推荐访问结构和备选 SQL,以加快查询执行速度
  • 使用实时和历史性能数据确定备选执行计划,以从计划性能回退中恢复
  • 推荐合适的并行度以实现最佳性能

管理员

全面的 SQL 调优建议

slide48
我们正在进行模式整合,如何确保不会有模式或用户耗尽我们所有的系统资源?我们正在进行模式整合,如何确保不会有模式或用户耗尽我们所有的系统资源?

Database Resource Manager 的指令可以防止单个用户会话占用全部资源

创建资源分配策略

为各个用户组分配合适的 CPU 和 I/O (Exadata)

确保最佳资源分配
oracle enterprise manager
技巧:在 Oracle Enterprise Manager 中设置资源管理器
  • 使用 Enterprise Manager UI 管理资源计划非常容易
slide52
新的 BI 系统定义了非常积极的 SLA。如何确保在整个系统中保持一致的性能?

代码迁移以及新的索引和对象可能经常会影响应用程序的性能

如何在这些变化上线之前验证关键查询的性能?

防止由应用程序变化导致的性能问题
slide53

验证

定制代码迁移的影响

中央 SPA 系统

生产

试验 1

状态 1

01001011001010100100100100100100100100100100100010010101001001001001110010010010010010010000100100000101110010010101001001001010101001000100000101010010010101010011010100101010010010101001100101

定制代码更改

试验 2

状态 2

  • 使用 SPA 导引式工作流(推荐)或 PL/SQL API
  • 创建前 X(20 或 30)个查询的 SQL 调优集
  • 使用当前状态远程建立第一试验 — 基准
  • 进行更改 — 创建索引或迁移定制代码
  • 使用同样的 SQL 调优集远程建立第二试验
  • 检查 SPA 报告,然后将更改上线或回滚。
slide54
技巧:去除猜测成分!
  • 分别在迁移更改之前和之后运行试验
  • 确保最重要的查询没有性能回退
  • 去除猜测成分