Welcome to Sign in | Help
in Search

timeout expired

Last post 11-18-2006, 11:29 AM by MrSmersh. 5 replies.
Sort Posts: Previous Next
  •  11-16-2006, 2:36 PM 894

    timeout expired

    Cand lucrez pe o baza mare in Sql Server , la selectia sau uneori si la stergerea unor date, salvate de obicei in proceduri stocate si executate din  aplicatie .NET, primesc

    Timeout Expired or server...

    Am citit ca ar trebui sa maresc proprietatea Timeout a obiectului SqlCommand in care preiau procedura, sau sa pun chiar 0, pentru timp nelimitat

    le-am facut pe amandoua, insa tot nu am scapat de aceasta eroare.

    Am incercat si sa mai optimizez fie query-ul ,fie indexari, insa la anumite query-uri nu am optiuni sa modific altfel pentru ca nu iese ceea ce imi cer clientii, si deci pot avea iar surpriza la timeout...

    Care ar putea fi solutia(solutiile) pentru eroarea asta?

     

    Va multumesc anticipat
     

    Filed under:
  •  11-16-2006, 4:07 PM 896 in reply to 894

    Re: timeout expired

    Alte posibile solutii:

    • adaugati in connection string - Connection Timeout = 0
    • Din Enterprise Manager - Right Click pe server - selectati Properties iar in tab-ul Connections setati Query Timeout pe 0.

    Cristian Andrei Lefter, SQL Server MVP
    MCT, MCSA, MCDBA, MCAD, MCSD .NET,
    MCTS, MCITP - Database Administrator SQL Server 2005
    http://sqlserver.ro
  •  11-17-2006, 1:06 AM 903 in reply to 894

    Re: timeout expired

    .Net 1.1 sau .Net 2.0?
    In 1.1 SqlCommand.CommandTimeout setat la 0 nu functioneaza correct (http://support.microsoft.com/kb/887126), seteaza-l la o valoare mare, gen32000.

    Numai de bine,
    ~ Remus


    http://rusanu.com
  •  11-17-2006, 9:45 AM 907 in reply to 894

    Re: timeout expired

    Salut

    Am vazut ca tu incerci sa stergi date dintr-o tabela foarte mare. recomandarile mele sunt urmatoarele:

    1. Nu stergi din tabela daca tabela este mare. asta pentru ca tu stergi informatiile si serverul incepe sa refaca indexes-i (banuiesc ca ai asa ceva pentru tabela respectiva) si chestia asta ia timp.

    2. Daca esti nevoi sa stergi din tabela respectiva, marcheaza cumva inregistrarile ce trebuiesc sterse si apoi cand serverul nu este accesat (noaptea de preferat), ruleaza un job care sa stearga pt tine. Nu uita orice stergere, necesita refacerea indexes-ilor

    Plus ca am vazut in unele carti ca "NU se recomanda stergerea informatiilor din tabele bazei de date, asta pentru a conferi consistenta informatiilor stocate".

    Cu respect.....



     

  •  11-18-2006, 5:48 AM 921 in reply to 907

    Re: timeout expired

    1. Nu stergi din tabela daca tabela este mare. asta pentru ca tu stergi informatiile si serverul incepe sa refaca indexes-i (banuiesc ca ai asa ceva pentru tabela respectiva) si chestia asta ia timp.

    Orice fel de operatii DML (insert, update, delete) pe un index (tabela==index) pot duce in timp la fragmentarea indexului. SQL Server nu va reorganiza indexi in background sau inline ca urmare a operatii DML. Pentru a reorganiza un index administratorul trebuie sa ruleze o comanda explicita (DBCC DBREINDEX sau DBCC INDEXDEFRAG in SQL 2000, ALTER INDEX in SQL 2005). O tratare exhaustiva a subiectului poate fi gasita in whitepaper-ul 'Microsoft SQL Server 2000 Index Defragmentation Best Practices' la http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx. Pentru SQL 2005 BOL acopera subiectul destul de pe larg: http://msdn2.microsoft.com/en-us/library/ms189858.aspx

     Ce trebuie inteles e ca reorganizarea indexisor este o operatiune rara si administrativa. O aplicatie, chiar una care sterge in mod curent portiuni largi dintr-un index, nu trebuie sa se preocupe de asta.

    2. Daca esti nevoi sa stergi din tabela respectiva, marcheaza cumva inregistrarile ce trebuiesc sterse si apoi cand serverul nu este accesat (noaptea de preferat), ruleaza un job care sa stearga pt tine. Nu uita orice stergere, necesita refacerea indexes-ilor

    Aceasta este o practica extrem de daunatoare. Sa zicem ca adaugam o coloana [deleted] cu valori posibile 0 sau 1. Programatorii aplicatiei sint siliti sa adauge la toate query-urile o clauza 'WHERE [deleted] = 0', rezultind intr-un impact sever in dezvoltare. Toate query-urile de update/delete autogenerate (e.g. DataSet table adapter) trebuiesc modificate sa faca un UPDATE in loc de DELETE. Fara sa mentionam impactul asupra oricarei aplicatzii third-party, care probabil va trebuii sa accesseze datele prin view-uri care sa mascheze recordurile 'sterse'.

    Dar cel mai sever impact este la run-time, pentru ca acuma toate query-urile au de a face cu un predicat care are selectivitate 50% (orice record poate fi [deleted] 0 sau 1)!! Trebuiesc scanate in medie dublu numarul de pagini, query-optimizer-ul nu mai poate fi liber sa aleaga orice index (si chiar daca decidem sa adaugam [deleted] in toti indexi, din nou el ofera doar 2 valori posibile, deci nu ajuta cu nimic), si cam orice index seek va fi transformat in planul de access intr-un index scan (cu implicatziile de rigoare in ce join-uri pot fi alese etc etc)

    Plus ca am vazut in unele carti ca "NU se recomanda stergerea informatiilor din tabele bazei de date, asta pentru a conferi consistenta informatiilor stocate".

    Ce carte scrie asa ceva? Autorul este cuma un vendor de solutzii de stocare cumva? Banuiesc ca Quantum sau Western Digital ar avea interes sa scrie asa ceva intr-o carte Smile

     Daca datele trebuiesc sterse, atuncea sa fie sterse. Ghostwriter-ul exista in server pentru un motiv intemeiat...


    http://rusanu.com
  •  11-18-2006, 11:29 AM 923 in reply to 921

    Re: timeout expired

    Si zici ceva si nu zici....
    Cazul in care datele trebuie auditate, la stergere fizica e mult mai stufos....
    Sa spunem ca ezista cazuri cind o sa faci asa si altele cind nu.
View as RSS news feed in XML
Powered by Community Server (Commercial Edition), by Telligent Systems