проблема при переносе документов (расчет товародвижения) : Супермаг Плюс (Супермаг 2000)

rost · █ 27.05.2009 14:20

Всем Доброго дня.
Имеем центр. базу, 62 ГБ.
Раз в месяц пересоздание индексов (утилита Олега), раз в неделю расчет
статистики. База заполнена примерно на половину, редологов 5 по 50 Мб.
Каждый день стопиться и стартует заново (бакап).

Проблема:
Сегодня при расчете аналитики (формировал с очисткой аналит. базы полностью, вручную), заметил, что за 1 час перенеслось всего 2%. Посмотрел логи - переключение редо идет раз в 5-10сек. Процессор загружен на 8-20%, темп не переполнен, как иногда бывает при проблемах с индексами.
На всякий случай выполнил штатные задания полное пересоздание индексов и расчет статистики.
Перезапустил базу, расчет аналитики - то же самое - сначала переносит по 200-300 док-тов, но дойдя до примерно 3000 (ок 1%), начинает переключать редологи, перенос по 3-7 документов. Опять прервал расчет - почистил аналит. базу (полностью)

Увеличил редологи до 250Мб (5х250) - ситуация изменилась только в том, что теперь переключение прим. раз в 1.5-2 мин.

Кто нибудь сталкивался с подобным, что можно сделать еще ???

Заранее спасибо.

PS ини файл

Код:

background_dump_dest = D:\ORACLE\admin\BASE\bdump
compatible = 8.1.6
control_files = "D:\ORACLE\oradata\BASE\control02.ctl"
control_files = "D:\ORACLE\oradata\BASE\control03.ctl"
control_files = "D:\ORACLE\oradata\BASE\control01.ctl"
db_block_buffers = 135000
db_block_max_dirty_target = 135000
db_block_size = 8192
db_file_direct_io_count = 128
db_file_multiblock_read_count = 8
db_files = 1024
db_name = biberco
distributed_transactions = 10
global_names = TRUE
hash_area_size = 16384000
instance_name = base
java_pool_size = 32768
job_queue_processes = 2
large_pool_size = 614400
log_archive_dest_1 = "LOCATION=D:\ORACLE\ORA81\RDBMS"
log_buffer = 10485760
log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800
max_dump_file_size = 10240
max_enabled_roles = 30
max_rollback_segments = 99
open_cursors = 100
optimizer_index_caching = 90
optimizer_index_cost_adj = 25
oracle_trace_collection_name = ""
os_authent_prefix = ""
parallel_max_servers = 5
processes = 165
remote_login_passwordfile = EXCLUSIVE
service_names = biberco
shared_pool_size = 150000000
sort_area_retained_size = 65536
sort_area_size = 8192000
user_dump_dest = D:\ORACLE\admin\BASE\udump
job_queue_processes = 1
job_queue_interval = 60
session_cached_cursors=30

Mtirt · █ 27.05.2009 14:28

Версия Оракла?
Размер оперативной памяти?

rost · █ 27.05.2009 14:36

Оракул 8.1.6, оперативы 4 Гб, Двуядерный ксеон 3.2, 5 винтов скази в раиде 5

didinap · █ 27.05.2009 14:41

Я бы тебе посоветовал не ставить на сервер конфигурацию с рейд5. Так как при записи на диск он слишком тормозит. Можно также проапгрейдить оракл на версию 10, и установить все на 64бит системе + закрытие периода. После этого у нас все начало летать.

rost · █ 27.05.2009 14:43

Согласен, но у меня неделю назад тоже все летало, что с базой - ума не приложу...

OlegON · █ 27.05.2009 14:53

Наверное летало при обычном, инкрементальном переносе, а сейчас - полный? Где-то сталкивался, действительно, там долбит одной и той же вставкой, табличка растет немеряно, план расползается... Выход, который выбрал я - один раз перетерпеть, закрыть период, а теперь, по ряду еще других причин, переносится в два захода, сначала скриптом, а потом уже td делает перенос небольшого количества доков и их расчет.
Второй и более профессиональный выход - воспользоваться dbms_stat.set_table_stats и выставить на эту растущую табличку правильную статистику. Или же собрать статистику, когда она полная. В этом и беда твоя, наверное, ты ее собрал на пустой. Табличку не помню, посмотри, на каком запросе застревает.

rost · █ 27.05.2009 15:05

Самое обидное, что статистику часто с нуля делаем... :(
А разве нормально, что до 1% примерно все нормально переноситься ???

Mtirt · █ 27.05.2009 15:06

Нормально. При полном переносе это процесс длительный, причем он потом к концу ускоряется, значительно. Первые 10-20% - очень медленно, обычно.

OlegON · █ 27.05.2009 15:07

Не понял, что значит "с нуля".
Нормально. До 1% таблица не сильно отличается от ожидаемого по статистике. Кстати, можно попробовать включить на время эксперимента optimizer_mode=RULE.

OlegON · █ 27.05.2009 15:09

Цитата:

Mtirt ➤ Нормально. При полном переносе это процесс длительный, причем он потом к концу ускоряется, значительно. Первые 10-20% - очень медленно, обычно.

Могу предложить фокус (жаль не помню таблицу), но та, куда инсерт идет. Дожидаемся, скажем, до 5%, прибиваем, считаем статистику (analyze хватит) запускаем заново - проходит влет...