powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Перенос огромных таблиц
25 сообщений из 28, страница 1 из 2
Перенос огромных таблиц
    #39602237
Ребят посоветуйте пожалуйста ! Есть у меня пару больших таблиц в базе около 120 млн строк . Если я их партицирую и перенесу в отдельное табличное пространство не скажеться ли это на производительности ? Так как будет основное табличное пространство и мое котороя я создам . Не будет ли оракл тормозить от того что ему прийдеться обращаться в другой таблспейс ?
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602241
Евгения Зайцева,

зависит от....
производительности дискового массива, на котором будет лежать "твоё" табличное пространство. Если там одношпендельный диск на 5400 оборотов - то производительность просядет. Если нормальные производительный дисковый массив, то ораклу всё равно сколько у него ТП - два или одно. Медленнее он работать не станет.

Я бы про секционирование больше беспокоился. Ляжет ли оно на режим использования таблицы и характерные запросы, работающие по ней....
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602242
merch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Евгения Зайцева, если ты хочешь, чтобы все начало тормозить - положи партиции на медленный диск.
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602260
Добрый Э - ЭхЕвгения Зайцева,

зависит от....
производительности дискового массива, на котором будет лежать "твоё" табличное пространство. Если там одношпендельный диск на 5400 оборотов - то производительность просядет. Если нормальные производительный дисковый массив, то ораклу всё равно сколько у него ТП - два или одно. Медленнее он работать не станет.

Я бы про секционирование больше беспокоился. Ляжет ли оно на режим использования таблицы и характерные запросы, работающие по ней....
Я как понимаю что партицировав таблицу по дате (по этим таблицам всегда в 95% случаев идет запрос по датам) я выграю в скорости . так как оракл будет брать отдельно по партициям . Хотя есть уже парьтицированная таблица по дате "date_added" и я не вижу в плане запроса использование партиции .. только индекс
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
SELECT p.* from payment p where p.s_id=465 and p.date_added BETWEEN sysdate-3 AND SYSDATE and p.amount >0 and p.status=-1

-----------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                     | Rows | Bytes | Cost | Time     |
-----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                          |   28 |  6216 |  311 | 00:00:04 |
| * 1 |   FILTER                              |                          |      |       |      |          |
| * 2 |    TABLE ACCESS BY GLOBAL INDEX ROWID | PAYMENT                  |   28 |  6216 |  311 | 00:00:04 |
| * 3 |     INDEX SKIP SCAN                   | I_DILL_ID                |    1 |       |  269 | 00:00:04 |
-----------------------------------------------------------------------------------------------------------


но если указываю партицию в запросе то он пишет что взял партицию
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
select * from payment PARTITION (P201801) where service_id=465 and p.added > sysdate-3  and amount >0 and payment_status=-1


------------------------------------------------------------------------------
| Id  | Operation                 | Name    | Rows | Bytes | Cost | Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT          |         |  402 | 88842 | 2667 | 00:00:33 |
| * 1 |   FILTER                  |         |      |       |      |          |
|   2 |    PARTITION RANGE SINGLE |         |  402 | 88842 | 2667 | 00:00:33 |
| * 3 |     TABLE ACCESS FULL     | PAYMENT |  402 | 88842 | 2667 | 00:00:33 |
------------------------------------------------------------------------------


Но почему в 1 случае когда я указываю date_added береться не партиция а индекс . Может мне оракл не пишет просто и все нормально ?
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602273
Евгения Зайцева,

в секции какой интервал дат попадает? а сколько записей выбирается по отдельно взятому p.s_id ?

Ты же сама видишь по планам, что оракл решил, исходя из статистики, что по отдельному p.s_id дешевле достать данные через глобальный индекс, чем полным сканированием отдельной секции...
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602281
Добрый Э - ЭхЕвгения Зайцева,

в секции какой интервал дат попадает? а сколько записей выбирается по отдельно взятому p.s_id ?

Ты же сама видишь по планам, что оракл решил, исходя из статистики, что по отдельному p.s_id дешевле достать данные через глобальный индекс, чем полным сканированием отдельной секции...
В секции за последние 3 дня ...
Может мне попробовать поубирать глобальные индексы и оставить только локальные для каждой партиции.чтобы сначала оракл брал партицию и в ней уже искал по индексам.
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602290
Евгения Зайцева,

судя по названию, секция содержит данные за месяц, а не за последние три дня.
Так сколько строк попадает в одну секцию? сколько из них будет принадлежать выбранному ID? А сколько в таблице всего строк с выбранным ID?
Секционирование - инструмент сложный. Как и у всякого инструмента - у него есть своя область применения, свои минусы и плюсы. Я потому и спрашивал - какие цели преследуются именно секционированием? Повышение производительности запросов за счет партишн прунинга? Облегчение манипуляций с историческими данными за счет работы в пределах секции с заведомо меньшим объемом, чем вся таблица? Или же у тебя секционирование - ради самого секционирования?
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602301
Фотография Stax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Евгения Зайцева,

для теста попробуйте напр так
SELECT p.* from payment p where p.s_id+1=465+1 and p.date_added BETWEEN sysdate-3 AND SYSDATE and p.amount >0 and p.status=-1

зи
задача убрать индекс, выражение ид+1 можно усложнить напр nvl,trunc,decode тощо
....
stax
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602302
Фотография Stax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добрый Э - Эх,

в древних версиях партиции были за отдельную плату, тож стимул использовать

.....
stax
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602314
StaxДобрый Э - Эх,

в древних версиях партиции были за отдельную плату, тож стимул использовать

.....
staxдля начала бы разобраться - нужно ли секционирование, и если нужно, то для чего? возможно выяснится, что ТС пытается "забивать гвозди микроскопом", не понимаю, что для этого есть "молоток".... Стоимость микроскопа в сравнении со стоимостью молотка пока оставим за рамками беседы...
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602326
Фотография Stax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добрый Э - ЭхStaxДобрый Э - Эх,

в древних версиях партиции были за отдельную плату, тож стимул использовать

.....
staxдля начала бы разобраться - нужно ли секционирование, и если нужно, то для чего? возможно выяснится, что ТС пытается "забивать гвозди микроскопом", не понимаю, что для этого есть "молоток".... Стоимость микроскопа в сравнении со стоимостью молотка пока оставим за рамками беседы...
а вот ето Вы зря отбрасываете, в Украине очень часто "выгодно" прибрести микроскоп, как-нибудь да пристоем (разберемся)

.....
stax
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602327
Добрый Э - ЭхЕвгения Зайцева,

судя по названию, секция содержит данные за месяц, а не за последние три дня.
Так сколько строк попадает в одну секцию? сколько из них будет принадлежать выбранному ID? А сколько в таблице всего строк с выбранным ID?
Секционирование - инструмент сложный. Как и у всякого инструмента - у него есть своя область применения, свои минусы и плюсы. Я потому и спрашивал - какие цели преследуются именно секционированием? Повышение производительности запросов за счет партишн прунинга? Облегчение манипуляций с историческими данными за счет работы в пределах секции с заведомо меньшим объемом, чем вся таблица? Или же у тебя секционирование - ради самого секционирования?
Нужно повысить скорость работы таблицы. я думаю что если таблицу разбить по партициям . А индексы сделать локально для партиции. Но как быть с первичными ключами тогда... по которым всегда есть глобальный индекс.
1) Партиции разбиты за месяц
2) около 50 т строк
3) каждая строка уникально по id . все таблица 50 млн строк. (в партиции около 400 т строк)
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602350
Хотя если в проекте будут запросы без указания дат то это уже не вариант будет просматривать каждая партиция...
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602398
Фотография Stax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Евгения ЗайцеваХотя если в проекте будут запросы без указания дат то это уже не вариант будет просматривать каждая партиция...
как раз вариант, если у вас много процов

імхо
партиции нужны
1) расспаралеливание
2) исторические данные

....
stax
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602551
Евгения ЗайцеваНо почему в 1 случае когда я указываю date_added береться не партиция а индекс . Может мне оракл не пишет просто и все нормально ?
Патамушта взять одну строку по глобальному индексу даже скип-сканом оказалось дешевле, чем просканить несколько разделов в поиске этой единственной.
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602913
Индекс-глобалистЕвгения ЗайцеваНо почему в 1 случае когда я указываю date_added береться не партиция а индекс . Может мне оракл не пишет просто и все нормально ?
Патамушта взять одну строку по глобальному индексу даже скип-сканом оказалось дешевле, чем просканить несколько разделов в поиске этой единственной.
я считаю что не так . Это потому что используеться обычные глобальные индексы и партицирование как само по себе не работает . и Его даже в плане запроса нету. Как только я переделала на партицированные индексы глобальные и локальные план стал нормальным и работать стало намного быстрее. Если я ошибаюсь отпишите пож.
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602917
просто были построены глобальные несекционированными на партицированную таблицу . И получался бред. Таблица партицирована но партиции не учитавались а шел запрос как по обычной таблице ..
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602922
Евгения Зайцева,

ну что тебе отписать?
сумбурно говоришь, коды не показываешь.
если в результате тебя всё устроило - то мы рады за тебя :)
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602937
Спасибо вам ребят на самом деле вы очень помогли разобрать что и как происходит . Дай вам бог всем крепкого здоровья !
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39602968
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Евгения ЗайцеваИндекс-глобалистпропущено...

Патамушта взять одну строку по глобальному индексу даже скип-сканом оказалось дешевле, чем просканить несколько разделов в поиске этой единственной.
я считаю что не так . Это потому что используеться обычные глобальные индексы и партицирование как само по себе не работает .
...
Если я ошибаюсь отпишите пож.
Ошибаетесь.
У сервера был выбор между двумя (или более) путями доступа:
- по глобальному индексу
- FTS

С учетом предиката (строгое равенство на уникальный атрибут) заход по глобальному индексу требовал (грубо, тут есть ньюансы в зависимости от параметров табличного пространства) прочитать 2-3 блока индекса и один блок из таблицы. Если посмотрите внимательно на план, то увидите, что этот метод доступа предусматривает заход в единственную секцию (P_START, P_STOP в плане имеют значение ROWID, ROWID) - т.е. partition pruning ВЫПОЛНЯЕТСЯ, но не так, как Вы ожидали.

Заход FTS требовал вычитать и отфильтровать несколько секций таблицы, это туева хуча работы в сравнении с заходом по глобальному индексу в данных конкретных условиях.
Потому был выбран заход по индексу и из него в таблицу по ROWID.

Создав локальный индекс, Вы добавили серверу размышлений - заходить partition range iterator в локальный индекс или FTS или заходить в глобальный индекс.
Убрав глобальный индекс, Вы не оставили серверу вариантов - pruning стал возможным только посредством partition iterator.
И это - тадааам - для данного конкретного запроса может быть МЕНЕЕ эффективно, чем заход через глобальный индекс.
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39603051
andrey_anonymousЕвгения Зайцевапропущено...

я считаю что не так . Это потому что используеться обычные глобальные индексы и партицирование как само по себе не работает .
...
Если я ошибаюсь отпишите пож.
Ошибаетесь.
У сервера был выбор между двумя (или более) путями доступа:
- по глобальному индексу
- FTS

С учетом предиката (строгое равенство на уникальный атрибут) заход по глобальному индексу требовал (грубо, тут есть ньюансы в зависимости от параметров табличного пространства) прочитать 2-3 блока индекса и один блок из таблицы. Если посмотрите внимательно на план, то увидите, что этот метод доступа предусматривает заход в единственную секцию (P_START, P_STOP в плане имеют значение ROWID, ROWID) - т.е. partition pruning ВЫПОЛНЯЕТСЯ, но не так, как Вы ожидали.

Заход FTS требовал вычитать и отфильтровать несколько секций таблицы, это туева хуча работы в сравнении с заходом по глобальному индексу в данных конкретных условиях.
Потому был выбран заход по индексу и из него в таблицу по ROWID.

Создав локальный индекс, Вы добавили серверу размышлений - заходить partition range iterator в локальный индекс или FTS или заходить в глобальный индекс.
Убрав глобальный индекс, Вы не оставили серверу вариантов - pruning стал возможным только посредством partition iterator.
И это - тадааам - для данного конкретного запроса может быть МЕНЕЕ эффективно, чем заход через глобальный индекс.

Реньше было куча насозданных таким индексов по партицированной таблице. Это как я понимаю просто несекционированный индекс и потому оракл
партиции не использовал а выбирал данные по нему
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
create index I_BlablaID on PAYMENT (bla_id DESC)
  tablespace BlaBla
  pctfree 10
  initrans 2
  maxtrans 255
  storage
  (
    initial 64K
    next 1M
    minextents 1
    maxextents unlimited
  )
  nologging;
 


но у партицированных таблиц как я понимаю есть еще секционированные локальные и глобальные индексы уже по партициям
. Так вот я и сделала вывод что в 1 случае выбор идет просто по индексу а партиции не используются и в плане их нету.
В чем различия тогда? Проще как я понимаю выбрать сначала по заданной партиции и в ней уже искать данные.
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39603102
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Евгения ЗайцеваЭто как я понимаю просто несекционированный индекс [/src]
Для более адекватного понимания - ознакомьтесь с видами индексов для секционированной таблицы:
https://docs.oracle.com/database/121/VLDBG/GUID-EE0A6FF8-50BB-4D9D-A7EB-E9FF9DCBEE06.htm#VLDBG00203

Евгения Зайцеваи потому оракл
партиции не использовал
...
а партиции не используются и в плане их нету.
В чем различия тогда? Проще как я понимаю выбрать сначала по заданной партиции и в ней уже искать данные.

Чукча не читатель...

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
create table dropme_t (id, dt)
partition by range(dt)
(partition pdec2017 values less than (date'2018-01-01')
,partition pjan2018 values less than (date'2018-02-01')
,partition pfeb2018 values less than (date'2018-03-01')
)
as
select to_number(reverse(to_char(rownum,'fm9999999999999999999999'))), date'2018-02-01'-30+mod(rownum,40) from dual connect by level < 100000
;
Table created

create index dropme_t$glb$nprfx_id on dropme_t(id); -- global non-prefixed index

Index created

explain plan for select * from dropme_t where id = :1 and dt > :2;
Explained

select * from table(dbms_xplan.display(format => 'ALL'));
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 3965172464
----------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name                  | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                   |                       |    45 |   990 |    77   (0)| 00:00:01 |       |       |
|*  1 |  TABLE ACCESS BY GLOBAL INDEX ROWID| DROPME_T              |    45 |   990 |    77   (0)| 00:00:01 | ROWID | ROWID |
|*  2 |   INDEX RANGE SCAN                 | DROPME_T$GLB$NPRFX_ID |   357 |       |     1   (0)| 00:00:01 |       |       |
----------------------------------------------------------------------------------------------------------------------------
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
   1 - SEL$1 / DROPME_T@SEL$1
   2 - SEL$1 / DROPME_T@SEL$1
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("DT">:2)
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
   2 - access("ID"=TO_NUMBER(:1))
Column Projection Information (identified by operation id):
-----------------------------------------------------------
   1 - "ID"[NUMBER,22], "DT"[DATE,7]
   2 - "DROPME_T".ROWID[ROWID,10], "ID"[NUMBER,22]
Note
-----
   - dynamic sampling used for this statement (level=2)
31 rows selected

-- А теперь изменим предикат:
explain plan for select * from dropme_t where id = 18 and dt > :2;
Explained

select * from table(dbms_xplan.display(format => 'ALL'));
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 1604903573
-----------------------------------------------------------------------------------------------------
| Id  | Operation                | Name     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
-----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT         |          |  4461 | 98142 |    79   (2)| 00:00:01 |       |       |
|   1 |  PARTITION RANGE ITERATOR|          |  4461 | 98142 |    79   (2)| 00:00:01 |   KEY |     3 |
|*  2 |   TABLE ACCESS FULL      | DROPME_T |  4461 | 98142 |    79   (2)| 00:00:01 |   KEY |     3 |
-----------------------------------------------------------------------------------------------------
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
   1 - SEL$1
   2 - SEL$1 / DROPME_T@SEL$1
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("ID">=18 AND "DT">:2)
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Column Projection Information (identified by operation id):
-----------------------------------------------------------
   1 - "ID"[NUMBER,22], "DT"[DATE,7]
   2 - "ID"[NUMBER,22], "DT"[DATE,7]
Note
-----
   - dynamic sampling used for this statement (level=2)
30 rows selected
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39603107
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Прошу прощения - ошибся при форматировании. Читать в редакции:
andrey_anonymous
Код: plsql
1.
2.
-- А теперь изменим предикат:
explain plan for select * from dropme_t where id >= 18 and dt > :2;
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39603166
andrey_anonymousПрошу прощения - ошибся при форматировании. Читать в редакции:
andrey_anonymous
Код: plsql
1.
2.
-- А теперь изменим предикат:
explain plan for select * from dropme_t where id >= 18 and dt > :2;



а если я использую такой запрос
Код: plsql
1.
select * from dropme_t WHERE  dt > to_date('12.01.2018','DD.MM.YYYY');


То есть как я поняла оракл сам решает как ему быстрее обратиться по партиции или по индексу в зависимости от написаного тобой селекта. А я сделала принудительно чтобы он использовал партицирование ....
...
Рейтинг: 0 / 0
Перенос огромных таблиц
    #39603169
Евгения Зайцеваandrey_anonymousПрошу прощения - ошибся при форматировании. Читать в редакции:
пропущено...


а если я использую такой запрос
Код: plsql
1.
select * from dropme_t WHERE  dt > to_date('12.01.2018','DD.MM.YYYY');


То есть как я поняла оракл сам решает как ему быстрее обратиться по партиции или по индексу в зависимости от написаного тобой селекта. А я сделала принудительно чтобы он использовал партицирование ....
Но работать стало быстрее . Наверно мне повезло =)
...
Рейтинг: 0 / 0
25 сообщений из 28, страница 1 из 2
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Перенос огромных таблиц
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]