Method for performing a corrective action upon a sub-system

• US 7,849,367 B2
• Filed: 04/10/2008
• Issued: 12/07/2010
• Est. Priority Date: 02/22/2002
• Status: Expired due to Term

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Srivastava, Rahul, Halpern, Eric M.
• Primary Examiner(s): Iqbal; Nadeem
• Application Number:
  US12/100,959
• Publication Number:
  US 20080215924A1
• Time in Patent Office: 971 Days
• Field of Search: 714 1- 4, 714/13, 714/15, 714/16, 714/18, 714/20, 714/21, 714/26, 714/27, 714/31, 714/37, 714/39, 714/47, 714/48
• US Class Current: 714/47.1
• CPC Class Codes: G06F 11/0709 in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
• CPC Class Codes: G06F 11/0757 by exceeding a time limit, i.e. time-out, e.g. watchdogs
• CPC Class Codes: G06F 11/0793 Remedial or corrective actions recovery from an exception in an instruction pipeline G06F9/3861; by retry G06F11/1402; for recovering from a failure of a protocol instance or entity H04L69/40
• CPC Class Codes: G06F 11/3006 where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems multiprogramming arrangements G06F9/46; allocation of resources G06F9/50
• CPC Class Codes: G06F 11/3055 Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available error or fault processing without redundancy G06F11/0703; error detection or correction by redundancy in data representation G06F11/08; error detection or correction by redundancy in operation G06F11/14; error detection or correction by redundancy in hardware G06F11/16
• CPC Class Codes: G06F 11/3082 the data filtering being achieved by aggregating or compressing the monitored data

Abstract

A server self health monitor (SHM) system monitors the health of the server it resides on. The health of a server is determined by the health of all of a server'"'"'s sub-systems and deployed applications. The SHM may make health check inquiries to server sub-systems periodically or based on external trigger events. The sub-systems perform self health checks on themselves and provide sub-system health information to requesting entities such as the SHM. Sub-systems self health updates may be based on internal events such as counters or changes in status or based on external entity requests. Corrective action may be performed upon sub-systems by the SHM depending on their health status or the health status of the server. Corrective action may also be performed by a sub-system upon itself.

Claims

1. A method for monitoring the health of a server comprising:

maintaining a server having a sub-system and a server self health monitor;

detecting the occurrence of a health check event by the server self health monitor;

transmitting a request by the server self health monitor to the sub-system for sub-system health information;

determining the health of the server by the server self health monitor using the sub-system health information; and

performing a corrective action upon the sub-system, by the server health monitor or the sub-system, wherein the corrective action is based on the health of the sub-system; and

wherein a first parameter specifies the maximum number of times a server can be restarted within a period of time specified by a second parameter.

2. The method as claimed in claim 1 wherein the health check event is expiration of a period of time.

3. The method as claimed in claim 1 wherein the health check event is a request from an administration server.

4. The method as claimed in claim 1 wherein the health check event is an event occurring external to the server, and wherein occurrence of the event is communicated to the server self health monitor.

5. The method as claimed in claim 1 wherein said transmitting a request includes transmitting a request from the server self health monitor to all sub-systems in a server, to request each sub-system'"'"'s health information.

6. The method as claimed in claim 1 wherein the server provides its health information to requesting entities.

7. The method as claimed in claim 1 wherein said determining sub-system health information includes the server self health monitor failing to receive sub-system health information from a sub-system, and the server self health monitor determining the sub-system has failed as a result of the failure to receive sub-system health information from the sub-system.

8. The method as claimed in claim 1 wherein said determining the health of the server includes determining whether all the sub-systems are in a failed state.

9. The method as claimed in claim 1 wherein said determining the health of the server includes determining whether a critical sub-system is in a failed state.

10. The method as claimed in claim 1 further comprising:

processing the server health information.

11. The method as claimed in claim 10 wherein said processing includes restarting a failed sub-system.

12. The method as claimed in claim 10 wherein said processing includes restarting all sub-systems if a critical sub-system is failed.

13. The method as claimed in claim 10 wherein said processing includes storing the sub-system health information.

14. The method as claimed in claim 10 wherein said processing includes determining if a condition is met.

15. The method as claimed in claim 14 wherein said processing includes determining if the sub-system'"'"'s health status has changed.

16. The method of claim 1, wherein a health update indicates that the sub-system is at one of multiple pre-defined health levels.

17. The method of claim 16, wherein health levels correspond to conditions, the conditions including good, failed, and between good and failed.

18. The method of claim 1, wherein the sub-system is set to a critical level if a minimum number of transactions have timed out.

19. The method of claim 1, wherein the sub-system performs a health check upon itself and provides sub-system health information to requesting entities.

20. The method of claim 1, wherein sub-system health updates are triggered by external entity requests, internal events such as counters, or changes in status.