Failover=restart SQL Service?

  • Hello everyone,

    Our company just upgraded to SQL server 2005 64 bit. and then we met the famous bug "A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: 0 seconds. Working set (KB): 223580, committed (KB): 6852344, memory utilization: 3%."

    So I set up "lock page in the memory" on both active/passive nodes. in order to take effect, SQL Service need to be restarted.

    I am just wondering if I just fail over active to passive node, should I still need to restart SQL service?

    Thanks

  • failover from Active to passive will restart the services on the passive node;

    failback from THEN_passive_Now_Active to Then_active_now_passive node will restart the services on the Then_active_now_passive node.

  • sunny Brook (4/20/2009)


    failover from Active to passive will restart the services on the passive node;

    failback from THEN_passive_Now_Active to Then_active_now_passive node will restart the services on the Then_active_now_passive node.

    Thanks you! So after failover and failback, "Lock Page in the memory" will work. Is that right?

  • It should if restarting SQL services is all that it needs to get working.

    BTW, I am having same errors as you were trying to fix. but our SQL is Standard edition, so, I could not apply the LOCK IN Pages thingy to fix. What I had to do was to adjust the max server memory and then restrict using of ROBOCOPY over network, which ,I deemed, caused the Memory trim.

  • sunny Brook (4/20/2009)


    It should if restarting SQL services is all that it needs to get working.

    BTW, I am having same errors as you were trying to fix. but our SQL is Standard edition, so, I could not apply the LOCK IN Pages thingy to fix. What I had to do was to adjust the max server memory and then restrict using of ROBOCOPY over network, which ,I deemed, caused the Memory trim.

    How did you find ROBOCOPY caused the problem?

  • ROBOCOPY is not the sole cause in my case, but it's a major one. I have a job copying backup files over to another server using robocopy. Many times, that error occured after the copy job started. As ROBOCOPy would aggressively demand alot mem when BIG files are being copied. There are some other occurences too when my copy job is not running. And the reason is a myth to me.

    There are the posts in here , here, and here among many others devoted to this issue, for your reference.

  • Thanks Sunny. I will read the articles.

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply