AnySQL.net

对Hash Cluster表的一些进一步测试之二

    今天早上用真实的数据进行了第二次测试, 一是验证我这种定义SIZE和HASHKEYS参数的方法有没有问题, 另外一个是难证Oracle自带的Hash函数是否高效. 为此我选取了1000万条真实的记录, 表的大小大约是1.5个G, 我将Cluster的HASHKEYS * SIZE设成2G左右, 语句如下: CREATE CLUSTER C_USER_HOST_ID_LOOKUP (USER_ID NUMBER(38,0))     SIZE 8192 SINGLE TABLE HASHKEYS 262144;     用sqlldr装载这些数据却用了1个小时, 这是因为你不能用Direct方式, 而且每条记录是随机存放的, 而不是连续存放的, 所以比较慢. 装载完成后, 用如下脚本进行验证. 其中的SELECT语句可是要执行大约1000万次的. DECLARE    TEMP VARCHAR2(64); BEGIN    FOR REC...

Posted on April 28, 2007 1:18 PM

对Hash Cluster表的一些进一步测试之一

    在前面的例子中, 我们都只是做了一些小批量数据, 如果我的Hash Cluster表有几个GB或几十个GB的大小时, 又怎么样呢? 下面进行的是我在笔记本上的测试, 用于测试的表的大小是100MB, 进行测试时的数据是50万条. 测试的目的是为了要证明Hash Cluster是否可能用于大数据量的表中, 即验证Oracle内建的Hash函数是否是高效的. 创建Hash Cluster的句语是: CREATE CLUSTER C_T_OBJECTS (OBJECT_ID NUMBER(38,0)) SIZE 8192 SINGLE TABLE HASHKEYS 12800;         在100MB的DB_CACHE_SIZE下进行测试: 21:48:10 SQL> SELECT HASH_VALUE, BUFFER_GETS, EXECUTIONS 21:48:54   2  FROM V$SQL WHERE HASH_VALUE=3523526785;...

Posted on April 27, 2007 11:19 PM

Oracle应当增加一种基于Hash算法的索引

    Hash是非常高效的一种查找算法, Oracle中的Hash Join更是声名远播, 还有Hash Cluster表, 可以获得很好的性能. 现在的B*Tree结构的索引, 虽然很好, 但在很繁忙的系统中, 还是有一些不足, 比较典型的是在索引的根结点上, 发生Split时很容易引起数据库的问题. 另外从Root块到Branch块, 再到Leaf块, 最后到获得表的记录, 需要访问比较多的结点.     既然Hash算法能用于表, 那么也能用于索引. 因为索引从另外一个角度来说, 也象一个表, 象一个包括了索引列加上ROWID组成的表. 通过这种Hash类型的索引, 第一个可以将读一条记录的Gets减少到2, 同时也没有了Root块和Branch块的Split问题, 实在是值得考虑的一种新的索引类型.     其实通过Context接口, 已经可以很容易地实现这样的功能, 谁有写过自定义的Context索引类型?     在Oracle中Hash Cluster不一定要求字段是数字类型的, 因此支持Hash Index并不需要改动很多吧?...

Posted on April 27, 2007 1:56 PM

如何创建Single Hash Cluster的表?

    Hash Cluster的表可以在没有索引的情况下, 获得对表的极快访问, 这种访问的逻辑读比维一性索引还有效. 在这儿有一张表T_OBJECTS, 其中的OBJECT_ID是主键, 大量的SQL语句都是根据OBJECT_ID去访问其他字段, 通过索引的情况下每次执行的逻辑读已经只有3了(Index Root->Leaf->Table), 但是就是这样一句简单的SQL的逻辑读占据了大半. 因此考虑到使用Single Hash Cluster表来进行调优. 应当如何来创建这个Cluster呢? 决定Cluster性能的主要有两个因素: SIZE和HASHKEYS.     下面是我的思路, 首先分析一下现在的表, 获得比较准确的块数. SQL> SELECT BLOCKS FROM USER_TABLES WHERE TABLE_NAME='T_OBJECTS';     BLOCKS ----------        118     因为在这个情况下, 数据分布均匀, 因此我只要将HASHKEYS定义为块数就已经比较好了, 实际上为了更安全,...

Posted on April 24, 2007 10:36 PM

如何在较长的文本字段上建立有效的索引?

    索引的键值太大的话会影响索引的效率, 还有可能出错. 但有时我们一定要为这字段建索引的话怎么办呢? 我们可以通过计算一个哈希值来实现. 比如有一个字段为NAME, 最长可能有1024个字符, 要在这个列上建一个索引的话, 可以有两种比较好的方法: 增加一个字段, 如HASH_NAME, 用于保存HASH值. 建一个函数索引.     第一种方法需要有一个建在Insert或Update上的触发器来更新HASH_NAME字段, 第二种方法相对简单, 在Oracle的高版本中, 可以用第二种方法. 需要注意的是, 理论上Oracle的这个计算哈希值的算法并不能保证唯一, 因此在查询时需要注意, 需要写两个条件, 如下所示: HASH_NAME = DBMS_UTILITY.GET_HASH_VALUE(:P_NAME) AND NAME=:P_NAME DBMS_UTILITY.GET_HASH_VALUE(NAME) = DBMS_UTILITY.GET_HASH_VALUE(:P_NAME) AND NAME = :P_NAME     另外在数据库升级中,...

Posted on September 13, 2006 11:17 PM