SQL2008 dbo 账户 孤立无法消除

Question

公司里的数据库升级到sqlsvrstd 2008 R2后，数据库从2005的备份还原后，系统无法正常运行，使用
（SELECT u.name AS "Name", ISNULL(l.name, 'dbo is unmatched') AS "Matched Login"
FROM sysusers u
LEFT JOIN master.dbo.syslogins l ON u.sid = l.sid
WHERE u.name = 'dbo'）后发现该数据库的dbo 用户被孤立，（dbo is unmatched），
执行：
SP_CONFIGURE 'allow updates',1
RECONFIGURE WITH OVERRIDE
GOUPDATE sysusers SET sid=0x010100000000000512000000 WHERE NAME='dbo'
Gosp_configure 'allow updates', 0
reconfigure with override
Go
消息：
配置选项 'allow updates' 已从 0 更改为 1。请运行 RECONFIGURE 语句进行安装。
消息 259，级别 16，状态 1，第 2 行
不允许对系统目录进行即席更新。
配置选项 'allow updates' 已从 1 更改为 0。请运行 RECONFIGURE 语句进行安装。

以上问题如何处理，困扰了很长时间。先谢谢！

Answer 1

Can't update system tables since sql2k5, you can reset dbo with sp_changedbowner.

Answer 2

It's done, You helped. Thanks a lot!

Answer 3

消除了dbo账户孤立的问题，不过原来的一个问题还存在，现象是客户端生成的计划任务执行总是失败，日志如下：已以用户 vitmgr 的身份执行。 拒绝了对对象 'sp_start_job' (数据库 'msdb'，架构 'dbo')的 EXECUTE 权限。 [SQLSTATE 42000] (错误 229).  该步骤失败。,00:00:00,14,229,,,,0，,

Answer 4

消除了dbo账户孤立的问题，不过原来的一个问题还存在，现象是客户端生成的计划任务执行总是失败，日志如下：已以用户 vitmgr 的身份执行。 拒绝了对对象 'sp_start_job' (数据库 'msdb'，架构 'dbo')的 EXECUTE 权限。 [SQLSTATE 42000] (错误 229).  该步骤失败。,00:00:00,14,229,,,,0，,

是不是权限的问题。

”拒绝了对对象 'sp_start_job' (数据库 'msdb'，架构 'dbo')的 EXECUTE 权限“

---

If you haven't all the things you want,be grateful for the things you don't have that you didn't want.

Answer 5

的确是权限问题，不过已赋予用户vitmgr最高权限了，问题依旧

Answer 6

What kind of permission does vitmgr have in msdb?

Answer 7

看错误提示，是在 msdb 没有权限，sp_start_job 需要的权限如下：

 

默认情况下，只有 sysadmin 固定服务器角色的成员才可以执行此存储过程。其他用户必须被授予 msdb 数据库中下列 SQL Server 代理固定数据库角色的权限之一：

 

• SQLAgentUserRole
  
  
• SQLAgentReaderRole
  
  
• SQLAgentOperatorRole
  
  

 

有关这些角色的权限的详细信息，请参阅 SQL Server 代理固定数据库角色。

 

SQLAgentUserRole 和 SQLAgentReaderRole 的成员只可以启动他们所拥有的作业。SQLAgentOperatorRole 的成员可以启动所有本地作业，包括其他用户所拥有的本地作业。sysadmin 的成员可以启动所有本地作业和多服务器作业。

Answer 8

请问你给了用户vitmgr什么权限呢？

---

it's time to start living the life you are imagined.

Answer 9

赋予了vitmgr这个用户sysadmin的角色，感谢各位热心的解答！

Answer 10

Not a good practice, never grant users more permission than what they need.