先用
RESTORE FILELISTONLY
FROM disK = 'd:\comcrm.dat'
可以看到备份集里的LogicalName和PhysicalName
PhysicalName先不管,你记下LogicalName就好了
RESTORE DATABASE comcrm20041217 --新库名
FROM disK = 'd:\comcrm.dat' --存放你备份文件的位置及文件名
WITH MOVE 'comcrm_Data' TO 'c:\tcomcrm20041217.mdf', --数据文件还原后存放的新位置
MOVE 'comcrm_Log' TO 'c:\comcrm20041217.ldf' ----日志文件还原后存放的新位置
comcrm_Data,comcrm_Log就是开始记下的数据文件和日志文件的LogicalName
'c:\tcomcrm20041217.mdf','c:\comcrm20041217.ldf' 是还原成的新库的物理文件名
RESTORE FILELISTONLY
FROM disK = 'd:\comcrm.dat'
可以看到备份集里的LogicalName和PhysicalName
PhysicalName先不管,你记下LogicalName就好了
RESTORE DATABASE comcrm20041217 --新库名
FROM disK = 'd:\comcrm.dat' --存放你备份文件的位置及文件名
WITH MOVE 'comcrm_Data' TO 'c:\tcomcrm20041217.mdf', --数据文件还原后存放的新位置
MOVE 'comcrm_Log' TO 'c:\comcrm20041217.ldf' ----日志文件还原后存放的新位置
comcrm_Data,comcrm_Log就是开始记下的数据文件和日志文件的LogicalName
'c:\tcomcrm20041217.mdf','c:\comcrm20041217.ldf' 是还原成的新库的物理文件名
=================================================================
1.你可以试试直接恢复:
restore database comcrm20041217
from disk='x:\comcrm.dat'
2.如果恢复出错,则要知道备份文件的具体内容才好恢复
首先要知道你的备份文件中包含了多少个备份及每个备份的详细信息,用sql语句:
RESTORE HEADERONLY from disk='x:\comcrm.dat'
这样,可以从上面的结果集(结果集列的含义参考sql联机帮助,下同)中,知道你应该恢复的数据库的备份号Position列)
然后,就可以从备份文件中获取你要恢复的这次备份的详细信息:
restore filelistonly from disk='x:\comcrm.dat' with file=xx --xx是备份号
最后,你就可以用下面的语句来恢复了
restore database comcrm20041217
from disk='x:\comcrm.dat'
with file=xx
,move '数据文件名' to '实际恢复后数据文件存放的目录及文件名' --这些信息根据上面的语句查询出来的结果进行修改
,move '日志文件名' to '实际恢复后日志文件存放的目录及文件名'
restore database comcrm20041217
from disk='x:\comcrm.dat'
2.如果恢复出错,则要知道备份文件的具体内容才好恢复
首先要知道你的备份文件中包含了多少个备份及每个备份的详细信息,用sql语句:
RESTORE HEADERONLY from disk='x:\comcrm.dat'
这样,可以从上面的结果集(结果集列的含义参考sql联机帮助,下同)中,知道你应该恢复的数据库的备份号Position列)
然后,就可以从备份文件中获取你要恢复的这次备份的详细信息:
restore filelistonly from disk='x:\comcrm.dat' with file=xx --xx是备份号
最后,你就可以用下面的语句来恢复了
restore database comcrm20041217
from disk='x:\comcrm.dat'
with file=xx
,move '数据文件名' to '实际恢复后数据文件存放的目录及文件名' --这些信息根据上面的语句查询出来的结果进行修改
,move '日志文件名' to '实际恢复后日志文件存放的目录及文件名'
============================================================
sp_change_users_login 'report' //
查看孤立用户
这里可以使用存储过程
sp_change_users_login
。它有三种动作,分别是
report
,
update_one
和
auto_fix
。
sp_change_users_login 'update_one','test','test'
sp_change_users_login 'update_one','hbbt31User','hbbt31User'
sp_change_users_login 'Auto_Fix',NULL,'testpassword'
==================================================
解决方法是使用sp_change_users_login来修复。
sp_change_users_login的用法有三种
用法2:
exec sp_change_users_login 'AUTO_FIX','用户名'
可以自动将用户名所对应的同名登录添加到syslogins中
如果没有建立testuser的登录用户,还可以用
sp_change_users_login 'Auto_Fix','testuser','testpass'
exec sp_change_users_login 'AUTO_FIX','用户名'
可以自动将用户名所对应的同名登录添加到syslogins中
如果没有建立testuser的登录用户,还可以用
sp_change_users_login 'Auto_Fix','testuser','testpass'
=====================================================
在对syslogins表做操作时如果提示:
的解决办法:
在一些网站或者软件系统中,由于安全或者程序异常等问题,可能会在sql Server 2000中造成一个异常问题:在企业管理器中打开数据库发现有一些“坏表”,即无法使用,也无法正常删除。其原因往往是因为在尝试建表的过程中,只向数据库服务器的系统表sysobjects中写入了类型为“U”的记录,却并未真正在数据库中成功创建该表的实体。ok,解决问题有思路了:
delete from sysobjects where [name]='cmd' and xtype='U'
按F5执行,可能会碰到一个错误提示:“未启用对系统目录的特殊更新。系统管理员必须重新配置 sql Server 以允许这种操作。” 解决这个小小的问题的方法是:打开mssql server 属性---》服务器选项----》启用对系统目录的特殊更新(允许对系统目录进行直接修改) 即可。(ps:企业管理器---》工具---》sql Server 配置属性---》服务器设置---》允许对系统目录直接进行修改)之后重新在查询分析器中执行刚才的sql语句。
执行成功后。在企业管理器中会发现那个坏表已经不存在了。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 [email protected] 举报,一经查实,本站将立刻删除。