SQL Server帐号的管理——21001错误

       我们在内部测试时大都使用SA/SA的帐号，一般来说客户也给我们SA的权限。偏偏这次客户给的帐号很特别而且权限比较的低。
       假定我们的用户名是abc，程序链接的用户名也是这个abc，数据表的建立者也是abc，但是运行存储过程的时候，对于数据表就需要加上abc.的前缀才能正常运行，非常的麻烦。本地的数据库存储过程写完在客户机就有可能是不适用的。
       一直懒于在我们内部建立abc用户进行测试，一再的不便让我决心建立这个用户。
       在“logins”下没有abc的帐号，但是建立abc后一直提示错误——“Error 21002: [ SQL-DMO] 用户"xxxxx"已经存在 ”，猜想一定是原来建立过abc被删除导致的。
       搜索原因和解决方案，果然如我所料。
       找到了自己的解决方法：
      
     

      使登录用户和数据库的孤立用户对应起来。
       其实我们建立了同样名称的数据库登录用户后，数据库中的表我们照样不能使用时因为sid的不同，就是系统登录表和数据库用户表中的用户名相同，单是sid字段，数据库中的还是以前旧系统的sid值，所以我们就要把它对应成我们新建的，数据库靠sid来识别用户。
       这里可以使用存储过程sp_change_users_login。它有三种动作，分别是report，update_one和auto_fix。
       运行sp_change_users_login 'report'，系统会列出当前数据库的孤立用户数。
       我们只需要选择当前数据库为testdb，然后运行
       sp_change_users_login 'update_one','test','test'
       系统就会提示修复了一个孤立用户。
       如果没有建立test的登录用户，还可以用
sp_change_users_login 'Auto_Fix', 'test', NULL, 'testpassword'
来创建一个登录用户名为test，密码为testpassword的用户与之对应。
         好了，到这里通常情况下，数据库对象得到访问问题已经解决了。如果有多个数据库中有同一个用户的数据表，只需要选择不同的数据库，执行update_one的那个就行了。
       
自己
执行：sp_change_users_login 'report' ——查到了结果中正巧就是abc这条。
执行：sp_change_users_login 'update_one','abc','abc'
一切ok，能正常地设定abc帐号的权限了。
=================================================================================================================
之前查看的一篇文章，但是对我的情况却没有作用。文章如下：

数据库系统虽然只是一套工具,却充满许多乐趣和挑战.
像计算机医师试着找出病症,像侦探试着找出端倪破案,像骑士试着征服野马,像电动游戏试着破关.

举个最常被问到的例子：
很多情况会造成孤儿帐号(Orphan account),当妳你见到银幕上出现[Error 21002: [ SQL-DMO] User "xxxxx" already exists.]讯息时,就是典型的孤儿帐号(Orphan account).

这讯息的意思是：[该帐号虽然看不见,但还是存在的.]或者[其它可能出现的帐号合并症]

这个时候,有了病征和病名,就要来找解方了.
第一道解方是:在该database下,找到sysusers table,看看那悬迨的account是否仍然卡在table里?=>拿掉该account,重新再建一个,就能打开死结.

看似破案容易,但此案的结中结是：
当你妳想从sysusers删掉该account时,另一个chain讯息出现了.
[Error: Ad hoc updates to system catalogs are not enabled. The system
administrator must reconfigure SQL Server to allow this.]

这讯息的意思是:[无权删除系统table]
系统table在default设定是力求保全的,不允许随便更新系统资料.

再一次,有了病征和病名后,再来找解方.
第二道解方如下：

User master
Exec sp_configure 'show advanced option', '1'

'如果出现以下讯息,就要加run下一指令
'confiuration option 'show advanced options' changed from 0 to 1
'Run the RECONFIGURE command to install

RECONFIGURE '若屏幕要求WITH OVERRIDE,就自己加在RECONFIGURE后面吧
EXEC sp_configure
'这时妳你会看见 Server Option 一一列出

EXEC sp_configure 'allow updates', '1'
'这时数据库已开放,允许妳你更动系统tables.
'快去更改/删除该trouble account吧.

EXEC sp_configure 'allow updates','0'


这个过程里也有可能再出第三环岔错,例如：
当妳你要从sysusers table里删除trouble account时,出现阻止删除动作的讯息:
[The selected user cannot be dropped because the user owns objects]
这讯息的意思是:[此帐号是该database的拥有者,妳你无权删除]

这讯息出现的原因,可以被重建现场：
Database=>All tasks=>detach database
然后attach 另一个帐号设定有任何微些不同的同一database.
这个微些不同包括的account setup的程序,内容..等等.
最可能的原因是:attach一个现在MSSQL server里没有的帐号.
也就是,server=>没有该帐号,database=>跟来一个独立帐号,违反了先在server里建立帐号,再assign给database的法则.因此造成Orphen现象.

第三道解方是：
1. 以sp_configure打开'allow updates'
2. 从该新database里,删除孤儿帐号.
3. 记得refresh DB下的Users folder=>可看见孤儿帐号不见了.恭喜!
4. 回到MS Server的Security下,assign一个使用account给该DB.(或者直接在该DB的Users下加入新帐号即可.)
5. 记得关闭sp_configure的'allow updates'许可.
=>
EXEC sp_configure 'allow updates','0'
RECONFIGURE WITH OVERRIDE
EXEC sp_configure

若是妳你真的很失运,那个孤儿游魂一般删不掉,别惊.
下面是第四道解方：
3. delete SQL Server Registration
4. 从SQL Server Group里重新注册该SQL Server.
5. 再从Security建立一个新帐号,assign给新database.
6. 记得关闭sp_configure的'allow updates'许可.

Orphan account是DBA最头痛的事.
即使是事先在server建好帐号,等着[移植]外来新DB,跟来的新帐号,也一样不被养父母DB server承认,真是名符其实的孤儿.

最好的万用解方是,写一个script,把以上四道解方全部放入.
这有两个好处:
1. 毕竟这是偶尔发生的事,滚石易生苔,久不用就忘.
2. 缩短繁褥的侦测抢救过程,数据库的抢救常常是压力很大的,尤其是online的DB.
3. 手头有个account permission记录,最实际.

这个主题是我最常被求救者问到主题之一,希望对你妳也有用.

====================================================
以上之外,还有第二个更简单的解方. (请不要扁我,我真的写到现在才想起来...>_<")

EXEC sp_change_users_login 'report' [<=这是保留字,不要乱改.]
这是要求DB给你妳一份login的报告.妳你可以一目了然,Orphan account的名单.

EXEC sp_charge_users_login 'auto_fix', 'theOrphanLoginName'
这是修补Orphan account.

这方法,是用在SQL2000的版半,我不能确定SQL早期是否有这指令.