简谈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这一行,尤其技术方面,真的得能够静下心来。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181028G0HGFK00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券