Professional Documents
Culture Documents
CPU Utilization: CPU usage had reached to a maximum of 44.5% and rest of the time the usage looks
normal.
Memory Utilization: Memory usage was normal during stress test, and it never crossed 68% of total
memory.
No of FLEXCUBE Sessions
No of FC
Time Sessions
5:00PM 20
5:15PM 97
5:30PM 249
5:45PM 701
6.00PM 746
6:15PM 682
6:30PM 604
6:45PM 563
7:00PM 501
7:15PM 305
7:30PM 209
No of ACTIVE Sessions
No of
Time ACTIVE Time Node1 Node2
Sessions
5:00PM 13 5:00PM 6 7
5:15PM 26 5:15PM 16 10
5:30PM 38 5:30PM 20 18
5:45PM 129 5:45PM 61 68
6.00PM 97 6.00PM 49 48
6:15PM 89 6:15PM 46 43
6:30PM 102 6:30PM 48 54
6:45PM 94 6:45PM 42 52
7:00PM 96 7:00PM 50 46
7:15PM 92 7:15PM 38 54
7:30PM 100 7:30PM 48 52
MAFACE session count: Sessions are always high on Node 2 for this user.
XAPP session count: XAPP sessions looks normal, and we didn’t see any XAPP sessions with more
count.
Blocking sessions: The below blocking session has been observed during the stress test and it got
released in few seconds.
Load Average on both the nodes: Load average during the stress test for every 15mins interval.
Instance Availability: Both the instances were available during stress test without any issues.
Redo Generation during Stress Test:
Alert log: Alert logs were monitored for both the instances and didn’t see any issues.
FRA USAGE: It is being monitored continuously and it was under threshold values.
Tablespaces Usage: Tablespace usage has been monitored and everything was under threshold
values.
Node 1 - Total cpu count on server is 128. Usage of cpu has maximum gone to 46.5 cpu per second.
Enough cpu is available on server.
Node 2 - Total cpu count on server is 128. Usage of cpu has maximum gone to 56.9 cpu per second.
Enough cpu is available on server.
Network Wait class event - TCP Socket (KGAS) is still being observed in few AWR reports:
Solution - From the database point of view, these waits can safely be ignored; the wait event does
not represent a database issue.
This wait event is significantly improved from last runs.
From an application or network point of view, delays in establishing a network connection may
produce unwanted delays for users. You should make sure that the application makes network calls
efficiently and that the network is working well such that these delays are minimized.
Ges Generic Event wait is observed in all AWR reports and Oracle support has already given patch
for this. This can be ignored and later can be supressed via patch.
No enqueue observed in this stress test. SQL_ID 1yu5ugmpzy019 is resolved and issue is not
appearing now.
UPDATE FCTB_ONLINE_STATS SET MAXRESP = :1 ,MINRESP =:2 ,AVGRESP= :3 ,COUNT =:4 ,
LOGTIME=to_date(:5 ,:"SYS_B_0") WHERE FUNCTIONID = :6 AND ACTION = :7 AND SOURCE = :8
------------------------------------------
Ran tuning advisory for mobapp query and sql profile is available. Bank needs to check this if this
can be accepting as recommended SQL profile.
Please find the below sql_id where it is being observed in most of the AWR reports and tuning
this will help in the performance of the DB.
Bank Team needs to check if 1st sql_id from mobapp can be tuned from the above screen
shot.
6) This query has been running for 40 min and was killed after bank confirmation.
select a.trnx_brn,a.user_ref,a.status,a.fcm_comment,a.fcm_reason_code,a.rej_by_c
orresp,a.is_vip,a.trnx_amount,a.trnx_ccy,a.account,a.acc_name,a.benname,a.benacc
,a.benaddr,a.benbankoption,a.benbankswift,a.benbank1,a.fway,a.purpose,a.details1
,a.details2,a.details3,a.trnx_fee,a.trnx_cable,a.trnx_senderfee,a.ira_acc,a.nost
ro,a.initiated,a.initiator,a.review_doc,a.review_customer,a.preprocessed,a.pre_p
rocessor,a.processed,a.processor,a.error,a.ftid,a.id from VW_OUTWARDS_SCRP_PBL a
where rownum <= 200 and processor='RA.BORIN'
7) Blocking session:
Below blocking session has been observed and it got released after few mins.
Sql_id - 'ajj93bj9wws1s'
UPDATE TEMENOS_OTT_REQUEST_STS A SET A.UDT = SYSDATE, A.CHECK_STATUS = :B6 , A.S
TATUS = CASE WHEN :B6 IN (:B5 , :B4 ) THEN 'OK2' ELSE A.STATUS END, A.FCM_COMMEN
T = NVL(:B3 ,A.FCM_COMMENT), A.FCM_REASON_CODE = NVL(:B2 ,A.FCM_REASON_CODE)
WHE
RE A.ID = :B1 RETURNING A.STATUS INTO :O0
Sql_id - 'a3af41ytu6vhb'
UPDATE OUTWARDS A SET A.STATUS = 'R' WHERE A.ID = :B1
Bank team needs to check this query logic to resolve Enq:TX – row lock contention.
8) LOV Queries:
Below LOV query has been observed and killed as it was taking time. It didn’t appear after
that.
Oracle team will check if history of this query is available in current production and tune it.
Below query has been observed with 3 sessions, these sessions were killed post 30 min after
confirming from bank.
Below query has been observed and these were reported to bank as it was running for more
than 10 min.
Sql_id - 734q4c5vy86k8
select
a.trnx_brn,a.user_ref,a.restrict_status,a.FCM_STATUS,a.FCM_COMMENT,a.FCM_CHK_DT,a.t
rnx_amount,a.trnx_ccy,a.rej_by_corresp,a.is_vip,a.is_waive,a.account,a.acc_name,a.benna
me,a.benacc,a.benaddr,a.benbankoption,a.benbankswift,a.benbank1,a.fway,a.purpose,a.de
tails1,a.details2,a.details3,a.trnx_fee,a.trnx_cable,a.trnx_senderfee,a.interswift,a.inter1,a.ira
_acc,a.nostro,a.initiated,a.initiator,a.review_doc,a.review_customer,a.preprocessed,a.pre_p
rocessor,a.processed,a.processor,a.error,a.ftid,a.id from VW_OUTWARDS_HSWIFT_PBL a
where rownum <= 2000
Below query has been observed and it was reported to bank as it was executing for more
than time.
Sql_id – 85w4u860mhb16
select
a.trnx_brn,a.user_ref,a.status,a.fcm_comment,a.fcm_reason_code,a.rej_by_corresp,a.is_vip
,a.trnx_amount,a.trnx_ccy,a.account,a.acc_name,a.benname,a.benacc,a.benaddr,a.benbank
option,a.benbankswift,a.benbank1,a.fway,a.purpose,a.details1,a.details2,a.details3,a.trnx_f
ee,a.trnx_cable,a.trnx_senderfee,a.ira_acc,a.nostro,a.initiated,a.initiator,a.review_doc,a.revi
ew_customer,a.preprocessed,a.pre_processor,a.processed,a.processor,a.error,a.ftid,a.id
from VW_OUTWARDS_SCRP_PBL a where rownum <= 20
0 and processor='RA.BORIN'
This query came from XAPP owner and package body - CVREQ$ACTION_STATIC_V2
EOD Details:
Posting 15 M entries took 25mins with 100 sessions on both the nodes.
EODM sql text has been changed so the sql_id got changed and ran with a different plan. We
will check the best available plan and baseline the plan.