SAPфорум.RU
https://www.sapboard.ru/forum/

Oracle 12c 12.2 -> high cpu usage
https://www.sapboard.ru/forum/viewtopic.php?f=14&t=96345		 Страница 3 из 3
Автор:  Egal [ Пн, май 07 2018, 17:50 ]
Заголовок сообщения:  Re: Oracle 12c 12.2 -> high cpu usage
SergoB написал(а):
Я посмотрел еще раз ваши селекты, можете посмотреть что значит --> "P"."OTYPE"='C'
Я не вижу такого для селекта с вашего прода.


HRP1002.OTYPE - тип объекта, С, должность.
Автор:  Egal [ Пн, май 07 2018, 17:52 ]
Заголовок сообщения:  Re: Oracle 12c 12.2 -> high cpu usage
Наверное потому, что:

В проде
ядро 745
версия DBSL: 745.04, пакет 320

В тесте
ядро 753
версия DBSL: 753.02, пакет 111
Автор:  SergoB [ Пн, май 07 2018, 18:01 ]
Заголовок сообщения:  Re: Oracle 12c 12.2 -> high cpu usage
Попробуйте для начала с тем же ядром, чтобы был прям SqlID одинаковый, тогда легче Oracle на баг указывать, если это баг с их стороны.
Автор:  Egal [ Вт, май 08 2018, 09:39 ]
Заголовок сообщения:  Re: Oracle 12c 12.2 -> high cpu usage
SergoB написал(а):
Попробуйте для начала с тем же ядром, чтобы был прям SqlID одинаковый, тогда легче Oracle на баг указывать, если это баг с их стороны.

Сейчас не реально.

Селект в обеих системах один и тот же:
Code:
  SELECT TLINE TABSEQNR FROM HRP1002 AS P
    INNER JOIN HRT1002 AS T ON P~TABNR = T~TABNR
  INTO CORRESPONDING FIELDS OF TABLE lt_hrline
    WHERE OTYPE = 'C' AND BEGDA <= i_date AND ENDDA >= i_date AND objid = i_STELL
  ORDER BY TABSEQNR.
Автор:  sap2me [ Пт, май 11 2018, 03:20 ]
Заголовок сообщения:  Re: Oracle 12c 12.2 -> high cpu usage
Egal написал:
Селект в обеих системах один и тот же:
Code:
  SELECT TLINE TABSEQNR FROM HRP1002 AS P
    INNER JOIN HRT1002 AS T ON P~TABNR = T~TABNR
  INTO CORRESPONDING FIELDS OF TABLE lt_hrline
    WHERE OTYPE = 'C' AND BEGDA <= i_date AND ENDDA >= i_date AND objid = i_STELL
  ORDER BY TABSEQNR.

В выложенном AWR вижу, что проблема все же не в CPU, а чтениях из буферного кэша:

Code:
db file sequential read      48.7   
DB CPU   46.6   


и если искать в ТОПах запрос который дает наибольший вклад в эти ожидания то мы видим запрос с sql_id 6m50v0x5g9mrq и в топе по времени выполнения и в топе по пользовательскому IO. Собственно ADDM на 94 странице и рекомендует начать оптимизацию с этого запроса:

Code:
SELECT DISTINCT "MANDT", "BUKRS", "KUNNR", "UMSKS", "UMSKZ", "AUGDT", "AUGBL", "ZUONR", "GJAHR", "BELNR", "BUZEI", "BUDAT", "BLDAT", "CPUDT", "WAERS", "XBLNR", "BLART", "MONAT", "BSCHL", "ZUMSK", "SHKZG", "GSBER", "MWSKZ", "DMBTR", "WRBTR", "MWSTS", "WMWST", "BDIFF", "BDIF2", "SGTXT", "PROJN", "AUFNR", "ANLN1", "ANLN2", "SAKNR", "HKONT", "FKONT", "FILKD", "ZFBDT", "ZTERM", "ZBD1T", "ZBD2T", "ZBD3T", "ZBD1P", "ZBD2P", "SKFBT", "SKNTO", "WSKTO", "ZLSCH", "ZLSPR", "ZBFIX", "HBKID ", "BVTYP", "REBZG", "REBZJ", "REBZZ", "SAMNR", "ANFBN", "ANFBJ", "ANFBU", "ANFAE", "MANSP", "MSCHL", "MADAT", "MANST", "MABER", "XNETB", "XANET", "XCPDD", "XINVE", "XZAHL", "MWSK1", "DMBT1", "WRBT1", "MWSK2", "DMBT2", "WRBT2", "MWSK3", "DMBT3", "WRBT3", "BSTAT", "VBUND", "VBELN", "REBZT", "INFAE", "STCEG", "EGBLD", "EGLLD", "RSTGR", "XNOZA", "VERTT", "VERTN", "VBEWA", "WVERW", "PROJK", "FIPOS", "NPLNR", "AUFPL", "APLZL", "XEGDR", "DMBE2", "DMBE3", "DMB21", "DMB22", "DMB23", "DMB31", "DMB32", "DMB33", "BDIF3", "XRAGL", "UZAWE", "XSTOV", "MWST2", "MWST3", "SKNT2", "SKNT3", "XREF1", "XREF2", "XARCH", "PSWSL", "PSWBT", "LZBKZ", "LANDL", "IMKEY", "VBEL2", "VPOS2", "POSN2", "ETEN2", "FISTL", "GEBER", "DABRZ", "XNEGP", "KOSTL", "RFZEI", "KKBER", "EMPFB", "PRCTR", "XREF3", "QSSKZ", "ZINKZ", "DTWS1", "DTWS2", "DTWS3", "DTWS4", "XPYPR", "KIDNO", "ABSBT", "CCBTC", "PYCUR", "PYAMT", "BUPLA", "SECCO", "CESSION_KZ", "PPDIFF", "PPDIF2", "PPDIF3", "KBLNR", "KBLPOS", "GRANT_NBR", "GMVKZ", "SRTYPE", "LOTKZ", "FKBER", "INTRENO", "PPRCT", "BUZID", "AUGGJ", "HKTID", "BUDGET_PD", "PAYS_PROV", "PAYS_TRAN", "MNDID", "KONTT", "KONTL", "UEBGDAT", "VNAME", "EGRUP", "BTYPE", "PROPMANO" FROM "BSAD" WHERE "MANDT"=:A0 AND "KUNNR" IN (:A1) AND "BUKRS"=:A2 AND "BUDAT"<=:A3 AND "HKONT" LIKE :A4 AND ("UMSKZ"=:A5 OR "UMSKZ"=:A6) AND "ZINKZ"=:A7


Если вы все-таки хотите пооптимизировать ваш конкретный запрос, то нужно найти его sql_id, child_number и на проде и на тесте

Code:
select sql_id,child_number,sql_text from v$sql where upper(sql_text) like '%SELECT DISTINCT "MANDT", "BUKRS", "KUNNR", "UMSKS""%'


а затем вытащить реальные планы выполнения запросом:
Code:
select * from table(dbms_xplan.display_cursor(ваш sql_id', ваш child_number));


тут уже можно будет и посравнивать
Автор:  SergoB [ Пт, май 11 2018, 08:28 ]
Заголовок сообщения:  Re: Oracle 12c 12.2 -> high cpu usage
sap2me написал(а):
Egal написал:
Селект в обеих системах один и тот же:
Code:
  SELECT TLINE TABSEQNR FROM HRP1002 AS P
    INNER JOIN HRT1002 AS T ON P~TABNR = T~TABNR
  INTO CORRESPONDING FIELDS OF TABLE lt_hrline
    WHERE OTYPE = 'C' AND BEGDA <= i_date AND ENDDA >= i_date AND objid = i_STELL
  ORDER BY TABSEQNR.

В выложенном AWR вижу, что проблема все же не в CPU, а чтениях из буферного кэша:

Code:
db file sequential read      48.7   
DB CPU   46.6   


и если искать в ТОПах запрос который дает наибольший вклад в эти ожидания то мы видим запрос с sql_id 6m50v0x5g9mrq и в топе по времени выполнения и в топе по пользовательскому IO. Собственно ADDM на 94 странице и рекомендует начать оптимизацию с этого запроса:

Code:
SELECT DISTINCT "MANDT", "BUKRS", "KUNNR", "UMSKS", "UMSKZ", "AUGDT", "AUGBL", "ZUONR", "GJAHR", "BELNR", "BUZEI", "BUDAT", "BLDAT", "CPUDT", "WAERS", "XBLNR", "BLART", "MONAT", "BSCHL", "ZUMSK", "SHKZG", "GSBER", "MWSKZ", "DMBTR", "WRBTR", "MWSTS", "WMWST", "BDIFF", "BDIF2", "SGTXT", "PROJN", "AUFNR", "ANLN1", "ANLN2", "SAKNR", "HKONT", "FKONT", "FILKD", "ZFBDT", "ZTERM", "ZBD1T", "ZBD2T", "ZBD3T", "ZBD1P", "ZBD2P", "SKFBT", "SKNTO", "WSKTO", "ZLSCH", "ZLSPR", "ZBFIX", "HBKID ", "BVTYP", "REBZG", "REBZJ", "REBZZ", "SAMNR", "ANFBN", "ANFBJ", "ANFBU", "ANFAE", "MANSP", "MSCHL", "MADAT", "MANST", "MABER", "XNETB", "XANET", "XCPDD", "XINVE", "XZAHL", "MWSK1", "DMBT1", "WRBT1", "MWSK2", "DMBT2", "WRBT2", "MWSK3", "DMBT3", "WRBT3", "BSTAT", "VBUND", "VBELN", "REBZT", "INFAE", "STCEG", "EGBLD", "EGLLD", "RSTGR", "XNOZA", "VERTT", "VERTN", "VBEWA", "WVERW", "PROJK", "FIPOS", "NPLNR", "AUFPL", "APLZL", "XEGDR", "DMBE2", "DMBE3", "DMB21", "DMB22", "DMB23", "DMB31", "DMB32", "DMB33", "BDIF3", "XRAGL", "UZAWE", "XSTOV", "MWST2", "MWST3", "SKNT2", "SKNT3", "XREF1", "XREF2", "XARCH", "PSWSL", "PSWBT", "LZBKZ", "LANDL", "IMKEY", "VBEL2", "VPOS2", "POSN2", "ETEN2", "FISTL", "GEBER", "DABRZ", "XNEGP", "KOSTL", "RFZEI", "KKBER", "EMPFB", "PRCTR", "XREF3", "QSSKZ", "ZINKZ", "DTWS1", "DTWS2", "DTWS3", "DTWS4", "XPYPR", "KIDNO", "ABSBT", "CCBTC", "PYCUR", "PYAMT", "BUPLA", "SECCO", "CESSION_KZ", "PPDIFF", "PPDIF2", "PPDIF3", "KBLNR", "KBLPOS", "GRANT_NBR", "GMVKZ", "SRTYPE", "LOTKZ", "FKBER", "INTRENO", "PPRCT", "BUZID", "AUGGJ", "HKTID", "BUDGET_PD", "PAYS_PROV", "PAYS_TRAN", "MNDID", "KONTT", "KONTL", "UEBGDAT", "VNAME", "EGRUP", "BTYPE", "PROPMANO" FROM "BSAD" WHERE "MANDT"=:A0 AND "KUNNR" IN (:A1) AND "BUKRS"=:A2 AND "BUDAT"<=:A3 AND "HKONT" LIKE :A4 AND ("UMSKZ"=:A5 OR "UMSKZ"=:A6) AND "ZINKZ"=:A7


Если вы все-таки хотите пооптимизировать ваш конкретный запрос, то нужно найти его sql_id, child_number и на проде и на тесте

Code:
select sql_id,child_number,sql_text from v$sql where upper(sql_text) like '%SELECT DISTINCT "MANDT", "BUKRS", "KUNNR", "UMSKS""%'


а затем вытащить реальные планы выполнения запросом:
Code:
select * from table(dbms_xplan.display_cursor(ваш sql_id', ваш child_number));


тут уже можно будет и посравнивать


Посравнивали уже, читайте раньше.
Автор:  SergoB [ Пт, май 11 2018, 09:20 ]
Заголовок сообщения:  Re: Oracle 12c 12.2 -> high cpu usage
Egal написал:
SergoB написал(а):
Попробуйте для начала с тем же ядром, чтобы был прям SqlID одинаковый, тогда легче Oracle на баг указывать, если это баг с их стороны.

Сейчас не реально.

Селект в обеих системах один и тот же:
Code:
  SELECT TLINE TABSEQNR FROM HRP1002 AS P
    INNER JOIN HRT1002 AS T ON P~TABNR = T~TABNR
  INTO CORRESPONDING FIELDS OF TABLE lt_hrline
    WHERE OTYPE = 'C' AND BEGDA <= i_date AND ENDDA >= i_date AND objid = i_STELL
  ORDER BY TABSEQNR.


Постройте еще одну копию, если тут не реально, и всё протестируйте в ней.
Пока у вас SqlID отличается, это не одно и тоже на стороне оптимайзера.
Добейтесь как минимум одинакового SQLID.
Автор:  sap2me [ Пт, май 11 2018, 10:33 ]
Заголовок сообщения:  Re: Oracle 12c 12.2 -> high cpu usage
SergoB написал(а):
Посравнивали уже, читайте раньше.

если ты про 2 картинки PNG, то там планы абсолютно одинаковы. разница может быть только за счет скорости работы дисковой системы. данных в табличках на продуктиве явно будет не меньше чем на тесте.

а вообще план вот так рабочий должен выглядеть:

Code:
SQL_ID  bb2u9fqah01q3, child number 0
-------------------------------------
SELECT "MATNR", "WERKS", "DBT_ASRT", "MATNR_PARENT", "MATNR_LEGACY",
"RESWK", "DISPR" FROM "MARC" WHERE "MANDT"=:A0 AND "DBT_ASRT" IN (:A1
,:A2 ,:A3 )

Plan hash value: 454562839

----------------------------------------------------------------------------------------
| Id  | Operation                   | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |          |       |       | 68892 (100)|          |
|*  1 |  TABLE ACCESS BY INDEX ROWID| MARC     |    15M|   667M| 68891  (10)| 00:01:09 |
|*  2 |   INDEX RANGE SCAN          | MARC~VBM |    21M|       |  8166   (4)| 00:00:09 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter((NVL("DBT_ASRT",' ')=:A1 OR NVL("DBT_ASRT",' ')=:A2 OR
              NVL("DBT_ASRT",' ')=:A3))
   2 - access("MANDT"=:A0)


с конкретным временем работы на каждом шаге.
Автор:  SergoB [ Пт, май 11 2018, 11:24 ]
Заголовок сообщения:  Re: Oracle 12c 12.2 -> high cpu usage
sap2me написал(а):
SergoB написал(а):
Посравнивали уже, читайте раньше.

если ты про 2 картинки PNG, то там планы абсолютно одинаковы. разница может быть только за счет скорости работы дисковой системы. данных в табличках на продуктиве явно будет не меньше чем на тесте.

а вообще план вот так рабочий должен выглядеть:

Code:
SQL_ID  bb2u9fqah01q3, child number 0
-------------------------------------
SELECT "MATNR", "WERKS", "DBT_ASRT", "MATNR_PARENT", "MATNR_LEGACY",
"RESWK", "DISPR" FROM "MARC" WHERE "MANDT"=:A0 AND "DBT_ASRT" IN (:A1
,:A2 ,:A3 )

Plan hash value: 454562839

----------------------------------------------------------------------------------------
| Id  | Operation                   | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |          |       |       | 68892 (100)|          |
|*  1 |  TABLE ACCESS BY INDEX ROWID| MARC     |    15M|   667M| 68891  (10)| 00:01:09 |
|*  2 |   INDEX RANGE SCAN          | MARC~VBM |    21M|       |  8166   (4)| 00:00:09 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter((NVL("DBT_ASRT",' ')=:A1 OR NVL("DBT_ASRT",' ')=:A2 OR
              NVL("DBT_ASRT",' ')=:A3))
   2 - access("MANDT"=:A0)


с конкретным временем работы на каждом шаге.



Читать совсем лень да? Не одинаковые там планы.

P.S. " разница может быть только за счет скорости работы дисковой системы" , так Egal говорит, что на этой же системе работало быстро до апгрейда.
Диски замедлились от апгрейда?

P.P.S. По поводу плана со временем, что предоставили то и смотрим как говорится :) В Explain можно просто нажать - вывести как TEXT.
Это Egal на заметку.
Автор:  sap2me [ Пн, май 14 2018, 02:06 ]
Заголовок сообщения:  Re: Oracle 12c 12.2 -> high cpu usage
SergoB написал(а):
Не одинаковые там планы.

в чем по твоему их принципиальное отличие? может я не заметил чего-то.

Цитата:
" разница может быть только за счет скорости работы дисковой системы" , так Egal говорит, что на этой же системе работало быстро до апгрейда.

в моей фразе которая процитирована речь идет о планах на разных системах. и скорости выполнения на них же.
Автор:  SergoB [ Ср, июн 20 2018, 11:48 ]
Заголовок сообщения:  Re: Oracle 12c 12.2 -> high cpu usage
Egal, что в итоге было? Как пофиксили?

BR, Sergo.
Автор:  Egal [ Ср, июн 20 2018, 13:31 ]
Заголовок сообщения:  Re: Oracle 12c 12.2 -> high cpu usage
SergoB написал(а):
Egal, что в итоге было? Как пофиксили?

BR, Sergo.


Ларчик просто открывался :lol:
До того как был еще апгрейд серверов, никто просто внимания не обратил что с одним из них "что-то пошло не так", только когда пользователей чуть-чуть набежало.
А проблема в том что сервер с какого-то бодуна принудительно делает понижение частоты процессора. Вместо 2400 - 400-500 МГц.
Ни отключение power saving ни какие вообще шаманства в биосе ни к чему не привели. Перевели инстанцию на другой сервер - все нормально стало.
Ждём решение вендора - будем настаивать на замене сервера.
Автор:  SergoB [ Ср, июн 20 2018, 14:54 ]
Заголовок сообщения:  Re: Oracle 12c 12.2 -> high cpu usage
Спасибо за апдейт, каких только странностей не случается :)

BR, Sergo.
Автор:  Egal [ Ср, июн 20 2018, 15:56 ]
Заголовок сообщения:  Re: Oracle 12c 12.2 -> high cpu usage
SergoB написал(а):
Спасибо за апдейт, каких только странностей не случается :)
BR, Sergo.


turbostat в помощь :lol:
Автор:  sap2me [ Чт, июн 21 2018, 02:07 ]
Заголовок сообщения:  Re: Oracle 12c 12.2 -> high cpu usage
Egal написал:
А проблема в том что сервер с какого-то бодуна принудительно делает понижение частоты процессора. Вместо 2400 - 400-500 МГц.
Ни отключение power saving ни какие вообще шаманства в биосе ни к чему не привели. Перевели инстанцию на другой сервер - все нормально стало.

а что за железяка если не секрет?

могу только представить описанное поведение, что втутре все так плохо с охлаждением, что либо частоту понижать, либо проц сгорит. либо брак конечно.
Страница 3 из 3 Часовой пояс: UTC + 3 часа
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/