Welcome to Sign in | Help

Re: timeout expired

  •  11-18-2006, 5:48 AM

    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
View Complete Thread
Powered by Community Server (Commercial Edition), by Telligent Systems