Fractured block in Oracle

A block in which the header and footer are not consistent at a given SCN. In a user-managed backup, an operating system utility can back up a datafile at the same time that DBWR is updating the file. It is possible for the operating system utility to read a block in a half-updated state, so that the block that is copied to the backup media is updated in its first half, while the second half contains older data. In this case, the block is fractured.

For non-RMAN backups, the ALTER TABLESPACE ... BEGIN BACKUP or ALTER DATABASE BEGIN BACKUP command is the solution for the fractured block problem. When a tablespace is in backup mode, and a change is made to a data block, the database logs a copy of the entire block image before the change so that the database can reconstruct this block if media recovery finds that this block was fractured.

Most Important New Features to Oracle Data Guard in 11g Release 1(11.1)

July 23, 2009
Oracle, Dataguard, New Features
(1.) Compression of redo traffic over the network in a Data Guard configuration
  This feature improves redo transport performance when resolving redo gaps by compressing redo before it is transmitted over the network.
(2.) Simplified Data Guard management interface
  The SQL statements and initialization parameters used to manage a Data Guard configuration have been simplified through the deprecation of redundant SQL clauses and initialization parameters.
(3.) Enhancements around DB_UNIQUE_NAME
  You can now find the DB_UNIQUE_NAME of the primary database from the standby database by querying the new  PRIMARY_DB_UNIQUE_NAME column in the V$DATABASE view. Also, Oracle Data Guard release 11g ensures each database's DB_UNIQUE_NAME is different. After upgrading to 11g, any databases with the same DB_UNIQUE_NAME will not be able to communicate with each other.
(4.) Use of physical standby database for rolling upgrades
  A physical standby database can now take advantage of the rolling upgrade feature provided by a logical standby. Through the use of the new KEEP IDENTITY clause option to the SQL ALTER DATABASE RECOVER TO LOGICAL STANDBY statement, a physical standby database can be temporarily converted into a logical standby database for the rolling upgrade, and then reverted back to the original configuration of a primary database and a physical standby database when the upgrade is done.
(5.) Heterogeneous Data Guard Configuration
  This feature allows a mix of Linux and Windows primary and standby databases in the same Data Guard configuration.
(6.) The ARCH redo transport mode has been deprecated
(7.) Real-time query capability of physical standby
  This feature makes it possible to query a physical standby database while Redo Apply is active.
(8) Snapshot standby
  A snapshot standby database is new type of updatable standby database that provides full data protection for a primary database.

Standby Online Redo Log

July 23, 2009
Oracle, Standby, Redo Log
  The synchronous and asynchronous redo transport modes require that a redo transport destination have a standby redo log. A standby redo log is used to store redo received from another Oracle database. Standby redo logs are structurally identical to redo logs, and are created and managed using the same SQL statements used to create and manage redo logs.
  Redo received from another Oracle database via redo transport is written to the current standby redo log group by a RFS background process. When a log switch occurs on the redo source database, incoming redo is then written to the next standby redo log group, and the previously used standby redo log group is archived by an ARCn background process.

How to define vi Editor as the default plain text editor for SQL*Plus ?

July 22, 2009
Key Word: Oracle, SQL*Plus, vi, Editor, glogin.sql 
  There is a glogin.sql in the $ORACLE_HOME/sqlplus/admin directory. You can define vi as the default text editor for SQL*Plus by adding the following line into it:
  DEFINE_EDITOR=vi
  Save the modified glogin.sql, then reconnect to Oracle with SQL*Plus.
  SQL>select * from dual;
  SQL>ed

  Does it work?
 
 

ORACLE DATABASE FORCE LOGGING

 July 20,2009
 KeyWord: ORACLE DATABASE, FORCE LOGGING
 [NO] FORCE LOGGING
 Use this clause to put the database into or take the database out of FORCE LOGGING mode. The database must be mounted or open.
 In FORCE LOGGING mode, Oracle Database logs all changes in the database except changes in temporary tablespaces and temporary segments. This setting takes precedence over and is independent of any NOLOGGING or FORCE LOGGING settings you specify for individual tablespaces and any NOLOGGING settings you specify for individual database objects.
 If you specify FORCE LOGGING, Oracle Database waits for all ongoing unlogged operations to finish.
 ALTER DATABASE FORCE LOGGING;
 ALTER DATABASE NO FORCE LOGGING;
 SELECT FORCE_LOGGING FROM V$DATABASE;
 

ALTER DATABASE OPEN RESETLOGS|NORESETLOGS

July 20, 2009
KeyWord: ORACLE DATABASE, RESETLOGS, NORESETLOGS
  RESETLOGS | NORESETLOGS This clause determines whether Oracle Database resets the current log sequence number to 1, archives any unarchived logs (including the current log), and discards any redo information that was not applied during
recovery, ensuring that it will never be applied.
  Oracle Database uses NORESETLOGS automatically except in the following specific situations, which require a setting for this clause:
  1. You must specify RESETLOGS:
   – After performing incomplete media recovery or media recovery using a backup controlfile
   – After a previous OPEN RESETLOGS operation that did not complete
   – After a FLASHBACK DATABASE operation
  2. If a created controlfile is mounted, then you must specify RESETLOGS if the online logs are lost, or you must   specify NORESETLOGS if they are not lost.
 

Behavior of Oracle Database in case Media Failure on datafile

Key Word: Oracle, Media Failure, SYSTEM Tablespace
  If the instance cannot write to a datafile in the SYSTEM tablespace, an undo tablespace (if the database is in automatic undo management mode, which is the preferred choice in Release 10g), or a datafile in a tablespace containing active rollback segments (if in manual undo management mode), then the database issues an error and shuts down the instance. All files in the SYSTEM tablespace and all datafiles containing rollback segments must be online in order for the database to operate properly.
  If an instance cannot write to a datafile other than those in the preceding list, then the result depends on whether the database is running in ARCHIVELOG mode or not.
  In ARCHIVELOG mode, the database records an error in the database writer trace file and takes the affected datafile offline. (All other datafiles in the tablespace containing this datafile remain online.) You can then rectify the underlying problem and restore and recover the affected tablespace.
  In NOARCHIVELOG mode, the database writer background process DBWR fails, and the instance fails, the cause of the problem determines the required response. If the problem is temporary (for example, a disk controller was powered off), then crash recovery usually can be performed using the online redo log files. In such situations, the instance can be restarted without resorting to media recovery. However, if a datafile is damaged, then you must restore a consistent backup of the entire database.

Oracle Backup and Recovery Solutions

Oracle,RMAN,Backup,Recovery

For performing backup and recovery based on physical backups, you have two solutions available:
(1.) Recovery Manager, a tool (with command-line client and Enterprise Manager GUI interfaces) that integrates with sessions running on the Oracle server to perform a
range of backup and recovery activities, as well as maintaining a repository of historical data about your backups
(2.) The traditional user-managed backup and recovery, where you directly manage the files that make up your database with a mixture of host operating system commands and SQL*Plus backup and recovery-related capabilities Both methods are supported by Oracle Corporation and are fully documented.
   RMAN is, however, the preferred solution for database backup and recovery. It can perform the same types of backup and recovery available through user-managed methods more easily, provides a common interface for backup tasks across different host operating systems, and offers a number of backup techniques not available through user-managed methods.
  Most of the backup and recovery documentation set will focus on RMAN-based backup and recovery. User-managed backup and recovery techniques are covered in the later chapters of Oracle Database Backup and Recovery Advanced User's Guide.
Whether you use RMAN or user-managed methods, you can supplement your physical backups with logical backups of schema objects made using data export utilities. Data thus saved can later be imported to re-create this data after restore and
recovery. However, logical backups are for the most part beyond the scope of the backup and recovery documentation.

Complete, Incomplete and Point-In-Time Recovery

Complete, Incomplete and Point-In-Time Recovery
July 15, 2009
Oracle Database, Backup, Recovery, TSPITR
  Complete recovery is recovering a database to the most recent point in time, without the loss of any committed transactions. Generally, the term "recovery" refers to complete recovery.
  Occasionally, however, you need to return a database to its state at a past point in time. For example, to undo the effect of a user error, such as dropping(RecycleBin)(Flash Database)(TSPITR) or deleting the contents of a table(Flash Table/LogMiner/Flash Transaction), you may want to return the database to its contents before the delete occurred. In incomplete recovery, also known as point-in-time recovery, the goal is to restore the database to its state at some previous target SCN or time.
  Point-in-time recovery is one possible response to a data loss caused by, for instance, a user error or logical corruption that goes unnoticed for some time. Point-in-time recovery is also your only option if you have to perform a recovery and discover that you are missing an archived log covering time between the backup you are restoring from and the target SCN for the recovery. Without the missing log, you have no record of the updates to your datafiles during that period. Your only choice is to recover the database from the point in time of the restored backup, as far as the unbroken series of archived logs permits, then perform an OPEN RESETLOGS and abandon all changes in or after the missing log. (If you discover that you have lost archived logs and your database is still up, you should do a full backup immediately.)

Errors and Failures Without Requiring Recovery from Backup

Errors and Failures Without Requiring Recovery from Backup
July 15, 2009
Oracle Database RMAN
1. Process Failure
   PMON will automatically perform the process recovery and rollback all involved transactions.
2. Program Failure
   It occurs when data violate the contrains, or data do not meet the data types, and so on, Oracle will automatically raise ORA- errors and Oracle will rollback the transactions automatically, or will wait for program's determination.
3. Instance Crash
   When an instance is shutdown abort or abnormally, SMON will perform recovery automatically(roll forward, then, open the database[uses can access the instance/database at this time], then, roll back the uncommitted transactions) when the instance starts up.

Errors and Failures Requiring Recovery from Backup

Errors and Failures Requiring Recovery from Backup
July 15, 2009
Oracle Database, RMAN
  While there are several types of problem that can halt the normal operation of an Oracle database or affect database I/O operations, only two typically require DBA intervention and media recovery: media failure, and user errors.
Other failures may require DBA intervention to restart the database (after an instance failure) or allocate more disk space (after statement failure due to, for instance, a full datafile) but these situations will not generally cause data loss or require recovery from backup.
1. User Error
   User errors occur when, either due to an error in application logic or a manual mis-step, data in your database is changed or deleted incorrectly. Data loss due to user error includes such missteps as dropping important tables or deleting or changing the contents of a table. While user training and careful management of privileges can prevent most user errors, your backup strategy determines how gracefully you recover the lost data when user error does cause data loss.
2. Media Failure
   A media failure is the failure of a read or write of a disk file required to run the database, due to a physical problem with the disk such as a head crash. Any database file can be vulnerable to a media failure. The appropriate recovery technique following a media failure depends on the files affected and the types of backup available.

Oracle Backup Types

Oracle Backup Types
1. Physical backups
   Physical backups are backups of the physical files used in storing and recovering your database, such as datafiles, control files, and archived redo logs. Ultimately, every physical backup is a copy of files storing database information to some other location, whether on disk or some offline storage such as tape.
   For example:
   (1.) shutdown the database, use os copy command backup all the control files, datafiles, online redo log files.
   (2.) use RMAN to make image copies of an tablespace when a database is running.
   (3.) use RMAN to make a full backup of the database.
   (4.) ...
2. Logical backups contain logical data (for example, tables or stored procedures) exported from a database with an Oracle export utility and stored in a binary file, for later re-importing into a database using the corresponding Oracle import utility.
   For instance:
   (1.) use exp or expdp utilities to export all objects of a database, or all objects of a schema(or schemas).
  

Overview of the RMAN Environment

Overview of the RMAN Environment
July 14, 2009
Oracle Database RMAN
1. The Target Database
The target database is the database that you are backing up, restoring, or
recovering with RMAN.
2.he RMAN Client
RMAN is a command-line-oriented database client, much like SQL*Plus, with its
own command syntax. From the RMAN client you can issue RMAN commands
and SQL statements to perform and report on backup and recovery operations.
RMAN can take interactive input or read input from plain text files (called
command files). RMAN then communicates with one or more server processes
on the target database server which actually perform the work. You can also
access RMAN through the Enterprise Manager; for details see Oracle Enterprise
Manager Administrator's Guide.
The RMAN executable is typically installed in the same directory as the other
database executables. On Unix systems, for example, the RMAN executable is
located in $ORACLE_HOME/bin.
3. The RMAN Repository
RMAN maintains metadata about the target database and its backup and
recovery operations in the RMAN repository. Among other things, RMAN
stores information about its own configuration settings, the target database
schema, archived redo logs, and all backup files on disk or tape. RMAN's LIST,
REPORT, and SHOW commands display RMAN repository information.
The primary store for RMAN repository data is always the control file of the
target database. The CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter controls how long backup records are kept in the control file before
those records are re-used to hold information about more recent backups.
Another copy of the RMAN repository data can also be saved in the recovery
catalog.
4. The Recovery Catalog
Using a recovery catalog preserves RMAN repository information if the control
file is lost, making it much easier to restore and recover following the loss of the
control file. (A backup control file may not contain complete information about
recent available backups.) The recovery catalog can also store a much more
extensive history of your backups than the control file, due to limits on the
number of control file records.
In addition to RMAN repository records, the recovery catalog can also hold
RMAN stored scripts, sequences of RMAN commands for common backup
tasks. Centralized storage of scripts in the recovery catalog can be more
convenient than working with command files.
Except for stored scripts, all of RMAN's features work equally well with or
without a recovery catalog. For more information on the recovery catalog see
Oracle Database Backup and Recovery Advanced User's Guide.
5. The Flash Recovery Area
The Automatic Disk-Based Backup and Recovery feature simplifies managing
disk space and files related to backup and recovery, by managing all backup and
recovery related files in a flash recovery area. You set the flash recovery area
location and size on disk, using the DB_RECOVERY_FILE_DEST and DB_
RECOVERY_FILE_DEST_SIZE initialization parameters. You also specify a
retention policy that dictates when backups may be discarded. RMAN then
manages your backup storage, deleting obsolete backups and backups already
copied to tape when space is needed, but keeping as many backups on disk as
space permits. This minimizes restores from tape during data recovery
operations to shorten restore and recovery times.
6. Media Managers
To access sequential media devices like tape libraries, RMAN uses third-party
media management software. A media manager controls these devices during
backup and recovery, managing the loading, labeling and unloading of media,
among other functions. Media management devices are sometimes called SBT
(system backup to tape) devices.
The Oracle Backup Solutions Program (BSP) works with vendors to help them
produce media management software for their devices. For enterprises that
already use media management software in their environment, many of those
software products can be directly integrated with RMAN. Contact your media
management software vendor for details about whether they participate in the
BSP and have an RMAN-compatible media management layer.