[ОТВЕТИТЬ]
04.05.2010 10:13
leonid
 
Разделил базу ЦО на оперативную и на аналитическую. Два сервера.
На оперативной базе проблемы с производительностью все равно иногда всплывают. Иногда время отклика в интерфейсе Супермага увеличивается.

Собрал по оперативной базе Stats Report.
Получил рекомендацию по параметрам:

Код:
Init.ora Parameters	 
Parameter	Value	 
db_16k_cache_size	16MB	 
db_block_size	8,192 	 
db_cache_size	1,008MB	 
db_file_multiblock_read_count	16 	 
db_keep_cache_size	1,008MB	 
optimizer_index_caching	90 	 
optimizer_index_cost_adj	20 	 
optimizer_mode	all_rows 	 
pga_aggregate_target	599MB	 
shared_pool_size	224MB	 
workarea_size_policy	auto 	 
_optimizer_cost_model	choose	 
session_cached_cursors	50	 
cursor_sharing	exact
Цитата:
1 Recommendations:
You are using the default optimizer mode and you may consider setting it to first_rows or first_rows_n if you have an online transaction processing system.
Кто-нибудь пробовал для оперативной базы выставлять optimizer_mode в first_rows или first_rows_n?
Цель - уменьшить время отклика интерфейса СМ.

Сайт для анализа репортов:
04.05.2010 10:37
John Doe
 
К сожалению, г-н Бурлесон ошибается. К еще большему - достаточно часто. Если посмотришь, достаточно часто в супермажных запросах хинты first_rows проскакивают в нужных местах. Опции fast=true так и не придумали. Что значит твое разделение на два сервера? Опция в админе? Что именно у тебя тормозит в интерфейсе, что ты собираешься ускорять? Подход должен быть комплексный.
04.05.2010 10:44
leonid
 
Цитата:
John Doe К сожалению, г-н Бурлесон ошибается. К еще большему - достаточно часто.
- звучит впечатляюще.

Два сервера - каждую ночь БД ЦО копируется на второй (физически) сервер. Отчеты крутятся на нем не нагружая оперативную БД.
04.05.2010 10:49
John Doe
 
Неплохой подход, но, осознавая, что ресурсы можно делить ресурс-менеджером, а в оперативной работе встречается куча ресурсоемких операций вроде проставлений цен последнего прихода, я бы предпочел из двух серверов собрать один. Но это надо смотреть в каждом конкретном случае.
Тормозит-то что?
04.05.2010 11:24
leonid
 
Мне просто показался правильным совет
Цитата:
1 Recommendations:
You are using the default optimizer mode and you may consider setting it to first_rows or first_rows_n if you have an online transaction processing system.
вот я и решил спросить.
Сейчас я сделал вывод, что многие запросы интерфейса СМ захинтованы, по этому смысла трогать этот параметр нет.
Вопрос был из познавательных целей, спасибо за ответ.
04.05.2010 13:03
Propil
 
leonid, о какой версии Oracle идет речь?
04.05.2010 13:34
leonid
 
Oracle 10.2.0.4 64bit на Винде
04.05.2010 14:28
Propil
 
а железо?
может, лучше оперативки добавить..
Цитата:
shared_pool_size 224MB
это лучше отдать на откуп самому ораклу решать
как и db_file_multiblock_read_count
04.05.2010 14:45
leonid
 
В 10G при workarea_size_policy = auto shared_pool_size в файле параметров ни на что не влияет, Оракл сам все решает.

А вот db_file_multiblock_read_count - параметр странный. Его изменение влияет на настройку Оптимизатора (Cost Based Optimizator). Чем он больше, тем выше цена full scan. Но и заниженное значение, как я понимаю, увеличивает количество чтений с диска. По умолчанию 16.
Кто как понимает этот параметр и что думает о его настройке?

У меня сервер MS Serv 2003 32 bit, как я понимаю, он не будет сам использовать память выше 2G, как с этим бороться, я не знаю, может подскажете?
04.05.2010 14:53
John Doe
 
Цитата:
leonid В 10G при workarea_size_policy = auto shared_pool_size в файле параметров ни на что не влияет, Оракл сам все решает.
Напутал ты теплое с мягким. Рекомендую еще раз перечитать доку. Даже с какого конца начинать возражать не знаю.
Цитата:
leonid А вот db_file_multiblock_read_count - параметр странный. Его изменение влияет на настройку Оптимизатора (Cost Based Optimizator). Чем он больше, тем выше цена full scan.
Наоборот, чем меньше, тем выше цена.
Цитата:
leonid У меня сервер MS Serv 2003 32 bit, как я понимаю, он не будет сам использовать память выше 2G, как с этим бороться, я не знаю, может подскажете?
С чем? У тебя, вроде, всего 2Гб? Поставь любую из 64-битных систем.
04.05.2010 15:11
Propil
 
вот наш сервер:
Win 2003 32-битная
Oracle 10g
оперативка - 4 гиг
в boot.ini выставил ключи /3gb /PAE
в оракле выставил max SGA size- 2304 Mb
PGA~ 300 Mb
В итоге - процесс oracle.exe отъедает 2,438 Gb оперативки
04.05.2010 15:48
leonid
 
Про авто менеджмент памяти в торопях попутал, сори.
(workarea_size_policy - управляет памятью для сортировки)
Ну да суть не в этом, Авто менеджмент памяти у меня включен, shared_pool Оракл выбирает сам.
(В файле написано 224MB,
select value from v$parameter where name='shared_pool_size';
VALUE
--------------------------------------------------------------------------------
0
)

Про db_file_multiblock_read_count я хотел сказать следующее:
Цитата:
так как слишком большое значение увеличит количество полных просмотров (full scan), а слишком маленькое значение увеличит использование индексов, даже в тех случаях, где полный просмотр таблиц был бы более эффективен.


Памяти попробую добавить
Опции темы


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

 

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