Best practices with sequences and primary keys

Question

We have a table of system logs that has a column called created_date. We also have a UI that displays these logs ordered by created_date. Sometimes, two rows have the exact same created_date down to the millisecond and are displayed in the UI in the wrong order. The suggestion was to order by primary key instead since the application uses an oracle sequence to insert records so the order of the primary key will be chronological. I felt this may be a bad idea as a best practice since the primary key should not be used to guarantee chronological order although in this particular application's case, since it is not a multi-threaded environment, it will work so we are proceeding with it.
The value for the created_date is NOT set at the database level (as sysdate) but rather by the application when it creates the object which is persisted by Hibernate. In a multi-threaded environment, thread A could create the object and then get blocked by thread B which is able to create the object and persist it with key N after which control returns to thread A it persists it with key N+1. In this scenario thread A has an earlier timestamp but a larger key so will be ordered before thread B which is in error.
I like to think of primary keys as solely something to be used for referential purposes at the database level rather than inferring application level meaning (like the larger the key the more recent the record etc.). What do you guys think? Am I being too rigorous in my views here? Or perhaps I am even mistaken in how I interpret this?

Answer 1

>
I think the chronological order of records should be using a timestamp (i.e. "order by created_date desc" etc.)
>
Not that old MYTH again! That has been busted so many times it's hard to believe anyone still wants to try to do that.
Times are in chronological order: t1 is earlier (SYSDATE-wise) than t2 which is earlier than t3, etc.
1. at time t1 session 1 does an insert of ONE record and provides SYSDATE in the INSERT statement (or using a trigger).
2. at time t3 session 2 does an insert of ONE record and provides SYSDATE
(which now has a value LATER than the value used by session 1) in the INSERT statement.
3. at time t5 session 2 COMMITs.
4. at time t7 session 1 COMMITs.
Tell us: which row was added FIRST?
If you extract data at time t4 you won't see ANY of those rows above since none were committed.
If you extract data at time t6 you will only see session 2 rows that were committed at time t5.
For example if you extract data at 2:01pm for the period 1pm thru 1:59pm and session 1 does an INSERT at 1:55pm but does not COMMIT until 2:05pm your extract will NOT include that data.
Even worse - your next extract wll pull data for 2pm thru 2:59pm and that extract will NOT include that data either since the SYSDATE value in the rows are 1:55pm.
The crux of the problem is that the SYSDATE value stored in the row is determined BEFORE the row is committed but the only values that can be queried are the ones that exist AFTER the row is committed.
About the best you, the user (i.e. not ORACLE the superuser), can do is to
1. create the table with ROWDEPENDENCIES
2. force delayed-block cleanout prior to selecting data
3. use ORA_ROWSCN to determine the order that rows were inserted or modified
As luck would have it there is a thread discussing just that in the Database - General forum here:
ORA_ROWSCN keeps increasing without any DML