I'm working on a large web application running under IIS 6.0 and connecting to an SQL Server 2005 database. I'm currently trying to connect to the database using Windows Authentication to properly log which user account updates records in the database, but I've run into a bit of a performance issue; The initial connection that establishes the session takes easily over a minute to finish.
There are no network issues (This is a test server, so all tests are local). My IIS is configured to use Basic Authentication (I need the login info plain) and Local Impersonation is enabled, with an empty username/password setting.
This setup establishes the connection properly, but as mentioned, takes way too long to start up (subsequent queries are performed at normal speed)
Does anyone know if Local Impersonation should affect performance this dramatically? Am I looking in the wrong place? Is there any way to force SQL Server to keep the database connection open?
Thanks in advance for any help!
Try changing the way you reference your local server. If your application settings are (local)\instance_name update it to (127.0.0.1)\instance_name.
I’ve had similar performance issue in the past and this fixed it. Note that you’ll need to add this IP address as one of the listeners in SQL Server Configuration manager under Network configuration -> TCP/IP
Related
I'm new to SQL Server. I was a postgres user before. I installed the default SQL Server on my local machine and I'm trying to get an old react with node js application of mine working with a SQL Server. When ever my frontend makes more than 1 call to the backend, if my SQL Server has admin privileges it throws
Error: 17810: Could not connect because the maximum number of '1' dedicated administrator connections already exists.
If not, it throws:
Error 18451: Only administrators may connect at this time.
I checked my database configs and it's set to MULTI_USERS, so I don't understand why I can't login without admin privileges. Can someone help me with this? I wasn't able to find anything online.
My NodeJS backend is using TypeORM to connect to the database
The dedicated administrator connection is a different kind of connection. It's not just "a connection being made by someone with administrative access". You would use the DAC when the SQL instance is having some kind problem, and you can't connect at all because resources are all tied up. SQL will reserve some resources especially for the DAC connection to make sure you can still connect.
A DAC connection can be made by specifying ADMIN: as part of your connection string, which will connect to the assigned DAC port.
You shouldn't use this for "routine" admin work. Just connect using a login with the required administrative server roles (eg, sysadmin). You definitely shouldn't use this as part of a regular application's connection string. You shouldn't be using a SQL Server sysadmin login either. Create a user with the appropriate permissions for your application, and don't use the admin connection.
Regarding your second issue: Make sure the instance wasn't set to start in single user or minimum configuration mode using startup flags. Note that this is for the whole instance, it's not the same as the configuration for an individual database.
The basic question is this, if our Windows service uses Windows Authentication for connections to SQL Server, and then because of a network disconnect, SQL server and/or the client machine cannot reach AD to authorize or authenticate, will our service still be able to connect to SQL Server and operate?
I’ve tried it and it seems to work, but we are concerned if it will work even after a few days of being disconnected or after server reboots and the like.
The alternative would be to use SQL Server Authentication, but we would rather not have to deal with potentially exposing and having to protect the password on the client computer. This computer may be in a remote location with little supervision. SQL Server would typically be running on this same remote computer.
And for the follow up questions, does it matter which edition of SQL Server we use? Does it matter that both SQL Server and the service are running on the same computer?
If AD connection is lost, existing SQL connections will keep working (at least for some time), and connection pools will be still available (again, for some time). However, I wouldn't get too comfortable with this, because these time spans might depend on settings outside of a typical DBA' reach.
Alternatives are:
Use an AD proxy. Depends on circumstances, might not be always viable;
Use local user accounts instead of AD. Works always.
I am working with azure based application. In which, I need to get connected with azure sql server. I had already configured firewall setting on azure portal for my IP address. But still even when I tried to get connected to azure sql server, it never gets connect at the very first time. When I try to connect it more than two times then it gets connected.
This problem is also with application level connectivity, when i try to run the application on visual studio same happens.
I had researched a lot regarding this specific problem but didn't get any solution yet. I always get network related error Error Code : 53.
Any help will be appreciated.
This looks a lot like a local network issue.
When your application is deployed onto an Azure resource (App service, VM, etc.) does it get a similar connection error?
Every Azure SQL Server has a firewall, you need to create a client IP rule but also to allow access to the Azure service.
I have a pc with windows server 2008 (but it also happens with Windows Server 2003) and IIS, with different installed sites, which normally function properly.
Sometimes (2-3 times a day) it happens that the mdb connection of the server stalling, in the sense that all the sites that read mdb database come into a kind of loop, since the browser returns the classic timeout error.
Not depend on the database or from the site, but occurs on all sites on the server. In general, they are sites in asp with classic ADODB connection. The web access continues to operate, it's just the mdb connection that goes into loop.
It’s sufficient to restart the service of web publishing or restart IIS, to run again the connection, but I want to prevent the problem, not solve it every time someone report it.
May depend on what? Some of the sites that does something that is blocking the mdb connection on entire server? A hacker attack of some kind? How can I monitor any abnormal behavior of the sites or external attacks?
Thank you.
Stop using an Access database file (.mdb or .accdb) as a back-end database for a web application.
Microsoft strongly recommends against it; it is simply the wrong approach for a number of reasons.
I have a situation where clients connecting to my webservice(that exists on another server) must access SQL Server databases and SSAS servers.
It must use the credentials of the client that is calling the service when accessing the SQL Servers and SSAS cubes.
For this to work I do
var winId = HttpContext.Current.User.Identity as WindowsIdentity;
var ctx = winId.Impersonate();
//Access Database/SSAS
ctx.Undo();
in my service which works fine when accessing SQL Server databases.
However when I access the SSAS servers I get
"The connection either timed out or was lost"
There are a number of posts like
http://denglishbi.wordpress.com/2009/03/31/windows-server-2008-kerberos-bug-%E2%80%93-transport-connection-issues-with-ssas-data/
http://sqlblogcasts.com/blogs/drjohn/archive/2009/03/28/kerberos-kills-large-mdx-queries-on-windows-server-2008-ssas.aspx
on this but I am using Windows Server 2008 R2
where my service lives so this should not be a problem as this bug should have been fixed by Microsoft.
Any information as to how to best diagnose this problem would be appreciated.
To clarify the SSAS servers do have SPNs. This was actually working at one point but has now stopped. Appears no sign of duplicate SPNs or anything.
What is interesting is it works intermittently on one SSAS server but seems to work all the time for the other.
They both have named SPNs as mentioned by this document
https://support.pyramidanalytics.com/entries/22056243-Configuring-Kerberos-Delegation-for-Named-Instances-of-SSAS-with-Active-Directory-and-additional-pro
My production environment is a load-balanced (and under heavy load) on a very large corporate Active Directory network. The following took a lot of testing to finally nail down settings that work.
I also run on Windows 2008 Server R2
My web services are in ASP.NET in IIS. For authentication I enabled "Windows Auth" and "ASP.NET Impersonation". Kernel mode is disabled and provider is "Negotiate:Kerboros"
SPNS and Trusted Delegation are setup for an AD account. My AD account looks like sys_myservice (sys_ is just a naming convention at my company)
The Application Pool identity is set to use the sys_myservice
After you make all these changes in your dev env, restart the entire server. For some odd reason this is always necessary when we bring on new servers and configure them.
With this setup my web services access SSAS, SQL Server, and more that use Windows Kerboros auth and all queries are performed correctly under the user's credentials.
The difference in my setup from yours is ASP.NET Impersonation is enabled at the IIS level. I had trouble doing the impersonation in code which is what you are trying to do. If you get code-level impersonation to work with your workflow I would be really interested in seeing you post an update.
Forgot to mention. My services are in a MVC application, I apply a global filter to all Action methods to force the application to authenticate all connections.
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
filters.Add(new System.Web.Mvc.AuthorizeAttribute());
}
and in my web.config system.web section
<authentication mode="Windows" />
<identity impersonate="true" />
I agree that the intermittently 'successful' SSAS instance is suspicious. I wonder if it's really using Kerberos all the time. Could be using a combination of negotiate/NTLM and Kerberos, with one auth method actually working and the other approaching failing. Might be worth another look at the SPN. This link might help: http://msdn.microsoft.com/en-us/library/dn194200.aspx
Did you try using Wireshark or any other Network Analysis tools to see anything red happening at that point of failure? Probably its better if you provide more troubleshooting observations from your end.
Also, does your web services has a Load balancer?
Regards,
Sasi.