数据库管理 (Database Admin)
数据库管理工作就是对数据库管理系统进行管理和维护的工作。他的核心目标是为了保证数据库的各个性能：
| 稳定性 | 指的是数据库系统的高可用性，利用主从、多主、分布式等不同的高可用架构（HA）来保证数据库系统的可用性，稳定性。 |
|---|---|
| 安全性 | 数据库存储内容的安全性，避免数据内容被非法访问和使用。 |
| 一致性 | 数据库自身提供很多功能来保证数据一致性，比如表的外键约束，非空约束等，这里说的数据库管理系统的数据一致性，是指在构建主备系统，主从系统等多主机系统时候，利用数据库提供的同步技术，复制工具等来保证多个数据库之间的数据一致性，这种保证性工作属于数据库管理工作的一部分。 |
| 系统的高性能 | 主要是管理工作里面的优化，监控，故障排除等工作。 |
数据库管理员（Database Administrator）是从事管理和维护数据库管理系统的相关人员的统称。在国外，也有公司把DBA称作数据库工程师(Database Engineer)，两者的工作内容基本相同，都是保证数据库服务7*24小时的稳定高效运转
数据库管理的工作范围
| 数据库对象管理 | 数据库对象管理实际上是对数据库的内数据的管理，了解不同数据库对象提供的特征和功能，遵循合理的关系设计原则，把概念设计和逻辑设计中的数据模型转化成物理数据库对象。数据库对象的创建，删除，修改和优化等。 |
|---|---|
| 数据库安全管理 | 包括但不限于系统安全性、数据安全性、网络安全性等，防止数据信息泄露，防止安全漏洞和不正当的数据修改，确保数据只提供给授权用户使用。 |
| 备份恢复管理 | 制定合理的备份策略，实现数据定期备份功能；保证灾难发生时数据库系统能够做到最快恢复和最小损失。 |
| 数据库性能管理 | 对影响数据库性能的因素进行监控和优化。对数据库能使用的资源进行优化，从而增加系统吞吐量，并减少竞争，最大可能地处理工作负载。 |
| 数据库环境管理 | 数据库的运行和维护管理；包括安装，配置，升级，迁移等确保数据库系统在内的IT基础设施正常运作的管理工作。 |
数据库对象管理
数据库里用来存储和指向数据的各种概念和结构的总称。数据库对象并没有严格的正式的定义。常见的基本数据库对象：
| 对象 | 名称 | 作用 |
|---|---|---|
| TABLE | 表 | 用于存储数据的基本结构 |
| VIEW | 视图 | 以不同的侧面反映表的数据，是一种逻辑上的“虚拟表”，视图本身不存储数据 |
| INDEX | 索引 | 索引提供指向存储在表的指定列中的数据值的指针，如同图书的目录，能够加快表的查询速度 |
| SEQUENCE | 序列 | 用来产生唯一整数的数据库对象 |
| STORE PROCEDURE、FUNCTION | 存储过程、函数 | 一组为了完成特定功能的SQL 语句集。存储过程、函数经过编译后，可以被重复调用，从而可以减少数据库开发人员的工作量 |
备份与恢复管理
数据库的备份
备份数据库就是将数据库中的数据，以及保证数据库系统正常运行的有关信息保存起来，以备系统出现故障后恢复数据库时使用。备份的对象包括但不限于：数据本身；和数据相关的数据库对象；用户及权限；数据库环境，如配置文件，定时任务等。
数据库的恢复
将数据库系统从故障或者瘫痪状态恢复到可正常运行，并能够将数据恢复到可接受状态的活动。
导致数据丢失的可能原因：
1 存储介质故障
2.用户的操作错误
3.服务器故障
4.病毒侵害
5.自然灾害
灾难备份与恢复
灾难恢复
指自然或人为灾害后，重新启用信息系统的数据、硬件及软体设备，恢复正常商业运作的过程。灾难恢复规划是涵盖面更广的业务连续规划的一部分，其核心即对企业或机构的灾难性风险做出评估、防范，特别是对关键性业务数据、流程予以及时记录、备份、保护。
灾难备份
为了灾难恢复而对数据、数据处理系统、网络系统、基础设施、专业技术能力和运行管理能力进行备份的过程。
恢复时间目标（RTO）
灾难发生后，信息系统或业务功能从停顿到必须恢复的时间要求。
必须恢复到的时间点要求，举个例子说明，比如RPO要求是1天，那么就是灾难发生后，必须能够把系统和数据恢复到故障发生24小时之前这个时间点的状态。24小时以内的数据存在丢失的可能性。24小时以内的数据丢失在这个等级下是允许的。但如果数据只能恢复到2天前，就是48个小时之前的状态，那么就不满足RPO=1天的要求。
恢复点目标（RPO）
灾难发生后，系统和数据必须恢复到的时间点要求。RTO强调的是服务的可用性，RTO越小服务损失就越少，RPO是数据丢失，RPO越小数据丢失的越少
典型的企业容灾目标：恢复时间目标RTO<30分钟，数据领丢失 RPO = 0
灾难恢复等级
| 等级一 | 基本支持。要求数据备份系统能够保证每周至少进行一次数据备份，备份介质能够提供场外存放。对于备用数据处理系统和备用网络系统，没有具体要求。例如能够把数据备份到磁带上，磁带同城异地保存。 |
|---|---|
| 等级二 | 备用场地支持。在满足等级一的条件基础上，要求配备灾难恢复所需的部分数据处理设备，或灾难发生后能在预定时间内调配所需的数据处理设备到备用场地；要求配备部分通信线路和相应的网络设备，或灾难发生后能在预定时间内调配所需的通信线路和网络设备到备用场地。 |
| 等级三 | 电子传输和设备支持。要求每天至少进行一次完全数据备份，备份介质场外存放，同时每天多次利用通信网络将关键数据定时批量传送至备用场地。配备灾难恢复所需的部分数据处理设备、通信线路和相应的网络设备。 |
| 等级四 | 电子传输及完整设备支持。在等级三的基础上，要求配置灾难恢复所需的所有数据处理设备、通行线路和相应的网络设备，并且出于就绪或运行状态。 |
| 等级五 | 实时数据传输及完整设备支持。除要求每天至少进行一次完全数据备份，备份介质场外存放外，还要求采用远程数据复制技术，利用通信网络将关键数据实时复制到备用场地。 |
| 等级六 | 数据零丢失和远程集群支持。要求实现远程实时备份，数据零丢失；备用数据处理系统具备与生产数据处理系统一致的处理能力，应用软件是“集群的”，可实时无缝切换。 |
某行业RTO/RPO与灾难恢复能力等级关系
| 灾难恢复能力等级 | RTO | RPO |
|---|---|---|
| 1 | 2天以上 | 1天至7天 |
| 2 | 24小时以上 | 1天至7天 |
| 3 | 12小时以上 | 数小时至1天 |
| 4 | 数小时至2天 | 数小时至1天 |
| 5 | 数分钟至2天 | 0至30分钟 |
| 6 | 数分钟 | 0 |
备份方式
| 全量备份 | 也称为完全备份。对某个指定时间点的所有数据和对应的结构进行一个完全的备份。 |
|---|---|
| 差异备份 | 差异备份是指上一次全量备份之后，对发生变化的数据进行的备份。 |
| 增量备份 | 增量备份是指上一次备份之后，对发生变化的数据进行的备份。 |
| 热备 | 在数据库正常运行下进行备份。备份期间，数据库读写均可正常进行。 |
| 温备 | 数据库可用性弱与热备，备份期间，数据库只能进行读操作，不能进行写操作。 |
| 冷备 | 在备份期间，应用的读写操作不可进行。备份出的数据可靠性最高。 |
| 物理备份 | 直接备份数据库所对应的数据文件甚至是整个磁盘。 |
| 逻辑备份 | 将数据从数据库中导出，并将导出的数据进行存档备份。 |
全量备份
特点：数据最完备；安全性最高；备份和恢复时间随着数据的体量而明显增加；非常重要，是差异备份和增量备份的基础；备份期间会对系统性能产生一定影响。
增量备份与差异备份
使用增量备份后每一个备份都是在上一个备份的基础上进行，一旦周四发生故障必须按照顺序从上周日的完全备份开始到周一、周二、周三依次恢复，假设周二恢复文件损坏那么周三的增量备份文件就失效了，数据就只能恢复到周一的状态。
而使用差异备份后每一个备份都是在上周日备份的基础上进行，因此周四发生故障时只需要上周日的完全备份以及周三的差异备份依次恢复就能使数据回到正常状态。
GaussDB支持全量，增量和差异三种备份形式
热备、温备和冷备
如果数据库的应用不接受服务停止的情况下，均采用热备方案，但是数据无法保证绝对的准确性。如果可以停止应用读写服务，而要求备份点数据的准确性的情况下，优先使用冷备方案。例如常规的日常备份尽量采用热备方案，而在系统迁移的情况下，为保证数据时点的准确性，倾向使用冷备方案。
物理备份和逻辑备份
恢复效率：物理备份只要直接恢复数据块数据文件即可效率高， 逻辑备份恢复的时候相当于重新执行sql，所以数据量大的时候系统开销大，效率低。
相对于物理复制对日志物理格式的强依赖，逻辑复制仅基于数据的逻辑变化，应用更加灵活。可以实现GaussDB 100跨版本复制、GaussDB 100向其它异构数据库（如：Oracle、MySQL）复制，以及在源、目标数据库表结构不一致时的定制支持。
数据库安全管理
数据库系统安全框架
广义范围，数据库安全框架可以分为三个层次：
| 网络层次安全 | 从技术角度讲，网络系统层次安全方法技术主要有加密技术，数字签名技术，防火墙技术和入侵检测技术等。 |
|---|---|
| 操作系统层次安全 | 核心是要保证服务器的安全，主要体现在服务器的用户账户，口令，访问权限等方面。数据安全主要体现在加密技术、数据存储的安全性，数据传输的安全性等方面，如Kerberos，IPsec，SSL和v*n等技术。 |
| 数据管理系统层次安全 | 数据库加密；数据存取访问控制；安全审计；数据备份。 |
安全控制模型
这个安全控制模型只是一个示意图，现代的数据库产品都有自己的安全控制模型
用户向应用程序提供其身份，应用程序将用户身份提交给DBMS进行验证，只有合法的用户才能进入到下一步的操作。对于合法用户，在进行数据库操作是，DBMS还要验证词用户是否具有这种操作权限。如果有操作权限，才进行操作，否则拒绝执行用户的操作。操作系统也有自己的保护措施，比如设置文件的访问权限。对于存储在磁盘上的文件，可以进行加密存储，这样即使数据被人窃取，也无法解读数据（GaussDB就提供这方面的加密功能）此外，还可以将数据文件保存多份进行冗余，当意外情况出现时候，避免损失数据。
身份验证
数据库用户的身份验证是DBMS提供的最外层安全保护措施，用来阻止未经授权的用户的访问；对于数据库应用目前普遍采用用户名密码验证模式，所以有必要增强密码强度。
1、采用长度较长的字符串，如8-20个字符；
2、混合数字，字母和符号的密码；
3、定期更换密码；
4、密码不能重复使用。
访问控制
访问控制是数据库安全中最有效的办法也是最容易出问题的地方。对于不同用户根据敏感数据的分类要求，给予不同的权限：
| 最小权限原则 | 就是给予能否满足需求的最小范围权限，不能随意扩大权限授予范围。例如，需要查询数据，那么只授予select权限就可以了，不能把delete，update这些权限也授予给用户。 |
|---|---|
| 检查关键权限 | 对于drop表，truncate表，update，delete这些会导致数据消失，或者数据变更的查询要谨慎授予，而且经常复检授予的对象用户是否还继续使用； |
| 检查关键数据库对象的权限 | 对于系统表，数据字典，敏感数据库表的访问权限要严格检查。 |
基于角色的权限管理
对于大型数据库系统或者用户数量多的系统，权限管理主要使用基于角色的访问控制。数据库“角色” 就是一个或者一群用户在数据库内科执行操作的集合。角色可以根据不同的工作职责创建，然后用户分配到相应的角色下，也可以轻松的切换角色，或者同时拥有多个角色。
开启审计
审计可以帮助数据库管理员发现现存架构和使用中的漏洞。
| 访问及身份验证审计 | 数据库用户登入（logon），登出（logoff）的相关信息，如登入登出时间，连接方式及参数信息，登入途径等。 |
|---|---|
| 用户与管理员审计 | 针对用户和管理员执行的活动进行分析和报告。如SQL语句，数据导入导出，加载卸载，备份恢复等。 |
| 安全活动监控 | 记录数据库中任何未授权或者可疑的活动生成审计报告。 |
| 漏洞与威胁审计 | 发现数据库可能存在的漏洞，以及想要利用这些漏洞的“用户”。 |
数据库加密
数据库加密的不同层次
DBMS内核层
数据在物理存取之前完成加/解密工作；
对于数据库用户来说是透明的，没有感觉的；
采用加密存储，加密运算在服务器端运行，在一定程度上会加重服务器的负载。 DBMS外层加密
开发专门的加解密工具，或者定义加解密方法；
可以控制加密对象粒度，到表或者字段级别进行加解密；
用户只需要关注敏感信息范围。
性能管理
资源
| 供给类资源 | 这类资源也称为基础资源，是计算机硬件对应的资源。操作系统管理的资源。处理能力： CPU>内存>>磁盘≈网络。 |
|---|---|
| 并发性控制资源 | 这类资源包括但不限于：锁，队列，缓存，互斥信号等。数据库系统管理的资源。 |
性能管理的基本原则就是充分利用资源不浪费。
性能管理的意义
| 资源的高效使用 | 数据库实际上总是在有限的环境下运行。对资源的有效管理确保数据库系统在高峰时期能够满足用户对系统的性能要求。 |
|---|---|
| 侦测系统问题 | 实时的系统性能监控（通过数据库提供的日志或者工具进行实时监控系统性能）。系统历史性能数据跟踪（历史性能数据的分析）。 |
| 容量规划 | 性能管理所收集到的数据是进行系统容量规划及其他前瞻性规划的基础。用事实而不是感觉说话。 |
性能管理的目标
数据库系统的基本指标为吞吐量和响应时间。
| OLTP | 在可接受的响应时间基础之上提供尽可能高的吞吐量。降低单位资源消耗，快速通过并发共享区域，减少瓶颈制约。 |
|---|---|
| OLAP | 在有限的资源内尽可能地缩短响应时间。一个事务应该充分利用资源来加速处理时间。 |
性能优化工作的一些场景
上线优化或未达到性能期望的性能优化；
响应速度逐渐变慢的系统优化；
系统运行过程中突然变慢的系统优化（应急处理）；
突然变慢，持续一段时间以后又恢复正常；
基于降低资源消耗的系统优化；
预防性的日常巡检工作。
性能管理需要采集的数据
采集的数据范围，包括但不限于：
CPU使用数据；
空间使用率；
使用数据库系统的用户和角色；
心跳查询的响应时间；
提交到数据库的SQL为基本单元的性能数据；
数据库工具提交的作业相关的性能数据（如加载，卸载，备份，恢复等）。
关注的时间范围:
日常范围：一周高峰时段的时间；月度结束的时间；季节变化数据。
一天范围内：用户集中使用系统的时间段；系统压力比较高的时间段等。
建立性能报表
数据库系统内置很多监控报表
提取性能相关的数据建立定期性能报表（日报，周报，月报）。
建立常见指标的性能趋势分析报表，可以对当前系统性能有直观的展现。
特定趋势类型的报表，包括但不限于：
----------基于异常事件的报表；
----------消耗大量资源的SQL或是作业；
----------特定用户、用户群的资源消耗报表；
----------特定应用的资源消耗报表。
查看内存使用情况：
select * from V$SGA;
查看表空间使用情况：
select * from V$TABLESPACE;
监控数据库状态
select * from V$DATABASE;
数据库运行与维护管理
数据库的安装
准备相关知识包括关系数据库理论，操作系统知识，了解数据库产品的特点以及软件、网络和服务器架构。了解目标数据库的专有名词和特定术语，阅读安装手册，特别是安装注意事项。
数据库的卸载
在实际场景中，多发生于数据库的版本升级之前，需要对老版本的数据库进行卸载或者清理。基本步骤：
1、（可选）对数据库进行一次全备。
2、停止数据库服务。
3、卸载数据库。
不同架构场景下
单机，主备或一主多备的卸载方式都是类似的，需要在每个节点上执行相同的卸载操作。
分布式集群的卸载一般使用专有的卸载工具。
卸载后
对于一些客户，数据库卸载后需要对存储介质上的数据再进行销毁处理，保证数据不外泄。
数据库的迁移
需要依据不同的迁移场景需求设计迁移方案。
考虑的要素：
1、迁移可用的时间窗口；
2、迁移可以使用的工具；
3、迁移过程中数据源系统是否停止写入操作；
4、迁移过程的数据源系统和目标系统之间的网络情况如何；
5、根据迁移的数据量估算备份/恢复时间；
6、迁移后，源和目标数据库系统之间的数据一致性稽核。
数据库的扩容
任何一个数据库系统的容量都是在某个时间点的基础上对未来一段时间内的数据量进行估算后确定的，容量不仅仅是数据存储量，还需要考虑以下几个方面：
计算能力不足（整个系统CPU日均繁忙程度>90%）；
响应/并发能力不足（QPS，TPS显著下降，无法满足SLA）；
数据容量不足（可用的数据空间低于15%）。
扩容方案的选择
| 垂直扩容 | 垂直扩容是增加数据库服务器硬件，如增加内存，增大存储，提升网络带宽，提升单机硬件方面性能配置。这种方式相对简单，但是会遭遇单机硬件性能瓶颈。 |
|---|---|
| 水平扩容 | 横向增加服务器数量，利用集群中服务器数量的优势来增加整体系统的性能。 |
| 停机扩容 | 简单，但是时间窗口有限，出现问题会导致扩容失败。而且如果时间过长，不易被客户接受。 |
| 平滑扩容 | 对数据库服务无影响；技术方案相对复杂，尤其数据库服务器数量增多，扩容复杂程度就急剧上升。 |
SLA Service Level Agreement 服务等级协议。在和客户签署合同时，一般会向客户做出一些性能方面的承诺，比如提供的数据库系统应当能够满足1万次/秒的查询，单次查询不超过30毫秒，能够承受3000的并发查询等和数据库相关的服务性指标。
其他还可能包括7*24小时响应等不同方面的服务承诺，根据不同程度要达到的服务水平的协议，称为SLA。
例行维护工作
数据库故障处理
配置数据库监控指标和告警阈值；
针对故障事件的等级设置告警通知流程；
接受告警信息后，根据日志进行故障定位；
对于遇到的问题，应详细记录原始信息；
严格遵守操作规程和行业安全规程；
对于重大操作，在操作前要确认操作可行性，做好相应的备份、应急和安全措施后，由有权限的操作人员执行。
数据库健康巡检
1、查看健康检查任务；
2、管理健康检查报告；
3、修改健康检查配置。