希望对你有帮助。
(2)setuid bit needs setting on the oracle executable
(Unix only). The symptom for this (at least, in my case) was that SQL*Plus on the server gave an ORA-3113 error when started by any userid other than oracle. The database remained up. The oracle executable in the $ORACLE_HOME/bin directory should have the permissions:
-rwsr-sr-x 1 oracle dba 34049236 Oct 11 17:17 oracle
The important features are the ownership of the executable (by oracle) and the setting of the setuid bit (the first s in the permissions string.) This allows the shadow processes to execute as if they were being executed by the oracle userid and therefore allows them to read and write to the database files, which are normally protected with write access granted to oracle only, and sometimes with read access restricted as well. The setting of the setgid bit (the second s ) is not important. If the permissions are wrong, they can be corrected with the command:
chmod 7755 $ORACLE_HOME/bin/oracle
Relinking the oracle executable (see below) will also set the permissions correctly. In fact, it is probable that in many cases changing the permissions was all that was required, rather than a full relink. A possible cause of this problem is using tar or cp or some other unix file-copying utility to move or clone the Oracle installation. These tools will not preserve the setuid permissions on executables unless run as root. (Thanks to Paul Ingram for his insights into this issue.)
(Oracle 8.1.7.0.0 on Solaris) Oracle executables need relinking
There are three ways of doing this:
There's an option on the Oracle Installer to relink the executables.
I didn't use this method as I didn't have the installation CDROM to hand. Enter the following Unix commands: cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk install
This relinked about a dozen executables, including $ORACLE_HOME/bin/oracle, and solved the problem. (Interestingly, the sqlplus executable was not relinked.)
Enter the following Unix commands: cd $ORACLE_HOME/bin
./relink all
Alternatively, given that it would seem necessary to only relink the oracle executable, ./relink oracle should be sufficient. ./relink without any parameters gives a list of possible targets for relinking. Before embarking on a relinking exercise, it may first be worth checking whether the real cause of the problem is simply incorrect file permissions (see above).
(Oracle 8.1.7.0.0 on Solaris)
(2)setuid bit needs setting on the oracle executable
(Unix only). The symptom for this (at least, in my case) was that SQL*Plus on the server gave an ORA-3113 error when started by any userid other than oracle. The database remained up. The oracle executable in the $ORACLE_HOME/bin directory should have the permissions:
-rwsr-sr-x 1 oracle dba 34049236 Oct 11 17:17 oracle
The important features are the ownership of the executable (by oracle) and the setting of the setuid bit (the first s in the permissions string.) This allows the shadow processes to execute as if they were being executed by the oracle userid and therefore allows them to read and write to the database files, which are normally protected with write access granted to oracle only, and sometimes with read access restricted as well. The setting of the setgid bit (the second s ) is not important. If the permissions are wrong, they can be corrected with the command:
chmod 7755 $ORACLE_HOME/bin/oracle
Relinking the oracle executable (see below) will also set the permissions correctly. In fact, it is probable that in many cases changing the permissions was all that was required, rather than a full relink. A possible cause of this problem is using tar or cp or some other unix file-copying utility to move or clone the Oracle installation. These tools will not preserve the setuid permissions on executables unless run as root. (Thanks to Paul Ingram for his insights into this issue.)
(Oracle 8.1.7.0.0 on Solaris) Oracle executables need relinking
There are three ways of doing this:
There's an option on the Oracle Installer to relink the executables.
I didn't use this method as I didn't have the installation CDROM to hand. Enter the following Unix commands: cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk install
This relinked about a dozen executables, including $ORACLE_HOME/bin/oracle, and solved the problem. (Interestingly, the sqlplus executable was not relinked.)
Enter the following Unix commands: cd $ORACLE_HOME/bin
./relink all
Alternatively, given that it would seem necessary to only relink the oracle executable, ./relink oracle should be sufficient. ./relink without any parameters gives a list of possible targets for relinking. Before embarking on a relinking exercise, it may first be worth checking whether the real cause of the problem is simply incorrect file permissions (see above).
(Oracle 8.1.7.0.0 on Solaris)
错误的原因很多。在oracle开发者提到这个词的时候,总以为是网络故障,但是据报告,任何造成后台进程crash的事情都是出现这个错误的原因。该信息或许和其他的错误信息一同出现。如果被损坏的后台进程是oracle的关键进程(PMON, SMON, DBWR etc.),你会得到“oracle不可用”的错误信息。查看你的日志或者查看任何跟踪文件可以帮助你对问题进行诊断。下面是一些造成该错误的原因总结:
(1)Invalid value for processes parameter in init.ora when starting database
当然,要解决它,就是把那些参数值调整为有效范围内的值。
(2)setuid bit needs setting on the oracle executable(Unix only).
The oracle executable in the $ORACLE_HOME/bin directory should have the permissions:
-rwsr-sr-x 1 oracle dba
(3)shared_pool_size too small.
你可以把它设置在200M以上。
(4)timed_statistics=true.
你可以把它设置为false。
(5)An insert into a table which grew into an additional extent allocated in a datafile which was over 2Gb in size.
这是在你的操作系统文件不允许超过2G的时候才会发生的,而且如果发生了错误,数据库就完蛋了。
(6)Create table as select .... where there was an invalid procedure or function called from a trigger defined on the table we were selecting from.
那就是把你所有的过程、函数和包全部编译一遍。
(7)Make use of Oracle Support / Metalink
寻求oracle技术支持吧!
把/proc/sys/kernel/shmmax增大
如512M,则shmmax=512*0.5*1024*1024=268435456
SHMMAX
SHMMIN
SHMMNI
SHMSEG
SEMMNI
maxdsiz(如果有的话)
max_thread_proc名字 描述n 合理取值
SHMMAX 最大共享内存段尺寸(字节) 512 kB + 8192 * 缓冲区数 + 额外 ... 无穷大
SHMMIN 最小共享内存段尺寸(字节) 1 (最多大约是 256 kB)
SHMSEG 每进程最大共享内存段数量 只需要 1 个段,不过缺省比这高得多.
SHMMNI 系统范围最大共享内存段数量 类似 SHMSEG + 用于其他应用的空间
SEMMNI 信号灯标识符的最小数量(也就是说,套) >= ceil(max_connections % 16)
SEMMNS 系统范围的最大信号灯数量 ceil(max_connections / 16) * 17 + 用于其他应用的空间
SEMMSL 每套信号灯最小信号灯数量 >= 17
SEMMAP 信号灯映射里的记录数量 参阅文本
SEMVMX 信号灯的最大值 >= 255 (缺省通常是32767,除非被要求,否则不要修改) swap记得要调为内存的2倍
你们说的这个“系统的核心参数”是在哪里设定?
kernel.shmmax=268435456 ,重起机器
或 echo 268435456 > /proc/sys/kernel/shmmax
或/sbin/sysctl -w kernel.shmmax=268435456
都可以