腾讯云在10月20日发出公告，云数据库SQL Server的实例从10月31日起会默认多出一个系统库td_admin。新建实例直接带上，存量实例分批灰度创建，不影响可用性也不用重启。
这个库由系统自动维护，只放登录审计日志和相关系统配置，日志保留近一个月。它不承接任何应用写入，也不该出现业务对象。看实例下的数据库列表里有没有这个名字，就知道灰度有没有到这台机器。
把审计日志搬进库里的原因写在公告里：日志持久化之后纳入主备同步，主备切换时审计记录不会断。主备切换是这类日志最容易断的地方。
公告列了三条禁止：不要删除或重命名这个库，不要修改其中的对象和数据，不要自己建一个同名的库。三条指向同一个问题——这个库由系统维护，动了之后登录审计和其他依赖它的功能会出问题。同名的库还会跟系统的直接撞上，报错位置很难定位到根因。等系统把其他内部数据也归集进来时，这类冲突只会更多，这个库的体量也会变大，备份体积的估算要跟着调。
多出来的一个库名落到运维上，最先受影响的是那些按库名遍历的脚本。有些团队习惯把业务表放在某个固定库里，备份和巡检脚本遍历实例下所有数据库，多出来的库会被一并处理。备份策略、账号权限、监控采集如果按实例下所有库配置，td_admin会被纳进范围。
要查的地方集中在三处。备份任务如果是全实例备份的，多出来的库会让备份体积增加，备份链路要能正常处理它；权限脚本如果按库授权，多出来的库不需要授权，别误授给业务账号。
第三处是巡检脚本，遍历所有库做表数量或索引检查的，要把这个库排除掉，否则报出来的数字会变。顺序上先改备份和巡检，这两项影响面最大，权限那项改动最小，可以最后做。脚本里如果有库名白名单，也要把td_admin补进去。按库数量做容量估算的，这个系数从此要减一，连接数的估算同样要跟着改。
10月31日之后新建的实例都带这个库，之后腾讯云还会把其他内部系统数据逐步归集进来，那次会另行公告。存量实例的灰度分批进行，时间跨度可能不止一天。眼下不需要做任何操作。真正要动的是机器上那些按库名遍历的脚本，它们不会报错，只会悄悄多出一条记录。等哪天台账发现备份大小和实例数对不上，才会回头找这个原因。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
