Oracle Best Practices for generating Transactions IDs in high OLTP systems

Question

We are in the process of designing a high OLTP system using Oracle 11g Database with the following NFRs:
1) 1 million transactions per day
2) 100,000 concurrent users
There are close to about 160-180 entities in the database and we want to know the best approach/practice in deriving the transaction IDs for the OLTP system. Our preferences are given below:
1) Use Oracle Sequence starting with 1,000,000,000 (1 billion) - This is to make the TXN ID look meaningful when it starts with 1 billion instead of starting it with 1.
2) Use timestamp and cast it to number instead of using Oracle sequence.
Note: Transaction IDs must appear in sequence as they are inserted - be it sequence/timestamp
I would like to know pros/cons of the above methods and their impacts on performance. Also, appreciate if you could share any any best practices/methods that Oracle supports.
Thanks in advance.
Ken R

Answer 1

Ken R wrote:
I did a quick PoC using both Oracle Sequence & Timestamp for 1 million inserts in a Non-RAC environment. Code used is given below:
create sequence testseq start with 1 cache 10000 order;
create table test1 (txnid number, txndate timestamp(9));
create table test2 (txnid number, txndate timestamp(9));
begin
for i in 1..1000000
loop
insert into test1 values(testseq.nextval,systimestamp(9));
end loop;
commit;
end;
begin
for i in 1..1000000
loop
insert into test2 values(to_number(to_char(systimestamp(9),'yyyymmddhh24missff9')), systimestamp(9));
end loop;
commit;
end;
Here are the results:
select max(txndate)-min(txndate) from test1;
Result >> 0 0:3:3.514891000
select max(txndate)-min(txndate) from test2;
Result >> 0 0:1:32.386923000
It appears that Timestamp is faster than sequence... Any thought is highly appreciated...Interesting that your sequence timing is so slow. You say this was a non-RAC environment, but I wonder if you had Oracle linked in RAC mode even though you were running single instance - this would result in the ORDERed sequence running through RAC's "DFS Lock Handle" mechanism which might account for the timing anomaly.
Unfortunately your test is not particularly relevant. As DomBrooks points out there are lots of problems with sequence-based or time-based columns, especially in RAC, and most particularly if you think you want a "no-gap" sequence. On top of this, of course, your test doesn't include an index on the relevant column, and it's single user and doesn't test for any concurrency effects.
Typical performance problems are: your RAC instances spend all their time negotiating who gets to use the next value; the index you use to enforce uniqueness suffers from massive contention on the "high-value" block unless you create a reverse-key index - at which point you have to be able to cache the entire index to minimise I/O overheads; you can hash partition the index to avoid using the reverse-key option - but that costs a lot of money if you don't already license the partitioning option.
Regards
Jonathan Lewis