Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Миграция в 10g - план поехал  [new]
KDIMA
Member

Откуда: Россия, Тверь
Сообщений: 120
Был сервер 9.2.0.6 на 32х битной 2003 винде.
Поставил на другой 64х битный 2003 сервер 10.2.0.1
Новый сервер круче старого по любым параметрам (дисковая подсистема быстрее, процов больше, памяти то-же)
База билинговая, строк в таблицах много.
Есть приложение, оно обрабатывает записи из больших таблиц. Приложение сначала заполняет временную таблицу состоящую из ID записи которую нужно обработать и колонка rownum.
Затем вытягивает данные таким запросом:
SELECT * 
    FROM (  SELECT 
                    row_num, operations.o_id, cusl_num, ab_num, o_bdate, 
                    o_edate, o_print, lso_cod,lcr_cod, lsop_cod, ac_id, 
                    o_telzone, cusl_id, plat_num, o_fullsumma, o_summa,
                    o_nds, o_fullsummausd, o_summausd, o_ndsusd, o_res, 
                    o_plan, o_lgota, lvo_cod,o_npacket, o_ndocum, 
                    ROWIDTOCHAR(OPERATIONS.ROWID) OROW , cdr_id, cdr_dlit, 
                    cdr_inp, cdr_vtelnum, cdr_cities, ROWIDTOCHAR(CDR.ROWID) CROW, 
                    service_type_id  FROM tmp_operations, operations , cdr  
            WHERE 
                (operations.o_id = tmp_operations.id)   
                AND ( operations.o_id = cdr.o_id (+)) 
            order by row_num
        ) 
    WHERE row_num >= :p_num;
в 9.2.0.6 план был такой:

   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=1648 Card=820 Bytes=356700)
   1    0   VIEW (Cost=1648 Card=820 Bytes=356700)
   2    1     NESTED LOOPS (OUTER) (Cost=1648 Card=820 Bytes=153340)
   3    2       NESTED LOOPS (Cost=828 Card=820 Bytes=122180)
   4    3         TABLE ACCESS (BY INDEX ROWID) OF 'TMP_OPERATIONS' (Cost=10 Card=818 Bytes=21268)
   5    4           INDEX (RANGE SCAN) OF 'SYS_C0011522' (UNIQUE) (Cost=2 Card=147)
   6    3         TABLE ACCESS (BY INDEX ROWID) OF 'OPERATIONS' (Cost=1 Card=1 Bytes=123)
   7    6           INDEX (UNIQUE SCAN) OF 'M2_OPRS_PK' (UNIQUE)
   8    2       TABLE ACCESS (BY INDEX ROWID) OF 'CDR' (Cost=1 Card=1 Bytes=38)
   9    8         INDEX (UNIQUE SCAN) OF 'M2_CDR_OPRS_FRGN' (UNIQUE)

в 10.2.0.1
стал такой:

Execution Plan
----------------------------------------------------------

----------------------------------------------------------------------------------------------
| Id  | Operation                      | Name           | Rows  | Bytes |TempSpc| Cost (%CPU)|
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                |  1024K|   167M|       |   528K (15)|
|   1 |  SORT ORDER BY                 |                |  1024K|   167M|   376M|   528K (15)|
|   2 |   HASH JOIN OUTER              |                |  1024K|   167M|   139M|   508K (16)|
|   3 |    HASH JOIN                   |                |  1024K|   128M|    37M|   366K (15)|
|   4 |     TABLE ACCESS BY INDEX ROWID| TMP_OPERATIONS |  1024K|    25M|       |     4   (0)|
|   5 |      INDEX RANGE SCAN          | SYS_C0030076   |   184K|       |       |     1   (0)|
|   6 |     TABLE ACCESS FULL          | OPERATIONS     |   135M|    13G|       |   140K (28)|
|   7 |    TABLE ACCESS FULL           | CDR            |   124M|  4765M|       | 41786  (35)|
----------------------------------------------------------------------------------------------

т.е. налицо предпочтение оптимизатором полного скана. А строк в таблицах много. Полный скан исполняеться крайне медленно.
По таблицу operations есть индекс по полю o_id b он PK, в таблице cdr есть индекс по полю o_id и он FK.
Статистика на обоих серверах собиралась так:
DBMS_STATS.GATHER_SCHEMA_STATS (OwnName           => 'ххх',
                                   Granularity       => 'ALL',
                                   Options           => 'GATHER',
                                   Gather_Temp       => FALSE,
                                   Method_Opt        => 'FOR ALL INDEXES FOR ALL COLUMNS SIZE AUTO',
                                   Estimate_Percent  => SYS.DBMS_STATS.AUTO_SAMPLE_SIZE,
                                   Degree            => SYS.DBMS_STATS.DEFAULT_DEGREE,
                                   Cascade           => TRUE,
                                   No_Invalidate     => FALSE
                                  );
Параметры оптимизатора 9.2.0.6:
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_dynamic_sampling           integer     1
optimizer_features_enable            string      9.2.0
optimizer_index_caching              integer     80
optimizer_index_cost_adj             integer     100
optimizer_max_permutations           integer     2000
optimizer_mode                       string      CHOOSE
То-же для 10.2.0.1
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_dynamic_sampling           integer     1
optimizer_features_enable            string      10.0.0
optimizer_index_caching              integer     80
optimizer_index_cost_adj             integer     40
optimizer_mode                       string      ALL_ROWS
optimizer_secure_view_merging        boolean     TRUE
optimizer_index_cost_adj уже я уменьшал.
Если поставить optimizer_features_enable=9.2.0 на 10ке то все становиться на свои места - запрос использует индексы, приложение работает быстро.
Вот план:
----------------------------------------------------------------------------------------
| Id  | Operation                      | Name             | Rows  | Bytes | Cost (%CPU)|
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                  |   818 |   347K|   664   (1)|
|   1 |  VIEW                          |                  |   818 |   347K|   664   (1)|
|   2 |   NESTED LOOPS OUTER           |                  |   818 |   132K|   664   (1)|
|   3 |    NESTED LOOPS                |                  |   818 |   100K|   334   (1)|
|   4 |     TABLE ACCESS BY INDEX ROWID| TMP_OPERATIONS   |   818 | 21268 |     5  (20)|
|   5 |      INDEX RANGE SCAN          | SYS_C0030076     |   147 |       |     2  (50)|
|   6 |     TABLE ACCESS BY INDEX ROWID| OPERATIONS       |     1 |   100 |     2  (50)|
|   7 |      INDEX UNIQUE SCAN         | M2_OPRS_PK       |     1 |       |     2  (50)|
|   8 |    TABLE ACCESS BY INDEX ROWID | CDR              |     1 |    40 |     2  (50)|
|   9 |     INDEX UNIQUE SCAN          | M2_CDR_OPRS_FRGN |     1 |       |     2  (50)|
----------------------------------------------------------------------------------------
Что есть такого в 10, что заставляет оптимизатор пользовать полный скан ?
Куда посмотреть и что показать ?
Спасибо тем кто дочитал :)
28 июн 07, 14:08    [4326759]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
Grami
Member

Откуда: Москва
Сообщений: 451
поставь хит use_nl.
28 июн 07, 14:30    [4326916]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
Grami
Member

Откуда: Москва
Сообщений: 451
KDIMA
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_dynamic_sampling           integer     1
optimizer_features_enable            string      10.0.0
optimizer_index_caching              integer     80
optimizer_index_cost_adj             integer     40
optimizer_mode                       string      ALL_ROWS
optimizer_secure_view_merging        boolean     TRUE


alter session set optimizer_mode = first_rows
28 июн 07, 14:33    [4326939]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
Grami
Member

Откуда: Москва
Сообщений: 451
KDIMA
в 10.2.0.1
стал такой:

Execution Plan
----------------------------------------------------------

----------------------------------------------------------------------------------------------
| Id  | Operation                      | Name           | Rows  | Bytes |TempSpc| Cost (%CPU)|
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                |  1024K|   167M|       |   528K (15)|
|   1 |  SORT ORDER BY                 |                |  1024K|   167M|   376M|   528K (15)|
|   2 |   HASH JOIN OUTER              |                |  1024K|   167M|   139M|   508K (16)|
|   3 |    HASH JOIN                   |                |  1024K|   128M|    37M|   366K (15)|
|   4 |     TABLE ACCESS BY INDEX ROWID| TMP_OPERATIONS |  1024K]|    25M|       |     4   (0)|
|   5 |      INDEX RANGE SCAN          | SYS_C0030076   |   184K|       |       |     1   (0)|
|   6 |     TABLE ACCESS FULL          | OPERATIONS     |   135M|    13G|       |   140K (28)|
|   7 |    TABLE ACCESS FULL           | CDR            |   124M|  4765M|       | 41786  (35)|
----------------------------------------------------------------------------------------------



установить статистику на темповую таблицу.
28 июн 07, 14:36    [4326966]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
evostr
Member

Откуда: Екатеринбург
Сообщений: 1278
KDIMA
есть такого в 10, что заставляет оптимизатор пользовать полный скан ?
Куда посмотреть и что показать ?

Если анализировать, что изменилось, то в первую очередь я бы глянул на системную статистику.
Показать можно трассировочный файл 10053 на обоих версиях для этого запроса.
28 июн 07, 14:47    [4327058]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
KDIMA
Member

Откуда: Россия, Тверь
Сообщений: 120
USE_NL конечно помогает. Спасибо.
Менять параметры сессии нереально - приложение закрытое.
Вообще хотелось-бы понять почему. Дабы избежать впредь.
Интересно чего не так. Данные те-же.

Системной статистики на старом сервере нет:
SELECT * FROM SYS.Aux_Stats$;
ничего не возвращает

На новом я собирал статистику. Но толку немного - нет рабочей нагрузки.

Трейсы по 10053 с 12 уровнем приложил.

К сообщению приложен файл (trace.zip - 39Kb) cкачать
28 июн 07, 15:10    [4327250]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18343
KDIMA
Менять параметры сессии нереально - приложение закрытое.

Ну уж прям-таки и "нереально" :)
Если приложение не меняет параметры сессии в процессе процессов, то можно триггером on-logon

Что до плана... Ну если действительно стало хуже (а не Вы так думаете глядя на HJ - по крайней мере в моей практике HJ при работе с телекомовскими данными при осмысленном применении показал себя очень хорошо), то подоприте аутлайном.
28 июн 07, 15:16    [4327290]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
_fast=true
Guest
KDIMA
Системной статистики на старом сервере нет:

Это я и так уже видел :)

KDIMA
На новом я собирал статистику. Но толку немного - нет рабочей нагрузки.

Я упомянул впервую очередь потому, что ее включение может оказать очень сильное влияние на оптимизатор. Даже если вы ее не собирали, в 10g есть noworkload statistics.
По поводу рабочей нагрузки есть set_system_stats.

KDIMA
Трейсы по 10053 с 12 уровнем приложил.

Гляну, но времени уже практически нет - рабочий день заканчивается.
28 июн 07, 15:22    [4327366]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
KDIMA
Member

Откуда: Россия, Тверь
Сообщений: 120
К сожалению хуже стало на самом деле, выборка порции на обработку на старом 2-3 секунды на новом от 5 минут.
28 июн 07, 15:32    [4327443]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
_fast=true
Guest
KDIMA
К сожалению хуже стало на самом деле, выборка порции на обработку на старом 2-3 секунды на новом от 5 минут.

А сколько реально во временную таблицу записей попадает? И сколько выбирается?
28 июн 07, 15:37    [4327487]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
KDIMA
Member

Откуда: Россия, Тверь
Сообщений: 120
Попадает около 16 миллионов, выбиратется по 10 тысяч.
Если во временной таблице 200-300 тысяч - работает быстро, быстрее чем на старом. Планы правда не снял.
28 июн 07, 15:38    [4327501]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18343
KDIMA
К сожалению хуже стало на самом деле, выборка порции на обработку на старом 2-3 секунды на новом от 5 минут.

Полагаю, если Вы существенно (на пару порядков) увеличите порцию, то есть шанс получить заметное сокращение общего времени обработки.
28 июн 07, 15:39    [4327507]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
KDIMA
Member

Откуда: Россия, Тверь
Сообщений: 120
После каждой порции идет коммит, если увеличить порцию будет много незакомиченных данных. Но мысль интересная. Попробую.
28 июн 07, 15:46    [4327540]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
_fast=true
Guest
KDIMA
Попадает около 16 миллионов, выбиратется по 10 тысяч.
Если во временной таблице 200-300 тысяч - работает быстро, быстрее чем на старом. Планы правда не снял.

Ради интереса, попробуй в 10g OPTIMIZER_DYNAMIC_SAMPLING в 1 поставить и посмотреть какой план будет.
28 июн 07, 15:49    [4327563]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
KDIMA
Member

Откуда: Россия, Тверь
Сообщений: 120
Порция в 1миллион вместо 10 тыщ не дает улучшение - только выборка идет 50 минут.
А вот OPTIMIZER_DYNAMIC_SAMPLING = 1 дает интересный результат:
---------------------------------------------------------------------------------------
| Id  | Operation                     | Name             | Rows  | Bytes | Cost (%CPU)|
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                  |   818 |   136K|  3245   (1)|
|   1 |  NESTED LOOPS OUTER           |                  |   818 |   136K|  3245   (1)|
|   2 |   NESTED LOOPS                |                  |   818 |   104K|  1660   (1)|
|   3 |    TABLE ACCESS BY INDEX ROWID| TMP_OPERATIONS   |   818 | 21268 |    10   (0)|
|   4 |     INDEX RANGE SCAN          | SYS_C0030076     |   147 |       |     2   (0)|
|   5 |    TABLE ACCESS BY INDEX ROWID| OPERATIONS       |     1 |   105 |     2   (0)|
|   6 |     INDEX UNIQUE SCAN         | M2_OPRS_PK       |     1 |       |     1   (0)|
|   7 |   TABLE ACCESS BY INDEX ROWID | CDR              |     1 |    40 |     2   (0)|
|   8 |    INDEX UNIQUE SCAN          | M2_CDR_OPRS_FRGN |     1 |       |     1   (0)|
---------------------------------------------------------------------------------------
т.е. имеем индексный доступ !
28 июн 07, 17:13    [4328206]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18343
KDIMA
Порция в 1миллион вместо 10 тыщ не дает улучшение - только выборка идет 50 минут.

Это время FTS меняется от 5 до 50 минут или общее время запроса?
Дело, конечно, хозяйское, но я бы попробовал довести вариант HJ до ума.
28 июн 07, 17:22    [4328258]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18343
andrey_anonymous
KDIMA
Порция в 1миллион вместо 10 тыщ не дает улучшение - только выборка идет 50 минут.

Это время FTS меняется от 5 до 50 минут или общее время запроса?
Дело, конечно, хозяйское, но я бы попробовал довести вариант HJ до ума.

Гыыы. Считаем:
50минут/5минут -это десятикратное увеличение времени выполнения
В то вреся как 1000000/10000=100, т.е. стократное увеличение выхода...
Итого, общая скорострельность возросла в 100/10=10 раз ;)
28 июн 07, 17:24    [4328269]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
KDIMA
Member

Откуда: Россия, Тверь
Сообщений: 120
Увиличиваеться время выборки порции с 5 до 50 минут, а обработка порции идет с той-же скоростью (730 зап/сек). Если иммем индексный доступ выборка порции идет 1-2 секунды. И практически не замедляет обработку.

Вот включил FIRST_ROWS:
---------------------------------------------------------------------------------------
| Id  | Operation                     | Name             | Rows  | Bytes | Cost (%CPU)|
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                  |   826K|   134M|  3268K  (1)|
|   1 |  NESTED LOOPS OUTER           |                  |   826K|   134M|  3268K  (1)|
|   2 |   NESTED LOOPS                |                  |   826K|   103M|  1666K  (1)|
|   3 |    TABLE ACCESS BY INDEX ROWID| TMP_OPERATIONS   |   826K|    20M|    10   (0)|
|   4 |     INDEX RANGE SCAN          | SYS_C0030076     |   148K|       |     2   (0)|
|   5 |    TABLE ACCESS BY INDEX ROWID| OPERATIONS       |     1 |   105 |     2   (0)|
|   6 |     INDEX UNIQUE SCAN         | M2_OPRS_PK       |     1 |       |     1   (0)|
|   7 |   TABLE ACCESS BY INDEX ROWID | CDR              |     1 |    40 |     2   (0)|
|   8 |    INDEX UNIQUE SCAN          | M2_CDR_OPRS_FRGN |     1 |       |     1   (0)|
---------------------------------------------------------------------------------------
28 июн 07, 17:40    [4328366]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
KDIMA
Что есть такого в 10, что заставляет оптимизатор пользовать полный скан ?
Добавлен новый метод для внешнего соединения, которого не было в предыдущих версиях:
HASH JOIN OUTER
В традициях Oracle новым методам приписывать несколько более оптимистически низкую стоимость :-). Наверное, многие помнят BITMAP CONVERSION FROM | TO ROWID в 9i и соответствующий скрытый параметр _b_tree_bitmap_plans.

Возможно _optim_peek_user_binds также имел место быть. Можете объяснить это ? Вроде как здесь OPTIMIZER_DYNAMIC_SAMPLING и так вроде был равен 1.

Всего
ЗЫ. За что вы так ненавидите dbms_xplan (см. utlxpls, например)? Тема фильтрующих предикатов не раскрыта :-).
28 июн 07, 18:28    [4328610]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
_fast=true
Member

Откуда: x$ksppi
Сообщений: 205
Ааз
Можете объяснить это ? Вроде как здесь OPTIMIZER_DYNAMIC_SAMPLING и так вроде был равен 1.
Всего
ЗЫ. За что вы так ненавидите dbms_xplan (см. utlxpls, например)? Тема фильтрующих предикатов не раскрыта :-).

В первом примере у автора в 10g OPTIMIZER_DYNAMIC_SAMPLING равен 2. Это хорошо видно в трассировочном файле. Также там видно, что Oracle выполняет динамический сбор статистики по временной таблице в 10g. После сбора статистики кардинальность была совершенно другая (1024K против 818), отсюда и совершенно другие пути доступа. Так что неn ничего удивительного, что при установке его обратно в 1 план выполнения вернулся в исходный (ну по крайней мере пути доступа и кардинальность, стоимость различается, но это влияние системной статистики).
Почему у автора кардинальность расчитывается неправильно выяснять особо неохота, да и времени нет.
Ну и идеями Вашего анонимного тезки не увлекался, вопрос же был "Что есть такого в 10, что заставляет оптимизатор пользовать полный скан?" :)

p.s. Насчет предикатов согласен, но тогда уж юзать 10060 - у нас же все по взрослому?
29 июн 07, 00:05    [4329262]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
KDIMA
Member

Откуда: Россия, Тверь
Сообщений: 120
Ааз
Можете объяснить это ? Вроде как здесь OPTIMIZER_DYNAMIC_SAMPLING и так вроде был равен 1.

Всего
ЗЫ. За что вы так ненавидите dbms_xplan (см. utlxpls, например)? Тема фильтрующих предикатов не раскрыта :-).


OPTIMIZER_DYNAMIC_SAMPLING на момент выполнения запроса действительно был 2, с 1 запостил уже в процессе эксперимента. Извиняюсь.

Чего-ж сразу ненавидите ? dbms_xplan я иногда даже люблю, просто привычка какая-то есть к SET AUTO....;

Пока оставил optimizer_mode=FIRST_ROWS. Надо дальше уж двигаться. Столько всего еще проверять...
Спасибо за советы!
29 июн 07, 08:48    [4329621]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
trak
Member

Откуда: spb.ru
Сообщений: 802
Ааз
[quot KDIMA]Наверное, многие помнят BITMAP CONVERSION FROM | TO ROWID в 9i и соответствующий скрытый параметр _b_tree_bitmap_plans.


НЕНАВИЖУ!!!!!!!!
УБИВАЮСЬ ГОЛОВОЙ ОП ТАПОК!!!!!
29 июн 07, 10:29    [4330151]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
_fast=true
Member

Откуда: x$ksppi
Сообщений: 205
trak
НЕНАВИЖУ!!!!!!!!
УБИВАЮСЬ ГОЛОВОЙ ОП ТАПОК!!!!!

Думаете, это поможет автору в решении его проблемы?

p.s. caps lock выключите.
29 июн 07, 11:01    [4330416]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
AttachWork
Member

Откуда: г. Ульяновск
Сообщений: 125
Теже грабли. теже глюки.
Производительность упала в разы, то что делалось за полчаса, доходит до 2-х часов.
27 июн 08, 11:15    [5856840]     Ответить | Цитировать Сообщить модератору
 Re: Миграция в 10g - план поехал  [new]
AttachWork
Member

Откуда: г. Ульяновск
Сообщений: 125
параметры инициализации

Name 10g (новая) 9i (старая)
aq_tm_processes 0 1
asm_diskgroups отсутствует
asm_diskstring отсутствует
asm_power_limit 1 отсутствует
audit_file_dest D:\ORACLE\PRODUCT\10.2.0\ADMIN\M2000\ADUMP отсутствует
commit_write отсутствует
create_stored_outlines отсутствует
db_cache_size 0 671088640
db_flashback_retention_target 1440 отсутствует
db_recovery_file_dest D:\oracle\product\10.2.0/flash_recovery_area отсутствует
db_recovery_file_dest_size 2147483648 отсутствует
db_unique_name blablabla
dblink_encrypt_login отсутствует FALSE
ddl_wait_for_locks FALSE отсутствует
enqueue_resources отсутствует 968
fast_start_mttr_target 0 300
fileio_network_adapters отсутствует
gcs_server_processes 0 отсутствует
hash_area_size 131072 1048576
hash_join_enabled отсутствует TRUE
instance_type RDBMS отсутствует
java_pool_size 0 159383552
large_pool_size 0 8388608
ldap_directory_access NONE отсутствует
log_archive_config отсутствует
log_archive_local_first TRUE отсутствует
log_buffer 6980608 524288
log_parallelism отсутствует 1
max_commit_propagation_delay 0 700
max_dispatchers 5
max_enabled_roles 150 30
max_shared_servers 20
max_rollback_segments отсутствует 37
max_shared_servers отсутствует 20
mts_circuits отсутствует 170
mts_dispatchers отсутствует (PROTOCOL=TCP) (SERVICE=m2000XDB)
mts_listener_address отсутствует
mts_max_dispatchers отсутствует 5
mts_max_servers отсутствует 20
mts_multiple_listeners отсутствует FALSE
mts_servers отсутствует 1
mts_service отсутствует m2000
mts_sessions отсутствует 165
olap_page_pool_size 0 33554432
optimizer_dynamic_sampling 2 1
optimizer_features_enable 10.2.0.4 09.02.2000
optimizer_mode ALL_ROWS CHOOSE
optimizer_max_permutations отсутствует 2000
optimizer_secure_view_merging TRUE отсутствует
oracle_trace_collection_name отсутствует
oracle_trace_collection_path отсутствует %ORACLE_HOME%\OTRACE\ADMIN\CDF\
oracle_trace_collection_size отсутствует 5242880
oracle_trace_enable отсутствует FALSE
oracle_trace_facility_name отсутствует oracled
oracle_trace_facility_path отсутствует %ORACLE_HOME%\OTRACE\ADMIN\FDF\
parallel_adaptive_multi_user TRUE FALSE
parallel_max_servers 80 5
pga_aggregate_target 734003200 152043520
partition_view_enabled отсутствует FALSE
plsql_compiler_flags INTERPRETED; NON_DEBUG INTERPRETED
plsql_native_c_compiler отсутствует
plsql_debug FALSE отсутствует
plsql_optimize_level 2 отсутствует
plsql_native_linker отсутствует
plsql_native_make_file_name отсутствует
plsql_native_make_utility отсутствует
plsql_warnings DISABLE:ALL отсутствует
pre_11g_enable_capture FALSE отсутствует
recyclebin on отсутствует
resumable_timeout 0 отсутствует
row_locking отсутствует always
serializable отсутствует FALSE
session_cached_cursors 20 0
sga_max_size 1157627904 1376856236
sga_target 1157627904 отсутствует
shared_pool_reserved_size 8808038 23907532
shared_pool_size 0 478150656
shared_server_sessions 165
skip_unusable_indexes TRUE отсутствует
smtp_out_server отсутствует
sort_area_size 65536 524288
sqltune_category DEFAULT отсутствует
streams_pool_size 0 отсутствует
transaction_auditing отсутствует TRUE
undo_retention 900 10800
undo_suppress_errors FALSE
27 июн 08, 11:21    [5856890]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить