БД растет и буксует, может оперативка мала? : Oracle

Mtirt · █ 18.03.2007 10:04

Цитата:

2)Дисков 3, но они в raid0, кстати перед raid5 приимущество только в переносе документов (на 11% быстрее).

Вся база? Мне становится страшно....

Mtirt · █ 18.03.2007 10:09

Что касается свободного места, Для работы в принципе хватит, для работы оптимайзера может и не хватить. Ем нужно столько же свободного места, сколько занимают данные.
Рекомендую добавить в Users перед запуском оптимайзера.

KOT · █ 21.03.2007 12:47

//Спасибо за совет, Mtirt. *04
//olegon, на выходных была ревизия, а у нас она похожа на фарс-мажёрно стихийное бедствие, поскольку считаем все за один раз ночью, а потом днями пересчитываем ту чушь, что сонные раздолбаи насчитали и что не насчитали. *01 Лог выложу, как только этот кошмар кончится.
baggio, скажу сразу, я тока учусь, вот select * from v$sga:

Fixed Size 70580
Variable Size 182087680
Database Buffers 506339328
Redo Buffers 77824

ОЗУ - 1Гб
################################
initDBYUZH.ora
################################
db_name = "DBYUZH"

instance_name = DBYUZH

service_names = DBYUZH

db_files = 1024

control_files = ("d:\oracle\oradata\DBYUZH\control01.ctl", "d:\oracle\oradata\DBYUZH\control02.ctl", "d:\oracle\oradata\DBYUZH\control03.ctl")

open_cursors = 100
max_enabled_roles = 30
db_file_multiblock_read_count = 8

db_block_buffers = 61809

shared_pool_size = 168780800

large_pool_size = 614400
java_pool_size = 0
job_queue_interval = 600
job_queue_processes = 10

log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800

processes = 160

parallel_max_servers = 5

log_buffer = 32768
##################################
###################################
user_dump_dest = d:\oracle\admin\DBYUZH\udump

db_block_size = 8192

remote_login_passwordfile = exclusive

os_authent_prefix = ""

distributed_transactions = 10
compatible = 8.1.0
sort_area_size = 65536
sort_area_retained_size = 65536
###################################

Диски на днях буду менять на новые, потому, что их гарантия 3 года,
а они не останавливаясь крутяться 3 года (seagateSCASI). *04 конечно не выкину, пойдут на резервный сервер, но доверия к ним тает. Если диски собраны в рэйд их ведь не протестить, система видит ОДИН диск, а не три!?

reddevil · █ 21.03.2007 15:50

db_block_buffers = 61809 * db_block_size = 8192 +
shared_pool_size = 168780800 =675128128 при 1гб ОЗУ это прямая дорога с своп, начни с этого.

reddevil · █ 21.03.2007 15:51

потом нахрена 3! управляющих файла на одном физическом диске?

reddevil · █ 21.03.2007 15:54

потом

Цитата:

select t.table_name, t.last_analyzed, t.num_rows
from all_tables t
where t.table_name in ('FFMAPREP', 'SMSPEC');

и

Код:

select count(*) from ffmaprep

результат сюда

reddevil · █ 21.03.2007 15:56

тьфу мля теги перепутал

bob · █ 21.03.2007 15:57

3 упр. файла на одном диске наверняка у многих находятся, потому что по умолчанию при создании базы они прописываются на один диск, а знания Оракла на момент создания базы у многих очень небольшие. Ну а потом уже лень переносить (или другие какие то причины).

reddevil · █ 21.03.2007 16:03

Цитата:

bob 3 упр. файла на одном диске наверняка у многих находятся, потому что по умолчанию при создании базы они прописываются на один диск, а знания Оракла на момент создания базы у многих очень небольшие. Ну а потом уже лень переносить (или другие какие то причины).

железобетонно)))

все остальные парметры тогда тож наверно стоит по умолчанию оставить)))

не совсем по теме, но может тогда проще администроование БД на аутсорсинг отдать?
(Если че могу предложить сови услуги по свердловской и смежным областям :) )
а потему в идеале для всех страждущих было бы еще вот такую штуку к вопросу прикладывать

если для 8i то там немножко не так, но если поискать можно и для 8 найти

KOT · █ 22.03.2007 14:38

Код:

select t.table_name, t.last_analyzed, t.num_rows 
from all_tables t 
where t.table_name in ('FFMAPREP', 'SMSPEC');

SMSPEC 22.03.2007 7:16:29 6780025
FFMAPREP 22.03.2007 10:56:47 5162345

ЭТО ОТСТУПЛЕНИЕ ОТ ТЕМЫ, НО ЕСЛИ НИ О ЧЕМ НЕ СКАЖЕТ ИНФА, ПРОПУСТИМ ЕЁ:
это на время статистики похоже, я её запускал сегодня утром раненько(с января, интервал 7 дней, в базовом модуле).
пришли менеджеры, и обноружили что не идет сумма продаж по кассовым документам и по отчёту оборотной ведомости, сильно не идет,
помидоры:
11,302кг - оборотная ведомасть
39,950кг - кассовый документ
кассы нормально выгрузились,
рассчеты нормально прошли,
журна винды без ошибок,
я в шоке, потому, что причины нет расхождения,
причём разницу отдельно по кассам (продажа помидор каждой кассой)сравнил, нет совпадения, значит не с выгрузкой кассы связано точно *10
провел рассчёты аналитические, данные стали сходиться, потом опять статистику рассчитал (на последнюю дату)

Код:

select count(*) from ffmaprep

TOAD в sql запросе застревает на ffmaprep и не дает данных.
что-то не так в синтаксисе?