Performance – Tablespaces Cifrados

Na sequência do post anterior sobre performance associada a tablespaces cifrados e sobre a minha afirmação que provavelmente causaria “overhead” ao nível do CPU segue uma exemplificação com factos (e gráficos).

 

Cenário 1:

Iremos capturar um trace na qual será criada uma tabela nova no tablespace cifrado e outra no tablespace
não cifrado que basicamente contem 2 vezes (union all) uma tabela criada anteriormente (encripted_t1/not_encripted_t1) em que somamos +10 e -10 à coluna R1.
Estas duas tabelas, encripted_t1 e not_encripted_t1 foram criadas nos tablespaces cifrados e não cifrados respectivamente, cada uma com  2 milhões de números aleatórios de 0 a 500. Optei por não descrever o processo todo aqui pois ficaria demasiado extenso e assim está dada a explicação.

Resumindo:

  • Tabela encripted_t1 tablespace TL_LUIS2 – Cifrado
  • Tabela not_encripted_t1 tablespace TL_LUIS1 – Não Cifrado

Avançado, criaremos como citei anteriormente mais duas tabelas que irão ler às tabelas de origem (encripted_t1/not_encripted_t1) e aplicar uma pequena operação matemática só para garantir que o processo não é apenas transpor valores.


SQL> create table encripted_t2 (R1 number) tablespace TL_LUIS2;

Table created.

SQL> create table not_encripted_t2 (R1 number) tablespace TL_LUIS1;

Table created.

SQL> alter system set timed_statistics = true;

System altered.

SQL> alter session set sql_trace=true;

Session altered.


SQL> insert into encripted_t2(select R1+10 from encripted_t1 union all select R1-100 from encripted_t1);
4000000 rows created.


SQL> insert into not_encripted_t2(select R1+10 from not_encripted_t1 union all select R1-100 from not_encripted_t1);
4000000 rows created.

[oracle@localhost trace]$ tkprof testSID_s000_4475.trc /home/oracle/testSID_not_encripted2.out

explain=lmarques/******@TESTSID table=sys.plan_table;

 

O resultado do TKPROF será apresentado no fim para melhor compreensão e facilidade na comparação.

Statistics tabela encripted_t2:


Statistics
----------------------------------------------------------
4979 recursive calls
139032 db block gets
53526 consistent gets
14985 physical reads
134787456 redo size
874 bytes sent via SQL*Net to client
857 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
46 sorts (memory)
0 sorts (disk)
4000000 rows processed


Statistics tabela not_encripted_t2:

Statistics
----------------------------------------------------------
4000 recursive calls
139272 db block gets
52262 consistent gets
15024 physical reads
134918704 redo size
874 bytes sent via SQL*Net to client
869 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
44 sorts (memory)
0 sorts (disk)
4000000 rows processed



SQL ID: f2n9j11bbxydr
Plan Hash: 3198889629
insert into encripted_t2(select R1+10 from encripted_t1 union all select
R1-100 from encripted_t1)



call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 2 0 0
Execute 1 6.37 20.59 14666 45252 138930 4000000
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 6.37 20.59 14666 45254 138930 4000000

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 88 (LMARQUES)



SQL ID: gztwdmabp772k
Plan Hash: 88491625
insert into not_encripted_t2(select R1+10 from not_encripted_t1 union all select R1-100 from not_encripted_t1)



call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 1 2 0 0
Execute 1 3.28 17.68 14770 44148 139172 4000000
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 3.29 17.68 14771 44150 139172 4000000

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 88 (LMARQUES)

Cenário 2:

Consiste em fazer update de todos os registos presentes em ambas as tabelas e anotar os valores do tkprof.

SQL> update encripted_t2 set R1 = R1 * dbms_random.value(1,10);

4000000 rows updated.

SQL> update not_encripted_t2 set R1 = R1 * dbms_random.value(1,10);

4000000 rows updated.


SQL ID: bm4knsf1u98dr
Plan Hash: 1830589931
update encripted_t2 set R1 = R1 * dbms_random.value(1,10)



call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 1 0 0
Execute 1 108.74 189.55 15145 15191 8196634 4000000
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 108.74 189.55 15145 15192 8196634 4000000

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 88 (LMARQUES)

SQL ID: 5vkqdztx2pnkr
Plan Hash: 1328674292
update not_encripted_t2 set R1 = R1 * dbms_random.value(1,10)

:q!

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 2 0.01 0.04 2 3 0 0
Execute 2 76.30 122.23 30586 45786 8199891 4000000
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 76.32 122.27 30588 45789 8199891 4000000

Misses in library cache during parse: 2
Optimizer mode: ALL_ROWS
Parsing user id: 88 (LMARQUES)

Cenário 3:

Depois de duas operações de INSERT/UPDATE, o cenário 3 pretende mostrar o valor máximo e minimo em ambas as
tabelas tal como o somatório. Esta operação ser
á essencialmente para vermos a diferença na fase de Fetch:

 


SQL> select max(R1), min(R1), sum(R1) from encripted_t2;

MAX(R1) MIN(R1) SUM(R1)
---------- ---------- ----------
5094.91688 -999.48332 4509438225



SQL> select max(R1), min(R1), sum(R1) from not_encripted_t2;

MAX(R1) MIN(R1) SUM(R1)
---------- ---------- ----------
5098.34983 -999.03228 4509256192


SQL ID: c2nduhuvxdb21
Plan Hash: 2411346477
select max(R1), min(R1), sum(R1)
from
encripted_t2


call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 1 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 2.44 4.21 14931 29690 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 2.44 4.21 14931 29691 0 1

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 88 (LMARQUES)


SQL ID: 9anun28tghg2v
Plan Hash: 3679694188
select max(R1), min(R1), sum(R1)
from
not_encripted_t2


call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 1 1 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.76 1.26 11555 30226 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 0.76 1.26 11556 30227 0 1

Conclusões Gráficas:

 

CPU Time (Menor é Melhor): Uma notória diferença em todos os cenários, com o valor do CPU Time a ser praticamente o dobro em operações de INSERT e  30% maior em operações de UPDATE.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Elapsed Time (Menor é Melhor): Uma notória diferença em todos os cenários também. O Elapsed é o tempo total decorrido em segundos, como consequência da soma das 3 fases (Parse+Execute+Fetch). Além da notória diferença na operação de SELECT, no DML UPDATE demorou mais 35.5% do tempo a completar o UPDATE.

 


Disk (Menor é Melhor): Representa o physical read.  Solta a vista a disparidade de valores na operação de UPDATE, onde a tabela não cifrada lê mais 49.5% dos buffers do disco para fazer o respectivo update. Parece um valor sem sentido dado que não há razão aparente para isso acontecer. Como tal, mais investigação é necessária aqui.

 

 

PS: Decidi usar a expressão Cifrado/Não cifrado em vez de encriptado/não encriptado a pedido de várias famílias.

 

Advertisements

2 thoughts on “Performance – Tablespaces Cifrados

  1. good one!Era gira ver isso numa máquina física com CPU Intel com hardware support para AES, para ver se tinha algum impacto substancial.Outra aproximação que seria interessante ver seria a adopção de criptografia ao nível do filesystem para avaliar o impacto na performance…

  2. Viva Francisco,Os testes foram feitos em VMs como tal, nao sei de que forma o vmware implementa ou não o AES, mas é uma boa questão para outro dia de analises :)Em relação à encriptação do filesystem, é menos selectiva que a presente no Oracle sendo possivel encriptar apenas determinadas colunas nas tabelas, por exemplo. Algo que do ponto de vista do filesystem é impossivel. A razão prende-se de tal como aqui foi demonstrado o overhead no CPU (e consequentemente no tempo total) é bastante considerável e como tal esta feature deve ser aplicada selectivamente.Do ponto de vista de performance, era interessante colocar um datafile no filesystem encriptado (dm-crypt+luks por exemplo) fazer os mesmos testes e comparar resultados.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s