[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::dbms

Title:	VAX DBMS
Notice:	THIS NOTESFILE IS NOT A FORMAL SUPPORT CHANNEL
Moderator:	SCARY::CHARLAND

Created:	Thu Feb 20 1986
Last Modified:	Tue Jun 03 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2642
Total number of notes:	11044

2597.0. "cpu loop on attach? ?v 5.1-11" by M5::PSOEHL (Go see THE RELIC!!!) Mon Feb 17 1997 20:06

Customer is noticing that 1 out of 10 of his processes that attempt to bind to his database go into a cpu loop and
don't come out. When this happens they have to kill the process.  Normally, an attach happens within 10 seconds. 
This has just started happening recently. So, what has changed?

They've added more users (350 to 450) and moved their database from ra72 drives to rz29. 

They're on a VAX, running vms 6.1 and DBMS v5.1-11. 

I've asked him to keep an eye on the PCs that the process is looping through when this happens and we can get a
better feel for 

I just left a message with him concerning his assumption that the process is not getting successfully attached to
the db.  What he is doing in the code is putting display (it's COBOL) statements in the code and it never reaches
the ones after the bind statement.  I believe that the bind is not an executable statement.  I mentioned that he
should do a dBO/SHOW STAT and try to see if the process shows up.  

This looks to  me  like note 2343, which I didn't see any resolution for. That note was for v5.1-11.

Any ideas?


TIA

T.R	Title	User	Personal Name	Date	Lines
2597.1	A few more things to look at	BOUVS::OAKEY	I'll take Clueless for $500, Alex	`Mon Feb 17 1997 20:21`	19
	~~ <<< Note 2597.0 by M5::PSOEHL "Go see THE RELIC!!!" >>> ~~ -< cpu loop on attach? ?v 5.1-11 >- ~~I've asked him to keep an eye on the PCs that the process is looping ~~through when this happens and we can get a better feel for Not just the PCs but is it really looping or sitting in something like LEF? ~~reaches the ones after the bind statement. I believe that the bind is not ~~an executable statement. I mentioned that he should do a dBO/SHOW STAT and ~~try to see if the process shows up. Rather than looking at stats, I'd look in the monitor log file to see if there is a request from the user to bind. If there is a request from the user, what was the disposition of the request? When this happens are other users already bound? Are many other users attempting to bind at the same time?
2597.2		NOVA::R_ANDERSON	Oracle Corporation (603) 881-1935	`Tue Feb 18 1997 06:23`	7
	>Rather than looking at stats, I'd look in the monitor log file to see if >there is a request from the user to bind. If there is a request from the >user, what was the disposition of the request? Of course, with DBMS v7.0, you CAN do this with SHOW STATS :-) Rick
2597.3	more info	M5::LWILCOX	Chocolate in January!!	`Fri Feb 21 1997 13:33`	26
	A little more info from the customer: He has discovered two things: \| \| 1) if he staggers the 3 jobs that seem to get hung up, the problem happens \| much less frequently. \| \| 2) if he deassigns DBM$BIND_BUFFERS for these 3 processes the problem \| appears to go away. He has run fine without this logical defined for 2 \| days. The default # buffers is 20, he defines DBM$BIND_BUFFERS 600. \| \| As an aside, he told me they went from 250-450 # users. \| \| He states that they do get the "received user attach request from" and \| the "sending normal user attach reply to" messages in the monitor log file and that it is in the DBQ$INTERPRET routine when it gets hung up. \| The quotas for the jobs have not changed and they are" Working set def 1000 working set extent 77,000 working set 77,000 page fiel quota 300,000