This page will help you to troubleshoot the performance problems you may face at the "Compute Dependency Dataset" step.
This is generally due to a big amount of objects involved in the computation of dependency dataset for external links.
|Microsoft SQL Server|
To troubleshoot this issue, you need the following Relevant input
Perform the below actions:
- Clean up table WORK_SELECTION If this does not solve the issue, you may proceed to step 2
- Check the object types in table WORK_SELECTION. If the most numerous objects are CAST_COBOL_GenericData, then you might consider proceeding to step 3 Else proceed directly to step 4
- Set the option "Data Structures" to "Don't save data"
- Use a Refined Target to restrict the Dependency Dataset
- CAST Support Tool (CST) - alias Sherlock with backup of the Knowledge Base and Management Base at least, OR access to the customer server
- Source code OR access to the customer server
Step 1: Clean up table WORK_SELECTION
This table is a working table. It should always be empty between two analysis. There may be remaining objects in the table, due to an analysis crash or abnormal termination.
The consequence can be a burst of the number of objects in the Dependency Dataset, leading to a performance issue.
To clean up the table, run the following query on your Knowledge Base :
set search_path=<YOUR_KB>; truncate table WORK_SELECTION;
Then relaunch analysis. If the performance issue is not solved, you may proceed to Step 2 -Check the object types in table WORK_SELECTION
Step 2: Check the object types in table WORK_SELECTION
Wait for the analysis to get stuck at step "Compute Dependency Dataset", then run the following query on your Knowledge Base :
set search_path=<YOUR_KB>; select count(k.idkey) as count, t.* from keys k join work_selection wk on k.idkey=wk.key_id join typ t on t.idtyp=k.objtyp group by k.objtyp, t.typnam, t.typdsc, t.status order by count desc;
The results should show you a list of object types with the corresponding number of objects in table WORK_SELECTION.
6122343;831;"CAST_COBOL_GenericData";"Cobol Data";"ACTIVE " 599209;890;"CAST_COBOL_SavedConditionalTest";"Cobol Conditional Test";"ACTIVE " 279567;114021;"CAST_COBOL_Literal";"Cobol Literal";"ACTIVE " 61854;809;"CAST_IMS_DatabaseProgramControlBlock";"IMS DB PCB";"ACTIVE " 54952;151005004;"IMSDCProgram";"IMS Program";"ACTIVE " 23684;151005005;"IMSDCTransaction";"IMS Transaction";"ACTIVE " 22888;138832;"CAST_Oracle_TableColumn";"Oracle table column";"ACTIVE " 18204;138315;"CAST_Oracle_CheckConstraint";"Oracle check table constraint";"ACTIVE " 15480;102;"JV_METHOD";"Java Method";"ACTIVE " 10760;103;"JV_FIELD";"Java Field";"ACTIVE " ...
If the most numerous objects are CAST_COBOL_GenericData, you might consider proceeding to step 3- Set the option "Data Structure" to "Don't save data".
Otherwise, proceed directly to step 4 - Use a Refined Target to restrict the Dependency Dataset
Step 3: Consider setting the option "Data Structure" to "Don't save data"
If your application contains Mainframe technology, this option can be found at Production tab, Mainframe tab.
By default, it is already set to "Don't save data". Data should be shaved because it leads to a huge volume of objects being created, and significantly increases the duration of the mainframe analyses.
These objects are Cobol internal objects and cannot be the target of external links, so they are useless for the computation of external links.
Once you have set it to "Don't save data", then relaunch analysis (the first re-analysis may be long because the former objects will have to be cleaned up from the Knowledge Base).
If for some reason you do not want to configure this option as indicated, then please proceed to step 4 - Use a Refined Target to restrict the Dependency Dataset
Step 4: Use a Refined Target to restrict the Dependency Dataset
- If during step 2, you found that the most numerous objects are CAST_COBOL_GenericData, but for some reason you want to keep these objects saved into database, then you have to exclude them from the Computency Dataset through a Refined Target.
Create a Refined Target for Mainframe Technology as shown below, by checking "Filter by object type" and then selecting every type of object but "Cobol Data", "Cobol Conditional Test" and "Cobol Literal".
Then apply your Refined Target to all the Dependencies whose target is Mainframe Technology.
If during step 2, you found that the most numerous objects where not CAST_COBOL_GenericData, then you must first identify which technology the object type belongs to.
To identify the technology, run the following query on your local base, where <OBJECT TYPE ID> is the first column of the first row in the results of Step 2Identify the technology
set search_path=<YOUR_KB>; select c.idcat as "Technology ID" , c.catnam as "Technology Name" , c.catdsc as "Technology Description"from cat c join typcat tc on c.idcat=tc.idcatparent join catcat cc on cc.idcat=c.idcat where tc.idtyp=<OBJECT_TYPE_ID> and cc.idcatparent=6000;
Knowing the technology and the object type of the most numerous objects in the Dependency Dataset, you may decide to exclude this object type, depending whether it can be the target of an external link or not.
For this, use a Refined Target for the technology and exclude the object type by proceeding as explained in the example for Mainframe technology and CAST_COBOL_GenericData example.
In order to overcome the performance issue in this step:
Go to dependencies tab and click "Reset" : you will then have only discovered dependencies
Go to Refined Target tab and define a Refined Target which will restrict the target object
Ticket # 6844