» СУБД Oracle (Оракл - для поиска:)).

Добрый день! Подскажите как раздать привилегии на роль для выполнения команд grand и revoke, если их выполняет не владелец схемы (на нем висит эта роль)? Спасибо.

Может кому то понадобится: на роли во вкладке system priviledges, добавить привилегию grant any object privilege.

WITH GRANT OPTION вам поможет. По крайней мере в пдф-ке по языку SQL для версии 11g так сказано:
------------------------------------------------------------------------------------------
Specify WITH GRANT OPTION to enable the grantee to grant the object privileges to
other users and roles.
------------------------------------------------------------------------------------------

УДАЧИ !!!

Цитата:

Помогите с альтернативами SQL для получения курса валюты на заданную дату (см.  1)
и исходящего остатка по выпискам фирмы (2)

Ну, если исключительно ради интереса, то можно и так:


Код:
SELECT ayDate, RateVal FROM
(SELECT RateVal FROM rates
WHERE ValuteISO=:ValuteISO AND RateDate<=:PayDate
ORDER BY RateDate DESC)
WHERE rownum = 1;

оракл вроде недавно обещал очердную революцию в быстродействи - где она, кто знает?

Цитата:

оракл вроде недавно обещал очердную революцию в быстродействи - где она, кто знает?

ты про какую из революций - 12c или exadata?

Цитата:

оракл вроде недавно обещал очердную революцию в быстродействи - где она, кто знает?

А тебя смущает текущая скорость?

Цитата:

А тебя смущает текущая скорость?

местами да оракл просто нереальный тормоз

Цитата:

местами да

где именно, например?

например в параллельной обработке большого количества данных

Добавлено:
или наоборот - обработка незначительного набора данных в памяти когда нужно и чтение и запись

Цитата:

например в параллельной обработке большого количества данных

Под параллельной обработкой ты что имеешь ввиду хинт parallel или одновременный запуск. Пиши подробности может получится что-нибудь ускорить


Цитата:

или наоборот - обработка незначительного набора данных в памяти когда нужно и чтение и запись

тоже много факторов может влиять

Oracle далеко не тормозной - его просто надо правильно готовить

Цитата:

параллельной обработке большого количества данных

для такой задачи у оракла есть Exadata, но ценник там, конечно, негуманный

Цитата:

например в параллельной обработке большого количества данных
 
Добавлено:
или наоборот - обработка незначительного набора данных в памяти когда нужно и чтение и запись

База обычно тюнингуется под конкретные задачи.

Цитата:

База обычно тюнингуется под конкретные задачи.

меня больше всего раздражает то что перепиешь какой-нибудь простой алгоритм на плскл - он работает в сто или тысячу раз медленнее чем раньше на 486

Цитата:

он работает в сто или тысячу раз медленнее чем раньше на 486

Да, есть такой момент, но зато он может обрабатывать много клиентов/потоков параллельно, чего 486 не мог.

В целом, итерационные и вычислительные алгоритмы нужно из БД выносить. Мне знакома единственная СУБД, которая может с ними работать действительно быстро - kdb+. Ну а оракл - он для другого совсем предназначен.

Цитата:

оракл - он для другого совсем предназначен

например для чего? если он нормально не может выполнять то что работало быстрее двадцать лет назад?

Цитата:

например для чего? если он нормально не может выполнять то что работало быстрее двадцать лет назад?

Например, чтобы собрать в одном месте 10-100 Тб (сколько там было адресное пространство у 486?) данных и медленно их просуммировать.

Цитата:

меня больше всего раздражает то что перепиешь какой-нибудь простой алгоритм на плскл - он работает в сто или тысячу раз медленнее чем раньше на 486

Значится, надо смотреть, где "собака порылась", и где надо копать Вам. В каждом конкретном случае можно найти причину "медленной отработки" блока. Самое простое, что пришло на ум - использование адвайзеров памяти (помошнички) для оптимизации размера выделяемой памяти.

Ищите и обрящите!
С наступившим новым годом !!!

УДАЧИ !!!

Цитата:

меня больше всего раздражает то что перепиешь какой-нибудь простой алгоритм на плскл - он работает в сто или тысячу раз медленнее чем раньше на 486

PL/SQL - язык, ориентирован на работу с данными. То-есть, на реляционную алгебру. В этой нише он работает настолько быстро, насколько позволяет минимальный радиус кривизны рук админа и программиста. И то там есть уже всякие коллекции и т. д. А если нужен хитрый алгоритм, то можно использовать хранимые процедуры на Java или на C.

Цитата:

Значится, надо смотреть, где "собака порылась", и где надо копать Вам. В каждом конкретном случае можно найти причину "медленной отработки" блока. Самое простое, что пришло на ум - использование адвайзеров памяти (помошнички) для оптимизации размера выделяемой памяти.

Найти-то причину можно, но вот полностью разрешить проблему, согласен, можно далеко не всегда, ибо часто она лежит глубоко внутри концепции СУБД. А от адвайзеров эффект есть только на самой начальной стадии, а дальше часто один вред.

Цитата:

PL/SQL - язык, ориентирован на работу с данными. То-есть, на реляционную алгебру

rrromano, строго говоря, на реляционную алгебру ориентирован язык SQL, а PL/SQL - его процедурное расширение, специфичное для оракла и позволяющее делать уже обычные итерационные алгоритмы. Производительность первого сильно зависит от построенной в БД модели данных (правильные индексы и табличные структуры), ну а для второго - действительно программист должен явным образом использовать коллекции и пореже переключать контекст между этими движками (не стоит, например, без явной необходимости включать в список полей SQL-запроса вызов PL/SQL-функции.)

Цитата:

строго говоря, на реляционную алгебру ориентирован язык SQL, а PL/SQL - его процедурное расширение, специфичное для оракла и позволяющее делать уже обычные итерационные алгоритмы. Производительность первого сильно зависит от построенной в БД модели данных (правильные индексы и табличные структуры), ну а для второго - действительно программист должен явным образом использовать коллекции и пореже переключать контекст между этими движками (не стоит, например, без явной необходимости включать в список полей SQL-запроса вызов PL/SQL-функции.)

Все так и есть ). И каждый толковый ораклоид обязан как минимум изредка заглядывать в тексты Тома Кайта ).

ето все конечно интересно но что делать мне когда оракл сильно тормозит на простой задаче? админы говорят что это buffer busi - что это?

Цитата:

админы говорят что это buffer busi - что это?

Это событие ожидания, возникающее при попытке одновременного доступа к одним и тем же блокам данных из многих потоков сразу. Самая частая причина - план запроса изменился и теперь включает полное сканирование одной из таблиц. Лечится обычно пересбором статистики по всем входящим в SQL-запрос таблицам или корректировкой запроса на предмет уменьшения его показателя LIO - количества обращений к блокам в памяти.

как мне для начала найти запрос - их там очень много..

Цитата:

как мне для начала найти запрос

Самое надежное - взять свой проблемный PL/SQL-блок и запустить его с трассировкой, для чего перед его исполнением выдать команду:

alter session set events '10046 trace name context forever, level 12';

После чего попросить админа переслать тебе полученный файл и обработать его утилитой OraSRP. В полученном отчете будет четко видно - на какой запрос сколько времени и прочих ресурсов ушло.

Цитата:

как мне для начала найти запрос - их там очень много..

Попробуй тех же админов, или можешь сам (если прав хватит) собрать AWR на проблемном по времени участке, там и топ запросов увидишь и почему они "тормозить" начали.
ИМХО 90% случаев можно решить без трассировки запроса, анализом ожиданий и планов.


Цитата:

админы говорят что это buffer busi - что это?

Возможно оочень много клиентов обращаются (работают, изменяют) к одним и тем же ресурсам - в итоге из-за того что данные "грязные" Oracle-у приходится туго.

В общем кури AWR, будут вопросы пиши.

Пока информации очень мало, но статистику попробуй собрать

Цитата:

ИМХО 90% случаев можно решить без трассировки запроса, анализом ожиданий и планов.

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

Конечно трассировка дает более менее конкретное понимание проблемы, но зачастую доступа к ней нет, а если запрос начал "шалить" на продуктиве? И хоть умучайся на своих базах, ты не всегда сможешь воспроизвести проблему.

сегодня еще проблема случилась база повисла при записи. вроде и строк было немного всего несколько десятокв миллионов. это тоже пробема для оракла?

Цитата:

это тоже пробема для оракла

Каждую строчку, поди, коммитил?