Good day.
We updated WinCC OA from 3.14 version to 3.15 and oracle schema from 8.15 version to 8.20. After which, we found performance problem of writing data into database and increasing the count of RDB buffer data files.
We executed tracing of RDB oracle sessions and found this:
Execution time of one merge statement elapsed about 3 seconds. The reason for slow execution is unindexed condition TO_CHAR(h.ts,'…') = TO_CHAR(s.partner, '…').
On our test lab the problem reproduce after increasing count of rows in ALERTHISTORY_######## table more than 6 millions rows.
For restore the process of writing data into database, we changed the condition after which whole RDB buffer data files was written into database.
We hope that ETM will accept this issue for detailed analysis.
Data write performance problem on RDB schema 8.20
Search
Data write performance problem on RDB schema 8.20
Last edited by sanikval on Mon Feb 10, 2020 11:24 am, edited 1 time in total.
Re: Data write performance problem on RDB schema 8.20
For a detailed analysis of this issue please get in contact with our WinCC OA Consulting team.
Doing Oracle analysis via the WinCC OA Portal is not the best approach.
Best Regards
Leopold Knipp
Senior Support Specialist
Doing Oracle analysis via the WinCC OA Portal is not the best approach.
Best Regards
Leopold Knipp
Senior Support Specialist
-
- Posts: 6
- Joined: Tue Jul 12, 2016 4:08 pm
Re: Data write performance problem on RDB schema 8.20
We have already analyzed:
Decision:
- in 3.14, the function UpdateAlertPartner used the index for h.ts
- in 3.15, the function UpdateAlertPartner not used the index h.ts because you are converting h. ts to TO_CHAR.
Decision:
- create index TO_CHAR(h.ts, ''YYYY.MM.DD HH24:MI:SS.FF3'') on ALERTHISTORY_000000123
- optimize the query
Re: Data write performance problem on RDB schema 8.20
If you want to have detailed information for your questions please get in contact with the WinCC OA consulting team.
Maybe you can get rid of the problem by switching the alert tables in RDB to create a new "alert history table".
Best Regards
Leopold Knipp
Senior Support Specialist
Maybe you can get rid of the problem by switching the alert tables in RDB to create a new "alert history table".
Best Regards
Leopold Knipp
Senior Support Specialist