删除用户MyUser,重新建立一个.

解决方案 »

  1.   

    TO:dawugui(潇洒老乌龟)我目前就是先删除的,但是这样太麻烦我是问如何能使其统一
    最好只用TransSql执行
      

  2.   

    你的SQL Server备份做好了吗?可以安心睡觉了吗? 如果你是一位DBA老手,在看完我的文章后,如果发现有错误之处,欢迎批评指正。 如果你做DBA时间不长,对数据库的备份有些担心,希望能找到一种让你放心的备份方 
    案,那么本文绝对适合你。 关于数据库的备份恢复原理,大家多少都比较熟悉了。但是,你目前做的数据库备份有 
    多可靠?你可以安心睡觉了吗?如果答案是肯定的,那就不用多花时间看下文了,如果 
    觉得还不够安心,总担心数据库哪一天坏了修不好,那么请接着看: [1] 我有RAID,还需要做数据库备份吗?需要。有了RAID,万一部份磁盘损坏,可以修 
    复数据库,有的情况下数据库甚至可以继续使用。但是,如果哪一天,你的同事不小心 
    删除了一条重要的记录,怎么办?RAID是无能为力的。你需要合适的备份策略,把那条 
    被误删的数据恢复出来。所以有了RAID,仍需要做备份。 
    集群,磁盘镜像同理。 
    [2] 如果你只做全备份,那么受限于全备份的大小和备份时间,不可能常做。而且只有 
    全备份,不能将数据库恢复至某个时间点。所以,我们需要全备份+日志备份。比如每 
    天一个全备份,每隔1小时或若干分钟一个日志备份。说到差异备份,因为微软的差异 
    备份记录的是上一次全备份以来发生的变化,所以,如果数据库的改动很频繁的话,没 
    过多久,差异备份就会和全备份的大小接近,因此这种情况下就不合适了。因此,全备 
    份+日志备份的方案适合绝大多数的用户。 
    [3] 如果你仅在数据库本地做备份,万一磁盘损坏,或者整个服务器硬件损坏,备份也 
    就没了,就没法恢复数据库。因此,你需要把备份文件传送至另一个物理硬件上。大多 
    数用户不用磁带机,因此不考虑。一般,我们需要另一台廉价的服务器或者PC来存放数 
    据库的备份,来防止硬件损坏造成的备份丢失。 
    [4] 你可以在数据库服务器本地做完备份,然后使用某些方式将备份文件传送至备机。 
    你是在备份完成后就马上穿送的吗?其实可以考虑将传送备份的脚本用T-SQL语句来 
    写。 
    [5] 备份文件传送至备机后,就可以高枕无忧了吗?不。作为DBA的你还需要检查备机 
    上的备份文件是否能将数据库恢复至最新,如果采用日志备份,会不会因为丢失某一个 
    日志备份文件而导致数据库不能恢复至最新?如何检查日志备份文件之间存在断档? 
    [6] 为了将数据库尽可能的恢复到最新,你可能会每隔10分钟(甚至1分钟)执行一次 
    日志备份,那么万一数据库坏了,在恢复的时候,手动恢复成百上千个日志文件,是不 
    是不太现实? 
    [7] 如果你所在公司有很多的数据库服务器(就像我所在的公司),而且磁盘空间有限 
    ,那么你不得不经常登录服务器来删除旧的备份文件,如果哪天忘了,或者五一十一长 
    假,磁盘空间用完了,就麻烦了。 
    [8] 数据库在备份的时候,并不会检查数据页面的完整性,如果数据页坏了,备份作业 
    仍会执行,而且不会报错,等到你发现数据页有错误的时候,你也很可能已经因为磁盘 
    空间不足,而删除了早期的备份,而此时剩下的那些备份可能都是包含损坏的数据页, 
    如果损坏的数据页是某个表的表头的话,那这个表你就再也没办法恢复了。 
    [9] 所以你需要定期执行DBCC检查,来尽早发现数据库页面的完整性。在未作完DBCC检 
    查之前,你不能删除旧的备份,以防止新的备份存在问题。所以,删除备份文件的工作 
    变的有些麻烦。 
    [10] 你可能知道SQL Server提供了数据库维护计划。没错,使用它可以定期做备份, 
    执行DBCC检查,但这一切仅限于本机操作。为了使数据库可靠,你还是需要自己把本地 
    备份传送至备机。 综上,你的备份做好了吗?检查了吗?删除旧的备份是不是花去你很多时间,特别是在 
    网络条件不好的时候?如果数据库备份文件的传送在某一时刻停止了,你多久才能发现 
    ?公司值晚班的同事有权限检查数据库的备份情况吗? 如果有兴趣的话,可以尝试使用我的解决方案,花一点小钱,帮你解决以上所有问题, 
    让你安心睡觉。 
    本人多年从事MSSQL的管理和开发,曾在上海多个高校及培训中心讲授相关课程。对 
    MSSQL有较好的认识和理解,以及较丰富的工作经验,N次的将数据库从灾难中恢复出 
    来。 
    现在和朋友一起设计了一款针对MSSQL的备份恢复系统。该系统安全可靠,第一版本已 
    经在我目前工作的公司运行了一年,近50台MSSQL服务器,已经历了多次的数据库灾难 
    ,每次都成功的救回了数据库。目前设计的第二版,采用第一版的核心技术,根据第一 
    版的使用反馈,融入了很多更可靠、管理更轻松的理念,是我本人和一些同行都感到较 
    为满意的一个产品。使用该产品: [1] 你可以安心睡觉了。如果不放心的话,尽管测试,把各种可能的灾难都测试几遍, 
    就放心了。 
    [2] 可靠安全。系统会检查备机上的备份文件,分析这些文件的内部信息,并报告可以 
    将数据库恢复到什么时刻,如果可恢复时刻与数据库当前时刻的差达到预定义的值(比 
    如某一时刻起网络故障导致备份文件无法传送至备机),就会报警,这样你就有尽可能 
    多的时间来排除故障。 
    [3] 最大程度减少工作量。所有数据库服务器的备份信息和可恢复信息都集中在一台主 
    控制机上显示,不用逐个登录检查。系统自动执行备份,自动执行检查,自动删除旧的 
    备份,保证磁盘上剩下的备份文件能将数据库恢复至最新。所以,如果数据库备份正常 
    ,你不用做任何维护操作,只需有人看着主控制机显示器的报告信息,就足够了。 
    [4] 万一数据库坏了,主控制机会提供给你恢复数据库所需的脚本,用于将数据库恢复 
    至最新/恢复至时间点/恢复成另一个数据库。你可以方便的将该脚本粘贴到备机的 
    Terminal服务器上执行。如果你的恢复策略中需要执行上千个日志文件的恢复,没有问 
    题,这些脚本都会由主控制机提供,不需要任何的改动,只需要运行就可以了。 我和公司的劳动合同马上要到期了,之后,打算暂时不找新的工作,推广我的备份恢复 
    系统,希望给广大的朋友提供方便的同时,自己也能得到些许回报。 
    相信很多高手也有自己的备份方案,但相信也有很多入门不久的朋友,需要一个可靠的 
    备份方案,数据库的备份恢复是个不算简单的问题,要保证可靠的话,需要投入很多的 
    时间和精力去学习,还可能需要一些经验的积累。有的朋友可能也不是以数据库为主, 
    也不打算在这方面花太多的时间,所以我的产品应该是有一定的市场的。但是我也不想 
    打没有准备的仗,所以在此先提出这样的想法,想听听大家的意见和建议。 [1] 有兴趣使用我介绍的这款备份恢复系统吗? 
    [2] 你已经找到类似的替代品了吗?收费的还是免费的? 
    [3] 如果该产品能满足你的需求,你愿意承担的价位是? 如果有兴趣的话,可以发送邮件至 [email protected] 索取演示版,邮件中麻烦 
    回答一下上述的3个问题。谢谢!另外,本人承接企业培训项目。 
      

  3.   

    这个问题最终是通过
    sp_change_users_login这个存储过程来实现的。
    具体用法,读者可以查sql帮助。