To avoid having to re-baseline replication and the target database(s), further consideration are needed when adding
inactive indexes to a replication enabled database environment.
1. When IDXBUILD is used to activate an index After-Imaging is disabled which replication relies on and therefore necessitates rebaselining replication.
2. When an offline IDXFIX is used to enable inactive indexes, while AI remains enabled, Replication will first have to be disabled in order for IDXFIX to run offline and therefore necessitates rebaselining replication.
3. To not have to rebaseline replication use IDXACTIVATE:
- The primary index will be used by default as the index to mimic when building other indices. If the primary index is not active then then the "useindex" parameter must be specified with an index name other than the primary . The value provided after the useindex parameter should only be the index name, not the table-name.index-name pairing.
- A condition of dropping a table, necessitates that Tables without an active primary index cannot be deleted, (for the same reason, neither can they be re-named). For example, the schema update cannot be reverted by deleting the inactive index(es) or new table with inactive index(es)
- A condition of adding another index as the primary index, necessitates that the primary index must be active.
- Consider adding a "small" active primary index initially which can be used to build the inactive indexes later with IDXACTIVATE. Once the inactive indexes have been built, the true primary index can be enabled through the Data Dictionary. Refer to Article How to activate a Primary Index