Composite Primary key & Primary key questions

Question

Background:
1.5 TB data warehouse. All tables use at least a 3 column composite Primary key. Most use 3. col1||col2||col3 to achieve uniqueness.
col1= very low cardinality. 99% of the values are '0'
col2 = high cardinality. (SSN's, loaded monthly)
col3 = low cardinality. (monthly sequence number used for partitioning)
From what I've read, the first column used in a composite primary key also receives its own index. If that is correct, then the primary key being used is losing its effectiveness by putting a very low cardinality column as the first column of the Primary key. By moving col2 to the first position of the composite key, I would be obtaining an index on SSN which would be much more useful. (Please correct me if I'm wrong) Or since the index would be so large anyway, the CBO would just do full table scans which is what I'm trying to get away from.
This Primary key is used to ensure uniqueness during loads. Other than that, it really has no purpose and is never queried by the user. (WHERE col1||col2||col3 = xxxxxxxxx)
As a DBA, I see this massive tablespace for holding the primary keys now reaching in excess of 157 GB and it seems like such a waste of space. The problem I'm running across is how to ensure uniqueness during the loads w/o having to store the unique values. (the 157 GB) If I drop the PK's, then create unique indexes just for the loads, then the unique index would be generated against the entire table, which would take forever.
If you create a local index (what I want in the end) it still has to create the index for all previous partitions (250+ partitions). You can't create a specific 'local' index on a partition. You create a local index on the table and when a new partition is added, the index is then added as well. That's what I want to do with some of my fields like SSN but for loading purposes, this isn't going to help me.
I need a way to ensure uniqueness during a monthly load of a new partition (col1||col2||col3) but w/o having to store these values for eternity. Right now it's the primary key, so it has to be stored. I hope I'm making sense here. Any ideas?

Answer 1

I think you need some clarification about the index supporting the primary key.
The primary key is unique - the database will enforce this for you.
All of the columns in the primary key are in the index that enforces the key (not just the first column).
Usually this index is a unique index, but you can have a non-unique index supporting a primary key.
I'm a little confused with some of your other statements
how to ensure uniqueness during the loads w/o having to store the unique valuesIf you don't store the value how do you know it is unique?
Did you mean that you don't want to store the key values in both the table and the index?
You may want to consider making col3 (the partition key) the leading column of the index, so you can create a local (instead of global) PK index.
I wouldn't worry too much about col1 (the column full of mostly zeros) - numbers are stored variable length. A NUMBER(38) that holds a zero takes no more space than a NUMBER(1) that holds a zero.