vdra_ltd@uhura.cc.rochester.edu (Valerie Drake) (06/06/91)
In comp.sys.novell you write: >We have recently installed a Dataease/Act1000 Database on a Novell 2.15c >file server. Every few days the server will slow to a crawl, eventually gives >an "unknown error reading drive f:". The server then hangs; the server keyboard >locks up and it is impossible to gracefully down the server. No error or abend >messages appear on the console. Slist is unable to locate the server at this >point. This server is on a IBM Token Ring network. There is one other server, >on the network; a Novell 2.0a, whichs does not seem to be affected. No viruses >were found using McAfee's ScanV77. Almost all of the Hot Fix areas are left. >Could this be caused by execeding the max open files limit? Could it be problem >with one of the token ring cards? >HELP PLEASE!!! >Thanks very much for any help in advance! Well you are close. Here is the problem. Novell 2.15c allocates memory for record locks within the same area as the open files memory pool (I believe it is Group 1 or 2 can't remember without my manual in front of me). Anyway, what happens is this: Each record locked (probably by a report which locks records individually) takes up memory from this pool. This memory is not released by NOVELL (even if the locks are released by DATAEASE) until the report completes and the file closes. If all of the memory pool is "eaten" in this manner, there is no more memory available to open files, and the server goes CLUNK and crashes. Sometimes it is possible to save the net by going to the console and disconnecting the user running the large report. (of course this crashes Dataease and you have to reorganize, but you are going to do that anyways :->). On to the solution: 1) Increase the maximum number of open files (done by running netgen, and changing the parameter, then saving this change, you will need to bring down the server to fix this). What this does is increase the maximum memory area that is allocated for open files/locks. Increase it to the maximum number allowed (999 I believe). If you don't have enough memory on the server to accomdate this get some more (you should have it for cache anyways.). This is at best a temporary fix. As your files grow you may find that the problem comes back. I'd bet your 2.0a server is either not running Datease, or has a larger number of max open files. 2) Change to Netware 386 for your server. Netware 386 dynamically allocates record locks, and will re-use released locks if it needs the memory. You should not have this problem on a netware 386 (3.11) server. 3) Change the report to LOCK ALL FILES. or LOCK FILE XXX EXCLUSIVE. or DO NOT LOCK RECORDS. All of these will prevent Dataease from generating a record lock for each record selected. You will need to identify the report(s) causing the lockup, and place this at the beginning of the DQL query. Remember that doing this has the corresponding effect on record locking ie if you lock exclusive or lock all files, no one else may access them while running that report, or if you make no locks, then the data may change while the report is running. It needs to be judged on a case by case basis. How do I know this you ask. Well I figured all this out, then called Dataease and told them. I was a Beta tester for the original Dataease LAN Version and am a Dataease Certified Consultant and a soon to be Novell CNE. I am manager of Consulting Services at Azatar MicroSystems, a Rochester-Based MicroConsulting company which specializes in networks and in Dataease Databases. My rates are $75/hour and this message took 15 minutes to type in :-> Just joking, this one is gratis. I KNOW how frustrating that problem is having found it for the first time myself. Other than this (implementation specific) problem Datease performs pretty well in a network environment and is reasonable robust in the 4.24 version. It does have its quirks, but what database don't? If you wish to contact me for consulting, or further advice call me during regular business hours at (716)385-9780. After June 21st (716)223-2300. Ask for Lee Drake. (even though the from is my wife's name - it's her account at the UOFR.) Good Luck, Lee Drake. -- | | +--+ +--+ o | Carpe Diem, Seize the DAY! | ////// | |\/ .\/. \/| o| vdra_ltd@uhura.cc.rochester.edu | /_ _\ | | )) /\ (( | o | Val & Lee Drake (The Fish Faces) +--,,,,----U----,,,,--+ |/\+--+ +--+/\| | | University of Rochester