Оракл жутко медленно работает. В чем может быть причина?

На просьбу удалить из таблицы 1000 строк получаем загрузку ЦП 100% и 4 минуты ожидания (всего таблица содержит около 64 тыс. записей)

Оракл установлен на вполне приличной машине: проц - 2-х головый Xeon 2Ггц, 2Гб ОЗУ, ОС - OpenSuse. Кроме Оракла на машине ничего существенного не запущено.

Совсем уж непривычная скорость работы. Подскажите, пожалуйста, в чем может быть проблема.

Какие данные ?? Есть КЛОБЫ ? Есть ли триггеры на таблицах ?
Если есть триггеры, то он выполняет не 1000 удаления, а к примеру 10 000 То естесственно время увеличится удаления.

Сообщение отредактировано: Marriage - 23.09.08, 12:38

Типы данных - Number(11, 0), Date, Varchar2 (самый большой варчар - 300 символов). Всего 28 полей. Имеется 3 триггера, но они на Insert и Update.

А запрос можно посмотреть на удаление ?

Конечно можно. Вот уже 10 часов выполняется

delete from table_name

А до этого на запрос

delete from table_name where id < 1000

ушло 4 минуты. Число записей, попавших в этот диапазон, оказалось около 300. Т.е. на удаление одной записи уходит почти 1 сек.

Сообщение отредактировано: Stoom Urchin - 24.09.08, 04:23

таблица во время удалениея не может чем-то еще блокироваться? на Delete не поставлено каскадного удаления или еще чего-то?

Блокировать ее некому. Каскадного удаления нет.
Еще такой нюанс. Изначально база стояла на машине с двухголовым 4-м пнем (3Ггц), и 1Гб ОЗУ. Затем вся схема и данные были импортированы на новую машину (xeon). Так вот на старом компе удаление проходит существенно быстрее: на полную очистку таблицы ушел 1 час (только что проверил).
Вообще говоря, на новой машине тормоза наблюдаются не только с удалением (хотя удаление, пожалуй, самый яркий пример).

Копайте настройки. Можно INIT базы посмотреть (желательно ДО и ПОСЛЕ)? Скорее всего траблы с распределением памяти.

Спасибо за участие.
Похоже я встрял надолго.

Stoom Urchin
Можно INIT базы посмотреть ?

Пытаюсь к сообщению прицепить файл и получаю в ответ

Цитата

ОБНАРУЖЕНЫ СЛЕДУЮЩИЕ ОШИБКИ
Вы не можете прикрепить этот тип файла

ну так зазипуй/зарарь

Вот, пожалуйста.
Прикреплённый файлinit.ora.zip (3.18 Кбайт, скачиваний: 120)

это ДО, или ПОСЛЕ, или ОДИНАКОВО ?

Извиняюсь... до и после чего?

А с местом на дисках все ок?

свободно > 100G

INIT какой базы?
1.Старой
2.Новой
3.Одинаковый для всех

Потестить дисковую систему, может в ней проблемы.
Фаловая система NTFS как я понимаю ?

Сообщение отредактировано: Marriage - 25.09.08, 07:44

Инит одинаковый.
Файловая система - ext3.

Цитата Marriage @ 25.09.08, 07:43

Потестить дисковую систему, может в ней проблемы.

Как это сделать?

Не думаю, что проблемы могут быть с этим, но все же... такой нюанс: старая база - Express Edition, новая - Enterprise.

Как это сделать? - Та же сандра может это сделать. Только как я понимаю у Вас никсы... Поэтому не знаю. Если Init одинаковый тогда я даже не знаю что это может быть

Мда, что-то совсем непонятное творится.
Спасибо, за участие.

Я кончно извиняюсь, а поле ID проиндексированно?
Такое видел, когда запросы работают по неиндексированным полям...
У меня в базе тоже было так, пока не понял что торможу и в условии отобора стоит неидекисрованная дата.

Сообщение отредактировано: shadow_tls - 26.09.08, 10:26

Индексы на месте.
Однако согласитесь, даже при их отсутствии удалять данные со скоростью 0.8 запись/сек - это чересчур.

Цитата Stoom Urchin @ 26.09.08, 11:19

Индексы на месте.
Однако согласитесь, даже при их отсутствии удалять данные со скоростью 0.8 запись/сек - это чересчур.

У нашего одного сотрудника запрос, вернее выполнение функции работало ну примерно 300 сек., при условии, что на моем компе та же функция отрабатывала 0.6 сек.. Проблема ушла, когда ему переставили клента - коряво был поставлен до этого.

альтернативное удаление можно попробовать: truncate table table_name

из предыдущих постов уловил, что был переезд базы с win на nix??!
с аналогичной проблемой сталкивался. при одинаковых настройках
на win работала в 10 раз быстрее, чем на nix.

докапались... тормозил ora_dbw, а точнее не сам процесс сброса данных
на физический носитель, а его работа в следствие неверной организации
хранения самих данных. уже точно не вспомню, но вроде бы помогло след.:
1. снести все (да... к сожалению)
2. !!!аккуратно!!! поставить server (сам лично по документации
выверял параметры по 10 раз)
3. воткнуть второй винт, где размещать пользовательские таблспайсы
(системный каталог оставили на первом винте)
4. для определенных таблспайсов создать определенные роллбэк сегменты
(в нашем случае для некоторых данных не нужен был rollback транзакции)
5. соответ. таблицы разместить в соотв. таблспайсах

после этого стало работать сносно

успехов

shadow_tls С клиентом проблема не связана, т.к. с разных клиентов с разных машин тупит одинаково.
grgdvo Переезда с win не было. Изначальна ОС была Suse, теперь CentOs. Пытаемся настраивать - некоторые улучшения уже есть.