I tried to turn on the Activity Monitor using SQL Server 2008 Management Studio (SSMS) through the options window of the application (Tools | Options | Environment | General | At Startup).
I restarted SSMS and I am getting the following message:
"This operation does not support connections to Microsoft SQL Server Standard Edition version 8.00.2249."
I need to be able to monitor the processes and activities inside the database since I am investigating a particular application which takes a lot of time in its database data retrieval access and I am thinking it may be due to some locks or some processes.
How do I resolve this? Inputs highly appreciated. Thanks.
The Activity Monitor relies on DMVs that were introduced in SQL Server 2005. You cannot monitor a SQL 2000 instance. Your version number (8.00.2249) is for a SQL Server 2000, a product no longer supported (mainstream support retired 4/8/2008). Upgrade the instance to SQL Server 2008.
If you want to investigate a SQL 2000 instance, you'll have to rely on the old views and procedures: sysprocesses, sp_who, sp_lock. See INF: Understanding and resolving SQL Server blocking problems.
SQL 2000 does not have Dynamic management views that feed this info to the activity monitor
Run sp_who2 instead, it is not as rich as the activity monitor but it will tell you who is connected and who is blocking. You can then also run something like DBCC INPUTBUFFER (SPID) to get the first 255 characters of the statement executed by the sql connection
Related
Microsoft® Access® for Microsoft 365 MSO (Version 2202 Build 16.0.14931.20888) 64-bit
Microsoft SQL Server 2019 - 15.0.4261.1 (X64) Copyright (C) 2019 Microsoft Corporation Standard Edition (64-bit) on Windows Server 2016 Datacenter 10.0
System Type 64 bit operating system, x64-based processor
I've created an ODBC 64-bit file DSN connection for a MS Access Pass-Through Query to a SQL Server database. I've got a large query that runs on the client side in around five minutes; the query appears to run and correctly return the requested records. The ODBC Timeout is set to 540 (seconds). The problem is that the server shows that the query ran for over forty-five minutes before I was contacted by a DBA. I terminated Access and that severed the connection.
Would anyone know why this might happen or how I could troubleshoot?
You can trace a query to see when different phases of the query complete.
Typically, when something impossible seems to be going on, when you look closer there's some easy explanation. Is there a transaction that's left open? Does running the query trigger updating statistics? Why does the DBA think the query keeps running? There's nothing unique about ODBC querying the database that would allow it to keep running without terminating. A first step might be to just run the query directly within SQL Studio and see if you can reproduce.
https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/performance/troubleshoot-never-ending-query?tabs=2008-2014
In our company we have to support a large legacy system built on Microsoft Access 2010 as frontend and SQL Server 2008 R2 as backend. The backend SQL server runs on Windows Server 2008 R2. Currently our users works on Terminal Server sessions on a Windows Server 2008 R2. A couple of days ago we started to test Windows Server 2019 and Notebooks with the latest version of Windows 10. We recognized a big performance difference while executing the same Access databases on the different environments.
For instance the creation of a report takes 27 seconds (new environment) instead of 7 seconds (old environment). The database.accdb is identical, the backend is identical (still Windows 2008 R2 Server with SQL Server 2008 R2 and SP2), only the execution environment (Windows) changed.
Does anyone of you have an idea how to explain this?
In Access 2010 the SQL server tables are linked using System-DSN data sources. On the old environment ODBC is used (Driver: SQL Server, Version: 6.01.7601.17514).
On the new environment I tested the following drivers:
ODBC Driver 11 for SQL Server (2014.120.5543.11)
ODBC Driver 17 for SQL Server (2017.173.01.01)
SQL Server (10.00.17763.01)
SQL Server Native Client 10.0 (2009.100.4000.00)
SQL Server Native Client 11.0 (2011.110.5058.00)
I created a new System-DSN using the different drivers and updated the linked tables in Access. But in any case the performance is still bad. I also tested the latest version of Access which comes with Office 2019, but again it is slow.
Sounds like your terminal sessions are getting throttled. Despite the fact that you have a SQL Server back end, Access is still doing a fair bit of thunking with the result sets, so any resource throttling differences between your Server 2008 and Server 2019 policies could be choking Access in the new server.
I think your answer is going to be found in Windows System Resource Manager. The page says it's not being maintained, but following the "Recommended Version" link leads to a generic Server 2019 page. Here's another article about how WSRM might be throttling sessions: Using WSRM to control RDS Dynamic Fair Share Scheduling.
Compare the Weighted_Remote_Sessions policy in 2008 and 2019 servers. There's either been a change to the default settings or behavior or the 2008 server policy was modified in the past to get to the current performance level.
Ok, a number of things to check.
First thing to check:
Launch the ODBC manager and check if SQL log tracing is on. I don’t know why, but I see sql logging turned on.
You NEED to be 100% sure it is turned off.
You MUST launch the ODBC manager from the command line or start menu, since the one in the control panel is for the x64 bit version, and you are using Access x32 (I assume).
So launch this version:
c:\Windows\SysWOW64\odbcad32.exe
So VERY important to launch the x32. It is assumed you are using a FILE dsn. So check these two settings:
(Make sure they are un-checked).
Next up?
Link access using the IP address of the sql server.
So, place of say:
myServer\SQLEXPRESS
Use:
10.50.10.101\SQLEXPRESS
(Of course use the IP address of sql server, not the above “example” IP).
The above things are quite easy to check.
Still no performance fix?
Then disable the fire wall on your new Terminal server (I seen this REALLY cause havoc).
And, disable windows defender on the new TS server if running.
The above tips should fix your issues.
If above don’t work, then next would be to check the priority settings for the TS server (GUI over server).
However, I am betting the above checks should restore your performance.
I'm following a step-by-step guide written by a Microsoft field engineer on below documentation to create BizTalk 2016 AOAG with SQL 2016 enterprise edition in conjunction with Server Management Studio (14.0.17224.0):
https://learn.microsoft.com/en-us/biztalk/core/high-availability-using-sql-server-always-on-availability-groups?redirectedfrom=MSDN
My question on preparing the availability group using Server Management Studio (14.0.17224.0) supports database DTC option is that new functionally added to SQL management studio (14.0.17224.0) and during creation of his lab environment he mention DTC support cannot be applied from the SSMS and must be done in script?
I created AG though SSMS GUI and ran query to find DTC status on DATABASE as below
:
--===Checking where there DTC support is ENABLED or NOT for BIZTALK 2016 SSODB======
SELECT NAME,DTC_SUPPORT FROM sys.availability_groups
HOLD ON!
The first thing you should do is really, double, triple check you really, absolutely 110% need (as in no other option) to use AOAG with BizTalk Server.
While supported, AOAG is in practice a net negative with BizTalk Server over regular failover clustering alone since it adds significant additional complexity to the setup, while providing no incremental benefit to BizTalk Server.
Note, this situation is specific to BizTalk Server. Many apps can and do benefit from AOAG, just not BizTalk Server.
Availability Groups is better H/A solution in my opinion. It comes with database-redundancy and a much faster failover which a BizTalk environmient will benifit from.
From SQL 2016 SP2 and SQL Server 2017 it also supports Cross Database Transaction inside instances in AOAG so you only need one instance (instead of 4 instance in SQL 2016 SP1).
I belive that a Windows Failover Cluster is more complex because you have a lot more shared resources while in Availiability Groups it is only the listner that is a resource in WFC.
Starting with SQL Server 2016 (13.x) Service Pack 2 you can alter an availability group for distributed transactions. For SQL Server 2016 (13.x) versions before Service Pack 2, you need to drop, and recreate the availability group with the DTC_SUPPORT = PER_DB setting.
Recently, I have installed MSSQL Server 2008 Express.
Every time I try to enable "SQL Server Agent (SQLEXPRESS)", I got this error message:
WMI Provider Error: "The Remote procedure call failed".
I have tried to search for a solution but I have found some solutions and tried them all but It is still not working. Do you have know a good solution for this?
In addition, what is SQL Server Agent? do we really need it?
This is a bit strange.
One of the restrictions of the free SQL Server Express (compared to the bigger editions) is that it has no SQL Server Agent.
So you shouldn't even be able try to enable SQL Server Agent, because your edition doesn't support it!
However, I have SQL Server 2008 Express installed as well, and I never cared to take a look if the SQL Server Agent service is listed on my machine.
I just looked on my machine: it is there, it's called "SQL Server Agent (SQLEXPRESS)" exactly as yours, and I'm even able to start it.
I didn't expect that!
But it's not visible in SQL Server Management Studio, so I can't create any jobs (and I expected that).
Apparently Microsoft restricted the use of SQL Server Agent in the Express edition not by omitting the service at all, but by making it invisible in Management Studio.
So my actual answer is this:
Don't waste time by trying to start SQL Server Agent.
You don't need it to run the database, and you can't use it anyway even if you can get it to run.
SQL Server Agent is used for Job Scheduling, amongst other things.
If you don't know what it is, you probably don't need it ;) It's not necessary for the standard SQL Server RDBMS functionality.
I can't speak specifically to the error you're seeing.
Can you monitor SQL server to tell exactly what queries it is running?
We have an application that is exhausting the application pool.
A server administrator has sent us a report from Debug Diag [http://www.microsoft.com/downloads/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en][1] which shows threads running for an hour which doesn't seem possible.
If we could just see what queries the server was actually running we could trace them to our code.
If you have the full version of SQL Server, it has the query profiler (from Management Studio, Tools menu, select "SQL Server Profiler").
SHOW PROCESSLIST;
or
SHOW FULL PROCESSLIST;