数据库运维管理系列之简谈Oracle数据库架构

本文是基于两年前做的两个生产案例总结而成，主要说明如何将单节点的核心 Oracle 数据库迁移升级至高可用架构，同时完善数据库的架构和配套增加相关数据库服务（备恢、监控、优化等）。

按理说本文是应该做成操作手册类型直接供读者阅读和操作的，无奈时间仓促，故而为简谈。其实很多时候，时间仓促只是一个借口而已，静不下心来或是舍不得花时间 （技术日新月异，为了永葆自身竞争力更愿意花时间去学习新知识） 再去重复操作一遍才是关键原因 （文中操作手册已经手动验证过 5 遍，应该不会有问题，一次的时间大概在 2h 左右） 。但已过去近两年，这个经验还算比较典型，不舍得一直尘封在自己电脑里，所以在此简谈一番，一是回忆巩固，二是共享大家，让大家有所收获。大家在实际操作过程中有问题欢迎咨询。做 IT ，还是得能够静下心来，我对象叫静静，虽然天天静静的叫着，但是自己的心越来越难静下来，哎，也许这就是人到中年的苦，事多浮躁，人心难静。

废话不多说，场景是这样，某单位中有两套核心生产数据库，单节点运行，但对单位的正常运行至关重要，经过沟通交流，为了保证数据库的稳定运行，决定进行升级至数据库高可用架构，同时完善数据库的备份、监控等服务。

首先是关于架构升级，原来单节点，升级之后的架构大致如下：

简单描述一下该架构：主要是 RAC+DG+ 历史归档库，比较传统、经典、适用。 RAC 集群采用共享光纤存储，有的公司如果没有光纤存储的话，可以考虑利用 iSCIS 搭建共享存储。 DG 节点使用本地存储，历史归档库考虑数据量较多，查询频次和性能要求不高，采用 NAS 存储。配套 ETL 服务器进行逻辑删除数据、历史数据的定时迁移。如果公司的投入有限的话，可以采用这种方式：

只是给数据库搭建一个 DG 节点，避免生产单节点，同时相关配套的数据库服务，可以根据投入成本和技术实力进行删减。

数据库配套服务方面主要包括数据库监控、数据库备份及恢复脚本、数据库性能持续优化等。数据库监控可以采用数据库自带的，也可以采购商业产品或是开源产品的，因为该单位有很多 mysql 数据库，故采用开源 Lepus 进行监控， Lepus 对 oracle 的监控并不完善，需要配套自写脚本进行监控；关于数据库的备份要求建立全流程的管理，包括备份工具选择（ rman,expdp, 商业备份软件等）、备份策略（备份时间、备份周期、全备份、增量等）、备份存储位置、备份恢复脚本以及脚本恢复预估时间，同时要求恢复脚本必须遵循准确无误、最小化操作的原则；数据库性能持续监控，持续优化，除了对 sql 优化外还应对服务器、网络、 IO 等进行监控，同时尽量减少单表数据量，实现瘦表，瘦库。

有一些企业对数据库的安全方面要求比较高，数据库防火墙、数据库脱敏、数据库审计等商业或是非商业产品会有所部署。

数据库应急演练是作为整个公司应急演练的一部分，必须持续性定期进行演练，确保灾难和故障面前，严格按照演练处理，做到对灾难和故障的准确把握。

整个 oracle 数据库的 rac+dg 的搭建内容较多，请参考：

链接： https://pan.baidu.com/s/1rK9JUVexU0RRAAjnsEm_Fg

提取码： t8pf 注：该搭建脚本经过至少 5 次验证，大家在使用的时候，有问题请及时跟我沟通。

以上，本文结束，历时 50 多分钟，理想中的本文结构应该是这样的：

1、 现状和规划

2、 迁移准备

3、 搭建环境

4、 迁移数据

5、 测试

6、 灾备与监控和定时优化

7、 数据库应急演练

8、数据库标准规范（sql书写规范、数据修改规范等）

按照理想的来写的话，估计得两天时间。

写在最后，自我勉励，做 IT 这一行，尤其技术方面，真的得能够静下心来