OLEDB Wait type

I ran the command dbcc sqlperf(waitstats) to monitor the waits in our db
server, i have noticed that more than 95% of the wait time SQL Server is
experiencing is in the "OLEDB Wait" type
Can some one tell me more about OLEDB Wait type, and what causes the server
to experience such a high rate of OLEDB waits?
Thanks,
Ram
Have a look here:
http://sqldev.net/articles/WaitTypes.htm
Some of the more common things I have found with OLEDB waits are if you are
running a lot of traces, lots of DTS packages or linked servers.
Andrew J. Kelly SQL MVP
"Ram" <Ram@.discussions.microsoft.com> wrote in message
news:A26BBA12-FA18-4DF8-AFB1-B1A9263A3A51@.microsoft.com...
>I ran the command dbcc sqlperf(waitstats) to monitor the waits in our db
> server, i have noticed that more than 95% of the wait time SQL Server is
> experiencing is in the "OLEDB Wait" type
> Can some one tell me more about OLEDB Wait type, and what causes the
> server
> to experience such a high rate of OLEDB waits?
> Thanks,
> Ram
|||Thanks Andrew..
"Andrew J. Kelly" wrote:

> Have a look here:
> http://sqldev.net/articles/WaitTypes.htm
> Some of the more common things I have found with OLEDB waits are if you are
> running a lot of traces, lots of DTS packages or linked servers.
> --
> Andrew J. Kelly SQL MVP
>
> "Ram" <Ram@.discussions.microsoft.com> wrote in message
> news:A26BBA12-FA18-4DF8-AFB1-B1A9263A3A51@.microsoft.com...
>
>
|||The following article has more information on the wait types
and troubleshooting issues with different wait types:
http://www.sqldev.net/articles/WaitTypes.htm
-Sue
On Wed, 19 Jan 2005 07:21:02 -0800, Ram
<Ram@.discussions.microsoft.com> wrote:

>I ran the command dbcc sqlperf(waitstats) to monitor the waits in our db
>server, i have noticed that more than 95% of the wait time SQL Server is
>experiencing is in the "OLEDB Wait" type
>Can some one tell me more about OLEDB Wait type, and what causes the server
>to experience such a high rate of OLEDB waits?
>Thanks,
>Ram

OLEDB Wait type

I ran the command dbcc sqlperf(waitstats) to monitor the waits in our db
server, i have noticed that more than 95% of the wait time SQL Server is
experiencing is in the "OLEDB Wait" type
Can some one tell me more about OLEDB Wait type, and what causes the server
to experience such a high rate of OLEDB waits?
Thanks,
RamHave a look here:
http://sqldev.net/articles/WaitTypes.htm
Some of the more common things I have found with OLEDB waits are if you are
running a lot of traces, lots of DTS packages or linked servers.
Andrew J. Kelly SQL MVP
"Ram" <Ram@.discussions.microsoft.com> wrote in message
news:A26BBA12-FA18-4DF8-AFB1-B1A9263A3A51@.microsoft.com...
>I ran the command dbcc sqlperf(waitstats) to monitor the waits in our db
> server, i have noticed that more than 95% of the wait time SQL Server is
> experiencing is in the "OLEDB Wait" type
> Can some one tell me more about OLEDB Wait type, and what causes the
> server
> to experience such a high rate of OLEDB waits?
> Thanks,
> Ram|||Thanks Andrew..
"Andrew J. Kelly" wrote:

> Have a look here:
> http://sqldev.net/articles/WaitTypes.htm
> Some of the more common things I have found with OLEDB waits are if you ar
e
> running a lot of traces, lots of DTS packages or linked servers.
> --
> Andrew J. Kelly SQL MVP
>
> "Ram" <Ram@.discussions.microsoft.com> wrote in message
> news:A26BBA12-FA18-4DF8-AFB1-B1A9263A3A51@.microsoft.com...
>
>|||The following article has more information on the wait types
and troubleshooting issues with different wait types:
http://www.sqldev.net/articles/WaitTypes.htm
-Sue
On Wed, 19 Jan 2005 07:21:02 -0800, Ram
<Ram@.discussions.microsoft.com> wrote:

>I ran the command dbcc sqlperf(waitstats) to monitor the waits in our db
>server, i have noticed that more than 95% of the wait time SQL Server is
>experiencing is in the "OLEDB Wait" type
>Can some one tell me more about OLEDB Wait type, and what causes the server
>to experience such a high rate of OLEDB waits?
>Thanks,
>Ramsql

OLEDB Wait type

I ran the command dbcc sqlperf(waitstats) to monitor the waits in our db
server, i have noticed that more than 95% of the wait time SQL Server is
experiencing is in the "OLEDB Wait" type
Can some one tell me more about OLEDB Wait type, and what causes the server
to experience such a high rate of OLEDB waits?
Thanks,
RamHave a look here:
http://sqldev.net/articles/WaitTypes.htm
Some of the more common things I have found with OLEDB waits are if you are
running a lot of traces, lots of DTS packages or linked servers.
--
Andrew J. Kelly SQL MVP
"Ram" <Ram@.discussions.microsoft.com> wrote in message
news:A26BBA12-FA18-4DF8-AFB1-B1A9263A3A51@.microsoft.com...
>I ran the command dbcc sqlperf(waitstats) to monitor the waits in our db
> server, i have noticed that more than 95% of the wait time SQL Server is
> experiencing is in the "OLEDB Wait" type
> Can some one tell me more about OLEDB Wait type, and what causes the
> server
> to experience such a high rate of OLEDB waits?
> Thanks,
> Ram|||Thanks Andrew..
"Andrew J. Kelly" wrote:
> Have a look here:
> http://sqldev.net/articles/WaitTypes.htm
> Some of the more common things I have found with OLEDB waits are if you are
> running a lot of traces, lots of DTS packages or linked servers.
> --
> Andrew J. Kelly SQL MVP
>
> "Ram" <Ram@.discussions.microsoft.com> wrote in message
> news:A26BBA12-FA18-4DF8-AFB1-B1A9263A3A51@.microsoft.com...
> >I ran the command dbcc sqlperf(waitstats) to monitor the waits in our db
> > server, i have noticed that more than 95% of the wait time SQL Server is
> > experiencing is in the "OLEDB Wait" type
> >
> > Can some one tell me more about OLEDB Wait type, and what causes the
> > server
> > to experience such a high rate of OLEDB waits?
> >
> > Thanks,
> > Ram
>
>|||The following article has more information on the wait types
and troubleshooting issues with different wait types:
http://www.sqldev.net/articles/WaitTypes.htm
-Sue
On Wed, 19 Jan 2005 07:21:02 -0800, Ram
<Ram@.discussions.microsoft.com> wrote:
>I ran the command dbcc sqlperf(waitstats) to monitor the waits in our db
>server, i have noticed that more than 95% of the wait time SQL Server is
>experiencing is in the "OLEDB Wait" type
>Can some one tell me more about OLEDB Wait type, and what causes the server
>to experience such a high rate of OLEDB waits?
>Thanks,
>Ram

OLE DB provider ran out of memory

I run 2 sql servers same nt4 sp5 and server 1 has 2G
memory, server 1 is linked to server 3 and vice versa.
server 1 has a limit of 1.5G max memory setting for sql
server and I recently ran into this error when initiating
job from server03
OLE DB provider 'SQLOLEDB' reported an error.
The provider ran out of memory. [SQLSTATE 42000] (Error
7399) Could not relay results of procedure 'xxx' from
remote server 'server01'.
[SQLSTATE 42000] (Error 7221) Associated statement is not
prepared
[SQLSTATE HY007] (Error 0) OLE DB provider 'SQLOLEDB'
reported an error.
The provider ran out of memory. [SQLSTATE 42000] (Error
7399)
Could not relay results of procedure 'xxx' from remote
server 'server01'.
[SQLSTATE 42000] (Error 7221). The step failed.
not sure if it's a memory cache problem or what. at my
wits endThe problem is more than likely on Server 3 not 1. You say Server 1 has 2GB
with a 1.5GB max setting, what about Server 3? Linked Servers and OLEDB
type activity is usually taken from the memory to leave portion and not the
memory pool. Memory to leave can be adjusted by using the -g statup
parameter for sql server. I also suggest you set a mx memory on Server 3 if
not already.
Andrew J. Kelly
SQL Server MVP
"Paul" <anonymous@.discussions.microsoft.com> wrote in message
news:c33101c3ee91$64e3dfb0$a101280a@.phx.gbl...
> I run 2 sql servers same nt4 sp5 and server 1 has 2G
> memory, server 1 is linked to server 3 and vice versa.
> server 1 has a limit of 1.5G max memory setting for sql
> server and I recently ran into this error when initiating
> job from server03
> OLE DB provider 'SQLOLEDB' reported an error.
> The provider ran out of memory. [SQLSTATE 42000] (Error
> 7399) Could not relay results of procedure 'xxx' from
> remote server 'server01'.
> [SQLSTATE 42000] (Error 7221) Associated statement is not
> prepared
> [SQLSTATE HY007] (Error 0) OLE DB provider 'SQLOLEDB'
> reported an error.
> The provider ran out of memory. [SQLSTATE 42000] (Error
> 7399)
> Could not relay results of procedure 'xxx' from remote
> server 'server01'.
> [SQLSTATE 42000] (Error 7221). The step failed.
> not sure if it's a memory cache problem or what. at my
> wits end
>

OLE DB provider ran out of memory

I run 2 sql servers same nt4 sp5 and server 1 has 2G
memory, server 1 is linked to server 3 and vice versa.
server 1 has a limit of 1.5G max memory setting for sql
server and I recently ran into this error when initiating
job from server03
OLE DB provider 'SQLOLEDB' reported an error.
The provider ran out of memory. [SQLSTATE 42000] (Error
7399) Could not relay results of procedure 'xxx' from
remote server 'server01'.
[SQLSTATE 42000] (Error 7221) Associated statement is not
prepared
[SQLSTATE HY007] (Error 0) OLE DB provider 'SQLOLEDB'
reported an error.
The provider ran out of memory. [SQLSTATE 42000] (Error
7399)
Could not relay results of procedure 'xxx' from remote
server 'server01'.
[SQLSTATE 42000] (Error 7221). The step failed.
not sure if it's a memory cache problem or what. at my
wits endThe problem is more than likely on Server 3 not 1. You say Server 1 has 2GB
with a 1.5GB max setting, what about Server 3? Linked Servers and OLEDB
type activity is usually taken from the memory to leave portion and not the
memory pool. Memory to leave can be adjusted by using the -g statup
parameter for sql server. I also suggest you set a mx memory on Server 3 if
not already.
--
Andrew J. Kelly
SQL Server MVP
"Paul" <anonymous@.discussions.microsoft.com> wrote in message
news:c33101c3ee91$64e3dfb0$a101280a@.phx.gbl...
> I run 2 sql servers same nt4 sp5 and server 1 has 2G
> memory, server 1 is linked to server 3 and vice versa.
> server 1 has a limit of 1.5G max memory setting for sql
> server and I recently ran into this error when initiating
> job from server03
> OLE DB provider 'SQLOLEDB' reported an error.
> The provider ran out of memory. [SQLSTATE 42000] (Error
> 7399) Could not relay results of procedure 'xxx' from
> remote server 'server01'.
> [SQLSTATE 42000] (Error 7221) Associated statement is not
> prepared
> [SQLSTATE HY007] (Error 0) OLE DB provider 'SQLOLEDB'
> reported an error.
> The provider ran out of memory. [SQLSTATE 42000] (Error
> 7399)
> Could not relay results of procedure 'xxx' from remote
> server 'server01'.
> [SQLSTATE 42000] (Error 7221). The step failed.
> not sure if it's a memory cache problem or what. at my
> wits end
>

OLE DB Destination fails with illegal instruction

Environment: Server Windows 2003 SP1, VS 2005

I ran into this problem trying to deploy an SSIS package to a development server. I tested by creating a simple SSIS package on the server itself. Two blocks an OLE DB Source block and an OLE DB Destination block. Two tables in the same database, one the source, the other the destination. Connection manager test connection works fine.

Package will execute from the IDE (locally on the development server), source block will read the table subcessfully, but when the destination block executes it fails and will stay yellow in the status screen. during the execution SQLDumper.exe is triggered. Analyzing the dump tells me:

(2b40.2938): Illegal instruction - code c000001d (first/second chance not available)
eax=04008010 ebx=00000004 ecx=00000010 edx=00000000 esi=00000940 edi=00000000
eip=7c82ed54 esp=0422f598 ebp=0422f608 iopl=0 nv up ei ng nz ac po cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000297

An illegal instruction was hit.

This error exists when the destination block is either an OLE DB Destinaltion or a SQL Server Destination block and the SSIS application is executing locally.

Strangely enough if I run this same SSIS application from my development laptop it works fine against either my local datbase instance (on the laptop) or against the development server (App running on laptop, DB on development server).

I have scanned the forums and search engines for this type of error, so any assistance would be appreciated.

Thanks...

do you have logging enabled? if so, please post the exact ssis error message.|||

Date 8/7/2006 12:48:57 PM
Log Windows NT (Application)

Source SQLDUMPER
Category (0)
Event 5000
Computer SPT-TEST01

Message
EventType sql90exception, P1 dtsdebughost.exe, P2 2005.90.1399.0, P3 434f5df1, P4 dtspipeline.dll, P5 2005.90.1399.0, P6 434f5dbc, P7 0, P8 0004ba38, P9 00000000, P10 NIL.

SSIS itself displays no error information except for the block turning yellow.....

|||

I am getting the same problem:

On a new development server installation Win 2003 R2 and MSDN SQL2005 Developer edition & SP1 (was a clean install) when using DTSWizard or a SSIS package in VS2005 on the server to transfer data onto a sql table (either from another table or flat file) I get a fatal error "Unhandled win 32 exception" - looking in the event log I get

Faulting application dtswizard.exe, version 9.0.2047.0, stamp 443f5b0a, faulting module dtspipeline.dll, version 2005.90.2047.0, stamp 443f5a9c, debug? 0, fault address 0x0004c258.

VS2005 on the server is

Microsoft SQL Server Integration Services Designer
Version 9.00.2047.00

On my developer desktop I have VS2005 as

Microsoft SQL Server Integration Services Designer
Version 9.00.1399.00

and I can build a project on this which runs ok from the desktop

I do get version difference alerts if I try & load a SSIS project on the server when I initially made it on the desktop

Any ideas?

regards

|||

lwulfers wrote:

Date 8/7/2006 12:48:57 PM
Log Windows NT (Application)

Source SQLDUMPER
Category (0)
Event 5000
Computer SPT-TEST01

Message
EventType sql90exception, P1 dtsdebughost.exe, P2 2005.90.1399.0, P3 434f5df1, P4 dtspipeline.dll, P5 2005.90.1399.0, P6 434f5dbc, P7 0, P8 0004ba38, P9 00000000, P10 NIL.

SSIS itself displays no error information except for the block turning yellow.....

again, did you turn on ssis logging?

OLE DB Destination fails with illegal instruction

Environment: Server Windows 2003 SP1, VS 2005

I ran into this problem trying to deploy an SSIS package to a development server. I tested by creating a simple SSIS package on the server itself. Two blocks an OLE DB Source block and an OLE DB Destination block. Two tables in the same database, one the source, the other the destination. Connection manager test connection works fine.

Package will execute from the IDE (locally on the development server), source block will read the table subcessfully, but when the destination block executes it fails and will stay yellow in the status screen. during the execution SQLDumper.exe is triggered. Analyzing the dump tells me:

(2b40.2938): Illegal instruction - code c000001d (first/second chance not available)
eax=04008010 ebx=00000004 ecx=00000010 edx=00000000 esi=00000940 edi=00000000
eip=7c82ed54 esp=0422f598 ebp=0422f608 iopl=0 nv up ei ng nz ac po cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000297

An illegal instruction was hit.

This error exists when the destination block is either an OLE DB Destinaltion or a SQL Server Destination block and the SSIS application is executing locally.

Strangely enough if I run this same SSIS application from my development laptop it works fine against either my local datbase instance (on the laptop) or against the development server (App running on laptop, DB on development server).

I have scanned the forums and search engines for this type of error, so any assistance would be appreciated.

Thanks...

do you have logging enabled? if so, please post the exact ssis error message.|||

Date 8/7/2006 12:48:57 PM
Log Windows NT (Application)

Source SQLDUMPER
Category (0)
Event 5000
Computer SPT-TEST01

Message
EventType sql90exception, P1 dtsdebughost.exe, P2 2005.90.1399.0, P3 434f5df1, P4 dtspipeline.dll, P5 2005.90.1399.0, P6 434f5dbc, P7 0, P8 0004ba38, P9 00000000, P10 NIL.

SSIS itself displays no error information except for the block turning yellow.....

|||

I am getting the same problem:

On a new development server installation Win 2003 R2 and MSDN SQL2005 Developer edition & SP1 (was a clean install) when using DTSWizard or a SSIS package in VS2005 on the server to transfer data onto a sql table (either from another table or flat file) I get a fatal error "Unhandled win 32 exception" - looking in the event log I get

Faulting application dtswizard.exe, version 9.0.2047.0, stamp 443f5b0a, faulting module dtspipeline.dll, version 2005.90.2047.0, stamp 443f5a9c, debug? 0, fault address 0x0004c258.

VS2005 on the server is

Microsoft SQL Server Integration Services Designer
Version 9.00.2047.00

On my developer desktop I have VS2005 as

Microsoft SQL Server Integration Services Designer
Version 9.00.1399.00

and I can build a project on this which runs ok from the desktop

I do get version difference alerts if I try & load a SSIS project on the server when I initially made it on the desktop

Any ideas?

regards

|||

lwulfers wrote:

Date 8/7/2006 12:48:57 PM
Log Windows NT (Application)

Source SQLDUMPER
Category (0)
Event 5000
Computer SPT-TEST01

Message
EventType sql90exception, P1 dtsdebughost.exe, P2 2005.90.1399.0, P3 434f5df1, P4 dtspipeline.dll, P5 2005.90.1399.0, P6 434f5dbc, P7 0, P8 0004ba38, P9 00000000, P10 NIL.

SSIS itself displays no error information except for the block turning yellow.....

again, did you turn on ssis logging?

OLE DB Destination fails with illegal instruction

Environment: Server Windows 2003 SP1, VS 2005

I ran into this problem trying to deploy an SSIS package to a development server. I tested by creating a simple SSIS package on the server itself. Two blocks an OLE DB Source block and an OLE DB Destination block. Two tables in the same database, one the source, the other the destination. Connection manager test connection works fine.

Package will execute from the IDE (locally on the development server), source block will read the table subcessfully, but when the destination block executes it fails and will stay yellow in the status screen. during the execution SQLDumper.exe is triggered. Analyzing the dump tells me:

(2b40.2938): Illegal instruction - code c000001d (first/second chance not available)
eax=04008010 ebx=00000004 ecx=00000010 edx=00000000 esi=00000940 edi=00000000
eip=7c82ed54 esp=0422f598 ebp=0422f608 iopl=0 nv up ei ng nz ac po cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000297

An illegal instruction was hit.

This error exists when the destination block is either an OLE DB Destinaltion or a SQL Server Destination block and the SSIS application is executing locally.

Strangely enough if I run this same SSIS application from my development laptop it works fine against either my local datbase instance (on the laptop) or against the development server (App running on laptop, DB on development server).

I have scanned the forums and search engines for this type of error, so any assistance would be appreciated.

Thanks...

do you have logging enabled? if so, please post the exact ssis error message.|||

Date 8/7/2006 12:48:57 PM
Log Windows NT (Application)

Source SQLDUMPER
Category (0)
Event 5000
Computer SPT-TEST01

Message
EventType sql90exception, P1 dtsdebughost.exe, P2 2005.90.1399.0, P3 434f5df1, P4 dtspipeline.dll, P5 2005.90.1399.0, P6 434f5dbc, P7 0, P8 0004ba38, P9 00000000, P10 NIL.

SSIS itself displays no error information except for the block turning yellow.....

|||

I am getting the same problem:

On a new development server installation Win 2003 R2 and MSDN SQL2005 Developer edition & SP1 (was a clean install) when using DTSWizard or a SSIS package in VS2005 on the server to transfer data onto a sql table (either from another table or flat file) I get a fatal error "Unhandled win 32 exception" - looking in the event log I get

Faulting application dtswizard.exe, version 9.0.2047.0, stamp 443f5b0a, faulting module dtspipeline.dll, version 2005.90.2047.0, stamp 443f5a9c, debug? 0, fault address 0x0004c258.

VS2005 on the server is

Microsoft SQL Server Integration Services Designer
Version 9.00.2047.00

On my developer desktop I have VS2005 as

Microsoft SQL Server Integration Services Designer
Version 9.00.1399.00

and I can build a project on this which runs ok from the desktop

I do get version difference alerts if I try & load a SSIS project on the server when I initially made it on the desktop

Any ideas?

regards

|||

lwulfers wrote:

Date 8/7/2006 12:48:57 PM
Log Windows NT (Application)

Source SQLDUMPER
Category (0)
Event 5000
Computer SPT-TEST01

Message
EventType sql90exception, P1 dtsdebughost.exe, P2 2005.90.1399.0, P3 434f5df1, P4 dtspipeline.dll, P5 2005.90.1399.0, P6 434f5dbc, P7 0, P8 0004ba38, P9 00000000, P10 NIL.

SSIS itself displays no error information except for the block turning yellow.....

again, did you turn on ssis logging?

Old machines works better than the higher-end new machine

Hi all,
My setup is : SQL Server 2000 SP3 on Windows 2000.
I used the profiler to run an sql script with 33,000 commands (mostly
inserts). I ran it on 4 setups and the results were strange. Lower-end
machines ran twice as fast as higher-end machines. I also ran out system
and not the script on all machines and got the same results.
Lower-end ? Motorola Pentium III 500. with 256 MB memory, one slow disk and
.
High-end machines had 1 Xeon processor, 1GB RAM, 3 fast disks.
Any help is greatly appreciated.
AviAssuming each insert is in a separate transaction, a likely cause of the
performance difference is that write caching is enabled on the older
machines but not on the high-end boxes. A synchronous log write is
required for each transaction so you'll need to wait for the i/o to
physically complete.
Write caching improve performance but the controller must guarantee that
data will eventually get written to disk with non-volatile (e.g. battery
backup) memory. Loss of log data may result in a corrupt database.
--
Hope this helps.
Dan Guzman
SQL Server MVP
--
SQL FAQ links (courtesy Neil Pike):
http://www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
http://www.sqlserverfaq.com
http://www.mssqlserver.com/faq
--
"Avi" <rememberoti@.yahoo.com> wrote in message
news:uAoQT02rDHA.4092@.tk2msftngp13.phx.gbl...
> Hi all,
>
> My setup is : SQL Server 2000 SP3 on Windows 2000.
>
> I used the profiler to run an sql script with 33,000 commands (mostly
> inserts). I ran it on 4 setups and the results were strange.
Lower-end
> machines ran twice as fast as higher-end machines. I also ran out
system
> and not the script on all machines and got the same results.
>
> Lower-end - Motorola Pentium III 500. with 256 MB memory, one slow
disk and
> .
> High-end machines had 1 Xeon processor, 1GB RAM, 3 fast disks.
>
> Any help is greatly appreciated.
> Avi
>|||Hi,
Thanks for the reply. It is enabled on both machines..
"Dan Guzman" <danguzman@.nospam-earthlink.net> wrote in message
news:eMdns82rDHA.2260@.TK2MSFTNGP09.phx.gbl...
> Assuming each insert is in a separate transaction, a likely cause of the
> performance difference is that write caching is enabled on the older
> machines but not on the high-end boxes. A synchronous log write is
> required for each transaction so you'll need to wait for the i/o to
> physically complete.
> Write caching improve performance but the controller must guarantee that
> data will eventually get written to disk with non-volatile (e.g. battery
> backup) memory. Loss of log data may result in a corrupt database.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> --
> SQL FAQ links (courtesy Neil Pike):
> http://www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
> http://www.sqlserverfaq.com
> http://www.mssqlserver.com/faq
> --
> "Avi" <rememberoti@.yahoo.com> wrote in message
> news:uAoQT02rDHA.4092@.tk2msftngp13.phx.gbl...
> > Hi all,
> >
> >
> >
> > My setup is : SQL Server 2000 SP3 on Windows 2000.
> >
> >
> >
> > I used the profiler to run an sql script with 33,000 commands (mostly
> > inserts). I ran it on 4 setups and the results were strange.
> Lower-end
> > machines ran twice as fast as higher-end machines. I also ran out
> system
> > and not the script on all machines and got the same results.
> >
> >
> >
> > Lower-end - Motorola Pentium III 500. with 256 MB memory, one slow
> disk and
> > .
> >
> > High-end machines had 1 Xeon processor, 1GB RAM, 3 fast disks.
> >
> >
> >
> > Any help is greatly appreciated.
> >
> > Avi
> >
> >
>|||Different RAID levels?
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Avi" <rememberoti@.yahoo.com> wrote in message news:uh6ZtM5rDHA.2400@.tk2msftngp13.phx.gbl...
> Hi,
> Thanks for the reply. It is enabled on both machines..
> "Dan Guzman" <danguzman@.nospam-earthlink.net> wrote in message
> news:eMdns82rDHA.2260@.TK2MSFTNGP09.phx.gbl...
> > Assuming each insert is in a separate transaction, a likely cause of the
> > performance difference is that write caching is enabled on the older
> > machines but not on the high-end boxes. A synchronous log write is
> > required for each transaction so you'll need to wait for the i/o to
> > physically complete.
> >
> > Write caching improve performance but the controller must guarantee that
> > data will eventually get written to disk with non-volatile (e.g. battery
> > backup) memory. Loss of log data may result in a corrupt database.
> >
> > --
> > Hope this helps.
> >
> > Dan Guzman
> > SQL Server MVP
> >
> > --
> > SQL FAQ links (courtesy Neil Pike):
> >
> > http://www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
> > http://www.sqlserverfaq.com
> > http://www.mssqlserver.com/faq
> > --
> >
> > "Avi" <rememberoti@.yahoo.com> wrote in message
> > news:uAoQT02rDHA.4092@.tk2msftngp13.phx.gbl...
> > > Hi all,
> > >
> > >
> > >
> > > My setup is : SQL Server 2000 SP3 on Windows 2000.
> > >
> > >
> > >
> > > I used the profiler to run an sql script with 33,000 commands (mostly
> > > inserts). I ran it on 4 setups and the results were strange.
> > Lower-end
> > > machines ran twice as fast as higher-end machines. I also ran out
> > system
> > > and not the script on all machines and got the same results.
> > >
> > >
> > >
> > > Lower-end - Motorola Pentium III 500. with 256 MB memory, one slow
> > disk and
> > > .
> > >
> > > High-end machines had 1 Xeon processor, 1GB RAM, 3 fast disks.
> > >
> > >
> > >
> > > Any help is greatly appreciated.
> > >
> > > Avi
> > >
> > >
> >
> >
>|||Thanks for the reply!
On both machines the Write Caching is enabled.
Any other ideas?
"Dan Guzman" <danguzman@.nospam-earthlink.net> wrote in message
news:eMdns82rDHA.2260@.TK2MSFTNGP09.phx.gbl...
> Assuming each insert is in a separate transaction, a likely cause of the
> performance difference is that write caching is enabled on the older
> machines but not on the high-end boxes. A synchronous log write is
> required for each transaction so you'll need to wait for the i/o to
> physically complete.
> Write caching improve performance but the controller must guarantee that
> data will eventually get written to disk with non-volatile (e.g. battery
> backup) memory. Loss of log data may result in a corrupt database.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> --
> SQL FAQ links (courtesy Neil Pike):
> http://www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
> http://www.sqlserverfaq.com
> http://www.mssqlserver.com/faq
> --
> "Avi" <rememberoti@.yahoo.com> wrote in message
> news:uAoQT02rDHA.4092@.tk2msftngp13.phx.gbl...
> > Hi all,
> >
> >
> >
> > My setup is : SQL Server 2000 SP3 on Windows 2000.
> >
> >
> >
> > I used the profiler to run an sql script with 33,000 commands (mostly
> > inserts). I ran it on 4 setups and the results were strange.
> Lower-end
> > machines ran twice as fast as higher-end machines. I also ran out
> system
> > and not the script on all machines and got the same results.
> >
> >
> >
> > Lower-end - Motorola Pentium III 500. with 256 MB memory, one slow
> disk and
> > .
> >
> > High-end machines had 1 Xeon processor, 1GB RAM, 3 fast disks.
> >
> >
> >
> > Any help is greatly appreciated.
> >
> > Avi
> >
> >
>|||Thanks for the reply,
The disks are not RAID configured. I even disabled two of them just to make
sure of that. I still get bad response.
Any other ideas are welocme!
"Tibor Karaszi" <tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
wrote in message news:u0G$Bo6rDHA.3436@.tk2msftngp13.phx.gbl...
> Different RAID levels?
> --
> Tibor Karaszi, SQL Server MVP
> Archive at:
http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
>
> "Avi" <rememberoti@.yahoo.com> wrote in message
news:uh6ZtM5rDHA.2400@.tk2msftngp13.phx.gbl...
> > Hi,
> >
> > Thanks for the reply. It is enabled on both machines..
> >
> > "Dan Guzman" <danguzman@.nospam-earthlink.net> wrote in message
> > news:eMdns82rDHA.2260@.TK2MSFTNGP09.phx.gbl...
> > > Assuming each insert is in a separate transaction, a likely cause of
the
> > > performance difference is that write caching is enabled on the older
> > > machines but not on the high-end boxes. A synchronous log write is
> > > required for each transaction so you'll need to wait for the i/o to
> > > physically complete.
> > >
> > > Write caching improve performance but the controller must guarantee
that
> > > data will eventually get written to disk with non-volatile (e.g.
battery
> > > backup) memory. Loss of log data may result in a corrupt database.
> > >
> > > --
> > > Hope this helps.
> > >
> > > Dan Guzman
> > > SQL Server MVP
> > >
> > > --
> > > SQL FAQ links (courtesy Neil Pike):
> > >
> > > http://www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
> > > http://www.sqlserverfaq.com
> > > http://www.mssqlserver.com/faq
> > > --
> > >
> > > "Avi" <rememberoti@.yahoo.com> wrote in message
> > > news:uAoQT02rDHA.4092@.tk2msftngp13.phx.gbl...
> > > > Hi all,
> > > >
> > > >
> > > >
> > > > My setup is : SQL Server 2000 SP3 on Windows 2000.
> > > >
> > > >
> > > >
> > > > I used the profiler to run an sql script with 33,000 commands
(mostly
> > > > inserts). I ran it on 4 setups and the results were strange.
> > > Lower-end
> > > > machines ran twice as fast as higher-end machines. I also ran out
> > > system
> > > > and not the script on all machines and got the same results.
> > > >
> > > >
> > > >
> > > > Lower-end - Motorola Pentium III 500. with 256 MB memory, one slow
> > > disk and
> > > > .
> > > >
> > > > High-end machines had 1 Xeon processor, 1GB RAM, 3 fast disks.
> > > >
> > > >
> > > >
> > > > Any help is greatly appreciated.
> > > >
> > > > Avi
> > > >
> > > >
> > >
> > >
> >
> >
>|||Avi wrote:
> Hi all,
> My setup is : SQL Server 2000 SP3 on Windows 2000.
> I used the profiler to run an sql script with 33,000 commands (mostly
> inserts). I ran it on 4 setups and the results were strange. Lower-end
> machines ran twice as fast as higher-end machines. I also ran out system
> and not the script on all machines and got the same results.
> Lower-end ? Motorola Pentium III 500. with 256 MB memory, one slow disk and
> High-end machines had 1 Xeon processor, 1GB RAM, 3 fast disks.
> Any help is greatly appreciated.
> Avi
Remember that Google is your friend. You are not alone in having this
kind of problem:
http://www.google.com/groups?as_q=new+machine+slower&num=10&as_scoring=r&hl=en&ie=UTF-8&oe=UTF-8&btnG=Google+Search&as_epq=&as_oq=&as_eq=&as_ugroup=microsoft.public.sqlserver.*&as_usubject=&as_uauthors=&as_umsgid=&lr=&as_drrb=q&as_qdr=&as_mind=12&as_minm=5&as_miny=1981&as_maxd=23&as_maxm=11&as_maxy=2003&safe=images
HARDWARE:
Ensure that there are no undetected hardware differences affecting your
benchmarks, e.g., that all memory is available to the processors, that
the hardware and network component interfaces to the systems are
equivalent, that you have exclusive use of the network while testing
(don't let Joe the Programmer download MP3s from your server during
tests). Once you have eliminated possible hardware variations then
reconsider the software element.
FILE I/O:
Test the machines on non-SQL I/O processing, i.e., file I/O. Perhaps the
"fast disks" aren't as fast as claimed. There are some posts here that
might be relevant:
http://www.google.com/groups?as_q=disk+formatting&num=10&as_scoring=r&hl=en&ie=UTF-8&oe=UTF-8&btnG=Google+Search&as_epq=&as_oq=&as_eq=&as_ugroup=microsoft.public.sqlserver.*&as_usubject=&as_uauthors=&as_umsgid=&lr=&as_drrb=q&as_qdr=&as_mind=12&as_minm=5&as_miny=1981&as_maxd=23&as_maxm=11&as_maxy=2003&safe=images
Good Luck,
Michael D. Kersey