日归档:2013 年 11 月 1 日

收集ASM的信息

当ASM出现故障时,需要收集的主要信息如下(来自于MOS,log SR时,通常让你提供alert,trace和这些信息),

发表在 ASM | 标签为 , | 留下评论

结合event 10046跟踪ASM的所有操作

关于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哈哈~

发表在 ASM | 标签为 , , | 留下评论