Tuesday, January 24, 2012

О влиянии наблюдателя на наблюдаемые являения

Сегодня делал небольшое исследование - сравнивал производительность двух серверов.
В частности, сделал такой самый простой тест, чтобы замерить скорость одного ядра: 

set timing on

create table test (
Client_ID    NUMBER,
NAME         Varchar2(3),
FAMILY       Varchar2(5),
DOLLARS      NUMBER,
PASSWORD     Varchar2(4),
BIRTHDAY        DATE
) tablespace users;

insert into test
select
   rownum ID,
   DBMS_RANDOM.STRING ('A',3),
   DBMS_RANDOM.STRING ('A',5),
   DBMS_RANDOM.VALUE (0,1000),
   DBMS_RANDOM.STRING ('X',4),
   SYSDATE-DBMS_RANDOM.VALUE (6000,30000)
from dual connect by rownum <= 1000000;

select sum(bytes)/1048576 from user_segments where segment_name='TEST';

SUM(BYTES)/1048576
------------------
                61

select count(*) from test;
select count(*) from test;
select count(*) from test;
select count(*) from test;


Табличка была целиком в памяти и время выполнения запроса стаблизировалось на цифре 10-20мс как на исходной так и второй системах:

SQL> set timing on
SQL> select count(*) from test;
select count(*) from test;
select count(*) from test;

  COUNT(*)
----------
   1000000

Elapsed: 00:00:00.03
SQL>
  COUNT(*)
----------
   1000000

Elapsed: 00:00:00.02
SQL>
  COUNT(*)
----------
   1000000

Elapsed: 00:00:00.01


Для того, чтобы повысить точность измерений решили включить трассировку и посмотреть время в микросекундах. После включения трассировки
alter session set events '10046 trace name context forever';
значения на обоих узлах стали 50-60мс:

PARSING IN CURSOR #139778252768168 len=25 dep=0 uid=84 oct=3 lid=84 tim=1327404119420870 hv=297253644 ad='2a99a2da8' sqlid='7b2twsn8vgfsc'
select count(*) from test
END OF STMT
PARSE #139778252768168:c=0,e=80,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1950795681,tim=1327404119420868
EXEC #139778252768168:c=0,e=30,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1950795681,tim=1327404119420975
FETCH #139778252768168:c=52992,e=54137,p=0,cr=7729,cu=1,mis=0,r=1,dep=0,og=1,plh=1950795681,tim=1327404119475172
STAT #139778252768168 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=7729 pr=0 pw=0 time=54134 us)'
STAT #139778252768168 id=2 cnt=1000000 pid=1 pos=1 obj=107338 op='TABLE ACCESS FULL TEST (cr=7729 pr=0 pw=0 time=75924 us cost=2093 size=0 card=1013983)'


Вот какое влияние оказывает трассировка на трассируемый процесс.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.

Does DEALLOCATE UNUSED or SHRINK SPACE will free space occupied by LOB segment?

Lets check how it works. My env is DB 19.20@Linux-x64 1) I created the table with 4 LOB columns of 4 different LOB types: BASICFILE BLOB, BA...