The complete guide to Microsoft WSUS and Configuration Manager SUP maintenance

~ Meghan Stewart | Support Escalation Engineer

I’ve recently seen a lot of questions about Windows Server Update Services (WSUS) maintenance for Configuration Manager environments so I wanted to take a minute and hopefully address some of them here. Usually the questions are along the lines of “How should I properly run this in a Configuration Manager environment?”, or “How often should I be running this maintenance?” I have also seen extremely conscientious Configuration Manager administrators be completely unaware that WSUS maintenance should be run at all. After all, most of us just setup WSUS servers since it is a prerequisite for a Software Update Point (SUP). Once the SUP is setup, we close the WSUS console and pretend it doesn’t exist anymore. Unfortunately, this can be problematic for our Configuration Manager clients and the overall performance of the WSUS/SUP server.

So with the understanding that this maintenance needs to be done, I bet you’re wondering what maintenance you need to do and how often you need to be doing it. The answer is you should be doing this maintenance monthly and I’ll show you how below. Running the proper maintenance is pretty easy and doesn’t take very long for WSUS machines that have been well maintained from the beginning, however be aware that if you have never run WSUS maintenance before and the WSUS computer has been in production for a while, the cleanup may be harder the first time you run it, but will be much faster in the subsequent months.

Important Considerations

Before we get started, it’s important that I mention a few things:

  1. You should read all of the instructions before starting this process, as you may realize that you need to do steps in the middle of the article before you are able to go through the process from the start of the article to the end.
  2. Remember that when doing WSUS maintenance when you have downstream servers, you add to the WSUS servers from the top down, but remove from the bottom up. So if you are syncing/adding updates, they flow into the top (upstream WSUS server) then replicate down to the downstream servers. When you do a cleanup, you are removing things from the WSUS servers, so you should remove from the bottom of the hierarchy and allow the changes to flow up to the top.
  3. It’s important to note that this WSUS maintenance can be performed simultaneously on multiple servers in the same tier. You do however want to make sure that one tier is done before moving onto the next one when doing a cleanup. The cleanup and re-index steps I talk about below should be run on all WSUS servers regardless of whether they are a replica WSUS server or not (see section 4 below for how to determine if the WSUS is a replica).
  4. This is a big one. You must ensure that you do not sync your SUPs during this maintenance process as it is possible you will lose some of the work you have already done if you do. You may want to check your SUP sync schedule and set it to manual during this process.
  5. Note that If you have multiple SUPs off the primary site or CAS that do not share the SUSDB, consider the WSUS that syncs with the first SUP on the site as residing in a tier below the site. For example, my CAS site has 2 SUPs. The one named “New” syncs with Microsoft update. This would be my top tier (Tier1). The server named “2012” syncs with “New” and it would be considered in the second tier and can be cleaned up at the same time I would do all my other Tier2 servers, such as my primary site’s single SUP.


How to run WSUS maintenance

The four basic steps necessary for proper WSUS maintenance include the following:

  1. Backup the WSUS database
  2. Run the WSUS Server Cleanup Wizard
  3. Re-index the WSUS database
  4. Decline superseded updates

I go through each of these below.

1. Backup your WSUS database

Backup your WSUS database (SUSDB) using whichever method is your favorite.

2. Run the WSUS Server Cleanup Wizard

The WSUS Server Cleanup Wizard can be launched from the console. It is located under Options as shown here:


NOTE If you have not done maintenance before, run step 3, then 2, then 3 again. The initial re-index will help the cleanup go faster.

Please be aware that if the WSUS Server Cleanup Wizard has never been run and the WSUS has been in production for a while, the cleanup may time out. In that case, re-index with Steps 2 and 3 first, then run the cleanup with only the top box checked (unused updates and updates revisions). This may require a few passes. If it times out, run it again until it completes, then run each of the other options one at a time. Lastly make a “full pass” with all options checked. See the following TechNet documentation for more information:

Use the Server Cleanup Wizard


The cleanup is finished once it actually reports the number of items it has removed. If you do not see this returned on your WSUS server, it is safe to assume that the cleanup timed out and you will need to start it again.


3. Re-index the WSUS database

After the cleanup is finished, you need to re-index the WSUS database (SUSDB) with the following script:

The steps to run the script are different depending on whether you installed SUSDB on SQL Server or on Windows Internal Database (WID). This was specified when you actually installed SUSDB. If you are not sure which you used, you can check a registry key on the WSUS server located at HKLM\Software\Microsoft\Update Services\Server\Setup to verify. Look for the SQLServerName value. If you see just a server name or server\instance, you are using SQL server. If you see something that has the string ##SSEE or ##WID in it, you installed on Windows Internal Database, as demonstrated below:



If you installed SUSDB on Windows Internal Database

If you installed SUSDB on Windows Internal Database (WID) you will need to install SQL Management Studio Express in order to run the re-index script. If you’re not sure which version of SQL Server Management Studio Express to install, here’s an easy way to figure that out:

  • For Windows Server 2012, go to C:\Windows\WID\Log and find the error log that has the version number you’re using. Lookup the version number here:

321185 - How to determine the version, edition and update level of SQL Server and its components (

This will tell you what Service Pack level it is running. Include the SP level when searching the Download Center for SQL Management Studio Express as sometimes it does matter.

  • For Windows Server 2008 R2 or below, go to C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\LOG and open up the last error log with Notepad. At the very top there will be a version number (e.g. 9.00.4035.00 x64). Lookup the version number here:

321185 - How to determine the version, edition and update level of SQL Server and its components (

This will tell you what Service Pack level it is running. Include the SP level when searching the Download Center for SQL Management Studio Express.

Once SQL Management Studio Express is installed, launch it and it will prompt you to enter the server name to connect to:

  • If your OS is Windows Server 2012, use \\.\pipe\MICROSOFT##WID\tsql\query
  • If you are not running Windows Server 2012, enter \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query

NOTE For WID, you may want to run SQL Server Management Studio Express as administrator if you were not the person who installed WSUS.

TIP Alternatively, you can also use a utility called sqlcmd to run the script if it is installed. See the following TechNet documentation for more information:

Reindex the WSUS Database

If you installed SUSDB on SQL Server

If you installed on full SQL Server, simply launch SQL Server Management Studio and enter the name of the server (and instance if needed) when prompted.

Running the script

To run the script in either SQL Server Management Studio or SQL Server Management Studio Express, click on the New Query button, paste the script in the window and then click Execute. When it is finished you will see Query executed successfully along with the messages of what indexes were rebuilt.



4. Decline superseded updates

Additionally, you may want to decline superseded updates in the WSUS server so it helps your clients scan more efficiently. Before declining updates, you should ensure that the superseding updates are deployed and that you no longer need the superseded ones. Configuration Manager does have a separate cleanup where it expires updates that are superseded based on criteria that you provide it. For more information about this setting, review the Supersedence Rules heading at these links:

You can do this manually in WSUS if you wish, or you can run this PowerShell script. Simply download the script and rename it with a .PS1 extension. Please note that I am providing this script “as is” and it should be fully tested in a lab before being used in production. Microsoft makes no guarantees regarding the use of script in any way.

NOTE You always want to run the script with the –SkipDecline parameter before running the decline so you get a summary of how many superseded updates you are about to decline.

I normally recommend to run the script on the WSUS servers if you choose to expire superseded updates immediately in Configuration Manager. I run this once a quarter in my environment. This should be done on all autonomous WSUS servers in the Configuration Manager/WSUS hierarchy. This does not need to be run on WSUS servers set as replica such as Secondary Site SUPs. If you are unsure, verify the setting on your WSUS.


If you do not expire updates immediately in Configuration Manager, you will need to set an exclusion period that matches your Configuration Manager setting for number of days to expire superseded updates. In this case, it would be 60 days since I specified to wait 2 months in my SUP properties.


Examples on how to run the script using PowerShell running as administrator:

  • Decline-SupersededUpdates.ps1 -UpdateServer SERVERNAME -Port 80 -SkipDecline
  • Decline-SupersededUpdates.ps1 -UpdateServer SERVERNAME -UseSSL -Port 8351
  • Decline-SupersededUpdates.ps1 -UpdateServer SERVERNAME -Port 8530
  • Decline-SupersededUpdates.ps1 -UpdateServer SERVERNAME -Port 8530 –ExclusionPeriod 60

Running the script with a –SkipDecline and –ExclusionPeriod 60 to gather information about my WSUS and how many updates I will decline:


Running the script with –ExclusionPeriod 60:


Running the script to decline the rest of the superseded updates:



What if I find out I needed one of those updates I declined?

If you decide you need one of these declined updates in Configuration Manager for some reason, you can get it back in WSUS by right-clicking on the update and selecting Approve. Change the approval to Not Approved and resync your SUP to get the update back in.


If the update is no longer in your WSUS, you can import it from the Microsoft Update Catalog as long as it has not been expired from the catalog.


HELP! My WSUS has been running for years without ever having maintenance done and the cleanup wizard keeps timing out.

There are really two different options you can take here:

1. Reinstall WSUS with a fresh database.

2. Ensure you have a backup of the SUSDB then run a re-index. When that completes, run the following stored procedure in SQL Server Management Studio or SQL Server Management Studio Express. After this finishes, follow all of the above instructions for running maintenance. This last step is necessary because the stored procedure here only removes unused updates and update revisions.


DECLARE @msg nvarchar(100)


CREATE TABLE #results (Col1 INT)

INSERT INTO #results(Col1) EXEC spGetObsoleteUpdatesToCleanup




SELECT Col1 FROM #results




INTO @var1


BEGIN SET @msg = 'Deleting' + CONVERT(varchar(10), @var1)

RAISERROR(@msg,0,1) WITH NOWAIT EXEC spDeleteUpdate @localUpdateID=@var1






DROP TABLE #results


Automating WSUS maintenance

I’m often asked whether these WSUS maintenance tasks can be automated, and the answer is yes, assuming that a few requirements are met first.

1. If you have never run WSUS cleanup, you need to do the first two cleanups manually. Your second manual cleanup should be run 30 days from your first since it takes 30 days for some updates and update revisions to “age out”. There are specific reasons for why you don’t want to automate until after your second cleanup. Your first cleanup will probably run longer than normal so you can’t judge how long this maintenance will normally take, whereas the second cleanup is a much better indicator of what is normal for your machines. This is important because you need to figure out about how long each step takes as a baseline (I also like to add about 30 minutes “wiggle room”) so that you can determine the timing for your schedule.

2. If you have downstream WSUS servers, you will need to run them first, then do the upstream servers.

3. To schedule the re-index of the SUSDB you will need a full version of SQL Server. Windows Internal Database (WID) does not have the capability of scheduling out a maintenance task though SQL Server Management Studio Express. With that said, in cases where WID is used you can use the Task Scheduler with SQLCMD mentioned earlier. If you go this route, it’s important that you DO NOT SYNC YOUR WSUS SERVERS/SUPs during this maintenance period! If you do, it is very possible your downstream servers will just end up resyncing all of the updates you just attempted to clean out. Personally, I schedule this overnight before my AM sync so I have time to check on it before my sync runs.

Links you will need and some you may possibly need:

Setting up the WSUS Cleanup Task in Task Scheduler

The easiest basic directions and troubleshooting for this step are here but I’ll walk you through the process below.

1. Open Task Scheduler and Select Create a Task. Under the General tab, set the name of the task, the user that you want to run the PowerShell script as (most people use a service account), select Run whether a user is logged on or not, then add a description if you wish.


2. Under the Actions tab, add a new action and specify the program/script you want to run. In this case we need to use PowerShell and point it to the PS1 file we want it to run. I use the script found here. If you would like a log, you can append the last line of the script to read:

$cleanupManager.PerformCleanup($cleanupScope)| Out-File c:\wsus\wsusclean.txt

Note that you will get an FYI/warning in Task Scheduler when you save, but this is OK and can be ignored.


3. Set your schedule under the Triggers tab for once a month on any schedule you wish. Again, you must ensure that you do not sync your WSUS during the entire cleanup and re-index time. This statement really is important enough for me to bold it three times in a single article.


4. Set any other conditions or settings you would like to tweak as well. Note that when you save the task, you may be prompted for credentials of the “run as” user.

5. You can also use these steps to configure the Decline-SupersededUpdates.ps1 script to run every 3 months. I usually set this to run before the other cleanup steps, but only after I have run it manually and ensured it completed successfully. I run at 12:00 AM on the 1st Sunday every 3 months.

Setting up the SUSDB re-index for WID using SQLCMD & Task Scheduler

1. Save the script here as a .sql file (e.g. SUSDBMaint.sql)

2. Create a basic task and give it a name:


3. Schedule this task to start about 30 minutes after you expect your cleanup to finish running. My cleanup is running at 1:00 AM every first Sunday. It takes about 30 minutes to run and I am going to give it an additional 30 minutes before starting my re-index. This means I would schedule this task for every 1st Sunday at 2:00 AM, as shown here:


4. Select the action to Start a program. In the Program/script box type the following, where the file specified after the –i parameter is the path to the SQL script you saved in step 1, and the file specified after the –o parameter is where you would like the log to be placed. Here’s an example of what that might look like:

“C:\Program Files\Microsoft SQL Server\110\Tools\Binn\SQLCMD.exe" -S \\.\pipe\Microsoft##WID\tsql\query -i C:\WSUS\SUSDBMaint.sql -o c:\WSUS\reindexout.txt


5. You will get a warning, similar to the one you got when creating the cleanup task. Click Yes to accept the arguments, then click Finish to apply.


6. You can test the script by forcing it to run and reviewing the log for errors. If you run into issues, the log will tell you why. Usually if it fails, the account running the task does not have appropriate permissions or the WID service is not started.

Setting up a basic Scheduled Maintenance Task in SQL for non-WID SUSDBs

NOTE You must be a sysadmin in SQL to create or manage Maintenance Plans.

1. Open SQL Server Management Studio and connect to your WSUS instance. Expand Management, then right-click on Maintenance Plans and select New Maintenance Plan. Give your plan a name.


2. Click on subplan1 and then ensure your Toolbox is in context:


3. Drag and drop the task Execute T-SQL Statement Task:


4. Right-click on it and select Edit. Copy and paste the WSUS re-index script and click OK:


5. Schedule this task to run about 30 minutes after you expect your cleanup to finish running. My cleanup is running at 1:00 AM every first Sunday. It takes about 30 minutes to run and I am going to give it an additional 30 minutes before starting my re-index. This means I would schedule this task to run every 1st Sunday at 2:00 AM.


6. While you are creating the maintenance plan, you may want to consider adding a backup of the SUSDB into your plan as well. I usually backup first, then re-index. Note this may add additional time to your schedule.

Putting it all together

When running this in a hierarchy, you want the WSUS cleanup run from the bottom of the hierarchy up, but you want the decline script to run from the top down.

Since I can’t sync during the actual cleanup, I would prefer to be able to complete all tasks overnight then check on their completion via the logging when I come into the office in the morning before my next sync is scheduled. This is because in the case that something failed, I can reschedule the maintenance for the next night once I identify what failed and resolve the issue.

These tasks may run faster or slower in your environment and the timing of your schedule should reflect that. Hopefully they are faster since my lab environment tends to be a bit slower than a normal production environment. I am a bit aggressive on the timing of the decline scripts since if Tier2 overlaps Tier3 by a few minutes, it will not cause a problem.

My sync is not scheduled to run. This keeps the declines from accidentally flowing into my Tier3 replica WSUS servers from Tier2. I did give myself extra time between the Tier3 decline and the Tier3 cleanup since I definitely want to make sure the decline script finishes before running my cleanup.

This brings up a common question: Since I am not syncing, why shouldn’t I run all of the cleanups and re-indexes at the same time? The answer is that you probably could, but I wouldn’t. If my coworker across the globe needs to run a sync, with this schedule I would minimize the risk of orphaned updates in WSUS and I can schedule it to rerun to completion the next night:

12:00 AM
12:15 AM
Tier2- Decline
12:30 AM
1:00 AM
Tier3 WSUS Cleanup
2:00 AM
Tier3 Re-index
Tier2 WSUS Cleanup
3:00 AM
Tier1- Cleanup
Tier2 Re-index
4:00 AM
Tier1 Re-index

If you’d like more information regarding SUP maintenance in Microsoft Configuration Manager, we also have this KB article:

3090526 - Software update maintenance in System Center 2012 Configuration Manager (

Special thanks to Vinay Pamnani for providing the script to decline superseded updates with an exclusion period and to The Scripting Guy

Meghan Stewart | Support Escalation Engineer | Microsoft


Our Blogs

ConfigMgr 2012 R2

Comments (26)
  1. Brandon Hilgeman says:

    Excellent post. This was much needed.

  2. Sreekanth says:

    Really a good one for ConfigMgr admins, Thank you for sharing

  3. carsten says:

    Great article – good to know … but why doesn't SCCM takes care for WSUS completly on it's own ? Product management must have good reasons for this decision … I suppose so.

    1. Gaurav says:

      Hi Carsten,

      CM1511 has WSUS Cleanup feature integrated in SUP Properties. However the action plan is still very much required. SUDB reindexing and decline of superseded updates still is very important for effective management of Software Updates.


  4. Rich says:

    With all of these steps you would think this would be more automated or built in…

  5. Anonymous says:

    "Please be aware that if the WSUS Server Cleanup Wizard has never been run and the WSUS has been in production for a while, the cleanup may time out."

    Why don't you guys just fix WSUS? WSUS feels like some cheap flaky application written by some guy in India for the lowest dollar amount Microsoft could get. Oh, you keep getting these random errors? Just click retry. Oh the clean up wizard is timing out with
    errors? Just retry!


  6. Henry Wilson, Sanofi says:

    Nice Comprehensive review of the WSUS Cleanup that (I'm sure) will help many folks!

  7. Leks says:

    Thanks for this extensive guide.
    One question though; Our DBA's run a daily index optimization on all user databases (the one from Ola Hallengren). Do we still need to re-index the SUSDB separately?

  8. paasin says:

    This is great!!!

  9. Daniel Wolf says:

    It's pretty ridiculous that WSUS includes a Cleanup tool that doesn't actually maintain the product. Why isn't this integrated? You own the entire stack, it's unacceptable that it doesn't maintain itself.

  10. Sean says:

    Thanks for the article! I think I will be able to use this to tune my clean-up process.

    One option other than scheduled tasks is Orchestrator (Microsoft System Center Orchestrator). That is if you are licensed for Orchestrator. Orchestrator is part of the System Center Suite package where I work. If you’re interested you may want to check if your
    company is licensed for Orchestrator by your System Center Suite license.

    By using Orchestrator I don't have to guess when the clean-up and indexing will end before I start on the next server or tier. Orchestrator is set up not to process the next step and server until the previous step is successful. In addition, Orchestrator sends
    me e-mail reporting the results of the cleanup and indexing per server.

    Automating the clean-up process in Orchestrator works like a charm for my company.

    If you use the WID (Windows Internal Database), in lieu of installing “SQL Server Management Studio Express” you can install "Microsoft SQL Server Native Client" and "SQL Server Command Line Query Tool". I am not saying one is better than the other but I installed
    the "Microsoft SQL Server Native Client" and "SQL Server Command Line Query Tool" and the database indexing works like a champ.

    If Meghan can comment on why it would be better to use "SQL Server Management Studio Express" over my method I will love the advice!

  11. Morgan Tiley says:

    Does this apply to 1511 as well or only cm12?

  12. nick says:

    Really clear and good article! We've done this for years, fortunately! But we got some new info so that we could adjust it a little more. What's your opinion about declining itanium updates? Is it worth or not?

  13. Niels says:

    Thanks Meghan, very useful and extensive guidance on WSUS maintenance.

  14. Johan Erven says:

    Is this guide also valid for SCCM Current Branche

    Thanks in advance



    1. Alan Dooley says:

      Current branch will run the cleanup wizard for you provided you tick the option it Site Component settings

      1. Emmanuel R says:

        Do run though the re-index DB script for WSUS DB

  15. NPherson says:

    Will any of these numerous tasks be integrated into the version of WSUS that ships with Windows Server vNext? If not, what will it take for them to bake this stuff in?

  16. Christian_K says:

    Great guide! What is the difference between the “Decline-SupersededUpdates.ps1” PowerShell script and the “Superceeded Updates” checkbox (last option) in the WSUS Server Cleanup Wizard?

    1. Andreiz says:

      Hi Christian,

      the script doesn’t care if the superseded update has been replaced by an approved update like the wizard does, read the text under the option for the condition it has to fulfill.

  17. Olaf says:


    first, thank you for this very complete article.
    Just for my understanding, if I have only a 2 Tier Implementation:
    – WSUS/SUP in a Primary Site, connected directly to the MS Update catalog
    – WSUS/Sup on Secondary Sites only as replica WSUS/SUP
    I run the Cleanup Wizard and Cleanup Script just on the Primary WSUS Server? Do I have to re-index all of the WSUS Servers in the environment?

    Kind regards

  18. Shri says:


    In our environment, we have 1 upstream and 5 downstream servers integrated with ConfigMgr. The sync is scheduled to run every 12 hours.
    Now the problem is that I was doing the clean up after 1 year approx on the downstream server and we have to cleanup huge no. of updates, so it has taken a lot of time. I used the similar script shown above but I observed that the no. of updates were increased again after sometime after the cleanup. I guess because of sync.

    Please let me know if shall I start the cleanup from Top to bottom flow unlike you suggested in the blog. Also let me know if there are any consequences.

  19. José Manuel Pérez Bethencourt says:

    Sorry if my english is not good, it’s not my native language.

    I just wanted to state that script for declining superseded updates in WSUS (Decline-SupersededUpdatesWithExclusionPeriod.ps1) has a runtime error in Spanish OS in two lines with Write-Progress:

    Write-Progress -Activity “Declining Updates” -Status “Declining update #$i/$countSupersededAll – $($update.Id.UpdateId.Guid)” -PercentComplete $percentComplete -CurrentOperation “$($percentComplete)% complete”

    The problem is that in Spanish Windows OS / locale the $percentComplete uses Spanish decimal point “,” and not “.”, and Write-Progress expects English number formatting. Hence the runtime error. The process does not stop and gets going on declining updates and gets the job done but the large number of runtime errors is troubling and finding out what’s wrong and ruling out an problem is time consuming. So this is a generic localization problem for any culture with a decimal point that is not the same as English.

    The runtime error is exactly:
    Write-Progress : No se puede validar el argumento del parámetro ‘PercentComplete’. El argumento 7506 es mayor que el
    intervalo máximo permitido de 100. Proporcione un argumento que sea menor o igual que 100 e intente ejecutar el
    comando de nuevo.
    En F:\scripts\Decline-SupersededUpdatesWithExclusionPeriod.ps1: 204 Carácter: 148
    + … ercentComplete $percentComplete -CurrentOperation “$($percentComplete)% complete …
    + ~~~~~~~~~~~~~~~~
    + CategoryInfo : InvalidData: (:) [Write-Progress], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationError,Microsoft.PowerShell.Commands.WriteProgressCommand

    The value of $percentComplete is computed as:

    $percentComplete = “{0:N2}” -f (($updatesDeclined/$countSupersededAll) * 100)

    To circumvent the problem, I have substituted previous line (you have to update two instances, there is a condicional depending on value of DeclineLastLevel):

    $invariantCulture = [System.Globalization.CultureInfo]::InvariantCulture
    $percentComplete = (($updatesDeclined/$countSupersededAll) * 100).toString(“0.00”,$invariantCulture)

    Obviously the first line that defines $invariantCulture should be put out of the loop that processes updates for performance reasons.

    I am sure that there is some better way to solve it, I don’t use PowerShell and I’m not proficient at it. Maybe someone can post a better solution, but I think that it can save a lot of time for non-English users out there stating this post and better still modifying the script to account for this localization bug.

    THANK YOU VERY MUCH for this informative post, I have not found a good source of information on the topic of WSUS maintenance in Configuration Manager context. This post is both broad in the sense of completeness and in-depth.

  20. Roel says:

    For those of you that still can’t complete the cleanup I’d recommend this thread:

    After manualy deleting one update from the database the Wizard is now running swimmingly.

    Regards, Roel

  21. T says:

    Good guide, but isn’t there are a mistake, to make cleanup on downstreem first? It should be done on upstream first, isn’t?

  22. When running the WSUS Server Cleanup Wizard and selecting the first option Unused Updates and update revisions if you have many updates the progress bar may never appear – you may wonder whether it’s working or not. One way you can tell if it is, is running SQL Management Studio, connecting to the database, and running the SQL command exec spGetObsoleteUpdatesToCleanup in a window while the wizard is running. You will get a list of rows and at the bottom will be the number of rows. Wait a few moments and then run it again, and see if the number of rows has decreased. It may take the wizard anywhere from 2 -15 minutes to delete a row on a database that has not had maintenance run on it for a long time.

Comments are closed.

Skip to main content