我没有答案，但有一些想法：

您无法控制哪个CMS将拥有一个会话，或者哪个将处理一个CMS。 查询。 （您也不能完全禁用CMS，但您已经知道这一点）。 在配置文件中指定特定的服务器和端口只能识别集群。 CMS将自己决定哪个会话拥有您的会话。

迁移过程涉及很多过程：本地LCMCLI过程，源CMS，LCM CMS（如果有）以及其他几个过程。 问题是，造成延迟的是哪一部分？ CMS查询的默认超时时间为9分钟。 您的流程运行了3个小时，因此我认为CMS查询处理不会延迟。 （您可以通过在Query Builder中运行它来确认这一点。）

您拥有专用的LCM服务，但是可以建立一个专用的LCM系统。 这将是一个完全独立的BOE集群，只托管LCM及其相关服务。 不能保证这会有所帮助，但是它将减少与LCM和其他服务的任何争用。

我相信 LCM APS将在FRS中生成中间文件作为其导入对象， 源CMS。 因此，无论您有多少RAM，总会有硬盘传输限制。

我能想到的一种解决方法是一次创建一个根文件夹，而不是现在拥有的所有文件夹。/p>

我应该提到这是一次全面的提升-因此排除依赖项= true

RAM不会加快关系计算。
更不用说它们了 在源CMS上运行的可能性最大，而不是在专用节点上运行。

向LCM提供的RAM在开始为实际内容的移动创建lcmbiars时就在使用。

哇-完全不同。 很好奇-您在新群集上的CMS数据库使用了什么？ 默认的SQL Anywhere数据库或与您的主群集相同的数据库？

唯一需要占用任何内存的进程是lcm_cli和ajs。 您确实已经分配了很多内存。

您可以尝试分离导出和导入：
您还可以通过生成lcmbiar而不是生活的方式来消除方程式中的目的地-这可能会给 您可能会想办法把目标放慢一点。

您是否包括安全性？ 如果是这样，是否涉及用户企业或AD/ldap？ 如果涉及到
AD/ldap，则可以通过在源和/或目标上禁用AD插件来加快速度-这将消除不必要的AD往返行程。

您好Shiva- 我正在按照模式手册进行全面的系统升级，先导出到biar，先导出用户/组，然后导出到依赖项，然后再报告。 但是，这些报告按使用顺序和前1-2000细分为许多单独的查询。 我总共要执行35个属性文件。 但是每个查询需要3个小时左右的时间，因此只有5天的停机时间才能导出！ 不行！

每本模式书全面升级，是的，我包括安全性，但不包括依赖项。 除此之外，LCM CLI似乎仍在排除依赖项，因为如果我从APS.Promotion中删除ClearCase服务，则LCM_CLI会爆炸，表示它无法检查依赖项。 重新添加此服务后，它将运行无误。

有AD用户。 同样，根据模式手册，在TARGET处禁用AD。 但是，我还没有达到目标。

您好，Brian，能否请您更新版本信息。 我将尽力关注此线程。