本文为Oracle 19c VLDB and Partitioning Guide第5章Managing and Maintaining Time-Based Information的读书笔记。
Oracle 数据库提供了基于时间管理和维护数据的策略。
本章讨论 Oracle 数据库中的组件，这些组件可以构建基于时间管理和维护数据的策略。
尽管大多数组织长期以来一直将他们的数据存储视为最有价值的企业资产之一，但这些数据的管理和维护方式因公司而异。 最初，数据用于帮助实现运营目标、经营业务以及帮助确定公司未来的方向和成功。
然而，新的政府法规和指导方针是数据保留方式和原因的关键驱动力。 现在的法规要求组织在很长一段时间内保留和控制信息。 因此，如今信息技术 (IT) 经理正在努力满足其他目标：
- 以尽可能低的成本存储大量数据
- 满足数据保留和保护的新法规要求
- 通过基于更多数据的更好分析来增加商机
5.1 Managing Data in Oracle Database With ILM
借助信息生命周期管理 (ILM)，您可以使用适用于该数据的规则和法规来管理 Oracle 数据库中的数据。
当今的信息有多种类型，例如电子邮件消息、照片或联机事务处理 (OLTP) 系统中的订单。 了解数据的类型及其使用方式后，您就会了解数据的演变和最终处置方式。
每个组织面临的一个挑战是了解其数据如何演变和增长，监控其使用如何随时间变化，并决定它应该留存多长时间，同时遵守现在适用于该数据的所有规则和法规。 信息生命周期管理 (ILM) 旨在通过流程、策略、软件和硬件的组合来解决这些问题，以便可以在数据生命周期的每个阶段使用适当的技术。
5.1.1 About Oracle Database for ILM
Oracle 数据库为实施 ILM 解决方案提供了理想的平台。
Oracle 数据库平台提供以下功能：
-
应用程序透明度
应用程序透明性在 ILM 中非常重要，因为它意味着无需自定义应用程序，并且还可以对数据进行各种更改而不会对使用该数据的应用程序产生任何影响。 数据可以在其生命周期的不同阶段轻松移动，并且可以使用数据库优化对数据的访问。 另一个重要的好处是，应用透明度提供了快速适应任何新监管要求所需的灵活性，同样不会对现有应用产生任何影响。 -
细粒度数据
Oracle 可以非常细粒度地查看数据并将相关数据分组，而存储设备只能看到字节和块。 -
低成本存储
由于要保留如此多的数据，使用低成本存储是实施 ILM 的关键因素。 由于 Oracle 可以利用多种类型的存储设备，因此可以以尽可能低的成本保存最大量的数据。 -
可执行的合规政策
当出于合规原因保留信息时，必须向监管机构表明数据是按照法规保留和管理的。 在 Oracle 数据库中，可以定义安全和审计策略，这些策略强制执行并记录对数据的所有访问。
5.1.1.1 Oracle Database Manages All Types of Data
信息生命周期管理涉及组织中的所有数据。
这些数据不仅包括结构化数据，例如 OLTP 系统中的订单或数据仓库中的销售历史，还包括非结构化数据，例如电子邮件、文档和图像。 Oracle 数据库支持使用 BLOB 和 Oracle SecureFiles 存储非结构化数据，Oracle Text 中提供了一个复杂的文档管理系统。
如果您组织中的所有信息都包含在 Oracle 数据库中，那么您可以利用数据库提供的特性和功能来管理和移动数据在其生命周期内的演变，而无需管理多种类型的数据存储 .
5.1.1.2 Regulatory Requirements
许多组织必须在特定时间段内保留特定数据。 不遵守这些规定可能导致组织不得不支付巨额罚款。
世界各地的各种监管要求，例如美国的 Sarbanes-Oxley、HIPAA、DOD5015.2-STD 和欧盟的欧洲数据隐私指令，正在改变组织管理其数据的方式。 这些规定规定了哪些数据必须保留，是否可以更改，以及必须保留多长时间，可以是 30 年或更长时间。
这些法规经常要求确保电子数据的安全，防止未经授权的访问和更改，并且对数据的所有更改以及由谁进行的更改进行审计跟踪。 Oracle 数据库可以在不影响应用程序性能的情况下保留大量数据。 它还包含限制访问和防止未经授权更改数据所需的特性，并且可以通过 Oracle Audit Vault 和 Database Firewall 进一步增强。 Oracle 数据库还提供了加密函数，可以证明高权限用户没有故意修改数据。 使用闪回数据技术，您可以将行在其生命周期内的所有版本存储在防篡改历史存档中。
5.1.1.3 The Benefits of an Online Archive
在线存档有很多好处。
在数据的生命周期中，通常会出现一个不再定期访问并且被认为符合归档条件的时刻。 传统上，数据会从数据库中删除并存储在磁带上，您可以在磁带上以极低的成本存储大量信息。 如今，不再需要将该数据存档到磁带，而是可以将其保留在数据库中，或传输到中央在线存档数据库。 所有这些信息都可以使用每 GB 成本非常接近磁带的低成本存储设备来存储。
将所有数据保存在 Oracle 数据库中以供存档有很多好处。 最重要的好处是数据总是即时可用。 因此，时间不会浪费在查找存档数据的磁带和确定磁带是否可读以及是否仍处于可以加载到数据库中的格式上。
如果数据已经存档多年，那么可能还需要开发时间来编写程序将数据从磁带存档重新加载到数据库中。 这可能会被证明是昂贵且耗时的，尤其是在数据非常陈旧的情况下。 如果数据保留在数据库中，那么这不是问题，因为它是在线的，并且是最新的数据库格式。
将历史数据保存在数据库中不再影响备份数据库所需的时间和备份的大小。 当RMAN 用于备份数据库时，它只在备份中包含已更改的数据。 因为历史数据不太可能发生变化，所以备份过的数据就不会再备份了。
另一个需要考虑的重要因素是如何从数据库中物理删除数据，尤其是当数据要从生产系统传输到中央数据库存档时。 Oracle 提供了通过使用可传输表空间或分区在数据库之间快速移动这些数据的能力，这将数据作为一个完整的单元进行移动。
当需要从数据库中删除数据时，最快的方法是删除一组数据。 这是通过将数据保存在其自己的分区中来实现的。 可以删除分区，这是一个非常快速的操作。 但是，如果由于必须维护数据关系而无法使用此方法，则必须发出常规的 SQL 删除语句。 您不应低估发出删除语句所需的时间。
如果有从数据库中移除数据的需求，并且将来可能需要将数据返回到数据库中，那么可以考虑以可传输表空间等数据库格式移除数据，或者使用 XML Oracle 数据库以开放格式提取信息的能力。
考虑将您的数据在线归档到 Oracle 数据库中，原因如下：
- 磁盘的成本接近磁带的成本，因此您可以省去查找包含数据的磁带的时间以及恢复该数据的成本
- 数据在需要时保持在线，为您提供更快的访问以满足业务需求
- 在线数据意味着即时访问，因此监管机构因未能提供数据而被罚款的可能性较小
- 可以使用当前应用程序访问数据，因此您无需浪费资源构建新应用程序
5.1.2 Implementing ILM Using Oracle Database
使用 Oracle 数据库构建信息生命周期管理解决方案非常简单。
ILM 解决方案可以通过以下四个简单步骤完成，但如果未实施 ILM 以实现合规性，则第 4 步是可选的：
- 第 1 步：定义数据类
- 第 2 步：为数据类创建存储层
- 第 3 步：创建数据访问和迁移策略
- 第 4 步：定义和执行合规政策
5.1.2.1 Step 1: Define the Data Classes
要有效利用信息生命周期管理，请在实施信息生命周期管理解决方案之前首先检查组织中的所有数据。
查看数据后，确定以下内容：
- 什么数据是重要的，它存储在哪里，什么必须保留
- 这些数据如何在组织内流动
- 随着时间的推移，这些数据会发生什么变化以及是否仍然需要它
- 所需的数据可用性和保护程度
- 法律和业务要求的数据保留
在了解了数据的用途之后，就可以在此基础上对数据进行分类。 最常见的分类类型是按年份或日期，但其他类型也是可能的，例如按产品或隐私。 也可以使用混合分类，例如按隐私和年份分类。
要区别对待数据类，数据必须在物理上分开。 最初创建信息时，通常会经常访问该信息，但随着时间的推移，可能很少有人引用它。 例如，当客户下订单时，他们会定期查看订单以查看其状态以及订单是否已发货。 订单到达后，他们可能永远不会再参考该订单。 此订单也将包含在运行以查看正在订购哪些商品的定期报告中，但随着时间的推移，不会出现在任何报告中，并且只有在有人进行涉及此的详细分析时才会在将来被引用。 例如，订单可以按财务季度 Q1、Q2、Q3 和 Q4 分类，也可以分类为历史订单。
使用这种方法的优点是，当数据按类别在行级别分组时，在本例中是订单日期，Q1 的所有订单都可以作为一个独立的单元进行管理，而Q2 的订单将驻留在不同的类中。 这可以通过使用分区来实现。 因为分区对应用程序是透明的，所以数据在物理上是分开的，但应用程序仍然可以找到所有订单。
5.1.2.1.1 Partitioning for ILM
分区涉及根据数据值物理放置数据，并且经常使用的技术是按日期对信息进行分区。
图 5-1 说明了一个场景，其中 Q1、Q2、Q3 和 Q4 的订单存储在单独的分区中，而前几年的订单存储在其他分区中。
图 5-1 将数据类分配给分区
Oracle 提供了几种不同的分区方法。 范围分区是 ILM 中一种常用的分区方法。 间隔和参考分区也特别适合在 ILM 环境中使用。
对数据进行分区有很多好处。 分区提供了一种简单的方法，可以根据数据的使用情况将数据分布在适当的存储设备上，同时仍然保持数据在线并存储在最具成本效益的设备上。 因为分区对访问数据的任何人都是透明的，所以不需要更改应用程序，因此可以随时实现分区。 当需要新分区时，只需使用 ADD PARTITION 子句添加它们，或者如果使用间隔分区，则自动创建它们。
除其他好处外，每个分区都可以有自己的本地索引。 当优化器使用分区修剪时，查询只访问相关分区而不是所有分区，从而提高查询响应时间。
5.1.2.1.2 The Lifecycle of Data
对您的数据进行分析可能会发现，最初，它的访问和更新频率非常高。 随着数据年龄的增加，其访问频率会降低到几乎可以忽略不计（如果有的话）。
大多数组织发现自己处于许多用户访问当前数据而极少数用户访问旧数据的情况，如图 5-2 所示。 数据被认为是：活跃的、不太活跃的、历史的或准备存档的。
由于保存了如此多的数据，因此在其生命周期内，数据应移动到不同的物理位置。 根据数据在其生命周期中所处的位置，它必须位于最合适的存储设备上。
图 5-2 随时间变化的数据使用情况
5.1.2.2 Step 2: Create Storage Tiers for the Data Classes
因为 Oracle 数据库可以利用许多不同的存储选项，所以实施信息生命周期管理解决方案的第二步是建立所需的存储层。
尽管您可以根据需要创建任意数量的存储层，但建议从以下层开始：
-
高性能
高性能存储层存储所有重要且经常访问的数据，例如保存我们 Q1 订单的分区。 该层在高性能存储设备上使用更小、更快的磁盘。 -
低成本
低成本存储层存储访问频率较低的数据，例如保存 Q2、Q3 和 Q4 订单的分区。 该层是使用大容量磁盘构建的，例如模块化存储阵列中的磁盘或低成本 ATA 磁盘，它们提供最大数量的廉价存储。 -
在线存档
在线存档存储层是存储所有很少访问或修改的数据的地方。 这个存储层可能非常大并且存储最大数量的数据。 您可以使用各种技术来压缩数据。 存储在 ATA 驱动器等低成本存储设备上的数据仍然在线且可用，其成本仅略高于将此信息存储在磁带上的成本，而且没有将数据归档到磁带所带来的缺点。 如果 Online Archive 存储层被标识为只读，那么就不可能更改数据，并且在初始数据库备份后不需要后续备份。 -
离线存档（可选）
脱机存档存储层是一个可选层，因为它仅在需要从数据库中删除数据并以其他格式（例如磁带上的 XML）存储时才使用。
图 5-2 说明了在一个时间间隔内如何使用数据。 使用此信息，可以确定要保留所有这些信息，需要多个存储层来保存所有数据，这还具有显着降低总存储成本的好处。
创建存储层后，在第 1 步：定义数据类中标识的数据类将使用分区在数据库内部物理实现。 这种方法提供了一种简单的方法，可以根据数据的使用情况将数据分布在适当的存储设备上，同时仍然保持数据在线和随时可用，并存储在最具成本效益的设备上。
您还可以使用 Oracle 自动存储管理 (Oracle ASM) 跨存储层管理数据。 Oracle ASM 是一种高性能、易于管理的 Oracle 数据库文件存储解决方案。 Oracle ASM 是一个卷管理器，提供专为数据库使用而设计的文件系统。 要使用 Oracle ASM，您需要为 Oracle 数据库分配分区磁盘，并优先考虑条带化和镜像。 Oracle ASM 管理磁盘空间，将 I/O 负载分配到所有可用资源以优化性能，同时消除手动 I/O 调整的需要。 例如，您可以增加数据库的磁盘大小或将部分数据库移动到新设备，而无需关闭数据库。
5.1.2.2.1 Assigning Classes to Storage Tiers
定义存储层后，可以将步骤 1 中确定的数据类（分区）分配给适当的存储层。
这种分配提供了一种简单的方法，可以根据数据的使用情况将数据分布在适当的存储设备上，使数据保持在线和可用，并存储在最具成本效益的设备上。 在图 5-3 中，识别为活跃、不活跃、历史或准备归档的数据分别分配到高性能层、低成本存储层、在线归档存储层和离线归档。 使用这种方法，不需要更改应用程序，因为数据仍然可见。
图 5-3 数据生命周期
5.1.2.2.2 The Costs Savings of Using Tiered Storage
实施 ILM 策略的好处之一是使用多层存储可以节省成本。
假设要存储 3 TB 的数据，其中 200 GB 用于高性能，800 GB 用于低成本，2 TB 用于在线存档。 假设高性能层的每 GB 成本为 72 美元，低成本层为 14 美元，在线存档层为 7 美元。
表 5-1 说明了使用分层存储可能节省的成本，而不是将所有数据存储在一类存储上。 如您所见，成本节省非常可观，如果数据适用于 OLTP 和 HCC 数据库压缩，则可以进一步节省成本。
表 5-1 使用分层存储节省的成本
| 存储层 | 全部用使用高性能磁盘 | 多个存储层 | 多个存储层+压缩 |
|---|---|---|---|
| 高性能 (200 GB) | $14,400 | $14,400 | $14,400 |
| 低成本 (800 GB) | $57,600 | $11,200 | $11,200 |
| 在线存档 (2 TB) | $144,000 | $14,000 | $5,600 |
| 每列总计 | $216,000 | $39,600 | $31,200 |
5.1.2.3 Step 3: Create Data Access and Migration Policies
实施信息生命周期管理解决方案的第三步是确保只有授权用户才能访问数据并指定如何在其生命周期内移动数据。
随着数据老化，有多种技术可以在存储层之间迁移数据。
5.1.2.3.1 Controlling Access to Data
数据的安全性是信息生命周期管理的另一个非常重要的部分，因为对数据的访问权限可能会在其生命周期内发生变化。
此外，可能存在对如何访问数据提出严格要求的监管要求。
可以使用数据库特性保护 Oracle 数据库中的数据，例如：
- 数据库安全
- 视图
- 虚拟专用数据库（VPD）
虚拟专用数据库 (VPD) 定义了对数据库的非常细粒度的访问级别。 安全策略确定可以查看哪些行以及可见的列。 可以定义多个策略，以便不同的用户和应用程序看到相同数据的不同视图。 例如，大多数用户可以看到 Q1、Q2、Q3 和 Q4 的信息，而只有授权用户才能查看历史数据。
安全策略在数据库级别定义，并透明地应用于所有数据库用户。 这种方法的好处是它为访问数据提供了一个安全和受控的环境，该环境不能被覆盖并且可以在不需要任何应用程序更改的情况下实施。 此外，可以定义只读表空间，以确保数据不会更改。
5.1.2.3.2 Moving Data using Partitioning
在其生命周期中，数据必须移动，分区是一种可以使用的技术。
移动数据可能由于以下原因而发生：
- 为了性能，只有有限数量的订单保存在高性能磁盘上
- 数据不再被频繁访问并且正在使用有价值的高性能存储，并且必须移动到低成本存储设备
- 法律要求信息在给定的时间间隔内始终可用，并且必须以尽可能低的成本安全保存
可以通过多种方式在 Oracle 数据库中物理移动数据以利用不同的存储层。 例如，如果对数据进行分区，则可以将包含 Q2 订单的分区从高性能存储层在线移动到低成本存储层。 因为数据是在数据库中移动的，所以它可以物理移动，而不会影响需要它的应用程序或对普通用户造成中断。
有时必须移动单个数据项，而不是一组数据。 例如，假设数据根据隐私级别进行了分类，并且一份以前保密的报告现在要向公众公开。 如果分类从秘密变为公共并且数据根据其隐私分类进行分区，则该行将自动移动到包含公共数据的分区。
每当数据从其原始来源移动时，确保所选过程符合任何法规要求非常重要，例如，数据不能被更改、防止未经授权的访问、易于读取以及存储在批准的位置。
5.1.2.4 Step 4: Define and Enforce Compliance Policies
信息生命周期管理解决方案的第四步是创建合规策略。
当数据分散且分散时，必须在每个数据位置定义和执行合规性策略，这很容易导致合规性策略被忽视。 但是，使用 Oracle 数据库提供一个中央位置来存储数据意味着可以非常轻松地执行合规性策略，因为它们都是从一个中央位置进行管理和执行的。
在定义合规策略时，请考虑以下方面：
- 数据保留
- 不变性
- 隐私
- 审计
- 过期
5.1.2.4.1 Data Retention
保留策略描述了如何保留数据、必须保留多长时间以及数据生命周期结束后会发生什么。
保留政策的一个例子是记录必须以其原始形式存储，不允许修改，必须保留七年，然后可以删除。 使用 Oracle 数据库安全性，可以确保数据保持不变，并且只有授权的进程才能在适当的时间删除数据。 还可以通过 ILM Assistant 中的生命周期定义来定义保留策略。
5.1.2.4.2 Immutability
不变性涉及向外部方证明数据是完整的且未被修改。
Oracle 数据库可以生成密码或数字签名并保留在数据库内部或外部，以表明数据未被更改。
5.1.2.4.3 Privacy
Oracle 数据库提供了多种方法来确保数据隐私。
可以使用虚拟专用数据库 (VPD) 定义的安全策略严格控制对数据的访问。 此外，可以对各个列进行加密，这样任何查看原始数据的人都看不到其内容。
5.1.2.4.4 Auditing
Oracle 数据库可以跟踪对数据的所有访问和更改。
这些审计功能可以在表级别或通过细粒度审计来定义，细粒度审计指定了何时生成审计记录的标准。 使用 Oracle Audit Vault and Database Firewall 可以进一步增强审计。
5.1.2.4.5 Expiration
最终，数据可能会因业务或监管原因而过期，并且必须从数据库中删除。
Oracle 数据库可以通过简单地删除包含要删除的信息的分区来非常快速和高效地删除数据。
5.2 Implementing an ILM Strategy With Heat Map and ADO
要为数据库中的数据移动实施信息生命周期管理 (ILM) 策略，您可以使用热图和自动数据优化 (ADO) 功能。
注意：Oracle Database 12c 第 2 版多租户环境支持热图和 ADO。这两个功能都是12c以后才支持的。
5.2.1 Using Heat Map
要实施您的 ILM 策略，您可以使用 Oracle 数据库中的热图来跟踪数据访问和修改。
热图提供段级别的数据访问跟踪以及段和行级别的数据修改跟踪。 您可以使用 HEAT_MAP 初始化参数启用此功能。
热图数据可以辅助自动数据优化（ADO）使用ADO策略管理In-Memory列存储（IM列存储）的内容。 使用包括列统计数据和其他相关统计数据的热图数据，IM 列存储可以确定何时快满（在内存压力下）。 如果确定几乎已满，如果有更频繁访问的段将受益于 IM 列存储中的填充，则可以驱逐非活动段。
5.2.1.1 Enabling and Disabling Heat Map
您可以使用 HEAT_MAP 子句通过 ALTER SYSTEM 或 ALTER SESSION 语句在系统或会话级别启用和禁用热图跟踪。
例如，以下 SQL 语句为数据库实例启用热图跟踪。
ALTER SYSTEM SET HEAT_MAP = ON;
启用热图后，内存中的活动跟踪模块会跟踪所有访问。 不跟踪 SYSTEM 和 SYSAUX 表空间中的对象。
以下 SQL 语句禁用热图跟踪。
ALTER SYSTEM SET HEAT_MAP = OFF;
禁用热图时，内存中活动跟踪模块不会跟踪访问。 HEAT_MAP 初始化参数的默认值为 OFF。
HEAT_MAP 初始化参数还启用和禁用自动数据优化 (ADO)。 对于 ADO，必须在系统级别启用热图。
5.2.1.2 Displaying Heat Map Tracking Data With Views
使用 V$、ALL、DBA* 和 USER* 热图视图查看热图跟踪数据。
示例 5-1 显示了热图视图提供的信息示例。 V$HEAT_MAP_SEGMENT 视图显示实时段访问信息。 ALL_、DBA_ 和 USER_HEAT_MAP_SEGMENT 视图显示用户可见的所有段的最新段访问时间。 ALL_、DBA_ 和 USER_HEAT_MAP_SEG_HISTOGRAM 视图显示用户可见的所有段的段访问信息。 DBA_HEATMAP_TOP_OBJECTS 视图显示最活跃对象的热图信息。 DBA_HEATMAP_TOP_TABLESPACES 视图显示最活跃表空间的热图信息。
示例 5-1 热图视图
/* enable heat map tracking if necessary*/
SELECT SUBSTR(OBJECT_NAME,1,20), SUBSTR(SUBOBJECT_NAME,1,20), TRACK_TIME, SEGMENT_WRITE,
FULL_SCAN, LOOKUP_SCAN FROM V$HEAT_MAP_SEGMENT;
SUBSTR(OBJECT_NAME,1 SUBSTR(SUBOBJECT_NAM TRACK_TIM SEG FUL LOO
-------------------- -------------------- --------- --- --- ---
SALES SALES_Q1_1998 01-NOV-12 NO NO NO
SALES SALES_Q3_1998 01-NOV-12 NO NO NO
SALES SALES_Q2_2000 01-NOV-12 NO NO NO
SALES SALES_Q3_1999 01-NOV-12 NO NO NO
SALES SALES_Q2_1998 01-NOV-12 NO NO NO
SALES SALES_Q2_1999 01-NOV-12 NO NO NO
SALES SALES_Q4_2001 01-NOV-12 NO NO NO
SALES SALES_Q1_1999 01-NOV-12 NO NO NO
SALES SALES_Q4_1998 01-NOV-12 NO NO NO
SALES SALES_Q1_2000 01-NOV-12 NO NO NO
SALES SALES_Q1_2001 01-NOV-12 NO NO NO
SALES SALES_Q2_2001 01-NOV-12 NO NO NO
SALES SALES_Q3_2000 01-NOV-12 NO NO NO
SALES SALES_Q4_2000 01-NOV-12 NO NO NO
EMPLOYEES 01-NOV-12 NO NO NO
...
SELECT SUBSTR(OBJECT_NAME,1,20), SUBSTR(SUBOBJECT_NAME,1,20), SEGMENT_WRITE_TIME,
SEGMENT_READ_TIME, FULL_SCAN, LOOKUP_SCAN FROM USER_HEAT_MAP_SEGMENT;
SUBSTR(OBJECT_NAME,1 SUBSTR(SUBOBJECT_NAM SEGMENT_W SEGMENT_R FULL_SCAN LOOKUP_SC
-------------------- -------------------- --------- --------- --------- ---------
SALES SALES_Q1_1998 30-OCT-12 01-NOV-12
SALES SALES_Q1_1998 30-OCT-12 01-NOV-12
SALES SALES_Q1_1998 30-OCT-12 01-NOV-12
SALES SALES_Q1_1998 30-OCT-12 01-NOV-12
SALES SALES_Q1_1998 30-OCT-12 01-NOV-12
SALES SALES_Q1_1998 30-OCT-12 01-NOV-12
...
SELECT SUBSTR(OBJECT_NAME,1,20), SUBSTR(SUBOBJECT_NAME,1,20), TRACK_TIME, SEGMENT_WRITE, FULL_SCAN,
LOOKUP_SCAN FROM USER_HEAT_MAP_SEG_HISTOGRAM;
SUBSTR(OBJECT_NAME,1 SUBSTR(SUBOBJECT_NAM TRACK_TIM SEG FUL LOO
-------------------- -------------------- --------- --- --- ---
SALES SALES_Q1_1998 31-OCT-12 NO NO YES
SALES SALES_Q1_1998 01-NOV-12 NO NO YES
SALES SALES_Q1_1998 30-OCT-12 NO YES YES
SALES SALES_Q2_1998 01-NOV-12 NO NO YES
SALES SALES_Q2_1998 31-OCT-12 NO NO YES
SALES SALES_Q2_1998 30-OCT-12 NO YES YES
SALES SALES_Q3_1998 01-NOV-12 NO NO YES
SALES SALES_Q3_1998 30-OCT-12 NO YES YES
SALES SALES_Q3_1998 31-OCT-12 NO NO YES
SALES SALES_Q4_1998 01-NOV-12 NO NO YES
SALES SALES_Q4_1998 31-OCT-12 NO NO YES
SALES SALES_Q4_1998 30-OCT-12 NO YES YES
SALES SALES_Q1_1999 01-NOV-12 NO NO YES
SALES SALES_Q1_1999 31-OCT-12 NO NO YES
...
SELECT SUBSTR(OWNER,1,20), SUBSTR(OBJECT_NAME,1,20), OBJECT_TYPE, SUBSTR(TABLESPACE_NAME,1,20),
SEGMENT_COUNT FROM DBA_HEATMAP_TOP_OBJECTS ORDER BY SEGMENT_COUNT DESC;
SUBSTR(OWNER,1,20) SUBSTR(OBJECT_NAME,1 OBJECT_TYPE SUBSTR(TABLESPACE_NA SEGMENT_COUNT
-------------------- -------------------- ------------------ -------------------- -------------
SH SALES TABLE EXAMPLE 96
SH COSTS TABLE EXAMPLE 48
PM ONLINE_MEDIA TABLE EXAMPLE 22
OE PURCHASEORDER TABLE EXAMPLE 18
PM PRINT_MEDIA TABLE EXAMPLE 15
OE CUSTOMERS TABLE EXAMPLE 10
OE WAREHOUSES TABLE EXAMPLE 9
HR EMPLOYEES TABLE EXAMPLE 7
OE LINEITEM_TABLE TABLE EXAMPLE 6
IX STREAMS_QUEUE_TABLE TABLE EXAMPLE 6
SH FWEEK_PSCAT_SALES_MV TABLE EXAMPLE 5
SH CUSTOMERS TABLE EXAMPLE 5
HR LOCATIONS TABLE EXAMPLE 5
HR JOB_HISTORY TABLE EXAMPLE 5
SH PRODUCTS TABLE EXAMPLE 5
...
SELECT SUBSTR(TABLESPACE_NAME,1,20), SEGMENT_COUNT
FROM DBA_HEATMAP_TOP_TABLESPACES ORDER BY SEGMENT_COUNT DESC;
SUBSTR(TABLESPACE_NA SEGMENT_COUNT
-------------------- -------------
EXAMPLE 351
USERS 11
SELECT COUNT(*) FROM DBA_HEATMAP_TOP_OBJECTS;
COUNT(*)
----------
64
SELECT COUNT(*) FROM DBA_HEATMAP_TOP_TABLESPACES;
COUNT(*)
----------
2
5.2.1.3 Managing Heat Map Data With DBMS_HEAT_MAP Subprograms
DBMS_HEAT_MAP 包为使用 DBMS_HEAT_MAP 子程序显示热图数据提供了额外的灵活性。
DBMS_HEAT_MAP 包括一组 API，这些 API 将热图外部化在不同存储级别，例如块、范围、段、对象和表空间； 第二组 API 外部化由顶级表空间的后台进程具体化的热图。
示例 5-2 显示了使用 DBMS_HEAT_MAP 包子程序的示例。
示例 5-2 使用 DBMS_HEAT_MAP 包子程序
SELECT SUBSTR(segment_name,1,10) Segment, min_writetime, min_ftstime
FROM TABLE(DBMS_HEAT_MAP.OBJECT_HEAT_MAP('SH','SALES'));
SELECT SUBSTR(tablespace_name,1,16) Tblspace, min_writetime, min_ftstime
FROM TABLE(DBMS_HEAT_MAP.TABLESPACE_HEAT_MAP('EXAMPLE'));
SELECT relative_fno, block_id, blocks, TO_CHAR(min_writetime, 'mm-dd-yy hh-mi-ss') Mintime,
TO_CHAR(max_writetime, 'mm-dd-yy hh-mi-ss') Maxtime,
TO_CHAR(avg_writetime, 'mm-dd-yy hh-mi-ss') Avgtime
FROM TABLE(DBMS_HEAT_MAP.EXTENT_HEAT_MAP('SH','SALES')) WHERE ROWNUM < 10;
SELECT SUBSTR(owner,1,10) Owner, SUBSTR(segment_name,1,10) Segment,
SUBSTR(partition_name,1,16) Partition, SUBSTR(tablespace_name,1,16) Tblspace,
segment_type, segment_size FROM TABLE(DBMS_HEAT_MAP.OBJECT_HEAT_MAP('SH','SALES'));
OWNER SEGMENT PARTITION TBLSPACE SEGMENT_TYPE SEGMENT_SIZE
---------- ---------- ---------------- ---------------- -------------------- ------------
SH SALES SALES_Q1_1998 EXAMPLE TABLE PARTITION 8388608
SH SALES SALES_Q2_1998 EXAMPLE TABLE PARTITION 8388608
SH SALES SALES_Q3_1998 EXAMPLE TABLE PARTITION 8388608
SH SALES SALES_Q4_1998 EXAMPLE TABLE PARTITION 8388608
SH SALES SALES_Q1_1999 EXAMPLE TABLE PARTITION 8388608
...
5.2.2 Using Automatic Data Optimization
要实施您的 ILM 策略，您可以使用自动数据优化 (ADO) 来自动压缩和移动数据库中不同存储层之间的数据。
该功能包括能够创建为每一层指定不同压缩级别的策略，以及控制何时发生数据移动。
要使用自动数据优化，您必须在系统级别启用热图。 您可以使用 HEAT_MAP 初始化参数启用此功能。
5.2.2.1 Managing Policies for Automatic Data Optimization
在使用 SQL 语句创建和更改表时，您可以在行、段和表空间粒度级别为 ADO 指定策略。 此外，ADO 策略可以对索引执行操作。
通过为 ADO 指定策略，您可以在数据库中的不同存储层之间自动进行数据移动。 这些策略还使您能够为每个层指定不同的压缩级别，并控制何时发生数据移动。
表的 ADO 策略
SQL CREATE 和 ALTER TABLE 语句的 ILM 子句使您能够创建、删除、启用或禁用 ADO 策略。 ILM 策略子句确定压缩或存储分层策略并包含其他子句，例如 AFTER 和 ON 子句以指定策略操作应发生的条件。 创建表时，可以为 ADO 添加新策略。 您可以更改该表以添加更多策略或启用、禁用或删除现有策略。 您可以将策略添加到整个表或表的分区。 将 ADO 策略添加到表或表的分区时，您只能为 AFTER 子句指定一种条件类型。 ILM ADO 策略被赋予一个系统生成的名称，例如 P1、P2 等等到 Pn。
段级策略仅执行一次。 策略成功执行后，将被禁用并且不会再次评估。 但是，您可以再次明确启用该策略。 行级别策略继续执行，并且在成功执行后不会被禁用。
可以使用关键字 GROUP、ROW 或 SEGMENT 为一组相关对象或在段或行的级别指定 ADO 策略的范围。
可应用于组策略的默认压缩映射是：
- 堆表上的 COMPRESS ADVANCED 映射到索引的标准压缩和 LOB 段的 LOW。
- 堆表上的 COMPRESS FOR QUERY LOW/QUERY HIGH 映射到索引的标准压缩和 LOB 段的 MEDIUM。
- 堆表上的 COMPRESS FOR ARCHIVE LOW/ARCHIVE HIGH 映射到索引的标准压缩和 LOB 段的 HIGH。
简而言之，对于索引都是标准压缩，对于LOB段则不同压缩级。
无法更改压缩映射。 GROUP 只能应用于段级别策略。 存储分层策略仅适用于段级别，不能在行级别指定。
In-Memory Column Store的ADO策略
自动数据优化 (ADO) 支持具有 INMEMORY、INMEMORY MECOMPRESS 和 NO INMEMORY 策略类型的内存列存储（IM 列存储）。
- 要在内存列存储中启用对象填充，请在 ADD POLICY 子句中包含 INMEMORY。
- 要提高 IM 列存储中对象的压缩级别，请在 ADD POLICY 子句中包含 INMEMORY MEMCOMPRESS。
- 要显式逐出从 IM 列存储中获益最少的对象，请在 ADD POLICY 子句中包含 NO INMEMORY。 例如：
以下是使用 NO INMEMORY 子句从 IM 列存储中逐出对象的示例。
ALTER TABLE sales_2015 ILM ADD POLICY NO INMEMORY
AFTER 7 DAYS OF NO ACCESS;
带有 In-Memory Column Store 子句的 ADO 策略只能是段级策略。 USER/DBA_ILMDATAMOVEMENTPOLICIES 和 V$HEAT_MAP_SEGMENT 视图包括有关内存列存储的 ADO 策略的信息。
定制的ADO策略
您可以使用 ON PL/SQL_function 选项自定义策略，该选项提供了确定何时执行策略的能力。 ON PL/SQL_function 选项仅适用于段级策略。 例如：
CREATE OR REPLACE FUNCTION my_custom_ado_rules (objn IN NUMBER) RETURN BOOLEAN;
ALTER TABLE sales_custom ILM ADD POLICY COMPRESS ADVANCED SEGMENT
ON my_custom_ado_rules;
5.2.2.2 Creating a Table With an ILM ADO Policy
将 ILM ADD POLICY 子句与 CREATE TABLE 语句结合使用，以创建具有 ILM ADO 策略的表。
示例 5-3 中的 SQL 语句创建一个表并添加一个 ILM 策略。
示例 5-3 使用 ILM ADO 策略创建表
/* Create an example table with an ILM ADO policy */
CREATE TABLE sales_ado
(PROD_ID NUMBER NOT NULL,
CUST_ID NUMBER NOT NULL,
TIME_ID DATE NOT NULL,
CHANNEL_ID NUMBER NOT NULL,
PROMO_ID NUMBER NOT NULL,
QUANTITY_SOLD NUMBER(10,2) NOT NULL,
AMOUNT_SOLD NUMBER(10,2) NOT NULL )
PARTITION BY RANGE (time_id)
( PARTITION sales_q1_2012 VALUES LESS THAN (TO_DATE('01-APR-2012','dd-MON-yyyy')),
PARTITION sales_q2_2012 VALUES LESS THAN (TO_DATE('01-JUL-2012','dd-MON-yyyy')),
PARTITION sales_q3_2012 VALUES LESS THAN (TO_DATE('01-OCT-2012','dd-MON-yyyy')),
PARTITION sales_q4_2012 VALUES LESS THAN (TO_DATE('01-JAN-2013','dd-MON-yyyy')) )
ILM ADD POLICY COMPRESS FOR ARCHIVE HIGH SEGMENT
AFTER 12 MONTHS OF NO ACCESS;
/* View the existing ILM ADO polices */
SELECT SUBSTR(policy_name,1,24) POLICY_NAME, policy_type, enabled
FROM USER_ILMPOLICIES;
POLICY_NAME POLICY_TYPE ENABLE
------------------------ ------------- ------
P1 DATA MOVEMENT YES
其它的Policy Type是哪些？
5.2.2.3 Adding ILM ADO Policies
使用带有 ALTER TABLE 语句的 ILM ADD POLICY 子句将 ILM ADO 策略添加到表中。
示例 5-4 中的 SQL 语句提供了将 ILM 策略添加到 sales 表的分区的示例。
示例 5-4 添加 ILM ADO 策略
/* Add a row-level compression policy after 30 days of no modifications */
ALTER TABLE sales MODIFY PARTITION sales_q1_2002
ILM ADD POLICY ROW STORE COMPRESS ADVANCED ROW
AFTER 30 DAYS OF NO MODIFICATION;
/* Add a segment level compression policy for data after 6 months of no modifications */
ALTER TABLE sales MODIFY PARTITION sales_q1_2001
ILM ADD POLICY COMPRESS FOR ARCHIVE HIGH SEGMENT
AFTER 6 MONTHS OF NO MODIFICATION;
/* Add a segment level compression policy for data after 12 months of no access */
ALTER TABLE sales MODIFY PARTITION sales_q1_2000
ILM ADD POLICY COMPRESS FOR ARCHIVE HIGH SEGMENT
AFTER 12 MONTHS OF NO ACCESS;
/* Add storage tier policy to move old data to a different tablespace */
/* that is on low cost storage media */
ALTER TABLE sales MODIFY PARTITION sales_q1_1999
ILM ADD POLICY
TIER TO my_low_cost_sales_tablespace;
/* View the existing polices */
SELECT SUBSTR(policy_name,1,24) POLICY_NAME, policy_type, enabled
FROM USER_ILMPOLICIES;
POLICY_NAME POLICY_TYPE ENABLE
------------------------ ------------- ------
P1 DATA MOVEMENT YES
P2 DATA MOVEMENT YES
P3 DATA MOVEMENT YES
P4 DATA MOVEMENT YES
P5 DATA MOVEMENT YES
5.2.2.4 Disabling and Deleting ILM ADO Policies
使用带有 ALTER TABLE 语句的 ILM DISABLE POLICY 或 ILM DELETE POLICY 子句来禁用或删除 ILM ADO 策略。
您可以禁用或删除 ADO 的 ILM 策略，如示例 5-5 中的 SQL 语句所示。 有时，如果现有 ILM 策略与您要添加的新策略冲突，您可能需要删除这些策略。
示例 5-5 禁用和删除 ILM ADO 策略
/* You can disable or delete an ADO policy in a table with the following */
ALTER TABLE sales_ado ILM DISABLE POLICY P1;
ALTER TABLE sales_ado ILM DELETE POLICY P1;
/* You can disable or delete all ADO policies in a table with the following */
ALTER TABLE sales_ado ILM DISABLE_ALL;
ALTER TABLE sales_ado ILM DELETE_ALL;
/* You can disable or delete an ADO policy in a partition with the following */
ALTER TABLE sales MODIFY PARTITION sales_q1_2002 ILM DISABLE POLICY P2;
ALTER TABLE sales MODIFY PARTITION sales_q1_2002 ILM DELETE POLICY P2;
/* You can disable or delete all ADO policies in a partition with the following */
ALTER TABLE sales MODIFY PARTITION sales_q1_2000 ILM DISABLE_ALL;
ALTER TABLE sales MODIFY PARTITION sales_q1_2000 ILM DELETE_ALL;
5.2.2.5 Specifying Segment-Level Compression and Storage Tiering With ADO
您可以使用段级压缩分层策略在表内的段级指定压缩。
结合行级压缩分层策略，您可以细粒度地控制数据库中数据的存储和管理方式。
示例 5-6 说明了如何为 ADO 创建策略以在 sales_ado 表上实施压缩和存储分层策略，反映了以下业务需求：
- 批量加载数据
- 运行 OLTP 工作负载
- 六个月没有更新后，压缩存档高
- 转向低成本存储
示例 5-6 使用段级压缩和存储分层
/* Add a segment level compression policy after 6 months of no changes */
ALTER TABLE sales_ado ILM ADD POLICY
COMPRESS FOR ARCHIVE HIGH SEGMENT
AFTER 6 MONTHS OF NO MODIFICATION;
Table altered.
/* Add storage tier policy */
ALTER TABLE sales_ado ILM ADD POLICY
TIER TO my_low_cost_tablespace;
SELECT SUBSTR(policy_name,1,24) POLICY_NAME, policy_type, enabled
FROM USER_ILMPOLICIES;
POLICY_NAME POLICY_TYPE ENABLED
------------------------ ------------- -------
...
P6 DATA MOVEMENT YES
P7 DATA MOVEMENT YES
5.2.2.6 Specifying Row-Level Compression Tiering With ADO
除了基本和高级压缩之外，自动数据优化 (ADO) 策略还支持混合列压缩 (HCC)。
无论表的压缩类型如何，都可以在任何表上定义 HCC 行级策略。 当段的其他部分有 DML 活动时，可以使用 HCC 压缩来自冷块的行。
对于非 HCC 表上的 HCC 策略，如果行位于 HCC 压缩单元 (CU) 中，则在更新期间可能会发生行移动。 此外，与行移动的其他用例类似，索引维护对于更新引用移动行的索引条目是必要的。
Oracle Database 12c 第 1 版 (12.1) 支持行级策略：但是，数据库必须兼容 12.2 或更高版本才能使用 HCC 行级压缩策略。
示例 5-7 使用行级混合列压缩创建 ADO 策略
示例 5-7 中的 SQL 语句使用 HCC 在表 employees_ilm 的行上创建了一个策略。
ALTER TABLE employees_ilm
ILM ADD POLICY COLUMN STORE COMPRESS FOR QUERY ROW
AFTER 30 DAYS OF NO MODIFICATION;
示例 5-8 使用行级高级压缩创建 ADO 策略
示例 5-8 中的 SQL 语句创建了一个对表 sales_ado 的行使用高级压缩的策略。
ALTER TABLE sales_ado
ILM ADD POLICY ROW STORE COMPRESS ADVANCED ROW
AFTER 60 DAYS OF NO MODIFICATION;
SELECT policy_name, policy_type, enabled
FROM USER_ILMPOLICIES;
POLICY_NAME POLICY_TYPE ENABLE
------------------------ ------------- -------
...
P8 DATA MOVEMENT YES
5.2.2.7 Managing ILM ADO Parameters
您可以使用在 DBMS_ILM_ADMIN PL/SQL 程序包中使用 CUSTOMIZE_ILM 过程设置的 ILM ADO 参数自定义 ADO 环境。
表 5-2 中描述了各种 ILM ADO 参数。
表 5-2 ILM ADO 参数
| 名称 | 描述 |
|---|---|
| ABSOLUTEJOB LIMIT | 限制并发 ADO 作业的绝对数量。 |
| DEGREEOF PARALLELISM | 确定运行 ADO 策略作业的并行度。 |
| ENABLED | 控制 ADO 后台评估和执行。 默认启用（TRUE 或 1）。ENABLED 的设置和 HEAT_MAP 初始化参数的交互如下： - 如果 HEAT_MAP 初始化参数设置为 ON 且 ENABLED 参数设置为 FALSE (0)，则会收集热图统计信息，但 ADO 不会自动对统计信息进行操作。 - 如果 HEAT_MAP 初始化参数设置为 OFF 且 ENABLED 参数设置为 TRUE (1)，则不会收集热图统计信息，并且因为 ADO 不能依赖热图统计信息，所以 ADO 什么都不做。 ADO 的行为就像 ENABLED 设置为 FALSE 一样。 |
| EXECUTION MODE | 控制 ADO 是在联机模式还是脱机模式下执行。 默认为联机 (2)。 |
| EXECUTION INTERVAL | 决定了 ADO 启动后台评估的频率。 默认值为 15 分钟。 |
| JOB LIMIT | 控制任何时候 ADO 作业的最大数量。 并发 ADO 作业的最大数量计算为 (JOB LIMIT)x(实例数)x(每个实例的 CPU 数)。 默认值为 2。 |
| POLICY TIME | 确定 ADO 策略是以秒还是天为单位指定的。 值为 1 秒或 0 天（默认值）。 |
| RETENTION TIME | 指定已完成 ADO 任务的数据在清除之前保留的时间长度。 默认值为 30 天。 |
| TBS PERCENT USED | 指定当表空间被认为已满时表空间配额的百分比。 默认值为 85%。 |
| TBS PERCENT FREE | TBS_PERCENT_FREE 参数的值指定表空间的目标空闲百分比。 默认值为 25%。 |
对于 TBS_PERCENT* 参数的值，ADO 会尽力而为，但不保证。 当表空间配额的百分比达到 TBS_PERCENT_USED 的值时，ADO 开始移动数据，以便表空间配额的可用百分比接近 TBS_PERCENT_FREE 的值。 例如，假设 TBS_PERCENT_USED 设置为 85，TBS_PERCENT_FREE 设置为 25，并且表空间已满 90%。 然后 ADO 启动移动数据的操作，以便表空间配额至少有 25% 的可用空间，这也可以解释为表空间配额的使用率低于 75%。
您可以使用 DBA_ILMPARAMETERS 视图显示参数。 例如，以下查询显示 ADO 相关参数的值。
SQL> SELECT NAME, VALUE FROM DBA_ILMPARAMETERS;
---------------------------------------------------------------- ----------
ENABLED 1
RETENTION TIME 30
JOB LIMIT 2
EXECUTION MODE 2
EXECUTION INTERVAL 15
TBS PERCENT USED 85
TBS PERCENT FREE 25
POLICY TIME 0
ABSOLUTE JOB LIMIT 10
DEGREE OF PARALLELISM 4
...
5.2.2.8 Using PL/SQL Functions for Policy Management
您可以使用 PL/SQL DBMS_ILM 和 DBMS_ILM_ADMIN 程序包进行高级策略管理和自定义，以实现更复杂的 ADO 场景并控制策略何时主动移动和压缩数据。
使用 PL/SQL DBMS_ILM 和 DBMS_ILM_ADMIN 包，您可以管理 ADO 的 ILM 活动，这样它们就不会对重要的生产工作负载产生负面影响。 数据库兼容性必须至少设置为 12.0 才能使用这些包。
DBMS_ILM 程序包的 EXECUTE_ILM 过程创建并安排作业以执行 ADO 策略。 EXECUTE_ILM() 过程提供此功能，而不管任何先前计划的 ILM 作业。 所有作业均已创建并计划立即运行； 但是，它们是否立即运行取决于调度程序排队的作业数。
如果您希望在执行 ILM 作业时有更多控制，并且不想等到下一个维护窗口，则可以使用 EXECUTE_ILM 过程。
DBMS_ILM 程序包的 STOP_ILM 过程停止所有作业、所有正在运行的作业、基于任务 ID 的作业或特定作业。
DBMS_ILM_ADMIN PL/SQL 包中的 CUSTOMIZE_ILM 过程使您能够自定义 ADO 的设置，如示例 5-9 所示。
例如，您可以设置 TBS_PERCENT_USED 和 TBS_PERCENT_FREE ILM 参数的值或设置 ABS_JOBLIMIT ILM 参数。 TBS_PERCENT_USED 和 TBS_PERCENT_FREE 确定何时根据表空间配额移动数据，ABS_JOBLIMIT 设置并发 ADO 作业的绝对数量。
您还可以使用 DBMS_METADATA PL/SQL 包重新创建包含策略的对象。
示例 5-9 使用 CUSTOMIZE_ILM 自定义 ADO 设置
SQL> BEGIN
2 DBMS_ILM_ADMIN.CUSTOMIZE_ILM(DBMS_ILM_ADMIN.TBS_PERCENT_USED, 85);
3 DBMS_ILM_ADMIN.CUSTOMIZE_ILM(DBMS_ILM_ADMIN.TBS_PERCENT_FREE, 25);
4 END;
5 /
SQL> BEGIN
2 DBMS_ILM_ADMIN.CUSTOMIZE_ILM(DBMS_ILM_ADMIN.ABS_JOBLIMIT, 10);
3 END;
4 /
5.2.2.9 Using Views to Monitor Policies for ADO
您可以使用 DBA_ILM* 和 USER_ILM* 视图查看和监控与您的数据库对象关联的 ADO 策略，从而更轻松地根据需要更改策略。
- DBA/USER_ILMDATAMOVEMENTPOLICIES 视图显示特定于 ADO 的 ILM 策略的数据移动相关属性的信息。
- DBA/USER_ILMTASKS 视图显示过程 EXECUTE_ILM 的任务 ID。 每次用户调用过程 EXECUTE_ILM 时，都会返回一个任务 ID 以跟踪此特定调用。 还会生成一个任务 ID，以跟踪数据库的周期性内部 ILM 任务。 此视图包含有关 ADO 的所有 ILM 任务的信息。
- DBA/USER_ILMEVALUATIONDETAILS 视图显示有关为特定任务考虑的策略的详细信息。 如果选择策略进行评估，它还会显示执行策略的作业的名称。 如果策略未执行，此视图还提供了原因。
- DBA/USER_ILMOBJECTS 视图显示数据库中 ADO 的所有对象和策略。 许多对象通过其父对象继承策略，或者因为它们是在特定表空间中创建的。 此视图提供策略和对象之间的映射。 在继承策略的情况下，此视图还指示继承策略的级别。
- DBA/USER_ILMPOLICIES 视图显示有关数据库中 ADO 的所有策略的详细信息。
- DBA/USER_ILMRESULTS 视图显示有关数据库中 ADO 的数据移动相关作业的信息。
- DBA_ILMPARAMETERS 视图显示有关 ADO 相关参数的信息。
5.2.3 Limitations and Restrictions With ADO and Heat Map
本主题讨论了与 ADO 和热图相关的限制和限制。
与 ADO 和热图相关的限制和限制包括：
- 时间有效性支持分区级 ADO 和压缩，行级 ADO 策略除外，这些策略将压缩超过其有效时间（访问或修改）的行。
- 如果在 ORA_ARCHIVE_STATE 列上分区，分区级 ADO 和压缩支持数据库内归档。
- 如果策略在表空间级别默认，则不支持 ADO 的自定义策略（用户定义的函数）。
- 使用存储分层时，ADO 不检查目标表空间中的存储空间。
- 具有对象类型或物化视图的表不支持 ADO。
- 按索引组织的表或簇不支持 ADO。
- ADO 并发性（ADO 的并发策略作业数）取决于 Oracle 调度程序的并发性。 如果 ADO 的策略作业失败两次以上，则该作业将被标记为已禁用并且稍后必须手动启用该作业。
- ADO 具有与移动表和表分区相关的限制。
5.3 Controlling the Validity and Visibility of Data in Oracle Database
您可以使用数据库内归档和时间有效性来控制 Oracle 数据库中数据的有效性和可见性。
5.3.1 Using In-Database Archiving
In-Database Archiving 使您能够通过将表中的行标记为inactive来对其进行归档。
这些非活动行在数据库中，可以使用压缩进行优化，但对应用程序不可见。如果需要，可通过设置会话参数将这些行中的数据用于合规性目的。
借助数据库内归档，您可以在单个数据库中存储更多数据更长时间，而不会影响应用程序性能。可以压缩存档数据以帮助提高备份性能，并且可以在应用程序升级期间推迟对存档数据的更新以提高升级性能。
要管理表的数据库内存档，您必须ROW ARCHIVAL为表启用并操作表的ORA_ARCHIVE_STATE隐藏列。或者，您可以为会话参数 指定ACTIVE或。ALLROW ARCHIVAL VISIBILITY
例如，您可以使用类似于示例 5-10中的 SQL 语句来隐藏或显示表中的行。目的是在大多数情况下仅显示活动数据，但在特定情况下需要维护所有数据。
实时 SQL：在Oracle Live SQL：使用数据库内存档示例中查看并运行有关 Oracle Live SQL 的相关示例。
示例 5-10 使用数据库内归档
/* Set visibility to ACTIVE to display only active rows of a table.*/
ALTER SESSION SET ROW ARCHIVAL VISIBILITY = ACTIVE;
CREATE TABLE employees_indbarch
(employee_id NUMBER(6) NOT NULL,
first_name VARCHAR2(20), last_name VARCHAR2(25) NOT NULL,
email VARCHAR2(25) NOT NULL, phone_number VARCHAR2(20),
hire_date DATE NOT NULL, job_id VARCHAR2(10) NOT NULL, salary NUMBER(8,2),
commission_pct NUMBER(2,2), manager_id NUMBER(6), department_id NUMBER(4)) ROW ARCHIVAL;
/* Show all the columns in the table, including hidden columns */
SELECT SUBSTR(COLUMN_NAME,1,22) NAME, SUBSTR(DATA_TYPE,1,20) DATA_TYPE, COLUMN_ID AS COL_ID,
SEGMENT_COLUMN_ID AS SEG_COL_ID, INTERNAL_COLUMN_ID AS INT_COL_ID, HIDDEN_COLUMN, CHAR_LENGTH
FROM USER_TAB_COLS WHERE TABLE_NAME='EMPLOYEES_INDBARCH';
NAME DATA_TYPE COL_ID SEG_COL_ID INT_COL_ID HID CHAR_LENGTH
---------------------- -------------------- ---------- ---------- ---------- --- -----------
ORA_ARCHIVE_STATE VARCHAR2 1 1 YES 4000
EMPLOYEE_ID NUMBER 1 2 2 NO 0
FIRST_NAME VARCHAR2 2 3 3 NO 20
LAST_NAME VARCHAR2 3 4 4 NO 25
EMAIL VARCHAR2 4 5 5 NO 25
PHONE_NUMBER VARCHAR2 5 6 6 NO 20
HIRE_DATE DATE 6 7 7 NO 0
JOB_ID VARCHAR2 7 8 8 NO 10
SALARY NUMBER 8 9 9 NO 0
COMMISSION_PCT NUMBER 9 10 10 NO 0
MANAGER_ID NUMBER 10 11 11 NO 0
DEPARTMENT_ID NUMBER 11 12 12 NO 0
/* Insert some data into the table */
INSERT INTO employees_indbarch(employee_id, first_name, last_name, email,
hire_date, job_id, salary, manager_id, department_id)
VALUES (251, 'Scott', 'Tiger', '[email protected]', '21-MAY-2009',
'IT_PROG', 50000, 103, 60);
INSERT INTO employees_indbarch(employee_id, first_name, last_name, email,
hire_date, job_id, salary, manager_id, department_id)
VALUES (252, 'Jane', 'Lion', '[email protected]', '11-JUN-2009',
'IT_PROG', 50000, 103, 60);
/* Decrease the ORA_ARCHIVE_STATE column size to improve formatting in queries */
COLUMN ORA_ARCHIVE_STATE FORMAT a18;
/* The default value for ORA_ARCHIVE_STATE is '0', which means active */
SELECT employee_id, ORA_ARCHIVE_STATE FROM employees_indbarch;
EMPLOYEE_ID ORA_ARCHIVE_STATE
----------- ------------------
251 0
252 0
/* Insert a value into ORA_ARCHIVE_STATE to set the record to inactive status*/
UPDATE employees_indbarch SET ORA_ARCHIVE_STATE = '1' WHERE employee_id = 252;
/* Only active records are in the following query */
SELECT employee_id, ORA_ARCHIVE_STATE FROM employees_indbarch;
EMPLOYEE_ID ORA_ARCHIVE_STATE
----------- ------------------
251 0
/* Set visibility to ALL to display all records */
ALTER SESSION SET ROW ARCHIVAL VISIBILITY = ALL;
SELECT employee_id, ORA_ARCHIVE_STATE FROM employees_indbarch;
EMPLOYEE_ID ORA_ARCHIVE_STATE
----------- ------------------
251 0
252 1
上例和LiveSQL中的例子都只是演示了数据的可见性，但没有说如何不影响性能。
5.3.2 Using Temporal Validity
时间有效性使您能够跟踪真实世界有效性的时间段。数据的有效时间可以由用户和应用程序设置，可以按指定的有效时间或有效时间范围来选择数据。
应用程序通常会记录数据库中记录的事实的有效性（或有效性），以及与业务管理相关的日期或时间戳。例如，人力资源 (HR) 应用程序中员工的雇用日期决定了保险业承保范围的生效日期，这是一个有效日期。该日期与员工记录输入数据库的日期或时间形成对比。前者的时间属性（雇用日期）称为有效时间（VT），而后者（输入数据库的日期）称为交易时间（TT）。有效时间通常由用户控制，而交易时间则由系统管理。注意VT和TT的概念及区别
时间有限性用的是VT的概念。
对于 ILM，有效时间属性可以表示一个事实在商业世界中何时有效，何时无效。使用有效时间属性，查询可以只显示当前有效的行，而不显示包含当前无效事实的行，例如已关闭的订单或未来的雇用。
有效时间时态建模不可或缺的概念包括：
-
有效时间
这是用户定义的时间表示。有效时间的示例包括项目开始和结束日期，以及员工雇用和终止日期。 -
具有有效时间语义的表
这些表具有一个或多个用户定义时间维度，每个维度都有开始和结束。 -
有效时间闪回查询
这是使用有效时间维度执行截至日期和版本查询的能力。
有效时间段由表定义中指定的两个日期时间列组成。您可以通过显式添加列来添加有效时间段，也可以自动创建列。create table 或 alter table 过程中可以添加一个有效时间段。
为了支持时态表查询的会话级可见性控制，DBMS_FLASHBACK_ARCHIVEPL/SQL 包提供了ENABLE_AT_VALID_TIME过程。要执行该过程，您需要所需的系统和对象权限。
以下 PL/SQL 过程设置了给定时间的有效时间可见性。
SQL> EXECUTE DBMS_FLASHBACK_ARCHIVE.enable_at_valid_time
('ASOF', '31-DEC-12 12.00.01 PM');
以下 PL/SQL 过程在会话级别将时态数据的可见性设置为有效时间段内的当前有效数据。
SQL> EXECUTE DBMS_FLASHBACK_ARCHIVE.enable_at_valid_time('CURRENT');
以下过程将时态数据的可见性设置为完整表，这是默认的时态表可见性。
SQL> EXECUTE DBMS_FLASHBACK_ARCHIVE.enable_at_valid_time('ALL');
5.3.3 Creating a Table With Temporal Validity
本主题中的示例展示了如何创建具有时间有效性的表。
示例 5-11显示了时间有效性的使用。
实时 SQL：在Oracle Live SQL：创建具有时间有效性的表中查看并运行有关 Oracle Live SQL 的相关示例。
示例 5-11 创建具有时间有效性的表
-- PERIOD FOR即时间有效性的关键字
/* Create a time with an employee tracking timestamp */
/* using the specified columns*/
CREATE TABLE employees_temp (
employee_id NUMBER(6) NOT NULL, first_name VARCHAR2(20), last_name VARCHAR2(25) NOT NULL,
email VARCHAR2(25) NOT NULL, phone_number VARCHAR2(20), hire_date DATE NOT NULL,
job_id VARCHAR2(10) NOT NULL, salary NUMBER(8,2), commission_pct NUMBER(2,2),
manager_id NUMBER(6), department_id NUMBER(4),
PERIOD FOR emp_track_time);
DESCRIBE employees_temp
Name Null? Type
------------------------------------------------------- -------- ---------------
EMPLOYEE_ID NOT NULL NUMBER(6)
FIRST_NAME VARCHAR2(20)
LAST_NAME NOT NULL VARCHAR2(25)
EMAIL NOT NULL VARCHAR2(25)
PHONE_NUMBER VARCHAR2(20)
HIRE_DATE NOT NULL DATE
JOB_ID NOT NULL VARCHAR2(10)
SALARY NUMBER(8,2)
COMMISSION_PCT NUMBER(2,2)
MANAGER_ID NUMBER(6)
DEPARTMENT_ID NUMBER(4)
SQL> SELECT SUBSTR(COLUMN_NAME,1,22) NAME, SUBSTR(DATA_TYPE,1,28) DATA_TYPE, COLUMN_ID AS COL_ID,
SEGMENT_COLUMN_ID AS SEG_COL_ID, INTERNAL_COLUMN_ID AS INT_COL_ID, HIDDEN_COLUMN
FROM USER_TAB_COLS WHERE TABLE_NAME='EMPLOYEES_TEMP';
NAME DATA_TYPE COL_ID SEG_COL_ID INT_COL_ID HID
---------------------- ---------------------------- ------ ---------- ---------- ---
EMP_TRACK_TIME_START TIMESTAMP(6) WITH TIME ZONE 1 1 YES
EMP_TRACK_TIME_END TIMESTAMP(6) WITH TIME ZONE 2 2 YES
EMP_TRACK_TIME NUMBER 3 YES
EMPLOYEE_ID NUMBER 1 3 4 NO
FIRST_NAME VARCHAR2 2 4 5 NO
LAST_NAME VARCHAR2 3 5 6 NO
EMAIL VARCHAR2 4 6 7 NO
PHONE_NUMBER VARCHAR2 5 7 8 NO
HIRE_DATE DATE 6 8 9 NO
JOB_ID VARCHAR2 7 9 10 NO
SALARY NUMBER 8 10 11 NO
COMMISSION_PCT NUMBER 9 11 12 NO
MANAGER_ID NUMBER 10 12 13 NO
DEPARTMENT_ID NUMBER 11 13 14 NO
/* Insert/update/delete with specified values for time columns */
INSERT INTO employees_temp(emp_track_time_start, emp_track_time_end, employee_id, first_name,
last_name, email, hire_date, job_id, salary, manager_id, department_id)
VALUES (TIMESTAMP '2009-06-01 12:00:01 Europe/Paris',
TIMESTAMP '2012-11-30 12:00:01 Europe/Paris', 251, 'Scott', 'Tiger',
'[email protected]', DATE '2009-05-21', 'IT_PROG', 50000, 103, 60);
INSERT INTO employees_temp(emp_track_time_start, emp_track_time_end, employee_id, first_name,
last_name, email, hire_date, job_id, salary, manager_id, department_id)
VALUES (TIMESTAMP '2009-06-01 12:00:01 Europe/Paris',
TIMESTAMP '2012-12-31 12:00:01 Europe/Paris', 252, 'Jane', 'Lion',
'[email protected]', DATE '2009-06-11', 'IT_PROG', 50000, 103, 60);
UPDATE employees_temp set salary = salary + salary * .05
WHERE emp_track_time_start <= TIMESTAMP '2009-06-01 12:00:01 Europe/Paris';
SELECT employee_id, SALARY FROM employees_temp;
EMPLOYEE_ID SALARY
----------- ----------
251 52500
252 52500
/* No rows are deleted for the following statement because no records */
/* are in the specified track time. */
DELETE employees_temp WHERE emp_track_time_end < TIMESTAMP '2001-12-31 12:00:01 Europe/Paris';
0 rows deleted.
/* Show rows that are in a specified time period */
SELECT employee_id FROM employees_temp
WHERE emp_track_time_start > TIMESTAMP '2009-05-31 12:00:01 Europe/Paris' AND
emp_track_time_end < TIMESTAMP '2012-12-01 12:00:01 Europe/Paris';
EMPLOYEE_ID
-----------
251
/* Show rows that are in a specified time period */
SELECT employee_id FROM employees_temp AS OF PERIOD FOR
emp_track_time TIMESTAMP '2012-12-01 12:00:01 Europe/Paris';
EMPLOYEE_ID
-----------
252
5.3.4 Limitations and Restrictions With In-Database Archiving and Temporal Validity
本主题列出了与数据库内存档和时间有效性相关的局限和限制。
限制和约束包括：
- ILM 不支持时间有效性的 OLTP 表压缩。如果在结束时间列上进行分区，则支持段级 ILM 和压缩。
- 用于数据库内归档的 OLTP 表压缩不支持 ILM。ORA_ARCHIVE_STATE如果在列 上分区，则支持段级 ILM 和压缩。
参考：
- https://oracle-base.com/articles/12c/temporal-validity-12cr1
- https://connor-mcdonald.com/2021/09/17/is-my-table-temporal/
- https://www.researchgate.net/publication/282835771_Checking_and_Verifying_Temporal_Data_Validity_Using_Valid_Time_Temporal_Dimension_and_Queries_in_Oracle_12C
5.4 Implementing an ILM System Manually Using Partitioning
您可以使用分区手动实施信息生命周期管理 (ILM) 系统。
示例 5-12说明了如何手动创建存储层并跨这些存储层对表进行分区，然后在该数据库上设置虚拟专用数据库 (VPD) 策略以限制对联机存档层数据的访问。
示例 5-12 手动实现 ILM 系统
REM Setup the tablespaces for the data
REM These tablespaces would be placed on a High Performance Tier
CREATE SMALLFILE TABLESPACE q1_orders DATAFILE 'q1_orders'
SIZE 2M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED LOGGING
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;
CREATE SMALLFILE TABLESPACE q2_orders DATAFILE 'q2_orders'
SIZE 2M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED LOGGING
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;
CREATE SMALLFILE TABLESPACE q3_orders DATAFILE 'q3_orders'
SIZE 2M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED LOGGING
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;
CREATE SMALLFILE TABLESPACE q4_orders DATAFILE 'q4_orders'
SIZE 2M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED LOGGING
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;
REM These tablespaces would be placed on a Low Cost Tier
CREATE SMALLFILE TABLESPACE "2006_ORDERS" DATAFILE '2006_orders'
SIZE 5M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED LOGGING
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;
CREATE SMALLFILE TABLESPACE "2005_ORDERS" DATAFILE '2005_orders'
SIZE 5M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED LOGGING
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;
REM These tablespaces would be placed on the Online Archive Tier
CREATE SMALLFILE TABLESPACE "2004_ORDERS" DATAFILE '2004_orders'
SIZE 5M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED LOGGING
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;
CREATE SMALLFILE TABLESPACE old_orders DATAFILE 'old_orders'
SIZE 15M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED LOGGING
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;
REM Now create the Partitioned Table
CREATE TABLE allorders (
prod_id NUMBER NOT NULL,
cust_id NUMBER NOT NULL,
time_id DATE NOT NULL,
channel_id NUMBER NOT NULL,
promo_id NUMBER NOT NULL,
quantity_sold NUMBER(10,2) NOT NULL,
amount_sold NUMBER(10,2) NOT NULL)
--
-- table wide physical specs
--
PCTFREE 5 NOLOGGING
--
-- partitions
--
PARTITION BY RANGE (time_id)
( partition allorders_pre_2004 VALUES LESS THAN
(TO_DATE('2004-01-01 00:00:00'
,'SYYYY-MM-DD HH24:MI:SS'
,'NLS_CALENDAR=GREGORIAN'
)) TABLESPACE old_orders,
partition allorders_2004 VALUES LESS THAN
(TO_DATE('2005-01-01 00:00:00'
,'SYYYY-MM-DD HH24:MI:SS'
,'NLS_CALENDAR=GREGORIAN'
)) TABLESPACE "2004_ORDERS",
partition allorders_2005 VALUES LESS THAN
(TO_DATE('2006-01-01 00:00:00'
,'SYYYY-MM-DD HH24:MI:SS'
,'NLS_CALENDAR=GREGORIAN'
)) TABLESPACE "2005_ORDERS",
partition allorders_2006 VALUES LESS THAN
(TO_DATE('2007-01-01 00:00:00'
,'SYYYY-MM-DD HH24:MI:SS'
,'NLS_CALENDAR=GREGORIAN'
)) TABLESPACE "2006_ORDERS",
partition allorders_q1_2007 VALUES LESS THAN
(TO_DATE('2007-04-01 00:00:00'
,'SYYYY-MM-DD HH24:MI:SS'
,'NLS_CALENDAR=GREGORIAN'
)) TABLESPACE q1_orders,
partition allorders_q2_2007 VALUES LESS THAN
(TO_DATE('2007-07-01 00:00:00'
,'SYYYY-MM-DD HH24:MI:SS'
,'NLS_CALENDAR=GREGORIAN'
)) TABLESPACE q2_orders,
partition allorders_q3_2007 VALUES LESS THAN
(TO_DATE('2007-10-01 00:00:00'
,'SYYYY-MM-DD HH24:MI:SS'
,'NLS_CALENDAR=GREGORIAN'
)) TABLESPACE q3_orders,
partition allorders_q4_2007 VALUES LESS THAN
(TO_DATE('2008-01-01 00:00:00'
,'SYYYY-MM-DD HH24:MI:SS'
,'NLS_CALENDAR=GREGORIAN'
)) TABLESPACE q4_orders);
ALTER TABLE allorders ENABLE ROW MOVEMENT;
REM Here is another example using INTERVAL partitioning
REM These tablespaces would be placed on a High Performance Tier
CREATE SMALLFILE TABLESPACE cc_this_month DATAFILE 'cc_this_month'
SIZE 2M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED LOGGING
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;
CREATE SMALLFILE TABLESPACE cc_prev_month DATAFILE 'cc_prev_month'
SIZE 2M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED LOGGING
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;
REM These tablespaces would be placed on a Low Cost Tier
CREATE SMALLFILE TABLESPACE cc_prev_12mth DATAFILE 'cc_prev_12'
SIZE 2M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED LOGGING
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;
REM These tablespaces would be placed on the Online Archive Tier
CREATE SMALLFILE TABLESPACE cc_old_tran DATAFILE 'cc_old_tran'
SIZE 2M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED LOGGING
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;
REM Credit Card Transactions where new partitions
REM are automatically placed on the high performance tier
CREATE TABLE cc_tran (
cc_no VARCHAR2(16) NOT NULL,
tran_dt DATE NOT NULL,
entry_dt DATE NOT NULL,
ref_no NUMBER NOT NULL,
description VARCHAR2(30) NOT NULL,
tran_amt NUMBER(10,2) NOT NULL)
--
-- table wide physical specs
--
PCTFREE 5 NOLOGGING
--
-- partitions
--
PARTITION BY RANGE (tran_dt)
INTERVAL (NUMTOYMINTERVAL(1,'month') ) STORE IN (cc_this_month )
( partition very_old_cc_trans VALUES LESS THAN
(TO_DATE('1999-07-01 00:00:00'
,'SYYYY-MM-DD HH24:MI:SS'
,'NLS_CALENDAR=GREGORIAN'
)) TABLESPACE cc_old_tran ,
partition old_cc_trans VALUES LESS THAN
(TO_DATE('2006-07-01 00:00:00'
,'SYYYY-MM-DD HH24:MI:SS'
,'NLS_CALENDAR=GREGORIAN'
)) TABLESPACE cc_old_tran ,
partition last_12_mths VALUES LESS THAN
(TO_DATE('2007-06-01 00:00:00'
,'SYYYY-MM-DD HH24:MI:SS'
,'NLS_CALENDAR=GREGORIAN'
)) TABLESPACE cc_prev_12mth,
partition recent_cc_trans VALUES LESS THAN
(TO_DATE('2007-07-01 00:00:00'
,'SYYYY-MM-DD HH24:MI:SS'
,'NLS_CALENDAR=GREGORIAN'
)) TABLESPACE cc_prev_month,
partition new_cc_tran VALUES LESS THAN
(TO_DATE('2007-08-01 00:00:00'
,'SYYYY-MM-DD HH24:MI:SS'
,'NLS_CALENDAR=GREGORIAN'
)) TABLESPACE cc_this_month);
REM Create a Security Policy to allow user SH to see all credit card data,
REM PM only sees this years data,
REM and all other uses cannot see the credit card data
CREATE OR REPLACE FUNCTION ilm_seehist
(oowner IN VARCHAR2, ojname IN VARCHAR2)
RETURN VARCHAR2 AS con VARCHAR2 (200);
BEGIN
IF SYS_CONTEXT('USERENV','CLIENT_INFO') = 'SH'
THEN -- sees all data
con:= '1=1';
ELSIF SYS_CONTEXT('USERENV','CLIENT_INFO') = 'PM'
THEN -- sees only data for 2007
con := 'time_id > ''31-Dec-2006''';
ELSE
-- others nothing
con:= '1=2';
END IF;
RETURN (con);
END ilm_seehist;
/
以上例子包括3部分，第一部分是Range Partition的例子，第二部分是Interval Partition的例子，第三部分是创建行级安全策略，其中con表示condition，即where条件。CLIENT_INFO是应用存放的会话信息。
5.5 Managing ILM Heat Map and ADO with Oracle Enterprise Manager
您可以使用 Oracle Enterprise Manager Cloud Control 管理热图和自动数据优化。