help emergency: log

Showing posts with label log. Show all posts

Wednesday, March 28, 2012

I/O request taking longer than 15 seconds to complete

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?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.

Monday, March 26, 2012

I was fianlly able to install VS tools over the weekend....Re: Help with installing VS Tools

Hi,

I have a problem with the installation of SSCE31VSTools-ENU.exe into VS2005. The installation ended after a few seconds although in the event log there is information that the product is successfuly installed. However, when I run Visual studio there is no project under Smart Device regarding SQL Compact database or something similar (there are only templates for: device application, class library, control library, console application, empty project and nothing more)

VS2005 is in this version 8.0.50727.762 (SP.050727-7600)

In application event log there is: Product: Microsoft SQL Server 2005 Compact Edition Tools for Visual Studio 2005 [ENU] -- Configuration completed successfully.'"

Has anyone some idea if there is a problem or how to create SQL Compact database?

Thank you

Jarda

Have you tried installing the released bits?|||

Hi William,

I have the same problem that the gentlemen in the initial message described. I tried installing the released bits as you recommended, but the problem continued. Do you have any other suggestions?

Thanks for your help.

Mario

|||

Hi,

yes, it's yesterday release (Date Published: 1/11/2007).

Thanks

Jarda

|||

Did you install in the correct order?

The VSTools must be installed before the SQL Server ce Runtime.

Robert Wishlaw

|||

Hi,

my installastion order was:

Compact SDK

Compact Tools

Compact SQL edition

I hope that SDK didn't install runtime.

Thanks

Jarda

|||

Hi,

I made another try with installation. Uninstall all items regarding SQL Compact edition and try to install VS Tools first. However I got this message

"The upgrade patch cannot be installed by the Windows Installer service because the program to be upgraded may be missing, or the upgrade patch may update a different version of the program. Verify that the program to be upgraded exists on your computer and that you have the correct upgrade patch." :-(

Other items can be installed well (SDK, runtime).

I have no previous (beta) installation of Compact edition on my machine.

Please help me

Thanks

Jarda

btw. the link to download the VS Tools from MS site is wrong.

|||

jardajirava wrote:

the link to download the VS Tools from MS site is wrong.

Which link?

Robert Wishlaw|||

jardajirava wrote:
Hi,
I made another try with installation. Uninstall all items regarding SQL Compact edition and try to install VS Tools first. However I got this message
"The upgrade patch cannot be installed by the Windows Installer service because the program to be upgraded may be missing, or the upgrade patch may update a different version of the program. Verify that the program to be upgraded exists on your computer and that you have the correct upgrade patch." :-(
Other items can be installed well (SDK, runtime).
I have no previous (beta) installation of Compact edition on my machine.
Please help me
Thanks
Jarda
btw. the link to download the VS Tools from MS site is wrong.

Are you installing

Microsoft SQL Server 2005 Compact Edition Server Tools

Microsoft SQL Server 2005 Compact Edition Tools for Visual Studio 2005 Service Pack 1

The first is only for installations with IIS and SQL Server 2005. (not Express)

Be sure that the versions of the VS tools and runtime are the same. Get the current version of the VSTools from the link in the Related Resources section of the runtime download page at

http://www.microsoft.com/downloads/details.aspx?FamilyID=85e0c3ce-3fa1-453a-8ce9-af6ca20946c3&DisplayLang=en#QuickInfoContainer

Robert Wishlaw|||

Hi,

it is Tools for Visual Studio 2005 Service Pack 1 (VSTools). All downloads I made yesterday (11.1.2007) I try to download it again now but same information is displayed.

I have installed this extensions/addons in my Visual studio 2005:

Microsoft Visual Studio 2005
Version 8.0.50727.762 (SP.050727-7600)
Microsoft .NET Framework
Version 2.0.50727

Installed Edition: Professional

Microsoft Visual Basic 2005 77626-009-0000007-41168
Microsoft Visual Basic 2005

Microsoft Visual C# 2005 77626-009-0000007-41168
Microsoft Visual C# 2005

Microsoft Visual C++ 2005 77626-009-0000007-41168
Microsoft Visual C++ 2005

Microsoft Visual Studio Tools for Office 77626-009-0000007-41168
Microsoft Visual Studio Tools for the Microsoft Office System

Microsoft Visual Web Developer 2005 77626-009-0000007-41168
Microsoft Visual Web Developer 2005

Microsoft Web Application Projects 2005 77626-009-0000007-41168
Microsoft Web Application Projects 2005
Version 8.0.50727.762

Visual Studio 2005 Tools for Office Second Edition 77626-009-0000007-41168
Microsoft Visual Studio 2005 Tools for the 2007 Microsoft Office System

Extensions for Windows WF
Windows Workflow Foundation Tools for Visual Studio

Microsoft Visual Studio 2005 Professional Edition - ENU Service Pack 1 (KB926601)
This service pack is for Microsoft Visual Studio 2005 Professional Edition - ENU.
If you later install a more recent service pack, this service pack will be uninstalled automatically.
For more information, visit http://support.microsoft.com/kb/926601

SQL Server Analysis Services
Microsoft SQL Server Analysis Services Designer
Version 9.00.2047.00

SQL Server Integration Services
Microsoft SQL Server Integration Services Designer
Version 9.00.1399.00

SQL Server Reporting Services
Microsoft SQL Server Reporting Services Designers
Version 9.00.1399.00

Windows Installer XML Version 3.0
Votive 2005
Windows Installer XML (WiX) Toolset, Version 3.0
Primary Contributor: Justin Rockwood
Additional Contributors: Bob Arnson
Copyright ? Microsoft Corporation. All rights reserved.

XmlMvp.XPathmania 1.0
XmlMvp.XPathmania

Maybe this helps

Thanks

Jarda

|||

I am experiencing the same problem. After downloading the most recent bits (1/11/07) from the MS website I receive the error, on attempting to install the VS Tools for Visual Studio 2005 SP1 (SSCE31VStools-Enu.msi) that:

I have confirmed I have installed VS 2005 SP1.

So... why does it reference an upgrade patch? I am installing the RTW version fresh, as I never installed the Beta.

Anyway... pretty frustrating :(

Ryan

|||

Sorry to reply to myself here... I discovered yesterday that my WMI installation is all messed up. This is rather odd as I develop WMI queries all the time against my localhost (just read queries, so I don't mess with the repositories etc).

I know WMI was working on Thursday before I installed the 3.1 Release of January 11 (in which I also uninstalled RC1). At any rate, WMI's class registrations are really messed up in a way the support articles and WMIDiag can't fix. Error message from WMI is 0x80040154 - Class not registered.

So... it makes some sense that the installer would not be able to find the correct product installed if it uses WMI to do so.

I am not able to point to the uninstall of RC1 or the install of the release version as "the problem", but it's an odd coincidence.

|||

I also get the same "The upgrade patch cannot be installed ..." message on VS SP1 when trying to install the tools.

|||

these post were helpful - I'm not going to try to install upgrade

Thanks

|||

Hi,

I just wanted to share that I was finally able to install the VS tools. The problem was that I had to uninstall and reinstall Visual Studio 2005 completely, then installed Visual Studio 2005 SP1, and finally installed the newly released code (including VS tools--> "SSCE31VSTools-ENU.exe").

I hope it helps.

Regards,

Mario

Monday, March 12, 2012

I really need help here

Hi,
My site is currently down. When users try to view a report they get
An internal error occurred on the report server. See the error log for more
details. (rsInternalError) Get Online Help
Could not allocate space for object 'ChunkData' in database
'ReportServerTempDB' because the 'PRIMARY' filegroup is full.
It was working fine until I loaded a new report a few days ago the
ReportServerTempDB when from a mere 400MB to 2.5GB. How can I fix this
please? I can't seem to find any info on this.
ThanksThis is a multi-part message in MIME format.
--=_NextPart_000_000B_01C71267.EA8848C0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: quoted-printable
Seems like your temp db is full. Try doing a transaction log backup with =truncate to shrink it.
Not quite sure what would cause the temp db to fill up like that, =though. Shrink it first, then you could run SQL Profiler against that db =do see what sort of statements that increases it so much over time.
Some of these articles might be usefull to you:
How to stop the transaction log of a SQL Server database from growing =unexpectedly
http://support.microsoft.com/kb/873235
Planning for Scalability and Performance with Reporting Services
http://www.microsoft.com/technet/prodtechnol/sql/2005/pspsqlrs.mspx
How to Performance Tune the Microsoft SQL Server tempdb Database
http://www.sql-server-performance.com/tempdb.asp
Kaisa M. Lindahl Lervik
"Chris" <Chris@.discussions.microsoft.com> wrote in message =news:9A24D6A4-E0E3-4540-8906-94C26EB7E6A2@.microsoft.com...
> Hi,
> My site is currently down. When users try to view a report they get
> > An internal error occurred on the report server. See the error log for =more > details. (rsInternalError) Get Online Help
> Could not allocate space for object 'ChunkData' in database > 'ReportServerTempDB' because the 'PRIMARY' filegroup is full. > > It was working fine until I loaded a new report a few days ago the > ReportServerTempDB when from a mere 400MB to 2.5GB. How can I fix this =
> please? I can't seem to find any info on this.
> > Thanks
--=_NextPart_000_000B_01C71267.EA8848C0
Content-Type: text/html;
charset="Utf-8"
Content-Transfer-Encoding: quoted-printable
=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&

Seems like your temp db is full. Try =doing a transaction log backup with truncate to shrink it.
Not quite sure what would cause the =temp db to fill up like that, though. Shrink it first, then you could run SQL Profiler =against that db do see what sort of statements that increases it so much over time.
Some of these articles might be usefull =to you:
How to stop the =transaction log of a SQL Server database from growing unexpectedly
http://support.microsoft.com/kb/873235
Planning for Scalability and Performance =with Reporting Services
http://www.microsoft.com/technet/prodtechnol/sql/2005/pspsqlrs.m=spx
How to =Performance Tune the Microsoft SQL Server tempdb Database

Kaisa M. Lindahl Lervik
"Chris" wrote in message news:9A24D6A4-E0E3-4540-8906-94C26EB7E6A2@.microsoft.com...> =Hi,> My site is currently down. When users try to view a report they get> => An internal error occurred on the report server. See the error =log for more > details. (rsInternalError) Get Online Help> Could =not allocate space for object 'ChunkData' in database > ='ReportServerTempDB' because the 'PRIMARY' filegroup is full. > > It was =working fine until I loaded a new report a few days ago the > =ReportServerTempDB when from a mere 400MB to 2.5GB. How can I fix this > please? I can't =seem to find any info on this.> > Thanks

--=_NextPart_000_000B_01C71267.EA8848C0--

Friday, March 9, 2012

I need to rebuild Log file from Master file

Dear sir,
Now i have big problem with SQL i lost Log file now i have only master
file . i used recovery to find Log file but not found.
Please tell me how to rebuild Log file from Master file?
Waiting your suport,
Bunthach Eng student of Cambodia (My mail bunthachx@.yahoo.com, My phone
85512 500 382
*** Sent via Developersdex http://www.examnotes.net ***Bunthach Eng wrote:

> Dear sir,
> Now i have big problem with SQL i lost Log file now i have only master
> file . i used recovery to find Log file but not found.
> Please tell me how to rebuild Log file from Master file?
> Waiting your suport,
With master file you mean data file I presume?
Try he following (procedure by Raino Botha):
shutdown sql
move the current database file or rename it
restart sql server
create a new database of the same name and log file and location as the
old database and log file
get rid of the old database. you may be able to right click delete it
in this situation or used sp_removedb
create a new database of the right size and shape with correct log and
data file locations
stop sql
rename the new databases.mdf or delete it if you don't have enough
space - do not touch the .ldf
move back in the old database .mdf file or rename it back again
restart sql server
it should come up suspect
--
1. From a query window, set the status so that you can update the system
tables by running the following query:
use Master
go
sp_configure "allow", 1
go
reconfigure with override
go
2. Then set the status of the DB that is giving you the problem (XXXXX)
into Emergency Mode by running the following query:
update sysdatabases set status = 32768 where name = '<DBName>'
go
checkpoint
go
shutdown with nowait
go
3. Go into the data directory (MSSQL7\DATA) and rename the log file
associated the DB in question (XXXX.ldf) to some temporary name, such
as XXXX.TMP.
4. Exit the query window.
5. Then start up SQL Server from a DOS command window by issuing:
sqlservr -c -T3608 -T4022.
6. Bring up another query window and verify that the DB is in emergency
mode by issuing:
select Name, Status from Sysdatabases where name = '<DB_Name>'
7. Verify that the status is 32768. If it is, then issue the query:
dbcc traceon(3604)
dbcc rebuild_log ('<DB_Name>','<log_filename>') <-- You will need the
quotation marks REBUILD_LOG should take less than 5 minutes even on a
very large
database. It should complete with the message DBCC execution completed
8. Take the database out of bypass recovery mode by issuing the command
update sysdatabases set status = 0 where name = '<DBName>'
9. Exit the query window and then shutdown (Ctrl-C in the DOS window)
and restart SQL server. Verify the status of the database by running
DBCC NEWALLOC and DBCC CHECKDB on the database."
HTH,
Stijn Verrept.|||Stijn
There is no sp_removedb stored procedure. I think you meant DROP DATABASE
...command
"Stijn Verrept" <TURN_moc.tfosyrtne@.njits_AROUND> wrote in message
news:JMadnf956pkAWzXeRVnyrQ@.scarlet.biz...
> Bunthach Eng wrote:
>
> With master file you mean data file I presume?
> Try he following (procedure by Raino Botha):
> shutdown sql
> move the current database file or rename it
> restart sql server
> create a new database of the same name and log file and location as the
> old database and log file
> get rid of the old database. you may be able to right click delete it
> in this situation or used sp_removedb
> create a new database of the right size and shape with correct log and
> data file locations
> stop sql
> rename the new databases.mdf or delete it if you don't have enough
> space - do not touch the .ldf
> move back in the old database .mdf file or rename it back again
> restart sql server
> it should come up suspect
> --
> 1. From a query window, set the status so that you can update the system
> tables by running the following query:
> use Master
> go
> sp_configure "allow", 1
> go
> reconfigure with override
> go
> 2. Then set the status of the DB that is giving you the problem (XXXXX)
> into Emergency Mode by running the following query:
> update sysdatabases set status = 32768 where name = '<DBName>'
> go
> checkpoint
> go
> shutdown with nowait
> go
> 3. Go into the data directory (MSSQL7\DATA) and rename the log file
> associated the DB in question (XXXX.ldf) to some temporary name, such
> as XXXX.TMP.
> 4. Exit the query window.
> 5. Then start up SQL Server from a DOS command window by issuing:
> sqlservr -c -T3608 -T4022.
> 6. Bring up another query window and verify that the DB is in emergency
> mode by issuing:
> select Name, Status from Sysdatabases where name = '<DB_Name>'
> 7. Verify that the status is 32768. If it is, then issue the query:
> dbcc traceon(3604)
> dbcc rebuild_log ('<DB_Name>','<log_filename>') <-- You will need the
> quotation marks REBUILD_LOG should take less than 5 minutes even on a
> very large
> database. It should complete with the message DBCC execution completed
> 8. Take the database out of bypass recovery mode by issuing the command
> update sysdatabases set status = 0 where name = '<DBName>'
> 9. Exit the query window and then shutdown (Ctrl-C in the DOS window)
> and restart SQL server. Verify the status of the database by running
> DBCC NEWALLOC and DBCC CHECKDB on the database."
> --
> HTH,
> Stijn Verrept.|||Uri Dimant wrote:

> Stijn
> There is no sp_removedb stored procedure. I think you meant DROP
> DATABASE ...command
You are right sp_removedb doesn't exist. Well as I said this procedure
isn't mine.
HTH,
Stijn Verrept.

Friday, February 24, 2012

I need Proof!

Not the alcohol kind!!
We're log shipping from one db to another in SQL 2000 and when I turn off
log shipping and move to the new server I need to be able to prove that the
two DB copies are identical bit for bit.
Is there an internal change number that I can get at with this info. Oracle
calls it the system change number.
We cannot for auditing reasons do things like: visually inspect tables,
create a final table and verify it gets applied, drop an object and once it's
dropped on the recipient move forward. Because of our Financial system
requirements, think Sarbanes Oxley, I need to be able to PROVE it with a
command, not something else.
That said, can anyone help? I thought dbcc dbinfo might do it but it
doesn't appear to be the case.
Many thanks!!!!
--
burt_king@.yahoo.comHmmm...you can check the status (success) and time/date for the t-log
backup, copy and restore jobs. Or if needed perhaps a third-party data
comparision tool like RedGate's Data Compare or ApexSQL's Diff tool.
HTH
Jerry
"burt_king" <burt_king@.yahoo.com> wrote in message
news:5EA89F29-EA3F-4793-ADD2-54411D06FE02@.microsoft.com...
> Not the alcohol kind!!
> We're log shipping from one db to another in SQL 2000 and when I turn off
> log shipping and move to the new server I need to be able to prove that
> the
> two DB copies are identical bit for bit.
> Is there an internal change number that I can get at with this info.
> Oracle
> calls it the system change number.
> We cannot for auditing reasons do things like: visually inspect tables,
> create a final table and verify it gets applied, drop an object and once
> it's
> dropped on the recipient move forward. Because of our Financial system
> requirements, think Sarbanes Oxley, I need to be able to PROVE it with a
> command, not something else.
> That said, can anyone help? I thought dbcc dbinfo might do it but it
> doesn't appear to be the case.
> Many thanks!!!!
> --
> burt_king@.yahoo.com|||copy and restore are proof enough for me,,,, but not the company. I need to
run a command which says, "what's the current version of the database?" and
both the source and destination should be the same.
--
burt_king@.yahoo.com
"Jerry Spivey" wrote:
> Hmmm...you can check the status (success) and time/date for the t-log
> backup, copy and restore jobs. Or if needed perhaps a third-party data
> comparision tool like RedGate's Data Compare or ApexSQL's Diff tool.
> HTH
> Jerry
> "burt_king" <burt_king@.yahoo.com> wrote in message
> news:5EA89F29-EA3F-4793-ADD2-54411D06FE02@.microsoft.com...
> > Not the alcohol kind!!
> >
> > We're log shipping from one db to another in SQL 2000 and when I turn off
> > log shipping and move to the new server I need to be able to prove that
> > the
> > two DB copies are identical bit for bit.
> >
> > Is there an internal change number that I can get at with this info.
> > Oracle
> > calls it the system change number.
> >
> > We cannot for auditing reasons do things like: visually inspect tables,
> > create a final table and verify it gets applied, drop an object and once
> > it's
> > dropped on the recipient move forward. Because of our Financial system
> > requirements, think Sarbanes Oxley, I need to be able to PROVE it with a
> > command, not something else.
> >
> > That said, can anyone help? I thought dbcc dbinfo might do it but it
> > doesn't appear to be the case.
> >
> > Many thanks!!!!
> > --
> > burt_king@.yahoo.com
>
>|||Like Jerry said, your best bet is probably a third-party tool for an
extremely strict data versioning requirement like that.
"burt_king" <burt_king@.yahoo.com> wrote in message
news:04BEEA1F-7FB3-4095-A784-870A95A6F0C4@.microsoft.com...
> copy and restore are proof enough for me,,,, but not the company. I need
> to
> run a command which says, "what's the current version of the database?"
> and
> both the source and destination should be the same.
> --
> burt_king@.yahoo.com
>
> "Jerry Spivey" wrote:
>> Hmmm...you can check the status (success) and time/date for the t-log
>> backup, copy and restore jobs. Or if needed perhaps a third-party data
>> comparision tool like RedGate's Data Compare or ApexSQL's Diff tool.
>> HTH
>> Jerry
>> "burt_king" <burt_king@.yahoo.com> wrote in message
>> news:5EA89F29-EA3F-4793-ADD2-54411D06FE02@.microsoft.com...
>> > Not the alcohol kind!!
>> >
>> > We're log shipping from one db to another in SQL 2000 and when I turn
>> > off
>> > log shipping and move to the new server I need to be able to prove that
>> > the
>> > two DB copies are identical bit for bit.
>> >
>> > Is there an internal change number that I can get at with this info.
>> > Oracle
>> > calls it the system change number.
>> >
>> > We cannot for auditing reasons do things like: visually inspect tables,
>> > create a final table and verify it gets applied, drop an object and
>> > once
>> > it's
>> > dropped on the recipient move forward. Because of our Financial
>> > system
>> > requirements, think Sarbanes Oxley, I need to be able to PROVE it with
>> > a
>> > command, not something else.
>> >
>> > That said, can anyone help? I thought dbcc dbinfo might do it but it
>> > doesn't appear to be the case.
>> >
>> > Many thanks!!!!
>> > --
>> > burt_king@.yahoo.com
>>|||try
DBCC fileheader [( {'dbname' | dbid} [, fileid])
--
Aleksandar Grbic
"burt_king" wrote:
> Not the alcohol kind!!
> We're log shipping from one db to another in SQL 2000 and when I turn off
> log shipping and move to the new server I need to be able to prove that the
> two DB copies are identical bit for bit.
> Is there an internal change number that I can get at with this info. Oracle
> calls it the system change number.
> We cannot for auditing reasons do things like: visually inspect tables,
> create a final table and verify it gets applied, drop an object and once it's
> dropped on the recipient move forward. Because of our Financial system
> requirements, think Sarbanes Oxley, I need to be able to PROVE it with a
> command, not something else.
> That said, can anyone help? I thought dbcc dbinfo might do it but it
> doesn't appear to be the case.
> Many thanks!!!!
> --
> burt_king@.yahoo.com|||DBCC fileheader doesn't appear to match the two for a log shipping server.
Sorry.
--
burt_king@.yahoo.com
"Aleksandar Grbic" wrote:
> try
> DBCC fileheader [( {'dbname' | dbid} [, fileid])
> --
> Aleksandar Grbic
>
> "burt_king" wrote:
> > Not the alcohol kind!!
> >
> > We're log shipping from one db to another in SQL 2000 and when I turn off
> > log shipping and move to the new server I need to be able to prove that the
> > two DB copies are identical bit for bit.
> >
> > Is there an internal change number that I can get at with this info. Oracle
> > calls it the system change number.
> >
> > We cannot for auditing reasons do things like: visually inspect tables,
> > create a final table and verify it gets applied, drop an object and once it's
> > dropped on the recipient move forward. Because of our Financial system
> > requirements, think Sarbanes Oxley, I need to be able to PROVE it with a
> > command, not something else.
> >
> > That said, can anyone help? I thought dbcc dbinfo might do it but it
> > doesn't appear to be the case.
> >
> > Many thanks!!!!
> > --
> > burt_king@.yahoo.com

Wednesday, March 28, 2012

I/O request taking longer than 15 seconds to complete

Monday, March 26, 2012

I was fianlly able to install VS tools over the weekend....Re: Help with installing VS Tools

Monday, March 12, 2012

I really need help here

Friday, March 9, 2012

I need to rebuild Log file from Master file

Friday, February 24, 2012

I need Proof!

I need Proof!

help emergency

Blog Archive

About Me