Академический Документы
Профессиональный Документы
Культура Документы
The RECOVER command actually has no effect, because it cannot find any
incremental backups with a tag of img_cpy_upd.
However, the BACKUP command will create a new Incremental Level 0 backup that is
labeled with a tag of img_cpy_upd because no backups have been created yet with
this tag.
The RECOVER command still will have no effect, because it cannot find any Level 1
incremental backups with a tag of img_cpy_upd.
The BACKUP command will create its first Incremental Level 1 backup that is labeled
with a tag of img_cpy_upd.
The RECOVER command finds the incremental level 1 image copy backups from the
previous night's run tagged as img_cpy_upd, and applies them to the existing
datafile image copies.
The BACKUP command will create the next Incremental Level 1 backup that is
labeled with a tag of img_cpy_upd.
After the third run of this script, RMAN would then choose the following files during a media
recovery scenario: the image copy of the database for tag img_cpy_upd from the previous
night, the most recent incremental level 1 backup, and all archived redo logs since the
image copy was taken. This strategy offers a potentially quick and flexible recovery, since
the datafile image copies will be relatively quick to restore, and the incremental level 1
backup plus all archived redo logs can be used to perform either a point-in-time or a
complete recovery.
See Listing 1.2 for an example of how this new feature could be implemented for a weekly
backup strategy.
Improved Incremental Backup Performance With Change Tracking. Another new
Oracle 10g optional feature, change tracking, promises to improve the performance of
incremental backup creation significantly. When an incremental backup was being taken
prior to 10g, all the blocks in each datafile being backed up needed to be scanned to
determine if the block had changed since the last incremental backup to determine if it
needed to be included in the new incremental backup.
With the new change tracking feature enabled, however, now only the first Level 0
incremental backup needs to be completely scanned, and the IDs of any changed blocks are
written instead to a change tracking file. All subsequent incremental backups will query the
change tracking file to determine if there are any changed blocks that need to be backed up.
Oracle automatically stores enough incremental backup metadata to insure that any of the
eight most recent incremental backups can be used as the "parent" of a new incremental
backup.
Each Oracle database has only one change tracking file, and if the database has been
configured for Oracle Managed Files (OMF) it will be automatically created based on the
specification for DB_CREATE_FILE_DEST. However, if OMF is not enabled for the
database, the location of the change tracking file can be specified manually. The initial size
of the change tracking file is 10MB, and it grows in 10MB increments, but Oracle notes that
the 10MB initial extent should be sufficient to store change tracking information for any
database up to one terabyte in size.
If the location needs to be moved, change tracking can be disabled, and a new change
tracking file can be created, but this causes the database to lose all change tracking
information. Moreover, unfortunately the change tracking file cannot be moved without
shutting down the database, moving it with the appropriate ALTER DATABASE RENAME FILE
<filename> command, and then restarting the database.
Oracle does recommend that this feature be activated for any database whose disaster
recovery plan utilizes incremental backups of differing levels. Oracle also notes that theirs is
a small performance hit during normal operations, but that hit should be discounted against
the need to avoid scans of datafiles during restoration and recovery operations.
See Listing 1.3 for more extensive RMAN script examples of this new feature
Improved Backup Resource Management. Oracle 9i added new features to help DBAs to
automatically manage backup file retention with the RETENTION POLICY directives of the
CONFIGURE command set. Oracle 10g has improved RMAN resource management even
further with the DURATION directive of the BACKUP command: It is now possible to tell
RMAN exactly how much system resources should be allocated to accomplish a backup task
so that it completes within a specified time frame.
For example, my client's primary production database is scheduled to begin at 00:15 every
day, and needs to complete before batch processing commences at 03:00 every day. In my
daily backup RMAN script, I can specify that the backups must complete in 2.5 hours, and
RMAN will begin backing up the specified database files:
Server Parameter File (SPFILE) AutoBackups. Oracle 9i added the ability to configure
automatic control file backups to occur whenever specific RMAN operations happened, or
when the DBA performed a significant modification of the database's logical or physical
structure that affected the control file (e.g. adding a new tablespace, or renaming a
datafile).
Oracle 10g expands this feature to include the auto-backup of the database's server
parameter file - the binary copy of the initialization parameter file -- as well. Though I have
to admit that I am still a fan of the initialization parameter file - old habits do die hard, dang
it! - it is obvious that Oracle views the SPFILE as the future basis for controlling database
parameter configuration.
Enhanced BEGIN BACKUP. Finally, here is a neat enhancement for user-managed
backups: The BEGIN BACKUP command that is used to take tablespaces offline one at a
time has been enhanced so that all of the database's tablespaces can be taken offline at
once:
-- Take all datafiles offline before starting user-managed backup
ALTER DATABASE BEGIN BACKUP;
-- Bring all datafiles back online after completing user-managed backup
ALTER DATABASE END BACKUP;
Though our shop uses RMAN for all production database backups, this command certainly
has value for smaller but no less mission-critical databases like OEM or RMAN recovery
catalog repositories.
Automatic Channel Failover. For those of you who create RMAN backups directly on tape
via a Media Management Layer (MML), Oracle 10g adds a new feature: If multiple channels
have been allocated for the backup step, but any one channel fails during that step, RMAN
will automatically try to use one of the other available channels to continue processing the
backups. Though I have had limited experience with using MML in conjunction with RMAN,
this feature appears to increase the flexibility and stability of directly backing up to alternate
media.
Restoration and Recovery Enhancements
RESTORE Failover. Oracle 10g has also significantly improved the restoration process
during initial restoration and recovery efforts:
RESTORE ... PREVIEW. If you have ever wondered exactly what backup files or image
copies RMAN will use to perform restoration, Oracle 10g now offers the RESTORE ...
PREVIEW command set to show exactly what backup pieces or image copies RMAN plans to
utilize.
For example, if I wanted to explore exactly what RMAN will choose if I want to restore the
database's SYSTEM tablespace, from within an RMAN session, I can issue the RESTORE
DATAFILE 1 PREVIEW; command and RMAN will return the following output:
See Listing 1.4 for additional examples of this command set.
Automatic Creation of Missing Datafiles. Consider this scenario: Your junior DBA has
just added a new tablespace to the production database, but she neglected to take a full
backup of the database immediately after adding the tablespace. Then, as luck would have
it, a media failure occurs on the same disk where the new tablespace's datafile resides.
Here's the good news: With Oracle 9i, it's definitely possible to recreate the datafile for the
new tablespace - as long as all the archived redo logs and online redo logs that were
generated since the creation of the new tablespace are available, that is. Once the datafile
has been taken offline, the ALTER DATABASE CREATE DATAFILE <datafile name>;
command is issued to recreate the datafile. Then the RECOVER DATAFILE <datafile
name>; command is issued to recover the datafile, and the datafile's tablespace can be
brought back online.
Moreover, here is the better news: Oracle 10g is now smart enough to handle this situation
without DBA intervention. If the database encounters a redo log entry for the creation of
the datafile, it will automatically add the new datafile to the database.
Other Enhancements
Improved Access To RMAN Metadata. Oracle 10g provides some new dynamic views
that offer a DBA the ability to see what's really happening during and after a set of RMAN
tasks have been completed, thus saving the effort of having to constantly monitor a
command window or log file to determine their status.
V$RMAN_OUTPUT will show the status of an ongoing RMAN job. For example, here is
some sample output from the example of the full database image copy backup run:
Results of currently active Recovery Manager sessions
Activity
---------------------------------------------------------------connected to target database: ZDCDB (DBID=1863541959)
using target database controlfile instead of recovery catalog
allocated channel: dbkp1
channel dbkp1: sid=145 devtype=DISK
Starting backup at 20-NOV-04
channel dbkp1: starting datafile copy
input datafile fno=00001 name=C:\ORACLE\ORADATA\ZDCDB\SYSTEM01.DBF
output filename=C:\ORACLE\RMANBKUP\DATA_D-ZDCDB_I-1863541959_TSSYSTEM_FNO-1_2OG5IGDQ tag=TAG20041120T114042 recid=2 stamp=54272
channel dbkp1: datafile copy complete, elapsed time: 00:01:19
channel dbkp1: starting datafile copy
input datafile fno=00013 name=C:\ORACLE\ORADATA\ZDCDB\SYSAUX01.D
BF
... (Some detail removed for brevity) ...
channel dbkp1: datafile copy complete, elapsed time: 00:00:03
Finished backup at 20-NOV-04
released channel: dbkp1
66 rows selected.
In addition, V$RMAN_STATUS lists the historical status of all RMAN jobs. Here is the
resulting output from my (not always successful!) experiments with image backups:
Results of most recent Recovery Manager sessions
Command/
TimeStamp
Session Action Status
-------------------- -------- -------- -----------------------2004-11-20T11:40:33 COMMAND BACKUP COMPLETED
2004-11-20T11:40:33 SESSION RMAN
COMPLETED
2004-11-20T11:39:50 SESSION RMAN
COMPLETED WITH ERRORS
2004-11-20T11:39:50 COMMAND BACKUP FAILED
2004-11-20T11:33:49 COMMAND BACKUP FAILED
2004-11-20T11:33:49 SESSION RMAN
COMPLETED WITH ERRORS
6 rows selected.
See Listing 1.5 for the queries used to create this output.
Improved Recovery Catalog Maintenance. Oracle 10g offers a new catalog maintenance
command, UNREGISTER DATABASE, to remove all information about an Oracle database
from an RMAN repository.
Dropping a Database Completely. If you really must drop an entire database, the new
DROP DATABASE command will remove all of the specified database's physical files,
including control files, datafiles, online redo log members, and server parameter files (if any
exist). Note that the database must be mounted in exclusive, restricted mode for this
command to succeed.
Conclusion
Oracle 10g's new Recovery Manager features greatly expand the flexibility and reliability of
any Oracle DBA's tool kit for disaster recovery planning, backup strategies and failure
recovery scenarios. And I've just scratched the surface! As promised, the next article in this
series will focus on one of the most intriguing new availability features: Flash Backup and
Recovery.
References and Additional Reading
While there is no substitute for direct experience, reading the manual is not a bad idea,
either. I have drawn upon the following Oracle 10g documentation for the deeper technical
details of this article:
B10734-01 Oracle Database Backup and Recovery Advanced User's Guide
B10735-01 Oracle Database Backup and Recovery Basics
B10750-01 Oracle Database New Features Guide
/*
||
||
||
||
||
||
||
||
||
||
||
||
*/
23
6
A 21-NOV-04
2034845
21-NOV-04
C:\ORACLE\RMANBKUP\IC_ZDCDB_109_1_542808898
20
7
A 21-NOV-04
2034836
21-NOV-04
C:\ORACLE\RMANBKUP\IC_ZDCDB_106_1_542808879
18
8
A 21-NOV-04
2034829
21-NOV-04
C:\ORACLE\RMANBKUP\IC_ZDCDB_104_1_542808863
24
9
A 21-NOV-04
2034847
21-NOV-04
C:\ORACLE\RMANBKUP\IC_ZDCDB_110_1_542808902
22
10
A 21-NOV-04
2034843
21-NOV-04
C:\ORACLE\RMANBKUP\IC_ZDCDB_108_1_542808894
26
11
A 21-NOV-04
2034852
21-NOV-04
C:\ORACLE\RMANBKUP\IC_ZDCDB_112_1_542808909
25
12
A 21-NOV-04
2034850
21-NOV-04
C:\ORACLE\RMANBKUP\IC_ZDCDB_111_1_542808906
15
13
A 21-NOV-04
2034791
21-NOV-04
C:\ORACLE\RMANBKUP\IC_ZDCDB_101_1_542808756
Finished restore at 21-NOV-04
------ Listing 1.5: Show RMAN current and historical activity
------ What's the current RMAN session activity?
TTITLE 'Results of currently active Recovery Manager sessions'
COL output
FORMAT A64
HEADING 'Activity'
SELECT
output
FROM v$rman_output
;
-- What are results from prior
TTITLE 'Results of most recent
COL command_id
FORMAT
COL row_type
FORMAT
COL operation
FORMAT
COL status
FORMAT
SELECT
command_id
,row_type
,operation
,status
FROM v$rman_status
ORDER BY command_id DESC
;
exclusively for retention of backup components such as datafile image copies, archived redo
logs, and control file autobackup copies. These features include:
Unified Backup Files Storage. All backup components can be stored in one consolidated
spot. The Flash Recovery Area is managed via Oracle Managed Files (OMF), and it can utilize
disk resources managed by Oracle Automated Storage Management (ASM). In addition, the
Flash Recovery Area can be configured for use by multiple database instances if so desired.
Automated Disk-Based Backup and Recovery. Once the Flash Recovery Area is configured,
all backup components (datafile image copies, archived redo logs, and so on) are managed
automatically by Oracle.
Automatic Deletion of Backup Components. Once backup components have been
successfully created, RMAN can be configured to automatically clean up files that are no
longer needed (thus reducing risk of insufficient disk space for backups).
Disk Cache for Tape Copies. Finally, if your disaster recovery plan involves backing up to
alternate media, the Flash Recovery Area can act as a disk cache area for those backup
components that are eventually copied to tape.
Flashback Logs. The Flash Recovery Area is also used to store and manage flashback logs,
which are used during Flashback Backup operations to quickly restore a database to a prior
desired state.
Sizing the Flash Recovery Area. Oracle recommends that the Flash Recovery Area should
be sized large enough to include all files required for backup and recovery. However, if
insufficient disk space is available, Oracle recommends that it be sized at least large enough
to contain any archived redo logs that have not yet been backed up to alternate media.
Table 1 below shows the minimum and recommended sizes for the Flash Recovery Area
based on the sizes of these database files in my current Oracle 10g evaluation database:
Setting Up the Flash Recovery Area. Activation of the Flash Recovery Area specifying
values for two additional initialization parameters:
Activating the Flash Recovery Area. It is obviously preferable to set up the Flash
Recovery Area when a database is being set up for the first time, as all that needs to be
done is to make the changes to the database's initialization parameters. However, if the
Flash Recovery Area is being set up for an existing database, all that's required to do is
issue the appropriate ALTER SYSTEM commands.
Listing 2.1 shows the changes I have made to the database's initialization parameter file,
including an example of how to insure that an additional copy of the database's archived
redo logs is created in the Flash Recovery area.
Listing 2.2 shows the commands to issue to set up the Flash Recovery Area when the
database is already open before flashback logging has been activated.
Enabling Flashback Database
As its name implies, Flashback Database offers the capability to quickly "flash" a database
back to its prior state as of a specified point in time. Oracle does this by retaining a copy of
any modified database blocks in flashback logs in the Flash Recovery Area. A new flashback
log is written to the Flash Recovery Area on a regular basis (usually hourly, even if nothing
has changed in the database), and these logs are typically smaller in size than an archived
redo log. Flashback logs have a file extension of .FLB.
When a Flashback Database request is received, Oracle then reconstructs the state of the
database just prior to the point in time requested using the contents of the appropriate
flashback logs. Then the database's archived redo logs are used to fill in the remaining gaps
between the last backup of the datafile and the point in time desired for recovery.
The beauty of this approach is that no datafiles need to be restored from backups; further,
only the few changes required to fill in the gaps are automatically applied from archived
redo logs. This means that recovery is much quicker than traditional incomplete recovery
methods, with much higher database availability.
It is worth noting the few prerequisites that must be met before a database may utilize
Flashback Database features:
The database must have flashback logging enabled, and therefore a Flash Recovery
Area must have been configured. (For a RAC environment, the Flash Recovery Area
must also be stored in either ASM or in a clustered file system.)
Since archived redo logs are used to "fill in the gaps" during Flashback Database
recovery, the database must be running in ARCHIVELOG mode.
Activating Flashback Database. Once the Flash Recovery Area has been configured, the next
step is to enable Flashback Database by issuing the ALTER DATABASE FLASHBACK ON;
command while the database is in MOUNT EXCLUSIVE mode, similar to activating a
database in ARCHIVELOG mode.
Setting the Flashback Retention Target. Once Flashback Database has been enabled, the
DB_FLASHBACK_RETENTION_TARGET initialization parameter determines exactly how
far a database can be flashed back. The default value is 1440 minutes (one full day), but
this can be modified to suit the needs of your database. For purposes of illustration, I have
set my demonstration database's setting to 2880 minutes (two full days).
Deactivating Flashback Database. Likewise, issuing the ALTER DATABASE FLASHBACK
OFF; command deactivates Flashback Backup and Recovery. Just as in the activation
process, note that this command must be issued while the database is in MOUNT
EXCLUSIVE mode.
See Listing 2.3 for queries that display the status of the Flash Recovery Area, status of the
related initialization parameters, and whether the database has been successfully configured
for flashback.
Storing Backups In Flash Recovery Area
Now that I have enabled the Flash Recovery Area and enabled flashback logging, I can next
turn my attention to preparing the database to use flashback logs during a Flashback
Database recovery operation.
Listing 2.4 lists the RMAN commands I will need to issue to configure the database for
Flash Recovery Area and Flashback Database use. Notice that I have not CONFIGUREd a
FORMAT directive for the RMAN channels used to create database backups; for these
examples, I am going to let RMAN place all backup components directly in the Flash
Recovery Area.
Listing 2.5 implements Oracle's recommended daily RMAN backup scheme using datafile
image copies and incrementally-updated backups. (See the previous article in this series for
a full discussion of this technique.)
Finally, Listing 2.6 shows the abbreviated results of the first cycle's run of this backup
scheme. Note that Oracle uses OMF naming standards for each backup component file - in
this example, datafiles, the "extra copy" of the archived redo logs, and control file
autobackups - stored in the Flash Recovery Area.
Flashback Database: An Example
Now that I have enabled flashback logging and have created sufficient backup components
that are being managed in the Flash Recovery Area, it is time to demonstrate a Flashback
Database operation.
Let's assume a worst-case scenario: One of my junior developers has been enthusiastically
experimenting with logical units of work on what he thought was his personal development
database, but instead mistakenly applied a transaction against the production database. He
has just accidentally deleted several thousand entries in the SH.SALES and SH.COSTS tables
- just in time to endanger our end-of-quarter sales reporting schedule, of course! Here is
the DML statements issued, along with the number of records removed:
DELETE FROM sh.sales
WHERE prod_id BETWEEN 20 AND 80;
10455 rows deleted
Executed in 89.408 seconds
DELETE FROM sh.costs
WHERE prod_id BETWEEN 20 AND 80;
6728 rows deleted
Executed in 18.086 seconds
COMMIT;
Commit complete
Executed in 0.881 seconds
Flashback Database to the rescue! Since I know the approximate date and time that this
transaction was committed to the database, I will issue an appropriate FLASHBACK
DATABASE command from within an RMAN session to return the database to that
approximate point in time. Here is a more complete listing of the FLASHBACK DATABASE
command set:
FLASHBACK [DEVICE TYPE = <device type>] DATABASE
TO [BEFORE] SCN = <scn>
TO [BEFORE] SEQUENCE = <sequence> [THREAD = <thread id>]
TO [BEFORE] TIME = '<date_string>'
Note that I can return the database to any prior point in time based on a specific System
Change Number (SCN), a specific redo log sequence number (SEQUENCE), or to a specific
date and time (TIME). If I specify the BEFORE directive, I am telling RMAN to flash the
database back to the point in time just prior to the specified SCN, redo log, or time,
whereas if the BEFORE directive is not specified, the database will be flashed back to the
specified SCN, redo log, or time as of that specified point in time, i.e., inclusively.
First, I queried my database's Flashback Logs to determine which ones are available, found
the log just prior to the user error and decided to flash back the database based on that
log's starting SCN. Listing 2.7 contains the query I ran against
V$FLASHBACK_DATABASE_LOGFILE to obtain this information.
Just as I would do during a normal point-in-time incomplete recovery, I then shut down the
database by issuing the SHUTDOWN IMMEDIATE command, and then restarted the
database and brought it into MOUNT mode via the STARTUP MOUNT command. Instead of
having to perform a restoration of datafiles as in a normal incomplete recovery, I instead
simply issue the appropriate FLASHBACK DATABASE command to take the database back to
the SCN I desired.
Once the flashback is completed, I could have continued to roll forward additional changes
from the archived redo logs available; however, I simply chose to open the database at this
point in time via the ALTER DATABASE OPEN RESETLOGS; command. Here are the actual
results from the RMAN session:
C:>rman nocatalog target sys/@zdcdb
Recovery Manager: Release 10.1.0.2.0 - Production
Copyright (c) 1995, 2004, Oracle. All rights reserved.
connected to target database: ZDCDB (DBID=1863541959)
using target database controlfile instead of recovery catalog
RMAN> FLASHBACK DEVICE TYPE = DISK DATABASE TO SCN = 2127725;
Starting flashback at 08-DEC-04
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=158 devtype=DISK
starting media recovery
media recovery complete
Finished flashback at 08-DEC-04
RMAN> alter database open resetlogs;
database opened
To see what is really going on during the flashback and recovery process, I have also
included a portion of the database's alert log. Note that Oracle automatically cleaned up
after itself: Since they are of no use any longer after the RESETLOGS operation, Oracle even
deleted the outmoded Flashback Logs from the Flashback Recovery Area.
Conclusion
Oracle 10g's Flash Recovery Area simplifies the storage and handling of backup components
and flashback logs, and the new Flashback Database features provide any Oracle DBA with a
much improved, faster option for incomplete database recovery. The next article in this
series will delve into the details of using Oracle 10g's expanded Logical Flashback features,
including some intriguing capabilities for recovering from logical errors at a much more
granular level than Flashback Database provides.
References and Additional Reading
While there is no substitute for direct experience, reading the manual is not a bad idea,
either. I have drawn upon the following Oracle 10g documentation for the deeper technical
details of this article:
B10734-01 Oracle Database Backup and Recovery Advanced User's Guide
/*
|| Oracle 10g RMAN Listing 2
||
|| Contains examples of new Oracle 10g FlashBack Recovery Area and
|| Flashback Database features.
||
|| Author: Jim Czuprynski
||
|| Usage Notes:
|| This script is provided to demonstrate various features of Oracle 10g's
|| FlashBack Recovery Area and Flashback Database features and should be
|| carefully proofread before executing it against any existing Oracle
database || to insure that no potential damage can occur.
||
*/
------ Listing 2.1: Setting up the Flash Recovery Area - closed database
------ Entries to add to database's INIT.ORA:
###########################################
# Flashback Backup and Recovery settings
###########################################
db_recovery_file_dest_size = 2G # See article for suggested sizing guidelines
db_recovery_file_dest = 'c:\oracle\fbrdata\zdcdb' # Should be a separate area
of disk
db_flashback_retention_target = 2880 # Will hold two days (2880 minutes) worth
of Flashback
# Activate this to transmit an extra copy of archived redo logs to Flash
Recovery Area
log_archive_dest_2 = 'location=use_db_recovery_file_dest'
log_archive_dest_state_2 = enable
------ Listing 2.2: Setting up the Flash Recovery Area - open database
------ Be sure to set DB_FILE_RECOVERY_DEST_SIZE first ...
ALTER SYSTEM SET db_file_recovery_dest_size = '5G' SCOPE=BOTH SID='*';
-- ... and then set DB_FILE_RECOVERY_DEST and DB_FLASHBACK_RETENTION_TARGET
ALTER SYSTEM SET db_file_recovery_dest = 'c:\oracle\fbrdata\zdcdb' SCOPE=BOTH
SID='*';
ALTER SYSTEM SET db_flashback_retention_target = 2880;
------ Listing 2.3: Flash Recovery status queries
-----
-- What's the earliest point to which this database can be flashed back?
TTITLE 'Flashback Database Limits'
COL oldest_flashback_scn
FORMAT
COL oldest_flashback_time
FORMAT
COL retention_target
FORMAT
COL flashback_size
FORMAT
COL estimated_flashback_size FORMAT
Size'
SELECT
oldest_flashback_scn
,oldest_flashback_time
,retention_target
999999999
A20
999999999
999999999
999999999
HEADING
HEADING
HEADING
HEADING
HEADING
'Oldest|Flashback|SCN #'
'Oldest|Flashback|Time'
'Oldest|Flashback|SCN #'
'Oldest|Flashback|Size'
Estimated|Flashback|
,flashback_size
,estimated_flashback_size
FROM v$flashback_database_log;
------ Listing 2.4: Configuring RMAN to use Flash Recovery Area
----RUN {
# Configure RMAN specifically to use Flash Recovery Area features
CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
}
------ Listing 2.5: RMAN Daily Backup Scheme Using Image Copies
----RUN {
##############################################################################
#
# RMAN Script: DailyImageCopyBackup.rcv
# Creates a daily image copy of all datafiles and Level 1 incremental backups
# for use by the daily image copies
##############################################################################
#
# Roll forward any available changes to image copy files
# from the previous set of incremental Level 1 backups
RECOVER
COPY OF DATABASE
WITH TAG 'img_cpy_upd';
# Create incremental level 1 backup of all datafiles in the database
# for roll-forward application against image copies
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'img_cpy_upd'
DATABASE;
}
------ Listing 2.6: Results of First Daily Backup
----List of Datafile Copies
Key
File S Completion Time Ckp SCN
Ckp Time
Name
------- ---- - --------------- ---------- --------------- ---41
1
A 07-DEC-04
2119100
07-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\DATAFILE\O1_MF_SYSTEM_0VDM2NP9_.DBF
1
1
A 20-NOV-04
2006057
20-NOV-04
C:\RMANBKUP
43
2
A 07-DEC-04
2119143
07-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\DATAFILE\O1_MF_UNDOTBS1_0VDM6MRV_.DBF
48
3
A 07-DEC-04
2119180
07-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\DATAFILE\O1_MF_DRSYS_0VDM9OP2_.DBF
44
4
A 07-DEC-04
2119156
07-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\DATAFILE\O1_MF_EXAMPLE_0VDM7S0X_.DBF
46
5
A 07-DEC-04
2119173
07-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\DATAFILE\O1_MF_INDX_0VDM94ON_.DBF
50
6
A 07-DEC-04
2119186
07-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\DATAFILE\O1_MF_TOOLS_0VDMB270_.DBF
47
7
A 07-DEC-04
2119176
07-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\DATAFILE\O1_MF_USERS_0VDM9F8W_.DBF
45
8
A 07-DEC-04
2119166
07-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\DATAFILE\O1_MF_XDB_0VDM8N66_.DBF
51
9
A 07-DEC-04
2119189
07-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\DATAFILE\O1_MF_LMPT1_0VDMB6CL_.DBF
49
10
A 07-DEC-04
2119184
07-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\DATAFILE\O1_MF_LMPT3_0VDM9Y6J_.DBF
53
11
A 07-DEC-04
2119193
07-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\DATAFILE\O1_MF_LMPT2_0VDMBGJN_.DBF
52
12
A 07-DEC-04
2119191
07-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\DATAFILE\O1_MF_LMPT4_0VDMBBGW_.DBF
42
13
A 07-DEC-04
2119127
07-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\DATAFILE\O1_MF_SYSAUX_0VDM53DD_.DBF
List of Archived Log Copies
Key
Thrd Seq
S Low Time Name
------- ---- ------- - --------- ---148
1
203
A 05-DEC-04
C:\ORACLE\ORADATA\ZDCDB\ARCHIVE\ZDC002030010493846599.ARC
149
1
204
A 06-DEC-04
C:\ORACLE\ORADATA\ZDCDB\ARCHIVE\ZDC002040010493846599.ARC
150
1
205
A 06-DEC-04
C:\ORACLE\ORADATA\ZDCDB\ARCHIVE\ZDC002050010493846599.ARC
151
1
206
A 06-DEC-04
C:\ORACLE\ORADATA\ZDCDB\ARCHIVE\ZDC002060010493846599.ARC
152
1
207
A 06-DEC-04
C:\ORACLE\ORADATA\ZDCDB\ARCHIVE\ZDC002070010493846599.ARC
153
1
208
A 06-DEC-04
C:\ORACLE\ORADATA\ZDCDB\ARCHIVE\ZDC002080010493846599.ARC
154
1
209
A 06-DEC-04
C:\ORACLE\ORADATA\ZDCDB\ARCHIVE\ZDC002090010493846599.ARC
155
1
209
A 06-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\ARCHIVELOG\2004_12_06\O1_MF_1_209_0V9Q1HHJ_.ARC
160
1
210
A 06-DEC-04
C:\ORACLE\ORADATA\ZDCDB\ARCHIVE\ZDC002100010493846599.ARC
161
1
210
A 06-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\ARCHIVELOG\2004_12_08\O1_MF_1_210_0VH53GGG_.ARC
156
1
210
A 06-DEC-04
C:\ORACLE\ORADATA\ZDCDB\ARCHIVE\ZDC002100010493846599.ARC
157
1
210
A 06-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\ARCHIVELOG\2004_12_07\O1_MF_1_210_0VDOMOGQ_.ARC
162
1
211
A 07-DEC-04
C:\ORACLE\ORADATA\ZDCDB\ARCHIVE\ZDC002110010493846599.ARC
163
1
211
A 07-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\ARCHIVELOG\2004_12_08\O1_MF_1_211_0VH53NS2_.ARC
158
1
211
A 07-DEC-04
C:\ORACLE\ORADATA\ZDCDB\ARCHIVE\ZDC002110010493846599.ARC
159
1
211
A 07-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\ARCHIVELOG\2004_12_07\O1_MF_1_211_0VDOPPDT_.ARC
164
1
212
A 07-DEC-04
C:\ORACLE\ORADATA\ZDCDB\ARCHIVE\ZDC002120010493846599.ARC
165
1
212
A 07-DEC-04
C:\ORACLE\FBRDATA\ZDCDB\ZDCDB\ARCHIVELOG\2004_12_08\O1_MF_1_212_0VH53V2V_.ARC
------ Listing 2.7: Flashback Log Query
------ What Flashback Logs are available?
TTITLE 'Current Flashback Logs Available'
COL log#
FORMAT 9999
HEADING
COL bytes
FORMAT 99999999 HEADING
COL first_change#
FORMAT 99999999 HEADING
COL first_time
FORMAT A24
HEADING
SELECT
LOG#
,bytes
,first_change#
,first_time
FROM v$flashback_database_logfile;
'FLB|Log#'
'Flshbck|Log Size'
'Flshbck|SCN #'
'Flashback Start Time'
She could perform an incomplete recovery of the database using the traditional
method of restoring backups of all datafiles and then applying the appropriate
archived redo logs to roll the database forward until the database reached a point in
time just prior to the time that the user error occurred.
Alternatively, if the new Oracle 10g Flashback Database feature had been enabled,
she could use that new method to "flash" the database back to a particular point in
time. (See the prior article in this series for complete details on this method.)
Another option would be to perform a brute-force recovery via manual means,
perhaps using database exports (providing, of course, that the exports were current
enough). However, unless the DBA is intimately aware of the inter-relation of the
affected data, this may not be practical, and could even be more destructive.
Unfortunately, in all these cases, the state of the data that has been added, modified or
deleted after the recovery point in time would most likely also be lost. Moreover, that
probably means that her users are going to spend their weekend re-entering significant
amounts of lost data.
Wouldn't it be great if Oracle provided a way to reverse the effects of a particular DML
statement completely, or (even better!) a dropped table? Here is the good news: Oracle 10g
has significantly improved the existing set of logical FLASHBACK features to handle many of
these not-quite-a-disaster data recovery operations.
Flashback Version Query
Flashback Version Query improves upon the existing Flashback Query feature: It allows a
DBA to see all the different versions of a particular row within a specified time frame, as
long as those versions are still available within the UNDO tablespace's rollback segments.
This time frame can be defined based on either a beginning and an ending timestamp value,
or based on a range of starting and ending System Change Numbers (SCNs).
back. Prior to ORA_ROWSCN, my application would have to check every value of every
column for that row to determine if any value had changed. Alternatively, I add a separate
numeric column that would be incremented whenever a change to a row was committed for
each table that needs this level of transaction control. However, ORA_ROWSCN makes
accurate transaction control almost trivial.
Flashback Transaction Query
Like its cousin Flashback Version Query, Flashback Transaction Query gives me even more
flexibility: It allows me to see all changed rows within a particular set of transactions that
occurred within a range of timestamps or SCNs.
Flashback Transaction Query uses the FLASHBACK_TRANSACTION_QUERY view as a
window into the database's UNDO segments. I can use this view's transaction ID column
(XID) to identify what changes have been recorded during a specific transaction.
Reminiscent of Oracle's LogMiner toolset, Flashback Transaction Query can display the actual
DML statements to issue, to reverse the original transaction.
Listing 3.5 shows how to utilize a Flashback Version Query SELECT statement to drive the
retrieval of all transactions that have occurred during a specific range off SCNs. Here is the
result of that query:
Current FLASHBACK_TRANSACTION_QUERY Contents For Selected Employees
User Table
Commit
XID#
Operation Logon Owner Table Name
SCN
---------------- ---------- ------ ------ ------------ --------UNDO SQL
-------------------------------------------------------------------------------04000C00E7000000 UPDATE
SYS HR
EMPLOYEES
2150749
update "HR"."EMPLOYEES" set "SALARY" = '37500' where ROWID =
'AAAGMsAAEAAAABWAAA';
04000C00E7000000 UPDATE
SYS HR
EMPLOYEES
2150749
update "HR"."EMPLOYEES" set "SALARY" = '32500' where ROWID =
'AAAGMsAAEAAAABYAAE';
04000C00E7000000 UPDATE
SYS HR
EMPLOYEES
2150749
update "HR"."EMPLOYEES" set "SALARY" = '48500' where ROWID =
'AAAGMsAAEAAAABYAAD';
04000C00E7000000 UPDATE
SYS HR
EMPLOYEES
2150749
update "HR"."EMPLOYEES" set "SALARY" = '25000' where ROWID =
'AAAGMsAAEAAAABYAAC';
04000C00E7000000 UPDATE
SYS HR
EMPLOYEES
2150749
update "HR"."EMPLOYEES" set "SALARY" = '5000' where ROWID =
'AAAGMsAAEAAAABYAAB';
04000C00E7000000 BEGIN
SYS
04001500E7000000 INSERT
SYS
2150749
HR
JOB_HISTORY
2150751
SYS
2150751
04001B00E7000000 DELETE
SYS HR
EMPLOYEES
2150753
insert into "HR"."EMPLOYEES"("EMPLOYEE_ID","FIRST_NAME","LAST_NAME","EMAIL",
"PHONE_NUMBER","HIRE_DATE","JOB_ID","SALARY","COMMISSION_PCT","MANAG
ER_ID",
"DEPARTMENT_ID") values ('906','David','Brin','dbrin@astounding.com',
'212-555-1616',TO_DATE('10/31/1987 00:00:00', 'mm/dd/yyyy hh24:mi:ss'),
'WRITER-3','39375',NULL,'901','280');
04001B00E7000000 BEGIN
SYS
2150753
04001E00E7000000 INSERT
SYS HR
EMPLOYEES
2150747
delete from "HR"."EMPLOYEES" where ROWID = 'AAAGMsAAEAAAABWAAA';
04001E00E7000000 BEGIN
SYS
2150747
04002900E7000000 INSERT
SYS HR
EMPLOYEES
2150721
delete from "HR"."EMPLOYEES" where ROWID = 'AAAGMsAAEAAAABYAAE';
04002900E7000000 INSERT
SYS HR
EMPLOYEES
2150721
delete from "HR"."EMPLOYEES" where ROWID = 'AAAGMsAAEAAAABYAAD';
04002900E7000000 INSERT
SYS HR
EMPLOYEES
2150721
delete from "HR"."EMPLOYEES" where ROWID = 'AAAGMsAAEAAAABYAAC';
04002900E7000000 INSERT
SYS HR
EMPLOYEES
2150721
delete from "HR"."EMPLOYEES" where ROWID = 'AAAGMsAAEAAAABYAAB';
04002900E7000000 INSERT
SYS HR
EMPLOYEES
2150721
delete from "HR"."EMPLOYEES" where ROWID = 'AAAGMsAAEAAAABYAAA';
04002900E7000000 BEGIN
SYS
2150721
19 rows selected.
Using SCNs vs. TIMESTAMPs. As you might expect, using an SCN to identify a transaction
or range of row versions is more accurate than using a TIMESTAMP. Oracle recommends
using SCNs over TIMESTAMPs when an extremely accurate Logical Flashback operation
needs to be performed; in fact, the documentation states that a TIMESTAMP can be as much
as three minutes ahead in time than an SCN.
Effect of UNDO_RETENTION Setting. The length of time the row versions are available
obviously depends on the setting of the UNDO_RETENTION initialization parameter. By
default, this setting is 900 seconds (15 minutes); in some cases, I have set
UNDO_RETENTION as high as 10800 (3 hours) for some databases that I knew needed
longer UNDO retention durations. For the sake of these examples, I have set it to 1800 (30
minutes) in my demonstration database, so that I can more easily illustrate these two new
features without recreating examples every 15 minutes.
Rewinding Tables with FLASHBACK TABLE
While Flashback Version Query and Flashback Transaction Query offer the capability to
retrieve the state of a table's rows at a prior point in time, Oracle 10g also offers the ability
to restore an entire table to an earlier state within the boundaries of available UNDO data
via the FLASHBACK TABLE command.
To illustrate this, I will create a new table in the HR demo schema called APPLICANTS that
I will use to record information about each person applying for a job. I will use a row-level
trigger and a sequence to automatically increment the primary key column,
APPLICANTS.APPLICANT_ID, whenever a new entry is added to the table.
Listing 3.6 shows the DDL and DML statements necessary to create and populate this table
initially. Once the new table was populated, I recorded the maximum SCN (2177093) just
before I issued a series of additional INSERT statements shown in Listing 3.7.
I will issue the FLASHBACK TABLE command shown in Listing 3.8 to bring the table back
to its initial state. Note that I set the table's ENABLE ROW MOVEMENT parameter to TRUE
before attempting to "rewind" the table.
Prerequisities. Before I can execute a FLASHBACK TABLE command, there are some
precursors:
The UNDO segments that hold the statements needed to "rewind" the table(s) back
to its prior state must still be available.
The user account from which I am issuing the FLASHBACK TABLE command must
have been granted the FLASHBACK TABLE object privilege for the tables that I wish
to "rewind," or the user account must have been granted the FLASHBACK ANY
TABLE privilege.
Also, the user account that is performing the FLASHBACK TABLE operation must
have been granted SELECT, INSERT, UPDATE, and DELETE rights.
Finally, the table(s) to be "rewound" must have the ENABLE ROW MOVEMENT
directive enabled. This directive allows Oracle to move rows into or out of the
selected table(s).
Caveats. Even though FLASHBACK TABLE offers some slick new capabilities, some warnings
are in order:
issued to restore the table to a different point in time (providing, of course, that
sufficient UNDO is available for the successive operation).
Also, FLASHBACK TABLE cannot be used to recover to a point in time prior to the
issuance of DDL statements that have modified the table's structure.
A new column, DROPPED, has been added to the DBA_TABLES data dictionary
view to allow screening for tables that have been dropped from the database but are
now present in the Recycle Bin instead.
The SHOW RECYCLEBIN; command shows all dropped tables and their dependent
objects when issued from within a SQL*Plus session.
The RECYCLEBIN data dictionary view shows the contents of the Recycle Bin for the
current user.
Finally, the DBA_RECYCLEBIN data dictionary view shows the complete contents of
the Recycle Bin.
Viewing Different Versions of Dropped Tables. Even if a table is created and dropped
several times, all of the different iterations of the dropped table and its dependent objects
are retained in the Recycle Bin until they are purged. Using the dropped table's object
identifier, I can query directly against the dropped table's data in the Recycle Bin, thus
allowing me to determine exactly which version of the table should be recovered. I will
demonstrate this feature in an upcoming recovery example.
Listing 3.9 displays several examples of querying the Recycle Bin for its current status.
Recycle Bin Space Pressure and Automatic Purging. Oracle 10g automatically manages
the contents of the Recycle Bin to insure there is enough space to store any dropped tables
and their related objects. Unfortunately, this also means that there is no way to predict
when Oracle may need to purge objects from the Recycle Bin.
Oracle will keep objects in the Recycle Bin until it can no longer allocate new extents in the
tablespace where the dropped objects originally resided without expanding the tablespace.
This situation is known as space pressure. When space pressure demands that Recycle Bin
space be reclaimed, Oracle will purge the oldest objects first (i.e., first-in, first-out basis),
and it will purge a dropped table's dependent objects first (e.g. indexes, triggers) before it
purges the table itself.
Manually Purging Recycle Bin Objects. Versions of objects that no longer need to be
retained can also be purged manually via the following commands, in order of increasing
destructiveness to the Recycle Bin:
Purging A Single Index. The PURGE INDEX <index name>; command purges
the most recent incarnation of the specified index from the Recycle Bin. Note that the
index cannot have been used to enforce a constraint for its supported table;
otherwise, Oracle will return an error.
Purging A Single Table. Issuing the PURGE TABLE <table name>; purges only
the most recent incarnation of the dropped table and its dependent objects (e.g.
indexes and triggers).
Purging All Schema Objects. The PURGE RECYCLEBIN; command will purge all
schema objects for the current user account from the Recycle Bin.
Purging All Objects. Finally, the PURGE DBA_RECYCLEBIN; command purges all
database objects in the Recycle Bin. Note that this command must be issued from a
user account with DBA privileges.
5
,droptime
6 FROM dba_recyclebin
7 WHERE owner = 'HR'
8 ;
Current Recycle Bin Contents
Object
Object Name
Type
Original Name
Dropped On
------------------------------ -------- -------------------- -------------------BIN$GXKs4x3zS+6aEyHIbjIO0g==$0 INDEX APPLICANTS_LAST_NAME 2005-013:19:04:25
_IDX
BIN$0YQGF9xpTgOPRqsqfuHtNA==$0 INDEX
3:19:03:36
_IDX
APPLICANTS_LAST_NAME 2005-01-
30
SQL> -- Third-most recent iteration of HR.APPLICANTS
SQL> SELECT COUNT(*) FROM "BIN$992SjQhHRlqHZHB4Aa/dWQ==$0";
COUNT(*)
---------16
Oracle retrieves the most recently-dropped table first, so if I issued a FLASHBACK TABLE
hr.applicants TO BEFORE DROP; Oracle would restore the iteration with 45 rows. Since I
want to restore only the iteration with 30 rows, I will issue a FLASHBACK TABLE
<object_identifier> TO BEFORE DROP; command to insure that I have restored the
desired copy of the table:
FLASHBACK TABLE "BIN$ldrmjTN0R8K8qyRRCmSsxw==$0" TO BEFORE DROP;
Alternatively, I can restore a different iteration of the table as with a different object name:
FLASHBACK TABLE "BIN$992SjQhHRlqHZHB4Aa/dWQ==$0"
TO BEFORE DROP
RENAME TO applicants_1;
Conclusion
Oracle 10g's new Logical Flashback features significantly expand an Oracle DBA's abilities to
recover data, transactions and database objects that have been lost with a minimum of
effort. When these new features are used in conjunction with each other and with the
FLASHBACK DATABASE features described in the previous article, just about any data loss
situation can be forestalled. The next article the final one in this series -- will concentrate
on additional availability enhancements implemented as part of DataGuard and Logminer.
References and Additional Reading
While there is no substitute for direct experience, reading the manual is not a bad idea,
either. I have drawn upon the following Oracle 10g documentation for the deeper technical
details of this article:
B10734-01 Oracle Database Backup and Recovery Advanced User's Guide
B10735-01 Oracle Database Backup and Recovery Basics
B10750-01 Oracle Database New Features Guide
B10759-01 Oracle Database SQL Reference
B10770-01 Oracle Database Recovery Manager Reference
/*
||
||
||
||
||
||
||
||
||
||
||
||
*/
)
VALUES (
902,
'Isaac',
'Asimov',
'iasimov@astounding.com',
'212-555-1313',
TO_DATE('01/01/1949', 'MM/DD/YYYY'),
'WRITER-1',
5000,
NULL,
901,
280
);
INSERT INTO hr.employees (
employee_id,
first_name,
last_name,
email,
phone_number,
hire_date,
job_id,
salary,
commission_pct,
manager_id,
department_id
)
VALUES (
903,
'Robert',
'Heinlein',
'bheinlein@astounding.com',
'212-555-1414',
TO_DATE('09/03/1945', 'MM/DD/YYYY'),
'WRITER-2',
25000,
NULL,
901,
280
);
INSERT INTO hr.employees (
employee_id,
first_name,
last_name,
email,
phone_number,
hire_date,
job_id,
salary,
commission_pct,
manager_id,
department_id
)
VALUES (
904,
'Ray',
'Bradbury',
'rbradbury@astounding.com',
'212-555-1515',
TO_DATE('10/31/1946', 'MM/DD/YYYY'),
'WRITER-1',
48500,
NULL,
901,
280
);
INSERT INTO hr.employees (
employee_id,
first_name,
last_name,
email,
phone_number,
hire_date,
job_id,
salary,
commission_pct,
manager_id,
department_id
)
VALUES (
905,
'Harlan',
'Ellison',
'hellison@astounding.com',
'212-555-1515',
TO_DATE('10/31/1962', 'MM/DD/YYYY'),
'WRITER-3',
32500,
NULL,
901,
280
);
COMMIT;
------ Listing 3.3: Sample transactions:
-- 1.) Add a new employee
-- 2.) Update salaries and department IDs for selected employees
-- 3.) Delete the newly-added employee
----INSERT INTO hr.employees (
employee_id,
first_name,
last_name,
email,
phone_number,
hire_date,
job_id,
salary,
commission_pct,
manager_id,
department_id
)
VALUES (
906,
'David',
'Brin',
'dbrin@astounding.com',
'212-555-1616',
TO_DATE('10/31/1987', 'MM/DD/YYYY'),
'WRITER-3',
37500,
NULL,
901,
280
);
COMMIT;
UPDATE hr.employees
SET salary = salary * 1.05
WHERE employee_id >= 902;
COMMIT;
UPDATE hr.employees
SET department_id = 270
WHERE employee_id = 905;
COMMIT;
DELETE FROM hr.employees
WHERE employee_id = 906;
COMMIT;
------ Listing 3.4: Flashback Version Example
------ Using the new ORA_ROWSCN pseudocolumn
SELECT
ORA_ROWSCN,
employee_id,
first_name,
last_name
FROM hr.employees;
-- Show all changes to selected rows regardless of versions available.
-- Note the use of MINVALUE AND MAXVALUE for the timestamp range so that
-- all possible versions are shown
-- What are results from prior RMAN commands and sessions?
SET LINESIZE 120
TTITLE 'Current FLASHBACK VERSION Results For Selected Employees'
COL
COL
COL
COL
COL
COL
COL
versions_xid
versions_startscn
versions_endscn
versions_operation
last_name
department_id
salary
FORMAT
FORMAT
FORMAT
FORMAT
FORMAT
FORMAT
FORMAT
A16
99999999
99999999
A12
A12
9999
999999.99
HEADING
HEADING
HEADING
HEADING
HEADING
HEADING
HEADING
'XID'
'Vsn|Start|SCN'
'Vsn|End|SCN'
'Operation'
'Last Name'
'Dept'
'Salary'
SELECT
versions_xid,
versions_startscn,
versions_endscn,
DECODE(
versions_operation,
'I', 'Insert',
'U', 'Update',
'D', 'Delete', 'Original') "Operation",
last_name,
department_id,
salary
FROM hr.employees
VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE
WHERE employee_id >= 901
hr.seq_applicants.NEXTVAL
INTO entry_id
FROM DUAL;
:new.applicant_id := entry_id;
:new.added_on := SYSDATE;
:new.added_by := DBMS_STANDARD.LOGIN_USER;
:new.changed_on := SYSDATE;
:new.changed_by := DBMS_STANDARD.LOGIN_USER;
END;
ELSIF UPDATING THEN
BEGIN
:new.changed_on := SYSDATE;
:new.changed_by := DBMS_STANDARD.LOGIN_USER;
END;
END IF;
END TR_BRIU_APPLICANTS;
/
-- Create a first set of applicants
insert into HR.APPLICANTS (LAST_NAME, FIRST_NAME, APPLICATION_DATE,
JOB_DESIRED, SALARY_DESIRED)
values ('Aniston', 'Seth', to_date('01-01-2005 12:00:00', 'dd-mm-yyyy
hh24:mi:ss'), 'IT_CNTR2', 88017.94);
insert into HR.APPLICANTS (LAST_NAME, FIRST_NAME, APPLICATION_DATE,
JOB_DESIRED, SALARY_DESIRED)
values ('Niven', 'Ray', to_date('01-01-2005 12:00:00', 'dd-mm-yyyy
hh24:mi:ss'), 'IT_CNTR1', 82553.39);
insert into HR.APPLICANTS (LAST_NAME, FIRST_NAME, APPLICATION_DATE,
JOB_DESIRED, SALARY_DESIRED)
values ('Brown', 'Jackson', to_date('01-01-2005 12:00:00', 'dd-mm-yyyy
hh24:mi:ss'), 'IT_CNTR2', 70113.04);
insert into HR.APPLICANTS (LAST_NAME, FIRST_NAME, APPLICATION_DATE,
JOB_DESIRED, SALARY_DESIRED)
values ('Murdock', 'Charlton', to_date('01-01-2005 12:00:00', 'dd-mm-yyyy
hh24:mi:ss'), 'IT_CNTR2', 70389.16);
insert into HR.APPLICANTS (LAST_NAME, FIRST_NAME, APPLICATION_DATE,
JOB_DESIRED, SALARY_DESIRED)
values ('Bedelia', 'Colin', to_date('01-01-2005 12:00:00', 'dd-mm-yyyy
hh24:mi:ss'), 'IT_CNTR3', 38720.86);
insert into HR.APPLICANTS (LAST_NAME, FIRST_NAME, APPLICATION_DATE,
JOB_DESIRED, SALARY_DESIRED)
values ('Chandler', 'Gino', to_date('01-01-2005 12:00:00', 'dd-mm-yyyy
hh24:mi:ss'), 'IT_CNTR1', 55511.77);
insert into HR.APPLICANTS (LAST_NAME, FIRST_NAME, APPLICATION_DATE,
JOB_DESIRED, SALARY_DESIRED)
HEADING
HEADING
HEADING
HEADING
HEADING
'Object Name'
'Object|Type'
'Original Name'
'Dropped On'
'Drop|SCN'
-- Query directly from a table in the Recycle Bin using its object identifier
SELECT *
FROM "BIN$0M5fd0JLT2Gops3S5EDkNw==$0";
------ Listing 3.10: Recycle Bin Housekeeping (in order of destructiveness)
-----
-- Purge an index from the Recycle Bin. Note that any index that's enforcing
-- a constraint can't be purged via this method
PURGE INDEX hr.applicant_last_name_idx;
-- Purge a table and its dependent objects from the Recycle Bin
PURGE TABLE hr.applicants;
-- Purge all dropped tables and their dependent objects for a specific
-- tablespace from the Recycle Bin
PURGE TABLESPACE example;
-- Purge all objects from the Recycle Bin for the current user account
PURGE RECYCLEBIN;
-- Purge all objects from the Recycle Bin for the entire database
PURGE DBA_RECYCLEBIN;
------ Listing 3.11: Create a third set of applicants
----insert into HR.APPLICANTS (LAST_NAME, FIRST_NAME, APPLICATION_DATE,
JOB_DESIRED, SALARY_DESIRED)
values ('Conners', 'Jose', to_date('01-01-2005 12:00:00', 'dd-mm-yyyy
hh24:mi:ss'), 'IT_CNTR2', 49579.74);
insert into HR.APPLICANTS (LAST_NAME, FIRST_NAME, APPLICATION_DATE,
JOB_DESIRED, SALARY_DESIRED)
values ('McFerrin', 'Jonatha', to_date('01-01-2005 12:00:00', 'dd-mm-yyyy
hh24:mi:ss'), 'IT_CNTR1', 87397.11);
insert into HR.APPLICANTS (LAST_NAME, FIRST_NAME, APPLICATION_DATE,
JOB_DESIRED, SALARY_DESIRED)
values ('Webb', 'Night', to_date('01-01-2005 12:00:00', 'dd-mm-yyyy
hh24:mi:ss'), 'IT_CNTR2', 85049.10);
insert into HR.APPLICANTS (LAST_NAME, FIRST_NAME, APPLICATION_DATE,
JOB_DESIRED, SALARY_DESIRED)
values ('Dzundza', 'Tramaine', to_date('01-01-2005 12:00:00', 'dd-mm-yyyy
hh24:mi:ss'), 'IT_CNTR1', 35239.10);
insert into HR.APPLICANTS (LAST_NAME, FIRST_NAME, APPLICATION_DATE,
JOB_DESIRED, SALARY_DESIRED)
values ('McCormack', 'Ethan', to_date('01-01-2005 12:00:00', 'dd-mm-yyyy
hh24:mi:ss'), 'IT_CNTR1', 49729.40);
insert into HR.APPLICANTS (LAST_NAME, FIRST_NAME, APPLICATION_DATE,
JOB_DESIRED, SALARY_DESIRED)
values ('Withers', 'Andie', to_date('01-01-2005 12:00:00', 'dd-mm-yyyy
hh24:mi:ss'), 'IT_CNTR2', 50804.93);
insert into HR.APPLICANTS (LAST_NAME, FIRST_NAME, APPLICATION_DATE,
JOB_DESIRED, SALARY_DESIRED)
values ('Goodman', 'Sonny', to_date('01-01-2005 12:00:00', 'dd-mm-yyyy
hh24:mi:ss'), 'IT_CNTR2', 97469.88);