深入探索Teradata数据库的并发控制、恢复与安全机制
1. 事务概念
事务是数据库操作的基本单元,其生命周期与特定操作密切相关。一个事务在应用执行
COMMIT
、
ROLLBACK
或
ABORT
语句时结束。事务的最后一条语句必须是数据定义语句(如
DATABASE
和
SET SESSION
等)。在 ANSI 事务语义下,
BEGIN TRANSACTION
和
END TRANSACTION
语句以及两阶段提交协议是不被允许的,若应用提交这些语句,数据库软件会报错。
ANSI 模式下,在以下情况会回滚整个事务:
- 当前请求导致死锁。
- 执行的 DDL 语句中止。
- 执行显式的
ROLLBACK
或
ABORT
语句。
ABORT
和
ROLLBACK
语句在 ANSI 模式下是被接受的,包括它们的条件形式。当单条或多条语句请求出错时,通常仅回滚该请求,事务保持打开状态,但在特定特殊情况下,整个事务会被回滚。此外,应用发起的异步中止也会导致在 ANSI 环境下整个事务回滚。
Teradata 事务分为隐式和显式两种。多语句请求和宏属于隐式事务,而嵌入式 SQL 应用进行的事务则是显式事务的例子。以下是一个带有嵌入式 SQL 和事务的 COBOL 程序示例:
EXEC SQL
BEGIN TRANSACTION
END-EXEC
EXEC SQL
DELETE FROM Employee
WHERE Name = ‘Smith T’
END-EXEC
EXEC SQL
UPDATE Department
SET EmpCount=EmpCount-1
WHERE DeptNo=500
END-EXEC
EXEC SQL
END TRANSACTION
END-EXEC
如果在
BEGIN TRANSACTION
和
END TRANSACTION
语句内的
DELETE
或
UPDATE
语句处理过程中出错,
Employee
和
Department
表将恢复到事务开始前的状态。当 Teradata 事务出现错误时,整个事务会被回滚。
若要撤销已完成的更新操作,可以通过将事务日志(或日志文件)应用到数据库,使其恢复到事务开始前的状态。事务日志包含数据库的前映像,可用于撤销事务;而包含数据库后映像的事务日志则可用于重做事务。事务在检查点或同步点开始和结束,事务恢复系统利用这些检查点将数据应用到准确的时间点,以将数据库恢复到更早(或更晚)的状态。
2. 锁的概念
锁是一种声明对某些资源使用权限的手段。可锁定的资源类型多样,锁定方式也各不相同。
在 Teradata RDBMS 中,大多数对资源的锁定默认是自动进行的。用户可以通过特定的锁规范来覆盖某些锁定,但前提是要保证数据的完整性。所施加的锁类型取决于请求的数据完整性要求。当其他用户请求已锁定的资源时,该请求会被排队,直到使用该资源的进程释放其锁。Teradata 锁管理器会隐式锁定以下对象:
| 锁定对象 | 描述 |
| — | — |
| 数据库 | 锁定数据库中所有表的行 |
| 表 | 锁定表中的所有行以及任何索引和后备子表 |
| 视图 | 锁定视图中的所有基础表 |
| 行哈希 | 锁定行的主副本(所有具有相同哈希码的行) |
数据库管理系统需要锁定机制,以避免常见的更新丢失异常等问题。例如,在多个进程访问同一数据库的情况下,如果没有锁定机制,可能会出现数据库对相同数据进行操作却得到不同(错误)结果的情况。
在 Teradata 数据库中,用户可以锁定三种资源类型:
- 数据库
- 表
- 行哈希
用户可以对 Teradata 资源施加四种不同级别的锁,具体如下表所示:
| 锁类型 | 描述 |
| — | — |
| 排他锁 | 请求者对锁定资源具有排他权,其他进程无法以任何方式读取、写入或访问该资源。通常在对数据库进行结构更改时才需要排他锁。 |
| 写入锁 | 请求者对锁定资源具有排他权,但不影响不关心数据一致性的读取者。 |
| 读取锁 | 请求者在读取资源时对其具有排他权,可确保读取操作(如
SELECT
语句执行期间)的一致性。多个用户可以同时持有对同一资源的读取锁,在此期间不允许对该资源进行修改。 |
| 访问锁 | 请求者在访问数据库时不关心数据的一致性。访问锁允许在
SELECT
操作进行期间对基础数据进行修改。 |
Teradata RDBMS 会自动施加大部分锁,不同类型的 SQL 语句所施加的锁如下表所示:
| SQL 语句类型 | 按访问类型的锁定级别 | 锁定模式 |
| — | — | — |
|
SELECT
| UPI/NUPI/USI:行哈希;NUSI/全表扫描:表 | 读取 |
|
UPDATE
| UPI/NUPI/USI:行哈希;NUSI/全表扫描:表 | 写入 |
|
DELETE
| UPI/NUPI/USI:行哈希;NUSI/全表扫描:表 | 写入 |
|
INSERT
| UPI/NUPI/USI:行哈希;NUSI/全表扫描:不适用 | 写入 |
|
CREATE DATABASE
、
DROP DATABASE
、
MODIFY DATABASE
| UPI/NUPI/USI:不适用;NUSI/全表扫描:数据库 | 排他 |
|
CREATE TABLE
、
DROP TABLE
、
ALTER TABLE
| UPI/NUPI/USI:不适用;NUSI/全表扫描:表 | 排他 |
死锁是指事务 1 锁定资源 A 后需要锁定资源 B,而资源 B 已被事务 2 锁定,事务 2 又需要锁定资源 A 的情况。Teradata RDBMS 通过中止其中一个事务来解决死锁问题。如果事务源自 BTEQ,BTEQ 会重新提交该事务;其他客户端软件则可能会或可能不会重新提交事务。以下是不同锁请求和持有锁类型的兼容性表格:
| 锁请求 \ 持有锁类型 | 无 | 访问 | 读取 | 写入 | 排他 |
| — | — | — | — | — | — |
| 访问 | 授予 | 授予 | 授予 | 授予 | 排队 |
| 读取 | 授予 | 授予 | 授予 | 排队 | 排队 |
| 写入 | 授予 | 授予 | 排队 | 排队 | 排队 |
| 排他 | 授予 | 排队 | 排队 | 排队 | 排队 |
3. 主机实用程序锁
Archive/Storage Facility(ASF2)和客户端驻留的存档/恢复工具使用的锁定操作与 Teradata RDBMS 不同,这些锁在 Teradata RDBMS 手册中常被称为 HUT(主机实用程序)锁。
HUT 锁的放置情况如下:
| 锁类型 | 锁定对象 |
| — | — |
| 读取 | 任何正在转储的对象 |
| 组读取 | 仅当表定义了后映像永久日志并且在
DUMP
命令中选择了相应选项时,转储的表的行 |
| 写入 | 正在恢复的永久日志表;恢复操作期间
ROLLFORWARD
或
ROLLBACKWARD
中的所有表;正在删除的日志表 |
| 排他 | 任何正在恢复的对象 |
HUT 锁具有以下特点:
- 与当前登录并输入语句的用户相关联,而非与作业或事务相关。
- 仅放置在参与实用程序操作的 AMP 上的对象上。
- 在
CLUSTER
转储期间在集群级别放置。
- 不会与同一用户在同一对象上放置的其他级别的实用程序锁冲突。
- 保持活动状态,直到通过实用程序命令的
RELEASE LOCK
选项或在实用程序操作完成后执行 Teradata SQL
RELEASE LOCk
语句释放。
- 如果在 Teradata RDBMS 重启前未被释放,则会自动恢复。
4. 系统和媒体恢复
系统恢复描述了 Teradata RDBMS 在系统或媒体故障后如何重启。非计划重启可能由以下原因之一引起:
- AMP 或磁盘故障
- 软件故障
- 奇偶校验错误
所有软件恢复的方式相同,而硬件故障会使受影响的组件离线,直到修复或更换。
当发生非计划重启时,会出现两种类型的事务自动恢复:
| 恢复类型 | 发生情况 |
| — | — |
| 单事务恢复 | RDBMS 因以下原因中止单个事务:事务死锁超时、用户错误、用户发起的中止命令、数据表格不一致、解析资源不可用。单事务恢复使用瞬态日志来恢复数据。 |
| RDBMS 恢复 | RDBMS 重启由以下原因引起:硬件故障、软件故障、用户命令。 |
当 AMP 在系统恢复期间未能上线时,RDBMS 会使用后备数据继续处理事务。当离线的 AMP 重新上线时,会启动 AMP 恢复程序以更新该 AMP 的数据。如果需要处理的行数较多,AMP 将离线恢复,RDBMS 会在后台模式下将更新发送到离线的 AMP;如果只需处理少量行,则在线恢复。完成所有更新后,AMP 被视为完全上线。
5. 两阶段提交
两阶段提交(2PC)是一种用于确保分布式数据库环境中事务提交的协议。Teradata RDBMS 默认仅在运行 IMS 或 CICS 数据库的 MVS 环境中支持两阶段提交,ANSI 事务语义不允许使用该协议。
Teradata RDBMS 实现参与者端,而 IMS 和 CICS 实现协调器。用户可以编写自定义协调器软件,并与支持参与者端的 Teradata RDBMS 和其他 DBMS 一起实现 2PC。该协议确保分布式事务中的所有参与者在继续操作之前就是否提交事务达成一致。
相关定义如下:
- 参与者:是指代表事务执行某些工作,并在分布式环境中提交或中止数据库事务的数据库管理器。任何数量的参与者都可以参与两阶段提交操作。参与者从投票决定提交或中止到收到协调器的提交或中止指令期间处于不确定状态。
- 协调器:是分布式环境中的控制数据库管理器,协调器永远不会处于不确定状态。在 Teradata RDBMS 中,协调器通常是 IMS 或 CICS,每个事务在同一时间只能有一个协调器。
两阶段提交协议的工作流程如下:
1.
阶段 1
:协调器请求所有参与者投票决定提交或中止,或者进入可以提交或回滚的状态。当参与者达到此状态时,会向协调器发送 OK 消息。如果协调器未收到此消息(或超时),则认为操作失败。
2.
阶段 2
:当事务中的所有参与者都向协调器发送 OK 消息后,协调器向所有参与者广播提交命令;如果并非所有参与者都发送 OK 消息,则协调器广播回滚命令。
两阶段提交的主要组件和接口如下表所示:
| 接口 | 功能 |
| — | — |
| 应用 - 参与者 | 请求 2PC 会话 |
| 协调器 - 参与者 | 处理 2PC 协议,包括投票请求、中止和提交消息 |
| 参与者 - 协调器 | 管理从参与者到协调器的通信,包括对会话信息请求的响应 |
| 应用 - 协调器 | 发起提交请求 |
不同应用开发工具支持的 2PC 会话数量如下表所示:
| 应用开发工具 | 支持的会话数量 |
| — | — |
| CLI 版本 2 | 多个 |
| 预处理器 2 | 一个 |
6. 安全与完整性
安全和完整性是 Teradata RDBMS 的重要方面。安全是指保护数据库免受未经授权的用户访问,而完整性则确保用户的操作是正确的,即保护数据库免受授权用户的错误操作。
系统安全的解决方案可分为以下四类:
| 类别 | 描述 |
| — | — |
| 资源访问控制 | 软件实施的访问限制 |
| 物理访问控制 | 物理访问限制 |
| 审计和问责 | 对与安全相关的用户操作进行系统审计 |
| 策略 | 完善且执行良好的数据中心安全策略 |
Teradata RDBMS for UNIX 的 2.0 版本支持引用完整性,用户也可以编写宏来强制执行系统中包含外键字段的每个表的引用完整性。
7. 资源访问控制
可以使用以下 Teradata 软件工具来实施访问限制:
- 用户标识符(用户名)
- 通道或 LAN 标识符(主机或客户端标识符)
- 登录策略
- TDP 用户安全接口
- 客户端安全
用户标识符是 Teradata 访问控制的基础,安全管理员可以选择同时强制执行通道或 LAN 客户端标识符。用户名是在
CREATE USER
语句中定义的,安全管理员必须为每个授权用户执行一次
CREATE USER
语句,以建立用户名、定义其密码并分配用户磁盘空间。用户名和数据库名存储在
DBase
表中,该表位于名为
DBC
的系统用户分配的空间中,可通过查询系统视图
DBC.Users
从
DBC.DBase
表中检索有关用户名的信息。
任何数量的不同客户端类型都可以连接到 Teradata RDBMS 服务器,每个连接都必须有自己唯一的客户端标识符。每个连接会被分配一个唯一的值,该值通过
Config
实用程序定义给 Teradata RDBMS,并用作客户端标识符(或主机 ID)。
用户必须发出登录请求,以便 Teradata RDBMS 识别用户并建立会话。登录字符串必须包含已在系统
DBase
中建立的用户名,还可以包含以下操作数的任意组合:
| 操作数 | 定义 |
| — | — |
| tdpid | 给定客户端上的每个 TDP 副本都被分配一个唯一的
tdpid
以进行标识,
tdpid
是基于客户端的操作数,不会传输到 Teradata RDBMS。 |
| 密码 | 密码用于验证用户以指定用户名发起 Teradata 会话的请求。默认情况下,密码必须出现在用户登录字符串中。安全管理员可以通过设置以下条件来允许无密码登录:存在包含
WITH NULL PASSWORD
选项的当前
GRANT LOGON
语句;TDP 安全用户退出
TDPLGUX
必须确认无密码的登录字符串有效(仅适用于 IBM 大型机客户端)。 |
| acctid | 账户 ID 可用于资源核算,每个用户名可以有一个或多个
acctid
。如果登录处理器在用户的登录字符串中未检测到
acctid
,则会分配一个默认值。
acctid
还可以包含一个优先级前缀,用于在交互式用户与长时间运行的批处理作业竞争系统资源时使用。 |
综上所述,Teradata 数据库在并发控制、恢复和安全方面提供了丰富的机制和功能,以确保数据的一致性、可用性和安全性。通过合理运用事务、锁、恢复和安全策略,用户可以更好地管理和维护数据库系统。
深入探索Teradata数据库的并发控制、恢复与安全机制
8. 客户端密码安全
客户端密码安全是保障Teradata数据库安全的重要环节。在用户登录过程中,密码起到了验证用户身份的关键作用。默认情况下,用户在登录时必须提供正确的密码,这个密码是在使用
CREATE USER
语句创建用户时所定义的。
安全管理员可以根据实际需求,对密码策略进行灵活配置。例如,若要允许用户无密码登录,需要满足特定条件:
- 存在包含
WITH NULL PASSWORD
选项的当前
GRANT LOGON
语句。
- 对于 IBM 大型机客户端,TDP 安全用户退出
TDPLGUX
必须确认无密码的登录字符串有效。
需要注意的是,即使允许无密码登录,数据库的其他安全措施依然会正常执行,以确保数据库的整体安全性不受影响。以下是一个简单的流程图,展示了客户端登录时密码验证的基本流程:
graph TD
A[用户发起登录请求] --> B{是否提供密码}
B -- 是 --> C{密码是否正确}
C -- 是 --> D[登录成功]
C -- 否 --> E[登录失败]
B -- 否 --> F{是否满足无密码登录条件}
F -- 是 --> D
F -- 否 --> E
9. 服务器密码安全
服务器密码安全同样不容忽视,它是数据库安全防护的一道重要防线。服务器密码主要涉及到系统用户和数据库管理员的账户密码,这些密码用于保护服务器的核心功能和敏感数据。
为了确保服务器密码的安全性,建议采用以下措施:
-
定期更换密码
:设置合理的密码更换周期,避免长期使用同一密码,降低密码被破解的风险。
-
使用强密码
:密码应包含字母、数字和特殊字符,且长度足够长,以增加密码的复杂度。
-
限制访问权限
:严格控制能够访问服务器密码的人员范围,仅授权必要的人员进行操作。
服务器密码的管理流程可以用以下步骤概括:
1.
创建初始密码
:在创建系统用户或数据库管理员账户时,设置初始密码。
2.
密码存储
:将密码以加密的方式存储在服务器中,防止明文泄露。
3.
密码验证
:在用户登录或执行敏感操作时,对输入的密码进行验证。
4.
密码更新
:按照预定的周期或在必要时,更新密码。
5.
密码重置
:当用户忘记密码或密码泄露时,提供安全的密码重置机制。
10. Teradata SQL数据控制语言命令
Teradata SQL数据控制语言(DCL)命令用于授予和撤销用户对数据库资源的权限,是实现数据库安全管理的重要手段。常见的 DCL 命令包括
GRANT
和
REVOKE
。
10.1 GRANT 命令
GRANT
命令用于授予用户特定的权限,其基本语法如下:
GRANT privilege [, privilege, ...]
ON object
TO user [, user, ...]
[WITH GRANT OPTION];
-
privilege:指定要授予的权限,如SELECT、INSERT、UPDATE、DELETE等。 -
object:指定权限所应用的数据库对象,如表、视图、存储过程等。 -
user:指定被授予权限的用户或角色。 -
WITH GRANT OPTION:可选参数,若指定该参数,被授予权限的用户可以将这些权限再授予其他用户。
例如,以下命令将
SELECT
和
INSERT
权限授予用户
user1
和
user2
,并允许他们将这些权限再授予其他用户:
GRANT SELECT, INSERT
ON Employees
TO user1, user2
WITH GRANT OPTION;
10.2 REVOKE 命令
REVOKE
命令用于撤销用户已有的权限,其基本语法如下:
REVOKE privilege [, privilege, ...]
ON object
FROM user [, user, ...];
例如,以下命令撤销用户
user1
对
Employees
表的
SELECT
和
INSERT
权限:
REVOKE SELECT, INSERT
ON Employees
FROM user1;
11. 安全与完整性的综合应用
在实际的数据库管理中,需要将安全和完整性机制综合应用,以构建一个坚固的安全防护体系。以下是一些具体的应用场景和建议:
11.1 多用户环境下的资源访问控制
在多用户的数据库环境中,不同用户可能具有不同的访问需求和权限级别。通过合理配置资源访问控制机制,如使用用户标识符、客户端标识符和登录策略,可以确保每个用户只能访问其被授权的资源。例如,对于普通员工用户,只授予他们对自己部门数据的查询权限;而对于高级管理人员,则可以授予他们对整个数据库的查询和部分修改权限。
11.2 数据完整性保护
为了保证数据的完整性,可以结合使用约束和引用完整性机制。例如,在创建表时,可以定义主键和外键约束,确保数据的一致性和关联性。同时,编写宏来强制执行引用完整性,防止出现数据不一致的情况。
11.3 安全审计与监控
定期进行安全审计和监控,记录用户的操作行为和系统事件。通过分析审计日志,可以及时发现异常行为和潜在的安全威胁,并采取相应的措施进行处理。例如,当发现某个用户频繁尝试登录失败时,可能存在暴力破解密码的风险,此时可以及时锁定该用户账户并进行进一步的调查。
12. 总结与展望
Teradata数据库在并发控制、恢复和安全方面提供了丰富而强大的功能。通过合理运用事务、锁、恢复机制以及安全策略,可以有效地保障数据库的一致性、可用性和安全性。
在未来,随着数据量的不断增长和业务需求的日益复杂,数据库的安全和性能将面临更大的挑战。因此,需要不断优化和完善现有的机制,同时探索新的技术和方法,以适应不断变化的环境。例如,引入人工智能和机器学习技术,实现对安全威胁的实时监测和预测;采用更高效的并发控制算法,提高数据库的并发处理能力。
总之,深入理解和掌握Teradata数据库的并发控制、恢复与安全机制,对于数据库管理员和开发人员来说至关重要。只有不断学习和实践,才能更好地管理和维护数据库系统,为企业的业务发展提供有力的支持。
超级会员免费看
3692

被折叠的 条评论
为什么被折叠?



