WSUS定时清理自动任务（且重建索引）

即使只同步部分补丁，WSUS服务器的占用也比较大，特别是只有一台WSUS服务器的情况下，一旦长时间不进行清理，索引就爆炸了，于是你的WSUS控制台就没法打开了，就有很多操作做不了了，但是WSUS这种东西让运维维护本身就是不合适的，这部分工作肯定是需要自动化的。
我们可以先用WSUS控制台的自动清理，然后用SUSDB手动维护wsus的数据库（https://learn.microsoft.com/zh-cn/troubleshoot/mem/configmgr/update-management/wsus-automatic-maintenance），也有的微软文档指出，应该先用SUSDB重新建立和整理索引，然后用WSUS控制台清理，或者反过来用wsus控制台清理，再用SUSDB建立索引，我目前还没有搞清楚怎么做，所以我会暂时记录在这里。
我参考了以下微软文档：
https://learn.microsoft.com/zh-cn/troubleshoot/mem/configmgr/update-management/wsus-maintenance-guide#help-my-wsus-has-been-running-for-years-without-ever-having-maintenance-done-and-the-cleanup-wizard-keeps-timing-out
这篇文档说明了在很久不执行WSUS清理的情况下确实会出现控制台一直超时的问题：

https://learn.microsoft.com/zh-cn/troubleshoot/mem/configmgr/update-management/wsus-maintenance-guide
这篇文档说明了以下内容，要先手动运行WSUS清理，再进行其他的脚本操作或者SUSDB的操作。但是这篇文章非常老了，可能不具有很高的参考性。

WSUS 维护任务可以自动执行，前提是先满足一些要求。

如果从未运行过 WSUS 清理，则需要手动执行前两次清理。 第二次手动清理应从第一次开始运行 30 天，因为某些更新和更新修订需要 30 天才能过时。在进行第二次清理之前，你不希望自动执行操作有具体原因。 第一次清理的运行时间可能会比正常时间长。 因此，无法判断此维护通常需要多长时间。 第二次清理是计算机正常运行情况的更好指标。 这一点很重要，因为你需要弄清楚每个步骤作为基线需要多长时间 (我也喜欢在) 添加大约 30 分钟的切换空间，以便你可以确定日程安排的时间。

如果有下游 WSUS 服务器，则需要先对它们执行维护，然后执行上游服务器。

若要计划 SUSDB 的重新编制索引，需要完整版本的 SQL Server。 Windows 内部数据库 (WID) 没有计划维护任务的功能，但SQL Server Management Studio Express。 也就是说，在使用 WID 的情况下，可以使用前面提到的任务计划程序 SQLCMD 。 如果执行此路由，请务必在此维护期间不要同步 WSUS 服务器/SUP！ 如果执行此操作，下游服务器可能最终会重新同步刚刚尝试清理的所有更新。在 AM 同步之前，我将此时间安排在一夜之间，所以我有时间在同步运行之前对其进行检查。

对于已运行的SUSDB，如何查看其运行情况：

点击查看代码

$s=(gp 'HKLM:\SOFTWARE\Microsoft\Update Services\Server\Setup').SqlServerName; $c=new-object System.Data.SqlClient.SqlConnection("Server=$s;Database=SUSDB;Integrated Security=True;TrustServerCertificate=True;"); $a=new-object System.Data.SqlClient.SqlDataAdapter("SELECT start_time, percent_complete as 'Progress%', CAST(total_elapsed_time/60000.0 AS DECIMAL(10,2)) AS 'Elapsed_Min', command, SUBSTRING(st.text,(r.statement_start_offset/2)+1,((CASE WHEN r.statement_end_offset=-1 THEN LEN(CONVERT(nvarchar(max),st.text))*2 ELSE r.statement_end_offset END-r.statement_start_offset)/2)+1) AS 'SQL_Text' FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) st WHERE r.database_id=DB_ID('SUSDB')", $c); $d=new-object System.Data.DataTable; $null=$a.Fill($d); $d | ft -AutoSize

执行后，你会看到一个表格：

Progress%: 如果显示数字（如 15.5），说明 SQL 正在执行支持进度报告的操作（如 Shrink 或部分 Index Rebuild）。如果显示 0 也不要慌，有些复杂的 SQL 逻辑不返回百分比，但只要它在列表里，就说明它在运行。

Elapsed_Min: 告诉你主脚本里的这个动作已经持续跑了多少分钟了。

SQL_Text: 会直接显示类似 ALTER INDEX... 或 DBCC SHRINK...。如果这里显示的正是你脚本里的内容，说明主程序没挂，只是 1TB 的数据量太大，SQL 正在搬砖。

也可以用以下命令监控磁盘运行情况：

点击查看代码

while($true){ $p=Get-Process sqlservr -ErrorAction SilentlyContinue; if($p){ $s=Get-Counter "\Process(sqlservr)\IO Read Bytes/sec","\Process(sqlservr)\IO Write Bytes/sec"; Clear-Host; Write-Host "--- SQL Server Disk I/O Monitoring (Ctrl+C to Stop) ---"; $s.CounterSamples | Select-Object InstanceName, CookedValue | ft -AutoSize } else { Write-Host "Waiting for sqlservr.exe..." }; Start-Sleep -Seconds 2 }

IO Read Bytes/sec：SQL 正在从磁盘读取数据的速度。在执行 DELETE 之前，SQL 需要先读取数据页。

IO Write Bytes/sec：SQL 正在向磁盘写入（或更新日志）的速度。删除大量 tbXml 数据时，由于涉及大量事务日志写入，这个数值通常会非常活跃。

单位：输出的 CookedValue 是字节/秒。

如果数值在 1,000,000 左右，代表大约 1 MB/s。