Optimizing insert performance

Hi there.
We're using SQL Server 2000 on a Windows 2000 box with dual
hyperthreaded Intel CPUs, raided hard disks and 2GB RAM. It should
certainly be able to handle our currently fairly modest demands. We
have all the latest security patches. Parallelism is disabled.
We're currently experiencing unacceptable slowness for inserts to a
particular table, Account_Transaction (see the DDL at the end of this
message). As you can see, the main features are a BIGINT auto-increment
primary key, and three foreign keys. This table currently has 7 million
rows and another million are inserted each month. We are currently
unhappy with the length of time it takes to insert into this table as
this operation is at the heart of our application.
Here is an example insert, called from within a stored procedure:
INSERT INTO dbo.Account_Transaction(
invoice_id, transaction_type_id, qty, amount, commission,
tax_percentage, currency_code, points, line_id, comment,
balance_before, external_id)
VALUES
(
@.invoice_id,
@.transaction_type_id,
@.qty,
@.amount,
@.amount_commission,
@.tax_percentage,
@.currency_code_home,
@.points,
@.line_id,
@.comment,
@.balance,
@.external_id
)
Looking at this query's SP:StmtCompleted event from the profiler we can
see the query took 375ms to complete and performed 76 reads (and
apparently zero writes, although the data was definitely inserted). We
think this is far too long.
What is strange though is that if we run the exact same statement
OUTSIDE of the calling procedure in query analyzer, substituting
literals for the variables, then it apparently completes in just 63ms,
although it performs the same number of writes:
INSERT INTO dbo.Account_Transaction(
invoice_id, transaction_type_id, qty, amount, commission,
tax_percentage, currency_code, points, line_id, comment,
balance_before, external_id)
VALUES
(6842289, 12, 1, 1, 0, 10, 'AUD', 0, 4, 'test', 0, 0)
If we now try the same two things on our test database, running on a a
bog-standard desktop machine, with only 300000 rows in the
Account_Transaction table, then both queries execute in similar times of
around 70ms.
So my question is - what is causing the slowness, and how can we speed
it up? How do we make the insert operation from within the SP take the
same amount of time as it takes when run on its own?
Any help appreciated,
Mike C
CREATE TABLE [dbo].[Account_Transaction] (
[id] [bigint] IDENTITY (1, 1) NOT NULL ,
[invoice_id] [bigint] NOT NULL ,
[transaction_type_id] [int] NOT NULL ,
[qty] [int] NOT NULL ,
[amount] [money] NOT NULL ,
[tax_percentage] [decimal](9, 3) NULL ,
[commission] [float] NOT NULL ,
[currency_code] [char] (3) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
[line_id] [int] NOT NULL ,
[points] [int] NOT NULL ,
[comment] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[balance_before] [money] NOT NULL ,
[balance_after] [money] NULL ,
[external_id] [bigint] NULL ,
[msrepl_tran_version] [uniqueidentifier] NOT NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Account_Transaction] WITH NOCHECK ADD
CONSTRAINT [PK_Account_Transaction] PRIMARY KEY CLUSTERED
(
[id]
) WITH FILLFACTOR = 90 ON [PRIMARY]
GO
ALTER TABLE [dbo].[Account_Transaction] WITH NOCHECK ADD
CONSTRAINT [DF__Account_T__amoun__3118447E] DEFAULT (0) FOR [amount],
CONSTRAINT [DF__Account_T__point__320C68B7] DEFAULT (0) FOR [points],
CONSTRAINT [DF__Account_T__msrep__31783731] DEFAULT (newid()) FOR
[msrepl_tran_version]
GO
CREATE INDEX [IX_Account_Transaction] ON
[dbo].[Account_Transaction]([invoice_id]) WITH FILLFACTOR = 90 ON [PRIMARY]
GO
ALTER TABLE [dbo].[Account_Transaction] ADD
CONSTRAINT [FK_Account_Transaction_Account_Invoice]
FOREIGN KEY
(
[invoice_id]
) REFERENCES [dbo].[Account_Invoice] (
[id]
) ON DELETE CASCADE ON UPDATE CASCADE ,
CONSTRAINT [FK_Account_Transaction_Line] FOREIGN KEY
(
[line_id]
) REFERENCES [dbo].[Line] (
[id]
),
CONSTRAINT [FK_Account_Transaction_Transaction_Type
] FOREIGN KEY
(
[transaction_type_id]
) REFERENCES [dbo].[Transaction_Type] (
[id]
)
GOMike
1) Make sure that your table has no triggers
2) Try drop the indexes just prior to INSERTING and re-create them after
Another thing might help that if you do it by using SP which accepted
parameters try to re-assign these parameters to local variable
CREATE PROC myProc
@.par INT
AS
DECLARE @.lpar INT
SET @.lpar =@.par
INSERT INTO Table VALUES (@.lpar )
"Mike Chamberlain" <none@.hotmail.com> wrote in message
news:eGXwhg%23HGHA.1180@.TK2MSFTNGP09.phx.gbl...
> Hi there.
> We're using SQL Server 2000 on a Windows 2000 box with dual hyperthreaded
> Intel CPUs, raided hard disks and 2GB RAM. It should certainly be able to
> handle our currently fairly modest demands. We have all the latest
> security patches. Parallelism is disabled.
> We're currently experiencing unacceptable slowness for inserts to a
> particular table, Account_Transaction (see the DDL at the end of this
> message). As you can see, the main features are a BIGINT auto-increment
> primary key, and three foreign keys. This table currently has 7 million
> rows and another million are inserted each month. We are currently
> unhappy with the length of time it takes to insert into this table as this
> operation is at the heart of our application.
> Here is an example insert, called from within a stored procedure:
> INSERT INTO dbo.Account_Transaction(
> invoice_id, transaction_type_id, qty, amount, commission,
> tax_percentage, currency_code, points, line_id, comment,
> balance_before, external_id)
> VALUES
> (
> @.invoice_id,
> @.transaction_type_id,
> @.qty,
> @.amount,
> @.amount_commission,
> @.tax_percentage,
> @.currency_code_home,
> @.points,
> @.line_id,
> @.comment,
> @.balance,
> @.external_id
> )
> Looking at this query's SP:StmtCompleted event from the profiler we can
> see the query took 375ms to complete and performed 76 reads (and
> apparently zero writes, although the data was definitely inserted). We
> think this is far too long.
> What is strange though is that if we run the exact same statement OUTSIDE
> of the calling procedure in query analyzer, substituting literals for the
> variables, then it apparently completes in just 63ms, although it performs
> the same number of writes:
> INSERT INTO dbo.Account_Transaction(
> invoice_id, transaction_type_id, qty, amount, commission,
> tax_percentage, currency_code, points, line_id, comment,
> balance_before, external_id)
> VALUES
> (6842289, 12, 1, 1, 0, 10, 'AUD', 0, 4, 'test', 0, 0)
> If we now try the same two things on our test database, running on a a
> bog-standard desktop machine, with only 300000 rows in the
> Account_Transaction table, then both queries execute in similar times of
> around 70ms.
> So my question is - what is causing the slowness, and how can we speed it
> up? How do we make the insert operation from within the SP take the same
> amount of time as it takes when run on its own?
> Any help appreciated,
> --
> Mike C
>
>
> CREATE TABLE [dbo].[Account_Transaction] (
> [id] [bigint] IDENTITY (1, 1) NOT NULL ,
> [invoice_id] [bigint] NOT NULL ,
> [transaction_type_id] [int] NOT NULL ,
> [qty] [int] NOT NULL ,
> [amount] [money] NOT NULL ,
> [tax_percentage] [decimal](9, 3) NULL ,
> [commission] [float] NOT NULL ,
> [currency_code] [char] (3) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
> [line_id] [int] NOT NULL ,
> [points] [int] NOT NULL ,
> [comment] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [balance_before] [money] NOT NULL ,
> [balance_after] [money] NULL ,
> [external_id] [bigint] NULL ,
> [msrepl_tran_version] [uniqueidentifier] NOT NULL
> ) ON [PRIMARY]
> GO
> ALTER TABLE [dbo].[Account_Transaction] WITH NOCHECK ADD
> CONSTRAINT [PK_Account_Transaction] PRIMARY KEY CLUSTERED
> (
> [id]
> ) WITH FILLFACTOR = 90 ON [PRIMARY]
> GO
> ALTER TABLE [dbo].[Account_Transaction] WITH NOCHECK ADD
> CONSTRAINT [DF__Account_T__amoun__3118447E] DEFAULT (0) FOR [amount],
> CONSTRAINT [DF__Account_T__point__320C68B7] DEFAULT (0) FOR [points],
> CONSTRAINT [DF__Account_T__msrep__31783731] DEFAULT (newid()) FOR
> [msrepl_tran_version]
> GO
> CREATE INDEX [IX_Account_Transaction] ON
> [dbo].[Account_Transaction]([invoice_id]) WITH FILLFACTOR = 90 ON
> [PRIMARY]
> GO
> ALTER TABLE [dbo].[Account_Transaction] ADD
> CONSTRAINT [FK_Account_Transaction_Account_Invoice]
FOREIGN KEY
> (
> [invoice_id]
> ) REFERENCES [dbo].[Account_Invoice] (
> [id]
> ) ON DELETE CASCADE ON UPDATE CASCADE ,
> CONSTRAINT [FK_Account_Transaction_Line] FOREIGN KEY
> (
> [line_id]
> ) REFERENCES [dbo].[Line] (
> [id]
> ),
> CONSTRAINT [FK_Account_Transaction_Transaction_Type
] FOREIGN KEY
> (
> [transaction_type_id]
> ) REFERENCES [dbo].[Transaction_Type] (
> [id]
> )
> GO|||It sounds like Mike is speaking of single transactional inserts and not bulk
inserts, so dropping / recreating indexes on the table would not be
practical.
"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:%23Unqxm%23HGHA.528@.TK2MSFTNGP12.phx.gbl...
> Mike
> 1) Make sure that your table has no triggers
> 2) Try drop the indexes just prior to INSERTING and re-create them after
>
> Another thing might help that if you do it by using SP which accepted
> parameters try to re-assign these parameters to local variable
>
> CREATE PROC myProc
> @.par INT
> AS
> DECLARE @.lpar INT
>
> SET @.lpar =@.par
> INSERT INTO Table VALUES (@.lpar )
>
>
> "Mike Chamberlain" <none@.hotmail.com> wrote in message
> news:eGXwhg%23HGHA.1180@.TK2MSFTNGP09.phx.gbl...
>|||Consider if the stored procedure is re-compiling each time it is executed.
This could explain the overhead when executing the insert from the procedure
while it still performs the same number of writes as the test insert from
Query Analyzer.
INF: Conditions for Stored Procedure Recompilation
http://support.microsoft.com/defaul...kb;en-us;104445
How to identify the cause of recompilation in an SP:Recompile event
http://support.microsoft.com/defaul...kb;en-us;308737
"Mike Chamberlain" <none@.hotmail.com> wrote in message
news:eGXwhg%23HGHA.1180@.TK2MSFTNGP09.phx.gbl...
> Hi there.
> We're using SQL Server 2000 on a Windows 2000 box with dual hyperthreaded
> Intel CPUs, raided hard disks and 2GB RAM. It should certainly be able to
> handle our currently fairly modest demands. We have all the latest
> security patches. Parallelism is disabled.
> We're currently experiencing unacceptable slowness for inserts to a
> particular table, Account_Transaction (see the DDL at the end of this
> message). As you can see, the main features are a BIGINT auto-increment
> primary key, and three foreign keys. This table currently has 7 million
> rows and another million are inserted each month. We are currently
> unhappy with the length of time it takes to insert into this table as this
> operation is at the heart of our application.
> Here is an example insert, called from within a stored procedure:
> INSERT INTO dbo.Account_Transaction(
> invoice_id, transaction_type_id, qty, amount, commission,
> tax_percentage, currency_code, points, line_id, comment,
> balance_before, external_id)
> VALUES
> (
> @.invoice_id,
> @.transaction_type_id,
> @.qty,
> @.amount,
> @.amount_commission,
> @.tax_percentage,
> @.currency_code_home,
> @.points,
> @.line_id,
> @.comment,
> @.balance,
> @.external_id
> )
> Looking at this query's SP:StmtCompleted event from the profiler we can
> see the query took 375ms to complete and performed 76 reads (and
> apparently zero writes, although the data was definitely inserted). We
> think this is far too long.
> What is strange though is that if we run the exact same statement OUTSIDE
> of the calling procedure in query analyzer, substituting literals for the
> variables, then it apparently completes in just 63ms, although it performs
> the same number of writes:
> INSERT INTO dbo.Account_Transaction(
> invoice_id, transaction_type_id, qty, amount, commission,
> tax_percentage, currency_code, points, line_id, comment,
> balance_before, external_id)
> VALUES
> (6842289, 12, 1, 1, 0, 10, 'AUD', 0, 4, 'test', 0, 0)
> If we now try the same two things on our test database, running on a a
> bog-standard desktop machine, with only 300000 rows in the
> Account_Transaction table, then both queries execute in similar times of
> around 70ms.
> So my question is - what is causing the slowness, and how can we speed it
> up? How do we make the insert operation from within the SP take the same
> amount of time as it takes when run on its own?
> Any help appreciated,
> --
> Mike C
>
>
> CREATE TABLE [dbo].[Account_Transaction] (
> [id] [bigint] IDENTITY (1, 1) NOT NULL ,
> [invoice_id] [bigint] NOT NULL ,
> [transaction_type_id] [int] NOT NULL ,
> [qty] [int] NOT NULL ,
> [amount] [money] NOT NULL ,
> [tax_percentage] [decimal](9, 3) NULL ,
> [commission] [float] NOT NULL ,
> [currency_code] [char] (3) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
> [line_id] [int] NOT NULL ,
> [points] [int] NOT NULL ,
> [comment] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [balance_before] [money] NOT NULL ,
> [balance_after] [money] NULL ,
> [external_id] [bigint] NULL ,
> [msrepl_tran_version] [uniqueidentifier] NOT NULL
> ) ON [PRIMARY]
> GO
> ALTER TABLE [dbo].[Account_Transaction] WITH NOCHECK ADD
> CONSTRAINT [PK_Account_Transaction] PRIMARY KEY CLUSTERED
> (
> [id]
> ) WITH FILLFACTOR = 90 ON [PRIMARY]
> GO
> ALTER TABLE [dbo].[Account_Transaction] WITH NOCHECK ADD
> CONSTRAINT [DF__Account_T__amoun__3118447E] DEFAULT (0) FOR [amount],
> CONSTRAINT [DF__Account_T__point__320C68B7] DEFAULT (0) FOR [points],
> CONSTRAINT [DF__Account_T__msrep__31783731] DEFAULT (newid()) FOR
> [msrepl_tran_version]
> GO
> CREATE INDEX [IX_Account_Transaction] ON
> [dbo].[Account_Transaction]([invoice_id]) WITH FILLFACTOR = 90 ON
> [PRIMARY]
> GO
> ALTER TABLE [dbo].[Account_Transaction] ADD
> CONSTRAINT [FK_Account_Transaction_Account_Invoice]
FOREIGN KEY
> (
> [invoice_id]
> ) REFERENCES [dbo].[Account_Invoice] (
> [id]
> ) ON DELETE CASCADE ON UPDATE CASCADE ,
> CONSTRAINT [FK_Account_Transaction_Line] FOREIGN KEY
> (
> [line_id]
> ) REFERENCES [dbo].[Line] (
> [id]
> ),
> CONSTRAINT [FK_Account_Transaction_Transaction_Type
] FOREIGN KEY
> (
> [transaction_type_id]
> ) REFERENCES [dbo].[Transaction_Type] (
> [id]
> )
> GOsql

Optimal installation on Win 2003

Hi

I'm fairly new to this, so bare with me...

I have to make a new installation of an MS SQL 2000 EE on a Windows 2003 Std. Edt.

HW:
-------
Dual Xeon 2,4 + 1 GB Ecc
1 x 32 MB Adaptec 2100S RAID Controller
2 x 18 GB 10K HD
4 x 18 GB 15K HD
-------

So far I have made following configuration...
-------
2 x 18 GB 10K HD / RAID 1
- C:\OS
- D:\MSSQL program files + System DB's (Master, pubs ect.)

4 x 18 GB 15K HD / RAID 5
- E:\TempDB
- F:\Data + Logs
-------
But I'm not sure that this is the optimal configuration, and I'm willing to start all over :)

So my q's are......
-------
Which RAID configuration would you suggest?
Which partitions on the raids would you suggest?
Which usage would you assign the various partitions?
How do I move the system and temp db's?
-------

Thanx!

Regards,

Taras Bredel dkHi Taras,

I just had our systems guys create a SQL 2000 box on Win 2k3. I have a raid 5 (with 2 HD) on a dual p3 with 1 gig of ram.

Let me just say that I can't remember having so many problems with a SQL box. Granted anyone using Win 2k3 in a production environment should have expected some early adopter problems, I didn't think my problem would be so frustrating.

My problem is that I can't get the SQL box to listen on any ports. By default, SQL server should listen on port 1433. I can plainly see that Network Utility has TCP/IP enabled and the default port is 1433.

I'm this close to rebuilding that box to a win 2k server.
The only thing really stopping me now is debating what is less work - moving the data - or trying to fix the SQL server.|||Hi Lee

Well it could install it on a W2K, but benchmarks shows that the performance gain on W2K3 should be considerably large.

So my advice to you is trouble shoot the W2K3 installation.

//Taras|||Taras,

Yes. That was the main reason that I wanted it on a 2k3 machine. The data is to be served internally on a quasi realtime basis. This is not a real-time system - but I would like as much performance as possible.

Once you get the machine up and running tell me if you had any problems.

Thanks.

Operating System Upgrade

Hi,
We are running SQL Server 7 on NT Server.
I am responsible for an upgrade path which will migrate to Windows 2000 Server and SQL Server 2000.
The upgrade will take place in steps with the operating system done first.
Is there any documentation describing the recommended methodology for performing such an upgrade ?
Are there any known problems to watch out for ?
I know theses are general questions but I would rather be aware of best prctices or potential problems before I start.
Any help gratefully received,
Den.
Have a look at
http://www.sqlteam.com/item.asp?ItemID=9066
http://www.sqlteam.com/item.asp?ItemID=9465
Query plans will change so some SQL may go faster others slower.
Paul
"Den" <anonymous@.discussions.microsoft.com> wrote in message
news:4CB242DE-4818-4E1E-AC3C-21D962AADDDC@.microsoft.com...
> Hi,
> We are running SQL Server 7 on NT Server.
> I am responsible for an upgrade path which will migrate to Windows 2000
Server and SQL Server 2000.
> The upgrade will take place in steps with the operating system done first.
> Is there any documentation describing the recommended methodology for
performing such an upgrade ?
> Are there any known problems to watch out for ?
> I know theses are general questions but I would rather be aware of best
prctices or potential problems before I start.
> Any help gratefully received,
> Den.

Operating System Upgrade

Hi,
We are running SQL Server 7 on NT Server.
I am responsible for an upgrade path which will migrate to Windows 2000 Serv
er and SQL Server 2000.
The upgrade will take place in steps with the operating system done first.
Is there any documentation describing the recommended methodology for perfor
ming such an upgrade ?
Are there any known problems to watch out for ?
I know theses are general questions but I would rather be aware of best prct
ices or potential problems before I start.
Any help gratefully received,
Den.Have a look at
http://www.sqlteam.com/item.asp?ItemID=9066
http://www.sqlteam.com/item.asp?ItemID=9465
Query plans will change so some SQL may go faster others slower.
Paul
"Den" <anonymous@.discussions.microsoft.com> wrote in message
news:4CB242DE-4818-4E1E-AC3C-21D962AADDDC@.microsoft.com...
> Hi,
> We are running SQL Server 7 on NT Server.
> I am responsible for an upgrade path which will migrate to Windows 2000
Server and SQL Server 2000.
> The upgrade will take place in steps with the operating system done first.
> Is there any documentation describing the recommended methodology for
performing such an upgrade ?
> Are there any known problems to watch out for ?
> I know theses are general questions but I would rather be aware of best
prctices or potential problems before I start.
> Any help gratefully received,
> Den.

Operating System Upgrade

Hi
We are running SQL Server 7 on NT Server
I am responsible for an upgrade path which will migrate to Windows 2000 Server and SQL Server 2000
The upgrade will take place in steps with the operating system done first
Is there any documentation describing the recommended methodology for performing such an upgrade
Are there any known problems to watch out for
I know theses are general questions but I would rather be aware of best prctices or potential problems before I start
Any help gratefully received
Den.Have a look at
http://www.sqlteam.com/item.asp?ItemID=9066
http://www.sqlteam.com/item.asp?ItemID=9465
Query plans will change so some SQL may go faster others slower.
Paul
"Den" <anonymous@.discussions.microsoft.com> wrote in message
news:4CB242DE-4818-4E1E-AC3C-21D962AADDDC@.microsoft.com...
> Hi,
> We are running SQL Server 7 on NT Server.
> I am responsible for an upgrade path which will migrate to Windows 2000
Server and SQL Server 2000.
> The upgrade will take place in steps with the operating system done first.
> Is there any documentation describing the recommended methodology for
performing such an upgrade ?
> Are there any known problems to watch out for ?
> I know theses are general questions but I would rather be aware of best
prctices or potential problems before I start.
> Any help gratefully received,
> Den.

Operating system question

Hello
Can I install SQL Server 2000 on Windows 2003 Server Enterprise?
Best Regards
Wojciech Znaniecki
Take a look here:
http://www.microsoft.com/sql/howtobu...netsupport.asp
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
"Wojtek Z" <wojtas_z@.poczta.fm> schrieb im Newsbeitrag
news:d3vqvl$qqf$1@.nemesis.news.tpi.pl...
> Hello
> Can I install SQL Server 2000 on Windows 2003 Server Enterprise?
> --
> Best Regards
> Wojciech Znaniecki
>
|||Hi
Yes, just make sure that you apply SP3a after the installation otherwise SQL
Server will not work on that platform.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Wojtek Z" <wojtas_z@.poczta.fm> wrote in message
news:d3vqvl$qqf$1@.nemesis.news.tpi.pl...
> Hello
> Can I install SQL Server 2000 on Windows 2003 Server Enterprise?
> --
> Best Regards
> Wojciech Znaniecki
>

Operating system question

Hello
Can I install SQL Server 2000 on Windows 2003 Server Enterprise?
--
Best Regards
Wojciech ZnanieckiTake a look here:
http://www.microsoft.com/sql/howtobuy/windowsnetsupport.asp
HTH, Jens Suessmeyer.
--
http://www.sqlserver2005.de
--
"Wojtek Z" <wojtas_z@.poczta.fm> schrieb im Newsbeitrag
news:d3vqvl$qqf$1@.nemesis.news.tpi.pl...
> Hello
> Can I install SQL Server 2000 on Windows 2003 Server Enterprise?
> --
> Best Regards
> Wojciech Znaniecki
>|||Hi
Yes, just make sure that you apply SP3a after the installation otherwise SQL
Server will not work on that platform.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Wojtek Z" <wojtas_z@.poczta.fm> wrote in message
news:d3vqvl$qqf$1@.nemesis.news.tpi.pl...
> Hello
> Can I install SQL Server 2000 on Windows 2003 Server Enterprise?
> --
> Best Regards
> Wojciech Znaniecki
>

Operating system question

Hello
Can I install SQL Server 2000 on Windows 2003 Server Enterprise?
Best Regards
Wojciech ZnanieckiTake a look here:
http://www.microsoft.com/sql/howtob...snetsupport.asp
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
--
"Wojtek Z" <wojtas_z@.poczta.fm> schrieb im Newsbeitrag
news:d3vqvl$qqf$1@.nemesis.news.tpi.pl...
> Hello
> Can I install SQL Server 2000 on Windows 2003 Server Enterprise?
> --
> Best Regards
> Wojciech Znaniecki
>|||Hi
Yes, just make sure that you apply SP3a after the installation otherwise SQL
Server will not work on that platform.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Wojtek Z" <wojtas_z@.poczta.fm> wrote in message
news:d3vqvl$qqf$1@.nemesis.news.tpi.pl...
> Hello
> Can I install SQL Server 2000 on Windows 2003 Server Enterprise?
> --
> Best Regards
> Wojciech Znaniecki
>