|
I have recently noticed an issue on our DB hosted server where our DB services are taking a very long time to start after a system reboot. We are talking 20 minutes or so on a small DB running on a server with 8GB of RAM. We have 3 services in question and it does not matter which combination of them are stopped or disabled, one or all of them will not start until at least 20 minutes has elapsed. One of the services is set as follows: -n SVRNAME -x TCPIP(port=2639) -c 2g -gp 4096 D:\XXXDatabases\CentralDB\XXX.db -n DBNAME -ec Simple What could be holding this up, we have tried to monitor start-up applications and services with no joy. When the DB is started using just DBSRV16.exe without being controlled by a service it starts with no problem, the issue does appear to be when it is controlled by a service. Once it has started the first time (using a service) we can stop and start easily, it is just after a reboot it has issues. |
Follow this question
By Email:Once you sign in you will be able to subscribe for any updates here
By RSS:Markdown Basics
- *italic* or _italic_
- **bold** or __bold__
- link:[text](http://url.com/ "title")
- image?
- numbered list: 1. Foo 2. Bar
- to add a line break simply add two spaces to where you would like the new line to be.
- basic HTML tags are also supported
Question tags:
question asked: 16 Oct '15, 11:52
question was seen: 2,348 times
last updated: 16 Oct '15, 12:20
You might want to verify if you are not delayed because of the type of Autostart setting these have. There is a 2nd type that is by definition to be (delayed start) and that could be interacting. Also if there are any additional SVC dependencies those could have created a startup order dependancy that could be delaying things even before we start. We normally only depend upon the network layer (if even that) but that may have been changed in your hosted environment somehow . . .
Also make sure the 'guest OS' is configure to optimize for background tasks and services {assuming Windows and the option changes a little by type of OS}.
Adding a console log will help identify if this is related to a recovery or network listener startup issue. (I would add -z and -o f_i_l_e_n_a_m_e._l_o_g) myself) If it is due to recovery, then how the vm session is being forced down could be your bigger issue.
If your hosting environment is moving you session around across their farm of blade server, you could be suffering from delays due to copying the session around (ie. VSPHERE/VMotion kinds of operations).
If it turns out to be a delay even before the database server start logging to the console log, I would get your Hosing service to help identify the lag in their environment. It may be the VM Session is just underpowered or the systems that runs on could be overworked (and the spinning up of the VM session itself could be at issue). Maybe a recent configuration change there ...