Planned Reboots

In situations where the ORACLE database server has been sufficiently sized, resource utilization is well below the "fully pegged" level, the database instance has been sufficiently isolated from instabilities created by or through interaction with other application services, but availability has still not improved into the "6 months without an instance crash or blue screen" range, then planned reboots should be considered.

Recalling NT's and ORACLE on NT's architectures, applications may, over time, suffer from memory management inconsistencies commonly called "memory leaks". Primarily due to thread-safe application code that is not 100% perfect, memory leaks can and do occur. Essentially, the longer an application is continuously run without any stop/restart, the more likely it becomes to encounter an error resulting in a process failure. In those situations, the simplest method by which to clear up any memory-resident problems is to simply reboot the NT server.

It may sound a bit contradictory to suggest that one way to improve availability is to purposefully reboot the database server. The resolution of this seemingly contradictory statement is a question. Which is better:

1) Having instance crashes occurring in an unexpected and random manner. ...OR...

2) Administration staff and end users knowing that the database instance will be unavailable on a periodic basis.

If your particular availability requirements are such that the database instance is shutdown each weekend for a cold backup, then take additional advantage of that downtime by performing a complete shutdown/restart of the NT server hosting the database instance. For instance, if your site has consisently run an ORACLE production instance at least two months before an instance crash occurs (and a minimum of two months without an instance crash is not considered adequate), then a planned reboot at one month intervals may very well remove the opportunity for the instance crash conditions to develop. If having a scheduled and expected outage once per month fixes unexpected outages every two or so months, then the organization can make an informed decision as to whether this is the better approach. Although the author would tend to suggest a planned off-hours reboot as somewhat of a last resort measure, in situations where the database instance is already unavailable due to a cold backup or occasional unexpected outages cannot be tolerated, then creating scheduled down-time may minimize the un-scheduled down-time to the benefit of the organization.