SQL Error 17803 Insufficient Memory Issue 1

[benaround]

We have installed MS SQL 2000, yes no service packs due to a vendor requirement, and are having a SQL 17803 Insufficient Memory available problem.

I have looked around and found that having Auto Shrink on, may cause / lead to this type of problem but seem to point to SQL 7 versus SQL 2000.

I have installed SQL 2000 with all the SQL defaults, logging, stats, auto shrink, etc. and was wondering if other SQL areas have this set on or off?

We do alot of SQL processing during the day with 80 to 100 users banging away at a medical app called EzCap with 9 DB's across 3 - raid 5 servers with 4 Gig memory. FYI, this was just upgraded from SQL 7.0, over this past weekend, with numerous problems but seems to be working OK if not for this problem.

Thanks ahead of time for your help.

 

[SQLBill]

Do you have the data files and log files set to autogrow?

If not, you need to do so.

If so, then how much do you allow it to grow by? You may need to increase the amount.

BTW- I would reconsider your vendor. There is a VERY huge security issue with SQL Server 2000 unless SP3a is applied. If your vendor is telling you to not apply the service packs/patches, I wonder what other security problems they are creating. Do they have a secure password for the SA account? Maybe they want to be able to hack your databases (hopefully not).

-SQLBill

 

[benaround]

We have a 8777Meg DB with autogrow set @ 10 percent. Sorry, but I'm not sure what the auto grow has to do with this type of error; please explain

FYI, regarding the vendor, I had to FTP a file, 24 Meg, last night and the ftp took almost 2 hours to download, it speaks loads of what what this vendor is like; not good. If it was not a mission / business critical type situation, I would of canceled out of the download, and said a few words to the vendor.

Regarding the security issues, the vendor has just, within the last 3 months, certified their product for SQL 2000. I'm sure it will take 2 years till they certify their product for SP3a. I'll check out the Microsoft site for more info on security issues with SQL 2k, thanks.

Many healthcare vendors seem to take advantage of quick / bad programming and design by falling into software holes that that are very difficult to re-program out. THis one is no exception to the rule.

 

[SQLBill]

Explanation....

You have a 10GB hard drive. Your database is 1 GB in size and autogrow is set for 500 MB. You insert 200 MB of data. The database will grow 500 MB and now you have 1.5 GB of data and .5 GB free space.

Now you add 2 GB of data, the database can take .5 right away (fills free space), expands 500 MB, fills that up (1 GB to go), expands 500 MB, fills that up (.5 GB to go), expands 500 MB, fills that up and all is done. BUT, if it can't expand as fast as the data is coming in, then it can return an error that there's not enough memory.

The SLAMMER worm is one that takes advantage of pre-SP3a versions. If you CAN'T use SP3a, make sure you give the SA account a strong password. Then change the ports that SQL Server uses (TCP 1433 and UDP 1434 are the defaults), I always change the TCP port. Or have your firewall block access to that port to all but authorized computers.

-SQLBill