Временные таблицы и не только. Тормоза базы

azzy
Дата: 02.12.2009 17:08:33
Собственно сабж указан в заголовке. Но подробности таковы

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

Часть обработки ведется джобами. Со вчера начали сыпаться ошибки о нехватке ресурсов Оra-04030. Часть пользователей посносили, но проблема осталась. Сегодня начались тормоза по запросам, которые в обычное время выполнялись 5-10 мин. В результате не сформированы данные пользователи вопят.

Собственно лирика вся, теперь детали:
Oracle9i Enterprise Edition Release 9.2.0.7.0 - Production
PL/SQL Release 9.2.0.7.0 - Production
CORE	9.2.0.7.0	Production
TNS for 32-bit Windows: Version 9.2.0.7.0 - Production
NLSRTL Version 9.2.0.7.0 - Production 

PFILE
*._offline_rollback_segments='_SYSSMU1$'
*.audit_trail='DB'
*.background_dump_dest='k:\oracle\admin\db\bdump'
*.bitmap_merge_area_size=2000000
*.compatible='9.2.0'
*.control_files='K:\oradata\dwh\CONTROL01.CTL '
*.core_dump_dest='k:\oracle\admin\db\cdump'
*.db_block_size=8192
*.db_cache_advice='ON'
*.db_cache_size=838860800
*.db_domain='mtbnet'
*.db_file_multiblock_read_count=128
*.db_name='dwh'
*.dblink_encrypt_login=TRUE
*.dispatchers='(PROTOCOL=TCP) (SERVICE=dbXDB)'
*.fal_server=''
*.fast_start_io_target=0
*.fast_start_mttr_target=0
*.hash_area_size=1048576
*.instance_name='db'
*.java_pool_size=100663296
*.job_queue_processes=4
*.large_pool_size=33554432
*.lock_sga=FALSE
*.log_archive_dest_1='LOCATION=I:\ora_archivelog\dwh'
*.log_archive_start=TRUE
*.log_buffer=1048576
*.log_checkpoint_interval=0
*.log_checkpoint_timeout=1800
*.log_checkpoints_to_alert=TRUE
*.max_dump_file_size='1M'
*.max_enabled_roles=92
*.max_shared_servers=3
*.open_cursors=300
*.optimizer_dynamic_sampling=2
*.optimizer_index_caching=30
*.optimizer_index_cost_adj=100
*.optimizer_max_permutations=80000
*.optimizer_mode='ALL_ROWS'
*.os_authent_prefix='OPS$'
*.parallel_automatic_tuning=TRUE
*.parallel_threads_per_cpu=4
*.partition_view_enabled=FALSE
*.pga_aggregate_target=5033164800
*.processes=90
*.query_rewrite_enabled='TRUE'
*.query_rewrite_integrity='trusted'
*.remote_archive_enable='TRUE'
*.remote_login_passwordfile='EXCLUSIVE'
*.remote_os_authent=FALSE
*.resource_manager_plan='DAILY_PLAN'
*.sessions=104
*.sga_max_size=1153433600
*.shared_pool_size=100000000
*.sort_area_size=4000000
*.standby_archive_dest=''
*.standby_file_management='AUTO'
*.star_transformation_enabled='TRUE'
*.timed_statistics=TRUE
*.transaction_auditing=FALSE
*.undo_management='AUTO'
*.undo_retention=3600
*.undo_suppress_errors=TRUE
*.undo_tablespace='UNDO'
*.use_indirect_data_buffers=FALSE
*.user_dump_dest='K:\oracle\admin\db\udump'

в алерт логе никаких ошибок кроме ошибок при работе с памятью не было. Перезагрузка сервера помогла отчасти - некоторые запросы прорвались, некоторые же запросы как выполнялись так и выполняются долго на рабочем, на тестовом все относительно неплохо.
azzy
Дата: 02.12.2009 17:13:19
azzy,

еще одно трассировка сессий, в которых выполнялись подвисшие запросы показала следующее:

*** 2009-12-02 11:32:31.748
*** SESSION ID:(17.727) 2009-12-02 11:32:31.686
WAIT #21: nam='db file sequential read' ela= 6884 p1=9 p2=5808 p3=1
WAIT #21: nam='db file sequential read' ela= 6518 p1=9 p2=1171 p3=1
WAIT #21: nam='db file sequential read' ela= 3391 p1=27 p2=311774 p3=1
WAIT #21: nam='db file sequential read' ela= 5610 p1=27 p2=995288 p3=1
WAIT #21: nam='db file sequential read' ela= 7423 p1=37 p2=364270 p3=1
WAIT #21: nam='db file sequential read' ela= 5989 p1=10 p2=239380 p3=1
WAIT #21: nam='db file sequential read' ela= 5700 p1=9 p2=177110 p3=1
WAIT #21: nam='db file sequential read' ela= 4146 p1=9 p2=772598 p3=1
WAIT #21: nam='db file sequential read' ela= 9952 p1=10 p2=155947 p3=1
WAIT #21: nam='db file sequential read' ela= 4601 p1=27 p2=27837 p3=1
WAIT #21: nam='db file sequential read' ela= 4474 p1=27 p2=306002 p3=1
WAIT #21: nam='db file sequential read' ela= 6362 p1=9 p2=675825 p3=1
WAIT #21: nam='db file sequential read' ela= 4101 p1=9 p2=845793 p3=1
WAIT #21: nam='db file sequential read' ela= 549 p1=9 p2=845794 p3=1
WAIT #21: nam='db file sequential read' ela= 4777 p1=9 p2=1033337 p3=1
WAIT #21: nam='db file sequential read' ela= 7757 p1=9 p2=1033325 p3=1
WAIT #21: nam='db file sequential read' ela= 9358 p1=9 p2=386925 p3=1
WAIT #21: nam='db file sequential read' ela= 6357 p1=27 p2=115538 p3=1
WAIT #21: nam='db file sequential read' ela= 13577 p1=27 p2=406642 p3=1
WAIT #21: nam='db file sequential read' ela= 16673 p1=9 p2=675815 p3=1
WAIT #21: nam='db file sequential read' ela= 3711 p1=9 p2=845792 p3=1
WAIT #21: nam='db file sequential read' ela= 7214 p1=28 p2=648407 p3=1
WAIT #21: nam='db file sequential read' ela= 4463 p1=10 p2=239400 p3=1
WAIT #21: nam='db file sequential read' ela= 15560 p1=9 p2=177045 p3=1
WAIT #21: nam='db file sequential read' ela= 6360 p1=9 p2=845798 p3=1
WAIT #21: nam='db file sequential read' ela= 572 p1=9 p2=845799 p3=1
WAIT #21: nam='db file sequential read' ela= 6072 p1=9 p2=1033288 p3=1
WAIT #21: nam='db file sequential read' ela= 5249 p1=9 p2=1176 p3=1
_Alex_SMIRNOV_
Дата: 02.12.2009 17:19:20
а случайно не поменялись объемы обрабатываемых данных в запросов, например, убрали какое-нибудь условие в запросе итд?... и теперь не хватает памяти на сортировку или построение HASH-JOINов
azzy
Дата: 02.12.2009 17:27:09
_Alex_SMIRNOV_,

объемы данных не менялись, произошел рост числа коннектов к базе, уже начал грешить на это. Но отключение этих клиентов не дало результата. Сегодня имеем ту же картину. Перезапуск сервера (полный ребут вместе с форточкой результатов не дал)
azzy
Дата: 02.12.2009 17:57:08
azzy,

ап