для не ораклистов она вообще бесполезная, т.к. для того, чтобы знать в чем все-таки преимущества ZDLRA, надо знать все остальные методы HA, которые у Оракла есть со всей кучей всяких тонкостей и возможностей.
для ораклистов она чересчур поверхностная
Такое, извините, на MySQL делается несложно (репликация и бекапы уже с реплики, а лучше со снапшота реплики), не говоря про более серьезные БД-решения.
в оракле это тоже возможно и без этой железки, у ZLDRA другие преимущества из которых лично я вижу только пару:
легкая и простая консолидация сразу кучи баз с помощью «волшебной blackbox»
легкое быстрое получение снепшота на любой* момент времени.
* а тут мне лень указывать всякие детали мелким шрифтом :)
Я регистрировал еще пару внутренних уязвимостей(закрыты в июле прошлого года), которые как мне кажется не входят ни в один из выше перечисленных векторов атак: возможность insert/update/delete при отсутствии на них гранта и возможность селекта данных, которые должны быть недоступны.
Еще насчет column_value: все-таки для унификации желательнее использовать value(), тогда легко и однотипно можно работать с конкретным возвращаемым типом. Пример:
declare
cursor c1 is SELECT value(t) x FROM TABLE(ku$_objnumset(1)) t;
cursor c2 is SELECT value(t) x FROM TABLE(ku$_objnumpairlist(ku$_objnumpair(10,20))) t;
begin
for r in c1 loop
dbms_output.put_line(r.x);
end loop;
for r in c2 loop
dbms_output.put_line(r.x.num1);
end loop;
end;
.
«Использование в SQL»: ассоциативные в 12c уже могут биндиться в SQL из PL/SQL если index by PLS_INTEGER: Link1 Link2
Мне кажется, что надо уточнить то, что вы имели ввиду под "Не поддерживает DML-операции" у ассоциативных массивов. Я бы лучше сказал, что ассоциативные массивы, в отличие от varray и nested table, не могут храниться в таблицах.
У VARRAY метод DELETE() существует, но нет методов delete(m), delete(m,n)
Я предполагал, что INDEX SKIP SCAN (ISS) логически разобьет индекс IX_BIG_TAB на 10 небольших индексов и уже последовательно пройдется по ним, используя access(«T».«DT»>=SYSDATE@!-.01 AND «T».«DT»<=SYSDATE@!). Т.е. сделает подобие IRS 10 раз, и, логически получится тоже самое что и в шагах 3-5 из запроса без join elimination.
Основное отличие в том, что Oracle заранее не знает, какие значения у лидирующего столбца в индексе, чтобы спускаться по дереву к каждому левому значению, и поэтому не знает где очередное начинается и где заканчивается, поэтому ему нужно отлавливать, когда значение лидирующего в branch-блоках изменяется и брать его уже для прохода по leaf-блокам, а остальные leaf-блоки skip'ает.
В общем-то у меня в этих скриптах многое связано между собой и по отдельности может запускаться с ошибкой. Для правильной установки под windows я написал такую инструкцию. В принципе под nix'ами минимум отличий от инструкции и все проще:
Все на самом деле просто:
Обращайте внимание на ACCESS и FILTER предикаты в плане:
xt_nums — таблица маленькая и легко вычитывается за один проход и если начинать от нее, то мы получаем значения лидирующего столбца в индексе для INDEX RANGE SCAN(далее я буду сокращать как привык — IRS). Соответственно при IRS мы будем заходить сразу с верхними и нижними границами по каждому из 10 значений полученных из xt_nums. А Index skip scan, при сработавшем Join elimination, вычитывает весь индекс IX_BIG_TAB, а не спускается по дереву как IRS.
Кстати, в Oracle 11.2 запросы получаются немного другие и их cost одинаков:
Вообще-то этот пример я как раз делал на 11.2. У вас, наверное какая-нибудь низкая версия типа 11.2.0.1 — 11.2.0.2 — это заметно по 0 в стоимости INDEX UNIQUE SCAN, насколько помню это в каком-то промежуточном патче было исправлено.
Кроме того, мне кажется что у вас занижен параметр optimizer_index_cost_adj или что-то не так со статистикой — слишком маленькая стоимость у INDEX SKIP SCAN. В общем у вас получилась проблема неправильного порядка таблиц во втором плане — попробуйте изменить в нем хинт на
outer с предикатами по столбцам двух и более разных таблиц
речь про «ORA-01417: a table may be outer joined to at most one other table» при оракловом синтаксисе.
в 12c это уже исправлено и оракловый синтаксис позволяет так соединять.
Дело в том, что Oracle RDBMS появилась раньше официально признанного стандарта, да и, кроме того, у всех РСУБД есть и были разногласия со стандартом. А реальных методов соединений, фильтрации и доступа не так много и практически все покрываются старым оракловым синтаксисом.
не могли бы Вы рассказать, в какой момент выполнения запроса происходит это преобразование?
В трассировке 10053(секция «Final query after transformations») вы можете увидеть, что как запрос трансформируется. В принципе есть способ попроще, но менее надежный и показывается не совсем точная копия трансформированного запроса:
в 11g — dbms_sql2.expand_sql_text
в 12с = dbms_utility.expand_sql_text
Вообще, советую прочитать Cost-Based Oracle fundamentals Джонатана Льюиса. Ее просто необходимо прочесть наряду с его же «Oracle Core», если хотите заниматься оптимизацией производительности.
вы имеете ввиду как раз «старое», которое в оракле «давным давно реализовано»
в оракле это тоже возможно и без этой железки, у ZLDRA другие преимущества из которых лично я вижу только пару:
* а тут мне лень указывать всякие детали мелким шрифтом :)
Он про это еще 5 лет назад писал: jonathanlewis.wordpress.com/2010/05/07/sqlnet-compression/
Как-то мимо меня проскочил этот топик… Как бы подписаться на hub/oracle чтобы письма приходили, когда новый топик появляется?
Исходный:
После трансформации:
Хотя он еще и работает для совместимости
Небольшие дополнения/правки от меня:
Link1
Link2
Основное отличие в том, что Oracle заранее не знает, какие значения у лидирующего столбца в индексе, чтобы спускаться по дереву к каждому левому значению, и поэтому не знает где очередное начинается и где заканчивается, поэтому ему нужно отлавливать, когда значение лидирующего в branch-блоках изменяется и брать его уже для прохода по leaf-блокам, а остальные leaf-блоки skip'ает.
В принципе можете прочитать тут и статью и комментарии: richardfoote.wordpress.com/2008/03/10/index-skip-scan-does-index-column-order-matter-any-more-warning-sign/
проще трассировку 10053 сделать
Вот, кстати, скриншоты как у меня это на винде: orasql.org/2014/10/16/just-a-couple-of-screenshots-of-sqlplusrlwrapcygwinconsole/
Обращайте внимание на ACCESS и FILTER предикаты в плане:
xt_nums — таблица маленькая и легко вычитывается за один проход и если начинать от нее, то мы получаем значения лидирующего столбца в индексе для INDEX RANGE SCAN(далее я буду сокращать как привык — IRS). Соответственно при IRS мы будем заходить сразу с верхними и нижними границами по каждому из 10 значений полученных из xt_nums. А Index skip scan, при сработавшем Join elimination, вычитывает весь индекс IX_BIG_TAB, а не спускается по дереву как IRS.
Вообще-то этот пример я как раз делал на 11.2. У вас, наверное какая-нибудь низкая версия типа 11.2.0.1 — 11.2.0.2 — это заметно по 0 в стоимости INDEX UNIQUE SCAN, насколько помню это в каком-то промежуточном патче было исправлено.
Кроме того, мне кажется что у вас занижен параметр optimizer_index_cost_adj или что-то не так со статистикой — слишком маленькая стоимость у INDEX SKIP SCAN. В общем у вас получилась проблема неправильного порядка таблиц во втором плане — попробуйте изменить в нем хинт на
речь про «ORA-01417: a table may be outer joined to at most one other table» при оракловом синтаксисе.
в 12c это уже исправлено и оракловый синтаксис позволяет так соединять.
В трассировке 10053(секция «Final query after transformations») вы можете увидеть, что как запрос трансформируется. В принципе есть способ попроще, но менее надежный и показывается не совсем точная копия трансформированного запроса:
в 11g — dbms_sql2.expand_sql_text
в 12с = dbms_utility.expand_sql_text
Вообще, советую прочитать Cost-Based Oracle fundamentals Джонатана Льюиса. Ее просто необходимо прочесть наряду с его же «Oracle Core», если хотите заниматься оптимизацией производительности.