You asked
"What's the point in creating two unique constraints changing only columns order in declaration?"
There isn't any point. The order of columns in a composite constraint doesn't make any difference:
SQL> select * from t23
2 /
COL1 COL
---------- ---
1 WTF
SQL> create index t23_i on t23(col1, col2);
Index created.
SQL> alter table t23 add constraint t23_uk unique (col1 , col2) using index t23_i
2 /
Table altered.
SQL> insert into t23 values (1, 'WTF')
2 /
insert into t23 values (1, 'WTF')
*
ERROR at line 1:
ORA-00001: unique constraint (APC.T23_UK) violated
SQL> alter table t23 drop constraint t23_uk
2 /
Table altered.
SQL> alter table t23 add constraint t23_uk unique (col2, col1) using index t23_i
2 /
Table altered.
SQL> insert into t23 values (1, 'WTF')
2 /
insert into t23 values (1, 'WTF')
*
ERROR at line 1:
ORA-00001: unique constraint (APC.T23_UK) violated
SQL>
That's the problem with exam-crammers: they often just say stuff, without providing explanation or context.
You also asked:
" Would it be a good idea to create second, single column index on invoice_date
?"
Without knowing the data it's hard to tell, but I would expect a date column to be less selective than an ID column (especially if the time element is truncated), so generally I would expect an index to built as (invoice_date, invoice_id)
anyway. That might allows us to use index compression.
Skip-scanning doesn't quite work as Steve states: it starts by probing the leading edge of the index, but only if the second column in the composite index is referenced in the WHERE clause. The optimizer might choose a Full Fast Index Scan for searching on third columns or lower. Also it won't choose a Skip Scan path if the leading edge has too many distinct values: another good reason for leading with columns of low selectively.
So, this doesn't exactly answer your question, but I think it does convey an important point: there are no universal rules governing creating indexes for performance. We need to understand the profile of the data - its values distribution and volumes - and also the most important queries which will use the table.