[ОТВЕТИТЬ]
Опции темы
06.12.2010 15:59  
Shiba
В течение трех дней сильно упала скорость БД. На графике в EM Perfomance, в active session ярко выделяется Concurrency.
В ADDM:
Ожидания "latch: library cache" заняли 50\% времени работы базы данных.
Ожидания "latch: shared pool" заняли 7\% времени работы базы данных.

параметр cursor sharing = force

Oracle 10.2.0.4
SM 1.026.4
 
06.12.2010 20:43  
bob
Можно узнать, для информации, за что был назначен штраф? Возможно, я (с ораклом не дружу в принципе), написал бы примерно так же при наличии проблем.
 
06.12.2010 21:33  
OlegON
Давайте не флудить. За что штраф - можно посмотреть, кликнув на красной карточке справа. В данном случае он был выдан за нарушение правил, неуказание города в профиле. Дальнейшие вопросы и обсуждения на тему штрафов в этой теме буду удалять.
Теперь придется по теме. Автор из того, что надо было бы указать для анализа проблемы (и вообще есть ли проблема в БД?) выдал что-то вроде "доктор, у меня болит живот". Извини, но когда, что ты перед этим ел, сколько ты съел и насколько сильно болит и с какой стороны - ничего не сказал. Лечение производительности в данном случае аналогично лечению человека по фотографии, поэтому и не ответил раньше.
Оптимизатор там есть?
 
07.12.2010 11:44  
Shiba
DETAILED ADDM REPORT FOR TASK 'ЗАДАЧА_59638' WITH ID 59638
----------------------------------------------------------

Analysis Period: 06-ДЕК-2010 from 14:42:20 to 16:00:59
Database ID/Instance: 4107660304/1
Database/Instance Names: *******/*******
Host Name: sbd05
Database Version: 10.2.0.4.0
Snapshot Range: from 13680 to 13681
Database Time: 126357 seconds
Average Database Load: 26,8 active sessions

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


FINDING 1: 47% impact (59122 seconds)
-------------------------------------
Конкуренция за внутренние блокировки, относящиеся к разделяемому пулу,
потребовала существенного времени работы базы данных.

NO RECOMMENDATIONS AVAILABLE

ADDITIONAL INFORMATION:
Ожидания "latch: library cache" заняли 37\% времени работы базы данных.
Ожидания "latch: shared pool" заняли 8\% времени работы базы данных.

SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: Класс ожидания "Конкуренция" потребовал существенного времени
работы базы данных. (47% impact [59334 seconds])

FINDING 2: 29% impact (36645 seconds)
-------------------------------------
Обнаружены операторы SQL, которые потребовали существенного времени работы
базы данных.

RECOMMENDATION 1: SQL Tuning, 12% benefit (15166 seconds)
ACTION: Изучите оператор SQL с SQL_ID "57w71dgk5qbtx" с точки зрения
повышения производительности.
RELEVANT OBJECT: SQL statement with SQL_ID 57w71dgk5qbtx and
PLAN_HASH 1549122313
SELECT DISTINCT SUBSTR(KGLNAOBJ,11) SID FROM X$KGLOB WHERE KGLHDNSP =
7 AND KGLNAOBJ LIKE 'ORA$ALERT$%' AND BITAND(KGLHDFLG,128)!=0 UNION
SELECT DISTINCT SID FROM DBMS_ALERT_INFO
RATIONALE: Оператор SQL с SQL_ID "57w71dgk5qbtx" выполнялся 449 раз, и
суммарное время его выполнения составило 33 сек.
RATIONALE: Ожидание события "latch: library cache" в классе ожидания
"Concurrency" учтено как 39% от времени базы данных, затраченного на
обработку оператора SQL с SQL_ID "57w71dgk5qbtx".

RECOMMENDATION 2: SQL Tuning, 5,4% benefit (6800 seconds)
ACTION: Настройте блок PL/SQL с SQL_ID "5k99n73mamgnd". См. главу
"Настройка приложений PL/SQL" в "Руководстве пользователя и
справочном руководстве PL/SQL "
RELEVANT OBJECT: SQL statement with SQL_ID 5k99n73mamgnd
begin supermag.core.NewSession(:V00001); end;
RATIONALE: Оператор SQL с SQL_ID "5k99n73mamgnd" выполнялся 261 раз, и
суммарное время его выполнения составило 26 сек.

RECOMMENDATION 3: SQL Tuning, 4,3% benefit (5372 seconds)
ACTION: Настройте блок PL/SQL с SQL_ID "01axthsn5jj8w". См. главу
"Настройка приложений PL/SQL" в "Руководстве пользователя и
справочном руководстве PL/SQL "
RELEVANT OBJECT: SQL statement with SQL_ID 01axthsn5jj8w
begin Supermag.SMBeginActionEx(:V00001,:V00002,:V00003,:V00004,:V0000
5,:V00006,:V00007,:V00008); end;
RATIONALE: Оператор SQL с SQL_ID "01axthsn5jj8w" выполнялся 4975 раз, и
суммарное время его выполнения составило 2.4 сек.

RECOMMENDATION 4: SQL Tuning, 4,2% benefit (5287 seconds)
ACTION: Запустите SQL Tuning Advisor для оператора SQL с SQL_ID
"amw5jcbza83tt".
RELEVANT OBJECT: SQL statement with SQL_ID amw5jcbza83tt and
PLAN_HASH 3458826458
SELECT /*+ INDEX_FFS(FFMapRep FFMapRep_Article) */ COUNT (*) FROM
FFMAPREP
ACTION: Изучите оператор SQL с SQL_ID "amw5jcbza83tt" с точки зрения
повышения производительности.
RELEVANT OBJECT: SQL statement with SQL_ID amw5jcbza83tt and
PLAN_HASH 3458826458
SELECT /*+ INDEX_FFS(FFMapRep FFMapRep_Article) */ COUNT (*) FROM
FFMAPREP
RATIONALE: Оператор SQL с SQL_ID "amw5jcbza83tt" выполнялся 6 раз, и
суммарное время его выполнения составило 881 сек.

RECOMMENDATION 5: SQL Tuning, 3,2% benefit (4020 seconds)
ACTION: Настройте блок PL/SQL с SQL_ID "2w0j6x3wdhsjn". См. главу
"Настройка приложений PL/SQL" в "Руководстве пользователя и
справочном руководстве PL/SQL "
RELEVANT OBJECT: SQL statement with SQL_ID 2w0j6x3wdhsjn
BEGIN
:Result := SUPERMAG.YZ_EXPORT.EXPORT_PREPAREDATA(:StartDate,
:StopDate, :Mode, :ConfigID);
END;
RATIONALE: Оператор SQL с SQL_ID "2w0j6x3wdhsjn" выполнялся 1 раз, и
суммарное время его выполнения составило 4282 сек.

FINDING 3: 20% impact (24766 seconds)
-------------------------------------
Неоптимальный размер памяти SGA вызвал дополнительные операции ввода/вывода и
аппаратный синтаксический анализ.

RECOMMENDATION 1: DB Configuration, 17% benefit (20915 seconds)
ACTION: Увеличьте размер SGA, задав значение параметра "sga_target"
равным 7500 Мбайт.

ADDITIONAL INFORMATION:
Значение параметра "sga_target" в период анализа равнялось "6000 M".

SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: Класс ожидания "Пользовательский ввод/вывод" потребовал
существенного времени работы базы данных. (23% impact [29534
seconds])
SYMPTOM: Аппаратный разбор операторов SQL потребовал существенного
времени работы базы данных. (7,6% impact [9586 seconds])
SYMPTOM: Конкуренция за внутренние блокировки, относящиеся к
разделяемому пулу, потребовала существенного времени работы
базы данных. (47% impact [59122 seconds])
INFO: Ожидания "latch: library cache" заняли 37\% времени работы
базы данных.
Ожидания "latch: shared pool" заняли 8\% времени работы базы
данных.
SYMPTOM: Класс ожидания "Конкуренция" потребовал существенного
времени работы базы данных. (47% impact [59334 seconds])

FINDING 4: 8,4% impact (10622 seconds)
--------------------------------------
Программный разбор операторов SQL потребовал существенного времени работы базы
данных.

RECOMMENDATION 1: Application Analysis, 8,4% benefit (10622 seconds)
ACTION: Изучите логику приложения для сохранения часто используемых
курсоров открытыми. Примите во внимание, что курсоры закрываются как
вызовами закрытий курсоров, так и при разрывах соединений сеансов.

RECOMMENDATION 2: DB Configuration, 8,4% benefit (10622 seconds)
ACTION: Рекомендуется увеличить максимальное число открытых курсоров,
которые могут существовать в сеансе, увеличив значение параметра
"open_cursors".
ACTION: Рекомендуетя увеличить размер кэша курсоров сеанса, увеличив
значение параметра "session_cached_cursors".
RATIONALE: Значение параметра "open_cursors" в период анализа равнялось
"300".
RATIONALE: Значение параметра "session_cached_cursors" в период анализа
равнялось "20".

SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: Конкуренция за внутренние блокировки, относящиеся к
разделяемому пулу, потребовала существенного времени работы
базы данных. (47% impact [59122 seconds])
INFO: Ожидания "latch: library cache" заняли 37\% времени работы базы
данных.
Ожидания "latch: shared pool" заняли 8\% времени работы базы
данных.
SYMPTOM: Класс ожидания "Конкуренция" потребовал существенного
времени работы базы данных. (47% impact [59334 seconds])

FINDING 5: 6% impact (7525 seconds)
-----------------------------------
Пропускная способность подсистемы ввода/вывода существенно ниже, чем
ожидалось.

RECOMMENDATION 1: Host Configuration, 6% benefit (7525 seconds)
ACTION: Рeкoмeндуeтся увeличить прoпускную спoсoбнoсть пoдсистемы
ввoда/вывoда. Oracle рeкoмeндуeт разнeсти всe файлы данных испoльзуя
ЕДИНУЮ мeтoдoлoгию. Вoзмoжнo, пoтрeбуeтся увeличить числo дискoв для
пoвышeния прoизвoдитeльнoсти. Bмecтo этoгo мoжнo пpимeнить peшeниe
Oracle для автoматичecкoгo упpавлeния хpанeниeм.
RATIONALE: В период анализа средняя пропускная способность ввода/вывода
файлов данных составляла 6.5 M в секунду для чтения и 109 K в секунду
для записи. Среднее время отклика для операций чтения одного блока
составляло 13 миллисекунд.

SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: Класс ожидания "Пользовательский ввод/вывод" потребовал
существенного времени работы базы данных. (23% impact [29534
seconds])

FINDING 6: 5,4% impact (6874 seconds)
-------------------------------------
Выполнение PL/SQL потребовало существенного времени работы базы данных.

RECOMMENDATION 1: SQL Tuning, 5,4% benefit (6874 seconds)
ACTION: Настройте блок PL/SQL с SQL_ID "01axthsn5jj8w". См. главу
"Настройка приложений PL/SQL" в "Руководстве пользователя и
справочном руководстве PL/SQL "
RELEVANT OBJECT: SQL statement with SQL_ID 01axthsn5jj8w
begin Supermag.SMBeginActionEx(:V00001,:V00002,:V00003,:V00004,:V0000
5,:V00006,:V00007,:V00008); end;
RATIONALE: Оператор SQL с SQL_ID "01axthsn5jj8w" выполнялся 4975 раз, и
суммарное время его выполнения составило 2.4 сек.
RATIONALE: Среднее время на выполнение PL/SQL составило 1.3 сек.

FINDING 7: 2,7% impact (3360 seconds)
-------------------------------------
Найдены отдельные сегменты базы данных, которые вызывают существенное время
ожидания ввода/вывода пользователем.

RECOMMENDATION 1: Segment Tuning, 2,7% benefit (3360 seconds)
ACTION: Изучите логику приложения, где используется ввод/вывод для TABLE
"SUPERMAG.SMSPEC" с идентификатором объекта 12956.
RELEVANT OBJECT: database object with id 12956
RATIONALE: Статистика операций ввода/вывода для этого объекта: 79 полных
сканирований объекта, 193067 операций физического чтения, 295
операций физической записи и 0 операций непосредственного чтения.
RATIONALE: Затрачено существенное время на ожидание оператором SQL с
SQL_ID "0ap72bxrc048d" ввода/вывода со стороны пользователя для
объекта, к которому преимущественно выполнялось обращение.
RELEVANT OBJECT: SQL statement with SQL_ID 0ap72bxrc048d
select sum( S.Quantity * decode (D.LocationTo, :"SYS_B_00",
:"SYS_B_01",
decode (D.LocationFrom, :"SYS_B_02" , -:"SYS_B_03", :"SYS_B_04") ) )
from Supermag.SmCard C, Supermag.SmDocuments D, Supermag.SmSpec S
where D.DocType = S.DocType and
D.ID = S.DocID and
C.Article = S.Article and
C.Article =:"SYS_B_05" and
D.DocState >= :"SYS_B_06" and
D.CreatedAt 0 AND ( G.QUANTITY >= S.QUANTITY OR :b4 = 0 )
AND G.QUANTITY
 
07.12.2010 11:46  
Shiba
CentOS release 5.5 (Final)
ядро
Linux 2.6.18-194.26.1.el5 #1 SMP Tue Nov 9 12:54:20 EST 2010 x86_64 x86_64 x86_64 GNU/Linux
 
07.12.2010 12:18  
Shiba
Вот, в частности, что может подвешивать

"SELECT DISTINCT SUBSTR(KGLNAOBJ,11) SID FROM X$KGLOB WHERE KGLHDNSP = 7 AND KGLNAOBJ LIKE 'ORA$ALERT$%' AND BITAND(KGLHDFLG,128)!=0 UNION SELECT DISTINCT SID FROM DBMS_ALERT_INFO
"
 
27.01.2011 11:53  
Shiba
При настройках sga_max_size от 5000М и выше, начинаются тормоза library cache.
При 6500М база чуть ли не намертво ложиться.
Более менее приемлема работа при 4500М.
 
17.11.2011 12:08  
leonid
Подниму старую тему, т.к. столкнулся с тем же.
При увеличении буферов (Кэш и Пул) выше некоторого предела БД "ложится" намертво.
Уменьшение буфера Кэш на лету отчасти решает проблему. Чтобы уменьшить Пул - надо перезагрузить сервак.

CPU 2 x X5650
mem 24Gb
Adaptec RAID10 + MaxIQ
Oracle 10.2.0.4.0 - 64bit
SUSE Linux Enterprise Server 11 (x86_64)
Размер БД (только данные) 250G.
СМ 1.026.3.5 + дописки
При увеличении SGA более 12G база работать перестает практически сразу.

Ответ на вопрос "Почему?" я нашел тут:


Как я понял (своими словами):
Процессор не успевает обработать данные в памяти. А по понятиям БД это много страшней, чем не успевать читать с диска. Когда процесс не успевает читать с диска - то тормозит он один. А когда проц не успевает обработать память - виснет все.
 
 
Опции темы



Часовой пояс GMT +3, время: 08:44.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.