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

Откуда: Київ
Сообщений: 113
Написал запрос , в результате получил - "ORA-01652: unable to extend temp segment by 128 in tablespace ...". так как я пишу только отчеты, у меня доступ к тестовой среде, и ограничены права доступа к БД, почитал доку по этой ошибке и попросил выгрузить этот отчет, только изначально необходимо расширить ТЕМР. Ответили что это может быть "крахом" для продуктива системы, соответственно никто ничего делать не будет... Мне интересно, это действительно так чревато для системы? Если да, то не пойму, в чем соль системы, которая не может отработать запрос в котором один join и один подзапрос, инфо тянется меньше чем с 2-х десятков таблиц ??...
26 июн 12, 01:39    [12773982]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Добавление место в темп не может привести к краху. Но если бы, например, меня попросили добавить место в темп для какого-то отчета, я бы предложил для начала разобраться с этим запросом. Возможно такой темп ему нужен из-за неоптимального плана, неверного выбора порядка соединений таблиц. А когда в запросе 20 таблиц - это запросто.
26 июн 12, 01:48    [12773994]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
Edward Shevtsov
Member

Откуда: Moscow
Сообщений: 13469
Liubomyr
Написал запрос , в результате получил - "ORA-01652: unable to extend temp segment by 128 in tablespace ...". так как я пишу только отчеты, у меня доступ к тестовой среде, и ограничены права доступа к БД, почитал доку по этой ошибке и попросил выгрузить этот отчет, только изначально необходимо расширить ТЕМР. Ответили что это может быть "крахом" для продуктива системы, соответственно никто ничего делать не будет... Мне интересно, это действительно так чревато для системы? Если да, то не пойму, в чем соль системы, которая не может отработать запрос в котором один join и один подзапрос, инфо тянется меньше чем с 2-х десятков таблиц ??...
твои пожелания должны быть подкреплены чем-то большим, чем простая констатация факта ошибки. Посмотри, сколько пр-ва в ТЕМП и насколько оправдано то, что твой запрос пожирает десятки мегабайт на диске. 20 таблиц в одном запросе - это просто перебор. Админы правы.
26 июн 12, 02:02    [12774009]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
Liubomyr
Member

Откуда: Київ
Сообщений: 113
20 таблиц, это не перебор, сама БД ооочень огромная, и необходимы сложные аналитические отчеты... Спасибо за розяснение, попробую поработать над оптимизацией ...
26 июн 12, 08:09    [12774217]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
Liubomyr
Member

Откуда: Київ
Сообщений: 113
wurdu, Edward Shevtsov,
Все никак не получается оптимизировать отчет( Применил все рекомендации по оптимизации о которых знал - минимум join-ов, последовательность условий у where, применил конструкцию with as ... Порекомендуйте что нибудь. Можно ли индексировать такие запросы? И как это лучше всего сделать? Вот сам скрипт:
WITH T1 AS (SELECT DISTINCT prha.segment1 AS REQ_NUMBER, 
PRDA.DISTRIBUTION_ID AS IDEE, 
PRLA.LINE_NUM AS LINE, 
PRLA.ITEM_DESCRIPTION AS LINE_DESCR, 
NVL(PRLA.QUANTITY, 1) AS QUANT, 
NVL(PRLA.UNIT_PRICE, 1) AS PRICE, 
(PRLA.UNIT_PRICE * PRLA.QUANTITY) AS SUMM, 
FC.CURRENCY_CODE AS CURRENCY, 
GCC.segment2 AS COSTCENTR_NUMB, 
tl.description AS COSTCENTR_DESCR, 
GCC.segment3 AS COST_ITEM, 
TL2.DESCRIPTION AS COST_ITEM_DESCR, 
PRDA.CREATION_DATE AS CREATION_DATE, 
PRHA.AUTHORIZATION_STATUS AS STATUS, 
PRHA.APPROVED_DATE AS APP_DATE, 
PAPF.FULL_NAME AS PREPARER_name, 
PAPFFF.FULL_NAME as Last_appr 
FROM PO_REQUISITION_HEADERS_ALL PRHA
,PO_REQUISITION_LINES_ALL PRLA
, PO_REQ_DISTRIBUTIONS_ALL PRDA
, GL_CODE_COMBINATIONS GCC
, FND_FLEX_VALUES_TL tl
, FND_FLEX_VALUES_TL tl2
, PER_ALL_PEOPLE_F PAPF
, PER_ALL_PEOPLE_F PAPFFF
, FND_CURRENCIES fc
, FND_FLEX_VALUE_SETS vs
, FND_FLEX_VALUES v
, FND_FLEX_VALUES v2
, FND_FLEX_VALUE_SETS vs2
, PO_ACTION_HISTORY PAHH 
WHERE 1 = 1 
AND PRLA.REQUISITION_HEADER_ID = PRHA.REQUISITION_HEADER_ID 
AND PRLA.REQUISITION_LINE_ID = PRDA.REQUISITION_LINE_ID 
AND NVL(PRLA.CURRENCY_CODE, 'UAH') = FC.CURRENCY_CODE 
AND PRHA.PREPARER_ID = PAPF.PERSON_ID 
AND PRDA.CODE_COMBINATION_ID = GCC.CODE_COMBINATION_ID 
AND GCC.SEGMENT2 = V.FLEX_VALUE 
AND GCC.SEGMENT3 = V2.FLEX_VALUE 
AND VS.FLEX_VALUE_SET_ID = V.FLEX_VALUE_SET_ID 
AND V.FLEX_VALUE_ID = TL.FLEX_VALUE_ID 
AND VS2.FLEX_VALUE_SET_ID = V2.FLEX_VALUE_SET_ID 
AND V2.FLEX_VALUE_ID = TL2.FLEX_VALUE_ID 
AND PAHH.OBJECT_ID = PRHA.REQUISITION_HEADER_ID 
AND pahH.employee_id = papFFF.person_id 
AND pahh.sequence_num = (SELECT MAX(pah.sequence_num) 
FROM PO_ACTION_HISTORY PAH 
WHERE 1 = 1 
AND pah.object_id = pahh.object_id) 
AND PRDA.ORG_ID IN (322, 321) 
AND PAPF.BUSINESS_GROUP_ID IN (321, 322) 
AND PAPFF.BUSINESS_GROUP_ID IN (321, 322) 

AND TRUNC(PRDA.CREATION_DATE) BETWEEN TO_DATE('2011/01/01 00:00:00', 'YYYY/MM/DD HH24:MI:SS') 
AND TO_DATE('2012/06/30 23:59:59', 'YYYY/MM/DD HH24:MI:SS') 
AND GCC.SEGMENT2 IN ('00155', '00157', '00159', '00165', '00170', '00178', '00332', '00337', '00421', '00424', '00465', '00491', '00492', '00498', '00514', '00515', '00516', '00517', '00518', '00519', '00520', '00521', '00522', '00523', '00524', '00525', '00526', '00527', '00446', '006600') 
AND VS.FLEX_VALUE_SET_NAME = 'COSTCENTER' 
AND TL.LANGUAGE = 'RU' 
AND TL2.LANGUAGE = 'RU' 
AND TL2.source_lang = 'RU' 
AND TL.source_lang = 'RU') 

SELECT T1.REQ_NUMBER
, T1.LINE, T1.LINE_DESCR
, T1.QUANT, T1.PRICE
, T1.SUMM, T1.CURRENCY
, T1.COSTCENTR_NUMB
, T1.COSTCENTR_DESCR
, T1.COST_ITEM
, T1.COST_ITEM_DESCR
, T1.CREATION_DATE
, T1.STATUS
, NVL(T2.PO, 'NO') AS ZAKAZ
, T1.PREPARER_name
, T1.Last_appr 
FROM T1 LEFT JOIN (SELECT PRDA.DISTRIBUTION_ID AS IDEE2
, PHA.SEGMENT1 AS PO 
FROM PO_REQ_DISTRIBUTIONS_ALL PRDA
, PO_HEADERS_ALL PHA
, PO_LINES_ALL PLA
, PO_DISTRIBUTIONS_ALL PDA 
WHERE 1 = 1 
AND PRDA.DISTRIBUTION_ID = PDA.REQ_DISTRIBUTION_ID 
AND PDA.PO_LINE_ID = PLA.PO_LINE_ID 
AND PLA.PO_HEADER_ID = PHA.PO_HEADER_ID) T2 ON T1.IDEE = T2.IDEE2 
ORDER BY T1.REQ_NUMBER, T1.LINE;
29 июн 12, 03:24    [12792009]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
Edward Shevtsov
Member

Откуда: Moscow
Сообщений: 13469
Liubomyr,

Проблема скорее всего в DISTINCT, который вызывает сортировку. With здесь особой роли не играет, поскольку только один блок T1 используется. Чтобы разобраться, начни с самой простой версии запроса (как ты его создавал) и на каждом этапе усложнения проверяй как отрабатывает. Найдешь шаг, на котором все резко плохеет.
Это OEBS? Если да, то значит Enterprise Edition, должны быть доступны materialized views. Посоветуйся с админом насчет возможности их использования. Индексы могут помочь, главное понять, где их создавать.
29 июн 12, 04:30    [12792025]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
Edward Shevtsov
Member

Откуда: Moscow
Сообщений: 13469
Liubomyr,

и вот это

1 = 1
убери
29 июн 12, 04:31    [12792026]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
Добрый Э - Эх
Guest
Edward Shevtsov
With здесь особой роли не играет, поскольку только один блок T1 используется.
With не играет особой роли? Даже если вдруг Оракл решил "материализовать" результат WITH-запроса ?
29 июн 12, 04:39    [12792027]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
Добрый Э - Эх
Guest
2 ТС
Лишь по одному тексту запроса, без плана и статистики по объектам - трудно сказать что либо о производительности запроса и его аппетиту до серверных ресурсов
29 июн 12, 04:42    [12792028]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Liubomyr
Применил все рекомендации по оптимизации о которых знал - минимум join-ов, последовательность условий у where, применил конструкцию with as
Это бессмысленные рекомендации и им следовать не надо. Темп может потреблять любое соединение, и в любом случае по тексту запроса что-то сказать невозможно. Поэтому, если 11g, то запускаешь запрос, ждешь и через
select dbms_sqltune.report_sql_monitor(report_level=>'ALL', type=>'TEXT', ...) monitor_report from dual 
получаешь отчет в котором видно где тратится время, темп и еще много полезной информации. Если 10g и есть возможность дождаться выполнения запроса - то выполнить с /*+ gather_plan_statistics /, а потом через dbms_xplan.display_cursor показат план. Либо анализировать v$sql_workarea_active, на предмет какая операция потребляет темп.
29 июн 12, 05:36    [12792038]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
andreymx
Member

Откуда: Запорожье
Сообщений: 54381
Liubomyr
...которая не может отработать запрос в котором один join и один подзапрос, инфо тянется меньше чем с 2-х десятков таблиц ??...
странно слышать, что в запросе с 20 таблицами всего один джойн
29 июн 12, 08:42    [12792191]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
pectopatop
Member

Откуда:
Сообщений: 765
Edward Shevtsov
в DISTINCT, который вызывает сортировку.

+ еще в самом конце запроса ORDER BY.
29 июн 12, 09:52    [12792608]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
Liubomyr
Member

Откуда: Київ
Сообщений: 113
Edward Shevtsov
With здесь особой роли не играет

Не сильно, но помогает. без него не смог вывести вообще ни одной строки, когда добавил - около 500
Edward Shevtsov
Это OEBS?
- да, но мы немного ее под свои БП подгоняли - и стандартные вюхи не подойдут.
Edward Shevtsov
Индексы могут помочь, главное понять, где их создавать.
Да, в том то и проблема, раньше не использовал... Попробую что-то почитать - понять что к чему ...
Спасибо огромное за советы! Посмотрим, что получится...
29 июн 12, 17:32    [12796270]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
Liubomyr
Member

Откуда: Київ
Сообщений: 113
andreymx
странно слышать, что в запросе с 20 таблицами всего один джойн

Почему ? Во первых нет необходимости использовать больше, а во вторых - они-же грузят запрос...
29 июн 12, 17:38    [12796318]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
Liubomyr,

планы запросов изучайте, структуры таблиц/индексов.
если таблицы таки большие, то вполне вероятно, что о тута вот:

AND TRUNC(PRDA.CREATION_DATE) BETWEEN TO_DATE('2011/01/01 00:00:00', 'YYYY/MM/DD HH24:MI:SS').. 

проблема
29 июн 12, 17:46    [12796369]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
Liubomyr
Member

Откуда: Київ
Сообщений: 113
orawish
планы запросов изучайте, структуры таблиц/индексов.
- уже делаю...
Google forever, или можете что-то конкретное порекомендовать ?
29 июн 12, 18:00    [12796450]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
Liubomyr
orawish
планы запросов изучайте, структуры таблиц/индексов.
- уже делаю...
Google forever, или можете что-то конкретное порекомендовать ?

sys.dbms_xplan
29 июн 12, 18:07    [12796491]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
Edward Shevtsov
Member

Откуда: Moscow
Сообщений: 13469
Liubomyr
andreymx
странно слышать, что в запросе с 20 таблицами всего один джойн

Почему ? Во первых нет необходимости использовать больше, а во вторых - они-же грузят запрос...
на N таблиц будет N-1 операций соединения
29 июн 12, 18:12    [12796518]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
Liubomyr
Member

Откуда: Київ
Сообщений: 113
Edward Shevtsov
на N таблиц будет N-1 операций соединения

Я имел ввиду явный...
29 июн 12, 18:26    [12796607]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
Не тупи
Одно слово JOIN в тексте запроса не означает, что он единственный
Правильнее будет сказать "единственный явный JOIN с использованием ANSI-синтаксиса". Причем, сочетание в одном запросе ANSI и нативного ораклового соединения тоже не очень удачная мысль.

PS. Если еще не понял, выражение типа "PRLA.REQUISITION_HEADER_ID = PRHA.REQUISITION_HEADER_ID" означает тот самый JOIN таблиц с алиасами PRLA и PRHA.
Это и есть тот самый "родной оракловый" синтаксис
2 июл 12, 02:54    [12801757]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
Liubomyr
Member

Откуда: Київ
Сообщений: 113
Вячеслав Любомудров
единственный явный JOIN с использованием ANSI-синтаксиса

Извините, так вроде я так и написал:

Liubomyr
Edward Shevtsov
на N таблиц будет N-1 операций соединения

Я имел ввиду явный...
4 июл 12, 02:52    [12813307]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
Edward Shevtsov
Member

Откуда: Moscow
Сообщений: 13469
Liubomyr,

это ты сам придумал про явные и неявные джойны? )
4 июл 12, 02:58    [12813314]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
Джойнов у тебя там валом
Просто с использованием разного синтаксиса
4 июл 12, 02:59    [12813315]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
98734249263492
Guest
Liubomyr
Вячеслав Любомудров
единственный явный JOIN с использованием ANSI-синтаксиса

Извините, так вроде я так и написал:

Liubomyr
пропущено...

Я имел ввиду явный...

Я раньше думал, чтобы запросы писать и с каким-нибудь OEBSом работать надо ну хотя бы необходимый минимум понимать в этом.
4 июл 12, 08:13    [12813498]     Ответить | Цитировать Сообщить модератору
 Re: Добавление свободного места в TEMP, чем это чревато?  [new]
Liubomyr
Member

Откуда: Київ
Сообщений: 113
Edward Shevtsov
Liubomyr,

это ты сам придумал про явные и неявные джойны? )


Нет! Если найду, кину книгу, где упоминался этот термин!


Вячеслав Любомудров
Джойнов у тебя там валом
Просто с использованием разного синтаксиса


Опять же, когда читал оптимизацию, в книге было сказано что использование "join" там где можно его заменить на "=" - не рекомендуется, так как существенно влияет на производимость. Почему обратил на это внимание? - Однажды попал в руки запрос:
T1 join T2 on T1.C1=T2.C1
join T3 on T2.C2=T3.C2 .... и т.д.
проверил, оказалось что можно было заменить на: T1.C1=T2.C1 and T2.C2=T3.C2 ...


Вот так...
4 июл 12, 11:03    [12814293]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Oracle Ответить