沃趣科技-Oracle 12c数据库优化器统计信息收集的最佳实践(1)-杨禹航

合集下载

Oracle数据库优化方案

Oracle数据库优化方案

Oracle数据库优化方案早上刚坐在办公桌前,一杯咖啡还没来得及品尝,大脑就已经开始飞速运转。

十年的方案写作经验告诉我,Oracle数据库优化方案要从哪儿开始着手。

得理清楚思路,把那些纷繁复杂的想法一股脑儿倒出来。

一、需求分析优化数据库,得明白业务需求。

这就像医生看病,不了解病情,怎能对症下药?咱们得先了解业务流程,找出瓶颈所在。

比如,有些业务操作频繁,但数据查询速度慢,这就需要优化查询语句和索引。

二、硬件检查硬件是数据库的基础,就像房子的地基。

如果地基不牢,房子怎能稳固?咱们得检查一下服务器硬件配置,看看CPU、内存、硬盘等是否满足数据库运行需求。

如果硬件不够强大,升级硬件是第一步。

三、数据库参数调整数据库参数就像一个人的基因,决定着数据库的性能。

有些参数可能默认设置并不适合实际业务需求。

这时候,咱们就得调整参数,让数据库发挥出最佳性能。

1.缓存参数缓存是数据库性能的关键。

合理设置缓存大小,可以让数据在内存中快速读取,减少磁盘I/O操作。

比如,SGA、PGA等缓存参数,要根据业务需求和硬件配置进行调整。

2.线程参数线程是数据库的并行处理能力。

合理设置线程数,可以让数据库在多核CPU上发挥出更高的性能。

但线程数也不是越多越好,过多会导致上下文切换频繁,降低性能。

四、索引优化索引是数据库的加速器。

合理的索引可以让查询速度飞快,但过多或不当的索引反而会降低性能。

咱们得对索引进行优化:1.删除无效索引有时候,一些索引长时间没有使用,或者业务逻辑发生变化,这些索引就成了负担。

删除这些无效索引,可以减少数据库维护成本。

2.重建索引随着数据量的增加,索引会逐渐碎片化,影响查询性能。

定期重建索引,可以让索引保持高效。

五、查询优化查询优化是数据库优化的重头戏。

有时候,一个简单的查询语句,就能让数据库性能翻倍。

1.重写查询语句有些查询语句可能过于复杂,导致执行计划不佳。

我们可以通过重写查询语句,简化逻辑,提高查询效率。

Oracle+12c体系结构简介

Oracle+12c体系结构简介
• 2017年初Oracle率先发布了12c Release 2版 本,包含Exadata、SuperCluster版本,而在 2017年3月1日,Oracle终于发布了它的Linux 64版本和Solaris版本,接下来还有 windows、HPUX、AIX版本会在Q2发布
12c各平台发布的时间线
FAQ时间
DATAGURU专业数据分析网站
数据库参数的对比
数据库版本
10.2.0.5.0
所有参数个数 开放参数个数
1618 259
11.2.0.4.0
12.1.0.2.0
2912
3975
351
380
12.2.0.1.0
4845
417
数据库参数的对比
数据库参数的版本变化
所有参数分布图
Oracle各版本参数数量分布图
开放参数分布图
对于核心业务上云的态度
课程前的一些话
• 亮点特性和取舍
– 容器数据库 – 灾备
• 目的和意义
– 进阶课程
• 基础知识
– Oracle体系结构 – 坚持
• • • •
12c Release 2的简介和背景 从数据库参数变化来解读数据库的变化 12c的使用场景 12c的体系结构
Oracle 12.2发布
Oracle 12c版本的发布
支持, 27%, 28% 观望, 58%, 59% 反对, 13%, 13%
支持 反对
观望
Oracle的企业使命logo变化
12c的使用实践
Oracle传统体系结构图
User process Shared Pool
Instance SGA
Database Buffer Cache

Oracle 12C优化器的巨大变化,上生产必读(上)

Oracle 12C优化器的巨大变化,上生产必读(上)

Oracle 12C优化器的巨大变化,上生产必读(上)序言优化器是Oracle数据库最吸引人的部件之一,因为它对每一个SQL语句的处理都必不可少。

优化器为每个SQL语句确定最有效的执行计划,这是基于给定的查询的结构,可用的关于底层对象的统计信息,以及所有与优化器和执行相关的特性。

随着每个新版本的发布,优化器都会进化,利用新功能以及新的统计信息来生成更好的执行计划。

随着对查询优化的新的自适应方法的引入,Oracle 12c数据库把这种进化更推上了一个台阶。

这份白皮书介绍了在Oracle 12c数据库中与优化器和统计相关的所有新特性并且提供了简单的,可再现的例子,使得你能够更容易地熟悉它们。

它还概括了已有的功能是如何被增强以改善性能和易管理性。

优化器和统计信息新特性1、自适应查询优化到目前为止,Oracle 12c数据库中最大的变化是自适应查询优化。

自适应查询优化是这样的一组功能,它使得优化器能够对执行计划进行实时调整,并且发现能够导致更佳的统计信息的额外信息。

当现有的统计信息不足以产生一个优化的计划,这种新方法是极其有用的。

自适应查询优化包括两个方面:自适应计划,它着重于改善一个查询的初次执行;自适应统计信息,它为后续的执行提供了额外的信息。

(图1. 自适应查询优化功能的组件)2、自适应计划自适应计划使得优化器能够延迟产生一个语句的最终计划,直到执行的时候才决定。

优化器在它所选择的计划(缺省计划)中植入统计收集器,从而在运行的时候,它能够判断自己的基数估算与计划的操作所实际看到的行数是否有很大的偏差。

如果有显著的区别,那么这个计划或者计划的一部分在SQL语句的首次执行就能够被自动调整来避免不理想的性能。

3、自适应的连接方式通过为计划中的某些分支预先确定多个子计划,优化器能够实时调整连接方式。

例如,在图2中优化器的初始计划(缺省计划)为order_items 和 product_info 之间的连接选定的是嵌套循环连接,通过对product_info表的索引读取。

oracle统计信息收集工作原理

oracle统计信息收集工作原理

oracle统计信息收集工作原理Oracle数据库的统计信息收集是优化查询性能的重要工具。

通过收集表和索引的统计信息,数据库优化器可以更好地选择执行计划,从而提高查询性能。

在这篇文章中,我们将探讨Oracle统计信息收集的工作原理。

1. 统计信息包括哪些内容。

在Oracle数据库中,统计信息包括表的行数、块数、平均行长度、列的数据分布和密度等信息,以及索引的高度、选择性等信息。

这些统计信息可以帮助优化器评估不同执行计划的成本,并选择最佳的执行计划。

2. 统计信息的收集方式。

Oracle数据库可以通过多种方式收集统计信息,包括使用DBMS_STATS包中的存储过程、使用ANALYZE命令、自动统计信息收集任务等。

其中,自动统计信息收集任务是Oracle数据库自带的一种自动收集统计信息的机制,可以根据数据库中的数据变化情况自动触发统计信息的收集。

3. 统计信息的使用。

一旦收集了统计信息,数据库优化器就可以使用这些信息来生成最佳的执行计划。

例如,当优化器需要选择一个索引来执行查询时,它会使用索引的统计信息来评估不同索引的成本,并选择最佳的执行计划。

4. 统计信息的更新策略。

由于数据库中的数据会不断变化,统计信息也需要定期更新以反映最新的数据分布情况。

Oracle数据库提供了自动统计信息收集任务来定期收集和更新统计信息,同时也可以手动触发统计信息的收集和更新。

总的来说,Oracle数据库的统计信息收集是优化查询性能的重要工具,通过收集表和索引的统计信息,数据库优化器可以更好地选择执行计划,从而提高查询性能。

同时,合理的统计信息收集策略也是保证数据库性能稳定的重要手段之一。

Oracle数据库性能优化分析

Oracle数据库性能优化分析

千里之行,始于足下。

Oracle数据库性能优化分析Oracle数据库性能优化分析是指对Oracle数据库进行综合性能分析和优化的过程。

通过分析数据库的运行状况、识别潜在的性能瓶颈、确定解决方案并实施优化措施,可以提高数据库的性能和效率。

以下是Oracle数据库性能优化分析的一般步骤:1. 收集性能数据:通过Oracle的性能监控工具,如AWR报告、统计信息收集等,收集数据库的性能数据,包括CPU利用率、I/O响应时间、锁定情况等。

2. 确定性能瓶颈:通过分析性能数据,确定数据库中存在的性能瓶颈,如高CPU使用率、高IO等待、长时间的锁等待等。

3. 优化SQL语句:分析执行频次较高的SQL语句,通过重写SQL语句、调整索引和统计信息等方式,优化SQL语句的执行计划,减少IO开销和CPU消耗。

4. 优化数据库结构:根据应用的需求和查询模式,调整表结构、分区策略、索引设计等,以提高查询性能和数据访问效率。

5. 优化数据库配置参数:调整数据库的配置参数,包括缓冲区大小、日志大小、并发连接数等,以最大限度地利用硬件资源,提高数据库的吞吐量和响应时间。

6. 确保数据完整性和一致性:通过使用合适的约束和触发器,确保数据的完整性和一致性,防止数据错误和冲突对性能造成负面影响。

第1页/共2页锲而不舍,金石可镂。

7. 监控和调优:定期监控数据库的性能指标,如响应时间、吞吐量等,及时识别和解决潜在的性能问题,保持数据库的高可用性和性能稳定性。

需要注意的是,性能优化是一个综合性的工作,需要结合具体的应用场景和需求来进行分析和优化,没有一种通用的解决方案,需要根据实际情况进行定制化的优化措施。

同时,性能优化是一个持续改进的过程,需要定期评估数据库的性能状况,并根据需求进行调整和优化。

oracle database 12c 介绍和概要

oracle database 12c 介绍和概要

oracle database 12c 介绍和概要Oracle Database 12c 是一款由 Oracle 公司开发的数据库管理系统,它是目前最流行的关系型数据库之一。

在 Oracle Database 12c 中,引入了许多新特性和改进,使得数据库的可用性、可扩展性和性能得到了进一步提升。

Oracle Database 12c 引入了多租户架构,允许多个数据库实例共享同一套 Oracle 数据库软件,从而降低了成本和资源消耗。

同时,它还支持各种不同的计算环境,包括 x86、x64 和 zSeries 等。

Oracle Database 12c 提供了丰富的功能和工具来支持数据管理、事务处理和数据分析等任务。

其中,最受欢迎的功能之一是闪回(Flashback),它允许管理员在误操作或数据损坏后快速恢复到以前的数据库状态。

此外,Oracle Database 12c 还提供了许多其他的内置工具,例如自动存储管理(ASM)、自动数据优化(AOP)和数据安全等。

Oracle Database 12c 的主要组件包括数据库实例、数据文件、控制文件、日志文件和表空间等。

数据库实例是由多个进程和内存结构组成的,它负责访问和控制数据库。

数据文件用于存储数据库的数据,控制文件包含了数据库元数据和磁盘文件的信息,日志文件记录了对数据的所有更改信息。

表空间则是由一个或多个数据文件组成的逻辑容器,用于存储用户的数据。

总之,Oracle Database 12c 是一款功能强大、易于使用和管理的关系型数据库,适用于各种不同的应用场景。

它提供了许多先进的功能和工具,可以帮助企业降低成本、提高性能和可靠性,是数据库管理员的理想选择。

oracle 12c 容灾之Active Data Guard 测试报告

oracle 12c 容灾之Active Data Guard 测试报告
场景描述
节点oratest3 为此次dataguard 搭建测试的主机环境,在测试前先安装数据 库软件,然后dbca 创建一个容器数据库为test,并且包含两个pdb 为pdb1 和 pdb2 并配置监听正常后,对新的容器数据库test 进行本机容灾dataguard 的搭 建和配置测试,并为后续的测试准备好测试环境同时验证dataguard 测试环境 是否正常等。
场景一:测试环境 dataguard 搭建测试 .................................... 3 场景描述 .................................................................................. 3 测试过程 .................................................................................. 3 结论 ....................................................................................... 10
ALTER DATABASE CREATE STANDBY CONTROLFILE AS 'control_files=/oracle/db_base/oradata/test/control01.ctl'
7 为备库创建参数文件:
CREATE SPFILE FROM PFILE='/oracle/db_base/product/12.1.0/dbhome_1/dbs/inittestdg.ora' 修改如下:
12c 容灾之 Active Data Guard 测试报告

深入解析和定制Oracle优化工具

深入解析和定制Oracle优化工具
先定制快照,定制awr就会顺水推舟 小步快走,立等可取 快照还有哪些改进之处
重要的监控项:DB time
定制快照的数据基础
DBA_HIST_SYS_TIME_MODEL
V$SYS_TIME_MODEL
DBA_HIST_SNAPSHOT
得到DB time的快照列表
BEGIN_SNAP END_SNAP SNAPDATE
awrinput.sql awrinpnm.sql
awrrpti.sql
?
select output from table(dbms_workload_repository.&fn_name( :dbid,:inst_num ,:bid, :eid,:rpt_options ));
AWR工作原理
定制AWR的思路
深入解析和定制Oracle优化工具
杨建荣
个人介绍- 杨建荣 Oracle ACE YEP成员 DBA+联合发起人 Oracle 10g OCP,OCM ,MySQL OCP 对shell , Java有一定的功底 《Oracle DBA 工作笔记》作者 曾在中国数据库大会,Oracle嘉年华,全球敏捷运维峰会 (Gdevops)演讲
性能优化结果
更多的定制和方向 精细化运维 自动化运维 数据分析和优化结合 有时候需要半自动化,基于安全
个人微信公众号,欢迎关注
T需求:查看上周某一天早上8:00~9:00之间的一个性能问题 1.查看上周某一个早上8:00~9:00的快照 2. 掐指一算上周那一天到今天的天数 3.然后上下翻屏找快照号 4.找到开始快照号,再找结束快照号 5.定义一个报告的名字
AWR内置的脚本调用关系
awrrpt.sql

数据库管理技术的优化实践案例

数据库管理技术的优化实践案例

数据库管理技术的优化实践案例随着信息技术的不断发展和进步,企业和组织对于数据的管理和存储需求日益增长。

而数据库管理技术就成为了有效管理和维护数据的核心工具之一。

数据库管理技术的优化实践是确保数据库系统高效运行和最大利用资源的关键。

本文将以实际案例为例,探讨数据库管理技术的优化实践以及带来的益处。

案例一:索引优化某电商公司的数据库出现了查询速度慢的问题。

为了解决这个问题,他们进行了索引优化的实践。

首先,他们对数据库中经常查询的字段创建了索引。

通过使用索引,查询性能得到显著提升。

此外,他们还对索引进行定期维护,包括删除重复索引和优化索引结构等。

通过这些措施,数据库的查询时间从原来的几秒减少到几毫秒。

这个实践案例的好处是明显的。

首先,查询速度的提升能够提高系统性能和用户体验。

其次,减少了服务器的负载,降低了硬件成本和维护成本。

最后,优化索引能够减少存储空间的占用,提高数据库的效率。

案例二:定期备份与恢复一个金融机构的数据库在运营过程中因为系统故障导致数据丢失。

为了防止类似情况再次发生,他们进行了定期备份与恢复的优化实践。

首先,他们制定了一份完整的备份计划,并设定了备份频率和备份点。

每天定期进行全量备份,并在每周进行一次差异备份。

其次,他们测试了备份和恢复的流程,确保备份的可行性和可恢复性。

通过这个实践案例,金融机构获得了多项好处。

首先,避免了数据丢失造成的巨大损失,保证了业务的可靠性。

其次,备份和恢复过程的优化使得备份时间和恢复时间大大缩短,缩小了计划中断的时间窗口。

最后,备份的数据可以用于数据分析和业务决策,提高了企业的竞争力。

案例三:性能监控与调优一家电信公司的数据库在高负载下出现了性能瓶颈。

为了解决这个问题,他们进行了性能监控与调优的优化实践。

首先,他们使用了性能监控工具来收集数据库的性能指标,包括CPU利用率、内存使用率、磁盘I/O等。

通过这些指标,他们可以及时发现性能瓶颈并进行相应的调优工作。

实践实战:在PoC中的Oracle 12c优化器参数推荐(含PPT)

实践实战:在PoC中的Oracle 12c优化器参数推荐(含PPT)

实践实战:在PoC中的Oracle 12c优化器参数推荐(含PPT)最近,Oracle数据库优化器的产品经理 Nigel Bayliss 发布了一篇文档,介绍:Setting up the Oracle Optimizer for PoCs - 在PoC测试中优化器参数的设置和调节。

优化器是Oracle 数据库的核心组件,我们一起来看一看12c 有哪些优化器的变化。

关注本公众号回复关键字:Internals 即可获得本文PPT(SettingUp..),同时附送了一系列的精彩PPT学习资源。

首先,作者描述了POC 测试的基本原则,遵循KISS 原则(Keep it Simple Stupid),从一个尽可能简单的基线开始;优先考虑稳定性和一致性;通过测试掌控变化;持续向前:首先,在Oracle 12cR1中,Oracle 引入了一个重要的新特性:自适应查询优化器- Adaptive Query Optimization,该特性的主要功能有两个:对SQL的执行计划进行运行时(run-time)调整,(也就是在SQL执行过程中,具备动态改变执行计划的能力);∙∙在SQL执行过程中,动态统计和发现新的统计信息,以实现更佳的执行计划;∙通过这个特性的描述,我们可以知道,当现有统计数据不足以生成最佳计划时,自适应查询优化器会很有用;当然相反方向是,如果我们数据库中执行计划是稳定的、优化的、满足需要的,那么这个新的特性对我们就基本不需要。

下图展示了这个新特性的两个路径:自适应执行计划、自适应统计信息。

在12.1版本中,是否启用自适应优化器参数由初始化参数optimizer_adaptive_features决定。

基于在执行过程中获得的真实统计信息,优化器动态调整执行计划的能力可以极大地提高查询性能。

下图展示了一个最常见的场景,基于静态统计信息,Oracle选择了Nest Loop的执行计划,当执行中动态统计信息(自适应统计信息)被收集之后,SQL的执行计划自动变更为Hash Join 的执行方式。

oracle12c创建实例

oracle12c创建实例

oracle12c创建实例【原创实用版】目录1.Oracle 12c 简介2.创建 Oracle 12c 实例的步骤3.创建实例过程中的注意事项4.完成创建后的操作正文一、Oracle 12c 简介Oracle 12c 是 Oracle 公司的一款关系型数据库管理系统,以其高效、稳定、安全著称,广泛应用于各行各业。

本文将介绍如何在 Oracle 12c 中创建实例。

二、创建 Oracle 12c 实例的步骤1.安装 Oracle 12c 数据库软件首先,需要在计算机上安装 Oracle 12c 数据库软件。

这一步骤相对简单,只需按照安装向导的提示进行即可。

2.创建数据库实例安装完成后,需要使用 Oracle 12c 的命令行工具创建数据库实例。

具体操作如下:```$ export ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome_1 $ export ORACLE_SID=orcl$ export NLS_DATE_FORMAT="yyyy-mm-dd hh24:mi:ss"$ sqlplus / as sysdba$ create database instance orcl```以上命令将创建一个名为“orcl”的数据库实例。

请注意,这里的命令可能需要根据您的实际情况进行修改。

3.设置数据库选项创建实例后,可以根据需要设置数据库选项。

例如,可以设置字符集、存储选项等。

设置完成后,需要使用“commit”命令提交更改。

4.创建数据库设置完数据库选项后,可以使用以下命令创建数据库:```$ createdb orcl```三、创建实例过程中的注意事项在创建 Oracle 12c 实例过程中,需要注意以下几点:1.确保计算机上已安装 Oracle 12c 数据库软件,并配置好环境变量。

2.在创建数据库实例时,需要使用 sysdba 身份登录。

Oracle12c性能优化攻略:攻略1-1:创建具有最优性能的数据库

Oracle12c性能优化攻略:攻略1-1:创建具有最优性能的数据库

Oracle12c 性能优化攻略:攻略1-1:创建具有最优性能的数据库⼀:章节前⾔本章着眼于影响表中数据存储性能的数据库特性本章着眼于影响表中数据存储性能的数据库特性。

表的性能部分取决于在创建之前所应⽤的数据库特性。

例如:在最初创建数据库时采⽤的物理存储特性以及相关的表空间都会在后来影响表的性能。

类似地,表性能还受到最开始选择的物理特性的影响。

例如:表类型和数据类型。

因此应⽤实践中使⽤的数据库、表空间、和表的创建标准(并将性能问题放在⼼上),就形成了优化数据可能性和可扩展性的基础。

组成Oacle 数据库的物理结构⽤来存储、管理、保护以及读取数据。

在创建数据库的时候,可以选择应⽤⼀些与性能相关的特性。

例如⽂件的初始布局以及表空间的管理类型,都是在创建数据库时制定。

这时所实现的架构上的决策,通常都会产⽣很长远的影响。

提⽰: oralce 实例的定义是其内存结构及其后台进程。

⽽Oracle 数据库则由物理⽂件(即:数据⽂件、控制⽂件、在线重做⽇志⽂件)组成。

如图1-1所描述的那样,表空间是⽀持管理⼀组数据⽂件的逻辑结构。

数据⽂件就是磁盘的物理⽂件。

配置表空间时,要注意⼀些对性能会产⽣深远影响的特性,也就是本地管理表空间以及⾃动段存储管理的表空间。

如果合理地设计这些特性,将来也就能最⼤限度得可接受到表性能 图1-1 逻辑存储于物理存储之间的关系图表是数据库中存储数据的对象。

数据库性能衡量的是应⽤能够以什么样的速度插⼊、更新、删除、和查询数据。

因此,此书就从优化表性能的攻略讲起。

本章⾸先介绍创建数据库和表空间时,可能会影响表性能的各⽅⾯因素,然后,讨论另外⼀些主题,⽐如根据于性能相关的业务需求,选择表类型和数据类型。

稍后介绍的主题包括管理表空间使⽤情况的物理实现⽅式。

本章还会详细介绍其他问题。

例如探测表碎⽚、处理位于⾼⽔位线下⽅的空闲空间、⾏链接以及数据压缩。

除此之外还会描述Oracle 段顾问(Oracle Segment Advisor ).这个⼯具很好⽤,能够帮助你⾃动探测并解决碎⽚和未使⽤的空间问题。

Oracle12c性能优化攻略:攻略目录表

Oracle12c性能优化攻略:攻略目录表

Oracle12c性能优化攻略:攻略⽬录表⼆:选择和优化索引1:理解B树索引2:选择需要建⽴索引的列3:创建主键约束和索引4:确保唯⼀列值5:为外键列创建索引7:决定何时使⽤组合索引8:实现基于函数的索引9:在虚拟列上创建索引10:在多个进程并⾏插⼊时限制索引争夺11:触发索引对优化器的可见性12:创建⽀持星型架构额位图索引13:创建位图连接索引14:创建索引组织表15:监控索引使⽤16:索引创建速度最⼤化17:回收未使⽤的索引空间三:优化实例内存1:⾃动内存管理2:关联多个缓冲池3:设定内存最⼩值4:监控内存调整操作5:优化内存使⽤6:调优PGA内存分配7:配置服务器查询缓存8:管理服务器结果缓存9:缓存SQL查询结果10:缓存客户端结果集11:缓存PL/SQL函数结果12:配置Oracle数据库智能闪存缓存13:调节重做⽇志缓冲区14:限制PGA内存分配四:监控系统性能1:实现AWR2:修改统计信息时间间隔和保存期限3:⼿⼯⽣成AWR报表4:通过企业管理器⽣成⼀份AWR报告5:为⼀条SQL⽣成AWR基线6:为数据库创建统计基线7:通过企业管理器关联AWR基线8:管理AWR统计信息库9:⾃动创建AWR基线10:快速分析AWR输出11:⼿⼯获取活动会话信息12:从企业管理器中获取ASH信息13:从数据字典中获取ASH信息五:最⼩化系统资源争夺1:理解响应时间2:确定引起最多等待的SQL语句3:分析等待事件4:理解等待事件的分类5:检查会话等待6:按类型检查等待事件7:解决缓冲区忙等待8:解决⽇志⽂件同步等待9:被另⼀个会话读取等待事件的最⼩化10:减少直接路径读取等待事件11:恢复写⼊器等待最⼩化12:找出谁持有阻塞锁13:确定被阻塞和引起阻塞的会话14:处理引起的阻塞的锁15:确定被锁定的对象16:解决enq:TM锁资源争夺17:确定最近被锁住的会话18:分析数据库中最近的等待事件19:确定由于锁定所花费等待时间20:锁存器争夺的最⼩化六:分析操作系统性能1:检测磁盘空间问题2:确定系统瓶颈3:确定消耗服务器资源最多的进程4:检测CPU瓶颈5:确定CPU和内存瓶颈6:确定I/O瓶颈7:检测⽹络密集型进程8:将⼀个资源密集型进程映射到⼀个数据库进程9:终⽌⼀个资源密集型进程七:检修数据库1:确定最优的撤销保留时间2:找出是什么消耗最多的撤销空间3:解决ORA_01555错误4:监控临时表空间使⽤率5:确定是谁在使⽤临时表空间6:解决”⽆法扩展临时数据段”错误7:解决打开游标错误8:解决被挂起的数据库问题9:激活⾃动诊断库命令解释器10:从ADRCI中查看报警⽇志11:使⽤ADRCI查看事件12:将事件打包发给Oracle技术指出团队13:运⾏⼀次数据库健康检查14:创建SQL测试⽤例15:⽣成⼀份AWR报告16:⽐较两阶段的数据库性能17:分析⼀份AWR报告⼋:创建⾼效的SQL1:获取⼀张表中的所有数据⾏2:获取⼀张表中的部分数据⾏3:通过想到对应的⾏来连接表4:在没有相对应数据⾏的情况下连接表5:构造简单的⼦查询6:构建相关⼦查询7:⽐较2个表找出缺失的数据⾏8:关联2个表找出匹配的数据⾏9:将相似SELECT 语句结果集合并10:查找⼀定范围内的值11:处理空值12:搜索部分列值13:重⽤共享池中的SQL语句14:避免偶然的全表扫描15:创建⾼效的临时表16:避免使⽤NOT ⼦句17:控制事务⼤⼩九:SQL⼿⼯调优1:显⽰查询的执⾏计划2:定制执⾏计划输出3:图形化显⽰执⾏计划4:解读⼀份执⾏计划5:监控运⾏时较长的SQL语句6:确定当前正在执⾏的好占资源的SQL语句7:查看当前正在运⾏的SQL语句的统计信息8:监控⼀个SQL执⾏计划的处理过程9:确定过去执⾏的SQL语句中最耗占资源的语句10:⽐较系统修改后的SQL 性能⼗:追踪SQL执⾏1:环境准备2:在追踪⼀个特定的SQL语句3:在你所拥有的会话中启⽤追踪4:找到追踪⽂件5:检查原始SQL追踪⽂件6:分析Oracle追踪⽂件7:使⽤TKPROF 设置追踪⽂件的格式8:使⽤TKPROF输出9:使⽤Oracle追踪分析器分析追踪⽂件10:追踪⼀个并⾏查询11:追踪特定的并⾏查询进程12:在RAC系统中追踪并⾏查询13:合并多个追踪⽂件14:找出正确的回话来进⾏追踪15:追踪⼀个SQL会话16:通过进程ID来追踪会话17:追踪多个会话18:追踪⼀个实例或数据库19:为会话⽣成事件10046追踪20:为实例⽣成10046追踪21:在⼀个正在运⾏的会话上设置追踪22:登录之后启⽤会话追踪23:追踪优化的执⾏路径24:⽣成Oracle错误⾃动追踪25:追踪后台进程26:启⽤Oracle 监听器追踪27:为数据卫⼠设置归档追踪⼗⼀:SQL⾃动调优1. 显⽰⾃动SQL调优⼯作详细信息2.显⽰sql⾃动调优建议3.⽣成SQL脚本实现⾃动调优建议4.修改SQL⾃动调优特性5.禁⽤和启⽤SQL⾃动调优6.修改维护窗⼝7.创建SQL调优集对象8.查看AWR中资源秘籍集型SQL语句9.⽤AWR中⾼资源消耗的SQL来填充优化集10.查看内存中资源密集型SQL语句11.⽤内存中⾼资源消耗SQL来填充调优集12.将内存中所有的SQL来填充调优集13.显⽰SQL调优集的内容14.有选择地从SQL调优集中删除语句15.传输SQL调优集16.创建调优任务17.⼿⼯运⾏SQL调优顾问18.从数据库⾃动诊断监视器中获取SQL调优建议⼗⼆:执⾏计划优化与⼀致性1:创建并接受SQL概要⽂件2:确认某个查询是否使⽤了SQL概要⽂件3:⾃动接受SQL概要⽂件4:显⽰SQL概要⽂件5:选择性测试SQL概要⽂件6:将SQL概要⽂件迁移到另外⼀个数据库中7:禁⽤SQL概要⽂件8:删除SQL概要⽂件9:为内存中的⼀条SQL语句创建计划基线10:为包含SQL调优集中的SQL语句创建计划基线11:⾃动增加计划基线12:修改计划基线13:确认是否存在计划基线14:确认某个查询是否使⽤了计划基线15:显⽰计划基线执⾏计划16:⼿⼯在计划基线中加⼊⼀个新的计划(扩展) 17:阻⽌⾃动接受新的低成本执⾏计划18:禁⽤计划基线19:移除计划基线信息20:迁移计划基线⼗三:优化配置1:选择器优化⽬标2:启⽤统计信息⾃动收集3:为统计信息收集设置⾸选参数4:⼿⼯⽣成统计信息5:锁定统计信息6:处理统计信息的缺失7:导出统计信息8:还原以前版本的统计信息9:收集系统统计信息10:验证新的统计信息11:强制优化使⽤某个索引12:启⽤查询优化器特性13:阻⽌数据库创建柱形图14:不使⽤绑定定量提⾼性能15:理解⾃适应游标共享16:在表达式上创建统计信息17:为相关列创建统计信息18:⾃动创建列组19:维护分区表统计信息20:为⼤表并⾏收集统计信息21:确定统计信息何时过期22:预览统计信息收集对象⼗四:实现查询提⽰1:编写⼀个提⽰2:改变访问路径3:改变连接顺序4:改变连接⽅法5:改变优化器版本6:在快速响应和整体优化之间进⾏选择7:进⾏直接路径插⼊8:在视图中加⼊提⽰9:缓存查询结果10:将分布式查询引导到⼀个特定的数据库⼗五:并⾏执⾏SQL1:为特定查询启⽤并⾏2:在创建对象时启⽤并⾏3:为已经存在的对象启⽤并⾏4:实现并⾏DML5:并⾏创建表6:并⾏创建索引7:并⾏重建索引8:并⾏移动分区9:并⾏拆分分区10:启⽤⾃动解释计划11:检查并⾏解释计划12:监控并⾏操作13:找出并⾏进程中的瓶颈14:获取并⾏回话中详细信息。

oracle12c oratop详解

oracle12c oratop详解

oracle12c oratop详解Oracle是一个大型的关系型数据库管理系统。

它具有高性能、安全、可靠等特点,并且被广泛应用于企业级应用程序和数据仓库等领域。

Oracle 12c是Oracle公司推出的最新一代数据库管理系统,它引入了许多新的功能和改进,提高了数据库的性能和可用性。

Oratop是一个用于监视和调优Oracle数据库的命令行实用程序。

它提供了许多工具和功能,帮助数据库管理员和开发人员监控和优化数据库的性能。

下面将详细介绍Oracle 12c和Oratop的一些重要功能和用途。

Oracle 12c的特点和改进:1.多租户架构:Oracle 12c引入了多租户架构,可以将一个物理数据库划分为多个逻辑数据库,每个逻辑数据库都可以独立管理和配置。

这种架构可以提高数据库的资源利用率,降低成本。

2.数据库内存虚拟化:Oracle 12c可以将数据库缓存的数据虚拟化到内存中,以加快数据访问的速度。

这种虚拟化技术可以提高数据库的性能,降低I/O开销。

3.多线程查询:Oracle 12c引入了并行查询功能,可以同时执行多个查询操作。

这种功能可以提高数据库的查询性能,加快数据检索的速度。

4.数据压缩:Oracle 12c提供了数据压缩功能,可以将数据库中的数据进行压缩存储,以减少存储空间的占用。

这种功能可以提高数据库的存储效率,降低存储成本。

5.自动化管理:Oracle 12c提供了自动化管理功能,可以自动进行数据库运维和监控。

这种功能可以减少管理员的工作量,提高数据库的可靠性和安全性。

Oratop的功能和用途:1.实时监控:Oratop可以实时监控数据库的各种系统指标,如CPU利用率、内存使用情况、I/O等。

这些指标可以帮助管理员及时发现和解决数据库性能问题。

2.会话跟踪:Oratop可以跟踪和监控数据库的会话,包括当前活动的会话、等待事件和SQL语句等。

这些信息可以帮助管理员分析数据库的性能瓶颈,优化SQL查询。

Oracle优化器介绍

Oracle优化器介绍

Oracle优化器介绍Oracle优化器(Optimizer)是Oracle数据库中的一个重要组件,它负责解析SQL语句,并选择最优的执行计划来执行查询。

优化器的目标是通过选择最佳的执行计划来获得最佳的性能,从而提高查询效率。

优化器的职责主要包括以下几个方面:1. 查询重写(Query Rewrite):通过对SQL语句进行语法分析和语义分析,优化器可以对查询进行重写,以便更好地利用索引和表的分区来提高查询性能。

2. 统计信息收集(Statistics Collection):优化器需要收集并维护关于数据库对象(如表、索引、列等)的统计信息,包括数据分布、数据存储方式等。

这些统计信息对于判断执行计划的代价非常重要。

3. 成本估计(Cost Estimation):通过统计信息,优化器可以估计每个可能的执行计划的代价,并选择代价最小的执行计划作为最优执行计划。

成本估计的目标是选择最少的I/O操作和计算资源,从而提高查询性能。

4. 选择最佳执行计划(Plan Selection):优化器使用一个叫作“查询优化器”的子模块来选择最佳的执行计划。

查询优化器会根据统计信息和成本估计,生成一个可能的执行计划列表,并对每个执行计划进行代价估算。

然后,查询优化器会选择代价最小的执行计划作为最优执行计划。

Oracle优化器的核心是基于成本的优化器(Cost-Based Optimizer,CBO)。

CBO利用收集的统计信息和成本估计来选择最佳的执行计划,从而提高查询性能。

成本估计主要包括CPU成本和I/O成本两个方面。

CPU成本是指完成一次查询所需的CPU资源,包括CPU运算和内存消耗。

CBO会根据操作的类型(如索引扫描、全表扫描等)和数据规模(如单个块的行数、表的总行数等)来估计CPU成本。

I/O成本是指完成一次查询所需的磁盘I/O操作数量。

CBO会根据表的大小、索引的选择性和查询条件的选择性等统计信息,来估计查询所需的I/O成本。

oracle12c benchmark results -回复

oracle12c benchmark results -回复

oracle12c benchmark results -回复题目:Oracle 12c基准测试结果与分析:提升数据库性能的关键引言:随着大数据和云计算时代的到来,数据库系统的性能和可扩展性变得越来越重要。

针对这一需求,Oracle 12c作为业内领先的关系数据库管理系统之一,通过进行基准测试来评估其性能和可靠性。

本文将详细分析一份Oracle 12c基准测试结果,并探讨关键因素对于提升数据库性能的作用。

一、基准测试简介1. 基准测试的定义:基准测试是通过模拟真实环境下的工作负载和数据量,在数据库系统中进行一系列测试和测量,以便评估其性能和可靠性指标。

2. 基准测试的意义:基准测试可以帮助数据库管理员(DBA)了解数据库系统的瓶颈以及优化需求,并为决策者提供参考,以支持系统升级和性能优化的决策。

二、Oracle 12c基准测试结果分析1. 性能指标分析:- 响应时间:基准测试中最常用的性能指标之一,表示数据库系统响应用户操作的速度。

- 吞吐量:表示数据库系统在单位时间内处理的事务或查询的数量,也是衡量性能的重要指标。

- 并发性能:指数据库系统在同时处理多个并发用户操作时的性能表现。

2. 测试用例和工作负载分析:- 测试用例:基准测试中通常会涵盖常见的数据库操作,如插入、查询、更新和删除等,以模拟真实环境下的工作场景。

- 工作负载:基准测试中采用的工作负载可以是事务型的(以完成某个业务功能为目标)或者是查询型的(以执行某个复杂查询为目标)。

3. 关键因素分析:- 硬件配置:硬件资源的优化对数据库系统的性能至关重要,如CPU、内存、硬盘及网络等。

合理配置硬件资源可以显著提升数据库系统的性能。

- 数据库参数调优:Oracle 12c提供了许多参数用于调优数据库系统的性能和稳定性,包括缓冲区大小、日志写入策略等。

合理设置这些参数可以最大程度地提升数据库性能。

- 索引和分区:索引和分区技术可以加速数据库的查询操作,降低数据检索的成本。

Oracle Business Activity Monitoring 12c 最佳实践说明书

Oracle Business Activity Monitoring 12c 最佳实践说明书

Oracle Business Activity Monitoring 12c Best PracticesO R A C L E W H I T E P A P E R|J A N U A R Y2016DisclaimerThe following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.Table of ContentsIntroduction 2 Schema Design 2 Dashboard Design and Deployment 3 Query Design 3 Data Archiving and Purging 4 Scalability and Performance 4 Real Time Data Sources for Oracle BAM 5 Production Roll Out Check List 5 Configuration 5 Load Test 11IntroductionThis whitepaper details some recommended best practices for Oracle Business Activity Monitoring’s 12c release. This will ensure Oracle BAM’s optimal usage while curbing common errors.Schema Design1.Oracle BAM 12c supports a star schema. It supports joins through Logical DataObjects (LDOs). An LDO allows you to join one FACT table with multiple DIM tables, which allows you to run queries on top of the LDO. If Active Data is used on top of an LDO with Archived Relation, the following considerations need to be taken into account to achieve the best performance:2.Mark your DIM table as ‘Slow Changing Dim’ if the changes to the DIM table arevery infrequent (once in a day or so). When you mark it with ‘slow-changing dim’, a join-memory enhancement comes into play that reduces the amount of heap required and also increases the query start up time.3.Keep DIM table size reasonable (e.g. less than 10k – only used for lookup) andbatch updates to DIM tables to avoid frequent updates so you can mark the DIM table as ‘Slow Changing Dim’. In the case where the dim table is growing at the same pace as the fact table, it is better to keep the dimension columns in the FACT table.4.Only join the FACT table with required DIMs as multiple DIMS requires complex njoins. Consolidate DIM tables to reduce number of joins.5.Design LDO with filters to reduce the amount of data returned. This reduces theTEMP tablespace required to run the archiver query.e Calculated Fields in your query to reduce the number of columns required inthe FACT DO. Keep only what’s absolutely required as columns in the FACT table.This will help Active and CQL template queries to be more efficient as they do not need to bring additional columns into memory.7.If you are using 11g Oracle DB, use Secure Files to improve performanceing Secure Files/technetwork/database/availability/oraclefmw-soa-11gr1-securefiles-1842740.pdf8.Create indexes for key fields. You can use BAM DO tool to create index. Seesome references herea.Oracle Database Performance Tuning Guide/technetwork/database/availability/oraclefmw-soa-11gr1-securefiles-1842740.pdfb.Oracle 9i Application Developer’s Guide – Fundamentals, Chapter 5 –Releasing an Index Strategyhttps:///cd/B10500_01/appdev.920/a96590/adg06idx.htmc.Expert Indexing in Oracle Database 11g: Maximum Performance for yourDatabase/gp/product/143023735X/ref=s9_simh_se _p14_d0_i1?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=search-desktop-advertising-no-results-center-1&pf_rd_r=0DY561RCQWH9ETC18ECB&pf_rd_t=301&pf_rd_p=1912 906182&pf_rd_i=oraclec 12c performance indexDashboard Design and Deployment1.Ensure that a dashboard is designed for a specific user group. Do not try tocreate an all-purpose dashboard.2.Create report which is “management by exception”.3.Allow the user to understand the health of the operations at a glance; thenprovide drill-down.e the LDO filter and dashboard parameters to filter data before dashboardis loaded.5.Limit a dashboard to 4-6 views or one view with multiple tabs.6.Make effective use of Action Buttons to take actions.e summary/aggregation as much as possible and provide drill down todetail records from there to avoid a large number of detail records.8.List views can have a performance. Listing hundred/thousands of records in alist view will impact performance.e OTN demos for design and best practices.10.Choose active data interval and throttle carefully as it has memoryimplications.Query Design1.For tactical (non-active), queries, examine the query string generated by thebusiness query and run the DB AWR report to tune the index or change your query to improve performance.2.For an active query, always specify a window size (range) because these willreduce amount of memory required. Also, use output window (sliding) judiciously to collapse results and so as to not overwhelm the dashboards.e the aggregation query and bind it to a chart. Then perform drill down todetail records. This organizes the data into smaller chunks and improves performance.4.Test your query with your production data set to ensure that the performance isreasonable.5.Familiarize yourself between the differences between scheduled query and real-time active query and use them as appropriate.Data Archiving and Purging1.Keep only the necessary data in your Data Object. Any data that is relevant foroperational monitoring and taking actions is a candidate for data object storage.2.Do not keep older data for historical purposes in the same data object.3.If you need the historical data to be available, transfer the data to another dataobject that is used for specific reporting.4.Schedule the Data Retention at non-peak hours using alerts. You need to shutdown all BAM Viewsets and Continuous Queries (using Admin Mode) during this task as they hold state in memory.5.If it is a requirement to archive the data prior to purging, then use ODI with BAM12c.e Alert to control filter based purging. Custom actions can also be provided tothe Alert to perform more customized purging.e Database ‘Partition’ capability to improve performance if purging and datainjections are happening concurrently.Scalability and Performance1.Oracle BAM 12c is designed for High Availability and Scalability. It is ACTIVE-ACTIVE. Scalability can be achieved via adding additional servers. Under the covers, BAM 12c uses ASM for fail over (for Unit of Order JMS with Automatic Migratable Target). More information can be found on the EDG Guide.2.For input scalability, multiple EMS can be started on different servers to improvethroughput.3.Note: Customers should consider using ‘batch’ to improve performance.4.CQL queries are load balanced using project as a base. All queries for a givenproject would reside on the same server. When a server crashes, CQL queries will be moved onto a different server.5.Number of CQL queries will be a factor for amount of heap required on themachine.6.It is recommended that dedicated machines be used for Oracle BAM (separateBAM from DB machines, and others based on install size). If the solution includes BPEL/BPM, use separate machines for BPEL and its storage to avoid contention.7.For HA solutions, make sure your servers are on the same subnet.8.Ensure that the application context is the same for Oracle BAM Web Services if theWS interface is used for pushing data into BAM.9.Tune DB accordingly – including adding indexes, partition table by day, parallelexecution and use DBIM (Database In-Memory). DBIM will accelerate access to the data because only the required columns (columnar storage) will be visited.In addition, for cases where filtering occurs but the filter is not very selective, DBIM is a little like having an index per column. For the queries that perform simple aggregations, DBIM can also accelerate aggregation.Real-Time Data Sources for Oracle BAM1.Oracle BAM Adapter2.Web Services3.JMS4.ODI5.EJBProduction Roll-Out Check ListConfiguration1.Lock down production topologya.Configuration Checkb.Check JMS and ASM configuration by following EDGFigure 1Figure 2Figure 3Figure 42.Load balancer configurationFigure 53.EMS / Persistence configuration (# of threads). Too many threads my causecontention. Too few may reduce throughput. We recommend start with 20 and tune it based on the throughput.a.Security check - Enterprise Group / Application Roles are defined correctly.Figure 6b.Server JVM parameters. This is required to monitor number of GC (see seconddoc). Here are two different settings. Use them as a reference.•-Xms:12g -Xmx:12g -Xns:6g -Xss:512k -Xverbose:gc -XverboseTimeStamp -XverboseLog:/testcase/bam/logs/gc.log -Xgc:throughput -XX:+UseLargePagesForHeap•Small payload with high injection rate (1000+ events per second) -Xms4g -Xmx4g -XX:+UseParallelGC -XX:+UseParallelOldGC -X:+ParallelRefProcEnabled -XX:PermSize=1g -XX:MaxPermSize=1g -XX:NewSize=1g -XX:+UseLargePages -XX:+UnlockCommercialFeatures -XX:+FlightRecorder4.Lock down dashboardsa.Ensure it can display properly with production load (long numbers).b.Ensure it can display properly on different devices.Load Teste LM to simulate users coming on board. For example:a.Start 20 virtual users: 2 every 30 secondsb.Duration: 20 minutesc.Stop all vusers: 2 every 5 secondsd.Monitor via BAM Admin “view set monitoring”e EMS clients to pump data into system.a.Start multiple EMS Servers. Ensure EMS Server is deployed to differentmanaged servers.3.Monitor throughput. Use BAM Business Query by creating a time series on the x-axis based on Data Object creation date column4.Monitoring Heap, Memory and CPU Usage. Use VisualVM.5.Analyzing AWR Reports. SQL execution time (with DB contain production data) tosee if additional index are required. Check for any locking, dead lock or etc.6.Longevity Testing. Run System for 5 days with EMS: Continuous load, purgingevery day, users come and go.7.HA Fail Over: Bring down one server, monitor performance, bring back serverback up. Manually, migrate services back to server upon restart.Oracle Corporation, World Headquarters Worldwide Inquiries500 Oracle Parkway Phone: +1.650.506.7000Redwood Shores, CA 94065, USA Fax: +1.650.506.7200Copyright © 2014, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability orfitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations areformed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by anymeans, electronic or mechanical, for any purpose, without our prior written permission.Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license andare trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo aretrademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 1215C O N N E C T W I T H U S/oracle/oracle/oracle。

直播预告丨Oracle12C~19C统计信息的最佳实践

直播预告丨Oracle12C~19C统计信息的最佳实践

直播预告丨Oracle12C~19C统计信息的最佳实践
优化器是Oracle数据库最大的黑盒子,决定着所有SQL语句在数据库中的执行计划,影响SQL语句运行的效率。

统计信息做为优化器的指路人,为优化器选择最佳执行计划不断输送信息。

Oracle不断在为统计信息叠加新功能,但在实际生产环境中,常常遇到统计信息的盲点区域,导致SQL运行效率低下,影响业务的感知。

下面就为大家介绍在19C中Oracle数据库在分区表统计信息引入的新功能。

分享大纲
1.统计信息介绍
2.11G中按月分区表统计信息处理
3.19C实时统计信息
4.19C统计信息最佳实践
面向人群
Oracle数据库优化人员、Oracle数据库开发人员、Oracle数据库运维人员。

友情提示
•直播免费报名参与,视频回放及PPT将会收录在《2020云和恩墨大讲堂》(/course/49)中,订阅专栏即可观看。

•请大家尽量观看直播,后期收看视频回放可能收费。

Oracle数据库性能优化实践应用分析r——以某城市商业银行财务系统为例

Oracle数据库性能优化实践应用分析r——以某城市商业银行财务系统为例

Oracle数据库性能优化实践应用分析r——以某城市商业银
行财务系统为例
童奕媛;杨林
【期刊名称】《金融科技时代》
【年(卷),期】2017(000)001
【摘要】Oracle数据库是最常用的数据库之一,其运行性能对应用系统有重要影响,本文介绍了Oracle数据库性能优化的目标是增加吞吐量、缩短响应时间,并总结了实现目标的3种方法——调整内存分配、调整磁盘I/O、优化SQL语句.最后,结合某城市商业银行财务系统数据库日常管理与实践经验,对Oracle数据库优化进行分析与探讨.
【总页数】5页(P31-35)
【作者】童奕媛;杨林
【作者单位】中国人民银行赣州市中心支行;赣州银行
【正文语种】中文
【相关文献】
1.铁道部运营财务收入系统Oracle数据库性能的调整 [J], 徐青
2.信息化视角下水电站基建工程财务竣工决算系统的构建——基于Oracle EBS财务系统与Oracle BI系统 [J], 刘磊
3.Oracle数据库性能优化实践应用分析——以某城市商业银行财务系统为例 [J], 童奕媛;杨林;
4.Oracle数据库性能优化及监控系统的设计实现 [J], 武文斌
5.信息系统Oracle数据库性能优化研究 [J], 王文阁
因版权原因,仅展示原文概要,查看原文内容请购买。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

Oracle 12c数据库优化器统计信息收集的最佳实践(1)介绍oracle优化器会为SQL语句产生所有可能的访问路径(执行计划),然后从中选择一条COST值最低的执行路径,这个cost值是指oracle估算执行SQL所消耗的资源。

为了让优化器能够精确计算的每一条执行计划的COST值,这就需要被执行SQL语句所需访问的所有对象(表和索引等)和系统有必要的描述信息。

这些必要的信息通常被称为optimizer statistics(优化器统计信息)。

理解和管理优化器统计信息是优化SQL执行的关键。

知道何时、如何以及快速的方式收集优化器统计信息对于维持系统良好性能是至关重要的。

本文将详细讨论,在Oracle常见的场景中何时以及如何收集统计信息,文章大致分如下几个部分:•如何收集统计信息•何时收集统计信息•提高统计信息质量•快速收集统计信息•何时不用收集统计信息•收集其他类型统计信息如何收集统计信息在Oracle中优选的方式是统计信息自动收集。

如果系统已经有完善的手动收集统计信息程序,那么可以优选手动统计信息收集。

无论选择哪种收集方式,首先需要考虑的是默认的全局参数设置是否满足您的需求。

在大多数情况下这些默认参数是能够满足的,但是如果我们想根据自己的系统的实际情况作出修改,那么我们可以通过设置SET_GLOBAL_PREFS.参数值。

一旦我们选择这样做,我们可以通过使用DBMS_STATS“set preference”工具覆盖默认设置。

例如,使用SET_TABLE_PREFS参数设置表统计信息收集时使用incremental 方式或者收集直方图信息。

使用这种方式,我们将会指定哪些指定统计信息被默认收集,而不需要在收集统计信息的时候调整参数。

我们可以自由的使用默认参数收集表/用户/数据库级别的统计信息,并且确定这些统计信息收集策略已经被使用。

更重要的是,我们可以在自动和手动统计信息收集之间自由切换。

自动统计信息收集oracle数据库需要收集那些缺少或者已经“stale”过期统计信息的对象统计信息。

这是在预定义的维护窗口中执行的自动任务完成的。

对于 oracle内部优先级高的对象,这些对象的统计信息需要最先被收集更新。

自动统计信息收集job会使用DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC过程,该过程使用和DBMS_STATS.GATHER_*_STATS 过程相同的默认参数设置。

这些默认设置在大多数场景是足够的。

然而,某些场景下需要更改其中一个或者多个默认参数值,我们可以使用DBMS_STATS.GATHER_*_STATS 过程完成设置。

参数值应该在尽可能小的范围内进行更改,最好是以每个对象为基础。

例如,如果我们想修改指定表的统计信息过期阈值,我们希望阈值由原来的10%更改为5%,我们可以使用DBMS_STATS.SET_TABLE_PREFS过程改变指定表的STALE_PERCENT属性。

·exec dbms_stats.set_table_prefs(user,'SALES','STALE_PERCENT','5')在修改完成后我们可以使用DBMS_STATS.GET_PREFS查看属性值修改情况。

需要三个选项,参数名、用户名、表名:select dbms_stats.get_prefs('STALE_PERCENT',user,'SALES') stale_percent from dual; STALE_PERCENT-------------5Setting DBMS_STATS Preferences如上所述,我们可能需要通过DBMS_STAT过程设置指定对象和表在自动统计信息收集时候的收集策略。

我们可以通过DBMS_STATS.GATHER_*_STATS 过程自定义收集策略,但是oracle还是推荐的方法是使用 DBMS_STATS.SET_*_PREFS过程进行设置。

参数可以在表级别、对象级别、数据库或者全局级别被修改(AUTOSTATS_TARGET和CONCURRENT只能在全局级别被更改):SET_TABLE_PREFSSET_SCHEMA_PREFSSET_DATABASE_PREFSSET_GLOBAL_PREFS通常情况下,我们最常修改的参数是ESTIMATE_PERCENT(控制采样百分比)和METHOD_OPT (控制直方图信息的创建),但是估算的百分比现在已经比默认的值更好,由于本节后面所述的原因而保留其缺省值对于表的统计信息收集时,允许DBMS_STATS.GATHER_*_STATS过程修改SET_TABLE_PREFS 过程指定的参数的默认值。

在使用DBMS_STATS.GATHER_*_STATS过程收集指定对象所有已存在的表的统计信息时,我们可以使用SET_SCHEMA_PREFS过程修改默认的参数配置。

这个过程实际上调用SET_TABLE_PREFS过程来为指定对象的所有表设置默认参数。

所以当我们使用该过程设置完成后,用户新创建的表收集统计信息使用的参数是依据GLOBAL配置指定的参数。

同样,SET_DATABASE_PREFS过程可以修改使用DBMS_STATS.GATHER_*_STATS过程收集用户定义对象统计信息时候的默认参数。

事实上这个过程调用的也是SET_TABLE_PREFS过程来为指定对象的所有表设置默认参数。

对于默认参数修改完后创建的对象,他会选择GLOBAL过程指定的默认参数配置。

如果设置ADD_SYS参数为TRUE,那么Oracle自己的用户(SYS,SYSTEM等)也可以被包括进去。

SET_GLOBAL_PREFS过程可以指定所有没有设置表优先级对象的统计信息收集过程的默认参数,在使用SET_GLOBAL_PREFS过程修改完默认参数后,所有的新建对象都会使用修改完后的默认收集参数,除非使用GATHER_*_STATS过程明确指定了参数或者设置了表的优先级。

使用DBMS_STATS.GATHER_*_STATS收集统计信息的时候,以上过程参数设置是分优先级别。

oracle 12CR2引入了新的影响优先级的参数REFERENCE_OVERRIDES_PARAMETER.当这个参数被设置成TRUE,那么优先级的顺序就会发生变化。

如下图所示。

ESTIMATE_PERCENT在收集统计信息过程中,可以使用ESTIMATE_PERCENT参数控制统计数据行的百分比。

当表中的所有行都被统计(即100%采样),我们将会得到最准确的统计信息。

Oracle数据库在11g引入了一个新的采样算法, hash-based算法来实现行信息统计,使用10%的采样频率采集到的信息精确度接近100%采样频率。

在使用dbms_stats gather_ * _stats过程指定estimate_percent设置auto_sample_size(默认)时新的算法就会被启动。

在Oracle数据库11g之前,数据库管理员往往设置estimate_precent参数为很低的值确保统计信息能被快速收集。

oracle强烈建议在从11g开始保持默认参数auto_sample_size。

这一点尤为重要,因为12C开始引入了新的直方图类型,混合和Top-Frequency,这些直方图只能在参数保持默认的auto_sample_size才能被收集。

现在很多的系统还保留着旧的统计信息收集脚本(手动设置百分比)。

所以当数据库升级到12CR2后,可以考虑使用preference_overrides_parameter参数覆盖手动统计信息收集使用的默认参数。

或者直接修改统计信息收集脚本。

METHOD_OPTMETHOD_OPT参数控制柱状图是否在收集过程中被创建。

柱状图是oracle数据库中一类特殊类型的列统计数据,用户提供表中列数据分布的详细信息。

默认情况下METHOD_OPT参数是'FOR ALL COLUMNS SIZE AUTO',这种情况下当表中的列被用在等值或者范围where条件中比如WHERE col1= 'X'或者WHERE col1 BETWEEN 'A' and 'B',并且这列数据是倾斜的。

那么oracle就会对这些列进行收集直方图信息。

优化器知道那些列用户查询谓词因为这些信息会被存储在数据字典表SYS.COL_USAGE$中。

一些DBA更倾向于自己控制直方图的创建。

Oracle推荐使用的方式是通过set_table_prefs进行设置。

例如,你可以人为指定只为SALES表的其中两列COL1和COL2创建直方图。

begindbms_stats.set_table_prefs(user,'SALES','method_opt','for all columns size 1 for columns size 254 col1 col2');end;/也可以指定列必须有直方图(COL1和COL2),此外,允许优化器决定是否在其他列上创建额外的直方图:begindbms_stats.set_table_prefs(user,'SALES','method_opt','for all columns size auto for columns size 254 col1 col2');end;/如果将METHOD_OPT属性设置成'FOR ALL COLUMNS SIZE 1'.那么直方图将会被禁止创建。

例如,可以修改DBMS_STATS全局属性中的METHOD_OPT使直方图信息不被创建。

begindbms_stats.set_global_prefs('method_opt','for all columns size 1');end;/我们也可以删除某些列上不需要的直方图信息。

使用如下方式,DBMS_STATS.DELETE_COLUMN_STATS然后指定col_stat_type为‘HISTOGRAM’。

手工统计信息收集如果已经有一个完善的统计信息收集过程或者因为某些原因想要对特定用户方案禁用自动统计信息收集而只保留收集数据字典的统计信息.可以使用dbms_stats.set_global_prefs 过程来改变autostats_target参数为oracle来替代auto.exec dbms_stats.set_global_prefs('autostats_target','oracle');手动收集统计信息过程中应该使用dbms_stats包,用它来替找过时的analyze命令.dbms_stats包提供多个dbms_stats.gather_*_stats过程来收集用户方案对象,数据字典和固定对象的统计信息.理想情况下,除了模式名称和对象名之外,应该让这些过程的所有参数都默认为默认值。

相关文档
最新文档