祝賀SQL版現在高手云聚﹐開個擂台賽如何﹖有問題直管進來﹐1個小時內解決。

meanderer

如题.

安化痞子

rt

2896995

沒有了

leo2003

我们在实际实施系统 (例如工资系统) 时,遇到这样一个问题:

在一台Win2k服务器上运行SQL Server 2000,
SQL Server 数据库中有敏感数据,
现我们不希望这台服务器的管理员查看数据库中的数据。

服务器管理员拥有windows的administrators的密码而没有 SQL 的sa 密码,但他还是可以以windows认证方式进入数据.

问题:
有什么方法可以让服务器管理员拥有windows的administrators的密码，而让他不可以进入M$ SQL Server??


先谢谢了

magicangel

TO leo2003
据我所知，你这种情况没办法。混合认证在QA里还是可以选择通过windows认证方式进入sqlserver。

可以对敏感数据加密。不告诉服务器管理员表结构，相应的内部责任和保密协议

等等看xzh2000有没有办法。

leo2003

谢谢 magicangel ,
现在我们也只能把部份敏感数据加密,
但这样效率较低(因为数据量不少)，
读的时候要解密，
写和更新的时候要加密，
很麻烦.

顺便请教:

有什么好方法可对某个表进行加密解密??

谢了

ufohj

最初由 magicangel 发布
[B]其实所有的死锁最深层的原因就是一个:资源竞争
表现一:
一个用户A 访问表A(锁住了表A),然后又访问表B
另一个用户B 访问表B(锁住了表B),然后企图访问表A
这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B,才能继续，好了他老人家就只好老老实实在这等了
同样用户B要等用户A释放表A才能继续这就死锁了
解决方法：
这种死锁是由于你的程序的BUG产生的，除了调整你的程序的逻辑别无他法
仔细分析你程序的逻辑，
1：尽量避免同时锁定两个资源
2: 必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源.

表现二:
用户A读一条纪录，然后修改该条纪录
这是用户B修改该条纪录
这里用户A的事务里锁的性质由共享锁企图上升到独占锁(for update),而用户B里的独占锁由于A有共享锁存在所以必须等A释
放掉共享锁，而A由于B的独占锁而无法上升的独占锁也就不可能释放共享锁，于是出现了死锁。
这种死锁比较隐蔽，但其实在稍大点的项目中经常发生。
解决方法:
让用户A的事务（即先读后写类型的操作),在select 时就是用Update lock
语法如下：
select * from table1 with(updlock) where .... [/B]

If use "select * from table1 with(updlock) where .... "
Will it cause more locks than before and slow-down the overall performance?
Thanks.

ccwlm741212

啊，我走错了！

-
既然是administrators，那什么不好管啊，目前我知道的唯一的方法：对敏感数据加密！

ccwlm741212

最初由 leo2003 发布
[B]
有什么好方法可对某个表进行加密解密??
[/B]

对关键数据加密解密！不是对表！

自己写一下函授就可以了啊！

ufohj

最初由 ufohj 发布
[B]


If use "select * from table1 with(updlock) where .... "
Will it cause more locks than before and slow-down the overall performance?
Thanks. [/B]

没人知道吗?
谢谢.