ArcSDE for Oracle 12.1.0.2 In-Memory元件測試
如今，記憶體資料庫被大家廣泛認可，懂得技術的人都明白，資料從磁碟讀寫肯定比在記憶體中讀寫要慢很多，而且目前也有很多記憶體資料已經有非常成熟的實施經驗，當然，當今資料庫的老大Oracle更加不會無視這個市場，很早就渲染他們Oracle12c的記憶體元件多麼的牛叉，快到不行更是他們經常使用的詞彙。
在今年7月22日，Oracle終於釋出了12.1.0.2版本，當然最關注的就是這個In-Memory元件的使用了。下載地址：http://www.oracle.com/technetwork/database/enterprise-edition/downloads/database12c-linux-download-2240591.html
在12c的In-Memory Option選件之中，資料在記憶體的獨立區域中按照列式儲存，資料是被壓縮存放的，記憶體與列式壓縮可以極大提升查詢的效能，下圖是IMO的示意圖：
這是美國時間6月10日，拉里做的12c inmemory option的現場釋出會。
------------------------------------------------------------------
版權所有，文章允許轉載，但必須以連結方式註明源地址，否則追究法律責任!
建議看到轉載，請直接訪問正版連結獲得最新的ArcGIS技術文章
Blog:
------------------------------------------------------------------
測試環境1：VM虛擬機器 、Linux 5.5、4GB記憶體、Oracle12.1.0.2 資料介紹：非空間資料
1：連線到sys使用者下，檢視記憶體初始化引數的值
[[email protected] ~]$ sqlplus / as sysdba SQL*Plus: Release 12.1.0.2.0 Production on Wed Jul 30 23:25:42 2014 Copyright (c) 1982, 2014, Oracle. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options SQL> show parameter inm NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ inmemory_clause_default string inmemory_force string DEFAULT inmemory_max_populate_servers integer 0 inmemory_query string ENABLE inmemory_size big integer 0 inmemory_trickle_repopulate_servers_ integer 1 percent optimizer_inmemory_aware boolean TRUE
2：預設情況下記憶體引數inmemory_size是沒有值得，使用者需要手動修改引數值。
- inmemory_clause_default：預設空值，表示需要顯式的指定某個table才能in memory。INMEMORY，表示所有的new table都in memory；NO INMEMORY，和空值是一個意思。
- inmemory_force：default：具有IN MEMORY屬性的table，才會被選定以in memory的方式儲存。OFF：即使具有IN MEMORY AREA被配置了，也不會有table以in memory的方式儲存。ON：除非顯式的指定NO INMEMORY的屬性的table，其他的table都會以in memory方式儲存。
- inmemory_query：enable，可以進行inmemory_query；disable，禁用inmemory_query
- inmemory_size：設定inmemory option的記憶體大小，注，不能動態調整。
- inmemory_max_populate_servers ：該引數設定用於將資料載入到記憶體的後臺程序數量
SQL> alter system set inmemory_size=2G scope=spfile;
System altered.
SQL> alter system set inmemory_max_populate_servers=2 scope=spfile;
System altered.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 4294967296 bytes
Fixed Size 2932632 bytes
Variable Size 603979880 bytes
Database Buffers 1526726656 bytes
Redo Buffers 13844480 bytes
In-Memory Area 2147483648 bytes
Database mounted.
Database opened.
SQL> show parameter inm
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
inmemory_clause_default string
inmemory_force string DEFAULT
inmemory_max_populate_servers integer 2
inmemory_query string ENABLE
inmemory_size big integer 2G
inmemory_trickle_repopulate_servers_ integer 1
percent
optimizer_inmemory_aware boolean TRUE
------------------------------------------------------------------
版權所有，文章允許轉載，但必須以連結方式註明源地址，否則追究法律責任!
建議看到轉載，請直接訪問正版連結獲得最新的ArcGIS技術文章
Blog: http://blog.csdn.net/linghe301
------------------------------------------------------------------
3：建立一個普通表，然後進行一個普通測試
SQL> create table t1 as select * from dba_objects;
Table created.
SQL> select bytes/1024/1024 from user_segments where segment_name='T1';
BYTES/1024/1024
---------------
12.5
SQL> set timing on
SQL> set time on
01:53:00 SQL> set autot traceonly
01:53:07 SQL> select * from t1;
92177 rows selected.
Elapsed: 00:00:03.51
Execution Plan
----------------------------------------------------------
Plan hash value: 3617692013
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 92177 | 10M| 429 (1)| 00:00:01 |
| 1 | TABLE ACCESS FULL| T1 | 92177 | 10M| 429 (1)| 00:00:01 |
--------------------------------------------------------------------------
Statistics
----------------------------------------------------------
2 recursive calls
0 db block gets
7596 consistent gets
1546 physical reads
0 redo size
12280356 bytes sent via SQL*Net to client
68146 bytes received via SQL*Net from client
6147 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
92177 rows processed我們從執行計劃中可以看到，邏輯讀7596個、物理讀1546個。該表在資料庫中佔用空間約12.5MB。
4：建立同樣的表在記憶體元件中進行測試
SQL> create table t2 as select * from dba_objects;
Table created.
SQL> set line 200
SQL> alter table t2 inmemory;
Table altered.
SQL> select * from v$inmemory_area;
POOL ALLOC_BYTES USED_BYTES POPULATE_STATUS CON_ID
-------------------------- ----------- ---------- -------------------------- ----------
1MB POOL 1710227456 4194304 DONE 3
64KB POOL 419430400 51314688 DONE 3
SQL> select count(*) from t2;
COUNT(*)
----------
92178
SQL> select * from v$inmemory_area;
POOL ALLOC_BYTES USED_BYTES POPULATE_STATUS CON_ID
-------------------------- ----------- ---------- -------------------------- ----------
1MB POOL 1710227456 8388608 DONE 3
64KB POOL 419430400 51445760 DONE 3
SQL> set timing on
SQL> set time on
01:59:12 SQL> set autot traceonly
01:59:21 SQL> select * from t2;
92178 rows selected.
Elapsed: 00:00:03.42
Execution Plan
----------------------------------------------------------
Plan hash value: 1513984157
-----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 92178 | 10M| 31 (17)| 00:00:01 |
| 1 | TABLE ACCESS INMEMORY FULL| T2 | 92178 | 10M| 31 (17)| 00:00:01 |
-----------------------------------------------------------------------------------
Statistics
----------------------------------------------------------
5 recursive calls
0 db block gets
9 consistent gets
0 physical reads
0 redo size
5016356 bytes sent via SQL*Net to client
68146 bytes received via SQL*Net from client
6147 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
92178 rows processed------------------------------------------------------------------
版權所有，文章允許轉載，但必須以連結方式註明源地址，否則追究法律責任!
建議看到轉載，請直接訪問正版連結獲得最新的ArcGIS技術文章
Blog: http://blog.csdn.net/linghe301
------------------------------------------------------------------
5：結論
從上面可以看出，當將表至於inmemory狀態時，該資料並沒有在記憶體中，我們可以檢視v$inmemory_area表裡面資訊，我們需要執行一些SQL語句如select count(*) from table將表讀入記憶體中，這時候檢視v$inmemory_area表中可以看到增長的資訊，可能我原來進行過相關測試，1M記憶體pool和64K記憶體pool都有相關的資訊，我們可以進行壓縮對比來檢視行式儲存和列式儲存的比較。
02:12:21 SQL> select (51445760 +8388608 -51314688 -4194304)/1024/1024 MB from dual;
MB
----------
4.125
可以進行對比，行式儲存為12.5MB，列式儲存約4MB，如果資料量更大的話這個對比更加明顯。
另外我們可以看到，使用in-memory元件，相關的邏輯讀僅有5，而且沒有物理讀，這個也是該元件的高效之處。
但是我們細心的朋友也會發現一個問題，普通查詢耗時3.51秒，但是記憶體元件查詢耗時3.42秒，我們看到後者的指標要比前者漂亮的多，但是效能方面並沒有想象中的提高，這個是為什麼呢？
經過諮詢，這個問題可能是：inmemory是列式儲存，資料經過壓縮的。它的優勢是針對某些列的分析型操作。你如果只是把資料拿出來，資料庫需要把列資料拼成行資料，相對於普通的行式儲存還要幹額外的工作，當然要慢了。
PS：因為虛擬機器的問題，我們測試都是在同一條件下進行，結果可能有所不同，但是希望能夠說明相關的問題。
6：其他
當然，Oracle也提供了In-Memory 的檢視來幫助使用者進行分析
v$im_segments
SQL> desc v$im_segments
Name Null? Type
----------------------------------------- -------- ----------------------------
OWNER VARCHAR2(128)
SEGMENT_NAME VARCHAR2(128)
PARTITION_NAME VARCHAR2(128)
SEGMENT_TYPE VARCHAR2(18)
TABLESPACE_NAME VARCHAR2(30)
INMEMORY_SIZE NUMBER
BYTES NUMBER
BYTES_NOT_POPULATED NUMBER
POPULATE_STATUS VARCHAR2(9)
INMEMORY_PRIORITY VARCHAR2(8)
INMEMORY_DISTRIBUTE VARCHAR2(15)
INMEMORY_DUPLICATE VARCHAR2(13)
INMEMORY_COMPRESSION VARCHAR2(17)
CON_ID NUMBER
SQL> select inmemory_size/1024/1024,bytes/1024/1024 from v$im_segments where segment_name='T2';
INMEMORY_SIZE/1024/1024 BYTES/1024/1024
----------------------- ---------------
4.125 12.5
user_tables表也會多了幾項關於INMEMORY的相關資訊
SQL> desc user_tables
Name Null? Type
----------------------------------------- -------- ----------------------------
TABLE_NAME NOT NULL VARCHAR2(128)
TABLESPACE_NAME VARCHAR2(30)
CLUSTER_NAME VARCHAR2(128)
IOT_NAME VARCHAR2(128)
STATUS VARCHAR2(8)
PCT_FREE NUMBER
PCT_USED NUMBER
INI_TRANS NUMBER
MAX_TRANS NUMBER
INITIAL_EXTENT NUMBER
NEXT_EXTENT NUMBER
MIN_EXTENTS NUMBER
MAX_EXTENTS NUMBER
PCT_INCREASE NUMBER
FREELISTS NUMBER
FREELIST_GROUPS NUMBER
LOGGING VARCHAR2(3)
BACKED_UP VARCHAR2(1)
NUM_ROWS NUMBER
BLOCKS NUMBER
EMPTY_BLOCKS NUMBER
AVG_SPACE NUMBER
CHAIN_CNT NUMBER
AVG_ROW_LEN NUMBER
AVG_SPACE_FREELIST_BLOCKS NUMBER
NUM_FREELIST_BLOCKS NUMBER
DEGREE VARCHAR2(10)
INSTANCES VARCHAR2(10)
CACHE VARCHAR2(5)
TABLE_LOCK VARCHAR2(8)
SAMPLE_SIZE NUMBER
LAST_ANALYZED DATE
PARTITIONED VARCHAR2(3)
IOT_TYPE VARCHAR2(12)
TEMPORARY VARCHAR2(1)
SECONDARY VARCHAR2(1)
NESTED VARCHAR2(3)
BUFFER_POOL VARCHAR2(7)
FLASH_CACHE VARCHAR2(7)
CELL_FLASH_CACHE VARCHAR2(7)
ROW_MOVEMENT VARCHAR2(8)
GLOBAL_STATS VARCHAR2(3)
USER_STATS VARCHAR2(3)
DURATION VARCHAR2(15)
SKIP_CORRUPT VARCHAR2(8)
MONITORING VARCHAR2(3)
CLUSTER_OWNER VARCHAR2(128)
DEPENDENCIES VARCHAR2(8)
COMPRESSION VARCHAR2(8)
COMPRESS_FOR VARCHAR2(30)
DROPPED VARCHAR2(3)
READ_ONLY VARCHAR2(3)
SEGMENT_CREATED VARCHAR2(3)
RESULT_CACHE VARCHAR2(7)
CLUSTERING VARCHAR2(3)
ACTIVITY_TRACKING VARCHAR2(23)
DML_TIMESTAMP VARCHAR2(25)
HAS_IDENTITY VARCHAR2(3)
CONTAINER_DATA VARCHAR2(3)
INMEMORY VARCHAR2(8)
INMEMORY_PRIORITY VARCHAR2(8)
INMEMORY_DISTRIBUTE VARCHAR2(15)
INMEMORY_COMPRESSION VARCHAR2(17)
INMEMORY_DUPLICATE VARCHAR2(13)
------------------------------------------------------------------
版權所有，文章允許轉載，但必須以連結方式註明源地址，否則追究法律責任!
建議看到轉載，請直接訪問正版連結獲得最新的ArcGIS技術文章
Blog: http://blog.csdn.net/linghe301
------------------------------------------------------------------
測試環境2：IBM 筆記本 W500 、Linux 6.4、8GB記憶體、Oracle12.1.0.2、ArcSDE10.3 資料介紹：空間資料 ST_Geometry儲存，記憶體引數設定為3GB
1：首先看一下資料情況，面狀資料subdltb約300W條記錄，查詢資料也是面狀資料query，裡面包含一個大的要素
11:40:28 SQL> select count(*) from subdltb;
COUNT(*)
----------
2999999
Elapsed: 00:00:11.09
11:40:53 SQL> select sde.st_area(shape) from query where objectid=3;
SDE.ST_AREA(SHAPE)
------------------
4.0640E+10
Elapsed: 00:00:00.422：使用ArcSDE for Oracle的ST_Intersects函式進行查詢，然後進行sum求和
11:41:16 SQL> select sum(a.db2gse_st_) from subdltb a,query b where sde.st_intersects(a.shape,b.shape)=1 and b.objectid=3;
SUM(A.DB2GSE_ST_)
-----------------
4451543224
Elapsed: 00:03:01.04
Execution Plan
----------------------------------------------------------
Plan hash value: 2821153078
--------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows |Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 |4648 | 2 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 |4648 | | |
| 2 | NESTED LOOPS | | 27712 |122M | 2 (0)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID | QUERY | 1 |2324 | 0 (0)| 00:00:01 |
|* 4 | INDEX UNIQUE SCAN | R7_SDE_ROWID_UK | 1 | | 0 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID | SUBDLTB | 27712 |61M | 2 (0)| 00:00:01 |
|* 6 | DOMAIN INDEX (Sel: Default - No Stats)| SHAPE_92247_4_SIDX | | | 18E (0)| |
--------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("B"."OBJECTID"=3)
6 - access("SDE"."ST_INTERSECTS"("A"."SHAPE","B"."SHAPE")=1)
Note
-----
- dynamic statistics used: dynamic sampling (level=2)
Statistics
----------------------------------------------------------
733910 recursive calls
0 db block gets
835491 consistent gets
88615 physical reads
0 redo size
559 bytes sent via SQL*Net to client
552 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
677 sorts (memory)
0 sorts (disk)
1 rows processed
3：使用In-MEMORY元件進行測試
將相關要素類進行Inmemory
SQL> select * from v$inmemory_area;
POOL ALLOC_BYTES USED_BYTES POPULATE_STATUS CON_ID
-------------------------- ----------- ---------- -------------------------- ----------
1MB POOL 2565865472 4194304 DONE 3
64KB POOL 637534208 51642368 DONE 3
SQL> alter table query inmemory;
Table altered.
SQL> select count(*) from query;
COUNT(*)
----------
4
SQL> select * from v$inmemory_area;
POOL ALLOC_BYTES USED_BYTES POPULATE_STATUS CON_ID
-------------------------- ----------- ---------- -------------------------- ----------
1MB POOL 2565865472 4194304 DONE 3
64KB POOL 637534208 51642368 DONE 3
SQL> select bytes/1024 KB from user_segments where segment_name='QUERY';
KB
----------
64
然後將subdltb資料放入記憶體中。
SQL> alter table subdltb inmemory;
Table altered.
SQL> select count(*) from subdltb;
COUNT(*)
----------
2999999
SQL> select * from v$inmemory_area;
POOL ALLOC_BYTES USED_BYTES POPULATE_STATUS CON_ID
-------------------------- ----------- ---------- -------------------------- ----------
1MB POOL 2565865472 849346560 POPULATING 3
64KB POOL 637534208 52297728 POPULATING 3
SQL> /
POOL ALLOC_BYTES USED_BYTES POPULATE_STATUS CON_ID
-------------------------- ----------- ---------- -------------------------- ----------
1MB POOL 2565865472 2554331136 DONE 3
64KB POOL 637534208 52953088 DONE 3我們看到，一開始檢視v$inmemory_area的populate_status是populating，這是因為300W記錄的資料，需要一定的時間寫入記憶體中，所以需要稍等些時間狀態才會變成DONE。然後檢視一下v$im_segments表資訊
SQL> select INMEMORY_SIZE/1024/1024,bytes/1024/1024 from v$im_segments where segment_name='SUBDLTB';
INMEMORY_SIZE/1024/1 BYTES/1024/1024
-------------------- ---------------
1182.25 1025
進行實際查詢
SQL> set timing on
SQL> set time on
12:36:09 SQL> set autot on
12:36:16 SQL> select sum(a.db2gse_st_) from subdltb a,query b where sde.st_intersects(a.shape,b.shape)=1 and b.objectid=3;
SUM(A.DB2GSE_ST_)
-----------------
4451543224
Elapsed: 00:03:00.14
Execution Plan
----------------------------------------------------------
Plan hash value: 2821153078
----------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 4648 | 2 (0) | 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 4648 | | |
| 2 | NESTED LOOPS | | 27712 | 122M| 2 (0)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID | QUERY | 1 | 2324 | 0 (0)| 00:00:01 |
|* 4 | INDEX UNIQUE SCAN | R7_SDE_ROWID_UK | 1 | | 0 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID | SUBDLTB | 27712 | 61M| 2 (0)| 00:00:01 |
|* 6 | DOMAIN INDEX (Sel: Default - No Stats)| SHAPE_92247_4_SIDX | | | 18E (0) | |
----------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("B"."OBJECTID"=3)
6 - access("SDE"."ST_INTERSECTS"("A"."SHAPE","B"."SHAPE")=1)
Note
-----
- dynamic statistics used: dynamic sampling (level=2)
Statistics
----------------------------------------------------------
734531 recursive calls
0 db block gets
835836 consistent gets
87819 physical reads
0 redo size
559 bytes sent via SQL*Net to client
551 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
455 sorts (memory)
0 sorts (disk)
1 rows processed
12:39:25 SQL> select sum(a.db2gse_st_) from subdltb a,query b where sde.st_intersects(b.shape,a.shape)=1 and b.objectid=3;
SUM(A.DB2GSE_ST_)
-----------------
4451543224
Elapsed: 00:12:46.23
Execution Plan
----------------------------------------------------------
Plan hash value: 209829830
-------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 4648 | 1851 (29)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 4648 | | |
| 2 | NESTED LOOPS | | 27712 | 122M| 1851 (29)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID| QUERY | 1 | 2324 | 0 (0)| 00:00:01 |
|* 4 | INDEX UNIQUE SCAN | R7_SDE_ROWID_UK | 1 | | 0 (0)| 00:00:01 |
|* 5 | TABLE ACCESS INMEMORY FULL | SUBDLTB | 27712 | 61M| 1851 (29)| 00:00:01 |
-------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("B"."OBJECTID"=3)
5 - filter("SDE"."ST_INTERSECTS"("B"."SHAPE","A"."SHAPE")=1)
Note
-----
- dynamic statistics used: dynamic sampling (level=2)
Statistics
----------------------------------------------------------
1801418 recursive calls
0 db block gets
1124 consistent gets
17 physical reads
0 redo size
559 bytes sent via SQL*Net to client
551 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
1 rows processed看到這個結果，我覺得是否是空間索引表如果In memory是否有相關效果，結果發現，空間索引表不支援in memory，會報ora-64358錯誤
SQL> select index_id from st_geometry_index where table_name='SUBDLTB';
INDEX_ID
----------
2
SQL> alter table s2_idx$ inmemory;
alter table s2_idx$ inmemory
*
ERROR at line 1:
ORA-64358: in-memory column store feature not supported for IOTs4：結論
通過對比可以看到，雖然在記憶體中進行查詢，大家都知道，st_instersects(a,b)需要傳入兩個引數，該函式a引數會走空間索引，b引數走全表掃描，所以儘可能將資料量大的放到a引數的位置，我按照最高效的方式測試，發現這種方式與普通查詢沒有任何差別，不管是邏輯讀還是物理讀和普通查詢區別不大，查詢時間也基本類似，如果我更換順序，走比較低效的查詢方式，果然，從執行計劃指標上看，在記憶體中進行全表掃描，而且物理讀和邏輯讀明顯減少，但是執行效率更加低效。
在記憶體技術方面，甲骨文並沒有採用SAP HANA的“全記憶體”架構，資料會根據不同的“溫度”來選擇不同的處理方式，包含傳統硬碟、快閃記憶體和記憶體三個層級，而不是把全部的資料都放到記憶體當中。Andy Mendelsohn介紹，在Oracle Database In-memory當中，最活躍或者說最熱的資料將放到記憶體中進行分析，活躍度相對較低的資料會採用快閃記憶體（事實上，Oracle資料庫是最早擁抱快閃記憶體的產品之一，在Exadata上已經大面積使用了快閃記憶體儲存），而溫度最低、最不活躍的資料還是會採用傳統磁碟來儲存。根據不同需求的資料採取不同的策略，這樣做的好處在於，客戶不必採購大量的記憶體裝置就可以獲得最佳效能提升，降低了總體成本，提升了投資回報率。
目前，Oracle的 IN-MEMORY元件還處於研究階段，這方面的資料還比較少，該問題還在不斷研究中，希望能夠得到一些有些的解決方法！
當然Oracle的IN-MEMORY OPTION作為一個剛剛釋出的元件還沒有經過專案的實踐，這不已經可以看到關於它的Bug問題了。
Oracle: That BUG in our In-Memory Option will be fixed in October
http://www.theregister.co.uk/2014/07/31/oracle_in_memory_bug_fix
------------------------------------------------------------------
版權所有，文章允許轉載，但必須以連結方式註明源地址，否則追究法律責任!
建議看到轉載，請直接訪問正版連結獲得最新的ArcGIS技術文章
Blog: http://blog.csdn.net/linghe301
歡迎新增微信公眾號：ArcGIS技術分享（arcgis_share），直接回復1就可以在移動端獲取最新技術文章
------------------------------------------------------------------
參考文件：
Oracle 12c新特性:IN-Memory Option - 列存與壓縮：http://www.eygle.com/archives/2014/07/oracle_12c_inmemory_option_two.html
Oracle 12c In-Memory option：http://www.orasql.com/blog/archives/2014/07/23/12c_inmemory.htm
【Oracle Database 12c新特性】In-Memory Option：http://www.askmaclean.com/archives/12c-in-memory-option.html
inmemory option的簡單介紹和測試：http://www.oracleblog.org/study-note/in-memory-option-simple-test/