von SQL Server CE zu SQL Server migriert, jetzt verursachen WebSecurity SQL Timeouts

Question

Wir haben eine Website, die wir ASP.Net Webpages gebaut mit

ich vor kurzem die Datenbank von SQL Server CE zu SQL Server 2014 migriert Ich tat dies mit die SQL Server Compact Toolbox auf meinem lokalen Computer, dann die .mdf Datei an unsere Website hosts SQL Server-Instanz angehängt.

Alles hat gut funktioniert und die Seite schien gut zu laufen. Doch kurz nach, fing ich an intermittierende Ausnahmen zu bemerken, die wie diese:

System.Web.HttpUnhandledException (0x80004005): Ausnahme vom Typ ‚System.Web.HttpUnhandledException‘ geworfen wurden.

System.Data.SqlClient.SqlException (0x80131904): Zeitlimit abgelaufen. Das Zeitlimit ist vor dem Abschluss des Vorgangs abgelaufen oder der Server reagiert nicht.

System.ComponentModel.Win32Exception (0x80004005): Die Warteoperation abgelaufen

bei System.Data.SqlClient.SqlInternalConnection.OnError (SqlException Ausnahme, Boolean Breakconnection, Aktion 1 wrapCloseInAction)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
at System.Data.SqlClient.TdsParserStateObject.ReadSniSyncOverAsync()
at System.Data.SqlClient.TdsParserStateObject.TryReadNetworkPacket()
at System.Data.SqlClient.TdsParserStateObject.TryPrepareBuffer()
at System.Data.SqlClient.TdsParserStateObject.TryReadByte(Byte& value)
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, SqlDataReader ds, Boolean describeParameterEncryptionRequest)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource 1 Abschluss, Int32 Timeout, Aufgabe & Aufgabe , Boolean AsyncWrite)
bei System.Data.SqlClient.SqlCommand.RunExecuteReader (CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String-Methode)
bei System.Data.SqlClient.SqlCommand.ExecuteScalar()
bei WebMatrix.Data. Database.QueryValue (String commandText, Obje ct [] args)
bei WebMatrix.WebData.DatabaseWrapper.QueryValue (String Command, Object [] Parameter)
bei WebMatrix.WebData.SimpleMembershipProvider.GetUserId (IDatabase db, String userTableName, String userNameColumn, String userIdColumn, String username)
bei WebMatrix.WebData.SimpleMembershipProvider.GetUser (String username, Boolean userIsOnline)
bei System.Web.Security.Membership.GetUser (String username, Boolean userIsOnline)
bei WebMatrix.WebData.WebSecurity.GetUserId (String username)
bei WebMatrix.WebData.WebSecurity.get_CurrentUserId()
bei ASP._Page_Default_cshtml. <> c__DisplayClass5.b__3() in e: \ web \ givenoru \ Default.cshtml: Zeile 118
bei System.Web.WebPages.WebPageBase. <> c__DisplayClassb.b__9 (Textwriter tw)
bei System.Web.WebPages.HelperResult.WriteTo (Textwriter writer)
bei System.Web.WebPages.WebPageBase.Write (HelperResult Ergebnis)
bei ASP._Page__SiteLayout_cshtml.Execute (in e): \ web \ givetoru_SiteLayout.cshtml: Leitung 184
bei System.Web.WebPages.WebPageBase.ExecutePageHierarchy()
bei System.Web.WebPages.WebPage.ExecutePageHierarchy (IEnumerable 1 executors)
at System.Web.WebPages.WebPage.ExecutePageHierarchy()
at System.Web.WebPages.WebPageBase.ExecutePageHierarchy(WebPageContext pageContext, TextWriter writer, WebPageRenderingBase startPage)
at System.Web.WebPages.WebPageBase.<>c__DisplayClass7.<RenderPageCore>b__6(TextWriter writer)
at System.Web.WebPages.HelperResult.WriteTo(TextWriter writer)
at System.Web.WebPages.WebPageBase.Write(HelperResult result)
at System.Web.WebPages.WebPageBase.RenderSurrounding(String partialViewName, Action 1 body)
bei System. Web.WebPages.WebPageBase.PopContext()
bei System.Web.WebPages.WebPageBase.ExecutePageHierarchy (WebPageContext pageContext, TextWr iter writer, WebPageRenderingBase startPage)
bei System.Web.WebPages.WebPageHttpHandler.ProcessRequestInternal (Httpcontextbase Httpcontext)

ClientConnectionId: 4f57f963-05e1-4429-946b-504e59e13050
Fehlernummer: -2, Status: 0, Klasse: 11

bei System.Web.WebPages.WebPageHttpHandler.HandleError (Exception e)
bei System.Web.WebPages.WebPageHttpHandler.ProcessRequestInternal (Httpcontextbase Httpcontext)
bei System.Web.WebPages.WebPageHttpHandler.ProcessRequestInternal (Httpcontext context)
bei System.Web.WebPages.WebPageHttpHandler.ProcessRequest (Httpcontext-Kontext)
bei System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
bei System.Web.HttpApplication.ExecuteStep (IExecutionStep Schritt, Boolean & completedSynchronously)

Nachdem einige graben tun, es sieht aus wie es mit Anrufen zu WebMatrix.WebData.WebSecurity Klassen wie diese zu tun haben kann:

WebSecurity.CurrentUserId 

Hat jemand irgendwelche Gedanken auf, was könnte dazu führen, dieses Problem? Muss ich etwas Besonderes für meine DB tun, um diese Zeitüberschreitungen zu vermeiden?

aktualisieren 20.170.303 922AM CT

Hier ist meine Verbindungszeichenfolgen sind als Referenz (mit sensiblen Daten unkenntlich gemacht):

<add name="StarterSiteEntities" connectionString="metadata=res://*/App_Code.ProductModel.csdl|res://*/App_Code.ProductModel.ssdl|res://*/App_Code.ProductModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=tcp:*****;initial catalog=*****;integrated security=False;Connection Timeout=30;user id=*****;password=****;MultipleActiveResultSets=True;App=EntityFramework&quot;" providerName="System.Data.EntityClient" /> 

<add name="StarterSite" connectionString="Data Source=tcp:****;Initial Catalog=****;User ID=****;Password=*****;Integrated Security=False;Connection Timeout=30;" providerName= 
"System.Data.SqlClient" /> 

Hier ist die Linie von meiner _AppStart.cshtml Datei, die die WebSecurity DB-Verbindung initialisiert:

WebSecurity.InitializeDatabaseConnection("StarterSite", "UserProfile", "UserId", "Email", autoCreateTables: false); 

Answer 1

Es sieht wie ein normales Verbindungsproblem mit dem SQL Server aus. Da Ihre Anwendung im Allgemeinen funktioniert, gehe ich davon aus, dass Sie möglicherweise unterschiedliche Verbindungszeichenfolgen für Ihren normalen Datenzugriffscode und die Authentifizierung mit SimpleMembershipProvider verwenden, wodurch das Problem nur dann auftritt, wenn alle authentifizierungsbezogenen Daten aus der Datenbank abgefragt werden:

Wie in meinem Kommentar unten erwähnt, behandelt Ihre Frage WebMatrix.WebData.WebSecurity, wo die Ausnahme auftritt, Authentifizierung mit der SimpleMembershipProvider. Die Verbindungszeichenfolge, die dafür verwendet wird, kann eine vollkommen andere sein, als Sie für Ihren normalen Datenzugriffscode verwenden würden, z. ein Entity Framework DataContext.

So, wie Sie es beschreiben, ich denke, es ist sehr wahrscheinlich, dass Sie zwei verschiedene Verbindungszeichenfolgen verwenden für SimpleMembershipProvider und Ihre EF DataContext (oder was auch immer Sie für Ihre Datenzugriffsgebiet genutzt wird) und vielleicht die eine für die SimpleMembershipProvider wurde bei der Migration zur vollständigen SQL Server-Datenbank nicht aktualisiert.

Ich hoffe, das führt Sie zumindest in die richtige Richtung. Andernfalls möchten Sie vielleicht Ihre web.config und insbesondere die komplette Membership- und ConnectionString-Konfiguration freigeben. Achten Sie darauf, keine sensiblen Daten zu veröffentlichen, obwohl :)

Update:

Die Verbindungszeichenfolgen Sie fein und identisch geschrieben scheinen.Ich habe ein Bit in Ihrer Ausnahme verpasst: Es heißt Timeout expired während im Fall, wenn es wirklich ein Verbindungs-Timeout war, würde es sagen Connection timeout expired (zumindest in .NET Framework 4.5 oder neuer, IIRC).

Sie sollten also überprüfen, ob Sie ein Abfrage-Leistungsproblem auftreten können. Haben Sie einen Index auf in Ihrer benutzerdefinierten Benutzertabelle, da dies nach dem StackTrace abgefragt wurde? Ich gebe zu, dass es unwahrscheinlich ist, dass eine einzelne Abfrage in einer Benutzertabelle ohne komplexe Joins länger als 30 Sekunden dauert, auch wenn kein Index vorhanden ist. Aber möglicherweise stoßen Sie manchmal auf eine Datenbanksperre.

Als nächstes können Sie SQL Server Profiler an Ihre Datenbank anhängen und ausführen lassen, bis eine Ausnahme wie die obige in Ihrer Anwendung erscheint. Überprüfen Sie dann, ob zu diesem Zeitpunkt in Profiler eine lange laufende Abfrage ausgeführt wurde.