[ОТВЕТИТЬ]
20.01.2009 10:50
mighty
 
Привет всем! Позавчера переехал на Win2003x64 и Oracle 10.2.0.4x64
Сервак: Xeon x2 3.20Гц, Озу - 8Г.
Супермаг 1.026.3
Офис. База весит 101Гб, (23 магазина), документов 1861623, строк спецификаций 47248674.
Параметры оракла в прицепе Params.zip, выкинул в эксель чтобы было удобнее смотреть.
Все таблспейсы находятся на одном RAID диске(зеркалка), индексы в отдельном таблспейсе SM_INDEX, аналитика в SM_ANAL, оперативка в SM_OPER. Таблицы FFMAPREP и SMDocuments партиционированы по дате(по месяцам).
Проблемы:
1) Себестоимость не рассчитывается - полный перенос либо зависает либо идет около 8-10 часов. Себестоимость рассчитывается 5 часов.
2) Тормозят отчеты в аналитической базе, запрос
select sum(decode(f.saletype,'CR',-f.salesum,f.salesum)) realiz from supermag.ffmaprep f where f.rectype=1 and f.saletype in ('CR','CS')
and f.saledate>=to_date('20.01.2008','DD.MM.YYYY')
and f.saledate<=to_date('19.01.2009','DD.MM.YYYY')
and f.article in ( select c.article from supermag.smcard c where c.accepted<>-1 )
отрабатывает от 14 до 25 минут
3) тормозит наценивание документов и создание автозаказа.
4) Файл подкачки на диске С:\pagefile.sys=2G, Процесс Oracle.exe в Диспетчере задач показывает занимаемую физическую память 200Мб, виртуальную 5,3Г
Я уже ничего не понимаю..

Поделитесь опытом как изначально установить параметры памяти чтобы потом можно было отслеживать узкие места и при этом максимально отдать ораклу память. Олег у тебя много опыта, какие пораметры в 10ке у меня неверно выставлены?
Вложения
Тип файла: zip Params_all.ZIP (18.7 Кб, 157 просмотров)
20.01.2009 11:07
deucel
 
Лучше только те, которые установлены.

Код:
SELECT p.NAME, p.VALUE
  FROM v$parameter p
 WHERE p.isdefault = 'FALSE'
По поводу 'тормозит' - попробуй собрать статистику.
Желательно как здесь советовал - https://olegon.ru/showpost.php?p=36353&postcount=7
20.01.2009 11:51
mighty
 
Цитата:
deucel Лучше только те, которые установлены.
По поводу 'тормозит' - попробуй собрать статистику.
Желательно как здесь советовал - https://olegon.ru/showpost.php?p=36353&postcount=7
Обновил вложение в первом посте - там и параметры по твоему запросу и параметры которые не пустые и все параметры(3 файла)
По поводу статистики, спасибо, попробую сделать это вечером когда нагрузка спадет с базы, но статистика рассчитывалась вчера в 22:00 смотрел по DBA_ALL_TABLES..
Статистика это способ оптимизации скорее уже на настроеной базе, то есть когда параметры памяти и оракла распределены верно, а у меня неверно, мне конечно больше бы надо совет по настройке паарметров оракла..Спасибо.
20.01.2009 11:59
Arsen
 
У тебя larg_pool=0, shared_pool=0, и db_cach_size=0,
если у тебя 8гигов ОЗУ то почему не используешь?
у меня тоже месяц назад был такой переход.

ставь db_cache_size=4-5G, shared_pool=1G, larg, pool=512-1G,
db_file_multiblock_read_count=64
20.01.2009 12:24
OlegON
 
Принципиально неправильный подход - копировать у других конфигурацию. Начиная с размера блоков и заканчивая сильными местами сервера все может быть разным. Совета по настройке общего нет - иначе бы просто список параметров давно тут на заглавной странице висел.

Цитата:
SQL> select sum(decode(f.saletype,'CR',-f.salesum,f.salesum)) realiz from supermag.ffmaprep f where f.rectype=1 and f.saletype in ('CR','CS')
2 and f.saledate>=to_date('20.01.2008','DD.MM.YYYY')
3 and f.saledate<=to_date('19.01.2009','DD.MM.YYYY')
4 and f.article in ( select c.article from supermag.smcard c where c.accepted<>-1 );

REALIZ
----------
1009232741

Elapsed: 00:01:16.23
документов 602335
строк спецификаций 51565538
пользователи вовсю фигачат сейчас отчеты, перенос - 5-7 минут, расчет 1.50-2.00 (считается на отдельной слабой машинке с почтовиком), 51 действующий магаз, 72 МХ в системе.
Ориентируйся на это, наверное. Процы слабее твоих, кстати. С ними проблема :(
20.01.2009 12:54
mighty
 
Олег, а ты мне можешь выложить свою конфигурацию паарметров Оракла - полную? я по каждому параметру разберусь, твоя буза примерно как и моя, только у меня чуть меньше. Сколько у тебя памяти и оракл какой версии? Если не хочешь на форуме выкладывать то кинь мне на mighty#mail.ru&? Пжалста...
У меня стоят автоматические параметры распределения памяти, поэтому параметры которые привел Arsen у меня занулены. Кстати а что лучше ручное выставление или автоматическое? всмысле достаточно ли оракл оптимально распределяет память или лучше самому все прописывать?
20.01.2009 13:22
Arsen
 
[QUOTE=mighty;38659]
4) Файл подкачки на диске С:\pagefile.sys=2G, Процесс Oracle.exe в Диспетчере задач показывает занимаемую физическую память 200Мб, виртуальную 5,3Г

вот смотри при автомэ распред. памяти оракл занимает у тебя 200 МБ-ов ОЗУ, но ты сможешь сам настроить его, хотя увеличь кеш буфера.
кстати сколько сейчас показывает оракл?
20.01.2009 14:59
deucel
 
Цитата:
OlegON Принципиально неправильный подход - копировать у других конфигурацию. (
Согласен, но все же
давай использовать возможности 10ки
поскольку pga_aggregate_target у тебя выставлен, тебе не хватает
Код:
ALTER SYSTEM SET workarea_size_policy = "AUTO" SCOPE=BOTH
но думаю стоит пока уменьшить до 1Гб (у тебя всего 8Гб памяти)
Код:
ALTER SYSTEM SET pga_aggregate_target = 1G SCOPE=SPFILE
раз у тебя 10.2.0.4, то и
Код:
ALTER SYSTEM SET compatible = '10.2.0.4.0' SCOPE=SPFILE
убери sga_max_size
Код:
ALTER SYSTEM RESET sga_max_size SCOPE=SPFILE SID='*'
явно завышен sga_target, давай для начала 3Гб (будет оставаться память, прибавишь)
Код:
ALTER SYSTEM SET sga_target = 3G SCOPE=SPFILE
с optimizer_mode = CHOOSE мож поспешил, оставь пока по умолчанию
Код:
ALTER SYSTEM RESET optimizer_mode SCOPE=SPFILE SID='*'
20.01.2009 15:13
deucel
 
не заметил у тебя параметра O7_DICTIONARY_ACCESSIBILITY ?!

Код:
ALTER SYSTEM SET O7_DICTIONARY_ACCESSIBILITY = TRUE SCOPE=BOTH
20.01.2009 15:54
mighty
 
Так и есть (O7_DICTIONARY_ACCESSIBILITY=TRUE),
workarea_size_policy = "AUTO".
Я ничего кроме убиения статистики и запуска нового сбора пока еще не попробовал, сейчас идет сбор статистики и в памяти процесс Oracle.exe -540Мб, виртуальная память - 5,4Гб.

Еще заметил что после апдейта версий СМ у меня некоторые таблицы FF создались в оперативной базе(таблспейсе), у некоторых стал LOGGING=YES...Сегодня приведу все таблицы в соотвествие..
20.01.2009 16:05
Arsen
 
советую статистику собрать не средствами СМ, а пакетом DBMS_STATS
21.01.2009 01:22
orekhov
 
Бездумно использовать DBMS_STATS не рекомендую. Например, сталкивались с тем, что собранная по временным таблицам статистика приводила к изменению планов запросов и соответственно к существенному увеличению времени выполнения некоторых отчётов. Если не уверены в том, что делаете - использование штатных средств Супермага выглядит более оправданным.
21.01.2009 10:16
kadr
 
Цитата:
OlegON документов 602335
строк спецификаций 51565538
пользователи вовсю фигачат сейчас отчеты, перенос - 5-7 минут, расчет 1.50-2.00 (считается на отдельной слабой машинке с почтовиком), 51 действующий магаз, 72 МХ в системе.
Ориентируйся на это, наверное. Процы слабее твоих, кстати. С ними проблема :(
Гляжу на такое время и наворачивается скупая мужская слеза ностальгии, у меня сравнимый порядок документов был на 01.01.2006.
Сейчас (пока 9ый оракель 32 бита на SLES, но уже заканчивается тестирование нового сервера под 10-кой 64 бита на Gentoo, если не забудется приведу здесь данные после переезда)

документов 5 515 580
строк спецификации 220 795 409
порядка 30-ти активных пользователей, в течении дня порядка 60-ти
Расчёт ТД 2 раза в неделю
перенос (доки за 3 дня) 1-40
расчёт 17-18 часов.
21.01.2009 10:31
OlegON
 
kadr, а запрос его прогони?
21.01.2009 10:34
kadr
 
Цитата:
OlegON kadr, а запрос его прогони?
я его запустил, пока писал он не отработал, сейчас отработал

в итоге 2881,613 сек. :(
21.01.2009 11:19
mighty
 
Олег дай мне пожалуйста все твои параметры из V$PARAMETERS, ничего у меня не получается - полный сбор статистики с CHOOSE вчера штатными средствами СМ+ длился 10 часов (на 9-ке 32 разрядой 4 часа сбор шел)
перенос начался в 23:00, сегодня утром в 9:00 я его отключил - пользователям надо работать а та всего 80% перенеслось, жуть просто..
Поставил оптимизатор на ALL_ROWS, сегодня попробую еще раз..
Но задом чувствую не в нем дело - дело в настройках базы и памяти конкретно..
21.01.2009 13:37
Arsen
 
А таблицы аналитики партиционированы?
21.01.2009 15:21
mighty
 
Да FFMAPREP по периоду..
22.01.2009 15:51
OlegON
 
Цитата:
select sum(decode(f.saletype,'CR',-f.salesum,f.salesum)) realiz from supermag.ffmaprep f where f.rectype=1 and f.saletype in ('CR','CS')
and f.saledate>=to_date('20.01.2008','DD.MM.YYYY')
and f.saledate<=to_date('19.01.2009','DD.MM.YYYY')
and f.article in ( select c.article from supermag.smcard c where c.accepted<>-1 )
Код:
-----------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name              | Rows  | Bytes | Cost  | Pstart| Pstop |
-----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                   |     1 |    75 |     2 |       |       |
|   1 |  SORT AGGREGATE                       |                   |     1 |    75 |       |       |       |
|   2 |   NESTED LOOPS                        |                   |     1 |    75 |     2 |       |       |
|   3 |    PARTITION RANGE ITERATOR           |                   |     1 |    66 |     1 |     3 |     7 |
|   4 |     PARTITION LIST INLIST             |                   |     1 |    66 |     1 |KEY(I) |KEY(I) |
|   5 |      TABLE ACCESS BY LOCAL INDEX ROWID| FFMAPREP          |     1 |    66 |     1 |   KEY |   KEY |
|   6 |       BITMAP CONVERSION TO ROWIDS     |                   |       |       |       |       |       |
|   7 |        BITMAP INDEX RANGE SCAN        | FFMAPREP_SALEDATE |       |       |       |   KEY |   KEY |
|   8 |    TABLE ACCESS BY INDEX ROWID        | SMCARD            |     1 |     9 |     1 |       |       |
|   9 |     INDEX UNIQUE SCAN                 | SMCARD_PK         |     1 |       |     1 |       |       |
-----------------------------------------------------------------------------------------------------------
22.01.2009 18:23
mighty
 
Так у тебя FFMAPREP по типу доукумента что ли партиционирован? А индексы FFMAPREP тоже партиционированы?
Олег, мне стоит надеяться что увижу твои параметры? Я запутался совсем, собрал статистику по ALL_ROWS(9 часов собиралась), стал себестоимость штатными супермаговским административным модулем считать с полным переносом - результат 1% за 9,5 часов..бред какой - то..Приэтом операторы говорят что если с СУПЕРМАГом работуют 3-4 человека то она работает быстро..
Сегодня базу офиса залил к себе на ноутбук, дома буду её пытаться настроить, 4г памяти это конечно не 8 как в офисе, но все же, что - то похожее..
23.01.2009 08:17
Arsen
 
а у тебя индексы ffmaprep не портицинированы?
23.01.2009 10:20
OlegON
 
Параметры не выкладываю, потому, что до того, как люди поняли, что за базой надо грамотно ухаживать, ее оптимизировала какая-то тетя, которая меняя параметры, spfile превратила в помойку, не хочу выглядеть бездарем. И еще раз повторюсь, уповать на то, что параметры тебя спасут - безнадежно. Как говорится параметра fast=true не существует. Я тебе привел план твоего запроса, учитывая, что у меня он отстреливает, тебе предлагается добиться такого же. План перед глазами. 10.2.0.4 - хороший выбор. Более того, в отличие от ранних версий 10ки, теперь я всех призываю переводить свои офисные базы на нее. Действительно, есть возможность ускорить многое. Обнаружил фичу, которая позволила мне время переноса ТД с 35 минут скостить до 7 минут (это не кнопка, это комплекс). В 9ке ее нет. Предупреждаю, что не все версии СМ на 10ке работают, но патч для работы СМ на 10ке, выданный в какой-то 25-26й версии (какой-то пакет для расчета статистики по кассовым докам), можно наложить и на более древнюю и все бегает, я тут писал - пользуйся. Рассказывать, как оптимизировать базу полностью и в деталях - не буду, извини, во первых это долго, во-вторых, это мое ноу-хау, я за это деньги получаю, потратив ОЧЕНЬ много времени на изучение, вместо того, чтобы тратить его на своих близких. Да и смысла никакого нет, сказав а, говори и б, вопросы потянутся чередой без какой-либо отдачи.
23.01.2009 11:38
mighty
 
Я тебя понял, я тоже трачу на работу по 15 часов в сутки, без выходных, просто пока не получается сделать так как я хочу..
Рассказывать как оптимизировать тоже не надо, мне только параметры были нужны я бы сам разобрался. За план спасибо, если есть желание рассказать про "комплекс", то расскажи. Так то я помощи просил, а не показать, как у тебя все просто офигительно летает..Это больше на рекламу себя похоже чем на помощь. То что ты профессионал, это все знают, рекламировать не надо. Сорря уж за оффоп.
23.01.2009 22:23
OlegON
 
Я трачу на работу больше 15 часов :) И еще больше не хочу, чего и тебе желаю. Помощь я тебе предлагал месяца два назад, ты сказал, что она тебе не нужна. Самая правильная помощь - правильный план. Я себя профи не называю, косячу не меньше остальных и чем больше узнаю, тем больше вижу, как много не знаю. Если ты доверяешь моему опыту, то еще раз, в последний, не начинай с параметров базы, если она раньше вообще шевелилась с ними. Начни с того, почему у тебя не такой план. Я сейчас просто физически не могу вспомнить, что я делал с базой, я ее шлифовал месяца два.
24.01.2009 12:33
mighty
 
Еще раз подскажи - у тебя как у тебя партиционированы таблицы FFMAPREP? Какие таблицы еще ты разбивал, и вопросик остался висеть по индексам - есть ли прирост выборок, если партиционировать индексы по FFMAPREP.
Короче стал разбираться со структурой таблиц..PL\SQL Developer показывает наличие Check'ов каких то странных на практически всех таблицах, типа SYS00340932 - sys.dbms_metadata.get_dll их не показывает, а PL\SQL Developer откуда-то знает. Возможно что они появились при отключениях света которые у нас были в декабре, по 3-4 часа и при автовосстановлении Оракла, потому что именно тогда себестоимость стала "тормозить" в переносе и расчете. Сегодня приведу таблицы FF% в соотвествие с эталонной базой созданной генератором и попробую рассчитать себестоимость..

ЗЫ: по поводу планов..надо статистику рассчитывать, а она считается 10 часов против 4 как было..это очень странно..скорее всего еще и индексы поехали в таблицах..
24.01.2009 12:58
mighty
 
Создал генератором чистую базу 1.026.3 - там этих левых чеков SYS_C001203 просто немерянно на кажой таблице..Стал разбираться эксперементируя с опциями таблиц - это оказывается если у поля опция NOT NULL то создается чек-констрайнт с таким "левым" наименованием SYS_C0032323
Значит не в них дело :-/
24.01.2009 16:15
Arsen
 
знаешь я тут спомнил, когда я портиционировал таблицы аналитики, то у меня перенос(полный 616000 доков) делал за 25 часов, а перед partitioning-ом за 1.5 часов. С+ посоветовал портиционировать и индексы, сделал и начал перенести уже за2 часа, и т.к улучшение не было я отказался от этого.
У меня сейчас база 92 гигов, SGA=7GB, PGA 808 MB(надо увеличить), и после того как как перешел на 10x64, то перенос проходит за 3 минуты(инкремент) а расчет за 45 минут, и юзеры сообщают, что производительность значительно увеличилось.

Если хочешь могу дать мои параметры, но Олег прав, тут дело не только в параметрах.

Кстати трасируй сесию оракла во время переноса и смотри файл, там очень многое можно найти.
24.01.2009 16:31
OlegON
 
SYS00340932 - забей, это действительно из-за констрейнтов. Более того, если вручную начнешь их создавать, почтовик начнет материться. Как я бил FFMAPREP я тут описывал где-то, индексы тоже бил. Почему бы и нет? Еще разбивал smspec, но не надо этого делать, просто влом собирать обратно.
25.01.2009 05:57
isi
 
Цитата:
OlegON SYS00340932 - забей, это действительно из-за констрейнтов. Более того, если вручную начнешь их создавать, почтовик начнет материться. Как я бил FFMAPREP я тут описывал где-то, индексы тоже бил. Почему бы и нет? Еще разбивал smspec, но не надо этого делать, просто влом собирать обратно.
Почему так решил по поводу smspec, я как раз думал его побить
25.01.2009 10:26
OlegON
 
Цитата:
isi Почему так решил по поводу smspec, я как раз думал его побить
Да никакого выигрыша не обнаружил, просто повозился... По индексу нормально отстреливает. Правда давно это было. Может сейчас как-то бы и проявилось. Бил по докам.


Опции темы


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

 

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