Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl→      все
 329 лямов - это много?  [new]
Myryan
Member

Откуда:
Сообщений: 11
 		Есть табличка на 329 лямов строк. Последнее время ощущается просадка в производительности.
В таблице происходит запись и чтение примерно в одинаковых пропорциях по времени. Запись происходит порциями, гораздо меньшими, чем чтение. Таблица без PK.
В соседнем треде http://www.sql.ru/forum/actualthread.aspx?bid=3&tid=733015&pg=1 пишут, что можно
применить партирование и секционирование. К сожалению я не разбирался так глубоко с ораклом и не
могу понять, что лучше будет в нашем случае. Буду благодарен любому совету по улучшению производительности! :)

CREATE TABLE "DEFGO"."ELEMENTS"
  (
    "ANSWER_ID" NUMBER(*,0) NOT NULL ENABLE,
    "NAME"      VARCHAR2(100 BYTE),
    "VALUE" CLOB,
    "ANSWER_ORDER"      NUMBER(*,0),
    "SCALE_ORDER"       NUMBER(*,0),
    "SCALE_GROUP_ORDER" NUMBER(*,0),
  )

Запрос простой, но их много, генерит их hibernate:
SELECT elements0_.answer_id    AS answer1_0_0_,
  elements0_.name              AS name0_,
  elements0_.value             AS value0_,
  elements0_.answer_order      AS answer4_0_,
  elements0_.scale_order       AS scale5_0_,
  elements0_.scale_group_order AS scale6_0_
FROM elements elements0_
WHERE elements0_.answer_id=?
22 фев 11, 11:34    [10272303]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
AmKad
Member

Откуда:
Сообщений: 3918
 		Myryan,

Создать индекс по ANSWER_ID.
22 фев 11, 11:45    [10272435]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
pravednik
Member

Откуда: Киев->Львов
Сообщений: 15589
 		Myryan,

какое распределение данных по elements0_.answer_id ?
22 фев 11, 11:47    [10272449]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
SQL*Plus
Member

Откуда: Россия, Москва
Сообщений: 6951
 		Выполните
SELECT  COUNT(*), COUNT(answer_id), COUNT(DISTINCT answer_id)
FROM elements 
WHERE ROWNUM <= 5E+06;
и покажите результат
22 фев 11, 11:48    [10272460]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 3754
 		А я бы стандартно предложил сделать trace 10046 проблемной сессии и выложить результат после обработки tkprof.
22 фев 11, 11:50    [10272486]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
tru55
Member

Откуда: СПб
Сообщений: 18260
 		Партицирование и секционирование - это одно и то же :)

Почитать - том доки под названием Data Warehousing Guide

Parallelism and Partitioning in Data Warehouses
22 фев 11, 11:52    [10272509]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
про_название
Guest 		"329 лямов" больше подходит про деньги.
не знаю, как кому, но для бд мне режет слух.
22 фев 11, 12:04    [10272642]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
Myryan
Member

Откуда:
Сообщений: 11
AmKad
Создать индекс по ANSWER_ID.

Есть такой:
CREATE INDEX "ELEMENTS_ID_IDX" ON "ELEMENTS"
  (
    "ANSWER_ID"
  )

автор
Выполните

SELECT COUNT(*), COUNT(answer_id), COUNT(DISTINCT answer_id)
FROM elements
WHERE ROWNUM <= 5E+06;

и покажите результат 


COUNT(*)               COUNT(ANSWER_ID)       COUNT(DISTINCT ANSWER_ID) 
---------------------- ---------------------- ------------------------ 
5000000                5000000                1926541

pravednik
какое распределение данных по elements0_.answer_id ?

Маппинг Answer 1 -- * Elements. То есть в таблице elements есть записи(среднее количество примерно 20),
которые принадлежат одному answer. Надеюсь я ответил на ваш вопрос. :)
22 фев 11, 12:23    [10272811]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
_Nikotin
Member

Откуда: СПб
Сообщений: 2801
SQL*Plus
SELECT  COUNT(*), COUNT(answer_id), COUNT(DISTINCT answer_id)
FROM elements 
WHERE ROWNUM <= 5E+06;

Всякое может быть, лучше:
SELECT  COUNT(*), COUNT(answer_id), COUNT(DISTINCT answer_id)
FROM elements sample (1.5);
22 фев 11, 12:24    [10272820]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
Myryan
Member

Откуда:
Сообщений: 11
wurdu
А я бы стандартно предложил сделать trace 10046 проблемной сессии и выложить результат после обработки tkprof.

Что-то заманчивое, можно поподробнее?
22 фев 11, 12:24    [10272824]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 3754
Myryan
wurdu
А я бы стандартно предложил сделать trace 10046 проблемной сессии и выложить результат после обработки tkprof.

Что-то заманчивое, можно поподробнее?
Как включить трассировку сессии?
Также можно с помощью DBMS_MONITOR.
22 фев 11, 12:35    [10272902]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
SQL*Plus
Member

Откуда: Россия, Москва
Сообщений: 6951
_Nikotin
SQL*Plus
SELECT  COUNT(*), COUNT(answer_id), COUNT(DISTINCT answer_id)
FROM elements 
WHERE ROWNUM <= 5E+06;

Всякое может быть, лучше:
SELECT  COUNT(*), COUNT(answer_id), COUNT(DISTINCT answer_id)
FROM elements sample (1.5);
Можно и так...
22 фев 11, 12:37    [10272919]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
SQL*Plus
Member

Откуда: Россия, Москва
Сообщений: 6951
Myryan
pravednik
какое распределение данных по elements0_.answer_id ?

Маппинг Answer 1 -- * Elements. То есть в таблице elements есть записи(среднее количество примерно 20),
которые принадлежат одному answer. Надеюсь я ответил на ваш вопрос. :)

А что выдаёт предложенный _Nikotin запрос?
_Nikotin
SELECT  COUNT(*), COUNT(answer_id), COUNT(DISTINCT answer_id)
FROM elements sample (1.5);
22 фев 11, 12:41    [10272950]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
SQL*Plus
Member

Откуда: Россия, Москва
Сообщений: 6951
Myryan
Маппинг Answer 1 -- * Elements. То есть в таблице elements есть записи(среднее количество примерно 20),
которые принадлежат одному answer. Надеюсь я ответил на ваш вопрос. :)
То есть ANSWER - это Master, а ELEMENTS - это Details...

Выполните
SELECT * FROM v$version;
и покажите результат.
22 фев 11, 12:49    [10273025]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
Myryan
Member

Откуда:
Сообщений: 11
_Nikotin
SELECT  COUNT(*), COUNT(answer_id), COUNT(DISTINCT answer_id)
FROM elements sample (1.5);


COUNT(*)               COUNT(ANSWER_ID)       COUNT(DISTINCTANSWER_ID) 
---------------------- ---------------------- ------------------------ 
4932971                4932971                4733876


SQL*Plus
SELECT * FROM v$version;


Oracle Database 10g Release 10.2.0.1.0 - Production              
PL/SQL Release 10.2.0.1.0 - Production                           
CORE	10.2.0.1.0	Production                                         
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production          
NLSRTL Version 10.2.0.1.0 - Production
22 фев 11, 14:28    [10273939]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
SQL*Plus
Member

Откуда: Россия, Москва
Сообщений: 6951
Myryan
Oracle Database 10g Release 10.2.0.1.0 - Production              
PL/SQL Release 10.2.0.1.0 - Production                           
CORE	10.2.0.1.0	Production                                         
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production          
NLSRTL Version 10.2.0.1.0 - Production
У вас Oracle Database Standard Edition, поэтому с секционированием у вас ничего не получится, так как его там нет.
Partitioning - это опция (платная) Oracle Database Enterprise Edition.

По возможности чаще перестраивайте индекс "ELEMENTS_ID_IDX", думайте о переносе неиспользуемых записей в архив и т.п.

P.S. Возможно, уже наступает время для перевода вашей системы на Oracle Database Enterprise Edition...
Обсудите это с вашим руководством.
22 фев 11, 15:00    [10274226]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
Myryan
Member

Откуда:
Сообщений: 11
 		SQL*Plus,

спасибо за советы. Будем думать.
22 фев 11, 15:16    [10274354]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
Alexander Anokhin
Member

Откуда: Moscow
Сообщений: 394
 		Myryan,
из того что ты привел абсолютно не следует какой-либо необходимости в партиционировании.

Из тех приведенных тобой данных следует что у индекса отличная селективность.
Из первого примера 0,00000052 из второго 0,00000021
Понятно, что это средние показатели (плюс взятые только из порции данных) проблемный запрос может выбирать самое скошенное значение.

Ключ ко всему в том, что ты считаешь просадками в производительности.
В чем они заключаются? Чего ждет в это время база?
Происходят ли они во время чтения данных или записи?
Часто ли удаляются ли из таблицы данные?
22 фев 11, 15:52    [10274607]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 1858
 		Интересно, каким путём здесь поможет секционирование?

Индекс по полю ANSWER_ID всё равно будет глобальным - грубо говоря, скорость поиска не изменится. Что мы хотели бы получить:

a) записи с одинаковым ANSWER_ID лежали бы "близко" друг от друга (например, в одном и том же блоке, если они туда вмещаются), чтобы уменьшить количество чтений. Кластеризация по ANSWER_ID, короче.
и/или
b) наиболее часто запрашиваемые данные лежали "близко" друг от друга (здесь речь идёт уже о множестве ANSWER_ID, по которым идут запросы от приложения, в какую-то единицу времени), чтобы повысить эффективность кеширования (конечно, при этом необходимо выделить достаточно памяти).

Поэтому надо понять, как лежат данные. Возможно, партишионирование здесь бесполезно. Например, предположим, что
1) для данного ANSWER_ID происходит вставка всех записей сразу;
2) в тот же день происходит один или несколько запросов для этого ANSWER_ID, а в следущие дни вероятность обращения к этим данным уже очень мала, практически 0;
3) данные только добавляют, не удаляют;

тогда пожелания a) и b) уже выполнены.

Если не так, то секционирование всё равно не панацея. Например, не выполняется a), хотите принудить. Делать 16 миллионов секций? Если делать крупные секции, то это не поможет кластеризации, а если мелкие - таблица может резко вырасти в размерах. Для b) не хватает данных в таблице.
22 фев 11, 15:52    [10274615]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
Timur Akhmadeev
Member

Откуда:
Сообщений: 457
SQL*Plus
По возможности чаще перестраивайте индекс "ELEMENTS_ID_IDX"

Какой в этом смысл?

Myryan,

не надо ребилдить индекс по чем зря. Снимите статспак репорт с базы данных во время работы вашего приложения и закиньте его куда-нибудь. См. %ORACLE_HOME%\rdbms\admin\spdoc.txt.
22 фев 11, 15:57    [10274652]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
Myryan
Member

Откуда:
Сообщений: 11
Alexander Anokhin
Myryan,
из того что ты привел абсолютно не следует какой-либо необходимости в партиционировании.

Из тех приведенных тобой данных следует что у индекса отличная селективность.
Из первого примера 0,00000052 из второго 0,00000021
Понятно, что это средние показатели (плюс взятые только из порции данных) проблемный запрос может выбирать самое скошенное значение.

Ключ ко всему в том, что ты считаешь просадками в производительности.
В чем они заключаются? Чего ждет в это время база?
Происходят ли они во время чтения данных или записи?
Часто ли удаляются ли из таблицы данные?


В системе медленнее стали извлекаться данные(запись - это не критично) для построения всевозможных отчетов.
Замедленнее заметно не только "на глаз", но и по логам, если подсчитать количество запросов в сек., которые генерит hibernate. Но это локально. На продакшене опять же можно определить "на глаз" или посмотреть по логам, но только время начала создания и конца генерации отчета. Что интеерсно, если подключиться на продакшен базу с локального компа, то выборка происходит быстрее, так что может и не в базе вопрос.
Чего ждет база.... если б я знал. Есть вариант как-то это посмотреть?
Как я уже говорил медленее стало именно извлечение данных. Это не сиюминутное явление. То есть месяц назад система работала реально быстрее. Опять же может быть вопрос и не в базе, ибо недавно не продакшен был поставлен большой релиз.
Данные из таблицы не удаляются никогда. Возможно нам есть смысл пересмотреть содрежимое базы и удалить очень старые данные, но это вопрос к начальству, а они пока занимают консервативную позицию.
22 фев 11, 16:30    [10274871]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
Myryan
Member

Откуда:
Сообщений: 11
Timur Akhmadeev
не надо ребилдить индекс по чем зря. Снимите статспак репорт с базы данных во время работы вашего приложения и закиньте его куда-нибудь. См. %ORACLE_HOME%\rdbms\admin\spdoc.txt.


Я спрошу админа, что б он предоставил данные.
22 фев 11, 16:31    [10274879]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
SQL*Plus
Member

Откуда: Россия, Москва
Сообщений: 6951
Timur Akhmadeev
SQL*Plus
По возможности чаще перестраивайте индекс "ELEMENTS_ID_IDX"

Какой в этом смысл?
Из общих соображений. Периодически улучшать возможно ухудшающуюся структуру индекса...

Timur Akhmadeev
не надо ребилдить индекс по чем зря. Снимите статспак репорт с базы данных во время работы вашего приложения и закиньте его куда-нибудь. См. %ORACLE_HOME%\rdbms\admin\spdoc.txt.
Совершенно согласен!
22 фев 11, 16:35    [10274905]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
Timur Akhmadeev
Member

Откуда:
Сообщений: 457
SQL*Plus
Из общих соображений. Периодически улучшать возможно ухудшающуюся структуру индекса...

Как именно структура balanced tree индекса может теоретически ухудшаться?
22 фев 11, 17:11    [10275166]     Ответить | Цитировать    Сообщить модератору
 Re: 329 лямов - это много?  [new]
andreymx
Member

Откуда: Запорожье
Сообщений: 20723
Myryan
В системе медленнее стали извлекаться данные(запись - это не критично) для построения всевозможных отчетов.
приведите пару запросов для медленных отчетов
22 фев 11, 17:43    [10275397]     Ответить | Цитировать    Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl→      все
Все форумы / Oracle Ответить