我们需要迁移生产数据库的存储。这样做的适当方法是什么，我们需要采取哪些特定/通用的预防措施？
数据库配置：
卷管理器 - 使用原始磁盘的 ASM。ASM 外部冗余作为存储从存储子系统
数据库版本发布 - Oracle 10g R2
数据库大小 - 约 5TB
现有存储（来源）：HP MSA 2312sa 双控制器。直接连接到我们的数据库服务器（无 fc 或以太网交换机）。
Oracle 二进制文件也在此存储上
新存储（目标）：HP EVA6300 FC 存储。该存储将通过 FC 交换机连接到主机。
我们能否使用基于主机的存储迁移（如 VxVM Plex 连接/分离）将数据从源 LUN 复制到目标 LUN？
我们是否必须使用 Oracle RMAN 备份和恢复方法进行存储迁移？
如果我加入两个/更多复杂的视图（通过加入两个/更多表组成的视图）；它会导致对基表的多次读取迭代吗？
仅在基表本身上设置连接条件不是更有效吗？
这是我在我们的生产 Oracle 10g R2（ASM 磁盘组）环境中分析过的一个问题，sql 查询是由应用程序本身动态生成的，而不是使用表来提取结果，而是使用复合视图。
此外，条件连接经常在这些复合视图上实现。
复杂视图上的这种连接是否会不必要地导致高 CPU 利用率并占用宝贵的缓冲区缓存？
我们的生产数据库之一具有相当奇特的 16KB 块大小。这个数据库是大约 2 年前创建的，当时数据库的大小只有大约 1TB。
然而，在过去 2 年中，db 大小已增长到大约 5TB。
工作负载是 OLTP（事务）和 OLAP（报告）的混合。
这个数据库块大小导致我们的数据库缓冲池不断被填满（95%~100% 已满）。
数据库在原始设备上使用 ASM。
16KB db 块大小是否次优？
这么大的块大小是否会对我们的存储子系统性能产生不利影响？
如果是这样，可以做些什么来纠正这种情况？
这里值得注意的是，我们实际上为报告和我们的应用程序（业务逻辑）执行了大量的全表扫描。
OLTP 性质源于这样一个事实，即我们的应用程序还具有事务性（金融事务）模块。
我们的数据库中存在大量非活动会话。
我们如何清理这些不活跃的会话？
数据库 - 带有 ASM 的 Oracle 10g R2