Тормоза под Oracle
Модераторы: m0p3e, edward_K, Модераторы
Тормоза под Oracle
Через support импортировал таблички в базу клиента( канал до клиента 100 Мбит/с , используемая БД - Oracle, сервер - Sun), скорость импорта составила 100 записей в секунду, если через atlantis импортировать, скорость примерно такая же. На своей машине(Pervasiv) скорость импорта ~3000 записей в секунду. Можно конечно сослаться на сетку или не оптимальную настройку Raid, но разница в скорости в 30 раз! В чем может быть проблема?
-
- Местный житель
- Сообщения: 702
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: Украина, Запорожска яобласть, г.Днепрорудный
Re: Тормоза под Oracle
1.в архитектуре разница, сравнение с локальной базой вообще не корректно
2. в самой процедуре импорта под вашей СУБД (у меня в ПИРе висит проблема по быстродействию в ОС, операция над несколькими тысячами карточек идет несколько суток)
3. индексы, если есть возможность, удалите, как в рекомендации по конвертации
2. в самой процедуре импорта под вашей СУБД (у меня в ПИРе висит проблема по быстродействию в ОС, операция над несколькими тысячами карточек идет несколько суток)
3. индексы, если есть возможность, удалите, как в рекомендации по конвертации
Re: Тормоза под Oracle
А можно поподробней про этот ПиР(номер, сроки и т.д.)? А то есть жалобы, что период в ОС закрывается по 3 часа, хотя раньше все было быстро...Andrey писал(а):1.в архитектуре разница, сравнение с локальной базой вообще не корректно
2. в самой процедуре импорта под вашей СУБД (у меня в ПИРе висит проблема по быстродействию в ОС, операция над несколькими тысячами карточек идет несколько суток)
3. индексы, если есть возможность, удалите, как в рекомендации по конвертации
-
- Местный житель
- Сообщения: 702
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: Украина, Запорожска яобласть, г.Днепрорудный
Re: Тормоза под Oracle
To spark:
это другой вопрос. см.F_OSOPER_RES_810530.txt
это другой вопрос. см.F_OSOPER_RES_810530.txt
Re: Тормоза под Oracle
с импортом разобрались, включение галочки "оптимизировать под MS sql и Oracle" увеличивает скорость почти на 2 порядкаAndrey писал(а):1.в архитектуре разница, сравнение с локальной базой вообще не корректно
2. в самой процедуре импорта под вашей СУБД (у меня в ПИРе висит проблема по быстродействию в ОС, операция над несколькими тысячами карточек идет несколько суток)
3. индексы, если есть возможность, удалите, как в рекомендации по конвертации
Сейчас другая проблема со скоростью - генерация дерева(аналог модуля ТОРО, 180000 записей ) : на локальной машине 1 минута, у клинета 70 минут.
Самая долгая опреция - всавка записи.
Может клиент криво Галактику поставил/настроил или все-таки узкое место ЛВС?
-
- Заслуженный деятель интернет-сообщества
- Сообщения: 5188
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: SPB galaxy spb
Re: Тормоза под Oracle
DataBase.UserTablesLocalCache=On
Ну еще выше есть параметр где хранить.
Правда некоторые программеры забывают об этой волшебной опции и используют таблы пользоателя в DSQL - для задания исключений есть ниже параметр.
Таблы пользователя будут хранится в папке MTCache - если со временем они резко растут, то есть повод писать в ТП (с указанием отчета который их увеличивает).
Чистить можно практически безболезнено
Ну и общие рекомендации по снижению загрузки сети никто не отменял. Еще посмотрите про SMb2 - на 2008 это тоже могет привести к тормозам.
Ну еще выше есть параметр где хранить.
Правда некоторые программеры забывают об этой волшебной опции и используют таблы пользоателя в DSQL - для задания исключений есть ниже параметр.
Таблы пользователя будут хранится в папке MTCache - если со временем они резко растут, то есть повод писать в ТП (с указанием отчета который их увеличивает).
Чистить можно практически безболезнено
Ну и общие рекомендации по снижению загрузки сети никто не отменял. Еще посмотрите про SMb2 - на 2008 это тоже могет привести к тормозам.
Re: Тормоза под Oracle
О! А где такая чудо-галочка??win писал(а):с импортом разобрались, включение галочки "оптимизировать под MS sql и Oracle" увеличивает скорость почти на 2 порядкаAndrey писал(а):1.в архитектуре разница, сравнение с локальной базой вообще не корректно
2. в самой процедуре импорта под вашей СУБД (у меня в ПИРе висит проблема по быстродействию в ОС, операция над несколькими тысячами карточек идет несколько суток)
3. индексы, если есть возможность, удалите, как в рекомендации по конвертации
Сейчас другая проблема со скоростью - генерация дерева(аналог модуля ТОРО, 180000 записей ) : на локальной машине 1 минута, у клинета 70 минут.
Самая долгая опреция - всавка записи.
Может клиент криво Галактику поставил/настроил или все-таки узкое место ЛВС?