Problem sa performansama privremene tabele

[ Jpeca @ 12.06.2011. 16:40 ] @

Imam store proceduru koja se koristi za kreiranje nekavog izveštaja za određeni period i vrstu osiguranja (kuća,auto). U proceduri se prvo kreira privermena tabela, pa se onda na osnovu te privrmene tabele i drugih povezanih tabela i pogleda formira lista za izveštaj.

Kad zamenim privremenu tabele sa tabelom-promenljvom vreme kreiranje tabele se značajno produži.
Privremena tabela #relevantrisk

Code:
CREATE TABLE #relevantrisk (pk int,[Channel] varchar(50), [Sub-Channel] varchar(50),
                                                  PaymentMethod varchar(50), [Name] varchar(250), HistoryActionType nvarchar(50), TransEffDate datetime, IPTPercent real )
INSERT INTO #relevantrisk (
    pk,
    Channel,
   [Sub-Channel],
    PaymentMethod,
   [Name],
   HistoryActionType,
   TransEffDate,
   IPTPercent)
SELECT ...
...
DROP TABLE #relevantrisk

Vrsta osiguranja Period Slogova Select (s) Vreme kreiranja tabele (s)
Home 01-05 do 11-05 133 21 21
Home 01-05 do 31-05 317 23 37
Motor 01-05 do 11-05 120 21 25

Tabela promenljiva @relevantrisk

Code:
DECLARE @relevantrisk table (pk int,[Channel] varchar(50), [Sub-Channel] varchar(50),
                                              paymentmethod varchar(50), [Name] varchar(250), HistoryActionType nvarchar(50), TransEffDate datetime, IPTPercent real )
INSERT INTO @relevantrisk (
    pk,
    Channel,
   [Sub-Channel],
    PaymentMethod,
   [Name],
   HistoryActionType,
   TransEffDate,
   IPTPercent)
SELECT ...

Vrsta osiguranja Period Slogova Select (s) Vreme kreiranja tabele (s)
Home 01-05 do 11-05 133 21 161
Home 01-05 do 11-05 317 23 470
Motor 01-05 do 11-05 120 21 520

Prema onome što ja znam trebalo bi da su perfomanse bolje za tabelu-promenljivu. Upit koji sledi na osnovu tabele jeste duplo brži u slučaju tabele-promenjljive ali to nije dovoljno da nadoknadi vreme utrošeno prilikom kreiranja. Da li ima neko objašnjenje? Nisam još imao prilike da bazu prebacim na drugo okruženje i da probam. U SELECT upitu uspostavlja se veza sa bazom na drugom serveru.

[ Koce @ 13.06.2011. 08:39 ] @

Sta ce ti dati bolje performance, @ ili # tabela zavisi od vise faktora a ponajvise od velicine tabele. Takodje, vrlo je bitno da znas da @ tabele nemaju statistike, tako da ako imas veliku tabelu i nekoliko transformacija, upita nad njom, koristi temp tabelu, i to tako sto ces joj pri kreiranju napraviti i clusterovan index po odgovarajucim kolonama. Ne znam da li sam te dobro shvatio, ali tebi je najveci problem punjenje te tabele, i to sa nekog drugog servera? Pogledaj da tu ne lezi problem, ili pusti exec plan nad telom procedure pa vidi gde trosi najvise resursa.