VS2005/CR - Certificate check, performance problem

Question

Post Author: Lars-Inge
CA Forum: General
Hello,I have a problem with the Crystal Reports (with CR ServicePack 1 installed) that shipps with the Visual Studio 2005 Professional IDE. It looks like the reports are using a certificate check that is out on the internet(?). The synpthoms are extremely bad performance the first time the reports are instantiated. E.g say I have this C# code:            CrystalReport1 rep = new CrystalReport1();The first time this line is called it takes minute(s) (1 minute + 40 sec) before it completes. After it completes the first time, the next calls to this line takes less than nothing (less than 1 sec). I want it to take less than nothing (less than 5-6 sec is OK) the first time aswell.If I disable the certificate check in the registry in Windows, it takes less than 1 second the first time aswell. E.g in "regedit":My ComputerHKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionWinTrustTrusted ProvidersSoftware PublishingChange the "state" from "0x23c00" to "+ "0x23e00" to switch it off.But I cannot do this on a customer computer.Does anyone have any good suggestions, please?Best regards,Lars-Inge

Answer 1

Hi,
both execution plans have very similar cost values (278461 for the bad plan, 270476 for the good plan) and the necessary I/O is also similar. But the bad plan creates an intermediate result of almost 500M rows before the SORT UNIQUE reduces this result to just 505 rows - while the good plan sorts the input data before doing the join and reduces the 627859 rows before doing a second sort operation (HASH UNIQUE). In addition the Nested Loops join to create the result for the inline-view trt_cells in the first plan seems to be more reasonable than the HASH join in the bad plan - but the treatment of ch_cells seems to be the bigger problem.
With the very similar cost value a small change in the arithemtic can result in a changed plan. But both plans do a bad job to determine the size of the resultsets of the hash joins: the bad plan expects to get 2.3M rows (instead of 500M) before the sort takes place and the good plan shows 1900 rows for the join (and gets 627859 rows).
I would try to check why the cardinalities for the join of ACRM_LEAD_TO_CHANNEL_DAILY and UA_CONTACTHISTORY with the join condition (ch.treatmentcode = daily_leads.treatmentcode) are not accurate. Perhaps the columns statistics for the join columns are misleading (number of distinct values, low_value, high_value in user_tab_cols). You could try to use the values in the standard formulas to calculate join selectivity and cardinality (here in a simplified version from Randolf Geist's blog: Oracle related stuff: Table Functions And Join Cardinality Estimates):
Join Selectivity = 1 / greater(num_distinct(t1.c1), num_distinct(t2.c2))
Join Cardinality = Join Selectivity * cardinality t1 * cardinality t2
Perhaps the results will show where the CBO needs a little bit help (or better statistics).
Regards
Martin