Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
CHAPTER 3 ■ FILES 107 Flashback Log Files Flashback log files (or simply flashback logs) were introduced in Oracle 10g in support of the FLASHBACK DATABASE command, a new feature of the Enterprise Edition of the database. Flashback logs contain “before images” of modified database blocks that can be used to return the database to the way it was at some prior point in time. Flashback Database The FLASHBACK DATABASE command was introduced to speed up the otherwise slow process of a point in time database recovery. It can be used in place of a full database restore and a rolling forward using archive logs, and it is primarily designed to speed up the recovery from an “accident.” For example, let’s take a look at what a DBA might do to recover from an “accidentally” dropped schema, in which the right schema was dropped, just in the wrong database (it was meant to be dropped in the test environment). The DBA recognizes immediately the mistake he has made and immediately shuts down the database. Now what? Prior to the flashback database capability, what would probably happen is this: 1. The DBA would shut down the database. 2. The DBA would restore the last full backup of database from tape (typically). This is generally a long process. 3. The DBA would restore all archive redo logs generated since the backup that were not available on the system. 4. The DBA would roll the database forward and stop rolling forward at a point in time just before the erroneous DROP USER command. 5. The database would be opened with the RESETLOGS option. This was a nontrivial process with many steps and would generally consume a large piece of time (time where no one would be accessing the database, of course). The causes of a point in time recovery like this are many: an upgrade script gone awry, an upgrade gone bad, an inadvertent command issued by someone with the privilege to issue it (a mistake, probably the most frequent cause), or some process introducing data integrity issues into a large database (again, an accident; maybe it was run twice instead of just once, or maybe it had a bug). Whatever the reason, the net effect was a large period of downtime. The steps to recover in Oracle 10g Enterprise Edition, assuming you configured the flashback database capability, would be as follows: 1. The DBA shuts down the database. 2. The DBA startup-mounts the database and issues the flashback database command, using either an SCN, the Oracle internal clock, or a timestamp (wall clock time), which would be accurate to within a couple of seconds. 3. The DBA opens the database with resetlogs.
108 CHAPTER 3 ■ FILES To use this feature, the database must be in ARCHIVELOG mode and must have been set up to enable the FLASHBACK DATABASE command. What I’m trying to say is that you need to have set up this capability prior to having a need to use it. It is not something you can enable after the damage is done; you must make a conscious decision to use it. Flash Recovery Area The Flash Recovery Area is a new concept in Oracle 10g. For the first time in many years (over 25 years), the basic concept behind database backups has changed in Oracle. In the past, the design of backup and recovery in the database was built around the concept of a sequential medium, such as a tape device. That is, random access devices (disk drives) were always considered too expensive to waste for mere backups. You used relatively inexpensive tape devices with large storage capacities. Today, however, you can buy terabytes of disk storage at a very low cost. In fact, by 2007, HP intends to ship desktop computers with terabyte disk drives. I remember my first hard drive on my personal computer: a whopping 40MB. I actually had to partition it into two logical disks because the OS I was using (MS-DOS at the time) could not recognize a disk larger than 32MB. Things have certainly changed in the last 20 years. The Flash Recovery Area in Oracle 10g is a new location where Oracle will manage many of the files related to database backup and recovery. In this area (an area being a set-aside area of disk for this purpose; a directory, for example), you could find • Copies of data files on disk • Incremental backups of your database • Redo logs (archived redo logs) • Control files and backups of control files • Flashback logs This new area is used to allow Oracle to manage these files, for the server to have knowledge of what is on disk and what is not on disk (and perhaps on tape elsewhere). Using this information, the database can perform operations like a disk-to-disk restore of a damaged data file or the flashing back (a “rewind” operation) of the database to undo an operation that should not have taken place. For example, you could use the flashback database command to put the database back the way it was five minutes ago (without doing a full restore of the database and a point in time recovery). That would allow you to “undrop” that accidentally dropped user account. The Flash Recovery Area is more of a “logical” concept. It is a holding area for the file types discussed in this chapter. Its use is optional—you do not need to use it—but if you want to use some advanced features such as the Flashback Database, you must use this area to store the information. DMP Files (EXP/IMP Files) Export and Import are venerable Oracle data extraction and load tools that have been around for many versions. Export’s job is to create a platform-independent DMP file that contains all
- 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 132 and 133: CHAPTER 3 ■ FILES 87 6 ( 7 TYPE O
- 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 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
- Page 182 and 183: CHAPTER 4 ■ MEMORY STRUCTURES 137
- Page 184 and 185: CHAPTER 4 ■ MEMORY STRUCTURES 139
- Page 186 and 187: CHAPTER 4 ■ MEMORY STRUCTURES 141
- Page 188 and 189: CHAPTER 4 ■ MEMORY STRUCTURES 143
- Page 190 and 191: CHAPTER 4 ■ MEMORY STRUCTURES 145
- Page 192 and 193: CHAPTER 4 ■ MEMORY STRUCTURES 147
- Page 194 and 195: CHAPTER 4 ■ MEMORY STRUCTURES 149
- Page 196 and 197: CHAPTER 4 ■ MEMORY STRUCTURES 151
- Page 198 and 199: CHAPTER 4 ■ MEMORY STRUCTURES 153
- Page 200 and 201: CHAPTER 5 ■ ■ ■ Oracle Proces
108<br />
CHAPTER 3 ■ FILES<br />
To use this feature, the database must be in ARCHIVELOG mode <strong>and</strong> must have been set up<br />
to enable the FLASHBACK DATABASE comm<strong>and</strong>. What I’m trying to say is that you need to have<br />
set up this capability prior to having a need to use it. It is not something you can enable after<br />
the damage is done; you must make a conscious decision to use it.<br />
Flash Recovery Area<br />
The Flash Recovery Area is a new concept in <strong>Oracle</strong> 10g. For the first time in many years (over<br />
25 years), the basic concept behind database backups has changed in <strong>Oracle</strong>. In the past, the<br />
design of backup <strong>and</strong> recovery in the database was built around the concept of a sequential<br />
medium, such as a tape device. That is, r<strong>and</strong>om access devices (disk drives) were always considered<br />
too expensive to waste for mere backups. You used relatively inexpensive tape devices<br />
with large storage capacities.<br />
Today, however, you can buy terabytes of disk storage at a very low cost. In fact, by 2007,<br />
HP intends to ship desktop computers with terabyte disk drives. I remember my first hard drive<br />
on my personal computer: a whopping 40MB. I actually had to partition it into two logical<br />
disks because the OS I was using (MS-DOS at the time) could not recognize a disk larger than<br />
32MB. Things have certainly changed in the last 20 years.<br />
The Flash Recovery Area in <strong>Oracle</strong> 10g is a new location where <strong>Oracle</strong> will manage many<br />
of the files related to database backup <strong>and</strong> recovery. In this area (an area being a set-aside area<br />
of disk for this purpose; a directory, for example), you could find<br />
• Copies of data files on disk<br />
• Incremental backups of your database<br />
• Redo logs (archived redo logs)<br />
• Control files <strong>and</strong> backups of control files<br />
• Flashback logs<br />
This new area is used to allow <strong>Oracle</strong> to manage these files, for the server to have knowledge<br />
of what is on disk <strong>and</strong> what is not on disk (<strong>and</strong> perhaps on tape elsewhere). Using this<br />
information, the database can perform operations like a disk-to-disk restore of a damaged<br />
data file or the flashing back (a “rewind” operation) of the database to undo an operation that<br />
should not have taken place. For example, you could use the flashback database comm<strong>and</strong><br />
to put the database back the way it was five minutes ago (without doing a full restore of the<br />
database <strong>and</strong> a point in time recovery). That would allow you to “undrop” that accidentally<br />
dropped user account.<br />
The Flash Recovery Area is more of a “logical” concept. It is a holding area for the file<br />
types discussed in this chapter. Its use is optional—you do not need to use it—but if you want<br />
to use some advanced features such as the Flashback <strong>Database</strong>, you must use this area to store<br />
the information.<br />
DMP Files (EXP/IMP Files)<br />
Export <strong>and</strong> Import are venerable <strong>Oracle</strong> data extraction <strong>and</strong> load tools that have been around<br />
for many versions. Export’s job is to create a platform-independent DMP file that contains all