We saw this issue during our rolling patch upgrade. We had a 2 node rac config
with 184.108.40.206 and GI 12.2 as well. Users were being directed to the instance
that was being shutdown or startup. Our users got Ora-1033 even though there
was a perfectly good instance running on another node.
According to oracle docs if your stop and start an instance via Srvctl you
should never be direct to an instance that is currently not available. We
couldn’t reproduce the issue though via a simple srvctl stop instance and start
Does anybody know if f there’s a setting or parameter I’m missing here? How do
I stop connections being directed to an instance that is in the middle of being
shutdown or starting up.
On 26 Sep 2019, at 5:33 am, Mladen Gogala <gogala.mladen@xxxxxxxxx> wrote:
On 9/25/19 2:59 PM, Luis Claudio Dias dos Santos wrote:You are confusing two things:
My question: is there a way to perform some kind of manual node eviction?
- Node eviction, which is performed by CRS to prevent split brain condition
- Shutdown, which is performed by a DBA, for whatever reason.
Next time in such situations we would manually evict the node, and justYou can start instance standalone, using srvctl start instance -d db -i inst
enable it after a fully flawless instance startup.
-o nomount. You can not mount it. As soon as you mount the instance, you are
accessing the shared resources, namely the control file and the cluster
registry. When opening the database, you will also use shared resources: ASM
disk group(s), redo logs and data files. Accessing shared resources requires
coordination done by CRS.
I would use adrci to figure out what is the problem with the evicted
instance. It may be hardware or it may be software. The problem is in the
Tel: (347) 321-1217