合理配置TimesTen内存数据库Hash索引的PAGES参数

        TimesTen内存数据库支持哈希、范围和位图三种类型的索引，其中哈希索引在等值查询中有着其他索引不能比的高效的优势，通常用于匹配单行或多行记录查询。

0. 哈希索引的创建语法：

1. CREATE [UNIQUE] HASH INDEX [Owner.]IndexName ON [Owner.]TableName ({ColumnName [ASC | DESC]} [,... ] ) [ PAGES = RowPages | CURRENT ] 

      在创建表时指定主键时都会使用索引来增强对数据的扫描，默认索引范围索引来增强主键查询，然而我们也可以使用唯一哈希来指定增强主键查询；如我我们在创建主键时使用哈希索引来增强主键查询，那么当应用在执行主键范围扫描时，哈希索引将会被忽略；哈希索引在等值查询单行或多行记录中有着范围索引不能比的高效的优势。

     哈希索引在创建时，会根据哈希索引创建时指定的PAGES参数自动分配固定数量的Buckets来存储表的索引信息，如果Buckets过少会降低索引散列度，索引散列度过低无论是在索引扫描、索引重建或回滚期间，均容易带来哈希冲突，从而带来性能影响；PAGES参数可以通过ALTER TABLE或者先DROP TABLE后CREATETABLE的方式修改。

     哈希索引的PAGES参数在哈希索引中如此重要，我们必须设置正确的PAGES参数来保证索引的高效使用；但是，由于应用及业务的增长，我们如何判断我们的PAGES参数配置是否正确呢？首先，我们需要知道，TimesTen在对数据的存储与Oracle不同，不是按照块来存储，而是按照页的方式进行存储，按照每个页256行记录的方式对数据进行存储，所以PAGES＝count/256；而Bucket的计算方式为Buckets=(PAGES*256)/20。

      但是，我们在实际运维中，经常会在tterrors中出现waiting for latch"Lock Hash Bucket[3918]"或者waiting for latch "Index OWNER.TABLENAME"的latch等待信息；其实还是由于PAGES参数设置不合理引起的，主要是对count的计算不准确造成的，由于系统运行一段时间后，达标一般都会存在一定的碎片（空行），所以count=NUM_USED_ROWS+NUM_FREE_ROWS，详细可以参考我们博文：
《 如何评估和计算TimesTen内存数据库表的大小》 http://blog.itpub.net/24930246/viewspace-1168811/

     那么PAGES参数是不是越大越好呢？当然不是了，PAGES参数过大，会导致Buckets过大，会占用更多的内存存储空间，内存对于内存数据库来说是一个非常重要的指标，内存过大直接影响内存数据库的装载/卸载、恢复等消耗的时长。

－－－－－－－－－－－－－－－End－－－－－－－－－－－－－－－－－－－－－－－－－

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24930246/viewspace-1416271/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24930246/viewspace-1416271/