You must define a primary index for any join index that is not column-partitioned (for a column-partitioned join index, a primary index is optional). The primary index of a join index must be defined as a NUPI, but the column on which the primary index is defined need not be nonunique. The preferences for defining a unique rather than a nonunique column set as the primary index for a base table also apply to join indexes.
Because join indexes are not part of the logical model for a database and are denormalized database objects, there may not be an overriding reason to define one column set over another as the primary index, apart from how much more evenly one set may distribute join index table rows than another.
Using the join key as the primary index for single-table join indexes is important, but otherwise there is no reason to select one unique (or highly singular) column set over another as the primary index.
If you create a join index to support a row-partitioned base table, consider creating it using row partitioning, unless the join index is row-compressed. You can also create a row-partitioned join index for a base table that does not have row partitioning. Such a join index may provide an alternative organization of the data that facilitates access based on partitions.
For example, suppose you have a nonpartitioned base table designed to handle efficient joins on its primary index. You may also want to create a row-partitioned join index on the table that optimizes fast row-partition-based access to the data. The rules for creating a row-partitioned join index are the same as those for creating a row-partitioned base table.
If a join index is designed to support range queries, consider specifying a row-partitioned primary index for it. You cannot specify a row-partitioned primary index for a row-compressed join index.
Join index primary indexes are defined analogously to base table primary indexes: with the CREATE JOIN INDEX statement.