Запросы Peoplesoft - производительность - PullRequest
Новая
       10

Запросы Peoplesoft - производительность

2 голосов
/ 17 марта 2010

У меня проблема с запросами PeopleSoft (с использованием серверной базы данных Oracle): когда пользователь запускает довольно сложный запрос, включающий несколько записей, PS выполняет принудительное объединение записей безопасности, создавая таким образом SQL:

выберите .... из
ps_job a, PS_EMPL_SRCQRY a1, ps_table2 b, ps_sec_rcd2 b1, ps_table3 c, ps_sec_rcd3 c1
где (... соединения безопасности a-> a1, b-> b1, c-> c1 ...) и (... соединения a, b и c ...) и
a.setid_dept = 'XYZ';

(предположим, что последнее условие имеет высокую селективность и в столбце есть индекс) Очевидно, что из-за расположения условий сначала создается огромное соединение, записываемое во временный сегмент, и когда последнее условие наконец применяется, выбирается только небольшое подмножество. Сформулированный таким образом запрос, скорее всего, достигнет заданного времени ожидания APPSRV и даже QRYSRV. При написании запроса вручную я предпочел бы переместить наиболее селективное условие в начало, тем самым ограничив объем обрабатываемых данных, до значительного уровня.
Любые идеи о том, как заставить PS вести себя так? На самом деле, уже переписывание SQL в стиле Oracle в ANSI SQL, кажется, ускоряет запросы - однако PS пишет запросы в стиле Oracle ...

Заранее спасибо
ДБА

Ответы [ 2 ]

2 голосов
/ 12 мая 2012

Помимо того, что предложил Грант, другим способом было бы создать представления для таблиц, к которым пользователь мог бы обращаться и выполнять обычные объединения.

Для вышеперечисленного вам придется - 1. Создайте представления для каждой из записей, которые будут использоваться в запросе. 2. Добавьте представления в дерево безопасности запросов. 3. Используйте представления в запросе PS. Это будет выполнять обычные объединения в представлениях, и в соединениях не будет записей безопасности.

Чтобы обеспечить безопасность данных на уровне пользователя, вы можете иметь другое представление безопасности и присоединить его к окончательному запросу, а также иметь условие в предложении where для проверки текущего пользователя, вошедшего в систему.

Таким образом, у вас будет фиксированное количество представлений, а не представление для каждого пользовательского запроса.

1 голос
/ 20 марта 2010

Единственное известное мне исправление, которое заставляет его выполнять соединения так, как оно должно быть, а не так, как это делается (и избегает страшного объединения декартовых объединений), - это создание представления, которое выполняет соединение правильно.

  • Создать запись с правильными полями.
  • Сделайте так, чтобы он отображал SQL-представление.
  • Вставьте ваш SQL, который теперь работает.
  • Добавьте его в дерево безопасности запросов.
  • Обновление кеша безопасности.
...