Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 General SQL Server Forums
 Data Corruption Issues
 DB Corrupt Problems

Author  Topic 

samana
Starting Member

2 Posts

Posted - 2010-08-17 : 06:22:21
First time DB is corrupted at the client side. We have created blank DB and Data transferred successfully without any errors and tested all the Constraints, Procedures, Views, Functions and Triggers. DBCC CHECKDB does not returned any error messages.

DB was copied at the Client machine and Worked fine for 2 days. Again 3rd day System is hanged during putting entries from our Software. When we checked DBCC CHECKDB command, we have got the following error message.

Server: Msg 8966, Level 16, State 1, Line 1
Could not read and latch page (1:4238) with latch type SH. sysindexes failed.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

But our tables, procedures, triggers and views are working fine. We are using one live database and one test database. Test database is loaded in another machine with different SQL Server, both the SQL servers are connected in the network.

At the client place, they have good system configuration, networking and powerful antivirus facilities. But they are using Pirated version of SQL Server 2000 with SP2 (in Windows 2003 Server – SP2 - Pirated).

We have the clarifications on the following:

1. What is the reason for the frequent Systems tables corruption.
2. Do we have any recovery methods (We have taken backup. But how to recover the current DB)
3. Shall we continue fetching data to the database? (system indexes only corrupted)
4. Is there any possibility for the DB Corrupt?
a) Simultaneous user entries (7 users)
b) Any DML Operations (Any errors in the coding)
c) System slowness or Network slowness

Kindly give your suggestion on the above information and help us to solve this problem.

Regards
Padmapriya

Kristen
Test

22859 Posts

Posted - 2010-08-17 : 06:44:08
"they are using Pirated version of SQL Server 2000 with SP2 "

Its good of you to be honest about that. But I expect, due to site policy here, your post will be unanswered / locked.

Database corruption is usually due to hardware problems; almost never (or maybe even "absolutely never") due to Applications.

SQL 2000 is an old database. SP2 is old too. At the least you need the latest Service Pack (4 I think, or maybe 4a). Either way, tell them to buy a licence.
Go to Top of Page

GilaMonster
Master Smack Fu Yak Hacker

4507 Posts

Posted - 2010-08-17 : 06:48:25
Corruption is typically an IO subsystem problem. Frequent, reoccuring corruption is a good sign that there's something wrong with the IO subsystem. Disks, SAN, RAID, Antivirus filter driver, firmware, drivers, could be anything in that stack.

p.s. SQL 2000 with SP2 is vulnerable to a whole collection of exploits (including Slammer) and has nasty bugs. Upgrade to SP4 ASAP, and suggest politely to the company that they will be in a whole lot of trouble when Microsoft does a software audit on them.

That corruption message you posted is not repairable. Restore from backup is your only option here.
It's not system indexes that are corrupt, it's the sysindexes table - the table that stored information on every single index in the database. If that's corrupt the DB is not usable.

--
Gail Shaw
SQL Server MVP
Go to Top of Page

GilaMonster
Master Smack Fu Yak Hacker

4507 Posts

Posted - 2010-08-17 : 06:49:35
quote:
Originally posted by Kristen

"they are using Pirated version of SQL Server 2000 with SP2 "

Its good of you to be honest about that. But I expect, due to site policy here, your post will be unanswered / locked.


It's his client pirating software, not him (at least how I read it). I might drop a link to this post to some licensing people at MS however...

--
Gail Shaw
SQL Server MVP
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2010-08-17 : 06:51:45
"It's his client pirating software, not him (at least how I read it)"

Yes, that's how I read it too. I assume the same SQLTeam site rules (here) apply though - can't condone it ...
Go to Top of Page
   

- Advertisement -