IBM-数据工程-VII-笔记-全-

IBM 数据工程 VII 笔记（全）

001：数据库管理员的一天 👨‍💻

在本节课中，我们将通过一个虚拟人物Rigel的日常工作，了解数据库管理员（DBA）的典型一天。你将能够描述DBA的日常工作流程，并识别他们执行的核心任务。

概述：DBA的一天从何开始？ ☕

Rigel是一名数据库管理员。他的一天从一杯咖啡开始，首要任务是检查他所负责的所有数据库是否都在正常运行，且没有错误。他使用预配置的仪表板来快速、轻松地获取最关键的信息。

今天是个好日子，只有一个轻微警报，Rigel顺利地解决了它。

检查例行任务与备份 📋

上一节我们介绍了DBA如何开始一天的工作，本节中我们来看看他如何确保系统的持续稳定。

接下来，Rigel检查预定的夜间任务是否已执行。他确认了计划备份已经完成，并再次核对了今晚的备份计划。

在确认仪表板和计划备份都没有问题后，Rigel开始查看他的电子邮件，寻找用户请求。这些请求通常以自助服务门户或服务台的工单形式出现。今天，他发现了四个支持工单，以及一封来自市场部开发人员的邮件，请求对某个功能进行改进。

处理用户请求与优化工作 ⚙️

在确认系统状态后，DBA需要处理来自用户和开发者的各种请求。以下是Rigel处理这些请求的步骤：

Rigel对这些支持工单进行分类，并计划如何回应。一些用户请求协助解决运行缓慢的查询，因此Rigel会审查查询计划并提供查询优化帮助。市场部的开发人员请求为一个追踪营销活动结果的数据库添加额外字段。Rigel与她讨论了所需的数据模式更改，并请她通过自助服务门户提交请求，以便跟踪和记录处理过程。

参与规划与资源配置会议 🤝

处理完上午的请求后，Rigel在快速午餐后参加了一个新数据库的规划会议。与会者包括开发人员、数据工程师和数据架构师。他正与他们合作设计一个数据库，旨在确保商业智能工作负载的高读取性能。Rigel将确保为未来的用户增长分配适当的资源，并制定压力测试场景，以找出数据库能承受的最大负载。

像Rigel这样的DBA会使用分析来确定适当的服务器资源，例如存储空间、内存、处理能力和日志文件大小。

配置监控与结束一天的工作 📱

会议结束后，Rigel回到办公桌前完成一天的工作。他花了一些时间配置一个警报，以便在触发时发送到他的手机。这样，他就能立即知晓任何问题。

在他工作时，他持续关注着电子邮件，留意新的支持工单。在收拾东西回家之前，又有几个工单到达，Rigel迅速处理了它们。最后，Rigel做了一些最终检查：他再次查看了仪表板，并确认已正确安排了夜间任务。

对充实的一天感到满意后，Rigel回家了。明天又是新的一天。

总结 📝

本节课中，我们一起学习了数据库管理员典型一天的工作内容。这包括：

  • 检查数据库状态并解决问题。
  • 响应支持工单和用户请求。
  • 与开发人员及其他利益相关者会面协作。
  • 监控数据库活动并配置警报。

这些任务共同确保了数据库系统的稳定性、安全性和高性能。

002：数据库管理生命周期

在本节课中，我们将学习数据库管理生命周期的四个阶段。你将能够识别每个阶段的核心任务，并了解参与决策的关键角色。

🎯 概述

数据库管理生命周期是数据库管理员（DBA）工作的核心框架。它系统地描述了从需求分析到日常运维的完整过程。理解这个生命周期有助于DBA高效、有序地管理数据库系统。

🔍 第一阶段：需求分析

上一节我们介绍了课程概述，本节中我们来看看生命周期的第一个阶段：需求分析。

在这个阶段，DBA（例如Rigel）需要与数据工程师合作，以理解数据库的目的和范围。Rigel及其设计团队必须明确涉及哪些数据，与数据的用户和生产者沟通，并开发用户将如何使用数据的示例，例如报告或仪表板。

Rigel和设计团队与利益相关者合作，以确定他们的需求。利益相关者可能包括：

  • 支持该数据库的应用程序的开发者、数据工程师、管理员或最终用户。
  • 技术经理。
  • 其他DBA。

以下是他们在需求分析阶段可能执行的一些任务：

  • 分析对数据库的需求。
  • 明确数据库要实现的目标。
  • 识别数据库的用户。

📐 第二阶段：设计与规划

在明确了需求之后，接下来进入设计与规划阶段。

在这个阶段，Rigel的工作是制定实施数据库的计划。为此，他需要处理诸如实例、数据库、表和索引等数据库对象。

数据库模型代表了数据库的设计，包括哪个实例包含哪些数据库和表、表之间如何关联、用户如何访问数据等。数据库架构师和DBA借助实体关系图（ERD）来为数据库及其对象建模。

在自管理环境（例如本地部署的数据库）中，DBA还需要考虑规模、容量和增长。他们需要确定适当的服务器资源，如存储空间、内存、处理能力和日志文件大小。他们还需要规划数据库对象的物理存储方式。例如，DBA可以选择将频繁使用的数据存储在高速磁盘阵列上，或者将索引与数据分开存储以获得更好的性能。

🛠️ 第三阶段：实施

设计规划完成后，便进入实施阶段。

在这个阶段，DBA将精心规划的设计付诸实践。Rigel会创建数据库对象，如实例、数据库、表、视图和索引。

Rigel执行的另一项任务是配置数据库安全，为数据库用户、组和角色授予访问权限，确保数据库对象只能由特定的授权用户和应用程序访问。他还会自动化重复的数据库任务，如备份、恢复和部署，以提高效率。

在填充数据库时，他可能会从其他数据库导入数据，从不同源导出数据库或查询，或者将项目从一个环境迁移到另一个环境，例如将项目从应用开发环境移动到生产环境。

🚀 第四阶段：监控与维护

数据库部署上线后，工作重心转向监控与维护。

在这个阶段，Rigel负责数据库的日常运维。他将监控系统以发现长时间运行的查询，并帮助最终用户优化这些查询，使其运行更快且不过度消耗系统资源。

Rigel工作的一个关键部分是审查报告。大多数关系数据库管理系统都有内置报告来监控活动、识别高消耗查询、资源使用情况和其他相关项目。公司通常会在这些报告基础上构建自定义报告，DBA会协助完成这项工作。

为了保持数据库以最高效率运行，Rigel可能还需要为数据库软件应用升级和安全补丁。他需要及时了解该领域的问题和进展，以便能够推荐和实施新兴的数据库技术。

Rigel还可能尽可能自动化部署和例行任务（如备份），以保持流程高效运行。

在每个数据库中，有时会出现操作性问题。Rigel负责对这些问题进行故障排除，并在必要时将问题升级。

DBA负责保护数据安全。Rigel工作的一部分是定期执行用户审计，确保只有授权用户才能进入系统，并且用户只能看到他们应该看到的内容。Rigel会审查日志和警报，寻找失败的登录和数据访问尝试，以识别潜在的威胁和漏洞。他还维护数据库用户和应用程序的权限，撤销不应再拥有访问权限的用户和组的访问权，并根据需要添加新用户和角色以执行其工作。

📝 总结

本节课中，我们一起学习了数据库管理生命周期的四个阶段：需求分析、设计与规划、实施、监控与维护。

  • 在需求分析阶段，DBA通过访谈数据用户和生产者、检查数据并创建样本来确定数据库的目的和范围。
  • 在设计与规划阶段，DBA进行逻辑和物理设计。
  • 在实施阶段，DBA部署数据库。
  • 最后，在监控与维护阶段，DBA管理数据库的日常操作。

理解这个完整的生命周期，是成为一名高效DBA的重要基础。

003：数据库对象 🗂️

在本节课中，我们将学习关系数据库管理系统（RDBMS）中数据库对象的层次结构。我们将了解什么是数据库实例、模式（Schema）以及常见的数据库对象，例如表、约束、索引等。掌握这些概念对于有效组织和管理数据库至关重要。

🏗️ 数据库对象的层次结构

关系数据库管理系统包含许多对象，数据库工程师和数据库管理员必须对它们进行组织。将表、约束、索引和其他数据库对象存储在层次结构中，有助于DBA管理安全性、维护和可访问性。

以下是一个典型的RDBMS层次结构示例，它概述了RDBMS是如何组织的。尽管不同产品之间可能存在细微差异，但大多数RDBMS都从一个实例开始。

🖥️ 数据库实例

一个实例是数据库或一组数据库的逻辑边界，您在其中组织数据库对象并设置配置参数。实例内的每个数据库都被分配一个唯一的名称，拥有自己的一组系统目录表（用于跟踪数据库内的对象），并拥有自己的配置文件。

您可以在同一物理服务器上创建多个实例，为每个实例提供唯一的数据库服务器环境。一个实例内的数据库及其对象与其他任何实例中的对象是隔离的。

以下是使用多个实例的常见场景：

  • 将一个实例用于开发环境，另一个实例用于生产环境。
  • 限制对敏感信息的访问。
  • 控制高级管理访问权限。

并非所有RDBMS都使用实例的概念，它们通常将数据库配置信息管理在一个特殊的数据库中。在基于云的RDBMS中，术语“实例”指的是服务的特定运行副本。

📦 模式

模式是一种专门的数据库对象，它提供了一种逻辑上分组其他数据库对象的方式。一个模式可以包含表、索引、约束和其他对象。

在大多数RDBMS中，当您创建数据库对象时，可以将其分配给一个模式。默认模式通常是当前登录用户的用户模式。

许多RDBMS使用专门的模式来保存特定数据库的配置信息和元数据。例如，系统模式中的表可以存储数据库用户列表及其访问权限、表上的索引信息、存在的任何数据库分区的详细信息以及用户定义的数据库类型。

🧱 数据库对象

数据库对象是存在于数据库中的项目。数据库设计过程包括定义数据库对象及其相互关系。

您可以通过图形化数据库管理工具、脚本或通过API访问数据库来创建和管理数据库对象。如果使用SQL来创建或管理对象，您将使用数据定义语言（DDL）语句，如 CREATE 或 ALTER。

上一节我们介绍了数据库对象的基本概念，本节中我们来看看常见的数据库对象类型。

以下是常见的数据库对象列表：

  • 表：由行和列组成的逻辑结构，用于存储数据。
  • 约束：业务数据通常需要遵守某些限制或规则，例如，员工编号必须唯一。约束提供了一种强制执行此类规则的方法。
  • 索引：索引是一组指针，用于提高性能并确保数据的唯一性。
  • 键：键唯一标识表中的一行。键使DBA能够定义表之间的关系。
  • 视图：视图提供了一种表示一个或多个表中数据的不同方式。视图不是实际的表，不需要永久存储。
  • 别名：别名是对象（如表）的替代名称。DBA使用别名来提供更短、更简单的名称来引用对象。
  • 事件：事件是数据库对象上的数据操作语言（DML）或数据定义语言（DDL）操作，可以启动触发器。
  • 触发器：触发器定义了一组操作，以响应在指定表上的插入、更新或删除操作而执行。
  • 日志文件：日志文件存储数据库中有关事务的信息。

📝 总结

本节课中我们一起学习了关系数据库管理系统中数据库对象的层次结构。我们了解到：

  • 实例是数据库或一组数据库的逻辑边界，用于组织数据库对象和设置配置参数。
  • 模式是一种专门的数据库对象，它提供了一种逻辑上分组其他数据库对象的方式，并为数据库对象提供了命名上下文。
  • 数据库对象是存在于数据库中的项目，例如表、约束、索引、键、视图、别名、触发器、事件和日志文件。

理解这些核心概念是进行有效数据库管理和设计的基础。

004：系统对象与数据库配置 🛠️

在本节课中，我们将要学习关系数据库管理系统（RDBMS）中的系统对象和数据库配置。我们将了解系统对象如何存储数据库的元数据，以及如何通过配置文件来初始化和调整数据库的运行参数。

系统对象与元数据 📊

上一节我们介绍了数据库的基本管理任务，本节中我们来看看数据库如何存储关于自身的信息。

无论你是想了解新索引是否有帮助、特定时间点的数据库事务量，还是当前连接到数据库的用户，能够反映数据库运行状态的数据都至关重要。RDBMS将关于其数据库的信息（称为元数据）存储在特殊的数据库、模式或目录中。它们存储特定类型的数据库信息，例如数据库或表的名称、列的数据类型或访问权限，这些信息统称为元数据。

用于此信息存储的其他术语包括数据字典和系统目录。RDBMS控制和更新这些系统对象，但你可以查询元数据表来发现数据库中对象的信息。

不同的RDBMS对其元数据存储使用不同的名称。

以下是几种常见RDBMS的元数据存储方式：

  • DB2：使用目录和目录。目录由描述DB2系统中所有已定义对象的表组成。当用户创建、更改或删除任何对象时，DB2会插入、更新或删除描述该对象及其与其他对象关系的目录行。目录包含DB2在正常操作期间使用的内部控制数据，其中包括数据库描述符、应用程序的访问路径以及恢复和实用程序状态信息。
  • MySQL：使用系统模式来存储数据库元数据。例如，每个新的MySQL实例都有四个系统数据库：information_schema、mysql、performance_schema和sys。每个系统数据库都包含多个只读表。
  • PostgreSQL：使用系统目录，这是一个包含表和视图的模式，其中包含数据库中所有其他对象及更多信息的元数据。通过它，你可以发现各种操作何时发生、如何访问表或索引，以及数据库系统是从内存读取信息还是需要从磁盘获取数据。

配置文件与初始化设置 ⚙️

了解了如何查询数据库的元数据后，我们来看看数据库启动时如何获取其初始设置。

在任何数据库安装过程中，你都需要提供参数，例如数据目录的位置、服务监听连接的端口号、内存分配等等。你可以接受默认选项，也可以提供自定义值以适应环境。

数据库安装过程将这些信息保存到称为配置文件或初始化文件的文件中。数据库在启动时使用这些文件中的信息来设置参数。

同样，不同的RDBMS使用不同的文件、文件位置和设置。尽管如此，它们都服务于相同的目的：为数据库启动和运行提供初始配置信息。

配置信息可以包括常规设置，如数据和日志文件的位置以及服务器监听请求的端口。配置信息也可以更侧重于性能，包括内存分配、连接超时和最大数据包大小等设置。

以下是不同RDBMS用于存储配置信息的文件：

  • DB2：使用 SQLDB.CONF 文件。
  • MySQL：在基于Windows的系统上使用 my.ini 文件，在基于Linux的系统上使用 my.cnf 文件。
  • PostgreSQL：使用 postgresql.conf 文件。

修改配置：本地与云端部署 🔄

现在，假设你想在数据库启动后修改这些参数。

在本地部署的RDBMS中，你需要停止数据库服务，修改配置文件，然后重新启动服务，从而使数据库读取修改后的设置。

在基于云的RDBMS中，你在创建数据库时选择配置选项。基于云的系统的一个优势是，你可以在服务运行时通过图形界面扩展许多配置选项，例如存储大小和计算能力，而无需编辑配置文件。

总结 📝

本节课中我们一起学习了系统对象和数据库配置的核心概念。

你了解到系统对象存储了数据库的元数据，你可以查询这些对象以获取有关数据库配置和性能的信息。不同的RDBMS对其系统对象使用不同的名称，大多数使用系统模式、系统表、目录或目录等术语。

配置文件存储数据库初始化时所需的信息。同样，不同的RDBMS对配置文件使用不同的名称，例如 SQLDB.CONF、my.ini 或 postgresql.conf。

在本地部署的RDBMS中，你通过编辑配置文件来更改设置。而在基于云的RDBMS中，你可以动态地扩展设置。

005：数据库存储

在本节课中，我们将要学习数据库存储的核心概念。我们将探讨物理存储与逻辑存储的区别，并深入了解表空间、存储组和分区这三种关键的管理结构及其作用。

🧱 物理存储与逻辑存储

作为数据库管理员，您需要确保数据库拥有足够的存储空间来容纳所有需要存储的数据。您必须确定数据库所需的容量并规划其增长。

在基于云的数据库中，通过API或图形控制台即可扩展存储空间。使用云数据库的优势之一，就是可以非常轻松地按需扩展或缩减存储空间。

在自管理或本地环境中，您同样可以规划存储空间以提升性能，例如将存在资源竞争的组件存储在不同的磁盘上。

关系数据库管理系统将磁盘上数据文件的物理存储与数据库的逻辑设计分离开来，这为管理数据库文件提供了更大的灵活性。您可以通过逻辑对象来管理数据，而无需关心物理存储的细节。

例如，您可以发出备份整个数据库的命令，而无需指定存储该数据库的所有物理磁盘。

📦 表空间及其优势

上一节我们介绍了物理与逻辑存储的分离，本节中我们来看看实现这一分离的核心结构：表空间。

表空间是包含数据库对象（如表、索引、大对象和长数据）的结构。数据库管理员使用表空间，根据数据存储位置来逻辑地组织数据库对象。

表空间定义了逻辑数据库对象与承载这些对象数据的物理存储容器之间的映射关系。一个存储容器可以是一个数据文件、一个目录或一个原始设备。

表空间包含一个或多个数据库对象。例如：

  • Tablespace1 可能包含多个小表。
  • Tablespace2 可能只包含一个大型表。
  • Tablespace3 可能包含频繁使用的索引。

数据库管理员会配置一个或多个存储容器来存储每个表空间。例如：

  • Container1 存储 Tablespace1。
  • Container2 和 Container3 共同存储 Tablespace2。
  • Container4 存储 Tablespace3。

通过结合使用表空间和容器，您可以将逻辑数据库存储与物理存储分开，并管理数据库及其对象的磁盘布局。这带来了以下几大好处：

以下是表空间的主要优势：

  1. 性能优化：您可以使用表空间来优化性能。例如，可以将频繁使用的索引放在快速的SSD上；反之，可以将包含很少访问或已归档数据的表存储在更便宜但速度较慢的机械硬盘上。
  2. 可恢复性：表空间使备份和恢复操作更加便捷。使用一条命令，您就可以备份或恢复所有数据库对象，而无需担心每个对象或表空间存储在哪个存储容器上。
  3. 存储管理：关系数据库管理系统会根据需要创建和扩展数据文件或容器。必要时，您也可以通过向表空间添加另一个存储路径或容器来手动扩展存储空间。

🌡️ 存储组及其功能

上一节我们了解了如何用表空间组织数据，本节中我们来看看如何根据数据特性进一步分组管理存储。

一些关系数据库管理系统提供了存储组功能。存储组是根据相似的性能特征对存储路径或容器进行的分组。这使您可以更轻松地执行多温数据管理。

在此上下文中，“温度”指的是数据访问的频率：

  • 热数据：访问非常频繁。
  • 温数据：访问较为频繁。
  • 冷数据：很少被访问。

通过使用存储组，您可以基于温度来组织数据和存储。例如：

  • 访问非常频繁的热表可以放在表空间 H 中，该表空间分布在一组快速的存储设备上。
  • 访问较为频繁的表可以放在表空间 W1 和 W2 中，存储在一个温存储组里。
  • 访问最不频繁的表可以放在表空间 C 中，存储在速度较慢、成本较低的冷存储组设备上。

使用存储组有助于优化频繁访问数据的性能，并降低存储不常访问数据的成本。

🧩 数据库分区及其应用场景

在管理超大规模数据时，仅仅分组可能还不够。本节我们将探讨一种更高级的技术：数据库分区。

分区关系数据库是指其数据跨多个数据库分区进行管理的关系数据库。您可以将需要包含大量数据的表划分为多个逻辑分区，每个分区包含整体数据的一个子集。

数据库分区常用于涉及海量数据的场景，例如数据仓库和商业智能数据分析。

📝 总结

本节课中我们一起学习了数据库存储管理的核心概念。

我们了解到，数据库存储通过逻辑数据库对象和物理磁盘文件进行管理。表空间是根据数据存储位置来组织数据库对象的结构。存储组是根据相似性能特征对存储路径或容器进行的分组，便于实施多温数据管理。而分区则用于存储超大型数据库的数据子集，以提升性能。

掌握这些概念，将帮助您更有效地规划、优化和管理数据库的存储资源。

006：备份与恢复简介 💾

在本节课中，我们将要学习数据库管理中至关重要的一个环节：备份与恢复。我们将了解其常见应用场景、不同类型的备份方式，以及执行备份与恢复操作时需要考虑的关键因素。

概述

备份与恢复是数据库领域的核心话题。它不仅是防止数据丢失的关键手段，也是数据迁移、系统测试等场景下的常用操作。理解其原理和最佳实践，对于保障数据安全与业务连续性至关重要。

备份与恢复的应用场景

上一节我们介绍了备份与恢复的基本概念，本节中我们来看看它的具体应用场景。

通常，备份与恢复用于在意外停机、误删除或数据损坏后恢复数据。然而，作为数据工程师，您可能还会在其他场景下进行这些操作。

以下是备份与恢复的几种常见用途：

  • 将数据从一个数据库迁移到另一个数据库。
  • 更换关系数据库管理系统。
  • 与业务伙伴共享数据或从其加载数据。
  • 为开发或测试环境创建数据副本。

物理备份与逻辑备份

了解了应用场景后，我们来探讨两种主要的备份类型：物理备份和逻辑备份。理解它们的区别有助于您根据实际情况选择最合适的策略。

逻辑备份会创建一个包含DDL（如 CREATE TABLE）和DML命令（如 INSERT）的文件，用于在数据库中重新创建对象和数据。因此，您可以使用此文件在相同或不同的系统上重建数据库。

逻辑备份的特点如下：

  • 恢复过程会创建表的“干净”版本，从而回收原数据库中的浪费空间。
  • 对于大型数据库，备份可能耗时较长，并可能影响其他并发查询的性能。
  • 支持细粒度备份，例如可以单独备份某个数据库或表。
  • 通常使用 BACKUP、RESTORE、IMPORT、EXPORT、DUMP 和 LOAD 等实用程序来执行。

物理备份（或称原始备份）会复制属于表、数据库或其他对象的所有物理存储文件和目录，包括数据文件、配置文件和用于辅助时间点恢复的日志文件。

物理备份的特点如下：

  • 通常比逻辑备份更小、更快。
  • 适用于需要快速恢复的大型或重要数据库。
  • 类似于备份物理系统上的任何其他类型文件。
  • 如果物理文件包含多个对象的数据，则无法轻松恢复单个表或数据库对象。
  • 备份文件与特定的RDBMS相关，通常只能恢复到相似的系统。
  • 这种存储级快照的方法常见于使用专用存储系统的数据库和云环境中。

可备份的对象与策略考量

现在我们已经了解了两种备份类型，接下来看看在数据库中具体可以对哪些对象进行备份，以及制定备份策略时需要考虑哪些因素。

根据您使用的RDBMS和执行的备份类型，您可以备份以下内容：

  • 整个数据库。
  • 一个模式（Schema）中的所有内容。
  • 数据库中的一个或多个表。
  • 数据库一个或多个表中的数据子集。
  • 数据库中的其他对象集合。

同时，您还可以选择备份的频率和类型，从而定制完全符合需求的备份策略。

在执行备份与恢复时，请记住以下几点：

  • 必须检查备份文件是否有效，并确保恢复计划能够成功执行。 这在将备份恢复作为灾难恢复计划的一部分时至关重要，无效的备份或无法恢复将导致数据丢失。
  • 必须确保备份文件在传输和存储过程中的安全级别，与数据库内数据的安全级别相同。

高级备份选项

除了基本操作，一些RDBMS还支持额外的备份选项，可以帮助您优化备份过程。

以下是两种常见的高级选项：

  • 压缩：您可以配置备份文件的压缩级别。压缩会减小输出文件的大小，这对于大型数据库或备份到远程位置非常有用。但代价是会增加执行备份和恢复过程所需的时间。
  • 加密：您可以加密备份文件以降低数据泄露的风险。同样，这也会增加备份和恢复所需的时间。

总结

本节课中我们一起学习了数据库备份与恢复的核心知识。

我们了解到，备份与恢复不仅用于数据恢复，还可用于数据迁移等多种目的。物理备份复制原始的数据库存储文件和目录，而逻辑备份则以特殊格式从数据库中提取数据。您可以备份整个数据库或其内部对象。务必确保备份安全可用，且恢复计划有效可行。此外，还可以利用压缩或加密等备份选项来优化操作。

掌握这些基础知识，是您实施可靠数据保护策略的第一步。

007：备份类型 💾

在本节课中，我们将要学习数据库备份的几种常见类型。我们将了解每种备份方式的工作原理、优点和缺点，帮助你为你的数据库系统选择合适的备份策略。

概述

备份是数据库管理中的核心任务，旨在保护数据免受意外丢失或损坏。根据数据量、变化频率和恢复时间目标的不同，可以选择不同类型的备份策略。常见的备份类型包括完全备份、时间点恢复、差异备份和增量备份。

完全备份

完全备份会创建你所备份对象中所有数据的完整副本。

核心概念：完全备份 = 数据库在备份时刻的完整快照

完全备份简化了恢复过程，因为你只需要找到最新的完全备份文件并恢复它即可。然而，随着数据库规模的增长，备份所需的时间、网络带宽和存储空间也会相应增加。

以下是完全备份的主要优缺点：

  • 优点：恢复过程简单直接。
  • 缺点：备份和存储成本高，尤其是对于大型数据库；如果只保留一份备份，文件损坏将导致无法恢复。

将数据的完整副本存储在数据库管理系统之外，意味着你必须确保其得到充分保护，防止未授权用户访问。当你恢复一个完全备份时，数据库将回到备份被创建时的状态。但自备份以来数据库可能已经处理了许多事务，理想情况下这些事务也应该被恢复。

时间点恢复

为了解决上述问题，一种方法是在数据库中启用事务日志记录。然后，你可以利用日志文件中的信息，在恢复的数据库上重新应用这些事务。

核心概念：恢复后状态 = 完全备份状态 + 应用至特定时间点的事务日志

在恢复数据库备份后重新应用事务的过程被称为“恢复”。它使你能够将数据恢复到某个特定时间点的状态，因此得名“时间点恢复”。

例如，如果你知道在上午11:05运行的一条DELETE语句错误地删除了某些数据，你可以恢复最新的完全备份，然后重新应用截至该时间点的事务，从而最大限度地减少从上次完全备份到错误数据被删除之间发生的数据变更损失。

不同的数据库系统对包含事务信息的日志使用不同的术语：

  • MySQL 称之为 二进制日志。
  • PostgreSQL 称之为 预写日志。
  • DB2 on Cloud 称之为 事务日志。

差异备份

由于完全备份可能需要大量的时间、带宽和存储空间，一种替代方案是将其与差异备份结合使用。

差异备份包含自上次完全备份以来发生更改的任何数据的副本。

核心概念：差异备份内容 = 自上次完全备份以来的所有数据变更

这使得差异备份文件比完全备份文件小得多，从而减少了备份所需的时间、带宽和存储，同时仍能让你恢复数据的近期副本。

例如，你可以在每周日执行一次完全备份，然后在周内的每一天运行一次差异备份。每个差异备份都包含自周日完全备份以来的所有变更。

因此，如果你需要在周二恢复数据库，你需要先恢复周日的完全备份，然后恢复周二的差异备份。你不需要恢复周一的差异备份，因为该文件中的所有变更也包含在周二的差异备份中。

从完全备份和差异备份恢复数据比仅恢复一个完全备份需要更长的时间。但由于你恢复数据的频率远低于备份频率，总体来看你很可能节省了时间。

增量备份

增量备份与差异备份类似，但它只包含自上次任何类型的备份以来发生更改的数据。

核心概念：增量备份内容 = 自上次备份（无论何种类型）以来的数据变更

例如，你可以在每周日执行一次完全备份，然后在周内的每一天运行一次增量备份。每个增量备份只包含自前一天备份以来的变更。

因此，如果你需要在周二恢复数据库，你需要先恢复周日的完全备份，然后恢复周一的增量备份，最后恢复周二的增量备份。

从完全备份和增量备份恢复数据比仅恢复一个完全备份或恢复差异备份需要更长的时间。但执行增量备份所需的时间可能比执行差异备份更少。

总结

本节课中我们一起学习了四种主要的数据库备份类型：

  1. 完全备份：创建简单，恢复直接，但执行速度慢且生成的文件大。
  2. 时间点恢复：通过结合事务日志，提供了比仅使用完全备份更精细的恢复模型。
  3. 差异备份：比完全备份执行更快，但恢复过程可能更耗时。
  4. 增量备份：执行速度最快，但恢复过程可能最耗时。

理解这些备份类型的区别，有助于你根据具体的业务需求、数据变化率和恢复时间目标，设计出高效、可靠的数据库备份与恢复策略。

008：备份策略

在本节课中，我们将要学习数据库备份策略的核心概念，包括热备份与冷备份的区别，以及如何根据业务需求制定合适的备份策略。

🔥 热备份与❄️ 冷备份

上一节我们介绍了备份的基本类型，本节中我们来看看两种主要的备份执行方式：热备份和冷备份。

热备份，也称为在线备份，是在数据库处于活动和使用状态时执行的备份。其核心优势在于备份期间不影响数据库的可用性，用户可以持续进行业务操作。然而，热备份也存在一些挑战：备份过程可能导致用户性能下降，并且如果备份期间数据发生变更，可能影响备份数据的完整性。

冷备份，也称为离线备份，是在数据库完全离线、停止服务时执行的备份。这种方式彻底消除了热备份中数据变更带来的完整性风险。但其主要缺点是备份期间用户无法访问数据库，因此不适用于需要7x24小时不间断运行的环境。

💾 备份存储与恢复考量

了解了备份的执行方式后，我们需要考虑备份数据的存储位置及其对恢复的影响。

热备份通常存储在可用的备用服务器上，并且会定期从生产数据库接收更新。这种安排使得当生产服务器发生故障时，可以快速将备用服务器上线，从而保障业务的持续可用性。

冷备份则倾向于存储在外部驱动器上，或存储在两次备份操作之间处于关机状态的服务器上。这种方式通常能提供更高的数据安全性，但也意味着恢复过程所需的时间会比热备份更长。

⚙️ 制定备份策略的关键决策

制定备份和恢复策略时，你需要做出多项决策。以下是需要考虑的核心要素列表：

  • 备份方式：选择物理备份或逻辑备份。
  • 备份类型：决定使用完全备份、差异备份还是增量备份。
  • 执行方式：采用热备份还是冷备份。
  • 数据处理：是否对备份数据进行压缩和加密。

除了上述技术选择，你还需要考虑以下业务层面的因素：

  • 备份频率：这取决于数据丢失对业务的影响程度，以及数据变化的频率。例如，产品信息表的变化频率通常低于客户订单表，因此可以降低前者的备份频率。对于数据量庞大的订单表，频繁进行完全备份并不现实，应考虑使用差异备份或增量备份。
  • 备份时机：如果数据主要在一个时区的工作时间内被访问，应将备份安排在非工作时间进行。对于全天候访问的数据，可以考虑在周末执行完全备份，在工作日进行增量或差异备份。
  • 自动化：备份是一项常规任务，如果关系数据库管理系统支持调度或自动化备份功能，应充分利用。

☁️ 云数据库的备份

将数据库部署在云端时，备份同样至关重要。根据所使用的具体关系数据库管理系统和云服务商，备份的实现方式可能有所不同。

  • 在某些情况下，备份可能自动运行。
  • 你可能需要手动启用自动备份功能。
  • 你也可能需要执行手动备份，或者运用本节课学到的知识来运行自己的备份策略。

例如：

  • Db2 on Cloud 的付费计划每天会自动执行一次加密备份。在企业版或标准版计划中，你还可以运行手动备份并执行时间点恢复。
  • 在使用 Google Cloud SQL（支持 MySQL、PostgreSQL 和 SQL Server）时，你可以启用自动增量备份，也可以执行按需备份。

如果你的特定关系数据库管理系统和云服务商组合不支持上述任何选项，市场上也有可供购买的第三方备份工具。

📝 课程总结

本节课中，我们一起学习了数据库备份策略的核心内容。

我们了解到，热备份（在线备份） 允许在数据库活动时进行备份，而冷备份则要求数据库离线。你的备份策略应根据恢复需求、可用性要求以及数据使用模式来确定。最后，大多数托管的云数据库服务都提供了自动备份功能，并带有一些可配置的选项，这大大简化了备份管理工作。

009：使用数据库事务日志进行恢复 📊

在本节课中，我们将学习数据库事务日志的核心概念、主要用途、存储位置、访问方式以及典型结构。事务日志是数据库恢复的关键工具，理解其工作原理对于数据库管理员至关重要。

概述

数据库管理系统使用事务日志来追踪所有更改或修改数据库的事务。这些日志中存储的信息可用于在数据意外删除或发生系统/硬件故障时进行恢复。通过结合数据库备份，事务日志可以帮助将数据库恢复到特定时间点的一致状态。

事务日志的主要用途

上一节我们介绍了事务日志的基本概念，本节中我们来看看它的核心用途。

事务日志主要用于数据库恢复。例如，考虑以下时间线场景：

  • 在时间 T1，执行备份命令，生成数据库的完整副本。
  • 用户继续工作，其活动信息被记录在事务日志中。
  • 在时间 T2，发生问题导致数据库损坏。
  • 在时间 T3，使用在 T1 时刻创建的备份映像执行恢复命令。这可以将数据库恢复到备份时的状态。
  • 在时间 T4，将 T1 到 T2 期间的事务日志应用到已恢复的数据库。这个应用已提交事务的过程称为前滚恢复，它可以将数据库恢复到故障发生前的状态。

事务日志的存储与访问

了解了事务日志的恢复用途后，接下来我们探讨其存储位置和访问方式。

通常通过数据库配置来指定事务日志文件的存储位置。以下是一些示例：

  • 在DB2中，事务日志文件可能位于Windows系统的 SQLLOGDIR 子目录下。
  • 在PostgreSQL中，日志文件默认存储在 pg_xlog 子目录。PostgreSQL中的事务日志文件称为预写日志，因为数据库管理器在将更改写入数据库文件之前，会先将其写入WAL。

一个推荐的最佳实践（至少对于生产数据库）是将事务日志文件存储在与数据库对象（如表空间）不同的存储卷上。这不仅能提升性能（避免数据库写入与日志写入竞争资源），还能提高可恢复性，因为它将日志与可能发生的数据库卷崩溃或损坏隔离开来。

对于业务关键型数据库，为了进一步增强可恢复性，一些关系数据库管理系统提供了将日志自动镜像到第二套存储设备的能力，或者可以通过编写脚本将日志复制或传送到远程副本或备用系统，这个过程称为日志传送。

事务日志的配置与结构

现在我们已经知道日志存储在哪里，本节中我们来了解如何配置以及日志内部的结构。

在许多RDBMS（如DB2和SQL Server）中，事务日志记录默认是启用的，但你仍可能希望更改默认设置以改进可恢复性和性能。在其他RDBMS（如MySQL）中，事务日志记录默认是禁用的，可能需要手动配置。

对于MySQL，你可以运行以下命令来检查日志记录是否启用：

SHOW BINARY LOGS;

如果已启用，你将看到日志文件列表。

与其他类型（如诊断和错误日志）多为文本格式、人类可读的日志不同，数据库事务日志通常采用二进制格式，有时会加密，需要专用工具来格式化和显示内容。

以下是查看日志内容的工具示例：

  • 在MySQL中，使用 mysqlbinlog 工具查看MySQL事务日志文件（也称为二进制日志）的内容。示例输出可能显示一条INSERT语句的日志文件条目。
  • 在DB2中，使用 db2fmtlog 工具来格式化和显示日志文件信息。示例输出可能显示一条用于创建表的DDL语句记录。

一个日志文件包含多个条目，其包含的信息可能因RDBMS而异。例如，DB2中一个典型的数据库日志记录由以下部分组成：

以下是DB2日志记录的典型结构组件：

  • 日志事务ID号：日志记录的唯一ID。
  • 数据库记录类型：描述数据库日志记录的类型。
  • 日志序列号：指向生成此日志记录的数据库事务的引用。
  • 前一个日志序列号：指向上一条日志记录的链接。这意味着数据库日志是以链表形式构建的。
  • 信息：详细说明触发写入此日志记录的实际更改。

总结

本节课中我们一起学习了数据库事务日志的关键知识。我们了解到，事务日志用于追踪所有更改数据库结构以及记录在数据库中插入、更新或删除数据的事务。在发生系统故障、磁盘损坏或意外删除时，事务日志通过应用或重放日志中的事务，协助数据库恢复，可以将数据库前滚到灾难事件发生前的某个时间点。一个良好的实践是通过更改数据库配置中的默认设置，将日志文件存储在与数据库卷分离的位置。事务日志的格式因RDBMS而异，但每个日志条目通常包含一个日志记录ID以及有关修改数据库的数据库活动或事务的详细信息。

010：数据库安全概述 🔒

在本节课中，我们将要学习数据库安全的基础知识。我们将探讨数据库安全的不同层面，理解认证与授权的区别，并了解如何通过审计、加密和应用安全来增强数据库的安全性。

概述

确保存储在系统中的数据安全是数据库管理角色的重要组成部分。这涉及识别数据的潜在风险，并通过在系统各个层面应用安全措施和控制来缓解这些风险。即使某些层面的措施实施可能不是你的直接责任，评估这些措施对于你存储或访问的数据是否足够也至关重要。

数据库安全的层级

上一节我们介绍了数据库安全的重要性，本节中我们来看看构成数据库安全体系的几个关键层级。

物理服务器安全 🖥️

首先，你需要确保系统中的实际服务器在物理上是安全的。对于本地服务器，你应该评估谁可以访问服务器所在地点以及现有的安全措施。如果你使用的是托管的云环境，你的提供商将负责此级别的安全。

操作系统安全 💾

接下来，你应该考虑托管数据库的操作系统。你需要确保它定期打上经过测试的最新补丁，使用已知的配置进行加固以减少漏洞，并持续监控任何未经授权的访问。

关系数据库管理系统安全 🗄️

你应该对RDBMS采取与操作系统类似的措施。你应该定期应用经过测试的最新更新，审查并使用系统中所有可用的安全功能和配置选项，并且确保只有一小部分受信任的用户拥有管理权限。

用户访问控制：认证与授权

在确保基础设施安全之后，我们需要管理谁可以访问数据。这涉及两个核心概念：认证和授权。

认证：验证身份 🔑

用户和客户端应用程序需要被允许访问服务器、数据库及其中的对象。首先，用户需要在服务器或数据库上进行认证，以启用其访问权限。

数据库认证类似于你使用PIN码或指纹访问手机，或使用密码访问电脑的过程。这是一个验证用户是否为其所声称身份的过程，例如，通过验证用户名和密码等凭据。

一些数据库系统允许你使用操作系统或其他凭据对数据库进行认证。例如，你可以使用外部认证方法，如可插拔认证模块、Windows登录ID、轻量级目录访问协议或Kerberos。

授权：授予权限 📋

即使用户在数据库上通过了认证，他们仍然需要被授权才能访问数据库中的对象和数据。你通过授予用户访问对象和数据的权限或特权来授权他们。

由于用户组通常需要相同的访问权限，在大多数RDBMS中，你可以将特权授予在数据库中承担特定角色的用户组。

以下是分配权限时可能涉及的操作，具体取决于你正在处理的对象：

  • 对于表：你可以允许用户SELECT（查询）、INSERT（插入）、UPDATE（更新）或DELETE（删除）数据，或者ALTER（更改）表的结构。
  • 更细粒度控制：在一些RDBMS中，你甚至可以进一步细化到基于列来分配权限。

你应该始终遵循最小权限原则，即只允许用户访问完成其任务所需的最少量数据。

增强安全措施

除了限制用户只能访问其角色所需的信息和对象外，你还应考虑监控和审计数据库活动。

审计与监控 📊

你应该跟踪哪些用户访问了服务器或数据库以及他们执行的操作。根据你的安全计划分析这些信息，可以提醒你其中存在的漏洞。

数据加密 🔐

在保护系统和数据以及审计访问之外，你还可以考虑使用加密为安全系统增加另一层保护。如果入侵者确实设法访问了数据，他们还必须解密数据才能使用它。

某些行业法规和地区立法要求对敏感数据使用特定级别的加密。在规划数据库安全时，检查此类法规对算法和密钥管理的要求非常重要。但请记住，加密和解密数据可能是一项耗时且耗费资源的操作，因此你需要考虑这对你运营的影响，以及是否需要相应地升级硬件。

应用安全 🛡️

即使是最安全的操作系统和RDBMS组合，也可能因松懈的应用程序安全（如SQL注入字符串和不安全的代码）而受到威胁。因此，测试和监控与你的数据和数据库交互的任何应用程序的安全性非常重要。

总结

本节课中我们一起学习了数据库安全的核心内容。

你了解到，在保护数据库时，需要考虑服务器和操作系统的安全，以及数据库和数据本身的安全。用户需要在服务器或数据库上进行认证才能访问它；用户需要被授权，即被授予权限或特权才能访问数据库中的对象和数据。你应该使用最小权限原则来减少对数据的访问。监控和审计数据库活动可以提醒你威胁和安全漏洞。加密可以通过使任何被泄露的数据更难读取来加强你的数据安全性。数据安全还包括保护你的应用程序。

011：用户、组与角色 🔐

在本节课中，我们将学习数据库安全管理的核心概念：用户、组与角色。我们将了解它们各自的定义、如何协同工作，以及如何利用它们来高效管理数据库安全对象。

👤 数据库用户

数据库用户是被允许访问特定数据库对象的用户账户。根据数据库管理系统（DBMS）和安全策略的不同，用户可能直接在数据库系统中被显式创建和认证，也可能在外部创建，并使用外部认证方式进行认证，例如操作系统或外部身份管理服务（如Kerberos、LDAP和云IAM）。

当首次创建用户时，除非他们是数据库的创建者，否则通常几乎没有任何实际与数据库对象交互的权限。

用户名称存储在系统表或目录表中，不应尝试直接编辑这些表。所有关系型数据库管理系统（RDBMS）都会提供SQL命令和/或用户界面工具，供您管理用户。

👥 用户组

上一节我们介绍了单个用户，本节中我们来看看如何将用户组织起来。一些RDBMS支持用户组的概念。在某些情况下，例如PostgreSQL，您在数据库中定义组，它们是用户的逻辑分组，旨在简化用户管理。在其他系统（如SQL Server和DB2）中，您可以将数据库组映射到底层操作系统中的管理组。当您使用该操作系统对用户进行身份验证时，这尤其有用。

类似地，如果您在Amazon关系数据库服务（RDS）等平台上运行数据库，则可以使用虚拟私有云（VPC）安全组和数据库（DB）安全组来管理用户访问。

以下是用户组的主要作用：

  • 简化权限管理，将权限分配给组而非单个用户。
  • 便于基于组织结构或职能划分用户。
  • 在某些系统中，可以与外部身份管理系统集成。

🎭 数据库角色

数据库角色与数据库组类似，它们将权限和访问权授予该角色的所有用户。数据库角色定义了在数据库中执行特定角色所需的一组权限。例如，备份操作员角色将拥有访问数据库和执行备份功能的权限。

一些RDBMS提供了一组预定义角色供您分配给用户，例如数据库所有者或备份操作员角色。大多数系统还允许您创建自定义角色。因此，您可以创建一个“销售人员”角色，该角色拥有销售人员对数据库中相关表所需的所有权限。

⚙️ 组与角色的协同工作

将权限分配给组或角色，而非单个用户，可以极大地简化安全管理任务。如果您知道一组用户都需要相同的功能来完成其工作角色，您可以将这些用户放入一个组，并将相关权限分配给该组。如果未来工作角色发生变化，向组添加新权限比向单个用户添加更快、更容易且更不易出错。

同样，如果有新员工加入团队，您只需将其添加到相应的角色或组中，而无需逐一分配所有单独的权限。一个用户可以是一个或多个角色的成员。例如，销售团队的负责人可以是“团队负责人”角色和“销售人员”角色的成员。

在实施角色或组成员资格时，请记住遵循最小权限原则：只将用户添加到他们需要成为成员的组中，并确保您的角色不包含其中大多数用户不需要的任何权限。在后一种情况下，您应重新评估角色权限，并创建多个更细粒度的角色或组。

📝 总结

本节课中我们一起学习了数据库安全管理的基础。我们了解到，根据数据库的不同，您可以直接在数据库系统中创建和认证用户，或使用操作系统等外部认证。在一些系统中，您在数据库中定义组来管理用户；而在另一些系统中，您可以将数据库组映射到操作系统组。您可以使用预定义的数据库角色为常见的数据库用户集分配权限，也可以根据自身需求定义自定义角色。最重要的是，组和角色的使用极大地简化了用户管理，提高了安全策略的效率和一致性。

012：管理对数据库及其对象的访问 🔐

在本节课中，我们将要学习如何管理用户对数据库及其内部对象（如表、存储过程等）的访问权限。具体来说，我们将了解如何授予、撤销和拒绝访问权限。

用户通过身份验证登录数据库后，需要获得相应的权限或特权才能访问数据库中的对象和数据。

权限可以授予给单个用户，也可以授予给组或角色。一个用户的最终权限，是其个人权限与其所属组或角色的权限的组合。

在本视频中，你将看到通用的SQL语句示例。请注意，你所使用的RDBMS（关系数据库管理系统）的语法可能与示例略有不同，并且很可能也提供了图形界面选项来执行这些任务。

授予数据库连接权限

上一节我们介绍了权限的基本概念，本节中我们来看看如何授予用户连接数据库的权限。

在一些系统中，用户是在数据库外部（例如操作系统或通过外部插件）进行身份验证的。对于这些用户，你可能还需要授予他们访问特定数据库的权限。你可以使用SQL的 GRANT CONNECT 命令来实现。

以下是授予组或角色连接权限的示例：

GRANT CONNECT ON DATABASE MyDB TO GROUP sales_team;

要授予单个用户（而非组或角色）连接权限，只需将组名替换为用户名即可。

GRANT CONNECT ON DATABASE MyDB TO USER john_doe;

如果你的RDBMS提供了访客（guest）或公共（public）账户，你可能会发现默认情况下它们拥有连接所有数据库的权限。在这种情况下，最佳实践是撤销该权限，以确保只有被明确授予权限的用户才能访问你的数据。

授予对数据库对象的权限

现在我们已经了解了如何连接数据库，接下来看看如何控制对数据库内部对象的操作。

你可以使用SQL的 GRANT 命令来授予对数据库中表的权限。以下示例授予 sales_team 组在 MyDB 数据库的 MyTable 表上的 SELECT 权限。

GRANT SELECT ON MyDB.MyTable TO GROUP sales_team;

你可以使用类似的语句，通过授予用户在表上的相关权限，来允许他们插入、更新和删除数据。

GRANT INSERT, UPDATE, DELETE ON MyDB.MyTable TO GROUP sales_team;

要将这些权限授予单个用户，只需将组名 sales_team 替换为该用户的用户名。

你还可以使用 GRANT 语句授予在数据库中创建对象的权限。以下示例展示了如何启用一个组或角色来创建表。

GRANT CREATE TABLE ON DATABASE MyDB TO ROLE developer_role;

同样，你可以使用类似的语句来允许用户创建表或存储过程等对象。

对于存储过程或函数，你可以允许用户或组查看其代码。这意味着他们可以查看该函数或过程的定义，但无法运行或更改它。

GRANT VIEW DEFINITION ON PROCEDURE MyDB.MyProc TO USER analyst_jane;

要运行代码，用户需要 EXECUTE 权限；要更改过程的定义，用户需要 ALTER 权限。

GRANT EXECUTE ON PROCEDURE MyDB.MyProc TO USER analyst_jane;
GRANT ALTER ON PROCEDURE MyDB.MyProc TO ROLE admin_role;

撤销与拒绝权限

除了授予权限，有时你可能需要移除它们。你可以使用 REVOKE 语句来移除已授予的权限，大多数RDBMS也会在用户界面中提供撤销功能。

以下是撤销权限的示例：

REVOKE SELECT ON MyDB.MyTable FROM GROUP sales_team;

然而，由于个人的权限是其所属所有组或角色权限的组合，sales_team 角色的成员可能仍能通过其所属的另一个角色访问此表。

如果你想确保用户对某个对象或操作没有权限，可以使用 DENY 语句来覆盖之前授予的任何该权限。DENY 的优先级通常高于 GRANT。

以下是拒绝权限的示例：

DENY SELECT ON MyDB.MyTable TO USER restricted_user;

总结

本节课中我们一起学习了数据库访问权限管理的核心操作。

  • 你学会了将权限授予用户、组或角色。
  • 权限控制着对数据库及其内部对象的访问。
  • 从 SELECT、INSERT、UPDATE、DELETE 到 CREATE、ALTER、DROP 等一系列针对不同类型对象的权限，允许对用户、组和角色的访问进行精细调整。
  • 你可以撤销先前授予的权限。
  • 你可以通过拒绝权限来覆盖现有的已授予权限。

通过合理运用授予、撤销和拒绝这三种操作，你可以构建一个安全、可控的数据库访问环境。

013：审计数据库活动 🔍

在本节课中，我们将要学习数据库审计的重要性、如何审计数据库访问以及如何审计数据库活动。审计是任何安全计划的关键部分，它能帮助我们识别安全系统中的漏洞，并跟踪权限管理中的错误。

概述 📋

审计或监控数据库活动是任何安全计划的关键部分。尽管审计不能直接保护数据库，但它可以帮助您识别安全系统中的漏洞，并跟踪权限管理中的错误。

在某些行业和国家，审计对敏感数据的访问甚至是一项要求。您应该考虑在所有数据库解决方案中实施审计，无论它们是本地部署还是在云端。审计数据库涉及记录数据库用户对数据库对象的访问和活动。通过审查这些记录（也称为日志），您可以识别可疑活动，并快速应对发现的安全威胁。

审计数据库访问 🔐

上一节我们介绍了审计的概述，本节中我们来看看如何审计数据库访问。

如果未经授权的用户访问了您的数据库，这意味着他们已经突破了您系统中的一个或多个安全层级。因此，必须跟踪谁访问了您的数据库，并审查这些信息以识别任何未经授权的用户。您还应该跟踪访问数据库的失败尝试，因为这可以帮助您识别潜在的攻击，例如对您系统的暴力破解尝试。

大多数数据库系统都提供了可用于审计数据库访问的功能。以下是两个例子：

  • 在 DB2 on Cloud 中，您可以使用内置审计工具的用户验证类别来记录用户身份验证事件。
  • 在 MySQL 中，审计日志插件会跟踪连接和断开连接事件。

审计数据库活动 📊

了解了如何审计访问后，本节我们将探讨如何审计数据库内部的活动。

有时，授权用户可能会发现他们可以查看和编辑本不应有权限的数据。如果您跟踪所有用户活动，就可以使用输出报告来审查哪些用户访问了哪些表，并检查这些操作是否符合您的安全计划。

为了审计数据库活动，一些关系数据库管理系统（RDBMS）使用触发器。触发器是一种特殊的存储过程，在发生数据操作语言（DML）语句事件（例如插入操作）后会自动记录活动。其他系统允许您将操作附加到数据库中发生的事件上。以下是具体实现方式：

  • 在 DB2 on Cloud 中，您可以使用变更历史事件监视器来启用对特定表或对象的审计。
  • 在 PostgreSQL 中，您可以使用可下载的 PG Audit 工具来记录单个操作类型或数据库中的所有操作。

您应确保所使用的任何审计实施方案都满足客户或所在地区要求的合规性标准。

总结 🎯

本节课中我们一起学习了以下核心要点：

  • 审计不能直接保护您的数据库，但能识别安全漏洞。
  • 某些行业、客户或地区可能要求创建并保留审计日志。
  • 您应该审计访问数据库的成功和失败尝试。
  • 您应该审计并审查数据库中的所有活动。

通过实施有效的审计策略，您可以更好地监控数据库安全状况，及时发现并应对潜在威胁。

014：数据加密 🔐

在本节课中，我们将要学习数据加密的核心概念、方法及其在关系数据库管理中的应用。我们将探讨静态数据与传输中数据的加密、对称与非对称加密的区别，以及透明数据加密和客户托管密钥等高级主题。

概述

数据加密是安全体系中的关键一层，通常是数据泄露时的最后一道防线。它有助于保护静态存储的数据以及在网络中传输的数据。某些行业、地区或特定客户可能要求对特定类型的数据进行加密，例如支付卡行业数据安全标准（PCI DSS）就要求处理、传输或存储信用卡信息的公司必须加密这些数据。

上一节我们介绍了数据库安全的基本框架，本节中我们来看看如何通过加密技术来加固这个框架。

静态数据加密

静态数据指的是存储在关系数据库管理系统（RDBMS）中的数据。对静态数据进行加密至关重要，这可以确保恶意用户即使绕过数据库安全措施直接访问数据文件，也无法读取数据内容。

不同的RDBMS提供不同级别的加密粒度：

  • 数据库级加密：对整个数据库进行加密，通常称为透明数据加密（TDE）。
  • 表或表空间级加密：对单个表或表空间进行加密。
  • 列级加密：提供最精细的粒度和灵活性。

需要注意的是，列级加密虽然灵活，但会带来性能下降和设置复杂性的问题。

加密算法与密钥

数据加密是通过使用算法将数据转换为不可读的字符串（称为密文）来实现的。这些算法使用一个密钥来确保没有密钥的人无法解读文本。

以下是两种主要的加密类型：

对称加密

对称加密是最简单的加密形式，它使用同一个密钥来加密和解密数据。

公式表示：密文 = 加密算法(明文, 密钥)；明文 = 解密算法(密文, 密钥)

数据加密标准（DES）和高级加密标准（AES）都使用对称密钥。由于只使用一个密钥，该密钥必须在所有需要访问数据的参与方之间共享，以便他们都能解密数据。共享密钥增加了密钥泄露的风险，一旦加密密钥泄露，数据也就随之泄露。

非对称加密

非对称加密，也称为公钥加密，使用两个密钥：一个公钥和一个私钥，合称为密钥对。

公式表示：密文 = 加密算法(明文, 公钥)；明文 = 解密算法(密文, 私钥)

数据使用公钥加密，而有效的用户则持有唯一匹配的私钥来解密。RSA和椭圆曲线密码学（ECC）都是非对称加密的例子。由于涉及多个私钥，确保这些密钥的安全存储至关重要。

透明数据加密

大多数现代数据库都为你处理了加密和密钥管理的复杂性，许多数据库支持透明数据加密。其“透明”部分意味着加密和解密过程对用户是不可见的。数据库引擎在存储数据前对其进行加密，然后在授权用户或应用程序请求信息时将其解密。

因为数据库引擎执行加密任务，所以它也会加密你的数据库备份。

客户托管密钥

尽管TDE简化了数据库加密过程，但你可能对在云中存储数据以及将密钥管理过程交给第三方有所顾虑。一些云数据库支持客户托管密钥，也称为“自带密钥”（BYOK）协议。

这提供了职责分离：云数据库系统负责加密过程，但你保留对其所用密钥的控制权。BYOK通过确保存储和加密你数据的云平台无法访问解密密钥，从而无法访问你的机密数据，提供了额外的保护层。它还使你的安全管理员能够管理公司密钥，而数据库管理员可以继续管理数据。对于客户在密钥轮换和过期方面有法规遵从性要求的企业，这提供了对密钥及其生命周期的完全控制。

加密与性能权衡

一些RDBMS同时支持对称和非对称加密，并允许你配置使用哪种。由于算法处理数据需要时间和资源，任何类型的加密和解密都会降低数据库的性能。

因为非对称算法通常使用更长的密钥，它们往往比对称算法对性能的影响更大。因此，除非你特别需要非对称加密，否则通常最好使用AES和DES等对称算法。事实上，对于前面提到的PCI DSS信用卡示例，AES是推荐的方法。

传输中数据加密

除了加密静态数据，你还应考虑加密传输中的数据，即数据在网络或互联网上传输时。

与静态数据加密类似，许多RDBMS为你提供此功能。一些云数据库使用传输层安全性（TLS）协议加密传输中的数据，而另一些则使用安全套接字层（SSL）协议。有些默认加密你的数据，而另一些则使用你可以启用或禁用的配置设置。同样，加密传输中的数据会影响系统的整体性能。

总结

本节课中我们一起学习了数据加密的核心知识。我们了解到数据加密能使被泄露的数据变得无用，可以加密静态数据或传输中的数据。加密和解密数据需要使用算法，对称加密更易用但安全性不如非对称加密。透明数据加密（TDE）可以简化加密设置，但加密过程会降低数据库和传输性能。最后，我们可以使用TLS和SSL来保护传输中的数据。

015：数据库监控概述 📊

在本节课中，我们将要学习数据库监控的核心概念、重要性以及实施方法。数据库监控是数据库管理的关键环节，它帮助我们确保数据库系统的健康、性能与可用性。

对于许多数据库管理员而言，数据库管理中最具挑战性且必要的环节之一是性能调优，而数据库监控是此过程的关键部分。数据库监控这一术语，指的是与审查数据库日常运行状态相关的各项任务。无论您使用哪家供应商的数据库产品，数据监控对于维护关系数据库管理系统的健康与性能都至关重要。

当您执行定期的数据库监控时，它有助于及时发现问题，从而维护数据库系统的健康与可访问性。如果您不执行此监控功能，那么数据库中的问题和故障可能在为时已晚之前都未被察觉。这可能导致您的用户和客户对您的服务失去信心，并且您的组织可能因此失去客户和收入。大多数关系数据库管理系统都提供了工具，使您能够观察数据库的当前状态，并随着时间的推移跟踪其在不同情况下的性能。

作为数据库管理员，您可以利用这些信息来执行多项数据库监控任务。

以下是数据库监控的主要任务：

  • 基于数据库使用模式预测未来的硬件需求。
  • 分析单个应用程序或数据库查询的性能。
  • 跟踪索引和表的使用情况。
  • 确定任何系统性能下降的根本原因。
  • 优化数据库元素以提供最佳性能。
  • 评估任何优化活动的影响。

在讨论主动监控的重要性之前，我们需要将其与被动监控区分开来。被动监控是在问题发生后进行的，您直接针对该问题采取行动，例如修复配置设置或增加资源。被动监控最常见的情况是：数据库安全遭到破坏时、数据库性能达到极低水平时，或者发生其他严重影响业务的重大数据库事件并需要尽快解决时。

相比之下，主动监控策略旨在通过在小问题演变成大问题之前识别它们，来避免这种被动的恐慌。这主要通过观察数据库的特定指标来实现，如果这些指标的值达到异常水平，则向相关方发送警报。主动监控通常利用自动化流程来执行任务，例如定期验证数据库系统是否在线且可访问、验证配置更改不会对数据库系统的性能产生不利影响，以及确保数据库系统在可接受的水平上运行和表现。这种主动方法被广泛认为是更好的策略，并且是大多数数据库管理员的首选。

为了确定您的数据库系统是否以最佳状态运行，您首先需要为数据库系统的性能建立一个基线。为此，您需要在给定时间段内定期记录关键性能指标。

一旦建立了数据库系统性能基线，您就可以随时将这些基线统计数据与数据库系统的当前性能进行比较。如果您的比较表明当前性能测量值显著高于或低于性能基线，那么这些就可能成为进一步分析和调查的潜在目标。

从这些调查中，您可能会确定某些数据库元素需要重新配置或优化。即使在一切运行良好且符合预期的情况下，您仍然可以使用性能基线数据来帮助确定操作规范。

以下是基线数据可帮助确定的操作规范：

  • 运营的高峰时段和非高峰时段。
  • 运行查询和处理批处理命令的典型响应时间。
  • 执行数据库备份和恢复操作所需的时间。

以下领域通常对数据库系统的性能影响最大：

  • 系统硬件资源
  • 网络架构
  • 操作系统
  • 数据库应用程序
  • 客户端应用程序

有两种方法可以监控数据库中的操作。您可以使用监控表函数查看实时显示数据库各元素状态的信息。例如，您可以使用监控表函数来检查表中使用的总空间量。这些表函数允许您检查报告数据库操作几乎所有方面的监控元素和指标。监控表函数使用轻量级、高速的监控基础设施。

或者，您可以设置事件监视器，以在特定类型的数据库事件在给定时间段内发生时捕获历史信息。事件监视器在特定类型的事件发生时，随时间捕获有关数据库操作的信息。例如，您可以创建一个事件监视器来捕获系统中发生锁和死锁时的信息。或者，您可能创建一个事件监视器来记录当您指定的阈值（例如，应用程序或工作负载使用的总处理器时间）被超过时的情况。

事件监视器以不同格式生成输出，并可以将此输出写入常规表，有些甚至具有额外的输出选项。

本节课中我们一起学习了数据库监控的核心知识。我们了解到，数据库监控对于维护关系数据库管理系统的健康与性能至关重要。主动监控旨在通过在小问题演变成大问题之前识别它们来避免被动恐慌。您需要为数据库系统的性能建立基线，以确定其是否以最佳状态运行。要监控数据库中的操作，您既可以查看特定时间点数据库各元素的状态，也可以设置事件监视器来捕获特定类型数据库事件随时间发生时的历史信息。

016：监控使用和性能 第 1 部分 📊

欢迎来到《监控使用和性能》第一部分。在本节课中，我们将学习为何需要在不同层级进行监控，并描述数据库监控的四个关键层级。

你需要使用合适的工具来监控数据库并有效监控其性能。无论使用哪种监控工具，相关信息都是通过几个关键性能指标（KPIs）获取的，这些指标通常被称为指标。

数据库性能通过使用这些关键的数据库性能指标来衡量。这些指标使数据库管理员能够有效优化其组织的数据库，以获得最佳性能。除了性能监控，定期监控对于运维和安全目的也很有用。监控的最终目标是识别并防止问题对数据库性能产生不利影响。

然而，出现的一些问题可能由硬件、软件、网络连接、执行的查询或其他未知因素引起。关键在于，问题可能出现在数据库环境的多个领域。因此，为了高效、成功地监控数据库的使用和性能，你需要在数据库环境内的几个不同层级进行监控。

这四个监控层级分别是：基础设施层、平台层（或实例层）、查询层以及用户或会话层。

首先，是基础设施层。所有底层基础设施组件，如操作系统、服务器、存储硬件资源和网络组件，都必须在数据库平台和查询的底层高效运行，这一点至关重要。

接下来，是实例或数据库平台层。无论你管理的是关系数据库系统（如DB2、PostgreSQL、MySQL或任何其他类型的关系数据库系统），还是同时管理多个系统的组合，每个平台在性能方面都需要考虑。平台级的数据库监控至关重要，因为它提供了维持数据库性能一致性所需的所有要素的整体洞察。

然后是查询层。通常，你的业务线应用程序会反复对数据库实例运行查询，然后将这些查询的相关结果格式化并返回给用户。此层级可能出现的大多数瓶颈主要源于低效的查询语句，这些语句可能导致延迟、错误处理不当，并降低查询吞吐量和并发性。

最后，是用户或会话层。这个层级常常是所有监控层级中最具误导性的。因为如果用户抱怨某些功能无法使用，你可以获取他们遇到问题的更多信息，进行调查并修复。但是，如果你的用户目前没有抱怨功能问题，你是否就可以假设一切运行正常，高枕无忧了呢？不幸的是，答案是否定的。仅仅因为现在可能没有问题，并不意味着问题不会在下一刻出现。真正成功的监控意味着以主动和持续的方式，不断监控数据库系统的使用、性能和行为。数据库监控的理想境界是，在用户甚至意识到问题之前，就主动识别出问题。监控所有这四个层级对于维持服务级别协议（SLAs）至关重要，例如确保数据库的高可用性、高正常运行时间和低延迟。

在本视频中，你学习了数据库性能是通过称为指标的关键性能指标来衡量的。指标使DBA能够优化组织的数据库以获得最佳性能。成功的数据库性能监控意味着在多个层级进行监控。你应该在基础设施层、平台层、查询层和用户层进行监控。

总结

本节课中，我们一起学习了数据库监控的重要性。我们了解到，有效的监控需要依赖关键性能指标（KPIs），并且必须在四个不同的层级进行：基础设施层、平台层、查询层和用户层。通过这种分层、主动和持续的监控方法，数据库管理员可以提前发现问题，优化性能，并确保满足服务级别协议的要求。

017：监控使用与性能（第二部分）📊

在本节课中，我们将学习监控数据库使用情况和性能的关键指标，并了解用于查看这些指标的内置工具及第三方监控工具。

概述

上一节我们介绍了监控数据库的基本概念。本节中，我们将深入探讨具体的监控指标、数据库产品自带的工具以及可选的第三方监控解决方案。

关键性能与使用指标

以下是监控数据库使用情况和性能的一些关键指标：

数据库吞吐量是数据库性能最重要的指标之一。它表示数据库承担的总工作量，通常以每秒执行的查询数来衡量。其核心公式可表示为：
吞吐量 = 查询数 / 秒

数据库资源使用率通过测量CPU、内存、日志空间和存储使用情况来监控数据库资源消耗。该汇总指标从两个方面体现资源使用情况：平均/最大/最新数值，以及时间序列数值。

数据库可用性指示数据库是处于运行（可用）还是停止（不可用）状态。它通常是一个汇总指标，以百分比形式表示历史可用时间数据。

数据库响应性显示系统对传入请求的响应情况，是另一个常用的数据库性能指标。它为数据库管理员提供了数据库服务器每个查询的平均响应时间信息，表明返回查询结果的速度。

数据库争用通过测量锁等待和并发数据库连接数，指示连接之间是否存在争用。数据库争用这一术语用于描述多个进程同时竞争访问同一数据库资源时发生的情况。

工作单元跟踪哪些事务或工作单元在数据库服务器上消耗了最多的资源。

以下是更多关键指标：

连接可以向数据库管理控制台显示各种网络连接信息，并能指示数据库服务器是否会因长时间运行的查询或打开的连接过多而失败。数据库连接是支持客户端与数据库软件之间通信的网络连接。打开的连接用于发送命令并以结果集的形式接收响应。

最频繁查询跟踪数据库服务器接收到的最频繁的查询，包括其频率和平均延迟（即处理所需时间）。这可以帮助数据库管理员优化这些查询，以获得显著的性能提升。

锁定对象显示有关任何被锁定的进程以及阻塞它们的进程的详细信息。锁和块会阻止多个并发事务同时访问一个对象，它们会使竞争进程暂停，直到该对象被释放并再次可访问。

存储过程显示自数据库激活以来调用的过程、外部过程、编译函数、外部函数、编译触发器和匿名块的聚合执行指标。

缓冲池跟踪缓冲池和表空间的使用情况。目录服务器使用缓冲池来存储缓存数据，以提高数据库性能。当缓冲池填满时，它会移除较旧且较少使用的数据，为新数据腾出空间。

顶级消费者显示系统资源的顶级消费者，可以帮助数据库管理员进行容量规划和资源分配。

请注意，这只是大多数数据库管理系统中众多可用指标的一小部分。

内置监控工具

为了查看这些关键的数据库性能指标，您将根据所使用的数据库使用不同的开箱即用工具。

例如：

  • 在 DB2 中，您可以使用诸如 DB2 数据管理控制台、工作负载管理器和快照监视器之类的工具。
  • 在 PostgreSQL 中，您可以使用 PG Admin 仪表板，这是一个非常流行的用于 PostgreSQL 系统的开源查询监控工具。
  • 在 MySQL 中，您可以在 MySQL Workbench 中利用性能仪表板、性能报告和查询统计工具，并且可以使用 MySQL 查询分析器来识别运行缓慢的查询。

第三方监控工具

有几种第三方性能和查询监控工具可帮助您监控查询、优化性能并加速数据库，其中一些工具还可能提供性能调优和查询优化功能。

对于 PostgreSQL 系统，有 PG Ana 工具，它提供对查询计划、查询分析、数据库可视化、仪表板、日志洞察以及性能优化和监控的自动洞察。

如果您拥有 PostgreSQL、MySQL、SQL Server 或 Oracle 数据库，并且需要查询监控工具，可以尝试 PRTG Network Monitor。

许多第三方工具可用于多种数据库系统，例如 SQL Server、Oracle、Sybase、DB2、MySQL 和 PostgreSQL 等。

  • SolarWinds 提供名为 Database Performance Analyzer 的基于订阅的监控解决方案。
  • Quest 的 Foglight for Databases 使您能够主动监控完整的数据库环境，并在一个全面的界面中查看所有数据库平台的状态。
  • Datadog 是一个 SaaS 平台，包含多个系统监控工具。它拥有超过 450 个内置集成，可连接到多种不同的数据库系统。

总结

本节课中，我们一起学习了可用于监控数据库使用情况和性能的多种不同指标，以及可用于监控数据库和查询的几种不同工具，其中一些包含在您的数据库产品中，而另一些则是第三方产品。掌握这些指标和工具是进行有效数据库管理和性能优化的基础。

018：数据库优化 🛠️

在本节课中，我们将学习为何需要优化数据库，并了解三种主流关系型数据库（MySQL、PostgreSQL、DB2）中用于优化数据库性能的核心命令。

随着数据库中存储的数据量和工作负载的增加，数据可能会变得碎片化。数据页可能留空或部分留空，从而导致数据库性能下降。通过优化数据库，可以识别瓶颈、优化数据库查询，并最终减少用户的数据库响应时间。

为何需要优化数据库？🤔

上一节我们提到了数据库性能可能下降。本节中，我们来看看具体原因。

随着数据库中存储的数据量和操作工作负载的不断增加，数据会变得碎片化。数据页可能留空或部分留空，从而导致数据库性能下降。通过优化数据库，可以识别瓶颈、优化数据库查询，并最终减少用户的数据库响应时间。

各数据库的优化命令概览 📊

每个关系数据库系统都有其自己的实用程序或命令来优化其数据库。

以下是不同数据库系统的主要优化命令：

  • MySQL：使用 OPTIMIZE TABLE 命令。
  • PostgreSQL：使用 VACUUM 和 REINDEX 命令。
  • DB2：使用 RUNSTATS 和 REORG 命令。

接下来，我们将逐一详细了解这些命令。

MySQL 优化：OPTIMIZE TABLE 命令

在 MySQL 中，可以使用 OPTIMIZE TABLE 命令来优化表。

如果 MySQL 数据库接收了大量插入、更新或删除操作，可能会导致数据文件碎片化。这意味着会浪费大量未使用的空间，进而影响数据库性能。因此，建议数据库管理员定期对 MySQL 表进行碎片整理。

在 MySQL 中，OPTIMIZE TABLE 命令会重新组织表数据和相关索引数据的物理存储，以减少存储空间并提高访问表时的输入/输出效率。

要使用 OPTIMIZE TABLE 命令，您需要对正在处理的表拥有 SELECT 和 INSERT 权限。

以下是一个命令示例，它可以在一次操作中优化三个不同的表：

OPTIMIZE TABLE table1, table2, table3;

您也可以使用图形化工具（如 phpMyAdmin）来优化 MySQL 中的表。

PostgreSQL 优化：VACUUM 命令

在 PostgreSQL 中，VACUUM 命令用于执行垃圾回收和可选的统计分析任务。

VACUUM 会回收由死元组占用的存储空间。这些死元组在删除或因更新而失效后，并未从数据库表中物理移除。在常规的 PostgreSQL 操作中，定期回收这些丢失的存储空间有助于提高数据库的整体性能。

请注意，如果启用了 autovacuum 功能，PostgreSQL 将自动为您执行 VACUUM 维护过程。

以下是 VACUUM 命令的使用示例：

当不带参数运行 VACUUM 时，该命令将释放当前用户有权执行此操作的每个数据库中每个表上的空间。

VACUUM;

如果指定了表名，则该命令将仅处理并释放该表上的空间。

VACUUM my_table;

如果不使用 FULL 参数，VACUUM 命令可以与正常的读写表操作同时运行，因为它不需要排他锁。任何回收的空间都会保留在已清理的表内供将来重用。

然而，如果指定了 FULL 参数，该命令将创建表内容的完整副本，并将其无空闲空间地写入磁盘，从而允许操作系统回收空间。因此，使用 FULL 参数可以回收更多空间，但运行时间要长得多，并且在处理每个表时需要排他锁。

VACUUM FULL my_table;

PostgreSQL 优化：REINDEX 命令

在 PostgreSQL 中，可以使用 REINDEX 命令重建一个或多个索引。

REINDEX 使用索引对应表中存储的数据重建索引，并替换旧版本的索引。当软件错误或硬件故障损坏了索引，或者索引变得臃肿并包含大量空页或接近空页时，可以使用此命令。您需要是索引、表或数据库的所有者才能重建索引。

使用 REINDEX 时，它会从头开始构建索引内容，因此其效果与删除并重新创建索引非常相似。但是，它们在读写锁的处理方式上有所不同。

以下是一些 REINDEX 的使用示例。

第一个示例将重建名为 my_index 的索引：

REINDEX INDEX my_index;

第二个示例将重建名为 my_table 的表上的所有索引：

REINDEX TABLE my_table;

DB2 优化：RUNSTATS 命令

在 DB2 中，RUNSTATS 命令更新系统目录中关于表、相关索引或统计视图特征的统计信息。这些特征包括记录数、页数和平均记录长度。优化器使用这些统计信息来确定数据的访问路径。

以下是针对不同对象调用 RUNSTATS 命令的时机：

  • 对于表：当表进行了大量更新后，或在表重组后，调用 RUNSTATS 命令。对于表，此命令从调用它的数据库分区收集表的统计信息。
  • 对于统计视图：当底层表的更改严重影响视图返回的行时，调用 RUNSTATS 命令。该视图必须事先已通过 ALTER VIEW 语句启用以用于查询优化。对于视图，此命令使用来自所有参与数据库分区上表的数据来收集统计信息。

以下是一些使用示例。

第一个示例仅收集表的统计信息，并包含 employee_id 和 employee_name 列的分布统计信息：

RUNSTATS ON TABLE employees WITH DISTRIBUTION ON COLUMNS (employee_id, employee_name);

第二个示例收集一组索引的统计信息：

RUNSTATS ON TABLE employees FOR INDEXES ALL;

DB2 优化：REORG 命令

在 DB2 中，REORG TABLE 命令通过重建行以消除碎片化数据并压缩信息来重组表。

在分区表上，可以重组单个分区。就范围而言，REORG TABLE 命令会影响数据库分区组中的所有数据库分区。

以下是一个简单的使用示例。此示例将使用名为 my_tmp_tbsp 的临时表空间来重组表以回收空间：

REORG TABLE employees USE my_tmp_tbsp;

在 DB2 中，REORG INDEX 命令用于重组索引。

您可以通过将索引数据重建到无碎片、物理连续的页中来重组表上定义的所有索引。

在数据分区表上，可以重组分区表上的特定非分区索引，或者如果指定了数据分区，则可以重组该分区上的所有分区索引。

如果指定了索引子句的 CLEANUP 选项，则无需重建索引即可执行清理。您可以清理表上的特定索引，也可以清理表上的所有索引。就范围而言，REORG INDEX 命令会影响数据库分区组中的所有数据库分区。

总结 📝

本节课中，我们一起学习了数据库优化的重要性及具体方法。

我们了解到，优化数据库可以提高响应时间并提升整体性能。各关系数据库管理系统提供了自己的实用程序或命令来优化数据库：

  • 在 MySQL 中，可以使用 OPTIMIZE TABLE 命令。
  • 在 PostgreSQL 中，可以使用 VACUUM 和 REINDEX 命令。
  • 在 DB2 中，可以使用 RUNSTATS 和 REORG 命令。

定期使用这些工具是维护数据库健康和高性能运行的关键任务之一。

019：使用索引 📚

在本节课中，我们将要学习数据库索引。索引是提升数据库查询性能的关键工具。我们将了解索引是什么、它如何工作、有哪些不同类型，以及如何创建和管理索引。

什么是数据库索引？🔍

数据库索引类似于书籍的目录。书籍目录能帮助你更快地找到书中的信息，数据库索引则能让计算机更快地找到数据库中的信息。

如果没有索引，计算机搜索数据库时，必须扫描整个数据库来寻找所需信息，这在大型数据库中会非常缓慢。数据库索引可以显著提升数据库的搜索性能。

索引如何工作？⚙️

在数据库中，索引本质上是表中选定列数据的一个有序副本。它的设计目的是实现高效搜索，而无需在每次访问时都搜索数据库表中的每一行。

创建索引所选择的列通常由管理员定义，可以基于多种因素，例如频繁搜索的术语。无论索引如何构建，其总体目标都是帮助用户快速、轻松地找到所需信息。

索引充当一个查找表，其中包含指向其所属基表中原始行的指针或链接。一个索引可以包含表中的一个或多个列。

然而，虽然索引可以提升数据库性能，但它们也需要额外的存储空间和维护，因为它们必须为任何数据库操作持续更新。你可能需要尝试不同类型的索引和索引选项，以找到查询性能和索引维护（例如所需的磁盘空间和活动量）之间的最佳平衡。

为了保持索引最新，例如，窄索引（索引键中列较少的索引）占用的磁盘空间更少，维护开销也更低。而宽索引虽然可能覆盖更多查询，但也需要更多空间和维护。

索引的主要类型 📊

数据库索引有许多不同的类型和方法。主要类型通常可以描述为以下几种：

  • 主键：一种特殊的索引，它总是唯一且非空，每个表只能有一个。它也是聚集的，意味着底层表中的数据实际上按照主键的顺序存储。
  • 辅助索引：除了主键之外，每个表还可以有任意数量的附加索引或辅助索引。这些索引是非聚集的，可以包含单列或多列。索引可以定义为唯一或非唯一。

列的顺序很重要，因为索引将按照创建索引时指定的列顺序进行排序。排序可以是升序（默认）或降序，但它会先按第一列排序，然后是下一列，依此类推。

创建主键 🔑

表的主键唯一标识表中的每一行。虽然在有些关系数据库管理系统中，拥有主键是可选的，但在创建表时创建一个主键通常是一个好习惯。也可以通过修改表来稍后添加主键。

以下是在创建表时定义主键的一般语法：

CREATE TABLE table_name (
    column1 datatype PRIMARY KEY,
    column2 datatype,
    ...
);

这是一个简单的例子。此示例将创建一个名为 team 的表，其中 team_id 列作为主键。

CREATE TABLE team (
    team_id INT PRIMARY KEY,
    team_name VARCHAR(50)
);

如果主键由多列组成，你甚至可以在定义所有列之后指定主键约束。你只需添加 PRIMARY KEY 选项，然后在括号中指定列名。

CREATE TABLE example (
    col1 INT,
    col2 INT,
    col3 VARCHAR(50),
    PRIMARY KEY (col1, col2)
);

由于主键需要具有唯一值，一种确保唯一性的方法是为主键列创建自动生成的递增值。在 DB2 中，这些被称为 IDENTITY 列，可以通过在列定义后指定关键字 GENERATED BY DEFAULT AS IDENTITY 来创建。在 MySQL 中，你只需在列定义后添加 AUTO_INCREMENT 关键字。

创建和删除索引 🛠️

上一节我们介绍了主键，本节中我们来看看如何创建和删除普通的辅助索引。

创建索引的基本语法如下面的第一个代码块所示。你使用 CREATE INDEX 语句来定义索引，并使用 ON 语句来指定在哪个数据库表上创建它。你在括号中指定列名，输入它们的顺序决定了索引的排序顺序。

CREATE INDEX index_name
ON table_name (column1, column2, ...);

以下是几个例子。

第一个示例在 project 表上创建一个名为 unique_idx 的唯一索引，索引列为 proj_name。这意味着 project 表不能有多行具有相同的 proj_name 值。当指定了 UNIQUE 选项时，它会阻止表包含两行或多行具有相同索引键值的情况。

CREATE UNIQUE INDEX unique_idx
ON project (proj_name);

第二个示例在 employee 表上创建一个名为 job_by_dept 的索引，它按顺序包含 work_dept 和 job 列。这个索引不是唯一的，因此表可以有多行具有相同的 work_dept 和 job 列值。但该索引的好处是，基于这些字段进行过滤的查询将比没有索引时更快。

CREATE INDEX job_by_dept
ON employee (work_dept, job);

要删除一个索引，你使用 DROP 语句。删除索引不会导致任何其他对象被删除，但会导致依赖于被删除索引或索引规范的包失效。

此示例删除名为 job_by_dept 的索引。

DROP INDEX job_by_dept;

主键索引或唯一键索引不能使用 DROP 语句显式删除。删除主索引或唯一键索引需要通过 ALTER TABLE 语句完成。使用 ALTER TABLE 删除主键或唯一键后，该索引不再被视为主索引或唯一索引，然后可以使用 DROP 语句显式删除它。

索引设计原则与考虑事项 💡

数据库应用程序瓶颈的主要来源之一可能是设计不当的索引或缺乏足够、合适的索引。因此，设计高效的索引对于优化数据库应用程序性能至关重要。

设计索引时，应考虑以下核心原则：

  • 理解数据库将如何被使用：例如，它将用于繁重的在线事务处理，还是用于大型数据集的存储和检索。
  • 理解最常用的查询：例如，如果你知道一个频繁使用的查询会连接两个或更多表，这可能有助于你决定使用最合适的索引类型。
  • 理解列的特性：例如，它们将包含什么类型的数据？它们将包含整数值吗？它们会是唯一的吗？从一开始了解这些特性将帮助你选择合适的索引类型。

在创建或维护索引时，你还需要考虑哪些索引选项能最好地提升其性能。

例如，如果你要在现有的大型表上创建聚集索引，使用 在线索引 选项将是一个好主意，因为它允许在构建索引的同时对底层数据进行并发活动。

另一个考虑是存储索引的最佳位置。你决定存储索引的位置可以通过提高磁盘输入/输出操作的性能来改善查询性能。例如，如果你将非聚集索引存储在与表存储组所在磁盘不同的磁盘上的存储组中，它可以提高性能，因为两个磁盘可以同时读取。

总结 📝

本节课中我们一起学习了数据库索引。

你了解到数据库索引可以显著提升数据库的搜索性能。数据库索引可以是主键索引，也可以是非主键索引（即标准索引）。主键可以在创建表时定义。CREATE INDEX 语句用于在数据库表上定义索引，而 DROP 语句用于删除索引。主键或唯一键索引不能使用 DROP 语句显式删除，必须首先使用 ALTER TABLE 语句删除。数据库应用程序瓶颈的主要来源之一是设计不当的索引或缺乏足够、合适的索引。最后，设计高效的索引对于获得最佳的数据库应用程序性能至关重要。

020：排除常见问题 🔧

在本节课中，我们将学习如何识别和解决数据库管理中常见的性能、配置和连接问题。我们将了解问题的根源、基本的故障排除步骤以及用于诊断和预防问题的工具。

什么是故障排除？🔍

故障排除是一个识别和解决问题的过程。这个过程通常从回答以下几个关键问题开始：

  • 症状是什么？
  • 谁或什么报告了问题？
  • 问题发生在哪里？ 它是否特定于某个平台、环境或应用程序？
  • 问题何时发生？ 是在特定时间、多次发生，还是在特定条件下发生？
  • 问题是否可重现？

通过系统地回答这些问题，我们可以缩小问题范围，找到根本原因。

数据库常见问题类型 📉

上一节我们介绍了故障排除的基本思路，本节中我们来看看数据库最常见的三类问题。

数据库最常见的问题通常由以下一个或多个原因引起：

  • 性能低下：这会导致用户查询或访问数据库的应用程序响应缓慢。
  • 配置不当：客户端、服务器或数据库配置不当会导致各种问题，包括性能低下、崩溃、错误甚至数据库损坏。
  • 连接问题：连接不畅会导致性能低下、超时或与数据库交互时出现各种错误。

性能低下问题分析 🐌

性能低下通常由磁盘读写延迟高、服务器处理时间慢或服务器与客户端之间连接不畅引起。这些问题可能根源于以下几个方面：

以下是性能问题的常见根源：

  1. 服务器硬件或配置：例如，服务器可能磁盘空间、内存或处理能力不足。在数据库服务器上增加这些资源称为垂直扩展。添加额外的数据库分区和分片以提高性能称为水平扩展。
  2. 配置不当：配置不当的数据库可能仍在运行，但无法满足需求。例如，它可能需要允许更多连接，或者可能需要更改其缓冲和索引设置，以跟上查询速度并快速返回结果。
  3. 连接性：客户端和数据库之间缓慢或不良的网络连接或有限的带宽会导致高延迟和处理时间。
  4. 查询和应用程序逻辑：编写不当的数据库查询或不正确的应用程序逻辑（例如不必要地锁定数据库对象）也会导致性能问题。

配置问题详解 ⚙️

配置不当或未优化的客户端、服务器或数据库可能导致以多种方式显现的无数问题。

以下是配置问题的具体表现和检查点：

  • 客户端配置：配置错误的客户端或驱动程序可能导致用户无法连接到数据库。常见原因包括：
    • 登录凭据不正确。
    • 主机名或IP地址错误。
    • 连接驱动程序损坏或过时。
    • 要修复这些问题，请检查客户端的驱动程序配置并验证以下内容：
      • 连接设置中指定的用户名和密码正确。确保客户端也配置为使用正确的身份验证类型（例如Windows或SQL身份验证）。
      • 连接配置设置（如IP地址、主机名和服务器名）正确。
      • 数据库应用程序的驱动程序版本是最新且正确的。

  • 服务器配置：服务器配置也显著影响性能和操作。你可能需要更改或配置以下内容来改善性能或纠正问题：
    • 添加更多物理RAM或增加分配给服务器的内存。
    • 添加更多物理磁盘空间或为服务器分配额外的磁盘空间。
    • 考虑升级CPU或为服务器分配更多处理能力。
    • 考虑对硬盘进行碎片整理，碎片化的数据会降低整体性能。
    • 有时，适当配置存储系统可以缓解性能问题，例如将频繁访问的表放在更快的磁盘上。
    • 操作系统或RDBMS软件中的错误可能导致错误和服务器崩溃，因此请确保定期应用软件补丁和安全更新以防止这种情况。

  • 数据库配置：你需要监控并持续评估数据库的配置，以确保其满足需求。你可能需要更改或纠正的配置设置示例如下：
    • 增加数据库允许的连接数以满足不断增长的需求。
    • 更改数据库缓冲以提高性能。
    • 更改数据库索引以提高性能。

连接问题排查 🌐

客户端和数据库服务器之间的连接不畅会导致各种问题，包括性能低下、错误消息或功能丧失。

最常见的连接问题通常由以下原因之一引起：

  1. 数据库服务器无法访问或未正常运行。
  2. 服务器上的数据库实例未正常运行。
  3. 客户端登录凭据不正确或缺少安全设置（例如SSL连接）。
  4. 客户端配置不正确。

以下是一些帮助排查和解决基本连接问题的常用方法：

  • 验证数据库服务器是否正常运行：具体步骤取决于你的配置和环境。例如，你可能需要物理检查本地服务器，或者需要验证云服务中的虚拟机是否正在运行。
  • 验证服务器上的数据库实例是否正在运行：此过程因操作系统和数据库而异。例如，在基于Windows的系统上，你可以使用任务管理器来验证实例是否正在运行；在DB2配置中，你可以运行db2cmd，然后在命令行中发出命令。
  • 验证客户端是否可以访问数据库：一个常见的方法是使用客户端的ping命令与服务器的IP地址或主机名通信。
  • 验证客户端连接驱动程序配置是否正确：例如，确保连接的用户名和密码正确，并且IP地址、主机名或安全加密协议等设置也正确。

监控与日志工具 📊

性能监控、报告以及服务器和数据库日志有助于识别性能瓶颈并确定最佳的纠正方法。

以下是关键的工具和它们的作用：

  • 性能监控：有助于在潜在的网络、服务器和数据库问题发生前识别它们，并帮助确定可以在哪些方面进行改进。
  • 仪表板：可以实时监控数据库，并在问题影响用户之前提供预警系统，同时跟踪历史性能和其他指标。
  • 服务器和数据库日志：帮助识别问题及其发生的时间。

总结 📝

本节课中，我们一起学习了数据库管理中的常见问题及其解决方法。

我们了解到，数据库最常见的问题是由性能低下、配置不当或连接问题引起的。性能低下通常由磁盘读写延迟高、服务器处理时间慢或客户端与服务器之间连接不畅引起。服务器配置问题（如硬件资源不足或设置配置错误）会显著影响性能。最常见的连接问题包括无法连接到数据库服务器、数据库服务器或实例未正常运行以及客户端登录凭据不正确。最后，性能监控报告以及服务器和数据库日志可以帮助识别性能瓶颈并确定最佳的纠正方法。

021：使用状态变量、错误代码与文档 📚

在本节课中，我们将学习如何获取数据库服务器的状态信息、检索错误代码，并利用官方文档进行故障排查。掌握这些技能是数据库管理员进行日常维护和问题诊断的基础。

检查数据库状态 🩺

当数据库出现问题时，首先需要检查其运行状态和健康状况。所有数据库都提供了一系列命令或工具，用于快速获取数据库的运行快照。这些工具可以通过命令行或图形界面访问。

例如，在Unix环境的命令行中，可以使用 service mysql status 命令来查看MySQL的状态。

service mysql status

命令输出会显示数据库服务器是“正在运行”还是“正常”，如下图所示。

可用的命令和语法因您使用的数据库（如DB2、MySQL或PostgreSQL）以及运行环境（如Unix或Windows）而异。

以下是不同数据库的示例：

  • 在DB2中，可以运行 db2pd 命令来监控DB2实例的状态并对数据库进行问题诊断。
  • 在MySQL中，可以使用 SHOW STATUS 命令来获取服务器状态信息。
  • 在运行PostgreSQL的服务器上，可以使用 pg_isready 命令来检查PostgreSQL数据库服务器的连接状态。

理解状态变量 📊

数据库使用许多状态变量来提供其运行信息。状态变量可以是全局的，也可以是会话级的。

  • 全局状态变量：代表服务器自身某些方面的状态（例如 aborted_connects），或所有连接到MySQL的会话的聚合状态（例如 bytes_received 和 bytes_sent）。如果变量没有全局值，则会显示会话值。
  • 会话状态变量（有时称为本地状态变量）：代表当前连接的值。

您还可以在 SHOW SESSION STATUS 语句中使用 LIKE 子句和模式，来显示匹配特定模式的状态变量信息。

例如，使用以下语句将只显示名称中包含“key”的变量状态：

SHOW STATUS LIKE ‘key%’;

除了命令，许多数据库还提供带有仪表板和报告的图形界面，用于实时监控数据库状态和信息。

例如，在运行于Windows Server上的Microsoft SQL Server中，您可以使用“活动监视器”来获取有关SQL Server进程及其如何影响当前实例的信息，并使用“系统监视器”来验证状态和监控SQL Server性能。

利用日志文件定位错误 🔍

有多种日志文件可以帮助您确定错误发生的时间和位置。最常用的是服务器/操作系统日志和数据库错误日志。

  • 服务器/操作系统日志：记录常规服务器活动、连接性以及运行数据库的服务器本身的其他方面。
  • 数据库错误日志：记录所操作数据库（如MySQL或PostgreSQL系统）特有的信息和错误。

日志文件是发现错误发生时间及错误描述的重要工具。

例如，在典型的SQL Server中，一些最常访问的日志包括：

  • 错误日志文件：每次启动SQL Server时创建。
  • 事件日志文件：显示信息和错误事件。
  • 默认跟踪日志：一个可选的日志文件，用于跟踪所有数据库配置更改。

解读错误代码与消息 📝

无论您是通过日志文件还是直接收到错误消息，很可能都需要解读具体的错误信息和错误代码。

错误消息或记录的错误通常包含可用于故障排除的消息和ID号。它们还可能包含其他信息，例如：

  • 导致问题的存储过程名称。
  • 错误发生时数据库的状态。
  • 额外的描述性信息。
  • 问题的严重级别。
  • 如果问题发生在脚本或批处理文件中，还可能看到引用的行号。

查阅官方文档寻求帮助 🆘

在检查数据库状态并收集信息后，下一步是深入了解您遇到的错误。

互联网上有许多文档和帮助站点，提供了错误代码表，可以帮助您解码和纠正错误。

以下是流行的资源：

总结 📋

本节课我们一起学习了数据库故障排查的基础知识。

我们了解到，数据库提供了多种实用程序来检查其健康状况和运行状态，可用命令及其语法因数据库类型而异。数据库使用全局或会话级的状态变量来提供运行信息，并且可能配备带有仪表板的图形界面用于实时监控。有多种日志文件可以帮助定位错误发生的时间和位置。最后，互联网上丰富的官方文档和错误代码表是解码和纠正错误的宝贵资源。掌握这些工具和方法，将使您能够更有效地管理和维护数据库系统。

022：用于故障排除的日志 🔍

在本节课中，我们将学习诊断日志的概念、用途、类型以及如何访问和利用它们进行数据库故障排除。日志是数据库管理员定位和解决问题的关键工具。

概述：什么是故障排除与诊断日志？

故障排除是一个系统性的过程，用于定位计算机系统中故障的原因，并提供纠正相关硬件和软件问题的详细信息。采用逻辑和系统化的方法进行故障排除对于成功解决问题至关重要。创建日志的主要原因之一就是为了故障排除。当问题发生时，你需要诊断它以理解其发生的原因和根源。

诊断日志跟踪系统组件或应用程序（如Web服务器或数据库）中正在发生的情况。它包含有关处理请求时遇到的事件或问题的信息。诊断日志是按时间顺序记录的重要事件和错误的记录，对于诊断和排除问题非常有用。例如，如果Web服务器收到加载缺失文件的请求，此错误及其详细信息可以记录到Web服务器日志中。诊断日志有时也被称为故障排除日志、错误日志或事件日志。必须认识到，它们可能包含事件、信息性消息、警告或错误及其详细信息。

诊断日志的类型与内容

数据库管理员需要熟悉系统中的各种诊断日志类型。这些日志包括服务器组件、存储和其他硬件设备、网络、操作系统、应用程序以及数据库的日志。

虽然系统管理员可能监控其他日志，但数据库管理员需要非常熟悉数据库诊断日志并经常查看它们。这些数据库诊断日志通常与数据库事务日志或查询日志是分开的。

诊断日志可以包含多种信息。诊断日志中消息的一些典型组成部分包括：

  • 问题和严重性类型：判断是事件、信息、警告还是错误。
  • 对应的错误代码和消息。
  • 错误发生的位置、URL或子系统。
  • 时间戳。
  • 用户的IP地址和用户代理。
  • 根据事件或错误而定的任何附加信息。

日志的存储与访问

在大多数情况下，你可以配置日志文件的位置。然而，某些日志（如系统日志文件）可能具有固定的位置。

许多日志文件以纯文本格式记录，任何文本编辑器都可以打开它们。例如，在运行Windows操作系统的机器上，双击日志文件默认会使用记事本打开。但是，有些日志文件是机器可读的，可能需要特定的查看器来查看其内容。

主流数据库日志配置示例

上一节我们介绍了日志的通用概念，本节中我们来看看不同数据库管理系统中的具体日志配置。

DB2 日志示例

以下是DB2诊断日志文件（称为DB2DIAG.LOG）中的一条消息示例，该文件为ASCII或纯文本格式，可以使用文本编辑器查看。它包括消息记录的时间戳、消息类型（在本例中，是通过运行db2start命令启动数据库管理器相关的事件），以及诸如DB2软件修复包和操作系统级别、关于系统资源（CPU和内存）信息等附加细节。使用DB2数据库管理器配置，你可以配置DB2诊断日志的位置以及要记录的消息的严重性或诊断级别。

PostgreSQL 日志配置

类似地，PostgreSQL数据库通常记录所有事件，如启动和关闭、错误、连接问题等。你可以使用postgresql.conf中的log_destination参数配置日志条目的存储位置：在Linux和Unix系统的情况下为syslog，在Windows系统的情况下为eventlog，到一个可以轻松导入表中并使用标准SQL语句查询日志条目的CSV日志文件，或者到stderr（标准错误的缩写，这是默认设置，通常输出到控制台）。可以使用log_directory参数指定特定位置（默认为pg_log）。你还可以选择日志文件名的格式，该格式基于特定的字符串模式命名日志文件，该模式可以包含时间戳。

MySQL 日志类型与配置

在MySQL中，区别于用于可恢复性的二进制日志或事务日志，你可以使用其他服务器日志进行故障排除。这些日志包括：

  • 通用查询日志：记录从客户端接收到的连接和查询。
  • 慢查询日志：顾名思义，记录执行时间超过指定时间的查询。
  • 最重要的是错误日志文件：包含来自mysqld（MySQL守护进程或服务器进程）的诊断和错误消息。

除了错误消息，MySQL错误日志还包括数据库服务器操作、启动和关闭期间的警告和注释。你可以配置MySQL将消息写入Windows事件日志（这是默认设置）、Linux和类Unix系统上的syslog或系统日志、stderr（标准错误，在Linux和Unix上是默认的）或指定的文件。你可以在mysqld或MySQL配置文件中使用log_error选项指定记录消息的文件名。

数据库管理员可以配置错误日志中存储多少信息，在级别1（仅错误）、级别2（错误和警告）和级别3（错误、警告和注释）之间选择。级别3是默认值。消息的详细程度使用log_error_verbosity选项指定。在此示例中，log_error_verbosity设置为2，即仅记录错误和警告。

总结

本节课中我们一起学习了数据库管理员需要熟悉多种类型的日志，尤其是数据库诊断日志。数据库诊断日志文件（也称为错误日志或故障排除日志）包含各种类型的信息性事件、警告和错误详细信息的带时间戳的消息。大多数诊断日志是基于文本的，可以在控制台或文本编辑器中查看，但有些可能需要特殊工具或查看器来查看和过滤其内容。大多数数据库提供用于启用和配置诊断及错误日志的设置，例如设置日志文件名和位置以及消息的详细程度。一些数据库（如MySQL）提供不止一种诊断日志，例如错误日志和慢查询日志。掌握日志的使用是进行有效数据库管理和故障排除的基础技能。

023：自动化数据库任务概述 🚀

在本节课中，我们将要学习什么是数据库自动化任务，解释使用脚本自动化任务的好处，列举一些常见的数据库自动化任务，并理解自动化在数据库测试中扮演的关键角色。

什么是数据库自动化？🤖

数据库自动化是指利用无人值守的进程和自我更新的程序来执行管理任务。它通过利用现有的流程和工具，使管理任务变得更简单、更快捷。

数据库自动化的核心优势在于：

  • 减少部署错误。
  • 提高变更实施的可靠性和速度。
  • 将员工从重复性的代码更新和其他工作中解放出来。

它尤其适用于那些耗时且重复性高的任务，例如：

  • 数据库健康检查。
  • 警报处理。
  • 服务器或数据库维护。

脚本自动化 📜

上一节我们介绍了数据库自动化的概念，本节中我们来看看实现自动化的核心手段之一：脚本。

脚本自动化是指利用软件来管理和复用现有脚本，在受控框架内实现自动化，而无需每次都开发和维护自定义脚本。脚本被编写用于执行常规但重要的工作。

以下是脚本可以自动化的常见任务：

  • 备份和清理事件日志。
  • 自动化网络任务。
  • 监控系统性能。
  • 读写注册表。
  • 管理各种用户账户、计算机账户、打印机、应用程序和服务。

对于大多数数据库管理任务，存在多种自动化方法和工具。其中一些内置于数据库中，另一些则由数据库管理员（DBA）和开发人员通过脚本或数据库代码来执行。

DBA可以编写的常见脚本包括用于备份、截断、加载和恢复数据库的进程。

在编写、更新和维护脚本时，拥有一个版本控制系统至关重要。该系统可以跟踪并保留代码和数据库变更的增量历史记录。必要时，如果发生错误或其他问题，DBA可以将数据库恢复到之前的版本。在版本控制环境中开发数据脚本效果最佳，其主要目标是保持代码与数据库同步。

自动化任务与工具 🛠️

除了核心的数据库操作，你还可以编写脚本来执行特定的DBA任务。

以下是此类任务的例子：

  • 发送错误通知。
  • 将归档日志从一个存储位置移动到另一个存储容器。
  • 调度报告等。

DBA还可以创建用于在数据库之间部署代码变更的脚本。自动化大多数数据库管理任务有几种方式，包括使用工具或调度器（如Cron jobs），以及使用Shell、Python或其他脚本语言编写脚本。

为何要自动化？💡

有许多充分的理由促使我们自动化数据库任务。

以下是主要的好处：

  • 提高吞吐量或生产力。
  • 提升质量或增加质量的可预测性。
  • 增强流程或产品的健壮性/一致性。
  • 提高输出或结果的一致性。
  • 解放劳动力以承担其他角色。
  • 在自动化流程的开发、部署、维护和运行中提供更高级别的工作。

可自动化的具体任务示例 📋

现在，让我们具体看看哪些数据库任务适合自动化。

以下是一些典型的可自动化任务：

  • 数据库健康检查：检查数据库以了解系统运行状况和效率的过程。
  • 警报日志文件清理：删除数据库写出的按时间顺序排列的消息和错误日志的过程。此文件中的典型消息包括数据库启动、关闭、日志切换、空间错误等。
  • 跟踪文件清理：删除跟踪文件或备份文件的过程，该文件是显示应用程序在某个时间点正在执行的进程和已加载模块的快照。
  • 数据字典统计信息收集：系统收集正在数据库、信息系统或研究项目中使用或捕获的数据元素的名称、定义和属性的集合的过程。数据字典提供关于数据元素的元数据。

你还可以自动化以下任务：

  • 数据库配置检查：检查数据库配置是否符合当前系统建议的过程。
  • 模式对象检查：监控数据库变更以快速识别薄弱环节和有问题的查询的过程。
  • 使用GUI工具的日常例行任务：使用图形用户界面（GUI）在数据库中执行日常功能的过程，例如运行报告和备份文件。

自动化数据库测试 🧪

数据库测试涉及检查数据库，以确保在受控测试环境中一切正确且运行正常。数据库测试包括检查模式、表、触发器等。

数据库测试在软件测试中非常重要，因为它确保接收并存储到数据库中的数据值和信息是有效的。数据库测试有助于：

  • 防止数据丢失。
  • 保存中止的事务数据。
  • 禁止未经授权访问信息。
  • 检查数据的完整性和一致性。

自动化软件测试可以查看应用程序内部，检查内存内容、数据表、文件内容和内部程序状态，以确定产品是否按预期运行。一旦创建，自动化测试可以重复运行，无需额外成本，并且比手动测试更快、更安全。自动化测试可以增加测试的深度和范围，有助于提高自动化数据库测试的质量和安全性。

总结 📝

本节课中我们一起学习了数据库自动化的核心知识。

我们了解到：

  • 数据库自动化是在数据库中使用无人值守的进程和自我更新的程序来执行管理任务。
  • 脚本语言可以轻松地在应用层面自动化流程。
  • 一些自动化流程包括备份、截断和恢复数据库。
  • 自动化数据库任务的优势包括提高吞吐量或生产力、提升质量或增加质量的可预测性，以及更好的流程或产品一致性。
  • 最后，自动化数据库测试有许多好处，包括更安全、更经济和更快速。

024：自动化报告和警报 📊🚨

在本节课中，我们将要学习数据库管理中的自动化报告、通知和警报。我们将了解它们之间的区别，探讨数据库管理员（DBA）如何使用它们，并介绍一些基于最佳实践的常见警报设置方法。

概述：报告、通知与警报的区别

上一节我们介绍了数据库管理的日常任务，本节中我们来看看如何通过自动化工具监控数据库健康状态。首先，我们需要区分报告、通知和警报。

  • 报告：提供数据库健康状况的定期概览。
  • 通知：用于跟踪需要关注但非紧急的问题。
  • 警报：用于快速提醒需要立即关注的紧急问题。

报告：数据库健康的定期概览 📈

想象一下，你是一家小公司的DBA，每周需要向老板汇报你所负责数据库的状态。你如何获取这些信息？又应该包含哪些内容？

大多数数据库管理系统（DBMS）都包含报告功能，可以提供关于数据库健康状况的洞察，例如：

  • 成功连接或连接失败的用户数量。
  • 已使用的空间量及其增长率。
  • 针对数据库执行的查询数量。

你可以创建和配置包含特定指标的报告，以获取所需信息。定期运行数据库健康报告，可以让你在问题变得严重之前加以解决，同时跟踪长期趋势，帮助你预测未来需求并做好准备。

你可以根据需求，将报告自动化设置为每日、每周或每月运行。

在大公司中，可能由整个部门管理自动化报告；而在小公司，可能由少数几位甚至一位DBA来执行此任务。有些公司还会使用提供额外选项和功能的第三方报告工具。

通知：潜在问题的预警 📨

与提供定期概览的报告不同，通知用于跟踪应该关注但不需要立即处理的问题。通知让DBA有机会跟踪特定的数据库事件。

例如，你可能会选择在用户尝试登录但失败时收到通知。少数此类事件是日常操作的一部分（例如用户忘记或输错密码），但一连串的登录失败通知可能表明存在恶意访问数据的企图。

你可以通过短信、电子邮件或仪表板接收自动化通知，需要配置你偏好的选项。

警报：紧急问题的即时响应 🚨

警报能让你快速意识到需要紧急关注的问题。它们由特定事件触发，例如：

  • 磁盘空间或内存严重不足。
  • 计划作业未能完成。
  • 错误日志中出现错误级别事件。

你需要确定哪些警报适合你的环境，并将其配置为在触发时立即通知值班的DBA。在配置警报和通知时，注意不要设置过多而导致无法全部响应。你应该评估哪些是至关重要的，并据此进行配置。

警报通常使用两个或更多阈值来传达事件的严重性：

  • 警告阈值：系统发送警告信息。
  • 严重阈值：系统发送严重警报信息。

一个最佳实践是，当指定事件的阈值达到 85% 时发出警告警报，达到 95% 时发出严重警报。你可以根据环境需求自定义这些值。

如何实现自动化 ⚙️

现在你已经对报告、通知和警报有了一些了解，接下来我们看看如何实现这些功能的自动化。

大多数关系数据库管理系统（RDBMS）允许你通过图形界面配置报告的内容和频率。许多系统提供示例报告，并允许你在必要时配置自己的报告。

通知和警报的功能类似，你可以通过图形界面、命令行工具或脚本来配置它们。自动化报告、通知和警报的过程因所使用的RDBMS而异。

总结

本节课中我们一起学习了数据库管理中的自动化监控工具。

  • 报告提供数据库健康状况的定期概览。
  • 通知对可能发展成麻烦的问题发出预警。
  • 警报则提醒需要立即关注的问题。

数据库管理员会根据其环境需求，自动化配置报告、通知和警报，以确保数据库的稳定、高效运行，并在问题出现时能够及时响应。

posted @ 2026-03-26 08:50  布客飞龙II  阅读(2)  评论(0)    收藏  举报