The alert file (also known as the alert log) is the diary of the database. It is a simple text file written to from the day the database is “born” (created) to the end of time (when you erase it). In this file, you’ll find a chronological history of your database—the log switches; the internal errors that might be raised;
when tablespaces were created, taken offline, put back online; and so on. It is an incredibly useful file for viewing the history of a database. I like to let mine grow fairly large before “rolling” (archiving) it. The more information the better, I believe, for this file.
I will not describe everything that goes into an alert log—that’s a fairly broad topic. I encourage you to take a look at yours, however, and see the wealth of information it holds. Instead, in this section we’ll take a look at a specific example of how to mine information from this alert log, in this case to create an uptime report.
In the past, I’ve used the alert log file for the http://asktom.oracle.com web site and to generate an uptime report for my database. Instead of poking through the file and figuring that out manually (the shutdown and startup times are in there), I decided to take advantage of the database and SQL to automate that work, thus creating a technique for generating a dynamic uptime report straight from the alert log.
Using an EXTERNAL TABLE (which is covered in much more detail in Chapter 10, “Database Tables”), we can actually query our alert log and see what is in there. I discovered that a pair of records was produced in my alert log every time I started the database:
Thu May 6 14:24:42 2004
Starting ORACLE instance (normal)
That is, I always saw a timestamp record, in that constant, fixed-width format, coupled with the message Starting ORACLE instance. I also noticed that before these records would be an ALTER DATABASE CLOSE message (during a clean shutdown), or a shutdown abort message, or nothing—no message, indicating a system crash. But any message would have some timestamp associated with it as well. So, as long as the system didn’t crash, some meaningful timestamp would be recorded in the alert log (and in the event of a system crash, some timestamp would be recorded shortly before the crash, as the alert log is written to quite frequently).
I discovered that I could easily generate an uptime report if I
• Collected all of the records like Starting ORACLE instance %.
• Collected all of the records that matched the date format (that were in fact dates).
• Associated with each Starting ORACLE instance record the prior two records (which would be dates).
CHAPTER 3 ■ FILES
94
The following code creates an external table to make it possible to query the alert log. (Note: replace /background/dump/dest/ with your actual background dump destination and use your alert log name in the CREATE TABLE statement.)
5 ORGANIZATION EXTERNAL 6 (
We can now query that information anytime:
ops$tkyte%ORA11GR2> select to_char(last_time,'dd-mon-yyyy hh24:mi') shutdown,
CHAPTER 3 ■ FILES
18 select rownum r, text_line 19 from alert_log
20 where text_line like '___ ___ __ __:__:__ 20__' 21 or text_line like 'Starting ORACLE instance %' 22 )
23 )
24 where text_line like 'Starting ORACLE instance %' 25 )
26 /
SHUTDOWN STARTUP MINS_DOWN DAYS_UP DAYS_STILL_UP --- --- --- --- --- 14-sep-2009 17:11
10-oct-2009 07:00 19-oct-2009 14:54 13433.93 25.58 31-oct-2009 05:00 07-nov-2009 08:32 10291.32 11.59 11-dec-2009 13:15 11-dec-2009 14:33 77.25 34.2 14-dec-2009 14:40 14-dec-2009 14:41 .02 3.01 14-dec-2009 14:42 14-dec-2009 14:42 0 0
15-dec-2009 08:31 15-dec-2009 08:31 .03 .74 36.27 7 rows selected.
I won’t go into the nuances of the SQL query here, but the innermost query from lines 18 through 21 collects the “Starting” and date lines (remember, when using a LIKE clause, _ matches precisely one character—at least one and at most one). That query also numbers the lines using rownum. Then, the next level of query uses the built-in LAG() analytic function to reach back one and two rows for each row, and slide that data up so the third row of this query has the data from rows 1, 2, and 3. Row 4 has the data from rows 2, 3, and 4, and so on. We end up keeping just the rows that were like Starting ORACLE instance %, which now have the two preceding timestamps associated with them. From there,
computing downtime is easy: we just subtract the two dates. Computing the uptime is not much harder (now that you’ve seen the LAG() function): we just reach back to the prior row, get its startup time, and subtract that from this line’s shutdown time.
My Oracle 11g Release 2 database came into existence on 14-Sep-2009 and it has been shut down six times (and as of this writing it has been up for 36.27 days in a row).
If you are interested in seeing another example of mining the alert log for useful information, go to http://tinyurl.com/y8wkhjt. This page shows a demonstration of how to compute the average time it took to archive a given online redo log file. Once you understand what is in the alert log, generating these queries on your own becomes easy.
In addition to using an external table to query the alert log in 11g, you can easily view the alert log using the ADRCI tool. That tool lets you find, edit (review), and monitor (interactively display new records as they appear in the alert log). Also, the alert log in 11g and above is available in two versions—
the old version we just used and an XML version:
ops$tkyte%ORA11GR2> select value from v$diag_info where name = 'Diag Alert';
VALUE
--- /home/ora11gr2/app/ora11gr2/diag/rdbms/orcl/ora11gr2/alert
ops$tkyte%ORA11GR2> !ls /home/ora11gr2/app/ora11gr2/diag/rdbms/orcl/ora11gr2/alert log.xml
ops$tkyte%ORA11GR2> !head /home/ora11gr2/app/ora11gr2/diag/rdbms/orcl/ora11gr2/alert/log.xml
CHAPTER 3 ■ FILES
96
<msg time='2009-09-14T17:11:45.823-04:00' org_id='oracle' comp_id='rdbms' msg_id='opistr_real:935:3971575317' type='NOTIFICATION' group='startup' level='16' host_id='dellpe' host_addr='192.168.1.252'
pid='31552' version='1'>
<txt>Starting ORACLE instance (normal) </txt>
</msg>
<msg time='2009-09-14T17:11:46.507-04:00' org_id='oracle' comp_id='rdbms' msg_id='ksunfy:14932:2937430291' type='NOTIFICATION' group='startup' level='16' host_id='dellpe' host_addr='192.168.1.252'
If you have utilities or tools to generate reports from XML (such as an Oracle database using XDB—
XML DB—for example), you may query/report on that format as well.
Of course, Enterprise Manager also displays the important alert log information as well.