Intrebari generale

Re: indecsi : dati-va si voi cu parerea

B_gd_n[ ]Sahlean — Mon, 05 Nov 2007 21:55:09 GMT

Cred ca gasesti raspunsul chiar in articolul respectiv:

"DMVs provide a level of transparency that was not available in SQL Server 2000 and can be used for diagnostics, memory and process tuning, and monitoring" .

Fragmente poti gasi in:

http://www.2shared.com/file/2464287/72fdc52a/sqlserver.html

http://www.sqlskills.com/blogs/paul/2007/10/05/IndexesFromEveryAngleHowCanYouTellIfAnIndexIsBeingUsed.aspx

http://www.mssqltips.com/tip.asp?tip=1359

http://www.mssqltips.com/tip.asp?tip=1196

http://www.mssqltips.com/tip.asp?tip=1014

http://www.databasejournal.com/features/mssql/print.php/3608296

http://www.sqlskills.com/blogs/paul/CategoryView,category,Indexes+From+Every+Angle.aspx

...

O prezentarea exhaustiva a solutiilor de optimizare poti gasi chiar in BOL din SQL Server 2000.

Ca fapt divers, de la adresa aceasta se poate copia o schema care include vederile (views) sistem din SQL Server 2005.

Re: indecsi : dati-va si voi cu parerea

MihaiBejenariu — Mon, 05 Nov 2007 16:32:04 GMT

xmldeveloper:
Daca folositi SQL Server 2005 cititi neaparat acest articol: http://blogs.msdn.com/sqlcat/archive/2006/02/13/531339.aspx

Super articolul.

BTW, cum s-ar face acelasi lucru in SQL Server 2000?

Re: indecsi : dati-va si voi cu parerea

Diana — Sat, 03 Nov 2007 17:13:04 GMT

liviu.costea:
Chiar am vrut sa ma uit la rapoarte (decat sa iau rezultatele la query, si sa le pun in csv ca sa pot cauta prin ele), dar nu imi apare optiunea "Reports". Nici in Tasks nu e. Eu am 2005 Developer Edition, poate in versiunea asta nu e sau poate mai trebuie ceva instalat.

Ai idee?

Ce - ti "intoarce" SERVERPROPERTY('ProductVersion') ?

Re: indecsi : dati-va si voi cu parerea

ggciubuc — Sat, 03 Nov 2007 12:29:12 GMT

liviu.costea:

Parerea mea e ca unul din indecsii astia doi e in plus, mai bine spus al doilea.

Legat de indexul pe 7 coloane : cred ca acestea fac parte dintr-un index cu optiunea include columns. Citez din books online :

Indexes that include nonkey columns provide the greatest benefit when they cover the query. This means the indexes include all columns referenced by the query. For more information see Index with Included Columns.

USE AdventureWorks;
GO
CREATE NONCLUSTERED INDEX IX_Address_PostalCode
ON Person.Address (PostalCode)
INCLUDE (AddressLine1, AddressLine2, City, StateProvinceID);
"

Re: indecsi : dati-va si voi cu parerea

liviu.costea — Fri, 02 Nov 2007 16:51:18 GMT

rsocol:

Ambii indecşi pot fi utili, la query-uri diferite. Mai precis, indexul nonclustered e util când faci o căutare după coloana datetime, fără sa ai nicio condiţie pe coloana int. Să luăm ca exemplu tabela Production.ProductCostHistory din AdventureWorks şi următoarele trei query-uri:

Da, ai dreptate, cu siguranta sunt cateva queri-uri care s-ar putea folosi de indexul asta. Si nu depinde numai de predicat(dupa StartDate) ci si de output, daca acele coloane care le selectez nu sunt in index probabil ca nu-l va ma folosi ca oricum trebuie sa treaca prin clustered.

Insa pot sa-mi dau seama daca am asemenea queri-uri care sa foloseasca indexul sau nu.

Folosind sys.dm_db_index_operational_stats am urmatorul rezultat pentru indexul asta: 0 reads si 13288 writes. Asta e tot ce vroiam.

Multumesc!

Re: indecsi : dati-va si voi cu parerea

liviu.costea — Fri, 02 Nov 2007 16:20:14 GMT

Diana:
Pe SQL 2005 exista si cateva rapoarte standard (la nivelul bazei de date) - cred ca te poate ajuta "Index Usage Statistics". Da "right-click" pe baza si alege Reports ---> Standard Reports. Rapoartele ofera datele din dynamic management views intr-o forma mai accesibila...

Chiar am vrut sa ma uit la rapoarte (decat sa iau rezultatele la query, si sa le pun in csv ca sa pot cauta prin ele), dar nu imi apare optiunea "Reports". Nici in Tasks nu e. Eu am 2005 Developer Edition, poate in versiunea asta nu e sau poate mai trebuie ceva instalat.

Ai idee?

Re: indecsi : dati-va si voi cu parerea

rsocol — Fri, 02 Nov 2007 16:00:57 GMT

Ambii indecşi pot fi utili, la query-uri diferite. Mai precis, indexul nonclustered e util când faci o căutare după coloana datetime, fără sa ai nicio condiţie pe coloana int. Să luăm ca exemplu tabela Production.ProductCostHistory din AdventureWorks şi următoarele trei query-uri:

SELECT COUNT(*) FROM Production.ProductCostHistory WHERE ProductID=708

SELECT COUNT(*) FROM Production.ProductCostHistory WHERE StartDate='20010701'

SELECT MAX(StartDate) FROM Production.ProductCostHistory

Pentru primul query se face Clustered Index Seek (şi are un cost total de 0.0032876), însă pentru al doilea query se face Clustered Index Scan (având un cost total de 0.0053128), pentru că avem nu avem condiţie pe prima coloană din index, iar pentru al treilea query face tot un Clustered Index Scan (costul fiind de 0.0054355). Dacă creăm şi un index non-clustered, pe aceleaşi coloane ca şi indexul clustered, dar în ordine inversă:

CREATE INDEX IX ON Production.ProductCostHistory (StartDate, ProductID)

Atunci şi al doilea query foloseşte un index seek, având astfel o performanţă mai bună (costul este acum 0.0034049). La al treilea query, aparent se face un Index Scan (pe noul index), dar observăm că de fapt e limitat cu un TOP 1, ceea ce îl face să fie la fel de performat ca un seek (costul total fiind 0.0032843).

Deci în cazul tău, problema se rezumă la a decide dacă pot exista query-uri care să pună condiţie doar pe coloana datetime, fără implica şi coloana int. Dacă există, atunci trebuie pus în balanţă beneficiul rezultat la asemenea interogări cu costul actualizării unui index suplimentar la adăugarea/actualizarea/ştergerea datelor din tabele. În cazul în care interogările sunt mult mai dese decât modificările, atunci probabil e mai bine să păstrăm indexul. Dacă modificările sunt foarte dese, atunci poate ar fi mai bine să renunţăm la el (dar chiar şi modificările pot beneficia de un index în cazul în care avem un UPDATE sau un DELETE care are o condiţie care implică acele coloane).

Răzvan

Re: indecsi : dati-va si voi cu parerea

Diana — Fri, 02 Nov 2007 15:25:06 GMT

Pe SQL 2005 exista si cateva rapoarte standard (la nivelul bazei de date) - cred ca te poate ajuta "Index Usage Statistics". Da "right-click" pe baza si alege Reports ---> Standard Reports. Rapoartele ofera datele din dynamic management views intr-o forma mai accesibila...

Re: indecsi : dati-va si voi cu parerea

liviu.costea — Fri, 02 Nov 2007 15:24:36 GMT

Da, e o idee buna sa ma uit la index usage, sa vad cat de mult a fost folosit indexul meu.

Mersi!

Re: indecsi : dati-va si voi cu parerea

liviu.costea — Fri, 02 Nov 2007 15:23:44 GMT

2005

Re: indecsi : dati-va si voi cu parerea

B_gd_n[ ]Sahlean — Fri, 02 Nov 2007 15:19:31 GMT

Liviu: ce versiune de SQL Server folosesti ?

Re: indecsi : dati-va si voi cu parerea

xmldeveloper — Fri, 02 Nov 2007 15:09:00 GMT

Daca folositi SQL Server 2005 cititi neaparat acest articol: http://blogs.msdn.com/sqlcat/archive/2006/02/13/531339.aspx

Va raspunde la intrebarea aduce un index mai mult overhead decat e utilizat?

Re: indecsi : dati-va si voi cu parerea

Diana — Fri, 02 Nov 2007 15:04:03 GMT

Cum e folosit tabelul -ce query - uri ruleaza in mod curent?

Incearca sa captezi un "trace" cu profiler - ul in timp ce se lucreaza pe tabel. Foloseste trace - ul ca workload pentru Database Engine Tuning Advisor (SQL 2005) / Index Tuning Wizard (SQL 2000) si vezi ce recomandari genereaza...

indecsi : dati-va si voi cu parerea

liviu.costea — Fri, 02 Nov 2007 14:32:38 GMT

Salut, am si eu o intrebare, daca puteti sa va dati cu parerea la urmatoarea situatie:

Faceam review la aplicatie si am gasit la o tabela urmatorii doi indecsi (tabela e foarte des folosita):

1. clustered pe 2 coloane: int si datetime (intul nu e identity), coloanele astea doua sunt si un alternate key

2. un index pe vreo 7 coloane, din care primele doua sunt aceleasi coloane de la primul index in ordine inversa. Cred ca celelalte 5 coloane is folosite ca output si nu in predicat.

Tabela are 10 coloane, dintre care o coloana e identity si PK.

Parerea mea e ca unul din indecsii astia doi e in plus, mai bine spus al doilea. Selectivitatea primelor doua coloane din index e foarte mare (de fapt e maxima), si cred ca se va folosi in mai toate cazurile indexul clustered. Chiar daca se va folosi indexul al doilea, faptul ca exclude doar 3 coloane din tabela nu salveaza mult IO fata de folosirea celui clustered.

Voi ce ziceti?