DB2 最佳实践: DB2 数据库存储机制

核心提示： 虽然存储世界变得更加虚拟化，但事实上数据仍然存储在机械磁盘驱动器上，DB2 最佳实践: DB2 数据库存储机制(4)，无论使用哪家供应商的存储子系统，最终数据仍存储在机械磁盘驱动器上，虽然过去十来年碟片大小有了长足的进步，但若要增加每个 CPU 核的物理磁盘数而不仅仅是空间，也就是旋转的物理磁盘

虽然存储世界变得更加虚拟化，但事实上数据仍然存储在机械磁盘驱动器上。无论使用哪家供应商的存储子系统，最终数据仍存储在机械磁盘驱动器上，也就是旋转的物理磁盘碟片上。LUN 可提供的存储带宽与组成它的实际物理磁盘的数量成正比。

虽然存储控制器缓存可帮助提高存储带宽，但 DB2 数据库系统已经将相关数据缓存到它们的缓冲池中。这限制了存储控制器充分减少实际物理磁盘需求，以支持 DB2 数据库服务器等 I/O 密集型系统的能力。在通常为 I/O 密集型的企业数据库系统中，最终结果是完全找不到实际物理磁盘的替代品。

除了传统的 SAN 存储控制器外，附加的存储虚拟化层也正在被添加到企业中，它们进一步为 DBA 抽象物理磁盘。这种虚拟化的例子有 San Volume Controller (SVC) 和 AIX® VIOS 。这些形式的虚拟化可提供称心的功能增强，例如透明地从一组 LUN 向另一组 LUN 迁移的能力，或者多个主机 LPAR 共享一条光纤通道 Host Bus Adapter (HBA) 的能力。但是，这样做需要付出一定的代价，通常包括 I/O 路径中出现更多的子系统。此外，对于 I/O 密集型系统，它们并不能减少对实际物理磁盘的需求。

处理高度虚拟化的存储

如本文简介部分所述，磁盘存储越来越多地被当做一种普通用品，可用存储空间常常被从其所在物理设备中抽象出来。

如果您的企业的 I/O 基础结构要求使用这样的存储系统，那么 DBA 需要继续确保所提供的虚拟 LUN 真正由专用的物理磁盘组成。原因是：如果实际磁盘太少，跟不上 CPU 的速度，那么企业系统很快会变成 I/O 密集型系统。不幸的是，虽然我们这些关心数据库性能的人是以实际磁盘数量来衡量存储需求的，但存储管理员却不同，他们只按空间的概念来考虑存储需求。虽然过去十来年碟片大小有了长足的进步，但若要增加每个 CPU 核的物理磁盘数而不仅仅是空间，只会变得越来越难。