|
Hello everybody, we are running MobiLink in version 17.0.10.5866 with an MS SQL consolidated and an UltraLite client on iOS. Everything worked fine until today; over the weekend we did some mass-changes in the consolidated database. After that users complained about long sync times. Checking in the MobiLink Profiler I saw that 100k of rows are sent over and over again. In the ML log I can see that the clients are always sending the same timestamp, even after a successful synchronization: System variable last_table_download value: 2020-04-10 05:05:31.550000 Any idea why this could happen or how to further troubleshoot this? Thank you all, happy Easter and stay healthy! Alex |
|
You likely have a long running transaction in your consolidated database and have snapshot isolation turned on. When snapshot isolation is turned ON, in order to ensure that rows aren't missed, ML must use the timestamp of the oldest open transaction in the server (or database if you are using -dt cmdline switch) to determine the I believe you will see the SQL being used to determine the oldest open transaction being used if you run the ML Server with the -ve switch to show system event scripts. Reg Hello Reg, that was unfortunately not the solution. What I should mention is that the last_table_download stays the same per remote, but is different from remote to remote. Some of the remotes do not face any issues and the timestamp is updated after every sync. Could it be that there is an error at the end of the sync on the client that is not communicated to the MobiLink server? Best regards, Alex
(14 Apr '20, 07:13)
Alexander Ilg
Replies hidden
It's quite possible that the remotes are not successfully applying the download, thus resulting in them asking for the same data again. How are you capturing errors during download at your remote sites in the application that initiates the synchronization request to UltraLite? Is it possible that the synchronization is timing out at the remote database waiting for the download to be generated in the consolidated database? Reg
(14 Apr '20, 15:53)
Reg Domaratzki
Hello Reg, so here is what we found out in the meantime. Maybe you can help us to understand the different timestamps and why they are used. Client UDB We run "select * from syspublication" --> for our publication we have the timestamp of the last synchonization Consolidated database We run: SELECT last_download_time FROM ML_SUBSCRIPTION M JOIN ML_DATABASE D ON D.RID = M.RID WHERE D.REMOTE_ID = 'E2620166-444D-4F37-9AF7-20D8FBFB71B3' --> timestamp for our publication is an old timestamp, four days in the past. This is the timestamp that I can see in the ML logfile and it is not updated after a successful sync. We are now running the ml_reset_sync_state for this remote id, which is changing last_download_time to 1900-01-01. Now when the client is doing a sync, the timestamp of the remote udb is used. What is the logic behind this? Thanks and best regards, Alex
(15 Apr '20, 06:09)
Alexander Ilg
Do you have more than one publication?
(15 Apr '20, 17:51)
Bill Somers
There is a second one, the default publication, but that is never used and the timestamp remains at 1900-01-01.
(16 Apr '20, 02:57)
Alexander Ilg
Comment Text Removed
It's still not clear to me from the information we have whether the remote database is sending an old last_download_time value, or the ML Server is modifying the value during the synchronization. You posted a partial line of output in your original post, but that information is written to the ML log a number of times during the synchronization, so the line on its own does not answer that question. The value in the last_download_time column of the ml_subscription table in the consolidated database is updated when you have download acknowledgements on, but there is no query in the ML Server code nor any SQL from the ML stored procedures created in the syncmss.sql file that queries the value. The value of the last_download_time column of the ml_subscription table in the consolidated database should have no effect on the next last download timestamp value that the ML Server sends down the remote database in the download stream, and should have no effect on the last_download_timestamp used when generating the download stream sent to the remote database. It's possible this value could have an effect if you’ve coded modify_last_download_timestamp or modify_last_download_timestamp events in the ML Server to change the logic that ML uses. Can you please ensure that the ML Server is running with at least the following verbosity options : -vcehpsx. Then please pick a single remote database whose timestamp value is not changing and find two consecutive synchronizations from this remote database and post both of them here. If the output is too large to post here, please upload them to: https://sap-my.sharepoint.com/:f:/p/reg_domaratzki/EgWc2cec8W5HrQow4umjF2kB2KB_pS7NLujSto8thAXjQw?e=5%3aUTugg2&at=9 The full synchronization output from the two synchronizations should give us a pretty clear idea what is going on, both at the client and server side. Thanks, Reg
(16 Apr '20, 15:00)
Reg Domaratzki
Alex, can I assume that you lack of response and lack of files uploaded to the link I posted means that you were able to figure out what was going on yourself by examining the verbose output from the ML Server? Thanks, Reg
(20 Apr '20, 12:40)
Reg Domaratzki
|
