First post - More on Exacheck....

It's time for my first post on my new Oracle blog. I split this blog off from my personal blog, so those of you who were just Oracle interested could come here and not need to worry about my personal stuff.

In my other blog I posted a few things about Exadata and Exacheck. Here are the links to those previous articles:

Exadata Patching Part One

Exadata Patching Part Two

Exadata Patching Part Three

Exadata Patching Part Four

Exadata Patching Part Five

For my first new post here, I thought I'd continue my thoughts on Exadata and in particular on Exacheck.

While there is a lot of gold in the header of the Exacheck report, there are some things that don't get flagged there that you won't catch unless you look through the detail findings. Also, there is so much information in the Exacheck output, it's easy to just miss something. At the end of the day, it seems that it's the little details that can make all the difference.

For example:

At the top of the report there is the section titled Findings Needing Attention. This section tends to get a lot of attention, in fact I think it gets a majority of the attention. But, lurking below are interesting things that don't surface to the Findings Needing Attention list.

In the report, after the Findings Needing Attention section is a section titled MAA Scorecard. When you review your Exacheck report, how carefully do you review this section?

For example, at one customer lately I found an entry in the MAA Scorecard that might be of concern.

As I parsed through the MAA scorecard, it looked fine until I hit the section titled:

DATA CORRUPTION PREVENTION BEST PRACTICES

Low and behold, I found this jewel:

FAIL

SQL Check

The data files should be recoverable

All Databases

View

Now, that little gem is somewhat of concern. I would think that it should be in red, blinking lights with warning horns going off. Of course, it might be a totally normal condition (such as in the case of nologging direct loads into tables) but it might also be a serious indication that there are things happening to your database that you don't want to happen. For example, maybe nologging direct loads are happening and this has not been integrated into your backup/recovery planning.

So.... even though the Exacheck report is long and full of data, I'd recommend that, at least the first time, you look through the whole thing and determine which pieces you consider to be important to look at.

Bonus thought....
Monitoring is important. I'm wondering how hard it would be to automate the output from Exacheck, and then create an external table that reads those results. Then you could build some PL/SQL to automate the checking out the output for the sections that are truly important.

The challenge that I find in this is that Oracle constantly improves Exacheck and changes the output format. So keeping up with those changes would be an interesting problem.

Thoughts?

Edit History
9/6/2013 - Edited to make the links to my other articles weblinks instead of just text.