[ОТВЕТИТЬ]
Опции темы
17.11.2008 16:25  
dmware
Цитата:
Сообщение от Mihon
Чувствую, что не в тему ляпну, но все-же:
Может быть, запустить задания на пересоздание индексов в Адм. модуле?
У нас как-то были тормоза дикие, решилось запуском заданий...

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

решение на пятой странице. мне оно никак вроде бы и не подходит, или же я просто не углядел пока
 
18.11.2008 07:44  
dmware
повозился с параметрами оптимайзера... в результате несколько уменьшилось время выборки документов. но по-прежнему очень долгие апдейты.. например, клиентский модуль практически умирает на некоторое время при смене статуса документа.
расчет себестоимости вылетел с той же ошибкой...
что делать?
 
18.11.2008 10:25  
deucel
Цитата:
Сообщение от dmware
прихожу к выводу, что оракл по собственной инициативе решает, что обращение не по индексу будет перспективней в плане скорости...
попробуй в параметрах БД

optimizer_index_caching = 90
optimizer_index_cost_adj = 10

последний параметр можно при необходимости опускать еще, но лучше не стоит - будет вылазить в других местах.
 
18.11.2008 10:29  
deucel
Цитата:
Сообщение от dmware
повозился с параметрами оптимайзера... в результате несколько уменьшилось время выборки документов. но по-прежнему очень долгие апдейты.. например, клиентский модуль практически умирает на некоторое время при смене статуса документа.
расчет себестоимости вылетел с той же ошибкой...
что делать?
Если сервера хватает - то похоже проблемы в параметрах БД (initDBname.ora)
если не сложно - покажи, мож чего посоветуем.
 
18.11.2008 13:18  
dmware
Цитата:
Сообщение от deucel
попробуй в параметрах БД

optimizer_index_caching = 90
optimizer_index_cost_adj = 10

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

первоначальные установки:
optimizer_index_caching = 0
optimizer_index_cost_adj = 70

правда до этого (до операции экспорта/импорта) все было именно так и работало неплохо.
еще параметр db_file_multiblock_read_count с 24 до 16
 
18.11.2008 13:34  
dmware
Цитата:
Сообщение от deucel
Если сервера хватает - то похоже проблемы в параметрах БД (initDBname.ora)
если не сложно - покажи, мож чего посоветуем.
*.compatible='9.2.0.0.0'
*.control_files='R:\ORACLE\ORADATA\DBCOSTR\CONTROL01.CTL','T:\ORACLE\ORADATA\DBCOSTR\CONTROL02.CTL'
*.core_dump_dest='c:\oracle\admin\dbcostr\cdump'
*.cursor_sharing='SIMILAR'
*.db_block_checksum=FALSE
*.db_block_size=8192
*.db_cache_advice='OFF'
*.db_cache_size=1543503872
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_keep_cache_size=268435456
*.db_name='DBCOSTR'
*.db_writer_processes=4
*.dispatchers='(PROTOCOL=TCP) (SERVICE=dbcostrXDB)'
*.fast_start_mttr_target=300
*.hash_join_enabled=TRUE
*.instance_name='DBCOSTR'
*.java_pool_size=33554432
*.job_queue_processes=10
*.large_pool_size=8388608
*.log_buffer=524288
*.O7_DICTIONARY_ACCESSIBILITY=TRUE
*.open_cursors=200
*.optimizer_index_caching=90
*.optimizer_index_cost_adj=10
*.optimizer_mode='CHOOSE'
*.parallel_automatic_tuning=TRUE
*.pga_aggregate_target=301989888
*.processes=300
*.query_rewrite_enabled='FALSE'
*.remote_login_passwordfile='EXCLUSIVE'
*.session_cached_cursors=100
*.sga_max_size=2207330416
*.shared_pool_size=201326592
*.sort_area_size=65536
*.star_transformation_enabled='FALSE'
*.timed_statistics=TRUE
*.undo_management='AUTO'
*.undo_retention=10800
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='c:\oracle\admin\dbcostr\udump'
 
18.11.2008 13:50  
deucel
не считая остального - твоя проблема в

Цитата:
Сообщение от dmware
*.cursor_sharing='SIMILAR'
он отрабатывает также как и 'FORCE'

поставь стандартный 'EXACT'
 
18.11.2008 13:56  
deucel
ну или к примеру на магазинах у меня для CPU c HT и 1Гб памяти

Код:
*.background_dump_dest='D:\oracle\oradata\DBname\bdump'
*.compatible='9.2.0.8.0'
*.control_files='D:\oracle\oradata\DBname\control01.ctl','D:\oracle\oradata\SEMIL01\control02.ctl','D:\oracle\oradata\DBname\control03.ctl'
*.core_dump_dest='D:\oracle\oradata\DBname\cdump'
*.cpu_count=1
*.db_block_checksum=FALSE
*.db_block_size=8192
*.db_cache_size=268435456
*.db_domain=''
*.db_file_multiblock_read_count=64
*.db_name='DBname'
*.db_writer_processes=1
*.dbwr_io_slaves=2
*.fast_start_mttr_target=300
*.filesystemio_options='SETALL'
*.instance_name='DBname'
*.job_queue_processes=5
*.log_buffer=10485760
*.max_dump_file_size='1024'
*.O7_DICTIONARY_ACCESSIBILITY=TRUE
*.optimizer_index_caching=90
*.optimizer_index_cost_adj=10
*.parallel_automatic_tuning=TRUE
*.pga_aggregate_target=134217728
*.pre_page_sga=TRUE
*.processes=100
*.remote_login_passwordfile='EXCLUSIVE'
*.shared_pool_size=134217728
*.timed_statistics=TRUE
*.transactions_per_rollback_segment=1
*.undo_management='AUTO'
*.undo_retention=10800
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='D:\oracle\oradata\DBname\udump'
*.workarea_size_policy='AUTO'
 
18.11.2008 14:19  
dmware
Цитата:
Сообщение от deucel
не считая остального - твоя проблема в



он отрабатывает также как и 'FORCE'

поставь стандартный 'EXACT'
а как же (цитата - с установленным параметром CURSOR_SHARING=EXACT (устанавливается по умолчанию) для каждого уникального SQL-оператора, который я выполняю, в представлении V$SQL создается новая запись – выполняется полный разбор оператора и для него создается новый план выполнения. В разделяемом пуле могут находиться сотни и тысячи очень похожих запросов, которые отличаются только литералами, используемыми в SQL-операторах. Это означает, что в приложении не используются переменные связывания, и это также означает, что сервер базы данных вынужден выполнять полный разбор практически каждого запроса, который, в свою очередь, не только потребляет много процессорного времени...

и вот тоже ( Здесь видно, что для EXACT сколько запросов (отличающихся только литералом) мы будем выполнять, столько и будет полных разборов, построений планов. Таких запросов в системе может быть на столько много, что сервер не сможет справиться с их разбором.
При прочих значениях параметра сursor_sharing, можно наглядно видеть, что только один запрос находиться в shared pool. И все сессии могут использовать план этого запроса. То есть полный разбор, построение плана производится один раз, а выполняется – много раз. Следствием этого является уменьшение количества полных разборов (они превращаются в частичный). А это значит, что потребляется меньше ресурсов (процессорное время, конкуренция в библиотечном кеше, размер разделяемого пула,…), производительность растет...

разве с параметром EXACT наоборот не упадет производительность? конечно же я поэкспериментирую - мне больше ничего не остается. но все таки?
хотя, с другой стороны - для запросов не подменяются планы...
 
18.11.2008 14:43  
baggio
я бы прибавил *.sort_area_size=65536
до метра хотябы...
и
*.log_buffer=10485760 ...
 
 


Опции темы



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

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