主页 / dba / 问题 / 326126
Accepted
marcin2x4
Asked: 2023-04-18 20:37:40 +0800 CST

SQL Server 服务器名突然改变

  • 772

我注意到我的@@ServerName参数值在我不知情的情况下被更新了，有没有办法追溯那个改变的人和时间？

我正在运行 AWS EC2 托管的 SQL Server 2016 标准版。

在此处输入图像描述

只是@@SERVERNAME已经改变了。

sql-server

4 个回答

  1. Best Answer

    我注意到我的@@ServerName 参数的值在我不知情的情况下被更新了，有没有办法追溯那个改变的人和时间？

    和

    仅@@SERVERNAME 已更改

    这意味着物理主机名没有改变，所以我不确定为什么其他答案会指向您。

    这很可能是通过 sp_[drop/add]server 完成的，如果您正在使用任何 t-sql 审计或跟踪，它将显示出来。如果不是，它不会出现在任何默认日志中。您可能会很幸运并检查主数据库的日志文件（例如 fn_dblog），但您不太可能获得任何有用的信息，因为主数据库使用简单恢复模型并且全局变量仅反映重启后的更改服务。

    您可能希望在以后实施某种类型的审计或跟踪。

    • 3

  2. 让我重复肖恩的话。可以肯定的是，我只是对此进行了重现，同时 Sean 发布了他的答案。无论如何：

    @@SERVERNAME 返回 sys.servers 表中的内容（或者，因为它是一个视图，所以是基础表）。

    您所看到的表明有人使用 sp_dropserver 和 sp_addserver 更改了它。我执行了 sp_dropserver 和 sp_addserver 过程并检查了三个常见的“默认审计”嫌疑人，但看不到这些 sp 正在执行的任何痕迹。因此，您需要进行一些自己的审核才能发现这一点。这是我的复制品（我的机器名称已更改）：

    SELECT @@SERVERNAME --Returns 'xyz', my machine name
EXEC sp_dropserver 'xyz'
EXEC sp_addserver 'GammaRay', 'LOCAL'
SHUTDOWN
--Start your SQL Server

SELECT @@SERVERNAME --Returns 'GammaRay'

--check errorlog files, nothing
--check default trace, nothing
--check system_health XE session, nothing

--Reset the name to the old name
EXEC sp_dropserver 'GammaRay'
EXEC sp_addserver 'xyz', 'LOCAL'
SHUTDOWN

    更新 1：我被要求通过查看日志记录来添加操纵 sys.servers 基础表的证据，使用以下查询：

    SELECT * 
FROM ::fn_dblog(NULL, NULL) 
WHERE AllocUnitName IN ('sys.sysxsrvs.cl','sys.syslnklgns.cl')

    所以我做了，并且 sp_dropserver 命令生成了这些日志记录（不是所有的列都发布了，对格式感到抱歉）

    LOP_DELETE_ROWS LCX_MARK_AS_GHOST   sys.sysxsrvs.cl
LOP_SET_BITS    LCX_PFS sys.sysxsrvs.cl
LOP_DELETE_ROWS LCX_MARK_AS_GHOST   sys.syslnklgns.cl
LOP_SET_BITS    LCX_PFS sys.syslnklgns.cl
LOP_SET_BITS    LCX_PFS sys.syslnklgns.cl
LOP_SET_BITS    LCX_PFS sys.sysxsrvs.cl

    以下 sp_addserver 生成了这些：

    LOP_INSERT_ROWS LCX_CLUSTERED   sys.sysxsrvs.cl
LOP_MODIFY_ROW  LCX_CLUSTERED   sys.sysxsrvs.cl
LOP_MODIFY_ROW  LCX_CLUSTERED   sys.sysxsrvs.cl
LOP_INSERT_ROWS LCX_CLUSTERED   sys.syslnklgns.cl
LOP_MODIFY_ROW  LCX_CLUSTERED   sys.syslnklgns.cl

    上面可能有一些不相关的噪音，我应该补充一下。

    目视浏览查询的完整输出，我找不到任何明显突出的内容。我想您可以尝试解码包含十六进制信息的列，例如“RowLog contents n”和“Log Records”。

    但是，由于 master 实际上停留在简单恢复中，因此重新启动后此信息丢失。即，启动后，查询返回零行。至少为了正常关机。您可以推测硬关闭可能不会生成会截断日志的检查点（但它可能会在启动时的崩溃恢复时被截断），但是，我发现重命名服务器名称的进程不太可能“ sys.servers 表”还会通过强行终止 SQL Server 进程来重新启动 SQL Server 实例。

    • 2

  3. 也许您可以在服务器级别找到它。正如 White Owl 已经提到的，它以系统管理员的名义出现。

    您可以通过从系统日志中的源事件日志中查找事件 ID 6011 来确定计算机名称何时更改。6011 在事件 ID 6006“事件日志服务已停止”之后、事件 ID 6009 和事件 ID 6005“事件日志服务已启动”之前重新启动时记录。

    从如何确定计算机名称何时更改

    • 1

  4. 不。

    服务器名称掌握在系统管理员手中。因此，找到更改名称的时间（以及原因）的唯一方法是询问 SA。通常，管理人员的大量讨论和参与会很好地记录基础架构中的如此大的变化。

    但是没有用于更改系统级变量的日志。

    • 0

相关问题