|
|
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Ребят посоветуйте пожалуйста ! Есть у меня пару больших таблиц в базе около 120 млн строк . Если я их партицирую и перенесу в отдельное табличное пространство не скажеться ли это на производительности ? Так как будет основное табличное пространство и мое котороя я создам . Не будет ли оракл тормозить от того что ему прийдеться обращаться в другой таблспейс ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2018, 11:53 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Евгения Зайцева, зависит от.... производительности дискового массива, на котором будет лежать "твоё" табличное пространство. Если там одношпендельный диск на 5400 оборотов - то производительность просядет. Если нормальные производительный дисковый массив, то ораклу всё равно сколько у него ТП - два или одно. Медленнее он работать не станет. Я бы про секционирование больше беспокоился. Ляжет ли оно на режим использования таблицы и характерные запросы, работающие по ней.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2018, 12:02 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Евгения Зайцева, если ты хочешь, чтобы все начало тормозить - положи партиции на медленный диск. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2018, 12:02 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Добрый Э - ЭхЕвгения Зайцева, зависит от.... производительности дискового массива, на котором будет лежать "твоё" табличное пространство. Если там одношпендельный диск на 5400 оборотов - то производительность просядет. Если нормальные производительный дисковый массив, то ораклу всё равно сколько у него ТП - два или одно. Медленнее он работать не станет. Я бы про секционирование больше беспокоился. Ляжет ли оно на режим использования таблицы и характерные запросы, работающие по ней.... Я как понимаю что партицировав таблицу по дате (по этим таблицам всегда в 95% случаев идет запрос по датам) я выграю в скорости . так как оракл будет брать отдельно по партициям . Хотя есть уже парьтицированная таблица по дате "date_added" и я не вижу в плане запроса использование партиции .. только индекс Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. но если указываю партицию в запросе то он пишет что взял партицию Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Но почему в 1 случае когда я указываю date_added береться не партиция а индекс . Может мне оракл не пишет просто и все нормально ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2018, 12:36 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Евгения Зайцева, в секции какой интервал дат попадает? а сколько записей выбирается по отдельно взятому p.s_id ? Ты же сама видишь по планам, что оракл решил, исходя из статистики, что по отдельному p.s_id дешевле достать данные через глобальный индекс, чем полным сканированием отдельной секции... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2018, 12:57 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Добрый Э - ЭхЕвгения Зайцева, в секции какой интервал дат попадает? а сколько записей выбирается по отдельно взятому p.s_id ? Ты же сама видишь по планам, что оракл решил, исходя из статистики, что по отдельному p.s_id дешевле достать данные через глобальный индекс, чем полным сканированием отдельной секции... В секции за последние 3 дня ... Может мне попробовать поубирать глобальные индексы и оставить только локальные для каждой партиции.чтобы сначала оракл брал партицию и в ней уже искал по индексам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2018, 13:12 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Евгения Зайцева, судя по названию, секция содержит данные за месяц, а не за последние три дня. Так сколько строк попадает в одну секцию? сколько из них будет принадлежать выбранному ID? А сколько в таблице всего строк с выбранным ID? Секционирование - инструмент сложный. Как и у всякого инструмента - у него есть своя область применения, свои минусы и плюсы. Я потому и спрашивал - какие цели преследуются именно секционированием? Повышение производительности запросов за счет партишн прунинга? Облегчение манипуляций с историческими данными за счет работы в пределах секции с заведомо меньшим объемом, чем вся таблица? Или же у тебя секционирование - ради самого секционирования? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2018, 13:21 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Евгения Зайцева, для теста попробуйте напр так 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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2018, 13:29 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Добрый Э - Эх, в древних версиях партиции были за отдельную плату, тож стимул использовать ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2018, 13:32 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
StaxДобрый Э - Эх, в древних версиях партиции были за отдельную плату, тож стимул использовать ..... staxдля начала бы разобраться - нужно ли секционирование, и если нужно, то для чего? возможно выяснится, что ТС пытается "забивать гвозди микроскопом", не понимаю, что для этого есть "молоток".... Стоимость микроскопа в сравнении со стоимостью молотка пока оставим за рамками беседы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2018, 13:40 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Добрый Э - ЭхStaxДобрый Э - Эх, в древних версиях партиции были за отдельную плату, тож стимул использовать ..... staxдля начала бы разобраться - нужно ли секционирование, и если нужно, то для чего? возможно выяснится, что ТС пытается "забивать гвозди микроскопом", не понимаю, что для этого есть "молоток".... Стоимость микроскопа в сравнении со стоимостью молотка пока оставим за рамками беседы... а вот ето Вы зря отбрасываете, в Украине очень часто "выгодно" прибрести микроскоп, как-нибудь да пристоем (разберемся) ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2018, 13:48 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Добрый Э - ЭхЕвгения Зайцева, судя по названию, секция содержит данные за месяц, а не за последние три дня. Так сколько строк попадает в одну секцию? сколько из них будет принадлежать выбранному ID? А сколько в таблице всего строк с выбранным ID? Секционирование - инструмент сложный. Как и у всякого инструмента - у него есть своя область применения, свои минусы и плюсы. Я потому и спрашивал - какие цели преследуются именно секционированием? Повышение производительности запросов за счет партишн прунинга? Облегчение манипуляций с историческими данными за счет работы в пределах секции с заведомо меньшим объемом, чем вся таблица? Или же у тебя секционирование - ради самого секционирования? Нужно повысить скорость работы таблицы. я думаю что если таблицу разбить по партициям . А индексы сделать локально для партиции. Но как быть с первичными ключами тогда... по которым всегда есть глобальный индекс. 1) Партиции разбиты за месяц 2) около 50 т строк 3) каждая строка уникально по id . все таблица 50 млн строк. (в партиции около 400 т строк) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2018, 13:49 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Хотя если в проекте будут запросы без указания дат то это уже не вариант будет просматривать каждая партиция... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2018, 14:07 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Евгения ЗайцеваХотя если в проекте будут запросы без указания дат то это уже не вариант будет просматривать каждая партиция... как раз вариант, если у вас много процов імхо партиции нужны 1) расспаралеливание 2) исторические данные .... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2018, 14:41 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Евгения ЗайцеваНо почему в 1 случае когда я указываю date_added береться не партиция а индекс . Может мне оракл не пишет просто и все нормально ? Патамушта взять одну строку по глобальному индексу даже скип-сканом оказалось дешевле, чем просканить несколько разделов в поиске этой единственной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2018, 17:47 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Индекс-глобалистЕвгения ЗайцеваНо почему в 1 случае когда я указываю date_added береться не партиция а индекс . Может мне оракл не пишет просто и все нормально ? Патамушта взять одну строку по глобальному индексу даже скип-сканом оказалось дешевле, чем просканить несколько разделов в поиске этой единственной. я считаю что не так . Это потому что используеться обычные глобальные индексы и партицирование как само по себе не работает . и Его даже в плане запроса нету. Как только я переделала на партицированные индексы глобальные и локальные план стал нормальным и работать стало намного быстрее. Если я ошибаюсь отпишите пож. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2018, 13:13 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
просто были построены глобальные несекционированными на партицированную таблицу . И получался бред. Таблица партицирована но партиции не учитавались а шел запрос как по обычной таблице .. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2018, 13:17 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Евгения Зайцева, ну что тебе отписать? сумбурно говоришь, коды не показываешь. если в результате тебя всё устроило - то мы рады за тебя :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2018, 13:22 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Спасибо вам ребят на самом деле вы очень помогли разобрать что и как происходит . Дай вам бог всем крепкого здоровья ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2018, 13:38 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Евгения ЗайцеваИндекс-глобалистпропущено... Патамушта взять одну строку по глобальному индексу даже скип-сканом оказалось дешевле, чем просканить несколько разделов в поиске этой единственной. я считаю что не так . Это потому что используеться обычные глобальные индексы и партицирование как само по себе не работает . ... Если я ошибаюсь отпишите пож. Ошибаетесь. У сервера был выбор между двумя (или более) путями доступа: - по глобальному индексу - FTS С учетом предиката (строгое равенство на уникальный атрибут) заход по глобальному индексу требовал (грубо, тут есть ньюансы в зависимости от параметров табличного пространства) прочитать 2-3 блока индекса и один блок из таблицы. Если посмотрите внимательно на план, то увидите, что этот метод доступа предусматривает заход в единственную секцию (P_START, P_STOP в плане имеют значение ROWID, ROWID) - т.е. partition pruning ВЫПОЛНЯЕТСЯ, но не так, как Вы ожидали. Заход FTS требовал вычитать и отфильтровать несколько секций таблицы, это туева хуча работы в сравнении с заходом по глобальному индексу в данных конкретных условиях. Потому был выбран заход по индексу и из него в таблицу по ROWID. Создав локальный индекс, Вы добавили серверу размышлений - заходить partition range iterator в локальный индекс или FTS или заходить в глобальный индекс. Убрав глобальный индекс, Вы не оставили серверу вариантов - pruning стал возможным только посредством partition iterator. И это - тадааам - для данного конкретного запроса может быть МЕНЕЕ эффективно, чем заход через глобальный индекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2018, 14:01 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
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. но у партицированных таблиц как я понимаю есть еще секционированные локальные и глобальные индексы уже по партициям . Так вот я и сделала вывод что в 1 случае выбор идет просто по индексу а партиции не используются и в плане их нету. В чем различия тогда? Проще как я понимаю выбрать сначала по заданной партиции и в ней уже искать данные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2018, 15:15 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Евгения ЗайцеваЭто как я понимаю просто несекционированный индекс [/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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2018, 15:41 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Прошу прощения - ошибся при форматировании. Читать в редакции: andrey_anonymous Код: plsql 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2018, 15:44 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousПрошу прощения - ошибся при форматировании. Читать в редакции: andrey_anonymous Код: plsql 1. 2. а если я использую такой запрос Код: plsql 1. То есть как я поняла оракл сам решает как ему быстрее обратиться по партиции или по индексу в зависимости от написаного тобой селекта. А я сделала принудительно чтобы он использовал партицирование .... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2018, 16:23 |
|
||
|
Перенос огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Евгения Зайцеваandrey_anonymousПрошу прощения - ошибся при форматировании. Читать в редакции: пропущено... а если я использую такой запрос Код: plsql 1. То есть как я поняла оракл сам решает как ему быстрее обратиться по партиции или по индексу в зависимости от написаного тобой селекта. А я сделала принудительно чтобы он использовал партицирование .... Но работать стало быстрее . Наверно мне повезло =) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2018, 16:23 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39602314&tid=1884419]: |
0ms |
get settings: |
5ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
40ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
| others: | 204ms |
| total: | 338ms |

| 0 / 0 |
