Sync looks hanging in download phase in C$ALL_SNAPSHOTS (last item)

Question

The synchronizations are “hanged” for a long period on time in the download phase on the last 2 items:
PI_APP_PUB_PROPERTIES
C$ALL_SNAPSHOTS
The time is bigger if the number of clients synchronizing at the same time is bigger as well.
I have taken some detailed cycles and the Total Sync Time does not fit at all with the sum of the time used for all the items during upload plus download… this difference is very high!
Did anybody faced a similar problem?
Below some examples:
session_id = 1106
SYNC_SECS = 428
UPLOAD_SECS = 3
DOWNLOAD_SECS = 425
SUM( UPLOAD_ITEMS_SECS) = 2
SUM( DOWNLOAD_ITEMS_SECS) = 279
Where are the 147 seconds of diff used for?!!
session_id = 1135
SYNC_SECS = 664
UPLOAD_SECS = 5
DOWNLOAD_SECS = 659
SUM( UPLOAD_ITEMS_SECS) = 4
SUM( DOWNLOAD_ITEMS_SECS) = 407
Where are the 253 seconds of diff used for?!!
Thanks everybody in advance.
Tomeu

Answer 1

Hey Tomeu
Try the following:
On the new associated CMP$ table, insert about 5000 or 10000 bogus rows. Run stats and then delete the rows.
I will try to sum up what the problem is, it isn't actually related to Oracle Mobile but with the database engine itself. You have a table CMP$ size 0 rows, mobile server inerts N amount of rows. When the download is complete, there is a cleanup process that run individual update statements in a batch/cursor scenario. The update statements actually use ROWID to update each row... and you would think the explain plan at this point uses the pk index to get the row required for update, it actually does a Full Table Scan on the N number of rows. If stats are collected when there is some data in the table, it will for the update statement to use a better explain plan to perform the update.
Now, if MGP is timing out, then there are a couple of issue that are happening... the C$ALL_SNAPSHOT issue could and should cause a timeout issue of MGP. A correction to this would be to convert the table that is causing this issue to Queue based refresh. Another issue could just be the type of SQL query that you are running in that snapshot isn't effecient with MGP/Sync and may need to be altered to perform better. Use of query caching can help, I would attempt that before queue based refresh though. So in this order, your performance tuning technique should be this:
1. Check the SQL and see if it can't be tuned to get better results.
2. Enable Query Cache for the snapshot
3. Queue-based refresh.
Let me know if you have questions.
Greg