The*_*war 2 index sql-server azure-sql-database transaction-log
将生成多少日志索引重建。我记得读取重建索引应该生成与表大小相同数量的日志文件。但我的测试显示并非如此。我们需要这个估计,因为我们正在尝试构建 azure 数据库索引,它有一个限制最大 2 GB。
我的数据库处于完全恢复模式。
桌子尺寸:

日志大小:

从图片中您可以看到在线索引重建操作的日志生成量非常少。如果我遗漏了什么,有人可以纠正我吗
如果您正在重建聚集索引,您实际上是在重建表,但非聚集索引只是表的一个子集(通常)。如果您使用 SORT_IN_TEMPDB 选项,您会将一些日志记录卸载到tempdb 事务日志。版本还将此事,于2005年在网上重建是最低限度记录,但被改回至2008年的完整记录您可能也想看看这篇文章,这可能是在决定是否要重建或重新组织在头脑里的日志大小有用.
- - 更新 - -
使用 Shanky 的测试设置,我执行了相同的步骤,但我添加了一些额外的尺寸检查。在重建之前,我执行日志备份并检查日志空间和利用率以及事务日志中索引的记录。然后我进行重建测试并重新检查日志大小和日志记录数:
backup log IndexLogging to disk = 'NUL'
--check log space/usage
dbcc sqlperf (logspace)
--check log records for the index, exclude the where for the total number of logs generated
SELECT LogRecordsGenerated = COUNT(*)
FROM sys.fn_dblog(NULL, NULL)
WHERE AllocUnitName = 'dbo.Logging.IX_LOGGING'
--Perform your rebuild operation and then recheck the same parameters
Run Code Online (Sandbox Code Playgroud)
I tried this about a dozen times and each time I get the same results, the DMV is only telling you for the transaction, but there are several nested transactions that are spawned as a result of the log_test transaction that don't show up including the allocation of extents and pages and the insertion of the data. If you look at the actual contents of the log file, you can see how the offline rebuild is very efficient. It just allocates the pages/extents, formats them and sets them and then deallocates the old ones. An online rebuild is doing a lot more work since it has to keep the index available while it rebuilds. This is probably more evident in the locking: offline it locks the entire object but online it has to go page by page, key by key. You can take a look for yourself to compare:
SELECT
OPERATION,
Context,
[Transaction Name],
[AllocUnitName],
[AllocUnitId],
[Page ID],
Description,
[Lock Information], [Transaction ID]
FROM FN_DBLOG(NULL,NULL)
Run Code Online (Sandbox Code Playgroud)
You can reduce the log generated by temporarily switching to BULK_LOGGED while your index maintenance runs, but you lose the ability to do point in time recovery for that period of time. Apparently it also does not reduce your log backup.
--More info on log usage from DBCC SQLPERF (logspace) and SELECT LogRecordsGenerated = COUNT(*) FROM sys.fn_dblog(NULL, NULL) WHERE AllocUnitName = 'dbo.Logging.IX_LOGGING' to show actual log sizes, note the index is only 648KB
This is the log after populating it with data:
Database Name Log Size (MB) Log Space Used (%) Status
IndexLogging 14.99219 70.89956 0
LogRecordsGenerated
10903
Here is the log after a log backup:
Database Name Log Size (MB) Log Space Used (%) Status
IndexLogging 14.99219 5.100313 0
LogRecordsGenerated
0
Log after log backup and then Online rebuild:
Database Name Log Size (MB) Log Space Used (%) Status
IndexLogging 14.99219 22.642 0
LogRecordsGenerated
11160
Log after log backup and then offline rebuild:
Database Name Log Size (MB) Log Space Used (%) Status
IndexLogging 14.99219 10.79338 0
LogRecordsGenerated
140
| 归档时间: |
|
| 查看次数: |
2009 次 |
| 最近记录: |