ORION
最初知道ORION是从Piner的blog上，大概他们经常需要做数据库存储选型方面的工作，作出的图形很直观。
前阵子还买了本他的新书，书中有ORION的章节，还介绍了很多基本的主机存储系统概念和架构，还有实践心得 — 对我这样的主机盲获益非浅；书中还包括企业数据库的监控管理架构设计，实用的案例等，涉及面比较广，强烈推荐给只知道Oracle数据库的工程师。
引用OTN的说法，
ORION is useful for understanding the performance capabilities of a storage system, either to uncover performance issues or to size a new database installation.
它附带的用户手册很详细，还讲述了OLTP和OLAP不同数据库业务下，对存储的设计关注点的不同。
由于SAN总是黑箱，测试起来，感觉结果有点夸张，可能是SAN Cache的原因。但可以用来比较不同存储的能力。
If you use Orion to simulate OLTP, be aware that the profile is not exactly like Oracle. Orion uses libaio asynchronous I/O routines (e.g., io_submit(2)/io_getevents(2)) for reads as well as writes. This differs from a real Oracle database workload, because the main reads performed by the server in an OLTP workload are db file sequential reads which are random single-block synchronous reads. For that matter, foreground direct path reads are mostly (if not entirely) blocking single block requests. The net effect of this difference is that Orion can generate a tremendous amount of I/O traffic without the process scheduling overhead Oracle causes with blocking reads.
下图是测试存储的每秒的IO能力
下面是测试存储在一定IO Load下的延迟(response time)
结合2个结果，可以得出在不同的IOPS情况下，单个IO的平均响应时间分别是多少。
结果比Piner的图差多啦。
