SQL Server 2000 - Win2003 SP1: Incompatible???

[SQLBill]

SQL Server 2000 SP3a
We use a vendor created database. We were running it on a Windows 2000 box with the latest service packs and everything was running fine. Saturday, we migrated to a Windows Server 2003 SP1 system as our Win2000 box was really old. Our database immediately had problems. Our initial thought was that during the migration it became corrupted. So we used the vendor software to create a new database. Everything worked well for one day. Now we are seeing problems again. Our analysts can see and query all the data via the vendor's GUI, but my Query Analyzer queries and Enterprise Manager jobs all fail. If the query has a join, we see these two errors:

Executed as user: dbo. I/O error (bad page ID) detected during read at offset 0x0000001ef10000 in file 'N:\Program Files\ISS\RealSecure SiteProtector\Site Database\Data\Default_RSDB\RealSecureDB.mdf'. [SQLSTATE HY000] (Error 823). The step failed.

Executed as user: dbo. Could not continue scan with NOLOCK due to data movement. [SQLSTATE 42000] (Error 601). The step failed.

We don't see both at the same time, and the first error message is the one we commonly see. With the second error, we get that even if we don't use WITH (NOLOCK).

Has anyone seen these errors? Has anyone had problems with SQL2000 and Windows 2003 SP1?

-SQLBill


Posting advice: FAQ481-4875

 

[JayKusch]

Have ya run a DBCC CheckDB on the DB yet?

Sound like you may be restoring the DB to a bad disc, spindle or block.

Thanks

J. Kusch

 

[gmmastros]

Take a look at this site. It seems to be on target, but it's hard to tell. It claims to apply to SQL 2000 Service Pack 3. Hope it helps.

http://support.microsoft.com/default.aspx?kbid=826433

-George

Strong and bitter words indicate a weak cause. - Fortune cookie wisdom

 

[SQLBill]

We've run DBCC CHECKDB and have consistency errors in some tables. We've also tried DBCC CHECKDB with the REPAIR_REBUILD option. But the problems stayed.

We are now investigating that it might be a SAN issue. Our SAN was created under Windows 2000. When we migrated, only our server changed to Win2003. So there might be a NTFS conflict since the SAN drives were formatted and built under Win2K not Win2K3.

-SQLBill

Posting advice: FAQ481-4875

 

[SQLBill]

We copied the .mdf and .ldf file to a computer running Win2k3 for everything and are going to see if we still have the same problem.

I'll keep this updated.

-SQLBill

Posting advice: FAQ481-4875

 

[SQLBill]

We restored the database to a Windows 2003 drive on a 2003 server and it still doesn't work.

All the information I find says I need to upgrade to SQL Server SP4 when using Windows 2003. Unfortunately, the vendor doesn't support SQL Server SP4.

Still accepting any other suggestions.

-SQLBill

Posting advice: FAQ481-4875

 

[SQLBill]

Solved it.

We ran DBCC CHECKDB ('dbname', repair_allow_data_loss), then we reindexed all the tables with errors (DBCC DBREINDEX ('tablename').

Everything works.

What caused the problem? We aren't sure, but we believe it's because we had two servers connected to the same drives on the same SAN. We were hoping to move Backup Exec off the SQL Server server onto it's own server and still be able to copy the files from the SAN to tape. But to do that, both servers have to be able to connect to the SAN and use the drives at the same time. It looks like that's not an option and we will have to put both SQL Server and Backup Exec on the same server.

-SQLBill

Posting advice: FAQ481-4875

 

[SQLBill]

Solved it - NOT.

The problem is back again. We even removed Win2k3 SP1. But the vendor says: We do not support Win2k3 SP1 even if it is removed. You must rebuild your system. (Then why did they not tell us this when we told them we were migrating to Win2k3 SP1? - Gotta love vendors).

-SQLBill

Posting advice: FAQ481-4875

 

[Jamfool]

Probably wont make you feel a lot better but Ive just looked round and we have two working servers
8.00.760 (2000 SP3/SP3a) on win2k3 sp1
with backupexec in its own instance.

There not using a SAN tho, as they are dev boxes.

 

[SQLBill]

Our problem isn't with Backup Exec. We have another vendor product that creates a SQL Server database. The vendor says they don't support their product on a Windows 2003 SP1 server. They say it's not even supported if we uninstall SP1.

It originally looked like the problem was caused by trying to run Backup Exec from one server while the vendors product was on a second server and both using the SAN. But it turned out that wasn't the problem.

The vendor says we need to completely rebuild the server without Windows 2003 SP1 or we can expect more problems. Our issue right now is why didn't the vendor tell us this to begin with when we described what we were going to do? But that's not an issue for here.

Microsoft seems to imply that SP4 solves the errors we are seeing, so we are going to attempt to apply that before rebuilding from the beginning. However, the vendor says...doesn't matter, the server still had SP1 on it and we don't support it - it's incompatible. So we may have to end up just rebuilding.

-SQLBill

Posting advice: FAQ481-4875