ORACLE管理优化培训内容临时记录

--根源原理分析本质-》方法
--ORACLE应用优化占百分比高
优化思路，工具，应用优化（SQL)
--清楚利和BI
--前台主机和后台数据库的处理布署，地点（CPU,IO,网络考虑）
--1.与数据库无关的资源利用分散到其它机器上
--资源合理：业务需求合理（需求过度），SQL算法合理，
--索引与解析关系
--存储，网络，主机，应用（开发），数据库，架构，需求过度
重要人：1.业务+技术，开发DBA（应用架构,需求控制），运维DBA（架构)
--DBA前置
--安全，高效
--OLAP高耗CPU,网络，IO资源（分区减少IO？）
--事务槽参数（INSERT)
--初期调 ：功能，性能，压力
--运行期：监控，周期性调优（主动）
--故障期：被动
--多索引的选择比对
--RBO规划选择了解
--JAVA界面交互，C大量计算
--ER模型
1.大量的冗余拆
2.经常在一起访问不拆，不经常一起访问拆
--代码规范
1.可读性 2.性能（避免硬解析）
--数据规划
1.大小写（转换）
--编码规划（基于这个字段的查询有关）
（省市县，市省县）
--数据库配置（OLAP,OLTP)，先了解业务特征
OLAP:IO型，PGA,SGA占有用小些
OLTP:PGA小些，SGA大些
--需与供
1.先调需再调供（应用向数据库）
2.数据库与OS（需与供）
应用，数据库，OS（顺序）
--
delete ,update会带来索引碎片
insert带来分裂
--大池（并行时会用到），日志缓冲区（大量LOAD数据）
--数据预处理（中间数据）
--OLAP吞吐量：单块大小*多块读取，OS，对象的EXTENT的大小（连续分配块),数据库读多块是不能跨EXTEND
--数据分布不均列-》收集柱状图信息
--PL/SQL:逻辑简易（大数据），而少量数据（复杂逻辑）采用程序语方处理（JAVA,C）；
写好SQL，选好算法（索引），访问数据块IO少---SQL优化归结为这3句话
--ADDM的使用
--server process(发送信息+接收信息）

 SQL_ADDRESS                                        RAW(8)
 SQL_HASH_VALUE                                     NUMBER
 dict v$fixed_table
 
 statspack--服务端安装？
 --先判断可能出现的原因，再逐层排除确定？--解决问题思路
-- awr--mmon进程负责

--位图可以并行修改

--每块最小的行数
--单次读取不能跨EXTEND


--不同对象（广度），所有对象的认识了解

--RBO ,写的SQL的位置，WHERE所放的条件，表从右往左，WHERE条件从下往上,Rbo(稳定不变,需求恒定不变),
--RBO 它的= <= <的优先级别
--RBO对SQL的写法，人工干预强a+0=10(索引换成全表)
--数据变化超过10%进行统计信息（条件判断，自动化收集JOB）
--optimizer_mode ,true(有统计信息CBO,没统计信息RBO），choose,first_row_n(趋向于索引),all_rows(趋向于全表扫描,混合模式),rule;
--表连接方式测试确定
--HASH JOIN与PGA有关（全表扫描，IO高，CPU低）
nest loop:（IO低，CPU高）
sort merge(关联的字段上有索引，表上没索引时？）
降低IO:分区表，（CBO模式下，高级算法RBO不支持)
--grant all on table to public;
--要的数据在索引用like '_k%'也可走索引,可以把索引当作一个小表（包含某列的值)
小结：因为索引是有序的；如：select object_name FROM a where object_name like '_BA_OBJECT%'
--rollup使用
--db block gets:current block(DML),consistents gets(select)带来引起的

--周末(evnet事件汇总与查看OID);

(b) 10046事件说明
10046事件是Oracle提供的内部事件，是对SQL_TRACE的增强.
10046事件可以设置以下四个级别:
1 - 启用标准的SQL_TRACE功能,等价于sql_trace
4 - Level 1 加上绑定值(bind values)
8 - Level 1 + 等待事件跟踪
12 - Level 1 + Level 4 + Level 8
类似sql_trace，10046事件可以在全局设置，也可以在session级设置。

--数据文件都在内存中时-》net message to client事件；

--tkprof很多参数的使用--工具的深入使用
[oracle@localhost ~]$ tkprof
Usage: tkprof tracefile outputfile [explain= ] [table= ]
              [print= ] [insert= ] [sys= ] [sort= ]
  table=schema.tablename   Use 'schema.tablename' with 'explain=' option.
  explain=user/password    Connect to ORACLE and issue EXPLAIN PLAN.
  print=integer    List only the first 'integer' SQL statements.
  aggregate=yes|no
  insert=filename  List SQL statements and data inside INSERT statements.
  sys=no           TKPROF does not list SQL statements run as user SYS.
  record=filename  Record non-recursive statements found in the trace file.
  waits=yes|no     Record summary for any wait events found in the trace file.
  sort=option      Set of zero or more of the following sort options:
    prscnt  number of times parse was called
    prscpu  cpu time parsing
    prsela  elapsed time parsing
    prsdsk  number of disk reads during parse
    prsqry  number of buffers for consistent read during parse
    prscu   number of buffers for current read during parse
    prsmis  number of misses in library cache during parse
    execnt  number of execute was called
    execpu  cpu time spent executing
    exeela  elapsed time executing
    exedsk  number of disk reads during execute
    exeqry  number of buffers for consistent read during execute
    execu   number of buffers for current read during execute
    exerow  number of rows processed during execute
    exemis  number of library cache misses during execute
    fchcnt  number of times fetch was called
    fchcpu  cpu time spent fetching
    fchela  elapsed time fetching
    fchdsk  number of disk reads during fetch
    fchqry  number of buffers for consistent read during fetch
    fchcu   number of buffers for current read during fetch
    fchrow  number of rows fetched
    userid  userid of user that parsed the cursor
    
    ---每个工具的使用场景（ORADEBUG SPID)--直接针对高负载SPID
    --SQL TUNING ADVISOR与人为合在一起使用
    --ORACLE 调 优工具使用
    --filter(M*N次的比较)两表之间的连接模式;
    --OEM可作为参照学习使用
    -->与别人的不同“广度和深度”-》分析思路（经验）
    --in ,exests,minus在替换时要注意结果；
    --物化视图：数据库仓库，报表，适合较为数据稳定的表（最适合场景)
    --聚簇：1.同类数据一起（省空间，少冗余） 2.多的数据在一起，排好序
         坏处：DML的维护和在扫描时候要在2个表中进行；（适合数据仓库，经常需要连接表）
    --IOT:适合范围扫描数据（所取的数据），基于主关键字的查询；
    --IOT建立逻辑ROWID，而物理的ROWID，坏处是基于非主关键字的查询没有显示出优势，建立的索引为假ROWID;
    --unique index:对DML不利，两边需校验,但有利于select
    8K/40=200
    200*200=40000(2层)
    40000*200=8000000(第3层)
    --索引内容的大小，索引块，索引的数据量（索引的影响因素），索引数据的分布，全表扫描IO的能力，索引块的层次（数据块）
    小结：索引的影响因素：索引内容大小，索引块大小，索引的数据量，索引的数据分布，全表扫描IO的能力，索引的高度
    --删除与关键字的UPDATE造成（索引碎片，松散），倾斜与插入有关系,造成索引的深度加大；--影响索引的性能
    小结：update,delete操作造成索引的松散（碎片），倾斜由插入造成的（加大深度）；
    --count(*) 与not null约束对索引的影响，not null列可相互借用
    小结：COUNT一NOT NULL等价于COUNT -NOT NULL另一列（ORACLE会自动选择）；
----------------------------------------------------------
index_stats视图(单会话生效）

     DEL_LF_ROWS                                        NUMBER
     DEL_LF_ROWS_LEN                                    NUMBER  DEL_LF_ROWS_LEN/DEL_LF_ROWS 大于20考虑重建; (松散度）
     
     SQL>                               desc index_stats
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 HEIGHT                                             NUMBER   --索引深度问题结合表的行数判断正常与否；
 
 --rebuild不能解决逻辑块问题（应该drop+create)
 
     --analyze 干的  
 AVG_SPACE                                          NUMBER
 CHAIN_CNT                                          NUMBER
 
 ----------------------------------------
 AVG_LEAF_BLOCKS_PER_KEY                            NUMBER
 AVG_DATA_BLOCKS_PER_KEY                            NUMBER
 
 --相差越小越好？
 --------------------------------------