Oracle study之--HASH Cluster特点
Oracle study之--HASH Cluster特点
Hash Cluster Table是Cluster Table的一种(另一种是Index Cluster Table)。在Hash Cluster Table中,Oracle会为每行数据按Hash键计算一个Hash值,拥有同样Hash值的记录在Hash Table中会物理上存放在一起,oracle为Hash Key计算所得到的Hash Value会对应到确定的数据库块地址,这样,应用在访问Hash Cluster Table时就可以根据Hash Value快速定位到要访问的数据,也就是说,在Hash Cluster Table中,数据本身就是索引。
在创建Hash Cluster Table时,有两个参数很重要,它们是SIZE和HASHKEYS参数。SIZE参数指定用来保存相同键值记录的空间大小。HASHKEYS参数指定Hash键的个数。该值要求是一个质数,若用户指定的值不是质数,则数据库会取与用户指定值最接近的质数。
本文试图通过测试验证关于Hash Cluster Table的以下问题:
1. 在提高应用访问性能方面,Hash Cluster Table与索引的区别;
2. 不同SIZE和HASHKEYS参数值对Hash Cluster Table的存储和查询性能有何影响;
3. Hash Cluster Table的适用场景,使用上有什么限制。
测试如下:
表test_hash_cluster有100万条记录,占用空间为55M,其表结构如下:
SQL> select count(*) from test_hash_cluster;
COUNT(*)
----------
1000000
SQL> select bytes/1024/1024 from user_segments where segment_name=\'TEST_HASH_CLUSTER\';
BYTES/1024/1024
---------------
55
SQL> desc TEST_HASH_CLUSTER
Name Null? Type
--------------------------- -------- ------------------
TABLE_NAME VARCHAR2(30)
NDA_ID NUMBER(38)
AGI_ID NUMBER(38)
CHUNK_DATE DATE
COMMIT_SCN NUMBER(22)
假设我们的应用对test_hash_cluster表的访问方式比较固定,具体查询语句如下:
select * from test_hash_cluster where table_name=:B1 and NDA_ID=:B2 and AGI_ID=:B3 and CHUNK_DATE=:B4;
若要求以上查询有个快速响应结果,通常我们会怎么做呢?
一般来说,我们都会考虑在(TABLE_NAME,NDA_ID,AGI_ID,CHUNK_DATE)列上创建组合索引,或者我们将TEST_HASH_CLUSTER表创建为索引组织表(IOT).其实我们还可以考虑Hash Cluster Table.
首先,我们还是为TEST_HASH_CLUSTER表创建索引,以与后面的Hash Cluster Table作性能上的比较。
create index ind_test_hash_cluster on test_hash_cluster (table_name, nda_id, agi_id, chunk_date);
SQL> select bytes/1024/1024 from user_segments where segment_name=\'IND_TEST_HASH_CLUSTER\';
BYTES/1024/1024
---------------
54
exec DBMS_STATS.GATHER_TABLE_STATS(\'SCOTT\',\'TAB_HASH_CLUSTER\',estimate_percent=>100);
SQL> select BLEVEL from user_indexes where index_name=\'IND_TEST_HASH_CLUSTER\';
BLEVEL
----------
2
索引ind_test_hash_cluster占用54MB的空间,其BLEVEL值为2,当我们查询TEST_HASH_CLUSTER表中的一条记录时,理论上我们需要访问三个索引数据块(root block, branch block, leaf block)+一个表数据块,即在没有数据缓存的情况下,我们需要作4次Physical Reads.下面的结果验证了上面的猜测:
select * from test_hash_cluster where table_name=\'NTS_OPEN_FUND_UNIT_TS\' and NDA_ID=1213871 and AGI_ID=2560 and CHUNK_DATE=to_date(\'20050101\',\'yyyymmdd\');
-----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 45 | 4 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST_HASH_CLUSTER | 1 | 45 | 4 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IND_TEST_HASH_CLUSTER | 1 | | 3 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
5 consistent gets
4 physical reads
0 redo size
857 bytes sent via SQL*Net to client
523 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
接下来,我们看看Hash Cluster Table的表现:
CREATE CLUSTER HASH_CLUSTER (
TABLE_NAME VARCHAR2(30),
NDA_ID NUMBER(38,0),
AGI_ID NUMBER(38,0),
CHUNK_DATE DATE )
SIZE 128
HASHKEYS 1000003
STORAGE(INITIAL 1048576 NEXT 1048576);
SQL> select bytes/1024/1024 from user_segments where segment_name=\'HASH_CLUSTER\';
BYTES/1024/1024
---------------
128
CREATE TABLE TAB_HASH_CLUSTER
( TABLE_NAME VARCHAR2(30),
NDA_ID NUMBER(38,0),
AGI_ID NUMBER(38,0),
CHUNK_DATE DATE,
COMMIT_SCN NUMBER(22,0)
)
CLUSTER HASH_CLUSTER (TABLE_NAME, NDA_ID, AGI_ID, CHUNK_DATE) ;
SQL> insert into TAB_HASH_CLUSTER select * from TEST_HASH_CLUSTER;
1000000 rows created.
SQL>commit;
SQL> alter system flush buffer_cache;
SQL> select * from TAB_HASH_CLUSTER where table_name=\'NTS_OPEN_FUND_UNIT_TS\' and NDA_ID=1213871 and AGI_ID=2560 and CHUNK_DATE=to_date(\'20050101\',\'yyyymmdd\');
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 65 | 0 (0)|
|* 1 | TABLE ACCESS HASH| TAB_HASH_CLUSTER | 1 | 65 | |
----------------------------------------------------------------------------
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
2 consistent gets
1 physical reads
0 redo size
853 bytes sent via SQL*Net to client
523 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
从测试结果可以看到,同样的查询语句,当底层表是Hash Cluster Table时,我们只需要作一次Physical Reads,读取一个数据块即可得到需要的数据了。
这是如何实现的呢?
在TAB_HASH_CLUSTER表的底层,oracle根据每条记录的(TABLE_NAME,NDA_ID,AGI_ID,CHUNK_DATE)列作hash计算,得到了一个Hash Value,这些Hash Value会对应到该记录在Cluster中具体的块地址。当应用在查询数据时,如果查询的where条件中提供了具体的(TABLE_NAME,NDA_ID,AGI_ID,CHUNK_DATE)值,Oracle会为查询的条件用同样的Hash算法计算Hash Value,这样,查询时就可以根据该Hash Value直接找到具体的数据块了。
接下来,我们看看SIZE和HASHKEYS参数对Hash表的影响:
前面,我们在创建Cluster HASH_CLUSTER时指定的HASHKEYS值为1000003,表TAB_HASH_CLUSTER的记录数为1000000,HASHKEYS值大于数据记录数,也就是有足够的HASHKEYS来保证HASHKEYS与数据之间是一一对应的。
那么,如果我们指定一个相对较小的HASHKEYS值会怎么样呢?
CREATE CLUSTER HASH_CLUSTER2 (
TABLE_NAME VARCHAR2(30),
NDA_ID NUMBER(38,0),
AGI_ID NUMBER(38,0),
CHUNK_DATE DATE )
SIZE 128
HASHKEYS 10007;
CREATE TABLE TAB_HASH_CLUSTER2
( TABLE_NAME VARCHAR2(30),
NDA_ID NUMBER(38,0),
AGI_ID NUMBER(38,0),
CHUNK_DATE DATE,
COMMIT_SCN NUMBER(22,0)
)
CLUSTER HASH_CLUSTER2 (TABLE_NAME, NDA_ID, AGI_ID, CHUNK_DATE);
表中有1,000,000条记录,但Hashkeys值只有10007个,这样,一个hash值就需要对应多条记录,也就是在读取数据时,一个Hash Value会对应到多个数据块上,也就是需要访问多个数据块,如下:
alter system flush buffer_cache;
SQL> select * from TAB_HASH_CLUSTER2 where table_name=\'NTS_OPEN_FUND_UNIT_TS\' and NDA_ID=1213871 and AGI_ID=2560 and CHUNK_DATE=to_date(\'20050101\',\'yyyymmdd\');
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 65 | 0 (0)|
|* 1 | TABLE ACCESS HASH| TAB_HASH_CLUSTER2 | 1 | 65 | |
----------------------------------------------------------------------------
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
64 consistent gets
63 physical reads
0 redo size
853 bytes sent via SQL*Net to client
523 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
除了Hashkeys参数,影响Hash Cluster Table的另一个重要参数是Size. 拥有相同键值的记录保存在由Size参数指定的同一空间中,或者说同一数据块中。在上面的例子中,10,007个Hash Value对应1,000,000条记录,平均一个Hash Value对应大约100条记录,但从统计信息看来,只访问了63个数据块,而不是100左右,其中重要原因就是Size参数,这里我们设置的是128字节,该Size可能可以存储多于一条的记录,这样100条记录就不一定是在100个不同块中,所以实际访问的数据块只有63。按此逻辑,如果我们将Size参数设置得更大,就可以保证更多拥有相同Hash Value的记录在物理上聚集在一起存放,比如,这里测试将Size设置为1024 byte.
CREATE CLUSTER HASH_CLUSTER3 (
TABLE_NAME VARCHAR2(30),
NDA_ID NUMBER(38,0),
AGI_ID NUMBER(38,0),
CHUNK_DATE DATE )
SIZE 1024
HASHKEYS 10007;
CREATE TABLE TAB_HASH_CLUSTER3
( TABLE_NAME VARCHAR2(30),
NDA_ID NUMBER(38,0),
AGI_ID NUMBER(38,0),
CHUNK_DATE DATE,
COMMIT_SCN NUMBER(22,0)
)
CLUSTER HASH_CLUSTER3 (TABLE_NAME, NDA_ID, AGI_ID, CHUNK_DATE);
select * from TAB_HASH_CLUSTER4 where table_name=\'NTS_OPEN_FUND_UNIT_TS\' and NDA_ID=1213871 and AGI_ID=2560 and CHUNK_DATE=to_date(\'20050101\',\'yyyymmdd\');
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 65 | 0 (0)|
|* 1 | TABLE ACCESS HASH| TAB_HASH_CLUSTER3 | 1 | 65 | |
----------------------------------------------------------------------------
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
7 consistent gets
6 physical reads
0 redo size
853 bytes sent via SQL*Net to client
523 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
正如前面所预料的, physical reads 降低了很多, 从63 降到了 6.
总结来说,当我们决定要用Hash Cluster Table来提高应用查询性能,那么选择合适的SIZE和HASHKEYS参数值就显得异常重要。设置合适SIZE和HASHKEYS参数的标准就是在读取数据时需要访问尽量少的数据块。一种方法就是设置HASHKEYS的值比数据记录数更大,或者当HASHKEYS小于总记录数时,保证Size指定的大小能存下所有拥有相同Hash Value的记录。否则,就会发生类似与“行链接”的想象,数据库需要用溢出块来存储多余的数据,并在原块中建立一个链接来指到新的溢出块上,进而影响访问性能。
最后,我们来看看Hash Cluster Table的适用场景及使用限制:
1. Hash Cluster Table适用于查询较频繁,而写操作相对较少的表,因为写数据时需要为每条记录计算Hash 值,并且需要在固定的块上作插入操作;
2. 由于Hash Cluster Table是基于Hash算法创建的,所以查询时必须是等值查询;否则,无从按查询条件计算Hash值;
3. 在我们决定使用Hash Cluster Table之前,我们需要能合理估计Hash Key的数量以及数据的空间大小,从而选择合适的SIZE和HASHKEYS参数,这对表的访问性能至关重要;
4. 与索引相比,Hash Cluster Table有其优势,如前面的测试所示,但也有其劣势,比如不够灵活。还以前面的例子来看,若我们建的是复合索引,则我们在查询时只要查询条件中指定了前面的一个或几个列,就能利用索引作快速查询。但若是Hash Cluster Table,则要求我们在查询条件中包含所有的Hash Key值。
--------转载自http://blog.itpub.net/27243841/viewspace-1104755/,感谢作者 !
转载于:https://blog.51cto.com/tiany/1642251
Oracle study之--HASH Cluster特点相关推荐
- Oracle Study案例之--基于表空间的时间点恢复(TSPITR)
Oracle Study案例之--基于表空间的时间点恢复(TSPITR) TSPITR(表空间时间点恢复)用于将一个或多个表空间恢复到过去某个时间点的状态,而其他表空间仍然保持现有状态. TSPIT ...
- Oracle Study之--Oracle 11g RAC添加节点错误
Oracle Study之--Oracle 11g RAC添加节点错误 系统环境: 操作系统:RedHat EL5 Cluster: Oracle 11gR2 Grid Or ...
- Oracle Study学习之--Flashback Archive
Oracle Study学习之--Flashback Archive CREATE FLASHBACK ARCHIVE Purpose Use the CREATE FLASHBACK ARCHIVE ...
- Oracle Study之--Oracle等待事件(3)
Oracle Study之--Oracle等待事件(3) Db file parallel read 这是一个很容易引起误导的等待事件,实际上这个等待事件和并行操作(比如并行查询,并行DML)没有关系 ...
- oracle顺序读等待,Oracle Study之--Oracle等待事件(4)
Oracle Study之--Oracle等待事件(4) Db file scattered read这个等待事件在实际生产库中经常可以看到,这是一个用户操作引起的等待事件,当用户发出每次I/O需要读 ...
- Oracle Study之--PL/SQL Developer软件错误
Oracle Study之--PL/SQL Developer软件错误 博文在51cto和CSDN同时开通 系统环境: 操作系统: Windows XP(64) 软件: PL/SQ ...
- linux安装oracle 操作系统内核参数 aio,Oracle Study之案例--安装Oracle内核参数配置
Oracle Study之案例--安装Oracle内核参数配置 在Linux系统下,安装Oracle之前,除了检查操作系统的硬件和软件是否满足安装需要之外,一个重点就是修改内核参数,其中最主要的是和内 ...
- Oracle Study之--Oracle 11g RAC设置归档路径错误案例
Oracle Study之--Oracle 11g RAC置归档路径错误案例 系统环境: 操作系统: RedHat EL55 集群: Oracle 11g GI Oracle: Oracl ...
- Oracle Study之案例--数据恢复神器Flashback(2)
Oracle Study之案例--数据恢复神器Flashback(2) 一.Flashback Table: 对于DML的误操作,可以通过Undo block对表进行回退(两种模式:基于时间和基于SC ...
- Oracle Study之--Oracle 11gR2通过RMAN克隆数据库
Oracle Study之--Oracle 11gR2通过RMAN克隆数据库 Purpose of Database Duplication A duplicate database is usefu ...
最新文章
- 三代组装软件canu学习笔记
- Java 数组长度和访问
- 【杂谈】工程能力差,C++水平菜?CUDA没写过?我推荐玩下Caffe
- HALCON示例程序classify_image_class_knn.hdev使用KNN分类器对多通道图像进行分割
- hacktoberfest_我第一次参加Hacktoberfest中学到了什么
- vuerouter传参方式_VUE Router学习原理(一)
- 选轻量应用服务器or云服务器ECS?一图帮你彻底区分
- JAVA语言中流程控制(顺序结构、判断语句、循环语句)
- 网站后端开发遇到的问题PHP,谁能帮我检查一下PHP网站后台开发这个问题是什么原因啊?...
- 噩耗!吴孟达去世,终年68岁!
- Apache Flink 1.9重磅发布!首次合并阿里内部版本Blink重要功能
- MFC 的几个常用函数,用来计算文件大小,下载速度,转换时间的
- rs485数据线接反_rs485接口怎么接线?弱电人必学RS485接口基础知识讲解
- java基础 --- 求一元二次方程的根(分情况讨论)
- (三) SiamRPN从论文角度介绍
- vue中pdf预览组件_pdf 在线预览之 vue-pdf插件
- c语言合法浮点数,c语言中什么是浮点数
- 一个面试我的后端妹子问的405错误
- STM32中断向量表的位置,重定向
- Indigenous students at U of T honoured for efforts in language revitalization, health equity
热门文章
- 【论文阅读】Deep Modular Co-Attention Networks for Visual Question Answering
- caffe 利用Python API做分类预测,以及特征的可视化
- 释放摄像头_防爆摄像头在使用过程中会遇到哪些问题,如何处理
- 两组树形数据的比对_Python数据分析-可视化“大佬”之Seaborn
- ejs 基础语法教程
- React 使用图片验证码组件(登录验证)
- HarmonyOS 组件篇
- ZZNU-oj-2141:2333--【O(N)求一个数字串能整除3的连续子串的个数,前缀和数组+对3取余组合数找规律】...
- java volatile关键字的理解
- Ns3 构建哑铃型拓扑,并实现两个点的TCP连接(详细请戳全文)