We have a cluster set up at my office ( Active/Active ) that has been
pitched as some prime real-estate, apparently, as the best place in the
office for a database. Now it looks like one of my nodes is overrun with
databases! I'd like to set up some traces in profiler or performance
monitor to gather some stats in case we start to experience some degredation
in performance. I want to be able to point to some numbers to explain to my
boss why we shouldn't put so many databases on one node. Any suggestions
on what are some good counters to turn on? I'm thinking I should monitor
I/O wait and paging at the very least. I've also heard someone mention to
monitor page life expectancy, but I don't know much about this one.

TW

"Tech Witch" <tech.witch@gmail.NOSPAM.com> wrote in message
news:%xTEd.833$2e7.668@newssvr12.news.prodigy.com. ..
> We have a cluster set up at my office ( Active/Active ) that has been
> pitched as some prime real-estate, apparently, as the best place in the
> office for a database. Now it looks like one of my nodes is overrun with
> databases! I'd like to set up some traces in profiler or performance
> monitor to gather some stats in case we start to experience some
> degredation
> in performance. I want to be able to point to some numbers to explain to
> my
> boss why we shouldn't put so many databases on one node. Any suggestions
> on what are some good counters to turn on? I'm thinking I should monitor
> I/O wait and paging at the very least. I've also heard someone mention to
> monitor page life expectancy, but I don't know much about this one.
>
> TW
>
>

The MS Ops guide has some specific recommendations on which counters to
monitor:

http://www.microsoft.com/technet/pro...n/sqlops5.mspx

But it's a big topic, so if you're concerned about performance, it might be
worth getting hold of a reference book - this MS one is pretty
comprehensive:

http://www.microsoft.com/mspress/books/4944.asp
http://vyaskn.tripod.com/sql_server_...nce_tuning.htm

Simon

"Simon Hayes" <sql@hayes.ch> wrote in message
news:41e541f0$1_2@news.bluewin.ch...
>
> The MS Ops guide has some specific recommendations on which counters to
> monitor:
>
>
http://www.microsoft.com/technet/pro...n/sqlops5.mspx
>
> But it's a big topic, so if you're concerned about performance, it might
be
> worth getting hold of a reference book - this MS one is pretty
> comprehensive:
>
> http://www.microsoft.com/mspress/books/4944.asp
> http://vyaskn.tripod.com/sql_server_...nce_tuning.htm

Thanks for the link. There is a lot more to learn about monitoring for SQL
than I thought. Guess I better get started learning if I'm going to pass my
MCDBA soon.

TW

"Tech Witch" <tech.witch@gmail.NOSPAM.com> wrote in message
news:%xTEd.833$2e7.668@newssvr12.news.prodigy.com. ..
> We have a cluster set up at my office ( Active/Active ) that has been
> pitched as some prime real-estate, apparently, as the best place in the
> office for a database. Now it looks like one of my nodes is overrun with
> databases! I'd like to set up some traces in profiler or performance
> monitor to gather some stats in case we start to experience some
degredation
> in performance. I want to be able to point to some numbers to explain to
my
> boss why we shouldn't put so many databases on one node. Any suggestions
> on what are some good counters to turn on? I'm thinking I should monitor
> I/O wait and paging at the very least. I've also heard someone mention to
> monitor page life expectancy, but I don't know much about this one.

You want a technical answer to what may be a political problem.

If it's your nodes, why are others installing stuff?


>
> TW
>
>

"Greg D. Moore (Strider)" <mooregr_deleteth1s@greenms.com> wrote in message
news:VfjFd.134939$Uf.128303@twister.nyroc.rr.com.. .
> You want a technical answer to what may be a political problem.
>
> If it's your nodes, why are others installing stuff?

I don't know if my techincal data will be the answer to this (yes,
political) problem. I intend to keep statistics on my node as a good
production dba should to help prevent problems in the future.

I'm merely the production DBA assigned to manage the node. My manager
approved database creation requests. My hope is that I can provide him with
enough information to prevent any future problems. In my experience,
techincal data works a lot better as supporting information for decision
making than whining.

TW