Question

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

我们面临的挑战是保持这些数据库的优化，同时为客户提供最大的数据存储，而不会中断。换句话说，我们正试图为他们的实际数据提供几乎所有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.' +@objectName + ';'
    EXEC (@COMMAND)

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

如果空间可用，维护工作正常，问题是它会使数据库膨胀并将客户端推送到10GB限制。这会导致问题，因为它们可能无法为需要添加值的表分配空间。然后，我们必须回过头来尝试缩小数据库，根据我的理解，然后撤消索引碎片整理/维护的一些好处。

鉴于数据文件的10GB限制以及运行维护以保持数据库运行充分的需要，我们可以/应该做些什么来从维护中获益而不必在之后缩小数据库？

我们使用简单恢复模式，没有自动收缩，并且自动增长率为10％

提前谢谢！

Answer 1

经过大量研究后，重组在运行时似乎没有在数据库文件中使用尽可能多的空间。

我最终将这些指令与他们引用的SQL维护脚本结合使用，这比决定重新组织或重建的方式要好得多。 https://www.brentozar.com/archive/2013/09/index-maintenance-sql-server-rebuild-reorganize/

Answer 2

不要做收缩数据库。缩小它只是为了再次增长它会导致碎片化是没有用的。很少，你需要执行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选项是否有用

SQL Server Express的维护建议

2 个答案: