Yes, it's very suspicious to me. No, at this time I can't get the errors
from the logs. I don't have the logs available to me and would need to get
them restored. I am more interested in how do we get these databases back
online than in finding the root cause right now. We do have snapshot
controlfiles still available to us. We should be able to use that to
restore the controlfile and go from there, shouldn't we? I need to get
them moved to the non-ASM host as soon as possible since they were supposed
to be migrated to the new non-ASM at the end of December. We had the
initial issue two weeks earlier, so haven't been able to migrate them.
On Mon, Jan 10, 2022 at 1:25 PM Andy Klock <andy@xxxxxxxxxxxxx> wrote:
On Monday, January 10th, 2022 at 3:09 PM, Sandra Becker <
The initial problem was the root mount ( / ) filling up. After they
cleared up that issue, we found that we could no longer log in to the
databases. We tried bouncing the databases and that made no difference. The
sys admins couldn't find a reason on their end and we couldn't find
anything in the logs prior to the reboot. The only thing we saw in logs
after the reboot was that it wouldn't recognize the ASM disk. "Reboot"
seems to be their stock answer to solve all problems.
Mounts filling up, things getting "cleared up", and missing libraries
seems a bit suspicious. Can you share the exact errors you are seeing in