Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
CHAPTER 3 ■ FILES 87 6 ( 7 TYPE ORACLE_LOADER 8 DEFAULT DIRECTORY data_dir 9 ACCESS PARAMETERS 10 ( 11 records delimited by newline 12 fields 13 REJECT ROWS WITH ALL NULL FIELDS 14 ) 15 LOCATION 16 ( 17 'alert_AskUs.log' 18 ) 19 ) 20 REJECT LIMIT unlimited 21 / Table created. We can now query that information anytime: ops$tkyte@ORA10G> select to_char(last_time,'dd-mon-yyyy hh24:mi') shutdown, 2 to_char(start_time,'dd-mon-yyyy hh24:mi') startup, 3 round((start_time-last_time)*24*60,2) mins_down, 4 round((last_time-lag(start_time) over (order by r)),2) days_up, 5 case when (lead(r) over (order by r) is null ) 6 then round((sysdate-start_time),2) 7 end days_still_up 8 from ( 9 select r, 10 to_date(last_time, 'Dy Mon DD HH24:MI:SS YYYY') last_time, 11 to_date(start_time,'Dy Mon DD HH24:MI:SS YYYY') start_time 12 from ( 13 select r, 14 text_line, 15 lag(text_line,1) over (order by r) start_time, 16 lag(text_line,2) over (order by r) last_time 17 from ( 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 /
88 CHAPTER 3 ■ FILES SHUTDOWN STARTUP MINS_DOWN DAYS_UP DAYS_STILL_UP ----------------- ----------------- ---------- ---------- ------------- 06-may-2004 14:00 06-may-2004 14:24 06-may-2004 14:24 .25 .02 10-may-2004 17:18 10-may-2004 17:19 .93 4.12 26-jun-2004 13:10 26-jun-2004 13:10 .65 46.83 07-sep-2004 20:13 07-sep-2004 20:20 7.27 73.29 116.83 I won’t go into the nuances of the SQL query here, but the innermost query from lines 18 through 21 collect the “Starting” and date lines (remember, when using a LIKE clause, _ matches precisely one character—at least one and at most one). It 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 10g database came into existence on May 6 and it has been shut down four times (and as of this writing it has been up for 116.83 days in a row). The average uptime is getting better and better over time (and hey, it is SQL—we could easily compute that now, too). If you are interested in seeing another example of mining the alert log for useful information, go to http://asktom.oracle.com/~tkyte/alert_arch.html. 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. Data Files Data files, along with redo log files, are the most important set of files in the database. This is where all of your data will ultimately be stored. Every database has at least one data file associated with it, and typically it will have many more than one. Only the most simple “test” database will have one file. In fact, in Chapter 2 we saw the most simple CREATE DATABASE command by default created a database with two data files: one for the SYSTEM tablespace (the true Oracle data dictionary) and one for the SYSAUX tablespace (where other nondictionary objects are stored in version 10g and above). Any real database, however, will have at least three data files: one for the SYSTEM data, one for SYSAUX data, and one for USER data. After a brief review of file system types, we’ll discuss how Oracle organizes these files and how data is organized within them. To understand this, you need to know what a tablespace, segment, extent, and block are. These are the units of allocation that Oracle uses to hold objects in the database, and I describe them in detail shortly.
- Page 82 and 83: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 84 and 85: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 86 and 87: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 88 and 89: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 90 and 91: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 92: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 95 and 96: 50 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 97 and 98: 52 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 99 and 100: 54 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 101 and 102: 56 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 103 and 104: 58 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 105 and 106: 60 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 107 and 108: 62 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 110 and 111: CHAPTER 3 ■ ■ ■ Files In this
- Page 112 and 113: CHAPTER 3 ■ FILES 67 Without a pa
- Page 114 and 115: CHAPTER 3 ■ FILES 69 and even dat
- Page 116 and 117: CHAPTER 3 ■ FILES 71 all operatio
- Page 118 and 119: CHAPTER 3 ■ FILES 73 *.cluster_da
- Page 120 and 121: CHAPTER 3 ■ FILES 75 ops$tkyte@OR
- Page 122 and 123: CHAPTER 3 ■ FILES 77 • To maint
- Page 124 and 125: CHAPTER 3 ■ FILES 79 • Resource
- Page 126 and 127: CHAPTER 3 ■ FILES 81 3 l_dummy nu
- Page 128 and 129: CHAPTER 3 ■ FILES 83 Trace Files
- Page 130 and 131: CHAPTER 3 ■ FILES 85 _qerixAlloca
- Page 134 and 135: CHAPTER 3 ■ FILES 89 A Brief Revi
- Page 136 and 137: CHAPTER 3 ■ FILES 91 Redundant Ar
- Page 138 and 139: CHAPTER 3 ■ FILES 93 (data from m
- Page 140 and 141: CHAPTER 3 ■ FILES 95 dictionary t
- Page 142 and 143: CHAPTER 3 ■ FILES 97 ■Note df i
- Page 144 and 145: CHAPTER 3 ■ FILES 99 “accidenta
- Page 146 and 147: CHAPTER 3 ■ FILES 101 So, at the
- Page 148 and 149: CHAPTER 3 ■ FILES 103 Password Fi
- Page 150 and 151: CHAPTER 3 ■ FILES 105 USER is "SY
- Page 152 and 153: CHAPTER 3 ■ FILES 107 Flashback L
- Page 154 and 155: CHAPTER 3 ■ FILES 109 of the requ
- Page 156 and 157: CHAPTER 3 ■ FILES 111 IMPDP, howe
- Page 158 and 159: CHAPTER 3 ■ FILES 113 tkyte@ORA10
- Page 160 and 161: CHAPTER 4 ■ ■ ■ Memory Struct
- Page 162 and 163: CHAPTER 4 ■ MEMORY STRUCTURES 117
- Page 164 and 165: CHAPTER 4 ■ MEMORY STRUCTURES 119
- Page 166 and 167: CHAPTER 4 ■ MEMORY STRUCTURES 121
- Page 168 and 169: CHAPTER 4 ■ MEMORY STRUCTURES 123
- Page 170 and 171: CHAPTER 4 ■ MEMORY STRUCTURES 125
- Page 172 and 173: CHAPTER 4 ■ MEMORY STRUCTURES 127
- Page 174 and 175: CHAPTER 4 ■ MEMORY STRUCTURES 129
- Page 176 and 177: CHAPTER 4 ■ MEMORY STRUCTURES 131
- Page 178 and 179: CHAPTER 4 ■ MEMORY STRUCTURES 133
- Page 180 and 181: CHAPTER 4 ■ MEMORY STRUCTURES 135
88<br />
CHAPTER 3 ■ FILES<br />
SHUTDOWN STARTUP MINS_DOWN DAYS_UP DAYS_STILL_UP<br />
----------------- ----------------- ---------- ---------- -------------<br />
06-may-2004 14:00<br />
06-may-2004 14:24 06-may-2004 14:24 .25 .02<br />
10-may-2004 17:18 10-may-2004 17:19 .93 4.12<br />
26-jun-2004 13:10 26-jun-2004 13:10 .65 46.83<br />
07-sep-2004 20:13 07-sep-2004 20:20 7.27 73.29 116.83<br />
I won’t go into the nuances of the SQL query here, but the innermost query from lines 18<br />
through 21 collect the “Starting” <strong>and</strong> date lines (remember, when using a LIKE clause, _<br />
matches precisely one character—at least one <strong>and</strong> at most one). It also “numbers” the lines<br />
using ROWNUM. Then, the next level of query uses the built-in LAG() analytic function to reach<br />
back one <strong>and</strong> two rows for each row, <strong>and</strong> slide that data up so the third row of this query has<br />
the data from rows 1, 2, <strong>and</strong> 3. Row 4 has the data from rows 2, 3, <strong>and</strong> 4, <strong>and</strong> so on. We end up<br />
keeping just the rows that were like Starting ORACLE instance %, which now have the two<br />
preceding timestamps associated with them. From there, computing downtime is easy: we<br />
just subtract the two dates. Computing the uptime is not much harder (now that you’ve seen<br />
the LAG() function): we just reach back to the prior row, get its startup time, <strong>and</strong> subtract that<br />
from this line’s shutdown time.<br />
My <strong>Oracle</strong> 10g database came into existence on May 6 <strong>and</strong> it has been shut down four<br />
times (<strong>and</strong> as of this writing it has been up for 116.83 days in a row). The average uptime is<br />
getting better <strong>and</strong> better over time (<strong>and</strong> hey, it is SQL—we could easily compute that now,<br />
too).<br />
If you are interested in seeing another example of mining the alert log for useful information,<br />
go to http://asktom.oracle.com/~tkyte/alert_arch.html. This page shows a<br />
demonstration of how to compute the average time it took to archive a given online redo<br />
log file. Once you underst<strong>and</strong> what is in the alert log, generating these queries on your own<br />
becomes easy.<br />
Data Files<br />
Data files, along with redo log files, are the most important set of files in the database. This is<br />
where all of your data will ultimately be stored. Every database has at least one data file associated<br />
with it, <strong>and</strong> typically it will have many more than one. Only the most simple “test”<br />
database will have one file. In fact, in Chapter 2 we saw the most simple CREATE DATABASE<br />
comm<strong>and</strong> by default created a database with two data files: one for the SYSTEM tablespace<br />
(the true <strong>Oracle</strong> data dictionary) <strong>and</strong> one for the SYSAUX tablespace (where other nondictionary<br />
objects are stored in version 10g <strong>and</strong> above). Any real database, however, will have at<br />
least three data files: one for the SYSTEM data, one for SYSAUX data, <strong>and</strong> one for USER data.<br />
After a brief review of file system types, we’ll discuss how <strong>Oracle</strong> organizes these files <strong>and</strong><br />
how data is organized within them. To underst<strong>and</strong> this, you need to know what a tablespace,<br />
segment, extent, <strong>and</strong> block are. These are the units of allocation that <strong>Oracle</strong> uses to hold<br />
objects in the database, <strong>and</strong> I describe them in detail shortly.