History/Data Change File Approach

I need to record in a table:
Who, When, What Field and New Value of Fields
When changes occur to an existing record.

The purpose is for users to occassionally view the changes. They'll want to be able to see the history of the record - who changed what and when.

I figured I'd add the needed code to the stored procedure that's doing the update for the record.

When the stored procedure is called to do the update, the PK and parameters are sent.

The SP could first retain the current state of the record from the disk,
then do the update, then "spin" thru the fields comparing the record state prior to the update and after. Differences could be parsed to a "Changes string" and in the end, this string is saved in a history record along with a few other fields:

Name, DateTime, Changes

FK to Changed Record: some int value
Name: Joe Blow
Date: 1/1/05 12:02pm
Changes: Severity: 23 Project: Everest Assigned Lab: 204

How does the above approach sound?

Is there a better way you'd suggest?

Any sample code for a system that spins thru the fields comparing 1 temporary record with another looking for changes?

Thanks,

PeterHave you considered using a trigger? You can use the inserted and deleted tables to compare your data without having to save it manually. Then insert your data into the history table as you suggested.

We often just save the before image to the history table along with the type of operation performed, the id that was used to perform it and a time stamp. Inserted records are not recorded (because all their data is already recorded on the live table) but deleted ones are. The differences for updated records can be determined at any time by comparing the before image to the next or previous stored image or the current actual record. We rarely actually look at this sort of history however unless data disappears or the customer tells us that there is something else wrong with the data and we need to trace what happened to it.|||ejustuss - thanks for the thoughts.

Good idea about simply saving the before image prior to the actual save of the new one.

Our users are used to systems where they can click a button and see essentially the change history of the record. This particular system is a Work Order system. The status of the WO changes over time, etc.

In other non-SQL Server systems I've developed I have a routine that prior to actual save:

1. saves "before save" copy of record
2. updates the record with new values into the DB
3. peels off an "After save" copy of record
4. runs a routine that compares side by side each field. Any changes are noted in a text variable (field name, new value).
5. Once all the fields are spun thru (compared), if there is any information in the text variable, a "change table" record is created with FK to the parent record, Who Changed it, When changed, and a single text field describing all the changes.

Weeks later when a user is viewing the particular record, they can press a button and have a query run against the change table to bring up a simple list of what changed when.

One wrinkle is that a Work Order has a huge text area. Once a WO is accepted by a lab, this text are becomes "frozen". So if we simply peel off a before save copy each time a user specifies an update - I wouldn't want to needlessly include this particular field due to space considerations.

Bottom line - I was assuming someone might have a canned routine for spinning thru a record comparing all field values against an identical layed out record. I figured there might be a system function or 2 to:
1. Identify how many fields are in a table
2. identify the content of a field - something like @.@.Field(i)
where i=1 to number of fields in the table.

Peter|||I don't know of any function like that although I am sure you can write one.

In triggers you can use IF UPDATE(column) to test if a column is updated but you still have to use the column names which means writing a different trigger for each case . The data in text fields will probably not be accessible within the trigger.

You don't have to save all the fields if you do a before image either just the fields you want to compare in case they are updated.

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 security Needs, Cheep Clients, Need Help

I have an existing server hosting several sites with associated back end
databases.
I have a new client who needs secure hosting solutions, including a secure
database, without the expense of a new server. I was thinking of the
following architecture. I know some ( most ) of this is not SQL related,
but bear with me please.
I am hosting web services on the server to provide the interface with the
external world. End-Use clients will have applications with certificates to
access these web services. I have two instances of SQL Server 2005 running,
MYSERVER\PUBLIC & MYSERVER\PRIVATE.
MYSERVER\PUBLIC contains all my existing, non-secure, databases plus some
info relevant to the new service which need not be secure.
MYSERVER\PRIVATE will contain all the new, to be secured, data.
MYSERVER\PRIVATE listens only on TCPIP Address 127.0.0.1, so should be
available only as 'localhost' from within the server, i.e. not be public to
the outside world. My web services should be able to access this data, and
the web services will only be accessible to these signed applications. Of
course, any relevant info would be encrypted.
Is this sufficient ?
Any input would be appreciated
Thanks
PhilYou have to make sure that you are using different service accounts for each
instance otherwise someone gaining elevated rights within one instance will
be able to get to the other instance. Additionally, you should not allow
any SQL logins to either instance. The web server should be configured to
connect to the instances using Windows credentials which forces anyone who
can not authenticate in Windows to not have access to either database
instance. The IIS server needs to be locked down to ensure that you don't
have any security holes. The service accounts for each instance should be
regular Windows accounts and NOT a member of local administrators or even
worse domain/enterprise administrators.
After accomplishing that, you pretty much have the front door closed. Now
you have to worry about all of the back end stuff. How are you going to
handle backups of the databases such that the data in your secure instance
remains secure even through the backup files? How are you going to control
administrator and developer access within your company to the secured
instance? How are you going to audit the operations within the secure
instance such that your customer on this secure instance can't create a
situation where they actually damaged data or caused the security to be
compromised, but are pointing the finger at you?
Mike
MHS Enterprises, Inc
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Phil" <prounds@.cassandragroup.com> wrote in message
news:eFeo0WchGHA.4080@.TK2MSFTNGP03.phx.gbl...
>I have an existing server hosting several sites with associated back end
>databases.
> I have a new client who needs secure hosting solutions, including a secure
> database, without the expense of a new server. I was thinking of the
> following architecture. I know some ( most ) of this is not SQL related,
> but bear with me please.
> I am hosting web services on the server to provide the interface with the
> external world. End-Use clients will have applications with certificates
> to access these web services. I have two instances of SQL Server 2005
> running, MYSERVER\PUBLIC & MYSERVER\PRIVATE.
> MYSERVER\PUBLIC contains all my existing, non-secure, databases plus some
> info relevant to the new service which need not be secure.
> MYSERVER\PRIVATE will contain all the new, to be secured, data.
> MYSERVER\PRIVATE listens only on TCPIP Address 127.0.0.1, so should be
> available only as 'localhost' from within the server, i.e. not be public
> to the outside world. My web services should be able to access this data,
> and the web services will only be accessible to these signed applications.
> Of course, any relevant info would be encrypted.
> Is this sufficient ?
> Any input would be appreciated
> Thanks
> Phil
>|||"Phil" <prounds@.cassandragroup.com> wrote in message
news:eFeo0WchGHA.4080@.TK2MSFTNGP03.phx.gbl...
>I have an existing server hosting several sites with associated back end
>databases.
> I have a new client who needs secure hosting solutions, including a secure
> database, without the expense of a new server. I was thinking of the
> following architecture. I know some ( most ) of this is not SQL related,
> but bear with me please.
> I am hosting web services on the server to provide the interface with the
> external world. End-Use clients will have applications with certificates
> to access these web services. I have two instances of SQL Server 2005
> running, MYSERVER\PUBLIC & MYSERVER\PRIVATE.
> MYSERVER\PUBLIC contains all my existing, non-secure, databases plus some
> info relevant to the new service which need not be secure.
> MYSERVER\PRIVATE will contain all the new, to be secured, data.
> MYSERVER\PRIVATE listens only on TCPIP Address 127.0.0.1, so should be
> available only as 'localhost' from within the server, i.e. not be public
> to the outside world. My web services should be able to access this data,
> and the web services will only be accessible to these signed applications.
> Of course, any relevant info would be encrypted.
> Is this sufficient ?
>
Can't tell if it's sufficient, but it should work.
Also don't even need to enable TCP/IP for the PRIVATE instance. Programs
running on the same box can use the shared memory provider, which only works
locally. Also make sure to put the private web apps in their own
application pool (or web site), and use a seperate set of Windows accounts
to run the secure web apps, connect to SQL and as the SQL Service account.
Segegate the data and use NTFS permissions to restrict read/write to the
database files, logs and backups.
David

High availability with existing cluster

I have a active/passive clustered SQL Server 2005 Enterprise. If the
data file becomes corrupt, I've lost my high availability and because
the database is over 200GB, a restore operation will take hours. Does
anyone have any suggestions for creating a warm stand-by in a
clustered environment? Is this even possible, since the stand-by would
need to become the virutal server resource owner?"Curtis" <curtmorrison@.hotmail.com> wrote in message
news:9d55337f-76a2-49f3-b1c8-18b17d09ab16@.b64g2000hsa.googlegroups.com...
>I have a active/passive clustered SQL Server 2005 Enterprise. If the
> data file becomes corrupt, I've lost my high availability and because
> the database is over 200GB, a restore operation will take hours. Does
> anyone have any suggestions for creating a warm stand-by in a
> clustered environment? Is this even possible, since the stand-by would
> need to become the virutal server resource owner?
Hi
Database corruption will be an issue that is not covered by hardware
clustering, and may require more time for recovery if that does occur. You
can look at log shipping or database mirroring, but for this to take over
you would need to change the client and possibly an active/active cluster.
You can also look at online restores to possibly make the system available
quicker in the event of having to restore. See
http://www.microsoft.com/sql/technologies/highavailability/default.mspx
John