SQL Assessment API 自定义评估工作流深度指南：从规则（Rule）、探测器（Probe）到规则集（Ruleset）的完整定制实践

示例工程数据库教程后端【免费下载链接】sql-server-samplesAzure Data SQL Samples - Official Microsoft GitHub Repository containing code samples for SQL Server, Azure SQL, Azure Synapse, and Azure SQL Edge项目地址https://gitcode.com/gh_mirrors/sq/sql-server-samples点击查看免费下载SQL Assessment API 是微软官方提供的 SQL Server 配置最佳实践评估机制其默认规则集由 SQL Server 团队维护但 API 从设计之初就面向高度可定制、可扩展的场景构建。本文以仓库内 Customization 文档 为主体结合 MakingCustomChecks_sample.json、DisablingBuiltInChecks_sample.json、ruleset.json 等仓库内真实文件系统讲解如何自定义评估工作流读懂规则与探测器的协作模型、掌握规则/探测器/目标模式Target Pattern的完整 JSON 语法、学会用覆盖override调整阈值与开关、编写自己的检查项并将自定义规则集接入Invoke-SqlAssessment评估流程。读完本文你将具备为 SQL Server 2012 及以上版本与 Azure SQL 托管实例定制专属评估策略的完整实战能力。图Rule 的 JSON 对象结构来源Customization 文档的 RuleStructure.svg图Probe 实现的结构来源Customization 文档的 ProbeStructure.svg图规则集文件的三层结构来源Customization 文档的 RulesetStructure.svg一、为什么需要自定义最佳实践并非放之四海而皆准SQL Assessment API 使用一组最佳实践建议来检查 SQL Server 环境或配置是否可以被改进。但最佳实践不是普适的指导方针取决于 SQL Server 的版本、版本类型Edition与配置、托管平台云环境、物理机、虚拟机甚至取决于使用模式。例如某些最佳实践只适用于云环境另一些只适用于物理机安装的 SQL Server 实例数据库类型不同适用的实践也不同——针对msdb数据库的最佳实践集合可能与用户数据库使用的集合截然不同。为了让建议更加具体SQL Assessment API 实现了两步评估流程为给定目标构建检查清单Checklist根据指定的目标服务器或数据库生成包含完整检查项的清单逐项检查并报告每条违反最佳实践的行为引擎遍历检查清单验证目标是否满足各项最佳实践。检查清单的构建基于规则Rule。每条规则要么定义一个新检查要么修改一个或多个现有检查。规则存放在规则集Ruleset中每个规则集拥有自己的name与version。用户可以将多个规则集按顺序逐个加入 SQL Assessment API 引擎构建检查清单时引擎按照规则被添加的顺序依次应用。单个检查可能受多条规则影响第一条规则必须定义该检查并分配唯一的字符串 ID。检查可以带有tags标签用于按组管理后续规则可以通过 ID 或标签引用检查进行覆盖override从而一次性修改多个检查。以仓库默认规则集中的MaxMemory检查为例下面的规则让该检查出现在所有 SQL Server 2012 及以上实例的清单中并将limit参数设置为 2147483647{ id: MaxMemory, itemType: definition, target: { type: Server, version: [11.0,) }, limit: 2147483647 }以下规则则修改上面定义的MaxMemory检查的limit参数{ id: MaxMemory, itemType: override, limit: 2000000000 }注意覆盖规则还可以配合targetFilter只针对特定目标生效。下面的两条规则分别为Standard 版与Express 版SQL Server 设置了不同的内存上限{ id: MaxMemory, itemType: override, targetFilter: { engineEdition: Standard }, limit: 131072 }, { id: MaxMemory, itemType: override, targetFilter: { engineEdition: Express }, limit: 1410 }检查进入清单并不意味着一定会被执行。每个检查都有enabled属性默认值为true如果所有规则应用后该属性变为false引擎将跳过此检查。下面的规则会禁用所有 Linux 实例上的MaxMemory检查以及所有与性能Performance标签相关的检查{ id: [ MaxMemory, Performance ], itemType: override, targetFilter: { platform: Linux }, enabled: false }二、规则集文件结构评估配置的载体规则集存储在一个包含 JSON 对象的文本文件中。规则集对象有三个必填的简单属性name、version与schemaVersion其中schemaVersion指定文件格式版本撰写本文档时格式版本为 1.0name与version共同构成规则集的身份标识。可选的rules属性存储规则数组用于构建检查清单见 Understanding rules and probes可选的probes属性存放探测器定义用于从目标 SQL Server 实例、宿主机及其他数据源获取实际数据。每个探测器定义是一个 JSON 数组包含一个或多个实现rules与probes之所以都是可选的是因为一个规则集内的规则可以使用另一个规则集内的探测器。{ name: Ruleset name, version: Ruleset version, schemaVersion: Schema version, rules:[ { … rule A … }, { … rule B … }, … ], probes:{ probe1: [ { … implementation 1 … }, { … implementation 2 … }, … ], probe2: [ … ], … } }仓库中提供了两个可直接参考的真实规则集文件DisablingBuiltInChecks_sample.json演示如何按 ID 禁用指定规则、按标签批量禁用规则、以及仅针对特定数据库禁用整个默认规则集MakingCustomChecks_sample.json演示如何编写包含规则与探测器的完整自定义规则集。此外ruleset.json 是随 API 交付的默认规则集约 770 KB包含 SQL Server 团队建议的全部内置规则DefaultRuleset.csv 是该规则集的可读版本方便熟悉现有规则并搜索、筛选字段。三、Rule 属性详解定义一个检查项的全部要素规则由一个 JSON 对象表示将其属性应用到新检查或已有检查上。完整属性如下| 属性 | 说明 | | - | - | |itemType| 取值definition定义新检查或override修改已有检查。一个检查可被多条规则修改 | |tags| 短字符串数组用于给检查分类。例如标记为 Memory 的检查来自内存相关的最佳实践。单词标签效果最佳 | |id| 要定义或修改的检查 ID。也可以是检查 ID 或标签的数组一次修改多个检查指定多个标签时只要检查拥有其中任意一个标签即会被影响 | |target| 目标模式Target PatternJSON 对象用于筛选适用规则被评估对象匹配target模式时该规则才被应用。详见 TargetPattern.md | |targetFilter| 与target语法相同但仅在覆盖override中使用用于限定覆盖生效的目标范围 | |displayName| 显示在检查清单中的短名称。可以把 displayName 理解为规则如果存成独立文件时的文件名通常它说明了该检查在查找什么 | |message| 字符串作为生成用户消息的模板。当检查发现配置不符合最佳实践时显示。详见 MessageTemplate.md | |description| 长描述解释为什么该检查要查找这个特定问题并简要讨论检测到问题后的影响 | |helpLink| 指向解释最佳实践与修复建议文章的链接 | |level| 严重级别取值Information、Low、Medium、High| |probes| 包含探测器引用的数组该检查通过这些引用获取所需数据。详见 ProbeReference.md | |condition| JSON 对象树形式的表达式使用检查参数与探测器数据。当最佳实践已实现时应返回true若求值为false则向用户显示消息 | |parameters| 任意属性随探测器数据一起传递给条件、消息模板、探测器参数与转换transform |仓库中的 MakingCustomChecks_sample.json 给出了一个可直接复制的完整definition规则示例——检查 Query Store should be active针对 SQL Server 2016 的用户数据库要求 Query Store 处于读写模式{ target: { type: Database, version: [13.0,), platform: Windows, Linux, engineEdition: OnPremises, ManagedInstance, name: { not: /^(master|tempdb|model)$/ } }, id: QueryStoreOn, itemType: definition, tags: [ CustomRuleset, Performance, QueryStore, Statistics ], displayName: Query Store should be active, description: The Query Store feature provides you with insight on query plan choice and performance…, message: Make sure Query Store actual operation mode is Read Write to keep your performance analysis accurate, helpLink: https://docs.microsoft.com/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store, probes: [ Custom_DatabaseConfiguration ], condition: { equal: [ query_store_state, 2 ] } }其中condition的含义是当探测器返回的变量query_store_state等于 2 时视为符合最佳实践否则规则将把message内容加入结果推荐集合触发告警。四、Target Pattern精准圈定规则与探测器的适用范围目标模式指定了筛选规则和探测器实现的条件。规则只应用于匹配其target模式的 SQL Server 实例和数据库。这一机制允许规则针对特定 SQL Server 版本、版本类型甚至特定数据库生效在自定义规则集中还可以按名称区分实例——例如开发用服务器可能不需要频繁备份。目标模式是一个 JSON 对象所有属性均为可选省略的属性视为匹配任意值。| 属性 | 允许值 / 说明 | | - | - | |engineEdition|PersonalOrDesktopEngine、Standard、Enterprise、Express、AzureDatabase、DataWarehouse、StretchDatabase、ManagedInstance。可用逗号分隔组合Azure是AzureDatabase, DataWarehouse, StretchDatabase, ManagedInstance的缩写SqlServer是PersonalOrDesktopEngine, Standard, Enterprise, Express的缩写 | |name| 目标 SQL Server 对象的名称数据库名或实例名的字符串模式 | |machineType| 托管目标 SQL Server 实例的机器类型的字符串模式支持Physical、AzureVm、Hypervisor、Other| |platform| 托管目标实例的平台支持Windows、Linux| |serverName| SQL Server 实例名的字符串模式。若目标是实例本身则serverName等于name否则为目标对象所在宿主实例的名称 | |type|Server或Database可用逗号分隔组合。检查的目标总是Server或Database之一对探测器而言两者往往都适用 | |version| 指定匹配 SQL Server 版本范围的版本模式 |示例匹配除master、tempdb、model之外的任何数据库name: { not: [ master, tempdb, model]}示例匹配物理机或 Azure 虚拟机machineType: [AzureVm, Physical]示例匹配除名称以Test结尾之外的实例serverName: {not: /*.Test$/}字符串模式字符串模式定义了匹配规则可以是字符串、JSON 对象或字符串模式数组任意字符串进行精确匹配以斜杠/开头和结尾表示正则表达式例如/Win*./。正则表达式选项写在结尾斜杠之后例如/win.*/c表示大小写敏感搜索。若字符串不以斜杠开头则视为精确匹配——字符串Linux等价于正则/^Linux$/JSON 对象只能含一个名为not的属性其值必须是任意字符串模式表示匹配一切不匹配该not值的内容。注意正则表达式默认不区分大小写需要区分大小写时使用c选项。SQL Assessment API 使用 .NET 正则表达式语法。以下模式匹配任何不以Test结尾的内容{ not: /*.Test$/c }版本模式版本范围列表可以是单个版本范围或版本范围数组。单个版本范围等价于只含一个元素的数组版本范围列表匹配任何满足其中任意一个范围的版本。version: [ [10.0.4326,10.0.4371], [10.0.5794,10.50), [10.50.2806,11.0), [11.0.2316,) ]版本范围由字符串编码包含一个或两个版本用逗号分隔并括在可选的小括号或方括号中。若有两个版本前者必须小于或等于后者分别代表边界版本至少由主版本号与次版本号两个数字构成用句点分隔。该格式遵循 NuGet 版本范围格式| 版本范围 | 匹配内容 | | - | - | |10.0| 恰好为版本 10.0 | |[10.0, 13.0]| 10.0 到 13.0 之间含两端10.0、10.50、11.0.345、13.0 | |(10.0, 13.0)| 10.0 到 13.0 之间不含两端10.50、11.0.345不匹配 10.0 或 13.0 | |[10.0, 13.1)| 10.0 到 13.1 之间不含右边界10.0、10.50、11.0.345、13.0、13.0.234不匹配 13.1 | |(10.0, 13.1]| 10.0 到 13.1 之间不含 10.0 | |[10.0,)| 10.0 及以上 | |(10.0,)| 10.0 以上但不含 10.0 本身 | |(,10.0]| 10.0 或以下 | |(,10.0)| 10.0 以下但不含 10.0 |实际使用时version常与type、platform、engineEdition组合出按版本分支的实现。例如 MakingCustomChecks_sample.json 中的Custom_DatabaseConfiguration探测器就为 SQL Server 2014 之前(,12.0)、2014[12.0, 13.0)、2016 及以上[13.0,)分别提供了三套 T-SQL 查询实现2016 的实现额外使用useDatabase: true在目标数据库上下文中执行以读取sys.database_query_store_options。五、探测器Probe数据的来源与实现选择机制检查本身不直接从目标服务器或数据库取数而是引用探测器probe。多数探测器使用 T-SQL 查询但 SQL Assessment API 还支持 WMI、Windows 注册表、Azure 实例元数据服务Azure Instance Metadata Service探测器以及以 .NET 类实现的自定义探测器。探测器返回零行或多行包含命名项的数据。如果一个检查从多个探测器取数最终数据集是各行数据的全部组合——行为类似 T-SQL 中的CROSS JOIN。检查的条件表达式按行分别求值例如数据库使用 3 个磁盘存放文件时磁盘剩余空间的最佳实践会分别作用于每个磁盘若检查使用两个探测器一个返回 2 行、另一个返回 3 行则条件将被求值 2×36 次其中 2 次为false时检查会生成 2 条消息。探测器实现可能依赖 SQL Server 版本例如动态管理视图在不同版本间存在差异因此一个探测器可以拥有多个实现每个实现都有自己的target规范与规则相同。评估引擎为每个目标选择最合适第一个匹配的实现——这意味着实现数组中的顺序很重要。另一个规则集还可以在探测器实现列表的顶部追加新实现。探测器还应该被设计为无副作用的函数调用顺序是不确定的引擎可能为了优化目标 SQL Server 负载而重排调用当没有任何检查需要某探测器的数据时该探测器不会被调用。默认规则集中的探测器只读取元数据如更新日志或服务器属性不读取用户表中的数据不向数据库或实例写入任何内容也不设置任何标志或属性。探测器类型探测器通过type属性决定取数机制| 类型 | 说明 | | - | - | | AzGraph | 对 Azure 资源图Azure Resource Graph执行的 Kusto 查询 | | AzMetadata | 对 Azure 实例元数据服务返回对象的 JSONPath | | CMD | 在目标机器上运行的命令壳脚本 | | External | 任意 .NET 代码 | | PowerShell | PowerShell 脚本 | | Registry | 来自注册表的数据 | | SQL | T-SQL 查询 | | WMI | WMI 查询 |各类型的具体参数说明可参考 Probes 参考文档。探测器实现的属性还包括implementation探测器的参数与影响输出结果的数据转换。例如 T-SQL 探测器的主要参数是取数查询queryExternal 探测器则需要assembly要加载的程序集与class实现IProbeImplementation接口的完整类名requires显式的功能需求。引擎检查需求是否全部满足若不满足则不执行探测器、跳过所有依赖它的检查并返回一条警告runFor与requires格式相同的逻辑需求但区别是不产生警告——探测器不执行查询而是立即返回空结果集target目标对象模式。requires 与 runFor优雅处理权限与配置缺失默认情况下探测器中的任何错误都会立即以错误消息终止整个评估过程这会导致结果不完整因为还有检查未运行。以DBCC DBINFO探测器为例若当前用户没有sysadmin角色直接执行会报错并终止评估。可以在requires中显式声明需求让引擎在执行查询前先检查DBMetaInfo: [ { type: SQL, target: { type: Database }, implementation: { query: DBCC DBINFO(TargetName) WITH TABLERESULTS,NO_INFOMSGS }, requires: { role: [ sysadmin ] } } ]而针对探测器本身在特定环境下无意义的场景例如探测数据库镜像端点的探测器在 HADR 未启用时没有意义使用runFor静默跳过比requires更合适避免对每个未参与 HADR 的实例都产生困惑性警告AGEndpoints: [ { type: SQL, target: { type: Server }, implementation: { query: SELECT [name] AS endpoint_name, is_encryption_enabled, encryption_algorithm, encryption_algorithm_desc FROM sys.database_mirroring_endpoints }, runFor: { feature: [ HADR ] } } ]需求以 JSON 属性表示属性名是需求名称属性值是字符串数组表示所需的值。例如requires: { server permission: [ ALTER TABLE, ADMINISTER BULK OPERATIONS ] }支持的需求类型包括 role如bulkadmin、diskadmin、permission、feature 与 service详见 Probe requirements 总览。六、探测器引用Probe Reference复用、别名与数据流转检查通过探测器引用来声明自己需要哪些数据。探测器引用是一个 JSON 对象当以无额外选项或参数的方式引用时可以缩写为仅含探测器 ID 的字符串如probes: [SysDmOsSysInfo]。完整属性如下| 属性 | 说明 | | - | - | |alias| 该探测器的替代名称可在本检查的表达式中使用。主要用于两个场景多次调用同一探测器与将一个探测器的数据传给另一个探测器 | |id| 被引用的探测器 ID | |params| 传递给探测器的参数JSON 对象的属性名是参数名属性值可以是任意表达式包含常量、全局/局部变量以及其他探测器返回的数据 | |transform| 在计算条件值之前应用于数据的数据转换 |多次调用同一探测器某些检查需要以不同参数多次调用同一探测器。此时添加多个具有相同id的引用并用别名::前缀区分不同参数对应的输出变量名。下面的检查比较 C: 盘与 D: 盘的剩余空间probes: [ { type: DiskInfo, alias: FirstDisk, params: { DiskName: C: } }, { type: DiskInfo, alias: SecondDisk, params: { DiskName: D: } } ], condition: { greater: [ FirstDisk::FreeSpace, SecondDisk::FreeSpace ] }将数据传递给另一个探测器一个探测器返回的数据可以作为参数传给另一个探测器参数表达式只需包含以探测器 ID 或别名作前缀的输出变量名。下面的例子中DatabaseMasterFiles探测器找出目标数据库使用的所有磁盘的卷 ID经aggregate转换去重后AzStorage探测器针对每个卷 ID 追加 Azure 相关存储属性probes: [ { id: DatabaseMasterFiles, alias: db_files, params: { dbId: null, type: null }, transform: [ { type: aggregate, group: [ volume_mount_point, volume_id ] }, { type: aggregate, group: volume_id, map: { volume_mount_point: join } } ] }, { id: AzStorage, params: { path: db_files::volume_id } } ]七、数据转换Data Transformation让数据以最合适的形态进入条件求值数据有时需要经过一系列转换。当数据格式不便使用时可以在探测器实现内应用转换。例如以下 T-SQL 查询返回的host_release是类似10.0.19044.2006的字符串SELECT host_platform, host_release FROM sys.dm_os_host_info虽然也可以在 T-SQL 中解析该字符串但用转换让代码更可读、更易创建与维护implementation: { query: SELECT host_platform, host_release FROM sys.dm_os_host_info, transform: { type: parse, map: { host_release: /^(?major\\d)\\.(?minor\\d) } } }转换同样可以应用在探测器引用中以提升探测器复用率当某个检查需要某指标的均值、而另一个最佳实践需要同一指标的最大值时两个检查可以引用同一个探测器各自应用自己的转换。这样不仅探测器的代码被复用数据也被复用——因为探测器只会被调用一次。完整的转换类型参考aggregate、defaultValue、nameValuePairs、noData、parse、performance、rename、toString等见 Data transformation reference。八、本地变量与消息模板让输出可计算、可读本地变量Local Variables检查可以定义本地变量供条件与消息模板使用。本地变量是涉及字面量、探测器数据与转换结果的任意表达式{ probes: [SysDmOsSysInfo], locals: { workers: {sub: [ max_workers_count, 1 ] } }, message: Workers {workers}., condition: { lt: [ 0, workers ], lt: [ workers, 4 ] } }消息模板Message Template检查在 Rule 的message属性中指定推荐消息。消息中可以嵌入探测器返回或检查计算出的数据语法类似 C# 字符串插值用加花括号{变量名}引用变量。例如message: Drop hypothetical {IndexName} index for {Schema}.{Object}消息模板支持格式说明符说明符须用冒号:跟在变量名之后。例如将fragmentation乘以 100、四舍五入到小数点后两位并附加百分号%message: Current fragmentation level is {fragmentation:P2}输出Current fragmentation level is 37.20%字符串值的格式化还有扩展行为当值非空时格式字符串会插入结果消息中其中的#号被字符串值本身替换适合在存在附加信息时拼接句子片段。例如message: Create index on {Table} with key columns {KeyCols}{IncludedCols: and included columns: #}当IncludedCols为空时输出Create index on MyTable with key columns Id, Name当IncludedCols包含SpaceAvailable, CPULoad时输出Create index on MyTable with key columns Id, Name and included columns: SpaceAvailable, CPULoad九、自动变量Automatic Variables无需探测器即可获得的目标元数据评估数据由探测器交付但部分数据在第一个探测器被调用之前就已经可用例如目标 SQL Server 版本或探测器的需求信息可通过自动变量访问。自动变量按命名空间分组详见 Automatic Variables 总览。attr::target::命名空间包含匹配目标模式的数据AttrTarget.md| 变量名 | 类型 | 说明 | | - | - | - | |attr::target::version| version | 目标 SQL Server 版本 | |attr::target::platform| string | 目标 SQL Server 宿主平台如 Windows、Linux | |attr::target::engine_edition| string | 目标引擎版本类型 | |attr::target::server_name| string | 目标服务器名 | |attr::target::machine_type| string | 目标机器类型 | |attr::target::urn| string | 目标对象 URN |attr::service::命名空间的变量由服务需求ServiceRequirement提供键名来自服务需求支持的值AttrService.md| 变量名 | 类型 | 说明 | | - | - | - | |attr::service::_key_| bool | 服务是否存在 | |attr::service::_key_.name| string | 实际服务名 | |attr::service::_key_.account| string | 该服务的用户账户名 |例如当 SQL Server Agent 服务存在且运行在本地服务账户下时消息会报告实际账户名{ message: Account {attr::service::SQLAgent.account} is not supported for SQL Server Agent service., localServiceAccount: NT AUTHORITY\\LOCALSERVICE, condition: [ { not: attr::service::SQLAgent }, { ine: [ attr::service::SQLAgent.account, localServiceAccount ]} ], probes: [ IsClusteredServer ] }十、条件表达式与运算符参考条件是 JSON 对象树形式的表达式用来描述最佳实践的正式形态。基础规则如下JSON 的true/false视为布尔常量JSON 数字视为十进制常量字符串视为字符串字面量以开头的字符串表示对变量的引用变量值由探测器设置被表达式或推荐文本消费包含多个属性的 JSON 对象是AND运算的简写形式例如{ version: 10.50.0, memroySize: 4096 }等价于{ and: [ ... ] }属性名以开头的单属性表达式是equal 运算的简写{memorySize: 4096}等价于{equal: [memorySize, 4096]}条件表达式可以是表达式数组数组是OR 运算的简写注意OR 简写只在条件表达式中有效而 AND 简写在所有位置都有效。条件中可用的运算符如下完整参考见 Operators.md逻辑运算not、and无参数返回false、or无参数返回true。字符串运算indexof/iindexof查找子串索引区分/不区分大小写、startswith/istartswith、endswith/iendswith。数学运算ceiling、floor、max、min、mul乘法、div除法、mod取余、add求和、sub求差、bitand、bitor、bitxor。集合运算intersect、in检查a是否在集合b中区分大小写、iin不区分大小写。比较运算lt/less、gt/greater、eq/equal区分大小写、ieq、ge/greaterequal、le/lessequal、ne/notequal、ine、match/imatch正则匹配第二个参数为正则表达式区分/不区分大小写、interval(*a*,*v₁*,*t₁*,...,*vₙ*,*tₙ*,*d*)找到第一个大于等于a的tᵢ并返回对应的vᵢ若所有t都小于a则返回d。十一、实战场景覆盖默认阈值与禁用内置检查覆盖默认阈值某些默认阈值可能不适合评估时点的实际基础设施。以FullBackup规则为例——它验证备份创建日期是否超过了规则中指定的阈值默认 7 天。首先运行Invoke-SqlAssessment -Check FullBackup | Select TargetObject, Message输出示意TargetObject Message ------------- -------- [DevTest] Create full backup. Last full backup is over 7 days old [Prototype] Create full backup. Last full backup is over 7 days old若要将阈值从 7 天改为 3 天创建一个充当附加配置的 JSON 文件BackupPolicy.json{ schemaVersion: 1.0, version: 1.0, name: Backup Policy, rules: [ { itemType: override, id: FullBackup, threshold: 3 } ] }然后使用-Configuration参数执行评估Invoke-SqlAssessment -Check FullBackup -Configuration .\BackupPolicy.json | Select TargetObject, Message输出将变为所有备份超过 3 天的数据库都触发推荐消息。完整流程见 OverridingDefaultThresholds.md。禁用内置检查仓库中的 DisablingBuiltInChecks_sample.json 演示了三种禁用方式{ schemaVersion: 1.0, version: 0.2, name: Custom Overrides, rules:[ { id: LatestCU, itemType: override, enabled: false }, { id: [TraceFlag], itemType: override, enabled: false }, { id: [DefaultRuleset], itemType: override, targetFilter: { type: Database, name: /^(DBName1|DBName2)$/ }, enabled: false } ] }三个部分分别演示①按 ID 禁用LatestCU检查②按TraceFlag标签批量禁用所有相关检查③利用targetFilter仅针对名为DBName1、DBName2的数据库禁用整个默认规则集DefaultRuleset标签。十二、评估模型与仓库中的更多资料围绕本文主题仓库内还有以下可直接继续深入阅读的资料核心概念Understanding rules and probes、Rule.md、Probe.md、ProbeReference.md、DataTransformation.md、LocalVariables.md、TargetPattern.md教程与操作指南CreatingCustomRules.md、DisablingBuiltInRules.md、How-To 目录含 QuickStart、使用 Azure 内置规则、使用非 SQL 探测器完整参考JSON 配置格式旧版扁平格式的 Checks/Probes 结构可作为理解历史格式的补充、探测类型参考、数据转换参考、运算符参考仓库级实证默认规则集 ruleset.json 与可读版 DefaultRuleset.csv、自定义规则集示例 MakingCustomChecks_sample.json 与 DisablingBuiltInChecks_sample.json。需要特别强调的是评估模型的两个内在特性它们决定了自定义规则的编写方式其一规则的最终状态取决于应用顺序——多个规则集按添加顺序逐个应用后添加的规则可以覆盖先添加的规则其二规则定义检查、探测器提供数据、条件判定合规性三者解耦——同一探测器可被多个检查以不同参数、不同转换复用探测器数据在各行之间以 CROSS JOIN 方式组合后再逐行求值。理解这两点就能把哪些对象要查、用什么数据查、什么算合规、违规怎么提示四个问题分别用target/targetFilter、probes、condition、message独立表达出来从而构建出既精确又可维护的自定义评估体系。SQL Assessment API 支持评估 SQL Server 2012 及以上版本与 Azure SQL 数据库托管实例本文所述自定义机制规则覆盖、探测器编写、规则集加载通过Invoke-SqlAssessment的-Configuration参数或 API 的规则集注册接口接入部分高级特性需要 SqlServer PowerShell 模块 22.0.30-preview 或更高版本支持详见 User Guide 说明。赞分享示例工程数据库教程后端【免费下载链接】sql-server-samplesAzure Data SQL Samples - Official Microsoft GitHub Repository containing code samples for SQL Server, Azure SQL, Azure Synapse, and Azure SQL Edge项目地址https://gitcode.com/gh_mirrors/sq/sql-server-samples点击查看免费下载相关推荐MoviePilot 过滤规则 API 实战指南内置/自定义规则、规则组管理与规则测试MoviePilot 过滤规则 API 实战指南内置/自定义规则、规则组管理与规则测试 导读 本文围绕 MoviePilot 仓库中的 Filter APIs后端AI AgentMCP 服务AI 技能Cloudflare WAF 深度实战托管规则集、自定义规则与速率限制配置完全指南Cloudflare WAF 深度实战托管规则集、自定义规则与速率限制配置完全指南 本文源自 GitHub_Trending/skills4/skills 仓人工智能AI 技能AI 插件NightingaleN9EAI 告警规则创建技能实战create-alert-rule 从集成规则包导入到自定义规则全解析NightingaleN9EAI 告警规则创建技能实战create alert rule 从集成规则包导入到自定义规则全解析 Nightingale 内置后端运维观测告警可观测性人工智能AI Agent上一篇Kimi K2 自动化数据分析 pipeline 实战3 段代码跑通一个完整分析工作流下一篇终极指南如何用WoWmapper轻松实现魔兽世界手柄操作创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考