Производительность табличных переменных на сервере SQL 2008 R2 с включенным TDE - PullRequest
Новая
       17

Производительность табличных переменных на сервере SQL 2008 R2 с включенным TDE

0 голосов
/ 20 января 2012

У меня следующая ситуация: у меня есть выпуск SQL 2008 R2 Enterprise, где я включил шифрование TDE в одной из баз данных.Одна из хранимых процедур из зашифрованной базы данных использует табличную переменную (@ t1), таблицу, которая заполняется почти 600К-записями.Затем есть оператор выбора, который использует соединение между этой таблицей и другой таблицей из зашифрованной базы данных (t2), в таблицах t2 у меня около 20 миллионов строк.Это соединение длится вечно (последний раз занял почти 4 часа).Если я использую вместо табличной переменной временную таблицу (# t3) и сделаю то же самое соединение, результат будет мгновенным.Кроме того, если я запускаю объединение между этими двумя таблицами на другом сервере, где у меня нет шифрования TDE (тот же SQL 2008 R2), объединение завершается за считанные секунды. Кто-нибудь сталкивался с подобными проблемами с переменными таблиц и зашифрованными базами данных, использующими TDE?Вот как я зашифровал базу данных: 

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'AASFA234234234as234#234#$##$'

CREATE CERTIFICATE SQLCertificate
WITH SUBJECT = 'SQL Certificate',
EXPIRY_DATE = '10/31/2020';

USE DBTest
go

CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE SQLCertificate;

ALTER DATABASE DBTest
SET ENCRYPTION ON
And this is the script that I used where _rptHousehold is a table that has 18mil records. The script never gets to the PRINT '3 ' + CONVERT(VARCHAR,GETDATE(),121), hangs on the select count(*) from @tt
PRINT '1 ' + CONVERT(VARCHAR,GETDATE(),121)

IF object_id('tempdb..#tt') IS NOT NULL 
    DROP TABLE #tt


declare  @tt table
(   [id] int        IDENTITY(1,1), 
    TableID         DECIMAL(11,0),
    AdvisorID       INT,
    idBuild         INT,
    Tablename       sysname,
    tCreatedate     datetime,
    ColumnName      varchar(100),
    Column_ID       int,
    qtyValue        decimal(25,9),
    tModifiedDate   datetime
)

INSERT INTO @tt
(TableID , AdvisorID , idBuild,Tablename,   tCreatedate,ColumnName, Column_ID,qtyValue )            
select  TOP 600000 
    t.object_ID
    ,AdvisorID
    ,1635
    ,t.NAME
    ,t.Create_date
    ,c.Name
    ,c.object_ID    
    ,CAST(RAND()* 100000 AS DECIMAL(25,9))
FROM sys.tables t CROSS JOIN sys.columns c  
    CROSS JOIN (SELECT DISTINCT idAdvisor AS AdvisorID FROM dbo._rptHousehold WHERE idBuild = 1635) ac              


PRINT '2 ' + CONVERT(VARCHAR,GETDATE(),121)

SELECT COUNT(*) FROM @tt 
PRINT '3 ' + CONVERT(VARCHAR,GETDATE(),121)

UPDATE tt
    SET 
        qtyValue = rp.qtyAvgPAAssets
FROM @tt tt 
    JOIN _rptHousehold rp
        ON rp.idAdvisor= tt.AdvisorID
            AND rp.idBuild= tt.idBuild

PRINT '4 ' + CONVERT(VARCHAR,GETDATE(),121)

1 Ответ

1 голос
/ 20 января 2012

Ну, я не думаю, что он напрямую связан с TDE, поскольку TDE шифрует данные, когда они записываются на диск, и дешифрует их, когда они читаются с диска, а служебные данные, как говорят, не так велики (<10%).</p>

  • возможно, на новом сервере данные не кэшируются в ОЗУ, поэтому их нужно читать с диска (конечно, в этом случае TDE делает это немного медленнее).
  • это такРекомендую использовать временные таблицы вместо табличных переменных, если у вас есть много строк для работы.
  • много других причин, почему они не работают так же хорошо, как раньше - я бы начал с проверки плана выполнения ..
...