John Esraelo
asked on
SQL traffic and usage
I am putting a plan together to upgrade a SQL 2008 R2 to 2016.
New to the work-place therefore not sure who / what is hitting and using this server remotely and/or by connecting.
What's the best way to find out what and who is hitting this box so I can be proactively be able to upgrade the box?
thx
JE
New to the work-place therefore not sure who / what is hitting and using this server remotely and/or by connecting.
What's the best way to find out what and who is hitting this box so I can be proactively be able to upgrade the box?
thx
JE
You would go to start then search and type in Terminal Services Manager then select your server on the left then on the right you will see the users tab and sessions tab to view whom is hitting it.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I am glad that we are thinking the same. The profiler is the best way to start the investigation. Thx
JohnE
JohnE
You don't need SQL Profiler if you just want to see if somebody is connected. You can just open a new query window in SSMS and run the following command:
exec sp_who2
Or open SSMS and right-click on SQL Server instance name and then choose the "Activity Monitor" option. Wait few seconds and it will show a graphic with the current connections.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
My understanding of author's question is he wants to know when is possible to perform the upgrade, meaning when nobody is connected.
If not, then yes, SQL Profiler should be used. Otherwise to get an actual report of who's connected, just check the current activity in SQL Server. Terminal Services connections doesn't say who's connected to the database.
If not, then yes, SQL Profiler should be used. Otherwise to get an actual report of who's connected, just check the current activity in SQL Server. Terminal Services connections doesn't say who's connected to the database.
ASKER
good morning all,
excellent answers and suggestions.
To be able to in-place upgrade from 1 version to another would requires me to understand the in-bound and out-bound processes and therefore their compatibility levels during the pre-upgrade.
The outbound is easy, as many suggested. The in-bound is a bit tricky because there are several servers that have either SSIS running and hitting this box, which is easy to find out (well takes time a bit) and there are hundred of OS level scheduled tasks that are written in VB.NET and scheduled.
Perhaps the profiler is indeed one of the good solutions.
I do appreciate your insight and excellent suggestions.
excellent answers and suggestions.
To be able to in-place upgrade from 1 version to another would requires me to understand the in-bound and out-bound processes and therefore their compatibility levels during the pre-upgrade.
The outbound is easy, as many suggested. The in-bound is a bit tricky because there are several servers that have either SSIS running and hitting this box, which is easy to find out (well takes time a bit) and there are hundred of OS level scheduled tasks that are written in VB.NET and scheduled.
Perhaps the profiler is indeed one of the good solutions.
I do appreciate your insight and excellent suggestions.
John, if you want, you can use DEA to help you with the migration assessment. I've wrote an article that may help you working with DEA.
ASKER
thank you all.
I was able to find out that there were a few SSIS packages hitting the box and the profiler revealed a few pieces of info
thx
again
JohnE
I was able to find out that there were a few SSIS packages hitting the box and the profiler revealed a few pieces of info
thx
again
JohnE