четверг, 30 мая 2013 г.

Секционирование таблиц в Oracle. Загадочное увеличение размера файлов данных. Часть 2

Пересоздал табличные пространства и таблицу, создав по умолчанию две секции (каждая из которых в свою очередь включает по 4 подсекции):
CREATE TABLESPACE OP_J_01 DATAFILE 'op_j_tbs01.dbf' SIZE 128K AUTOEXTEND ON NEXT 1K MAXSIZE UNLIMITED;
CREATE TABLESPACE OP_J_02 DATAFILE 'op_j_tbs02.dbf' SIZE 128K AUTOEXTEND ON NEXT 1K MAXSIZE UNLIMITED;
CREATE TABLESPACE OP_J_03 DATAFILE 'op_j_tbs03.dbf' SIZE 128K AUTOEXTEND ON NEXT 1K MAXSIZE UNLIMITED;
CREATE TABLESPACE OP_J_04 DATAFILE 'op_j_tbs04.dbf' SIZE 128K AUTOEXTEND ON NEXT 1K MAXSIZE UNLIMITED;
CREATE TABLE ZAKUPKI_DEV.OPERATION_JOURNAL_REDIF
   (    OP_JOURNAL_ID NUMBER(20,0) NOT NULL ENABLE,
        ORDER_ID NUMBER(20,0),
        TMSTMP TIMESTAMP (6),
        EVENT_CLASS VARCHAR2(50)

    )
PARTITION BY RANGE (TMSTMP) INTERVAL (NUMTOYMINTERVAL(1,'MONTH'))
  SUBPARTITION BY LIST (EVENT_CLASS)
  SUBPARTITION TEMPLATE
    (
    SUBPARTITION EC_REGISTER_CONTRACTS VALUES ('REGISTER_CONTRACTS') TABLESPACE OP_J_01,
    SUBPARTITION EC_ORDER VALUES ('ORDER') TABLESPACE OP_J_02,
    SUBPARTITION EC_AUTHORIZATION VALUES ('AUTHORIZATION') TABLESPACE OP_J_03,
    SUBPARTITION EC_OTHER VALUES (DEFAULT) TABLESPACE OP_J_04
    )
(PARTITION p201101 VALUES LESS THAN (TO_DATE('01012011','ddmmyyyy')),
 PARTITION p201102 VALUES LESS THAN (TO_DATE('01022011','ddmmyyyy'))
) ENABLE ROW MOVEMENT;

Смотрим размер файлов данных:
TABLESPACE_NAME BYTES USER_BYTES
OP_J_01 19005440 18939904
OP_J_02 19005440 18939904
OP_J_03 19005440 18939904
OP_J_04 19005440 18939904

А вот это уже интересно. Получается, на каждую субпартицию заранее резервируется место в табличном пространстве: на одну субпартицию 10МБ, на две 18МБ.
Для чистоты эксперимента проделал тоже самое, но с созданием трех секций:
TABLESPACE_NAME BYTES USER_BYTES
OP_J_01 27394048 27328512
OP_J_02 27394048 27328512
OP_J_03 27394048 27328512
OP_J_04 27394048 27328512
Т.е. на три секции требуется 26МБ на каждую субпартицию. Похоже, это и есть ответ на вопрос из предыдущего поста, почему размер файлов данных вырос до 43МБ.

В результате этих манипуляций возникло нелепое предположение: может быть такое, что независимо от количества данных в каждой партиции размер файлов данных увеличивается синхронно для всех? Проведем эксперимент:
Заново создаю файлы данных и таблицу с одной секцией по-умолчанию (всё как в первом посте), имею размер файлов данных 10616832 байт (~10МБ).
Вставляю в таблицу 383940 записей с EVENT_CLASS = 'ORDER' и tmstmp < TO_DATE('01012011', 'ddmmyyyy'), ожидая при этом, что увеличиться только файл данных, соответствующий табличному пространству EC_ORDER VALUES:
TABLESPACE_NAME BYTES USER_BYTES
OP_J_01 10616832 10551296
OP_J_02 19005440 18939904
OP_J_03 10616832 10551296
OP_J_04 10616832 10551296

Так и получается. При этом на самом деле был создан дополнительный экстент для сегмента, соответствующего субпартиции P201101_EC_ORDER.
Нелепое предположение осталось неподтвержденным и это прекрасно :)
Автор: на Комментариев нет:

среда, 29 мая 2013 г.

Секционирование таблиц в Oracle. Загадочное увеличение размера файлов данных

Выполнил следующий эксперимент:
Имею:
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production

Создаю 5 табличных пространств с минимальным допустимым размером и шагом увеличения:
CREATE TABLESPACE OP_J_01 DATAFILE 'op_j_tbs01.dbf' SIZE 128K AUTOEXTEND ON NEXT 1K MAXSIZE UNLIMITED;
CREATE TABLESPACE OP_J_02 DATAFILE 'op_j_tbs02.dbf' SIZE 128K AUTOEXTEND ON NEXT 1K MAXSIZE UNLIMITED;
CREATE TABLESPACE OP_J_03 DATAFILE 'op_j_tbs03.dbf' SIZE 128K AUTOEXTEND ON NEXT 1K MAXSIZE UNLIMITED;
CREATE TABLESPACE OP_J_04 DATAFILE 'op_j_tbs04.dbf' SIZE 128K AUTOEXTEND ON NEXT 1K MAXSIZE UNLIMITED;
CREATE TABLESPACE OP_J_05 DATAFILE 'op_j_tbs05.dbf' SIZE 128K AUTOEXTEND ON NEXT 1K MAXSIZE UNLIMITED;

Смотрю, что получилось:
SELECT tablespace_name, bytes, user_bytes FROM dba_data_files WHERE tablespace_name LIKE 'OP%' ORDER BY 1

TABLESPACE_NAME BYTES USER_BYTES
OP_J_01 131072 65536
OP_J_02 131072 65536
OP_J_03 131072 65536
OP_J_04 131072 65536
OP_J_05 131072 65536

Создаю секционированную таблицу:
CREATE TABLE OPERATION_JOURNAL_REDIF 
   (    OP_JOURNAL_ID NUMBER(20,0) NOT NULL ENABLE, 
        ORDER_ID NUMBER(20,0), 
        TMSTMP TIMESTAMP (6), 
        EVENT_CLASS VARCHAR2(50)
   ) 
PARTITION BY RANGE (TMSTMP) INTERVAL (NUMTOYMINTERVAL(1,'MONTH'))
  SUBPARTITION BY LIST (EVENT_CLASS)
  SUBPARTITION TEMPLATE
    (
    SUBPARTITION EC_REGISTER_CONTRACTS VALUES ('REGISTER_CONTRACTS') TABLESPACE OP_J_01, 
    SUBPARTITION EC_ORDER VALUES ('ORDER') TABLESPACE OP_J_02, 
    SUBPARTITION EC_AUTHORIZATION VALUES ('AUTHORIZATION') TABLESPACE OP_J_03, 
    SUBPARTITION EC_OTHER VALUES (DEFAULT) TABLESPACE OP_J_04
    )
(PARTITION p0 VALUES LESS THAN (TO_DATE('01012011','ddmmyyyy')))
TABLESPACE OP_J_05 ENABLE ROW MOVEMENT;

Снова смотрю на размеры файлов данных:

TABLESPACE_NAME BYTES USER_BYTES
OP_J_01 10616832 10551296
OP_J_02 10616832 10551296
OP_J_03 10616832 10551296
OP_J_04 10616832 10551296
OP_J_05 131072 65536

Файлы увеличились до 10МБ каждый. Initial_extent для всех созданных табличных пространств 65536. Почему тогда размер увеличен до 10МБ? Вопрос открытый, но дальше интересней.

Вставляю в таблицу 5000 записей с EVENT_CLASS = 'ORDER', ожидаю при этом, что все записи будут аккуратно сложены в табличное пространство OP_J_02, а значит в файл данных op_j_tbs02.dbf:
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (36310210,40186,to_timestamp('22.01.13 18:27:43,477000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (36310230,40185,to_timestamp('22.01.13 18:28:26,842000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (36664590,42822,to_timestamp('28.02.13 17:09:19,933000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (36664610,42822,to_timestamp('28.02.13 17:11:37,451000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (36664660,42805,to_timestamp('28.02.13 17:15:38,845000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (36664670,42805,to_timestamp('28.02.13 17:16:07,246000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (300089,9841,to_timestamp('17.02.11 03:46:55,749261000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (300150,9839,to_timestamp('12.10.10 13:39:50,158000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (36310540,40206,to_timestamp('22.01.13 18:36:27,250000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (36311360,40211,to_timestamp('22.01.13 18:48:02,011000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
...
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (350497,12338,to_timestamp('17.02.11 19:04:29,130000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (36430590,41221,to_timestamp('04.02.13 16:53:14,609000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (36430610,41221,to_timestamp('04.02.13 16:54:25,511000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (36805210,44327,to_timestamp('02.04.13 17:29:46,846000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (36805230,44325,to_timestamp('02.04.13 17:30:00,489000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (36805280,44333,to_timestamp('02.04.13 17:34:35,661000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (36805290,44333,to_timestamp('02.04.13 17:34:43,450000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (349921,11667,to_timestamp('17.02.11 11:52:51,472000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (349922,11327,to_timestamp('17.02.11 11:53:39,030000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
Insert into OPERATION_JOURNAL_REDIF (OP_JOURNAL_ID,ORDER_ID,TMSTMP,EVENT_CLASS) values (349923,12291,to_timestamp('17.02.11 11:54:07,633000000','DD.MM.RR HH24:MI:SS,FF'),'ORDER');
commit;

И снова смотрю размеры файлов данных:
TABLESPACE_NAME BYTES USER_BYTES
OP_J_01 45219840 45154304
OP_J_02 45219840 45154304
OP_J_03 45219840 45154304
OP_J_04 45219840 45154304
OP_J_05 131072 65536

Удивительно, но все файлы данных имеют размер 43МБ. Этому объяснения пока не нашел.
Автор: на Комментариев нет:
Подписаться на: Комментарии (Atom)