Operation is not valid due to the current state of the object.
HttpException (0x80004005): The URL-encoded form data is not valid.

Wie ich nach zum Glück kurzer Suche herausfand, war ein Update daran schuldig und auf  Scotts Blog (nach „appSettings“ suchen) fand ich dann auch einen Weg, das Problem zu beseitigen.

Und zwar muss dazu in der Datei web.config unter appSettings folgeder Eintrag (der Zahlenwert muss individuell gewählt werden) hinzugefügt werden:

<add key="aspnet:MaxHttpCollectionKeys" value="3000"/>

Danach funktionierte alles wieder wie gehabt.

Dabei sind mir v.a. folgende Artikel untergekommen:

• Verwalten von Servern mit der richtlinienbasierten Verwaltung
• SQL Server 2008 – Getting tough with Policy Management

Mit der schönen Abfrage …

SELECT facet.name as ‘Facet Name’,
OnDemand = CASE facet.execution_mode & 4
WHEN 4 THEN ‘On Demand; On Schedule’
END,
OnChangeLogOnly = CASE facet.execution_mode & 2
WHEN 2 THEN ‘On Change, Log Only’
END,
OnChangePrevent = CASE facet.execution_mode & 1
WHEN 1 THEN ‘On Change, Prevent’
END
FROM msdb.dbo.syspolicy_management_facets facet

… lässt sich schön Abfragen, welche Facets (ich würde das mal als ZielObjekte bezeichnen) bestimmte Evaluation Modi unterstützen.

In meinem Fall wollte ich z.B. erzwingen, dass Tabellennamen in der Datenbank DB1 immer mit tDb1 beginnen. Leider scheint genau dieses über die Policies nicht unterstützt zu sein, da dafür der Evalutation Mode On Change:  prevent verwendet können werden müßte.

Es kann vermutlich nur über DDL Trigger realisiert werden.

• Using a Dedicated Administrator Connection
• remote admin connections Option
• How to: Use the Dedicated Administrator Connection with SQL Server Management Studio

Wichtig ist, dass man sich im SSMS nicht mit dem Explorer verbindet, sondern ein neues Query öffnet und damit die Verbindung zur DB herstellt (Wichtig: dem Instanznamen admin: voranstellen und einen Sysadmin verwenden).

Das Öffnen einer DAC per SQLCMD direct auf dem DB-Server sieht wie folgt aus:

sqlcmd -Sadmin:localhost -U sa -P password -d master

Der SQL Browser lief bei mir übrigens dabei nicht.

Das Blog von Pinal Dave war mit dem Post SQL SERVER – Plan Cache – Retrieve and Remove – A Simple Script Ausgangspunkt meiner Recherche.

Zunächst einmal kann man sich mit folgender Abfrage einmal alle gespeicherten Pläne im Cache anzeigen lassen, die nur einmal benutzt wurden:

SELECT [text], cp.size_in_bytes, plan_handle
FROM sys.dm_exec_cached_plans AS cp
CROSS APPLY sys.dm_exec_sql_text(plan_handle)
WHERE cp.cacheobjtype = N'Compiled Plan'
AND cp.objtype = N'Adhoc'
AND cp.usecounts = 1
ORDER BY cp.size_in_bytes DESC;
GO

Einzelne Pläne können mit dem Verwaltungsbefehl DBCC FREEPROCCACHE aus dem Cache entfernt werden, indem man das plan_handle aus der obigen Abfrage dem Befehl in Klammern hinten anstellt, wie im folgenden Beispiel:

DBCC FREEPROCCACHE(0x06000100804AD30040219A86000000000000000000000000)
WITH NO_INFOMSGS;
GO

Wenn ansonsten kein plan_handle angegeben wird, werden alle Pläne aller DBs auf dem Server gelöscht.
Das ist auf dem Produktivserver nicht unbedingt best practice.

Da das Finden und Löschen eines Plans die Entwicklerproduktivität negativ beeinflusst, ist es hilfreich, dass man die Erstellung der Pläne schon relativ einfach im Vorfeld verhindern kann.
Dazu kann man dem jeweiligen SQL Befehl wie im folgenden Beispiel den Query Hint OPTION (RECOMPILE) hinzufügen:

SELECT * FROM Customers
OPTION (RECOMPILE);
GO

Ein Hinweis von Klaus Aschenbrenner und der Blogpost Clearing your ad-hoc SQL plans while keeping your SP plans intact von Maciej Pilecki führten mich zu folgendem Befehl, der wohl nur die Adhoc Pläne, nicht aber die von Prozeduren löscht:

DBCC FREESYSTEMCACHE('SQL Plans');
GO

Allerdings hat das Teil den Nachteil, dass es auch parameterisierte Abfragen (z.B. von LinqToSQL und Entity Framework) wegputzt.

Übrigens gibt es auch beim Zugriff mit .Net-Anwendungen über das Entity Framework das Query Plan Caching eine Property System.Data.EntityClient.EntityCommand.EnablePlanCaching.
Die habe ich allerdings noch nicht genauer untersucht.

Evtl. könnte man mit Hilfe der obigen Abfrage in Kombination mit DBCC FREEPROCCACHE automatisch in bestimmten Zeitzyklen einfach alle Pläne löschen, die nur einmal verwendet wurden.

Damit läßt sich scheinbar so ziemlich alles verfolgen, was auf der Box abgeht und mit dem SQL Server zu tun hat.
Vereinfacht gesagt, legt man fest, welche Ereignisse beobachtet werden sollen und wo die gesammtelten Informationen gesammelt werden sollen.

Als einführende Beispiele haben mir die folgenden Artikel sehr geholfen:

• SQL SERVER – Introduction to Extended Events – Finding Long Running Queries
• An Overview of Extended Events in SQL Server 2008
• Getting Started with Extended Events in SQL Server 2008

Ausführlicher kann man sich mit dem Whitepaper Using SQL Server 2008 Extended Events einarbeiten.

Auf CodePlex gibt’s auch eine grafische Oberfläche für die Extended Events, das SQL Server 2008 Extended Events SSMS Addin. Damit kommt man anfangs wahrscheinlich einfacher zu einem Ergebnis, da es einige Events, Targets, usw. gibt.

Mit folgendem Skript kann man z.B. auftretenden Fehler mitprotokollieren:

IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AjErrorsReported')
DROP EVENT SESSION AjErrorsReported ON SERVER
GO

--SELECT * FROM sysmessages WHERE msglangid=1031 ORDER BY 1,2

-- Create Event
CREATE EVENT SESSION AjErrorsReported
ON SERVER
-- Add event to capture event
ADD EVENT sqlserver.error_reported
(
-- Add action - event property
ACTION (
sqlserver.session_id
,sqlserver.sql_text
,sqlserver.tsql_stack
,sqlserver.database_id
,sqlserver.username
,sqlserver.client_hostname
)
WHERE sqlserver.error_reported.severity>=11
)
-- Add target for capturing the data - XML File
ADD TARGET package0.asynchronous_file_target(
SET filename='E:\SqlServerData\MSSQL10_50.MSSQLSERVER\MSSQL\Log\AjErrorsReported.xet'
, metadatafile='E:\SqlServerData\MSSQL10_50.MSSQLSERVER\MSSQL\Log\AjErrorsReported.xem')
-- Add target for capturing the data - Ring Bugger
--,ADD TARGET package0.ring_buffer(SET max_memory = 4096)
WITH (max_dispatch_latency = 3 seconds)
GO

-- Enable Event
ALTER EVENT SESSION AjErrorsReported ON SERVER
STATE=START
GO

-- Read the data from Ring Buffer
--SELECT CAST(dt.target_data AS XML) AS xmlLockData
--FROM sys.dm_xe_session_targets dt
--JOIN sys.dm_xe_sessions ds ON ds.Address = dt.event_session_address
--JOIN sys.server_event_sessions ss ON ds.Name = ss.Name
--WHERE dt.target_name = 'ring_buffer'
--AND ds.Name = 'AjErrorsReported'
--GO

-- Read the data from XML File
SELECT
event_data_XML.value('(event/data[1])[1]','INT') AS error
,event_data_XML.value('(event/data[2])[1]','INT') AS severity
,event_data_XML.value('(event/data[3])[1]','INT') AS [state]
,event_data_XML.value('(event/data[4])[1]','BIT') AS user_defined
,event_data_XML.value('(event/data[5])[1]','VARCHAR(1024)') AS [message]
,event_data_XML.value('(event/action[1])[1]','INT') AS session_id
,event_data_XML.value('(event/action[4])[1]','INT') AS database_id
,event_data_XML.value('(event/action[5])[1]','VARCHAR(50)') AS username
,event_data_XML.value('(event/action[6])[1]','VARCHAR(10)') AS client_hostname
,event_data_XML.value('(event/action[2])[1]','VARCHAR(1024)') AS sql_text
,event_data_XML.value('(event/action[3])[1]','VARCHAR(512)') AS tsql_stack
--SELECT CAST(event_data AS XML) event_data, *
FROM
(
SELECT CAST(event_data AS XML) event_data_XML, *
FROM sys.fn_xe_file_target_read_file
('E:\SqlServerData\MSSQL10_50.MSSQLSERVER\MSSQL\Log\AjErrorsReported*.xet',
'E:\SqlServerData\MSSQL10_50.MSSQLSERVER\MSSQL\Log\AjErrorsReported*.xem',
NULL, NULL)) T
GO

-- Stop the event
ALTER EVENT SESSION AjErrorsReported ON SERVER
STATE=STOP
GO

-- Clean up. Drop the event
DROP EVENT SESSION AjErrorsReported
ON SERVER
GO

Joseph Albahari hat eine ArtikelSerie zum Thema Threading in C# (.Net 4.0) veröffentlicht.