日归档：2013 年 11 月 1 日

关于ASM的限制，请参见 ASM – Scalability and Limits (Doc ID 370921.1) 有朋友说12.1上已经可以创建2T的文件，事实上，在很多时候，我们还是不建议这样使用，bug依然存在，维护还是问题。。。。。 例如： Bug 14181123 ROOT.SH HANGS ON OHASD.BIN REBOOT Bug 16565325 ASM FILE CREATION PERFORMANCE REGRESSION 当你碰到ASM的一些报错或者bug，怎么去检查问题呢？ 前面已经说过使用DBI_TRACE去trace asm的过程，这里再说下，结合event 10046去诊断问题。 比如一个场景，客户反映在ASM上创建表空间很慢，或者cp很慢，或者其他。。。。。很慢的问题，那么首先我们先设置 DBI_TRACE=1 来跟踪ASM的内部操作： 这里你可以看到ASM的每一个操作的详细的执行情况 然后，我们设置event 10046来跟踪该进程的执行情况 例如，我们将 +ASMDATA/RACDB/datafile/USERS.259.814462681 复制到/home/grid/asmfile 现在我们使用tkprof进行格式化： 可以看到，trace中显示了每一步我所执行的操作映射成ASM内部操作的过程和执行计划，时间等等详细信息，根据这个，不难找出瓶颈或者问题了吧，O(∩_∩)O哈哈~