Difference between physical and logical standby database

A standby database can be either a physical standby database or a logical standby database:

Physical standby database

Provides a physically identical copy of the primary database, with on disk database structures that are identical to the primary database on a block-for-block basis. The database schema, including indexes, are the same. A physical standby database is kept synchronized with the primary database by recovering the redo data received from the primary database.

Logical standby database

Contains the same logical information as the production database, although the physical organization and structure of the data can be different. The logical standby database is kept synchronized with the primary database by transforming the data in the redo received from the primary database into SQL statements and then executing the SQL statements on the standby database. A logical standby database can be used for other business purposes in addition to disaster recovery requirements. This allows users to access a logical standby database for queries and reporting purposes at any time. Also, using a logical standby database, you can upgrade Oracle Database software and patch sets with almost no downtime. Thus, a logical standby database can be used concurrently for data protection, reporting, and database upgrades.

The difference between physical and logical standby is in the way the changes from the primary are applied. Both created as an exact image of the primary database. Both receive redo logs from the primary database. The difference is that a physical standby is mounted (but not open) and applies the received redo logs just as in the case of media failure recovery. A logical standby reconstructs SQL statements from the received redo logs and executes them. A logical standby is (must be) opened and can with some limitations be used for reporting or other purposes. A physical standby is mounted and generally cannot be used for any other purposes. You can however switch temporarily to read-only mode and query it but synchronization with the primary will be paused until you return to the recovery mode. In 10g Rel. 2 you can also open it read-write and then flashback to its original state

Internal Errors (ORA-600) and Core Dumps (ORA-7445)

ORA-00600: internal error code, arguments: [argument1] [argumentX]

The internal argument ORA-600 is raised within the Oracle kernel when an exceptional condition occurs. Inside the kernel code at various stages of processing, so called assertions are executed. These are certain conditions that must be true to be able to proceed. The assertions are internal health checks and guard over the integrity of memory and data of the instance and the database. When such an assertion fails, an ORA-600 error is raised with either a numeric or alphanumeric first argument and possibly more arguments depending on the particular error. Note that not all ORA-600 errors are necessary fatal errors causing the session to terminate; some are quite benign. Others however can be severe so they must always be carefully investigated.

ORA-07445: exception encountered: core dump

A core dump is an exceptional condition similar to the internal error ORA-600, however, the big difference is that the kernel did not anticipate the error. Whereas in the case of the internal error the exceptional condition was discovered by an assertion which is a predefined check, the core dump happens because the operating system at some point aborts the process because it is doing a forbidden action such as trying to access an area of memory that does not belong to the process. This is why core dumps are often referred to as access violations. The term 'core dump' stems from a period when memory was stored with the use of magnetic cores, in computer terminology 'core' equates to 'memory'. A core dump means that the memory of the process was dumped in a file 'core' on the file system.

Oracle Background Processes

The Background Processes

MMON – This process performs various manageability-related background tasks, for example:

• Issuing alerts whenever a given metrics violates its threshold value
  

• Capturing statistics value for SQL objects which have been recently modified

MMNL - This process performs frequent and lightweight manageability-related tasks, such as session history capture and metrics computation.

MMAN - is used for internal database tasks that manage the automatic shared memory. MMAN serves as the SGA Memory Broker and coordinates the sizing of the memory components.

Finding CRS master node

check the crsd.log

cd $ORACLE_HOME/log/crsd/crsd.log

2010-02-05 02:32:32.139: [ OCRMAS][3348]th_master:13: I AM THE NEW OCR MASTER at incar 67. Node Number 3

This means that we had another incarnation and the master node is 2.

Confusing a little beat. This is happening because the logs rotate or are write in a matter of events happening between the nodes.

So for my opinion please check the crsd.log from each node and the master is the one in the latest incarnation.

e.g

From node1 crsd.log :
2010-02-02 13:05:44.424: [ OCRMAS][3348]th_master:13: I AM THE NEW OCR MASTER at incar 62. Node Number 1

From node2 crsd.log :
2010-01-18 09:58:19.932: [ OCRMAS][3352]th_master:13: I AM THE NEW OCR MASTER at incar 53. Node Number 2

From node3 crsd.log :
2010-02-05 02:32:32.139: [ OCRMAS][3348]th_master:13: I AM THE NEW OCR MASTER at incar 67. Node Number 3

So the master node is 3 !!!

You can also check with :

ocrconfig -showbackup

where the latest backup is, that's the master node. But remember that by default ocrbackups are taken every 4 hours.

OR

I have RAC 4 nodes and need to know master node:

-I have RAC 4 nodes and need to know master node:

- Use ocrconfig -showbackup
Oracle backup OCR file automatic on master node, So check OCR backup information be able help.

$ ocrconfig -showbackup

node04 2009/07/21 23:10:38 /u01/oracle/product/crs/cdata/crs
node04 2009/07/21 19:10:38 /u01/oracle/product/crs/cdata/crs
node04 2009/07/21 15:10:38 /u01/oracle/product/crs/cdata/crs
node04 2009/07/20 23:10:36 /u01/oracle/product/crs/cdata/crs
node04 2009/07/08 11:10:14 /u01/oracle/product/crs/cdata/crs

that mean master node be "node04"
more
- grep -i "master node" ocssd.log | tail -1 at ORA_CRS_HOME/log/nodename/cssd/ path.
But perhaps not see in ocssd.log file.

Events that trigger a checkpoint

Oracle Checkpoint

A checkpoint performs the following three operations:

1. Every dirty block in the buffer cache is written to the data files. That is, it synchronizes the datablocks in the buffer cache with the datafiles on disk.
It's the DBWR that writes all modified databaseblocks back to the datafiles.
2. The latest SCN is written (updated) into the datafile header.
3. The latest SCN is also written to the controlfiles.

The update of the datafile headers and the control files is done by the LGWR(CKPT if CKPT is enabled). As of version 8.0, CKPT is enabled by default.
Events that trigger a checkpoint
The following events trigger a checkpoint.

* Redo log switch
* LOG_CHECKPOINT_TIMEOUT has expired
* LOG_CHECKPOINT_INTERVAL has been reached
* DBA requires so (alter system checkpoint)

Additionally, if a tablespace is hot backuped, a checkpoint for the tablespace in question is taking place.
While redo log switches cause a checkpoint, checkpoints don't cause a log switch.
Time and SCN of last checkpoint
The date and time of the last checkpoint can be retrieved through checkpoint_time in v$datafile_header
The SCN of the last checkpoint can be found in v$database.checkpoint_change#.
Size of redo log
If the size of the redo log is to small, the performance of the checkpoint will not be optimal. This is the case if the alert.log contains messages like Thread .. cannot allocate new log....