Just the other day, I was telling you about an outage caused by ASM maintenance so when I was on My Oracle Support and they had an article entitled "ASM Alert! : After A Rebalance Operation, An ASM Disk Goes Offline In A RAC ASM Configuration (External Redundancy Diskgroups)" with note ID 1537143.1 you're darn right I was interested and read it. I suggest you do the same if you have to deal with ASM on RAC instances because it describes a very real situation where an ASM instance may not realize the disk was dropped on another ASM instance on purpose and then it gets expelled from the first ASM instance.
Why is this so interesting? It sounds a lot like what I've encountered several times over the past year, and it affects several different database products INCLUDING Exadata on certain releases of the database and Bundle Patches. Of course we have seen this on non Exadata instances, where the likelihood of us encountering the issue are higher as they might not see large database patch increments which could introduce the fix and have us avoid this altogether. I'll be asking my DBAs about this tomorrow. Will you? Why not?
The article speaks for External Redundancy Diskgroups so can you please explain the tie to Exadata? Thanks for this alert!
ReplyDeleteKevin,
ReplyDeleteThanks for your interest, and for asking the question! The note indicates that this bug is in several different versions of Bundle Patches that are delivered for Exadata, so I felt it important to highlight that just in case people thought it may not affect them if they were on that platform. Did that address your question, or was it more specifically why External Redundancy Diskgroups matter for Exadata?