Disk Avg.read time statistics not collected for a drive

kannappaganeshkannappaganesh Posts: 3
edited July 12, 2014 12:22PM in SQL Monitor Previous Versions
SQL monitor not collecting disk avg.read time and avg.disk queue length statistics for one drive (F: ) in a monitored server. Other logical disk counters are collected for the drive. For other drives in the machine, all statistics are collected.
Any idea what is causing this and suggestions for fix.
· Share on Twitter

Comments

  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    Are you monitoring a cluster where f: is a shared resource and you are not looking at the currently active node?
    · Share on Twitter
  • kannappaganeshkannappaganesh Posts: 3
    Brian,
    Yes, we are monitoring a cluster with F: shared, but looking at the currently active node. The statistics for other counters like disk avg.write time etc.. are collected by SQL Monitor for F: drive. So, the drive is accessible.. Only the two avg read time and disk queue length are not collected.
    · Share on Twitter
  • avibooksavibooks Posts: 15
    Has there been any resolution for this issue? I am experiencing a similar issue on our SQL cluster
    · Share on Twitter
  • avibooksavibooks Posts: 15
    I am able to get the performance counters for Disk avg. read/write time using Performance monitor on the server where the base monitor is located, but SQL Monitor is not displaying the disk counters.
    · Share on Twitter
  • thefragilethefragile Posts: 4
    Anyone ever figure this out? Having the same issue. Data is getting collected for a clustered drive for everything except Read Time. Seems to be looking at the passive node and causing access denied errors there. How can I tell SQLMonitor the drive is currently on the other node for that sensor?
    · Share on Twitter
  • avibooksavibooks Posts: 15
    Apparently this is a known bug (SRP-9314) in SQL Monitor. The response I got from Red Gate in ticket "Unable to get Disk avg. read/write time for certain drives" was that they are aware of the bug but cannot say when it will be looked at.
    · Share on Twitter
  • thefragilethefragile Posts: 4
    Thank you for that information Avibooks.

    That is most unfortunate as it's happening on a crucial drive.

    Did you attempt to remove and re-add the cluster to SQLMonitor? I haven't tried that yet, but thought it might be worth a shot...
    · Share on Twitter
  • avibooksavibooks Posts: 15
    No, I have not tried that yet. Could you let me know if that works out for you. Thanks.
    · Share on Twitter
  • thefragilethefragile Posts: 4
    Removing the server, letting the data purge, and then re-adding the cluster did not work for me. This is frustrating. I'm going to open a ticket with Redgate with this issue (so they have another instance to add to their issue tracking), and then consider starting from scratch..
    · Share on Twitter
  • avibooksavibooks Posts: 15
    Funnily enough the disk read/write time stats on the drives in my cluster started getting populated again. Not all at once though. They came trickling in; one day the Disk Avg. Read time for one drive started getting populated, few days later the Disk Avg. Write time for another drive and so on so forth until all drive statistics were back.

    No guarantee it's going to stay the same the next time we perform a cluster failover though!
    · Share on Twitter
  • thefragilethefragile Posts: 4
    Interesting! We're going to start fresh sadly, sometime very soon.

    One thing I noted when removing the cluster and re-adding it was that before, it had cluster name, then under that, the nodes listed separately. And we could click node1, see stats, then node2, different stats for CPU, memory, etc, and so on with all nodes. After re-adding it, it was simply the cluster name with no nodes listed under it. So it appears they changed the way it handles clusters in some version or another. And my guess would be that the issue we're running in to is tied to that change somehow. Only a guess of course :)

    Glad to hear yours is sorting itself out without having to lose any other data! :) I'll post back again to confirm that starting fresh 'fixes' it for us. How could it not though? New instance, new DB... if it doesn't, I'll really start getting concerned...
    · Share on Twitter
Sign In or Register to comment.