Monitor SharePoint Database Performance

http://technet.microsoft.com/en-us/library/cc298801.aspx

SQL Server counters to monitor

Monitor the following SQL Server counters to ensure the health of your servers:

• General statistics   This object provides counters to monitor general server-wide activity, such as the number of current connections and the number of users connecting and disconnecting per second from computers running an instance of SQL Server. Consider monitoring the following counter:
  • User connections   This counter shows the amount of user connections on your computer running SQL Server. If you see this number rise by 500 percent from your baseline, you may see a performance reduction.
• Databases   This object provides counters to monitor bulk copy operations, backup and restore throughput, and transaction log activities. Monitor transactions and the transaction log to determine how much user activity is occurring in the database and how full the transaction log is becoming. The amount of user activity can determine the performance of the database and affect log size, locking, and replication. Monitoring low-level log activity to gauge user activity and resource usage can help you to identify performance bottlenecks. Consider monitoring the following counter:
  • Transactions/sec   This counter shows the amount of transactions on a given database or on the entire server per second. This number is more for your baseline and to help you troubleshoot issues.
• Locks   This object provides information about SQL Server locks on individual resource types. Consider monitoring the following counters:
  • Average Wait Time (ms)   This counter shows the average amount of wait time for each lock request that resulted in a wait.
  • Lock Wait Time (ms)   This counter shows the wait time for locks in the last second.
  • Lock waits/sec   This counter shows the number of locks per second that could not be satisfied immediately and had to wait for resources.
  • Number of deadlocks/sec   This counter shows the number of deadlocks on the computer running SQL Server per second. This should not rise above 0.
• Latches   This object provides counters to monitor internal SQL Server resource locks called latches. Monitoring the latches to determine user activity and resource usage can help you to identify performance bottlenecks. Consider monitoring the following counters:
  • Average Latch Wait Time (ms)   This counter shows the average latch wait time for latch requests that had to wait.
  • Latch Waits/sec   This counter shows the number of latch requests that could not be granted immediately.
• SQL Statistics   This object provides counters to monitor compilation and the type of requests sent to an instance of SQL Server. Monitoring the number of query compilations and recompilations and the number of batches received by an instance of SQL Server gives you an indication of how quickly SQL Server is processing user queries and how effectively the query optimizer is processing the queries. Consider monitoring the following counters:
  • SQL Compilations/sec   This counter indicates the number of times the compile code path is entered per second.
  • SQL Re-Compilations/sec   This counter indicates the number statement recompiles per second.
• Buffer Manager   This object provides counters to monitor how SQL Server uses memory to store data pages, internal data structures, and the procedure cache, as well as counters to monitor the physical I/O as SQL Server reads and writes database pages. Consider monitoring the following counter:
  • Buffer Cache Hit Ratio
  • This counter shows the percentage of pages that were found in the buffer cache without having to read from disk. The ratio is the total number of cache hits divided by the total number of cache lookups over the last few thousand page accesses. Because reading from the cache is much less expensive than reading from disk, you want this ratio to be high. Generally, you can increase the buffer cache hit ratio by increasing the amount of memory available to SQL Server.
• Plan Cache   This object provides counters to monitor how SQL Server uses memory to store objects such as stored procedures, ad hoc and prepared Transact-SQL statements, and triggers. Consider monitoring the following counter:
  • Cache Hit Ratio
  • This counter indicates the ratio between cache hits and lookups for plans.

Physical server counters to monitor

Monitor the following counters to ensure the health of your computers running SQL Server:

• Processor: % Processor Time: _Total   This counter shows the percentage of time that the processor is executing application or operating system processes other than Idle. On the computer that is running SQL Server, this counter should be kept between 50 percent and 75 percent. In case of constant overloading, investigate whether there is abnormal process activity or if the server needs additional CPUs.
• System: Processor Queue Length   This counter shows the number of threads in the processor queue. Monitor this counter to ensure that it remains less than two times the number of core CPUs.
• Memory: Available Mbytes   This counter shows the amount of physical memory, in megabytes, available to processes running on the computer. Monitor this counter to ensure that you maintain a level of at least 20 percent of the total available physical RAM.
• Memory: Pages/sec   This counter shows the rate at which pages are read from or written to disk to resolve hard page faults. Monitor this counter to ensure that it remains under 100.

For more information and memory troubleshooting methods, see SQL Server 2005 Monitoring Memory Usage (http://go.microsoft.com/fwlink/p/?LinkID=105585).

Disk counters to monitor

Monitor the following counters to ensure the health of disks. Note that the following values represent values measured over time — not values that occur during a sudden spike and not values that are based on a single measurement.

• Physical Disk: % Disk Time: DataDrive   This counter shows the percentage of elapsed time that the selected disk drive is busy servicing read or write requests–it is a general indicator of how busy the disk is. If thePhysicalDisk: % Disk Time counter is high (more than 90 percent), check the PhysicalDisk: Current Disk Queue Length counter to see how many system requests are waiting for disk access. The number of waiting I/O requests should be sustained at no more than 1.5 to 2 times the number of spindles that make up the physical disk.
• Logical Disk: Disk Transfers/sec   This counter shows the rate at which read and write operations are performed on the disk. Use this counter to monitor growth trends and forecast appropriately.
• Logical Disk: Disk Read Bytes/sec and Logical Disk: Disk Write Bytes/sec   These counters show the rate at which bytes are transferred from the disk during read or write operations.
• Logical Disk: Avg. Disk Bytes/Read   This counter shows the average number of bytes transferred from the disk during read operations. This value can reflect disk latency — larger read operations can result in slightly increased latency.
• Logical Disk: Avg. Disk Bytes/Write   This counter shows the average number of bytes transferred to the disk during write operations. This value can reflect disk latency — larger write operations can result in slightly increased latency.
• Logical Disk: Current Disk Queue Length   This counter shows the number of requests outstanding on the disk at the time that the performance data is collected. For this counter, lower values are better. Values greater than 2 per disk may indicate a bottleneck and should be investigated. This means that a value of up to 8 may be acceptable for a logical unit (LUN) made up of 4 disks. Bottlenecks can create a backlog that can spread beyond the current server that is accessing the disk and result in long wait times for users. Possible solutions to a bottleneck are to add more disks to the RAID array, replace existing disks with faster disks, or move some data to other disks.
• Logical Disk: Avg. Disk Queue Length   This counter shows the average number of both read and write requests that were queued for the selected disk during the sample interval. The rule is that there should be two or fewer outstanding read and write requests per spindle, but this can be difficult to measure because of storage virtualization and differences in RAID levels between configurations. Look for larger than average disk queue lengths in combination with larger than average disk latencies. This combination can indicate that the storage array cache is being overused or that spindle sharing with other applications is affecting performance.
• Logical Disk: Avg. Disk sec/Read and Logical Disk: Avg. Disk sec/Write   These counters show the average time, in seconds, of a read or write operation to the disk. Monitor these counters to ensure that they remain below 85 percent of the disk capacity. Disk access time increases exponentially if read or write operations are more than 85 percent of disk capacity. To determine the specific capacity for your hardware, refer to the vendor documentation or use the SQLIO Disk Subsystem Benchmark Tool to calculate it. For more information, see SQLIO Disk Subsystem Benchmark Tool (http://go.microsoft.com/fwlink/p/?LinkID=105586).
  • Logical Disk: Avg. Disk sec/Read   This counter shows the average time, in seconds, of a read operation from the disk. On a well-tuned system, ideal values are from 1 through 5 ms for logs (ideally 1 ms on a cached array), and from 4 through 20 ms for data (ideally less than 10 ms). Higher latencies can occur during peak times, but if high values occur regularly, you should investigate the cause.
  • Logical Disk: Avg. Disk sec/Write   This counter shows the average time, in seconds, of a write operation to the disk. On a well-tuned system, ideal values are from 1 through 5 ms for logs (ideally 1 ms on a cached array), and from 4 through 20 ms for data (ideally less than 10 ms). Higher latencies can occur during peak times, but if high values occur regularly, you should investigate the cause.

Managing Oneself

"Success in the knowledge economy comes to those who know themselves - their strengths, their values, and how they best perform" - Peter Drucker, 2005

What are my strengths? How do I perform? What are my values? What should I contribute? You can read the full article here: http://www.sis.pitt.edu/~peterb/3005-001/managingoneself.pdf ...Or google this topic for easier-to-understand materials.

HOW TO READ A BOOK

Strategies for Getting the Most out of Non-Fiction Reading

How can you learn the most from a book when you are reading for information, rather than for pleasure?

It's very satisfying to start at the beginning and read straight through to the end. Some books, such as novels, have to be read this way, since a basic principle of fiction is to hold the reader in suspense. Your whole purpose in reading fiction is to follow the writer's lead, allowing him or her to spin a story bit by bit.

But many of the books you'll read during your undergraduate and graduate years, and possibly during the rest of your professional life, won't be novels. Instead, they'll be non-fiction: textbooks, manuals, histories, academic studies, and so on.

The purpose of reading books like these is to gain information. Here, finding out what happens — as quickly and easily as possible — is your main goal. So unless you're stuck in prison with nothing else to do, NEVER read a non-fiction book from beginning to end.

You may find more information here:  or having no time? shorter version here: http://www.farnamstreetblog.com/how-to-read-a-book/

and hang on - You will have to practice these techniques for a considerable length of time — at least a few months — before they come to seem natural, and they will never be easier than the comfortable, passive way we've all been reading for many years