It appears to be borked similarly to the way you describe at least as far back as 9.4.1 MR1. (32 bit 9.4.10000.50077).
I started a copy of Planning Sample. On this occasion I took the kamikaze approach of leaving logging turned on on the performance monitor cubes.
Logon time was 17:25. Looking at }StatsByCubeByClient:
17:26: browsed and sliced the view plan_line_item_input from the cube plan_BudgetPlanLineItem. (34 values including consolidations). }StatsByCubeByClient showed no values at this point.
17:27: }StatsByCubeByClient showed 1 View Calc in the Latest and 0M26 elements.
17:30: The values in that cube were increased by 10% via a data spread.
17:31: }StatsByCubeByClient still showed 1 View Calc in the 0M26 element only.
17:32: I went to the log file and backed out the previous spread change.
17:33: }StatsByCubeByClient still showed 1 View Calc in the 0M26 element only.
I then stopped the server and restarted it. The second login was at 17:38. Looking at the other cubes:
, apparently. This correctly recorded activity at 0M38, 0M39 and 0M40. It did not record any subsequent activity even when I pulled the plan_line_item_input view again (which hadn't been opened in this session) at 17:50. At 17:51 it was still showing only the entries for the original 3 minutes, not the ones that I'd performed at 17:50.
, at least as far as I can tell. By 17:54 it had recorded values for each minute interval. The values look legitimate.
. It had registered my browsing of some of the stats cubes at 17:39. However by 17:41 the 0M39 values had disappeared to be replaced by 0M40 values (which were not complete; they didn't reflect all of the cubes that I'd looked at) and by 17:54 all values had vanished from the cube.
, again as far as I can tell. By 17:57 it had registered a value for each minute since the second startup and again, those values seem plausible.
The interesting part about }StatsByCubeByClient comes from looking at the log file. This is a random sample:
Code: Select all
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H17",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H18",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H18",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H19",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H19",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H20",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H20",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H21",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H21",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H22",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H22",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H23",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Update","Elapse Time (ms)","1H23",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","LATEST",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","LATEST",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M00",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M00",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M01",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M01",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M02",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M02",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M03",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M03",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M04",""
"20091003072655","20091003072655",*,"N","1.","0.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M04",""
"20091003072655","20091003072655",*,"N","0.","1.","}StatsByCubeByClient","Admin","plan_BudgetPlan","Cell Retrieval","Count","0M05",""
In other words it seems to be just continually writing 1 and immediately zeroing it out. Obviously the log file is far too large to attach here in full but it appeared to be doing this across all of the metrics in the cube.
I could apply FP1 and check it there as well but if you've already seen it in FP2 I think it's safe to assume that (although the specifics may vary) the performance monitor is broken all the way through the 9.4.1 series of releases.