类型2索引导致性能下降 [英] type-2 index causing performance hit

问题描述

我们正在使用DB2 UDB版本8.1 fp7& AIX 5.2上的fp9。

在我们的数据库中，我们进行大量的插入和删除（数百万行）。

由于伪删除键，性能大大降低。

在10分钟内，它从每分钟18000交易变为9000并且

更低。

当执行带有CLEANUP ONLY PAGES的索引重组时，数字

交易再次攀升。但几分钟后它再次下降到
9000.

我们必须不断运行reorg以保持稳定的速度。


我正在考虑在所有索引上使用minpctused选项。

但是当主键等约束使用
时如何指定？

我们可以使用其他选项来保持稳定的表现。

解决方案

< be ***** *********@gmail.com>在消息中写道

news：11 ********************* @ g14g2000cwa.googlegro ups.com ...

我们正在使用DB2 UDB版本8.1 fp7& AIX 5.2上的fp9。
在我们的数据库中，我们进行大量的插入和删除（数百万行）。
由于伪删除密钥，性能大大降低。
它在10分钟内从每分钟18000交易到9000并且
更低。
当执行带有CLEANUP ONLY PAGES的索引重组时，
交易的数量再次攀升。但是几分钟后它再次下降到了9000.
我们必须不断地运行reorg以保持稳定的速度。

我正在考虑使用minpctused选项在所有索引上。
但是当你使用主键等约束时如何指定呢？
我们可以使用其他选项来保持稳定的性能。

在创建PK之前创建一个具有所需属性的唯一索引

（使用alter table创建PK）。


I怀疑minpctused使用会有所帮助。实际上它可能会变得更糟，因为

它会尝试在你插入时重新编辑索引页面并且

删除。


我建议为索引使用高百分比免费值（25-30％）。

其他选项包括使用加载命令。

< blockquote>感谢您的提示和建议。

我会尝试高百分比的免费价值，但负载是不可能的。

应用程序（不是我们的）只是按照这种方式工作。

我希望其中一个选项可以工作，因为我必须说DB2不是

为我们正在做的高交易量构建，这将非常悲伤。

我读到了类型2索引的好处，但似乎有一个

大的缺点是因为它降低了索引的效率大时间在我们的情况下。

<是************** @ gmail.com>在消息中写道

news：11 ********************** @ o13g2000cwo.googlegr oups.com ...

感谢您提示和建议。
我会尝试高百分比的免费价值，但负载是不可能的。
应用程序（不是我们的）只是这样工作。
我希望其中一个选项可以工作，因为我必须说DB2不是为我们正在做的高交易量而构建的会非常伤心。
我读到了类型2索引带来的好处，但似乎有一个很大的缺点，因为它会降低索引的效率。 >我们的情况。

DB2在具有高交易量的基准测试中表现非常出色，因此为这些工作负载构建了

。实际上，DB2在TPC-C基准测试中保持了最高tpmC

的记录。
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp

We are using DB2 UDB version 8.1 fp7 & fp9 on AIX 5.2.
On our databases we do massive inserts and deletes (millions of rows).
The performance is dramatically reduced because of pseudo deleted keys.
In a 10 minutes it goes from 18000 transaction per minute to 9000 and
lower.
When an index reorg with CLEANUP ONLY PAGES is executed, the number of
transactions climbs again. But a few minutes later it drops again to
9000.
We have to run the reorg constantly to keep a steady speed.

I''m thinking of using the option minpctused on all indexes.
But how do you specify this when constraints like primary keys are
used?
Are there other options we can use to keep a steady performance.

解决方案

<be**************@gmail.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...

We are using DB2 UDB version 8.1 fp7 & fp9 on AIX 5.2.
On our databases we do massive inserts and deletes (millions of rows).
The performance is dramatically reduced because of pseudo deleted keys.
In a 10 minutes it goes from 18000 transaction per minute to 9000 and
lower.
When an index reorg with CLEANUP ONLY PAGES is executed, the number of
transactions climbs again. But a few minutes later it drops again to
9000.
We have to run the reorg constantly to keep a steady speed.

I''m thinking of using the option minpctused on all indexes.
But how do you specify this when constraints like primary keys are
used?
Are there other options we can use to keep a steady performance.

Create an unique index with the attributes you want prior to creating the PK
(create the PK with an alter table).

I doubt that minpctused used will help. In fact it may make it worse since
it will attempt to reorg the index pages online while your are inserting and
deleting.

I would suggest using a high percent free value (25-30%) for the indexes.
Other options include using the load command.

Thanks for the tip and suggestions.
I''ll try the high percent free value, but the load is not possible. The
application (not ours) just works this way.
I hope one of the options will work, cause else I must say DB2 is not
build for high transaction volumes we are doing and that would be very
sad.
I read about the benefits from type-2 indexes, but there seems to be a
big drawback because it reduce the efficiency of the index big time in
our situation.

<be**************@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

Thanks for the tip and suggestions.
I''ll try the high percent free value, but the load is not possible. The
application (not ours) just works this way.
I hope one of the options will work, cause else I must say DB2 is not
build for high transaction volumes we are doing and that would be very
sad.
I read about the benefits from type-2 indexes, but there seems to be a
big drawback because it reduce the efficiency of the index big time in
our situation.

DB2 has done very well in benchmarks with high transaction volumes, so it is
built for such workloads. In fact, DB2 holds the record for the highest tpmC
in the TPC-C benchmark.
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp

这篇关于类型2索引导致性能下降的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！