Oracle RAC Data Synchronization problem

Now there is this environment:

A web Server, a pure Java app program

The database is made up of two forms of RAC. Web server and app programs are connected through OCI (RAC)

Database.

Out of such a strange problem, webserver update or an illustration into a data, followed by the app in the query can not be, until the use of tools to query there is no problem.

Initial suspicion

1. Rac method The following database two instance sync not good?

Inquiries related to the relevant information found in the Max_commit_propagation_delay.

The maximum submission propagation delay (Max_commit_propagation_delay, abbreviated MCPD) is used in an Oracle RAC (or OPS) environment, representing the latest system change Code (SCN) produced by a instance system in a RAC system, How quickly to react to another instance.

For example, the RAC system, there are a,b two instances (instance), a, B Local System change code for SCN1,A Update data DATA1 submission, LGWR operation completed, A Local System change code for SCN2, after less than max_commit_propagation After _delay time, the B system local change code only becomes SCN2.

Global Cache Services Refreshes the SCN in the RAC. Regardless of whether the SCN refreshes in a timely manner, subsequent data queries do not result in database errors. However, during this time, it is possible that the query result is not the latest data, resulting in a read consistency problem.

All instances in a RAC environment, this parameter value must be the same.

After Oracle8i, the recommended two values are 0 and 700 (default), and other values are not recommended. In fact, these two values represent the two SCN generation mechanisms in a RAC environment:

Lamport scheme and broadcast on Commit scheme.

Set to the default value of 700, which means that the Lamport SCHEME,SCN change will not be fully synchronized and the synchronization will be completed in 7 seconds instead of waiting 7 seconds. If the system is idle, synchronization may be completed in 0.5 seconds (or even less), and no synchronization time can exceed 7 seconds, regardless of how busy the system is. It is not difficult to understand that using this mode, the whole RAC system has a high operating efficiency.

Set to 0 to change the full synchronization using the broadcast on Commit SCHEME,SCN. Whenever commit (that is, when LGWR writes redo log):

-LGWR sends a message to update the global SCN.

-LGWR sends a message to update its local SCN for each active instance.

There is information that, as long as MCPD < 700, the system will adopt broadcast on Commit scheme.

Lamport scheme can adapt to the requirements of most applications, only a particular high real time business, only need broadcast on COMMIT scheme. Through analysis, it is not difficult to understand that broadcast on COMMIT scheme will require more system resources