oracle training

索引的原理
在二叉树中通过索引找到Rowid， 再通过rowid到table中找到记录

-------------------
Transaction事务 ACID

Isolated
隔离级别
4种隔离级别，
read uncommited (oracle 不支持)
read commited (默认) oracle
repeatable read (在事务即使别人修改了也看不到)
Serializable read (在事务即使别人修改，新增，删除了都看不到) oracle
-- 场景： 读配置树/长事务，其他线程会修改这个数。


Sqlserver db2 支持 read uncommited。 脏读(一个人在提交，另一个人在读)。
原因 是read commited 会阻塞， read uncommited不会阻塞。
为此 sqlserver多出来个 READ_COMMITTED_SNAPSHOT 来解决阻塞问题

Oracle 不支持，用snapshot的方式解决了read commited 阻塞的问题。
Undo segment

行级锁
(Sybase 以前只支持块级锁 2k左右，所以影响范围大)
两个用户同时改一条记录，A改了，没提交， 这时B也去修改，这时B会被block住，要等A提交后才行。

但是会出现第二个用户修改了第一个用户先修改的记录

这就产生了乐观锁和悲观锁
悲观锁 select for update 不推荐
乐观锁 timestamp version


-----------------------------

物理层面 Table -- tablespace -- segment -- extent -- block (8K)
普通表和segment是一一对应的
逻辑层面 用户 oracle/oracle -- schema


90% Heap Table
index和table 的table space 要分开， 避免IO瓶颈

10% IOT table index-organized tables
将这个table作为一个index来储存
而且不用rowid了。
500w 数据中查100w条数据求和 0秒
Heap Table 3秒

Partition table 分区表
对应多个segment，放在不同的tablespace中，放到很多不同的磁盘中，减少了磁盘使用。(Hash Partition) 1000w 数据以上
RAID 磁盘阵列
也就解决了这个问题，partition 在这方面没有多大意义了。
但是更多的是为了管理
如果有个上亿条数据，按月份来分区，如果要删除1月份的数据，没有partition table 用delete会产生很大的undo segment， 很慢。 partition就直接去掉一个分区就ok了。(Range Partition)

并行查询 基于partition

Temporary table
由于不需要undo segment， 所以执行比普通表快。针对于不同的transaction，会对应不同的temporary table (单例)
场景： 用存储过程将数据放入零时表中，进行业务逻辑计算。之后删除

Hash Table 不推荐
两个table有大量的链接查询，把这两个table的segment放在一起。

---------------------------
B-Tree Indexes 二叉树
Reverse Key B-Tree Indexes
Bit Map Indexes 位图索引 性别只有3个可能 （male, female, NA）
不适合频繁新增，修改。 Status flag 就不适合。
update操作时，不是行级锁，而是把这个表锁住。


-------------

OLTP web系统 block 8K
OLAP 大量查询 DSS决策应用 block 32K

--------

Analyse table …. Compute Statistics
oracle自动调优 一般自动1周做一次
如果100w条数据 只有一条id为2，其他的都是1，
这时查where id=1， 如果走index再查rowid，性能反而比全表扫描差。
Anaysis table 会自动决定要怎么走。

性能调优
减少行连接，减少碎片。
Rebuild index on line
Rebuild table

高水标记
数据删了， 但是block还是被占用了，系统全表扫描还是会扫到。 如果有索引了就没这个问题了。
Rebuild table alter table move…
还有种折中的方式create新的table，数据导入，删除原来的，修改新table的名字。
Truncate table
新插入的数据是放到 free list中，高水标记里面的

append 提示 往高水标记外插数据

ASSM 解决 free list争用
不是将meta信息放到第一个block下，而是分布在其他的block中


----------------

Bad practise 用空字符串代替null
null不占空间 空字符串占空间


Block 分为 header / free space / row data
Free space 是用来留出来update的 而不是update

行迁移 update 时 block空间不足了 (常见)
性能降低
这时就需要rebuild table

行链接 一行数据放不下 (很少)


-----------------------------------

Oracle 11g以后的全表扫描会根据大小 选择性的放入buffer cache

SGA -- shared Global Area
1， buffer cache 缓存db数据 hit radio 95%
2， Redo log -- 频繁的写入redo file
3， Shared Pool 缓存执行计划 hit radio 95%

PGA -- private GA
有自己的内存结构 存放用户相关信息 排序规则等

Checkpoint
日志切换时会发生一次checkpoint，DBWR会把buffer cache 往db file写数据

-------------------------
Shutdown immediate 常用
Shutdown 等所有连接断开
Shutdown transactional 等事务结束
Shutdown abort 在无法正常shut down的情况下 暴力shutdown

Startup 执行了3步操作 nomount / mount / open
1， 读参数文件(pfile, spfile)， 启动内存
2， mount control file
3, 线程打开相应的file

Startup mount 1,2 步
Disable Archieve log
Alter database open

Startup nomount 第一步
用以查看某些parameter修改错误 导致无法startup的情况
Alter system set memory_max_target=800M scope=spfile;

Find . -name "*.ora"

Startup nomount pfile='…./initinitorcl.ora'

------------------------------
Toad 可以分析redo log, 可以分析行迁移/行链接，health check

-----------------------------
执行计划
清理执行计划
Alter system flush shared pool;

Preparestatement 预存了带问号的执行计划，以后每次使用都不需要再生成新的执行计划。
如果碰到特殊的记录 1000w 条数据 1条id是1 其余的都是1000
如果第一次查id=1000， 这时执行计划会觉得全表扫描快，所以生成了全表扫描的执行计划。 第二次要id=1 用的还是全表扫描的执行计划。

Createstatment 每次的查询值不同，都会创建新的执行计划
适合OLAP系统，都是select 操作


但是preparestatment 避免了shared pool 中缓存过多id=1/2/3...的执行计划。
适合OLTP系统。

CBO 基于成本的优化器 (默认) 11G支持的很好
CRO 基于规则的优化器 有索引就用索引

碰到抽风的时候 优化步骤
1， 基于现有数据，重新进行表分析
2， 创建一个规则，用hint的方式，创建基于CRO的优化器

----------------------
cursor sharing EXACT/FORCE/SIMILAR
DBA用来解决了shared pool 中缓存过多id=1/2/3...的执行计划


Hibernate 是createStatement 还是prepareStatement？
prepareStatement的
如我执行：find("select * from t_table where id = ?",new Integer(5));
在控制台显示SQL时只显示：select * from t_table where id = ?