cancel
Showing results for 
Search instead for 
Did you mean: 

Mobilink SQL Anywhere Schedule - Urgent Question!

Former Member
2,598

Hi, Is there any way we can specify in the Synchronization Profile or in dbmlsync schedule to run the synchronization every 30 minutes (e={sch=every:00:30;}) between 6AM to 11PM.

It looks like the only way to do that is

e=

{sch=everyday@6:00,everyday@6:30,everyday@7:00,everyday@7:30,everyday@8:00,everyday@8:30,everyday@9:00,everyday@9:30,everyday@10:00,everyday@10:30,everyday@11:00,everyday@11:30,everyday@12:00,everyday@12:30,everyday@13:00,everyday@13:30,everyday@14:00,everyday@14:30,everyday@15:00,everyday@15:30,everyday@16:00,everyday@16:30,everyday@17:00,everyday@17:30,everyday@18:00,everyday@18:30,everyday@19:00,everyday@19:30,everyday@20:00,everyday@20:30,everyday@21:00,everyday@21:30,everyday@22:00,everyday@22:30,everyday@23:00;}

The issue is, it is a pretty long string and I don't have any way to randomize the time within the interval so that multiple remote databases with the same schedule do not cause congestion at the MobiLink server by synchronizing at exactly the same time.

I'll appreciate the suggestions.

Accepted Solutions (0)

Answers (2)

Answers (2)

Breck_Carter
Participant

Here's a WAG...

Have you considered using a Server Initiated Synchronization listener and push request setup to let the server side decide when the remotes should synchronized? Then the schedule could be based on actual load rather than prayerful randomization 🙂

Former Member
0 Kudos

Hi Breck,

I am not too sure if Server Initiated Synchronization can be implemented in our network topology. As I understand there are some limitations in this approach.

Device limitations when using UDP gateways •The IP address on the device must be addressable directly from the MobiLink server.

•IP tracking for UDP notification does not work if the IP address on a Windows device is not addressable directly from the MobiLink server.

Regards,

Chinmay

0 Kudos

The Listener can also work by polling the MobiLink server. See this tutorial for more information: http://dcx.sap.com/index.html#sa160/en/mlsisync/ms-examples-s-356626411.html

Something similar can also be done with server initiated remote tasks when using central admin of remotes: http://dcx.sap.com/index.html#sa160/en/mlserver/ml-centraladmin.html I don't know much about remote tasks, but it looks like they let you set a random delay interval which sounds like it's exactly what you want.

Former Member
0 Kudos

Thanks Bill, Breck and Russ for your valuable inputs.

It seems like polling the MobiLink server may be the ideal solution for us. Central admin of the remotes is something we wanted to eventually achieve with Mobilink.

Regards,

Chinmay

Breck_Carter
Participant
0 Kudos

If there was a "Hallmarks of MobiLink" section in the Help (there isn't) one of the points would be "central administration of remotes".

Which means you should be able to find a solution, and if you can't there will be heck to pay 🙂

Former Member
0 Kudos

You could consider generating more random times on a per-remote basis in the sch option above, but I don't know how easy that is to do in your environment. I suppose you wouldn't ask this question if it was easy.

A more programmatic approach is to use an event hook. See Synchronization initiation with event hooks. Using this approach you'd randomly delay the sync to initiate in each desired interval. A more predictable approach would be to use an integer hash of some remote-specific information, like a username, device name, remote id, whatever. This would spread the load and once it worked, you know it should continue to work. Using a random delay can cause spikes and headaches. For your sanity I suggest a non-random approach, if you can.

  • Russ
Former Member
0 Kudos

Hi Russ,

Thanks for your response. I am thinking about using 'sp_hook_dbmlsync_delay' and modify the #hook_dict. I understand that random spikes may cause some issues. I guess the best approach will be to test this change thoroughly.

Regards,

Chinmay

Former Member
0 Kudos

Hi Chinmay,

Thorough testing is always a good thing. 🙂

Best Regards,

  • Russ