在本文中，我们将给您介绍关于性能测试过程中oracle数据库报ORA-27301ORA-27302错的详细内容，并且为您解答oracle性能测试报告的相关问题，此外，我们还将为您提供关于Docker-
在本文中，我们将给您介绍关于性能测试过程中oracle数据库报ORA-27301 ORA-27302错的详细内容，并且为您解答oracle 性能测试报告的相关问题，此外，我们还将为您提供关于Docker-Oracle和物理机Oracle数据库性能测试、Eclipse连接Oracle数据库的ORA-00604 ORA-12705错误、HP-UNIX 平台修改 Oracle processes 参数报错：ORA-27154、ORA-27300、ORA-27301、ORA-27302、HP-UNIX平台修改Oracle processes参数报错：ORA-27154、ORA-27300、ORA-27301、ORA-27302的知识。
本文目录一览：- 性能测试过程中oracle数据库报ORA-27301 ORA-27302错（oracle 性能测试报告）
- Docker-Oracle和物理机Oracle数据库性能测试
- Eclipse连接Oracle数据库的ORA-00604 ORA-12705错误
- HP-UNIX 平台修改 Oracle processes 参数报错：ORA-27154、ORA-27300、ORA-27301、ORA-27302
- HP-UNIX平台修改Oracle processes参数报错：ORA-27154、ORA-27300、ORA-27301、ORA-27302
性能测试过程中oracle数据库报ORA-27301 ORA-27302错（oracle 性能测试报告）
最近在性能测试过程中发现，发现虚拟用户数上不去，加载到一定的数量应用端就报错，提示连接数据库出错。在测试的过程中查看web容器的线程池 数据源的连接池 都还有空闲，同时查看oracle的v$session视图 发现session数到了一定数量就上不去了。查看数据库参数 process 设置的是1000 ，再查看oracle 的警告日志发现报下面的错误：
ORA-27302: failure occurred at: skgpspawn3
Docker-Oracle和物理机Oracle数据库性能测试
@H_301_0@Docker性能测试
测试环境：
操作系统：CentOS7、openstack nova-docker启动的centos7、openstack环境启动的centos7虚拟机
cpu：Intel(R) Xeon(R) cpu E5-2690 v3 @ 2.60GHz * 2
内存：Micron 2133MHz 16G * 8
网卡：Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection
关键字：Linpack、netperf、iometer
docker与虚拟机计算效率比较
在测试中是通过运算Linpack程序来获得计算能力数据的。结果如下图所示：
图中从左往右分别是物理机、docker和虚拟机的计算能力数据。可见docker相对于物理机其计算能力几乎没有损耗，而虚拟机对比物理机则有着非常明显的损耗。虚拟机的计算能力损耗在50%左右。
为什么会有这么大的性能损耗呢？一方面是因为虚拟机增加了一层虚拟硬件层，运行在虚拟机上的应用程序在进行数值计算时是运行在Hypervisor虚拟的cpu上的；另外一方面是由于计算程序本身的特性导致的差异。虚拟机虚拟的cpu架构不同于实际cpu架构，数值计算程序一般针对特定的cpu架构有一定的优化措施，虚拟化使这些措施作废，甚至起到反效果。比如对于本次实验的平台，实际的cpu架构是2块物理cpu，每块cpu拥有16个核，共32个核，采用的是NUMA架构；而虚拟机则将cpu虚拟化成一块拥有32个核的cpu。这就导致了计算程序在进行计算时无法根据实际的cpu架构进行优化，大大减低了计算效率。
docker与虚拟机内存访问效率比较
内存访问效率的比较相对比较复杂一点，主要是内存访问有多种场景：
（1）大批量的，连续地址块的内存数据读写。这种测试环境下得到的性能数据是内存带宽，性能瓶颈主要在内存芯片的性能上；
（2）随机内存访问性能。这种测试环境下的性能数据主要与内存带宽、cache的命中率和虚拟地址与物理地址转换的效率等因素有关。
以下将主要针对这两种内存访问场景进行分析。在分析之前我们先概要说明一下docker和虚拟机的内存访问模型差异。下图是docker与虚拟机内存访问模型：
可见在应用程序内存访问上，虚拟机的应用程序要进行2次的虚拟内存到物理内存的映射，读写内存的代价比docker的应用程序高。
下图是场景（1）的测试数据，即内存带宽数据。左图是程序运行在一块cpu（即8核）上的数据，右图是程序运行在2块cpu（即16核）上的数据。单位均为GB/s。
从图中数据可以看出，在内存带宽性能上docker与虚拟机的性能差异并不大。这是因为在内存带宽测试中，读写的内存地址是连续的，大批量的，内核对这种操作会进行优化（数据预存取）。因此虚拟内存到物理内存的映射次数比较少，性能瓶颈主要在物理内存的读写速度上，因此这种情况docker和虚拟机的测试性能差别不大;
内存带宽测试中docker与虚拟机内存访问性能差异不大的原因是由于内存带宽测试中需要进行虚拟地址到物理地址的映射次数比较少。根据这个假设，我们推测，当进行随机内存访问测试时这两者的性能差距将会变大，因为随机内存访问测试中需要进行虚拟内存地址到物理内存地址的映射次数将会变多。结果如下图所示。
左图是程序运行在一个cpu上的数据，右图是程序运行在2块cpu上的数据。从左图可以看出，确实如我们所预测的，在随机内存访问性能上容器与虚拟机的性能差距变得比较明显，容器的内存访问性能明显比虚拟机优秀；但出乎我们意料的是在2块cpu上运行测试程序时容器与虚拟机的随机内存访问性能的差距却又变的不明显。
针对这个现象，IBM的论文给出了一个合理解释。这是因为当有2块cpu同时对内存进行访问时，内存读写的控制将会变得比较复杂，因为两块cpu可能同时读写同一个地址的数据，需要对内存数据进行一些同步操作，从而导致内存读写性能的损耗。这种损耗即使对于物理机也是存在的，可以看出右图的内存访问性能数据是低于左图的。2块cpu对内存读写性能的损耗影响是非常大的，这个损耗占据的比例远大于虚拟机和docker由于内存访问模型的不同产生的差异，因此在右图中docker与虚拟机的随机内存访问性能上我们看不出明显差异。
docker与虚拟机启动时间及资源耗费比较
上面两个小节主要从运行在docker里的程序和运行在虚拟机里的程序进行性能比较。事实上，docker之所以如此受到开发者关注的另外一个重要原因是启动docker的系统代价比启动一台虚拟机的代价要低得多：无论从启动时间还是从启动资源耗费角度来说。docker直接利用宿主机的系统内核，避免了虚拟机启动时所需的系统引导时间和操作系统运行的资源消耗。利用docker能在几秒钟之内启动大量的容器，这是虚拟机无法办到的。快速启动、低系统资源消耗的优点使docker在弹性云平台和自动运维系统方面有着很好的应用前景。
docker与虚拟机网络性能比较
采用netperf软件，分别使用TCP_STREAM | UDP_STREAM | TCP_RR | UDP_RR 四中模式测试性能和延迟
docker与虚拟机存储性能比较
采用iometer分别以顺序读、随机读、顺序写、随机写四中模式对如下3中场景进行测试，测试过程中文件系统采用ext4 测试前预热30s，每一种测试用例测试时间3分钟
参考文献
cbl709《docker与虚拟机性能比较》2015-02-26
@线超博《Native、Docker容器和KVM虚拟机网络性能对比测试》
作者：肥狐
出处：http://idbeta.cnblogs.com/
本博客内除了标题带[转]字样外的所有文章，均采用“署名-非商业性使用-禁止演绎 2.5 中国大陆”授权，任何违反本协议的行为均属于非法行为。如需非商业性转载，必须保留此段声明，且在文章页面明显位置给出原文连接。如需商业性转载出版，请直接和我联系。
如果您看了本篇博客,觉得对您有所收获，请点击右下方的【推荐】，同时欢迎您【关注我】
Eclipse连接Oracle数据库的ORA-00604 ORA-12705错误
用MyEclipse来连接Oracle数据库时出现了如下错误：ORA-00604: error occurred at recursive SQL level 1ORA-12705: Cannot acces
用MyEclipse来连接Oracle数据库时出现了如下错误：
ORA-00604: error occurred at recursive SQL level 1
ORA-12705: Cannot access NLS data files or invalid environment specified
到网上一搜都是关于Oracle编码的问题，，但是我用jdbc连接却没有问题，可以运行，于是想到是不是Eclipse本身的问题，最终终于在网上找到此问题的答案，原来是Eclipse的环境编码和Oracle的有冲突
Oracle在注册表中NLS_LANG值为SIMPLIFIED CHINESE_CHINA.ZHS16GBK
Eclipse启动时的配置文件Eclipse.ini的-Duser.language属性却为en
将en改为zh，问题解决
HP-UNIX 平台修改 Oracle processes 参数报错：ORA-27154、ORA-27300、ORA-27301、ORA-27302
OS 版本 ：HP-UX B.11.31
Oracle 版本：11.2.0.4 (RAC)
（一）问题描述
最近发现无法连接上数据库，报错信息为 “ORA-00020：maximum number of processes (3000) exceeded”，很明显是数据库的进程数量已经达到了最大值，可用过 v$process 确认
SQL> select count(*) from v$process;
COUNT(*)
----------
3000
于是打算将数据库参数 processes 改大一些，直接修改为 6000。修改命令如下：
SQL> alter system set processes=6000 scope=spfile sid=''*'';重启节点：
srvctl stop instance -d {oracle_name} -i {instance_name}
srvctl start instance -d {oracle_name} -i {instance_name}
在重启时候，发现有错误提示：
ORA-27154: post/wait create failed
ORA-27300: OS system dependent operation:semget failed with status: 28
ORA-27301: OS failure message: No space left on device
ORA-27302: failure occurred at: sskgpcreates
（二）解决方案
通过查找资料，可通过修改 OS 内核参数解决，可以使用 SAM 修改，也可使用 kctune 工具修改，这里使用 kctune 工具修改，修改过程如下
（1）确认 semm * 参数的当前值
oracledb2#[/]kctune | grep semm
semmni 5120 5120
semmns 8192 8192
semmnu 4092 4092
semmsl 2048 Default Immed
（2）修改 semmni 参数
oracledb2#[/]kctune semmni=8192
==> Update the automatic ''backup'' configuration first? y
* The automatic ''backup'' configuration has been updated.
* Future operations will update the backup without prompting.
NOTE: The requested changes could not be applied to the currently
running system, for the following reasons:
- The tunable ''semmni'' cannot be changed without a reboot.
* The requested changes have been saved, and will take effect at
next boot.
Tunable Value Expression
semmni (now) 5120 5120
(next boot) 8192 8192
（3）修改 semmns 的值
oracledb2#[/]kctune semmns=16384
* The automatic ''backup'' configuration has been updated.
NOTE: The requested changes could not be applied to the currently
running system, for the following reasons:
- The tunable ''semmns'' cannot be changed without a reboot.
* The requested changes have been saved, and will take effect at
next boot.
Tunable Value Expression
semmns (now) 8192 8192
(next boot) 16384 16384
（4）修改 nproc 参数的值，该参数修改后立刻生效
oracledb2#[/]kctune nproc=8192
* The automatic ''backup'' configuration has been updated.
WARNING: The validity of the tunable values could not be completely
verified, because the value of the tunable ''process_id_max''
will not be known until the system is booted. The tunable
values will be verified during boot. Please check the console
messages during boot to see if there are any tunable value
errors.
* The requested changes have been applied to the currently
running configuration.
Tunable Value Expression Changes
nproc (before) 6144 6144 Immed
(now) 8192 8192
（5）修改 semmnu 的值
oracledb2#[/]kctune semmnu=8188
* The automatic ''backup'' configuration has been updated.
NOTE: The requested changes could not be applied to the currently
running system, for the following reasons:
- The tunable ''semmnu'' cannot be changed without a reboot.
* The requested changes have been saved, and will take effect at
next boot.
Tunable Value Expression
semmnu (now) 4092 4092
(next boot) 8188 8188
需要注意的是，在修改 semmnu 之前，需要确定 nproc 的值，确保：nproc >= semmnu + 4。
错误示范：
oracledb2#[/]kctune semmnu=8188
ERROR: The values of the tunables ''semmnu'' (8188) and ''nproc'' (6144)
do not satisfy the requirement:
nproc >= semmnu + 4
在改完参数之后，需要重启 OS，参数才能生效。接着再重启数据库，正常启动。
HP-UNIX平台修改Oracle processes参数报错：ORA-27154、ORA-27300、ORA-27301、ORA-27302
OS 版本 ：HP-UX B.11.31
Oracle版本：11.2.0.4 (RAC)
（一）问题描述
最近发现无法连接上数据库，报错信息为“ORA-00020：maximum number of processes (3000) exceeded”，很明显是数据库的进程数量已经达到了最大值，可用过v$process确认
sql> select count(*) from v$process; COUNT(*) ---------- 3000
于是打算将数据库参数processes改大一些，直接修改为6000。修改命令如下：
sqlalter system set processes=6000 scope=spfile sid='*';
重启节点：
srvctl stop instance -d {oracle_name} -i {instance_name}
srvctl start instance -d {oracle_name} -i {instance_name}
在重启时候，发现有错误提示：
ORA-27154: post/wait create Failed
ORA-27300: OS system dependent operation:semget Failed with status: 28
ORA-27301: OS failure message: No space left on device
ORA-27302: failure occurred at: sskgpcreates
（二）解决方案
通过查找资料，可通过修改OS内核参数解决，可以使用SAM修改，也可使用kctune工具修改，这里使用kctune工具修改，修改过程如下
（1）确认semm*参数的当前值
oracledb2#[/]kctune | grep semm
semmni 5120 5120
semmns 8192 8192
semmnu 4092 4092
semmsl 2048 Default Immed
（2）修改semmni参数
oracledb2#[/]kctune semmni=8192
==> Update the automatic 'backup' configuration first? y
* The automatic 'backup' configuration has been updated.
* Future operations will update the backup without prompting.
NOTE: The requested changes Could not be applied to the currently
running system,for the following reasons:
- The tunable 'semmni' cannot be changed without a reboot.
* The requested changes have been saved,and will take effect at
next boot.
Tunable Value Expression
semmni (Now) 5120 5120
(next boot) 8192 8192
（3）修改semmns的值
oracledb2#[/]kctune semmns=16384
- The tunable 'semmns' cannot be changed without a reboot.
Tunable Value Expression
semmns (Now) 8192 8192
(next boot) 16384 16384
（4）修改nproc参数的值，该参数修改后立刻生效
oracledb2#[/]kctune nproc=8192
WARNING: The validity of the tunable values Could not be completely
verified,because the value of the tunable 'process_id_max'
will not be kNown until the system is booted. The tunable
values will be verified during boot. Please check the console
messages during boot to see if there are any tunable value
errors.
* The requested changes have been applied to the currently
running configuration.
Tunable Value Expression Changes
nproc (before) 6144 6144 Immed
(Now) 8192 8192
（5）修改semmnu的值
oracledb2#[/]kctune semmnu=8188
- The tunable 'semmnu' cannot be changed without a reboot.
Tunable Value Expression
semmnu (Now) 4092 4092
(next boot) 8188 8188
需要注意的是，在修改semmnu之前，需要确定nproc的值，确保：nproc >= semmnu + 4。
错误示范：
ERROR: The values of the tunables 'semmnu' (8188) and 'nproc' (6144)
do not satisfy the requirement:
nproc >= semmnu + 4
在改完参数之后，需要重启OS，参数才能生效。接着再重启数据库，正常启动。
今天关于性能测试过程中oracle数据库报ORA-27301 ORA-27302错和oracle 性能测试报告的介绍到此结束，谢谢您的阅读，有关Docker-Oracle和物理机Oracle数据库性能测试、Eclipse连接Oracle数据库的ORA-00604 ORA-12705错误、HP-UNIX 平台修改 Oracle processes 参数报错：ORA-27154、ORA-27300、ORA-27301、ORA-27302、HP-UNIX平台修改Oracle processes参数报错：ORA-27154、ORA-27300、ORA-27301、ORA-27302等更多相关知识的信息可以在本站进行查询。
本文标签：
![[转帖]Ubuntu 安装 Wine方法（ubuntu如何安装wine）](https://www.gvkun.com/zb_users/cache/thumbs/4c83df0e2303284d68480d1b1378581d-180-120-1.jpg)
