• About Me

    Maxwell Miranda
    Oracle DBA Consultant.
  • Category

  • Archives

  • My Blog Calendar

    February 2018
    M T W T F S S
    « Sep    
  • RSS Oracle Feeds

    • Can't access database after power outage
      I could access the database before the power outage. From what I've read, it is a problem with the environment variables, but they are correct. Not sure what else to add. C:\Documents and Settings\konoca>sqlplus / as sysdba SQL*Plus: Release - Production on Wed Feb 21 09:17:08 2018 Copyright (c) 1982, 2005, Oracle. All rights reserved. ERR […]
    • Problems with RESET DATABASE
      Recently I wanted to do RESET DATABASE. Oracle documentation suggests the following commands connect target / startup force nomount reset database to incarnation 2 run { set until time "date time" restore controlfile from autobackup alter database mount restore database recover database } alter database open resetlogs In this view my db has given e […]
  • Advertisements

Redo Log

Each Oracle database has a redo log. This redo log records all changes made in datafiles.
The redo log makes it possible to replay SQL statements.Before Oracle changes data in a datafile it writes these changes to the redo log. If something happens to one of the datafiles, a backed up datafile can be restored and the redo, that was written since, replied, which brings the datafile to the state it had before it became unavailable.
The same technique is also used in a data guard environment (standby databases): One database (the primary database) records all changes and sends them to the standby databases. These standby databases in turn apply (reply) the arrived redo which keeps the synchronized with the primary database.

Archive Log vs Noarchive Log
As Oracle rotates through its redo log groups, it will eventually overwrite a group which it has already written to. Data that is being overwriten would of course be useless for a recovery scenario. In order to prevent that, a database can (and for production databases should) be run in archive log mode. Simply stated, in archive log mode, Oracle makes sure that online redo log files are not overwritten unless they have been savely archived somewhere.
A database can only be recoverd from media failure if it runs under archive log.

LGWR writes the redo log buffers to disk.
The background process in charge for archiving redo logs is ARCn (if automatic archiving is enabled.)
In order to find out in which mode the instance runs, one can use archive log list from within sql plus.
Log Buffer
All changes that are covered by redo is first written into the log buffer. The idea to first store it in the memory is to reduce disk IO. Of course, when a transaction commits, the redo log buffer must be flushed to disk, because otherwise the recovery for that commit could not be guaranteed. It is LGWR (Log Writer) that does that flushing.

Determining amount of generated redo log

n.name, t.value
v$mystat t join
v$statname n
t.statistic# = n.statistic#
n.name = ‘redo size’;

RBA (Redo Byte Address)
The RBA consists of three parts and is ten bytes long:

* Log sequence number
* Block number within this sequence
* Offset within this block

The location of each redo log entry is identified throuhg an RBA. The RBAs are important for dirty db blocks in the buffer cache.

Log sequence number
Whenever Oracle (or more precisely, the log writer process) writes to another online redo log file group (also referred to as log switch), the log sequence number increments by one.
If the database is opened with reset logs, the log sequence number is reset to 1.

Determining optimal redo log size
The optimal size of redo log files can be queried with

select optimal_logfile_size from v$instance_recovery;

Minimizing generation of redo
For a few operations, it is possible to minimize the generation of redo if the nologging option is set.