作者简介：
李真旭（Roger）
云和恩墨西北区技术总监，Oracle ACE, ACOUG 核心专家
对于数据库升级迁移，这两年是一个非常热门的话题，尤其是 x86 的流行，很多客户纷纷投向了 x86 的怀抱。对我们技术人员而言，对于数据库的升级迁移，观点的截然不同的。如下是前不久网上一群技术爱好者的观点：
由于传统架构同城都是小型机，因此对数据库的升级同时通常都会选择新的架构，比如选择当前比较流行的 x86 架构，不仅仅是节约成本那简单，因为这些年 x86 架构的日渐成熟，无论是性能，稳定性等各方面都取得了长足进步。
从传统小型机到 x86 架构的转变，也就意味着夸平台的数据库迁移升级。根据我们的经验，跨平台迁移升级有如下一些方面的难点：
这里给大家分享一些主流的迁移升级方法和案例，前几年最为常见的方法必定属 goldengate了。这是我们之前一个客户的迁移方式。
对于利用 goldengate 进行数据库的迁移，也存在一定的难点，比如数据校验等。虽然这是目前比较流程的跨平台迁移升级方式，然而却并非唯一的方式，也并非最佳的迁移方式。
在跨平台迁移升级方面，我们也一直在进行尝试，选择新的方案。
在2014年底我们在某运营商成功运用 xtts 增量方式实现了核心业务数据库的跨平台迁移，这应该是国内最早采取这种方案的成功案例。如下是该客户的其中一套核心数据库的迁移步骤：
经过多次测试验证，我们顺利了完成了多套核心 Oracle RAC 数据库从 AIX 到 Linux 的迁移，停机时间均控制在3小时内。通过该成功案例，也为大家进行数据库迁移升级提供了新的方案。
对于数据库迁移升级，方法多种多样，没有最好的迁移方法，只有最合理的迁移方法。
对于10046 trace，这是所有 DBA 的必备技能之一，在我的职业生涯中，通过 10046trace 解决了很多疑难问题，此次数据恢复也需要借助 10046trace 来发现问题的根源：
虽然10g 的老去，11g 成为主流，12c 的日渐流行。Oracle ASM用的越来越多，而很多dba对asm认识还是不足够，很多人认为 asm 是一个黑盒。其实并非如此。但是不可否认的是，在 Oracle 10g 的版本中，asm 的稳定性确实是一个问题。往往由于一些误操作，就可能导致 asm 磁盘组无法 mount，几年前我们就曾经遇到过 add disk 命令没结束，ctrl c 后，导致磁盘组 diskmount，然后再也无法 mount 了。这里提到的也是一个比较悲剧的案例。
