Ang. MSSQL og Timeout

Prøv:
    cmd.CommandTimeout = 120;

- eller hvor lang tid du gerne vil vente.

prøv at bruge en StringBuilder i stedet for en string
string's er mega langsomme

lifo> Det er også en god ide, men her var det specifikt databaseforespørgslen der tog for lang tid.

man kan sætte timeout, op men en så simpel SQL bør ikke tage > 30 sekunder

----

StringBuilder er meget hurtigere til append end String, men i medmindre der er
rigtigt mange records så snakker vi tusinddele sekunder

----

men hvis vi nu kigger lidt på SQL'en

for optimal performance skal der være index på [Oprettet d.] - er der det ?

og så må der være en fejl i den SQL - SELECT COUNT(Nummer) og GROUP BY nummer
synes jeg ikke giver mening

Hej Arne, min kode ser ud som flg. nu...:

public void getLMGData()
{           
    string txtData = "";
    SqlCommand  cmd = new SqlCommand("SELECT * FROM [NET Danmark AS$Forsendelse] WHERE ([Oprettet d.] BETWEEN ('01-10-2005') AND ('31-10-2005')) AND (AgentKode = '6666CLK')", oSQLConn);           
    cmd.CommandTimeout = 320;
    FileStream fs1 = new FileStream("tekstfil.txt", FileMode.OpenOrCreate, FileAccess.Write, FileShare.Write);
    StreamWriter sw = new StreamWriter(fs1);

    try {
        SqlDataReader SqlDR = cmd.ExecuteReader();
       
        while (SqlDR.Read())
        {
            txtData = SqlDR.GetString(1) + "|";        //Pakkenr
            txtData += SqlDR.GetDateTime(18) + "|";    //Lev. Dato
            txtData += System.Math.Round(SqlDR.GetDecimal(24)) + "|";    //Pris
            txtData += System.Math.Round(SqlDR.GetDecimal(10)) + "\n";    //Vægt
            sw.Write(txtData);
        }

        SqlDR.Close();
       
        MessageBox.Show("Færdig!");

    } catch (Exception ee) {
        MessageBox.Show("Fejl: " + ee.ToString());
    }
   
    sw.Close();
    fs1.Close();
   
}

Hvad ville kunne gøres bedere siger du?

//>Rune

den er jo lidt anderledes

:-)

er der index på felterne:

[Oprettet d.]
AgentKode

?

Hej Arne,

Ja, jeg har index på de 2 felter...

Jeg har prøvet at lave det om til og være StringBuilder istedet for String, og det resulterede i flg. resultat:

String:
Loadtime: 3 min, 7 sec

StringBuilder:
Loadtime: 2 min, 45 sec

Så lidt har det givet... - den skal hente 59.000 records ind...

Er der mere jeg kan gøre?

//>Rune

59000 records på 3 minutter lyder meget langsomt

er hardwaren OK ?

har det system travlt med andet ?

er data og log segmenterne allokeret med de rigtige størrelser fra start
så den ikke har extended nogle tusind gange ?

Det er et Navision system som får trukket nogle hissige forspørgelser af vores kundeservice afdelinger osv. så tralvlt har databasen da...

SQL serveren er blevet sat op af et professionelt firma, så jeg går ikke ud fra at MSSQL serveren er sat forkert op... Det er jo nok højst sandsynlig et hardware problem vi har, eftersom der er sket meget på det sidste datamæssigt.

Men i skal i hvertfald ha' tak for jeres hjælp.

"venne" og "Arne_v" gider i ikke ligge et svar, så får i lige points...

//>Rune

Tror at det har med disk skrivningen at gøre

prøv at udkommentere sw.Write(txtData);
og så se hvor lang tid det tager 
så kan du se hvor lang tid det tager at læse data
og finder ud af om det er disk skrivningen der sløver det ned

Hej Lifo,

Det gjorde ingen forskel...

//>Rune

performance er ihvertfald en faktor 20-50 for lav !

kan du ikke få nogen til at checke den SQLServer ?

og svar fra mig

Hej Arne,

Nej, jeg kender ikke rigtig nogen der kan klare det job... - har du nogen ide til hvad jeg kunne gøre?

//>Rune

Jeg er enig med arne_v i at det er alt for langsomt. Enten er serveren for lille eller overbelastet, eller også må der være mange, mange millioner rækker i tabellen.
En reorganisering kunne måske også hjælpe.

venne> Der ER mange milioner records i tabellen, den er kæmpe stor... men på prøve at finde ud af en løsning.

I skal alle ha' mange tak for hjælpen!

//>Rune

Can you run the test at a time with low load on the system ?

If it still takes 3 minutes something is wrong.

Even with millions of rows.

The performance is equivalent to a hard IO per row. A cache hit rate of 0%.

That is statistically impossible.

You select on creation date. Many of theese rows should be close to each other.

If the database is accessed remotely, it could also be interesting to try and
run the test locally to see if the network is the bottleneck.