Страница 1 из 4
Быстродействие на Oracle
Добавлено: 13 фев 2008, 13:42
Nikos
Добрый день. Собираемся переходить с Pervasive на Oracle. Конвертнул тестовую БД и возникли серьезные проблемы с производительностью.
1. Долгий вход. После введения пароля появляется досовское окно "Подключаемся к БД" где-то на минуту-полторы.
2. Визуально работает медленнее при открытии интерфейсов/ перемещении по записям.
3. Выполнение таких операций как "Пересчет сальдовых остатков" выполняется минимум в 5 раз медленнее, чем на Pervasive.
Все тесты выполнял на одном и том же сервере, БД одинаковая, только конвертированная. При том же пересчете сальдовых остатков Pervasive использует 3-5% ЦП, в то же время Oracle 60-80%! памяти тоже больше использует, зачем....
БД посмотрел Ораклист - говорит, что все в порядке, узких мест нет, попадание в КЭШ идеальное, памяти везде хватает.
В чем может быть дело? Подскажите, у кого есть опыт.
Добавлено: 13 фев 2008, 14:42
Ged
Для начала логи смотрите .. типа ORA90DRV.LOG
Добавлено: 13 фев 2008, 16:45
Nikos
в ORA90DRV.LOG только события неправильного входа (пароль ошибся как-то раз)
Добавлено: 13 фев 2008, 17:43
SergZol
сделай tnsping имя базы
покажет сколько времени уходит на ответ базы
скорее всего нада поиграться с настройками ораклового клиента
все настройки лежат в папке установки ораклового клиента \network\admin tnsnames.ora, sqlnet.ora
Добавлено: 14 фев 2008, 10:31
oiko
Простого попадания в кэш мало - надо много чего подкручивать в настройках(нужно собирать статистику) и достаточно мощный сервер.
Кстати попробуй
*.OPTIMIZER_INDEX_CACHING=90
*.OPTIMIZER_INDEX_COST_ADJ=50
*.optimizer_mode='FIRST_ROWS'
А оракл все-таки предназначен для ведения больших обьемах баз/пользователей и изначально подгребает больше ресурсов чем первазив.
Добавлено: 14 фев 2008, 11:54
Galex
Nikos, а что вы хотели?... Конфигурацию вашего оборудования можно посмотреть?.. Перейти на Oracle с Pervasive не меняя оборудование не получится... Использование Oracle подразумевает, в первую очередь, мощную дисковую подсистему, а про то, что Oracle использует всю память и процессорное время (в отличие от Pervasive) я вообще молчу...
Добавлено: 14 фев 2008, 13:07
Nikos
1. tnsping вряд ли что покажет, так как SQL+ быстро коннектится
2. А где попробовать *.OPTIMIZER_INDEX_CACHING=90
*.OPTIMIZER_INDEX_COST_ADJ=50
*.optimizer_mode='FIRST_ROWS' и зачем?
3. Ораклист посмотрел дисковую систему - говорит, что время ожидания хорошее. То, что использует много ресурсов, это конечно не важно.
4. Сервер на мой взгляд неплохой (двухпроцессорный на Xeon, 6Гб оперативки, сказевый рэйд..., а БД всего-то 30 Гб)
Сейчас как раз изучаем статистику.
Добавлено: 18 фев 2008, 10:43
oiko
Приведены настройки оптимайзера ориентированные на использование индекса версия 9 и выше. (проверено ускорят часть выборок и формирование отчетов)
Прописать их в Init.ora(или что там у вас).
Добавлено: 18 фев 2008, 10:54
Nikos
Параметры оптимайзера поправил, запустил пересчет сальдовых остатков - пока не ясно. А вот что касается долгого входа в Галактику, то проблема не решилась (по-прежнему около минуты).
Добавлено: 18 фев 2008, 13:26
oiko
Вообще-то засекал вход не дольше 14 секунд.
Ваша база еще очень хилая по размеру - может и не проявиться ускорения.
Добавлено: 18 фев 2008, 13:36
Nikos
Да я и не переживал бы, если ускорения не появилось, но она стала работать медленнее первасива почти в 5 раз!
Сальдовые остатки еще не пересчитаны, но судя по тенденции, возможно, после установки параметров оптимайзера пересчет отработает раза в полтора быстрее, чем до установок, хотя все-равно заметно медленее первасива.
Добавлено: 18 фев 2008, 14:41
Galex
Nikos, а чем мотивируется переход с Pervasive на Oracle?... Если пользователей не много, база не большая... Чем плох Pervasive?..
Добавлено: 18 фев 2008, 17:53
Nikos
Прежде всего безопасность
Добавлено: 19 фев 2008, 13:56
oiko
У вас кто-то внагую копирует файлы таблиц?
Добавлено: 19 фев 2008, 16:02
Nikos
Дело даже не в том, что в данный момент кто-то копирует, а в том что есть возможность практически неподготовленному пользователю получить любые данные.