Server Side SSMS

  • Comments posted to this topic are about the item Server Side SSMS

  • I cannot speak for others but me being almost permanently RDP'd into the server with an active session of SSMS already up and running has saved our caboose a couple of times in the last almost 9 years when no one else (not even the infrastructure folks) could get into the server.  If you can't actually spare the (IMHO) small amount of memory or the pittance of CPU to do the same, then you need to get some more memory and another couple of core.  Hopefully, you'll never need it but, if you ever do and you don't have it, you'll wonder why you didn't.  If you do need it and you have it, you'll wonder why you didn't do it earlier and never go without it again.

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".
    "Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • This experience of working from home (WFH) has shown me that I really do want to have tools like SSMS on a machine at work. When I first started WFH I tried running SSMS and ADS from my work laptop. I thought it would be best, but I discovered that it isn't. The lag time to download query results over the wire was intolerable. And for my area I've got a really good Internet connection and speed. It still was bad. So, I've gone to using DirectAccess and RDP to my workstation at work each day. The speed of working is significantly faster.

    Its true that the remote connection to my work workstation does get dropped 2 or 3 times a day, but the speed with which I can work RDP into my workstation is so much better that I'd rather put up with occasional disconnects, than pull results down to my work laptop.


  • I don't fully understand why we don't all do *everything* on a remote box, and basically just use local hardware as a viewing window into remote systems. Seems much more light-weight, would allow IT to deal with configurations in one location, save security issues with people losing laptops, etc.

    Getting a new laptop or getting new people set up means waiting for shipping, waiting to be added to groups to get software pushed to you, then calling the help desk because it never showed up, or the wrong version got pushed, etc.

    Seems like they should be able to just spin up a VM with software included that mirrors the job description I'm in, and I'm off to the races.

    Oversimplifying, I know, but still...

    Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses

  • Been tried for years, with various levels of success:

    Part of the reason is a lot of hardware in a central place. If everyone depends on the VM cluster, then you get back to the mainframe days, where potentially you have a lot of failure points and idle people when things break. It's also not entirely simple to backup/move/manage VMs.


    I think we ought to have these for some things, and certainly for sysadmins.

  • jonathan.crawford wrote:

    I don't fully understand why we don't all do *everything* on a remote box, and basically just use local hardware as a viewing window into remote systems...

    Part of it is the current technology available either cannot do this effectively, or adds too much cost into the environment.  Where I work they tried "virtualizing" desktop applications for a while using Citrix XenApp, but it wasn't too effective.  The results were that everything was slower, more difficult to manage, and like Steve mentioned you have "all your eggs in one basket".  Even having a load balancer setup and a large number of servers still resulted in odd performance bottlenecks and poor end user experience.  We ended up just using it for remotely located employees.  With all the shelter-in-place / stay-at-home orders in effect, we've had to use it more again, and of course it's negatively impacting productivity again such that they are looking to buy many more VPN licenses and switching remote people to using that.

  • When we provision a instance, we will set SQL Server max mem so that at least 4 - 8 GB memory is free for both Widows and SSMS. If I'm going to deploy a script that might take hours to run, something like deploying an index on a 300 GB table, then I will RDP into the server and run it via SSMS there. That way, I can fold up my laptop and check in on it from home. However, we do have a dedicated RDP instance just for this purpose. I still don't run SSMS on a production high volume transaction server.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • For the last 7 years, we 've been deploying on Windows Server Core, and now more recently, Linux.

    We don't have the opportunity for local tools, other than limited commandline based ones.

    We rely on Manage Servers / Jump Boxes and offer a choice of tooling.  SSMS is restricted to SQL Administrators, ADS or other IDEs can be used by others.

    AucklandSQL User Group
    Independent SQL Server Consultant
    SQL Server MVP

Viewing 8 posts - 1 through 8 (of 8 total)

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