简谈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书写规范、数据修改规范等）

按照理想的来写的话，估计得两天时间。10月24程序员节的时候在当当半价买了两本书《云计算信息安全管理——CSAC-STAR实施指南》、《云计算架构技术与实践(第2版)》，但愿省下的这两天能够看完一本。

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