Post reply

Sql Server Core vs Full blown version of SQL Server

  • December 14, 2015 at 6:04 pm

    #1845967

    Lynn Pettis (12/14/2015)

    Here is how I look at it. If the people who build, create, and maintain the servers (physical or virtual) have decided to install Windows Server Core on the servers and only add those services that are needed on that server (SQL Server, file share, ftp, web, print server, etc.) then you need to learn to work with them, not against them. They are in the same boat you are when it comes to managing the servers. If they want to use a GUI interface it has to connect remotely. If that doesn't work and they have to connect directly to the server they have to use command line access as well.

    They are trying to reduce the surface area of attack on their servers, and reduce the complexity of maintenance (patch management, etc.). Learn the SQL that you need to identify and resolve issues using either SQLCMD or PowerShell.

    Also, make sure the DAC connection is enabled. Many times when a SQL Server instance becomes unresponsive to a remote SSMS connection, you can still connect a remote SSMS query window to that server using the DAC connection (that is what it is there for by the way). You'll still need to run queries to identify and resolve the issue(s).

    Help yourself, learn more about SQL Server and how to troubleshoot issues without a GUI. You may find yourself working someplace where they don't use Windows Server Core but prohibit installing any client tools on production servers.

    BTW,

    I use T-SQL commands and I do not use the GUI to get a quick view of what is going on when I get a timeout from a remote client. That is very rare. I only use as a last resort and when time is of essence.

    I'm on board with everyone, I'm not fighting anyone. I'm was just trying to exploring the options.

    I already knew what the pros and cons are.

    For better, quicker answers on T-SQL questions, click on the following...
    http://www.sqlservercentral.com/articles/Best+Practices/61537/

    For better answers on performance questions, click on the following...
    http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

  • December 14, 2015 at 6:11 pm

    #1845969

    Mike Hinds (12/11/2015)

    What I haven't seen mentioned is the solution my organization uses:

    Have a dedicated (to the DBAs) terminal server where SSMS, Profiler, et al, are installed. Then run SSMS (and other tools) as a Remote App. I do this to manage all (nearly 300) visible instances of SQL. (Invisible includes those in DMZs, and those in our UAT that is accessible through a VPN).

    Regards,

    - Mike

    Hmm... interesting.

    Thanks for sharing that with me.:-)

    For better, quicker answers on T-SQL questions, click on the following...
    http://www.sqlservercentral.com/articles/Best+Practices/61537/

    For better answers on performance questions, click on the following...
    http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

  • December 14, 2015 at 6:18 pm

    #1845973

    Welsh Corgi (12/9/2015)

    Jeff Moden (6/12/2015)

    I can't speak for anyone else and I'm sure that it will rub some folks' sensibilities the wrong way but I do install the full monty on my servers and it has saved my keester a couple of times when the only way in was by RDC (and, no... sorry, I don't remember the exact details. It was quite a while ago).

    Thank you.

    I like the flexibility of using the client tools on the server if everything goes bad,

    Yes you can use power shell but it limits your vision. I want to be able to quickly navigate among screens,

    I do not want to be limited to power shell.

    Thanks Jeff it has save my keester several times. Especially with a heavy ETL to Staging and staging to DW.

    For better, quicker answers on T-SQL questions, click on the following...
    http://www.sqlservercentral.com/articles/Best+Practices/61537/

    For better answers on performance questions, click on the following...
    http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

  • December 14, 2015 at 6:47 pm

    #1845978

    Welsh Corgi (12/14/2015)

    Lynn Pettis (12/14/2015)

    Here is how I look at it. If the people who build, create, and maintain the servers (physical or virtual) have decided to install Windows Server Core on the servers and only add those services that are needed on that server (SQL Server, file share, ftp, web, print server, etc.) then you need to learn to work with them, not against them. They are in the same boat you are when it comes to managing the servers. If they want to use a GUI interface it has to connect remotely. If that doesn't work and they have to connect directly to the server they have to use command line access as well.

    They are trying to reduce the surface area of attack on their servers, and reduce the complexity of maintenance (patch management, etc.). Learn the SQL that you need to identify and resolve issues using either SQLCMD or PowerShell.

    Also, make sure the DAC connection is enabled. Many times when a SQL Server instance becomes unresponsive to a remote SSMS connection, you can still connect a remote SSMS query window to that server using the DAC connection (that is what it is there for by the way). You'll still need to run queries to identify and resolve the issue(s).

    Help yourself, learn more about SQL Server and how to troubleshoot issues without a GUI. You may find yourself working someplace where they don't use Windows Server Core but prohibit installing any client tools on production servers.

    BTW,

    I use T-SQL commands and I do not use the GUI to get a quick view of what is going on when I get a timeout from a remote client. That is very rare. I only use as a last resort and when time is of essence.

    I'm on board with everyone, I'm not fighting anyone. I'm was just trying to exploring the options.

    I already knew what the what the pros and cons are.

    If this part of your statement above is true:

    I use T-SQL commands and I do not use the GUI to get a quick view of what is going on when I get a timeout from a remote client. That is very rare. I only use as a last resort and when time is of essence.

    Why do you need SSMS on the server? You could use SQLCMD to run the same queries and run them just as quickly.

  • December 14, 2015 at 6:55 pm

    #1845979

    Lynn Pettis (12/14/2015)

    Welsh Corgi (12/14/2015)

    Lynn Pettis (12/14/2015)

    Here is how I look at it. If the people who build, create, and maintain the servers (physical or virtual) have decided to install Windows Server Core on the servers and only add those services that are needed on that server (SQL Server, file share, ftp, web, print server, etc.) then you need to learn to work with them, not against them. They are in the same boat you are when it comes to managing the servers. If they want to use a GUI interface it has to connect remotely. If that doesn't work and they have to connect directly to the server they have to use command line access as well.

    They are trying to reduce the surface area of attack on their servers, and reduce the complexity of maintenance (patch management, etc.). Learn the SQL that you need to identify and resolve issues using either SQLCMD or PowerShell.

    Also, make sure the DAC connection is enabled. Many times when a SQL Server instance becomes unresponsive to a remote SSMS connection, you can still connect a remote SSMS query window to that server using the DAC connection (that is what it is there for by the way). You'll still need to run queries to identify and resolve the issue(s).

    Help yourself, learn more about SQL Server and how to troubleshoot issues without a GUI. You may find yourself working someplace where they don't use Windows Server Core but prohibit installing any client tools on production servers.

    BTW,

    I use T-SQL commands and I do not use the GUI to get a quick view of what is going on when I get a timeout from a remote client. That is very rare. I only use as a last resort and when time is of essence.

    I'm on board with everyone, I'm not fighting anyone. I'm was just trying to exploring the options.

    I already knew what the what the pros and cons are.

    If this part of your statement above is true:

    I use T-SQL commands and I do not use the GUI to get a quick view of what is going on when I get a timeout from a remote client. That is very rare. I only use as a last resort and when time is of essence.

    Why do you need SSMS on the server? You could use SQLCMD to run the same queries and run them just as quickly.

    Lynn,

    Let it go.

    Do not worry about it.

    Thanks.

    For better, quicker answers on T-SQL questions, click on the following...
    http://www.sqlservercentral.com/articles/Best+Practices/61537/

    For better answers on performance questions, click on the following...
    http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

  • December 15, 2015 at 8:37 am

    #1846107

    Does anyone know if DOS style (character mode) apps will run, or can be written for, Windows Core Edition?

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

Viewing 6 posts - 46 through 50 (of 50 total)

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