impact of nullable columns in unique indexes under CBO?

We have a vendor application that has virtually all columns in all tables defined to allow nulls, has no primary key definitions but does have unique indexes on the logical primary keys.

My question is this...does the fact that the columns in the unique index are defined as null have any impact on how the CBO evals the cost of accessing these tables?

We see simple two table joins on relatively large tables 250k+ rows doing table scans when the columns from unique indexes are in the where clause. For example,

SELECT	/*+ FIRST_ROWS */   AB_TRAN.*
FROM	AB_TRAN,
	QUERY_RESULT
WHERE	QUERY_RESULT.unique_id 	= 1654
  AND	AB_TRAN.tran_num	= QUERY_RESULT.QUERY_RESULT;

yields the following execution plan with newly rebuilt indexes and brand new table and index statistics

SELECT STATEMENT Optimizer=HINT: FIRST_ROWS (Cost=1138 Card=10216724 Bytes=2400930140)
  NESTED LOOPS (Cost=1138 Card=10216724 Bytes=2400930140)     TABLE ACCESS (FULL) OF AB_TRAN (Cost=1137 Card=238597 Bytes=52014146)

    INDEX (UNIQUE SCAN) OF QUERY_RESULT_INDEX (UNIQUE) Given that QUERY_RESULT.unique_id is the high order piece of the unique key on QUERY_RESULT and QUERY_RESULT.QUERY_RESULT is the next piece and it is joined to AB_TRAN.tran_num which is the unique key on that table I would have expected it to use the index on each of the respective tables.

We are getting terrible performance out of CBO on all kinds of queries so I started wondering about the impact of all the NULLABLE columns. This is 8.1.7.4 Received on Thu Aug 29 2002 - 17:35:48 CEST