ACCESS【面试虐菜】—— Oracle知识整理《收获,不止Oracle》

平时堆表不足之处:

    表更新有日记开销

   
表删除有毛病

   
表记录太大搜索较慢

   
索引回表读开支很大

   
有序插入难有序读出

 

DELETE产生的undo最多,redo也最多,因为undo也需要redo保护

 

全局临时表:

1
高效去除记录

  基于事务的全局临时表commit或者session连接退出后,自动删除

  基于回话的大局临时表在剥离回话后自行删除

 

2
针对不一样的对话数据独立,不一样的session访问全局临时表,看到的结果差距

 

大局临时表在先后的四回调用实践进度中,必要频繁清空记录再插入记录,就考虑接纳基于是无敌额

 

分区表

--分区表删除
alter table range_part_tab truncate partition p9;

--分区表交换
alter table range_part_tab exchange partition p9 with table mid_table;

--分区表的分割
alter table range_part_tab split partition p_max at(to_date('2013-02-01','YYYY-MM-DD'))into (partition p2013_01,partition p_max);

--分区表合并
alter table range_part_table merge partitions p2013_01,p_max into partition p_max;

 

SCN,有限支撑数据一致读,解决了读一致性的标题,幸免选用锁

 

 

Oracle开启与关闭进程

1
startup nomount 寻找定位
参数文件(SGA共享内存段开启,后台进度开启)

2
alter database mount 寻找定位 控制文件(其中富含 数据文件 日志文件
检查点音讯等)

3
alter database open 寻找定位 数据文件 日志文件等

 

关闭刚刚是翻开的逆进度:

整套下令融合在shutdown
immediate里面

database
closed.

database
dismounted.

oracle
instance shut down.

 

各文件查找地方:

show
parameter spfile;

show
parameter control;

 

sqlplus
“/ as sysdba”

select
file_name from dba_data_files;

select
group#,member from v$logfile;

show
parameter recovery;

setlinesize
1000;

show
parameter dump;

 

cd
/home/oracle/admin/itmtest/bdump

ls
-lart alert*

 

OLTP倾向于让块的尺寸小一些:因为一旦块太大,不难导致大气冒出查询及革新操作都对准同一个数据块,从而发生热点块竞争。

 

Leaf
主要囤积了 key column value 以及
具体能定位到数据块所在地方的rowid

 

目录特点:

    高度比较低

    存储索引列还有rowid

    本身是形影不离的

 

MIN
MAX的目录优化:INDEX FULL SCAN(MIN\MAX)

    select max(object_id) from t;
    select max,min from (select max(object_id) max from t) a,(select min(object_id) min from t) b;

 

目录回表读(TABLE
ACCESS BY INDEX ROWID)

select * from t where object_id <=5;

因为是select
* 查询完索引列后,还索要再次回到查询其他任何的值

 

INDEX
RANGE SCAN
针对索引中度较低这些特点落成的一种限制扫描,在回到记录很少时一定连忙。

 

INDEX
FAST FULL SCAN 针对所有索引的全扫描,一遍读取四个索引块

INDEX
FULL SCAN
针对所有索引的全扫描,一次读取一个索引块,有利于数据的排序,在count*的场子很适用,但是逻辑读增添了

 

Union,对多个结果集进行并集操作,不包蕴重复行,同时拓展默许规则的排序;

Union
All,对多个结果集举办并集操作,包涵重复行,不开展排序;

 

主外键:

    1
主键本身是一种索引

    2
可以确保表中主键所在列的唯一性

    3
可以使得的限量外键看重的表的记录的完整性

 

假定某个表建立的目录过多,插入数据的时候会很慢。可以去除索引后,插入,再建立目录。可以优化很大一部分的年月。

 

索引过多,对二种操作的熏陶:

1
对insert影响最大,只要有目录,就会变慢,愈来愈多越慢。

2
对delete来说,有好有坏,在海量数据删除较少多少的时候,很有用。不过过多的目录,也会使得其余的目录举行更新时代价变大。

3
对update的影响微乎其微。

 

树立索引会引起上上下下表的锁,使得表被挂起,任何操作不可能推行。

 

alter
index 索引名 monitoring usage;

select * from v$object_usage;--查询索引是否被使用

alter index 索引名 nomonitoring usage;--解锁索引监控

 

位图索引允许存储为空值(缺点,举行插队的时候,同一个目录的值相同,是插不进入的)

 

确立位图索引适合的三个规格:1
位图索引列多量重新 2 该表极少更新

 

干什么位图索引只适用于低基数值,可是对屡次更新的列不适用。
案由在于,PROCESSED_FLAG列只有四个值:Y和N。对于插入到表中的笔录,该列值为N(表示未处理)。别的进度读取和拍卖那几个记录时,就会把该列值从N更新为Y。这么些进程要疾速地找出PROCESSED_FLAG列值为N的记录,所以开发人员知道,应该对这些列建立目录。他们在别处驾驭到,位图索引适用于低基数(low-cardinality)列,所谓低基数列就是指那几个列只有很少的可取值,所以看上去位图索引是一个很自然的抉择。
不过,所有难题的案由正是以此位图索引。选用位图索引,一个键指向多行,可能数以百计甚至越来越多。假使更新一个位图索引键,那么这一个键指向的数百条记录会与您其实创新的那一行一同被有效地锁定。
为此,即使有人插入一条新记录(PROCESSED_FLAG列值为N),就会锁定位图索引中的N键,而那会一蹴而就地同时锁定其余数百条PROCESSED_FLAG列值为N的记录(以下记作N记录)。此时,想要读那些表并处理记录的历程就无法将N记录修改为Y记录(已处理的记录)。原因是,要想把那么些列从N更新为Y,须要锁定同一个位图索引键。实际上,想在那个表中插入新记录的任何会话也会卡住,因为它们同样想对这些位图索引键锁定。容易地讲,开发人士达成了那般一组协会,它五遍最多只允许一个人插入或更新!
可以用一个粗略的例子表明那种场馆。在此,使用多个会话来突显阻塞很简单暴发:

ORA10G> create table t ( processed_flag varchar2(1) );
Table created.
ORA10G> create bitmap index t_idx on t(processed_flag);
Index created.
ORA10G> insert into t values ( 'N' );
1 row created.

当今,若是在另一个SQL*Plus会话中推行以下命令:

ORA10G> insert into t values ( 'N' );

那条语句就会“挂起”,直到在第二个闭塞会话中发生COMMIT甘休。

相关文章