Time sure does fly and just a reminder Mainstream Support for SQL Server 2012 ends in just over 3 months on 11th July 2017.
Ideally any new SQL Server installs should be the newest, or as close to the newest version of SQL Server as possible, to get the maximum RoE.
With SQL Server 2016 SP1, a lot of Enterprise features are now included in the other editions, so is a great option. Something to be aware of though is that Microsoft is now requiring Software Assurance to be acquired for use of a DR instance. The use of one DR instance was usually included by default in earlier versions.
Task Manager is extremely useful for Windows DBAs, however in the Linux world the use of GUIs may be few and far between.
To your rescue is the top command
Simply open a command/terminal prompt and run top
It may appear to be very basic, but the power is in the options available via simple key presses.
Pressing h on the keyboard will show the options available to you.
So if for example you pressed c you would now see the full command/path information:
To show CPU/Memory info simply press m
To change the refresh rate press d and enter a new refresh rate
If you need to kill a problem PID, you can use k
Try out the various available options to get a real insight into the Linux server activity and press q once finished to close it.
Variations are expected due to SQL Server workloads, but never the less the times averaged out. Having the Windows firewall enabled was slightly faster with an average of 39.7 milliseconds compared to 40.8 milliseconds, which I was not expecting.
Below shows the milliseconds taken between the start/end of each test with the Windows firewall on and off:
Interestingly once installed, the SQL Server Agent refused to start, even after a restart and the latest SSMS showed the SQL Server Agent as inaccessible.
Running the below allowed me to access the SQL Server Agent in SSMS but the Agent still doesn’t start.
sp_configure 'show advanced options','1'
sp_configure 'Agent XPs','1'
sp_configure 'show advanced options','0'
Update: Not having much luck I suspected the issue may be that the server name was more than 15 characters. This is currently a reported issue by Microsoft. Starting over, I created a new VM called vnextvm and the agent installed and started this time with no issues.
If you’ve been a SQL Server DBA for the past 5,10,15 years then your exposure to Linux has likely been minimum or even non-existent.
Consider some of the typical methods you’d use/check when investigating a SQL Server that is no-longer responding:
Connect using RDP
Locate and view SQL Errorlogs
Windows Event Logs
SQL Server Configuration Manager
In the Linux column, would you know the corresponding tool?
It’s just a matter of time before a vendor/project/Manager hands over a SQL Server on Linux for you to support and at the end of the day when there is an issue with SQL it’ll likely end up in your lap.
So now, is a really good time to start getting up to speed with Linux support.