MS SQL SERVER数据库导出数据出错后的问题及解决办法
MS SQL SERVER数据库导出数据出错后的问题及解决办法
查询表错误信息如下:
消息 7105，级别 22，状态 6，第 4 行
LOB 数据类型节点的数据库 ID 5 (页 (1:13020)，槽 6)不存在。这通常是由于可以读取数据页上未提交的数据的事务所致。请运行 DBCC CHECKTABLE。
或当你导出数据表到另一个库时会出现这样的信息:
- 正在执行 (错误)
消息
错误 0xc0202009: 数据流任务 1: SSIS 错误代码 DTS_E_OLEDBERROR。出现 OLE DB 错误。错误代码: 0x80004005。
已获得 OLE DB 记录。源:“Microsoft SQL Server Native Client 11.0” Hresult: 0x80004005 说明:“LOB 数据类型节点的数据库 ID 5 (页 (1:2573)，槽 18)不存在。这通常是由于可以读取数据页上未提交的数据的事务所致。请运行 DBCC CHECKTABLE。”。
(SQL Server 导入和导出向导)
数据库坏了吗?修复吧(做好备份喔)
use master
ALTER DATABASE [myinfoNew] SET SINGLE_USER WITH ROLLBACK IMMEDIATE; --把数据设为单用户模式
dbcc checkdb('myinfoNew',repair_allow_data_loss);
dbcc checkdb('myinfoNew',repair_rebuild);
ALTER DATABASE [dbname] SET MULTI_USER --恢复多用户模式
还是不行................
那祝贺你,你中了微软的坑了.也不知道是什么原因呀?微软的数据库产品真的不敢恭维.好让我慢慢来说.在我解决这个问题的过程中,MS SQL SERVER不止是这么一点点的问题.都有点让我吃惊.
在网上找了许多的相似的问题,看看他们是如何解决的.但对于我的问题可一点用途都没有.
我的表是这样的:
CREATE TABLE [dbo].[AddressPic](
[AutoId] [int] IDENTITY(1,1) NOT NULL,
[znumber] [int] NOT NULL,
[AbookPic] [image] NULL,---注意是image字段
[AbookPicNO] [int] NOT NULL)
这个表简单吧,数据库及表我都用了很久了.我是在想把现有的数据进行降级的时候(2014到2012)导出数据时发现了这一问题.我想完了完了,我这个表里面有近2G的数据呀!特别是image字段时的图片等信息.
先说说我想从SQL2014降到SQL2012遇上的问题,SSMS我用的是SQL2012.
1.我用了数据库自带的导出数据功能. 导出数据表出现上面的错误.
2. 是不是数据太大了呀?Sql语句导出加上条件范围.不靠谱,映射数据型200,203都来了,根本不是我varchar,image.也不知是不是对应这个,反正数据类型出现了200,203之类的.又在网格找一下.并打了补丁这个现象没有了.但导出数据同样会出现上面的错误.
3.我把2014和2012数据进行链接.通过远程插入表总是可以吧.
用语句insert openrowset等还是不行,信息给出了一条数据成功, 到Sql2012去一看空空的.一条数据都没有.忽攸人.
3.有建立视图的方法.导出数据总可以吧.喔靠.....视图不能保存.要不就把SSMS直接给你闪退.
SQL2012的其它问题没有发现,没有时间去帮微软搞测试了.
算了吧....都入微软的坑了...别想降级了....还是把数据整好吧.....!!!
我不降级导出数据了.(降级的唯一办法就是导出数据,网上有许多的办法我试了行不通! )
回到我的SQL2014,我用DBCC CHECKTABLE检查了10个表,其它有三个表出现下面的情况
消息 8961，级别 16，状态 1，第 9 行
表错误: 对象 ID 1157579162，索引 ID 1，分区 ID 357338084671488，分配单元 ID 71851982169178112 (类型为 LOB data)。位于页 (29:41331)，槽 0，文本 ID 151663607808 的行外数据节点与它在页 (1:255885)，槽 0 的引用不匹配。
消息 8961，级别 16，状态 1，第 9 行
表错误: 对象 ID 1157579162，索引 ID 1，分区 ID 357338084671488，分配单元 ID 71851982169178112 (类型为 LOB data)。位于页 (27:69730)，槽 0，文本 ID 151663607808 的行外数据节点与它在页 (1:255885)，槽 0 的引用不匹配。
消息 8961，级别 16，状态 1，第 9 行
表错误: 对象 ID 1157579162，索引 ID 1，分区 ID 357338084671488，分配单元 ID 71851982169178112 (类型为 LOB data)。位于页 (27:69732)，槽 0，文本 ID 151663607808 的行外数据节点与它在页 (1:255885)，槽 0 的引用不匹配。
表错误: 对象 ID 1157579162，索引 ID 1，分区 ID 357338084671488，分配单元 ID 71851982169178112 (类型为 LOB data)。位于页 (29:41328)，槽 0，文本 ID 151663607808 的行外数据节点与它在页 (1:255885)，槽 0 的引用不匹配。
消息 8961，级别 16，状态 1，第 9 行
表错误: 对象 ID 1157579162，索引 ID 1，分区 ID 357338084671488，分配单元 ID 71851982169178112 (类型为 LOB data)。位于页 (29:41329)，槽 0，文本 ID 151663607808 的行外数据节点与它在页 (1:255885)，槽 0 的引用不匹配。
消息 8961，级别 16，状态 1，第 9 行
表错误: 对象 ID 1157579162，索引 ID 1，分区 ID 357338084671488，分配单元 ID 71851982169178112 (类型为 LOB data)。位于页 (29:41330)，槽 0，文本 ID 151663607808 的行外数据节点与它在页 (1:255885)，槽 0 的引用不匹配。
消息 8961，级别 16，状态 1，第 9 行
表错误: 对象 ID 1157579162，索引 ID 1，分区 ID 357338084671488，分配单元 ID 71851982169178112 (类型为 LOB data)。位于页 (29:41332)，槽 0，文本 ID 151663607808 的行外数据节点与它在页 (1:255885)，槽 0 的引用不匹配。
消息 8961，级别 16，状态 1，第 9 行
表错误: 对象 ID 1157579162，索引 ID 1，分区 ID 357338084671488，分配单元 ID 71851982169178112 (类型为 LOB data)。位于页 (29:41334)，槽 0，文本 ID 151663607808 的行外数据节点与它在页 (1:255885)，槽 0 的引用不匹配。
消息 8929，级别 16，状态 1，第 9 行
对象 ID 1157579162，索引 ID 1，分区 ID 357338084671488，分配单元 ID 357338084671488 (类型为 In-row data): 在 ID 为 151663607808 的行外数据中发现错误，该数据由 RID = (13:130946:68) 标识的 data 记录所有
消息 8929，级别 16，状态 1，第 9 行
对象 ID 1157579162，索引 ID 1，分区 ID 357338084671488，分配单元 ID 357338084671488 (类型为 In-row data): 在 ID 为 152974196736 的行外数据中发现错误，该数据由 RID = (13:130946:69) 标识的 data 记录所有
Soft_SaveFiles的 DBCC 结果。
对象 'Soft_SaveFiles' 的 27 页中有 1830 行。
CHECKTABLE 在表 'Soft_SaveFiles' (对象 ID 1157579162)中发现 0 个分配错误和 324 个一致性错误。
对于由 DBCC CHECKTABLE (myinfoNew.dbo.Soft_SaveFiles)发现的错误，repair_allow_data_loss 是最低的修复级别。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
吓死宝宝了....我平时为什么不去检查一下呢?难道这也是DBA每天要做的工作吗?
完了,表坏了.....肯定是表里的某一行出问题.这一行或几行的数据肯定是丢了的.因为image根本查询不出来或通过程序是读不出来的.不丢才怪.
我新建一个与问题表相同结构的表. 什么索引呀,键呀,约束呀....通通给PASS掉.
查询有image类型字段没有意义
就用
select AutoId,
number,
--AbookPic, ---这是IM AGE字段
AbookPicNO
from AddressPic
完全没有问题,可是加上image字段就会出错.我想到范围查询
select AutoId,number,AbookPic,AbookPicNO from AddressPic where autoid<10
没有问题,10-100没有问题.100-200出问题了.....这就简单了.
再缩小范围100-150.........,1500-1600,1610-1700..........就慢慢来吧,要有耐心,谁让你用微软产品呢?哈哈....
终于找到有问题的记录了..如1503-1509....这记录存的都是大美女呀...取不出来了.........向微软哭吧
用范围导出(SQL句)或视图麻烦. 谁知道会不会又出问题呢?...........就用语句吧,对于有问题的记录行你记录下来,就不要导出了.丢就丢了吧....
当然有许多的方法.记得有篇文章说过用insert into转移表数据比较快,所以就用:
insert into 'newtable'(字段) select (字段) from 'oldtable' where 范围
还是很快的.2G.我分了三次就转运到新表了(addressPICnew)...........
把原来的表删除,把新表改为原来的名字,OK...............
总结:
1.规化好数据库版,别出现导出数据降级的问题.
2.少用或不用image或varbinary(MAX)类型字段.
3.用微软成熟的产品,当小白鼠会浪费你时间的.时间就是金钱.
4.说微软的数据库产品适合中小型企业确实有他们的道理或有过不好的经历吧.
5微软的数据库在我用上面的方面转存数据表的时候,有些Image字段丢失,以前我是用程序取出来看过和学习过的.请看看我的:
6.微软的数据库中当你保存重要数据的时候不要升级,微软说是可以升级的.可你的自信来自于对微软数据库的自信吗?
7.我存取数据库数据用的是C#的程序,这个程序以后变成了.Net4.5以后的版本了. 以前存取用的是.NET2.0 1.1版本的程序. 算了,也不分析是程序的问题还是数据库的问题?还是操作系统的问题?(从2000到Xp再到win7,数据库(200---2014)是跟着升级走来的)......一把鼻涕一把泪.....
不知有没有兄弟用oracle, sybase,DB2它们有这样的情况吗??