Пользователь
Логин:
Пароль:
Забыли свой пароль?

Поиск по сайту
 

 Расширенный поиск
Реклама

 

Опрос


Погода

Евгений Новашов (все сообщения)
Форумы
Обновления
Поиск
Пользователи 
Правила
Помощь
Войти

Выбрать дату в календаре ...  Выбрать дату в календаре

Страницы: Пред. 1 2
База Данных по SD 4.5
#
15.07.2011 06:06:25
Данный запрос выбирает 20 полей, и 12 записей, но нет разницы в полях т.к. с одним с полем такой же результат (с одним полем ID, система выбирает 5 полей (4 служебных)).
проблема вот в таких строчках (сотрудник в 3 группах):
T10101.prj_ass_wog_oid IN (281980751970332,281980792078337,281489065314750)
T70101.ser_ass_wog_oid IN (281980751970332,281980792078337,281489065314750)
T30101.ass_workgroup IN (281980751970332,281980792078337,281489065314750)
T80101.inc_assign_workgroup IN (281980751970332,281980792078337,281489065314750)

При такой конструкции НО с одним значением запрос отработает за 1 сек.
Изменено: Евгений Новашов - 15.07.2011 06:08:00
 
Перейти
База Данных по SD 4.5
#
14.07.2011 12:09:49
1. Java runtime vendor : Sun Microsystems Inc. Java runtime version: 1.6.0_02-b05
2. Скорость обработки запроса в базе 20 сек, на клиенте 40 сек. При статистике запрос обрабатывается за 1 сек, на клиенте за 2 сек.
3. Email record мы активно используем. До данной фишки такие же тормоза были.

Интересно как работает в РЖД у них объемы колоссальные.

classes12.zip - заменен
Изменено: Евгений Новашов - 14.07.2011 12:11:00
 
Перейти
База Данных по SD 4.5
#
13.07.2011 06:44:26
Добрый день.
Email record - включен, без него "тормоза" были такие же.
У нас 23 сервис пак, файл ojdbc14.jar есть в папке lib.
При старте пишет:
Status> JDBC Driver name:Oracle JDBC driver
Status> JDBC Driver version:10.1.0.4.0
 
Перейти
База Данных по SD 4.5
#
12.07.2011 05:16:56
Коллеги всем доброго времени суток.
Предлагаю поделится архитектурой БД:
У нас БД стоит на Oracle 10.2 (виртуальный сервер Linux - 4 процессора, 16 Гб ОЗУ), размер базы составляет 25 Гб. В системе 1,5 мил заявок, столько же Работ, около 0,5 мил KE.
Сталкиваемся с проблемами производительности, причина проблем - низкая производительность выполнения SQL запросов из-за отсутствия индексирования (во многих запросах). Проблему можно решить включением "статистики" в БД Oracle (есть такая фишка). В результате Oracle анализирует архитектуру таблиц и сам находит оптимальный путь исполнения запроса. Но почему то при статистики БД виснет через час (пока не разобрались в чем проблема).
Конкретный пример: если специалист находится в 2 группах, то "События сегодня" (Service Today) отрабатывает за 40 сек., если в одной за 1 сек. Причина в том, что при нескольких группах SQL запрос строится на команде IN в результате индексы не берутся.
Будем дальше "копать" причину зависания при "статистике".
 
Перейти
Временные зоны и Email Notification
#
07.04.2011 09:38:54
Привязались ко всему smile:-). Речь идет о обращениях (SC). Соответственно группы и сотрудники и учетки в Московском часовом поясе. Поэтому Deadline в SC работает отонсительно региона корректно. Информация в почте приходит не корректно smile:-(
 
Перейти
Временные зоны и Email Notification
#
07.04.2011 09:14:51
Нет, сервер БД и APP расположены в Новокузнецке. Специалисты раскинуты по всем регионам.
 
Перейти
Временные зоны и Email Notification
#
07.04.2011 06:55:41
Коллеги имеется SD 4.5 SP 23. Наткнулись на проблему с временными зонами. При отправке писем испонителям о назначенных заявках с использованием стандартного шаблонам "Service call Assignment Notification" система использует временную зону сервера, а не группы..сотрудника..аккаунта. т.е. сервер SD в Новокузнецке отправляет письмо специалисту в Москву в письме есть поле Deadline, в самой заявке Deadline 11:00 (к примеру) в письме же пишет 14:00 (+3 часа - часовой пояс Новокузнецка).

Скорее всего можно решить обходным путем через Calculate Fields или математику в DB Rule но все же... Система должна поддерживать такую простую функциональность.

Кто сталкивался с подобным глюком ОТЗОВИТЕСЬ !!! smile:-) Заранее благодарен.
 
Перейти
Страницы: Пред. 1 2

Сегодня были (гостей: 9, пользователей: 0, из них скрытых: 0)