【Oracle Database 12c New Feature】Aggregate Data Across Many PDBs by CONTAINERS Clause

在最新版本的Oracle Database 12.1.0.2中,新特性提供了PDB Containers子句,用以从CDB$ROOT层面直接聚合查询多个PDB中同一张表的数据。在新特性文档中该段如下描述: Screen Shot 2014-10-16 at 8.54.26 AM

但是实现起来并非看上去如此简单。

现有测试环境如下: 当前CDB中有2个PDB,分别是PDB1和PDB2;每个PDB中都有一个相同名字的Local User,为KAMUS;每个KAMUS用户下都有一个TT表,表结构相同,数据不同。

  • 首先按照想象,在CDB$ROOT中直接使用SYS用户查询,会报ORA-00942错误。
SQL> show user
USER is "SYS"
SQL> show con_name

CON_NAME
------------------------------
CDB$ROOT

SQL> select count(*) FROM CONTAINERS(KAMUS.TT) WHERE CON_ID IN (3);
select count(*) FROM CONTAINERS(KAMUS.TT) WHERE CON_ID IN (3)
                                      *
ERROR at line 1:
ORA-00942: table or view does not exist
  • 这要求我们首先创建一个Common User。并赋予其足够的权限。赋予select any table权限是为了方便测试,在真实环境中你可能需要更精细地规划权限。
SQL> CREATE USER C##KAMUS IDENTIFIED BY oracle DEFAULT tablespace users;

User created.

SQL> GRANT dba TO C##KAMUS CONTAINER=ALL;

Grant succeeded.

SQL> grant select any table to C##KAMUS CONTAINER=ALL;

Grant succeeded.
  • 其次要求用Common User分别连接所有需要聚合查询的PDB,在其中创建一个与表名字相同的视图。
sqlplus "C##KAMUS/oracle@db-cluster-scan:1521/pdb1"
CREATE OR REPLACE VIEW tt AS SELECT * FROM kamus.tt;
alter session set container=pdb2;
CREATE OR REPLACE VIEW tt AS SELECT * FROM kamus.tt;
  • 然后还需要在Common User中创建一个相同名字的空表,否则查询仍然会报ORA-00942错误。
SQL> show user
USER is "C##KAMUS"
SQL> show con_name

CON_NAME
------------------------------
CDB$ROOT
SQL> create table TT (dummy char(1));

Table created.

SQL> select count(*) FROM CONTAINERS(TT);

  COUNT(*)
----------
    117362
  • 只需要创建一个名字相同的表,已经可以聚合查询count(*)了。但是如果在SQL语句中涉及到特定列仍会有问题。从报错中透露的P000进程,可知Oracle在实现此过程中使用了并行查询,不同的并行子进程在不同的PDB中查询相关表,最后在CDB级别中的汇总显示。
SQL> select OBJECT_NAME FROM CONTAINERS(TT) where rownum<11;
select OBJECT_NAME FROM CONTAINERS(TT) where rownum<11
*
ERROR at line 1:
ORA-12801: error signaled in parallel query server P000, instance dbserver1.vbox.com:cdb12c_1 (1)
ORA-00904: "OBJECT_NAME": invalid identifier


SQL> select count(*) from CONTAINERS(TT) where OBJECT_NAME='XX';
select count(*) from CONTAINERS(TT) where OBJECT_NAME='XX'
*
ERROR at line 1:
ORA-12801: error signaled in parallel query server P000, instance dbserver1.vbox.com:cdb12c_1 (1)
ORA-00904: "OBJECT_NAME": invalid identifier
  • 因此可以将所有期望聚合查询的列都加入到C##KAMUS用户的TT表中,此处增加了OBJECT_NAME字段,可以看到特意在测试中增加了number类型的OBJECT_NAME字段,而PDB中的OBJECT_NAME字段均为varchar2类型,因此可见只需列名称相同即可,无需类型相同。
SQL> alter table TT add OBJECT_NAME number(10);

Table altered.

SQL> select OBJECT_NAME from CONTAINERS(TT) where rownum<11;

OBJECT_NAME
------------------------------------
ICOL$
I_CDEF3
TS$
CDEF$
I_FILE2
I_OBJ5
I_OBJ1
I_OBJ4
I_USER2
I_COL2

10 rows selected.

SQL> select count(*) from CONTAINERS(TT) where OBJECT_NAME like 'ICOL%';

  COUNT(*)
----------
        12
  • 从以上已经看出,如果更简单,那么在C##KAMUS中创建一个与PDB中KAMUS.TT表完全相同结构的空表即可。这里用impdp来实现。
impdp C##KAMUS/oracle@db-cluster-scan:1521/cdb12c DIRECTORY=dpump DUMPFILE=expdat.dmp EXCLUDE=TABLE_DATA TABLES=KAMUS.TT REMAP_SCHEMA=KAMUS:C##KAMUS

SQL> show con_name

CON_NAME
------------------------------
CDB$ROOT
SQL> show user
USER is "C##KAMUS"
SQL> select table_name from tabs;

TABLE_NAME
------------------------------
TT

SQL> select count(*) from TT;

  COUNT(*)
----------
         0

SQL>
SQL> SELECT count(*) FROM CONTAINERS(TT);

  COUNT(*)
----------
    117386

SQL> SELECT count(*) FROM CONTAINERS(TT) WHERE CON_ID IN (3);

  COUNT(*)
----------
     58693
  • 查看执行计划,在执行计划中已经完全没有显示最终表的名称,而是出现X$CDBVW$这样的FIXED TABLE名称,在CDB中的执行计划将很难判断真实的执行路径。
SQL> set autot on
SQL> SELECT count(*) FROM CONTAINERS(TT);


  COUNT(*)
----------
    117386


Execution Plan
----------------------------------------------------------
Plan hash value: 3954817379

---------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                 | Name     | Rows  | Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |
---------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT          |          |     1 |     1 (100)| 00:00:01 |       |       |        |      |            |
|   1 |  SORT AGGREGATE           |          |     1 |            |          |       |       |        |      |            |
|   2 |   PX COORDINATOR          |          |       |            |          |       |       |        |      |            |
|   3 |    PX SEND QC (RANDOM)    | :TQ10000 |     1 |            |          |       |       |  Q1,00 | P->S | QC (RAND)  |
|   4 |     SORT AGGREGATE        |          |     1 |            |          |       |       |  Q1,00 | PCWP |            |
|   5 |      PX PARTITION LIST ALL|          | 58693 |     1 (100)| 00:00:01 |     1 |   254 |  Q1,00 | PCWC |            |
|   6 |       FIXED TABLE FULL    | X$CDBVW$ | 58693 |     1 (100)| 00:00:01 |       |       |  Q1,00 | PCWP |            |
---------------------------------------------------------------------------------------------------------------------------


Statistics
----------------------------------------------------------
     117574  recursive calls
          0  db block gets
      58796  consistent gets
          0  physical reads
        124  redo size
        544  bytes sent via SQL*Net to client
        551  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
         13  sorts (memory)
          0  sorts (disk)
          1  rows processed

结论: 操作起来稍显复杂,功能正常。

【Oracle Database 12c New Feature】In-Memory Column Store Initialization Parameters

Oracle发布的Database 12c最新版本12.1.0.2中正式引入了IMCS(列式内存)功能,正是在刚发布的时候被称为In-Memory Database Option的选件。

到底什么是IMCS?跟SAP HANA不一样吗?

IMCS是SGA中的一块新的独立区域,就跟众所周知的Buffer Cache或者Shared Pool一样,IMCS更接近于Buffer Cache,就是缓存表或者表分区或者物化视图中的数据的,但是不同的地方是在IMCS中缓存的数据格式并不是按照传统的行方式,而是按照列方式来缓存的。更简单地说,现在Oracle数据库在内存中既可以缓存行式数据也可以缓存列式数据了,但是在磁盘中存储的始终只有一份行式数据,这是Oracle IMCS与SAP HANA或者Sybase IQ等列式内存数据库截然不同的地方。 Screen Shot 2014-09-16 at 8.45.35 AM

Oracle在磁盘中始终只有一份行式数据,只是在缓存到内存中的时候,可以选择附加一份列式缓存。请注意,这里提及的“附加”一词,意味着,Oracle数据库以前的所有行为都没有发生变化,应该缓存到Buffer Cache(传统的行式缓存)中的还是会缓存到Buffer Cache中,只是如果设置了某张表也需要一份列式缓存,那么Oracle会额外维护一份该表的列式数据,这份数据就是存在SGA的新区域In-Memory Area中。这份数据只会保存在内存中,一旦数据库实例重启,这部分内存会重新加载(按照不同的设置,可以是一启动就立刻加载,也可以使用到再加载)。

Oracle需要保证效率的地方是当大量的DML产生时,额外的这部分列式缓存如何高效地保持更新和同步,特别是在RAC环境中更会是一个挑战,Oracle并没有透露更多关于这方面的信息,所有一切唯有等待真正应用的测试。

本文主要通过解释跟IMCS相关的数据库初始化参数,来介绍其中的知识。包括隐含参数,总共有115个参数跟inmemory相关(wow!)。

SQL> @p "inmemory"

NAME                                                         VALUE
------------------------------------------------------------ ----------------------------------------
_inmemory_check_prot_meta                                    FALSE
_inmemory_private_journal_quota                              100
_inmemory_private_journal_sharedpool_quota                   20
_inmemory_private_journal_numbkts                            512
_inmemory_private_journal_numgran                            128
_inmemory_jscan                                              0
_inmemory_pin_hist_mode                                      16
_inmemory_txn_checksum                                       0
_inmemory_buffer_waittime                                    100
_inmemory_cu_timeout                                         100
_inmemory_cudrop_timeout                                     1000
_inmemory_exclto_timeout                                     1000
_inmemory_num_hash_latches                                   256
_inmemory_strdlxid_timeout                                   0
_inmemory_incremental_repopulation                           FALSE
_inmemory_lock_for_smucreate                                 FALSE
_inmemory_auto_distribute                                    TRUE
_inmemory_autodist_2safe                                     FALSE
_inmemory_distribute_timeout                                 300
_inmemory_distribute_ondemand_timeout                        300
inmemory_size                                                218103808
_inmemory_64k_percent                                        30
_inmemory_min_ima_defersize                                  0
_inmemory_memprot                                            TRUE
_inmemory_analyzer_optimize_for                              0
_inmemory_default_flags                                      8459
_inmemory_default_new                                        FALSE
inmemory_clause_default
inmemory_force                                               DEFAULT
inmemory_query                                               ENABLE
_inmemory_query_scan                                         TRUE
_inmemory_scan_override                                      FALSE
_inmemory_scan_threshold_percent_noscan                      50
_inmemory_small_segment_threshold                            65536
_inmemory_query_fetch_by_rowid                               FALSE
_inmemory_pruning                                            ON
_inmemory_enable_sys                                         FALSE
_inmemory_populate_fg                                        FALSE
_inmemory_pga_per_server                                     536870912
inmemory_max_populate_servers                                1
_inmemory_servers_throttle_pgalim_percent                    55
inmemory_trickle_repopulate_servers_percent                  1
_inmemory_populate_wait                                      FALSE
_inmemory_populate_wait_max                                  600
_inmemory_imco_cycle                                         120
_inmemory_enable_population_verify                           1
_inmemory_log_level                                          1
_inmemory_fs_verify                                          FALSE
_inmemory_force_fs                                           FALSE
_inmemory_force_fs_tbs                                       SYSAUX
_inmemory_force_fs_tbs_size                                  1073741824
_inmemory_fs_raise_error                                     FALSE
_inmemory_fs_nodml                                           FALSE
_inmemory_fs_enable                                          FALSE
_inmemory_fs_enable_blk_lvl_inv                              TRUE
_inmemory_fs_blk_inv_blkcnt
_inmemory_fs_blk_inv_blk_percent                             20
_inmemory_enable_stat_alert                                  FALSE
_inmemory_imcu_align                                         TRUE
_inmemory_max_populate_retry                                 3
_inmemory_imcu_target_rows                                   1048576
_inmemory_imcu_target_bytes                                  0
_inmemory_imcu_source_extents                                0
_inmemory_imcu_source_blocks                                 0
_inmemory_imcu_source_minbytes                               1048576
_inmemory_imcu_populate_minbytes                             5242880
_inmemory_imcu_source_analyze_bytes                          134217728
_inmemory_imcu_target_maxrows                                8388608
_inmemory_imcu_source_maxbytes                               536870912
_inmemory_max_queued_tasks                                   208
_inmemory_repopulate_threshold_rows
_inmemory_repopulate_threshold_blocks
_inmemory_pct_inv_rows_invalidate_imcu                       50
_inmemory_pct_inv_blocks_invalidate_imcu                     100
_inmemory_repopulate_threshold_mintime_factor                5
_inmemory_repopulate_threshold_mintime                       0
_inmemory_repopulate_threshold_scans                         0
_inmemory_repopulate_priority_scale_factor                   100
_inmemory_repopulate_invalidate_rate_percent                 100
_inmemory_repopulate_priority_threshold_row                  20
_inmemory_repopulate_priority_threshold_block                40
_inmemory_repopulate_threshold_rows_percent                  5
_inmemory_repopulate_threshold_blocks_percent                10
_inmemory_repopulate_disable                                 FALSE
_inmemory_check_protect                                      FALSE
_inmemory_checksum                                           FALSE
_inmemory_validate_fetch                                     FALSE
_inmemory_journal_row_logging                                FALSE
_inmemory_journal_check                                      0
_inmemory_rows_check_interrupt                               1000
_inmemory_dbg_scan                                           0
_inmemory_segment_populate_verify                            0
_inmemory_query_check                                        0
_inmemory_test_verification                                  0
_inmemory_invalidate_cursors                                 TRUE
_inmemory_prepopulate_fg                                     0
_inmemory_prepopulate                                        TRUE
_inmemory_trickle_repopulate                                 TRUE
_inmemory_trickle_repopulate_threshold_dirty_ratio           0
_inmemory_trickle_repopulate_min_interval                    300
_inmemory_trickle_repopulate_fg                              0
_inmemory_force_non_engineered                               FALSE
_inmemory_suppress_vsga_ima                                  FALSE
optimizer_inmemory_aware                                     TRUE
_optimizer_inmemory_table_expansion                          TRUE
_optimizer_inmemory_gen_pushable_preds                       TRUE
_optimizer_inmemory_autodop                                  TRUE
_optimizer_inmemory_access_path                              TRUE
_optimizer_inmemory_quotient                                 0
_optimizer_inmemory_pruning_ratio_rows                       100
_parallel_inmemory_min_time_threshold                        AUTO
_parallel_inmemory_time_unit                                 1
_optimizer_inmemory_bloom_filter                             TRUE
_optimizer_inmemory_cluster_aware_dop                        TRUE
_optimizer_inmemory_minmax_pruning                           TRUE

115 rows selected.

先将注意力放在非隐含参数上,总共是7个参数(Phew!)。

SQL> show parameter inmemory

NAME                                               TYPE        VALUE
-------------------------------------------------- ----------- --------------------------------------------------
inmemory_clause_default                            string
inmemory_force                                     string      DEFAULT
inmemory_max_populate_servers                      integer     1
inmemory_query                                     string      ENABLE
inmemory_size                                      big integer 208M
inmemory_trickle_repopulate_servers_percent        integer     1
optimizer_inmemory_aware                           boolean     TRUE

inmemory_clause_default

该参数主要设置IMCS的一些默认参数值,这些默认值在今后为新的表或者分区设置IMCS时会自动参考。该参数默认值为空,表示除非在建表时明确指定要使用IMCS,否则不会将表缓存到列式内存中。该参数的设置可选项包括:

NO INMEMORY:与默认值效果一样,除非在建表时明确指定要使用IMCS,否则不会将表缓存到列式内存中。

INMEMORY:表示默认建表时就会使用IMCS,除非建表时明确指定“NO INMEMORY”。如果设置为该值,就可以继续设置如下这些其它的IMCS参数值。

NO MEMCOMPRESS | MEMCOMPRESS FOR { DML | QUERY [ LOW | HIGH ] | CAPACITY [LOW | HIGH] }: 表示在IMCS中缓存的列式数据是否需要压缩,如果压缩,采取何种压缩模式。

PRIORITY { NONE | LOW | MEDIUM | HIGH | CRITICAL }:优先级表示Oracle将表数据加载到列存中的积极性,Oracle会最优先考虑CRITICAL级别的加载,最后才进行NONE级别的加载。要知道内存毕竟是有限的,因此将那些必须要缓存到列存中的表设置为CRITICAL是更好的选择。

DISTRIBUTE [ AUTO | BY ROWID RANGE | BY PARTITION | BY SUBPARTITION ]:该参数只对RAC环境有效,指定IMCS中的数据在RAC环境多个节点的内存中如何分布。分别表示自动|按照ROWID范围|按照分区|按照子分区等方式在多个节点内存中缓存数据。

NO DUPLICATE | DUPLICATE [ ALL ]:该参数只对RAC环境有效,指定IMCS中的数据在RAC环境多个节点中是否要镜像。默认为NO DUPLICATE,也就是一份数据只会在多个节点中维护一份缓存,DUPLICATE表示维护两份相同的缓存,而DUPLICATE ALL则表示在所有节点内存中都维护一份相同的缓存。注意:在非Oracle工程系统(比如Exadata)中,只能是NO DUPLICATE效果,即使设置了DUPLICATE也不生效。

示例命令:

alter system set
INMEMORY_CLAUSE_DEFAULT='INMEMORY MEMCOMPRESS FOR CAPACITY HIGH'
scope=both;

inmemory_force

INMEMORY_FORCE = { DEFAULT | OFF } 当设置为默认值DEFAULT时,明确指定了INMEMORY的表和物化视图会缓存到IMCS中;如果设置为OFF,则表示全局禁用IMCS,意味着即使在表和物化视图上指定了INMEMORY,也不会缓存到In-Memory Area中。可以看到,这个参数没有提供全局打开IMCS的选项。

inmemory_max_populate_servers

该参数定义后台启动的用于将表数据加载至In-Memory Area区域中的进程个数,根据文档描述,该参数默认值是min(一般的CPU核数,PGA_AGGREGATE_TARGET/512),当inmemory_size=0的时候(也就是没有设置In-Memory Area大小的时候),该参数值为0,一旦设置了inmemory_size,该参数会根据上述算法自动设置。 如果该参数为0,则没有后台进程加载数据,表现为V$INMEMORY_AREA视图中的POPULATE_STATUS列始终为POPULATING。 Oracle建议该参数值不能设置过高,否则将导致CPU资源消耗严重。

inmemory_query

该参数用于在SYSTEM级别或者SESSIOn级别指定是否要启动inmemory查询,当设置了inmemory_size之后,该值默认会设置未ENABLE。 该参数可以在会话级别设置,临时启用或者禁用inmemory查询,用以比较两者之间的性能差距。一旦禁用,则即使相应表已经被缓存到In-Memory Area中,Oracle也不会选择扫描该区域。

inmemory_size

该参数用于指定In-Memory Area的大小,默认值为0,意味着默认没有启用IMCS。如同其他的内存相关参数,修改了此参数以后需要重新启动数据库实例才可以生效。该参数最小需要设置为100MB。在多租户环境中,如果是在PDB级别设置了该参数,则表明该PDB可以使用到的最大IMCS,但是注意的是多个PDB的该参数值的总和未必一定要等于在CDB级别的设置,甚至可以超越CDB级别的值。如果没有在PDB级别设置,那么所有PDB都会继承CDB上的该参数值,意味着所有PDB都可以用到所有可用的IMCS。 由于IMCS是列式存储,并且具有强大的压缩功能,因此即使准备将整个数据库的表都缓存到IMCS中,也无需特别大的内存空间。万一内存空间不够,表数据无法缓存到IMCS中,在V$INMEMORY_AREA.POPULATE_STATUS字段中可以发现“OUT OF MEMORY”字样。 实际上在绝大多数情况下,启用IMCS只需要设置这一个初始化参数即可,设置足够大的内存空间,然后尽情地Cache那些想缓存的表吧。

inmemory_trickle_repopulate_servers_percent

该参数定义后台用于重新加载IMCS中数据的进程负载,该参数值是一个相对于inmemory_max_populate_servers参数值的百分比。举例说,如果inmemory_max_populate_servers=10,而inmemory_trickle_repopulate_servers_percent=5,则意味着有10*0.05=0.5个进程会负责重新加载。什么是0.5个进程,实际上就是重新加载数据的进程负载最多占据一颗CPU的50%。 该参数默认值为1,在大多数场合都是适用的。

optimizer_inmemory_aware

该参数用于限制Oracle优化器对于inmemory功能的感知,默认值为TRUE,如果将该参数修改为FALSE,则Oracle优化器不会考虑使用IMCS,等同于设置OPTIMIZER_FEATURES_ENABLE小于12.1.0.2。

US Travel Tips (OOW, ACE Directors) – Cont. II

第一篇任意门:OOW US Travel Tips for ACE Director – Visa, Hotel, Car Rental, etc.

第二篇任意门:US Travel Tips (OOW, ACE Directors) – Cont.

为什么还会有第三篇呢,因为有人说,你这太不务正业了,介绍完签证,就是租车购物是吧。我深感惭愧,知错就改,最重要的要放在最后,所以就有第三篇。

在OOW前几天专门为ACE Directors举办的Product Briefing是干嘛的?

其实最开始的那篇文章提过了,在这个会议上会有Oracle各个产品线的总监级人物,预先透露一些会在OOW中宣布的产品新特性,回答作为听众的大家的一些问题,这实际上是给ACED与Oracle官方和研发Team更近距离的交流机会。小会议的现场,果粉免费宣传单元。 IMG_3361

参加Product Briefing的话住在哪里?

不出意外的话,所有人都会住在从SFO机场下高速很近的Sofitel,这个酒店不用像Hilton那样在网上预定,Oracle会直接处理好,只要拎包到酒店前台报名字就可以入住了。从Sofitel走到Oracle总部大约需要15分钟时间,在秋意爽朗的加州清晨走走路是很好的享受。 这就是酒店。 IMG_3379

从SFO机场怎么到酒店?

每个酒店都会有从机场接客人到酒店的班车,不过Sofitel比较挫,貌似客流量不大,所以必须要到了机场以后给他们前台打电话要车,再等大概二十分钟才会有车过来。本来想找到打电话的那个候车厅(在机场到达出口外面)照片,未果。打车也可以,到酒店大约是40美金,只能自己掏。

参加OOW住在哪里?

每年都是Hilton Union Square,就是联合广场旁边的希尔顿,楼下马路对面就是一堆租车公司,所以如果选择OOW结束以后租车,那么Pickup的地点选择Union Square就没错。

从Hilton怎么去OOW的Moscone Center?

Google Maps实在刷不出来,只好将就用Yahoo,每天是有很多趟Shuttle Bus往返酒店和会场,但是最方便的方法还是沿着路线走路过去,A是希尔顿,B是Moscone Center,大约10-15分钟的路程。中间标出来的是Apple Store,每年OOW的前后都是iPhone发布新品的时候,想买新品要一大早去排队,去年抢购土豪金的火爆场景还记忆犹新,今年可能可以直接带个iPhone 6回来。 Screen_Shot_2014-08-25_at_5_51_23_PM

听Larry演讲的Keynote有什么值得说的?

包含Larry演讲的Keynote一般都是在OOW第二天的下午3点开始,一开始通常是最大的钻石赞助商上台,大约半个小时后,三点半左右,Larry会上台,第一次参加的兄弟们会觉得很激动,因为Oracle选用的出场音乐通常都很震撼,如果又有大型新品发布(比如2008年Exadata的发布),各种长枪短炮,场面极其火爆。 IMG_0161

在Keynote快结束的前3分钟就要赶紧出场,否则你就会面临最终退场时候人山人海的挪动,特别如果你又很靠前,没有十几分钟出不来。所以,你是愿意在楼梯上做个照相的人,还是愿意在下面的人海中做个被照的人呢? IMG_0192

该如何选择感兴趣的Session?

每年的OOW有数千session,勤劳如老杨这样的也不过每天能够听4-5场,4天的话也就最多20场,所以从浩如烟海的讲座中预先筛选出感兴趣的话题,并提前做好计划是很重要的。Moscone Center并不是只有一个地方,有West,South和North三栋楼,大部分跟Oracle Database相关的话题都是South,还有一部分在West。OOW有专门的网页可以用于规划Session,并添加到自己的日程表中。

Oracle Policy-Managed Cluster – Growing for DBaaS

Policy-Managed Cluster在Oracle 11gR2中被引进,在Oracle 12c中使用dbca创建RAC数据库的时候,Policy-Managed选项已然成为默认值。 Policy-Managed RAC

那么到底什么是Policy-Managed方式的集群和数据库呢?与以前的Admin-Managed方式有何区别?何种环境适合使用这种新的方式进行管理?本文尝试回答这些问题,并且做出简单的测试。

什么是Policy-Managed方式?

基于策略的管理方式,是以服务器池(Server Pools)为基础的,简单地说,就是先定义一些服务器池,池中包含一定量的服务器,然后再定义一些策略,根据这些策略Oracle会自动决定让多少数据库实例运行在池中的几台机器上。数据库实例名后缀、数据库实例个数、所运行的主机,这些都是通过策略决定的,而不是数据库管理员事先定好的。

与Admin-Managed方式有何区别?

实际上上面的表述已经明确说明了,Policy-Managed和Admin-Managed方式的差别。让我们再回顾一下,在以往我们创建一个RAC数据库大概是怎样的方法,我们在dbca的界面中会选择要将数据库实例运行在整个集群中的几台机器上,或者是2台或者是3台,甚或是更多,但是只要在安装的时候选定几台机器,那么以后如果不做增减节点的操作,就始终会在这几台机器上运行。而且,通常会根据主机名称的排序自动将每台主机上的数据库实例依次命名为dbname1到dbnameN。这些在管理员安装完毕以后,都不会再自动变化,这就是Admin-Managed方式。

何种环境适合使用这种新的方式进行管理?

当管理大量的服务器集群,并且在这些集群中运行着多种不同重要程度,不同策略的RAC数据库时,为了简化管理,建议使用Policy-Managed方式,实际上Oracle也建议只有在超过3台的服务器的时候才使用Policy-Managed来管理整个数据库集群。想象一下使用Policy-Managed方式可以达到的效果:如果我们有10台服务器组成,根据不同的应用的重要性定义服务器池的关键程度,然后在其中某些机器意外停机的情况下,仍然可以自动地保持足够多的机器给重要的系统提供数据库服务,而将不关键的系统数据库服务器个数降低到最低限度。

那么Policy-Managed方式到底长什么样?

在默认安装完Oracle 12c的RAC数据库之后,发现数据库实例始终只会启动在一个节点中。检查服务器池配置。

[oracle@dbserver2 ~]$ srvctl config srvpool
Server pool name: Free
Importance: 0, Min: 0, Max: -1
Category:
Candidate server names:
Server pool name: Generic
Importance: 0, Min: 0, Max: -1
Category:
Candidate server names:
Server pool name: orcl_pool
Importance: 0, Min: 0, Max: 1
Category: hub
Candidate server names:

Free池和Generic池是默认存在的,orcl_pool池则是在dbca创建数据库的时候由我们自己定义的。其中Min: 0, Max: 1表示在这个池中最少允许有0台机器,最多允许有1台机器被使用。所以这也造成了使用这个服务器池的数据库实例始终只会启动在一个节点中,即使这在我们最初的定义中是一个RAC数据库。

当前的数据库实例启动在节点2中,比较一下节点1和节点2服务器使用情况的输出。

[grid@dbserver2 ~]$ crsctl status server dbserver1 -f
NAME=dbserver1
MEMORY_SIZE=3954
CPU_COUNT=1
CPU_CLOCK_RATE=2
CPU_HYPERTHREADING=0
CPU_EQUIVALENCY=1000
DEPLOYMENT=other
CONFIGURED_CSS_ROLE=hub
RESOURCE_USE_ENABLED=1
SERVER_LABEL=
PHYSICAL_HOSTNAME=
STATE=ONLINE
ACTIVE_POOLS=Free --此处显示未Free,表示节点1中不属于任何正在运行的服务器池资源。
STATE_DETAILS=
ACTIVE_CSS_ROLE=hub

[grid@dbserver2 ~]$ crsctl status server dbserver2 -f
NAME=dbserver2
MEMORY_SIZE=3954
CPU_COUNT=1
CPU_CLOCK_RATE=2
CPU_HYPERTHREADING=0
CPU_EQUIVALENCY=1000
DEPLOYMENT=other
CONFIGURED_CSS_ROLE=hub
RESOURCE_USE_ENABLED=1
SERVER_LABEL=
PHYSICAL_HOSTNAME=
STATE=ONLINE
ACTIVE_POOLS=ora.orcl_pool --此处显示节点2正运行在orcl_pool服务器池资源中。
STATE_DETAILS=
ACTIVE_CSS_ROLE=hub

接下来需要修改一下配置,让RAC数据库以我们熟知的方式启动在多个节点上。 –修改orcl_pool池中最少运行一台机器,最多运行2台机器,还记得我们前面说的关键程度吗?importance表示该池的关键程度,数字越大表示关键程度越高,越优先被考虑满足Min条件。

[oracle@dbserver2 ~]$ srvctl modify srvpool -serverpool orcl_pool -importance 5 -min 1 -max 2

–重新检查服务器池信息,可以看到已经修改成功,Min: 1, Max: 2

[oracle@dbserver2 ~]$ srvctl config srvpool
Server pool name: Free
Importance: 0, Min: 0, Max: -1
Category:
Candidate server names:
Server pool name: Generic
Importance: 0, Min: 0, Max: -1
Category:
Candidate server names:
Server pool name: orcl_pool
Importance: 5, Min: 1, Max: 2
Category: hub
Candidate server names:

–查看当前服务器池的状态,可以看到orcl_pool池中激活的服务器包括了节点1和节点2两台机器。

[grid@dbserver1 ~]$ crsctl status serverpool
NAME=Free
ACTIVE_SERVERS=

NAME=Generic
ACTIVE_SERVERS=

NAME=ora.orcl_pool
ACTIVE_SERVERS=dbserver1 dbserver2

在修改完毕以后,节点1中的数据库实例就会自动启动,我们可以通过crsctl命令查看服务器的状态,其中STATE_DETAILS字段显示了正在启动资源,在正常启动完毕以后该字段会显示为空。

[grid@dbserver2 ~]$ crsctl status server dbserver1 -f
NAME=dbserver1
MEMORY_SIZE=3954
CPU_COUNT=1
CPU_CLOCK_RATE=2
CPU_HYPERTHREADING=0
CPU_EQUIVALENCY=1000
DEPLOYMENT=other
CONFIGURED_CSS_ROLE=hub
RESOURCE_USE_ENABLED=1
SERVER_LABEL=
PHYSICAL_HOSTNAME=
STATE=ONLINE
ACTIVE_POOLS=ora.orcl_pool
STATE_DETAILS=STARTING RESOURCES
ACTIVE_CSS_ROLE=hub

现在就出现了一个比较尴尬的情况(对于我们以前管理RAC的常识来说),由于dbserver1中的实例是后启动的,因此实例名后缀为2,而dbserver2中的实例名后缀是1,实际上,在Policy-Managed管理的RAC环境中,无需关注到底哪个实例启动在哪台机器上,我们需要的就是通过SCAN IP,通过Service名去访问数据库就好,而不需要通过实例名访问数据库。但是这里为了测试一下功能,还是决定1归1,2归2,我有说过我是完美主义者吗?

--先将dbserver1上的数据库服务资源reolocate到dbserver2中,这样实例2就运行回到了dbserver2中。
[grid@dbserver1 ~]$ crsctl relocate resource ora.orcl12c.db -s dbserver1 -n dbserver2
--再将dbserver1中的实例启动,因为实例2已经启动在dbserver2中,因此即使此时该实例是后启动的,但是仍然还是会命名为实例1。
[oracle@dbserver1 ~]$ srvctl start instance -db orcl12c -node dbserver1

最后将这个RAC数据库再改回到只会启动一个实例的默认状态。

[oracle@dbserver2 ~] srvctl modify srvpool -serverpool orcl_pool -min 0 -max 1

以后,无论是启动在哪台机器上,数据库的实例名永远会是dbname_1(注意,这里有一个下划线,这是Policy-Managed数据库实例的命名规则)。而我们访问数据库,则不应该指定实例名。比如:

sqlplus sys/passwd@db-cluster-scan:1521/orcl12c as sysdba

因为现在你已经无需关心到底实例是启动在哪台机器上了,后面是一个资源池,是不是有些熟悉这样的表述,是的,没错,Cloud! 我们也贴上了Cloud这个红到发紫的词,这就是Oracle私有云解决方案的构成组件之一。

How to cleanup ADRCI Homes

ADRCI (ADR Command Interpreter) 是伴随Oracle 11g推出的新工具,由于各种log的位置纷繁复杂,因此在Oracle 11g中,Oracle将数据库、监听、客户端等的Log统一转到了diagnostic_dest初始化参数所指向的目录下的diag目录中,并且提供了ADRCI实用程序来进行高效查询及管理。在这之前我曾经写过两篇跟ADRCI相关的文章。
ADRCI Purge is NOT What You Think It Should Be:ADRCI的Purge命令用于清除日志文件中的内容,但是使用起来并非尽如人意。
Oracle11g for Windows ADRCI Issue:在Windows中使用ADRCI会产生的小问题,当然很久没有用过Windows,不知道这个问题是不是还依然存在。

ADRCI看上去是个很好的东西,但是除了show alert相对简单之外,其它的各种命令和查询条件的指定实际上比较繁琐,因此ADRCI在我周边的使用者寥寥可数,我算是坚持使用的为数不多者。因为使用者不多,所以对于ADRCI中一些极为简单的操作,了解者也比较少。

本文也是如此,如何删除在ADRCI中显示出来的多余的Homes?解决方法简单到令人发指。

问题重现,在命令中show homes显示出6个Home,这通常是由于安装过其它的数据库实例,然后删除的时候遗留下来的Log目录仍然存在。对于完美主义者来说这难以容忍。

[oracle@emnotech rdbms]$ adrci

ADRCI: Release 12.1.0.1.0 - Production on Mon Aug 18 01:34:31 2014

Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.

ADR base = "/u01/app/oracle"
adrci> show home
ADR Homes:
diag/clients/user_oracle/host_266584670_80
diag/tnslsnr/emnotech/listener
diag/rdbms/orcl/orcl
diag/rdbms/slob/SLOB
diag/rdbms/slob/orcl
diag/rdbms/slob/slob

如上所示,ADR的基础目录在/u01/app/oracle,而各个Home都在其下的diag目录中,因此我们直接ls看一下目录结构。

[oracle@emnotech rdbms]$ pwd
/u01/app/oracle/diag/rdbms
[oracle@emnotech rdbms]$ ls -l
total 8
drwxr-x---. 3 oracle oinstall 4096 Jun  3 14:20 orcl
drwxr-xr-x. 5 oracle oinstall 4096 Aug  1 00:36 slob
[oracle@emnotech rdbms]$ ls -l slob
total 12
-rw-r-----.  1 oracle oinstall    0 Jun  5 03:16 i_1.mif
drwxr-xr-x. 16 oracle oinstall 4096 Jun  5 03:16 orcl
drwxr-xr-x. 16 oracle oinstall 4096 Jun  5 03:35 slob
drwxr-xr-x. 16 oracle oinstall 4096 Aug  1 00:36 SLOB

可以看到目录结构与ADRCI命令行中显示的完全一样,所以,解决方法就是直接rm掉不需要的目录。

[oracle@emnotech rdbms]$ rm -rf slob
[oracle@emnotech rdbms]$ ls -l
total 4
drwxr-x---. 3 oracle oinstall 4096 Jun  3 14:20 orcl

友情提示:一定要屡次确认才可以执行rm -rf这样危险的命令,每次对这个命令敲回车我都心惊胆战、心存敬畏。

[oracle@emnotech rdbms]$ adrci

ADRCI: Release 12.1.0.1.0 - Production on Mon Aug 18 01:35:23 2014

Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.

ADR base = "/u01/app/oracle"
adrci> show home
ADR Homes:
diag/clients/user_oracle/host_266584670_80
diag/tnslsnr/emnotech/listener
diag/rdbms/orcl/orcl
adrci>

再次进入ADRCI中查看Homes,世界清静了。

Oracle Database In-Memory (12.1.0.2) Frequently Asked Question

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 In-Memory选件是否会替代Exadata?

当然不。这个问题太幼稚,就不做解释了。

好吧,那到底什么是Oracle Database In-Memory选件呢?

这是一项新的技术,内置在Oracle数据库中,通过内存中的列式存储数据来获得超快的数据处理能力。

当使用Oracle Database In-Memory时,数据库的大小受限于服务器中的可用内存容量吗?

不。由用户来决定哪些对象会存在In-Memory列式缓存中。如果一张表太大了,无法完全缓存在In-Memory列存中,Oracle会尝试将尽可能多的数据保持在内存中(以列的形式),剩下的仍然存储在闪存或者磁盘中(以原来行的形式),这样的操作非常高效并且是完全透明的。 你可以有选择性的定义一部分数据库,比如将热表、热分区、经常访问的列放入内存中。这就让除了Oracle原有的那些跨越内存、闪存、磁盘的各种优化方式之外,Oracle Database In-Memory选件还能够专门为频繁访问的业务关键数据提供帮助。当然,如果数据库足够小,全部表都能使用Oracle Database In-Memory选件。

Oracle Database In-Memory选件只会对分析/报表类业务有帮助吗?

虽然确实分析/报表类业务能够从列式存储中获得最多的收益,但是其他类型业务也同样能够受益。比如通过减少需要的索引,就能够加速OLTP业务。通常在以前的混合负载业务中需要在表上创建很多的多字段索引来支撑报表类型的查询,如今In-Memory列存则对DML操作造成更少的影响,而又可以提供相同的查询性能。 减少索引还能够带来优化和管理的简便,DBA不再需要去rebuild那些碎片化的索引,也不再需要去研究为什么优化器选择了错误的索引。

从Oracle Database In-Memory功能中能够期望获得多少性能提升?

使用该选项能够为多种查询负载提供显著的性能提升。从一个非常简单的星型查询到一个非常复杂的具有多个子查询的SQL,就算所有的的表都在内存中,In-Memory列式缓存仍然会胜过普通的Buffer Cache。 比如说,In-Memory列存在查询很少列上的很多行时,会提供极高的性能,通常这类查询都是分析类的查询,在这类查询上使用In-Memory列存和使用普通缓存(Buffer Cache)相比,有超过100倍的性能提升。

当使用Oracle Database In-Memory选件的时候,我该对索引做些什么吗?

你可以保留以前的所有索引,就像以前那样运行你的应用。Oracle优化器完全能够感知到内存中的列式数据,只有当确认使用这些列式数据会有性能提升的时候才会使用到,如果优化器认为从索引访问中能够获得更好的性能,那么就会自动去读取普通缓存(Buffer Cache)中的数据,就跟以前一样。 不过,如果将一些多列索引设置为invisible,引导Oracle优化器更多地去选择列式缓存,可能会带来额外的速度提升。然后,你可以删除掉这些无用的索引,这样又能带来进一步的性能提升,因为Oracle数据库需要维护的索引更少了。

如果使用Oracle Database In-Memory选项,数据库现在的功能会受影响吗?

没有任何一项现有的Oracle数据库功能会受到Oracle Database In-Memory选项的限制;很多操作还能在性能上获得显著提升;一些原本为了提高性能所做的操作(比如创建索引)会变得不再重要;安全性、高可用性以及其它的所有功能都跟以前一模一样,完全不受影响。 当然在DML操作上会有一些额外消耗,因为In-Memory列存要时刻跟表数据保持同步,但是这部分列存是完全在内存中的,所以不需要额外的Logging操作。

Oracle Database In-Memory选项在高可用性上跟其它厂商的内存数据库相比如何?

因为In-Memory列存并没有给Oracle数据库施加任何限制,因此在高可用性上可以享受Oracle数据库完整的丰富的高可用解决方案,而其它厂商的高可用性均不太完备。

如何规划In-Memory列存所需要的内存大小?

In-Memory Area(用于保存In-Memory列存的内存区域)是SGA中的一块新的缓存池,该缓存大小由初始化参数INMEMORY_SIZE指定,如果一旦设定,最小是100MB。因为In-Memory Area是SGA的一部分,因此其最大大小受制于分配了其它所有内存池之后的SGA中的剩余空间。INMEMORY_SIZE默认是0,也就是不启用Oracle Database In-Memory选项。 由于In-Memory Area是一块静态区域,所以不会被自动内存管理算法所影响。 如果想要修改In-Memory Area的大小,需要重启数据库实例,在RAC数据库中,可以在各实例的内存中复制In-Memory列存,因此可以通过重启节点的方式来最小化对应用的影响。

在RAC环境中,是否In-Memory列存是在集群的所有节点中完全镜像的?

在RAC环境中,用户可以自行设定使用以下三种选项中的任何一种: 1. 在所有实例的内存中镜像相同的表数据。这样每个实例都会读取自己的本地内存,通常这用于较小的表。 2. 表数据分布在所有实例的内存中。这样每个实例内存中只会保存表中的一部分数据,没有冗余复制。 3. 表数据分布在所有实例的内存中,并且为高可用性保留2份镜像。这种工作机制很像ASM的条带化和冗余性。

【Oracle Database 12c New Feature】ILM – In-Database Archiving

本文介绍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 rows selected.

先检查一下TV表中的数据分布,一共有9个不同的时间段,前面5个都只有1条记录,后面4个则有大量测试记录。

SQL> select INSERT_TIME,count(*) from TV group by INSERT_TIME order by 1;

INSERT_TIME         COUNT(*)
----------------- ----------
20130811 09:04:30          1
20130811 09:08:27          1
20130811 09:22:30          1
20130811 09:39:40          1
20130811 09:45:22          1
20130811 09:50:44      19368
20130811 09:50:46      19368
20130811 09:50:47      19368
20130811 09:50:48      19368

9 rows selected.

尝试将所有20130811 09:50之后的记录全部设置为归档模式。直接使用UPDATE语句将ORA_ARCHIVE_STATE字段更新为任意非0的字符,0表示该记录是活跃的,任何非0字符都表示该记录被归档。

SQL> UPDATE TV SET ORA_ARCHIVE_STATE = '20' WHERE INSERT_TIME>to_date('20130811 09:50','YYYYMMDD HH24:MI');

77472 rows updated.

再次执行相同的查询语句,可以看到只存在活跃的5条记录了。

SQL> select INSERT_TIME,count(*) from TV group by INSERT_TIME order by 1;

INSERT_TIME         COUNT(*)
----------------- ----------
20130811 09:04:30          1
20130811 09:08:27          1
20130811 09:22:30          1
20130811 09:39:40          1
20130811 09:45:22          1

5 rows selected.

可以在会话级别设置即使是记录被归档,也仍然显示出来。

SQL> ALTER SESSION SET ROW ARCHIVAL VISIBILITY = ALL;

Session altered.

SQL> select INSERT_TIME,count(*) from TV group by INSERT_TIME order by 1;

INSERT_TIME         COUNT(*)
----------------- ----------
20130811 09:04:30          1
20130811 09:08:27          1
20130811 09:22:30          1
20130811 09:39:40          1
20130811 09:45:22          1
20130811 09:50:44      19368
20130811 09:50:46      19368
20130811 09:50:47      19368
20130811 09:50:48      19368

9 rows selected.

检查ORA_ARCHIVE_STATE值,可以看到所有活跃数据的ORA_ARCHIVE_STATE字段值均为0,这也是在表级别启用数据库内归档以后的默认值。

SQL> select ORA_ARCHIVE_STATE,INSERT_TIME,count(*) from TV group by ORA_ARCHIVE_STATE,INSERT_TIME order by 2;

ORA_ARCHIVE_STATE    INSERT_TIME         COUNT(*)
-------------------- ----------------- ----------
0                    20130811 09:04:30          1
0                    20130811 09:08:27          1
0                    20130811 09:22:30          1
0                    20130811 09:39:40          1
0                    20130811 09:45:22          1
20                   20130811 09:50:44      19368
20                   20130811 09:50:46      19368
20                   20130811 09:50:47      19368
20                   20130811 09:50:48      19368

9 rows selected.

将其中的一些记录的ORA_ARCHIVE_STATE字段更新为另外的非0字符。

SQL> update TV set ORA_ARCHIVE_STATE='ARCHIVING' where INSERT_TIME='20130811 09:50:48';

19368 rows updated.

SQL> select ORA_ARCHIVE_STATE,INSERT_TIME,count(*) from TV group by ORA_ARCHIVE_STATE,INSERT_TIME order by 2;

ORA_ARCHIVE_STATE    INSERT_TIME         COUNT(*)
-------------------- ----------------- ----------
0                    20130811 09:04:30          1
0                    20130811 09:08:27          1
0                    20130811 09:22:30          1
0                    20130811 09:39:40          1
0                    20130811 09:45:22          1
20                   20130811 09:50:44      19368
20                   20130811 09:50:46      19368
20                   20130811 09:50:47      19368
ARCHIVING            20130811 09:50:48      19368

在会话级别重新设置不显示归档数据,可以看到只要是ORA_ARCHIVE_STATE字段不为0的记录都不会显示。

SQL> ALTER SESSION SET ROW ARCHIVAL VISIBILITY = ACTIVE;

Session altered.

SQL> select INSERT_TIME,count(*) from TV group by INSERT_TIME order by 1;

INSERT_TIME         COUNT(*)
----------------- ----------
20130811 09:04:30          1
20130811 09:08:27          1
20130811 09:22:30          1
20130811 09:39:40          1
20130811 09:45:22          1

性能考虑,这一点数据库内归档与时间有效性是相同的,都只是对隐藏字段进行了filter操作。即使是只显示活跃数据,也仍然需要扫描全表。这一点在真实应用中可以通过创建索引来避免全表扫描,可以参看MOS Note: Potential SQL Performance Degradation When In Database Row Archiving (Doc ID 1579790.1),也就是数据库内归档只应该在一个具备良好性能的SQL基础上对返回结果进行过滤,而不要期望归档的记录不参与扫描

SQL> select * from TV;

INSERT_TIME
-----------------
20130811 09:04:30
20130811 09:08:27
20130811 09:22:30
20130811 09:39:40
20130811 09:45:22


Execution Plan
----------------------------------------------------------
Plan hash value: 1723968289

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     4 |  8044 |   102   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| TV   |     4 |  8044 |   102   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("TV"."ORA_ARCHIVE_STATE"='0')

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
        375  consistent gets
          0  physical reads
          0  redo size
        648  bytes sent via SQL*Net to client
        543  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          5  rows processed

数据库内归档可以跟时间有效性管理一起配合使用。在会话级别激活时间有效性,可以看到检索不再返回任何数据。执行计划中显示filter条件融合了数据库内归档跟时间有效性两层过滤。

SQL> exec dbms_flashback_archive.enable_at_valid_time('CURRENT');

PL/SQL procedure successfully completed.

SQL> select * from tv;

no rows selected


Execution Plan
----------------------------------------------------------
Plan hash value: 1723968289

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     3 |  6087 |   102   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| TV   |     3 |  6087 |   102   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("T"."ORA_ARCHIVE_STATE"='0' AND ("T"."VALID_TIME_START"
              IS NULL OR SYS_EXTRACT_UTC(INTERNAL_FUNCTION("T"."VALID_TIME_START"))<=S
              YS_EXTRACT_UTC(SYSTIMESTAMP(6))) AND ("T"."VALID_TIME_END" IS NULL OR
              SYS_EXTRACT_UTC(INTERNAL_FUNCTION("T"."VALID_TIME_END"))>SYS_EXTRACT_UTC
              (SYSTIMESTAMP(6))))


Statistics
----------------------------------------------------------
         34  recursive calls
          8  db block gets
        397  consistent gets
          0  physical reads
          0  redo size
        347  bytes sent via SQL*Net to client
        532  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          0  rows processed

将时间有效期设置为20130811 09:39:50,根据上一篇文章我们设置的1分钟有效期,只有在20130811 09:39:40插入的这条活跃记录可以被显示出来。

SQL> exec dbms_flashback_archive.enable_at_valid_time('ASOF',to_date('20130811 09:39:50','YYYYMMDD HH24:MI:SS'));

PL/SQL procedure successfully completed.

SQL> select * from TV;

INSERT_TIME
-----------------
20130811 09:39:40


Execution Plan
----------------------------------------------------------
Plan hash value: 1723968289

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     3 |  6087 |   102   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| TV   |     3 |  6087 |   102   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("T"."ORA_ARCHIVE_STATE"='0' AND ("T"."VALID_TIME_START"
              IS NULL OR INTERNAL_FUNCTION("T"."VALID_TIME_START")<=TIMESTAMP'
              2013-08-11 09:39:50.000000000') AND ("T"."VALID_TIME_END" IS NULL OR
              INTERNAL_FUNCTION("T"."VALID_TIME_END")>TIMESTAMP' 2013-08-11
              09:39:50.000000000'))


Statistics
----------------------------------------------------------
         35  recursive calls
          6  db block gets
        398  consistent gets
          0  physical reads
          0  redo size
        550  bytes sent via SQL*Net to client
        543  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

结论:数据库内归档是一个Oracle利用隐藏字段实现的非常简单的功能,但是数据架构人员在规划的时候一定要考虑性能因素。

【Oracle Database 12c New Feature】ILM – Temporal Validity

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 COLUMN_NAME,DATA_TYPE,HIDDEN_COLUMN FROM USER_TAB_COLS WHERE TABLE_NAME='TV';

COLUMN_NAME          DATA_TYPE            HID
-------------------- -------------------- ---
VALID_TIME_END       DATE                 YES
VALID_TIME_START     DATE                 YES
INSERT_TIME          DATE                 NO
VALID_TIME           NUMBER               YES

插入一行当前时间

SQL> insert into TV values (sysdate);

1 row created.

正常情况选择,这行记录总是存在的

SQL> select * from TV;

INSERT_TIME
-----------------
20130811 09:04:30

为了应对这个新功能,在Flashback Query中新增了as of period for关键字。as of period for valid_time sysdate+1表示我们想查询在明天都还有效的数据,因为根据我们的设定,所有数据都只在插入以后1分钟内有效,因此自然无法找到在明天还有效的数据,返回零条记录。

SQL> select * from TV as of period for valid_time sysdate+1;

no rows selected

再插入一条测试数据。

SQL> insert into TV values (sysdate);

1 row created.

SQL> select * from TV;

INSERT_TIME
-----------------
20130811 09:04:30
20130811 09:08:27

我们想查询昨天就有效的数据,但是所有的数据有效期开始都是插入数据的那个时间点,自然无法找到昨天就有效的数据,返回零条记录。

SQL> select * from TV as of period for valid_time sysdate-1;

no rows selected

除了使用as of这种闪回查询的语法,还可以直接在会话级别设置有效时间点。CURRENT表示设置为当前时间点。

SQL> exec dbms_flashback_archive.enable_at_valid_time('CURRENT');

PL/SQL procedure successfully completed.

SQL> select * from TV;

no rows selected

在我的测试过程中,TV并不稳定,有时候即使设置了as of,也仍然会返回所有记录,但是过一会儿再次执行完全相同的语句,又能够返回符合条件的记录。没有详细跟踪不稳定的原因,但是猜测与cursor执行计划重用有关,毕竟Oracle的实现只是增加了一个filter条件,如果由于某种原因,之前cursor的执行计划被重用,那么很可能这个filter条件就没有加上,随之而来的也就会返回所有记录。

接下来,我们通过显示执行计划,看看Oracle是如何增加这个filter条件的。
首先禁用TV。执行计划是很正常的全表扫描。

SQL> exec dbms_flashback_archive.DISABLE_ASOF_VALID_TIME;

PL/SQL procedure successfully completed.

SQL> select count(*) from tv;

  COUNT(*)
----------
     77477


Execution Plan
----------------------------------------------------------
Plan hash value: 4129329588

-------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |   102   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| TV   | 76349 |   102   (0)| 00:00:01 |
-------------------------------------------------------------------

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
        333  consistent gets
          0  physical reads
          0  redo size
        544  bytes sent via SQL*Net to client
        543  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

重新在会话级别启用TV,可以看到在第二步,也就是全表扫描之后增加了一个filter,由于指定的有效期是CURRENT,因此filter条件是VALID_TIME_START 小于等于 当前时间 小于 VALID_TIME_END,也就是只要指定的有效期落在VALID_TIME_START和VALID_TIME_END之间,这条记录就可以被显示出来。同时也可以看到如果这两个限制条件为空,也都作为开放区间,也就是为空就表示不做限制。
由于测试的记录都只有1分钟有效期,因此此时已经没有一条记录可以显示了。

SQL> exec dbms_flashback_archive.enable_at_valid_time('CURRENT');

PL/SQL procedure successfully completed.

SQL> select count(*) from tv;

  COUNT(*)
----------
         0


Execution Plan
----------------------------------------------------------
Plan hash value: 4129329588

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |    18 |   103   (1)| 00:00:01 |
|   1 |  SORT AGGREGATE    |      |     1 |    18 |            |          |
|*  2 |   TABLE ACCESS FULL| TV   |   287 |  5166 |   103   (1)| 00:00:01 |
---------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter(("T"."VALID_TIME_START" IS NULL OR
              SYS_EXTRACT_UTC(INTERNAL_FUNCTION("T"."VALID_TIME_START"))<=SYS_EXTRACT_
              UTC(SYSTIMESTAMP(6))) AND ("T"."VALID_TIME_END" IS NULL OR
              SYS_EXTRACT_UTC(INTERNAL_FUNCTION("T"."VALID_TIME_END"))>SYS_EXTRACT_UTC
              (SYSTIMESTAMP(6))))


Statistics
----------------------------------------------------------
         33  recursive calls
          4  db block gets
        354  consistent gets
          0  physical reads
          0  redo size
        541  bytes sent via SQL*Net to client
        543  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

通过执行计划显示后台机制是一方面,另一方面我们也可以看到实际上TV是会有性能问题的,如果WHERE条件中无法使用到索引而执行了全表扫描(我这里因为没有WHERE条件所以只能是全表扫描),那么无论最终符合有效期的记录是多少,总要先进行所有记录的扫描,我们可以通过前后两次的consistent gets基本相同来获得这个结论。

更直白的说,如果作为系统设计人员不去考虑索引的构建,而仅仅是启用了TV,那么哪怕根据有效期限制,有10万记录的表只有1条会被显示出来,也仍然需要先扫描10万记录,然后再filter掉99999条,这对于程序员来说,如果不仔细阅读执行计划,就可能会造成很大的困扰,程序员会很奇怪,为什么这张表里面看上去只有1条记录,但是却要扫描那么长时间呢?

结论:数据有效期是Oracle利用隐藏字段和Flashback Query技术作的一个有趣的功能,但是数据架构人员在规划的时候一定要考虑性能因素。

【Oracle Database 12c New Feature】Advanced Security – Oracle Data Redaction

1. 什么是Oracle Data Redaction
不确认正式的中文翻译是什么,我翻译为数据改写。这是一项在12c中出现的Oracle高级安全新组件,其作用是限制SQL语句的返回结果样式,对于特定的用户可以限制某些字段显示被自动改写过的值。这是一项非常有用的安全功能,而在12c之前如果要实现相同的功能,可能需要创建特定的视图,或者在存储到数据库的时候就用加密算法进行加密。而12c的数据改写功能则在最后数据返回到客户端的前一刻将数据改写,这并不会影响到数据真实的存储。看一个简单的例子就明白了。

原本存储的数据记录如下:

SQL> select * from EMPLOYEES;

EMPLOYEE_ID FIRST_NAME           LAST_NAME                 SOCIAL_SECU     SALARY
----------- -------------------- ------------------------- ----------- ----------
        100 Steven               King                      247-85-9056       7000
        101 Neena                Kochhar                   334-08-6578       5000

在设置完Data Redaction之后,再次执行相同的语句,可以看到有隐私性质的列-社会保障号被遮盖了,只显示最后4位,这就实现了安全的目的。

SQL> select * from kamus.employees;

EMPLOYEE_ID FIRST_NAME           LAST_NAME                 SOCIAL_SECU     SALARY
----------- -------------------- ------------------------- ----------- ----------
        100 Steven               King                      ***-**-9056       7000
        101 Neena                Kochhar                   ***-**-6578       5000

2. 如何设置Oracle Data Redaction
设置用户的合适权限,由于Oracle Redaction对于DBA用户不起效果,因此需要将DBA角色收回。

revoke dba from kamus;
grant connect, resource, unlimited tablespace to kamus;
grant select on sys.redaction_policies to kamus;
grant select on sys.redaction_columns to kamus;
grant execute on dbms_redact to kamus;

创建测试环境,包括测试表和测试数据。

CREATE TABLE "EMPLOYEES" (
"EMPLOYEE_ID" NUMBER(6,0), 
"FIRST_NAME" VARCHAR2(20), 
"LAST_NAME" VARCHAR2(25), 
"SOCIAL_SECURITY" VARCHAR2(11), 
"SALARY" NUMBER(4,0)
)
/

Insert into EMPLOYEES (EMPLOYEE_ID,FIRST_NAME,LAST_NAME,SOCIAL_SECURITY,SALARY) values (100,'Steven','King','247-85-9056',7000);
Insert into EMPLOYEES (EMPLOYEE_ID,FIRST_NAME,LAST_NAME,SOCIAL_SECURITY,SALARY) values (101,'Neena','Kochhar','334-08-6578',5000);
commit;

SQL> select * from EMPLOYEES;

EMPLOYEE_ID FIRST_NAME           LAST_NAME                 SOCIAL_SECU     SALARY
----------- -------------------- ------------------------- ----------- ----------
        100 Steven               King                      247-85-9056       7000
        101 Neena                Kochhar                   334-08-6578       5000

Oracle Redaction针对单张表的某个字段进行设置,分别通过ADD_POLICY存储过程的object_name和column_name来控制;Redaction有多种类型,第一种为FULL,也就是完全改写,对于字符类型的字段将改写为一个空格,对于数字类型的字段改写为0,对于日期类型的字段改写为2001-01-01,类型通过function_type参数来控制。

BEGIN
DBMS_REDACT.ADD_POLICY (
   object_schema          => 'KAMUS',
   object_name            => 'EMPLOYEES',
   policy_name            => 'REDACT_EMP',
   column_name            => 'SOCIAL_SECURITY',
   function_type          => DBMS_REDACT.FULL,
   expression             => '1=1',
   enable                 => TRUE
   );
END;
/

SQL> select * from employees;

EMPLOYEE_ID FIRST_NAME           LAST_NAME                 SOCIAL_SECU     SALARY
----------- -------------------- ------------------------- ----------- ----------
        100 Steven               King                                        7000
        101 Neena                Kochhar                                     5000

Redaction的第二种类型是RANDOM,对于字符类型的字段将改写为随机字符,对于数字类型的字段改写为具有相同长度的随机数字,对于日期类型的字段改写为随机日期(永远不会跟真实日期相同)。

BEGIN
DBMS_REDACT.ALTER_POLICY (
   object_schema          => 'KAMUS',
   object_name            => 'EMPLOYEES',
   policy_name            => 'REDACT_EMP',
   column_name            => 'SOCIAL_SECURITY',
   action                 => DBMS_REDACT.MODIFY_COLUMN,
   function_type          => DBMS_REDACT.RANDOM
);
END;
/

SQL> select * from kamus.employees;

EMPLOYEE_ID FIRST_NAME           LAST_NAME                 SOCIAL_SECU     SALARY
----------- -------------------- ------------------------- ----------- ----------
        100 Steven               King                      wa};w~ZC i&       7000
        101 Neena                Kochhar                   Q9N]##T/YAV       5000

Redaction的第三种类型是PARTIAL,将改写为按照function_parameters参数指定的格式。

BEGIN
DBMS_REDACT.ALTER_POLICY (
   object_schema          => 'KAMUS',
   object_name            => 'EMPLOYEES',
   policy_name            => 'REDACT_EMP',
   column_name            => 'SOCIAL_SECURITY',
   action                 => DBMS_REDACT.MODIFY_COLUMN,
   function_type          => DBMS_REDACT.PARTIAL,
   function_parameters    => 'VVVFVVFVVVV,VVV-VV-VVVV,*,1,5'
);
END;
/

SQL> select * from kamus.employees;

EMPLOYEE_ID FIRST_NAME           LAST_NAME                 SOCIAL_SECU     SALARY
----------- -------------------- ------------------------- ----------- ----------
        100 Steven               King                      ***-**-9056       7000
        101 Neena                Kochhar                   ***-**-6578       5000

3. 如何精细化设置哪些用户才启用数据改写
通过expression参数设置,比如如下所示,所有不是KAMUS的用户都启用在EMPLOYEES.SOCIAL_SECURITY字段上的数据改写,而如果是KAMUS用户进行检索,则还是返回真实的数据。

BEGIN
DBMS_REDACT.ALTER_POLICY (
   object_schema          => 'KAMUS',
   object_name            => 'EMPLOYEES',
   policy_name            => 'REDACT_EMP',
   column_name            => 'SOCIAL_SECURITY',
   action                 => DBMS_REDACT.MODIFY_EXPRESSION,
   expression             => 'SYS_CONTEXT ( ''USERENV'',''SESSION_USER'' ) !=''KAMUS'''
);
END;
/

expression参数非常灵活,通过此参数可以使Data Redaction发挥巨大的作用。expression参数可选值如下图所示。
Screen Shot 2013-07-31 at 6.27.12 PM

4. 如何增加数据改写策略
通过DBMS_REDACT.ALTER_POLICY存储过程可以增加多个字段的数据改写策略,比如下例,增加在SALARY字段上的全数据改写。

BEGIN
DBMS_REDACT.ALTER_POLICY (
   object_schema          => 'KAMUS',
   object_name            => 'EMPLOYEES',
   policy_name            => 'REDACT_EMP',
   column_name            => 'SALARY',
   action                 => DBMS_REDACT.ADD_COLUMN,
   function_type          => DBMS_REDACT.FULL,
   expression             => 'SYS_CONTEXT ( ''USERENV'',''SESSION_USER'' ) !=''KAMUS'''
);
END;
/

SQL> select * from kamus.employees;

EMPLOYEE_ID FIRST_NAME           LAST_NAME                 SOCIAL_SECU     SALARY
----------- -------------------- ------------------------- ----------- ----------
        100 Steven               King                      ***-**-9056          0
        101 Neena                Kochhar                   ***-**-6578          0

5. 数据改写到底是发生在哪一阶段,有哪些限制

--where条件中的字段并不会受数据改写影响,可以看到即使最后都是显示SALARY=0,但是where条件还是正常执行并筛选出正确结果的。
SQL> select * from kamus.employees where SALARY>5000;

EMPLOYEE_ID FIRST_NAME           LAST_NAME                 SOCIAL_SECU     SALARY
----------- -------------------- ------------------------- ----------- ----------
        100 Steven               King                      ***-**-9056          0

SQL> select * from kamus.employees where SALARY<5000;

no rows selected

SQL> select * from kamus.employees where SALARY=5000;

EMPLOYEE_ID FIRST_NAME           LAST_NAME                 SOCIAL_SECU     SALARY
----------- -------------------- ------------------------- ----------- ----------
        101 Neena                Kochhar                   ***-**-6578          0

--在启用了数据改写策略的表上无法进行全表的CTAS操作。
SQL> create table t as select * from kamus.employees;
create table t as select * from kamus.employees
                         *
ERROR at line 1:
ORA-28081: Insufficient privileges - the command references a redacted object.

--如果CTAS操作中的字段上没有启用数据改写策略,CTAS可以正常进行。
SQL> create table t as select EMPLOYEE_ID,FIRST_NAME from kamus.employees;

Table created.

SQL> drop table t;

Table dropped.

--如果包含了启用数据改写策略的列,则会报ORA-28081错误。
SQL> create table t as select EMPLOYEE_ID,FIRST_NAME,SALARY from kamus.employees;
create table t as select EMPLOYEE_ID,FIRST_NAME,SALARY from kamus.employees
                                                *
ERROR at line 1:
ORA-28081: Insufficient privileges - the command references a redacted object.