Openbravo Issue Tracking System - Openbravo Localizations
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0049691Openbravo LocalizationsLocalization Francepublic2022-06-29 22:502023-03-20 13:34
Reporteregoitz 
Assigned Toegoitz 
PriorityurgentSeveritymajorReproducibilityalways
StatusclosedResolutionduplicate 
PlatformOS5OS Version
Product Version 
Target VersionFixed in Version 
Merge Request Status
Regression date
Regression introduced by commit
Regression level
Support ticket
OBNetwork customerGold
Regression introduced in release
Summary0049691: Some queries are slow, and read lot of information from disk on environment with millioins of transation.
DescriptionThere are some queries related to the french localization and the fiscal certification that are creating high disk usage /contention on environments with million of records.


There quereis are the following and other similar in the other tables tables.



select distinct obcfr_tick0_.Obpos_Applications_ID as col_0_0_ from OBCFR_Ticket obcfr_tick0_ where obcfr_tick0_.AD_Client_ID='??';

Executed by
openbravo=> select distinct obcfr_tick0_.Obpos_Applications_ID as col_0_0_ from OBCFR_Ticket obcfr_tick0_ where obcfr_tick0_.AD_Client_ID='757D621ABD1948F5BCBAD91F19BB70AC';


That is happening even having the following patches applied:
https://gitlab.com/openbravo/ci/modules/org.openbravo.certification.france.dev/-/commit/cc55b8f1f4bb8212985b330518684ba19508f114 [^]



Steps To ReproduceCheck database statistics.

Execute the query on an environmnent with million of records in the table.

Proposed SolutionCould be an option to check the terminals with blockchain initialized ( maybe + last order sync not null) to get the same value?

Additional Information
TagsNOR
Relationships
duplicate of defect 0047331 closed vmromanos Modules Improve performance FrenchFiscalSecurityManager 
related to defect 0049792 closed egoitz Openbravo Localizations Some queries are slow, and read lot of information from disk on environment with millioins of transation. 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2022-06-29 22:50egoitzNew Issue
2022-06-29 22:50egoitzOBNetwork customer => Gold
2022-06-30 09:19psanjuanAssigned To => aferraz
2022-06-30 09:19psanjuanSummarySome queries are slow are read lot of information from disk on environment with millioins of transation. => Some queries are slow, and read lot of information from disk on environment with millioins of transation.
2022-07-12 17:30aferrazAssigned Toaferraz => igor_trebol
2022-07-13 08:53egoitzIssue cloned0049792
2022-07-13 08:53egoitzRelationship addedrelated to 0049792
2022-07-13 09:45rafarodaTag Attached: NOR
2022-07-25 12:41sebastien_lironIssue Monitored: sebastien_liron
2022-07-27 11:05aferrazAssigned Toigor_trebol => egoitz
2022-07-27 11:06aferrazNote Added: 0139637
2022-07-27 11:06aferrazStatusnew => feedback
2022-07-27 16:02sebastien_lironNote Added: 0139651
2023-03-20 13:34aferrazRelationship addedduplicate of 0047331
2023-03-20 13:34aferrazStatusfeedback => closed
2023-03-20 13:34aferrazResolutionopen => duplicate

Notes
(0139637)
aferraz   
2022-07-27 11:06   
We are waiting for a test environment where the problem is reproduced.
It's likely that the problem is fixed by applying 0047331.
(0139651)
sebastien_liron   
2022-07-27 16:02   
as per victor : Please note we haven't transplanted yet to pmods; we will do it in several weeks as part of the preparation for the new certification process (which will take place in one month's time).

It does not seems to me that the MR was done on the standard module