I'm using "SQL*Plus: Release 10.2.0.1.0 - Production"
Which tells us nothing about your Oracle Server version unfortunately! The bit below ("Connected to...") is about the server side
select foo_id from foo;
The clustered index does not contain a pointer to each row of the table - instead it contains pointers to clusters (groups of rows with the same foo_id
). It could in theory be useful for a query like select distinct foo_id from foo;
(no idea if it actually would though), but you still need to go to the underlying table to answer select foo_id from foo;
.
So why doesn't my hint work
Because it is just a hint - the CBO is clever enough to ignore it if it means full scanning the clustered index and the table instead of just the table
Also the correct hint for a clustered scan is cluster
rather than index
eg /*+ CLUSTER(foo) */
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
You have to rebuild it to access the base table.
Provided that your default trace has not rolled over, you can trace who disabled the index from default trace.
For a more robust solution, you need to create a server level trigger as described by Aaron in his blog post.
Index has a maintenance cost to it. I would highly recommend to use sp_BlitzIndex (from Brent Ozar's team) to have a better view of your current index portfolio.