Dear Charles,
Thanks for your infor. This happend when users try to login.
We encounter this problems nearly 8 times. Initially we suspect is caused by
the program that not proper releasing the record lock and causing a
threshold. Will try to use the way to solve it when we encounter this again.
FYI, When we trace back the capture file i get such the information.
Case (1) the state no indicate anythings not working well ? Even
LIST.READU, no readcord is being lock ? But realize that some user access
the database thru other
servers
Case (2) is we realize that port user 492 has lock the 12417 of
records causing threshold and causing the database hang ?
Btw what is the purpose of "uvlictool" ?
Below is the information capture
Case (1)
File access State Netnode Owner Collisions Retries
Semaphore # 1 0 0 0 0 0
Semaphore # 2 0 0 0 0 0
Semaphore # 3 0 0 0 0 0
Semaphore # 4 0 0 0 0 0
Semaphore # 5 -16777216 0 106 0 0
.
.
.
Login State Netnode Owner Collisions Retries
Semaphore # 1 0 0 0 170 172
Case (2)
File access State Netnode Owner Collisions Retries
Semaphore # 1 0 0 0 0 0
Semaphore # 2 0 0 0 0 0
Semaphore # 3 0 0 0 0 0
Semaphore # 4 0 0 0 0 0
Semaphore # 5 0 0 0 0 0
...
Login State Netnode Owner Collisions Retries
Semaphore # 1 0 0 0 0 0
Active Group Locks: Record Group
Group Group
Device.... Inode.... Netnode Userno Lmode G-Address. Locks ...RD
...SH ...EX
72613888 69842 0 492 1 IN DE97000 1 0
0 0
72613897 1488 0 492 1 IN 28391000 1 0
0 0
72613897 1488 0 492 1 IN 283F2000 1 0
0 0
72613897 1488 0 492 1 IN 28453000 1 0
0 0
72613897 1488 0 492 1 IN 284B4000 1 0
0 0
72613897 1488 0 492 1 IN 28515000 1 0
0 0
72613897 1488 0 492 1 IN 28576000 1 0
0 0
72613897 1488 0 492 1 IN 285D7000 1 0
0 0
72613897 1488 0 492 1 IN 28638000 1 0
0 0
..
.
.
> -----Original Message-----
> From: Stevenson, Charles [SMTP:[EMAIL PROTECTED]
> Sent: Tuesday, 22 June, 2004 12:07 AM
> To: [EMAIL PROTECTED]
> Cc: Ang Suan Yong
> Subject: RE: [U2] Universe Database Hang (login hang)
>
> > Do anyone having experience on Universe Database hang.
> > ( note that existing user process still able to run the
> > process and access the database only user which using new
> > session log to the database will hang over there ?
> > ) The system file is not full . When i LIST.READU EVERY
> > (using existing
> > session) found that no much record locking / The database
> > daemon is still alive during the situation of database hang
>
> Are you saying that users hang as they try to log in? That is, invoking
> the UV shell hangs the user, but not the database itself, right?
>
> Do "ANALYZE.SHM -s" to list semaphores. Something may have locked the
> login semaphore, which each login process should set briefly, then
> release. Toward the bottom you will see :
>
> Login State Netnode Owner Collisions Retries
> Semaphore # 1 1 0 16 1 859086
> ^
> If State is "1", not "0", that is your problem.
>
>
> The equivalent unix command is "[uvhome dir]/bin/smat -s"
>
> Solution:
>
> As superuser, already at uv command prompt, type "UNLOCK LOGINLOCK
> SEMAPHORE".
> (Look up UNLOCK SEMAPHORE" in User ref manual, the online "HELP UNLOCK"
> is incomplete.)
> If superuser is not already in UV, you won't be able to login, to run
> these commands.
> I don't know the best way to unlock the semaphore in that case. Anyone?
>
>
> Moral:
>
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !! !!
> !! ALWAYS LEAVE A ROOT SESSION AT UV TCL PROMPT. !!
> !! (e.g. in data center, system console) !!
> !! !!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
>
>
> One possible cause:
>
> I had the problem where I tried to pipe the output of uv/bin/uvlictool
> -report_lic to "gerp" instead of "grep":
> $/dbms/uv/bin/uvlictool report_lic | gerp UVCS
> uvlictool apparently sets the login semaphore while it takes its
> snapshot. The subsequent error caused uvlictool to leave it locked.
> My solution: a little script "uvlicr" that does:
>
> /dbms/uv/bin/uvlictool report_lic > /tmp/uvlicr.txt ; cat
> /tmp/uvlicr.txt
>
> Piping that to "gerp" won't cause havoc. Same for script "uvlicc" &
> "uvlictool clean_lic -a".
>
> - cds
>
>
DISCLAIMER:-
<<This email is confidential and intended only for the use of the individual
or entity named above and may contain information that is privileged. If you
are not the intended recipient, you are notified that any dissemination,
distribution or copying of this email is strictly prohibited. If you have
received this email in error, please notify us immediately by return email
or telephone and destroy the original message. Thank you.>>
-------
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/
