Client Copy

Local Client Copy
-----------------------------
1. 使用SCC4 建立target client
2. 確認profile parameter "login/no_automatic_user_sapstar" = 0
使用sap*/pass登入target client
使用SCCL複製資料
3. 指定source client，選定customizing data, application data and user master records
4. 使用背景程式執行client copy

PS:
1.為了確保data consistency, 不要進入target client 操作，最好source client也不要使用
2.如果使用全新client，可以從cloent 000 複製過去
3. 如果要增進效能，可以從 (menu) Edit => Export Settings 排除tables or packages，關於Export Setting，可以參考Note 446485


Remote Client Copy
-------------------------------------
1. 步驟跟local client copy相同，只差在remote client copy是透過RFC傳送資料
2. 遇到問題請參考Note 557132
3. Remote client copy 另外可以參考Note 47502
4. 如果remote client copy複製all data，在過程中source client 的 table結構如果改變，remote client copy將會因錯誤而終止


Parallel Procesing
----------------------------------
1. 使用SCCL (local client copy) 或是 SCC9 (remote cloent copy)，接著在(menu) Goto => Parallel Processes 指定平行處理的數目
2. 平行處理無法用在client transports
3. 如果要定義RFC server group，使用SM59，RFC => RFC Groups，其他資訊可以參考Note 99284


Client Transport
--------------------------------
Client transport的功能跟local client copy and remote client copy相同，但是不使用RFC
client transport export:
1. 登入source client，使用SCC8，使用profile挑選要複製的資料
2. 指定target system，target system要在TMS中有定義的system
3. 因為執行時間可能會很久，需要使用背景程式跑

在export過程中，會call "tp" 非同步的將資料匯出:
RO<number>: 包含client-independent data
RT<number>: 包含client-specific data
RX<number>: 包含SAP script texts

即使是SCC8已經結束，也不代表export 完成，此時不要執行任何client copy的工具，可以使用SE01檢查export的狀態，並顯示request<SID>KT<NO>的log。
在export過程中，使用SCC3也得不到有用的資訊，因為執行R3trans的export 作業已經結束，反而會得到abort的訊息。

client transport import:
根據選取的client ransport profile 資料型態的不同，以下的client copt command file會被加到target system buffer:
<SID>KO<number>: 包含client-independent data
<SID>KT<number>: 包含client-specific data
<SID>KX<number>: 包含SAP script texts

使用STMS過版client transport request，完成後再登入到target client 使用SCC7做post-import activities。

使用SE09顯示client transport logs

在client transport過程中，使用SCC8的RFC system check按鈕可以check repository consistency。


Others
----------------------
如何複製large client可以參考Note 489690
估計client size大小可以執行程式RSTABLESIZE

SAP Note: 88346 - Changing the RFC destination if IP changes are made

Symptom

After you change the IP addresses of a host, the RFC destinations for which this host is defined as the target host no longer work.

Other Terms

RFC, destination, IP, DNS, host name, target host

Reason and Prerequisites

If you enter the host name (for example hs0311) as the target host when you maintain the RFC destination, the host name is stored internally in the database table RFCDES (for the destination administration) as its corresponding IP address. Among other things, this should reduce the time required to set up the RFC connection. As a result, the conversion of the target host name into its IP address is no longer required. Furthermore, the host name (as a Domain Name Server, among other things) can assume any length. This is not suitable for storage in the database table RFCDES.

This will create problems if the IP addresses of the target hosts are changed. After this action has been carried out, you must therefore amend the affected RFC destinations that use the IP addresses accordingly in transaction SM59.

Note:

• If you want to prevent the name of the target host from being stored as its respective IP address in the database table RFCDES, you must enter the host name as a SAP router name (/H/hs0311 instead of hs0311). In this case, the host name is stored as such in the database table RFCDES.

SAP Note: 403708 - Changing an IP address

Symptom

You want to change an IP address.

Other Terms

IP address, IP configuration, network, TCP/IP ,ipconfig

Reason and Prerequisites

This note provides information about configuring the operating system.

Solution

Internally, SAP systems use host names to communicate. As a result, you should experience no problems when you change an IP address.

Theoretically, you only need to make changes at operating system level:
- /etc/hosts
- /etc/services
- DNS entries
- Routing tables

However, you should err on the side of caution and check the following in the SAP system:
- Transaction SM59, table RFCDES, also see
  Note 88346 for additional information
- Transaction SM55, if you are using IP addresses here, you must adjust them
- Transaction SM51, check for consistent host names
- Transaction SMLG, check whether the entries for the server groups have been created with IP addresses

Also ensure that changes are not only made in the affected system but in all SAP systems, clients, and external programs that communicate with the affected system in any way.

Outside the SAP system:
- saprouter, adjust the saprouttab to the changes
* If the saprouter receives a new address:
  You should inform us of this change (for sapserv3).
  Open a message on the 'xx-ser-net-chg' component
  and inform us of the address change.
- Adjust the IP addresses so that the service connection continues to function
- If you use an APO system, see Note
  154997

Depending on your system landscape and configuration, additional
relevant points may be added. This note does not claim to be complete.

SAP BRSPACE Online Reorganizations

1. Which situations a table reorganization be useful ?

• Reduction of table size
• Cleanup of table fragmentation
• Change of table storage parameters (e.g. INITRANS)
• Move of table to a different tablespace
• Reduction of chained and migrated rows
• Reduction of number of allocated extents
• Transition from LONG to LOB columns (Oracle >= 10g)
• Reduction of hot spots on disk level
• Activation of Transparent Data Encryption
• Change of table structure

2. Which situations  a tablespace reorganization be useful ?

• Activation of LMTS
• Activation of ASSM
• Cleanup of freespace block corruption
• Reduction of database size
• Reduction of backup size
• Reduction of filesystem size
• Reduction of fragmentation
• Reduction of number of datafiles
• Increase of number of datafiles
• Transition to new tablespace layout
• Other change to tablespace layout
• Optimization of filesystem layout

3. How does a BRSPACE online reorganization work?

• Determination of CREATE commands for target table and indexes based on DBMS_METADATA.GET_DDL
• Creation of target table with naming convention <source_table>#$
• Export of source table CBO statistics based on DBMS_STATS.EXPORT_TABLE_STATS
• Copy of source table data to target table based on DBMS_REDEFINITION.START_REDEF_TABLE. This package will implicitly create a materialized view log MLOG$_<source_table> to track all changes that are performed on the source table while the reorganization is running.
• Creation of target indexes with naming convention <source_index>#$
• Import of source table CBO statistics to target table based on DBMS_STATS.IMPORT_TABLE_STATS
• Finalizing of the online reorganization using DBMS_REDEFINITION.FINISH_REDEF_TABLE. In this step all changes in the materialized log are applied to the target table and the names of source and target table are exchanged.
• The source table is dropped.
• The ?#$“ suffix of the target table indexes is removed.

4. What are the advantages of a BRSPACE Online Reorganization?

• It uses the advantages of DBMS_REDEFINITION:

          a. The reorganization can be performed in parallel to production operation.
              This means the table is accessible and records can be inserted / updated / deleted.

„          b. If anything goes wrong during the reorganization the source table still 

              exists unchanged and no restore / recovery is necessary.
          c.„ Compared to an offline reorganization via export / import all data has to be 

              copied only once and not twice

• „ It provides possibilities for client and server side parallelism in order to speed up the reorganization if sufficient system resources exist and the reorganization should finish within a specific time window.
• „ It has already proven to be a reliable reorganization tool at many customers.
• „ It performs a lot of useful activities implicitly that would require a lot of manual efforts and impose the risk of errors if DBMS_REDEFINITION is used directly.

5. What are the restrictions of a BRSPACE Online Reorganization?

• It is only available as of Oracle 9i.
• It cannot handle tables with LONG or LONG RAW columns. As of 10g it is possible to convert them during an online reorganization on the fly to LOB columns (if SAP >= 6.40 is used).
• Temporarily twice the space is needed because both source and target table and indexes exist in parallel.
• If a table has no primary key constraint (or no unique index with NOT NULL columns) a ROWID based online reorganization is necessary that requires overhead (ROWID index, ROWID column).
• The setup of the materialized view is an overhead that can negatively impact the performance of the reorganization of many very small tables.
• Structure changes on the source table and its indexes must not be performed during the reorganization (as they would be lost).

6. How is a normal BRSPACE Online Reorganization started?

• Table reorganization:

          brspace -f tbreorg -t <table_name>

• Tablespace reorganization:

          brspace -f tbreorg -s <source_tsp> -t "*" -n <target_tsp>

• Additional useful options exist, e.g.:

         a) -p <degree>

             => BRSPACE parallelism degree

         b) -e <degree>

             => PX parallelism degree

         c) -l <category>

             => Initial extent size category

         d) -i <target_ind_tsp>

             => Definition of target index tablespace (if different from target table tablespace)

7. Reference:

    Note 646681 and the BRSPACE online documentation.

SAP HANA 效應

原文連結：http://www.experiencesaphana.com/community/blogs/blog/2012/05/03/the-sap-hana-effect

翻譯原文連結：http://scn.sap.com/community/chinese/hana/blog/2012/10/22/sap-hana-%E6%95%88%E5%BA%94?source=email-cn-scn-newsletter-20121127

在最近的一次公開網絡研討會上，某位競爭對手由於缺乏對 SAP HANA 的了解，而對產業和金融分析師發表了有限的和不准確的理解。在 SAP 我們通常不對這種事情做出回應。但是這個戲劇化的事情的發生，讓我不禁思考：我們一定是做了很正確的事情！我是指，一個數據庫的領先和卓越的建設者怎麼可能根本不知道下一代數據庫技術呢？或者，僅僅因為他們不願意承認現實，所以才以訛傳訛？
        HANA 團隊對三件事有著同樣的激情 --HANA 客戶的成功，寓樂於工作，對現狀質疑。本著這一精神，我想代表 HANA 團隊，將我們的記錄設置在我們的競爭對手的一些不准確的信息上，這樣做本身也是十分有趣的。

SAP HANA 優勢

        一開始，我想指出的是： (A). 對過去的技術方法進行比較是完全沒有意義的。(B). HANA 的客戶都享受著不間斷的現代技術所帶來的非凡好處。(C). HANA 代表了企業計算環境中、特別是在數據庫技術的全新一代。這是一個為實時分析和應用而產生的現代的數據平台，它使組織能夠根 ​​據各種體積大而詳細的數據實時分析業務操作，它的存在消除了 OLTP 和 OLAP 系統之間的延遲和層，使它們成為 “真正的”實時系統。SAP HANA Advantage 是一個緊密集成的系統，不同的完全事務性的組件集成在系統優化器中。所有組件，如 OLTP ， OLAP （業務以及倉庫操作）都能無縫地工作，來進行向上和向外擴展文本、規劃和純應用程序的開發。在沒有服務器 zoo 、沒有內部複製、沒有物化聚合、更沒有堆棧引擎的情況下，它也可以方便地部署！
      在我下面的分析中，我會盡量精簡一些。我會定期更新這個博客，不斷為 SAP HANA 還原真相。修正如下：
#1 數據庫的未來設計中心
錯誤觀點:    內存 DBMS 無法替代所有或大部分關係型 DBMS 。
正確觀點：內存 DBMS 是數據庫的一個未來的設計中心。它已經取代絕大部分的數據庫市場 -- 尤其是分析，規劃，仿真和實時應用程序（例如：遊戲市場）。基於完善的學術研究，它能支持 OLAP 和 OLTP 。它在性能至上的市場中已經成為流行品。就像改變了雲以及事務處理的應用程序一樣，它將以同樣的方式將改變企業的市場。

#2 數據庫平台的作用
錯誤觀點：內存數據庫只能做一些事情，如 MOLAP ，運行報告，查詢和分析，規劃和預算編制，以及發現非結構化信息。
正確觀點： SAP HANA 在內存中的數據庫平台是一個通用的內存數據庫平台 — 它能帶來新的數據，捕捉交易與全面的 ACID 兼容性，當它們發生時分析它們，做數據庫處理，下放商業、預測和規劃的邏輯，它服務的客戶包括分析師、雲計算和移動應用程序。它的主流應用遠遠超過了小眾對數據庫的理解，你並不需要添加多種技術和或將一個 box 中的引擎複製為不同的用途。( 例： Endeca – text Essbase - planning, Times Ten - caching, analytics)。

#3 數據量增加而向外擴展與NUMA 支持
錯誤觀點： SAP HANA 對數據市場和數據倉庫的支持有限，因而不能向外擴展。
正確觀點： SAP HANA 可以擴展到無限數量的內核 / 節點，而硬件價格在不斷下降。去年五月，在我們的 SAPPHIRE NOW 大會， Hasso 已經使用 SAP HANA 展示了 32 個節點 / 1000+ 核心（在他講話的第 13 分 45 秒）。順便說一句，我們在世界各地已經運行了 3 個像這樣的 1000 + 的核心系統。我們有多節點向外擴展系統的現場客戶和幾個合作夥伴，包括 IBM ， HP ，應用範圍早已向外擴展。
此外，我們最近在 100TB 的基准上運行了 16 個節點的 IBM 的 X5 服務 ​​器。每個服務器都有 0.5 TB 的主存，並能在業務報告情況下，使用 300-500 毫秒處理 100TB 的數據倉庫， 800 毫秒 -2 秒處理臨時分析查詢。此外，數據可以被交換成標準的的 HANA 機制，如過時的查詢。HANA 也支持 NUMA 架構。相反，在 Oracle Exalytics 上公共文件的限制為 1 TB ，他們已公開表示這方面的一個重要部分是用於放在一起的所有產品的工作內存（ Essbase+Endeca+TimesTen ）。

#4 OLTP & OLAP
錯誤觀點：“ SAP HANA 寫入性能有限。”
正確觀點：對於 OLTP+ OLAP 而言， SAP HANA 在單一硬件和單一操作系統上是一個單一的基礎，它能向上和向外擴展（從小型到 1000 + 核心的多個節點之間），也會因工作負載而動態地調節。只有我們在內存中的數據庫中插入了一個高寫入性能和高分析性能的柱狀存儲。這是 SAP HANA 的一個關鍵的差異化。

#5 存儲方式 – 行、列、文本
錯誤觀點： SAP HANA 不支持非結構化的數據，也不提供行和列的壓縮。
正確觀點： SAP HANA 可以在一個數據庫中存儲行、列以及文本， 它本身就支持非結構化數據的存儲。因為這些都整合在一起了，所以就簡化了各個不同的存儲器中的事務以及分析操作。事實上， SAP HANA 就是在非結構化基礎上建立起來的。它能處理在結構數據上的標準搜索、文本挖掘、以及類文本的搜索。SAP HANA 中也將包含 Inxight 技術在語言上的功能，如標籤，特徵提取，實體提取和情感分析。Inxight 在市場上是最好的文本分析軟件。SAP HANA 支持大量壓縮的列存儲。行存儲並不需要大量壓縮，因為它只被用做壓縮列和不相關的表格的緩衝器而已。

＃6 數據緩存和查詢優化
錯誤觀點： SAP HANA 和 TimesTen 都能做數據緩存。
正確觀點：上一代的數據庫使用緩存來提高性能。HANA 是基於一個新的建築範式上的一個純內存數據庫。既然整個數據庫都在 HANA 中，你就不用再緩存數據。SAP HAHA 有一個世界頂級的查詢優化器，本身就允許大規模的平行查詢執行，包括內部和外部運營的平行操作。

＃7 ：ACID 性質和交易的完整性
錯誤觀點： SAP HANA 不具有“事務完整性 / 正確性”，缺乏“多版本並發控制（ MVCC ）”。
正確觀點： SAP HANA 是完全符合 ACID 的，我們使用永久性存儲系統來保證備份和持久性。SAP HABA 的並發性很完整，它有著例如語句級和快照隔離的常規功能的。

＃8 ：聚合和物化視圖
錯誤觀點：你需要聚合數據的物化視圖取得高性能。
正確觀點：又是一個！就像電動車不需要火花塞一樣，內存中詳細數據瞬時聚合性能高得多。聚合是過時的技術，因為需要耗費大量精力來創建，存儲冗餘和管理變化。SAP HANA 並不需要像傳統數據庫那樣上性能指標，鑑於它所有的部分都存在在內存中，面對所有尺寸的數據，它能將自己的行為設置成就像一個索引一樣。

＃9 ：商業智能客戶端
錯誤觀點： SAP HANA 只對一些 BI 客戶端提供有限的支持。
正確觀點： SAP HANASAP 已經優化 Business Objects 的運行。此外 _ 如今眾多 _ 第三方客戶端已成為可能（如 Tableau ， TIbco Spotfire ），我們將繼續在 SAP HANA 上向第三方 BI 客戶端完全開放。

#10 ：規劃應用程序和分析功能
錯誤觀點： SAP HANA 為規劃和預算編制程序提供了很有限的支持。
正確觀點： SAP HANA 為規劃程序提供了完整的支持，有相當多的 SAP 企業績效管理程序可以運行在 SAP HANA 上。SAP HANA 在數據庫中有本地規劃支持 與規劃引擎。類似於分解聚合、複製和其他的操作符是 SAP HANA 中關係代數的一部分。此外，我們支持 SAP 數據庫內自帶的規劃語言 FOX 。
規劃是 SAP HANA 一個巨大的參數 — 而不是其他方式。SAP HANA 不需要標準多維立方體（ cube ）操作，因為我們都是瞬時計算。SAP HANA 的庫包含了主要的分析和商業功能，例如數學函數、貨幣轉換、單位轉換、異動加權、時間序列分析、層次處理和預測函數，並且還對其他庫提供了擴展支持。有了運行在 HANA 上的 SAP BW ，我們沒有層；我們把規劃計算下放到 HANA 數據庫層來實現高性能。SAP HANA 將支持所有事務應用、商業倉庫、 BI 和所有 SAP 雲應用程序。我們也有第三方合作夥伴開發內置於 SAP HANA 中的規劃應用程序。

#11 ：運營報表和數據源
錯誤觀點： SAP HANA 對使用複制和 ETL 技術的運營報表能力有限，由於“有限的數據源”。
正確觀點： SAP 擁有非常好的對於不同數據源（如 SAP CO-PA 加速器）的實時運行報表解決方案；其中很多都是非 SAP 程序數據源。SAP 數據服務和 SAP Sybase 複製服務器是市場領先的 ETL 和復制技術，可以從非 SAP 和 SAP 數據源加載數據。HANA 具有極高的插入率，由於大規模並行的批量機制，它支持所有的數據源，並且測試表明數據傳入 SAP HANA 的速度為每小時 2TB 。

#12 ：價格
錯誤觀點：“ SAP HANA 比Exalytics 貴上 5 至 50 倍”。1TB HANA H/W 價格為 36.2 萬美元， SAP HANA 軟件收費 375 萬美元。
正確觀點：對於 1TB 存儲，我們對 H/W 期望價格為 40 至 60 萬美元（並非 36.2 萬），而軟件也遠沒有這裡說的那麼貴。SAP HANA 也針對不同市場提供了不同的價格。
價格範圍從小型業務（例如，單個 H/W 節點為 1.2 萬美元 +2 萬美元的 SAP B1 Analytics ON HANA ）到大於 100TB 內存的超大型業務場景。客戶也可以為單個應用程序 (BW, BPC, CO-PA, Smart Meter Analytics 等 ) 購買 SAP HANA ，或者數據集市和數據倉庫。對於 40TB 的數據倉庫， BW on HANA 是很有競爭力的。另外， HANA 價格也包括了客戶所需要的一切 – 測試、開發和 QA 環境環境和支持。無需為數據加載和移動、存儲加速（如 Exadata ）購買其他軟件。綜上這些 - 對於一個 512GB 使用配置， SAP HANA 總價比對手產品的價格大約低 50% 。

#13 ：標準和開放性
錯誤觀點：“ HANA 只能同 SAP 工具使用，只有有限的甚至非標準的 SQL 。”
正確觀點：大多數客戶使用 HANA 處理非 SAP 數據和用例 – 同時是 SAP 和非 SAP 應用程序的用例。工作在標準的 SQL 和 MDX ，並且對每個應用都有標準接口，對每一層都是開放的：
·         開放選擇 H/W 供應商，在競爭對手前選擇為市場帶來新的芯片級的創新。
·         開放選擇 BI 客戶端。
·         開放選擇所有應用程序和平台。
·         有數以百計的在 SAP HANA 上的自定義（非 SAP ）應用程序正在開發。
舉個例子， Oracle 應用程序和 Oracle BI 無需做任何改變，即可運行在 SAP HANA 上。已有的 Oracle 存儲過程將因知識產權原因翻譯成 SQLScript ，展示了 SAP HANA 的完全開放性。

#14 ：磁盤中的 SAP HANA
錯誤觀點： SAP HANA 不支持數據存儲至磁盤中。
正確觀點： SAP HANA 通過使用優先級技術，例如最近最少使用（ LRU ）支持數據存儲磁盤。SAP HANA 可以將相關數據放在內存中，而來自磁盤的數據則根據需要加載。

#15 ：查詢速度
錯誤觀點： SAP HAN 執行查詢的速度不比其他數據庫快。
正確觀點： SAP HANA 將所有數據以整數格式列式存儲，並且利用了最新的 intel 創新技術，如向量運算的 CPU 開發優化。SAP HANA 下一代架構以及芯片級的創新使其快於市場上任何一家競爭對手數據庫。舉個例子，我們有 4 個客戶使用了 SAP HANA 後，業務流程提升了 10 萬倍。領先的是 MKI ，其零售、物流數據分析提升了 40.8 萬倍。

#16 ： SAP HANA 運行比 Exadata 和 Exalytics 慢。
錯誤觀點：“ SAP HANA 跑的沒有 Exadata 快，更別提 Exalytics ”。
正確觀點：在一個客戶架構的例子中， SAP HANA 對信用檢查和信用額度驗證業務流程，使用同樣數據和查詢語句比 Oracle Exadata 快 1.5 萬倍。該實時性能是比較了事務中多個冗餘沙箱、分析、內存加速和文本處理得出的，由於在他們架構中有固有延遲。我們已經在幾個客戶發現了這個現象，這裡只舉出一個作為例子。

目前市場上的方式：

SAP HANA 使用的新方式：

#17 ：安裝和實施經歷
錯誤觀點： SAP HANA 需要幾天去安裝，而實施則需要幾月甚至幾年。
正確觀點： SAP HANA 在數據中心安裝只需幾分鐘至一小時。事實上，很快你就能從我們合作夥伴或者云上安裝。Provimi 的利潤分析僅用了 3 個星期就上線了。

#18 ：考勤和差旅
錯誤觀點：如果沒有顯著系統開銷，數據庫很難展示基於時間的報表。
正確觀點：你可以使用 SAP HANA 對你的報表時間遍歷（例如，比較實際天數和預測天數），以及比如使用滑動瀏覽時間軸，而報表則瞬時生成，無需存儲另外的指標或者視圖。

總結

我列舉了這些事實，以期你能了解 SAP HANA 背後的真相。SAP HANA 的表現打亂了原本安靜的傳統數據庫市場，開創了集 OLTP+OLAP 於一個硬件和一個操作系統，可以運行在小至微型機，大至 1000+ 內核的服務器集群中的先河。其技術定義和我們真正關心的屬性交叉在一起，例如，
1. 1. 爆炸式數據量（是的，隨著你的發展而調節、與磁盤存儲一起工作）。
2. 2. 多結構數據（是的，包括文本和機器數據）。
3. 3. 對新鮮數據的實時分析（是的，實時）。
4. 4. 高速互動（是的，以人類思考的速度）。
5. 5. 無需調優數據庫（是的，更簡單更便宜）。
以上這些提供了性能上進行改進的順序。SAP HANA 通過重新改革公司的客戶互動、財務和供應鏈性能，為全世界的公司帶來了巨大商業貿易以及競爭優勢。農夫山泉（ Oracle 數據庫提升了 2.2 萬倍性能）正在停用 Oracle 。
我們也在開創新的領域，例如醫藥行業中，重新改革基因組分析或者為全世界帶來貿易和實時銀行分析，以及我們這個時代的其他一些大挑戰。時間正召喚我們追趕新的地平線，世界不只是過去的增加，更是我們可以創造的更美好的事物。人生苦短，我們不應被這些謠傳阻止前進步伐。