High values shown in fn_virtualfilestats

Hello
Recently taken a new DBA position, reviewing existing infrasturture and DB
config's
Ran fn_Virtualfilestats and got the following values
does anyone think these are high or show areas for further investigation,
don't want to waste time on further research unless it is warranted etc..
DbId FileId NumberReads NumberWrites BytesRead BytesWritten
IoStallMS TotalIO TotalBytes AvgStallPerIO AvgBytesPerIO %IO
%Bytes %Stall
1 1 130,290 1,526 1,958,551,552 12,607,488 1,698,394 131,816
1,971,159,040 12 14,953 - - -
1 2 133 8,352 844,288 7,136,768 530 8,485 7,981,056 - 940
- - -
2 1 2,083,373 2,601,750 123,263,590,400 142,436,696,064 4,019,981
4,685,123 265,700,286,464 - 56,711 - - -
2 2 445 40,305 3,399,680 2,011,328,000 138,101 40,750
2,014,727,680 3 49,441 - - -
3 1 1,657 212 102,449,152 1,761,280 10,597 1,869 104,210,432
5 55,757 - - -
3 2 125 376 808,960 1,279,488 606 501 2,088,448 1 4,168 -
- -
4 1 85,701 12,803 1,611,898,880 115,671,040 920,057 98,504
1,727,569,920 9 17,538 - - -
4 2 131 35,076 867,840 38,672,896 734 35,207 39,540,736 -
1,123 - - -
5 1 129,386,983 74,380,203 4,230,597,074,944 758,879,707,136
620,669,109 203,767,186 4,989,476,782,080 3 24,486 23 15 35
5 2 46,854 7,785,308 8,537,051,648 170,821,746,176 83,066
7,832,162 179,358,797,824 - 22,900 - - -
5 3 859,051 161,645 137,308,340,224 8,708,202,496 433,444
1,020,696 146,016,542,720 - 143,055 - - -
6 1 300,782,919 39,811,200 13,757,658,587,136 883,146,989,568
624,737,406 340,594,119 14,640,805,576,704 1 42,986 38 44 35
6 2 37,640,629 48,658,405 2,287,763,603,456 1,769,531,336,704
587,872 86,299,034 4,057,294,940,160 - 47,014 9 12 -
6 3 93,167,363 5,626,515 1,646,596,202,496 91,128,004,608
206,870,818 98,793,878 1,737,724,207,104 2 17,589 11 5 11
6 4 40,422 42,124 3,743,186,944 3,528,704,000 40,320 82,546
7,271,890,944 - 88,095 - - -
6 5 37,396,020 9,428,284 4,503,717,322,752 110,340,931,584
155,824,784 46,824,304 4,614,058,254,336 3 98,539 5 13 8
6 6 87,854,655 6,876,154 2,424,926,773,248 99,701,825,536
150,576,872 94,730,809 2,524,628,598,784 1 26,650 10 7 8
18 1 1,524 16 20,750,336 131,072 33,663 1,540 20,881,408 21
13,559 - - -
18 2 10 17 279,552 165,888 187 27 445,440 6 16,497 -
- -
--
Neil HamblyNeil,
That is a pretty unreadable post and most people willnot take the time to
clean it up. But a single snapshot of filestats is mostly meaningless by
itself. You need to take a baseline or starting point first. Then after
some period of time you take another reading and compare the differences.
That gives you a time period to reference how long it takes for the numbers
to accumulate.
--
Andrew J. Kelly SQL MVP
"Neil Hambly" <hambly_neil@.hotmail.com> wrote in message
news:49136F95-EF7A-42AF-9042-08D670FBDA36@.microsoft.com...
> Hello
> Recently taken a new DBA position, reviewing existing infrasturture and DB
> config's
> Ran fn_Virtualfilestats and got the following values
> does anyone think these are high or show areas for further investigation,
> don't want to waste time on further research unless it is warranted etc..
> DbId FileId NumberReads NumberWrites BytesRead BytesWritten
> IoStallMS TotalIO TotalBytes AvgStallPerIO AvgBytesPerIO %IO
> %Bytes %Stall
> 1 1 130,290 1,526 1,958,551,552 12,607,488 1,698,394 131,816
> 1,971,159,040 12 14,953 - - -
> 1 2 133 8,352 844,288 7,136,768 530 8,485 7,981,056 - 940
> - - -
> 2 1 2,083,373 2,601,750 123,263,590,400 142,436,696,064 4,019,981
> 4,685,123 265,700,286,464 - 56,711 - - -
> 2 2 445 40,305 3,399,680 2,011,328,000 138,101 40,750
> 2,014,727,680 3 49,441 - - -
> 3 1 1,657 212 102,449,152 1,761,280 10,597 1,869 104,210,432
> 5 55,757 - - -
> 3 2 125 376 808,960 1,279,488 606 501 2,088,448 1 4,168 -
> - -
> 4 1 85,701 12,803 1,611,898,880 115,671,040 920,057 98,504
> 1,727,569,920 9 17,538 - - -
> 4 2 131 35,076 867,840 38,672,896 734 35,207 39,540,736 -
> 1,123 - - -
> 5 1 129,386,983 74,380,203 4,230,597,074,944 758,879,707,136
> 620,669,109 203,767,186 4,989,476,782,080 3 24,486 23 15 35
> 5 2 46,854 7,785,308 8,537,051,648 170,821,746,176 83,066
> 7,832,162 179,358,797,824 - 22,900 - - -
> 5 3 859,051 161,645 137,308,340,224 8,708,202,496 433,444
> 1,020,696 146,016,542,720 - 143,055 - - -
> 6 1 300,782,919 39,811,200 13,757,658,587,136 883,146,989,568
> 624,737,406 340,594,119 14,640,805,576,704 1 42,986 38 44 35
> 6 2 37,640,629 48,658,405 2,287,763,603,456 1,769,531,336,704
> 587,872 86,299,034 4,057,294,940,160 - 47,014 9 12 -
> 6 3 93,167,363 5,626,515 1,646,596,202,496 91,128,004,608
> 206,870,818 98,793,878 1,737,724,207,104 2 17,589 11 5 11
> 6 4 40,422 42,124 3,743,186,944 3,528,704,000 40,320 82,546
> 7,271,890,944 - 88,095 - - -
> 6 5 37,396,020 9,428,284 4,503,717,322,752 110,340,931,584
> 155,824,784 46,824,304 4,614,058,254,336 3 98,539 5 13 8
> 6 6 87,854,655 6,876,154 2,424,926,773,248 99,701,825,536
> 150,576,872 94,730,809 2,524,628,598,784 1 26,650 10 7 8
> 18 1 1,524 16 20,750,336 131,072 33,663 1,540 20,881,408 21
> 13,559 - - -
> 18 2 10 17 279,552 165,888 187 27 445,440 6 16,497 -
> - -
> --
> Neil Hambly|||May be easier to read if values copied into excel
main concerns are with Byte
"Neil Hambly" wrote:
> Hello
> Recently taken a new DBA position, reviewing existing infrasturture and DB
> config's
> Ran fn_Virtualfilestats and got the following values
> does anyone think these are high or show areas for further investigation,
> don't want to waste time on further research unless it is warranted etc..
> DbId FileId NumberReads NumberWrites BytesRead BytesWritten
> IoStallMS TotalIO TotalBytes AvgStallPerIO AvgBytesPerIO %IO
> %Bytes %Stall
> 1 1 130,290 1,526 1,958,551,552 12,607,488 1,698,394 131,816
> 1,971,159,040 12 14,953 - - -
> 1 2 133 8,352 844,288 7,136,768 530 8,485 7,981,056 - 940
> - - -
> 2 1 2,083,373 2,601,750 123,263,590,400 142,436,696,064 4,019,981
> 4,685,123 265,700,286,464 - 56,711 - - -
> 2 2 445 40,305 3,399,680 2,011,328,000 138,101 40,750
> 2,014,727,680 3 49,441 - - -
> 3 1 1,657 212 102,449,152 1,761,280 10,597 1,869 104,210,432
> 5 55,757 - - -
> 3 2 125 376 808,960 1,279,488 606 501 2,088,448 1 4,168 -
> - -
> 4 1 85,701 12,803 1,611,898,880 115,671,040 920,057 98,504
> 1,727,569,920 9 17,538 - - -
> 4 2 131 35,076 867,840 38,672,896 734 35,207 39,540,736 -
> 1,123 - - -
> 5 1 129,386,983 74,380,203 4,230,597,074,944 758,879,707,136
> 620,669,109 203,767,186 4,989,476,782,080 3 24,486 23 15 35
> 5 2 46,854 7,785,308 8,537,051,648 170,821,746,176 83,066
> 7,832,162 179,358,797,824 - 22,900 - - -
> 5 3 859,051 161,645 137,308,340,224 8,708,202,496 433,444
> 1,020,696 146,016,542,720 - 143,055 - - -
> 6 1 300,782,919 39,811,200 13,757,658,587,136 883,146,989,568
> 624,737,406 340,594,119 14,640,805,576,704 1 42,986 38 44 35
> 6 2 37,640,629 48,658,405 2,287,763,603,456 1,769,531,336,704
> 587,872 86,299,034 4,057,294,940,160 - 47,014 9 12 -
> 6 3 93,167,363 5,626,515 1,646,596,202,496 91,128,004,608
> 206,870,818 98,793,878 1,737,724,207,104 2 17,589 11 5 11
> 6 4 40,422 42,124 3,743,186,944 3,528,704,000 40,320 82,546
> 7,271,890,944 - 88,095 - - -
> 6 5 37,396,020 9,428,284 4,503,717,322,752 110,340,931,584
> 155,824,784 46,824,304 4,614,058,254,336 3 98,539 5 13 8
> 6 6 87,854,655 6,876,154 2,424,926,773,248 99,701,825,536
> 150,576,872 94,730,809 2,524,628,598,784 1 26,650 10 7 8
> 18 1 1,524 16 20,750,336 131,072 33,663 1,540 20,881,408 21
> 13,559 - - -
> 18 2 10 17 279,552 165,888 187 27 445,440 6 16,497 -
> - -
> --
> Neil Hamblysql

High values shown in fn_virtualfilestats

Hello
Recently taken a new DBA position, reviewing existing infrasturture and DB
config's
Ran fn_Virtualfilestats and got the following values
does anyone think these are high or show areas for further investigation,
don't want to waste time on further research unless it is warranted etc..
DbId FileId NumberReads NumberWrites BytesRead BytesWritten
IoStallMS TotalIO TotalBytes AvgStallPerIO AvgBytesPerIO %IO
%Bytes %Stall
1 1 130,290 1,526 1,958,551,552 12,607,488 1,698,394 131,816
1,971,159,040 12 14,953 - - -
1 2 133 8,352 844,288 7,136,768 530 8,485 7,981,056 - 940
- - -
2 1 2,083,373 2,601,750 123,263,590,400 142,436,696,064 4,019,981
4,685,123 265,700,286,464 - 56,711 - - -
2 2 445 40,305 3,399,680 2,011,328,000 138,101 40,750
2,014,727,680 3 49,441 - - -
3 1 1,657 212 102,449,152 1,761,280 10,597 1,869 104,210,432
5 55,757 - - -
3 2 125 376 808,960 1,279,488 606 501 2,088,448 1 4,168 -
- -
4 1 85,701 12,803 1,611,898,880 115,671,040 920,057 98,504
1,727,569,920 9 17,538 - - -
4 2 131 35,076 867,840 38,672,896 734 35,207 39,540,736 -
1,123 - - -
5 1 129,386,983 74,380,203 4,230,597,074,944 758,879,707,136
620,669,109 203,767,186 4,989,476,782,080 3 24,486 23 15 35
5 2 46,854 7,785,308 8,537,051,648 170,821,746,176 83,066
7,832,162 179,358,797,824 - 22,900 - - -
5 3 859,051 161,645 137,308,340,224 8,708,202,496 433,444
1,020,696 146,016,542,720 - 143,055 - - -
6 1 300,782,919 39,811,200 13,757,658,587,136 883,146,989,568
624,737,406 340,594,119 14,640,805,576,704 1 42,986 38 44 35
6 2 37,640,629 48,658,405 2,287,763,603,456 1,769,531,336,704
587,872 86,299,034 4,057,294,940,160 - 47,014 9 12 -
6 3 93,167,363 5,626,515 1,646,596,202,496 91,128,004,608
206,870,818 98,793,878 1,737,724,207,104 2 17,589 11 5 11
6 4 40,422 42,124 3,743,186,944 3,528,704,000 40,320 82,546
7,271,890,944 - 88,095 - - -
6 5 37,396,020 9,428,284 4,503,717,322,752 110,340,931,584
155,824,784 46,824,304 4,614,058,254,336 3 98,539 5 13 8
6 6 87,854,655 6,876,154 2,424,926,773,248 99,701,825,536
150,576,872 94,730,809 2,524,628,598,784 1 26,650 10 7 8
18 1 1,524 16 20,750,336 131,072 33,663 1,540 20,881,408 21
13,559 - - -
18 2 10 17 279,552 165,888 187 27 445,440 6 16,497 -
- -
Neil HamblyNeil,
That is a pretty unreadable post and most people willnot take the time to
clean it up. But a single snapshot of filestats is mostly meaningless by
itself. You need to take a baseline or starting point first. Then after
some period of time you take another reading and compare the differences.
That gives you a time period to reference how long it takes for the numbers
to accumulate.
Andrew J. Kelly SQL MVP
"Neil Hambly" <hambly_neil@.hotmail.com> wrote in message
news:49136F95-EF7A-42AF-9042-08D670FBDA36@.microsoft.com...
> Hello
> Recently taken a new DBA position, reviewing existing infrasturture and DB
> config's
> Ran fn_Virtualfilestats and got the following values
> does anyone think these are high or show areas for further investigation,
> don't want to waste time on further research unless it is warranted etc..
> DbId FileId NumberReads NumberWrites BytesRead BytesWritten
> IoStallMS TotalIO TotalBytes AvgStallPerIO AvgBytesPerIO %IO
> %Bytes %Stall
> 1 1 130,290 1,526 1,958,551,552 12,607,488 1,698,394 131,816
> 1,971,159,040 12 14,953 - - -
> 1 2 133 8,352 844,288 7,136,768 530 8,485 7,981,056 - 940
> - - -
> 2 1 2,083,373 2,601,750 123,263,590,400 142,436,696,064 4,019,981
> 4,685,123 265,700,286,464 - 56,711 - - -
> 2 2 445 40,305 3,399,680 2,011,328,000 138,101 40,750
> 2,014,727,680 3 49,441 - - -
> 3 1 1,657 212 102,449,152 1,761,280 10,597 1,869 104,210,432
> 5 55,757 - - -
> 3 2 125 376 808,960 1,279,488 606 501 2,088,448 1 4,168 -
> - -
> 4 1 85,701 12,803 1,611,898,880 115,671,040 920,057 98,504
> 1,727,569,920 9 17,538 - - -
> 4 2 131 35,076 867,840 38,672,896 734 35,207 39,540,736 -
> 1,123 - - -
> 5 1 129,386,983 74,380,203 4,230,597,074,944 758,879,707,136
> 620,669,109 203,767,186 4,989,476,782,080 3 24,486 23 15 35
> 5 2 46,854 7,785,308 8,537,051,648 170,821,746,176 83,066
> 7,832,162 179,358,797,824 - 22,900 - - -
> 5 3 859,051 161,645 137,308,340,224 8,708,202,496 433,444
> 1,020,696 146,016,542,720 - 143,055 - - -
> 6 1 300,782,919 39,811,200 13,757,658,587,136 883,146,989,568
> 624,737,406 340,594,119 14,640,805,576,704 1 42,986 38 44 35
> 6 2 37,640,629 48,658,405 2,287,763,603,456 1,769,531,336,704
> 587,872 86,299,034 4,057,294,940,160 - 47,014 9 12 -
> 6 3 93,167,363 5,626,515 1,646,596,202,496 91,128,004,608
> 206,870,818 98,793,878 1,737,724,207,104 2 17,589 11 5 11
> 6 4 40,422 42,124 3,743,186,944 3,528,704,000 40,320 82,546
> 7,271,890,944 - 88,095 - - -
> 6 5 37,396,020 9,428,284 4,503,717,322,752 110,340,931,584
> 155,824,784 46,824,304 4,614,058,254,336 3 98,539 5 13 8
> 6 6 87,854,655 6,876,154 2,424,926,773,248 99,701,825,536
> 150,576,872 94,730,809 2,524,628,598,784 1 26,650 10 7 8
> 18 1 1,524 16 20,750,336 131,072 33,663 1,540 20,881,408 21
> 13,559 - - -
> 18 2 10 17 279,552 165,888 187 27 445,440 6 16,497 -
> - -
> --
> Neil Hambly|||May be easier to read if values copied into excel
main concerns are with Byte
"Neil Hambly" wrote:

> Hello
> Recently taken a new DBA position, reviewing existing infrasturture and DB
> config's
> Ran fn_Virtualfilestats and got the following values
> does anyone think these are high or show areas for further investigation,
> don't want to waste time on further research unless it is warranted etc..
> DbId FileId NumberReads NumberWrites BytesRead BytesWritten
> IoStallMS TotalIO TotalBytes AvgStallPerIO AvgBytesPerIO %IO
> %Bytes %Stall
> 1 1 130,290 1,526 1,958,551,552 12,607,488 1,698,394 131,816
> 1,971,159,040 12 14,953 - - -
> 1 2 133 8,352 844,288 7,136,768 530 8,485 7,981,056 - 9
40
> - - -
> 2 1 2,083,373 2,601,750 123,263,590,400 142,436,696,064 4,019,981
> 4,685,123 265,700,286,464 - 56,711 - - -
> 2 2 445 40,305 3,399,680 2,011,328,000 138,101 40,750
> 2,014,727,680 3 49,441 - - -
> 3 1 1,657 212 102,449,152 1,761,280 10,597 1,869 104,210,432
> 5 55,757 - - -
> 3 2 125 376 808,960 1,279,488 606 501 2,088,448 1 4,168
-
> - -
> 4 1 85,701 12,803 1,611,898,880 115,671,040 920,057 98,504
> 1,727,569,920 9 17,538 - - -
> 4 2 131 35,076 867,840 38,672,896 734 35,207 39,540,736 -
> 1,123 - - -
> 5 1 129,386,983 74,380,203 4,230,597,074,944 758,879,707,136
> 620,669,109 203,767,186 4,989,476,782,080 3 24,486 23 15 35
> 5 2 46,854 7,785,308 8,537,051,648 170,821,746,176 83,066
> 7,832,162 179,358,797,824 - 22,900 - - -
> 5 3 859,051 161,645 137,308,340,224 8,708,202,496 433,444
> 1,020,696 146,016,542,720 - 143,055 - - -
> 6 1 300,782,919 39,811,200 13,757,658,587,136 883,146,989,568
> 624,737,406 340,594,119 14,640,805,576,704 1 42,986 38 44 35
> 6 2 37,640,629 48,658,405 2,287,763,603,456 1,769,531,336,704
> 587,872 86,299,034 4,057,294,940,160 - 47,014 9 12 -
> 6 3 93,167,363 5,626,515 1,646,596,202,496 91,128,004,608
> 206,870,818 98,793,878 1,737,724,207,104 2 17,589 11 5 11
> 6 4 40,422 42,124 3,743,186,944 3,528,704,000 40,320 82,546
> 7,271,890,944 - 88,095 - - -
> 6 5 37,396,020 9,428,284 4,503,717,322,752 110,340,931,584
> 155,824,784 46,824,304 4,614,058,254,336 3 98,539 5 13 8
> 6 6 87,854,655 6,876,154 2,424,926,773,248 99,701,825,536
> 150,576,872 94,730,809 2,524,628,598,784 1 26,650 10 7 8
> 18 1 1,524 16 20,750,336 131,072 33,663 1,540 20,881,408 21
> 13,559 - - -
> 18 2 10 17 279,552 165,888 187 27 445,440 6 16,497 -
> - -
> --
> Neil Hambly

High values shown in fn_virtualfilestats

Hello
Recently taken a new DBA position, reviewing existing infrasturture and DB
config's
Ran fn_Virtualfilestats and got the following values
does anyone think these are high or show areas for further investigation,
don't want to waste time on further research unless it is warranted etc..
DbIdFileId NumberReads NumberWrites BytesRead BytesWritten
IoStallMS TotalIO TotalBytes AvgStallPerIO AvgBytesPerIO %IO
%Bytes %Stall
11 130,290 1,526 1,958,551,552 12,607,488 1,698,394 131,816
1,971,159,040 12 14,953 - - -
12 133 8,352 844,288 7,136,768 530 8,485 7,981,056 - 940
- - -
21 2,083,373 2,601,750 123,263,590,400 142,436,696,064 4,019,981
4,685,123 265,700,286,464 - 56,711 - - -
22 445 40,305 3,399,680 2,011,328,000 138,101 40,750
2,014,727,680 3 49,441 - - -
31 1,657 212 102,449,152 1,761,280 10,597 1,869 104,210,432
5 55,757 - - -
32 125 376 808,960 1,279,488 606 501 2,088,448 1 4,168 -
- -
41 85,701 12,803 1,611,898,880 115,671,040 920,057 98,504
1,727,569,920 9 17,538 - - -
42 131 35,076 867,840 38,672,896 734 35,207 39,540,736 -
1,123 - - -
51 129,386,983 74,380,203 4,230,597,074,944 758,879,707,136
620,669,109 203,767,186 4,989,476,782,080 3 24,486 23 15 35
52 46,854 7,785,308 8,537,051,648 170,821,746,176 83,066
7,832,162 179,358,797,824 - 22,900 - - -
53 859,051 161,645 137,308,340,224 8,708,202,496 433,444
1,020,696 146,016,542,720 - 143,055 - - -
61 300,782,919 39,811,200 13,757,658,587,136 883,146,989,568
624,737,406 340,594,119 14,640,805,576,704 1 42,986 38 44 35
62 37,640,629 48,658,405 2,287,763,603,456 1,769,531,336,704
587,872 86,299,034 4,057,294,940,160 - 47,014 9 12 -
63 93,167,363 5,626,515 1,646,596,202,496 91,128,004,608
206,870,818 98,793,878 1,737,724,207,104 2 17,589 11 5 11
64 40,422 42,124 3,743,186,944 3,528,704,000 40,320 82,546
7,271,890,944 - 88,095 - - -
65 37,396,020 9,428,284 4,503,717,322,752 110,340,931,584
155,824,784 46,824,304 4,614,058,254,336 3 98,539 5 13 8
66 87,854,655 6,876,154 2,424,926,773,248 99,701,825,536
150,576,872 94,730,809 2,524,628,598,784 1 26,650 10 7 8
181 1,524 16 20,750,336 131,072 33,663 1,540 20,881,408 21
13,559 - - -
182 10 17 279,552 165,888 187 27 445,440 6 16,497 -
- -
Neil Hambly
Neil,
That is a pretty unreadable post and most people willnot take the time to
clean it up. But a single snapshot of filestats is mostly meaningless by
itself. You need to take a baseline or starting point first. Then after
some period of time you take another reading and compare the differences.
That gives you a time period to reference how long it takes for the numbers
to accumulate.
Andrew J. Kelly SQL MVP
"Neil Hambly" <hambly_neil@.hotmail.com> wrote in message
news:49136F95-EF7A-42AF-9042-08D670FBDA36@.microsoft.com...
> Hello
> Recently taken a new DBA position, reviewing existing infrasturture and DB
> config's
> Ran fn_Virtualfilestats and got the following values
> does anyone think these are high or show areas for further investigation,
> don't want to waste time on further research unless it is warranted etc..
> DbId FileId NumberReads NumberWrites BytesRead BytesWritten
> IoStallMS TotalIO TotalBytes AvgStallPerIO AvgBytesPerIO %IO
> %Bytes %Stall
> 1 1 130,290 1,526 1,958,551,552 12,607,488 1,698,394 131,816
> 1,971,159,040 12 14,953 - - -
> 1 2 133 8,352 844,288 7,136,768 530 8,485 7,981,056 - 940
> - - -
> 2 1 2,083,373 2,601,750 123,263,590,400 142,436,696,064 4,019,981
> 4,685,123 265,700,286,464 - 56,711 - - -
> 2 2 445 40,305 3,399,680 2,011,328,000 138,101 40,750
> 2,014,727,680 3 49,441 - - -
> 3 1 1,657 212 102,449,152 1,761,280 10,597 1,869 104,210,432
> 5 55,757 - - -
> 3 2 125 376 808,960 1,279,488 606 501 2,088,448 1 4,168 -
> - -
> 4 1 85,701 12,803 1,611,898,880 115,671,040 920,057 98,504
> 1,727,569,920 9 17,538 - - -
> 4 2 131 35,076 867,840 38,672,896 734 35,207 39,540,736 -
> 1,123 - - -
> 5 1 129,386,983 74,380,203 4,230,597,074,944 758,879,707,136
> 620,669,109 203,767,186 4,989,476,782,080 3 24,486 23 15 35
> 5 2 46,854 7,785,308 8,537,051,648 170,821,746,176 83,066
> 7,832,162 179,358,797,824 - 22,900 - - -
> 5 3 859,051 161,645 137,308,340,224 8,708,202,496 433,444
> 1,020,696 146,016,542,720 - 143,055 - - -
> 6 1 300,782,919 39,811,200 13,757,658,587,136 883,146,989,568
> 624,737,406 340,594,119 14,640,805,576,704 1 42,986 38 44 35
> 6 2 37,640,629 48,658,405 2,287,763,603,456 1,769,531,336,704
> 587,872 86,299,034 4,057,294,940,160 - 47,014 9 12 -
> 6 3 93,167,363 5,626,515 1,646,596,202,496 91,128,004,608
> 206,870,818 98,793,878 1,737,724,207,104 2 17,589 11 5 11
> 6 4 40,422 42,124 3,743,186,944 3,528,704,000 40,320 82,546
> 7,271,890,944 - 88,095 - - -
> 6 5 37,396,020 9,428,284 4,503,717,322,752 110,340,931,584
> 155,824,784 46,824,304 4,614,058,254,336 3 98,539 5 13 8
> 6 6 87,854,655 6,876,154 2,424,926,773,248 99,701,825,536
> 150,576,872 94,730,809 2,524,628,598,784 1 26,650 10 7 8
> 18 1 1,524 16 20,750,336 131,072 33,663 1,540 20,881,408 21
> 13,559 - - -
> 18 2 10 17 279,552 165,888 187 27 445,440 6 16,497 -
> - -
> --
> Neil Hambly
|||May be easier to read if values copied into excel
main concerns are with Byte
"Neil Hambly" wrote:

> Hello
> Recently taken a new DBA position, reviewing existing infrasturture and DB
> config's
> Ran fn_Virtualfilestats and got the following values
> does anyone think these are high or show areas for further investigation,
> don't want to waste time on further research unless it is warranted etc..
> DbIdFileId NumberReads NumberWrites BytesRead BytesWritten
> IoStallMS TotalIO TotalBytes AvgStallPerIO AvgBytesPerIO %IO
> %Bytes %Stall
> 11 130,290 1,526 1,958,551,552 12,607,488 1,698,394 131,816
> 1,971,159,040 12 14,953 - - -
> 12 133 8,352 844,288 7,136,768 530 8,485 7,981,056 - 940
> - - -
> 21 2,083,373 2,601,750 123,263,590,400 142,436,696,064 4,019,981
> 4,685,123 265,700,286,464 - 56,711 - - -
> 22 445 40,305 3,399,680 2,011,328,000 138,101 40,750
> 2,014,727,680 3 49,441 - - -
> 31 1,657 212 102,449,152 1,761,280 10,597 1,869 104,210,432
> 5 55,757 - - -
> 32 125 376 808,960 1,279,488 606 501 2,088,448 1 4,168 -
> - -
> 41 85,701 12,803 1,611,898,880 115,671,040 920,057 98,504
> 1,727,569,920 9 17,538 - - -
> 42 131 35,076 867,840 38,672,896 734 35,207 39,540,736 -
> 1,123 - - -
> 51 129,386,983 74,380,203 4,230,597,074,944 758,879,707,136
> 620,669,109 203,767,186 4,989,476,782,080 3 24,486 23 15 35
> 52 46,854 7,785,308 8,537,051,648 170,821,746,176 83,066
> 7,832,162 179,358,797,824 - 22,900 - - -
> 53 859,051 161,645 137,308,340,224 8,708,202,496 433,444
> 1,020,696 146,016,542,720 - 143,055 - - -
> 61 300,782,919 39,811,200 13,757,658,587,136 883,146,989,568
> 624,737,406 340,594,119 14,640,805,576,704 1 42,986 38 44 35
> 62 37,640,629 48,658,405 2,287,763,603,456 1,769,531,336,704
> 587,872 86,299,034 4,057,294,940,160 - 47,014 9 12 -
> 63 93,167,363 5,626,515 1,646,596,202,496 91,128,004,608
> 206,870,818 98,793,878 1,737,724,207,104 2 17,589 11 5 11
> 64 40,422 42,124 3,743,186,944 3,528,704,000 40,320 82,546
> 7,271,890,944 - 88,095 - - -
> 65 37,396,020 9,428,284 4,503,717,322,752 110,340,931,584
> 155,824,784 46,824,304 4,614,058,254,336 3 98,539 5 13 8
> 66 87,854,655 6,876,154 2,424,926,773,248 99,701,825,536
> 150,576,872 94,730,809 2,524,628,598,784 1 26,650 10 7 8
> 181 1,524 16 20,750,336 131,072 33,663 1,540 20,881,408 21
> 13,559 - - -
> 182 10 17 279,552 165,888 187 27 445,440 6 16,497 -
> - -
> --
> Neil Hambly

High file i/o

SQL Server 2000 SP4 running on Windows Server 2003 with two RAID 5 disk
groups, A and B.
I've done some monitoring using fn_virtualfilestats() and determined
that of the five databases on my SQL Server, the "Fred" database's data
file is getting a great majority of the reads and writes of all the
data files on disk group A. During peak periods, disk group A's average
disk queue length is 14 compared with disk group B's average of 2. As
you can see, disk group A, where Fred's data file resides, is getting
hammered!
Now that I know this, I'd like to spread disk group A's i/o out over
these two disks groups by creating another filegroup for the Fred
database on disk group B and moving certain high i/o tables and/or
indexes to it. How can I determine which table(s) and/or index(es)
would be good candidates for this? The best I've determined so far is
to take an educated guess, but I would prefer to see some real i/o
numbers at the table level. Is this possible?
Thanks,
AaronMy first question for you is where are your transaction log files? In my
experience, moving the transaction logs to their own device offers the
biggest performance improvement. Next would be moving your nonclustered
indexes to their own filegroup on a separate device.
"Aaron S" <gcsdba1@.yahoo.com> wrote in message
news:1154308389.902467.305860@.i42g2000cwa.googlegroups.com...
> SQL Server 2000 SP4 running on Windows Server 2003 with two RAID 5 disk
> groups, A and B.
> I've done some monitoring using fn_virtualfilestats() and determined
> that of the five databases on my SQL Server, the "Fred" database's data
> file is getting a great majority of the reads and writes of all the
> data files on disk group A. During peak periods, disk group A's average
> disk queue length is 14 compared with disk group B's average of 2. As
> you can see, disk group A, where Fred's data file resides, is getting
> hammered!
> Now that I know this, I'd like to spread disk group A's i/o out over
> these two disks groups by creating another filegroup for the Fred
> database on disk group B and moving certain high i/o tables and/or
> indexes to it. How can I determine which table(s) and/or index(es)
> would be good candidates for this? The best I've determined so far is
> to take an educated guess, but I would prefer to see some real i/o
> numbers at the table level. Is this possible?
> Thanks,
> Aaron
>|||"Aaron S" <gcsdba1@.yahoo.com> wrote in message
news:1154308389.902467.305860@.i42g2000cwa.googlegroups.com...
> SQL Server 2000 SP4 running on Windows Server 2003 with two RAID 5 disk
> groups, A and B.
> I've done some monitoring using fn_virtualfilestats() and determined
> that of the five databases on my SQL Server, the "Fred" database's data
> file is getting a great majority of the reads and writes of all the
> data files on disk group A. During peak periods, disk group A's average
> disk queue length is 14 compared with disk group B's average of 2. As
> you can see, disk group A, where Fred's data file resides, is getting
> hammered!
> Now that I know this, I'd like to spread disk group A's i/o out over
> these two disks groups by creating another filegroup for the Fred
> database on disk group B and moving certain high i/o tables and/or
> indexes to it. How can I determine which table(s) and/or index(es)
> would be good candidates for this? The best I've determined so far is
> to take an educated guess, but I would prefer to see some real i/o
> numbers at the table level. Is this possible?
>
In 2000 I'm not sure. But it's a bad deal anyway. You'll forever be
tweaking the placement of objects on filegroups. If you place the object on
a file group having one file on each volume, SQL Server will automatically
balance space (and traffic) between the files and thus the volumes.
David|||Aaron
Be aware , that you 'll be benefit from the perfomance issue only if you
move the file to the filegropup that located on another physical disk.

> indexes to it. How can I determine which table(s) and/or index(es)
> would be good candidates for this?
Run SQL Server Profiler to see what is going on.
"Aaron S" <gcsdba1@.yahoo.com> wrote in message
news:1154308389.902467.305860@.i42g2000cwa.googlegroups.com...
> SQL Server 2000 SP4 running on Windows Server 2003 with two RAID 5 disk
> groups, A and B.
> I've done some monitoring using fn_virtualfilestats() and determined
> that of the five databases on my SQL Server, the "Fred" database's data
> file is getting a great majority of the reads and writes of all the
> data files on disk group A. During peak periods, disk group A's average
> disk queue length is 14 compared with disk group B's average of 2. As
> you can see, disk group A, where Fred's data file resides, is getting
> hammered!
> Now that I know this, I'd like to spread disk group A's i/o out over
> these two disks groups by creating another filegroup for the Fred
> database on disk group B and moving certain high i/o tables and/or
> indexes to it. How can I determine which table(s) and/or index(es)
> would be good candidates for this? The best I've determined so far is
> to take an educated guess, but I would prefer to see some real i/o
> numbers at the table level. Is this possible?
> Thanks,
> Aaron
>|||Aaron S wrote:
> SQL Server 2000 SP4 running on Windows Server 2003 with two RAID 5 disk
> groups, A and B.
> I've done some monitoring using fn_virtualfilestats() and determined
> that of the five databases on my SQL Server, the "Fred" database's data
> file is getting a great majority of the reads and writes of all the
> data files on disk group A. During peak periods, disk group A's average
> disk queue length is 14 compared with disk group B's average of 2. As
> you can see, disk group A, where Fred's data file resides, is getting
> hammered!
> Now that I know this, I'd like to spread disk group A's i/o out over
> these two disks groups by creating another filegroup for the Fred
> database on disk group B and moving certain high i/o tables and/or
> indexes to it. How can I determine which table(s) and/or index(es)
> would be good candidates for this? The best I've determined so far is
> to take an educated guess, but I would prefer to see some real i/o
> numbers at the table level. Is this possible?
> Thanks,
> Aaron
>
More than likely, you're seeing the result of missing or inadequate
indexes. Monitor the SQL Server:Access Methods -> Full Scans/sec
counter, and then use Profiler to determine which queries are producing
the most Reads. Pick the worst offender, focus on optimizing that query
(through indexing, rewrites, etc). Rinse, repeat...
Tracy McKibben
MCDBA
http://www.realsqlguy.comsql

High file i/o

SQL Server 2000 SP4 running on Windows Server 2003 with two RAID 5 disk
groups, A and B.
I've done some monitoring using fn_virtualfilestats() and determined
that of the five databases on my SQL Server, the "Fred" database's data
file is getting a great majority of the reads and writes of all the
data files on disk group A. During peak periods, disk group A's average
disk queue length is 14 compared with disk group B's average of 2. As
you can see, disk group A, where Fred's data file resides, is getting
hammered!
Now that I know this, I'd like to spread disk group A's i/o out over
these two disks groups by creating another filegroup for the Fred
database on disk group B and moving certain high i/o tables and/or
indexes to it. How can I determine which table(s) and/or index(es)
would be good candidates for this? The best I've determined so far is
to take an educated guess, but I would prefer to see some real i/o
numbers at the table level. Is this possible?
Thanks,
AaronMy first question for you is where are your transaction log files? In my
experience, moving the transaction logs to their own device offers the
biggest performance improvement. Next would be moving your nonclustered
indexes to their own filegroup on a separate device.
"Aaron S" <gcsdba1@.yahoo.com> wrote in message
news:1154308389.902467.305860@.i42g2000cwa.googlegroups.com...
> SQL Server 2000 SP4 running on Windows Server 2003 with two RAID 5 disk
> groups, A and B.
> I've done some monitoring using fn_virtualfilestats() and determined
> that of the five databases on my SQL Server, the "Fred" database's data
> file is getting a great majority of the reads and writes of all the
> data files on disk group A. During peak periods, disk group A's average
> disk queue length is 14 compared with disk group B's average of 2. As
> you can see, disk group A, where Fred's data file resides, is getting
> hammered!
> Now that I know this, I'd like to spread disk group A's i/o out over
> these two disks groups by creating another filegroup for the Fred
> database on disk group B and moving certain high i/o tables and/or
> indexes to it. How can I determine which table(s) and/or index(es)
> would be good candidates for this? The best I've determined so far is
> to take an educated guess, but I would prefer to see some real i/o
> numbers at the table level. Is this possible?
> Thanks,
> Aaron
>|||"Aaron S" <gcsdba1@.yahoo.com> wrote in message
news:1154308389.902467.305860@.i42g2000cwa.googlegroups.com...
> SQL Server 2000 SP4 running on Windows Server 2003 with two RAID 5 disk
> groups, A and B.
> I've done some monitoring using fn_virtualfilestats() and determined
> that of the five databases on my SQL Server, the "Fred" database's data
> file is getting a great majority of the reads and writes of all the
> data files on disk group A. During peak periods, disk group A's average
> disk queue length is 14 compared with disk group B's average of 2. As
> you can see, disk group A, where Fred's data file resides, is getting
> hammered!
> Now that I know this, I'd like to spread disk group A's i/o out over
> these two disks groups by creating another filegroup for the Fred
> database on disk group B and moving certain high i/o tables and/or
> indexes to it. How can I determine which table(s) and/or index(es)
> would be good candidates for this? The best I've determined so far is
> to take an educated guess, but I would prefer to see some real i/o
> numbers at the table level. Is this possible?
>
In 2000 I'm not sure. But it's a bad deal anyway. You'll forever be
tweaking the placement of objects on filegroups. If you place the object on
a file group having one file on each volume, SQL Server will automatically
balance space (and traffic) between the files and thus the volumes.
David|||Aaron
Be aware , that you 'll be benefit from the perfomance issue only if you
move the file to the filegropup that located on another physical disk.
> indexes to it. How can I determine which table(s) and/or index(es)
> would be good candidates for this?
Run SQL Server Profiler to see what is going on.
"Aaron S" <gcsdba1@.yahoo.com> wrote in message
news:1154308389.902467.305860@.i42g2000cwa.googlegroups.com...
> SQL Server 2000 SP4 running on Windows Server 2003 with two RAID 5 disk
> groups, A and B.
> I've done some monitoring using fn_virtualfilestats() and determined
> that of the five databases on my SQL Server, the "Fred" database's data
> file is getting a great majority of the reads and writes of all the
> data files on disk group A. During peak periods, disk group A's average
> disk queue length is 14 compared with disk group B's average of 2. As
> you can see, disk group A, where Fred's data file resides, is getting
> hammered!
> Now that I know this, I'd like to spread disk group A's i/o out over
> these two disks groups by creating another filegroup for the Fred
> database on disk group B and moving certain high i/o tables and/or
> indexes to it. How can I determine which table(s) and/or index(es)
> would be good candidates for this? The best I've determined so far is
> to take an educated guess, but I would prefer to see some real i/o
> numbers at the table level. Is this possible?
> Thanks,
> Aaron
>|||Aaron S wrote:
> SQL Server 2000 SP4 running on Windows Server 2003 with two RAID 5 disk
> groups, A and B.
> I've done some monitoring using fn_virtualfilestats() and determined
> that of the five databases on my SQL Server, the "Fred" database's data
> file is getting a great majority of the reads and writes of all the
> data files on disk group A. During peak periods, disk group A's average
> disk queue length is 14 compared with disk group B's average of 2. As
> you can see, disk group A, where Fred's data file resides, is getting
> hammered!
> Now that I know this, I'd like to spread disk group A's i/o out over
> these two disks groups by creating another filegroup for the Fred
> database on disk group B and moving certain high i/o tables and/or
> indexes to it. How can I determine which table(s) and/or index(es)
> would be good candidates for this? The best I've determined so far is
> to take an educated guess, but I would prefer to see some real i/o
> numbers at the table level. Is this possible?
> Thanks,
> Aaron
>
More than likely, you're seeing the result of missing or inadequate
indexes. Monitor the SQL Server:Access Methods -> Full Scans/sec
counter, and then use Profiler to determine which queries are producing
the most Reads. Pick the worst offender, focus on optimizing that query
(through indexing, rewrites, etc). Rinse, repeat...
Tracy McKibben
MCDBA
http://www.realsqlguy.com