ORA-27125
今日在dbca创建多实例的时候出现报错：
ORA-27125:unable to create shared memory segment
问题原因：
sga大小和内核参数shmmax大小设置问题
过程回顾：
因为想创建传统多实例，在原实例基础上又用dbca开始创建另一个实例，但到了安装环境报此错误。
按网上的方法向/proc/sys/vm/hugetlb_shm_group 添加dba组号，但是没有效果。
处理过程：
最终的解决办法是将内核参数中的shmmax调大，原实例的sga调小，新建实例的sga设小一点，最终安装无报错。
后续
shmmax大小最好是系统内存一半以上，两sga总和大于系统内存一半但不超过shmmax设置的值
vim /etc/sysctl.conf
修改后生效：
/sbin/sysctl -p
ORA-27104
今日遇到了一则启动数据库的报错：
ORA-27104: system-defined limits for shared memory was misconfigured
问题原因：
sga_max_size设置过大；
过程回顾：
因想调大sga_target的值，而当前配置为sga_target和sga_max_size均为8G，因此无法动态调整sga_target，所以想设置sga_max_size然后重启数据库，再动态修改sga_target；
执行语句如下：
alter system set sga_target = 8G scope=both;
alter system set sga_max_size=25G scope=spfile;
alter system set pga_aggregate=5G scope=spfile;
然后找到当前使用的spfile:
show parameter spfile
用当前spfile创建备份的pfile(其实应该改参数前就备份才对)：
create pfile='/data/app/oracle/product/12.2.0/dbhome_1/dbs/pfile0706.ora' from spfile;
然后便自信关库重启，之后便遇到了上述报错；
处理过程：
看到报错后定位到应该是sga_max_size设置过大，OS本来是32G内存，而SGA+PGA设置的值加起来都30G了，所以修改之前备份的pfile，将sga_max_size改为16G，再以pfile启动；
sqlplus / as sysdba
startup pfile='/data/app/oracle/product/12.2.0/dbhome_1/dbs/pfile0706.ora'
可以正常启动
后续：
之后还需用pfile创建新的spfile：
create spfile ='spfileSRM0706.ora' from pfile='/data/app/oracle/product/12.2.0/dbhome_1/dbs/pfile0706.ora';
show parameter spfile
此时show parameter spfile不会有显示，表示这是用pfile启动的，而且有些需要写道spfile的参数也是无法配置，需要下次重启数据库才可以显示。
ORA-01078 和 LRM-00109
参考https://blog.csdn.net/qq_18312025/article/details/84945164
ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/ora01/app/oracle/product/11.2.0/db_1/dbs/initORA11G.ora'
将/ora01/app/oracle/admin/ora/pfile/下面的init.ora.较大数的文件 拷贝 到报错位置/ora01/app/oracle/admin/ora/pfile/并重命名为报错名字initORA11G.ora即可
ORA-32001
参考https://blog.csdn.net/u014677702/article/details/53319181
ORA-32001: 已请求写入 SPFILE, 但是在启动时未指定 SPFILE
可以通过以下语句来确认是否是用spfile来启动的，为空表示用pfile启动
SQL> show parameter spfile;
使用以下语句来修改oracle来使用spfile启动
SQL> create spfile from pfile;
重启后生效
ORA-02020
Oracle ORA-02020 : 过多的数据库链接在使用中
参考https://blog.csdn.net/ytfy12/article/details/48318963/
SQL> alter system set open_links=50 scope=spfile;
System altered
SQL> alter system set open_links_per_instance=50 scope=spfile;
System altered
重启生效
ORA-12516
问题原因：
oracle的会话数超出了限制，一般都是由于多次connect建立多个连接会话引起的，最后导致oracle无法响应新的请求。
处理过程：
1.查看当前连接进程数
SQL>select count(*) from v$process;
查看数据库当前会话的连接数：
SQL> select count(*) from v$session;
2.查看进程数上限
SQL>select value from v$parameter where name = 'processes';
查看会话数上限
SQL> show parameter sessions
3.查看当前数据库的processes设置
SQL> show parameter processes
SQL> show parameter sessions
4.修改新值
SQL> alter system set processes=2500 scope=spfile;
SQL> alter system set sessions=2555 scope=spfile;
5.重新启动数据库服务
SQL>shutdown immediate
SQL>startup
原文链接：https://blog.csdn.net/michaelsrc/article/details/6760247
DBT-50000
这是dbca建库的报错，无法检查可用内存
这是bug，通过如下命令启动即可：
dbca -J-Doracle.assistants.dbca.validate.ConfigurationParams=false
另外如传送窗口是乱码，可使用export LANG=en_US
ORA-31623和ORA-06512
在expdp时报错如下
UDE-31623: operation generated Oracle error 31623
ORA-31623: a job is not attached to this session via the specified handle
ORA-06512: at "SYS.DBMS_DATAPUMP", line 3263
ORA-06512: at "SYS.DBMS_DATAPUMP", line 4488
ORA-06512: at line 1
默认未修改 steam_pool_size(下限，默认为0)，data pump数据泵在11g中开始Advanced Queue高级队列来控制其job作业的启动、停止和重启了。如果streams pool的当前size为0(在v$sgainfo中可以查看)，那么显然无法分配到任何内存。
解决方案
alter system set streams_pool_size=128m scope=spfile;
然后重启数据库。
ORA-00845
ORA-00845: MEMORY_TARGET not supported on this system
错误原因是MEMORY_MAX_TARGET 的设置不能超过 /dev/shm 的大小
切换到root用户，使用命令修改
mount -o remount,size=20G /dev/shm/
ORA-03113、ORA-16033、ORA-19502、ORA-00312、ORA-00262、ORA-00350、ORA-01900
发现一系列报错，最开始是在startup过程中产生：
判断问题与日志相关，先startup;，报ORA-03113
想执行startup mount;启动到mount状态，以及select status from v$instance;查看启动状态，报ORA-24324、ORA-01041、SP2-0642、ORA-03114：
故重新进入sqlplus，再startup mount;成功。
先将spfile备份一份pfile留存。
然后检查日志状态：
select group#,thread#,sequence#,status from v$log;
发现THREAD1 GROUP1 状态还是CURRENT，
执行alter database clear unarchived logfile group 1;
发现ORA-00312、ORA-00262、ORA-00350报错：
看样子是需要把GROUP2归档，GROUP好切，不过我直接清了：
alter database clear unarchived logfile group 2;
怕redo日志不够又加了几个：
ALTER DATABASE ADD LOGFILE GROUP 4 ('xxx.LOG') SIZE 512m;
再open，成功：
alter database open;
然后定位到原因是归档日志空间满了
select * from v$flash_recovery_area_usage;
然后RMAN中删除了近期日志：
delete archivelog all completed before 'sysdate-28';
还改了归档日志路径，改到一个大一点的磁盘，再重启(重启前先备份一个pfile出来)，
之后配置定时备份和归档日志清理的任务即可。