RelationalDBDesign RelationalDBDesign


Backup Recovery   «Prev 

DBMS LogMiner Logfile

LogMiner
DBMS LogMiner Logfile

Location 1 This sub-program starts the process of reading the archive log files by opening it.
Location 2 Name of the log file that must be added to the list of log files to be analyzed within a session.
Location 3 The following options are valid: a) Purges the existing list of log files and starts a new list (DBMS_LOGMNR.NEW), b) Adds a file to an existing list (DBMS_LOGMNR.ADDFILE), and c) Removes the log file from the list of log files to be analyzed (DBMS_LOGMNR.REMOVEFILE)
Location 4 This sub-program starts the process of reading the archive log files by opening it.
Location 5 starts the process of reading log files.
Location 6 ends the session of LogMiner.
Location 7 This sub-program starts the process of reading the archive log files by opening it.
Location 8 starts the process of reading log files.
Location 9 ends the session of LogMiner.
Location 10 starts the process of reading log files.
Location 11 ends the session of LogMiner.

Oracle LogMiner

Oracle LogMiner, which is part of Oracle Database, enables you to query online and archived redo log files through a SQL interface. Redo log files contain information about the history of activity on a database.

LogMiner Benefits

All changes made to user data or to the database dictionary are recorded in the Oracle redo log files so that database recovery operations can be performed. Because LogMiner provides a well-defined, easy-to-use, and comprehensive relational interface to redo log files, it can be used as a powerful data auditing tool, and also as a sophisticated data analysis tool. The following list describes some key capabilities of LogMiner:
  1. Pinpointing when a logical corruption to a database, such as errors made at the application level, may have begun. These might include errors such as those where the wrong rows were deleted because of incorrect values in a WHERE clause, rows were updated with incorrect values, the wrong index was dropped, and so forth. For example, a user application could mistakenly update a database to give all employees 100 percent salary increases rather than 10 percent increases, or a database administrator (DBA) could accidently delete a critical system table. It is important to know exactly when an error was made so that you know when to initiate time-based or change-based recovery. This enables you to restore the database to the state it was in just before corruption.
  2. Determining what actions you would have to take to perform fine-grained recovery at the transaction level. If you fully understand and take into account existing dependencies, then it may be possible to perform a table-specific undo operation to return the table to its original state. This is achieved by applying tablespecific reconstructed SQL statements that LogMiner provides in the reverse order from which they were originally issued. Normally you would have to restore the table to its previous state, and then apply an archived redo log file to roll it forward.
  3. Performance tuning and capacity planning through trend analysis. You can determine which tables get the most updates and inserts. That information provides a historical perspective on disk access statistics, which can be used for tuning purposes.
  4. Performing postauditing. LogMiner can be used to track any data manipulation language (DML) and data definition language (DDL) statements executed on the database, the order in which they were executed, and who executed them. (However, to use LogMiner for such a purpose, you need to have an idea when the event occurred so that you can specify the appropriate logs for analysis; otherwise you might have to mine a large number of redo log files, which can take a long time. Consider using LogMiner as a complementary activity to auditing database use. See the Oracle Database Administrator's Guide for information about database auditing.)