For repairs, upgrades, and changes that require you to isolate one or more instances or nodes, Oracle RAC provides interfaces that relocate, disable, and enable services to minimize service disruption to application users. When you relocate a service, you indicate the service should run on another instance temporarily. If you forcibly disable a service, then the service is stopped on all database instances and is no longer available. Disabled services are not restarted automatically. When a service is stopped or relocated, FAN is published with a planned reason code, typically reason=user. Once you complete the operation, you can return the service to normal operation or enable the service and then restart it. When a service restarts, FAN is published with UP status codes.
Due to dependencies, if you manually shutdown your database, then all of your services for that database automatically stop. If you want your services to automatically start when you manually restart the database, then you must set the management policy of the service to automatic. If you want to shut down only one instance of the database, but not the service, you can use the srvctl stop instance command with the -f parameter. When you use the -f parameter with this command, the database services that were running on that instance are failed over to another instance if possible.
See Also:
Managing Planned Outages Without User Interruption
You may have to stop database instances for many reasons, such as upgrading the Oracle software, patching, and replacing hardware. The steps in this section result in the least impact to users and requests are not interrupted.
For planned outages, the recommended approach is to drain requests over a controlled time period from FAN-enabled Oracle connection pools. Application Continuity provides continuous service for those requests that do not complete within the allotted time.
Using any FAN-aware pool with Fast Connection Failover configured (such as OCI session pools, Universal Connection Pool, Oracle WebLogic Server Active GridLink for Oracle RAC, or ODP.NET) allows sessions to drain at request boundaries after receipt of the FAN planned DOWN event. Requests are far more important than transactions because this allows the issued work to complete.
To manage a planned outage without user interruption:
Use SRVCTL to relocate the service from an instance or, if you are using a UNIFORM service, then shut down the service on an instance. Do not use the -force flag with any of these commands. The connection pool automatically releases a connection at a request boundary.
The FAN planned DOWN event clears idle sessions from the connection pool immediately and marks active sessions to be released at the next check-in. These FAN actions drain the sessions from the instance without disrupting the users.
Existing connections on other instances remain usable, and new connections can be opened to these instances if needed.
Not all sessions, in all cases, will check their connections into the pool. It is best practice to have a timeout period after which the instance is forcibly shut down, evicting any remaining client connections.
For those pools that are configured to use Application Continuity, Universal Connection Pool, or Oracle WebLogic Server Active GridLink for Oracle RAC, an attempt is made to recover these remaining sessions, masking the outage from users and applications.
Once the upgrade, patch, or repair is complete, restart the instance and the service on the original node.
The FAN UP event for the service informs the connection pool that a new instance is available for use, allowing sessions to be created on this instance at next request boundaries.