Thoughts and Musings on Oracle Exacheck

If you deal with Oracle Exadata, then you are probably aware of Exacheck. Exacheck is a tool that is used to determine the health of the entire Exadata infrastructure. (Note that Exacheck is also available for Exalogic but for the purposes of this discussion we will be dealing with Exacheck and Exadata).

The infrastructure checks on Exadata includes checking the database, the cell servers, the network and the other components of the Exadata machine. When I do classes and talk about Exacheck, I ask the attendees if they wanted to find out the health of their entire infrastructure, do they have a single tool that can quickly give them an idea of the health of their entire database or application Infrastructure in just a few moments? Universally the answer is no. Exacheck provides this tool for Exadata.

Beyond health, the Exacheck tool provides a review of the system configuration compared to Oracle best practices. This review includes a number of checks, some of which may or may not apply in your specific environment. However, each of the checks does cover each Oracle best practice, and as such, you might find specific gaps in your architecture by reviewing the Exacheck report.

I’m not going to re-invent the wheel by showing you the different parts of the Exacheck report. I have previously written on Exacheck on my old blog site. The Exacheck is updated and improved all the time. For example, since the post that I referenced above, the Exacheck output now includes a detailed list of each component, the current level of the software that the component and compares the current version with the recommended versions and indicates if your version is still supported.

What I’d like to focus on in this post are some of the brand new features that have been made available in the latest version of Exacheck – 2.2.5.

The first thing I’d like to point out is that Exacheck is constantly being improved. The Exacheck six months ago has been much improved. To keep up with the new functionality in Exacheck, the best place to go is the Exacheck Feature Fix History document. This document is contained in the download package that includes Exacheck. In the latest version of Exacheck as of this writing (2.2.4_2014-228) the Exacheck Feature and Issue Fix History Document contains a history of the new features, and also lists features that have been fixed and removed.

In Exacheck version 2.2.4_2014-228 we have some great new features. Let's look at a few of these.

The Exacheck Daemon Can be Configured to Auto-Start Upon Reboot

Exacheck 2.2.2 introduced a daemon process that provides for automated execution of Exacheck operations. You can run Exacheck on a reoccurring basis (hours or days). Exacheck also includes the ability to automatically email the results to a recipient. Here is an example of enabling the Exacheck Daemon:


In this case the Exacheck AUTORUN_INTERVAL parameter is set so that Exacheck runs on a daily basis. Each run will email the report to the email value NOTIFICATION_EMAIL parameter.

Having adjusted the settings, we would start the Exacheck daemon. This is required anytime we use the –set command to modify a parameter as seen here:

./exachk -d start

Further Exacheck 2.2.3 provides the ability to define a schedule when Exacheck is executed. For example:

./exachk -set "AUTORUN_SCHEDULE=15,16,17 * * 2"

Will setup Exacheck to run on hours 15-17 on every day of the month that is a Tuesday. After we issue the –set command we would need to start the daemon again by issuing the exachk command again with the –d start parameter. You can query the Exacheck daemon to see when the next run is by using the –nextautorun parameter. You can use the –status parameter to look at the status of the Exacheck daemon.

Increased daemon error logging ability

Exacheck has a lot of logging that is handy to look at if you are concerned that there are problems with the output of Exacheck, or if the daemon fails. Many people are familiar with the regular Exacheck output, but they are not familiar with the logging. You will find these logs contained in the Exacheck report output zip file in a directory called logs. Also, the log files are contained on disk, in a directory called logs, which is associated with the individual Exacheck run.

The main log file is called Exacheck_error.log. This contains any errors that occurred during the Exacheck report output. The daemon process itself will include information on errors and problems that it has raised in the error log.

Collection Manager for ORAchk, RACckeck and Exadata (MOS Note 1602329.1)

Collection Manager provides a central repository for Exacheck information, and other collection information. This makes collection, management, reporting and life cycle maintenance of Enterprise level Exacheck data easier to deal with. Collection Manager now provides a GUI front end. This new front end makes it easier to manage the repository of this collected information. MOS note 1602329.1 provides a great deal of information on the Collection Manager.

There are other new Exacheck features, and there continue to be new Exacheck features introduced all the time. So, keep up with these changes and make sure that you are always using the most current version of Exacheck!

More coming soon!


Post a Comment:
  • HTML Syntax: NOT allowed

Welcome to Robert G. Freeman's Oracle Blog. My specific interest is with Oracle Database and Oracle Exadata. I've been involved with Oracle databases for over two decades and have worked for Oracle now for over 4 years. Site Meter

  • Subscribe by Email
  • Search

    « July 2016