SQL Server Express的维护建议

我们运行我们的应用程序的云版本，它使用SQL Server 2012 Express作为数据库引擎。每个客户端都有自己的SQL Server实例，允许他们的实例使用由Express限制的全部1GB内存，并为他们提供10GB的数据库大小。SQL Server Express的维护建议

我们面临的挑战是保持这些数据库的优化，同时允许为客户端提供最大的数据存储并且不会中断。换句话说，我们试图给他们几乎所有10GB的Express数据库作为他们的实际数据，但是我们需要运行维护来保持性能优化，并且它增长了数据库，有时这么大以至于维护失败。

每个星期天晚上我们运行一个SQL维护脚本，如下所示。

BEGIN; 
    FETCH NEXT FROM partitions INTO @objectid, @indexid, @partitionnum, @frag; 

    IF @@FETCH_STATUS < 0 
     BREAK; 

    SELECT @objectname = o.name, @schemaname = QUOTENAME(s.name) 
    FROM sys.objects AS o 
    JOIN sys.schemas as s ON s.schema_id = o.schema_id 
    WHERE o.object_id = @objectid; 

    SELECT @indexname = QUOTENAME(name) 
    FROM sys.indexes 
    WHERE object_id = @objectid AND index_id = @indexid; 

    SELECT @partitioncount = count (*) 
    FROM sys.partitions 
    WHERE object_id = @objectid AND index_id = @indexid; 

    -- 30 is an arbitrary decision point at which to switch between reorganizing and rebuilding. 
    IF @frag < 30.0 
     SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REORGANIZE'; 

    IF @frag >= 30.0 
     SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON, STATISTICS_NORECOMPUTE = OFF);' 

    IF @partitioncount > 1 
     SET @command = @command + N' PARTITION=' + CAST(@partitionnum AS nvarchar(10)); 

    EXEC (@command); 

    PRINT 'Executed: ' + @command; 

    SET @COMMAND = 'USE DATA UPDATE STATISTICS Data.dbo.' [email protected] + ';' 
    EXEC (@COMMAND) 

    PRINT 'Executed: ' + @command; 
    PRINT @objectname + 'Index Name: ' + @IndexName + 'Percent Fragmented: ' + CAST(@Frag AS VARCHAR(20)) 
END;

维护工作正常，如果有可用空间，问题是，它膨胀的数据库，并推动客户高达10GB的极限。这会导致问题，因为它们可能无法为需要添加值的表分配空间。然后，我们必须回去尝试缩小数据库，这从我的理解中，然后取消了索引碎片整理/维护的一些好处。

鉴于10GB限制上的数据文件，并需要运行维护，以保持数据库的充分运行，有什么能/应该怎样做才能得到维护方面的优势，而不必事后收缩数据库？

我们使用简单恢复模式，没有自动收缩，自动增长和10％的

预先感谢您！

来源

2016-12-05 Shaun

不要做收缩数据库。缩小它只是为了再次增长而导致碎片化，没有用处。很少，你会需要执行一个Shrinkfile，如在一些不寻常的事情之后。另外，为了减少自动增长，您可以继续设置数据文件为7GB。既然你的恢复很简单，那么你的日志文件不会真的变得太大。这里说的是一个相当简单的维护计划，你可以每晚运行。

•Check Database Integrity 
•Shrink the Log File – (This is ok because recovery mode is Simple) 
•Reorganize Index 
•Rebuild Index 
•Update Statistics 
•Clean Up History

您也可以在dba exchange

排序在tempdb 得到相当明确的答案了你可能想看看是否SORT_IN_TEMPDB选项将大量的研究出现后帮助

来源

2016-12-05 20:52:06

谢谢你的反馈，但是如果我运行索引的重新组织和重建，因为我使用SQL Express，我的数据库大小限制被击中，然后我的客户端无法将数据输入到数据库中。所以基本上维持运行，DB是现在的近10GB和客户端不再能进入的数据？有关如何克服这个问题的想法？ – Shaun

如果reindex操作正在推动您的存储限制，那么您可能需要考虑购买更多存储。 10GB没有那么多，而且空间越来越便宜。有些设置可能会减少操作期间和之后的磁盘空间大小，例如使用或不使用tempdb进行重新索引，但是，您正在使用磁盘空间实现硬约束。 –

嗨Ross，它实际上不是磁盘空间限制，而是我碰到的SQL Express数据库大小限制。你可以稍微扩展一下，或者提供一个关于“使用或不使用tempdb进行重新索引”的能力的链接？ – Shaun

重新组织在运行时不会在数据库文件中占用太多空间。

我结束了使用这些指令的组合，他们引用的SQL维护脚本好得多它使重组或重建决策的方式。 https://www.brentozar.com/archive/2013/09/index-maintenance-sql-server-rebuild-reorganize/

来源

2016-12-06 01:19:18 Shaun

SQL Server Express的维护建议

回答

相关问题