Different types of standby database in oracle data guard

In oracle data guard configuration, you need to setup one or more additional databases beside the primary database. These additional databases are called standby database. Up to nice standby database can be created for one primary database.

Using a backup of primary database you can set up standby database and then you can made standby database as part of data guard configuration. Once you configured standby database, data guard automatically maintains standby database by transmitting redo log from the primary database and then applying redo to the standby database.

A standby database can be of three types.

1)Physical Standby Database: A physical standby database is an identical copy of the primary database. The disk structures are also identical with primary database. It is kept synchronized with the primary database by Redo Apply- which means the redo data is received from the primary database and then redo is applied to the physical standby database.

Note that as of Oracle Database 11g release 1 (11.1), a physical standby database can receive and apply redo while it is open for read-only access. You can use physical standby database for query and reporting purpose along with data protection.

2)Logical Standby Database: A logical standby database is the same logical information of the primary database. The physical data structure need not to be same on the standby database. It is kept synchronized with the primary database by SQL Apply- which means the redo data is received from the primary database, transforms redo data into SQL statements and at last executes the SQL statements on the standby database.

You can use logical standby database for query and reporting purpose along with data protection. Also you have to facility to upgrade oracle database software and patch sets along with data protection with help of logical standby database.

3)Snapshot Standby Database: A snapshot standby database is a convertible copy of the physical standby database but the difference from the physical or logical standby database is, the redo data that it received does not apply into it. The redo is applied whenever it is converted back to the physical standby database. You can play with the snapshot standby database and while converting to physical standby database from snapshot standby database these local updates are discarded.

Note that in case of snapshot standby database, the time needed to perform a role transition is directly proportional to the amount of redo data that needs to be applied.

Configuring the Mail server in Unix

There are a number of reasons why you would want to set up your own Linux mail server. You are in a company that has needs for a more reliable mail solution than anything the competition has to offer.

I have deployed Postfix servers in single-user environments

Following are the steps to Install the postfix in  the server

1) Open up a terminal window (or, if you are using a GUI-less server just log in).

2) Issue the command sudo apt-get install postfix.

That's it! Of course, depending upon the current state of your distribution, the installation may or may not have to install some dependencies. But this will happen automatically for you. The installation will also automatically start the Postfix daemon for you. So as soon as installation is complete you can test to make sure you can connect to your Postfix server with the command:

telnet

You should see something like this:

Trying ...
Connected to www.mymail.com.
Escape character is '^]'.
220 localhost.localdomain ESMTP Postfix

Configuring postfix

To allow Postfix to accept relay email, edit the " /etc/postfix/main.cf" file, setting the following value to the relevant host.

relayhost = :

Remember to restart or reload the service for the changes to take effect.

# service postfix restart

Test the change by sending an email.

# echo "This is a test" | mail -s "Relay Test" me@example.com

Datagaurd Quik Refference

Data guard setup and configuration - quick reference

Quick reference to dataguard configuration for the DBAs. The table gives an easy reference on the main attributes of log_archive_dest_n parameter and gives quick concept on the setting. Also, the scenarios where standby redo logs are used to minimize data loss and also to enable real-time apply is discussed.

Configuration	Performance	Availability	Protection	Meaning and Remarks
Standby redo logs	Not required, but recommended	Required	Required	Redo data from primary will be written to standby redo logs by LGWR process and real time apply can be enabled, LGWR/ARCH parameter can be set.
LGWR (Redo archival process)	Not required	Required	Required	Specifies the redo transport service uses LGWR to collect and transit redo data to standby.
ARCH (Redo archival process)	Possible	Not possible	Not possible	Specifies that redo transport services uses ARCn process to collect and transmit redo data to standby.
SYNC (Network transmission)	Not required	Required	Required	SYNC specifies Network I/O to standby is synchronous, that means the LGWR process on primary will wait for Network I/O to complete on the standby so that successful transfer of redo records to standby database is ensured.
ASYNC (Network transmission)	Can be set	Cannot be set	Cannot be set	ASYNC specifies the the LGWR will not wait for Network I/O  to complete and proceeds asynchronously. Not valid if ARCH parameter is used
AFFIRM (Disk Writes)	Not required	Required	Required	Specifies that disk I/O to archived redo logs and standby redo logs on the standby are done synchronously and the LGWR process on primary will wait to continue its processing.
NOAFFIRM (Disk Writes)	Can be set	Cannot be set	Cannot be set	Specifies that disk I/O to archived redo logs and standby redo logs on the standby is done asynchronously and the LGWR process on primary will not wait to continue its processing.

TYPES OF PATCHES IN ORACLE

It all started in January 2005 with Critical Patch Updates (CPU).  Then Patch Set Updates (PSU) were added as cumulative patches that included priority fixes as well as security fixes.  As of the October 2012 Critical Patch Update, Oracle has changed the terminology to better differentiate between patch types.  This terminology will be used for the Oracle Database, Enterprise Manager, Fusion Middleware, and WebLogic.

Critical Patch Update (CPU) now refers to the overall release of security fixes each quarter rather than the cumulative database security patch for the quarter.  Think of the CPU as the overarching quarterly release and not as a single patch.

Patch Set Updates (PSU) are the same cumulative patches that include both the security fixes and priority fixes.  The key with PSUs is they are minor version upgrades (e.g., 11.2.0.1.1 to 11.2.0.1.2).  Once a PSU is applied, only PSUs can be applied in future quarters until the database is upgraded to a new base version. PSU : same as CPU  patches but include both the security fixes and priority fixes Which mean you can't Apply CPU and PSU and same database.

A PSU is a collection of proactive, stabilizing cumulative patches for a particular product version (base release or patch set).  PSUs are cumulative and include all of the security fixes from CPU patches, plus additional fixes.  Critical Patch Updates are the primary means of releasing security fixes for Oracle products. CPUs are cumulative with respect to prior CPUs and generally contain only security fixes.  Each PSU is limited from 25 to 100 new bug fixes.

Security Patch Update (SPU) terminology is introduced in the October 2012 Critical Patch Update as the term for the quarterly security patch.  SPU patches are the same as previous CPU patches, just a new name.  For the database, SPUs can not be applied once PSUs have been applied until the database is upgraded to a new base version.

Bundle Patches are the quarterly patches for Windows and Exadata which include both the quarterly security patches as well as recommended fixes.