首先，楼主的操作是完全按照手册上的写的，没问题。建议flushstae多做几次。
其次，xpload的过程会很久，好像内部实际上就是调用dbcc reindex的过程。这个对大表来说，不如删除了索引直接重建快。
我的教训就是：一个80G的数据库，sp_post_xpload用了2天，然后发现索引还是坏，最终重建索引又花了2天。
还有，文档上说过load 回去的时候不支持远程load。。。但在我的测试环境（备份点是AIX 5.3,恢复点是Linux都是ASE 12.5.4)上，是可以的。
至于Eisen说的远程Dump就能转换格式，我个人认为这句话不全对。要看两端的环境是否相同。
我测试过的环境中，Windows 32位下dump的，linux Redhat 5.3 64位的能load 回去，自动做平台转换。
但是Aix 64位下dump的，不能load 回Redhat中。只能按照手册中的来操作。
这个帖子还是挺重要的，当初找这个跨平台的文档还是在Sybase网站搜索了半天的。
首先感谢朋友们的热心回复，感觉SYBASE在跨平台的DUMP/LOAD上，很纠结,
sp_post_xpload这步其实不一定好用，我最后是通过dbcc reindex(tablename)的方式来重建全库所有表的索引的，且做了
update partition statistics
最后还重新刷了某些SP，最终才成功的，
但是另一种情况
平台1：安腾64位小机，安装了SYBASE 1254 64位 FOR 安腾64
平台2：IBM小机，安装SYBASE 1254 FOR AIX（硬件IBM5200)
同样的步骤，却依然有问题，在登录业务程序时，一直报
Index id 2 on table id 652529358 cannot be used in the optimization of a query as it is SUSPECT.
Please have the SA run DBCC REINDEX on the specified table
DBCC REINDEX 不管用了
期待SYBASE公司的技术和广大高手们的回复
通过dbcc reindex(tablename)的方式来重建全库所有表的索引了，干吗不BCP，还这么劳时劳力！
通过dbcc reindex(tablename)的方式来重建全库所有表的索引了，干吗不BCP，还这么劳时劳力！
wfcjz 发表于 2010-05-21 10:57 http://bbs3.chinaunix.net/images/common/back.gif
用户库里存在很多大表，基本bcp一张表就要接近1小时，且bcp后需要重建索引，那个过程时间会更长，
已经尝试过这样做了。太痛苦。
由于是帮助客户评估业务在IBM机器上运行的情况，同时，目标机器硬件较差(IBM5200,2个CPU,4G内存，虽然有盘柜，但是整体速度太慢了）
因此bcp是最后的选择，
欢迎有BCP跨平台转移业务数据库经验的兄弟一起探讨
回复 13# Linuxcn.com
>> Index id 2 on table id 652529358 cannot be used in the optimization of a query as it is SUSPECT.
>>Please have the SA run DBCC REINDEX on the specified table
重建表652529358 的indid=2的索引还是报这个错误？
执行 sp_listsuspect_object 看看是否还报异常？
首先感谢朋友们的热心回复，感觉SYBASE在跨平台的DUMP/LOAD上，很纠结,
sp_post_xpload这步其实不一定好 ...
Linuxcn.com 发表于 2010-05-21 10:34 http://bbs.chinaunix.net/images/common/back.gif
呵呵，你的情况和我差不多，你说的这种情形我实际中都遇到过。
sp_post_xpload其实是dbcc 过的了，但是就是很奇怪的还是报索引有问题。。
解决方法和简单，不用dbcc reindex，而是直接删除那个对应的索引再重建就OK。
首先，楼主的操作是完全按照手册上的写的，没问题。建议flushstae多做几次。
其次，xpload的过程会很久， ...
hefan 发表于 2010-05-06 13:37 http://bbs.chinaunix.net/images/common/back.gif
嗯。这个倒是，确实有通过remote bs备份依然load失败的经历。
成功的是 win32 -> linux 32,win32 -> linux 64, win32 -> aix 64 ,linux 32 -> aix 64 ,
失败的是 linux64 -> win32 , aix64 -> linux32 , aix64 -> win32
用户库里存在很多大表，基本bcp一张表就要接近1小时，且bcp后需要重建索引，那个过程时间会更长，
已经 ...
Linuxcn.com 发表于 2010-05-21 11:05 http://bbs.chinaunix.net/images/common/back.gif
说一个投机取巧的方法——
我曾经有一次为从sco 11.0.5-> linux 32遭遇了怪异字符，无法bcp in的问题，
实在没法了，我就通过建proxytable，然后insert table select * from proxytable的方式解决了无法bcp的问题
我一般是用bcp来实现的