今天，Oracle（甲骨文）公司的 Oracle Open World / Java One / Oracle Developer 北京大会今天开幕。
大会从13号到16号，共4天，今天上午主要是大会注册时间。由于参会人员众多，Oracle 安排了半天时间用于参会者注册报道。我较早就到达了现场，看到为排队准备的临时隔离绳早已准备好，还有十多个安检通道。看这阵式，等下的注册场面一定很火爆。
今年的大会上，OTN 组织了一次 Oracle ACE 大聚会（OTN Lounge），并有精彩演讲安排。我在里面也安排了一个主题演讲，安排在 15 号（周三）上午。此外还有 Oracle 数据库方面的很多专家如冯春培，盖国强，楼方鑫，张乐奕等，还包括阿里巴巴公司一位经常与我协作的高级 Java 工程师 贺贤懋。
OTN Lounge 的具体日程安排如下：
为了对核心技术拥有更多的自主控制能力，为了解决数据库的线性扩展问题，为了尽量减少对商业软件的依赖，为了摆脱对高端硬件的依赖，为了… 基于以上多种原因，2年前，我们计划将公司某核心应用平台进行大手术：数据库平台从软件到硬件全部重构。当然，这其中应用架构的改造也不可避免的进行了大换血。
这个项目无论是从技术角度还是是业务角度来说，都对我们有着非常大的价值，也必定会带来非常深远的影响。项目历时2年多，分4个阶段才完成：
应用接口统一
这一阶段主要是为了后面真正迁移的时候做准备工作，将该核心应用系统的所有数据访问入口统一到一起，全部以服务化的接口方式呈现给其他有需要的系统，一来方便后续变更的控制，二来也推进了服务化的进程。
Oracle数据库中拆分（1拆16）
这个阶段本不是必要的，但是由于项目启动稍微晚了点，数据出现了爆发性增长，导致该系统的数据表太大（单表不带索引过500GB），原 Oracle 数据库已经快撑不住了。为了安全起见，先在 Oracle 中从一个主表以会员ID进行 hash 运算后再进行水平拆分，从1个表分拆成了16个。附表由于访问量稍小，而且全部是根据主键访问，暂时保留原样。
当然，这样的水平拆分，必然会带来数据访问路由以及数据合并的问题。我们专门为此开发了具有分布式数据库路由/数据合并，数据库读写分离，数据库链接管理等功能的数据访问中间层，专门解决拆分后给应用服务器带来的影响，使得应用服务器完全感受不到后端数据库的变化。
这个数据访问中间层，对前端应用服务器来说，就是一个完整的数据库，所有数据请求都从这里实现，以协议的方式和前端应用服务器的jdbc驱动进行交互，以便让数据库对应用服务器彻底透明。
Oracle迁移至 MySQL（16拆128）
这个阶段是整个阶段中历时最长，复杂度最高，风险系数最高的，未知因素也最多的一个阶段。虽然 MySQL 数据库已经在互联网行业占据了大片江山，但是对于阿里巴巴来说，却仍然是一个新鲜玩意儿，因为之前我们一直都用 Oracle 来提供所有的业务系统的数据库服务。
在此之前，我们从来没有在如此核心业务系统的数据库上使用过 PC Server 和本地硬盘来承载数据库，一直是使用 IBM 小型机和中高端存储设备来解决高性能和高可靠的问题。在更换成 PC Server 和本地硬盘来承载数据库之后，我们就必须面对 PC Server 本身硬件可能存在的不可靠性所带来的 Crash，所以我们必须有一套完善的 HA 切换机制，要比小型机厂商所提供的商业 HA 管理软件更加高效更加自动化更加可控，才能我们降低了设备本身可靠性之后达到原有的可用性要求。
对于一个需要满足 365 * 24 * 7 的核心业务系统来说，肯定是不可能给我们太多时间来进行数据迁移的，所以我们不得不设计出一个对现有系统影响尽可能小的迁移方案，这势必会造成方案的高度复杂化，带来更多的风险。最后的迁移方案要经历如下4个阶段：
1. Oracle 读/写;；MySQL 初始化并增量写
2. Oracle 读/写； MySQL 写
3. Oracle 写； MySQL 读/写
4. Oracle 停访问； MySQL 读/写
当然，也正式由于有如此复杂的方案，才确保了在整个迁移过程中的的停机时间被控制在了10分钟之类。
附属Detail信息迁移至 MySQL
从项目开始，至完成主表拆分结束，已经接近2年了。这2年时间内，数据量一直都在飞涨，这让即使仅仅只是按照主键访问的附表也快无法承受持续增长的业务压力，附表的拆分也就成了必行之势。由于在原来主表拆分的过程中，整个项目组已经积累了大量的经验，附表拆分过程非常顺利，基本没有出现任何问题。虽然附表的拆分过程与主表相比除了 1拆16这个阶段外没有减少其他任何环节，但是整个拆分过程也才2个月就全部搞定了。
这个迁移项目算是彻底完成了，但是我们的迁移之路并不会就此止步，还有很多的系统仍然存在扩展性问题，还有很多的数据库应用等着我们去拆分。
注：同事们还为此送了我们一个虽不太雅但也意思相近的名称 “拆迁队”。
在 IT 行业很多工程师（尤其是很多 DBA）的心目中，都把小型机视为解决性能问题的终极武器，认为小型机的处理能力要远大于 PC Server。在几年前，可能也确实是这样。但随着近几年 X86 架构芯片技术的飞速发展，PC Server 的处理能力已经越来越强悍，不断的给我们带来惊喜。
最近几年的小型机市场，基本上被 IBM 吃掉了大部分。虽然可能并不完全是因为其 Power 芯片处理能力与其他厂商的芯片相比有优势，但其处理能力方面的优异表现确实是一个很重要的因素。所以最近几年我们一直关注着 IBM 小型机与其他主机的处理能力比较，当然比较是基于 Oracle 数据库所做的一些测试。
测试基本模型如下：
在待测主机上安装好 Oracle 数据库，配置足够装载下所有数据的 SGA，将 Oracle 的 Redo 日志放在内存文件系统上。然后在我们技术能力范围内对 Oracle 进行相应的调优。
使用我们真实的线上数据抽样（约10GB），Import 进入待测试主机上的 Oracle 数据库中。
通过 PL/SQL 编写出模拟我们在线业务中最为典型的事务逻辑，然后使用C++编写多线程程序作为压力测试客户端。
通过多台主机运行压力测试程序，平缓的给待测主机增加压力，待测主机的 CPU 利用率基本用完为止。
测试数据的收集主要通过恒定时间段的 Oracle 数据库自身性能数据采样（statspack），然后分析 statspak 中的每秒事务数。以往经验显示，基本上当客户端压力线程到达一定数量之后，处理量就比较稳定甚至下降。然后我们从中取出每秒事务数的最大值，做为该机器的处理能力分值。
这个测试模型主要消耗的资源是主机的 CPU + RAM 的能力，而且当初也得到了 IBM 实验室的人认可。
通过这几年对几种主机处理能力跟踪测试情况来看，IBM Power 芯片的优势已经越来越不明显了，甚至其 Power 5+ 芯片的处理能力已经不如某些型号的 Intel x86 芯片的处理能力了，部分主机处理能力对比数据如下：
近四五年来的测试数据：
Sun v880(4C): [...]
同事 郑隐（也是同一个学院的校友）今天在 Team 内部做了一次关于 Oracle Data Buffer 相关的 Internal 信息的分享，觉得非常不错，特此共享出来:
Oracle Data Buffer Cache Internal
此PPT版权所有：郑隐
为本人所在 Team（Alibaba DBA Team）发个招聘的小广告，详细信息如下：
MySQL DBA
职位描述：
管理MySQL数据库
开发项目支持与优化
MySQL数据库性能优化
MySQL数据库高级特性测试，优化与实践
岗位要求：
精通SQL
熟悉SQL Tuning
熟悉MySQL数据库架构与管理
熟悉MySQL Replication与NDB cluster的原理
熟悉LINUX操作系统
熟悉shell,perl(掌握一门)
良好的沟通技能、团队合作能力
熟悉unix环境下C语言编程者优先
注：不要太聪明的，只要做事踏实的
Oracle 开发 DBA
职位描述：
评估，跟踪，支持开发项目
数据库变更管理
Schema设计与审核
数据库开发性能优化
开发、测试环境管理与维护
岗位要求：
精通SQL,PL/SQL
精通SQL Tuning
精通数据库建模
熟悉Oracle基本管理
有开发经验者优先
良好的沟通技能、团队合作能力
注：此招聘广告长期有效
有意者请将简历 Mail 至本人邮箱： sky000 [AT] gmail.com
