bg0l+@andrew.cmu.edu (Bruce E. Golightly) (05/16/89)
We're trying to get a STAR data base going on a 6000 series VAX, and having real problems. Lock management is driving us crazy. STAR doen't allow the use of SET commands to modify lock modes or locking, and something is clearly not working right. We are ending up with a one user version of the data base. Everything is locking, with the result that we have users crashing out constantly. We have even lost forms and frame definitions because of locking problems. Has anyone else seen anything like this? We are not sure exactly where the problem is coming from. The VAX 6330 is running under VMS 5.1, which apparently has some problems too, so we're not sure if we're looking at an Ingres or VMS problem. Problem number 2 - system catalogs within STAR. SYSMOD doesn't touch the STAR specific catalogs. We can get it to modify the system catalogs that are "normal" with in the STAR data base area, but cannot get the others modified. Any suggestions?
robf@squid.rtech.com (Robert Fair) (05/17/89)
[Problem running Star on VMS 5.1] INGRES has only just been certified to run on VMS 5, including 5.1 - make sure you have the most up-to-date version of INGRES. [Problem SYSMODing STAR-specific system catalogs] This is a funny in 5.0 - the Star catalogs are created in the coordinator database already modified, and shouldn't need changing unless you have a lot of activity in adding/deleting machine nodes or links. If you do need to re-modify the STAR catalogs (iinode, iilink etc) go into the coordinator database as a user with privilege to access the system catalogs (the INGRES user is a good idea, or the DBA with the -u flag), specify the +U flag to allow system catalogs to be updated, check the table structures with the HELP command, and then simply re-MODIFY them. Notes: 1) This procedure is NOT generally recommended or supported, since updating the system catalogs can be dangerous if you make a typo. 2) Changing the structure/keys for any system catalogs from the default values is strongly NOT recommended, and may have unpleasant results. In INGRES 6.2 the SYSMOD command seems to handle STAR databases directly, and optimizes all the STAR catalogs very nicely! (At least it did when I tested it...) Robert Fair RTI Tech Support
bg0l+@andrew.cmu.edu (Bruce E. Golightly) (05/18/89)
We tried a couple of things that seem to have helped a little. Frankly, what we've done is cheating and may be risky. I got into the STAR data base as if it were a regular data base. This can be done by tacking II onto the front of the data base name. I then manually modified the STAR specific catalogs to their normal structures. This is the sort of action normally taken by SYSMOD. This has resolved some of our problems for the time being. We can, at this point, have several developers working at the same time with FEWER locking problems. A test allowed us to have 4 out of 5 developers successfully working on VIFRED forms concurrently. We're extremely worried about the underlying problem, though. We plan to perform some additional experiments to see if there are other things we can do to eliminate or further reduce the locking problems. Our concern is for the future. What happens when we're got N users trying to retrieve/update data table in this STAR data base? Tolerating locking problems during the development phase is quite different than trying to live with them in production. Some the the planned tables for this application are going to be quite large, and will see heavy concurrent usage in both retrieve and update modes. I'll pass along further developments as they occur. Bruce