数据库中的列已损坏
我有一个 SQL Server 数据库。其中一个表的一列由于缺乏更好的词而被损坏。我可以选择 * 甚至选择该特定列，它工作正常。我可以毫无问题地对所有其他列执行计数、排序和分组等功能。但是，如果我尝试在这一列上执行其中一个函数，则会出错并显示以下消息： 错误：（状态：S1000，本机代码：E28）
另外，我使用 winsql 连接到数据库。
以前有人见过这种行为吗？
附加信息：
select colname from tablename
工作正常
select colname from tablename order by colname
产生错误
I have a SQL Server database. One of the tables has a column that, for lack of a better word, is acting corrupted. I can select * or even select that specific column and it works fine. I can perform functions like count, order by and group by on all other columns with no problems. But if I try and do one of those functions on this one column, it errors out with the following message: Error: (State:S1000, Native Code: E28)
Also, I am connected to the database using winsql.
Has anyone ever seen this kind of behavior before?
Additional info:
select colname from tablename
works fine
select colname from tablename order by colname
produces the error
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
尝试重建索引。我遇到了类似的问题，重建索引修复了它。在另一种情况下，重建索引不起作用，因此我不得不恢复夜间备份。谢天谢地，我们每晚都会对开发数据库进行备份。
Try rebuilding indexes. I had similar problem and rebuilding indexes fixed it. In another case, rebuilding indexes did not work, so I had to restore the nightly backup. Thank goodness we had nightly backups for the development database.
如果 SQL 数据库报告损坏/这确实是损坏 - 开始要非常小心。损坏可能会通过 823 / 824 和其他高严重性错误开始显现。保持冷静并运行 DBCC CheckDB - 找出损坏的程度。不要将其拆下或开始执行随机操作。
在继续之前，您应该对事务日志进行尾部日志备份 - 如果您被迫恢复，您很可能需要它。我可能会选择 COPY_ONLY 选项。
CheckDB 可能需要一些时间，但让它完成并查看报告了多少损坏，以及报告了哪些对象。
NC 索引的损坏可以通过索引重建轻松解决，而页面损坏的损坏将更加困难。
如果 CheckDB 拒绝完成并且本身出错，那么您遇到了真正的问题，并且将导出您可以/从备份恢复的数据。
Paul S. Randal 的博客是阅读腐败和查找/修复/游戏结束时的最佳地点之一。 http://www.sqlskills.com/blogs/paul/
这仅适用于您我们真正关注的是损坏，而不是一段不可靠的 SQL。
If the SQL database is reporting corruption / this really is corruption - start being very careful. The corruption might start manifesting itself with 823 / 824 and other high severity errors. Keep your cool and run DBCC CheckDB - find out the extent of the corruption. Don't detach it or start performing random actions.
You should take a tail of log backup of the transaction log before you proceed - you may well need it if you are forced to restore. I would probably take this with a COPY_ONLY option.
CheckDB might take some time, but let it finish and see how many corruptions are being reported, and on what objects they are being reported.
Corruptions on NC indexes can be solved easily through an index rebuild, corruptions with torn pages are going to be harder.
If CheckDB refuses to finish and error's itself, you have a real problem and will be exporting what data you can / restoring from a backup.
One of the best places to read up on corruptions and finding / fixing / when it's game over is Paul S. Randal's blog. http://www.sqlskills.com/blogs/paul/
This applies only if you really are looking at corruption instead of a piece of dodgy SQL.