| Table of Contents | ||||
|---|---|---|---|---|
|
...
- Using Transformations in Matching Rules
Avoid functions transforming data (SOUNDEX, UPPER, etc. included) in match/binning rules.- Reasons:
- May cause an issue on the Indexes. These functions is performed for every time the record is compared.
- Solution
- Materialize these values into attributes via enrichers
- Reasons:
- Use Fuzzy Matching Functions with Care
- Distance and Distance Similarity functions are the most costly functions.
Sometimes, materializing a phonetized value with enricher then comparing with equality gives functionally equivalent results.
- Distance and Distance Similarity functions are the most costly functions.
- Very Large Complex Rules
- Avoid one big matching rule.
- Each rule should address a functionnally consistent set of attribute data.
- Consider Indexing
- For very large volumes, adding an index on the significative columns involved in the binning, then one index for the columns matching rule.
e.g.:create index S_<indexName> on MI_<entity> (B_BATCHID,B_BRANCHID,B_CLASSNAME, B_PUBID, B_SOURCEID, <columns involved matching, with those having more distinct values first>);-- Remove BranchID for v4.0 and above
- For very large volumes, adding an index on the significative columns involved in the binning, then one index for the columns matching rule.
Issues in Other Certification Phases
...
- Symptom: "ORA-01467: Sort Key too long" issue
- Solution:
alter session set "_windowfunc_optimization_settings" = 128;in session initializing for the connection pool in the datasource configuration.
- Solution:
...
Applications reflect sizing issues that may exist in the application server or database tiers. Make sure to review the Server Configuration and Sizing section before proceeding.
Collections
Slow Collections
...
Collections slow to display may have many causes, inluding:
- Filtering & Sorting
- Design-time or user-defined filters and sort operations tax the database.
- For large datasets, consider disabling user filtering and Sorting if not strictly necessary. When filtering/search, make sure to enable search methods functionally useful and reasonable for the performances (e.g: Full text on an entity with a lot of columns is not a good idea).
- Number of different entities involved to compose the collection (looking up data through the references)
- Number of computed columns
- Using PL/SQL or Using SemQL
Optimize SemQL or PL/SQL code.
- Using PL/SQL or Using SemQL
Business Views
...
- Looking up for values in other entities through the references means as many database joins when accessing the data.
- Computed columns
- These columns typically use PL/SQL (PL/pgSQL) or SemQL code to compute their values.
- Make sure to optimize the expressions and code. For example, avoid retrieving data using cursors instead a set-based approach.
Business Views
Business Views or forms slow to display may have many causes, including:
- Slow Embedded Collections (see previous paragraph)
- To many Embedded Collections Too many embedded collections in the form : when a view is displayed, each embedded collection generate a SQL call to the database. So try to move not necessary Moving embedded collections in tabsto secondary tabs as transitions should be considered then.
Custom Search
Filter data by using a custom Search can be costly in many cases :
- Using FDN_ columns instead of FID_ columns in the SemQL condition
- Using function transforming data (SOUNDEX, UPPER, etc. included) may cause an issue on the Indexes
- To complex SemQL condition with .