Dapper TVP Behavior and SQL Server Monitoring Overhead
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 25/100
Direzione di ricerca
Inizia riproducendo la chiamata alla stored procedure usando AsTableValuedParameter di Dapper e ispeziona l'output risultante di SQL Server Extended Events. Confronta le istruzioni INSERT osservate per ogni riga con il comportamento previsto di TVP e documenta se è disponibile il batching o una soluzione alternativa pratica; l'issue non indica file o test del repository.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Hi
I’m reaching out to ask for your advice regarding how Dapper sends Table-Valued Parameters (TVPs) to SQL Server and how that appears in monitoring tools such as Extended Events.
In my project, I have defined a TVP as follows:
CREATE TYPE dbo.UserDefinedParameters AS TABLE (
Id INT,
Value1 INT,
Value2 INT,
Value3 INT
)
Dapper parameters on call store procedure command
var searchParameters = new
{
SearchParams = table.AsTableValuedParameter("dbo.UserDefinedParameters"),
OtherParam01 = 10,
OtherParam02 = 20,
};
Everything works correctly, but our database team raised a concern regarding how this call is logged in Extended Events. Specifically, they noticed that each row in the TVP is being sent as a separate INSERT INTO statement, like this:
DECLARE @p1 dbo.UserDefinedParameters
INSERT INTO @p1 VALUES (1, 1, 1388, NULL)
INSERT INTO @p1 VALUES (2, 1, 1388, 603)
-- potentially hundreds more...
EXEC dbo.Search
@SearchParams = @p1,
@OtherParam01 = NULL,
@OtherParam02 = NULL,
...
My questions are:
Is this the expected behavior from Dapper when sending TVPs?
Is there a way to batch these values or reduce the number of INSERT statements?
Have you seen this being a real issue in practice, and would you recommend any workaround or tuning?
- Lingua principale
- C#
- Stelle
- 18.4k
- Fork
- 3.7k
- Merge medio
- 2g 5h
- PR unite (30g)
- 4
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di DapperLib/Dapper
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 68/100
-
Dapper.Rainbow uses DbConnection on Init instead of IDbConnectionForse già presa @Khaos66 l’ha presa 1560 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 58/100
-
Dapper.StrongName 2.1.86 fails strong-name signature verification (all TFMs) — works in 2.1.79Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 65/100
Tutte le issue di DapperLib/Dapper
Issue simili
-
[誤判定] `define` が `デフィね`・`デフィ値` になるForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta再現済み 要トリアージ 誤判定
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
yksr-melt/Meltype#421 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
Facepunch/sbox-public#12063 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
facioquo/stock-indicators-dotnet#2316 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
ionide/FsAutoComplete#1559 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
lostindark/DriverStoreExplorer#477 ·
I maintainer di solito rispondono entro 1 giorno