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

Откуда:
Сообщений: 51
Коллеги, есть непонятная ситуация.

HP-UX 11.31 Itanium Memory – 200+ G
DB – 10.2.0.5 Size – 10+ Tb
Все возможные патчи на БД поставлены.

Нагрузка - 1000-1800 (50-100 активных сессий), плюс джобы подготавливающие отчёты, загрузки данных, то-сё…
Основное приложение написано на АПЕКС 3.1.2.00.02. Раздельная инсталляция - БД на одном сервере, Апач на другом.

После старта экземпляра всё работает нормально, однако через неделю-две производительность сильно снижается!
Падает производительность приложений работающих с LOB, а таких у нас большинство.
В частности, это проявляется в черезвычайно длительной процедуре заливки новых версий Апекс приложений.
Если вначале это минуты, то по прошедствии времени, при деградации производительности с LOB, это длится часами, или вообще не заканчивается.
С нашей точки зрения, это следствие всё той же деградации производительности с LOBами.

Причина этого явления непонятна. Единственный способ который реально помогает - перегрузка БД.
Сами понимаете, что это не метод.
При этом это не латчи, и не блокировки - чистое время процессора.
Смена TEMP & UNDO tablespace’ов, alter system flush - и другие приседания и камлания эффекта не дают.
В инете ничего на эту тему нарыть не удалось.
В основном это банальные советы, типа не делайте много мелких изменений LOB, накопите в переменной и пишите максимально большими кусками.
Но это не объясняет причину снижения одних и тех же операций с LOB со временем.

Конкретный тестовый пример простейший. Берём блок :
set timing on;
set serveroutput on
DECLARE
zzz CLOB;
xxx CLOB := 'asdasdasdasd';
BEGIN
dbms_lob.createtemporary(zzz,TRUE);
FOR i IN 1..10000 Loop
dbms_lob.append(zzz, xxx);
END LOOP;
dbms_lob.freetemporary(zzz);
EXCEPTION
WHEN OTHERS THEN
dbms_lob.freetemporary(zzz);
RAISE;
END;
/

После старта экземпляра время его выполнения ок. 0.2 с.
Темп деградации – примерно в 10 раз в неделю. Через неделю примерно 2 сек., через 2 недели – 10-20 и т.д.
Естественно, ждать, пока замедлится на 3-4-5 порядков, возможности нет, приходится экземпляр перезапускать.
И опять – всё возвращается к описанной картине.

Никакой корреляции с платформой, версией ОС, спецификой АПЕКС, версией БД установить не удалось.
Промоделировать ситуацию не удаётся, так как на тестовых серверах не удаётся организовать адекватную нагрузку.
Таким образом на тестовых серверах, подобная ситуация не воспроизводится.
Уточняю, что тестовая среда на Linux x86_64. Так что нельзя исключать зависимость от платформы.

Есть у кого нибудь идеи из-за чего может происходить деградация работы с LOBами, и как с этим бороться?
6 июн 17, 15:01    [20543581]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
VDom
Падает производительность приложений работающих с LOB, а таких у нас большинство.

почему? Зачем ва LOB?
VDom
Есть у кого нибудь идеи

Завист от того, хотите ли вы работать. Т.е. например, воспроизвести нагрузку на тесте можно многими способами и ПО для этого. Но вы не хотите(.
- прочитать ветку про "тормозит"
- перейти на версию апекса выше и подтягивать архитектуру под новые версии.
6 июн 17, 15:21    [20543665]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1945
VDom,

Похоже больше на базу, а не на апекс, так что вам скорее в соседний раздел.
Может быть сервер или диск перегружены чем-то в это время ?

Если интересует сторона апекс, не уверен, что это может влиять напрямую, но рядом - сталкивался с утечкой TEMP памяти при использовании Text Field with autocomplete с опцией Lazy Loading: NO

Cессии отжирали неадекватное количество TEMP памяти и отваливались потом с ошибками, отловил в итоге виновника по V$ACTIVE_SESSION_HISTORY. Можно было так же наблюдать рост счетчиков в v$temporary_lobs для APEX_PUBLIC_USER между запросами.
6 июн 17, 15:51    [20543834]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1945
VDom,

Я так понял у вас mod_plsql ?

Если не помогают другие средства отладки, и по словарям проблему не получается отследить (с вашими объемами), немного радикальный метод, но можно кильнуть все апексные сессии, они скорее всего должны восстановиться в рамках пула сессий (не помню, как с mod_plsql), но всякая память и ресурсы связанные с ними освободятся. Тогда сможете проверить, помогло или нет и влияют ли здесь утечки.

Можно какой-нибудь хитрый job написать, который бы давал сессиям таймаут.
6 июн 17, 17:04    [20544190]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Migelle
Member

Откуда:
Сообщений: 151
VDom,
А деградация идет только в апексовых сессиях, или в отдельных сессиях такая же картина? Если второе, то ИМХО апекс тут вообще не причем и с этим вопросом надо идти в ветку оракла.
6 июн 17, 17:27    [20544294]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1945
Migelle,

Если это утечки ресурсов, например PGA или TEMP, другие сессии очень даже могут быть причем.
Самым простым способом утечки можно проверить - килянием.
6 июн 17, 17:32    [20544311]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Migelle
Member

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

Ну, про ТЕМР автор сам написал, что не помогает. PGA явно проверяли на исчерпание.
У нас есть несколько проектов не на апексе, и коннекций сильно поменьше, веб-приложение общается с БД обменом CLOB-ами. Работает иногда годами без перезагрузки и деградации не наступает. Но все работает на 11.2, может 10.2 имеет в себе сей глюк.
6 июн 17, 21:19    [20544846]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1945
Migelle,

то что ТС писал по поводу TEMP, это не совсем то. Утекшую TEMP память в пуле сессий фиг освободишь без убийства сессии, во всяком случае я не знаю как.

+
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> SELECT S.sid, S.serial#, SUM (T.blocks) * TBS.block_size / 1024 / 1024 used
_mb, T.tablespace
  2    FROM v$sort_usage T, v$session S, dba_tablespaces TBS
  3   WHERE T.session_addr = S.saddr
  4     AND T.tablespace = TBS.tablespace_name
  5     and s.sid = sys_context('userenv','sid')
  6   GROUP BY S.sid, S.serial#, TBS.block_size, T.tablespace;

no rows selected

SQL> declare
  2    t sys_refcursor;
  3
  4    i number;
  5  begin
  6    open t
  7    for
  8    with rownums
  9    as (select distinct
 10        rownum rn
 11          from dual
 12       connect by level <=1000000
 13    )
 14    select rn from rownums
 15     union all
 16    select rn from rownums;
 17
 18    fetch t into i;
 19    close t;
 20  end;
 21  /

PL/SQL procedure successfully completed.

SQL> SELECT S.sid, S.serial#, SUM (T.blocks) * TBS.block_size / 1024 / 1024 used
_mb, T.tablespace
  2    FROM v$sort_usage T, v$session S, dba_tablespaces TBS
  3   WHERE T.session_addr = S.saddr
  4     AND T.tablespace = TBS.tablespace_name
  5     and s.sid = sys_context('userenv','sid')
  6   GROUP BY S.sid, S.serial#, TBS.block_size, T.tablespace;

       SID    SERIAL#    USED_MB TABLESPACE
---------- ---------- ---------- -------------------------------
       264       9871         12 MY_TEMP

SQL>  alter system flush buffer_cache
  2  ;

System altered.

SQL>  alter system flush shared_pool;

System altered.

SQL> begin
  2    dbms_session.modify_package_state(DBMS_SESSION.FREE_ALL_RESOURCES);
  3  end;
  4  /

PL/SQL procedure successfully completed.

SQL> alter session set events '60025 trace name context forever';

Session altered.

SQL> SELECT S.sid, S.serial#, SUM (T.blocks) * TBS.block_size / 1024 / 1024 used
_mb, T.tablespace
  2    FROM v$sort_usage T, v$session S, dba_tablespaces TBS
  3   WHERE T.session_addr = S.saddr
  4     AND T.tablespace = TBS.tablespace_name
  5     and s.sid = sys_context('userenv','sid')
  6   GROUP BY S.sid, S.serial#, TBS.block_size, T.tablespace;

       SID    SERIAL#    USED_MB TABLESPACE
---------- ---------- ---------- -------------------------------
       264       9871         12 MY_TEMP

SQL> declare
  2    t sys_refcursor;
  3
  4    i number;
  5  begin
  6    open t
  7    for
  8    with rownums
  9    as (select distinct
 10        rownum rn
 11          from dual
 12       connect by level <=1000000
 13    )
 14    select rn from rownums
 15     union all
 16    select rn from rownums;
 17
 18    fetch t into i;
 19    close t;
 20  end;
 21  /

PL/SQL procedure successfully completed.

SQL> SELECT S.sid, S.serial#, SUM (T.blocks) * TBS.block_size / 1024 / 1024 used
_mb, T.tablespace
  2    FROM v$sort_usage T, v$session S, dba_tablespaces TBS
  3   WHERE T.session_addr = S.saddr
  4     AND T.tablespace = TBS.tablespace_name
  5     and s.sid = sys_context('userenv','sid')
  6   GROUP BY S.sid, S.serial#, TBS.block_size, T.tablespace;

       SID    SERIAL#    USED_MB TABLESPACE
---------- ---------- ---------- -------------------------------
       264       9871         24 MY_TEMP

SQL>

Тоже самое касается CACHE_LOBS.

Настройки в ords типа jdbc.MaxConnectionReuseCount не просто так делают.
7 июн 17, 10:04    [20545668]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
VDom
Member

Откуда:
Сообщений: 51
Коллеги, спасибо всем кто откликнулся.
К сожалению текущую работу никто не отменял, а она немаленькая, и оперативно отвечать на предложения не получается.

Поэтому отвечу всем сразу.

Без LOBов нельзя - логика приложения, хранятся сканы документов.
Нагрузку конечно можно попробовать воспроизвести, но для адекватных результатов надо бы и чтобы железо было одинаковое, а его нет.

На счёт тестовых серверов.
На самом деле тестовые сервера есть разные и на Linux Х_86_64 и на HP-UX Itanium (но железки с Itanium совсем чахлые).
Ни на одном из них деградации работы с LOBами не замечено. Правда там и нагрузки нет.
Есть идея запустить на самом загруженном сервере наш тест и посмотреть динамику. До сих пор мы этого не делали.

Перейти на более новые версии Апекса пока не можем. 5 Апекс например стаёт только на Oracle 12, а вопрос миграции и лицензирования зависит от заказчика.
Кроме того, это потребует некоторых ресурсов, человеческих и финансовых, а это опять зависит от заказчиков.

Похожий вопрос задан и в общей ветке Oracle.
Дисковая система не перегруженна, да и система в целом тоже.
Из 48 ядер в среднем занято 40.

Не думаю что виноват конкретно Апекс. Скорее всего это общая проблема LOB, а поскольку движок Апекса сам интенсивно работает с LOBами, то это сказывается и на нём. Однако нельзя исключать и того, что из-за интенсивной работы Апекса с LOBами общая нагрузка на LOBы сильно возрастает, и тогда проявляется проблема с LOBами.

Да у нас mod_plsql.
Регулярно перестартовываем Апачи, когда по разным причинам возростает нагрузка.
Нагрузка сразу падает, но дело в том что деградация с течение времени увеличивается.
В том числе и ночью когда Апекс нагрузки нет. Так что это врядли зависит от текущей нагрузки Апекса.

На счёт темпов и undo.
Проверяли так - создавали новое дефаултное ТП, а потом перестартовывали Апачи.
Все Апексные сессии отваливались, а потом продолжались с новыми ТП.
Никакого влияния на скрипт.
Есть некие колебания времени работы скрипта в течении суток, но в целом идёт рост времени.
7 июн 17, 13:15    [20546657]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
VDom
Member

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

Ещё раз, спасибо всем кто откликнулся.

Давайте не будем рассматривать работу с таблицами с LOBами, ограничимся нашим тестовым примером.
В примере есть только временный LOB. Время выполнения этого скрипта монотонно растёт…
Независимо от текущей мгновенной нагрузки на сервере.
Насколько я понимаю, ничего, кроме процессора, памяти, хранимых процедур и темпа в нём не используется.
Даже относительно ТЕМПа есть сомнения, т.к. темпLOB кэшируем и относительно невелик…
Создаётся впечатление, что какие-то структуры управления памятью, выделяемой под ТемпLOBы, не чистятся в процессе работы сервера, монотонно наращивая свой объём из-за чего теряется скорость обработки…
Как с этим бороться, непонятно…
7 июн 17, 15:57    [20547472]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
blkangel
Member

Откуда:
Сообщений: 1636
А если закрывать?

DECLARE 	
	zzz CLOB;
	xxx CLOB := 'asdasdasdasd';
BEGIN
	dbms_lob.createtemporary(zzz,TRUE);
	dbms_lob.open(zzz,dbms_lob.lob_readwrite);
	FOR i IN 1..10000 Loop
		dbms_lob.append(zzz, xxx);
	END LOOP;
	dbms_lob.close(zzz);
	EXCEPTION WHEN OTHERS THEN dbms_lob.close(zzz);
RAISE;
END;
/
7 июн 17, 16:10    [20547538]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
blkangel
Member

Откуда:
Сообщений: 1636
Так же попробуйте отказаться от Кэш, замедлит общий темп, но возможно на длительную работу не скажется.

DECLARE
zzz CLOB;
xxx CLOB := 'asdasdasdasd';
BEGIN
dbms_lob.createtemporary(zzz,FALSE);

FOR i IN 1..10000 Loop
dbms_lob.append(zzz, xxx);
END LOOP;
dbms_lob.freetemporary(zzz);
EXCEPTION WHEN OTHERS THEN dbms_lob.freetemporary(zzz);
RAISE;
END;
/
7 июн 17, 16:12    [20547544]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
blkangel
Member

Откуда:
Сообщений: 1636
DECLARE 	
	zzz CLOB;
	xxx CLOB := 'asdasdasdasd';
BEGIN
	dbms_lob.createtemporary(zzz,FALSE);

	FOR i IN 1..10000 Loop
		dbms_lob.append(zzz, xxx);
	END LOOP;
	dbms_lob.freetemporary(zzz);
	EXCEPTION WHEN OTHERS THEN dbms_lob.freetemporary(zzz); raise;
END;
/
/
7 июн 17, 16:13    [20547549]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
VDom
Member

Откуда:
Сообщений: 51
VDom,
«Так же попробуйте отказаться от Кэш, замедлит общий темп, но возможно на длительную работу не скажется.»

Увы, время сразу возрастает примерно в 100 раз, что неприемлемо…
Кстати, время без кэша растёт примерно в той же пропорции, что и с кэшем. Только по абсолютному значению раз в сто больше…

“Сравнить состояние до и после через "AWR : Compare period reports" пробовали?
Посмотреть на v$sgastat - если какие-то "структуры управления памятью" растут, может их поискать?”

Идея вполне здравая, если бы не… Вот время работы скрипта за сутки выросло раза в полтора… Или за неделю – в десять раз… Что с чем сравнивать? «Сейчас» с «сутки назад» или «неделю назад»? БД-то реально рабочая, за сутки меняется всё… Хотя… Если сохранять СГАСТАТ , скажем раз в 10 минут, а потом вдумчиво смотреть на колебания циферок… Например, выстроить графики по каждому параметру за месяц… Ох, не знаю, не знаю… :-/
7 июн 17, 16:58    [20547795]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
VDom
До сих пор мы этого не делали.

сделайте. Это ваша обязанность. ПО для нагрузки есть.
VDom
но для адекватных результатов надо бы и чтобы железо было одинаковое, а его нет.

не надо. Вы и так увидите динамику по памяти и производительности.
VDom
Перейти на более новые версии Апекса пока не можем. 5 Апекс например

можете но не хотите. Апекс 4 от тройки отличается очень сильною. А вот 5 от 4 не сильно.
Т.е. вам надо перейти на 4-ку.
Либо жолго парить мозги вопросами с тройкой.

VDom
Без LOBов нельзя - логика приложения, хранятся сканы документов.

т.е. вы одной фразой отписались и хотите варианты решения вашей проблемы?
КОНКРЕТНЕЕ ЗАЧЕМ ЭТОТ ТИП ПОЛЯ НУЖЕН В ХРАНИМКЕ КРОМЕ ВЫГРУЗИТЬ НА КЛИЕНТА?

VDom
Похожий вопрос задан и в общей ветке Oracle.

ссылку пожалуйста. Может мы по второму кругу обсуждам.
7 июн 17, 21:50    [20548348]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
VDom
Давайте не будем рассматривать работу с таблицами с LOBами, ограничимся нашим тестовым примером.

тогда это вопрос чисто ветки оракла. Дайте ссылку на то обсуждение.
Апекс ни при чём вроде.
7 июн 17, 21:54    [20548358]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
VDom
Member

Откуда:
Сообщений: 51
Деградация носит кумулятивный характер, поэтому надо понять что может иметь кумулятивный характер, и может ли это быть связанно с операциями с LOB.
С моей точки зрения это :

1) сегментация TEMP табличного пространства - замена табличного пространства TEMP на другое ничего не даёт поэтому этот фактор исключаем
2) рост swap памяти - проверка показала что свопа нет и он не растёт
3) переполнение каких то счётчиков, или семафоров -
В HP-UX есть заклинание kcusage показывающее пороговые значения и текущие

Tunable Usage / Setting
=============================================
filecache_max 12156600320 / 12197325864
maxdsiz 8060928 / 2147483647
maxdsiz_64bit 190971904 / 274877906944
maxfiles_lim 922 / 63488
maxssiz 98304 / 134217728
maxssiz_64bit 2097152 / 1073741824
maxtsiz 13484032 / 1073741824
maxtsiz_64bit 369098752 / 8589934592
maxuprc 382 / 27000
max_thread_proc 193 / 3000
msgmbs 0 / 8
msgmni 2 / 4096
msgtql 0 / 30000
nflocks 132 / 30000
ninode 3862 / 484096
nkthread 2148 / 52516
nproc 870 / 30000
npty 0 / 200
nstrpty 2 / 200
nstrtel 0 / 60
nswapdev 1 / 32
nswapfs 0 / 32
semmni 132 / 30000
semmns 11705 / 60000
shmmax 104237301760 / 226158430208
shmmni 51 / 4096
shmseg 32 / 512

Из приведённого только filecache_max наводит на размышления.
Он достиг 12156600320 при пороге 12197325864. Разница 40 725 544. Вроде много, но это 0,34% !! Это настораживает.
Вообщето в БД у нас 187 ТП, а у них 592 файла. И это без всяких других файлов БД (онлайн журналов и т.д.).
Непонятно только как это может влиять на LOB.

4) сегментация памяти - мне кажется что это кандидат №1

Поясню почему.
Есть такое понятие как управление большой памятью. Памяти у нас действительно много, и я даже не всю её использую.
System Page Size: 16Kbytes
Memory: 261149792K (137296352K) real, 265148832K (139316016K) virtual, 105355568K free Page# 1/893

В связи с этим вспоминаем что есть такая вещь как HugePages, которую как раз и рекомендуется использовать при большой памяти.
То есть при старте память для Oracle сразу выделяется одним непрерывным куском, а внутри этого куска управление памятью выполняется максимально большими страницами.
Всё это хорошо описано, и я неоднократно это настраивал но под Linux.
Специалисты по HP-UX говорят что в HP-UX нет понятия HugePages и что там всё изначально делается правильно??
Но как? Толком мне никто этого так и не пояснил. В инете есть какие то упоминания о HugePages и HP-UX но ничего конкретного.

Складывается впечатление, что какие то структуры управляющие за управление памятью, с течением времени заполняются, в результате чего начинаются тормоза.
8 июн 17, 10:38    [20549175]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
VDom
Member

Откуда:
Сообщений: 51
В общей ветке это тема "Деградация производительности при работе с LOB"
http://www.sql.ru/forum/1262261/degradaciya-proizvoditelnosti-pri-rabote-s-lobami

Но в ветке Апекса намного больше предложений.

С переходом на новые версии Апекс не всё так просто.
Есть договор, в котором указано чего и какой версии должно быть.
В любом случае это решает заказчик, а его этот вопрос меньше всего волнует.
Кстати мы пробовали и 4 и 5 Апекс, так что мы готовы, но.

Приложение и написано для работы со сканами разных документов, в этом его смысл.
На самом деле мы вынесли из БД часть сканов (большую часть) в так называемый файловый архив.
Но проблема с LOB никуда не делась и не ушла.
Кроме того не забываем что у Апекса вся работа с файлами - загрузка/выгрузка, и собственно залмвка приложений всё идёт через таблицу WWV_FLOW_DATA с ITEM_VALUE CLOB.
Учитывая интенсивное использование приложений на апексе так или иначе возрастает работа с LOB.
Возможно достигается какой то порог, после чего начинаюся проблемы с LOB.
Хотя да, в этом случае это проблема БД, но не без участия Апекс.
8 июн 17, 11:29    [20549378]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1945
VDom
Все Апексные сессии отваливались, а потом продолжались с новыми ТП.

т.е. прямое влияние апекса вы исключили, и всё говорит о том, что апекс ни при делах, проблема где-то на уровне базы в целом.
Свидетельств косвенного влияния вы не продемонстрировали, апекс используется как прослойка и лишь в части функционала. Я так понимаю, свидетельств, что виновата загрузка или выгрузка нет, я бы, например, подозревал манипуляции с Persistent LOBs и, в том числе, другие опции. Похоже на какой-нибудь баг.

VDom
Давайте не будем рассматривать работу с таблицами с LOBами, ограничимся нашим тестовым примером.

Если бы все было так просто, вы бы сами проблему легко воспроизвели, но тестовый пример проблемы роста времени выполнения, я так понимаю, не воспроизводит. Это значит, что виновато что-то что рядом, а рядом много чего, в SecureFiles and Large Objects Developer's Guide много красивых слов и опций, которые могут стрелять, например, только в комбинации, при наличии соответствующих багов на уровне оракла.

Соответственно, я не вижу сейчас смысла смотреть проблему в привязке к апексу, с учетом, что нет свидетельств, которые явно указывали бы на апекс, или что апекс ограничивает как-то отладку проблемы, которая проявляется на уровне базы и имеет общий характер.
8 июн 17, 12:37    [20549727]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
VDom
Но в ветке Апекса намного больше предложений.

но честнее было сразу сказать, что апекс ни при чём и дать ссылку).
VDom
Приложение и написано для работы со сканами разных документов, в этом его смысл.

ну а апекс заточен на файловый архив. Есть разница?
VDom
Кроме того не забываем что у Апекса вся работа с файлами - загрузка/выгрузка, и собственно залмвка приложений всё идёт через таблицу WWV_FLOW_DATA с ITEM_VALUE CLOB.

не понял.
Я сразу перебрасываю сканы в свою таблу.
Никаких ваших ТАКИХ хранимок нету.
Что я делаю не так?
VDom
Учитывая интенсивное использование приложений на апексе так или иначе возрастает работа с LOB.

Мы про архитектуру вроде? Тогда огласите юз-кейс такой работы.
Возможно вы апекс используете не по назначению....при баге в самой СУБД.
8 июн 17, 13:08    [20549865]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
VDom
Member

Откуда:
Сообщений: 51
SDev

Да прямой связи с Апексом нет. Но косвенное очень даже может быть. Об этом я уже писал.
То есть сам движок Апекса очень интенсивно работает с LOB. Поэтому Апекс скорее катализатор а не причина, причина гдето в БД.
Мы тоже думаем что это может быть баг. Но реквесты, я создавать не могу. Да и даже если бы мог - Oracle 10 уже не поддерживается.

Почему мы сосредоточились на тестовом примере.
Во первых это объективный критерий по которому можно оценивать снижение производительности при работе с LOBами.
По времени срабатывания скрипта можно понять что БД пора перегружать.
Во вторых можно отбросить вопросы связанные с таблицами, их параметрами хранения и т.д. и т.п.
И даже в этом упрощонном примере непонятны причины.

У нас 10 БД поэтому SecureFiles нет.
И всё таки какая то коссвенная связь между Апексом и производительностью работы с LOB есть.
8 июн 17, 13:50    [20550035]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
VDom
Почему мы сосредоточились на тестовом примере.

прогоните тесты на новых версиях БД и апекса.
Установка апекс 30 минут и установка БД 2,5 часа на ноуте.
С третьей версией апекса уже никто реально не работает.
8 июн 17, 13:56    [20550059]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1945
VDom
И всё таки какая то коссвенная связь между Апексом и производительностью работы с LOB есть.

Если бы у вас были какие-нибудь объективные данные для этого утверждения, демонстрация связи запросами с проблемного сервера не было бы такой большой проблемой. Легко обвинить часть приложения, о которой не всё знаешь, но тем не менее это не конструктивный подход. Апекс действительно много работает с CLOB/BLOB и на уровне item в том числе, но и вы сами наверняка тоже с большими объемами LOB работаете. Часть с апекс отлажена большим числом людей с разными архитектурами приложений и pl/sql, часть с вашим приложением ограничена только вашей архитекторой с вашим кодом и отлажена хуже, чем apex сотрудниками oracle во всевозможных ситуациях. Тестовый пример никак не связан с апекс, поэтому, как минимум, я предлагаю вам собрать больше данных в другом разделе, чтобы появился хоть какой-то смысл смотреть конкретно что-то в привязке к апекс.

Прочего рода совета намного рациональнее обсуждать в разделе oracle.
8 июн 17, 14:44    [20550286]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
VDom
Member

Откуда:
Сообщений: 51
Petro123

Дело в том что на всех наших тестовых серверах, и на IA64 и на x86_64, время работы нашего тестового скрипта не растёт.
Так что нет смысла пробовать на других версиях БД или Апекса. На некоторых тестовых серверах даже работы выполняются, но нагрузка не соизмеримая.

Видимо дело всё таки в нагрузке.
8 июн 17, 17:44    [20551050]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
VDom
Дело в том что на всех наших тестовых серверах, и на IA64 и на x86_64, время работы нашего тестового скрипта не растёт.

странно у вас с логикой.
Это ваше:
автор
Промоделировать ситуацию не удаётся, так как на тестовых серверах не удаётся организовать адекватную нагрузку.

говорит что тестовой площадки нормальой у вас НЕТ.
Вы не умеете её готовить.
А вы пишите что время скрипта не растёт.
Обычна лень. Уж извините.
Поэтому у вас даже у себя....без заказчика нет четвёрки.
8 июн 17, 20:22    [20551390]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
VDom,
про бизнес логику и зачем хранимка вы тоже не ответили.
Поэтому удачи!
8 июн 17, 20:23    [20551392]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
VDom
Member

Откуда:
Сообщений: 51
Petro123

C логикой у нас всё нормально.
Тестовых серверов у нас 4. На одном из них заказчик учится.
Загрузка его не соизмерима с промом - там миллионы коннектов в сутки.
На остальных нагрузки нет вовсе.
До последнего времени мы мониторили скорость срабатывания тестового скрипта только на проме.
В качестве критерия мы используем время работы тестового скрипта.
Так вот оно ни на одном тестовом сервере не растёт.
Для адекватной ситуации надо на одном из тестов создать соизмеримую с промом нагрузку, а это не реально.
Нам просто некуда записать такую нагрузку даже за сутки, требуется хотя бы несколько дней.

По поводу приложения.
У нас штук 40 приложений на Апексе, и даже затрудняюсь сказать сколько разных других программ.
Несколько Апексных приложений специально разработаны для работы с документами, в том числе и сканами документов.
Чтобы как то разрулить ситуацию с LOBами (а первой возникла проблема с местом и временем логического экспорта), был разработан так называемый файловый архив в который выгрузили большую часть имеджей.
За счёт этого сильно сократился размер БД и сейчас он занимает всего 10ТБ.
Однако выявилась другая проблема которая была и раньше, но которая не диагностировалась, связанная с лобами - снижение скорости работы с LOB в течении 2-3 недель. Эта проблема выявилась при использовании программы загрузки/выгрузки документов в LOB. Скорость её работы падала в сотни раз. Разбор этой ситуации и выявил проблему которой посвящено данное обсуждение.
Кроме того у нас периодически возникает ситуация, когда приложения разработанные на Апекс устанавливается очень долго.
В нормальной ситуации это пара минут, а потом время установки возрастает до часов. Причины этого нам были не понятны.
После выявления проблемы деградации производительности с LOB стало понятно что это одна и та же проблема.
Дело в том что движок Апекса очень интенсивно работает с LOB. Например все загрузки/выгрузки файлов выполняются через таблицу www_flow_data с LOB полем. Это относится и к загрузке Апексных приложений.
Поэтому это обсуждение есть и в Апексной ветке и в основной ветке Oracle.
9 июн 17, 11:56    [20552586]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
VDom
Для адекватной ситуации надо на одном из тестов создать соизмеримую с промом нагрузку, а это не реально.

У меня впечатление, что вы всех убеждаете о невозможности создать нагрузочный тест.
Каждый раз у вас новый аргумент.
Вот, на второй странице новый:
VDom
Нам просто некуда записать такую нагрузку даже за сутки, требуется хотя бы несколько дней.

- нагрузку не записывают. Нагрузку создают.
- результаты нагрузки в виде БЛОБ закачанных сканов можно удалять тем же JOB'ом.
.......
Далее вы в 10 раз мешаете все проблемы в кучу так, что читать сложно.
Ещё раз:
1. Тестовая площадка для нагрузочного тестирования по ГОСТ
2. Архитектура ИС как рекомендует Оракл для версии 4 и 5.
9 июн 17, 12:20    [20552712]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
VDom
Member

Откуда:
Сообщений: 51
Petro123
Я сразу перебрасываю сканы в свою таблу.
Никаких ваших ТАКИХ хранимок нету.
Что я делаю не так?


Если кто не в курсе, работа с файлами в Апекс (я имею ввиду нормальный не эмбедед Апекс 3) в общих чертах выглядит так :
В интерфейсе создаётся элемент File brauser из которого файл попадает в apex_application_files, из которого потом можно переместить его туда куда нужно. Это стандартная процедура есть примеры и т.д.
На самом деле apex_application_files это вьюшка на wwv_flow_file_objects$.
В конце манипуляции с файлом надо только не забывать чистить apex_application_files
delete from apex_application_files where name = p_upload_name;

Иначе со временем вы можете "внезапно" выяснить что табличка wwv_flow_file_objects$ сильно выросла и съела всё свободное место в ТП.

Подчёркиваю вся вся работа с файлами (и исходниками собственно приложений Апекса) проходит через wwv_flow_file_objects$.
Сделайте например импорт Апекс приложения, потом посмотрите, что оно появилось в репозитрории Апекс.
Затем посмотрите wwv_flow_file_objects$ и вы увидите что ваше приложение в ней - это и есть репозиторий.
Короче все файлы в Апексе проходят через неё. Возможно в других версиях Апекс что то изменилось, но это вряд ли.
Кто сомневается - проверьте её размер, после инсталляции Апекса и например, через год работы системы.
Заодно посмотрите что в ней, и узнаете много интересного.
И это не единственная таблица Апекса с LOB. Весь движок Апекса очень бурно работает с LOB полями.
Если вы пока не этого не заметили, значит у вас не сильно активно пользуются приложением.

Именно поэтому мы связываем деградацию производительности при работе с LOB и АПЕКС.
То есть проблема возникает только на интенсивно работающих с Апекс приложениями системах.
Я не говорю что виноват Апекс, проблема в БД но проблема проявляется под влиянием Апекса.
Но что же на самом деле происходит непонятно.
9 июн 17, 12:49    [20552871]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
VDom
Если кто не в курсе

я в курсе
VDom
Иначе со временем вы можете "внезапно" выяснить

есть запрос, который показывает это конкретно. И нет никакой "внезапно".
Дальше опять бла бла бла.
Вы не знали что есть запрос на чистку при загрузке БЛОБ?
9 июн 17, 12:57    [20552908]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
повторяю вопрос. Что я делаю не так?
--перекидываем в свою таблицу все поступающие БЛОБ
Insert into MY_FILES (ID, AP_UNAME, F_DATA, F_MIMETYPE, F_CHARSET, F_FILENAME)
    select ************      from WWV_FLOW_FILES      where NAME=pNAME;
удаляем их со служебной таблицы
--Delete from WWV_FLOW_FILES   where NAME=pNAME;
9 июн 17, 13:07    [20552966]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1945
VDom
Именно поэтому мы связываем деградацию производительности при работе с LOB и АПЕКС.

Начиная с 5.0 апекс ушел от этого хранилища, вместо apex_application_files используется apex_application_temp_files, который чистится сам (хотя кое какие проблемки там еще остались, если выбирать сразу конечную таблицу в качестве хранилиша), более того использование старого хранилища desupported в 5.1.

Начиная с apex 4.2 (фактичиски с 4.1.1, если патчем) в связке с ords, если вам не нравится как в этом плане устроен mod_plsql, можно использовать restful сервисы для загрузки файлов (пример есть в документации) без промежуточных таблиц.

Но опять же, каких либо данных, что именно с этим связаны ваши проблемы не представлено.
9 июн 17, 13:25    [20553071]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1945
Petro123
повторяю вопрос. Что я делаю не так?

Немного не по теме.
В версиях до 5.0 этого недостаточно, этот код оставляет мусор после себя.
Проблема не сколько в апекс, а во многом на уровне параметров PlsqlDocumentTablename mod_plsql и apex.docTable в ords и том, как они работают. Файл грузится в служебную таблицу, код очистки выполняется гораздо позже.
Если посередине есть валидация или сработает какая-нибудь другая ошибка файл остаётся в базе.

В случае с ords напрашивается интеграция с restful, чтобы файлы грузились сразу в конечную таблицу и декларативно через какой-нибудь системный rest сервис, но пока декларативного нет.

VDom
Кроме того не забываем что у Апекса вся работа с файлами - загрузка/выгрузка, и собственно залмвка приложений всё идёт через таблицу WWV_FLOW_DATA с ITEM_VALUE CLOB.

Мне неизвестно, чтобы WWV_FLOW_DATA был как-то связан с файлами.
Могу ошибаться, но насколько мне известно:
- В старых версиях все items хранились как clob, чтобы обойти ограничения в 4000.
- В новых версиях хранится в 2-х столбцах varchar2 и clob, в clob помещается если между 4000 и 32767.
- Если включена опция 12c с 32767 в varchar2 в таблицах - вполне вероятно как clob вообще не хранится, не проверял.
- Если бы у вас с этой таблицей была бы проблема, врят ли вы бы жаловались на заливку приложений, все приложения повисли бы напрочь.
- Очень вероятно, что 11g или 12c решают проблему в топике.
10 июн 17, 13:16    [20555181]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1945
+ могу ошибаться, но, мне кажется, в старых версиях мастера делали Item Source: Only when current value in session state is null где-то по умолчанию при создании форм (может быть я что-то путаю).

Сейчас при создании форм используется Item Source: Always, replacing any existing value in session state, если источник database column и если приложение не в старом compability mode, поменять эту опцию на предыдущую уже нельзя.

Среди прочих отличий этих опций: одна из них используется совместно с persisted session state, другая c in-memory session state (и не хранится в таблице). Врят ли эти изменения связаны непосредственно с производительностью, но на производительность, вероятно, тоже какое-то влияние оказывают.
10 июн 17, 13:42    [20555233]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
SvDev,
очень много допущений и гаданий на кофейной гуще.
Я выше писал, что на данной ветке уже разбирали этот мусор и приводился запрос который показывает этот мусор.
Я запрос у себя запускал на продакшене и никакого мусора нету.
Могу поискать тот запрос.
А то как в анекдоте: "видишь суслика?".
...
Про транзакцию при скачке, разумеется у меня есть try в коде чтобы процесс не прервался и завершился.
Нет проблем.
Проблемы у ТС т.к. он решает по админски, а надо решать по программистски (заменяя кусками).
10 июн 17, 14:56    [20555399]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1945
Petro123,

Это потому что ты валидацию не делаешь и ограничение на размер заливаемого файла (очень частое требование)
10 июн 17, 15:11    [20555425]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
SvDev
Petro123,
Это потому что ты валидацию не делаешь и ограничение на размер заливаемого файла (очень частое требование)

Это типа предложение что можно сделать в хранимке?
Пусть автор конкретнее скажет use-case или Варианты Использования(ВИ). Что именно он валидирует при функционале: "Закачать файл на сервере".
Тогда можно подумать о решениях.
Их много всяких. Причём на том же JS вообще ПЕРЕД закачкой.
Или сделать тест на двое суток, где отменять закачку по валидации на 100000 блобов.
Но не так что тему мусолить 3 страницы и ничего не делать.
...
У меня система в продакшене успешно 3 года.
Он тут один с таким вопросом тоже 3 года.
Сразу напрашивается вывод, что дело не в апексе, а топик стартере.
11 июн 17, 12:17    [20556413]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
кстати, запрос с показом мусора при работе с download\upload никто не привёл.
А он тут был в каком то топике про "тормоза".
11 июн 17, 12:22    [20556421]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1945
Petro123,

Вопроса про мусор не было . Тебе надо - создай тему, лень объяснять.

Petro123
Он тут один с таким вопросом тоже 3 года.
Сразу напрашивается вывод,

Зато подобных шаблонных ответов по всему разделу большая куча...
11 июн 17, 12:36    [20556445]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
SvDev
Вопроса про мусор не было . Тебе надо - создай тему, лень объяснять.

твоё:
автор
В версиях до 5.0 этого недостаточно, этот код оставляет мусор после себя.

SvDev
Зато подобных шаблонных ответов по всему разделу большая куча...

это не удивительно. Конструктор апекс с низким порогом вхождения (мало кода и много вопросов).
Удачи автору!
11 июн 17, 13:23    [20556502]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
SvDev,
вообще, сегодня наверно ты не с той ноги встал. На протяжении топика ты говорил что данных мало чтобы судить о связи апекса с проблемой ТС.
Появились какие то новые данные?
Пусть ТС идёт делать тесты. А то флуда много пошло.
11 июн 17, 13:30    [20556512]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1945
Petro123,

Вопрос с файлами просто элементарно проверяется, делается любая валидация, которая срабатывает при загрузке, в разделе validations и загружается любой файл. Дальше в wwv_flow_files по имени файла найти можно. Обойти можно конечно, но лучше не в этой теме.

Про тесты согласен. Про то, что каких-то вопросов не было не аргумент. Многие вопросы, например, обсуждаются на otn форуме и здесь не освещены.
11 июн 17, 13:47    [20556535]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
SvDev
Вопрос с файлами просто элементарно проверяется

да. Согласен. Пусть ТС тестит. Я тоже ленивый)). Шутка.
SvDev
Про то, что каких-то вопросов не было не аргумент. Многие вопросы, например, обсуждаются на otn форуме и здесь не освещены.

А такой аргумент?
В катастрофах и НЕработоспособности, есть правило от инженеров: "самая простая причина обычно самая правильная".
Звучит как то так, но пословица говорит, что бОлее вероятно что у ТС - простейшая причина.
Как то: Версия апекс тройка или лишние хранимки по архитектуре.
Это не я говорю. Это инженеры)).
11 июн 17, 14:03    [20556558]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1945
Petro123,

Хранимки чаще всего не лишние, вместо них можно воткнуть слова: oracle database - 10-ка, а так очень даже)
11 июн 17, 14:19    [20556578]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
SvDev,
Я работы на тройке видел кусками. Сам с 4-ки начал.
Те куски что видел говорили о том, что там были в порядке вещей велосипеды с ручным перебросом айтемсов на сервер. Или частое http.print(
Я же за декларативную разработку начиная с 4-ки).
Но гадать конечно не будем.
Про 10 ку разумеется. При смене версии платформы автоматом и база сменится.
Выше писал, что установка базы 2,5 часа. Противопаказаний нет. Только желание.
imho
Удачи!
11 июн 17, 14:26    [20556583]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1945
Petro123,

И стоимость)
11 июн 17, 14:28    [20556584]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
SvDev,
XE бесплатная
11 июн 17, 16:52    [20556733]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1945
Petro123,

Если 10 Тб базу с 48 ядрами переведёшь на XE, я думаю, Нобелевскую получишь)
11 июн 17, 17:19    [20556759]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 29750
SvDev,
Дык мы о тестовой площадке всё. О ней родимой.
Для нее только желание.
11 июн 17, 17:37    [20556774]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1945
Petro123,

Для нормальной тестовой площадки XE не хватит, для этого скорее всего можно бесплатно EE использовать, если хватит Oracle Technology Network License Agreement для данного случая, вроде должно хватить. Но тут надо сначала воспроизвести проблему, иначе смена версии БД или чего-то еще на тесте ничего не покажет.
11 июн 17, 18:14    [20556806]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
VDom
Member

Откуда:
Сообщений: 51
Petro123,
Ошибаетесь уважаемый, сначала в реал тестинге записывают (ну или если хотите сохраняют) а потом проигрывают (или если угодно создают)
11 авг 17, 16:14    [20717355]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1945
VDom,

Как с поиском зависимостей, какие-то конкретные данные статистические есть ?
Например, apex_workspace_activity_log - можно понаблюдать количество запросов к определенным страницам, содержащий определенный функционал (exists apex_application_page_items / apex_application_page_proc и др)

Проверить корелляцию запросов к страницам не содержащий этот функционал и т.д., таким образом сужать круг...

При работе с такими проблемами это не всегда надежный способ, проблема всегда может оказаться в каком-то другом месте, но если она, например, косвенно связана с апексом, то есть вероятность найти какой-нибудь неожиданный способ её исправить.

+ У вас есть вариант обновиться до апекс 4.2 (в котором было много оптимизаций, например под RAC (apxpart.sql) и в таблице wwv_flow_data в том числе ) и ords 2.0.10 с app server (не знаю как поведёт себя ваша система на нём, но зато вы сможете использовать RESTful ).

Это имеет смысл, если вы связываете проблему с wwv_flow_file_objects$ и wwv_flow_data, можно сделать замеры, как зависит нарастание проблемы от времени и разного рода нагрузки, и сделать тесты как изменилось нарастание после переезда.

Заодно будут пересозданы апексные таблицы в новую схему (кроме wwv_flow_file_objects$)
11 авг 17, 18:42    [20717638]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1945
Добавлю,

можно посмотреть как изменилась таблица wwv_flow_data

+ 3.1.2
prompt ...wwv_flow_data



create table wwv_flow_data (
    flow_instance        number not null
                         constraint wwv_flow_data_fk
                         references wwv_flow_sessions$
                         on delete cascade,
    item_id              number,
    item_element_id      number,
    item_filter          varchar2(1)
                         constraint valid_item_filter
                         check (item_filter in ('Y','N')),
    session_state_status varchar2(1)
                         constraint valid_session_state_status
                         check (session_state_status in ('I','U','R')),
    flow_id              number,
    item_name            varchar2(255),
    name_length          int,
    item_value           clob)
    storage (initial 1M next 1M freelists 20)
    lob (item_value) store as (cache reads enable storage in row)
/




create unique index WWV_FLOW_DATA_IDX1 on wwv_flow_data (FLOW_INSTANCE,ITEM_ID);
create index WWV_FLOW_DATA_IDX2 on wwv_flow_data (flow_id,FLOW_INSTANCE);


+ 4.2.6
prompt ...wwv_flow_data
--==============================================================================
-- session state
--
-- IF YOU CHANGE THIS TABLE OR IT'S INDEXES
-- do not forget to synchronize ../utilities/apxpart.sql
--==============================================================================
create table wwv_flow_data (
    flow_instance        number
                         constraint wwv_flow_data_session_fk
                         references wwv_flow_sessions$
                         on delete cascade,
    item_id              number,
    item_filter          varchar2(1)
                         constraint valid_item_filter
                         check (item_filter in ('Y','N')),
    session_state_status varchar2(1)
                         constraint valid_session_state_status
                         check (session_state_status in ('I','U','R')),
    flow_id              number,
    item_name            varchar2(255),
    is_encrypted         varchar2(1),
    item_value_vc2       varchar2(4000),
    item_value_clob      clob,
    constraint wwv_flow_data_pk primary key (flow_instance, item_id)
                         using index (
                             create index wwv_flow_data_pk on wwv_flow_data (flow_instance,item_id)
                             compress 1) )
    storage (initial 1M next 1M freelists 20)
    initrans 8 maxtrans 255
    lob (item_value_clob) store as (cache reads disable storage in row)
/

create index WWV_FLOW_DATA_IDX1 on wwv_flow_data (flow_id) compress 1
/


Соотношение clob ко всем остальным не clob, очень низкое, например, оно может быть 0.0001 % (на сервере, что я проверял, нагрузка небольшая, зато приложений много).
И те в новых версиях хранятся как out of line, т.е. не мешают ничем

+ проверить
-- для версии 5.0
select count(case when t.item_value_clob is not null then 1 end) 
       / (count(case when t.item_value_clob is not null then 1 end) + count(t.item_value_vc2)) clob_proportion
     
     , count( distinct
             ( select t2.flow_id
               from apex_050000.wwv_flow_step_items t2
                  , APEX_050000.wwv_flows t3
               where t2.id = t.item_id
                 and t2.flow_id = t3.id
                 and t3.security_group_id not in (10,11,12) )) distinct_apps
from apex_050000.wwv_flow_data t


Это я всё веду к тому, что упомянутых узких архитектурных мест с LOB в современных версиях апекса нет. И что, и в 3-тьей версии, не увидел каких-либо подтверждений участия апекс.
15 авг 17, 18:48    [20726263]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3      [все]
Все форумы / Oracle APEX Ответить