先尝试kill会话或者重启尽快恢复业务吧，表象为shared pool的latch，还需要进一步分析trace查明原因

Chains most likely to have caused the hang:
 [a] Chain 1 Signature: <not in a wait><='latch: shared pool'<='latch: row cache objects'<='library cache load lock'
     Chain 1 Signature Hash: 0x3d174963
 [b] Chain 2 Signature: 'row cache lock'<='library cache load lock'<='cursor: pin S wait on X'
     Chain 2 Signature Hash: 0xdcd81129
 [c] Chain 3 Signature: <not in a wait><='latch: shared pool'<='latch: row cache objects'<='library cache load lock'
     Chain 3 Signature Hash: 0x3d174963

昨天别的同事也重启了数据库 恢复了业务，估计问题还是出现。

还有哪些地方需要分析的

请提供下故障前的1-2个awr报告

根据目前提供trace文件中的某一个HANG ANALYSIS只能确认是内存问题，目前的信息无法确认具体原因。请提供下故障前的2个awr，或者是下载平台上的巡检脚本上传巡检包。

您好，根据分析，发现是ASM先挂了，挂的原因就是内存不足，大量操作等待ASM file metadata operation，trace中大量KFN的函数。之后数据库无法连接ASM，就自动挂了

1、目前asm内存为默认值1G，将ASM的memory_target调整为2G

2、当前主机有90几G的内存，而数据库的内测仅4G，建议先将DB的SGA调到20G，PGA调大到5G

内存确实不合理，已经进行调整。

后续观察一下