Deci e varchar(36), asa ca wtf se aplica

Deci e uniqueidentifier sau varchar(36) ?

Exista o singura idee si un singur sfat: masoara, nu ghicii. De unde stii ca dimensiunea cheii este problema? Masoara, masoara si iar masoara.Ia un query din cele de zeci de secunde si ruleaza-l din SSMS. Seteaza SET STATISTICS IO ON si vezi ce logical reads are, pe ce rowset. Sint zeci sau sute? De la mii in sus in mod sigur faci scan nu seek. ...

OK ca idee generala cind tu sau altcineva da peste o astfel de problema: primul lucru, masori. In SQL 2000 exista sysprocesses, in 2K5 exista sys.dm_exec_requests . Te uiti si vezi de ce sint blocate query-urile. Te uiti in blocking_session_id, in wait_type si last_wait_type si la wait_resource. In 99% din cazuri te prinzi imediat care-i problema. ...

Banuiesc ca te referi de fapt la interogarea mai multor event log-uri, nu viewere. Poti folosi batrinul Eventquery.pl sau WMI. Pentru WMI exista nenumarate scripuri pe net.

ignatandrei: cu caching de 10 minute pe date... ;-) apropos, explica si ce e cachingul asta si cum functioneaza

De unde stii? Mult mai probabil tu ai drept sa vezi 3 BD-uri din cele citeva mii.

Pai nu ai o instanta de SQL a ta, dedicata. E shared, si o gramada de clienti ai providerului de hosting or accesseze aceasi instanta, fiecare i-si vede doar baza lui de date. La citeva mii de baze de date hostuite, citeva sute de conexiuni pe minut nici nu-i mult.

Pai atit de repede cite hituri sint la clienti care share-uiesc instant * numarul de conexiuni pe hit. Hostingul nu e dedicat, e?Iar daca portul T-SQL este cumva expus la internet, adaugi si numarul de boti din RBNet care scaneaza 1433.

Este un server hostuit care face sharing la instanta (ie. ai db-ul ta, dar instanta este shared)? @@connections intoarce numarul total de evenimente login de cind a pornit serverul (instanta) si atunci nu e nici minune ca ajunge la 500k intr-un mediu shared.