本篇文章给大家谈谈客户案例|用友NC财务系统上云，以及对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。
客户原本打算让我们在阿里云上新建一个RAC，通过物理备份RMAN迁移的方式迁移到云端。但考虑到成本，客户计划采用逻辑迁移的方式将数据库导入到现有的一套云RAC中。原有业务系统的RAC也由我司搭建并运营。配置为16C64G，数据量100G左右。
2 上云方案
我公司作为技术专家，给客户建议：
1）复用原有云RAC环境，无需购买新服务器。
2）云上RAC扩展。新购NC财务1.5T共享数据盘和0.5T归档盘，并将两套服务器升级为64C128G；
3) 评估停机时间。如果采用逻辑导入迁移，再加上周边业务系统的调试和参数修改，总共需要停机2天。企业无法承受如此长的停机时间。因此改用RMAN迁移，在扩容后的RAC环境中创建新的数据库。采用RMAN增量迁移方式，数据库割接时间几乎为0，剩下的就是应用调整时间，从原来的两天缩短到几天。小时；
4）建议采用两次迁移方式，提前一周完成数据库迁移，基于云数据库环境调整应用，并测试应用可用性，这样可以缩短第二次正式迁移的应用调整时间。
最终云架构如下：
经过详细审核，客户最终采纳了我司提出的整体迁移实施方案。
3 实施过程
以下是具体实施过程：
（1）共享盘扩容在阿里云控制台购买ESSD共享盘。挂载到两台弹性云服务器上后，使用udev添加ASM磁盘。原业务系统的数据盘为DATA，归档盘为ARCH。新创建的磁盘名为NCDATA和NCARCH，用于存储新的NC系统数据。
（2）ECS升级ECS升级是在阿里云控制台上进行的，需要关机重启。客户的业务系统非常重要，不能随意关闭。 RAC架构的优势显现出来。通过逐一升级配置，可以保证业务连续性。
整个升级流程如下：
1）节点1，停止数据库和CRS；
2）ECS控制台停止节点1，选择64C256G配置进行升级（阿里云可用区64C128G配置已售空）。当节点1的ECS宕机时，VIP和SCAN IP自动漂移到节点2，因此业务自动切换到节点2。
3）启动节点1，使用crsctl check crs和crsctl stat res -t检测集群已经启动，启动instance 1数据库实例，使用crsctl stat res -t检查资源是否正常，以及node的升级1已完成。
然后在节点2上重复节点1的升级过程。
(3) 迁移验证1) 参数文件非常重要。通过create pfile导出原库配置文件，并修改关键配置参数以适应新环境。注意目录，注意扫描ip，注意集群databae改为false等。
2）将数据备份到云端。前一天的备份文件已传输至云端。备份文件包含1T数据。通过专线传输数据花了4个多小时。这也是迁移过程中最耗时的步骤。
3）数据库恢复。在节点1上操作时，需要关注ORACLE_SID。由于RAC环境中有一套生产库，因此在操作过程中一定要反复确认操作对象。先创建spfile文件，同时在初始文件中构建文件系统和ASM存储涉及的目录结构。然后在nomount下恢复控制文件，在mount下恢复数据库，然后恢复数据库，然后打开resetlogs等，都是常规操作。恢复数据库脚本必须更改新的asm存储数据目录，否则将恢复到原生产库的数据目录，如“set newname for datafile 1 to \’+NCDATA/orcl/datafile/system.dbf\’; ”所有数据文件所有临时文件都必须更改。再次强调，如果有生产库，恢复是一个高风险的操作。请务必检查sid 环境和恢复脚本。
4) 将数据库添加到RAC集群。修改cluster databae参数为true，使用srvctl添加数据库，断开单库后，srvctl start database -d nccdb -o open启动，可以使用crsct stat查看实例。
交付到应用程序测试时，数据库已完成，一路上没有出现任何意外。 4路数据库恢复耗时不到2小时，瓶颈在于NAS数据读取（备份介质在NAS上）。阿里巴巴的ESSD共享存储性能非常高。
（4）正式迁移第一次迁移验证了整个迁移方案的可行性，也验证了应用系统上云后的功能。正式迁移比较简单，第一次迁移后参数文件就都有了。
同样在节点1上操作，确保sid已设置为nccdb1。
1）删除第一次迁移恢复的数据库。它也可以被删除，并将在第二次恢复时被覆盖。删除过程如下。删除RAC库时有几点需要注意。
a) 环境变量和sid不要写错，一定要再次确认；
b) 修改cluster_database=FALSE;
c) 停止数据库srvctl stop database -d nccdb，两个节点都会停止；
d) 确认instance_name，然后删除数据库；
e) srvctlremovedatabase-dnccdb删除库的集群信息。步骤5无需执行。
2）修改spfile参数cluster_database=FALSE后，检查ASM目录结构，看nccdb是否存在。如果不存在，则需要重建；
3）启动数据库到nomount状态并恢复控制文件后，恢复databasese，恢复数据库和恢复档案，最后打开resetlogs等，一路顺利。
4）修改spfile参数cluster_database=true后，关闭单库，srvctl start database -d nccdb -o open启动，检查集群资源，新数据库存在，检查日志是否正常。最后，不要忘记替换临时文件。迁移后原来的临时文件将失效。
至此，用友NC财务系统已经安装在阿里云oracle RAC上。
4、本次上云的价值
1）实现了在阿里云上托管RAC架构下的多个数据库的案例，为客户节省了云资源成本；
用户评论
々爱被冰凝固ゝ
终于看到关于用友NC财务系统的文章啦！之前一直听别人说它好用，现在看见这个案例后更加心动了。希望可以尽快了解下它的具体功能细节，看看能不能帮我们公司提升效率哦。
有9位网友表示赞同！
一个人的荒凉
这篇文章写的不错，案例分析很详细，看得出上云确实能为企业带来很多好处，降低IT成本的同时还能提高数据安全性和灵活性。以后是不是应该考虑跟风了?
有20位网友表示赞同！
她最好i
作为一家老公司，虽然一直使用着传统的财务系统，但最近也关注上了“云”这个概念，这案例看起来很有启发性。不过我想问下这个上云的过程会不会很复杂？对公司的现有系统影响会有多大呢？
有5位网友表示赞同！
念旧是个瘾。
我们公司也是做批发行业的，以前经常受到库存管理和财务结算的困扰。看了这个案例后感觉用友NC财务系统上云真的能解决这些难题啊！希望可以尽快咨询下他们，看看能不能给我们的企业带来同样的成功。
有6位网友表示赞同！
我怕疼别碰我伤口
讲真，我对这种宣传的文章有点免疫了，哪个公司不夸自己功能强大？还是等看实际效果再说吧。另外我觉得文章没有提到具体的财务管理流程优化，这点比较遗憾。
有14位网友表示赞同！
沐晴つ
上云确实可以提升效率，但安全性和可靠性也是关键问题。这篇文章没有详细介绍云平台的安全性措施，还是有点担心用户信息泄露的风险。希望用友可以加强这个方面的宣传和保障。
有6位网友表示赞同！
ゞ香草可樂ゞ草莓布丁
看了案例后感觉用友NC财务系统上云确实是个不错的选择，能帮助企业更好地整合资源、优化流程、提高效率。但对于中小公司来说，可能会存在技术门槛和成本问题，需要仔细考虑性价比因素才能做出决定。
有14位网友表示赞同！
有一种中毒叫上瘾成咆哮i
我之前一直觉得财务管理很复杂，总是感觉自己掌握不够到位。现在看到这个案例后，感觉用友NC财务系统上云可以让我们的工作更加高效便捷化，甚至可以提升财务人员的工作精度。
有16位网友表示赞同！
凉笙墨染
文章写的不错，案例分析得比较透彻，让我对用友NC财务系统上云有了更全面的理解。特别是数据安全性和备份机制方面，让我感觉非常安心。
有15位网友表示赞同！
请在乎我１秒
客户案例的确能让人更加了解产品的优势和价值。我觉得这篇文章还可以加入一些数据图表来更有直观地展示云平台带来的效益，能够更直观的触动到潜在客户。
有11位网友表示赞同！
念初
上云虽然方便快捷，但还是对系统稳定性有要求。我希望能看到更多关于故障处理和恢复机制的介绍，这样才能更加放心使用平台服务。
有6位网友表示赞同！
▼遗忘那段似水年华
公司一直在寻找合适的财务管理软件，看了这个案例后觉得用友NC财务系统上云很有潜力！希望能够了解更多关于价格、功能细节和支持服务等等信息，以便做出更合理的选择。
有11位网友表示赞同！
铁树不曾开花
其实对我来说，最大的争议可能在于，对于传统企业来说，是否真的方便直接接轨？需要考虑技术人员的培训调整和内部流程改造，这部分内容我觉得可以更加详细地说明。
有13位网友表示赞同！
断秋风
这个案例让我对用友NC财务系统上云有了更深入的了解。它不仅可以提高工作效率，还能提供更好的数据安全保障。 对于我公司来说，很有借鉴意义！
有8位网友表示赞同！
红尘滚滚
说真的，看这些案例的时候，感觉很像广告宣传片，缺少真实的反馈和用户体验分享。我希望能够看到更多来自普通公司的使用感受，这样才能更客观地评价产品的价值。
有20位网友表示赞同！
陌颜
我们公司现在正在考虑云平台，这个案例让我对用友这款产品更有了解，未来可以考虑跟他们进行深入沟通探讨。
有11位网友表示赞同！
孤街浪途
客户案例真能展现企业的实力，我非常期待看到更多类似的分享，帮助企业更好地选择合适的解决方案！
有14位网友表示赞同！