Upgrade на 10g
Игорь Мельников (Igor.Melnikov) представляется вашему вниманию полноценный семинар по миграции на 10g. Архив включает презентации, методички к лабораторным работам, а также все исходные тексты используемых в лабораторных работах скриптов. Конечно все прогрессивное человечество готовится к миграции на 11g, но если по какой-то причине вы относите себя к любителям старины - этот семинар для Вас :). Шутка конечно. Просто одна известная компания приучила всех пользователей, что раньше 2 Service Pack пользоваться ее продуктами нельзя. Так эта мысль так крепко засела, что многие ждут 11gR2. И очень зря, надо сказать. Хотите знать почему нужно мигрировать сразу на 11g ? Если Вы партнер Oracle не пропустите 11 сентября этого года и семинар по новым опциям, а если заказчик - 5 ноября и Oracle Technology day !
Сообщения
да-да, есть любители старины и им в конце года это все предстоит. Так что архив очень в тему. Большое спасибо!
ОтветитьУдалитьА вот насчет семинаров и партнеров, то меня очень удручает ситуация, что "Календарь мероприятий для партнеров по технологиям" на партнерском сайте Oracle уже два с половиной месяца как заканчивается 30 мая. Никакой информации на вторую половину года там нет. Только случайно, через блог Форса я узнал, что в октябре приедут в Новосибирск. Но это конечно, не к Вам претензия.
А вот у нас тестовая процедура на 11g выполняется 3 часа 20 минут против 3 минут на 9i и 10g. Бьемся долго, ничего понять не можем.
ОтветитьУдалитьКстати Бурлесон тоже считает, что надо дождаться 11gR2.
Ну так если есть процедура что мешает стравнить трассивровки, выяснить sql который стали работать хуже и применить sql plan baseline ? Делов на 5 минут. Бурлесон конечно же будет считать что нужно подождать. Он же консультант. Ему гораздо выгоднее взять с людей 2 раза деньги при миграции с 9 на 10, а потом с 10 на 11 :)))))
ОтветитьУдалитьНи трассировка, ни PL/SQL Hierarchical Profiler, ни ADDM аномалий не выявили, но тормозит.
ОтветитьУдалитьВот наш максимально-упрощенный тестовый пример и результаты.
Платформа AIX 5.3
create table test as select * from dba_objects where not OBJECT_ID is null;
alter table test add constraint test_pk primary key(OBJECT_ID);
CREATE OR REPLACE TRIGGER test_bu
before UPDATE
ON test
referencing new AS new old AS old
FOR EACH ROW
BEGIN
NULL;
END;
/
Вариант 1:
BEGIN
FOR dd1 IN
(SELECT *
FROM test
WHERE rownum <= 10000)
LOOP
UPDATE test
SET CREATED = dd1.CREATED +1
WHERE test.OBJECT_ID = dd1.OBJECT_ID;
END LOOP;
COMMIT;
END;
/
Вариант 2:
DECLARE
TYPE t_test IS TABLE OF test%ROWTYPE;
l_tab t_test;
BEGIN
SELECT *
BULK COLLECT INTO l_tab
FROM test
WHERE rownum <= 10000;
FORALL i IN l_tab.first .. l_tab.last
UPDATE test
SET CREATED = l_tab(i).CREATED +1
WHERE test.OBJECT_ID = l_tab(i).OBJECT_ID;
COMMIT;
END;
/
------------------------------------------------
Кол-во строк | Вариант1 | Вариант2
| триггер | триггер
| да | нет | да | нет
------------------------------------------------
10000 | 2.4 | 00.6 | 00.5 | 00.3
20000 | 09.8 | 01.1 | 01.0 | 00.6
40000 | 39.2 | 02.1 | 02.0 | 01.3
Как видно, в варианте 1 при включенном триггере зависимость времени выполнения от кол-ва обрабатываемых строк нелинейно.
Согласен, что вариант 1 далеко не оптимален, но:
1. он упрощен, в реале все сложнее
2. таких примеров много и переписывать все приложение весьма проблематично.
3. на том же сервере на Oracle 9.2.0.7 и 10.2.0.3 все работает великолепно.
Без текста триггера сложно понять проблему.
ОтветитьУдалитьЕсли переписывание кода точно не наш метод, я бы попробовал откомпилировать весь pl/sql - native compilation.
Интересный реультат может дать установка compatible в 10.2, но optimizer_features_enable в 11.1
Опять таки не понятно - проблема в выполнении pl/sql или в sql, который внутри процедур...
Текст триггера приведен. Там единственна строчка null;. Native пробовал, различные варианты plsql_optimize_level тоже пробовал.
ОтветитьУдалитьПроблема в том, что update внутри pl/sql и при наличии триггеров очень долго выполняется. С compatible=10.2 попробую. Но у меня складывается впечатление, что проблема в переключениях контекстов sql и pl/sql.
Что дал Native ?
ОтветитьУдалитьВ реальной то жизни наверно в триггере на просто NULL стоит.
При
plsql_optimize_level=2
по идее вариант 1 должен превращаться в варинт 2 оптимизатором.
Наверно имеет смысл пособираться данные с помощью
http://asktom.oracle.com/tkyte/runstats.html
Тогда будет видно в чем разница между вариантами
Оказывается это баг №7173924.
ОтветитьУдалитьНесомненно стоит перейти на 11R1 и как можно быстрее, чтобы стать "кроликом" для самого Oracle.
ОтветитьУдалить;)))
Другой вариант - дотянуть на 9i до пенсии :)
ОтветитьУдалитьзанятно в баге 7173924 оракловский саппортмен в упор не видит деградации. Клиент не отвязался, саппортмен нашел другой баг 6400175 и указал что 7173924 его дублирует. А баг 6400175 не виден, скромно скрыт от нескромных взоров клиентов. :)
ОтветитьУдалитьПри переходе на 11g есть реальный шанс огрести корзину скрытых багов по полной.
Дмитрий, заинтересованность в переходе понятна, но надо же совесть иметь. :)