I am reposting this from another forum.
In this article http://msdn.microsoft.com/en-us/library/ms184246(v=SQL.100).aspx, it is stated that "The index transactions will be stored in the tempdb transaction log, and the concurrent user transactions will be stored in the transaction log of the user database. This allows for the transaction log of the user database to be truncated during the index operation if it is required."
However, this doesn't seem to be the case for me.
I am running Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (X64) on a Windows Server 2008 x64 EE server in FULL recovery mode with all user databases set to 100 for their compatibility mode. The server has 48GB of ram. I have a nightly job that runs ALTER INDEX REBUILD or ALTER INDEX REORGANIZE for each index in a user database. The SP called by the job determines if the table has any underlying LOB datatypes and if so will not attempt an online rebuild, it also determines whether to rebuild or reorganize based off the fragmentation percentage of the index and does not use explicit transactions. There are almost no concurrent user transactions running when I run the index rebuild job. Each night, the user database log blows up during the index rebuild job (or it would if I didn't have a job in place that checked the amount of used space in the log and cancelled the index rebuild/reorganize job if it gets too full, then fires a transaction log backup.)
To test whether it had something to do with the stored procedure or not, I simply backed up the transaction log to clear the log space, ensured the log space was near to 0 using dbcc sqlperf('logspace'), picked one of our very large indexes, which is about 40GB in size and ran a manual rebuild on it:
USE TESTDB;
GO
ALTER INDEX [IX_NAME] on [tbl_TABLENAME] REBUILD WITH ( STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = ON, ONLINE = on, maxdop = 4)
GO
(IX_NAME is just a generic index name and tbl_TABLENAME is a generic table name, both generalized for posting this on a public forum.)
The transaction log in the user database blows up in a matter of minutes and the tempdb log barely grows when I run the manual rebuild.
Is the statement from Microsoft wrong, or am I missing something? When I posted this on another forum, the response was that regardless of where the data is sorted, the transactions must be fully logged in the user database and not in tempdb in order to allow the engine to rollback the changes should transaction need to be rolled back. This makes the most sense in what I am seeing, and it would seem that the statement from Microsoft is wrong.
Charles Evans