
Hello Sumit,
Instead of measuring the timing, can't we run before every analysis?
While running Snapshot if you observe the Generate module step is taking longer than usual, then to increase the performance we can perform Optimization on the Cast Server Storage on the schemas created for this application.
You can perform optimization of schemas by running CSSOptimize.exe using below documentation.
https://doc.castsoftware.com/display/DOCCOM/CAST+Storage+Service+-+maintenance+activities
Post that remove the locks of the local base from server manager.
Then open Cast ms and run the Snapshot again.
Please sign in to leave a comment.
Hello Sumit,
Instead of measuring the timing, can't we run before every analysis?
for "Generate Module step", If I run optimization only on the central schema, will it be enough?
Hi Durgesh,
For Question"Instead of measuring the timing, can't we run before every analysis?"
It happens rarely Over time of continued use, the efficiency of your CAST Storage Service schemas may well start to degrade as is the case for any RDBMS ("gaps" in table data, inefficient indexes etc.). To counter this, CAST provides a tool that can be run to optimize the schemas stored in your CAST Storage Service - i.e. to clean up defects that have appeared over time.
So we are not sure when we can observe this behaviour.
Thanks
Hi Durgesh,
For question"for "Generate Module step", If I run optimization only on the central schema, will it be enough?:
No, generate module runs on both KB and Central, so it is required to run it on both the schemas.
We also recommend to run optimization on entire schema triplet, to have a better performance.
Thanks
Beware while removing the lock from base, if you are using CAST AIP 8.3.6 or 8.3.7 then the locks would not be removed as there was a bug see below page:
https://doc.castsoftware.com/display/TG/Server+Manager+-+Remove+Locks
Hello Sumit,
is there any specific time we can consider as treshold to apply this fix or will it depend on the application size?
Hi Deepak,
To comment on the performance of the job, we need to compare at least two Snapshot runs.
The issue occurred here because of the performance of database which goes down overtime, hence in this context we have already run multiple snapshot runs to say what is expected time of the job completion in general referring the timestamp in logs.
Thanks