Вопрос к профессионалам по Oracle.
Вдогонку. Так как система работает с кассовыми аппаратами, почти после каждого обновления БД выполняется commit.
Может индексы забыл сделать?
P.S. Я не специалист, так что сильно не бейте
P.S. Я не специалист, так что сильно не бейте
Мне нужно обоснованное мнение.
Так индексы есть или нет ?
Если нет, то сдесь и обосновывать нечего.
Если нет, то сдесь и обосновывать нечего.
>>Если заребутить комп с Oracle, система опять начинает работать быстро.
Понимаешь, индексирование помогает при связывании таблиц. Я не могу понять, как оно может повлиять на "update table". Так же я не могу понять, почему после перезапуска сервера всё снова начинает работать быстро. Плюс к тому, почему в первые несколько недель никаких проблем мы не испытывали.
То есть мне не понятно, почему скорость работы резко меняется при том, что данных в день набирается не более 5000 строк.
Здесь, скорее всего, есть какие-то проблемы со Storage/Tablespace свойствами.
То есть мне не понятно, почему скорость работы резко меняется при том, что данных в день набирается не более 5000 строк.
Здесь, скорее всего, есть какие-то проблемы со Storage/Tablespace свойствами.
При update table - индексы перестраиваются. Если их много и они громоздкие, то это может быть причиной для тормозов.
Индесксов нету. Запросы очень простые.
"update a set a.status=1 where a.id=2"
"update a set a.status=1 where a.id=2"
Причин может быть много.
Что показывают
и
?
Каковы размеры shared_pool_size и sort_area_size?
Каковы размеры rollback segments?
Что за запросы и каковы планы запросов? Updat'ы разные бывают - может он 1 запись трогает, а может полтаблицы.
Сколько пользователей? Может, они блокируют друг друга?
Что показывают
select * from v$sysstat
и
select * from v$sesstat
?
Каковы размеры shared_pool_size и sort_area_size?
Каковы размеры rollback segments?
Что за запросы и каковы планы запросов? Updat'ы разные бывают - может он 1 запись трогает, а может полтаблицы.
Сколько пользователей? Может, они блокируют друг друга?
сто пудов, раз индексов нет, при связывании в запросе по внешним ключам нескольких таблиц они блокируются целиком (если есть индекс - блокируются только нужные строки)
профессионалы по Oracle не запускают Oracle на 32-битных архитектурах под Win2k
Как определить размер shared_pool_size, sort_area_size и rollback_segments?
Я же написал - апдейты очень простые, а-ля
Они не трогают пол таблицы, а только одну строку.
Почему же после ребута всё работает быстрее?
Обычно в системе не более трёх пользователей. Но это не важно, т.к. даже при наличии всего одного уже тормозит.
Я же написал - апдейты очень простые, а-ля
sql.Format("begin update cb_cash_order set status=4, location='%s', moved_id=0 where cbid='%s'; commit; end;",
g_pCBIni->GetTerr m_szOrderCBID);
Они не трогают пол таблицы, а только одну строку.
Почему же после ребута всё работает быстрее?
Обычно в системе не более трёх пользователей. Но это не важно, т.к. даже при наличии всего одного уже тормозит.
Пожалуйста, иди флудить в другом месте.
Да без проблем. Больше ни поста в этом треде. Только, плс прочти мой комментарий еще раз. Потому что, это есть правда, а не пустые слова.
Плиз, прочти мой вопрос ещё раз. А именно первую его строку. Для данной задачи такой архитектуры БОЛЕЕ чем достаточно. Спасибо за внимание.
Посмотреть параметры экземпляра можно либо в файле init<SID>.ora (<SID> - имя экземпляра либо сделав
А в чем выражается торможение? Сколько времени выполняются update, select? Если один и тот же запрос выполнить несколько раз, это занимает примерно одинаковое время? Если да - проблемы, скорее всего в настройках подсистемы памяти, если нет - возможно, в блокировках таблиц.
Что касается update, то, в данном случае, если нет индекса по cbid, то при апдейте блокируется вся таблица, блокировка снимается при commit. Если При этом к таблице обратится другая сессия, она будет ждать завершения транзакции со стороны первой.
select * from v$parameter
А в чем выражается торможение? Сколько времени выполняются update, select? Если один и тот же запрос выполнить несколько раз, это занимает примерно одинаковое время? Если да - проблемы, скорее всего в настройках подсистемы памяти, если нет - возможно, в блокировках таблиц.
Что касается update, то, в данном случае, если нет индекса по cbid, то при апдейте блокируется вся таблица, блокировка снимается при commit. Если При этом к таблице обратится другая сессия, она будет ждать завершения транзакции со стороны первой.
Обновление одной записи в таблице идёт от 1 до 5 секунд. Мне удалось исправить (или отложить?) эту проблему, увеличив размер tablespace, который был забит на 99%. Вдобавок, я настроил storage для каждой таблицы, чтобы размер прирастал на несколько мегабайт.
Оставить комментарий
kokoc88
Ситуация следующая :- Имеется приличный (для поставленной задачи) комп P4, 2.4GHZ, 512MB
- На этом компе стоит Win2K + Oracle 9.
- Имеется программа, которая использует этот Oracle.
- Все таблицы созданы простым SQL, без каких-либо модификаций их свойств.
Теперь описываю проблему :
- Через какое-то время система начинает ужасно тормозить, особенно при выполнении "update table". При этом запросы не сложные, типа insert/update одной таблицы или select из двух таблиц. Все таблицы размером 5000-10000 строк, но имеют довольно большое число полей 20-35.
- Это точно (100%) не связано с сетью, или интерфейсом программа-Oracle. (Тестировалось выполнением тех же запросов на PL/SQL Developer.)
- Если заребутить комп с Oracle, система опять начинает работать быстро. (Но это происходит не всегда.)
- Эта система работает на нескольких точках. При изначальной установке тормозов не наблюдается довольно долгое время.
Вопрос:
- С чем может быть связано такое поведение и как это можно исправить?
- Если необходимо предоставить какие-то дополнительные данные, я не против их предоставить.