数据库管理：安全、备份与恢复全解析

### 数据库管理：安全、备份与恢复全解析 #### 1. 数据库安全处理 在数据库应用中，安全是至关重要的一环。假设在一个应用里，当用户点击浏览器页面上的特定按钮时，会向 Web 服务器发送如下查询，然后再传至数据库管理系统（DBMS）： ```sql /* *** EXAMPLE CODE – DO NOT RUN *** */ /* *** SQL-QUERY-CH06-01 *** */ SELECT * FROM EMPLOYEE; ``` 此语句会返回所有员工（EMPLOYEE）行的数据。若应用安全策略规定员工只能访问自己的数据，那么 Web 服务器可在该查询中添加如下 WHERE 子句： ```sql /* *** EXAMPLE CODE – DO NOT RUN *** */ /* *** SQL-QUERY-CH06-02 *** */ SELECT * FROM EMPLOYEE WHERE EMPLOYEE.Name = '<%SESSION("EmployeeName")%>'; ``` 这样的表达式会让 Web 服务器将员工姓名填入 WHERE 子句。例如，对于以“Benjamin Franklin”为名登录的用户，该表达式会生成如下语句： ```sql /* *** EXAMPLE CODE – DO NOT RUN *** */ /* *** SQL-QUERY-CH06-03 *** */ SELECT * FROM EMPLOYEE WHERE EMPLOYEE.Name = 'Benjamin Franklin'; ``` 由于姓名是由 Web 服务器上的程序插入的，浏览器用户并不知晓这一过程，也无法进行干预。这种安全处理既可以在 Web 服务器上完成，也能在应用程序内部实现，或者写成存储在 DBMS 中的代码，由 DBMS 在适当的时候执行。数据库管理员（DBA）和应用程序员必须谨慎操作，否则数据库安全可能会因 SQL 注入攻击等技术而受到威胁。 此外，还可以在安全数据库中存储额外的数据，该数据库可由 Web 服务器和存储在 DBMS 中的代码访问。例如，安全数据库可以包含用户身份与 WHERE 子句额外值的配对信息。假设人事部门的用户可以访问除自己数据之外的更多数据，那么合适的 WHERE 子句谓词可以存储在安全数据库中，由应用程序读取，并在必要时附加到 SQL SELECT 语句中。 一般来说，应优先使用 DBMS 的安全功能。只有当这些功能无法满足需求时，才使用应用代码进行补充。安全措施离数据越近，被渗透的可能性就越低。而且，使用 DBMS 的安全功能速度更快、成本更低，并且可能产生更高质量的结果。 #### 2. 数据库备份与恢复 计算机系统可能会出现故障，硬件会损坏，程序存在漏洞，人为编写的程序也会有错误，人们还会犯错。这些故障在数据库应用中都可能发生。由于数据库被多人共享，且通常是组织运营的关键要素，因此尽快恢复数据库至关重要。 在进行数据库备份与恢复时，需要解决几个问题： - **业务层面**：业务功能必须继续进行。例如，客户订单、财务交易和装箱单必须手动完成。待数据库应用恢复正常后，再录入新数据。 - **系统恢复**：计算机运维人员必须尽快将系统恢复到可用状态，且尽可能恢复到系统崩溃前的状态。 - **用户操作**：用户需要知道系统恢复后该怎么做。有些工作可能需要重新录入，用户必须清楚需要回溯到多远。 当故障发生时，简单地修复问题并恢复处理是不可能的。即使在故障期间没有数据丢失（这假设所有类型的内存都是非易失性的，这是不现实的），计算机处理的时间和调度也过于复杂，无法精确重现。操作系统要想在中断处精确重启处理，需要大量的开销数据和处理过程。因此，通常有两种恢复方法：通过重新处理恢复和通过回滚/前滚恢复。 ##### 2.1 通过重新处理恢复 由于无法在精确的点恢复处理，次优的选择是回到已知的点，从那里重新处理工作负载。这种恢复方式最简单的形式是定期制作数据库副本（称为数据库保存），并记录自保存以来处理的所有事务。当故障发生时，运维人员可以从保存的副本中恢复数据库，并重新处理所有事务。 然而，这种简单的策略通常不可行。一方面，重新处理事务所需的时间与首次处理时相同。如果计算机任务繁重，系统可能永远无法赶上进度。另一方面，当事务并发处理时，事件是异步的。人类活动的细微变化，如用户在响应应用程序提示前阅读电子邮件消息，可能会改变并发事务的执行顺序。例如，在原始处理中客户 A 获得了航班的最后一个座位，而在重新处理时客户 B 可能会获得该座位。因此，在多用户系统中，重新处理通常不是一种可行的故障恢复方式。 ##### 2.2 通过回滚和前滚恢复 另一种数据库恢复方法是定期制作数据库副本（数据库保存），并记录自保存以来事务对数据库所做的更改日志。当故障发生时，可以使用以下两种方法之一： - **前滚（Rollforward）**：使用保存的数据恢复数据库，并重新应用自保存以来所有已提交的事务。需要注意的是，这里不是重新处理事务，因为应用程序不参与前滚过程，而是重新应用日志中记录的已处理更改。 - **回滚（Rollback）**：通过撤销错误或部分处理的事务对数据库所做的更改来纠正错误。然后重新启动故障发生时正在处理的事务。 回滚方法实际上并不使用数据库保存，但所有 DBMS 都会创建数据库保存，因为它们在从硬盘故障（与这里强调的系统崩溃不同）中恢复时很有用。 这两种方法都要求保留事务结果的日志。该日志按时间顺序记录数据更改。事务必须先写入日志，再应用到数据库。这样，如果系统在事务记录到日志和应用到数据库之间崩溃，最坏的情况是有一个未应用事务的记录。如果事务在记录到日志之前就被应用，就可能在没有记录更改的情况下更改数据库，这可能导致粗心的用户重新录入已经完成的事务。 在发生故障时，我们使用日志来撤销或重做事务。为了撤销事务，日志必须包含每个更改的数据库记录在更改之前的副本，这些记录称为前映像（Before-Images）。通过将事务所有更改的前映像应用到数据库来撤销事务。为了重做事务，日志必须包含每个数据库记录（或页面）在更改之后的副本，这些记录称为后映像（After-Images）。通过将事务所有更改的后映像应用到数据库来重做事务。 以下是一个事务日志的示例，展示了可能包含的数据项： | 事务 ID | 反向指针 | 正向指针 | 时间 | 操作类型 | 对象 | 前映像 | 后映像 | 相对记录编号 | | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | | 1 | 0 | 2 | 11:42 | START | CUST 100 | (old value) | | | | 2 | 1 | 3 | 11:43 | MODIFY | SP AA | (old value) | (new value) | | | 3 | 2 | 4 | 11:46 | START | ORDER 11 | (old value) | | | | 4 | 3 | 5 | 11:47 | MODIFY | SP BB | (old value) | (new value) | | | 5 | 4 | 6 | 11:47 | INSERT | | | (value) | | | 6 | 5 | 7 | 11:48 | START | | | | | | 7 | 6 | 8 | 11:49 | COMMIT | | | | | | 8 | 7 | 9 | 11:50 | COMMIT | | | | | | 9 | 8 | 10 | 11:51 | MODIFY | | | (new value) | | | 10 | 9 | 0 | 11:51 | COMMIT | | | | | 对于这个示例事务日志，每个事务都有一个唯一的名称用于识别。此外，给定事务的所有映像通过指针链接在一起。一个指针指向该事务之前的更改（反向指针），另一个指针指向该事务之后的更改（正向指针）。指针字段中的零表示列表的结束。DBMS 恢复子系统使用这些指针来定位特定事务的所有记录。 恢复系统崩溃的过程可以用以下 mermaid 流程图表示： ```mermaid graph LR classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px; classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px; A([开始处理]):::startend --> B(接受浏览器订单数据):::process B --> C(读取 CUSTOMER 和 SALESPERSON 记录):::process C --> D(更改 CUSTOMER 和 SALESPERSON 记录):::process D --> E(重写 CUSTOMER 记录):::process E --> F(重写 SALESPERSON 记录):::process F --> G(插入新 ORDER 记录):::process G --> H{系统崩溃?}:::decision H -->|是| I(记录日志):::process I --> J(恢复处理器):::process J --> K(应用前映像):::process K --> L(回滚事务):::process H -->|否| M(继续处理):::process ``` 为了减少恢复数据库所需的处理时间，DBMS 产品有时会使用检查点（Checkpoints）。检查点是数据库和事务日志之间的同步点。执行检查点时，DBMS 会拒绝新请求，完成未完成的请求，并将其缓冲区写入磁盘。然后，DBMS 会等待操作系统通知它所有对数据库和日志的未完成写入请求已成功完成。此时，日志和数据库同步。然后将检查点记录写入日志。之后，可以从检查点恢复数据库，并且只需要应用检查点之后开始的事务的后映像。 检查点操作成本较低，每小时进行三到四次（或更多）是可行的。这样，最多只需恢复 15 到 20 分钟的处理。大多数 DBMS 产品会自动执行检查点，无需人工干预。 #### 3. 数据库管理员的其他职责 除了安全和备份恢复，数据库管理员（DBA）还有其他重要的管理职责。 - **错误