Ошибка при расчете себестоимости : Супермаг Плюс (Супермаг 2000)

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

решение на пятой странице. мне оно никак вроде бы и не подходит, или же я просто не углядел пока

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

попробуй в параметрах БД

optimizer_index_caching = 90
optimizer_index_cost_adj = 10

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

Если сервера хватает - то похоже проблемы в параметрах БД (initDBname.ora)
если не сложно - покажи, мож чего посоветуем.

вчера пришел именно к этому... причем увеличение производительности было отмечено. но только на выборке документов и очень незначительное.

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

правда до этого (до операции экспорта/импорта) все было именно так и работало неплохо.
еще параметр db_file_multiblock_read_count с 24 до 16

*.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'

не считая остального - твоя проблема в

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

поставь стандартный 'EXACT'

ну или к примеру на магазинах у меня для CPU c HT и 1Гб памяти

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

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

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

я бы прибавил *.sort_area_size=65536
до метра хотябы...
и
*.log_buffer=10485760 ...