说实话，第一次听说要在Docker里装Oracle的时候，我内心是拒绝的。Oracle这种重量级选手，动辄几个G的安装包，跑起来吃内存像喝水，平时在物理机上装都得小心翼翼伺候着，塞进容器里？听着就像把大象塞进冰箱。但架不住项目组新来的小伙子天天念叨，说测试环境资源紧张，好几套系统等着用数据库，物理机装一套Oracle得浪费半台机器。我寻思着，既然Docker能跑MySQL、跑PostgreSQL，那Oracle应该也不是不行，只是这坑估计不少。
真上手的时候，第一个坑就来了——镜像。Oracle官方在Docker Hub上的镜像，名字叫，但别指望能直接下来，得先到Oracle官网注册账号，同意一堆协议，才能拿到下载权限。这流程搞得跟特务接头似的，烦是烦了点，但想想Oracle这公司一贯的做派，也就不意外了。好在网上有不少好心人打包好的镜像，比如，虽然非官方，但胜在方便，拿来练手完全够用。我用的就是这玩意儿，11g XE版本，轻量，适合我们这种小项目。
拉镜像这步还算顺利，，几个G的东西，等个几分钟就完事了。接下来就是启动容器，命令也不算复杂：
docker run -d --name oracle11g
-e ORACLEPASSWORD=oracle
端口映射到1521，密码设成oracle，简单粗暴。但这里有个细节容易踩坑，就是容器启动后Oracle初始化需要时间，不是立马就能连上的。我第一次启动完，兴冲冲地用SQL Developer去连，结果报错，还以为是哪里配置错了，查了半天日志才发现是还没初始化完。所以启动完容器，别急着连，等个一分钟左右，看到日志里出现再动手。
连接的时候又遇到个问题，Oracle的用户体系跟MySQL不太一样，默认的管理员是和，密码就是我们启动时设置的那个。但用SQL Developer连的时候，角色得选对，要选，用默认的就行。我第一次用连接，角色选错了，又折腾了半天。不过这些小问题，一旦搞明白，后面就顺了。
数据持久化这块，是Docker装数据库的重中之重。容器说没就没，万一哪天手滑删了，数据全没了，那可就哭都来不及。所以启动容器的时候，得挂载数据卷：
docker run -d --name oracle11g
-e ORACLEPASSWORD=oracle
-v /opt/oracle-data:/u01/app/oracle/oradata
把容器里的数据目录映射到宿主机上，这样就算容器删了，数据还在。这个习惯一定要养成，别嫌麻烦，真出问题的时候就知道这个动作有多救命了。
还有一点，Docker里的Oracle性能调优，跟物理机完全是两码事。容器默认的资源限制比较保守，如果宿主机配置还行，建议启动的时候加个参数，把共享内存调大点：
docker run -d --name oracle11g
-e ORACLE_PASSWORD=oracle
-v /opt/oracle-data:/u01/app/oracle/oradata
Oracle对共享内存挺敏感的，默认的64M太小，跑起来容易出问题。我之前没加这个参数，跑个稍微复杂点的查询就报内存相关的错误，加上之后就好了。另外，如果宿主机内存充足，还可以加限制容器最大内存，防止它吃光宿主机资源。
用了一段时间，整体感觉Docker装Oracle，最大的优势就是环境隔离和快速部署。以前在物理机上装Oracle，光前置检查就得折腾半天，什么内核参数、依赖包、用户权限，一个不对就装不上。现在用Docker，一条命令搞定，而且想换版本也方便，拉个不同tag的镜像就行。最重要的是，测试环境可以随便造，搞坏了删掉重建，一分钟的事，这在以前想都不敢想。
不过也别把Docker里的Oracle想得太完美。性能方面，容器毕竟有额外一层隔离，高并发场景下跟物理机还是有差距。而且Oracle官方对Docker的支持态度比较暧昧，很多企业生产环境还是不敢用容器跑Oracle。但对我们这种开发测试环境来说，Docker装Oracle绝对是神器，省时省力，还不占地方。如果你也跟我一样，被Oracle的安装折磨过，不妨试试Docker这条路，说不定就柳暗花明了。
