Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 тормозит приложение  [new]
Adel2
Guest
Здравствуйте,

у меня тормозит приложение, удалось поймать селект со статистикой,
что можно понять из ниже следующего, выполнение длится и сейчас около 30-40 секунд :\
Мне нужно узнать узнать где нужно рыть в Оракле, с селектом все нормально, так как раньше все быстро работало
SELECT *
FROM
A WHERE ( upper(name) LIKE upper('andre%%') ) and (emp_number IS 
NOT NULL) ORDER BY UPPER(name) ASC, UPPER(emp_number) ASC, 
UPPER(unit_number) ASC, UPPER(departen) ASC

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.02 0.01 0 0 0 0
Execute 1 0.00 0.26 0 3 0 0
Fetch 1 0.64 0.81 414 9087 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 0.66 1.09 414 9090 0 1

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
24 апр 07, 14:33    [4062921]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17089
ddl табилцы и индексов в студию. план в студию. статистику обнови. результаты в студию.
24 апр 07, 14:36    [4062942]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
evostr
Member

Откуда: Екатеринбург
Сообщений: 1278
Adel2
у меня тормозит приложение, удалось поймать селект со статистикой,
что можно понять из ниже следующего, выполнение длится и сейчас около 30-40 секунд :\

Приведенный запрос выполняется за 1 секунду. Смотрите, что еще есть в трейсе.
Adel2
Мне нужно узнать узнать где нужно рыть в Оракле, с селектом все нормально, так как раньше все быстро работало

Подумайте, что могло измениться.
24 апр 07, 14:42    [4062985]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
Adel2
Guest
Насчет индексов вы правы их по функции upper(name) нету. Да я создам этот индекс,
но дело не в этом. Дело в том что все это работало пиемлимо без индексов.
Просто запросы периодически становятся медленными.
Может ли это быть
1. Изза тщательной работы CPU на сервере? временами достигает 90-100%?
2. Изза обращений многих схем в одно табличное пространство? как мне вывести отчет, чтоб понять что именно tablespace является узким местом?

Абсолютно ничего не менялось за последнее время
24 апр 07, 15:02    [4063162]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17089
автор
Дело в том что все это работало пиемлимо без индексов.

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

как все просто

автор
1. Изза тщательной работы CPU на сервере?

не. плохо стараются

автор
ак мне вывести отчет, чтоб понять что именно tablespace является узким местом

статспак
автор
Абсолютно ничего не менялось за последнее время

сосем-совсем ничего?
и данные не добавлялись?
24 апр 07, 15:24    [4063325]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
Adel2
Guest
вывел отчет из статспака:
правда не могу понять :\
помогите плизз

STATSPACK report for

DB Name         DB Id    Instance     Inst Num Release     Cluster Host
------------ ----------- ------------ -------- ----------- ------- ------------
DBBAS         3863864387 DBBAS               1 9.2.0.7.0   NO      snoop

              Snap Id     Snap Time      Sessions Curs/Sess Comment
            --------- ------------------ -------- --------- -------------------
Begin Snap:     44463 24-Apr-07 15:00:16       89     874.5
  End Snap:     44473 24-Apr-07 16:00:15       78   1,153.6
   Elapsed:               59.98 (mins)

Cache Sizes (end)
~~~~~~~~~~~~~~~~~
               Buffer Cache:       208M      Std Block Size:          8K
           Shared Pool Size:       112M          Log Buffer:      5,120K

Load Profile
~~~~~~~~~~~~                            Per Second       Per Transaction
                                   ---------------       ---------------
                  Redo size:            235,534.00             60,393.76
              Logical reads:             24,889.56              6,381.98
              Block changes:              1,465.21                375.70
             Physical reads:              3,776.19                968.26
            Physical writes:                 60.86                 15.60
                 User calls:                125.53                 32.19
                     Parses:                 37.05                  9.50
                Hard parses:                  5.03                  1.29
                      Sorts:                 17.36                  4.45
                     Logons:                  7.10                  1.82
                   Executes:                 45.56                 11.68
               Transactions:                  3.90

  % Blocks changed per Read:    5.89    Recursive Call %:     54.89
 Rollback per transaction %:    0.06       Rows per Sort:    182.09

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %:   99.75       Redo NoWait %:     99.99
            Buffer  Hit   %:   93.56    In-memory Sort %:     99.98
            Library Hit   %:   94.02        Soft Parse %:     86.42
         Execute to Parse %:   18.67         Latch Hit %:     99.72
Parse CPU to Parse Elapsd %:   28.26     % Non-Parse CPU:     95.00

 Shared Pool Statistics        Begin   End
                               ------  ------
             Memory Usage %:   96.08   93.55
    % SQL with executions>1:   50.38   31.95
  % Memory for SQL w/exec>1:   33.48   28.22

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                                     % Total
Event                                               Waits    Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file sequential read                         2,481,462       6,549    24.27
db file scattered read                            885,023       6,226    23.08
CPU time                                                        4,672    17.32
PX Deq Credit: send blkd                           37,948       2,632     9.75
enqueue                                             6,919       2,145     7.95
          -------------------------------------------------------------
Wait Events for DB: DBBAS  Instance: DBBAS Snaps: 44463 -44473
-> s  - second
-> cs - centisecond -     100th of a second
-> ms - millisecond -    1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)

                                                                   Avg
                                                     Total Wait   wait    Waits
Event                               Waits   Timeouts   Time (s)   (ms)     /txn
---------------------------- ------------ ---------- ---------- ------ --------
db file sequential read         2,481,462          0      6,549      3    176.8
db file scattered read            885,023          0      6,226      7     63.1
PX Deq Credit: send blkd           37,948        566      2,632     69      2.7
enqueue                             6,919        283      2,145    310      0.5
PX Deq: Execute Reply             197,907         44      1,597      8     14.1
buffer busy waits                 222,232        142      1,157      5     15.8
log file sync                      17,293        126        395     23      1.2
PX Deq: Signal ACK                 16,053      5,778        304     19      1.1
log file parallel write            20,586          0        285     14      1.5
library cache lock                    115         68        252   2189      0.0
latch free                         37,154     18,521        214      6      2.6
PX Deq: Table Q Sample              1,694         90         56     33      0.1
library cache load lock                39         11         50   1277      0.0
log file sequential read            1,023          0         47     46      0.1
PX Deq: Msg Fragment               15,907          1         47      3      1.1
log file switch (checkpoint            45         31         40    883      0.0
PX qref latch                       2,878      2,059         37     13      0.2
PX Deq Credit: need buffer          4,890          0         37      8      0.3
db file parallel read                  91          0         31    337      0.0
library cache pin                   5,325          1         25      5      0.4
log file switch completion            175          2         23    132      0.0
PX Deq: Parse Reply                13,662          3         22      2      1.0
control file sequential read       16,872          0         16      1      1.2
SQL*Net more data to client       135,140          0         14      0      9.6
db file single write                  349          0         12     35      0.0
direct path read                1,033,835          0         11      0     73.7
control file parallel write         1,725          0         10      6      0.1
PX Deq: Join ACK                   13,935          0          9      1      1.0
log buffer space                       37          0          8    215      0.0
PX Deq: Table Q Get Keys              417          0          7     17      0.0
local write wait                       13          0          2    138      0.0
sort segment request                    1          1          1    985      0.0
process startup                        15          0          1     59      0.0
PX Deq: Table Q qref                1,845          0          1      0      0.1
LGWR wait for redo copy               235         11          0      2      0.0
log file single write                 132          0          0      3      0.0
row cache lock                         17          0          0     13      0.0
wait list latch free                    9          0          0     14      0.0
SQL*Net break/reset to clien           84          0          0      1      0.0
direct path write                   3,942          0          0      0      0.3
slave TJ process wait                   1          1          0     18      0.0
async disk IO                         231          0          0      0      0.0
SQL*Net message from client       320,910          0    160,242    499     22.9
PX Deq: Execution Msg             450,355        811      7,297     16     32.1
PX Deq: Table Q Normal             95,177      2,223      5,073     53      6.8
PX Idle Wait                       24,461        354      4,024    164      1.7
jobq slave wait                       437        417      1,268   2901      0.0
SQL*Net more data from clien       24,740          0          1      0      1.8
SQL*Net message to client         320,905          0          1      0     22.9
Wait Events for DB: DBBAS  Instance: DBBAS Snaps: 44463 -44473
-> s  - second
-> cs - centisecond -     100th of a second
-> ms - millisecond -    1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)

                                                                   Avg
                                                     Total Wait   wait    Waits
Event                               Waits   Timeouts   Time (s)   (ms)     /txn
---------------------------- ------------ ---------- ---------- ------ --------
          -------------------------------------------------------------
Background Wait Events for DB: DBBAS Instance: DBBAS Snaps: 44463 -44473
-> ordered by wait time desc, waits desc (idle events last)

                                                                   Avg
                                                     Total Wait   wait    Waits
Event                               Waits   Timeouts   Time (s)   (ms)     /txn
---------------------------- ------------ ---------- ---------- ------ --------
log file parallel write            20,592          0        285     14      1.5
log file sequential read            1,023          0         47     46      0.1
db file sequential read               625          0         21     33      0.0
db file single write                  341          0         12     36      0.0
control file parallel write         1,713          0          9      5      0.1
db file scattered read                 95          0          6     68      0.0
enqueue                                28          0          4    130      0.0
control file sequential read        2,413          0          1      0      0.2
log buffer space                        9          0          1     99      0.0
latch free                            160         43          1      4      0.0
LGWR wait for redo copy               235         11          0      2      0.0
log file single write                 132          0          0      3      0.0
buffer busy waits                       2          0          0     45      0.0
rdbms ipc reply                        53          0          0      0      0.0
async disk IO                         231          0          0      0      0.0
rdbms ipc message                  60,382      5,839     26,040    431      4.3
pmon timer                          1,982      1,970      3,507   1769      0.1
smon timer                            137          1      3,198  23344      0.0
24 апр 07, 15:34    [4063403]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
badm
Member

Откуда: Kazan
Сообщений: 984
А зачем выложил отчет за час? если запрос длится 40 секунд, значит и отчет давай за это время, ибо то что ты предоставил напрямую не относятся к твоему запросу и при советах о настройке по данному отчету правильного совета не дождешься (только если случайно), и вообще хорошо бы отчет по отдельной сессии, а то наверно там много кто работает ? )))

и можешь сказать приблезительно объемы таблицы когда все работало нормально и объем сейчас, есть ли статистика по табличке и индексам, и припомни что с момента "нормальной" работы могло изменится? и еще не було ли глобальных изменений в таблице как то delete, update, insert возможно индексы надо перестроить!
24 апр 07, 16:01    [4063627]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
Adel2
Guest
Ок, выложу, только вот система опять нормально работает,
жду пока начнутся тормоза :\
24 апр 07, 16:58    [4064099]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
evostr
Member

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

Ой! не надо только вот отчет statspack для одного запроса делать. Посмотрите лучше, что с сервером происходит в этот момент (загрузка CPU, I/O). Кстати, а регулярность появления тормозов какая? Может у вас какое-нибудь тяжелое задание периодически запускается?
Сколько памяти на сервере? Какая ОС? Статистику собираете? Если да, то как?
Для анализа запроса лучше использовать трассировку, хотя как я понял ее результат у вас есть, вот с ним и разбирайтесь.
По тому что есть.
1. Оракл для получения одной строки выполняет больше 9000 логических чтений. Имхо, многовато :). А с учетом предыдущей темы, можно предположить, что это не единичное выполнение данного запроса (ну или аналогичных, т.к. переменные не используются). Индекс бы не помешал.
2. Вы говорите о 30-40 секундах, а из отчета видно что запрос выполнялся чуть более 1. Что творилось в остальное время - посмотрите в трейсе.
И в целом по системе.
3. db file scattered read 23% - много. Возможно где-то еще отсутствуют индексы и ненужные full scan-ы идут.
4. Про hard parse вы и сами в курсе :)
Остальное все потом...
24 апр 07, 21:02    [4065319]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
R432
Guest
Sessions < 100
Logons: 7.10 /sec
Интересная системка...
25 апр 07, 08:23    [4065988]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
Adel2
Guest
Возвращаясь к проблеме

Кстати, а регулярность появления тормозов какая? -Не знаю, точной статистики нету :\

Может у вас какое-нибудь тяжелое задание периодически запускается?
Есть периодическая задача, выполняется каждый час, думаете она может тормозить систему?:
select       asset,
             trunc(a_date,'HH') a_hour,
             round(avg(e_time),0) round_e_time,
             min(em_time) min_e_time,
             max(e_time) max_e_time,
             count(*) total
            from
             A
            where
             trunc(s_date,'HH') > (select max(s_hour) from B) and
             (sysdate-trunc(s_date,'HH'))*24 > 1
            group by
             asset,
             trunc(s_date,'HH')

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.04       0.05          1         49          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1     25.45      95.31     119235     120109          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3     25.49      95.37     119236     120158          0           0

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 118  

Сколько памяти на сервере? 8 ГБ, свободно 2,5 ГБ - 0.5 ГБ (периодически)
Какая ОС? Солярис
Статистику собираете? Да Если да, то как? Статистика собирается каждый таблиц которые неделю не анализровались или же sample size меньше чем 9. Метод ESTIMATE, SAMPLE 10.

Для анализа запроса лучше использовать трассировку, хотя как я понял ее результат у вас есть, вот с ним и разбирайтесь.
По тому что есть.
1. Оракл для получения одной строки выполняет больше 9000 логических чтений. Имхо, многовато :). А с учетом предыдущей темы, можно предположить, что это не единичное выполнение данного запроса (ну или аналогичных, т.к. переменные не используются). Индекс бы не помешал. - Да индекс я введу, правда хочу узнать прежде почему вдруг работало нормально а теперь медленно

2. Вы говорите о 30-40 секундах, а из отчета видно что запрос выполнялся чуть более 1. Что творилось в остальное время - посмотрите в трейсе.
И в целом по системе.
Да я выбрал неудачный трейс файл, поставил трейс после логона по схеме, за минуту генерируются более 30 -40 файлов.

3. db file scattered read 23% - много. Возможно где-то еще отсутствуют индексы и ненужные full scan-ы идут.
Да согласен. Решит ли это проблему производительности?
4. Про hard parse вы и сами в курсе :)
Честно сказать, не уверен что имеете ввиду, вы про бинды?


Здесь в этой теме я както упоминал о интенсивном использовании тэйблспейса. То что на нем сидят 5-6 схем. может ли это быть причиной?
50-60 миллионов физических чтений, т.е три файла по 15 миллионов физ. чтений за пару дней :\

Остальное все потом...
25 апр 07, 10:58    [4066741]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
evostr
Member

Откуда: Екатеринбург
Сообщений: 1278
Adel2
Возвращаясь к проблеме

Пожалуйста, в своих сообщениях отделяйте мои слова от Ваших. Есть кнопка quote

Adel2
Не знаю, точной статистики нету :\

Что мешает узнать?

Adel2
Есть периодическая задача, выполняется каждый час, думаете она может тормозить систему?

Об этом можно сказать, узнав когда возникают тормоза. Но вобще сам по себе запрос, выполняющий 120 тыс. физических чтений и не возвращающий ни одной строки, мне лично не нравится :)

Adel2
8 ГБ, свободно 2,5 ГБ - 0.5 ГБ (периодически)

А чем память то занята? Ораклу, судя по statspack, Вы совсем мало выделили.
Adel2
Солярис

В Solaris есть много утилит для диагностики производительности. Вот и смотрите, что происходит на сервере в момент тормозов и кто грузит систему. iostat, vmstat, prstat, sar Вам в помощь.

Adel2
Статистика собирается каждый таблиц которые неделю не анализровались или же sample size меньше чем 9. Метод ESTIMATE, SAMPLE 10.

Собирается - это хорошо. Но сам метод у меня вызывает определенные сомнения, но об этом пока рано :)

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

С этим полностью согласен. Сам тоже всегда предпочитаю сначала разобраться.

Adel2
Да я выбрал неудачный трейс файл, поставил трейс после логона по схеме, за минуту генерируются более 30 -40 файлов.

А что так много? У Вас при формировании каждого отчета отдельная сессия что-ли открывается?

Adel2
Да согласен. Решит ли это проблему производительности?

Избавление от fullscan, там где они действительно не нужны, должно повысить производительность, как отдельных запросов (где они были), так и системы в целом.

Adel2
Честно сказать, не уверен что имеете ввиду, вы про бинды?

Да.

Adel2
Здесь в этой теме я както упоминал о интенсивном использовании тэйблспейса. То что на нем сидят 5-6 схем. может ли это быть причиной? 50-60 миллионов физических чтений, т.е три файла по 15 миллионов физ. чтений за пару дней :\

Тут нужно больше данных о вашей подсистеме I/O (что за диски, raid и т.д.), ну и как сами файлы данных распределены по ним. Если одни диски перегружены, а другие простаивают, то нужно перераспределять нагрузку.
25 апр 07, 11:56    [4067331]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
Adel2
Guest
evostr

Пожалуйста, в своих сообщениях отделяйте мои слова от Ваших. Есть кнопка quote

сорри, я не совсем разобрался еще в форуме
Adel2
Не знаю, точной статистики нету :\

evostr

Что мешает узнать?

Скажем пользователи системы не знают периодичность и точные времена, однажды я их уже просил фиксировать время и детали тормозов, но они так и не успевают это делать
evostr


Об этом можно сказать, узнав когда возникают тормоза. Но вобще сам по себе запрос, выполняющий 120 тыс. физических чтений и не возвращающий ни одной строки, мне лично не нравится :)

Да меня тоже это удивило, возможно они время от времени возвращают строки
evostr

А чем память то занята? Ораклу, судя по statspack, Вы совсем мало выделили.

На сервере еще несколько баз крутятся (7-8 баз). Думаете мне надо выделить еще пространства для Буффер Кэша, я вот думаю об этом, но что то мне подсказывает, что проблему надо решить без увеличения ресурсов
evostr

В Solaris есть много утилит для диагностики производительности. Вот и смотрите, что происходит на сервере в момент тормозов и кто грузит систему. iostat, vmstat, prstat, sar Вам в помощь.
да видите ли я просил их вести статистику, они ведут посредсвом SAR,но с сара создать графу вызывает трудности, все детали в одном файле и времени потребует такой анализ

evostr

А что так много? У Вас при формировании каждого отчета отдельная сессия что-ли открывается?

Да это веб приложение, при каждом обращении к Ораклу создаёт сессию и убивает, пользователей тоже не мало
evostr

Избавление от fullscan, там где они действительно не нужны, должно повысить производительность, как отдельных запросов (где они были), так и системы в целом.

опять же хотелось бы сперва выявить корень проблемы

evostr

Тут нужно больше данных о вашей подсистеме I/O (что за диски, raid и т.д.), ну и как сами файлы данных распределены по ним. Если одни диски перегружены, а другие простаивают, то нужно перераспределять нагрузку.

Система NAS, разбита на 5 групп. эти файлы находятся в одной группе, правда не знаю как узнать о нагрузке других групп. пойду поговорю с Админами
25 апр 07, 12:18    [4067500]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
Adel2
Guest
Кстати,
я правильно понимаю утилита выдаёт мне N количество физических чтений датафайла,
это ведь в частности с момента перезагрузки базы?
как называется таблица где можно найти эту информацию, к сожалению я лишь как найти это через утилиту :\, трейсить не охота, слишком большой трейс получится
25 апр 07, 13:07    [4067999]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
evostr
Member

Откуда: Екатеринбург
Сообщений: 1278
Adel2
я правильно понимаю утилита выдаёт мне N количество физических чтений датафайла,
это ведь в частности с момента перезагрузки базы?

Я не знаю, что за утилиту Вы используете, но в базе именно так учитывается.
Adel2
как называется таблица где можно найти эту информацию, к сожалению я лишь как найти это через утилиту :\, трейсить не охота, слишком большой трейс получится

X$KCFIO
Сорри, не удержался

p.s. на самом деле смотрите в представлении v$filestat, связав его с v$datafile
25 апр 07, 13:35    [4068277]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
Adel2
Guest
Заценил :)
я имел ввиду динамическую вьюшку
спасибо, я ею время от времени пользуюсь, но блин забываю :\
25 апр 07, 13:53    [4068450]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
Adel2
Guest
Почему то все трейс файлы на это приложение длятся не более 2-3 секунд,
тем не менее приложение продолжает тормозить. где я мог пропустить что-то? может и вовсе с базой все в порядке?
26 апр 07, 10:29    [4072306]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
evostr
Member

Откуда: Екатеринбург
Сообщений: 1278
Adel2
Почему то все трейс файлы на это приложение длятся не более 2-3 секунд,
тем не менее приложение продолжает тормозить. где я мог пропустить что-то? может и вовсе с базой все в порядке?

1. Так вы же сами писали, что "это веб приложение, при каждом обращении к Ораклу создаёт сессию и убивает". В файлы трассировки и пишется информация только в течение этого времени.
2. Что сделали для диагностики причин возникновения тормозов?
Если у вас в эти моменты CPU загружены на 100% и 7-8 других баз, как вы писали, то может проблема и не в этой БД, а просто в общей загрузке сервера другими базами/приложениями.
Но и в этой базе вам явно есть что оптимизировать :)
26 апр 07, 11:36    [4072868]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
Adel2
Guest
evostr

2. Что сделали для диагностики причин возникновения тормозов?
Если у вас в эти моменты CPU загружены на 100% и 7-8 других баз, как вы писали, то может проблема и не в этой БД, а просто в общей загрузке сервера другими базами/приложениями.
Но и в этой базе вам явно есть что оптимизировать :)


Для диагностики попросил сисадминов включить стаистику на сервере приложении и на сервере базы, и попросил пользователей фиксировать время замедлений более 30 секунд. Через 5-6 замедлнеий они пришлют мне отчет, я попрошу у сисадминов отчет, сравню, но мне кажется они не скоро включат статы. Кстати в прошлый раз мы так и не смогли нормализовать САР отчеты, хотел преобразовать их в ексель, не получалось изза ненормальных полей. пойду в Юникс форум спрошу что они делают для этого

Еще 2 вопроса
1. А не может быть что листенер перегружен? как можно выявить что он загружен? как то же люди определяют что им пора переходить на shared listener.
2. В базе прописан параметр parallel max server=8, меня это настораживает, так как он не дефолтный а в других базах на том же сервере по дефолту стоит 5 (в описании значение по умолчанию присуждается по критериям CPU и тд)

evostr

Но и в этой базе вам явно есть что оптимизировать :)

может поможете, укажете как и где оптимизировать. :\
26 апр 07, 14:07    [4073978]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17089
автор
hared listener.

мож shared server? дык когда тыщи три одновременных коннектов будет?
26 апр 07, 14:38    [4074256]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
Vya4ek
Member

Откуда:
Сообщений: 47
Добрый день Уважаемые. подскажите как уменьшить buffer wait time
а то уже за тыщу перевалило. Заранее спасибо
8 май 07, 12:55    [4113509]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
bbw?
Guest
Vya4ek
Добрый день Уважаемые. подскажите как уменьшить buffer wait time
а то уже за тыщу перевалило. Заранее спасибо

Вы о чем?
8 май 07, 13:27    [4113948]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
Vya4ek
Member

Откуда:
Сообщений: 47
вот о чем.

К сообщению приложен файл. Размер - 0Kb
8 май 07, 14:14    [4114413]     Ответить | Цитировать Сообщить модератору
 Re: тормозит приложение  [new]
evostr
Member

Откуда: Екатеринбург
Сообщений: 1278
2 Vya4ek
Если действительно есть проблемы с buffer busy wait, а не просто циферки не нравятся, то для начала нужно определить
1) reason code (в 9i - это параметр p3 у данного wait'а);
2) тип блоков, на которых возникают (v$waitstat);
3) сегменты (v$segment_statistics);
4) вызывающие их sql-операторы (если получится).

p.s. И вобще-то можно было новую тему начать.
8 май 07, 15:25    [4114895]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить