[ОТВЕТИТЬ]
Опции темы
18.11.2008 15:04  
deucel
Цитата:
Сообщение от baggio
я бы прибавил *.sort_area_size=65536
до метра хотябы...
Тогда уж
WORKAREA_SIZE_POLICY = AUTO

 
18.11.2008 20:00  
dmware
так.. провел серию тестов после рабочего дня..
переиндексация... затем увиличил оба параметра:

Цитата:
Сообщение от baggio
я бы прибавил *.sort_area_size=65536
до метра хотябы...
и
*.log_buffer=10485760 ...
получил... понижение производительности... неожиданно...
оцениваю следующим образом - собственно чрезвычайно долгая выборка документов (приходные накладные выбираю)...
у меня получилось вместо полутора минут за выбранный мною период (5 дней по одному из магазинов) до смены параметров, две с копейками...
вернул все обратно... далее...
расчет статистики, полный, в административном модуле... та же выборка - не дождался результата (> 5-7 минут)...
удалил статистику по схеме... просто, чтобы посмотреть, что получится...
begin
dbms_stats.delete_schema_stats(
ownname => 'supermag'
);
end;
вдруг выясняется, что теперь документы выбираются за полторы минуты... медленно, но это не предыдущий вариант...
собираю статистику тем же заданием - больше 5 минут. просто уже не дождался...
все это время системным монитором наблюдаю постоянное обращение к диску, где у меня размещены файлы userXX.dbf. при этом обращения к индексам почти нет...
да, пробовал устанавливать cursor_sharing как в EXACT, так и возвращал обратно. никакой разницы не заметил. параметр динамический, для чистоты эксперимента перезапускал экземпляр...
собственно ни к чему не пришел:)
 
18.11.2008 20:28  
OlegON
Цитата:
*.db_writer_processes=4
этого не надо вообще
Цитата:
*.log_buffer=524288
это бы увеличить до 10М
Цитата:
*.query_rewrite_enabled='FALSE'
?
Цитата:
*.sga_max_size=2207330416
а база часом не свопается?
Цитата:
*.sort_area_size=65536
это не надо
cursor_sharing лучше не трогать, оно неадекватно влияет... Почтовик летает, отчеты проседают до жути.
Индексы надо отребилдить вручную, статистику собрать через analyze. Встроенным заданиям верить не надо, кроме проведения актов и сбора мусора они ничего толком не умеют.
Прочитал ветку и не понял, что проседает-то? Проц? Винты? Планы бы посмотреть. То, что ты выбрал в начале - неудачный пример.
 
19.11.2008 10:01  
dmware
Цитата:
Сообщение от OlegON
...
Индексы надо отребилдить вручную, статистику собрать через analyze. Встроенным заданиям верить не надо, кроме проведения актов и сбора мусора они ничего толком не умеют.
Прочитал ветку и не понял, что проседает-то? Проц? Винты? Планы бы посмотреть. То, что ты выбрал в начале - неудачный пример.
При выборке, например, приходных накладных за некоторый период, процесс oracle.exe - 87-100%, обращение к винту, на котором лежат userx.dbf, к индексам обращения практически нет (2-10%) и очень долго формируется результат: против обычных секунд - долгие минуты.
В настоящий момент занялся перестройкой индексов по таблицам с документами...
Перестроил вручную на smspec - больше не успел - запустил пользователей - вечером продолжу...
после перестройки (а еще пересоздал первичный ключ, внешние ключи...) собрал статистику вручную (все так же):
begin
dbms_stats.gather_schema_stats (
ownname => 'SUPERMAG',
cascade => TRUE,
estimate_percent => dbms_stats.auto_sample_size,
method_opt=>'for all columns size auto'
);
end;
пока все по-прежнему...
сейчас наблюдаю обращение к юзерс - 100%, индексы тоже задействованы... такое ощущение, что действительно по какой-то из таблиц, в которой информация с документами, проблема с индексами... остальные то разделы замечательно работают...
 
19.11.2008 10:07  
dmware
во время выполнения выборки из своей сессии посмотрел самый массивный запрос:
Код:
SELECT --+ FIRST_ROWS
 DH.ID as ID, DH.CreatedAt, CL.Name as ClientName, DH.LocationTo, DH.OpCode as Operation, DH.UserOp, DH.TotalSum, DH.Debt as Payment, DH.BaseDocTypeAndID, DH.DocState, (select (select nvl(Sum(SPECV.TotalPrice), :"SYS_B_00") from Supermag.SVSpecWI SPECV where SPECV.DocType = DH.DocType and SPECV.DocID = DH.ID) - (select nvl(Sum(SVAT.TaxSum), :"SYS_B_01") from Supermag.SVSpecVatWI SVAT where SVAT.DocType = DH.DocType and SVAT.DocID = DH.ID and SVAT.TaxRate > :"SYS_B_02") from Dual) as TotalSumNoVat, (select nvl(Sum(SVAT10.TaxSum),....
отсюда обращение к представлениям, за которыми стоят указанные таблицы...
SVSpecWI(SLSPECQMISMATCH, SMCARD, SMCOMMONBASES, SMSPECCOMPINF, SMSPECIO)
SVSpecVatWI(SMSPECTAX, SMTAXIDENTITY)
SVInsertedDocsWI (SMDOCBLOBFILES)
SVDocumentsWI (SMDOCTAX, SMDOCUMENTS, SMPARTNERUSERLOC, SMTAXIDENTITY, SMWAYBILLSIN)

наверное следует для них вручную пересоздать индексы и посмотреть, что из этого получится?
еще хотел отметить достаточно быструю выборку документов, ассоциированных с артикулом в карточке товара (раздел документы). а ведь там документы разных типов... возможно выборка в этих разделах ведется из разных таблиц
 
19.11.2008 10:36  
dmware
Цитата:
Сообщение от OlegON
статистику собрать через analyze
только сейчас заметил - пропустил.. попробую сделать так
 
19.11.2008 10:42  
Mtirt
Тогда еще заодно и
ANALYZE TABLE problem_table VALIDATE STRUCTURE CASCADE OFFLINE
 
20.11.2008 13:09  
baggio
а ктонить такое видел..
1.26.1. SP4

SQL*Loader: Release 9.2.0.8.0 - Production on Чтв Ноя 20 12:54:53 2008

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Управляющий файл: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PathFinder_FFMapOutIn0.CTL
Файл данных: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PathFinder_FFMapOutIn0.DAT
Строка опций обработки файла: "fix 123"
Файл плохих записей: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PathFinder_FFMapOutIn0.bad
Файл удаленных записей: ничего не задано

(Разрешить удалять все записи)

Количество записей для загрузки: ALL
Количество записей для пропуска: 0
Допускается ошибок: 0
Продолжение: ничего не задано
Использован маршрут: Прямой
Бесшумные режимы: FEEDBACK, ERRORS и DISCARDS

Таблица SUPERMAG.FFMAPOUTIN, загружен из каждой логической записи.
Режим вставки действует для этой таблицы: INSERT

Имя столбца Позиция Дл. Огр. Вкл Тип данных
------------------------------ ---------- ----- ---- ---- ---------------------
INCOMEDOC FIRST 4 INTEGER
INCOMEITEM NEXT 4 INTEGER
SALEDOC NEXT 4 INTEGER
SALEITEM NEXT 4 INTEGER
QUANTITY NEXT 8 DOUBLE
ARTICLE NEXT 50 CHARACTER
SALEOP NEXT 2 SMALL INTEGER
INCOMEOP NEXT 2 SMALL INTEGER
SALEDATE NEXT 8 DATE YYYYMMDD
INCOMEDATE NEXT 8 DATE YYYYMMDD
FORCEDMAPPING NEXT 1 CHARACTER
INCOMEQ NEXT 8 DOUBLE
INCOMETOTALSUM NEXT 10 PACKED DECIMAL (19, 4)
INCOMETOTALNOVAT NEXT 10 PACKED DECIMAL (19, 4)

SQL*Loader-929: Ошибка при синтаксическом анализе команды вставки для таблицы SUPERMAG.FFMAPOUTIN.
ORA-01031: привилегий недостаточно
 
20.11.2008 13:19  
kadr
такое видели ещё 2 года назад вот тут
 
20.11.2008 13:31  
dmware
Цитата:
Сообщение от Mtirt
Тогда еще заодно и
ANALYZE TABLE problem_table VALIDATE STRUCTURE CASCADE OFFLINE
после этой проверки, которая продолжалась много часов, а также пересоздания индексов для таблиц, которые участвуют при выборке документов (выше) ничего разительно не изменилось.
статистка была собрана, также пробовал ее удалять.
взял два запроса:
1-й участвует при выборке накладных,
2-й - тот, что используется в карточке товара (из сессии)
таблицы те же самые. только второй отрабатывает за секунды даже при большом интервале.
в первом участвуют представления.
по дискам видно, что во втором задействуются индексы.
на настоящий момент идей нет никаких, кроме как удалить представления, создать их заново (просто еще не успел)
сейчас идет расчет себестоимости, который продолжается уже почти 11 часов (операция переноса остатков)
 
 


Опции темы



Часовой пояс GMT +3, время: 23:28.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.