电信核心系统去小型机化-去“I”

去“IOE”是一个甚嚣尘上的话题，在经年的渲染之后，很多企业都在以各自的方式在进行演绎。

云和恩墨最近帮助用户实施了一个重要的“去I”项目，引用恩墨一线负责人老熊的描述：

2014年5月8日，是一个重要的日子。一个省级电信运营商，将核心的CRM系统Oracle数据库进行了升级迁移，成功地从原来运行在IBM 595平台上的双节点10.2.0.5 RAC数据库，迁移并升级到基于x86+vmware平台的双节点11.2.0.3 RAC数据库上。新平台的服务器成本只有原小型机成本的十分之一。我个人认为是这是一个里程碑式的事件，这标志着，不远的将来，以IBM p系列为代表的小型机将退出电信运营商的舞台，而以x86平台为核心的私有云平台将占主导地位。

X86平台的快速发展，使得其支持电信核心系统成为可能，随着各企业不断摸索和尝试，让大家更有信心的道路正在显现。

在升级和迁移过程中，也面临了很多技术问题，以下是其中之一的重要内容分享。

1. 在Oracle数据库的世界里，统计信息显得是那么重要，所以在升级系统时，我们考虑的一个重要问题是，在新的系统上采用何种统计信息收集策略，或者至少要保证上线的时候不能因为统计信息问题而导致系统性能异常。
2. 这套CRM系统在2010年之前运行在Oracle 9i之上，那时采用手工手集统计信息的方式，每个月在固定的日期收集2-3次统计信息。在我接触到这套系统之前，系统隔段时间总会遇到收集统计信息后某些SQL性能变差影响业务的问题。后来我与这套系统的DBA商量，对手工要收集统计信息的表进行了梳理，去掉可能会引起问题的直方图，对某些表上的某些列必须收集直方图，最后将dbms_stats.gather_table_stats中的method_opt参数改为for all column size repeat，之后基本上再没出现过统计信息变更导致性能的问题。
3. 2010新数据库随应用的升级同时升级到了10.2.0.5版本。开始仍然是用一张表一张表的方式收集统计信息，再后来，随时时间和应用的演变，统计信息的收集也发生了变化。但仍然是手工收集的方式，而没有开启统计信息自动收集。
4. 基于大量11gR2数据库采用自动统计信息的现状、11gR2在CBO以及自动收集统计信息上的不断完善，我们决定在此次新系统上线时以及上线后，采用“自动收集统计信息”的策略。
5. 在用这样的方式收集统计信息后，我们使用SPA测试了数万条SQL语句，再用几十个SQL PROFILE固化了可能存在风险的SQL，这样系统就顺利上线了。

变革的时代来临了，我们一起拥抱变化吧！