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.
All in Oracle database.
Thursday, July 23, 2009
Wednesday, July 22, 2009
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.
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.
Tuesday, July 21, 2009
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?
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?
Monday, July 20, 2009
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;
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.
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.
Sunday, July 19, 2009
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.
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.
Saturday, July 18, 2009
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.
(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.
Subscribe to:
Posts (Atom)