[ОТВЕТИТЬ]
27.05.2009 14:20
rost
 
Всем Доброго дня.
Имеем центр. базу, 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
27.05.2009 14:28
Mtirt
 
Версия Оракла?
Размер оперативной памяти?
27.05.2009 14:36
rost
 
Оракул 8.1.6, оперативы 4 Гб, Двуядерный ксеон 3.2, 5 винтов скази в раиде 5
27.05.2009 14:41
didinap
 
Я бы тебе посоветовал не ставить на сервер конфигурацию с рейд5. Так как при записи на диск он слишком тормозит. Можно также проапгрейдить оракл на версию 10, и установить все на 64бит системе + закрытие периода. После этого у нас все начало летать.
27.05.2009 14:43
rost
 
Согласен, но у меня неделю назад тоже все летало, что с базой - ума не приложу...
27.05.2009 14:53
OlegON
 
Наверное летало при обычном, инкрементальном переносе, а сейчас - полный? Где-то сталкивался, действительно, там долбит одной и той же вставкой, табличка растет немеряно, план расползается... Выход, который выбрал я - один раз перетерпеть, закрыть период, а теперь, по ряду еще других причин, переносится в два захода, сначала скриптом, а потом уже td делает перенос небольшого количества доков и их расчет.
Второй и более профессиональный выход - воспользоваться dbms_stat.set_table_stats и выставить на эту растущую табличку правильную статистику. Или же собрать статистику, когда она полная. В этом и беда твоя, наверное, ты ее собрал на пустой. Табличку не помню, посмотри, на каком запросе застревает.
27.05.2009 15:05
rost
 
Самое обидное, что статистику часто с нуля делаем... :(
А разве нормально, что до 1% примерно все нормально переноситься ???
27.05.2009 15:06
Mtirt
 
Нормально. При полном переносе это процесс длительный, причем он потом к концу ускоряется, значительно. Первые 10-20% - очень медленно, обычно.
27.05.2009 15:07
OlegON
 
Не понял, что значит "с нуля".
Нормально. До 1% таблица не сильно отличается от ожидаемого по статистике. Кстати, можно попробовать включить на время эксперимента optimizer_mode=RULE.
27.05.2009 15:09
OlegON
 
Цитата:
Mtirt Нормально. При полном переносе это процесс длительный, причем он потом к концу ускоряется, значительно. Первые 10-20% - очень медленно, обычно.
Могу предложить фокус (жаль не помню таблицу), но та, куда инсерт идет. Дожидаемся, скажем, до 5%, прибиваем, считаем статистику (analyze хватит) запускаем заново - проходит влет...
27.05.2009 15:25
rost
 
Супер :)
Попробую, щас только таблицу найду...
27.05.2009 15:47
rost
 
Вроде получается, что в две таблицы идет перенос:
ffdocuments
ffspec
27.05.2009 16:04
Mtirt
 
Да, только в них.
27.05.2009 16:10
bob
 
Посмотрел у себя по базе. Размер примерно такой же. версия та же.
Один проц на 3 Ггц пень, два зеркала из обычных саташных винтов.
Перенос идет 1 час. где-то полчаса 1-2 процента, затем резко ускоряется.
Редо-логи переключаются раз в 10-15 секунд.
Принципиальное отличие db_file_multiblock_read_count = 64
Ну и конечно замечание про рейд5 (было выше про скорость записи) верное.
27.05.2009 16:16
rost
 
Со значением поиграю, переключается у Тебя часто очень ИМХО, конечно.
Расчет запустил, жду 5%, как советовали Люди. Потом статистику расчитаю.
Ждем...
27.05.2009 16:47
rost
 
Все, перенос окончен, время 1час, 12 мин.
Огромное всем спасибо за участие.
28.05.2009 08:35
bob
 
Цитата:
rost Все, перенос окончен, время 1час, 12 мин.
Огромное всем спасибо за участие.
Что конкретно помогло?
28.05.2009 13:01
rost
 
Помог перенос до 5% и пересчет статистики...
Опции темы


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

 

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