存档

文章标签 ‘sqlserver’

Microsoft SQLServer, 错误 : 15023,用户、组或角色’XXX’在当前数据库中已存在如何解决

2018年10月23日 没有评论

为一个数据库添加一个用户或者映射数据库时,提示以下错误信息:
用户、组或角色 ***** 在当前数据库中已存在。 (Microsoft SQLServer, 错误 : 15023)

问题原因:在还原数据库的过程中,在其它sql server服务器上进行还原之后,会出现一个在原服务器上可以正常的用户在目标服务器上出现无法登录的使用。

解决方法:
当数据库恢复到其他服务器时,原数据库中包含一组用户和权限,但可能没有相应的登录或者登录所关联的用户可能不是相同的用户。这种情况可能会出现上面的问题。该问题是无法通过新建登录或者是对同名登录授予对应数据库的“用户”权限来解决登录问题。由于SQLServer会提示“错误15023:当前数据库中已存在用户或角色”,要解决这个问题,需要调用系统存储过程sp_change_users_login,具体用法如下:

1.打开SQL Server Management Studio, 右键选择“数据库”>“新建查询”
输入以下sql脚本:

Use 数据库名
go
sp_change_users_login update_one, XXX, XXX

接着执行脚本即可。

注:其中update_one是存储过程的参数,表示只处理一个用户,前一个XXX是“用户”,后一个XXX是“登录”,以上这个SQL表示将服务器登录“XXX”与数据库用户“XXX”重新关联。

错误3456:未能恢复日志记录 SQL2000数据库置疑解决方法

2015年9月28日 没有评论

一次客户由于硬盘损坏,种种原因下,我当时仅仅只拿到了备份了的mdf文件,那么恢复起来就是一件很麻烦的事情了。

SQL2000数据库置疑解决方法
按下面的步骤处理:
1.新建一个同名的数据库
2.再停掉sql server服务
3.用备份的数据库MDF的文件覆盖掉这个新建的同名数据库文件
4.再重启sql server服务
5.此时打开企业管理器时新建的同名数据库会出现”置疑”,先不管,执行下面的语句(注意修改其中的数据库名)

?View Code SQLSERVER
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE
GO
UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='数据库名'
Go
sp_dboption '数据库名', 'single user', 'true'
Go
DBCC CHECKDB('数据库名')
Go
update sysdatabases set status =28 where name='数据库名'
Go
sp_configure 'allow updates', 0 reconfigure with override
Go
sp_dboption '数据库名', 'single user', 'false'
Go

ok数据能访问了


操作一下发现有部分表不能select不能写入操作错误:“发生错误:-2147467259,未能在数据库 ‘XXX’ 中运行 BEGIN TRANSACTION,因为该数据库处于回避恢复模式”
这时,数据库本身一般还有问题,解决办法是,利用
数据库的脚本创建一个新的数据库,并将数据导进去就行了.
企业管理器–右键你的数据库–所有任务–导出数据
–目标标数据库选择新建
–选择”在两个sql数据库之间复制对象和数据”
–把”包含扩展属性”选上,其他的根据需要选择
–最后完成

注:以上如果失败,一般会提示xxx用户不在。在sql用户管理里建立附于新数据库权限再导一次数据即可。

以下是转别人的一些处理过的办法和经验,给于大家参考。

SQLSERVER数据库文件损坏处理2例
WINDOWS2000
SQLSERVER2000
这段时间遇到了好几起由于数据库文件损坏,而造成客户系统暂停使用的情况。在恢复过程中查阅参考了几篇网上的技术文章,实际操作过后感觉有必要承前启后一下,因此将恢复过程做个记录。
案例1:
客户报告中午正常使用的系统,下午无法打开,报告的是连接数据库错误。电话中初步判断是数据库启动失败。首先告知客户无法立即恢复,先转成手工操作。
到达客户处,首先检查“事件查看器”,发现系统日志文件损坏,事件查看器无法显示系统日志。只能首先删除清空,并重建事件日志文件。然后再启动sqlserver,这时候就可以在事件查看器中看到sqlserver启动失败的错误信息了。错误大概是说 “启动过程中master数据文件损坏,数据库无法恢复”。由于master是系统数据库,因此SQLSERVER无法启动。
此服务器以前曾经发生过windows2000操作系统崩溃,曾经备份过SQLSERVER的 DATA 目录,万幸,把master的两个数据文件覆盖过来(master.mdf,mastlog.ldf)后,数据库就可以启动了。
测试一下,怎么程序还是不能打开,都快出汗了。一看,客户数据库居然是“质疑”的。再看事件查看器有”Disk”错误,连忙找备份,好在管理员在前一天中午做过数据备份。恢复并将数据文件转移到另一个硬盘分区上,至此系统操作正常。至于丢失的一天数据让客户找时间再补入系统。
分析原因:客户表示没有非法关机,停电等故障。因此有可能是硬盘出现坏道,或者是内存品质不良。因此与客户协商,准备先更换一块硬盘,再跟踪使用情况。
案例二:
某天给客户升级报表,第二天早上,客户打电话来说系统不能打开。初步判断也是数据库启动失败。询问客户也没有修改过机器名,管理员密码。通过VNC连上客户服务器发现,还是MASTER数据库损坏。
这时候情况比较复杂,由于是新安装的系统,运行还不满一个月。实施时由于疏忽没有做过任何备份。只能尝试将其他电脑上的master数据文件拷贝过来。我笔记本上的SQLSERVER是desktop版,与服务器上安装的不符。没办法,只能死马当活马医了。压缩,发送,折腾了半个小时才把文件发送到客户服务器上。覆盖… 启动… ,绿色箭头出来了。居然成功了。
打开企业管理器,这时,客户数据库的属性都变成和我笔记本上的数据库一样了。密码,用户数据库。当然由于部分数据文件不一样,所有的用户数据库都是质疑的。删除不存在的用户数据库,然后附加客户自己的数据库。
通常,附加数据库后,系统应该就可以使用了。但没想到的是这个客户数据文件也是损坏的,附加数据库失败。这下恢复过程陷入僵局。虽然数据没用多少天,但库中有关键数据必须恢复。
附加数据库错误提示:
“错误3456:未能恢复日志记录(***:***:x)事务 ID(0:***xx)……等等”
怀疑是日志文件损坏,只能寄希望于数据文件没有损坏。删除数据库日志文件,单独附加数据库文件,结果还是失败,报告“日志文件不符”。
由于远程操作过于缓慢,只能将客户数据文件压缩传回本地,再想办法进行修复。
首先上网找了几篇丢失数据库日志文件的恢复数据的文章。
http://www.jaron.cn/chs_db/20/20 … ticle_view_1587.htm
由于数据日志中还有活动事务,文中第一种方法显然不适用我这种情况。遂按照第二种方法将数据库设置为紧急模式。当做到 DBCC CHECKDB 时。结果就与文章表示的不同了。
服务器: 消息 3908,级别 16,状态 1,行 2
未能在数据库 ‘sttzjg’ 中运行 BEGIN TRANSACTION,因为该数据库处于回避恢复模式。
此时网上的文章都没有提示找不到进一步的处理方法了。这时直接做DTS数据导出也是报错:DTS Wizard报告说“初始化上下文发生错误”。
不过万幸的是,这时候已经可以SELECT数据了。但有几个表 SELECT的时候报告:
服务器: 消息 601,级别 12,状态 3,行 1
由于数据移动,未能继续以 NOLOCK 方式扫描。
不能使用DTS, 常用的mssql2工具也不行。没有办法了,只能用SELECT手工恢复数据。首先新建一个新的业务数据库new,然后使用 “insert into new.dbo.table select * from *** “一个一个拷贝数据表。化了一个多小时,最后只剩下那三个SELECT也报错的表了。
试试bcp,也报错,不过数据倒是导出来了,这下就好办了。用bcp把能导出的数据导到新库。至此数据库基本恢复。检查报表,发现也是丢失了一天的数据。时间节点上看,大概就是增加报表之后的一天的数据全部丢失,主要就是那三张SELECT报错的表中。
继续检查事件查看器中的内容,没有发现严重的磁盘错误。开关机的日志也很正常,很奇怪,不知道什么情况会造成一整天的事务日志没有完成,而且还造成master数据库损坏。想不出来原因,还是先给客户设置好每日的数据自动备份。以后再出现这种情况也好处理一些。
总结:我们的客户使用的服务器都很一般,数据库备份相当重要,培训客户做好备份,减少由于系统故障造成的数据损失。

数据库主体在该数据库中拥有架构无法删除解决方法

2015年9月23日 没有评论

先删除此用户对应的架构,然后在删除对应的用户
步骤
1。SQL SERVER MANAGEMENT STUDIO > 数据库 > 安全性 > 构架,先删除对应的构架

2。SQL SERVER MANAGEMENT STUDIO > 数据库 > 安全性 > 用户,删除对应的用户 其它方法: SQL2005删除用户的时候,产生“数据库主体在该数据库中拥有架构,无法删除”的解决办法 –执行如下SQL语句 ALTER AUTHORIZATION ON SCHEMA::db_owner TO dbo; –然后手动删除就可以了。

但在删除的过程中,可能会出现删除不了的情况,这时候需要手动将已经引用过的架构用户改为系统帐户,以下是相关SQL语句:

?View Code SQLSERVER
1
2
3
4
5
6
7
8
9
10
11
12
13
14
declare @name sysname
declare csr1 cursor 
for
select name from sysobjects where xtype ='TF'
open csr1
FETCH NEXT FROM csr1 INTO @name
while (@@FETCH_STATUS=0)
BEGIN
    SET @name='bbsdata.' + @name
    exec ('ALTER SCHEMA dbo TRANSFER ' +  @name)
    fetch next from csr1 into @name
END
    CLOSE csr1
    DEALLOCATE csr1
?View Code SQLSERVER
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
declare @name sysname
declare csr1 cursor 
for
select name from sysobjects where xtype ='U'
//请注意上下一行不同点,我们用Xtype来定义我们需要查找的表//
open csr1
FETCH NEXT FROM csr1 INTO @name
while (@@FETCH_STATUS=0)
BEGIN
    SET @name='bbsdata.' + @name
    exec ('ALTER SCHEMA dbo TRANSFER ' +  @name)
    fetch next from csr1 into @name
END
    CLOSE csr1
    DEALLOCATE csr1

代码很简单,就是一个简单的循环操作,但比手动去将每个表的架构改回来却是省了很多功夫的!

希望对大家有所帮助

分类: 解决方案 标签: ,