http://scn.sap.com/docs/DOC-35523/ HANA視頻學習網站
http://www.erp100.com/article-8632-1.html 對RDBMS、內存數據庫（SAP
HANA）與 HADOOP 的認識
（High-Performance
Analytic Appliance ，簡稱HANA，高性能分析設備）
HANA是一個軟硬件結合體，提供高性能的數據查詢功能，用戶可以直接對大量實時業務數據進行查詢和分析，而不需要對業務數據進行建模、聚合等。SAP內存數據庫的數據並不是只在內存裏，也會不停寫到硬盤裏，這就用到複製服務器Replication
Server，包括Log-based，Trigger-based和ETL-based。這些複製服務器需要用到Sybase Replication Server、Sybase Replication Server Agent、Sybase Adaptive Server EntERPrise (AES，適用性服務器)等，以及HANA Load Controller和BO Data Services。
從較高層面來看，若要了解 Hadoop，需重點掌握其四大功能：Hadoop是分佈式文件系統
- 商用服務器集羣
- Hadoop MapReduce 編程模型
- Hadoop 軟件架構
- Hadoop 生態系統
RDBMS、內存數據庫（SAP
HANA）與 HADOOP 的區別
挑選在 OLTP 或分析型解決方案環境中使用的數據技術時，我們需要了解各項備選技術之間的差異。下表列出了傳統 RDBMS、內存數據庫（特別是 SAP HANA）以及 Hadoop 之間的主要區別。該表格並非針對特定產品製作，因而具有一定程度的普遍性。技術發展日新月異，表中列出的詳細信息也必然會隨之改變。然而，值得注意的是，不同數據庫類型所表現出的以下關鍵差異性，在未來極有可能保持不變：
- RDBMS 仍將是解決衆多問題的可行解決方案，特別是對於時效性要求不高的簡單的 OLTP 而言。
- SAP HANA 等採用內存計算技術的產品，最適用於注重速度（例如，實時數據更新和分析），但數據量不至於過大，並且對於企業而言，成本較爲合理的業務場景。
- Hadoop 則更適用於具備以下特徵的場景，即數據數量非常大，數據類型（如非結構化文本）難以採用其他數據庫技術進行存儲，且對數據分析及其處理速度要求不高，或者必須儘量削減成本。
如何創建XS Job來完成定時任務
你將在本文中看到如何編寫一個簡單的XS應用並調度一個XS Job來執行它。這個應用會向特定的表裏插入一條記錄。
1. 前提條件
1.1 這個功能從HANA SPS07開始有效，所以請確保你的HANA是Revision 70之後的版本。
1.2 確保XSEngine正常運行。
在你的Web Browser裏輸入http://<Web_Server_Host>:80<HANA_instance>/sap/hana/xs/admin/，如果能看到下面的界面就說明XSEngine一切正常。
1.3 HANA上的必要配置
你可以把下面這些和XSengine相關的角色賦給用戶(這裏我們使用的用戶是"DEMO_USER")。
該用戶的Schema權限也要賦給用戶_SYS_REPO。
在xsengine.ini裏添加section "schedule"和參數"enabled"如下。
如果需要向表裏寫數據，你必須把"sqlscript mode"改成"UNSECURE"(如下圖)，否則你只能在procedure裏使用select語句。
2. Procedure
2.1 新建XS project。
當要給project指定一個workspace時，你可以新建一個workspace或者使用缺省的workspace。
這裏我們使用缺省的workspace。
你可以在Project Explorer裏看到新建的project。
同時你也可以在Web Browser裏看到它。
2.2 新建數據庫object。
這裏我們新建個表來做測試。
2.3 新建XS JavaScript和XS Job。
按下面的步驟新建XS JavaScript。
.xsjs文件生成之後，如下新建一個JavaScript function。
我們向表DEMO_TABLE裏插入一條包含時間戳的記錄。
function my_js() {
var sql = "INSERT INTO DEMO_USER.DEMO_TABLE VALUES ('inserted by javascript job', NOW())";
var conn = $.db.getConnection();
var pstmt = conn.prepareStatement(sql);
pstmt.execute();
conn.commit();
conn.close();
}
然後新建一個XS Job。
.xsjob文件生成之後，可以在XS Job文件裏定義任務了。
在"action"裏指定剛纔新建的XS JavaScript文件裏的function。
在"schedules"中指定調度時間，其中的"xscron"同Linux環境的"crontab"的語法類似，這裏我們指定每5秒鐘執行一次。
{
"description": "my first JS job",
"action": "XS_JOB_DEMO:my_js.xsjs::my_js",
"schedules": [
{
"description": "run every 5 seconds",
"xscron": "* * * * * * 0:59/5"
}
]
}
2.4 新建HANA Procedure和XS job。
按下面的步驟新建XS JavaScript。
.hdbprocedure文件生成之後，如下新建一個HANA Procedure。
我們也向表DEMO_TABLE裏插入一條包含時間戳的記錄。
PROCEDURE "DEMO_USER"."XS_JOB_DEMO::my_procedure" ( )
LANGUAGE SQLSCRIPT
SQL SECURITY INVOKER
DEFAULT SCHEMA DEMO_USER
AS
BEGIN
/*****************************
Write your procedure logic
*****************************/
INSERT INTO DEMO_TABLE VALUES('inserted by procedure job', NOW());
END;
然後同樣新建一個XS Job來執行這個Procedure。
請注意“action”的語法，和剛纔的XS JavaScript是不同的。
這裏我們指定每10秒鐘執行一次。
{
"description": "my first Procedure job",
"action": "XS_JOB_DEMO::my_procedure",
"schedules": [
{
"description": "run every 10 seconds",
"xscron": "* * * * * * 0:59/10"
}
]
}
2.5 在Web Browser裏啓動任務。
你可以在HANA XS Administration Tool裏看到剛纔新建的兩個XS Job。
輸入"User"和"Locale"，勾選"Active"，然後 按下"Save"之後XS Job就開始執行了。
你也可以在此監控任務。
從下圖可見JavaScript的任務每5秒執行一次，HANA Procedure的任務每10秒執行一次。
在之前的調查中，有用戶希望可以通過微視頻的方法瞭解SAP HANA。
因此做了一個SAP HANA 權限問題分析的小視頻，如果大家覺得內容和形式不錯，歡迎點贊。
如果有意見和建議，歡迎留言。
視頻的主要介紹了兩種權限分析的方法：
Authorization Trace
Authorization Dependency Viewer
並分別做了一個簡單的例子，如何設置，以及如何分析結果。
觀看視頻點擊鏈接： SAP HANA 權限分析
視頻中相關的系統視圖：
GRANTED_PRIVILEGES
USERS
OBJECTS
執行命令：
alter system alter configuration ('indexserver.ini','SYSTEM') SET('trace','authorization')='info' with reconfigure;
alter system alter configuration ('indexserver.ini','SYSTEM') unset ('trace','authorization') with reconfigure;
系統遷移HANA 示例及問題診斷
1.簡介
本blog演示將bw on oracle系統遷移至bw on HANA，並對常見問題作出解答。
2.最佳實踐
2.1. 導出源系統 (BW on Oracle)
2.1.1 SMIGR_CREATE_DDL (SE38)
這個ABAP程序會針對BW表進行準備工作。
這一步，將會生成用於在目標系統創建表的DDL語句。生成的rowstorelist.txt列出了將會以行存儲保存的表。生成的estimated_row_count.txt包含了各個行表的條目信息。這一信息將被用於在導入分佈式系統中所使用。
如下note提供了關於這個report的最新信息。請確保在執行SMIGR_CREATE_DD前，將此note中所有提及的關聯note安裝完畢。
1921023
- SMIGR_CREATE_DDL: Corrections and enhancements for SAP HANA.
您也可以通過如下link獲取幫助信息: http://scn.sap.com/docs/DOC-47657
執行完畢後，你可以找到如下生成的文件
2.1.2 運行SWPM
在導出系統時，SWPM主要有三個步驟：Export Preparation, Table Splitting Preparation 及 Database Instance Export。建議從service market 下載最新版本的SWPM用於完成系統遷移。
2.1.2.1 Export Preparation
這一步將會創建Export DVD。即生成後續導出系統所用的文件夾目錄結構。雖然文件夾目錄的創建也可以直接在第三步Export Database Instance時創建，但SWPM在並行執行export/import時會需要您提供Export DVD。
完成後，如下文件夾（空）目錄結構將會生成。
2.1.2.2 Table
Splitting Preparation
我們使用工具"SAPuptool"( Fastsplitter)來進行分拆表操作。這一工具是SUM/DMO的一個組成部分。這個工具相對於傳統的分拆表工具（R3ta
或Oracle table splitter）能更效率的完成分拆表操作。
執行下面的命令以確定您系統對應所需下載的組件
vml3158:~ # uname -a
Linux vml3158 3.0.101-0.46-default #1 SMP Wed Dec 17 11:04:10 UTC 2014 (8356111) x86_64 x86_64 x86_64 GNU/Linux)
通過加壓最新的SUM獲取SAPuptool:
SAPCAR -xvf SUM.SAR /sapcd/SUM10_SP13
以下爲分拆表命令的示例:
/sapcd/SUM10_SP13/SUM/abap/bin/SAPuptool splittable table =<table_name> segmentsize=0.2 nocntlines whereFile=<table_name>
下面是在SWPM中調用SAPuptool的步驟：.
導入分拆表文件
以下爲測試示例：
REPOSRC%10 表示將表REPOSRC分拆成10片。
如果想以固定的條目數來拆分，可使用：<TABLENAME>:<每個分片條目數>。
勾選Use SAPuptool from SUM，並提供已下載解壓後的文件路徑以啓用SAPuptool。
檢查參數。
完成分拆表。
現在到出媒介中將包含用於並行導出表的文件<table_name>.WHR，及之前進行了分拆表表目的文件whr.txt。
2.1.2.3 Database Instance Export
輸入先前生成的SMIGR目錄（2.1.1 SMIGR_CREATE_DDL）
定義分拆包的參數。在這一步，將會限定每個包的大小。
參數"Perform Parallel Export and Import"用於生產系統遷移。R3load會在目標硬件平臺執行導入。
注意：
對於BW系統，我們選擇 "Use
Unsorted Unload" 以加速導出。如果我們不選擇這個選項，表會在導出是進行排序。這意味着額外資源和時間的使用。
而這一選項僅可用於BW系統，因爲BW系統沒有cluster及pool 的結構。對於ERP系統，我們不能使用這一選項。此外，這也與目標系統數據庫類型相關，具體內容請參閱Note 954268.
選擇 "Unload Order by Size" 意味着根據導出尺寸進行排序。在第一次導出執行後，我們能分析各個包的統計時間以定義一個更優化導出次序。使得需要最長時間的job能在最開始運行。
job總是是基於CPU使用率和I/O吞吐量。一般來說，在導出時系統爲下線狀態，因此當CPU使用率都到達95%時，意味着系統資源幾乎被完全使用。
此處sapinst會讀取"CustomSortOrder.txt"以確定導出次序。我們可以根據之前運行的結果來定義這個文件。一般將最大，耗時最長的表加入這個文件中。
選項"-merge_bck"用於確保TSK文件在job意外中斷時的數據一致性。
檢查參數配置。
停止BW系統。
僅啓動數據庫（Oracle）
導出完畢。
你會發現，由SMIG_GREATE_DDL生成的文件被複制到了這個導出的文件夾。
2.2. 導入目標系統 (BW on HANA)
2.2.1 設置OS環境變量
在使用SWPM進行導入前，需要設置如下變量。
HDB_MASSIMPORT, 此參數參考Note 1775293及link：Migration
to SAP HANA: Latest News about SAP Note 1775293
_JAVA_OPTIONS,此參數參考link：RUNNING
WITH JAVA
2.2.2 設置HANA系統參數
建議將log_mode在進行import時臨時修改爲overwrite，以避免在導入過程中生成大量log backup文件。
2.2.3 設置Table Placement
此處需要按照您HANA系統架構（單機或是集羣；集羣中包含多少worker節點）解壓出Note1908075中對應的HdbTablePlacementParameters.SQL
文件。
2.2.4 執行SWPM
這裏將路徑設置爲在之前步驟2.1.2中導出媒介所在路徑。
將路徑設置爲先前解壓文件HdbTablePlacementParameters.SQL所在路徑。
下載Note1958346中附件HdbLandscapeReorgCheckProcedure.SQL，並設置對應路徑。
此處需要指定SAPEXE.SAR以及SAPEXEDB.SAP路徑到下載的kernel 文件路徑。
在解壓從service market place後，這兩個文件的文件路徑如下：
SAPEXE.SAR：/DATA_UNITS/K_7XX_U_LINUX_X86_64/DBINDEP/
SAPEXEDB.SAP：/DATA_UNITS/K_7XX_U_LINUX_X86_64/HDB/
導入完成。
3.常見問題及處理
3.1 時區設置
3.1.1問題描述：
若application server時間設置與HANA DB 時區設置不一致，會出現如下錯誤信息。
3.1.2解決方法：
調整HANA時區設置。以HANA <sid>adm用戶登錄，並修改在home目錄（/usr/sap/<SID>/home）下的兩個文件(.sapenv.csh, .sapenv/sh)，調整時區設置。
.sapenv.csh: setenv TZ <time zone>
.sapenv.sh: export TZ=<time zone>
修正後，需要重啓HANA數據庫以使時區設置生效。
如下信息可供參考：
1801227 - Change Time Zone if SID is not changed via Config. Tool
1829651 - Time zone settings in HANA scale out landscapes
1791342 - Time Zone Support in HANA
1932132 - SAP HANA : Large time difference between application server and HANA database.
3.2 HANA client 安裝媒介缺損
3.2.1問題描述：
在安裝過程中，步驟“Install SAP HANA Database Clinet”失敗。
手動安裝顯示如下錯誤：
vml3158:/sapmnt/vml3158/a/installfile # ./hdbinst
cannot exec /sapmnt/vml3158/a/installfile/./../install/sdbrun: No such file or directory
3.2.2解決方法：
下載完整的安裝媒介。
可以通過手動安裝HANA client以驗證媒介是否完整。
vml3158:/sapmnt/vml3158/a/installfile/hdbclient/SAP_HANA_CLIENT # ./hdbinst --batch -a client --path=/usr/sap/HBW/hdbclient --sid=HBW
3.3 Migration Key
3.3.1問題描述：
安裝過程中報錯：
3.3.2解決方法：
參考如下notes輸入正確migration key。
1899381 - How to check migration key issues during a System Copy
1134948 - ABAP Migration Key for special installation numbers (SAP internal)
在SAP Help Portal ( http://help.sap.com/hana_platform/) 中可以看到SAP HANA最新版本的相關文檔。
如果您需要查看HANA非最新版本的對應文檔時，可以通過如下路徑直接下載到之前所有版本的完整文檔。
SAP Service Marketplace -> Products -< Installation & Upgrade Guides -> SAP In-Memory Computing
-> SAP In-Memory Appliance (SAP HANA).
MCOD ( Multiple Components on One Database),
Database Software 和 Database Runtime Components 是共享的，並使用同一套硬件。
MCOS （Multiple Components on One System),
Database Software 和 Database Runtime Components是非共享的。
在SAP HANA中，除了基本的分詞等文本分析任務外，從SPS09開始增加了文本挖掘（Text Mining）的功能。具體來說，具體來說包括文本關鍵詞提取，文本分類，相似文本查找，相似單詞查找等功能，在SPS09中，文本挖掘接口以XS接口的形式提供，在SPS10中，提供了SQL形式的接口，這對於文本挖掘的任務，真是非常cool, 有了這個神器，文本分類不再需要整合R，直接在HANA中就可以實現文本分類的功能，具體來說，在HANA內部，在建立全文索引之後，維護了一個term-document矩陣，基於此，可以計算TF,IDF,TF-IDF等詞項權重，以歐幾里得距離爲基礎，實現K近鄰分類。
廢話不多說，下面直接見例子，本文只是介紹最基本用法爲主，更多參數及原理請讀者自行查找相關資料。
－ 準備數據
- SET SCHEMA TMTEST;
- DROP TABLE MYTEST CASCADE;
- CREATE COLUMN TABLE MYTEST(ID INTEGER primary key,CONTENT NCLOB,LANG VARCHAR(32),CLASS VARCHAR(64));
- INSERT INTO MYTEST VALUES('1','I am a chinese, I live in beijing','en','china');
- INSERT INTO MYTEST VALUES('2','I like fish,especially big fish','en','fish');
- INSERT INTO MYTEST VALUES('3','fish is an animal,live in water','en','fish');
- INSERT INTO MYTEST VALUES('4','fish is delicous, I like it','en','fish');
- INSERT INTO MYTEST VALUES('5','Chinese is great, I like chinese','en','china');
- INSERT INTO MYTEST VALUES('6','China and Chinese','en','china');
我們插入6條記錄，屬於倆個大類，‘china’跟'fish'.
二 建立全文索引
- DROP FULLTEXT INDEX ftidx;
- CREATE FULLTEXT INDEX ftidx ON MYTEST (CONTENT)
- ASYNC
- FAST PREPROCESS OFF
- SEARCH ONLY OFF
- TEXT ANALYSIS ON
- CONFIGURATION 'LINGANALYSIS_FULL'
- TEXT MINING ON
- TEXT MINING CONFIGURATION 'DEFAULT.textminingconfig'
- LANGUAGE DETECTION ('EN')
具體參數意義請參考相關文檔，我就不一個一個解釋了，主要是關閉FAST PREPROCESS,關閉SEARCH ONLY，打開TEXT ANALYSIS跟TEXT MINING，文本挖掘配置參數文件用默認的。
三 Delta Merge
- MERGE DELTA OF MYTEST;
記住，這一步非常重要！！！！！
四 相關功能函數
(1) 輸入一個單詞，找出相關的單詞。
例如找出fish的相關單詞
（2） 輸入一篇文章，找出文章中重要的單詞
例如，找出ID=3的文章中的重要單詞
（3） 輸入字符開頭，找出推薦的單詞
例如找出C開通的單詞
（4） 以文找文，輸入一篇文章，找出相似文章
（5） 以詞找文
（6） kNN分類算法
在上例子中，我們的訓練集合中就兩類，fish跟china。然後我們想看看water是哪個類別，在結果的CATEGORY_VALUE中看到是fish這一類的。
全部SQL代碼參考附件textmining.sql
參考資料：
1 http://help.sap.com/hana/SAP_HANA_Text_Mining_Developer_Guide_en.pdf
2 http://help.sap.com/hana/SAP_HANA_SQL_and_System_Views_Reference_en.pdf
[本文的測試案例所使用的SAP HANA版本爲SAP HANA SPS10]
想獲取更多SAP HANA學習資料或有任何疑問，請關注新浪微博@HANAGeek！我們歡迎你的加入！
請勿用於任何商業用途。
大家好，在這篇文章裏，筆者將和大家分享如何自定義SAP HANA登陸界面背景。過程很簡單，只需三步即可完成。在SAP HANA SPS08裏面，我們是不能修改登陸界面背景的。所以，每次訪問XS應用的時候，一直會看到如下的登陸界面。
那麼在SAP HANA SPS09裏面，首先默認的登陸界面改成了如下十分簡潔的藍色主題。同時，從SAP HANA SPS09開始，也提供給用戶修改背景的能力，用戶可以使用任意圖片。 
讀者可以從 SAP HANA XS Configuration Parameters - SAP HANA Administration Guide - SAP Library 獲取相關的信息，如下圖所示。
第一步：上傳圖片並且設置權限
首先需要明確一點，對於單個SAP HANA實例來說，所有XS應用的登陸界面都是相同的。這也就意味着背景圖片和你的XS項目是沒有關係的，應該放在一個全局的地方，比如官方文檔中推薦的"/sap/hana/xs/ui/Image.jpg"。爲了簡化操作，筆者使用了自己的一個XS項目。
可能大家已經注意到在官方文檔中有一個必要條件"No requirement for authentication and authorization"。所以，我們必須先設置該圖片爲公開權限，就是不需要登陸就能訪問的權限。那麼，通過修改.xsaccess文件就可以做到，具體爲修改authentication字段爲null。
.xsaccess
第二步：配置xsengine.ini -> httpserver -> login_screen_background_image
如下圖所示，設置login_screen_background_image參數爲圖片存放的路徑
第三步：設置technical用戶
創建一個technical用戶，比如“_USS”，然後賦予其"sap.hana.xs.selfService.user.roles::USSExecutor"角色
將該用戶賦給"/sap/hana/xs/selfService/user/selfService.xssqlcc"
大功告成！隨便訪問一個XS應用來測試一下吧！
想獲取更多SAP HANA學習資料或有任何疑問，請關注新浪微博@HANAGeek！我們歡迎你的加入！
轉載本文章請註明作者和出處，，請勿用於任何商業用途。
本文英文版
大家好，新年快樂！
每逢新春佳節，我們都會發一些新年祝福語給家人、朋友和同事，最常見的就是新年快樂，恭喜發財之類的，當然也會收到許多別人的祝福。筆者自從有了手機，每年除夕都會做這件事情，不發的話總感覺缺了點什麼。衆所周知，SAP HANA有文本分析功能，春節在家閒着無聊，一個念頭閃過，SAP HANA可以分析新年祝福語嗎？筆者做了一些測試，均以失敗告終，但是好消息是我們可以在SAP HANA文本分析裏面做定製化，從而讓SAP HANA能夠識別和分析新年祝福語。在本文中，筆者將和大家分享如何在SAP HANA裏面定製化文本分析，讓SAP
HANA爲我們送上新年祝福。
有趣的爭論，到底哪種羊？
在我們切入正題之前，讓我們先看一個有趣的爭論。大年初一當筆者打開Chrome的時候，出現了下面的Google doodle，呵呵，Google也和我們一起慶祝農曆新年。
不過現在已經看不到這個Google
doodle了，如果大家還想回味一下的話，可以訪問 Lunar
New Year 2015 和 Google
Doodle Rings in Chinese Lunar New Year. 那麼有趣的爭論到底是什麼呢？大家知道，今年是羊年，中國人就叫羊年，可是老外弄不明白了，到底中國的羊年是哪一種羊呢？到底是公羊(Ram)、綿羊(Sheep)還是山羊(Goat)？哈哈，詳見 Whatever
Floats Your Goat: The 2015 Lunar New Year Animal Is Up For Debate : Code Switch : NPR
來自SAP HANA的祝福 - 定製化文本分析EXTRACTION_CORE
我們將在該節討論如何通過定製化文本分析EXTRACTION_CORE來收到SAP HANA的祝福。首先，讓我們看一下在沒有定製化的情況下會發生什麼。本文所有測試都基於 SAP HANA SPS 09 Rev. 91。
- DROP SCHEMA TA CASCADE;
- CREATE SCHEMA TA;
- SET SCHEMA TA;
- CREATE COLUMN TABLE TA_TABLE (
- ID INTEGER PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
- CONTENT NVARCHAR(200),
- LANG NVARCHAR(2)
- );
- INSERT INTO TA_TABLE (CONTENT, LANG) VALUES ('新年快樂', 'ZH');
- INSERT INTO TA_TABLE (CONTENT, LANG) VALUES ('恭喜發財', 'ZH');
- CREATE FULLTEXT INDEX TA_INDEX ON TA_TABLE (CONTENT)
- CONFIGURATION 'EXTRACTION_CORE'
- LANGUAGE COLUMN LANG
- TEXT ANALYSIS ON;
- SELECT * FROM "$TA_TA_INDEX";
通過上面的SQL語句，我們首先建了一張帶有語言字段(LANG)的原始表，接着插入了兩條祝福語，新年快樂和恭喜發財，然後我們創建了一個全文索引來做文本分析，該全文索引基於原始表中的CONTENT字段，配置爲EXTRACTION_CORE。大家可以從 Text Analysis - SAP HANA Text Analysis Developer Guide - SAP Library找到目前所有可用的配置。下圖是我們查詢文本分析的結果表，大家可以從 Structure of the $TA Table - SAP HANA Text Analysis Developer Guide - SAP Library 找到所有列的解釋。從圖中可以發現，SAP HANA沒有解析出任何內容，原因很簡單，因爲在SAP HANA預先定義的 predefined entity types 裏面沒有GREETING。
那麼我們現在可以做什麼呢？我們可以從 SAP HANA Text Analysis Extraction Customization Guide - SAP Library 中找到答案，該文件展示瞭如何定製化文本分析的解析。這裏還有一個視頻詳細介紹了該方法 SAP HANA Academy - Text Analysis: 10. Custom Dictionaries - YouTube 下面就讓我們自己來一步步實現。
步驟一：創建XS項目
步驟二：創建.hdbtextdict文件，即自定義詞典。在該文件中，我們可以定義自己的 TA_TYPE(entity_category) 和 TA_TOKEN(entity_name)。比如，我們定義了"GREETING"這個entity_category, 定義了"新年快樂"和"恭喜發財"這兩個entity_name。
GREETING.hdbtextdict
- <?xml version="1.0" encoding="UTF-8"?>
- <dictionary xmlns="http://www.sap.com/ta/4.0">
- <entity_category name="GREETING">
- <entity_name standard_form="新年快樂">
- </entity_name>
- <entity_name standard_form="恭喜發財">
- </entity_name>
- </entity_category>
- </dictionary>
步驟三：創建.hdbtextconfig文件，即自定義配置。在該文件中，我們需要引入步驟二中的.hdbtextdict文件。本例中，我們複製了SAP HANA標準的 EXTRACTION_CORE (sap.hana.ta.config::EXTRACTION_CORE)，然後引入我們的自定義詞典。
EXTRACTION_CORE_CUSTOM.hdbtextconfig
- ...
- <!-- List of repository objects containing Text Analysis extraction dictionaries. -->
- <property name="Dictionaries" type="string-list">
- <string-list-value>TACustom::GREETING.hdbtextdict</string-list-value>
- </property>
- ...
步驟四：使用步驟三中的自定義配置來創建全文索引。
- DROP FULLTEXT INDEX TA_INDEX;
- CREATE FULLTEXT INDEX TA_INDEX ON TA_TABLE (CONTENT)
- CONFIGURATION 'TACustom::EXTRACTION_CORE_CUSTOM'
- LANGUAGE COLUMN LANG
- TEXT ANALYSIS ON;
- SELECT * FROM "$TA_TA_INDEX";
如下圖所示，現在我們可以收到來自SAP HANA的祝福啦。
當然，除了這兩個祝福語之外還有許許多多祝福語，用戶可以豐富自己的自定義詞典，即.hdbtextdict文件.
來自SAP HANA的情感 - 定製化文本分析EXTRACTION_CORE_VOICEOFCUSTOMER
我們知道SAP HANA文本分析中最強的武器是情感分析。現在我們已經得到了SAP HANA的祝福，那麼對於這些祝福，SAP HANA又會分析出什麼情感呢？出於好奇，筆者嘗試了英語和中文兩種語言，下面就讓我們一起來看一下。
- INSERT INTO TA_TABLE (CONTENT, LANG) VALUES ('Happy new year', 'EN');
- INSERT INTO TA_TABLE (CONTENT, LANG) VALUES ('Congratulations for prosperity', 'EN');
- SELECT * FROM TA_TABLE;
首先，筆者在原始表中添加了兩條英語祝福，和我們原先兩條中文祝福對應。 "新年快樂" 對應 "Happy new year", "恭喜發財" 對應 "Congratulations for prosperity"。 然後我們這次創建配置爲 "EXTRACTION_CORE_VOICEOFCUSTOMER" 的全文索引，讓SAP HANA來做情感分析。
- DROP FULLTEXT INDEX TA_INDEX;
- CREATE FULLTEXT INDEX TA_INDEX ON TA_TABLE (CONTENT)
- CONFIGURATION 'EXTRACTION_CORE_VOICEOFCUSTOMER'
- LANGUAGE COLUMN LANG
- TEXT ANALYSIS ON;
- SELECT * FROM "$TA_TA_INDEX";
從如下的分析結果，我們可以發現SAP HANA從兩條新插入的英語祝福語中成功分析出了情感，但是原先的兩條中文祝福語卻沒有分析出情感。深入分析的話，SAP HANA在兩條英語祝福語中分析出了具體是哪種情感(紅框標註)和情感所形容的具體主題。另外還可以發現在 SAP HANA SPS09中有一個改進，那就是TA_PARENT字段。有了這個字段，我們可以非常方便的綁定情感和主題。那麼下面讓我們來具體看一下。
- 對於 "Happy new year", "Happy" 是一個弱正面情感(weak positive sentiment)。然後爲什麼快樂呢？爲新年 "new year"。
- 對於 "Congratulations for prosperity", "Congratulations" 也是一個弱正面情感(weak positive sentiment)。然後恭喜什麼呢？恭喜發財 "prosperity".
看起來SAP HANA完美支持了英語的情感分析，那麼對於中文呢？別擔心，我們依舊可以像在上節中定製化EXTRACTION_CORE一樣來定製化EXTRACTION_CORE_VOICEOFCUSTOMER。因爲中文是一種非空格語言(non-whitespace language), 我們需要查看 Sentiment Analysis Customization in Nonwhitespace Languages。那麼我們想讓SAP HANA也分析出來和英文類似的結果。
- 對於 "新年快樂", "新年" 等同於 "new year"， "快樂" 等同於 "happy"。
- 對於 "恭喜發財", "恭喜" 等同於 "congratulations"， "發財" 等同於 "prosperity"。
那麼，讓我們來嘗試一下。
步驟一：創建自定義詞典，即.hdbtextdict文件。該文件的XML結構和上節的 GREETING.hdbtextdict相同。但是在情感分析中，我們只能使用如下五種entity_category:
- CustomTopic
- CustomPositive
- CustomNegative
- CustomNeutral
- CustomProblem
GREETING_VOC.hdbtextdict
- <?xml version="1.0" encoding="UTF-8"?>
- <dictionary xmlns="http://www.sap.com/ta/4.0">
- <entity_category name="CustomTopic">
- <entity_name standard_form="新年">
- </entity_name>
- <entity_name standard_form="發財">
- </entity_name>
- </entity_category>
- <entity_category name="CustomPositive">
- <entity_name standard_form="快樂">
- </entity_name>
- <entity_name standard_form="恭喜">
- </entity_name>
- </entity_category>
- </dictionary>
步驟二：創建自定義配置，即.hdbtextconfig文件。和上節的.hdbtextconfig文件類似，我們先複製SAP HANA標準配置EXTRACTION_CORE_VOICEOFCUSTOMER (sap.hana.ta.config::EXTRACTION_CORE_VOICEOFCUSTOMER) 然後引入我們的自定義詞典。
EXTRACTION_CORE_VOC_CUSTOM.hdbtextconfig
- ...
- <!-- List of Text Analysis extraction dictionaries for Sentiment Analysis. -->
- <property name="Dictionaries" type="string-list">
- ...
- <string-list-value>TACustom::GREETING_VOC.hdbtextdict</string-list-value>
- </property>
- ...
步驟三：使用步驟二中的自定義配置來創建全文索引。
- DROP FULLTEXT INDEX TA_INDEX;
- CREATE FULLTEXT INDEX TA_INDEX ON TA_TABLE (CONTENT)
- CONFIGURATION 'TACustom::EXTRACTION_CORE_VOC_CUSTOM'
- LANGUAGE COLUMN LANG
- TEXT ANALYSIS ON;
- SELECT * FROM "$TA_TA_INDEX";
雖然我們可以在TA_TYPE字段中找到 "CustomTopic" and "CustomPositive"，分析的結果不完全正確，分析結果不太滿意。我們需要的是類似英語的那種分析結果。那麼爲什麼分析結果會不同呢？原因是我們只定義了自定義詞典，但是對於情感分析來說還有其他因素，比如解析規則等。爲了簡便，我們可以在兩條中文祝福語中稍加修改來達到目的。
- INSERT INTO TA_TABLE (CONTENT, LANG) VALUES ('新年很快樂', 'ZH');
- INSERT INTO TA_TABLE (CONTENT, LANG) VALUES ('恭喜你發財', 'ZH');
- SELECT * FROM "$TA_TA_INDEX";
現在我們就可以發現和英文差不多的分析結果了。SAP HANA在兩條中文祝福語中都分析出了具體情感和主題。這就是我們想要的！
總結
在本文中，我們定製化了兩種SAP HANA文本分析的配置，EXTRACTION_CORE 和 EXTRACTION_CORE_VOICEOFCUSTOMER。通過對文本分析的定製化，我們在農曆新年收到了來自SAP HANA正面情感的祝福。
希望這篇文章對大家理解SAP HANA的文本分析有所幫助。祝大家新年快樂，恭喜發財！
想獲取更多SAP HANA學習資料或有任何疑問，請關注新浪微博@HANAGeek！我們歡迎你的加入！
轉載本文章請註明作者和出處http://scn.sap.com/community/chinese/hana/blog/2015/03/01/%E6%9D%A5%E8%87%AAsap-hana%E7%9A%84%E6%96%B0%E5%B9%B4%E7%A5%9D…，請勿用於任何商業用途。
什麼是SDI
SDI，即Smart Data Integration，是集成到HANA中的一個數據遷移和同步工具。通過SDI，我們可以用圖形化的方式對遠程數據源（如Oracle，DB2，Hive等）的數據做過濾、連接、類型轉換等操作，然後導入到HANA。
使用SDI要做的工作
- 啓動HANA的DP Server
- 安裝配置DP Agent
- 註冊DP Agent
- 註冊 Adapter
- 創建遠程數據源及虛表
- 創建並激活數據流圖
- 執行存儲過程
啓動HANA的DP Server
Data Provisioning Server是HANA的一個native進程，它與DP Agent或遠程數據源進行數據交互。DP Server是HANA自帶組件，不需要額外安裝，但默認情況下DP Server是disabled，所以我們需要將其enable。激活方法是：Configuration選項卡àdaemon.iniàdpserverà將instances置1
該屬性是change online，不需要重啓HANA。
DP Server啓動完成後可以在Services選項卡中看到dpserver的狀態爲active：
安裝配置DP Agent
1. 從SAP Software Download Center下載DP Agent安裝包“data_provision_agent_xxxxxxxx.zip”。
2. 解壓zip包，將其中的DATA_UNITS\HANA_DP_AGENT_10_LIN_X86_64文件夾copy到要安裝的linux機器上（當然你也可以安裝windows版的）。
3. 執行./hdbinst
輸入安裝路徑。
輸入用於DP Agent服務的用戶名、監聽端口和管理端口。
4. 進入DP Agent安裝路徑，運行配置工具：
5. 在彈出的對話框中點擊ConfigureàPreferences：
在DP Agent的配置界面，你可以配置Adapter Framework和各個Adapter的參數，Adapter Framework的參數適用於所有Adapter，比如Worker Thread Pool是線程池的容量，即並行導入的最大線程數。
註冊DP Agent
1. 運行DP Agent的配置工具：
2. 先要連接到一個HANA系統，點擊Connect to HANA
在彈出的對話框中填入HANA系統的鏈接信息，這裏既可以連接到On Premise的HANA，也可以連接到On Cloud的HANA。
3. 連接到HANA之後就可以看到現有的所有Adapter：
然後點擊Register Agent按鈕，彈出對話框：
點擊Register按鈕完成註冊，註冊成功後在HANA Studio中查看視圖"SYS"."AGENTS"：
可以看到”srsserverAgent”已經成功註冊到HANA系統。
註冊Adapter
DP Agent註冊成功後，還需要將要連接的遠程數據源對應的Adapter註冊到HANA系統。
1. 將要連接的數據源的JDBC驅動文件（例如Oracle的JDBC驅動文件ojdbc6.jar）拷貝到DP Agent安裝目錄的lib子文件夾下：
<DP_AGENT_INSTALL_DIR>/lib
默認爲：/usr/sap/dataprovagent/lib
2. 在配置工具界面的Adpaters列表中選擇遠程數據源的Adapter，例如，要連接Oracle則選擇OracleLogReaderAdapter，然後點擊Register Adapter按鈕。
3. Adapter註冊成功後，在HANA中查看視圖"SYS"."ADAPTERS"：
可以看到OracleLogReaderAdapter已經成功註冊到HANA系統。
創建遠程數據源及虛表
1. 創建SDI遠程數據源和創建SDA遠程數據源類似，在Adapter Name欄選擇遠程數據源對應的Adapter，例如連接Oracle則選擇OracleLogReaderAdapter。
2. 以Oracle數據源爲例，Instance Name是DP Agent中創建的實例名稱，你可以使名稱和數據源名稱一致，Administration Port是該instance的管理端口，默認是13456。
3. 創建虛表方法和SDA一致。
創建並激活數據流圖
1. 在repository或HANA XS project中新建一個數據流圖：
2. 使用拖拽的方式構建一個數據流圖：
可以選中各個節點，然後在其屬性框中設置其屬性，例如，JOIN節點的屬性框如下所示：
3. 保存並激活數據流圖：
執行存儲過程
1. 數據流圖成功激活後，我們在數據流圖所在的schema下可以看到生成了一個存儲過程：
2. 存儲過程內容如下：
CREATE PROCEDURE "SDI"."LEO.SDI::sdi_fg1"()
LANGUAGE SQLSCRIPT SQL SECURITY INVOKER
AS
BEGIN
ORCL_DS_TSTTAB_DATA_TAB = SELECT "ID", "NAME" FROM "SDI"."orcl_ds_TSTTAB";
ORCL_DS_TSTTAB_2_DATA_2_TAB = SELECT "ID", "NAME" FROM "SDI"."orcl_ds_TSTTAB";
SORT_OUTPUT_TAB=SELECT "ID", "NAME" FROM :ORCL_DS_TSTTAB_DATA_TAB ORDER BY "ID" ASC;
JOIN_OUTPUT_2_TAB = SELECT "INPUT1"."ID" AS "ID", "INPUT2"."NAME" AS "NAME_2" FROM(:SORT_OUTPUT_TAB AS "INPUT1" INNER JOIN :ORCL_DS_TSTTAB_2_DATA_2_TAB AS "INPUT2" ON"INPUT1"."ID"="INPUT2"."ID");
SELECT "ID" AS "ID", "NAME_2" AS "NAME_2" FROM :JOIN_OUTPUT_2_TAB INTO"SDI"."SORTED_JOINED_TSTTAB";
END
3. 調用該存儲過程即可完成數據導入。
參考資料
SAP HANA EIM Administration Guide
SAP HANA Academy – Smart Data Integration/Quality : SAP ECC Replication [SPS09]
想獲取更多SAP HANA學習資料或有任何疑問，請關注新浪微博@HANAGeek！我們歡迎你的加入！
轉載本文章請註明作者和出處http://scn.sap.com/community/chinese/hana/blog/2015/03/01/sdi%E7%9A%84%E9%83%A8%E7%BD%B2%E5%8F%8A%E7%AE%80%E5%8D%95%E4%B…，請勿用於任何商業用途。
簡介
SAP HANA XS從SPS06開始引入了XSJS outbound connectivity這個非常有用的特性。通過XSJS outbound connectivity，我們可以在SAP HANA原生應用中發起HTTP/HTTPS請求去獲取外部資源。這個特性使得SAP HANA和社交媒體的連接變成了可能，而且十分方便，我們可以從社交媒體上做很多有趣的分析。那麼在本文中，筆者將向大家展示如何使用XSJS outbound connectivity搜索微博。
筆者去年去美國出了一次差，那是第一次去美國，週末閒得無聊想去電影院看一場電影，一時興起用SAP HANA做了一個電影應用，然後用這個應用選了一部電影去看。這個應用的大致思路是從Twitter上爬取評價電影的微博，將其插入SAP HANA，然後使用SAP HANA自帶的文本分析功能來分析情感，進而進行評分。但是，去年那個時候SAP HANA還是SPS05版本，還沒有XSJS outbound connectivity功能，筆者只能用Twitter4J來連接Twitter API。要是那個時候有這個功能該多好啊！沒關係，現在用這個功能來搜索微博還爲時不晚，那就讓我們開始吧！本文將使用Twitter作爲例子，對於國內的讀者來說需要先翻牆。。。
準備工作
- 一個SAP HANA，至少SPS06版本，本文使用SAP HANA SPS08 Rev. 80
- 一個Twitter賬號
步驟
1.調查Twitter API
在第一步中，我們需要調查搜索微博需要使用哪個API，然後就是怎麼和Twitter API交互，認證啦，授權啦這些事情。首先你可以從這裏找到所有Rest API，我們想搜索微博，所以我們可以使用這個API，所有的信息都羅列的非常詳細了，包括URL，參數和例子。
那麼我們該如何調用這個API呢？可以從這裏找到答案。因爲我們只是搜索微博，所以我們可以使用Application-only authentication。從這個文檔裏面有一個包含三個步驟非常詳細的例子，這恰恰就是我們所需要的。這裏有一點需要注意，需要使用HTTPS來調用API v1.1，你可以從這裏找到該信息。
2.使用Postman來模擬調用API
在第一步中，我們已經知道了如何調用Twitter API，我們可以先用Postman來測試一下。當然有很多和Postman類似的工具，你可以自由選擇。所有步驟在這裏已經詳細描述，筆者在這裏只是用一些截圖總結一下。
a. 編碼API key和API secret
首先如果你沒有應用的話，你需要先創建一個應用。創建完應用，你可以在“API Keys”這個標籤下找到應用的<API key>和<API secret>。筆者已經重新生成了API key和API secret，所以下圖的API key和API secret已經作廢。
然後將<API key>:<API secret>編碼成Base64格式。你可以使用Base64 Decode and Encode - Online來完成。
b. 獲取bearer token
你需要先退出Twitter賬號，要不然會報錯"403 Forbidden: The server understood the request, but is refusing to fulfill it."，下圖的bearer token已經失效。
c. 用該bearer token測試GET search/tweets | Twitter Developers
測試成功，我們搜索帶有#SAPHANA的微博，得到了如下結果。簡單起見，我們只使用q這個參數。
3.設置SAP HANA使用HTTPS
截止到目前，我們已經成功使用Postman搜索了微博。爲什麼不用XSJS outbound connectivity來完成相同的事情呢？讓我們開始吧！由於從API v1.1開始必須使用HTTPS，我們需要做的第一件事情就是讓SAP HANA支持HTTPS訪問，但是默認是不行的，我們需要進行配置。你可以參照這篇文章來完成該步。當你完成了該步，你應該可以做如下兩件事情，如果不能說明沒有配置成功。
a. 可以成功訪問https://<hostname or IP>:43<instance number>/sap/hana/xs/admin/
b. 當你切換至“Trust Manager”標籤頁，沒有“No valid SAP crypto configuration”錯誤。
4.創建Twitter API的trust store
在該步驟中，我們需要創建Twitter API的trust store。同樣，你可以參照這篇文章來完成該步。你只需要修改一個地方，就是把https://api.github.com/換成https://api.twitter.com/。
5.使用XSJS outbound connectivity搜索微博
我們終於到了這步。因爲我們在前面幾步已經完成了相當多的準備工作，這一步對我們來說就簡單許多。我們只需要完成以下步驟即可，筆者是在SAP HANA Stuido裏面完成的，當然讀者也可以在Web IDE裏面完成。項目結構如下圖所示：
a. 創建XS項目
b. 創建.xsapp, .xsaccess和services目錄
c. 創建twitterApi.xshttpdest，編輯，保存，激活
description = "twitter api";
host = "api.twitter.com";
port = 443;
pathPrefix = "/1.1";
useProxy = true;
proxyHost = "proxy.pal.sap.corp";
proxyPort = 8080;
authType = none;
useSSL = true;
timeout = 0;
d. 在下圖紅框裏面編輯trust store，保存
e. 創建search.xsjs，編輯。從Application-only authentication | Twitter Developers，我們可以得知bearer token除非被註銷，要麼對於應用來說是一直有效的，所以我們不必每次都去獲取bearer token，我們可以直接在代碼裏使用bearer token。
var destination = $.net.http.readDestination("searchTweets.services", "twitterApi");
var client = new $.net.http.Client();
var request = new $.net.http.Request($.net.http.GET, "/search/tweets.json?q=%23SAPHANA");
request.headers.set('Authorization', 'Bearer AAAAAAAAAAAAAAAAAAAAADa7RAAAAAAAUhLkOYDVULCmK2KnNlce6dURp7Y%3Dp1ERxtaQ0IdJMAi1EdZLjT4GDt1ketu1DzzPjNqHTk');
var response = client.request(request, destination).getResponse();
$.response.status = response.status;
$.response.contentType = response.contentType;
$.response.setBody(response.body.asString());
f. 保存，激活所有文件
6.測試
現在我們就可以來測試XSJS outbound connectivity了。測試成功，發現有一條微博是“The only limitation is our imagination!”，是筆者很欣賞的一句話。
總結
在本文中，我們成功使用XSJS outbound connectivity來搜索微博。但是，我們並沒有將搜索到的記錄插入SAP HANA，當然這個是完全可以做到的。除此之外，我們還可以用XSJS outbound connectivity來調用其他Twitter API。
想獲取更多SAP HANA學習資料或有任何疑問，請關注新浪微博@HANAGeek！我們歡迎你的加入！
轉載本文章請註明作者和出處http://scn.sap.com/community/chinese/hana/blog/2014/12/02/%E4%BD%BF%E7%94%A8sap-hana-xs%E6%90%9C%E7%B4%A2%E5%BE%AE%E5%8D…，請勿用於任何商業用途。
在本文中，我們將和大家一起討論視圖及其授權，我們會用幾個例子向大家展示如何賦予視圖的權限以及什麼情況下我們需要使用“WITH GRANT OPTION”語句。
問題描述
- 有三個用戶，分別是用戶A，用戶B和用戶C，每個用戶擁有自己的schema
- 用戶A在自己的schema下面創建了表A，然後將表A的select權限賦予了用戶B
- 用戶B基於表A在自己的schema下面創建了視圖B
- 現在問題來了。用戶B可以將視圖B的select權限賦給用戶C嗎？那麼用戶C是否又能看到視圖B中的數據呢？
在回答這些問題之前，讓我們先在SAP HANA裏面做幾個實驗。本文的測試案例所使用的SAP HANA版本爲SAP HANA SPS8 Revision 80。
實驗一
步驟一：使用SYSYEM用戶創建三個用戶，分別是USER_A, USER_B和USER_C
CREATE USER USER_A PASSWORD Initial1;
CREATE USER USER_B PASSWORD Initial1;
CREATE USER USER_C PASSWORD Initial1;
步驟二：使用USER_A在自己的schema USER_A下面創建TABLE_A，然後將該表的select權限賦給USER_B
CREATE COLUMN TABLE USER_A.TABLE_A (ID INTEGER);
GRANT SELECT ON USER_A.TABLE_A TO USER_B;
步驟三：使用USER_B在自己的schema USER_B下面創建基於TABLE_A的視圖VIEW_B
CREATE VIEW USER_B.VIEW_B AS SELECT * FROM USER_A.TABLE_A;
步驟四：使用USER_B嘗試給USER_C賦予VIEW_B的select權限，但是失敗
GRANT SELECT ON USER_B.VIEW_B TO USER_C;
VIEW_B是USER_B創建的，那麼爲什麼USER_B不能給USER_C賦予VIEW_B的select權限呢？
原因很簡單。雖然VIEW_B是USER_B創建的，但是VIEW_B是基於TABLE_A的，而USR_C對於TABLE_A是沒有任何權限的。試想一下，如果USER_B成功運行了步驟四中的SQL語句，那麼權限將不復存在。因爲任何用戶都可以使用這種手段來看到任何表，比如該例中，USER_C就可以通過USER_B來創建視圖的方法讓其看到TABLE_A中的內容。
那麼有什麼辦法可以讓USER_C擁有VIEW_B的select權限嗎？有，而且十分簡單。我們只需要讓USER_A給USER_B說點什麼，比如：
“兄弟，你可以自己玩我的籃球（TABLE_A），如果你和其他人（USER_C）有籃球比賽（VIEW_B），你也可以用我的籃球。”
這意味着USER_A同意USER_B讓其他人一起玩USER_A的籃球。在這種場景中，我們就可以使用“WITH GRANT OPTION”了，這句語句允許被授權的人繼續授權給其他人。那麼，讓我們來試一下。
步驟五：使用USER_A重新給USER_B賦予TABLE_A的select權限，這次我們加上“WITH GRANT OPTION”
GRANT SELECT ON USER_A.TABLE_A TO USER_B WITH GRANT OPTION;
步驟六：使用USER_C成功查看VIEW_B
SELECT * FROM USER_B.VIEW_B;
實驗二
現在讓我們來看另外一個例子。在這個例子中，我們先讓USER_A把TABLE_A的select權限賦給USER_C，看看會發生什麼。
步驟一：使用SYSTEM創建三個用戶，分別是USER_A, USER_B和USER_C
CREATE USER USER_A PASSWORD Initial1;
CREATE USER USER_B PASSWORD Initial1;
CREATE USER USER_C PASSWORD Initial1;
步驟二：使用USER_A在自己的schema USER_A下面創建TABLE_A，然後將該表的select權限賦給USER_B和USER_C
CREATE COLUMN TABLE USER_A.TABLE_A (ID INTEGER);
GRANT SELECT ON USER_A.TABLE_A TO USER_B;
GRANT SELECT ON USER_A.TABLE_A TO USER_C;
步驟三：使用USER_B在自己的schema USER_B下面創建基於TABLE_A的視圖VIEW_B，並且將整個schema USER_B的select權限賦給USER_C
CREATE VIEW USER_B.VIEW_B AS SELECT * FROM USER_A.TABLE_A;
GRANT SELECT ON SCHEMA USER_B TO USER_C;
步驟四：使用USER_C嘗試查看VIEW_B，但是失敗
SELECT * FROM USER_B.VIEW_B;
這次爲什麼失敗呢？現在你可能有些困惑，你可能這麼認爲：
1.因爲USER_A把TABLE_A的select權限賦予了USER_C，所以USER_C應該可以查看TABLE_A。對，你說的沒錯。USER_C可以成功運行如下語句：
SELECT * FROM USER_A.TABLE_A;
2.因爲USER_B把自己整個schema USER_B的select權限賦給了USER_C，所以USER_C應該可以查看schema USER_B下面的所有對象。這個觀點正確嗎？從步驟四中的錯誤信息可以得出這個觀點是錯誤的。那麼錯在哪裏呢？
我們還是舉籃球的例子。
- USER_A對USER_B說，“USER_B，你可以玩我的籃球。”
- USER_A對USER_C說，“USER_C，你可以玩我的籃球。”
- USER_B對USER_C說，“USER_C，你可以一直和我一起玩籃球。”
如果USER_C和USER_B一起玩USER_B的籃球，那麼沒有任何問題。但是如果USER_B在玩USER_A的籃球，此時USER_C可以加入一起玩嗎？不行，因爲USER_A沒有同意USER_B讓其他人一起玩USER_A的籃球。這就是原因所在。那麼，我們還是需要使用“WITH GRANT OPTION”來解決該問題。
步驟五：使用USER_A重新給USER_B賦予TABLE_A的select權限，這次我們加上“WITH GRANT OPTION”
GRANT SELECT ON USER_A.TABLE_A TO USER_B WITH GRANT OPTION;
步驟六：使用USER_C成功查看VIEW_B
SELECT * FROM USER_B.VIEW_B;
實驗三
假設我們現在多了一個用戶USER_D。USER_C想在自己的schema USER_C下面創建一個基於VIEW_B的視圖VIEW_C，而且想讓USER_D查看VIEW_C。那麼我們應該運行哪些SQL來實現這個需求呢？大家可以把這個實驗當做課後練習，這裏我們就不具體解釋了，代碼如下：
--SYSTEM
CREATE USER USER_A PASSWORD Initial1;
CREATE USER USER_B PASSWORD Initial1;
CREATE USER USER_C PASSWORD Initial1;
CREATE USER USER_D PASSWORD Initial1;
--USER_A
CREATE COLUMN TABLE USER_A.TABLE_A (ID INTEGER);
GRANT SELECT ON USER_A.TABLE_A TO USER_B WITH GRANT OPTION;
--USER_B
CREATE VIEW USER_B.VIEW_B AS SELECT * FROM USER_A.TABLE_A;
GRANT SELECT ON USER_B.VIEW_B TO USER_C WITH GRANT OPTION;
--USER_C
CREATE VIEW USER_C.VIEW_C AS SELECT * FROM USER_B.VIEW_B;
GRANT SELECT ON USER_C.VIEW_C TO USER_D;
--USER_D
SELECT * FROM USER_C.VIEW_C;
總結
基於以上的實驗，我們現在來回答文章開頭的問題。
- 如果你的視圖是基於其他不是由你創建的對象，然後你想讓其他人能夠查看你的視圖，那麼你需要讓基於對象的擁有者在給你賦權限的時候加上“WITH GRANT OPTION”
- 另外，你擁有對整個schema的select權限並不意味這你可以查看這個schema下面所有的對象
同樣，你可以訪問SAP HANA開發者指南得到相似的答案 Object Privileges - SAP HANA Developer Guide - SAP Library，下面將其翻譯成中文。
“一些數據庫對象是基於其他對象的，比如視圖通常定義爲對其他表和視圖的查詢。對於有依賴對象操作的賦權需要對該對象和其所依賴對象的權限。對於視圖來說，SAP HANA實現了標準的SQL行爲。一個用戶擁有對一個視圖操作的賦權需要滿足如下兩點：
- 用戶被賦予操作該視圖的權限或者角色
- 該視圖的擁有者對於該視圖依賴的對象具有WITH GRANT OPTION賦權”
聲明：本文所介紹的視圖及其權限是一種通用的機制和原理，不僅僅適用於SAP HANA，其他數據庫同樣適用，比如Oracle。
想獲取更多SAP HANA學習資料或有任何疑問，請關注新浪微博@HANAGeek！我們歡迎你的加入！
轉載本文章請註明作者和出處http://scn.sap.com/community/chinese/hana/blog/2014/11/18/%E8%A7%86%E5%9B%BE%E5%8F%8A%E5%85%B6%E6%8E%88%E6%9D%83，請勿用於任何商業用途。
在上一篇博文SAP HANA 高可用性 (High Availability) 解決方案 (二) - Host Auto-Failover, 節點失效自動切換中，我們主要介紹了HANA高可用性方案中的故障恢復（Fault Recovery）的解決方案，接下來我們繼續探討另一不可或缺的部分，災難恢復（Disaster Recovery）。
HANA支持的災難恢復解決方案有下面三種：
- 備份：只是業界常用的方案，就是定期地對數據庫進行備份；（這部分內容在SAP HANA數據恢復技術（二）：數據庫備份和SAP HANA數據恢復技術（三）：數據庫恢復中有介紹）
- 存儲複製（Storage Replication）：就是持續地將主存儲的數據以鏡像的方式複製到遠端的備份存儲中去；（這部分內容在中SAP HANA分佈式系統及高可用性(一)有介紹）
- 系統複製（System replication）：需要創建備份系統（Secondary System），它會持續地從主系統（Primary System）同步數據和事務日誌；由於主輔系統的鏡像屬性，一旦主系統出現災難性的故障，我們就可以啓用輔助系統來代替主系統；
SAP HANA系統複製是一種既可以用來做錯誤恢復又可以用來做災難恢復的靈活的技術，從而達到高可用性的目的。
SAP HANA系統複製是用來解決主系統（Primary System）出現整個數據庫系統崩潰，包括硬盤損壞的場景。在這種情況下，SAP HANA利用備份系統（Secondary System）來接管主系統。在SAP HANA系統複製中，備份系統擁有自己的數據存儲，這些數據都是從原始數據複製過來的。
如上圖所示，備份系統與主系統擁有相同的配置和拓撲結構。這就意味着在主系統中，每一個活躍的有自己持久化層的服務器在備份系統中都有一個對應的服務器。對於每一對服務器而言，複製工作是這樣完成的：首先初始化，主系統響應請求，將一個數據快照傳送到備份系統中。從這個快照時間後主系統的所有改變都會被複制。主系統中的日誌在持久化時，主系統會將其發送到備份系統中。主系統中的一個事務直到被複制併發送到備份系統中後，纔會被提交。具體提交的時間點可以通過配置log replication mode來指定：
1. 硬盤同步模式（Synchronous on disk）：主系統中的事務直到收到日誌在備份系統中持久化到硬盤中的回覆後才被提交。這種模式保證的了兩個系統的即時一致性，代價爲數據傳輸時間和數據在備份系統中持久化的時間。
2. 內存同步模式（Synchronous in-memory）：主系統中的事務直到收到日誌在備份系統中被接收並存儲到內存中後才被提交。代價爲數據傳輸時間以及數據丟失的可能。
3. 異步模式（Asynchronous）：主系統的事務在發送日誌後被提交，不需要等待備份系統的回覆。此模式沒有延遲但是有數據丟失的可能。
如果備份系統連接丟失或者備份系統崩潰，主系統在一個可配置的時限後會恢復複製。備份系統會持久化收到的日誌，但是不會立刻回放日誌。爲了避免日誌的增長，增量的數據快照會被異步的傳輸到備份系統中。如果備份系統要進行接管，只需要回放最近數據快照的之後的日誌即可。當發生失效導致接管時，系統管理員操作備份系統將其從recovery模式轉換到全操作模式。接管後，備份系統會恢復到主系統重啓後的狀態並開始接受查詢。（系統在重啓後的狀態可能與重啓前狀態不同，例如load/unload以及import操作再重啓後可能會丟失）
SAP HANA 系統複製實施
前提準備
- 主系統和備份系統都被獨立地安裝並運行。
- 兩個系統中有同樣數量的工作主機。這樣就表示standby主機數量可以不一致。
- 系統複製不支持一臺主機上面有多個同類服務器（例如index server）
- 若是分佈式系統，所以配置步驟都要在master name server節點執行。
- 備份系統的軟件版本必須不小於主系統版本。
- 兩個系統必須有相同的System ID和instance number。
- 兩個系統需要有相同的.ini配置文件
- 兩個系統需要有不同的Hostname
建立SAP HANA系統複製步驟（通過hdbnsutil）
A. 配置主系統
1. 將log_mode屬性設爲“normal”，表示日誌區必須被備份；（備份系統也需要此設置）
2. 做一次初始化數據備份
3. 使主系統支持系統複製並且給主系統一個邏輯名字（使用<sid>adm用戶）：
cd /usr/sap/<sid>/HDB<instance_number>/exe
./hdbnsutil -sr_enable --name=<primary_logical_name>
B. 配置備份系統
1.使用<sid>adm關閉備份系統：
/usr/sap/hostctrl/exe/sapcontrol -nr <instance_number> -function StopSystem HDB
2. 向主系統註冊備份系統（remoteHost中若包含大寫字母，改爲小寫字母）：
cd /usr/sap/<sid>/HDB<instance_number>/exe
./hdbnsutil -sr_register --name=<secondary_logical_name> --remoteHost=<primary_host> --remoteInstance=<primary_instance_number> --mode=[sync|syncmem|async]
3. 啓動備份系統使之進入recovery mode
/usr/sap/hostctrl/exe/sapcontrol -nr <instance_number> -function StartSystem HDB
如果一切順利，則在主系統的landscape中看到下圖。
系統複製接管步驟（通過hdbnsutil）
1. 在備份系統使用<sid>adm執行接管：
cd /usr/sap/<sid>/HDB<instance_number>/exe
./hdbnsutil -sr_takeover
2. 若主系統修復成功，關閉主系統。
3. 註冊主系統爲新的備份系統然後啓動。
在新的主系統中可以看到兩系統角色交換。
建立SAP HANA系統複製步驟（通過HANA Studio）
A. 配置主系統
1. 初始化數據備份
2. 使主系統支持系統複製
3. 爲主系統設定一個邏輯名字；
B. 配置備份系統
1. 關閉備份系統，並向第一系統註冊；
2. 填寫相關參數，包括邏輯名，複製模式，主系統主機名等。然後啓動備份系統。
系統複製接管（通過HANA Studio）
右鍵點擊備份系統，選擇System Replication，選擇Perform takeover。
SAP HANA系統複製相關參數說明
對於不同的系統複製需求，可以調整相關參數，見下表。
|
配置參數 |
數據類型 |
單位 |
默認值 |
作用於系統 |
描述 |
|
datashipping_ min_time _interval |
int |
秒 |
600 |
Secondary |
備份（Secondary）系統兩次數據同步請求之間的最小時間間距。 如果datashipping_logsize_threshold參數先達到，就是logsize超過設定閾值，數據同步請求會先於最小時間間距所設定的時間點發出。 |
|
datashipping_ logsize_ threshold |
int |
bytes |
5*1024*1024*1024（5GB） |
Secondary |
備份系統兩次數據同步請求之間所累積的最小日誌量。 如果在datashipping_min_time_interval所設定的時間間距過完後，累積的日誌大小還沒超出設定的閾值，數據同步請求也會被觸發。（也就是說以上兩個參數不管哪個先達成，都會觸發數據同步請求） |
|
datashipping _snapshot _max_ retention _time |
int |
分 |
120 |
Primary |
完整地同步到備份系統的snapshot的最大保留時間。 之前同步到備份系統的snapshot只要超過這個最大保留時間就會被自動刪除。如果snapshot的數據傳輸在超過設定的最大保留時間後還沒完成，之前完成的部分並不會被刪除，也就是說只有完整的snapshot纔有可能被自動刪除。 如果此參數設爲0，snapshot在完成同步傳輸後會馬上被刪除。 |
|
preload_ column_ tables |
bool |
true/false |
true |
Primary和Secondary |
在主（primary）系統把此參數設爲true，那麼所有數據已加載到內存的表（loaded table）的相關信息都會被存放在snapshot中，然後同步到備份系統。 當備份系統也把此參數設爲true之後，備份系統纔會根據接收到的關於loaded table的信息來對相應的表執行數據到內存的預加載。 |
|
logshipping _timeout |
int |
秒 |
30 |
Primary |
主系統等待單個log buffer傳輸到備份系統的最長時間，如果同步日誌的請求發出後在此設定時間內沒響應，系統就會默認已經出錯，然後log buffer會被釋放，同時系統會結束該日誌同步的會話。 在備份系統與主系統的連接出錯的情況下，事務日誌只寫到主系統，日誌同步只能在連接正常後才能恢復。 如果參數enable_full_sync被設置爲true，主系統就會被阻塞（停止提交已執行事務）直到與備份系統的連接恢復正常。 |
|
logshipping_ async_buffer_size |
int |
bytes |
67108864 (64M) |
Primary |
在異步複製的模式下（async），負責寫日誌的線程將log buffer拷貝到一個過渡的內存buffer中，然後由另一個線程異步地從這個內存buffer中讀取log buffer並將其發送到備份系統。 此參數就是用來設置這個存放日誌的buffer空間究竟有多大；若產生日誌的速度遠高於發送日誌的速度，設定較大的log buffer就能較長時間地應對高峯期堆積下來未發送的日誌。 |
|
logshipping _async _wait_on _buffer_full |
bool |
bool |
true |
Primary |
此參數作用於異步複製模式下log buffer區存滿的情況。 如果此參數被設爲true，則主系統會一直等待直到log buffer有足夠空間存入新產生的日誌爲止；但是這樣做在高負載時有大量日誌堆積在log buffer區未被處理的情況下會讓主系統變慢。 如果此參數設爲false，主系統爲了不受影響會暫時關閉與備份系統的連接；高峯期過後備份系統會重新連上主系統，然後通過增量傳輸來完成同步。 |
|
reconnect _time_interval |
int |
秒 |
30 |
Secondary |
如果出現網絡故障而導致備份系統與主系統的連接中斷，備份系統會每隔一個時間段嘗試一次重連，這個參數就是用來設置這個重連時間段的長短。 |
|
enable _full_sync |
bool |
bool |
false |
Primary |
在此參數設爲true並且在同步（sync）的複製模式下，一旦備份系統與主系統的連接出現故障導致log buffer不能被髮送到備份系統，正在執行的事務會被阻塞。這樣做能保證在日誌不能被髮到備份系統的情況下，產生該日誌事務也不能在主系統完成commit。 |
SAP HANA系統複製測試
場景1：單主機系統，兩系統在相同配置的兩臺物理機上，使用內網光纖連接（網速62MB/s，穩定），插入（INSERT）測試。
|
Amount of records (million) |
Threads in parallel |
Executed time (second) |
|||
|
sync |
syncmem |
async |
No replication |
||
|
10 |
100 |
685 |
688 |
689 |
693 |
場景2：單主機系統，兩系統處於遠程連接（北京-上海）（網速1MB/s，不穩定），硬件相同，插入（INSERT）操作。
|
Amount of Transactions (million) |
Threads in parallel |
Executed time (second) |
|||
|
sync |
syncmem |
async |
No Replication |
||
|
1 |
10 |
208 |
212 |
131 |
128 |
通過以上兩個測試場景，可以看出在網速較高且穩定的網絡中，系統複製在插入事務中不會影響性能。而在遠程網絡環境中的系統複製，sync和syncmem模式會影響性能，而async模式可達到近似no replication的性能。
場景3：多主機系統（2workers+1standby），使用內網光纖連接，插入（INSERT）測試。
|
Amount of Transactions (million) |
Threads in parallel |
Executed time (second) |
|||
|
sync |
syncmem |
async |
No Replication |
||
|
10 |
100 |
1507 |
1511 |
1503 |
1496 |
通過測試可以看出對於分佈式的SAP HANA系統，在高速且穩定的網絡環境中，系統複製不會影響插入性能。
場景4：單主機系統，使用內網光纖連接，導入(IMPORT)測試。
|
Amount of records (million) |
Threads in parallel |
Executed time (second) |
|||
|
sync |
syncmem |
async |
No replication |
||
|
100(5.2G) |
80 |
|
22 |
22~46 |
|
場景5： 單系統主機，兩系統處於遠程連接（北京-上海），硬件相同，導入(IMPORT)測試。
|
Amount of records (million) |
Threads in parallel |
Executed time (second) |
|||
|
sync |
syncmem |
async |
No replication |
||
|
10（524M） |
25 |
486 |
471 |
465 |
9 |
根據以上兩個場景的實驗結果，在高速且穩定的網絡環境中，系統複製會影響Import操作的性能，在低速不穩定的網絡環境中，import操作性能遠遠低於無複製系統。
場景6：備份系統接管(Takeover)測試
單主機系統
多主機系統（2workers +1 standby）
根據測試結果，備份系統的接管與系統的數據量沒有關係，這是因爲備份系統的接管過程主要工作是回放上一次savepoint之後的redo log。
結論以及幫助
- 在網絡方面，根據測試結果，本地光纖連接與遠程公共網絡連接兩種網絡環境中，系統複製性能和穩定性相差很大，推薦使用獨佔的端到端高速網絡，並且該網絡使用隔絕其他網絡接入，加密，認證等安全措施。如果需要在遠程網絡進行系統複製，推薦使用async模式，如果系統有大量的import等高系統資源消耗的操作，建議先關閉系統複製，等操作結束後，可繼續進行系統複製。
- 根據測試結果如果網絡速度不是瓶頸的話，不同類型的複製同步模式對於普通事務來講有相近的性能。推薦使用sync模式，提供更高的安全性和穩定性。如果遠程、不穩定的網絡環境，則推薦使用async模式，以保證較高性能。
- 根據測試，接管時間是很穩定的，與HANA數據量關係不大。但是在初始化replication時，備份系統會將主系統的數據進行full replication，這段時間，備份系統使不可以接管的。
- 我們可以在多主機的SAP HANA系統中設置系統複製，與此同時，SAP HANA內部可以使用auto-failover 功能以得到更高的可用性。
- 同時我們也可以在備份系統的基礎上增加更多的系統複製以提高可用性。步驟與之前介紹一致，但需要注意，第三系統是以備份系統作爲主系統建立的系統複製，第三系統與備份系統之間只能使用async模式進行復制。
