X
  • July 29, 2014

Thoughts and Musings on Oracle Exacheck

Guest Author

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:

./exachk
-set "AUTORUN_INTERVAL=1d;AUTORUN_FLAGS= -o
v;NOTIFICATION_EMAIL=firstname.lastname@company.com;PASSWORD_CHECK_INTERVAL=1"

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!

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha