上周帮客户在一台测试服务器上部署了两套Oracle 19c实例单机多实例折腾了一下午中间踩了几个挺有代表性的坑。这篇文章我把实际操作的思路、命令、避坑点都放上来给计划在同一台机器上跑多个Oracle库的朋友做个参考。先说清楚一件事我这里说的“Oracle多实例部署”指的是在一台操作系统上运行两个或两个以上互相独立的Oracle数据库实例每个实例有自己独立的SGA、后台进程、数据文件和控制文件。很多朋友会把多实例、RAC、多租户PDB混在一起实际上它们解决的是完全不同的问题用错方案后面会很难受。1. 先搞清楚多实例到底解决什么问题1.1 什么场景适合用单机多实例我这次部署的背景是客户的一台测试服务器16GB内存两块1TB数据盘。他们手上同时跑着两个业务系统的测试环境一个用于接口联调一个用于性能压测。老板不想买两台机器DBA又不想在同一个库里把两套业务表混在一起——于是单机多实例就成了最合适的方案。这种场景下单机多实例大概有三种典型用途测试环境隔离同一台服务器上跑多套环境互相之间不干扰。接口联调那边把表结构改乱了压测环境完全不受影响。跨版本兼容测试比如同一台机器上同时装Oracle 11g和19c业务升级前先验证一下兼容性这在很多公司做数据库版本升级评估时会用到。资源复用服务器物理资源充足但业务量又达不到需要独立服务器的程度多实例可以把机器资源榨干。反过来如果业务场景是生产环境高可用那单机多实例就不合适了。同一台物理机宕机上面所有实例一起挂谈不上什么高可用。生产高可用该上RAC或者Data Guard这是方案选型层面的问题别搞混。1.2 多实例、RAC、PDB的区别在哪里很多刚接触Oracle的朋友会把这三个概念绕晕我打个比方单机多实例相当于一栋楼里好几套独立公寓各有各的水电表、门锁、房本只是共用楼道和地基。RAC相当于好几个家庭合住一套大房子共用同一个客厅和厨房共享存储但各自有卧室独立实例配合起来干活一个家庭忙不过来时另一个可以接着干。多租户PDB相当于一栋公寓楼里的不同房间但整栋楼的物业管理实例和后台进程是同一套班子房间里怎么装修业务数据互不干扰但物业停了整栋楼都停。三者的对比我用一个表格来说明对比维度单机多实例RAC多租户PDB共享内容物理机资源存储、网络、集群软件实例、后台进程、数据库文件隔离程度完全隔离实例隔离存储共享数据隔离实例共享适用场景测试环境、跨版本兼容生产高可用、负载均衡整合多个小业务降低运维成本管理复杂度中等很高低需要额外软件无GI集群软件无单机多实例的隔离性其实非常好每个实例有自己独立的内存结构和进程一个实例出问题crash掉其他实例通常不受影响。但它对规划能力要求比较高尤其是端口、目录、内存这些资源如果预先没规划好后续会踩不少坑。2. 动手前的三笔账版本、端口、内存2.1 版本选择与目录规划多实例部署有两种大方向同版本多实例和跨版本多实例。我第一次给客户部署时用的是同版本方案两个实例都是19c只装一套Oracle软件共用同一个ORACLE_HOME但ORACLE_SID不同。好处是软件安装一次、补丁打一次省事坏处是升级或者回退时两个实例会一起受影响。跨版本方案则相反11g、12c、19c各自装在自己的ORACLE_HOME下完全独立。好处是互不牵连坏处是安装和补丁维护的工作量翻倍环境变量切换也更麻烦每次操作前都要确认当前到底在用哪个版本的sqlplus。部署前目录规划非常关键。我的建议是数据文件目录一定要按实例分开千万别图省事把两个实例的数据文件塞到同一个父目录下。我踩过一次坑DBCA静默建库时没有指定独立子目录结果第二个实例的数据文件直接跟第一个实例混在一起后来清理时折腾了很久。下面是我这次用的磁盘布局可以参考挂载点用途内容/u01软件安装目录/u01/app/oracle/product/19.0.0/dbhome_1软件包/u02主实例数据目录/u02/oradata/ORCL19C1主实例数据文件/u03第二实例数据目录/u03/oradata/ORCL19C2第二实例数据文件/u04快速恢复区/u04/fra/ORCL19C1、/u04/fra/ORCL19C2每个实例的归档日志和闪回区也建议分开目录。虽然ADR自动诊断信息库会按实例各自分开但快速恢复区如果在同一目录下两个实例会互相争抢空间一个实例爆掉另一个也会受影响。2.2 监听端口规划默认情况下Oracle监听器跑在1521端口多实例部署时如果两个实例都要对外提供服务就要规划好监听端口。我的做法是每个实例分配一个独立监听端口并配套一个独立的监听器名称。这次我分配的是实例ORCL19C1用1521端口监听器叫LISTENER_1521实例ORCL19C2用1522端口监听器叫LISTENER_1522。虽然可以在一个监听器里同时注册多个实例但我个人更推荐一个实例一个监听器好处是监听故障隔离。如果你把两个实例放在同一个监听器上监听器一旦异常重启两个实例的服务会同时闪断。分开之后至少能保证一个实例的服务不受另一个监听器故障的影响。另外从等保合规角度讲很多安全扫描要求不能使用默认端口1521这种默认端口本身就是扫描工具的重点目标。改成1522、1523这类非默认端口在加固层面也算一道小屏障。2.3 内存规划与内核参数内存规划是单机多实例最容易出问题的环节。Oracle实例的内存分为SGA和PGA如果一个实例分配过多第二个实例可能直接启动失败。这台测试服务器物理内存16GB我按下面的思路分配实例1ORCL19C1业务联调用SGA 6GBPGA 1.5GB实例2ORCL19C2压测用SGA 4GBPGA 1GB操作系统本身预留至少3GB以上这样算下来总占用大约12.5GB操作系统还能剩3GB左右缓冲。如果后台还跑着监控代理、备份脚本之类的进程内存规划时也要把它们算进去。改内核参数时注意/etc/sysctl.conf里的kernel.shmall和kernel.shmmax。多实例情况下共享内存段不像单实例那样只要一个超大共享段就行。我习惯把kernel.shmmax设置成不小于单实例最大SGA的值同时把shmall设置成物理内存总页数偏大一些避免同时创建多个共享内存段时被限制。具体计算方式是shmall 物理内存字节数 / 页大小用root执行getconf PAGE_SIZE能查到页大小大多数x86架构是4096字节。16GB物理内存的话shmall可以设置成4194304。还有个容易被忽略的坑/etc/security/limits.conf里的memlock限制。如果设置了oracle用户不可锁定内存SGA分配会到内存锁定那一步失败报ORA-27102。我把oracle用户的memlock设置成了unlimited实测最省心。3. 完整部署实操记录Oracle 19c双实例3.1 环境准备与软件安装先创建操作系统用户和目录结构。我用的是Oracle Linux 7.9Oracle 19c对这个系统的兼容性很好groupadd oinstall groupadd dba useradd -g oinstall -G dba oracle mkdir -p /u01/app/oracle mkdir -p /u02/oradata mkdir -p /u03/oradata mkdir -p /u04/fra chown -R oracle:oinstall /u01 /u02 /u03 /u04内核参数和limits配置这里不展开写不同版本Linux差异不大网上主流的Oracle 19c安装前检查脚本都能用。核心是kernel.sem、kernel.shmall、kernel.shmmax、fs.file-max这几个参数字段以及oracle用户的nofile、nproc、memlock限制。软件安装部分要注意如果两个实例共用同一个ORACLE_HOME只需要跑一次OUI安装。安装数据库软件时选“Install database software only”不要勾选“Create a database”。数据库实例留给后面的DBCA去建这样更清晰。3.2 DBCA静默建库关键参数差异图形界面在部分服务器上不可用所以我的习惯是用DBCA静默模式建库。连续执行两条建库命令分别创建两个实例。第一条命令dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbname ORCL19C1 \ -sid ORCL19C1 \ -characterSet AL32UTF8 \ -totalMemory 6144 \ -emConfiguration NONE \ -datafileDestination /u02/oradata/ORCL19C1 \ -recoveryAreaDestination /u04/fra/ORCL19C1 \ -storageType FS \ -databaseType MULTIPURPOSE第二条命令dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbname ORCL19C2 \ -sid ORCL19C2 \ -characterSet AL32UTF8 \ -totalMemory 4096 \ -emConfiguration NONE \ -datafileDestination /u03/oradata/ORCL19C2 \ -recoveryAreaDestination /u04/fra/ORCL19C2 \ -storageType FS \ -databaseType MULTIPURPOSE两条命令的本质区别在于-sid参数、数据文件目录和内存大小。-gdbname和-sid保持一致这样数据库名和实例名不会产生混淆。-datafileDestination必须指向各自独立的目录这是多实例部署中最容易犯错的地方——两个实例的数据文件如果在同一个目录Oracle会报ORA-01157之类的错误因为数据库文件重名冲突。建库完成后用下面的命令检查两个实例的进程是否都起来了ps -ef | grep ora_ | grep -v grep正常情况下你会看到两套独立的后台进程进程名分别带ORCL19C1和ORCL19C2字样。只要有其中一套进程缺失就说明对应的实例启动失败需要去查看对应实例的alert日志。3.3 配置双监听器与动态注册数据库建好后接下来配置监听器。用netca创建监听器比较方便也可以用编辑器直接写listener.ora。我手动维护listener.ora更多一些毕竟服务器上没有图形界面的情况很常见。下面是我这次用的listener.ora配置LISTENER_1521 (DESCRIPTION_LIST (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 192.168.1.10)(PORT 1521)) ) ) SID_LIST_LISTENER_1521 (SID_LIST (SID_DESC (GLOBAL_DBNAME ORCL19C1) (ORACLE_HOME /u01/app/oracle/product/19.0.0/dbhome_1) (SID_NAME ORCL19C1) ) ) LISTENER_1522 (DESCRIPTION_LIST (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 192.168.1.10)(PORT 1522)) ) ) SID_LIST_LISTENER_1522 (SID_LIST (SID_DESC (GLOBAL_DBNAME ORCL19C2) (ORACLE_HOME /u01/app/oracle/product/19.0.0/dbhome_1) (SID_NAME ORCL19C2) ) )我建议用静态注册的方式在listener.ora里写明SID列表别只依赖动态注册。很多朋友以为实例启动后监听会自动识别服务实际上动态注册依赖PMON进程向监听器注册这个注册过程有延迟有时候等好几分钟监听状态里仍看不到实例误以为数据库没启动。静态注册可以保证监听启动后立刻就能转发连接请求。另外还要注意local_listener参数。如果实例默认监听端口是1521而你的实例配置在1522端口上不设置local_listener参数的话PMON永远不会往1522端口的监听器注册服务。在实例里执行alter system set local_listener(ADDRESS(PROTOCOLTCP)(HOST192.168.1.10)(PORT1522)) scopeboth sidORCL19C2;这里sidORCL19C2很关键只针对第二个实例生效不会影响第一个实例。配置完成后启动监听lsnrctl start LISTENER_1521 lsnrctl start LISTENER_1522 lsnrctl status LISTENER_1522如果status输出中看到ORCL19C2的实例状态为READY或UNKNOWN就说明监听器工作正常。3.4 多实例环境变量切换与启停操作单机多实例最让人头疼的是环境变量切换。很多DBA习惯把ORACLE_SID、ORACLE_HOME写进用户的环境变量文件里但这样只对单个实例有效。我这次的做法是写了两套独立的环境变量脚本放在/opt/oracle_env目录下# /opt/oracle_env/orcl19c1.env export ORACLE_BASE/u01/app/oracle export ORACLE_HOME/u01/app/oracle/product/19.0.0/dbhome_1 export ORACLE_SIDORCL19C1 export PATH$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH$ORACLE_HOME/lib# /opt/oracle_env/orcl19c2.env export ORACLE_BASE/u01/app/oracle export ORACLE_HOME/u01/app/oracle/product/19.0.0/dbhome_1 export ORACLE_SIDORCL19C2 export PATH$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH$ORACLE_HOME/lib操作哪个实例前先source对应的环境脚本这样sqlplus、rman这些命令一定是针对当前环境的。我遇到过几次不source脚本直接敲sqlplus结果连错实例的情况回头看全是环境变量混淆的问题。实例启停命令本身没太多特殊之处但顺序有讲究# 启动第二实例先环境再监听再库 source /opt/oracle_env/orcl19c2.env lsnrctl start LISTENER_1522 sqlplus / as sysdba SQL startup关闭时反过来SQL shutdown immediate SQL exit lsnrctl stop LISTENER_1522如果数据库和监听器都在运行你想单独重启监听器注意业务连接会短暂中断。我一般确认没有活跃会话后才操作监听重启。4. 常见问题与排查实录实际部署过程中不可能一帆风顺我把这次遇到的高频问题以及平时帮别人排查时总结的经验放在下面4.1 监听器启动失败或端口被占用监听器起不来的第一反应是查端口占用。netstat -tlnp | grep 1522看看端口是否被其他进程占用。我遇到过测试服务器上有个Java服务自己起了个监听在1522端口Oracle监听自然起不来。还有一次是防火墙的问题Oracle监听实际已经监听成功但客户端连不进来检查firewalld才发现端口没放行。如果确实端口冲突了两种解决思路改Oracle监听端口或者让占用的服务让路。我建议优先让路因为改端口牵扯到客户端的连接字符串、应用配置改动范围会扩散。如果必须改Oracle监听端口修改listener.ora后执行lsnrctl reload不用重启监听进程reload会平滑加载新配置。4.2 实例启动成功但监听里没有服务这个现象很典型ps -ef里能看到实例在跑但lsnrctl status就是看不到服务。原因通常是三个一是动态注册延迟PMON默认每60秒向监听器注册一次刚启动的实例可能要等一两分钟才出现在监听状态里。二是local_listener参数没设置实例不知道要向哪个监听器注册。三是service_names参数不对监听器里显示的service name可能不是你预期的名字。排查命令是show parameter local_listener; show parameter service_names;如果local_listener是空的按前文方式设置如果service_names不对用alter system set service_namesORCL19C2 scopeboth;调整。另外确认监听器用的是哪个sqlnet.ora文件。如果存在两个$ORACLE_HOMETNS_ADMIN环境变量指向错误目录也会出现监听配置读不到的情况lsnrctl status报错信息里通常会显示实际读取的目录路径看出问题后及时调整TNS_ADMIN。4.3 内存不足导致实例启动失败多实例最大的风险点就是内存分配。第二个实例启动时如果报ORA-27102: out of memory或者ORA-00064: parameter is too large基本可以断定内存账没算对。处理方法先看系统剩余内存free -g如果剩余内存很少把第二个实例的sga_target调小。如果第一个实例的SGA已经占了8GB第二个实例还想再干6GB物理内存不够肯定会失败。我一般建议两个实例的SGA总和不要超过物理内存的60%给操作系统和其他进程留足余地。还要注意/etc/sysctl.conf里的kernel.shmall是不是太小。如果单实例大SGA没问题多实例同时创建多个共享内存段时shmall限制的是共享内存页总量两个实例的共享段加起来可能超过这个限制。计算方式前面提到过用getconf PAGE_SIZE拿到页大小然后按物理内存总字节数除以页大小来设置。改完后执行sysctl -p生效最好重启验证一下。4.4 连接错库环境变量惹的祸单机多实例最隐蔽的问题是连错库。明明想连ORCL19C2结果sqlplus进去发现是ORCL19C1这种问题通常出在ORACLE_SID设置错误。排查思路很简单echo $ORACLE_SID which sqlplus确认当前设置是否正确。还有一种情况是不同版本的ORACLE_HOME混用PATH里如果前面一个home的bin覆盖了后面一个sqlplus版本就是错的。多版本共存时我建议把各自的环境变量脚本分开source不要都写进系统级profile里。还有一个细节如果使用sqlplus system/密码192.168.1.10:1522/ORCL19C2这种方式连接虽然走的是监听不太受环境变量影响但监听器必须能正确路由到目标实例。如果listener.ora里SID_LIST配错了SID_NAME客户端连进来也会报ORA-12514。4.5 sqlplus登录缓慢的隐藏原因热词里提到sqlplus登录Oracle数据库出现缓慢或者错误的问题我这次也碰到了。现象是sqlplus本地登录时要卡几十秒才进去但远程连接反而很快。查下来是反向DNS解析问题Oracle在建立连接时会尝试反向解析客户端IP对应的主机名如果/etc/hosts里没有本机主机名的映射并且DNS服务器不可达解析就会长时间超时。解决方式有两种第一种是在/etc/hosts里加一行把主机名和IP对应起来192.168.1.10 dbserver01 127.0.0.1 localhost第二种是在sqlnet.ora里设置SQLNET.INBOUND_CONNECT_TIMEOUT10这个参数会限制连接建立阶段的等待时长超时直接报错不会让登录过程卡死。但要注意设置太短可能误伤正常连接我建议从10秒开始调。4.6 常见问题速查表现象可能原因排查命令解决办法监听启动失败端口被占用netstat -tlnp | grep 端口让占用方让路或改监听端口实例在跑但监听无服务local_listener参数未设置show parameter local_listener设置local_listener指向对应监听第二个实例启动报ORA-27102内存分配超限free -g调小SGA检查shmallsqlplus连到错误实例ORACLE_SID设置错误echo $ORACLE_SIDsource对应环境脚本sqlplus登录卡顿反向DNS解析超时/etc/hosts检查hosts加本机映射调SQLNET超时客户端报ORA-12514监听SID_LIST配置错误lsnrctl status检查listener.ora的SID_NAME实例启动找不到控制文件数据文件目录混用show parameter control_files单独规划目录分开存放5. 几个实操心得经历过这次单机多实例部署有几点体会比较深。环境变量切换这件事真的建议做成脚本而不是靠记忆。人总有恍惚的时候一次source错了环境文件后面所有操作全乱。我后来把启停逻辑做成了带菜单的shell脚本选择1就启动ORCL19C1选择2就启动ORCL19C2脚本里先自动source对应环境文件再执行监听和数据库的启停出错概率大幅下降。端口规划也不建议用1521、1522把同类型端口扎堆。有的安全基线扫描会对连续开放端口比较敏感至于具体用哪些端口需要根据公司安全策略来定。不管最后用什么端口记得在文档里把“实例名、端口、监听器名、数据文件目录、服务名”这五件套记录清楚后续排查问题时能少走很多弯路。监控方面多实例环境比单实例更需要关注系统资源。我建议哪怕只是测试环境也把top、内存、磁盘使用情况纳入基本监控。两个实例同时跑业务时资源争抢是难免的特别是压测期间磁盘I/O很容易成为瓶颈。我这次就是因为两个实例同时跑批量任务结果归档日志目录一下就被撑满了。所以给每个实例单独设置快速恢复区大小并及时清理归档现在已经成为我多实例部署的固定动作。备份策略也得按实例分别规划。很多备份脚本里写死了数据库名或者ORACLE_SID套到多实例环境里不检查就直接跑很容易把备份数据写到同一个目录里互相覆盖。每个实例的备份脚本、RMAN配置、目录路径必须完全独立并且备份恢复演练时要有文档明确当前在操作哪个实例。平时多做一次演练关键时刻就能少一次慌乱。