Oracle数据库性能优化(碎片整理)
1系统问题
XX公司BI系统上线运行以来，客户反映系统目前存在着下面的几个问题，涉及到数据库和ETL.
问题一：表空间增长太快，每个月需增加3—5G空间。
问题二：ETL JOB会经常导致数据库产生表空间不足错误。
2系统优化分析
2.1分析思路
要解决表空间的问题，我们必须搞清楚下面几个问题：
思路一：真正每个月数据仓库增量是多少空间？
目的：得出一个正确的月表空间增长量。
思路二：目前的数据仓库表空间是是如何分布的。
目的：找出那些对象是最占空间，分析其合理性。
2.2分析过程
要得到真实的数据分布必须对表进行分析，首先需要对数据仓库的oracle数据库进行表分析，。执行下面脚本可以对数据库进行表分析。
脚本一
analyze table SA_IMS_PRODUCT_GROUP compute statistics;
analyze table SA_CONSUMP_ACT_DEL compute statistics;
analyze table SA_FINANCE_ACT compute statistics;
analyze table SA_CONSUMP_TGT_DEL compute statistics; analyze table SA_FACT_IS compute statistics; analyze table SA_CPA compute statistics; analyze table SA_REF_TERR_ALIGNMENT_DEL compute statistics; analyze table SA_IMS_MTHLC_BK compute statistics; analyze table SA_IMS_CHPA compute statistics; analyze table SA_FINANCE_PNL compute statistics; analyze table SA_CUST_TARG_SEG compute statistics; analyze table SA_CONSUMP_ACT compute statistics; analyze table SA_FINANCE_BS compute statistics; analyze table SA_FINANCE_BGT_QTY compute statistics; analyze table SA_CONSUMP_ACT0423 compute statistics; analyze table SA_CALLS compute statistics; analyze table SA_COMPANY_DAILY_SALES_ALL compute statistics; analyze table SA_IMS_MTHLC compute statistics; analyze table SA_IMS_MTHUS compute statistics; analyze table SA_CONSUMP_TGT compute statistics; analyze table TEST_TABLE compute statistics; analyze table SA_DOCTOR_CYCLE_EXTRACT compute statistics; analyze table SA_EXCHANGE_ACT compute statistics; analyze table SA_IMS_MTHST compute statistics; analyze table SA_FINANCE_CONCUR_DETAIL compute statistics; analyze table WK_SA_CPA compute statistics; analyze table SA_REF_TERR_ALIGNMENT compute statistics; analyze table SA_CONSUMP_TGT0316 compute statistics; analyze table SA_CUSTOMER compute statistics; analyze table SA_CUST compute statistics; analyze table SA_HKAPI compute statistics; analyze table SA_CONSUMP_TGT_AMT compute statistics; analyze table SA_CUST0423 compute statistics; analyze table SA_COMMUNITY_TGT compute statistics; analyze table SA_CM_WORKING_DATE compute statistics; analyze table SA_CM_IN_MARKET_SALES_CU compute statistics; analyze table SA_DASH_SFE compute statistics; analyze table SA_CPA_TERR compute statistics; analyze table IDX_SA_CUST compute statistics; analyze table SA_REF_EMP_TERR compute statistics; analyze table SA_CM_IN_MARKET_SALES_OCM compute statistics; analyze table SA_COMPANY_MONTHLY_SALES compute statistics; analyze table SA_MAP_YEARMONTH_RATE compute statistics; analyze table SA_FINANCE_ACT_BPCS_TEST compute statistics; analyze table SA_REF_EMP_TERR0413 compute statistics; analyze table SA_FINANCE_ACT_BPCS compute statistics; analyze table IDX$$_143D0001 compute statistics;
analyze table SA_COMPANY_DAILY_SALES_ALL_23 compute statistics; analyze table SA_COMMUNITY_TGT_AMT compute statistics; analyze table SA_DASH_MONTHLY_MAT_SALES compute statistics; analyze table SA_DASH_ATTRITION compute statistics; analyze table SA_DASH_MARKET_SHARE compute statistics; analyze table SA_CORP compute statistics; analyze table SA_COMMUNITY_ACT compute statistics; analyze table SA_CM_IN_MARKET_SALES_CU_DEL compute statistics; analyze table WK_SA_COMPETITOR_PRODUCT compute statistics; analyze table SA_IMS_ANTI_HYPER_TEST compute statistics; analyze table SA_TERRITORY compute statistics; analyze table TEST_CUSTOMER_TGT compute statistics; analyze table SA_COMPETITOR_PRODUCT compute statistics; analyze table SA_CM_IN_MARKET_SALES_OCM_DEL compute statistics; analyze table SA_COMPANY_DAILY_SALES compute statistics; analyze table SA_REF_MR_CORP compute statistics; analyze table SA_IS_MATERIAL compute statistics; analyze table SA_IS_KEY_MESSAGE compute statistics; analyze table SA_DRIVER_REASON compute statistics; analyze table SA_REF_MR_CUST compute statistics; analyze table SA_BARRIER_REASON compute statistics; analyze table SA_ACCOUNT compute statistics; analyze table SA_REF_MR_PROD compute statistics; analyze table SA_REF_VENDOR_EMP compute statistics; analyze table SA_FINANCE_ACT_ADJUSTMENT compute statistics; analyze table SA_RANKING_MESSAGE compute statistics; analyze table SA_TC compute statistics; analyze table SA_CUST_PARENT compute statistics; analyze table SA_EXCHANGE_RATE_ACT_MTH compute statistics; analyze table SA_EXCHANGE_RATE compute statistics; analyze table SA_DASH_GROWTH_BUBBLE compute statistics; analyze table SA_COST_CENTER compute statistics; analyze table PM_KEY compute statistics; analyze table SA_CM_REF_TERR_OCM compute statistics; analyze table SA_CM_REF_TERR_CU compute statistics; analyze table SA_BPCS_TO_ISMI compute statistics; analyze table PRODUCT compute statistics; analyze table SA_SHIFT_LEVEL compute statistics; analyze table SA_SFE_VARIABLES compute statistics; analyze table SA_PRODUCT compute statistics; analyze table SA_PATIENT_TYPE_EN compute statistics; analyze table SA_MR_KEY_PRODUCT compute statistics; analyze table SA_MAP_TEAM_BRAND compute statistics; analyze table SA_MAP_CUSTOMER compute statistics;
analyze table SA_MAP_AGGR compute statistics;
analyze table SA_LOCATION compute statistics;
analyze table SA_INCREMENTAL_SHIFT compute statistics;
analyze table SA_IMS_CITY compute statistics;
analyze table SA_TGT_FREQ compute statistics;
analyze table SA_TGT_CALLS compute statistics;
analyze table SA_FINANCE_ANP compute statistics;
analyze table SA_COMPANY_DAILY_SALES_23 compute statistics;
analyze table SA_GEOGRAPHY compute statistics;
analyze table SA_MAP_PONUMBER_BPCSTERRCODE compute statistics;
analyze table PK_SA_MAP_PONUMBER_BPCSTERRCOD compute statistics;
analyze table SA_MAP_SAP_BPCS_CUST compute statistics;
analyze table PK_SA_MAP_SAP_BPCS_CUST compute statistics;
analyze table SA_MAP_SAP_BPCS_SKU compute statistics;
analyze table PK_SA_MAP_SAP_BPCS_SKU compute statistics;
analyze table SA_REF_DAY compute statistics;
analyze table STAGEPLAN compute statistics;
analyze table SA_SPLIT_HOSPTIAL compute statistics;
analyze table SA_USAGE_LEVEL compute statistics;
analyze table TEST_CUSTOMER compute statistics;
analyze table SA_NEW_USAGE_LEVEL compute statistics;
analyze table SA_PROD_GROUP_NEW compute statistics;
通过表分析，我们可以得到数据仓库中每个表的记录行数，BLOCK数，EMPTY BLOCKS 数等等关键的数据分布数据，分析后，这些数据会存放在系统表，USER_TABLES和USER_SEGMENTS中。通过对这些系统查询，我们可以得到整个数据库的数据分布情况，从而为分析问题原因提供充足基础。
执行下面的脚本，可以得到一个数据库的数据分布报告：
脚本二
SELECT SEGMENT_NAME TABLE_NAME, SEGMENT_TYPE,
GREATEST(ROUND(100 * (NVL(HWM - AVG_USED_BLOCKS,0)/GREATEST(NVL(HWM,1),1) ), 2), 0) WASTE_PER,
ROUND(BYTES/1024, 2) TABLE_KB, NUM_ROWS,
BLOCKS, EMPTY_BLOCKS, HWM HIGHWATER_MARK, AVG_USED_BLOCKS,
CHAIN_PER, EXTENTS, MAX_EXTENTS, ALLO_EXTENT_PER,
DECODE(GREATEST(MAX_FREE_SPACE - NEXT_EXTENT, 0), 0,'N','Y') CAN_EXTEND_SPACE,
NEXT_EXTENT, MAX_FREE_SPACE,
O_TABLESPACE_NAME TABLESPACE_NAME
FROM
(SELECT A.SEGMENT_NAME, A.SEGMENT_TYPE, A.BYTES,
B.NUM_ROWS, A.BLOCKS BLOCKS, B.EMPTY_BLOCKS EMPTY_BLOCKS,
A.BLOCKS -
B.EMPTY_BLOCKS - 1 HWM,
DECODE( ROUND((B.AVG_ROW_LEN * NUM_ROWS * (1 + (PCT_FREE/100)))/C.BLOCK_SIZE, 0), 0, 1,
ROUND((B.AVG_ROW_LEN * NUM_ROWS * (1 + (PCT_FREE/100)))/C.BLOCK_SIZE, 0)
) + 2 AVG_USED_BLOCKS,
ROUND(100 * (NVL(B.CHAIN_CNT, 0)/GREATEST(NVL(B.NUM_ROWS, 1), 1)), 2) CHAIN_PER, ROUND(100 * (A.EXTENTS/A.MAX_EXTENTS), 2) ALLO_EXTENT_PER,A.EXTENTS EXTENTS,
A.MAX_EXTENTS MAX_EXTENTS,
B.NEXT_EXTENT NEXT_EXTENT, B.TABLESPACE_NAME O_TABLESPACE_NAME
FROM USER_SEGMENTS A,
USER_TABLES B,
user_tablespaces C
WHERE
SEGMENT_NAME = TABLE_NAME and
SEGMENT_TYPE = 'TABLE' AND
B.TABLESPACE_NAME =
C.TABLESPACE_NAME
UNION ALL
SELECT SEGMENT_NAME || '.' || B.PARTITION_NAME, SEGMENT_TYPE, BYTES,
B.NUM_ROWS, A.BLOCKS BLOCKS, B.EMPTY_BLOCKS EMPTY_BLOCKS,
A.BLOCKS -
B.EMPTY_BLOCKS - 1 HWM,
DECODE( ROUND((B.AVG_ROW_LEN * B.NUM_ROWS * (1 + (B.PCT_FREE/100)))/C.BLOCK_SIZE, 0),
0, 1,
ROUND((B.AVG_ROW_LEN * B.NUM_ROWS * (1 + (B.PCT_FREE/100)))/C.BLOCK_SIZE, 0)
) + 2 AVG_USED_BLOCKS,
ROUND(100 * (NVL(B.CHAIN_CNT,0)/GREATEST(NVL(B.NUM_ROWS, 1), 1)), 2) CHAIN_PER, ROUND(100 * (A.EXTENTS/A.MAX_EXTENTS), 2) ALLO_EXTENT_PER, A.EXTENTS EXTENTS,
A.MAX_EXTENTS MAX_EXTENTS,
B.NEXT_EXTENT,
B.TABLESPACE_NAME O_TABLESPACE_NAME
FROM USER_SEGMENTS A,
USER_TAB_PARTITIONS B,
USER_TABLESPACES C,
USER_TABLES D
WHERE
SEGMENT_NAME = B.TABLE_NAME and
SEGMENT_TYPE = 'TABLE PARTITION' AND
B.TABLESPACE_NAME =
C.TABLESPACE_NAME AND
D.TABLE_NAME = B.TABLE_NAME AND
A.PARTITION_NAME =
B.PARTITION_NAME),
(SELECT TABLESPACE_NAME F_TABLESPACE_NAME,MAX(BYTES)
MAX_FREE_SPACE
FROM USER_FREE_SPACE
GROUP BY TABLESPACE_NAME)
WHERE F_TABLESPACE_NAME = O_TABLESPACE_NAME AND
GREATEST(ROUND(100 * (NVL(HWM - AVG_USED_BLOCKS, 0)/GREATEST(NVL(HWM, 1), 1) ), 2),
0) > 2
AND BLOCKS > 1
ORDER BY 4 DESC, 3 DESC, 2 ASC;
运行脚本二后，我们以生产环境的STAGE SCHEMA为例。得到报告如下：
报告的各列含义如下：
WASTE_PER：空间浪费比率，实际用到的数据块/分配给该表的数据块。
TABLE_KB：表占空间大小，以KB为单位。
NUM_ROWS:表中记录行数。
BLOCKS：分配给该表的数据块数。
EMPTY_BLOCKS：已分配给该表但尚未使用的数据块。
HIGHWATER_MARK：表的高水位标志。
AVG_USED_BLOCKS：实际有数据的数据块数。
CHAIN_PER：发生数据行迁移的记录数。
各列有如下关系：
BLOCKS = EMPTY_BLOCKS+ HIGHWATER_MARK+1
WASTE_PER= (HIGHWATER_MARK - AVG_USED_BLOCKS)/ HIGHWATER_MARK 用下面的一个图可以直观了解他们之间的关系：
图中红色块表示在HIGHWATER_MARK下已分配但未被使用的块，形成空洞。
（该报告以表大小倒序排序）
2.3分析结论
从报告中，目前STAGE表空间存在以下几个问题：
一：数据库表空间浪费比率很高，整个STAGE数据库表空间总的浪费比率为：73.33% 二：很多表记录不多，但占得空间巨大。比如占空间很大的几个表
三：以DEL结尾的几个表，占的空间很大，跟用户访谈得知，这几个表是备份表，不做删除清理，不合理。
2.4原因分析
从上面的分析可以知道，目前数据库最主要的问题也是表空间浪费很高，造成空间浪费很多。那么造成浪费的原因是什么呢？
一般来说，造成浪费的原因有如下几个方面：
一：频繁的DEL操作，造成表空间大量的空块，具体表现为表的HWM很高，那么ORACLE在统计剩余空间时，是以HWM水位线上面的空间来计算的。也就是说HWM下面的空间不能被重新分配，尽管可能已经没有数据。那么表空间经常会爆满。
O racle表段中的高水位线HWM
在Oracle数据的存储中，可以把存储空间想象为一个水库，数据想象为水库中的水。水库中的水的位置有一条线叫做水位线，在Oracle中，这条线被称为高水位线（High-warter mark, HWM）。在数据库表刚建立的时候，由于没有任何数据，所以这个时候水位线是空的，也就是说HWM为最低值。当插入了数据以后，高水位线就会上涨，但是这里也有一个特性，就是如果你采用delete语句删除数据的话，数据虽然被删除了，但是高水位线却没有降低，还是你刚才删除数据以前那么高的水位。也就是说，这条高水位线在日常的增删操作中只会上涨，不会下跌。
二：数据库发生行迁移。
行迁移
当修改不是行的行时，当修改后的行长度大于修改前的行长度，并且该数据块中的空闲空间已经比较小而不能完全容纳该行的数据时，就会发生行迁移。在这种情况下，Oracle 会将整行的数据迁移到一个新的数据块上，而将该行原先的空间只放一个指针，指向该行的新的位置，并且该行原先空间的剩余空间不再被数据库使用，这些剩余的空间我们将其称之为空洞，这就是产生表碎片的主要原因，表碎片基本上也是不可避免的，但是我们可以将其降到一个我们可以接受的程度。
从我们上面的分析来看，XX公司数据库发生行迁移的记录很少（CHAIN_PER 很低）。所以这个不是造成空间浪费的原因原因。所以，造成空间浪费的真正原因是
一：频繁的DEL操作，导致表的HWM被拉高。
二：备份表只插入，不做定期清理。
下面我们验证一下，删除操作对数据库表空间的影响。
我们以SA_IMS_PRODUCT_GROUP这个打表为例，然后创建一个新表，表的记录跟原来是一样多的，然后比较删除记录前跟删除记录后，表空间的情况。
创建表：
create table SA_IMS_PRODUCT_GROUP_HHS as select * from SA_IMS_PRODUCT_GROUP
对表SA_IMS_PRODUCT_GROUP_HHS进行表分析
analyze table SA_IMS_PRODUCT_GROUP_HHS compute statistics
下面是删除操作之前的表的空间情况。可以发现，SA_IMS_PRODUCT_GROUP_HHS这个表比SA_IMS_PRODUCT_GROUP这个表占的空间少了2G多。仅为122M左右，原表为2.7G.
接下来，我们删除一些记录，然后看看HWM是否会下降。
delete from SA_IMS_PRODUCT_GROUP_HHS where CITY_NAME='CHPA'
对表再进行分析，下面是分析结果，可以发现，表记录少了，但表的大小没有降下来，表明表的HWM还是删除前的水位。
然后我们再把删除的记录插进去，看看表是否变化了。
i nsert into SA_IMS_PRODUCT_GROUP_HHS select * from SA_IMS_PRODUCT_GROUP where CITY_NAME='CHPA'
对表再进行分析，下面是分析结果，可以发现，表记录跟删除前一样多，但表的尺寸变
大了，表明表的HWM被拉高了，尽管记录还是一样多。
从上面的验证可以发现，如果我们对表进行反复删除，并且插入新记录，每次操作都会拉高表的HWM，造成表空间的浪费。那么在我们informatica 的JOB运行过程，是否存在着删除表记录的操作呢？通过对JOB的检查，确实在ETL JOB中，很多地方在装载数据前，为了避免数据记录的重复装载，每次装载之前都会先进行删除操作。
下面我们拿一个JOB来分析，在这个验证中，我们反复运行一个JOB，理论上记录是不会增多的，看对表空间的影响如何。
我们以下面的ETL JOB为例：
下面是运行JOB 之前的目标表的空间情况：
表大小为15232k 数据块为1904块记录数位21666行
然后运行JOB.
下图是运行JOB后，目标表的空间情况：
表大小为15360K 数据块为1920块记录数位21666行
比较可以发现，尽管表记录没变化，但每一次运行JOB。表的尺寸都会增长。
2.5改进措施
综上所述，为了让系统更稳定，减少空间浪费，可以从下面三个方面进行改进：
一：减少表记录删除后，对表空间造成的虚长的影响：
由于删除表记录无法避免，我们只能减少删除操作带来的影响。
为了降低表的HWM。可以采用下面的命令，用来消除部分行迁移，消除空间碎片，使数据更紧密：
注意：
1，对于分区表，不能使用上面这个命令，需要对每个分区进行move，
ALTER TABLE TABLE_NAME MOVE PARTITION PARTITION_NAME;
子分区的情况：
ALTER TABLE TABLE_NAME MOVE SUBPARTITION SUB PARTITION_NAME;
2，对表进行move操作之后，表的索引将处于失效状态，所以在move之后应该对索引重建。索引重建的时候也要区分全局索引和分区索引。
全局索引重建命令：
ALTER INDEX INDEX_NAME REBUILD;
分区索引重建命令：
ALTER INDEX INDEX_NAME REBUILD PARTITION PARTITION_NAME;
下面这个存储过程可以达到以上操作的自动化。
二：对于_DEL 这样的备份表。开发一个ETL JOB 按一定周期（暂定2个月）运行，定期进行清除。
三：作为一项日常数据库维护措施，DBA应该定期监控数据库表空间的利用情况，监控碎片情况，定时整理。
通过上面的三个措施，问题得到解决
oracle系统表和视图说明
1.视图的概述 视图其实就是一条查询sql语句，用于显示一个或多个表或其他视图中的相关数据。视图将一个查询的结果作为一个表来使用，因此视图可以被看作是存储的查询或一个虚拟表。视图来源于表，所有对视图数据的修改最终都会被反映到视图的基表中，这些修改必须服从基表的完整性约束，并同样会触发定义在基表上的触发器。(Oracle支持在视图上显式的定义触发器和定义一些逻辑约束) 2.视图的存储 与表不同，视图不会要求分配存储空间，视图中也不会包含实际的数据。视图只是定义了一个查询，视图中的数据是从基表中获取，这些数据在视图被引用时动态的生成。由于视图基于数据库中的其他对象，因此一个视图只需要占用数据字典中保存其定义的空间，而无需额外的存储空间。 3.视图的作用 用户可以通过视图以不同形式来显示基表中的数据，视图的强大之处在于它能够根据不同用户的需要来对基表中的数据进行整理。视图常见的用途如下： 通过视图可以设定允许用户访问的列和数据行，从而为表提供了额外的安全控制 隐藏数据复杂性 视图中可以使用连接(join)，用多个表中相关的列构成一个新的数据集。此视图就对用户隐藏了数据来源于多个表的事实。 简化用户的SQL 语句 用户使用视图就可从多个表中查询信息，而无需了解这些表是如何连接的。 以不同的角度来显示基表中的数据 视图的列名可以被任意改变，而不会影响此视图的基表 使应用程序不会受基表定义改变的影响 在一个视图的定义中查询了一个包含4 个数据列的基表中的3 列。当基表中添加了新的列后，由于视图的定义并没有被影响，因此使用此视图的应用程序也不会被影响。 保存复杂查询 一个查询可能会对表数据进行复杂的计算。用户将这个查询保存为视图之后，每次进行类似计算只需查询此视图即可。
ORACLE优化总结和注意事项
ORACLE优化总结和注意事项 本文档中对优化方法进行详述，并对在优化过程中发现的一些问题进行总结。列出ORACLE的一些注意事项 注意事项： 1.安装的过程中，请务必进行正确安装。 2.当安装过程中出现错误的时候，最好清除原有遗留信息，进行重装，否则在数据库运行 的过程中可能会出现各种诡异的问题。 3.当数据库安装的过程中如果有警告信息，请记录下来，存档，方便排查数据库问题 4.安装的过程中请选择OLTP的数据模板Transaction Processing 5.安装过程中文件的创建
Controlfile、Datafiles、Redo Log Groups如果条件允许，最好分别放于不同的磁盘上。其中Controlfile和Redo Log Groups要尽量保证放在不同的磁盘上 6.其中Redo Log Groups重做日志组最好建5组以上，每个文件大小在1G以上，最大不超 过3G，避免出现进行check_point的时候造成buffer wait 导致数据库宕机 7.检查/etc/hosts文件 配置最后一行信息，将当前的主机名和ip配对起来，避免应用服务连接数据库导致的性能损耗 8.安装完成后，请启动数据库确保数据库基本安装成功 步骤： sqlplus /nolog connect /as sysdba startup//启动数据库实例 exit//退出sqlplus lsnrctl start//启动监听
emctl start dbconsole 上述步骤如果执行完，没有报错，则说明数据库基本安装正确，并可正常运行。如果执行上述操作的时候出现了问题，则说明数据库安装的过程中出现了某些问题，即使数据库实例当前可以启动连接，但是在以后稳定服务的过程中也是有可能会出现一些数据库问题的。 配置OCI连接 因为当前应用服务采用OCI连接的方式，因此在运行应用服务之前要配置OCI的连接条件 1、需求软件： 如果应用服务是跟ORACLE数据库安装在一台机器上，则不需要额外软件，直接进入第2步即可 如果应用服务是跟ORACLE数据库分开部署，则需要在部署应用服务的机器上安装一个客户端（精简客户端即可大小几M）需要从官方网站下载三个文件instantclient-basic-linux-x86-64-10.2.0.3-20070103.zip instantclient-sqlplus-linux-x86-64-10.2.0.3-20070103.zip instantclient-jdbc-linux-x86-64-10.2.0.3-20070103.zip 解压到同一个目录中，同时在该目录下新建一个文件tnsnames.ora文件，文件中添加以下内容 # Generated by Oracle configuration tools. HMS = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.10.15.61)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = hms) ) )
oracle数据字典详解
学习笔记：oracle数据字典详解 --- 本文为TTT学习笔记，首先介绍数据字典及查看方法，然后分类总结各类数据字典的表和视图。然后列出一些附例。 数据字典系统表，保存在system表空间中。 由表和视图组成，由服务器在安装数据库时自动创建，用户不可以直接修改数据库字典，在执行DDL 语句时，oracle会自动修改。 记录一些表和视图（只读的），新建的表不要和这空间建在一起(9i以前的版本新用户建的表默认表空间为system，注意修改) --查询数据字典： select * from dictionary --数据字典导出方法： conn / as sysdba spool on spool c:\dic.txt select * from dictionary spool off 主要四部分： 1，内部RDBMS表：x$…… 2，数据字典表：……$ 3，动态性能视图：gv$……，v$…… 4，数据字典视图：user_……,all_……，dba_……
数据库启动时，动态创建x$，在X$基础上创建GV$，在GV$基础上创建V$X$表-->GV$(视图)--->V$(视图) +++ 一，内部RDBMS表x$……，例如：x$kvit,x$bh,x$ksmsp，x$ksppi和x$ksppcv 核心部分，用于跟踪内部数据库信息，维持DB的正常运行。 是加密命名的，不允许sysdba以外的用户直接访问，显示授权不被允许。最好不要修改. x$kvit=Kernel Layer Performance Layer V Information tables Transitory Instance parameter 数据库启动时，动态创建x$…… +++ 二，数据字典表……$，如tab$,obj$,ts$…… --用来存储表、索引、约束以及其他数据库结构的信息。 --创建数据库时通过脚本sql.bsq来创建，脚本：$oracle_home/rdbms/admin/sql.bsq +++ 三，动态性能视图gv$……，v$……，如V$parameter --记录了DB运行时信息和统计数据，大部分动态性能视图被实时更新以反映DB当前状态。 --数据库创建时建立的。 --只有sysdba可以直接访问。 --查看表v$fixed_view_definition(***)，可以查看GV$和V$视图的创建语句。(oracle提供一些特殊视图，用来记录其他视图的创建方式，v$fixed_view_definition就是其中之一) --select view_definition from v$fixed_view_definition where view_name='V$FIXED_TABLE'; --gv$……=Global V$，在X$……基础上创建，是为了满足OPS环境(多个实例)的需要面产生的，可以返回多个实例的信息。
OracleSQL性能优化方法
OracleSQL性能优化方法 Oracle性能优化方法(SQL篇) (1) 1综述 (2) 2表分区的应用 (2) 3访咨询Table的方式 (3) 4共享SQL语句 (3) 5选择最有效率的表名顺序 (5) 6WHERE子句中的连接顺序． (6) 7SELECT子句中幸免使用’*’ (6) 8减少访咨询数据库的次数 (6) 9使用DECODE函数来减少处理时刻 (7) 10整合简单,无关联的数据库访咨询 (8) 11删除重复记录 (8) 12用TRUNCATE替代DELETE (9) 13尽量多使用COMMIT (9) 14运算记录条数 (9) 15用Where子句替换HA VING子句 (9) 16减少对表的查询 (10) 17通过内部函数提高SQL效率 (11) 18使用表的不名(Alias) (12) 19用EXISTS替代IN (12) 20用NOT EXISTS替代NOT IN (13) 21识不低效执行的SQL语句 (13) 22使用TKPROF 工具来查询SQL性能状态 (14) 23用EXPLAIN PLAN 分析SQL语句 (14) 24实时批量的处理 (16)
1综述 ORACLE数据库的性能调整是个重要，却又有难度的话题，如何有效地进行调整，需要通过反反复复的过程。在数据库建立时，就能依照顾用的需要合理设计分配表空间以及储备参数、内存使用初始化参数，对以后的数据库性能有专门大的益处，建立好后，又需要在应用中不断进行应用程序的优化和调整，这需要在大量的实践工作中不断地积存体会，从而更好地进行数据库的调优。 数据库性能调优的方法 ●调整内存 ●调整I/O ●调整资源的争用咨询题 ●调整操作系统参数 ●调整数据库的设计 ●调整应用程序 本文针对应用程序的调整，来讲明对数据库性能如何进行优化。 2表分区的应用 关于海量数据的表，能够考虑建立分区以提高操作效率。建立分区一样以关键字为分区的标志，也能够以其他字段作为分区的标志，但效率不如关键字高。建立分区的语句在建表时能够进行讲明： create table TABLENAME(
ORACLE 性能优化
ORACLE 数据库性能优化 参考书目： 《ORACLE 9i Database Performance Tuning Guide and Reference》《ORACLE 9i Database Reference》 《ORACLE 9i SQL Reference》 《ORACLE 9i Database Administrator’s Guide》
一、数据库实例创建过程参数确定 在创建数据库实例过程中，需要确定以下几个参数： 1. 数据块大小（DB_BLOCK_SIZE） 该参数指明了ORACLE所处理的数据存贮于数据文档以及SGA内存中的数据块大小。 该参数的可选择的范围为:4k,8k,16k,32k,64k。对于OLTP系统而言，取值可以为4K或8K，对于DSS系统而言，则可以取较大的数据，如32K或64K 建议统一取8K（即8192） 说明 DB_BLOCK_SIZE的大小将影响创建表时的EXTENT的大小。例如指定db_block_size=16K,某表空间的EXTENT MANAGEMENT 为local autoallocate，则其系统将extent的大小最小指定为1M.所以将可能导致空间的浪费。 2. 字符集(Character set) 该参数确定数据库以何种字符集来存贮CHAR以及V ARCHAR、V ARCHAR2等字符类型的值。对于ORACLE数据字典中的字符（如表及字段的COMMENT 内容）具有同样的作用。因此需要考虑如字符集的使用。对于国际项目，因为数据库中的comment内容（包括表及字符、存贮过程中的中文字符等内容）可能性需要以中文存贮，而用户业务数据使用的字符可能性是使用本地的语言，基于此，该参数需要选择支持UNICODE的字符编码的字符集。目前ORACLE9i支持以下二种UNICODE字符集： ?UTF8 ?AL32UTF8 建议统一取AL32UTF8
( O管理)ORACLESL性能优化(内部培训资料)
（O管理）ORACLESL性能优化(内部培训资料)
ORACLESQL性能优化系列(一) 1.选用适合的ORACLE优化器 ORACLE的优化器共有3种: a.RULE(基于规则) b.COST(基于成本) c.CHOOSE(选择性) 设置缺省的优化器,可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明,如RULE,COST,CHOOSE,ALL_ROWS,FIRST_ROWS.你当然也在SQL句级或是会话(session)级对其进行覆盖. 为了使用基于成本的优化器(CBO,Cost-BasedOptimizer),你必须经常运行analyze命令,以增加数据库中的对象统计信息(objectstatistics)的准确性. 如果数据库的优化器模式设置为选择性(CHOOSE),那么实际的优化器模式将和是否运行过analyze命令有关.如果table已经被analyze过,优化器模式将自动成为CBO,反之,数据库将采用RULE形式的优化器. 在缺省情况下,ORACLE采用CHOOSE优化器,为了避免那些不必要的全表扫描(fulltablescan),你必须尽量避免使用CHOOSE优化器,而直接采用基于规则或者基于成本的优化器.
2.访问Table的方式 ORACLE采用两种访问表中记录的方式: a.全表扫描 全表扫描就是顺序地访问表中每条记录.ORACLE采用一次读入多个数据块(databaseblock)的方式优化全表扫描. b.通过ROWID访问表 你可以采用基于ROWID的访问方式情况,提高访问表的效率,,ROWID包含了表中记录的物理位置信息..ORACLE采用索引(INDEX)实现了数据和存放数据的物理位置(ROWID)之间的联系.通常索引提供了快速访问ROWID的方法,因此那些基于索引列的查询就可以得到性能上的提高. 3.共享SQL语句 为了不重复解析相同的SQL语句,在第一次解析之后,ORACLE将SQL语句存放在内存中.这块位于系统全局区域SGA(systemglobalarea)的共享池(sharedbufferpool)中的内存可以被所有的数据库用户共享.因此,当你执行一个SQL语句(有时被称为一个游标)时,如果它和之前的执行过的语句完全相同,ORACLE就能很快获得已经被解析的语句以及最好的执行路
Oracle SQL性能优化方法研究
Oracle SQL性能优化方法探讨 Oracle性能优化方法(SQL篇) (1) 1综述 (2) 2表分区的应用 (2) 3访问Table的方式 (3) 4共享SQL语句 (3) 5选择最有效率的表名顺序 (5) 6WHERE子句中的连接顺序． (6) 7SELECT子句中幸免使用’*’ (6) 8减少访问数据库的次数 (6) 9使用DECODE函数来减少处理时刻 (7) 10整合简单,无关联的数据库访问 (8) 11删除重复记录 (8) 12用TRUNCATE替代DELETE (9) 13尽量多使用COMMIT (9) 14计算记录条数 (9) 15用Where子句替换HAVING子句 (9) 16减少对表的查询 (10) 17通过内部函数提高SQL效率 (11)
18使用表的不名(Alias) (12) 19用EXISTS替代IN (12) 20用NOT EXISTS替代NOT IN (13) 21识不低效执行的SQL语句 (13) 22使用TKPROF 工具来查询SQL性能状态 (14) 23用EXPLAIN PLAN 分析SQL语句 (14) 24实时批量的处理 (16)
1综述 ORACLE数据库的性能调整是个重要，却又有难度的话题，如何有效地进行调整，需要通过反反复复的过程。在数据库建立时，就能依照顾用的需要合理设计分配表空间以及存储参数、内存使用初始化参数，对以后的数据库性能有专门大的益处，建立好后，又需要在应用中不断进行应用程序的优化和调整，这需要在大量的实践工作中不断地积存经验，从而更好地进行数据库的调优。 数据库性能调优的方法 ●调整内存 ●调整I/O ●调整资源的争用问题 ●调整操作系统参数 ●调整数据库的设计 ●调整应用程序 本文针对应用程序的调整，来讲明对数据库性能如何进行优化。 2表分区的应用 关于海量数据的表，能够考虑建立分区以提高操作效率。建
ORACLE性能优化31条
1.ORACLE的优化器共有3种 A、RULE (基于规则) b、COST (基于成本) c、CHOOSE (选择性) 设置缺省的优化器，可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明，如RULE，COST，CHOOSE，ALL_ROWS，FIRST_ROWS 。你当然也在SQL句级或是会话(session)级对其进行覆盖。 为了使用基于成本的优化器(CBO，Cost-Based Optimizer) ，你必须经常运行analyze 命令，以增加数据库中的对象统计信息(object statistics)的准确性。 如果数据库的优化器模式设置为选择性(CHOOSE)，那么实际的优化器模式将和是否运行过analyze 命令有关。如果table已经被analyze过，优化器模式将自动成为CBO ，反之，数据库将采用RULE 形式的优化器。 在缺省情况下，ORACLE采用CHOOSE优化器，为了避免那些不必要的全表扫描(full table scan) ，你必须尽量避免使用CHOOSE优化器，而直接采用基于规则或者基于成本的优化器。 2.访问Table的方式 ORACLE 采用两种访问表中记录的方式： A、全表扫描 全表扫描就是顺序地访问表中每条记录。ORACLE采用一次读入多个数据块(database block)的方式优化全表扫描。 B、通过ROWID访问表 你可以采用基于ROWID的访问方式情况，提高访问表的效率，ROWID包含了表中记录的物理位置信息。ORACLE采用索引(INDEX)实现了数据和存放数据的物理位置(ROWID)之间的联系。通常索引提供了快速访问ROWID的方法，因此那些基于索引列的查询就可以得到性能上的提高。 3.共享SQL语句 为了不重复解析相同的SQL语句，在第一次解析之后，ORACLE将SQL语句存放在内存中。这块位于系统全局区域SGA(system global area)的共享池(shared buffer pool)中的内存可以被所有的数据库用户共享。因此，当你执行一个SQL语句(有时被称为一个游标)时，如果它和之前的执行过的语句完全相同，ORACLE就能很快获得已经被解析的语句以及最好的执行路径。ORACLE的这个功能大大地提高了SQL 的执行性能并节省了内存的使用。 可惜的是ORACLE只对简单的表提供高速缓冲(cache buffering)，这个功能并不适用于多表连接查询。 数据库管理员必须在init.ora中为这个区域设置合适的参数，当这个内存区域越大，就可以保留更多的语句，当然被共享的可能性也就越大了。 当你向ORACLE提交一个SQL语句，ORACLE会首先在这块内存中查找相同的语句。这里需要注明的是，ORACLE对两者采取的是一种严格匹配，要达成共享，SQL语句必须完全相同(包括空格，换行等)。 数据库管理员必须在init.ora中为这个区域设置合适的参数，当这个内存区域越大，就可以保留更多的语句，当然被共享的可能性也就越大了。 共享的语句必须满足三个条件： A、字符级的比较：当前被执行的语句和共享池中的语句必须完全相同。 B、两个语句所指的对象必须完全相同： C、两个SQL语句中必须使用相同的名字的绑定变量(bind variables)。 4.选择最有效率的表名顺序(只在基于规则的优化器中有效) ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，因此FROM子句中写在最后的表(基础表driving table)将被最先处理。在FROM子句中包含多个表的情况下，你必须选择记录条数最少的表作为基础表。当ORACLE处理多个表时，会运用排序及合并的方式连接它们。首先，扫描第一个表(FROM子句中最后的那个表)并对记录进行派序，然后扫描第二个表(FROM子句中最后第二个表)，最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并。 如果有3个以上的表连接查询，那就需要选择交叉表(intersection table)作为基础表，交叉表是指
Oracle ERP常用系统表结构
PO模块常用表结构 表名: PO.PO_REQUISITION_HEADERS_ALL 说明: 采购请求 REQUISITION_HEADER_ID NUMBER PR头标识码 SEGMENT1VARCHAR2(20)PR号 ENABLE_FLAG VARCHAR2(1)使能标志(Y/N) AUTHORIZATION_STATUS VARCHAR2(25)批准标志(APPROVED/) TYPE_LOOKUP_CODE VARCHAR2(25)类型(PURCHASE) REQUIST_ID NUMBER请求标识码 CANCEL_FLAG VARCHAR2(1)取消标志(Y/N) TRANSFERRED_TO_OE_FLAG VARCHAR2(1)可否转入OE标志(Y/N) PREPARER_ID NUMBER准备人ID(可与HR.PER_PEOPLE_F.PERSON_ID关联） 表名: PO.PO_REQUISITION_LINES_ALL 说明: 采购请求明细 REQUISITION_LINE_ID NUMBER PR行ID REQUISITION_HEADER_ID NUMBER PR头ID LINE_NUM NUMBER栏目 LINE_TYPE_ID NUMBER行类别 CATEGORY_ID NUMBER归类标识码 ITEM_DESCRIPTION VARCHAR2(240)项目描述 UNIT_MEAS_LOOKUP_CODE VARCHAR2(25)单位 UNIT_PRICE NUMBER单价(已折为人民币) QUANTITY NUMBER数量 DELIVER_TO_LOCATION_ID NUMBER交货位置码（与HR.HR_LOCATIONS.LOCATION_ID关联）TO_PERSON_ID NUMBER收货人代码 SOURCE_TYPE_CODE VARCHAR2(25)来源类型 ITEM_ID NUMBER项目内码 ITEM_REVISION VARCHAR2(3)项目版本 QUANTITY_DELIVERED NUMBER已交付数量 SUGGESTED_BUYER_ID NUMBER建议采购员代码 ENCUMBERED_FLAG VARCHAR2(1)分摊标志 RFQ_REQUIRED_FLAG VARCHAR2(1) NEED_BY_DATE DATE需求日期(原始) LINE_LOCATION_ID NUMBER定位行标识码(为空时表示未生成PO) MODIFIED_BY_AGENT_FLAG VARCHAR2(1)被采购员更改标志（被拆分Y/NULL）
Oracle性能优化
ORACLE的优化器共有3种 A、RULE (基于规则) b、COST (基于成本) c、CHOOSE (选择性) 设置缺省的优化器，可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明，如RULE，COST，CHOOSE，ALL_ROWS，FIRST_ROWS 。你当然也在SQL句级或是会话(session)级对其进行覆盖。 为了使用基于成本的优化器(CBO， Cost-Based Optimizer) ，你必须经常运行analyze 命令，以增加数据库中的对象统计信息(object statistics)的准确性。 如果数据库的优化器模式设置为选择性(CHOOSE)，那么实际的优化器模式将和是否运行过analyze命令有关。如果table已经被analyze过，优化器模式将自动成为CBO ，反之，数据库将采用RULE形式的优化器。 在缺省情况下，ORACLE采用CHOOSE优化器，为了避免那些不必要的全表扫描(full table scan) ，你必须尽量避免使用CHOOSE优化器，而直接采用基于规则或者基于成本的优化器。 2.访问Table的方式 ORACLE 采用两种访问表中记录的方式： A、全表扫描 全表扫描就是顺序地访问表中每条记录。ORACLE采用一次读入多个数据块(database block)的方式优化全表扫描。 B、通过ROWID访问表 你可以采用基于ROWID的访问方式情况，提高访问表的效率， ROWID 包含了表中记录的物理位置信息。ORACLE采用索引(INDEX)实现了数据和存放数据的物理位置(ROWID)之间的联系。通常索引提供了快速访问ROWID的方法，因此那些基于索引列的查询就可以得到性能上的提高。 3.共享SQL语句 为了不重复解析相同的SQL语句，在第一次解析之后，ORACLE将SQL语句存放在存中。这块位于系统全局区域SGA(system global area)的共享池(shared buffer pool)中的存可以被所有的数据库用户共享。因此，当你执行一个SQL语句(有时被称为一个游标)时，如果它和之前的执行过的语句完全相同， ORACLE就能很快获得已经被解析的语句以及最好的执行路径。ORACLE的这个功能大提高了SQL的执行性能并节省了存的使用。 可惜的是ORACLE只对简单的表提供高速缓冲(cache buffering)，这个功能并不适用于多表连接查询。
Oracle性能优化
y物理模型CheckList （Oracle，性能） 1. 系统级优化 数据库参数配置 合理分配SGA及其内部参数（经验值如下）： SGA=phy*（60%-80%） Share pool=SAG*45% DB Cache=SGA*45% Log Buffer: 1~3M 注：Oracle9i在Windows下有bug，是由Windows下的SGA最大 值有2G的限制造成的 注意调整process和open cursor参数，这两个参数直接影响 数据库的session量 分离表和索引：将表和索引建立在不同的表空间，决不要将 不属于Oracle内部系统的对象存放到SYSTEM表空间。同 时，确保数据表空间和索引表空间置于不同的硬盘，减少I/O 竞争； 如果是企业版数据库，大表可以考虑采取分区存储措施，提 高系统的性能； 优化Export和Import工作：使用较大的BUFFER(比如10MB , 10,240,000)可以提高EXPORT和IMPORT的速度 定期分析查询计划，提高数据库的性能；
2. 索引相关 要对经常查询的字段建立索引，但是由于索引管理的开销， 在增删改操作频繁的情况下避免建立不必要的索引； 对于只读或者接近只读的场合，如数据仓库，对于势值比较 小的列可以考虑使用bitmap索引； 如果索引是建立在多个列上, 只有在它的第一个列(leading column)被where子句引用时,优化器才会选择使用该索引. 3. SQL相关 Oracle的From子句表的顺序：记录越多的表放在越前面 （左）； Oracle的where子句表达式的顺序：过滤掉最大数目记录的条 件放到where子句的末尾； Select子句中避免使用‘*’，增加了查询表的列的开销； 在执行结果等效的情况下，使用Truncate代替Delete； 为了在查询过程中要尽量使用索引，对于like语句避免使用 右匹配或者中间匹配的模糊查询； 将过滤条件尽可能放到Where子句中，而不是放到Having子 句中； 在SQL语句中，要减少对表的查询，特别是在含有子查询的 SQL子句中； 使用表的别名可以减少解析的时间并避免引起歧义； 使用exists替代in； 用NOT EXISTS替代NOT IN； 通常情况下，采用表连接的方式比exists更有效率； 当提交一个包含一对多表信息(比如部门表和雇员表)的查询
ORACLE系统包介绍
Oracle 系统包 DBMS_OUTPUT a)启用 i. dbms_output.enable(buffer_size in integer default 20000); ii. set serveroutput on; b)禁用 i. dbms_output.disable; c)PUT和PUT_LINE i. PUT：所有信息显示在同一行 ii. PUT_LINE信息显示后，自动换行 d)NEW_LINE用于在行的尾部追加行结束符，一般用PUT同时使用 e)GET_LINE和GET_LINES i. DBMS_OUTPUT.GET_LINE(li ne 0UTVARCHAR2,status OUT INTEGER)用于取缓冲区的单行 信息 ii. DBMS_OUTPUT.GET_LINES(lines OUT chararr,numlies IN OUT INTEGER) 用于取得缓冲区的多行信息 DBMS_JOB a)SUBMIT用于建立一个新作业 语法 DBMS_JOB.SUBMIT( job OUT BINARY_INTEGER, what IN VARCHAR2, next_date IN DATE DEFATULT SYSDATE, interval IN VARCHAR2 DEFAULT ' NULL' , no_parse IN BOOLEAN DEFAULT FALSE, instance IN BINARY_INTEGER DEFAULT any_instance, force IN DEFAULT FALSE); 例子 VAR jobno NUMBER; BEGIN DBMS_JOB.SUBMI( :jobno, 'pro_hrs101d0_ins_hrs101t0', sysdate, ‘sysdate+1 '); b)REMOVE!于删除作业队列中的特定作业 语法：DBMS_JOB.REMOVE(jov IN BINARY_INTEGER); 例子：DBMS_JOB.REMOVE(10);--删除JOB号为10 的JOB c)CHANGE用于改变与作业相关的所有信息
Oracle性能优化总结
个人理解，数据库性能最关键的因素在于IO，因为操作内存是快速的，但是读写磁盘是速度很慢的，优化数据库最关键的问题在于减少磁盘的IO，就个人理解应该分为物理的和逻辑的优化，物理的是指oracle产品本身的一些优化，逻辑优化是指应用程序级别的优化物理优化： 一、优化内存
V$ROWCACHE视图结构
3.管理员可以通过下述语句来查看数据缓冲区的使用情况 select name,value from v$sysstat where name in ('db block gets', 'consistent gets ', 'physical reads'); 数据缓冲区使用命中率（physical reads除以db block gets加consistent gets之和)一定要小于10%，否则需要增加数据缓冲区大小 4.管理员可以通过执行下述语句，查看日志缓冲区的使用情况 select name,value from v$sysstat where name in ('redo entries','redo log space requests') 根据查询出的结果可以计算出日志缓冲区的申请失败率：requests除以entries 申请失败率应该解决与0，否则说明日志缓冲区开设太小，需要增加Oracle数据库的日志缓冲区 二、物理I/0的优化 1.在磁盘上建立数据文件前首先运行磁盘碎片整理程序 为了安全地整理磁盘碎片，需关闭打开数据文件的实例，并且停止服务。如果有足够的连续磁盘空间建立数据文件，那么就容易避免数据文件产生碎片。 2.不要使用磁盘压缩（Oracle文件不支持磁盘压缩） 3.不要使用磁盘加密
oracle性能调优-管理oracle日志之Oracle日志运行机制
理解Oracle的日志机制 ? Oracle的日志是用来记录用户对数据库的改变，这样，当出现服务器硬件故障或者用户错误而丢失数据时，可以通过重做这些日志来恢复已提交的事务，Oracle日志机制包含以下组件： ?日志缓存SGA的一部分，用于缓存服务器进程产生的日志，包括DML和DDL； ? LGWR进程这个后台进程负责将日志缓存的数据写到联机日志文件，每个实例只有一个； ?数据库检查点检查点用于同步数据文件和日志文件，一个检查点事件的完成，代表在这个事件开始之前发生的所有对数据文件的改变都已实际记录到了数据文件，数据库在这个时间点是一致的，在实例恢复的时候，只有在最后一个检查点之后的日志才需要重做； ?联机日志文件用于存放从日志缓存中写出的日志数据，每个数据库最少需要两个日志文件，当前日志文件填满以后，发生日志切换，然后才可以继续写下一个日志文件； ?日志归档LGWR写满所有组的联机日志文件以后，会回头再写第一个组的日志文件，在非归档模式下，被重用的日志文件中的日志会被丢弃，在归档模式下，日志文件被重用前会被ARC0进程复制到归档日志文件； ? 一些可选的日志机制，如归档和Standby，因为附加的I/O会降低系统的性能，同时提供了可靠的灾难恢复能力，不建议因这些性能的下降而关闭生产系统的归档功能。 调整日志缓存 ? 日志缓存的管理机制可以类似理解成一个漏斗，日志数据不断地从漏斗上方加入，然后偶尔打开漏斗下方的开关将加入的数据清空，这个开关就是LGWR进程，为了日志缓存有空间容纳不断加进来的日志数据，LGWR在下面列出的任何一个条件下都会执行写出日志缓存的操作： ?应用程序发出Commit命令时； ?三秒间隔已到时； ?日志缓存三分之一满时； ?日志缓存达到1M时； ?数据库检查点发生时； ? 测量日志缓存的性能通过服务器进程放置日志条到日志缓存时发生等待的次数和时间来测量； Select Name, Value From V$sysstat Where Name In ('redo entries', 'redo buffer allocation retries','redo log space requests'); redo entries 服务器进程放进日志缓存的日志条的总数量； redo buffer allocation retries 服务器放置日志条时必须等待然后再重试的次数； redo log space requests LGWR进程写出日志缓存时等待日志切换的次数； 这个查询用于计算日志缓存重试率，这个比率应该小于百分之一； Select Retries.Value / Entries.Value "Redo log Buffer Retry Ratio" From V$sysstat Entries, V$sysstat Retries Where https://www.wendangku.net/doc/c110094839.html, = 'redo entries' And https://www.wendangku.net/doc/c110094839.html, = 'redo buffer allocation retries'; 这个查询用来显示哪些会话的LGWR正在进行写等待；
oracle性能优化简介
ORACLE SQL性能优化 我要讲的题目是Oracle SQL性能优化，只是Oracle性能优化中的一项。Oracle的性能优化包含很多方面，比如调整物理存取，调整逻辑存取，调整内存使用，减少网络流量等。这里选择SQL性能优化是因为这部分内容我们测试人员最容易接触到，另外开发人员写SQL脚本时有时很随意，不知不觉就会造成程序性能上的下降。 1．选择最有效率的表名顺序(只在基于规则的优化器中有效) ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,因此FROM子句中写在最后的表(基础表 driving table)将被最先处理. 在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基 础表.当ORACLE处理多个表时, 会运用排序及合并的方式连接它们.首先,扫描第一个表(FROM子句中最后的那个表)并对记录进行派序,然后扫描 第二个表(FROM子句中最后第二个表),最后将所有从第二个表中检索出 的记录与第一个表中合适记录进行合并. 例如: 表 TAB1 16,384 条记录 表 TAB2 1 条记录 选择TAB2作为基础表 (最好的方法) select count(*) from tab1,tab2 执行时间0.96秒 选择TAB2作为基础表 (不佳的方法)
select count(*) from tab2,tab1 执行时间26.09秒 如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表. 例如: EMP表描述了LOCATION表和CATEGORY表的交集. SELECT * FROM LOCATION L , CATEGORY C, EMP E WHERE E.EMP_NO BETWEEN 1000 AND 2000 AND E.CAT_NO = C.CAT_NO AND E.LOCN = L.LOCN 将比下列SQL更有效率 SELECT * FROM EMP E , LOCATION L , CATEGORY C WHERE E.CAT_NO = C.CAT_NO AND E.LOCN = L.LOCN AND E.EMP_NO BETWEEN 1000 AND 2000 2．WHERE子句中的连接顺序． ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾.
oracle性能优化(简单版)
--数据库巡检或性能优化方法各异，但首要的是要发现数据库性能瓶颈，系统自带的statspack,或awr太耗时， --以下是本人常用的方法，共享之 --1、查询数据库等待事件top10,关注前前几个等待事件，关注前三个等待事件是否有因果或关联关系 --oracle 9i select t2.event,round(100*t2.time_waited/(t1.w1+t3.cpu),2) event_wait_percent from ( SELECT SUM(time_waited) w1 FROM v$system_event WHERE event NOT IN ('smon timer','pmon timer','rdbms ipc message','Null event','parallel query dequeue','pipe get', 'client message','SQL*Net message to client','SQL*Net message from client','SQL*Net more data from client', 'dispatcher timer','virtual circuit status','lock manager wait for remote message','PX Idle Wait', 'PX Deq: Execution Msg','PX Deq: Table Q Normal','wakeup time manager','slave wait','i/o slave wait', 'jobq slave wait','null event','gcs remote message','gcs for action','ges remote message','queue messages') ) t1, (select * from ( select t.event,t.total_waits,t.total_timeouts,t.time_waited,t.average_wait,rownum num from (select event,total_waits,total_timeouts,time_waited,average_wait from v$system_event where event not in ('smon timer','pmon timer','rdbms ipc message','Null event','parallel query dequeue','pipe get', 'client message','SQL*Net message to client','SQL*Net message from client','SQL*Net more data from client', 'dispatcher timer','virtual circuit status','lock manager wait for remote message','PX Idle Wait', 'PX Deq: Execution Msg','PX Deq: Table Q Normal','wakeup time manager','slave wait','i/o slave wait', 'jobq slave wait','null event','gcs remote message','gcs for action','ges remote message','queue messages') order by time_waited desc ) t) where num<11) t2, (SELECT VALUE CPU FROM v$sysstat WHERE NAME LIKE 'CPU used by this session' ) t3 --oracle10g select t2.event,round(100*t2.time_waited/(t1.w1+t3.cpu),2) event_wait_percent from ( SELECT SUM(time_waited) w1 FROM v$system_event WHERE event NOT IN ('smon timer','pmon timer','rdbms ipc message','Null event','parallel query dequeue','pipe get','client message','SQL*Net message to client','SQL*Net message from client','SQL*Net more data from client','dispatcher timer','virtual circuit status','lock manager wait for remote message','PX Idle Wait','PX Deq: Execution Msg','PX Deq: Table Q Normal','wakeup time manager','slave wait', 'i/o slave wait','jobq slave wait','null event','gcs remote message','gcs for action','ges remote
- Oracle性能优化总结
- oracle性能优化总结
- Oracle性能调优原则
- OracleDBA应遵循的调优原则
- Oracle性能优化学习心得
- Oracle数据库性能优化
- Oracle SQL性能调优及加密函数如BASE64、MD5
- Oracle的性能优化课件
- oracle性能优化简介
- ORACLE+SQL性能优化系列
- ORACLE+SQL性能优化(全)
- ORACLE优化总结和注意事项
- oracle性能调优-管理oracle日志之Oracle日志运行机制
- Oracle_SQL性能优化技巧大总结
- ORACLE 性能优化系列
- OracleSQL性能优化方法
- Oracle性能优化学习心得byLYH
- ORACLE SQL性能优化(全)
- Oracle DBA优化数据库性能心得体会
- ORACLESQL性能优化(全)