13518219792
我就实话实说了，也不说些假安慰的话了，如果数据损坏，那就看你有没有备份过了，有备份的就幸运了，如果没有的话，而你自己又不懂数据库恢复，那只有请人帮忙恢复了，而且不一定能修复，数据库修复是一个很复杂的问题，而且问题可大可小啊，需要懂的很多，而且没有保证一定就能修复，看情况而定
公司主营业务：网站设计制作、网站建设、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。成都创新互联是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。成都创新互联推出亳州免费做网站回馈大家。
恢复sqlserver数据库表数据步骤如下：
一、心态：
1、务必冷静，事情已经发生不可慌乱。
2、立即查看当前时间，最好能够精确到秒,并做记录。
3、应立即向直接上级反映此事，不可隐瞒，防止事态扩大。
4、如果权限允许，应当立即停止相关应用，防止有新的数据写入数据库。
二、恢复：
1、构建新数据库以及写入一些数据
2、做一次完整备份，这个是前提，没有一份完整备份文件是无法进行接下来的操作的。
注意：如上图所示，恢复模式一定要说完整，如果是其他类型那恐怕就没有下文了。一般来讲新建数据库的时候，默认不要去改恢复模式这个属性。
3、写入一条新数据。
4、记住此时要记录时间点。
此刻最好看一下系统时间。接下来就要演示如何进行数据恢复。
5、做事务日志备份，做事务日志备份需要注意一下一点，如图所示。
备份模式请选择事务日志，备份路径自行决定
进入选项，将可靠性第1、2勾选，事务日志选择第二个，压缩属性可以不选择.点击确定备份成功，此时数据库将显示为正在还原状态
注意：如果备份失败，请检查该数据库是否正在被占用，如果是请kill。
6、还原完整备份。
数据库处于正在还原状态，右键数据库--任务--还原--文件和文件组，选择最近的一次完整备份。此时，需要在“选项”中选择第二种还原方式，具体如下图。
如上图，勾选完整数据备份文件。
如上图，恢复状态选择第二种，从字面意思就知道为什么要选择这种。
7、接着还原备份的事务日志。
完整备份还原完毕，接着要对事务日志进行还原，右键数据库--任务--还原--事务日志，如下图：
还原事务日志的时候需要特别注意“时间点”这个设置，其他不需要设置。
时间点选择为误删数据的时间点之前就可以恢复出误删的数据，所以之前强调要查看一下时间。如下图所示
点击确定，在确定等待还原成功，数据库变成可用状态。如下图。
如果查询发现数据不是你想要的，那么可以重复上述的操作，从备份事务日志开始，然后最后选择时间点的时候在缩小范围。
SQL Server2000安装盘进行修复安装，应该可以解决你的问题！
如还存在问题可以追问，当及时回答！
希望能帮到你！
用备份还原一个新的库，并把新库中的表数据同步回去。
你可以做完整恢复，或者时间点恢复。但是对于大数据库，是非常耗时和耗费磁盘空间的。雷达下载更专业。
这个方法仅仅用于还原数据，在还原数据（就是同步数据）的时候，你要考虑触发器、外键等因素。
sqlserver附加数据库错误823的解决方案
一、SQL-Server附加数据库时失败。
1、异常情况：服务器在正常运行的情况下突然断电，导致数据库文件损坏，具体表现是：数据库名后面有“（置疑）”字样。
2、异常分析：关于823错误的 SQL-SERVER 中的帮助：
================================
错误 823
严重级别 24
消息正文
在文件 "%4!" 的偏移量 %3! 处的 %2! 过程中，检测到 I/O 错误 %1!。
解释
Microsoft SQL Server 在对某设备进行读或写请求时遇到 I/O 错误。该错误通常表明磁盘问题。但是，错误日志中在错误 823 之前记录的其它核心消息应指出涉及了哪个设备。
3、解决办法：
在SQL-Server企业管理器中，新建同名数据库（这里假设为Test）后，停止数据库，把损坏的数据库文件Data.mdf和Test_log.LDF覆盖刚才新建数据库目录下的Data.mdf和Test_log.LDF，同时删除Test_log.LDF文件；启动数据库服务，发现数据库名Test后面有“置疑”字样。不要紧，打开SQL自带查询分析器，分别执行如下SQL语句：
第一、
exec sp_configure 'allow updates',1 RECONFIGURE WITH OVERRIDE /* 打开修改系统表的开关 */
第二、
update sysdatabases set status=32768 where name='数据库名' /* 设置数据库状态 */
第三、
DBCC REBUILD_LOG ('数据库名','D:\database\Test_Log.LDF') /* 重建LDF文件 */
第四、
update sysdatabases set status=0 where name='数据库名' /* 重置数据库状态 */
第五、
restore database 数据库名 WITH RECOVERY /* 恢复数据库 */
第六、
exec sp_configure 'allow updates',0 RECONFIGURE WITH OVERRIDE /* 关闭打开修改系统表的开关 */
按照此方法操作，应该能修复数据库正常访问了。如果问题依然存在，最笨的一个方法就是新建另一个数据库，把原数据库（Test）各个表的数据导出到新建数据库表中。
============================================================
补充说明：用上面的六步把数据库置疑的问题解决了，但是数据库表里还有损坏的表(inf_gdscode)，把坏表导出的时候也不成功。最后在查询分析器里运行：
USE nmgbt_hcxuexipos (数据库名)
GO
DBCC CHECKTABLE ('inf_gdscode',REPAIR_ALLOW_DATA_LOSS)
GO
具体方法有3种。
方法一:
第一步：
backup
log
database_name
with
no_log
或者
backup
log
database_name
with
truncate_only
--
no_log和truncate_only是在这里是同义的，随便执行哪一句都可以。
第二步：
1.收缩特定数据库的所有数据和日志文件，执行：
dbcc
shrinkdatabase
(database_name,[,target_percent])
--
database_name是要收缩的数据库名称；target_percent是数据库收缩后的数据库文件中所要的剩余可用空间百分比。
2.收缩一次一个特定数据库中的数据或日志文件，执行
dbcc
shrinkfile(file_id,[,target_size])
--
file_id是要收缩的文件的标识
(id)
号,若要获得文件
id，请使用
file_id
函数或在当前数据库中搜索
sysfiles；target_size是用兆字节表示的所要的文件大小（用整数表示）。如果没有指定，dbcc
shrinkfile
将文件大小减少到默认文件大小。两个dbcc都可以带上参数notruncate或truncateonly，具体意思查看联机帮助.
方法二：
第一步：
先备份整个数据库以备不测
。
第二步：
备份结束后，在query
analyzer中执行如下的语句：
exec
sp_detach_db
yourdbname,true
--卸除这个db在mssql中的注册信息
第三步：
到日志的物理文件所在的目录中去删除该日志文件或者将该日志文件移出该目录
第四步：
在query
analyzer中执行如下的语句：
exec
sp_attach_single_file_db
yourdbname,'
d:\mssql\data\yourdbname_data.mdf
'
--以单文件的方式注册该db，如果成功则mssql将自动为这个db生成一个500k的日志文件。
方法三:
1.
进入企业管理器，选中数据库，比如demo
2.
所有任务-分离数据库
3.
到数据库文件的存放目录，将muonline_log.ldf文件删除，以防万一，你可以拷出去
4.
企业管理器-附加数据库，选muonline，这个时候你会看见日志文件这项是一个叉，不要紧，继续，此时数据库就会提示你该数据库无日志是否创建一个新的，确定就是了。
5.
记得数据库重新附加后用户要重新设置一下。
如果以后,不想要它变大:
sql2000下使用：
在数据库上点右键-属性-选项-故障恢复-模型-选择-简单模型。
或用sql语句：
alter
database
数据库名
set
recovery
simple
