EMC优化与扩展Oracle性能解决方案

哇，好激动哦。

那多是数据库里面的东西了，其实你感兴趣的话可以比较下平时和”慢“的时候，存储是不是真的有压力。其实这种95%以上都是数据库里面逻辑问题课，哪里索引没加，平时不觉得，流量上来开销就一下子上去了。DBA学问还挺大的说。

其运行的Oracle是单实例的库还是RAC的库呢？

这个方案测试是单实例的，基于RAC的测试进行中。

让您笑话了，偶这边的环境是制造企业，可以说是15%的OLAP和85%的OLTP。到目前为止上面还真没告诉偶，具体指标是多少都是一些定性的东西。至于IOPS和Throughput是多少个预期的值实际上是多少呢？还真的不知道，只要在需要调整数据库里面内容的时候已经数据库慢啦或者丢数据的时候他们才想起偶。

不是RAC。

liulei，挺好奇你管的Oracle TPS有多少，用的DMX处理了多少IOPS和Throughput？什么时候有时间分享下？讲讲性能不牵涉到具体业务。

基准数据收集还是挺重要的，EMC很多解决方案文档里面，都会先定一个Baseline，然后看应用什么配置以后有没有什么改善。

您说的非常对

您说的这些应该是 数据库物理设计上的范畴，通过一系列的参数模型可以估算出其某些部分的性能参数，

偶很好奇的是数据库的逻辑模型 也就是说 整个体系为什么是这样的，举个例子，某张表存储代表业务上那一部分的数据，那么这些字段为啥都要这么设计，这些字段掉个个排列好不好呢？ 也许逻辑模型是这些系统的灵魂

是的，系统优化越上层效果越好，了解一些算法的人都知道，一段程序的时间和空间复杂度会指数级影响应用性能。其次是数据结构，目前大多数系统还是使用关系数据库，所以表结构的设计与优化，索引，表锁等，数据一致性需求也直接影响到性能。鉴于许多系统在应用层已经优化到一个阀值，再继续优化并不是没有可能，只是出于业务，成本考虑，用户不会去更改过多，或者花更多的时间在新功能和创新上。

所以，健壮的基础架构可以为现有的系统带来更多附加值，也就是EMC解决方案用武之地。试想一个数据库事务或者存储过程原来完成时间在10ms（假设），其中一半消耗在数据库服务器中完成，剩下5ms用来从存储获取和写入数据。那么，通过闪存和高性能存储，缩短这个过程到1ms以内，那么整个事务完成时间就减少了40%，整体性能也直接提升40%。直接明了！

如同好的摄影师能用差的镜头也能拍出唯美的PP，那么对于一些没有那么多时间的玩家花钱买好装备也能达到大师的效果。哈。

我的看法类似，在业务层面做数据库性能优化是治本，在硬件层面做优化是治标。成本角度来说，优化业务比较困难而且成本较高，优化硬件性能容易，成本低，见效快。

甲方解决了问题乙方有卖出额，皆大欢喜。

同意你的看法，这就需要用户根据自己的实际情况，技术水平，成本承受等综合考虑采用哪种方式最适合。