SUMMARY: Semaphore Error

Well, I only got one reply.  Thanks to Eric Paul for suggesting that I raise the 
semmni from 100 to 256.  That didn't do the trick, I'm afraid, but I've gotten 
much further along this time.  Now, I was able to import the tablespace, but a 
separate process that builds indices on the tables in a different tablespace is 
doing the same thing.

I've built a new SID and have been playing with the numbers.  I am hoping that I 
have something bad someplace that is hidden and that a new instance will make it 
work properly.  If this fails, I may have another post.

Thanks to all,
-Sal


------------- Begin Forwarded Message -------------

Date: Thu, 14 Apr 2005 15:21:56 -0400 (EDT)
From: Sal Serafino <serafino@cshl.edu>
Subject: Semaphore Error
To: sunmanagers@sunmanagers.org
Mime-Version: 1.0
Content-MD5: azQ73iTWcCzQjD3OE11x/w==

Hi All-

I have a situation where I am transporting an Oracle (9.0.1) tablespace between 
two identically outfitted and configured 450's running Solaris 8.  My script 
sets up the transaction to use a huge rollback segment in order to offline drop 
the datafile and then to drop the tablespace including contents.  Oracle will 
drop all objects from the database, but then hangs at the end.  A trace of the 
processes spawned shows:

5944:   semtimedop(2293762, 0xFFFFFFFF7FFF8FEC, 1, 0xFFFFFFFF7FFF8FD8) Err#11 
EAGAIN
5944:   semtimedop(2293762, 0xFFFFFFFF7FFF8FEC, 1, 0xFFFFFFFF7FFF8FD8) 
(sleeping...)
5944:   semtimedop(2293762, 0xFFFFFFFF7FFF8FEC, 1, 0xFFFFFFFF7FFF8FD8) Err#11 
EAGAIN
5944:   semtimedop(2293762, 0xFFFFFFFF7FFF8FEC, 1, 0xFFFFFFFF7FFF8FD8) 
(sleeping...)
5944:   semtimedop(2293762, 0xFFFFFFFF7FFF8FEC, 1, 0xFFFFFFFF7FFF8FD8) Err#11 
EAGAIN
5944:   semtimedop(2293762, 0xFFFFFFFF7FFF8FEC, 1, 0xFFFFFFFF7FFF8FD8) 
(sleeping...)

I had to kill it to make it stop.  I actually did get a "Tablespace Dropped." 
message on the Oracle side, and there are no objects owned by this user and no 
references to the tablespace anywhere.  BUT... the tablespace still exists in 
dba_tablespaces and the datafile still exists in dba_data_files, so any attempt 
to import the transported tablespace afterwards dies. 

According to semop(2), The semtimedop() function will fail if:

     EAGAIN
           The timeout expired  before  the  requested  operation
           could be completed.

     The semtimedop() function will fail if one of the  following
     is detected:

     EFAULT
           The timeout argument points to an illegal address.

     EINVAL
           The timeout argument specified  a  tv_sec  or  tv_nsec
           value  less than 0, or a tv_nsec value greater than or
           equal to 1000 million.

There are errors other than EAGAIN.  My /etc/system file looks good:

set msgsys:msginfo_msgmax=8192
set msgsys:msginfo_msgmnb=16384
set msgsys:msginfo_msgmni=1700
set msgsys:msginfo_msgtql=512
set semsys:seminfo_semmns=2048
set semsys:seminfo_semmnu=2048
set semsys:seminfo_semmsl=2048
set semsys:seminfo_semmni=100
set semsys:seminfo_semume=256
set shmsys:shminfo_shmmax=2147483647
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=100
set shmsys:shminfo_shmseg=10
set maxusers=256
set nproc=4096
set pt_cnt=256
set rlim_fd_cur=2048
set rlim_fd_max=8192


Ideas?  Greatly appreciated,
-Sal

------------- End Forwarded Message -------------
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers