Kald af SP tager lang tid

Det burde ikke tage længere tid i en SP.

Men vi skal jo nok se lidt kode for at kunne forklare hvorfor det alligevel gør det.

Vil nogen kode nogen sinde vaere langsommere i en SP?

For ikke at skrive alt for megen kode, saa goer jeg foelgende:

foreach cursor fetch
{
insert into tabel
}

insert into tabel2

Nej.

cursor har ikke noget godt ry performance mæssigt.

Men bruger du også cursor i ikke-SP løsningen ??

(en SELECT og så app der genererer INSERT er ikke det samme som en CURSOR)

Begge loesninger bruger cursore. Begge bliver eksikveret i SSMSE. De 2 loesninger er defineret saaledes:

1)
CREATE PROC dbo.InsertStuff(@Id BIGINT)
AS

foreach cursor fetch
{
insert into tabel
}

insert into tabel2

Dette kalder jeg ved:

EXEC InsertStuff 2016

2)
DEFINE @Id AS BIGINT
SET @Id = 2016

foreach cursor fetch
{
insert into tabel
}

insert into tabel2

Så lyder det mystisk.

Bare en nysgerrigt spørgsmål...

Er det slet ikke muligt at konstruere en
INSERT INTO table (col1, col2 ... coln)
SELECT col1, col2 , ... coln
FROM another_table

Det vil nok være hurtigere.
Måske du kan eksperimentere lidt med rettighederne for det FETCH. READ ONLY?

/Thomas

Der er meget der kan spille ind når du bruger en SP og meget svært at svare generelt på. Men men.... til at starte med som berglund spørger så, hvilken cursor type bruger du?
Og hvordan med din SP? Er den lavet med recompile?

Jeg har fundet ud af det er erklaeringen af cursoren der tager laaaang tid. Jeg ved ikke hvor lang tid eftersom jeg aldrig har ladet den faerdiggoere erklaeringen. Det som det drejer sig om er:

DECLARE PartsCursor
CURSOR FOR

"select saetning"


Hvis jeg smider "select saetning" over i en temporaer tabel, og laver cursoren herpaa, saa gaar det hurtigt og jeg er igen nede paa de 2-4 sekunder.

Jeg maa aerligt indroemme at jeg ikke ved om den er lavet med recompile. Den er ikke lavet med read only, det kunne vaere en mulighed.

Nu kender jeg jo ikke din kode, men i rigtigt mange tilfælde kan man undgå at bruge en cursor, well...

Prøv evt. at lave en FAST_FORWARD cursor, eller måske en STATIC - forsøg hvad der fungerer bedst :)

Må vi se den fulde kode?

Måske det er en deadlock, dvs. at læse/skrive rettigheder der sætter hinanden i skak. Man skal virkelig overveje typen af CURSOR hvis man man vil brugen den.

Microsoft om DECLARE CURSOR. Her kan du læse om typer af CURSOR:
http://msdn.microsoft.com/en-us/library/ms180169.aspx

/thomas

berglund og janus_007>> Jeg tror ikke det er muligt ikke at bruge en cursor, eftersom raekkerne er afhaengige af hinanden... Dvs, hvis en vaerdi er sat i forrige raekke, saa skal et flag saettes i denne raekke.

berglund>> Desvaerre har jeg allerede aendret koden til brug af tmp tabel, og kan derfor ikke vise den org. kode. Ikke desto mindre siger min logiske sans at det ikke har noget med deadlock at goere eftersom det jo virker uden brug af cursor... men der er maaske bare mig og min manglende viden.

Nu var det jo dig der snakkede om Cursors ;)

Hvad der kan lade sig gøre eller ej... tjaaa... sålænge vi ikke kan se din kode er det jo svært at debatere det med dig!

svar => point

Det må jo henlede det lidt på at det kan gøres bedre når man ikke vil vise det :-)

Generelt har hele tråden været gæt på gæt på gæt på gæt ... hvilket kunne være løst tidligere hvis alt info kom med fra start ... :-P

Men nok om det ... godt det virker, hygge nat.

// ouT

Tak for alle kommentarer.

svar => point

lukker spg.