|
Hi All, A weird one, that I am sure is simple but I've never seen before! A client has a service that we click to start in Sybase Central, however the Egg Timer sits there and does not indicate the service has started. Quitting Sybase Central and re-opening or going into Services in Windows shows "Start Pending". Up to this point that's we assume an issue with a location, port, or service name BUT the database seems to be started fine and we can connect to it, using it just as we normally would! The service has parameters: -x TCPIP{port=41953} -n DEMOSQL -o C:\DBLogMessages\DBMessages.txt -oe C:\DBLogMessages -c 1G -ca 0 "e:\spaceman32\demo\spaceman.db" -n Demo The machine details are: SQL Anywhere 10 - Version: 10.0.1.3831 CPU: Intel(R) Xeon(R) CPU E5-2403 0 @ 1.80Ghz RAM 8GB (2.8GB in use= 35%) 64X - Windows Server 2012 R2 Stripping the service down to basics gives the same result: -x TCPIP -n DEMOSQL "e:\spaceman32\demo\spaceman.db" -n Demo We are logging the messages and the log file looks great i.e. it shows the service trying to start and then says it is accepting requests - just as one would want. This makes sense as we can connect to the database and it runs as normal. Below is the message log, (at least the parts I would think are pertinent - not the who processors, licencing bit): I. 11/20 12:20:33. Starting database "Demo" (e:\spaceman32\demo\spaceman.db) at Fri Nov 20 2015 12:20 I. 11/20 12:20:33. Database recovery in progress I. 11/20 12:20:33. Last checkpoint at Fri Nov 20 2015 12:16 I. 11/20 12:20:33. Checkpoint log... I. 11/20 12:20:34. Transaction log: spaceman.log... I. 11/20 12:20:35. Rollback log... I. 11/20 12:20:35. Checkpointing... I. 11/20 12:20:35. Starting checkpoint of "Demo" (spaceman.db) at Fri Nov 20 2015 12:20 I. 11/20 12:20:35. Finished checkpoint of "Demo" (spaceman.db) at Fri Nov 20 2015 12:20 I. 11/20 12:20:35. Recovery complete I. 11/20 12:20:35. Database "Demo" (spaceman.db) started at Fri Nov 20 2015 12:20 I. 11/20 12:20:35. Database server started at Fri Nov 20 2015 12:20 I. 11/20 12:20:35. Trying to start SharedMemory link ... I. 11/20 12:20:35. SharedMemory link started successfully I. 11/20 12:20:35. Trying to start TCPIP link ... I. 11/20 12:20:40. TCPIP link started successfully I. 11/20 12:20:40. Now accepting requests The main issue we have is that we can't run a Net STOP on it for copy purposes as we refresh this database each night from the live one. We can probably run kill.exe on the process this seems rather overkill, (no pun intended), and I hoped someone may be able to help and give me an easy solution to make the service start normally. Any thoughts? Thanks, Alasdair |
|
Are these the actual parameters used for the service? In this case I wonder what Yes, they are the actual parameters, as you say they are not quite right. Will change the -oe one and see if we get any logs for startup errors, (no idea who set it up, I didn't look at these in particular. Whilst the are not quite right the service does the same thing with or without them so the actual issue does not see to be related but I will change the -oe and see if it logs anything then report back.
(20 Nov '15, 09:34)
RADicalSYS
OK, corrected the -oe option, although in reality I would expect it would have just output a file called DBLogMessages with no extension anyway, (which wasn't there). Parameters are now: -x TCPIP{port=41953) -n DEMOSQL -o C:\DBLogMessages\DBMessages.txt -oe C:\DBLogMessages\DBErrors.txt -c 1G -ca 0 "e:\spaceman32\demo\spaceman.db" -n Demo We don't get a DBErrors.txt file so I presume Sybase sees no issues.
(20 Nov '15, 10:08)
RADicalSYS
Version 10 has never been tested with Windows Server 2012 R2 and Microsoft has made many changes to that OS that are likely affecting this; that V10 does not know how to deal with. If you can install the developer edition of V16 or V17 and see that behaving well then I would then expect this to be due to a limitation of an unsupported version. But if you use a version that has been tested with this OS then you may be looking at a new phenomena and possible related to your specific O/S configuration. Has this behaviour only started since going to R2 or after applying some patch from Microsoft? As far as the service manager status persisting as Start Pending . . . that would be related to the callback features needed to be added to (implemented in) processes to be capable of running as a service. I can't think of much that would interfere with that. That code has been pretty stable for a long time so something subtle has happened. I would add -z to youre command line to see if that reveals something else ... but I have no expectations of there being any additional details on this.
(20 Nov '15, 10:22)
Nick Elson S...
1
Nick, I could probably put 16 on there, without a problem and test that but I guess another piece of information that may be relevant is that the live database service is running fine - it has started without issues. As such they have two services on the server, one for a live database and one for a practice one so Sybase 10 can work, it just isn't for this second service. We are hoping to stop the live service tonight when the users finish and see what happens with both, (although I am worried the live won't start after that either)! It could be after a patch as it has worked in the past so that seems quite possible. We may have to port the customer to Sybase 16 which should be fine as we have tested with it and have people using it and they have actually bought 16 when they went live, we just used the older version as we had not tested 16 at that point. Will report back when we have stopped the live database and see what happens. Thanks very much for the input everyone.
(20 Nov '15, 11:41)
RADicalSYS
|
|
HI All, Just reporting back on my odd problem. I went into the clients server and the service was showing "Running". I stopped it and started it - all fine. I then used the overnight batch process that stops the service, copies in a new database and starts it again and all was fine! I looked in the server logs and could see they had restarted the server this morning and it seems this restart solved the issue. I could see in the logs that Distributed COM was causing issues up until the restart - maybe something to do with it. A server restart would have been somewhere on the list of things to try but I was worried in case things got worse and on the restart the main database service decided not to start properly too! As such I don't know what the issue was but it is working now. Thanks for all of your input and if I ever get more info on this I'll let you all know. Regards, Alasdair |
Have you tried using dbsvc -u and -x to start and stop the services, as opposed to Sybase Central?
Breck, no but I am hopefully back into their system this afternoon to do some more checking so will try that too.