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.