PCIE SSD对数据库架构的影响巨大？参与讨论得派克金笔！（获奖名单已公布-2014-6-27）

wolfop

PCIE的SSD虽然能对数据库虽然有提升，但是其实也带来很多问题，如果你不在乎数据安全来说，你可以随便用，实际上问题很多
1， 传统磁盘的随机读写IOPS只有一百多，PCIE SSD的随机读写IOPS高达惊人的50多万(详细数据请参考http://www.shannon-sys.com/direct-io-g2_zh.html)。 随机读写延迟也从毫秒级别降到微秒级别。我们应该怎么才能充分利用PCIE SSD这些出色的性能来优化我们的数据库架构和性能呢？
注意一点PCIE SSD是插在数据库服务器上的那么，如果服务器宕机了，你肯定访问不了了。这对业务关键系统是很可怕的，所以基本职能用来做只读缓存。对于oracle来说，可以用来做extend SGA，但是注意，extend SGA还是缓存，如果你的fast_recover_target不变，你对底层盘阵/磁盘的写IO需求并没有变化，仍然要写磁盘，仍然可能在高IOPS写的情况下性能下降，和是否用PCIE SSD没直接关系。聊以自慰的是的确可以释放底层磁盘的IOPS read的需求。
  如果做写缓存（一般是借助第三方驱动，例如linux的b-cache之类），那么这台机器宕机了怎么办，你只能通过dataguard来保护你的DB，不好意思，那么你的应用响应时间 log file sync的性能影响主要是网络，你的SSD帮不了什么忙。当然，如果你愿意接受数据丢失，可以用最大性能模式，前提是你允许宕机切换丢数。
  即便读，也不是一个完美的解决方案，对于以随机读较多的OLTP还好，但是对于Oracle的OLAP来说，原因在于
1）如果你用做extend SGA，不要忘记数据仓库类型的工作负载是采用并行执行，而11G开始并行执行的读缺省采用direct path read，和SGA无关。除非你打算用实际用的很少的in memory parallel execution。
2）你更加需要依赖别的驱动作为块设备的读cache，这类驱动并不知道你到底在做什么读，一个0级别的数据库备份就可能让你本来应该LRU保存的对SLA有效的数据块被换出去。

2， 在PCIE SSD的帮助下，我们自己是否可以在普通服务器甚至PC上配置出类似Oracle Exadata性能的架构呢？ 如果可以的话，应该怎么配置？
如果是跑ORACLE的话，没戏，没有smart-scan之类的帮助，你永远是一个share disk架构，在OLAP上面不可能和share disk+share nothing的Exadata比。实际上在Exadata上测试过，禁用smart scan以后，OLAP的读等待事件从cell smart table scan变成cell multi block physical read以后，性能下降到原来1/3。OLTP呢，除非你能接受宕机不是0数据丢失而采用最大性能模式，否则你的log file sync永远有一个最大可用性的DG的over head
3,  使用PCIE SSD来保存我们公司的关键数据足够安全吗？
   关键在于怎么用，如果你把PCIE SSD做了写缓存或者干脆把redo/datefile放到上面，都用DG的最大可用性方式，肯定足够安全，否则，你是打算接受HA切换（不是DR切换）RPO!=0还是接受RTO长达数小时（比如你的服务器主板坏了）。退而求其次就是做只读缓存，对写密集应用帮助有限。
4， 通常都是使用什么工具来评测PCIE SSD？ 测试PCIE SSD应该关注哪些数据？
  不关心。

其他数据库，也有同样的问题，DB2/INFORMIX，要做到HA切换0数据丢失，要么只是只读缓存，要么就是做HADR的同步方式。

wolfop

回复 60# to407

真笨，人家给symantec销售搞定了，就算11GR2，也要死活用一个要钱的CFS。