Oracle Database In-Memory选件于美国时间6月10日已经发布，发布会视频参看：http://www.oracle.com/us/corporate/events/dbim/index.html 什么时候Oracle Database In-Memory选件能够发布？ 该选件将包含在Oracle Database 12c的第一个Pacthset（12.1.0.2）中一起发布。 价格如何？ 价格会在发布日的时候决定。 新的Oracle Database In-Memory选件是否会替代In-Memory Database Cache（就是TimesTen技术）选件？ 当然不，完全不一样的应用场景。In-Memory Database Cache是在应用程序层通过TimesTen来管理的内存性质的数据库，这是为了让OLTP应用享受到对于存储在Oracle数据库中一部分表的超低延迟访问而设计的。 Oracle Database In-Memory选件是否会替代TimesTen？ 当然不。像上面所说，TimesTen通常是部署在应用层的，可能是作为一个独立的数据库，也可能是作为在Oracle数据库前面的In-Memory Database Cache。TimesTen提供的是超低延迟数据访问，由此提供了极速的响应时间。由此受益的OLTP系统通常不会创建用于报表应用的索引，也因此通常无法从数据库层的Oracle Database In-Memory选件中获得多少性能提升。 Oracle Database In-Memory选件是否会替代Exalytics？ 当然不。并不是所有客户都需要在他们的系统中拥有强力的分析能力，而Exalytics是Oracle的一体化策略分析平台。它提供了丰富的分析工具和可视化工具，以及大量的标准报表、预测分析、数据发现，是为了最优化地运行BI和EPM工作的平台，是对数据库层的补充而不是竞争。 Exalytics也不仅仅是针对Oracle Database 12c的，它可以处理多种数据源，包括Teradata、Oracle database 11g、SAP Netweaver等。 那么在Exalytics中使用的是什么关系型内存数据库引擎呢？ Exalytics使用的是TimesTen In-Memory Database for Exalytics。在TimesTen产品发展路线图中也包含着跟Oracle Database In-Memory选件相类似的列式存储技术，而且是使用的相同的底层列式处理架构。这项技术计划在2014年跟Oracle Database In-Memory选件一起在相同的时间窗口发布。实际上，TimesTen和Oracle Database In-Memory选件在Oracle公司内部是由同一个小组来开发的，共享相同的创新技术以及底层架构。 那么在Exalytics中使用的内存数据库引擎在未来会变成Oracle Database In-Memory选件吗？ 没有这个计划。Oracle期望TimesTen会持续研发。 Oracle Database…

本文介绍Oracle Database 12c中关于数据生命周期管理多个新特性中相对最简单的一个，数据库内归档（In-Database Archiving）。使用的测试表是上一篇介绍数据时间有效期管理中使用的TV表（包括表结构和测试数据），如果你还没有看过上一篇文章，可以先阅读【Oracle Database 12c New Feature】ILM – Temporal Validity。 相比起数据时间有效期管理而言，数据库内归档非常简单，只有一个开关，对于一条数据，要不就是活跃的允许显示，要不就是归档掉不显示，这是由数据库管理员来人工操作的。 在设置数据库内归档之前，必须要在表级别启用该特性。如上一篇文章提到的，In-Database Archiving支持多租户架构，可以在PDB中使用。 SQL> alter table TV row archival; Table altered. Oracle仍然是使用隐藏列来实现这个功能的，在启用该特性以后，会自动在表上增加ORA_ARCHIVE_STATE字段，这是一个VARCHAR2(4000)的字段。 SQL> select COLUMN_NAME,DATA_TYPE,HIDDEN_COLUMN FROM USER_TAB_COLS WHERE TABLE_NAME=’TV’; COLUMN_NAME DATA_TYPE HID ——————– ——————– — ORA_ARCHIVE_STATE VARCHAR2 YES SYS_NC00005$ RAW YES VALID_TIME_END DATE YES VALID_TIME_START DATE YES INSERT_TIME DATE NO VALID_TIME NUMBER YES 6…

ILM全称是Information Lifecycle Management，意思是信息生命周期管理，听上去很高端洋气的一个词，但是实际上几乎每个稍微大些的系统都已经在做ILM了，比如说将生产表中的数据定期插入到历史表中，并把生产表中的这些数据删除，这就是数据生命周期管理；又比如使用了分区，定期将过期的数据分区删除掉，或者置为READONLY，让RMAN不再备份，这也是数据生命周期管理。 因此ILM由来已久，只要数据存在活跃-不活跃-静止这样的周期变化，那么ILM就必不可少，Oracle Database 12c中提供了很多新功能用来方便地进行数据生命周期管理，有些功能甚至是我们期盼已久的。 本文先介绍时间有效期管理（Temporal Validity），下两篇文章会介绍数据库内归档（In-Database Archiving）以及数据热度图（Heat Map）。注意：Temporal Validity和Heat Map目前还不支持多租户架构的数据库，因此想要使用，必须是一个NON-CDB，In-Database Archiving则支持多租户架构，可以在PDB中使用。 一. 时间有效期管理（Temporal Validity） 以下简称TV，TV的功能大致上可以这样描述：在表中手动或者自动建两个时间类型的字段，一个表示有效期的开始时间，一个表示有效期的结束时间，就可以通过设置让只有在有效期内的记录才会被选择出来。 以下这个场景是我构想出来的，一张表里不断地INSERT数据，但是每条数据有效期只有1分钟，过了1分钟再查就看不见了，如果加以仔细策划，应该会是很有趣的功能。直接进入测试。 设置TV，需要使用dbms_flashback_archive包，需要该包的执行权限。 SQL> grant execute on dbms_flashback_archive to kamus; 创建测试表，period for关键字是TV新功能的关键字，valid_time是TV策略的名字，可以随便写。valid_time_start和valid_time_end字段可以不手工定义，只要指定了period for关键字，Oracle会自动创建两个不可见字段。我这里之所以手工定义开始和结束时间字段，是为了能够指定DEFAULT值。有效期开始时间valid_time_start是记录插入的当前时间，有效期结束时间valid_time_end是当前时间的后一分钟。由此定义出了一个跨度1分钟的有效期。 SQL> conn kamus/oracle SQL> create table TV (insert_time date, valid_time_start date invisible default sysdate, valid_time_end date invisible default sysdate+1/1440, period for valid_time(valid_time_start,valid_time_end) ); 可以看到明确定义的INSERT_TIME字段用于演示，VALID_TIME_START和VALID_TIME_END是明确定义的不可见字段。之外，Oracle还自动创建了VALID_TIME字段，也是隐藏字段。 SQL> select…