话说 Oracle ACE 这回事儿
Tuesday, August 24th, 2010
前段时间，在有幸被多人举荐并由 Oracle 公司的 Jack 提名后，被 Oracle 公司授予了 Oracle ACE (Expertise: MySQL) 称号。
很多朋友听闻此事后都向我道贺，也有很多朋友提出疑问： Oracle ACE 到底为何物？
Oracle ACE 程序主要是 Oracle 公司为了奖励使用推广Oracle公司某个领域产品的技术专家们所做的贡献而设立的一种荣誉机制。目前，除了通过业内知名人士举荐并由 Oracle 公司的人提名最终经过 ACE 程序审核小组评审之外，无法通过认证考试或者是其他途径获得。
目前国内共有 16 位技术专家获此荣誉，分别分布在6个技术领域，如下：
Database Management & Performance：5人
Database App Development：5人
Middleware & SOA：4人
Applications & Apps Technology：1人
MySQL：1人
其中 MySQL 领域目前国内就我一个人（希望在未来能够有越来越多的战友们能够加入这个行列），全球也只有4位。能够获此殊荣，确实非常开心，这是对我个人在这个技术领 域内的认可。当然，这也离不开我所在的公司为我提供的成长平台，离不开所在Team的各位同事给我的帮助。同时，也希望国内有更多的技术专家能够获得 ACE 称号。
原文出自： Sky.Jian – i Sky000
话说 Oracle ACE 这回事儿
核心业务系统数据库平台迁移： Oracle -> MySQL
Tuesday, August 24th, 2010
为了对核心技术拥有更多的自主控制能力，为了解决数据库的线性扩展问题，为了尽量减少对商业软件的依赖，为了摆脱对高端硬件的依赖，为了… 基于以上多种原因，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 [...]
不要过度迷信小型机
Tuesday, March 10th, 2009
在 IT 行业很多工程师（尤其是很多 DBA）的心目中，都把小型机视为解决性能问题的终极武器，认为小型机的处理能力要远大于 PS 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 [...]
关于oracle数据文件拷贝
Tuesday, February 17th, 2009
前几天要备份几个standby出来，RMAN一时之间不好用，数据文件都是存裸设备的，就用起了dd,当时急于出门，
dd脚本写好后nohup上就走了，半路上才想起来standby根本没有open read only,其上的mrp进程还在做实时恢复，
FNT，晚上回家本来准备重新弄，后来感觉可以先recover，因为我dd的blocksize就是db_block_size,每个IO单元
就是一个block，而数据库写文件的最小粒度也是一个block，并且我每个block的边界也和数据库的一样，这样应
该是不存在fuzzy block的，先用dbv看了下文件，OK，然后结合日志恢复，全部OK
今天就上面的情况做了模拟，发现这么做确实是可以的
测试环境：
Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
PL/SQL Release 9.2.0.6.0 - Production
CORE 9.2.0.6.0 Production
TNS for IBM/AIX RISC System/6000: Version 9.2.0.6.0 - Production
NLSRTL Version 9.2.0.6.0 - Production
–100M的表空间
sys@testdb>create tablespace mytest datafile ‘/crmsnap/data/mytest01.dbf’ size 100M;
Tablespace created.
–测试表，大概3行一个block
sys@testdb>create table mytest(id number,txt char(2000)) tablespace mytest;
Table created.
sys@testdb>create index mytest_id_ind on mytest(id) tablespace mytest;
Index created.
sys@testdb>begin
2 for x in 1..100000000 [...]
记一次BT的数据订正
Monday, May 26th, 2008
最近业务部门提出一个需求, 数据库里有些字段中保存的信息里全角和半角字符参杂, 影响市容, 要求做数据订正, 全部统一.
其中英文/数字/英文标点符号 都统一用半角字符, 而日文字符都统一用全角字符. 而且提出订正的字段中还包含一些clob字段.
那就函数+游标, 慢慢订正吧, 分析了一下, 要写四个函数:
1. varchar2数据类型的, 全角英文变半角.
2. clob数据类型的, 全角英文变半角.
3. varchar2数据类型的, 半角日文变全角.
4. clob数据类型的, 半角日文变全角.
开工:
第一个, 还好, 有现成函数: to_single_byte.
TO_SINGLE_BYTE returns char with all of its multibyte characters converted to their corresponding single-byte characters. char can be of datatype CHAR, VARCHAR2, NCHAR, or NVARCHAR2. The value returned is in the same datatype as [...]
