Skip to main content

This might be a continuation of the following community post or a reference to it if needed.

 

https://community.ifs.com/framework-and-experience-101/how-can-i-resolve-performance-issues-when-updating-vouchers-to-general-ledger-12780?postid=47153#post47153

 

We are seeing a lot of WARNING: too many parse errors in the oracle alert logs when our customer’s database gets into a complete slowdown mode and needing a forced reboot. It happens almost every Tuesday.

What is the reason for the errors? What can be done to eliminate or mitigate such errors? Do we need an ORACLE patch or change in parameter settings? Is solution id 247656 (and/or others) the answer to this? Our customer is hosted on ITAR cloud.

During this slowdown the GL Update suffers greatly and does not finish. And when the customer reboots, the GL update finishes within a reasonable amount of time. Rebooting the system frequently is not an acceptable solution for the customer since it is affecting their business.

 

 

2023-01-31T11:06:02.663212-06:00

WARNING: too many parse errors, count=9700 SQL hash=0xc76abb8a

PARSE ERROR: ospid=1236, error=12850 for statement:

2023-01-31T11:06:02.663212-06:00

INSERT INTO BU_ACCESS_VALID_TAB (RELATION_ID, ORG_BU_ID, PERSON_ID, COMPANY_ID, EMP_NO, ACCESS_ROLE_ID, POS_CODE, SUBORDINATE, VALID_FROM, VALID_TO, TRANS_FROM, TRANS_TO, RELATION_TYPE, SUBSTITUTE_ENTRY, SUBSTITUTE_SEQ_ID, ACCESS_AREA, ROWVERSION) SELECT RELATION_ID, ORG_BU_ID, PERSON_ID, COMPANY_ID, EMP_NO, ACCESS_ROLE_ID, POS_CODE, SUBORDINATE, VALID_FROM, VALID_TO, TRANS_FROM, TRANS_TO, RELATION_TYPE, SUBSTITUTE_ENTRY, SUBSTITUTE_SEQ_ID, ACCESS_AREA, ROWVERSION FROM BU_ACCESS_TEMP_TAB T WHERE T.POS_CODE IS NOT NULL AND NVL(:B1 , T.POS_CODE) = T.POS_CODE AND TRUNC(SYSDATE) <= T.VALID_TO AND EXISTS (SELECT 1 FROM POSITION_ACCESS_VALID_TAB CA, BUSINESS_UNIT_TAB BU WHERE BU.BUSINESS_UNIT_ID = T.ORG_BU_ID AND CA.STRUCT_BU_ID = DECODE(BU.BUSINESS_UNIT_TYPE, 'COMPANY', BU.BUSINESS_UNIT_ID, BU.STRUCT_BU_ID) AND CA.POS_CODE = T.POS_CODE AND CA.STRUCT_BU_ID = NVL(:B2 , CA.STRUCT_BU_ID) AND CA.VALID_FROM <= T.VALID_TO AND CA.VALID_TO >= T.VALID_FROM) AND (SUBORDINATE <> 'TRUE' OR RELATION_ID NOT IN (SELECT RELATION_ID FROM BU_ACCESS_TEMP_TAB V, BUSINESS_UNIT_TAB B WHERE V.ORG_BU_ID = B.BUSINESS_UNIT_ID AND V.SUBORDINATE = 'TRUE' AND (B.BUSINESS_UNIT_TYPE = 'COMPANY' OR (B.BUSINESS_UNIT_TYPE = 'CUSTOM' AND B.IS_ROOT = 'TRUE'))))

Additional information: hd=000001EF10FF6F90 phd=000001EF82715950 flg=0x110676 cisid=93 sid=93 ciuid=93 uid=93

 

2023-01-31T15:30:57.871671-06:00

WARNING: too many parse errors, count=302 SQL hash=0xd88be228

PARSE ERROR: ospid=3904, error=12872 for statement:

2023-01-31T15:30:57.871671-06:00

select PART_NO,DESCRIPTION,DIM_QUALITY,SUPPLY_CODE from IFSAPP.INVENTORY_PART_LOV_MRP where  ( CONTRACT = :1        )

Additional information: hd=000001ED9B3331F8 phd=000001EE1FF3A000 flg=0x110676 cisid=1409 sid=1409 ciuid=1409 uid=1409

2023-01-31T15:32:18.373817-06:00

 

2023-01-24T11:05:07.905427-06:00

WARNING: too many parse errors, count=100 SQL hash=0x2b3ebcd7

PARSE ERROR: ospid=3228, error=12872 for statement:

2023-01-24T11:05:07.905427-06:00

select OBJID, OBJVERSION, IFSAPP.ACTIVITY_API.Get_Total_Key_Path(ACTIVITY_SEQ), IFSAPP.Project_Api.Get_Company(PROJECT_ID), IFSAPP.Project_API.Get_Program_Id(PROJECT_ID), IFSAPP.ACTIVITY_API.Get_Program_Description(ACTIVITY_SEQ), PROJECT_ID, IFSAPP.PROJECT_API.Get_Name(PROJECT_ID), SUB_PROJECT_ID, IFSAPP.SUB_PROJECT_API.Get_Description(PROJECT_ID,SUB_PROJECT_ID), ACTIVITY_NO, IFSAPP.ACTIVITY_API.Get_Description(ACTIVITY_SEQ), ACTIVITY_SEQ, IFSAPP.Proj_Lu_Name_API.Decode(proj_lu_name), PROJ_LU_NAME, KEYREF1, KEYREF

Additional information: hd=0000018019B75C48 phd=0000018246D570C8 flg=0x110676 cisid=1286 sid=1286 ciuid=1286 uid=1286

2023-01-24T11:06:39.688752-06:00

 

When I ran a Google search on the ORACLE errors, it reported the following.

What needs to be done to the database to prevent such errors?

 

 

ORA-12850: Could not allocate slaves on all specified instances: 2 needed, 0 allocated

Error code: ORA-12872
Description: First slave parse gave different plan
Cause: First hard parse on slave given QC-supplied environment and parameters gave different plan from QC. Try again with outline.
Action: No external action. Internally used for outline-based reparse.


Hi @Roy Almeida ,

Parse errors such as this doesn’t always mean that they are the cause of the performance issue. You can potentially see such errors even if you have some sort of the syntax error in an SQL or is a object used in the query is invalid. 

i would probably looks at what is causing the database to become slow on a very specific day of the week. If you know when the slow down starts become visible on Tuesday, i suggest capturing few AWR reports starting couple of hours before the slow down and well in to the peak of the slow down to see if you can see a significant deviation from the usual. Once you find the top impact SQL’s and processes you might be able to see what sort of activity is having the biggest impact. 

Cheers 


Hi Sajith

 

Thanks for your response. We have requested the AWR reports and will review them when they become available. 

 

Also if you looked closely at the above errors, they point to ORA-12850 and ORA-12872 which I googled as follows.

I dont know if these errors happen every day or sometimes and these are seen in the alert logs.

Does it mean that something needs to be tweaked or tuned in the ORACLE database parameter settings? (or even JDBC)?

 

ORA-12850: Could not allocate slaves on all specified instances: 2 needed, 0 allocated

Error code: ORA-12872
Description: First slave parse gave different plan
Cause: First hard parse on slave given QC-supplied environment and parameters gave different plan from QC. Try again with outline.
Action: No external action. Internally used for outline-based reparse.


Also, the database slowdowns could be happening due to the following errors extracted from the ORACLE alert log:

(and this happened on Tuesday)

 

2023-01-31T17:11:12.229145-06:00

WARNING: pga_aggregate_limit value is too high for the

amount of physical memory on the system

  PGA_AGGREGATE_LIMIT is 192512 MB

  PGA_AGGREGATE_TARGET is 16384 MB.

  physical memory size is 131071 MB

  limit based on physical memory and SGA usage is 31948 MB

  SGA_MAX_SIZE is 86016 MB


It cloud be due to the Oracle Bug 34775863 (Patch 34775863 ).
 

Solution is any of the following (from Oracle):

    1. Upgrade to a database version where this fix is included, note this will be included in 19.19.0.0.230418DBRU which will release April 2023.
    
    2. Apply Patch 34775863 if available for your platform and database version, if a patch is not available please create an SR with support to request one.
    
    3. Use the following workaround:

alter system set "_nlj_batching_enabled"=0;


It cloud be due to the Oracle Bug 34775863 (Patch 34775863 ).
 

Solution is any of the following (from Oracle):

    1. Upgrade to a database version where this fix is included, note this will be included in 19.19.0.0.230418DBRU which will release April 2023.
    
    2. Apply Patch 34775863 if available for your platform and database version, if a patch is not available please create an SR with support to request one.
    
    3. Use the following workaround:

alter system set "_nlj_batching_enabled"=0;

Thanks for this information….


Hi @Roy Almeida 

Did you find any solution to this?

 

Regards,

Sayeed


Hi 

It’s been more than 1 year since I logged this. Have not heard any more complaints from the customer regarding this matter. Some database changes were done by the ITAR cloud team which probably alleviated performance issues.

 

The customer has also signed up for UPD22 at this time and patches 157677;163572 will be part of the solution which might help. In addition, going from UPD8 to UPD22 could also mean ORACLE updates/upgrade.

If I hear anything more on this matter, I shall revisit this post. Thanks for your help and advice.

 

Roy


Reply