RE: HDR and Indexes

Hi, Madison, What specific issue are you talking about? Slow index replication during the initial index creation, when Primary can't do transactions while it is replicating index to Secondary? My understanding is that the slowness of index replication is mostly due to the fact, that Secondary is trying to read each page from disk before writing it. Frankly speaking, I don't understand, why it's impossible to simply dump all the replicated index pages (during the initial index creation) directly to disk without reading them. This should dramatically increase the index replication speed. Actually, the fact, that Primary stops updates during index replication, causes serious problems for us: we need to stop the entire 24x7 system, when we need to build an index on a really big table. We had a problem of building big indexes in HDR environment, when 75% of physical log fullness was triggering a checkpoint on Secondary, and this checkpoint was infinite and was causing the entire system to hang.. This problem was fixed long time ago, smth like 9.40uc6. Also, there is still a problem of lock timeout, when few indexes must be build on a table from a single script. The problem is caused by table lock, placed on a table for the duration of index replication. This problem has a simple workaround: SET LOCK MODE TO 3600 (or smth really big). -Alexey > -----Original Message----- > From: informix-list-bounces@iiug.org [mailto:informix-list-bounces@iiug.org] > On Behalf Of Madison Pruet > Sent: Thursday, June 29, 2006 2:00 PM > To: informix-list@iiug.org > Subject: HDR and Indexes > > Most of the folks using HDR know about the create index issue. Can I > have honest reaction on this issue? > > Thx > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list

Alexey Sonkin wrote: > Slow index replication during the initial index creation, > when Primary can't do transactions while it is replicating index > to Secondary? If it is this issue then I would say that its impact is moderate for us. We only build indices we need to support changes in software so we can take a modest amount of downtime (~5 mins) when we do this. When creating multiple indices on the same table it slows us down. We generally try and avoid creating new indices on our largest tables because even with "create index online" the impact on the system is too great and if we had to do this it would be when introducing a new server and new fragmentation strategy. Ben.