David, "could not record analysis results" generally means that the analysis job had timed out due to one reason or another and the results for some targets were not recorded into the database. There are two issues in your situation:
1. Why the job times out.
2. Why the analysis results for sucessfull targets are in factor of 100s.
There are many reasons for the job to time out. But here's one reason:
There was an issue ont he target where the scan was taking a very long time to complete (by scan I mean the execution of BLPatchCheck2.exe). This eventually times out causing the chain of events. So the question is why did BLPatchCheck2.exe take a long time to run. This could be a whole issue on its own, but starting 8.0.10 and 8.1.2 we replaced the stPatchAssessment.dll on the target from version 18.104.22.168 to 22.214.171.124 which dramatically improves performance, therefore minimizing the possibility for unusually long times of scanning the system. Here's one article that features this dll, note that this dll fixes many other problems, and the issue in article is not the concern here: https://kb.bmc.com/infocenter/index?page=content&id=KA348230
To find which targets take a long time to scan should be easy... just open your log from the GUI, and browse through "red X" targets, and check the ones that have started the analysis and not completed.
There was a design flaw, where we would wait for the targets to return the analysis results, and then flush those results into the database in the batches of 100, so in some instances, where the job times out, there could have been some targets which completed the analysis and returned the results to the appserver, but the appserver never flushed them to the database, because it was waiting for few more results from other targets to reach the 100. This is why you see the discrepancy that there's only few targets that did not complete the scan, but the results in the job run only give you the round number of successful targets. This was/will be resolved in 8.1.6, 8.2.2, 8.3. But if you resolve the issue 1, technically you do not need to worry about this issue, since you will not hit it.
sorry for length, and I hope this is it.
We are running 8.2, some of the Servers have the 8.1.02.233 agent on them. The same job was run last week in around the same time with no issues. When you click on the task whilst running it, it shows a green tick next to the Servers as if it is successful but when the job finishes it changes this. Also if i click on the results and execute against failed targets it will then work because there are under 2000 Servers. Is there a setting anywhere that limits the results you can pull off?
>>We are running 8.2
Is this 8.2.GA or 8.2 SP2. The design flaw where we flush results in 100s was fixed in 8.2.2 (i.e. SP2)
The servers that fail and never complete the scan per view in job tun log from the GUI, what is the stPatchAssessment.dll version on those servers? If it's not 126.96.36.199, then apply the fix suggested earlier.
>>Is there a setting anywhere that limits the results you can pull off?
No, this will only happen during some time outs, and if the appserver is not at 8.2.2
If nothing here is applicable, then maybe we're dealing with something new, and probably a ticket with dedicated engineer may be better.
Its 8.2 GA and this has never been an issue before. Its not down to a specific Server either, it only seems to be when running against more than 2000+ Servers.
If i run the analysis against 2800 Servers, 2000 will work and 800 won't for this reason "could not record analysis results" If i then run it against the 800 they will then work. I have checked some of the Servers in the 800 and they have the version 188.8.131.52 stPatchAssessment.dll.
perhaps some other bug somewhere if it's the the issue that's resolved in 8.2.2. What happens if you run PAJ against 2001 servers?
I have the similar issue where we ran the analysis againest 2005 server and 43 out them had agent issue thus it scanned for 1962 and succeded for just 1000.
Again we ran the analysis againest 2095 server and this time it succeded for just 2000.
BBSA version 8.2 GA
Doesn't that means it passing analysis result back to DB in a batch of 1000?