计算机改名导致数据库链接的诡异问题

前几天给开发部门部署测试数据库时,遇到一个很诡异的问题:创建一个链接服务器GEK-MIS01时,报错如下:

    消息 15190,级别 16,状态 1,过程 sp_dropserver,第 56 行

    仍有对服务器 ‘GEK-MIS01‘ 的远程登录或链接登录。

脚本如下(略去登录名等关键信息):

 

因为当时是一批脚本执行而且仅有这个脚本出错,当我准备查检查出错原因的时候,又有更紧急的事情要处理,就耽搁了处理这个问题,开发那边在测试过程发现这个数据库链接有问题,邮件反馈给我,我检查时居然发现很多不可思议的现象:

(1): 我用SSMS进入“服务器对象”——“链接服务器”下,居然看不到这个链接服务器对象,而通过sysservers等系统表又能查到这个服务器链接对象的信息,当时我就百思不得其解,纳尼啊?

(2) 重新执行上面脚本时发现删除链接服务器那段脚本根本删除不了该链接服务器,而添加链接服务器时则报错

IF  EXISTS (SELECT srv.name FROM sys.servers srv WHERE srv.server_id != 0 AND srv.name = N‘GEK-MIS01‘)

EXEC master.dbo.sp_dropserver @server=N‘GEK-MIS01‘, @droplogins=‘droplogins‘

GO

EXEC master.dbo.sp_addlinkedserver @server = N‘GEK-MIS01‘, @srvproduct=N‘SQL Server‘

  消息 15028,级别 16,状态 1,过程 sp_addlinkedserver,第 82 行

  服务器 ‘GEK-MIS01‘ 已存在。

(3):接下来我测试了下链接服务器的使用情况,发现有些登录名(Windows 身份认证,sysadmin角色)下使用该数据库链接没有问题,而SQL Server身份验证的登录名则会报下面错误:

  EXEC [GEK-MIS01].DatabaseName.dbo.Procedure  ‘xxxx‘

  消息 916,级别 14,状态 1,第 1 行

  服务器主体 "username" 无法在当前安全上下文下访问数据库 "xxxxx"。

(4):而在SSMS下,在"服务器对象"—>“链接服务器”—> "GEK-MIS01"下单击目录时,报如下错误。

具体错误信息如下:

 

解决办法: 查看当前USER为guest, 执行下面赋权语句即可解决问题

SELECT CURRENT_USER;

GRANT EXECUTE ON SYS.XP_PROP_OLEDB_PROVIDER TO guest;

但是对于现象1,2,3则困扰了我好久,一直以为是权限问题,最后经过吐血的漫长排查,终于发现一个让人吐血的原因:这台测试数据库服务器原先的计算机名称为gek-mis01,后来不知道啥原因被系统管理员用作测试服务器(历史原因了我就不多说了),改名为GETTESTNT15,而一台新的服务器命名为gek-mis01,结果我今天新建链接服务器时,就踩到了这个地雷。

接下来解决起来就比较顺利了,首先删除该链接服务器,修复计算机改名问题,重新新建该链接数据库,OK,问题解决了!

Code Snippet

  1. exec sp_droplinkedsrvlogin‘GEK-MIS01‘ ,‘xxxxx‘
  2. exec sp_dropserver‘GEK-MIS01‘
  3. USE master;
  4. GO
  5. IF SERVERPROPERTY(‘servername‘) <> @@SERVERNAME
  6. BEGIN
  7. DECLARE @server sysname;
  8. SET @server [email protected]@SERVERNAME;
  9. EXEC [email protected]= @server;
  10. SET @server = CAST(SERVERPROPERTY(‘servername‘) AS sysname);
  11. EXEC [email protected][email protected], @local=‘LOCAL‘;
  12. END
时间: 2024-10-06 08:44:34

计算机改名导致数据库链接的诡异问题的相关文章

数据库链接信息加密

业务场景: web项目部署在Tomcat中,数据库链接信息直接明文写在了项目的配置文件中,导致验收不通过,要求把数据库链接信息加密. 项目背景: properties文件存储DataSource信息 spring配置文件中,org.apache.commons.dbcp2.BasicDataSource控制加载DataSource信息 设计方案: properties文件中修改密码为密文 重写BasicDataSource类,在setpassword方法中添加解密步骤 spring配置文件中,用

沫沫金【实践可用】--web工程ORM数据库链接(JDBC)链接集群库||普通库,两种标准

普通链接配置,应用到集群会启动失败,请修改 集群数据库链接 jdbc.url=jdbc:oracle:thin:@//127.0.0.1:1521/momojin 普通数据库链接 jdbc.url=jdbc:oracle:thin:@127.0.0.1:1521/momojin 区别就在于:"//",如上所示 标红的地方.请务必清楚

Oracle 数据库链接

SQL> CREATE DATABASE LINK   mydblink 2    CONNECT TO   test   IDENTIFIED BY   test123 3    USING '(DESCRIPTION = 4      (ADDRESS_LIST = 5        (ADDRESS = (PROTOCOL = TCP)(HOST=192.168.1.210)(PORT = 1521))) 6        (CONNECT_DATA = (SERVICE_NAME = o

EntityFramework 多数据库链接,MySql,SqlServer,Oracel等

环境:EntityFramework5.0,MySql5.6,MSSQL2012 EF是强大的ORM工具,真正意义上的多数据库链接指的是不同类型的数据库,以及同种类型的数据库多个库,EF很好的支持这一点,下面简单演示下: 创建一个MVC4.0,Framework4.5的基本项目,然后重点是WebConfig配置: <?xml version="1.0" encoding="utf-8"?> <!-- For more information on

ORA-00064 processes设置过大导致数据库打不开

processes设置过大导致数据库打不开 在processes设置过大后,可能导致数据库打不开,开启数据库后会报错: SQL> startup ORA-00064: object is too large to allocate on this O/S (1,7746920) SQL> 解决办法: 首先找到pfile位置,然后从pfile启动数据库; startup pfile=$ORACLE_BASE/admin/SID/pfile/init.ora.49201715235' pfile一

EF之MSSQL分布式部署一:EFContext自定义数据库链接

不废话,上代码: 来源:http://bbs.csdn.net/topics/390823046 原文地址:EF之MSSQL分布式部署一:EFContext自定义数据库链接 /// <summary> /// 得到Entity的连接字符串 /// </summary> /// <param name="edmxFullName">Edmx的包括命名空间的全名称</param> /// <param name="server

chattr和lsattr命令,不能被删除、改名、设定链接关系,同时不能写入或新增内容

chattr和lsattr命令详解 chattr命令的作用很大,其中一些功能是由Linux内核版本来支持的,如果Linux内核版本低于2.2,那么许多功能不能实现.同样-D检查压缩文件中的错误的功能,需要2.5.19以上内核才能支持.另外,通过chattr命令修改属性能够提高系统的安全 性,但是它并不适合所有的目录.chattr命令不能保护/./dev./tmp./var目录. lsattr比较简单,只是显示文件的属性[root]#lsattr ----ia---j--- ./lsattr_te

java JDBC 数据库链接

1.准备环境搭建: myeclipse,sql2005,jdbc. 2.都下载完之后开始进行安装 ,前两个是属于数据库软件,正常安装即可(注意数据库登陆不要使用windows验证) <1> 将JDBC解压缩到任意位置,比如解压到C盘program files下面,并在安装目录里找到sqljdbc.jar文件,得到其路径开始配置环境变量 在环境变量classpath 后面追加 C:\Program Files\Microsoft SQL Server2005 JDBC Driver\sqljdb

[20140804] 疑似存储上线导致数据库一致性问题

背景: 同一个存储设备提供了2块存储,1块已经在使用 a,另外一块没有使用b. 疑似: 当b初始化,上线之后,导致在a存储的数据库文件出现一致性问题. 解决方法: 幸好有数据库镜像,打算切换数据库镜像,然后备份数据库镜像,还原到原来的master. 然后创建数据库镜像,在切换到原来的master上. [20140804] 疑似存储上线导致数据库一致性问题,布布扣,bubuko.com