建议：若非系统资源紧张，切记操作
有时候由于大量用户访问Oracle，造成无法访问数据库资源，旨在增加Oracle数据库访问连接数
单库操作修改 processes和sessions的大小：
查询Oracle 用户连接数
select username,count(username) from v$session where username is not null group by username;
select count(*) from v$session where status='ACTIVE';查看系统资源
select resource_name, current_utilization, max_utilization, limit, round(max_utilization / limit * 100) || '%' rate from (select resource_name, current_utilization, max_utilization, to_number(initial_allocation) limit from v$resource_limit where resource_name in ('processes', 'sessions') and max_utilization > 0);修改系统资源大小，然后重启数据库
alter system set processes=1000 scope=spfile;
alter system set sessions=1110 scope=spfile;RAC多节点操作修改processes大小:
第一步：修改参数
单实例
alter system set processes=8000 scope=spfile;
RAC（在主节点上修改，一般为节点一）
alter system set processes=8000 sid='*' scope=spfile;第二步：重启数据库
单实例：shutdown immediate – startup
RAC：多个节点的参数都修改完成后可同时重启数据库
srvctl stop database -d orcl – srvctl start database -d orcl
也可以单独每个节点重启
srvctl stop database -d orcl1/2 – srvctl start database -d orcl1/2一般重启数据库后重新查看参数就能看到参数已经改过来了。
一次操作不规范产生的奇葩问题：
业务系统数据库时RAC需要修改processes参数，我用alter system set processes=8000 sid='*’scope=spfile;在主节点修改了参数后，在oracle用户下用shutdown immediate/startup来重启数据库，于是产生了两个问题:1.可能导致数据库关闭时间过长。2.两个节点重启后节点一的process参数没有变化，节点二却改过来了。
然后尝试alter system set processes=8000 scope=spfile;在节点一再次修改并重启节点一数据库，还是改不过来，查看参数文件却改过来了。
然后将两个节点用shutdown immediate全都关闭，在用srvctl start重新启动就好了。
关库时间过长过长问题:
有些业务系统，在关闭数据库时可能有大量的事务在进行，会导致关库时间过长，有的时候半个小时都关不掉。
关闭数据库时可tail -f alert.log观察数据库关闭过程
- 第一次会长时间卡在这
- 第二次长时间会卡在这提示：有些进程无法被PMON进程清理，导致SHUTDOWN时无法关闭而HANG住（10g以后会有提示）。
- 系统中查看一下这些是什么进程
杀掉进程，oracle用户下执行即可
[oracle@hisdb ~]$ kill -9 1182如果日志中没有提示哪些进程导致数据库无法关闭
则可用
ps -ef|grep LOCAL=NO 查找相关进程kill掉如何避免大事务回滚，可在关库前checkpoint一下，主节点执行即可
ALTER SYSTEM CHECKPOINT;要注意的是alter system switch logfile; 也会触发checkpoint,但只会对执行sql的那个节点,不会对RAC中的所有节点
总结来源：
zongzizz：https://blog.csdn.net/zongzizz/article/details/122936214
流沙Quicksand：https://blog.csdn.net/gengzhy/article/details/122980996
