How Online Index Operations Work:
Temporary mapping index
Online index operations that create, drop, or rebuild a clustered
index also require a temporary mapping index. This temporary index is
used by concurrent transactions to determine which records to delete
in the new indexes that are being built when rows in the underlying
table are updated or deleted. This nonclustered index is created in
the same step as the new clustered index (or heap) and does not
require a separate sort operation. Concurrent transactions also
maintain the temporary mapping index in all their insert, update, and
delete operations.
Disk Space Requirements for Index DDL Operations
If a clustered index is created, rebuilt, or dropped online, a
temporary nonclustered index is created to map old bookmarks to new
bookmarks. If the SORT_IN_TEMPDB option is set to ON, this temporary
index is created in tempdb. If SORT_IN_TEMPDB is set to OFF, the same
filegroup or partition scheme as the target index is used. (My note: default is OFF)
Index ID 254 is indeed the mapping index. The Online Indexing Operations in SQL Server 2005 whitepaper has more details.
If I understand you correctly you have two tables (for this question):
CREATE TABLE Clients
(Client int, ClientName varchar(50), Lots Of Other Columns)
and
CREATE TABLE Payments
(PaymentID, Payment Columns, ClientID)
Obviously not actual code there to create your tables...
And your application is somehow joining those tables behind the scenes. Probably on the ClientID. So your user runs a filter on "Acme Company" and behind the scenes SQL Server is doing a JOIN statement.
Again - pseudocode
SELECT TheDataIWantFromPayments, TheCustomerDataIWant
FROM Payments
INNER JOIN Customers
ON Payments.ClientID = Customers.CliendID
WHERE Customer.ClientName = 'Acme Company'
So here is where having more information can really help. On first blush this could be a problem with a simple index create as a solution. Perhaps there is no index on the clientID in each table. Perhaps there is no index on the ClientName.
But there could be other factors at play, too. It is possible that the vendor issues this query as a contains search using the syntax of CompanyName LIKE '%Acme Company%'
and then no index on CompanyName would help. It could be that the database design requires a lot of key lookups and an index isn't the solution.
Either way - 6 minutes for 15 rows is not acceptable. I would look at those tables and at least verify that the CompanyName and ClientID (or whatever the columns are that contain those values) are indexed on each side.
I would also strike up a conversation with the vendor. Even just you adding indexes could be an action that violates your support contract. Perhaps there are considerations that they already have. And you shouldn't have to be working through someone else's bad design or poorly performing application.
You can gather some data to help you. Play with the PAL tool and look at your performance data on your system. If you have a development/test environment and you can recreate this, perhaps through playing with Extended Events or SQL Trace you can see the query that issued and then run the query showing a query plan to get a sense for what is happening. But I would definitely loop the vendor in to a question like this.
Best Answer
It is not completely clear what your after with your question. I assume you want to know if and importantly when an
alter index .. coalesce
was performed.I think without (an in other answers already mentioned auditing setup) it is impossible to get such a date (although I would want to know if someone knows better).
That said, the effects of an
alter index coalesce
can be made visible with aanalyze index .. compute statistics
.Now that the table is filled, the index is analyzed and some index related values extracted:
All but one row deleted and index analyzed (again):
The query above returns the same values.
Coalescing the index:
The query above now returns
So, there is a possibility to find out if there was a coalescing done, but it's not straight forward and probably useless, depending on your context.