数据库性能诊断的七种武器

  • 4,177 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,177
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
207
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Enqueue 有 3 个参数: 1. P1 表示 Lock type 、 mode 比如, P1RAW 的值为 54580006 ,其中, 54 表示的是 T , 58 表示的为 X , 6 表示的专用锁; 也可以用 SELECT chr(to_char(bitand(p1,-16777216))/16777215)|| chr(to_char(bitand(p1, 16711680))/65535) "Lock", to_char( bitand(p1, 65535) ) "Mode" FROM v$session_wait WHERE event = 'enqueue' ; 来查询当前发生 enqueue 等待事件的 Lock mode ,该值对应着 V$lock 中的 lock type 2. P2 、 P3 代表 Enqueue name 的 ID1 和 ID2 ,分别对应着 V$Lock 中的 ID1 和 ID2 大多数情况下, Enqueue 的等待时间为 3 秒 在 v$Lock 中, request = 0 表示的是 Holder , >0 表示的是 waiter 确定 Enqueue 的性能: 1. 可以查询 v$sysstat 来查看 enqueue 等待 select * from v$sysstata where class = 4 2. 对于 9i ,可以查询: SELECT eq_type "Lock", total_req# "Gets", total_wait# "Waits", cum_wait_time FROM V$enqueue_stat WHERE Total_wait# > 0 ; 3. 对于 8i ,可以查询: SELECT ksqsttyp "Lock", ksqstget "Gets", ksqstwat "Waits" FROM X$KSQST where KSQSTWAT > 0; 根据这两个 sql ,确定整个系统中的 enqueue 的等待情况 几个普遍存在的 Lock mode : TX :事务锁 Note 62354.1 ; 在以下情况下发生: 1) Another session is locking the requested row. 2) When two sessions tries to insert the same unique key into a table (none of them has done a COMMIT), then the last session is waiting for the first one to COMMIT or ROLLBACK. 3) There are no free ITL (Interested Transaction List) in the block header (increase INI_TRANS och PCT_FREE for the segment). TM : DML enqueue , 一般当外键没有建立索引的时候产生, Note 38373.1 , Note 33453.1 ST : space management enqueue ,当系统存在小碎片,或者存在大量的 sort 的时候产生 Note 33567.1 JQ : Job queue UL : user lock ,当用户 DBMS_LOCK.REQUEST 时产生 SQ : sequence enqueue, 检查 sequence 的 cache size 是否过小 SS : sort segment enqueue, 检查 temp 表空间太小,是否有查询需要使用大量的 temporary 空间 HW enqueue 指和段的高水位标记相关等待;手动分配适当区可以避免这一等待 TX 是最常见的 enqueue 等待。 TX enqueue 等待通常是以下三个问题之一产生的结果: 第一个问题是唯一索引中的重复索引,你需要执行提交( commit ) / 回滚( rollback )操作来释放 enqueue 。 第二个问题是对同一位图索引段的多次更新。因为单个位图段可能包含多个行地址( rowid ),所以当多个用户试图更新同一段时,可能一个用户会锁定其他用户请求的记录,这时等待出现。直到获得锁定的用户提交或回滚, enqueue 释放。 第三个问题,也是最可能发生的问题是多个用户同时更新同一个块。如果没有足够的 ITL 槽,就会发生块级锁定。通过增大 initrans 和 / 或 maxtrans 以允许使用多个 ITL 槽(对于频繁并发进行 DML 操作的数据表,在建表之初就应该考虑为相应参数设置合理的数值,避免系统运行以后在线的更改,在 8i 之前, freelists 等参数不能在线更改,设计时的考虑就尤为重要),或者增大表上的 pctfree 值,就可以很容易的避免这种情况。 TM enqueue 队列锁在进行 DML 操作前获得,以阻止对正在操作的数据表进行任何 DDL 操作 ( 在 DML 操作一个数据表时,其结构不能被更改 select * from V$ENQUEUE_STAT; enqueue 类型 : BL, Buffer Cache Management CF, Controlfile Transaction CI, Cross-instance Call Invocation CU, Bind Enqueue DF, Datafile DL, Direct Loader Index Creation DM, Database Mount DR, Distributed Recovery DX, Distributed TX FS, File Set IN, Instance Number IR, Instance Recovery IS, Instance State IV, Library Cache Invalidation JQ, Job Queue KK, Redo Log “Kick” L[A-P], Library Cache Lock MR, Media Recovery N[A-Z], Library Cache Pin PF, Password File PI, Parallel Slaves PR, Process Startup PS, Parallel Slave Synchronization Q[A-Z], Row Cache RT, Redo Thread SC, System Commit Number SM, SMON SQ, Sequence Number Enqueue SR, Synchronized Replication SS, Sort Segment ST, Space Management Transaction SV, Sequence Number Value TA, Transaction Recovery TM, DML Enqueue TS, Temporary Segment (also TableSpace) TT, Temporary Table TX, Transaction UL, User-defined Locks UN, User Name US, Undo Segment, Serialization WL, Being Written Redo Log XA, Instance Attribute Lock XI, Instance Registration Lock
  • Statspack Installation of the Statspack Package Installing the Statspack utility creates the perfstat user, who owns all PL/SQL code and database objects created (including the Statspack tables, the constraints, and the Statspack package). During the installation you will be prompted for the perfstat user’s default and temporary tablespaces. The Statspack package has been available with Oracle Database from Oracle8.1.6. When initially installed roughly 80 MBs of the perfstat user’s default tablespace is used. This may grow later with the tables storing snapshot information. Collecting Statistics To take a snapshot of performance data, log on to SQL*Plus as the perfstat user, and then execute the statspack.snap procedure. This stores the current performance statistics in the Statspack tables, which can be used as a baseline snapshot for comparison with another snapshot taken at a later time. Automatically Collecting Statistics To compare performance from one day, week, or year to the next, there must be multiple snapshots taken over a period of time. The best method to gather snapshots is to automate the collection at regular time intervals. The spauto.sql script makes use of the dbms_job package to provide an automated method for collecting statistics. The supplied script schedules a snapshot every hour, on the hour. This can be changed to suit the requirements of the system. Producing a Report To examine the change in statistics between two time periods, execute the spreport.sql file while being connected to the perfstat user. The user is shown a list of collection periods and selects a start and end period. The difference between the statistics at each end point is then calculated and put into a file named by the user.
  • First Page of the Statspack Report The first page summarizes the report. The items found on this page include most of the information that the DBA requires to enhance performance. Each of these areas will be covered in greater depth during the course. • Cache Sizes The current size of the buffer cache, shared pool, and log buffer are shown here in KB. Also included here is the value of the primary block size. • Load Profile One value given here is per second and the other is per transaction. What is shown includes the redo size and the physical reads and physical writes performed during the snapshot period. • Instance Efficiency Percentages The items listed here are ones that are most often used for tuning a database. These statistics are used to indicate that workloads have changed on the database. • Top Five Wait Events The full list of wait events appears later in the report and will be dealt with later in the course. The top contention items are listed under this heading.
  • The “ head ” image depicts a decision point.

Transcript

  • 1. 数据库性能诊断的七种武器 ITPUB : Ora-600 liyinan
  • 2. 主要议题
    • 性能优化面临的挑战
    • 调优工具的变迁
    • 诊断工具中的七种武器
    • Q & A
  • 3. <Insert Picture Here> 性能优化面临的挑战
  • 4. 性能优化面临的挑战 1 、架构和业务的设计与变更 2 、熟悉各种数据库参数、系统参数 3 、应用逻辑与 SQL 代码实现 4 、选择合适的存储方式 存储盘阵、存储模式、存储参数、存储表空间、存储对象等 5 、复杂的网络配置 还有更多。。。 DBA 的事情好多哦… 为满足业务的运行要求,高性能要求是目前 IT 系统普遍面临的最棘手问题,尤其是客户面对着目前越来越庞大系统和数据,系统整合、数据大集中似乎成了趋势,而对我们来说,则充满了压力和挑战。
  • 5. <Insert Picture Here> 调优工具的变迁
  • 6. Oracle 调优工具的变迁
    • 朦胧之初 (v5)
      • Debug code
    • 初见端倪 (v6)
      • Counters/Ratios
      • BSTAT/ESTAT
      • SQL*Trace
    • 有所发展 (v7)
      • 出现了 Wait Event
      • counters 向 timers 的变迁
  • 7. Oracle 调优工具的变迁
    • 快速进化 (8i)
      • 宽广的范围
      • STATSPACK
    • 逐渐完善 (9i)
      • 更精细的收集 - Session tuning using 10046 SQL traces
      • 更加全面的 STATSPACK
      • 智能化、自动化开始初现
    • 日趋完美 (10g) – 基于数据库自动化基础的更完美的优化
      • 自动化收集
      • 更加广泛的收集
      • 保留一段时间的历史
      • 提供了: ASH, AWR, ADDM, EM 等功能调用
      • 形成了越来越完善的性能优化诊断工具
  • 8. <Insert Picture Here> 诊断工具中的七种武器
  • 9. 诊断工具中的七种武器
    • 碧玉刀 — 动态性能视图:刀是最大众化的武器,小到刮刀、折刀、剃刀、西瓜刀、切菜刀、剔骨刀,大到柳叶刀、圆月弯刀、武士刀、青龙偃月刀。。。不论大小长短、不论古今中外,刀是最常见的武器。不过再普通的刀,到了高手的手中,也会成为神兵利器,刀如此, Oracle 的动态性能视图也如此,无论各种性能问题,根源皆可寻究于此。
    • V$SYSSTAT V$SESSION V$SESSTAT V$SGASTAT
    • V$FILESTAT V$UNDOSTAT V$ROLLSTAT V$WAITSTAT
    • V$LOCK V$LATCH V$SQL V$SQLAREA V$SQLTEXT
    • V$PROCESS V$LIBRARYCACHE V$ROWCACHE ……
  • 10. 动态性能视图
    • 大处着眼,小处着手
    • 不是每个问题,都那么清楚的摆在我们面前,细致的察看,仔细的分析,利器才是利器
    • select name,value from v$sysstat where name like '%SQL%';
      • NAME VALUE
      • ------------------------------------------------------- ----------
      • bytes sent via SQL*Net to client 2.0196E+12
      • bytes received via SQL*Net from client 1.3342E+12
      • SQL*Net roundtrips to/from client 7397997982
      • bytes sent via SQL*Net to dblink 1.5108E+12
      • bytes received via SQL*Net from dblink 1.1800E+11
  • 11. 诊断工具中的七种武器
    • 长生剑 — 等待事件:剑,轻灵、快速、灵敏,甚至于诡异。谈笑间,轻松快意时寻出敌人弱点,以闪电般的速度刺入敌人最虚弱的部位,一击破敌。
    • 性能优化的核心是什么,快速准确的定位,不需要华丽的显示,不需要冗长的信息,需要的仅仅是一个准确的定位,等待事件就是此中利器。
  • 12. 等待事件
    • v$system_event / v$session_event / v$session_wait
    • 竞争即等待
    • 寻找第一眼的感觉
    • 从 v$system_event 中发现系统问题
    • 从 v$session_event 中发现会话问题
    • 从 v$session_wait 的参数中找到竞争对象
  • 13. 等待事件
    • 熟悉各种主要的等待事件 , 快速定位问题所在
    • Top 5 Timed Events                                         Avg %Total ~~~~~~~~~~~~~~~~~~                                        wait   Call Event                                 Waits    Time (s)   (ms)   Time Wait Class ------------------------------ ------------ ----------- ------ ------ ---------- wait for a undo record        35,928       3,451     65   50.1      Other CPU time                                      1,687           24.4 db file scattered read 392,504 821 11.7 User I/O wait for stopper event to be i  4,027        278     69     3.4      Other log file sync 28,880 171 2.1 Commit
    • wait for a undo record 等待与回滚段的大量回滚有关,一般是出现了大事务回退造成
    • select sid, event, wait_class from v$session_wait s where s.event not like ‘%message%’; SID     EVENT                                                            WAIT_CLASS ------------------- ---------------------------------------------------------------- 507    PX Deq: Txn Recovery Start                    Idle 511    PX Deq: Txn Recovery Start                    Idle 268    PX Deq: Txn Recovery Start                    Idle ……
    • select pid, state, undoblocksdone from v$fast_start_servers;        PID STATE       UNDOBLOCKSDONE ---------- ----------- --------------        133 RECOVERING            7124 ……
  • 14. 等待事件
    • buffer busy waits( 数据高速缓存忙等待 )
    • db file scattered read( 数据文件离散读取 )
    • db file sequential read( 数据文件顺序读 )
    • direct path read( 直接路径读取 )
    • direct path write( 直接路径写出 )
    • enqueue( 队列 )
    • free buffer waits( 空闲缓冲区等待 )
    • latch free( 锁存器空闲 )
    • log buffer space( 日志缓冲区空间分配 )
    • log file switch(archiving needed)
    • log file switch(checkpoint incomplete)
    • log file sync( 日志文件同步 )
  • 15. 诊断工具中的七种武器
    • 霸王枪 — statspack :枪中之霸王,胆气之结晶。枪具有剑的轻灵,又有棍的霸道,不论是快速定位,还是全面分析,都是 statspack 所能胜任的。
  • 16. Statspack
    • 有了全面的信息收集,分析问题变得简单了
    • Statspack 的安装
      • $ORACLE_HOME/rdbms/admin/spcreate.sql
    • 收集统计信息
      • $ORACLE_HOME/rdbms/admin/statspack.snap
    • 自动收集统计信息
      • $ORACLE_HOME/rdbms/admin/spauto.sql
    • 生成报表
      • $ORACLE_HOME/rdbms/admin/spreport.sql
    • 要收集计时信息,设置:
      • TIMED_STATISTICS = True
  • 17. Statspack 的输出
      • 包含的信息:
      • 数据库和实例名称
      • 获取快照的时间
      • 当前高速缓存的大小
      • 负载概览
      • 实例效率百分比
      • 前五个等待事件
      • 等待事件的完整列表
      • 共享池中 SQL 语句的信息
      • 实例活动统计
      • 表空间和文件 I/O
      • 缓冲区统计信息
      • 回退段或还原段统计信息
      • 栓锁活动
      • 字典高速缓存统计信息
      • 库高速缓存统计
      • SGA 统计
      • Init.ora 参数的启动值
  • 18. Statspack 内容
  • 19. Statspack 内容
  • 20. Statspack 内容
  • 21. Statspack 内容
  • 22. 诊断工具中的七种武器
    • 孔雀翎 — ash 、 awr 、 addm 、 addr :是一种暗器,但又不是暗器。悄然,自动,不动声色间,一切皆在握。 Oracle 在 10g 开始,推出了一系列自动化、智能化的工具,虽然这些工具在以前或多或少都有相似的影子,但功能的增强、理念的增强,造就了这些以前所不具备的新工具。
  • 23. Active Session History- 活动会话历史
    • 每秒钟自动从内存中抓取样例的活动会话信息
    • 可以从 v$active_session_history 获得会话近期的活动信息
    • select a.sql_text from v$sql a where sql_id in (select sql_id from v$active_session_history where session_id=157);
    • 信息直接从内存结构中获取,并不保存,仅在系统运行中有效
    • 可以得到
      • SID
      • SQL ID
      • Program
      • Wait event#
      • Object, File, Block
      • actual wait time (if captured while waiting)
    • 通过 ashrpt.sql 可以产生 ash 分析报告,发现某个时段的 TOP (Top Events/ Top SQL/ Top Sessions/ Top Objects/Files/Latches)
    • 可以通过活动会话信息追溯到性能问题的根源
    查找数据库的瞬间问题
  • 24. ASH 报告
  • 25. ASH 报告
  • 26. ASH 报告
  • 27. 活动会话信息
    • 什么资源在竞争?
    • 向下追溯到哪个程序带来了竞争?以及哪个 SQL 带来了竞争?
  • 28. 活动会话信息中的 TOP
  • 29. 通过 TOP SQL 进一步发现问题
  • 30.
    • 10g 的数据库中内置了工作负载信息库
    • AWR 是 Oracle10g 数据库自动化管理的基础架构
    • 自动捕获工作负载数据
      • 默认情况下,每隔 60 分钟保存一次,或者手动保存 7 天的数据
    • 存储在新 SYSAUX 表空间内
    • 服务器自动管理空间要求
      • 自动清除旧数据
    • 存储不同类别的数据:
      • 基本统计,例如物理读取
      • SQL 统计,例如磁盘读取(每个 sql 语句)
      • 量度,例如,物理读取数量 / 秒
    • 通过 awrrpt.sql 可以产生与 statspack 类似的性能差异报告
    Automatic Workload Repository- 自动负载信息库 (AWR)
  • 31. AWR 报告
  • 32. AWR 报告
  • 33. Automatic Database Diagnostic Monitor - 自动数据库诊断监控 (ADDM)
    • AWR 收集完信息后自动调用,为数据库提供性能诊断分析报告
    • 分析依赖于 AWR 收集的性能信息快照,对比两次收集快照的性能差异,提供分析建议
    • 由 Oracle 自动调用,也可以手动调用
    • 可以分析当前的,最近一次收集的,也可以分析之前还存在的 AWR 快照
    • 对 RAC 架构同样适用
    • 分析结果在数据库的相应字典表中存储,可以通过 dbms_advisor 包的 get_task_report 过程来获取已经分析的结果,也可以通过 addmrpt.sql 脚本对特定的快照进行分析
    SQL Advisor High-load SQL IO / CPU issues RAC issues Automatic Diagnostic Engine Snapshots in Automatic Workload Repository Self-Diagnostic Engine inside DB System Resource Advice Network + DB config Advice
  • 34. 性能诊断:以前与现在的情况
    • 以前
    • 检查系统利用率
    • 查看等待事件
    • 观察 latch 争用情况
    • 查看共享池和库缓存 latch 的等待情况
    • 检查 v$sysstat
    • 查看 “ parse time elapsed” > “parse time cpu” 以及硬分析数量超过正常的情况
    • 通过以下方法识别 SQL
      • 识别具有很多硬解析的会话并跟踪它们,或者
      • 在 v$sql 中检查具有相同散列计划的多个语句
    • 检查所访问的对象并查看 SQL
    • 通过观察 SQL 包含文字的情况来识别“硬解析”问题
    • 支持游标共享
    • Oracle10 g
    • 1. 查看 ADDM 建议
    • 2. ADDM 建议使用 cursor_sharing
    情况:硬解析问题
  • 35. ADDM 分析报告
  • 36. ADDM 分析报告细节
  • 37. Automatic Database difference Report - AWR 数据对比报告 (ADDR)
    • 对 AWR 报告的一种补充
    • 基于基线的理念,对比比单纯的报告更能够说明问题
    • 比基线更灵活,产生报告时随意选择对比基线
    • 通过 awrddrpt.sql 可以获取性能异常时间与正常时间段 AWR 报告的对比值,能够快速发现性能差异,从而定位问题
  • 38. AWR Compare Period Report
  • 39. AWR Compare Period Report: Configuration
  • 40. AWR Compare Period Report: Load Profile
  • 41. AWR Compare Period Report: Top Timed Events
  • 42. AWR Compare Period Report: Report Details
  • 43. AWR Compare Period Report: Top SQL by Elapsed Time
  • 44. 孔雀翎在手,优化就是这么 easy
    • 性能信息和负载量的捕捉
      • 系统统计信息 , 等待事件 ,SQL 负载等
    • 性能问题分析
      • 与正常阶段比,哪种资源消耗明显?
      • 与正常阶段比,哪些语句出现了明显问题?
      • 哪种操作带来了问题?
      • 什么资源上出现了瓶颈?
      • 瓶颈的原因是什么?
    • 性能调整方案
      • 多个性能问题,哪个影响更大
      • 每个性能问题,应该怎么解决
      • 如果不能解决,考虑进一步调用哪个工具进行分析处理
    ASH AWR ADDR ADDM ADDM
  • 45. 性能调优工具关联图示 Snapshots In-memory statistics AWR SGA 60 mn ADDM results MMON DBA Snapshots Statspack Fore- -ground Automatic ASH ADDM Alerts
  • 46. 诊断工具中的七种武器
    • 多情环 — sql tuning advisor/sql access advisor :多情环似乎是一个情种,谁拥有它似乎都会产生感情,从而对许多江湖中的事看的很淡。在 Oracle 应用中,谁对性能影响最大,不言而喻,是 SQL ,准确地说是 SQL 语句的算法,可以说, 80% 以上的性能问题都可以通过调整 SQL 来解决或者缓解,拥有调优 SQL 性能的能力,基本上可以算作一个 DBA 高手咯。。。
  • 47.
    • 以前
    • 检查系统使用情况
    • 查看等待事件
    • 查看数据库分散读取上的等待事件
    • 通过以下方法识别 SQL (难以操作)
      • 识别具有大量数据库分散读取等待事件的会话并跟踪它们,或者在 OEM 中查看最突出的会话
    • 获得解释计划
    • 检查被访问的对象(大小 / 基数)
    • 查看 SQL 统计信息和 / 或与对象统计信息相比较 (v$sql) (难以操作)
    • 识别问题
    • 联系打包应用程序的供应商
    • 为供应商提供测试方案
    • 供应商提供补丁 / 升级
    • 安装在客户的下一个维护周期中的补丁 / 升级
    • Oracle10 g
    • 查看 ADDM 建议
    • 根据链接来运行自动 SQL 调整
    • 接受来自 SQL 调整的 SQL 描述文件建议
    SQL 调整:以前与现在的情况 情况:打包应用程序中的不良 SQL
  • 48. 执行计划
    • 执行计划是一系列的优化器用来完成 SQL 操作的步骤和操作
  • 49. 曾经我们如何查看执行计划
    • 通过下面的工具能够看到执行计划
      • EXPLAIN PLAN
      • V$SQL_PLAN
      • SQL Trace
      • SQL*Plus AUTOTRACE
    • 看到执行计划不是目的,优化与分析仍然靠 DBA 去努力。。。
  • 50. SQL 调优建议
    • SQL Tuning & Access Advisors
    • 能够对系统中的 SQL 语句提供优化指导
    • 从多个不同的方向为 SQL 提供优化建议
    • 建议包括了:统计信息的重新收集,创建 / 删除索引,创建 / 删除物化视图,是否需要物化视图日志, SQL 语句的书写以及固化执行计划的 SQL Profiling
    • 通过存储在 Oracle 内部的 SQL Profiling 能够在不改变 SQL 代码的基础上强制执行计划
    SQL Profile Packaged Apps + Indexes, MVs, Partitions Well-tuned SQL Customizable Apps + SQL Advice Customizable Apps + High-load SQL Packaged Apps Customizable Apps Automatic Tuning Optimizer Auto SQL Tuning Auto SQL Analysis Access Advisor
  • 51. SQL Tuning Advisor Overview Add Missing Indexes Modify SQL Constructs Create a SQL Profile Automatic Tuning Optimizer SQL Structure Analysis Access Path Analysis SQL Profiling Statistics Analysis Gather Missing or Stale Statistics DBA SQL Tuning Recommendations SQL Tuning Advisor
  • 52. SQL Tuning Usage Scenarios SQL Tuning Advisor ADDM High-load SQL Cursor Cache AWR SQL Tuning Set (STS) User-defined Filter / Rank SQL Sources Manual Selection Automatic Selection AWR
  • 53. SQL Tuning in Oracle Database 10g End-to-End Workflow Workload AWR one hour A good end-to-end solution, but manual intervention is required SQL Tuning Candidates SQL Tuning Advisor ADDM Generate Recommendations DBA Invoke Advisor Implement DBA Evaluate Recommendations DBA
  • 54. Automatic SQL Tuning in Oracle 11g It’s Automatic! Workload Choose Candidate SQL one week SQL Tuning Candidates Test SQL Profiles Implement SQL Profiles Generate Recommendations AWR DBA View Reports / Control Process
  • 55. Automatic SQL Tuning
    • 完全自动的 SQL 优化
    • 自动捕捉高负载的 SQL
    • 自动创建 SQL Profile ,不改变 SQL 代码自动优化 SQL
    • 不能完全取代 DBA ,代码的书写还是需要 DBA 来调整的
    Packaged Apps Custom Apps Automatic SQL Tuning
      • SQL Profiles
    Nightly Well-tuned SQL Automatic implement Manually implement
      • SQL Analysis
    Report Auto Capture High-Load SQL
  • 56. SQL Access Advisor Overview Partitions ( 11g only ) MV and MV Logs Bit-map indexes Automatic Tuning Optimizer Access Path Analysis B*-tree indexes DBA Recommendations SQL Access Advisor 除了像在 Oracle 数据库 10g 中一样可以分析索引、物化视图等, Oracle 数据库 11g 中的 SQL Access Advisor 还可以分析表和查询以提供可能的分区策略 — 这在设计最佳模式时可以提供很大帮助
  • 57. 诊断工具中的七种武器
    • 离别钩 —提示 (hints) , Oracle 很强大的工具,优化 SQL 的利器,能够强制 SQL 的执行算法,确保 SQL 执行按照我们希望的执行计划。钩,用的好伤人,用不好伤己, hints 也如此。非高手者,非思路清晰者,且忌乱用,用不好的话,你会很受伤的。。。
  • 58. 一些典型的 hints
    • 首选用于测试执行计划
    • 其次可用于在需求确定时,固化执行计划
    • 常用的 hints :
      • FIRST_ROWS, ALL_ROWS ,RULE
      • FULL(tab)
      • INDEX( tab index )
      • NO_INDEX ( tab index )
      • USE_NL(tab)
      • USE_MERGE(tab..)
      • USE_HASH(tab1 tab2)
      • PARALLEL ( table, <degree> [, <instances>] )
    • 它很锋利,小心“伤人”
  • 59. 诊断工具中的七种武器
    • 拳头:没有武器就是有武器,有武器就是没有武器。最后一种武器 - 拳头,就是对整个体系的全面理解,无形的武器胜于有形的武器,就像太极,没有招数就是最好的招数。
    • 作为一个 DBA ,或者更高一些,作为一个架构管理员,能够理解整个业务系统,对数据库、存储、网络、系统、应用软件、业务流程都非常清楚,甚至于对使用者的使用习惯都非常清楚,优化就不再是什么高难度了。天地之大皆装于我胸中,万物皆为我之神兵。如果真有那么一天一切都在你的掌握之中,优化也许会比吃饭更容易一些咯
  • 60. 结尾
    • 优化的工具有千千万,找到适合的最关键
    • 精通一、两个工具,比什么工具都“会”使更有用
    • 工具就是工具,最终优化人来定
    • 工具是可以换的,人“才”是换不来的
    • 优化应该在系统中整体贯穿,需要我们用优化工具的时候似乎已经有点晚。。。
  • 61. Q & A
      • 感谢参与