Wednesday, March 28, 2012
I/O size
Following is my understanding when sql needs anythings reads from disk it
request to Windows which do 64 k read even though sqlserver has only
requested single record' Am I right?
how sql handle the I/O request when it reads from RAM (data cache)?
Thanks.
--
FarhanI/O refers to an actual read from the I/O device. So if a data page is
in the SQL Server Data Cache, then there is no I/O.
So really, it is the other way 'round. During execution, data is
requested from the Storage Engine. The Storage Engine will check if the
required data page is in cache. If it is not, then the page is read from
disk (the I/O device) which will almost certainly cause I/O. It could
also trigger the storage engine into reading multiple consecutive pages
(Read Ahead) from disk and (temporarily) stored in the Data Cache.
Gert-Jan
Farhan wrote:
> Hello,
> Following is my understanding when sql needs anythings reads from disk it
> request to Windows which do 64 k read even though sqlserver has only
> requested single record' Am I right?
> how sql handle the I/O request when it reads from RAM (data cache)?
> Thanks.
> --
> Farhan|||Gert,
I am looking for the size of I/O id sqlserver misses the cache hit?
Here is what I got from search
"
IO size depends on what the operations is and we try to do a good job
of
balacing various facotrs to achieve optimal performance. The following
is
not a complete list but I hope it helps explain the situation:
Operation Random / Sequential Read / Write Size Range (per I/O)
========= =================== ============ ====================OLTP - Log Sequential Write 512 bytes - 64KB
OLTP - Data Random Read/Write 8K
Bulk Insert Sequential Write 8~128 KB
Read Ahead Sequential Read 8KB - any multiple of 8KB up to 256K
We use non-buffered IO on files so that means the windows operating
system
pass those directly to the disk subsystem. If you use RAID, then it
depends
on configuration parameters such as stripe size.
--
Wei Xiao
SQL Server Storage Engine Development
"
"Gert-Jan Strik" wrote:
> I/O refers to an actual read from the I/O device. So if a data page is
> in the SQL Server Data Cache, then there is no I/O.
> So really, it is the other way 'round. During execution, data is
> requested from the Storage Engine. The Storage Engine will check if the
> required data page is in cache. If it is not, then the page is read from
> disk (the I/O device) which will almost certainly cause I/O. It could
> also trigger the storage engine into reading multiple consecutive pages
> (Read Ahead) from disk and (temporarily) stored in the Data Cache.
> Gert-Jan
>
> Farhan wrote:
> >
> > Hello,
> > Following is my understanding when sql needs anythings reads from disk it
> > request to Windows which do 64 k read even though sqlserver has only
> > requested single record' Am I right?
> > how sql handle the I/O request when it reads from RAM (data cache)?
> > Thanks.
> > --
> > Farhan
>|||I don't think there are exact numbers, because it will depend on the
situation, the logic is internal (to the Storage Engine) and might
change with every hotfix or service pack.
Why do you want to know the I/O size?
Because it is even more 'unpredictable' then the story below suggests,
because a data cache miss can trigger multiple Read Aheads. According to
Inside SQL Server 2000 (a book I can recommend)
" Up to 32 extents of read ahead are outstanding at a time.
Four extents (32 pages) at a time are read with a single 256-KB
scatter read. "
The book also describes the read ahead behavior with respect to multiple
files, and the enhancements of Enterprise Edition (versus Standard
Edition) such as the "Merry-Go-Round" optimization.
Gert-Jan
Farhan wrote:
> Gert,
> I am looking for the size of I/O id sqlserver misses the cache hit?
> Here is what I got from search
> "
> IO size depends on what the operations is and we try to do a good job
> of
> balacing various facotrs to achieve optimal performance. The following
> is
> not a complete list but I hope it helps explain the situation:
> Operation Random / Sequential Read / Write Size Range (per I/O)
> ========= =================== ============ ====================> OLTP - Log Sequential Write 512 bytes - 64KB
> OLTP - Data Random Read/Write 8K
> Bulk Insert Sequential Write 8~128 KB
> Read Ahead Sequential Read 8KB - any multiple of 8KB up to 256K
> We use non-buffered IO on files so that means the windows operating
> system
> pass those directly to the disk subsystem. If you use RAID, then it
> depends
> on configuration parameters such as stripe size.
> --
> Wei Xiao
> SQL Server Storage Engine Development
> "
> "Gert-Jan Strik" wrote:
> > I/O refers to an actual read from the I/O device. So if a data page is
> > in the SQL Server Data Cache, then there is no I/O.
> >
> > So really, it is the other way 'round. During execution, data is
> > requested from the Storage Engine. The Storage Engine will check if the
> > required data page is in cache. If it is not, then the page is read from
> > disk (the I/O device) which will almost certainly cause I/O. It could
> > also trigger the storage engine into reading multiple consecutive pages
> > (Read Ahead) from disk and (temporarily) stored in the Data Cache.
> >
> > Gert-Jan
> >
> >
> > Farhan wrote:
> > >
> > > Hello,
> > > Following is my understanding when sql needs anythings reads from disk it
> > > request to Windows which do 64 k read even though sqlserver has only
> > > requested single record' Am I right?
> > > how sql handle the I/O request when it reads from RAM (data cache)?
> > > Thanks.
> > > --
> > > Farhan
> >
I/O request taking longer than 15 seconds to complete
07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
occurrence(s) of I/O requests taking longer than 15 seconds to complete on
file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (7). The OS
file handle is 0x000006D4. The offset of the latest long I/O is:
0x000001e856fa00
We reviewed Microsoft support notes and other forum discussion on this which
lead us to believe this might be indicative of a hardware issue. We're
running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then worked
extensively with HP support and ran a detailed diagnostics routine, 5
iterations, which consumed 12+ hours and interrogated all hardware components
- it came back with no problems.
We're not seeing any errors in the operating system event log. Could this
be an erroneous message within SQL? What else to do?I've seen this same problem and my suspicions are that the disk defrag is
causing the problem.
It only happens after hours when we've set the defrag to run. It happened
again early this morning on one of our servers but it probably been a
month or so since it happened before that.
Jim
On 2007-07-29, Jeffrey Howard <JeffreyHoward@.discussions.microsoft.com> wrote:
> We're periodically getting the following error message in the SQL log:
> 07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
> occurrence(s) of I/O requests taking longer than 15 seconds to complete on
> file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (7). The OS
> file handle is 0x000006D4. The offset of the latest long I/O is:
> 0x000001e856fa00
> We reviewed Microsoft support notes and other forum discussion on this which
> lead us to believe this might be indicative of a hardware issue. We're
> running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then worked
> extensively with HP support and ran a detailed diagnostics routine, 5
> iterations, which consumed 12+ hours and interrogated all hardware components
> - it came back with no problems.
> We're not seeing any errors in the operating system event log. Could this
> be an erroneous message within SQL? What else to do?|||What does the file stats look like? Does it indicate you have issues
reading or writing to your data or log files? What do your disk queues look
like when this happens on that drive? Are log files the only files on that
physical drive array or is it shared?
--
Andrew J. Kelly SQL MVP
"Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in message
news:C63FFFEE-84E6-4687-984A-1ECE699ED679@.microsoft.com...
> We're periodically getting the following error message in the SQL log:
> 07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
> occurrence(s) of I/O requests taking longer than 15 seconds to complete on
> file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (7). The
> OS
> file handle is 0x000006D4. The offset of the latest long I/O is:
> 0x000001e856fa00
> We reviewed Microsoft support notes and other forum discussion on this
> which
> lead us to believe this might be indicative of a hardware issue. We're
> running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then worked
> extensively with HP support and ran a detailed diagnostics routine, 5
> iterations, which consumed 12+ hours and interrogated all hardware
> components
> - it came back with no problems.
> We're not seeing any errors in the operating system event log. Could this
> be an erroneous message within SQL? What else to do?|||> We reviewed Microsoft support notes and other forum discussion on this which
In case you have not, I'd suggest you review the notes/articles by Bob Dorr
on this subject, especially this one:
http://www.microsoft.com/technet/prodtechnol/sql/2005/diagandcorrecterrs.mspx
Linchi
"Jeffrey Howard" wrote:
> We're periodically getting the following error message in the SQL log:
> 07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
> occurrence(s) of I/O requests taking longer than 15 seconds to complete on
> file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (7). The OS
> file handle is 0x000006D4. The offset of the latest long I/O is:
> 0x000001e856fa00
> We reviewed Microsoft support notes and other forum discussion on this which
> lead us to believe this might be indicative of a hardware issue. We're
> running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then worked
> extensively with HP support and ran a detailed diagnostics routine, 5
> iterations, which consumed 12+ hours and interrogated all hardware components
> - it came back with no problems.
> We're not seeing any errors in the operating system event log. Could this
> be an erroneous message within SQL? What else to do?|||Linchi:
Thank you - we reviewed the article this morning and it is not applicable to
this situation.
Jeff
"Linchi Shea" wrote:
> > We reviewed Microsoft support notes and other forum discussion on this which
> In case you have not, I'd suggest you review the notes/articles by Bob Dorr
> on this subject, especially this one:
> http://www.microsoft.com/technet/prodtechnol/sql/2005/diagandcorrecterrs.mspx
> Linchi
> "Jeffrey Howard" wrote:
> > We're periodically getting the following error message in the SQL log:
> > 07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
> > occurrence(s) of I/O requests taking longer than 15 seconds to complete on
> > file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (7). The OS
> > file handle is 0x000006D4. The offset of the latest long I/O is:
> > 0x000001e856fa00
> >
> > We reviewed Microsoft support notes and other forum discussion on this which
> > lead us to believe this might be indicative of a hardware issue. We're
> > running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then worked
> > extensively with HP support and ran a detailed diagnostics routine, 5
> > iterations, which consumed 12+ hours and interrogated all hardware components
> > - it came back with no problems.
> >
> > We're not seeing any errors in the operating system event log. Could this
> > be an erroneous message within SQL? What else to do?|||Jim:
Thank you. Our disk has 97% space availability. We did run defrag after
getting your feedback but unfortunately that didn't resolve the problem
because we more of these messages afterwards.
Jeff
"Jim Holcomb" wrote:
> I've seen this same problem and my suspicions are that the disk defrag is
> causing the problem.
> It only happens after hours when we've set the defrag to run. It happened
> again early this morning on one of our servers but it probably been a
> month or so since it happened before that.
> Jim
> On 2007-07-29, Jeffrey Howard <JeffreyHoward@.discussions.microsoft.com> wrote:
> > We're periodically getting the following error message in the SQL log:
> > 07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
> > occurrence(s) of I/O requests taking longer than 15 seconds to complete on
> > file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (7). The OS
> > file handle is 0x000006D4. The offset of the latest long I/O is:
> > 0x000001e856fa00
> >
> > We reviewed Microsoft support notes and other forum discussion on this which
> > lead us to believe this might be indicative of a hardware issue. We're
> > running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then worked
> > extensively with HP support and ran a detailed diagnostics routine, 5
> > iterations, which consumed 12+ hours and interrogated all hardware components
> > - it came back with no problems.
> >
> > We're not seeing any errors in the operating system event log. Could this
> > be an erroneous message within SQL? What else to do?
>|||Andrew:
Thank you. We're not seeing any other issues; this system is used very
lightly by 1-2 users during the day time, but has a number of batch processes
which run overnight. We rarely see these messages refer to daytime
operations. We've got 97% disk space available; the system's sole
responsibility is SQL; the drive where the log file and database are stored
is shared, but not that directory.
Jeff
"Andrew J. Kelly" wrote:
> What does the file stats look like? Does it indicate you have issues
> reading or writing to your data or log files? What do your disk queues look
> like when this happens on that drive? Are log files the only files on that
> physical drive array or is it shared?
> --
> Andrew J. Kelly SQL MVP
> "Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in message
> news:C63FFFEE-84E6-4687-984A-1ECE699ED679@.microsoft.com...
> > We're periodically getting the following error message in the SQL log:
> > 07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
> > occurrence(s) of I/O requests taking longer than 15 seconds to complete on
> > file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (7). The
> > OS
> > file handle is 0x000006D4. The offset of the latest long I/O is:
> > 0x000001e856fa00
> >
> > We reviewed Microsoft support notes and other forum discussion on this
> > which
> > lead us to believe this might be indicative of a hardware issue. We're
> > running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then worked
> > extensively with HP support and ran a detailed diagnostics routine, 5
> > iterations, which consumed 12+ hours and interrogated all hardware
> > components
> > - it came back with no problems.
> >
> > We're not seeing any errors in the operating system event log. Could this
> > be an erroneous message within SQL? What else to do?
>
>|||> the drive where the log file and database are stored
> is shared, but not that directory.
Consider moving log files to another drive, preferably RAID 1 or 10.
Separating data and log files a SQL Server Best Practice because it prevents
data file I/O from interfering with the transaction log writes and also
provides more recovery options. Moving the log files to a different drive
will likely mitigate the I/O warning messages too.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in message
news:E1CAA072-FDCE-4033-95E4-D9E0C5DF677E@.microsoft.com...
> Andrew:
> Thank you. We're not seeing any other issues; this system is used very
> lightly by 1-2 users during the day time, but has a number of batch
> processes
> which run overnight. We rarely see these messages refer to daytime
> operations. We've got 97% disk space available; the system's sole
> responsibility is SQL; the drive where the log file and database are
> stored
> is shared, but not that directory.
> Jeff
>
> "Andrew J. Kelly" wrote:
>> What does the file stats look like? Does it indicate you have issues
>> reading or writing to your data or log files? What do your disk queues
>> look
>> like when this happens on that drive? Are log files the only files on
>> that
>> physical drive array or is it shared?
>> --
>> Andrew J. Kelly SQL MVP
>> "Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in
>> message
>> news:C63FFFEE-84E6-4687-984A-1ECE699ED679@.microsoft.com...
>> > We're periodically getting the following error message in the SQL log:
>> > 07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
>> > occurrence(s) of I/O requests taking longer than 15 seconds to complete
>> > on
>> > file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (7).
>> > The
>> > OS
>> > file handle is 0x000006D4. The offset of the latest long I/O is:
>> > 0x000001e856fa00
>> >
>> > We reviewed Microsoft support notes and other forum discussion on this
>> > which
>> > lead us to believe this might be indicative of a hardware issue. We're
>> > running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then
>> > worked
>> > extensively with HP support and ran a detailed diagnostics routine, 5
>> > iterations, which consumed 12+ hours and interrogated all hardware
>> > components
>> > - it came back with no problems.
>> >
>> > We're not seeing any errors in the operating system event log. Could
>> > this
>> > be an erroneous message within SQL? What else to do?
>>|||So I take it you are saying this happens most when the batch jobs are being
run. If so then this is a prime candidate for seeing issues like this.
Anytime you do heavy write activity in SQL Server you will always have
issues to some degree with the data and log files on the same physical disk
or disk array. If this is a single disk drive and not a disk array you can
easily get I/O contention. You should think about adding another disk or
disk array as Dan mentioned to house the log files and nothing else.
--
Andrew J. Kelly SQL MVP
"Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in message
news:E1CAA072-FDCE-4033-95E4-D9E0C5DF677E@.microsoft.com...
> Andrew:
> Thank you. We're not seeing any other issues; this system is used very
> lightly by 1-2 users during the day time, but has a number of batch
> processes
> which run overnight. We rarely see these messages refer to daytime
> operations. We've got 97% disk space available; the system's sole
> responsibility is SQL; the drive where the log file and database are
> stored
> is shared, but not that directory.
> Jeff
>
> "Andrew J. Kelly" wrote:
>> What does the file stats look like? Does it indicate you have issues
>> reading or writing to your data or log files? What do your disk queues
>> look
>> like when this happens on that drive? Are log files the only files on
>> that
>> physical drive array or is it shared?
>> --
>> Andrew J. Kelly SQL MVP
>> "Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in
>> message
>> news:C63FFFEE-84E6-4687-984A-1ECE699ED679@.microsoft.com...
>> > We're periodically getting the following error message in the SQL log:
>> > 07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
>> > occurrence(s) of I/O requests taking longer than 15 seconds to complete
>> > on
>> > file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (7).
>> > The
>> > OS
>> > file handle is 0x000006D4. The offset of the latest long I/O is:
>> > 0x000001e856fa00
>> >
>> > We reviewed Microsoft support notes and other forum discussion on this
>> > which
>> > lead us to believe this might be indicative of a hardware issue. We're
>> > running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then
>> > worked
>> > extensively with HP support and ran a detailed diagnostics routine, 5
>> > iterations, which consumed 12+ hours and interrogated all hardware
>> > components
>> > - it came back with no problems.
>> >
>> > We're not seeing any errors in the operating system event log. Could
>> > this
>> > be an erroneous message within SQL? What else to do?
>>|||Make sure your batch jobs are set to not overlap at all to allow most
breathing room for the server.
--
TheSQLGuru
President
Indicium Resources, Inc.
"Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in message
news:E1CAA072-FDCE-4033-95E4-D9E0C5DF677E@.microsoft.com...
> Andrew:
> Thank you. We're not seeing any other issues; this system is used very
> lightly by 1-2 users during the day time, but has a number of batch
> processes
> which run overnight. We rarely see these messages refer to daytime
> operations. We've got 97% disk space available; the system's sole
> responsibility is SQL; the drive where the log file and database are
> stored
> is shared, but not that directory.
> Jeff
>
> "Andrew J. Kelly" wrote:
>> What does the file stats look like? Does it indicate you have issues
>> reading or writing to your data or log files? What do your disk queues
>> look
>> like when this happens on that drive? Are log files the only files on
>> that
>> physical drive array or is it shared?
>> --
>> Andrew J. Kelly SQL MVP
>> "Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in
>> message
>> news:C63FFFEE-84E6-4687-984A-1ECE699ED679@.microsoft.com...
>> > We're periodically getting the following error message in the SQL log:
>> > 07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
>> > occurrence(s) of I/O requests taking longer than 15 seconds to complete
>> > on
>> > file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (7).
>> > The
>> > OS
>> > file handle is 0x000006D4. The offset of the latest long I/O is:
>> > 0x000001e856fa00
>> >
>> > We reviewed Microsoft support notes and other forum discussion on this
>> > which
>> > lead us to believe this might be indicative of a hardware issue. We're
>> > running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then
>> > worked
>> > extensively with HP support and ran a detailed diagnostics routine, 5
>> > iterations, which consumed 12+ hours and interrogated all hardware
>> > components
>> > - it came back with no problems.
>> >
>> > We're not seeing any errors in the operating system event log. Could
>> > this
>> > be an erroneous message within SQL? What else to do?
>>|||We moved the log file to a different RAID drive but found that while it
lessened the number of these messages considerably, it did not eliminate them.
"Dan Guzman" wrote:
> > the drive where the log file and database are stored
> > is shared, but not that directory.
> Consider moving log files to another drive, preferably RAID 1 or 10.
> Separating data and log files a SQL Server Best Practice because it prevents
> data file I/O from interfering with the transaction log writes and also
> provides more recovery options. Moving the log files to a different drive
> will likely mitigate the I/O warning messages too.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in message
> news:E1CAA072-FDCE-4033-95E4-D9E0C5DF677E@.microsoft.com...
> > Andrew:
> >
> > Thank you. We're not seeing any other issues; this system is used very
> > lightly by 1-2 users during the day time, but has a number of batch
> > processes
> > which run overnight. We rarely see these messages refer to daytime
> > operations. We've got 97% disk space available; the system's sole
> > responsibility is SQL; the drive where the log file and database are
> > stored
> > is shared, but not that directory.
> >
> > Jeff
> >
> >
> >
> > "Andrew J. Kelly" wrote:
> >
> >> What does the file stats look like? Does it indicate you have issues
> >> reading or writing to your data or log files? What do your disk queues
> >> look
> >> like when this happens on that drive? Are log files the only files on
> >> that
> >> physical drive array or is it shared?
> >>
> >> --
> >> Andrew J. Kelly SQL MVP
> >>
> >> "Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in
> >> message
> >> news:C63FFFEE-84E6-4687-984A-1ECE699ED679@.microsoft.com...
> >> > We're periodically getting the following error message in the SQL log:
> >> > 07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
> >> > occurrence(s) of I/O requests taking longer than 15 seconds to complete
> >> > on
> >> > file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (7).
> >> > The
> >> > OS
> >> > file handle is 0x000006D4. The offset of the latest long I/O is:
> >> > 0x000001e856fa00
> >> >
> >> > We reviewed Microsoft support notes and other forum discussion on this
> >> > which
> >> > lead us to believe this might be indicative of a hardware issue. We're
> >> > running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then
> >> > worked
> >> > extensively with HP support and ran a detailed diagnostics routine, 5
> >> > iterations, which consumed 12+ hours and interrogated all hardware
> >> > components
> >> > - it came back with no problems.
> >> >
> >> > We're not seeing any errors in the operating system event log. Could
> >> > this
> >> > be an erroneous message within SQL? What else to do?
> >>
> >>
> >>
>|||> We moved the log file to a different RAID drive but found that while it
> lessened the number of these messages considerably, it did not eliminate
> them.
I'm glad you're making progress. The bottom line is that you'll need to
either reduce the batch workload or increase disk I/O capacity.
How are the disks configured now (RAID and number of spindles)? Do you have
any other processes besides SQL Server that may be contributing to the I/O
workload?
Have you reviewed the batch schedule as TheSQLGuru and Andrew suggested?
Since you are still getting the warning, it appears you are attempting more
concurrent work than your I/O subsystem and server can handle. In that
case, you'll probably improve batch throughput and reduce the warning
messages by adjusting the schedule. Running SQL queries serially instead of
concurrently can also improve buffer efficiency and reduce I/O workload.
Aside from changing the batch schedule, it's possible that application
tuning or redesign can reduce I/O demand. Check I/O intensive queries to
see if there is room for improvement. Adding more disks (and perhaps RAID
changes) will increase I/O capacity but I don't recommend throwing hardware
at this problem unless you are certain it's a supply and demand issue.
Also, see
http://blogs.msdn.com/sqlserverstorageengine/archive/2006/06/21/642314.aspx
and monitor the disk performance counters during batch processing.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in message
news:D20393B9-2554-46A1-A1FD-509624F07A5A@.microsoft.com...
> We moved the log file to a different RAID drive but found that while it
> lessened the number of these messages considerably, it did not eliminate
> them.
> "Dan Guzman" wrote:
>> > the drive where the log file and database are stored
>> > is shared, but not that directory.
>> Consider moving log files to another drive, preferably RAID 1 or 10.
>> Separating data and log files a SQL Server Best Practice because it
>> prevents
>> data file I/O from interfering with the transaction log writes and also
>> provides more recovery options. Moving the log files to a different
>> drive
>> will likely mitigate the I/O warning messages too.
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> "Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in
>> message
>> news:E1CAA072-FDCE-4033-95E4-D9E0C5DF677E@.microsoft.com...
>> > Andrew:
>> >
>> > Thank you. We're not seeing any other issues; this system is used very
>> > lightly by 1-2 users during the day time, but has a number of batch
>> > processes
>> > which run overnight. We rarely see these messages refer to daytime
>> > operations. We've got 97% disk space available; the system's sole
>> > responsibility is SQL; the drive where the log file and database are
>> > stored
>> > is shared, but not that directory.
>> >
>> > Jeff
>> >
>> >
>> >
>> > "Andrew J. Kelly" wrote:
>> >
>> >> What does the file stats look like? Does it indicate you have issues
>> >> reading or writing to your data or log files? What do your disk
>> >> queues
>> >> look
>> >> like when this happens on that drive? Are log files the only files on
>> >> that
>> >> physical drive array or is it shared?
>> >>
>> >> --
>> >> Andrew J. Kelly SQL MVP
>> >>
>> >> "Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in
>> >> message
>> >> news:C63FFFEE-84E6-4687-984A-1ECE699ED679@.microsoft.com...
>> >> > We're periodically getting the following error message in the SQL
>> >> > log:
>> >> > 07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
>> >> > occurrence(s) of I/O requests taking longer than 15 seconds to
>> >> > complete
>> >> > on
>> >> > file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms]
>> >> > (7).
>> >> > The
>> >> > OS
>> >> > file handle is 0x000006D4. The offset of the latest long I/O is:
>> >> > 0x000001e856fa00
>> >> >
>> >> > We reviewed Microsoft support notes and other forum discussion on
>> >> > this
>> >> > which
>> >> > lead us to believe this might be indicative of a hardware issue.
>> >> > We're
>> >> > running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then
>> >> > worked
>> >> > extensively with HP support and ran a detailed diagnostics routine,
>> >> > 5
>> >> > iterations, which consumed 12+ hours and interrogated all hardware
>> >> > components
>> >> > - it came back with no problems.
>> >> >
>> >> > We're not seeing any errors in the operating system event log.
>> >> > Could
>> >> > this
>> >> > be an erroneous message within SQL? What else to do?
>> >>
>> >>
>> >>|||Finally how did you resolve this issue?
TIA,
--
Manoj Kumar
"Jeffrey Howard" wrote:
> Linchi:
> Thank you - we reviewed the article this morning and it is not applicable to
> this situation.
> Jeff
> "Linchi Shea" wrote:
> > > We reviewed Microsoft support notes and other forum discussion on this which
> >
> > In case you have not, I'd suggest you review the notes/articles by Bob Dorr
> > on this subject, especially this one:
> > http://www.microsoft.com/technet/prodtechnol/sql/2005/diagandcorrecterrs.mspx
> >
> > Linchi
> >
> > "Jeffrey Howard" wrote:
> >
> > > We're periodically getting the following error message in the SQL log:
> > > 07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
> > > occurrence(s) of I/O requests taking longer than 15 seconds to complete on
> > > file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (7). The OS
> > > file handle is 0x000006D4. The offset of the latest long I/O is:
> > > 0x000001e856fa00
> > >
> > > We reviewed Microsoft support notes and other forum discussion on this which
> > > lead us to believe this might be indicative of a hardware issue. We're
> > > running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then worked
> > > extensively with HP support and ran a detailed diagnostics routine, 5
> > > iterations, which consumed 12+ hours and interrogated all hardware components
> > > - it came back with no problems.
> > >
> > > We're not seeing any errors in the operating system event log. Could this
> > > be an erroneous message within SQL? What else to do?|||Please post if the issue is resolved and what steps were taking to
resolve the issue.
I/O request taking longer than 15 seconds to complete
07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
occurrence(s) of I/O requests taking longer than 15 seconds to complete on
file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (7). The OS
file handle is 0x000006D4. The offset of the latest long I/O is:
0x000001e856fa00
We reviewed Microsoft support notes and other forum discussion on this which
lead us to believe this might be indicative of a hardware issue. We're
running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then worked
extensively with HP support and ran a detailed diagnostics routine, 5
iterations, which consumed 12+ hours and interrogated all hardware components
- it came back with no problems.
We're not seeing any errors in the operating system event log. Could this
be an erroneous message within SQL? What else to do?
I've seen this same problem and my suspicions are that the disk defrag is
causing the problem.
It only happens after hours when we've set the defrag to run. It happened
again early this morning on one of our servers but it probably been a
month or so since it happened before that.
Jim
On 2007-07-29, Jeffrey Howard <JeffreyHoward@.discussions.microsoft.com> wrote:
> We're periodically getting the following error message in the SQL log:
> 07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
> occurrence(s) of I/O requests taking longer than 15 seconds to complete on
> file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (7). The OS
> file handle is 0x000006D4. The offset of the latest long I/O is:
> 0x000001e856fa00
> We reviewed Microsoft support notes and other forum discussion on this which
> lead us to believe this might be indicative of a hardware issue. We're
> running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then worked
> extensively with HP support and ran a detailed diagnostics routine, 5
> iterations, which consumed 12+ hours and interrogated all hardware components
> - it came back with no problems.
> We're not seeing any errors in the operating system event log. Could this
> be an erroneous message within SQL? What else to do?
|||What does the file stats look like? Does it indicate you have issues
reading or writing to your data or log files? What do your disk queues look
like when this happens on that drive? Are log files the only files on that
physical drive array or is it shared?
Andrew J. Kelly SQL MVP
"Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in message
news:C63FFFEE-84E6-4687-984A-1ECE699ED679@.microsoft.com...
> We're periodically getting the following error message in the SQL log:
> 07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
> occurrence(s) of I/O requests taking longer than 15 seconds to complete on
> file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (7). The
> OS
> file handle is 0x000006D4. The offset of the latest long I/O is:
> 0x000001e856fa00
> We reviewed Microsoft support notes and other forum discussion on this
> which
> lead us to believe this might be indicative of a hardware issue. We're
> running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then worked
> extensively with HP support and ran a detailed diagnostics routine, 5
> iterations, which consumed 12+ hours and interrogated all hardware
> components
> - it came back with no problems.
> We're not seeing any errors in the operating system event log. Could this
> be an erroneous message within SQL? What else to do?
|||> We reviewed Microsoft support notes and other forum discussion on this which
In case you have not, I'd suggest you review the notes/articles by Bob Dorr
on this subject, especially this one:
http://www.microsoft.com/technet/prodtechnol/sql/2005/diagandcorrecterrs.mspx
Linchi
"Jeffrey Howard" wrote:
> We're periodically getting the following error message in the SQL log:
> 07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
> occurrence(s) of I/O requests taking longer than 15 seconds to complete on
> file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (7). The OS
> file handle is 0x000006D4. The offset of the latest long I/O is:
> 0x000001e856fa00
> We reviewed Microsoft support notes and other forum discussion on this which
> lead us to believe this might be indicative of a hardware issue. We're
> running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then worked
> extensively with HP support and ran a detailed diagnostics routine, 5
> iterations, which consumed 12+ hours and interrogated all hardware components
> - it came back with no problems.
> We're not seeing any errors in the operating system event log. Could this
> be an erroneous message within SQL? What else to do?
|||Linchi:
Thank you - we reviewed the article this morning and it is not applicable to
this situation.
Jeff
"Linchi Shea" wrote:
[vbcol=seagreen]
> In case you have not, I'd suggest you review the notes/articles by Bob Dorr
> on this subject, especially this one:
> http://www.microsoft.com/technet/prodtechnol/sql/2005/diagandcorrecterrs.mspx
> Linchi
> "Jeffrey Howard" wrote:
|||Jim:
Thank you. Our disk has 97% space availability. We did run defrag after
getting your feedback but unfortunately that didn't resolve the problem
because we more of these messages afterwards.
Jeff
"Jim Holcomb" wrote:
> I've seen this same problem and my suspicions are that the disk defrag is
> causing the problem.
> It only happens after hours when we've set the defrag to run. It happened
> again early this morning on one of our servers but it probably been a
> month or so since it happened before that.
> Jim
> On 2007-07-29, Jeffrey Howard <JeffreyHoward@.discussions.microsoft.com> wrote:
>
|||Andrew:
Thank you. We're not seeing any other issues; this system is used very
lightly by 1-2 users during the day time, but has a number of batch processes
which run overnight. We rarely see these messages refer to daytime
operations. We've got 97% disk space available; the system's sole
responsibility is SQL; the drive where the log file and database are stored
is shared, but not that directory.
Jeff
"Andrew J. Kelly" wrote:
> What does the file stats look like? Does it indicate you have issues
> reading or writing to your data or log files? What do your disk queues look
> like when this happens on that drive? Are log files the only files on that
> physical drive array or is it shared?
> --
> Andrew J. Kelly SQL MVP
> "Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in message
> news:C63FFFEE-84E6-4687-984A-1ECE699ED679@.microsoft.com...
>
>
|||> the drive where the log file and database are stored
> is shared, but not that directory.
Consider moving log files to another drive, preferably RAID 1 or 10.
Separating data and log files a SQL Server Best Practice because it prevents
data file I/O from interfering with the transaction log writes and also
provides more recovery options. Moving the log files to a different drive
will likely mitigate the I/O warning messages too.
Hope this helps.
Dan Guzman
SQL Server MVP
"Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in message
news:E1CAA072-FDCE-4033-95E4-D9E0C5DF677E@.microsoft.com...[vbcol=seagreen]
> Andrew:
> Thank you. We're not seeing any other issues; this system is used very
> lightly by 1-2 users during the day time, but has a number of batch
> processes
> which run overnight. We rarely see these messages refer to daytime
> operations. We've got 97% disk space available; the system's sole
> responsibility is SQL; the drive where the log file and database are
> stored
> is shared, but not that directory.
> Jeff
>
> "Andrew J. Kelly" wrote:
|||So I take it you are saying this happens most when the batch jobs are being
run. If so then this is a prime candidate for seeing issues like this.
Anytime you do heavy write activity in SQL Server you will always have
issues to some degree with the data and log files on the same physical disk
or disk array. If this is a single disk drive and not a disk array you can
easily get I/O contention. You should think about adding another disk or
disk array as Dan mentioned to house the log files and nothing else.
Andrew J. Kelly SQL MVP
"Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in message
news:E1CAA072-FDCE-4033-95E4-D9E0C5DF677E@.microsoft.com...[vbcol=seagreen]
> Andrew:
> Thank you. We're not seeing any other issues; this system is used very
> lightly by 1-2 users during the day time, but has a number of batch
> processes
> which run overnight. We rarely see these messages refer to daytime
> operations. We've got 97% disk space available; the system's sole
> responsibility is SQL; the drive where the log file and database are
> stored
> is shared, but not that directory.
> Jeff
>
> "Andrew J. Kelly" wrote:
|||We moved the log file to a different RAID drive but found that while it
lessened the number of these messages considerably, it did not eliminate them.
"Dan Guzman" wrote:
> Consider moving log files to another drive, preferably RAID 1 or 10.
> Separating data and log files a SQL Server Best Practice because it prevents
> data file I/O from interfering with the transaction log writes and also
> provides more recovery options. Moving the log files to a different drive
> will likely mitigate the I/O warning messages too.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in message
> news:E1CAA072-FDCE-4033-95E4-D9E0C5DF677E@.microsoft.com...
>
I/O request taking longer than 15 seconds to complete
07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
occurrence(s) of I/O requests taking longer than 15 seconds to complete on
file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (7)
. The OS
file handle is 0x000006D4. The offset of the latest long I/O is:
0x000001e856fa00
We reviewed Microsoft support notes and other forum discussion on this which
lead us to believe this might be indicative of a hardware issue. We're
running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then worked
extensively with HP support and ran a detailed diagnostics routine, 5
iterations, which consumed 12+ hours and interrogated all hardware component
s
- it came back with no problems.
We're not seeing any errors in the operating system event log. Could this
be an erroneous message within SQL? What else to do?I've seen this same problem and my suspicions are that the disk defrag is
causing the problem.
It only happens after hours when we've set the defrag to run. It happened
again early this morning on one of our servers but it probably been a
month or so since it happened before that.
Jim
On 2007-07-29, Jeffrey Howard <JeffreyHoward@.discussions.microsoft.com> wrote:n">
> We're periodically getting the following error message in the SQL log:
> 07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
> occurrence(s) of I/O requests taking longer than 15 seconds to complete on
> file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (
7). The OS
> file handle is 0x000006D4. The offset of the latest long I/O is:
> 0x000001e856fa00
> We reviewed Microsoft support notes and other forum discussion on this whi
ch
> lead us to believe this might be indicative of a hardware issue. We're
> running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then worked
> extensively with HP support and ran a detailed diagnostics routine, 5
> iterations, which consumed 12+ hours and interrogated all hardware compone
nts
> - it came back with no problems.
> We're not seeing any errors in the operating system event log. Could this
> be an erroneous message within SQL? What else to do?|||What does the file stats look like? Does it indicate you have issues
reading or writing to your data or log files? What do your disk queues look
like when this happens on that drive? Are log files the only files on that
physical drive array or is it shared?
Andrew J. Kelly SQL MVP
"Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in message
news:C63FFFEE-84E6-4687-984A-1ECE699ED679@.microsoft.com...
> We're periodically getting the following error message in the SQL log:
> 07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
> occurrence(s) of I/O requests taking longer than 15 seconds to complete on
> file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (
7). The
> OS
> file handle is 0x000006D4. The offset of the latest long I/O is:
> 0x000001e856fa00
> We reviewed Microsoft support notes and other forum discussion on this
> which
> lead us to believe this might be indicative of a hardware issue. We're
> running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then worked
> extensively with HP support and ran a detailed diagnostics routine, 5
> iterations, which consumed 12+ hours and interrogated all hardware
> components
> - it came back with no problems.
> We're not seeing any errors in the operating system event log. Could this
> be an erroneous message within SQL? What else to do?|||> We reviewed Microsoft support notes and other forum discussion on this whi
ch
In case you have not, I'd suggest you review the notes/articles by Bob Dorr
on this subject, especially this one:
[url]http://www.microsoft.com/technet/prodtechnol/sql/2005/diagandcorrecterrs.mspx[/url
]
Linchi
"Jeffrey Howard" wrote:
> We're periodically getting the following error message in the SQL log:
> 07/27/2007 03:42:19,spid2s,Unknown,SQL Server has encountered 21
> occurrence(s) of I/O requests taking longer than 15 seconds to complete on
> file [E:\mssql\data\centfwamms_log.ldf] in database [centfwamms] (
7). The OS
> file handle is 0x000006D4. The offset of the latest long I/O is:
> 0x000001e856fa00
> We reviewed Microsoft support notes and other forum discussion on this whi
ch
> lead us to believe this might be indicative of a hardware issue. We're
> running SQL on an HP ML150 G3, with SBS 2003 Premium R2. We then worked
> extensively with HP support and ran a detailed diagnostics routine, 5
> iterations, which consumed 12+ hours and interrogated all hardware compone
nts
> - it came back with no problems.
> We're not seeing any errors in the operating system event log. Could this
> be an erroneous message within SQL? What else to do?|||Linchi:
Thank you - we reviewed the article this morning and it is not applicable to
this situation.
Jeff
"Linchi Shea" wrote:
[vbcol=seagreen]
> In case you have not, I'd suggest you review the notes/articles by Bob Dor
r
> on this subject, especially this one:
> [url]http://www.microsoft.com/technet/prodtechnol/sql/2005/diagandcorrecterrs.mspx[/u
rl]
> Linchi
> "Jeffrey Howard" wrote:
>|||Jim:
Thank you. Our disk has 97% space availability. We did run defrag after
getting your feedback but unfortunately that didn't resolve the problem
because we more of these messages afterwards.
Jeff
"Jim Holcomb" wrote:
> I've seen this same problem and my suspicions are that the disk defrag is
> causing the problem.
> It only happens after hours when we've set the defrag to run. It happened
> again early this morning on one of our servers but it probably been a
> month or so since it happened before that.
> Jim
> On 2007-07-29, Jeffrey Howard <JeffreyHoward@.discussions.microsoft.com> wr
ote:
>|||Andrew:
Thank you. We're not seeing any other issues; this system is used very
lightly by 1-2 users during the day time, but has a number of batch processe
s
which run overnight. We rarely see these messages refer to daytime
operations. We've got 97% disk space available; the system's sole
responsibility is SQL; the drive where the log file and database are stored
is shared, but not that directory.
Jeff
"Andrew J. Kelly" wrote:
> What does the file stats look like? Does it indicate you have issues
> reading or writing to your data or log files? What do your disk queues lo
ok
> like when this happens on that drive? Are log files the only files on tha
t
> physical drive array or is it shared?
> --
> Andrew J. Kelly SQL MVP
> "Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in messag
e
> news:C63FFFEE-84E6-4687-984A-1ECE699ED679@.microsoft.com...
>
>|||> the drive where the log file and database are stored
> is shared, but not that directory.
Consider moving log files to another drive, preferably RAID 1 or 10.
Separating data and log files a SQL Server Best Practice because it prevents
data file I/O from interfering with the transaction log writes and also
provides more recovery options. Moving the log files to a different drive
will likely mitigate the I/O warning messages too.
Hope this helps.
Dan Guzman
SQL Server MVP
"Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in message
news:E1CAA072-FDCE-4033-95E4-D9E0C5DF677E@.microsoft.com...[vbcol=seagreen]
> Andrew:
> Thank you. We're not seeing any other issues; this system is used very
> lightly by 1-2 users during the day time, but has a number of batch
> processes
> which run overnight. We rarely see these messages refer to daytime
> operations. We've got 97% disk space available; the system's sole
> responsibility is SQL; the drive where the log file and database are
> stored
> is shared, but not that directory.
> Jeff
>
> "Andrew J. Kelly" wrote:
>|||So I take it you are saying this happens most when the batch jobs are being
run. If so then this is a prime candidate for seeing issues like this.
Anytime you do heavy write activity in SQL Server you will always have
issues to some degree with the data and log files on the same physical disk
or disk array. If this is a single disk drive and not a disk array you can
easily get I/O contention. You should think about adding another disk or
disk array as Dan mentioned to house the log files and nothing else.
Andrew J. Kelly SQL MVP
"Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in message
news:E1CAA072-FDCE-4033-95E4-D9E0C5DF677E@.microsoft.com...[vbcol=seagreen]
> Andrew:
> Thank you. We're not seeing any other issues; this system is used very
> lightly by 1-2 users during the day time, but has a number of batch
> processes
> which run overnight. We rarely see these messages refer to daytime
> operations. We've got 97% disk space available; the system's sole
> responsibility is SQL; the drive where the log file and database are
> stored
> is shared, but not that directory.
> Jeff
>
> "Andrew J. Kelly" wrote:
>|||Make sure your batch jobs are set to not overlap at all to allow most
breathing room for the server.
TheSQLGuru
President
Indicium Resources, Inc.
"Jeffrey Howard" <JeffreyHoward@.discussions.microsoft.com> wrote in message
news:E1CAA072-FDCE-4033-95E4-D9E0C5DF677E@.microsoft.com...[vbcol=seagreen]
> Andrew:
> Thank you. We're not seeing any other issues; this system is used very
> lightly by 1-2 users during the day time, but has a number of batch
> processes
> which run overnight. We rarely see these messages refer to daytime
> operations. We've got 97% disk space available; the system's sole
> responsibility is SQL; the drive where the log file and database are
> stored
> is shared, but not that directory.
> Jeff
>
> "Andrew J. Kelly" wrote:
>
Friday, March 9, 2012
I need to put my main page on IE when some one request for it.
Hi
Can anybody tell me that how can i configure the things that will show my main report page when i enter Url like http://localhost/ReportServer. It gives directory struction first & then we have to select particular report
Rajnish
Hi Rajnish,
You can provide the entire URL, not just the directory name. Something like this: http://Servername/ReportServer/Pages/ReportViewer.aspx?%2fReportName&rs:Command=Render
Friday, February 24, 2012
I need help, please
I use a lot of Request.QueryString("Index1")
But the Request.QueryString is always the same.
I use in If-Loops.
The server send me the follow message:
Response Buffer Limit Exceeded
Execution of the ASP page caused the Response Buffer to exceed its
configured limit
Can everybody help me, please.
Thank you.Hi,
Sorry but thats not a SQL Server question, youd better give it a try
in the ASP groups.
HTH, jens Suessmeyer.
--
http://www.sqlserver2005.de
--|||As you say, this seems to be placed in an infinite loop and so the
'buffer exceeded limit' error.
try a smaller loop like
while i < 3
Request.QueryString(...)
....
and see what gets printed.
also this is ASP error not an SQL Server.