保险exadata
思考EXADATA
从前年参加了一个客户EXADATA的测试后，就一直在关注和学习Exadata，不久前又参与了一次和EXADATA的PK TEST，对Exadata的兴趣正浓，虽然没有Exadata的实施经验，对它也有一些自己的看法。最近本来一直在读英文版的Exadata essential一书，突然国内一些同仁居然已经翻译成书了，立刻在dangdang下了单，准备一周之内读完，节约了我不少时间。Exadata无疑是Oracle刮起的一股旋风，虽然teradata和netzza的发展时间更久，但一直处于不温不火的状态，号称市场为王的oracle又打了一场胜仗。Exadata号称最佳DW一体机，但将DW迁移到Exadata，在迁移以前，除了了解它的优点，也需要认真考虑一些问题。
Smart scan
是一个非常好的特性，它在存储里面过滤掉不需要的字段和记录，这样可以减少大量的I/O，从而提高数据库instance的性能。但是目前只在SQL做FULL TABLE SCAN和索引快速扫描的操作时发生。如果我们的报表如果不是走FULL TABLE SCAN，则无法利用到这一特性。复杂的查询，诸如Joins, sorts, group-bys, aggregation都很可能无法利用到智能扫描。
很多已经建成运行的DW系统，是设计成星型/雪花模型，在数据库层面开启了星型转换，也就是在事实表上的外键上建有BIT MAP索引和纬度表的相关主键一一对应。报表的SQL往往是一个事实表关联数个甚至10几个纬度表，Oracle利用星型转换来提高这种典型星型/雪花SQL的查询性能。
例如，在我们一个的DW系统中(micro strategy)，利用下面的SQL初略查询出运行时间大于10秒的报表SQL，可以初步判断出，我们82%的报表都是做星型转换
（包括bitmap merge，and， minus，pruning，temp table 等等），从而无法利用到Smart scan。
SQL> SELECT COUNT(1) "ALL_SQL", SUM(CASE WHEN EXISTS (SELECT 1
FROM V$SQL_PLAN B
WHERE A.SQL_ID = B.SQL_ID
AND (B.OPERATION LIKE 'BITMAP AND%' OR B.OPERATION LIKE 'BITMAP MERGE%' OR
B.OPERATION LIKE '%TRANSFORMATION%')) THEN 1 ELSE 0 END) "STAR_SQL"
FROM V$SQLAREA A WHERE A.ELAPSED_TIME/DECODE(A.EXECUTIONS,0,1) > 10000000 AND a.PARSING_SCHEMA_NAM='DW'
SQL> /
ALL_SQL STAR_SQL
---------- ----------
126 104
当然你可以一开始就不要考虑使用星型转换，但对于一个已经在运行的生产环境，这种颠覆性的改动是基本不可能发生的。
Bloom Filters.
在各种Exadata的资料里面，布隆过滤也是oracle提到的一个关键特性，当大表和小表join的时候（hash join）发生，它和智能扫描类似，通过将这一操作下移到Cell，从而提高数据库的性能。
关于这个特性，我则是从bug里面留意到它，到目前为止，我们的生产库11.2.0.2.6，仍然屏蔽了这一特性，因为bug。
SQL> show parameter bloom;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_bloom_filter_enabled boolean FALSE
_bloom_pruning_enabled boolean FALSE
最初是遇到了性能问题，Bug 8361126 ， 并行查询时发生bloom过滤导致SQLhang住，打补丁解决后。
后来又间隙的发生SELECT产生死锁问题，后确认由bug 9124206 和 bug 8361126引起ERROR
ORA-00060: deadlock detected while waiting for resource
ORA-10387: parallel query server interrupt (normal)
关于这个bug，预期的FIX version是12g，后来我们只有屏蔽掉这一特性。
除此之外bloom filter还存在一些wrong result bug，详细可以查阅metalink。
在EXADATA的提供的数据库version里面，这一系列bug，有没有解决呢？或者有没有新的bug？
ONGOING PATCH
除了上述Bloom过滤的bug，还有更多的bug问题值得考虑。作为一个长期维护大型繁忙RAC,DW数据库的DBA，一定会遭遇到各种令人头疼bug。这和历来Oracle的策略有关，Oracle一向是先发布，占领市场，再维修。
Wrong result bug
我第一次遇到，是9i的全连接的wrong result bug，后来还遇到过几次这样的bug，当这只是留意到了的。
去年，客户反应报表数据不正确（OOPS!），经过长期间的排查后，发现SQL的结果不正确，CASE是这样
给这个SQL加上关闭查询转换的hint，返回结果正确
SQL> select /*+NO_QUERY_TRANSFORMATION */。。。
直接运行SQL，结果错误，少了几百条记录。开了SR后，没有找到任何类似案例和解决方案。
后来费劲地将几十个G的数据，导入到笔记本，重现了故障，然后又上传到metalink，最终确认了一个新的bug号,查询转换中的一种”临时表转换“导致SQL结果错误。
除此之外，还有各种在一般的环境里面见不了的奇怪的bug。
比如SQL如果写的很复杂，很多的表连接，子查询，VIEW,它可能会运行不了,直接报
ORA-03002: operator not implemented
如果发生了查询转换，也可能查不到明明存在的表
ORA-00942: table or view does not exist
ORA-942 errors are possible from queries using subquery partition pruning with temporary table transformations.
Oracle的每一个版本的数据库都是在不断的patch中，exadata也不例外，在网上看到一个case，描述的是memlock设置过小导致RAC节点不断重启的问题。
通过查询metalink note ： Exadata Critical Issues [ID 1270094.1] 可以了解目前Exadata的已经发现的问题，包括：
?Causes on-disk corruption or data loss 磁盘故障，数据丢失
?Causes failure that impacts system wide availability 系统可用性
?Causes intermittent wrong results 错误的SQL结果。
（这就是为什么以前各大银行都会采用IBM的解决方案，可靠是最重要的原因，没人会愿意自己的账号突然少了几块钱吧。不过在网上的新闻看到，不少银行已经开始部署Oracle了，比如平安，澳洲银行）
维护问题
系统迁移到EXADATA后，无疑对DBA的维护能力是一个新的考验。但关键是Exadata的维护，似乎目前只有oracle的support team能做。
Teradata还做了一个视频来调侃exadata的admin的复杂。
http://v.youku.com/v_show/id_XMzAyNTE5Njcy.html
以exadata的patch为例子，它包括三部分：
Storage Server Patch
Database Server Patch
Infiniband Switches Patch
存储和网络的patch都不是dba所能接触，而db的patch也比传统的db或者rac复杂很多。而且critical patch的频率目前很高。
如果是升级则更复杂，包括升级cell，升级database，升级crs，应用pre fix patch，升级OS，打指定的patch，涉及的各层面（存储，网络，主机）的component多达几十个。
我还记得10G早期版本的RAC，提到重启，升级，补丁，添加节点就烦，很费劲的打上一个补丁，又触发一个un-publish bug。
一个EXADATA DBA需要掌握的Skill：
System Admin
8 compute servers
8 copies of Linux
8 copies of Oracle Clusterware
14 copies more of Linux on Storage cells
Network Admin
3 InfiniBand switches
Ethernet switches & KVM switch
NDS, NTP, optional firewalls
Storage Admin
14 storage servers, each w/ 12 disks, 384GB flash
14 copies of Exadata Storage Server software
14 ASM copies of ASM installation, one on each Storage cell
Database Admin
8 copies of Oracle 11g DB Server
RAC DB
SQL statement tuning
Disaster Recovery, Backup/Restore
调优问题
EXADATA是预先配置好的一体机，就不需要DBA调优了吗？错误，EXADATA使用的仍然的Oracle数据库的优化器，它仍然需要DBA对SQL进行调优。DBA则需要学习Exadata的相关调优方法，相关的参数设置，等待事件等等。
据说存储索引的效果也不能令人感到那样满意，存储索引和分区修剪差不多，通过在闪盘里面为每个1M的存储单位维护一个数据结构（保存当前单元的最大值和最小值），用于过滤掉不需要访问存储单元。第一它需要数据是有序的才能发挥最大效果，第二它不能走索引，第三每个表只能自动维护8个列。至于具体是哪个列，什么算法，有没有办法设置，还没有找到相关资料。但是8个列肯定不够，现在的DW的事实动辄就是几百个字段。
SELECT COUNT(1),B.TABLE_NAME FROM dba_tab_columns b WHERE b.OWNER='ODS' AND B.TABLE_NAME LIKE '%TRX' GROUP BY B.TABLE_NAME ORDER BY 1
COUNT(1) TABLE_NAME
---------- ------------------------------
231 BACK_XXX_TRX
245 AP_XXX_TRX
252 PURCH_XXX_TRX
258 MATL_XXX_TRX
281 BILLINGXXX_TRX
340 PLANNED_XXXMANCE_TRX
418 DELIVXXX_TRX
449 SALES_XXX_TRX
至于最佳的OLTP
EXADATA默认采用的是Oracle的RAC，RAC是一种share everything的构架 采用的分布式锁管理和分布式缓存。由于分布式管理，RAC随着集群节点的增多，在高并发情况下（如多个节点同时修改在另外一个节点管理的缓存中的数据时），多节点间的的通讯协调复杂性将指数型增长，IP中断和CPU处理出让更会大大降低处理效率， DBA则会在系统中观测到大量GC等待事件。为了解决这种问题，有时候不得不考虑一些其它的解决手段，比如把表按instance id进行分区，插入数据的时候，保证一个instance的session只会去访问和自己对应segment中的block，从而减少产生 global cache request, gc buffer busy等待以及HW锁，其实这就是在RAC里面用上了“MPP”的解决办法。RAC是一种很优秀的数据库集群解决方案，很如果要说RAC的解决方案是“最佳”的OLTP，难免有点言过其实。听说一些售前都不推荐大型的ERP部署RAC，采用IBM的P或者Z系列服务器，反而更为可靠。
而且绝大多数OLTP的数据量都不会大于1TB，Exadata 1/4机架提供磁盘容量都远大于1TB，这样会造成磁盘的浪费。
虚拟化技术
目前Exadata只是单纯的数据库服务器，不提供任何虚拟化技术。我认为这一点是和IBM的SYSTEM P和Z解决方案(逻辑分区，微分区，Hypervisor，虚拟 I/O 服务器，APV，PowerVM Lx86，Live Partition Mobility)最大的差距。
昂贵的价格
根据网络上的一些信息，
$9,120,000 Oracle Enterprise Licenses
$4,416,000 RAC Licenses
$6,019,200 3 yr support Oracle Enterprise Edition
$5,829,120 3 yr support RAC
---------------
$25,384,320
一套完整X2全机架的费用（包括软件）是几百万美金。就算是打2折以后，也不便宜。我去年遇到一个客户用power和exadata做了pk test，exadata胜出，但是客户仍然选择了power，几倍的性能优势和10倍以上的价格差距，N倍的移植维护难度，潜在的风险，怎么选？在经济低迷的今天，性价比的确是个问题。不过，在国内，这个问题似乎可以缩小，bmw来中国可以翻几倍买。
最后Is Exadata More Trouble Than It's Worth?
这是一篇由MATTHEW MCKENZIE撰写的文章，也是我们都想知道的问题，他想说就是exadata is good,but it is not silver-bullet
也许我们可以期待Exadata的下一个版本X3。
Smart scan
是一个非常好的特性，它在存储里面过滤掉不需要的字段和记录，这样可以减少大量的I/O，从而提高数据库instance的性能。但是目前只在SQL做FULL TABLE SCAN和索引快速扫描的操作时发生。如果我们的报表如果不是走FULL TABLE SCAN，则无法利用到这一特性。复杂的查询，诸如Joins, sorts, group-bys, aggregation都很可能无法利用到智能扫描。
很多已经建成运行的DW系统，是设计成星型/雪花模型，在数据库层面开启了星型转换，也就是在事实表上的外键上建有BIT MAP索引和纬度表的相关主键一一对应。报表的SQL往往是一个事实表关联数个甚至10几个纬度表，Oracle利用星型转换来提高这种典型星型/雪花SQL的查询性能。
例如，在我们一个的DW系统中(micro strategy)，利用下面的SQL初略查询出运行时间大于10秒的报表SQL，可以初步判断出，我们82%的报表都是做星型转换
（包括bitmap merge，and， minus，pruning，temp table 等等），从而无法利用到Smart scan。
SQL> SELECT COUNT(1) "ALL_SQL", SUM(CASE WHEN EXISTS (SELECT 1
FROM V$SQL_PLAN B
WHERE A.SQL_ID = B.SQL_ID
AND (B.OPERATION LIKE 'BITMAP AND%' OR B.OPERATION LIKE 'BITMAP MERGE%' OR
B.OPERATION LIKE '%TRANSFORMATION%')) THEN 1 ELSE 0 END) "STAR_SQL"
FROM V$SQLAREA A WHERE A.ELAPSED_TIME/DECODE(A.EXECUTIONS,0,1) > 10000000 AND a.PARSING_SCHEMA_NAM='DW'
SQL> /
ALL_SQL STAR_SQL
---------- ----------
126 104
当然你可以一开始就不要考虑使用星型转换，但对于一个已经在运行的生产环境，这种颠覆性的改动是基本不可能发生的。
Bloom Filters.
在各种Exadata的资料里面，布隆过滤也是oracle提到的一个关键特性，当大表和小表join的时候（hash join）发生，它和智能扫描类似，通过将这一操作下移到Cell，从而提高数据库的性能。
关于这个特性，我则是从bug里面留意到它，到目前为止，我们的生产库11.2.0.2.6，仍然屏蔽了这一特性，因为bug。
SQL> show parameter bloom;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_bloom_filter_enabled boolean FALSE
_bloom_pruning_enabled boolean FALSE
最初是遇到了性能问题，Bug 8361126 ， 并行查询时发生bloom过滤导致SQLhang住，打补丁解决后。
后来又间隙的发生SELECT产生死锁问题，后确认由bug 9124206 和 bug 8361126引起ERROR
ORA-00060: deadlock detected while waiting for resource
ORA-10387: parallel query server interrupt (normal)
关于这个bug，预期的FIX version是12g，后来我们只有屏蔽掉这一特性。
除此之外bloom filter还存在一些wrong result bug，详细可以查阅metalink。
在EXADATA的提供的数据库version里面，这一系列bug，有没有解决呢？或者有没有新的bug？
ONGOING PATCH
除了上述Bloom过滤的bug，还有更多的bug问题值得考虑。作为一个长期维护大型繁忙RAC,DW数据库的DBA，一定会遭遇到各种令人头疼bug。这和历来Oracle的策略有关，Oracle一向是先发布，占领市场，再维修。
Wrong result bug
我第一次遇到，是9i的全连接的wrong result bug，后来还遇到过几次这样的bug，当这只是留意到了的。
去年，客户反应报表数据不正确（OOPS!），经过长期间的排查后，发现SQL的结果不正确，CASE是这样
给这个SQL加上关闭查询转换的hint，返回结果正确
SQL> select /*+NO_QUERY_TRANSFORMATION */。。。
直接运行SQL，结果错误，少了几百条记录。开了SR后，没有找到任何类似案例和解决方案。
后来费劲地将几十个G的数据，导入到笔记本，重现了故障，然后又上传到metalink，最终确认了一个新的bug号,查询转换中的一种”临时表转换“导致SQL结果错误。
除此之外，还有各种在一般的环境里面见不了的奇怪的bug。
比如SQL如果写的很复杂，很多的表连接，子查询，VIEW,它可能会运行不了,直接报
ORA-03002: operator not implemented
如果发生了查询转换，也可能查不到明明存在的表
ORA-00942: table or view does not exist
ORA-942 errors are possible from queries using subquery partition pruning with temporary table transformations.
Oracle的每一个版本的数据库都是在不断的patch中，exadata也不例外，在网上看到一个case，描述的是memlock设置过小导致RAC节点不断重启的问题。
通过查询metalink note ： Exadata Critical Issues [ID 1270094.1] 可以了解目前Exadata的已经发现的问题，包括：
?Causes on-disk corruption or data loss 磁盘故障，数据丢失
?Causes failure that impacts system wide availability 系统可用性
?Causes intermittent wrong results 错误的SQL结果。
（这就是为什么以前各大银行都会采用IBM的解决方案，可靠是最重要的原因，没人会愿意自己的账号突然少了几块钱吧。不过在网上的新闻看到，不少银行已经开始部署Oracle了，比如平安，澳洲银行）
维护问题
系统迁移到EXADATA后，无疑对DBA的维护能力是一个新的考验。但关键是Exadata的维护，似乎目前只有oracle的support team能做。
Teradata还做了一个视频来调侃exadata的admin的复杂。
http://v.youku.com/v_show/id_XMzAyNTE5Njcy.html
以exadata的patch为例子，它包括三部分：
Storage Server Patch
Database Server Patch
Infiniband Switches Patch
存储和网络的patch都不是dba所能接触，而db的patch也比传统的db或者rac复杂很多。而且critical patch的频率目前很高。
如果是升级则更复杂，包括升级cell，升级database，升级crs，应用pre fix patch，升级OS，打指定的patch，涉及的各层面（存储，网络，主机）的component多达几十个。
我还记得10G早期版本的RAC，提到重启，升级，补丁，添加节点就烦，很费劲的打上一个补丁，又触发一个un-publish bug。
一个EXADATA DBA需要掌握的Skill：
System Admin
8 compute servers
8 copies of Linux
8 copies of Oracle Clusterware
14 copies more of Linux on Storage cells
Network Admin
3 InfiniBand switches
Ethernet switches & KVM switch
NDS, NTP, optional firewalls
Storage Admin
14 storage servers, each w/ 12 disks, 384GB flash
14 copies of Exadata Storage Server software
14 ASM copies of ASM installation, one on each Storage cell
Database Admin
8 copies of Oracle 11g DB Server
RAC DB
SQL statement tuning
Disaster Recovery, Backup/Restore
调优问题
EXADATA是预先配置好的一体机，就不需要DBA调优了吗？错误，EXADATA使用的仍然的Oracle数据库的优化器，它仍然需要DBA对SQL进行调优。DBA则需要学习Exadata的相关调优方法，相关的参数设置，等待事件等等。
据说存储索引的效果也不能令人感到那样满意，存储索引和分区修剪差不多，通过在闪盘里面为每个1M的存储单位维护一个数据结构（保存当前单元的最大值和最小值），用于过滤掉不需要访问存储单元。第一它需要数据是有序的才能发挥最大效果，第二它不能走索引，第三每个表只能自动维护8个列。至于具体是哪个列，什么算法，有没有办法设置，还没有找到相关资料。但是8个列肯定不够，现在的DW的事实动辄就是几百个字段。
SELECT COUNT(1),B.TABLE_NAME FROM dba_tab_columns b WHERE b.OWNER='ODS' AND B.TABLE_NAME LIKE '%TRX' GROUP BY B.TABLE_NAME ORDER BY 1
COUNT(1) TABLE_NAME
---------- ------------------------------
231 BACK_XXX_TRX
245 AP_XXX_TRX
252 PURCH_XXX_TRX
258 MATL_XXX_TRX
281 BILLINGXXX_TRX
340 PLANNED_XXXMANCE_TRX
418 DELIVXXX_TRX
449 SALES_XXX_TRX
至于最佳的OLTP
EXADATA默认采用的是Oracle的RAC，RAC是一种share everything的构架 采用的分布式锁管理和分布式缓存。由于分布式管理，RAC随着集群节点的增多，在高并发情况下（如多个节点同时修改在另外一个节点管理的缓存中的数据时），多节点间的的通讯协调复杂性将指数型增长，IP中断和CPU处理出让更会大大降低处理效率， DBA则会在系统中观测到大量GC等待事件。为了解决这种问题，有时候不得不考虑一些其它的解决手段，比如把表按instance id进行分区，插入数据的时候，保证一个instance的session只会去访问和自己对应segment中的block，从而减少产生 global cache request, gc buffer busy等待以及HW锁，其实这就是在RAC里面用上了“MPP”的解决办法。RAC是一种很优秀的数据库集群解决方案，很如果要说RAC的解决方案是“最佳”的OLTP，难免有点言过其实。听说一些售前都不推荐大型的ERP部署RAC，采用IBM的P或者Z系列服务器，反而更为可靠。
而且绝大多数OLTP的数据量都不会大于1TB，Exadata 1/4机架提供磁盘容量都远大于1TB，这样会造成磁盘的浪费。
虚拟化技术
目前Exadata只是单纯的数据库服务器，不提供任何虚拟化技术。我认为这一点是和IBM的SYSTEM P和Z解决方案(逻辑分区，微分区，Hypervisor，虚拟 I/O 服务器，APV，PowerVM Lx86，Live Partition Mobility)最大的差距。
昂贵的价格
根据网络上的一些信息，
$9,120,000 Oracle Enterprise Licenses
$4,416,000 RAC Licenses
$6,019,200 3 yr support Oracle Enterprise Edition
$5,829,120 3 yr support RAC
---------------
$25,384,320
一套完整X2全机架的费用（包括软件）是几百万美金。就算是打2折以后，也不便宜。我去年遇到一个客户用power和exadata做了pk test，exadata胜出，但是客户仍然选择了power，几倍的性能优势和10倍以上的价格差距，N倍的移植维护难度，潜在的风险，怎么选？在经济低迷的今天，性价比的确是个问题。不过，在国内，这个问题似乎可以缩小，bmw来中国可以翻几倍买。
最后Is Exadata More Trouble Than It's Worth?
这是一篇由MATTHEW MCKENZIE撰写的文章，也是我们都想知道的问题，他想说就是exadata is good,but it is not silver-bullet
也许我们可以期待Exadata的下一个版本X3。