Taken from the MSDN article on FOREIGN KEY Constraints
A FOREIGN KEY constraint does not have to be linked only to a PRIMARY
KEY constraint in another table; it can also be defined to reference
the columns of a UNIQUE constraint in another table.
I think it is perfectly fine to define a UNIQUE CLUSTERED INDEX
on an IDENTITY
column and define the PRIMARY KEY
on different columns, often with a NONCLUSTERED INDEX
but you don't have to specify an index.
Are there any reasons for periodic/cyclic slow-down of insert performance?
Yes. check point events. With a write intensive workload, big RAM server, as you describe, a large number of 'dirty' pages accumulate in memory. At the predetermined checkpoint interval all these dirty pages get written to disk, causing a spike of IO requests. This in turn slows down the log commit writes, which manifests as the increase in INSERT response time you observe periodically. QED. This is, of course, just a guess, in lack of a proper investigation. For a more certain response, I recommend you read How to analyse SQL Server performance and apply the techniques described there to identify the problem.
If the problem is indeed caused by checkpoint, then SQL Server 2012 comes with Indirect Checkpoints:
Indirect checkpoints, new in SQL Server 2012, provide a configurable database-level alternative to automatic checkpoints. ... Indirect checkpoints reduce checkpoint-related I/O spiking by continually writing dirty pages to disk in the background.
For a more detailed discussion about chekcpoint impact on performance read
SQL Q&A: Fine Tuning for Optimal Performance:
In Search of Spikes
Q. I’m troubleshooting an issue where we see periodic I/O spikes from one of our SQL Servers. I’ve narrowed it down to checkpoints using PerfMon, but I can’t tell which database is the major culprit. How can I drill in further?
Pre-SQL Server 2012 you have the option to reduce the recovery interval value. This will increase the frequency of checkpoints, but will reduce the number of dirty pages each checkpoint has to write. Spreading out the data IO helps (buy more spindles). Separating the log IO to it's own path (own spindle) does not help the checkpoint, but isolates the log commits from the effects and thus keep the INSERT responsive. SSDs work miracles.
I would advice against any structural changes. In my opinion you already have the best clustered index for time series. Any structural change would have to be backed by root-cause- performance analysis pointing to the current structure as a problem.
Best Answer
Yes there is.
It is called "index organized table" (IOT) - which in my opinion is the better name as it makes it absolutely clear that the index and the table are the same physical thing (which is the reason why we can have only one clustered index in SQL Server)
There is no such thing as
create clustered index
in Oracle.To create an index organized table, you use the
create table
statement with theorganization index
option.In Oracle you usually use IOTs for very narrow tables. Very often for tables that only consist of the primary key columns (e.g. m:n mapping tables), e.g.
You can create IOTs with more column, in that case the you need to define the non-pk columns as "included" columns. E.g. if the assignment table should have additional columns, like start and end date that are not part of the primary key:
See the manual for more details and examples: https://docs.oracle.com/database/121/SQLRF/statements_7002.htm#i2153235
Somewhat unrelated, but maybe interesting anyway:
An interesting blog post that questions SQL Server's (and MySQL's) behaviour of using a clustered index as the default when creating a table:
Unreasonable Defaults: Primary Key as Clustering Key
Coming from an Oracle background I wholeheartedly agree with that.