Delphix Products

Hi All I add my first dSource oracle but before ingestion engine causes "log file sync" wait on it. Someone had same problem?
#Virtualization

Mario,
Are saying that Delphix is causing "log file sync" waits in your source database, after you have created a dSource?
If that is correct, then I am curious how you come to this conclusion?

1. Are you querying from V$SESSION for sessions belonging to Delphix and seeing them waiting on "log file sync"?
2. Or, are you noticing that other sessions (not necessarily belonging to Delphix) are waiting on "log file sync"?

If #1 is the situation you are seeing, then the Delphix sessions are not *causing* the "log file sync" waits, they are *waiting* on "log file sync".  They are not the cause, they are the effect.
If #2 is the situation you are seeing, then how do you know the origin of the "log file sync" waits?  "Log file sync" waits are always caused by the LGWR process, either because it is processing redo writing too slowly (i.e. I/O too slow), or because something is interrupting it from writing redo too often (i.e. interrupted too often).

Could you clarify please?
Thanks!
-Tim

Hi We observed an increment of Log sync waits on all transaction In the database using Oracle Enterprise Manager . This situation continued for 2 days and ended when we stop DELPHIX SYNC. Our investigation on oracle metalink shows that rman process can disturb database and cause log sync file wait then i post thai thread.

Mario,
One would be hard-pressed to understand how RMAN datafile backups or archivelog backups can cause "log file sync" on foreground transactions.
Except for updating the data dictionary views, RMAN does not perform transactions.  While RMAN itself does not generate redo to affect the LGWR or affect redo generation in any way, it may be possible that RMAN is signaling LGWR in some manner, interrupting the flushing of redo from memory-based Log Buffer to storage-based online redo log files.  If the latter is the case, such as waits on the RMAN sessions, then we should be able to find evidence of that, but first things first, and let's start at the beginning...
It would be helpful to drill down into the observed sessions experiencing "log file sync" waits, and display what SQL statements are experiencing the wait, display what user is executing the sessions, and begin to understand what is actually happening and what is actually affected.  It is never enough simply to observe waits without understanding their context.  When you find who is waiting and on what SQL, can you share that?

Also, can you share the MOS/Metalink note IDs which indicate that RMAN "disturbs" the database and causes "log file sync"?
Looking forward to getting to the bottom of this...

Thanks!
-Tim

Hi Tim The Metalink Note is 1229104.1. Today we intastigate accurately with storage group, backup group and dba group (my team). Our first preoccupation about DELPHIX role in the problem was resolved, we founded storage events on the same time of this incidents. Now we are continuing tests and analisys about this case to confirm these new clues. Thanks for yourr suggestions and interest, and sorry for kg english.