SQL Server Express的维护建议

Question

We operate a cloud version of our application that uses SQL Server 2012 Express as the DB engine. Each client has their own instance of SQL Server, allowing their instance to use the full 1GB of memory limited by Express, and it gives them 10GB of database size.

The challenge we have is keeping these databases optimized, yet allowing for maximum data storage for the clients and without disruption. In other words, we're trying to give them nearly all 10GB of the Express db for their actual data, but we need to run maintenance to keep performance optimized and it grows the DB, sometimes so large that maintenance fails.

Every Sunday night we run a SQL maintenance script like what's below.

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;

The maintenance works fine if space is available, the problem is that it swells the database and pushes the clients up to the 10GB limit. This then causes issues because they may not be able to allocate space for tables they need to add values into. We then have to go back and try and shrink the DB, which from my understanding, then undoes some of the benefits of the index defragmentation / maintenance.

Given the 10GB limit on data files, and the need to run maintenance to keep the DB's operating sufficiently, what could/should we do to get benefits from maintenance without having to shrink the database afterwards?

We're using Simple recovery mode, no autoshrink, and autogrowth at 10%

Thank you in advance!

Answer 1

after a lot of research it appears that reorganizing doesn't use as much space in the database files when run.

I ended up using a combination of these instructions with the SQL maintenance script they referenced which is much better the way it's making the decision to reorganize or rebuild. https://www.brentozar.com/archive/2013/09/index-maintenance-sql-server-rebuild-reorganize/

Answer 2

Don't do a shrink database. There is no use in shrinking it just to grow it again contributing to fragmentation. Rarely, would you need to perform a Shrinkfile as in after something unusual. Also, to reduce auto growth, you could go ahead and set the data file to something like 7GB. Since your recovery is simple then your log files should never really grow too large. That being said here is a rather straightforward maintenance plan that you could run nightly.

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

You may also get a pretty clear answer over at dba exchange

Sort in TempDB You might want to see if the SORT_IN_TEMPDB option will help