Premises / What you want to achieve
With the server replacement, the version of SQL Server was upgraded.
At that time, an event occurred in which repetition worsened compared to the old environment. I am in trouble without improvement.
Problems and error messages that have occurred
Event①Response deteriorated in client-server system. Login etc. as a whole.
Event ②
Accessing a linked server configured with Oracle Provider for OLE DB deteriorates a simple select process of 30,000 records from a few seconds to two and a half minutes.
environment
"Old environment"
Build on VMWare
Windows Server 2008 R2 Standard SP1
SQL Server 2014 32-bit version (12.0.5000.0)
Link server consists of Microsoft OLE DB Provider for Oracle
"New environment"
Build on VMWare
Windows Server 2012 R2 Standard
SQL Server 2014 64-bit version (12.0.5000.0)
Link server consists of Oracle Provider for OLE DB
Things I tried
I thought it was related to the network, but I couldn't find any noticeable phenomena by monitoring the performance monitor.
The same applies to other CPUs, memories, disks, etc.
Also, if data is obtained from an external DB without using a linked server, it can be obtained in a normal time, so it is speculated that this is a SQL Server problem.
I would like you to teach me how to identify the cause. Thank you
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 have an AWS instance, on which SQL Server 2014 has been running for more than 3 years.
But a few days ago, suddenly the SQL Server stopped running.
I checked the server and tried to start SQL Server service from services, from SQL Server Configuration Manager etc. but I'm not able to start the server and got following error:
So I checked event viewer entries and I found these two errors:
I started some research work over web to overcome on this issue and I found that I can start SQL service using below command using T902:
net start MSSQL$REVCORD /T902
And SQL Server service started successfully.
But I want to make SQL Server / services back to normal as before so I can start / stop services normally.
I found on web that this cause is due to corruption in master SQL Server database, I don't have backup of master SQL Server database so I cannot restore it back.
I checked multiple threads over web and tried multiple things to overcome this issue but no luck.
So finally I decided to reinstall/recover SQL Server 2014, but I am getting another error while reinstalling:
Based on finding over web, all threads showing that I have to uninstall and reinstall SQL Server to make it normal again.
Please help! It's a live server with multiple calls continously so I cannot uninstall/reinstall SQL Server there due to possible data loss.
The first thing:
select * from sys.sysmessages where error = 5833
The message:
The affinity mask specified is greater than the number of CPUs supported or licensed on this edition of SQL Server.
Check your edition, and fix the affinity mask so that the number of CPUs satisfy the number which is supported by your edition.
You can fix it in SSMS on the Processors tab in your server properties, or using sp_configure
I am using the 64-bit version of SQL Server 2016 Express, trying to connect to a 32-bit Pervasive SQL v10 database. I am setting up a Linked Server in SQL Server via ODBC connection, but I am receiving this error that has given me a lot of pain in the past:
The specified DSN contains an architecture mismatch between the Driver and Application
I had a similar issue not long ago trying to connect to a Microsoft Access database, but with help here I was able to obtain the 64-bit ODBC driver for Access. However, there does not seem to be one for Pervasive v10 at all, only for PSQL v11+, which does not help me in this case.
Previous question: SQL Server Linked Server to MS Access - DSN Architecture Mismatch Error
So if anyone has a suggestion for connecting to a 32-bit client from a 64-bit SQL Server installation, when there does not exist a 64-bit ODBC driver for this client, please let me know.
One of the suggested solutions was to use an OLEDB link instead (but no details provided on this, and I'm not sure how it would differ from the linked server I am already trying to create, which is already using OLEDB).
There was also mention somewhere of installing an entirely separate 32-bit SQL Express client, and chaining an additional ODBC link to point to the first one, but I would rather avoid all that overhead if possible, especially since this is a production server that is already running Sage 50 in addition to our own software and web services with SQL Server...
Other details: The client that is built on Pervasive SQL v10 that I am trying to connect to is Peachtree 2017 - Sage 50. This is all running on Windows Server 2012 R2 Standard.
More reading here:
https://support.na.sage.com/selfservice/viewdocument.do?noCount=true&externalId=12693&sliceId=1&cmd=displayKC&dialogID=50216&docType=kc&noCount=true&isLoadPublishedVer=&stateId=50217&docTypeID=DT_Article&ViewedDocsListHelper=com.kanisa.apps.common.BaseViewedDocsListHelperImpl
https://www.experts-exchange.com/questions/23995371/Installing-Pervasive-SQL-Client-on-Windows-2008-64bit-missing-ODBC-Driver.html
Edit:
Thanks for the comments! After further investigation... it looks like this IS actually PSQL v11, not v10. Now, I'm not sure why the 64-bit ODBC driver is not already installed... but I am looking into this now...
We are working for a client with an asp.net/SQL server application which has been using a SQL Server 2005 system till now. The client has decided to upgrade the database to SQL Server 2008 R2 and has procured a powerful server machine with 16 processors with enough RAM and installed Windows Server 2008 64 bit on the system. Now we are tasked with the installation of SQL Server 2008 on the system followed by migration of the existing DB from the SQL 2005 box. Now I am not a SQL Server DBA nor am I a System Administrator by role. Hence, in spite of reading up a lot of the literature on the net, I am not quite able to make sense of it all or put it in the right order of execution. Can somebody explain me the following items, preferably in terms of bullet lists:
What are the points of consideration during installation of SQL Server 2008, specifically in terms of
Configuring memory usage
Configuring the SQL Server to take advantage of the multiple processors available
Other factors to configure to enable SQL Server 2008 features for performance and scalability
Other points, if any, for configuring the Windows Server 2008 with respect to SQL Server 2008
Note: We will only use the Database Engine services in SQL Server. The applications does not use SSIS, SSRS, etc.
SQL Server will take advantage of whatever processors are available. Processors will be shared between sessions - if all of the work is being done by a single session, then it will all occur on the same processor (to the best of my knowledge - this requires citation).
Memory usage is dynamic by default, meaning that there is no restrication on memory usage. You can limit the memory usage used by the server (right-click on the connection in SSMS and select properties) if needed. This is generally used if the instance is part of a server performing other tasks, such as running other database instances, web service tasks, etc.
SQL server is pretty good it sorting itself out according to its environment. If you are in a position that you need to create a server farm and distribute data and processing between different machines, this is a whole new topic, discussed at length on MSDN and the StackExchange forums.