This is the SAP Release Note for SAP HANA Database Maintenence Revision 102.01 of the SAP HANA platform software Support Package Stack (SPS 10).

The DSP (Datacenter Service Point) phase of SAP HANA SPS 10 started with Revision 102 and can be used by customers running SAP HANA in production environments.
Past this Datacenter Service Point point, SAP strongly recommends allways using the latest SAP HANA Maintenence Revision of the same Support Package Stack, available on SAP Service Marketplace.

Please refer to the SAP HANA Revision and Maintenance Strategy document on SAP Service Marketplace for an overview regarding the SAP HANA revision and maintenance strategy.

For details about the SAP HANA revision and maintenance strategy and recommended upgrade paths between SAP HANA Revisions, Support Package Stacks, Maintenance Revisions and Datacenter Service Points, see “SAP Note  2021789: SAP HANA Revision and Maintenance Strategy“.

Please refer also to the following SAP Notes:

• 2165826: SAP HANA Platform SPS 10 Release Note
  This is the central entry point for all information around SAP HANA Platform Support Package Stack (SPS 10), the comprised SAP HANA Revisions and subsequent SAP HANA Maintenance Revisions.

• If you upgrade to this Revision and you’re using SAP BW on HANA, please check the ABAP-related notes which can be found in the attachments of this note.

Installation/Upgrade

• Before you start the upgrade from Revision 64, 65, and 66. Please check out SAP Hot News Note 1918267.
• As part of the installation or the upgrade to Revision 101 or higher, the master key of the secure store in the file system (SSFS) is changed from the initial default key to an installation-specific individual key. Please check out SAP Note 2183624. To change the master key of SSFS of the hdbuserstore, please see also SAP Note 2210637.
• Please check “SAP Note 1948334 : SAP HANA Database Update Paths for Maintenance Revisions” for the possible update paths from Maintenance Revisions to SPS Revisions.
• If you upgrade from a Revision prior to SPS 06, first upgrade your system to the latest SPS 06 Revision (Revision 69.07) before upgrading to this Revision.
• If you encounter a problem during the upgrade phase “Importing Delivery Units”, please check out SAP Note 1795885.
• If you are using SAP HANA live, please check Release Note 1778607 before you start upgrading to SPS 10.
• Before you start the upgrade to this Revision, please check out SAP Note 2159899 – Release Notes for SAP HANA Application Lifecycle Management for SAP HANA SPS 10.
• In order to run the SAP HANA Database Revision 80 (or higher) on SLES 11, additional operating system software packages are required.
  Before you start the upgrade or the installation of Revision 80 or higher, please check out SAP Note 2001528.
• If the SAP HANA installation or one of its AFL plugins fails, please check out SAP Note 2183500
• If you encounter the problem: “HALM Process Engine: Data cannot be updated alert message”, please check out SAP Note2184376.
• If you get the issue that the Win8 HANA studio upgrade via update site failed, please check out SAP Note 2182779.
• For a troubleshooting guide for the SAP HANA platform lifecycle management tool hdblcm, please check out  SAP Note 2078425.

General

• With SAP HANA SPS 09, several inconsistencies in handling the data types double / float have been fixed. This leads to a change in the string representation of float / double data types. Please check out SAP Note 2092868.
• With SAP HANA SPS 09, several inconsistencies in handling the data types double / float have been fixed. This leads to a change in the string representation of float / double data types and may cause inconsistencies in concat attributes (such as primary keys, unique constraints) that contain float / double data type columns. Please check out SAP Note 2104798.
• As of Revision 93 the Embedded Statistics Server is the default setting. If you still running the old statistics server, the upgrade triggers the migration to the Embedded Statistics Server automatically. Please check out SAP Note 2091313 : HANA Statistics Server – changed standard setting of the statistics server as of Revision 94.
• Please note that when the Embedded Statistics Server is used, some program changes are required in the ABAP monitoring tools. See SAP Note 1925684 for details.
• If the recovery of data without using the backup catalog fails with incorrect syntax near “USING”, please check out SAP Note2157184.
• If you are using SAP Web Dispatcher as the HTTP load balancer, additional configuration is required. Please see SAP Note2146931 for details.
• If you have problems creating or modifying a user in the SAP HANA web-based development workbench, please check out SAP Note 2183760.
• If you are using the SAP HANA cockpit delivery unit “HANA_ADMIN Version 1.3.9”, the start, killing, and stopping of services do not work properly, even if successfully reported. Please check out SAP Note 2182831.
• Please note that the virtual table function is currently not supported on multitenant databases. Please check out SAP Note2182597.
• The version of libnuma1 (library for Non-Uniform Memory Access) delivered with SLES 11 SP1 up to version libnuma1-2.0.3-0.4.3 contains a bug which causes the name server to crash. Please check out SAP Note 2132504.
• You can find information about SHINE (SAP HANA Interactive Education) demo content in SAP Note 1934114.
• You can find documentation corrections information for the SAP HANA option Advanced Data Processing in SAP Note2183605.

The SAP HANA Troubleshooting and Performance Analysis Guide contains detailed information about tuning SQL statements.

Most frequently Used Commands For SAP HANA Administrators

Also see

Top 50 SAP HANA Interview questions and Answers

2. Which indications exist for critical SQL statements?

The following SAP HANA alerts indicate problems in the SQL are:

SQL: “HANA_Configuration_MiniChecks” (SAP Notes 1969700, 1999993) returns a potentially critical issue (C = ‘X’) for one of the following individual checks:

3. Which prerequisites are helpful for SQL statement tuning?

See SAP Note 2000000 for more information about an optimal SAP HANA performance configuration and useful prerequisites for performance and SQL statement optimization.

4. How can I identify a specific SQL statement?

Quite obviously a specific SQL statement can be identified by its SQL text. Due to the fact that the text can be quite long and there can be different similar SQL texts it is useful to identify a SQL statements based on a hash value that is derived from the SQL text. This hash value is called statement hash and can be found in column STATEMENT_HASH of SAP HANA performance views like M_SQL_PLAN_CACHE, M_EXPENSIVE_STATEMENTS or M_SERVICE_THREAD_SAMPLES.
The statement ID (column STATEMENT_ID) can’t be used for that purpose as it is based on a connection ID and not on a SQL statement text.

5. What is an expensive SQL statement?

An expensive SQL statement is a database access that shows high values in areas like:

• High execution time: Usually most important in the area of performance analysis are SQL statements with a particular high overall runtime. Usually the overall runtime counts, so it doesn’t matter if a statement is executed 1 time with a duration of 1000 seconds or if it is executed 1 million times with an average duration of 1 ms, because in both cases the statement is responsible for a total duration of 1000 seconds.
• High memory utilization
• High CPU consumption
• High lock wait time

6. How can time information in the SQL cache (M_SQL_PLAN_CACHE) be interpreted?

Tables like M_SQL_PLAN_CACHE, M_SQL_PLAN_CACHE_RESET and HOST_SQL_PLAN_CACHE contain several time related columns and it is not always clear how to interpret them:

Usually long EXECUTION_OPEN or EXECUTION_FETCH times are caused by retrieving the data.
From a SQL tuning perspective the most important information is the total elapsed time of the SQL statement which is the sum of preparation time and execution time.

7. How can I determine the most critical SQL statements?

For a pure technical SQL optimization it is useful to determine the most expensive SQL statements in terms of elapsed time and check the result list top down. The most expensive SQL statements in the SQL cache can be determined in the following ways:

• M_SQL_PLAN_CACHE / HOST_SQL_PLAN_CACHE
• SAP HANA Studio -> Administration -> Performance -> SQL Plan Cache
• SQL: “HANA_SQL_SQLCache” (SAP Note 1969700)
• Solution Manager self service “SQL Statement Tuning” (SAP Note 1601951)

Additionally expensive SQL statements can be captured by trace features:

If you are interested in the top SQL statements in terms of memory consumption, you can activate both the expensive statement trace and the statement memory tracking (SPS 08 or higher, see SAP Note1999997 -> “Is it possible to limit the memory that can be allocated by a single SQL statement?”) and later on run SQL: “HANA_SQL_ExpensiveStatements” (SAP Note 1969700) with ORDER_BY = ‘MEMORY’.
The currently running SQL statements can be determined via SQL: “HANA_SQL_ActiveStatements”(SAP Note 1969700).
In all cases you get a list of SQL statements / STATEMENT_HASH values that subsequently be analyzed in more detail.

8. How can I determine and interpret basic performance information for a particular SQL statement?

The following SQL statements available via SAP Note 1969700 can be used to collect further details for a given STATEMENT_HASH (to be specified in “Modification section” of the statements):

Below you can find several typical output scenarios for SQL: “HANA_SQL_StatementHash_KeyFigures”.

Scenario 1:  Transactional lock waits

We can see that nearly the whole execution time is caused by lock wait time, so transactional lock (i.e. record or object locks) are responsible for the long runtime. Further transactional lock analysis can now be performed based on SAP Note 1999998.

Scenario 2: High number of executions

An elapsed time of 0.55 ms for 1 record is not particularly bad and for most of the SQL statements no further action is required. In this particular case the number of executions is very high, so that overall the execution time of this SQL statement is significant. Optimally the number of executions can be reduced from an application perspective. If this is not possible, further technical analysis should be performed. Really quick single row accesses can be below 0.10 ms, so there might be options for further performance improvements (e.g. index design or table store changes).

Scenario 3: High elapsed time

An execution time of 284 ms for retrieving one row from a single table is definitely longer than expected and it is very likely that an improvement can be achieved. Further analysis is required to understand the root cause of the increased runtime.

Scenario 4: High elapsed time for DML operations, no lock wait time

An elapsed time of 10 ms for inserting a single record is quite high. If DML operations have an increased elapsed time it can be caused by internal locks that are e.g. linked to the critical phase of savepoints. Further internal lock analysis can now be performed based on SAP Note 1999998.

Scenario 5: Many records

Reading about 200,000 records in less than 2 seconds is not a bad value. In the first place you should check from an application perspective if it is possible to reduce the result set or the number of executions. Apart from this there are typically also technical optimizations available to further reduce the elapsed time (e.g. delta storage or table store optimizations).

Scenario 6: High Preparation Time

Preparation time is linked to the initial parsing and compilation. You can reduce this overhead by using bind variables rather than literals so that several SQL statements with the same structure need to be parsed only once. Furthermore you can perform a more detailed analysis to understand why the preparation step is taking longer than expected.

9. Which options exist to understand the execution of a SQL statement in detail?

In order to understand how a SQL statement can be tuned it is essential to know how it is processed. For this purpose you an use the following tools:

10. What are typical approaches to tune expensive SQL statements?

Depending on the results of the analysis of an SQL statement the following optimizations can be considered.

JoinEvaluator.cpp(01987) : getJoinStatistics: SAPSR3:CRMM_BUAG (-1)/BUAG_GUID<->SAPP25:CRMM_BUAG_H (-1)/BUAG_GUID
JoinEvaluator.cpp(01999) : jStats   clSizesL:0 clCntAL:0 cntSJL:0 TTL:0 clSizesR:0 clCntAR:0 cntSJR:0 TTR:0

ALTER SYSTEM RECOMPILE SQL PLAN CACHE ENTRY '<plan_id>'

SELECT ... FROM COSP
WHERE ... AND ( OBJNR BETWEEN ? AND ? OR OBJNR BETWEEN ? AND ? )

UPDATE "<table_name>" WITH PARAMETERS ('OPTIMIZE_COMPRESSION' = 'FORCE', 'COLUMNS' = ('<column_name>') )

indexserver.ini -> [search] -> qo_top_1_optimization = false

indexserver.ini -> [calcengine] -> max_cache_size_bytes = <byte>

11. Are secondary indexes required to provide an optimal performance?

SAP HANA is able to process data efficiently so that often a good performance is possible even without the use of indexes. In case of frequent, selective accesses to large tables it is nevertheless useful to create additional secondary indexes. As a rule of thumb column store indexes should be created on single columns whenever possible, because single column indexes require much less memory compared to multi column indexes.
See SAP Note 2160391 for more details.

12. Which advanced features exist for tuning SQL statements?

The following advanced features exist to optimize SQL statements:

13. Are there standard recommendations for specific SQL statements available?

In general it is hard to provide standard recommendations because optimizations often depend on the situation on the individual system. Nevertheless there are some exceptions where the underlying root cause is of a general nature. These SQL statements are collected in the following table:

Statement hash	Statement description	Optimization
eb82038136e28e802bd6913b38a7848c	CALL of BW_CONVERT_CLASSIC_TO_IMO_CUBE	This procedure is executed when a classic infocube is converted to an in-memory optimized infocube using transaction RSMIGRHANADB. Increased load is normal when large infocubes are converted. After the conversion of the existing infocubes is finished, executing this procedure is no longer required, so it is only a temporary activity.
651d11661829c37bf3aa668f83da0950 42bf4a47fbf7eabb5e5b887dffd53c7c	CALL of COLLECTOR_HOST_CS_UNLOADS INSERT into HOST_CS_UNLOADS_BASE	Disable the data collection for HOST_CS_UNLOADS as described in SAP Note 2084747. This action is also recommended in SAP Note 2147247.
2c7032c1db3d02465b5b025642d609e0 b8b6f286b1ed1ef2e003a26c3e8e3c73 5ec9ba31bee68e09adb2eca981c03d43 5f42d3d4c911e0b34a7c60e3de8a70d2	SELECT on M_BACKUP_CATALOG_FILES and M_BACKUP_CATALOG	These SELECTs are regularly issued by the backup console in SAP HANA Studio. In order to minimize the impact on the system you should open the backup console only when required and not permanently. If you repeatedly need to open the backup console, you can increase the refresh interval (default: 3 seconds): Check if the backup catalog is unnecessarily large and delete old catalog entries if possible using: BACKUP CATALOG DELETE ALL BEFORE BACKUP_ID ...
68f35c58ff746e0fe131a22792ccc1b5	CALL of BW_F_FACT_TABLE_COMPRESSION	It is normal to see a significant cumulated runtime, because it is a central procedure call for all F fact table compressions. This procedure performs BW compression on F fact tables (i.e. elimination of requests and transition of data into E fact table or dedicated F fact table partition). If F fact tables with a significant amount of records are processed, a significant runtime is expected. Otherwise you can use SQL: “HANA_Threads_ThreadSamples_FilterAndAggregation” (SAP Note 1969700) in order to check for the THREAD_DETAIL information related to this statement hash, which contains the involved table names. Based on this information you can check if you can optimize BW F fact table compression for the top tables. Be aware that the THREAD_DETAIL information is only available when the service_thread_sampling_monitor_thread_detail_enabled parameter is set to true (see SAP Note 2114710).
91d7aff2b6fb6c513293d9359bf559a6	CALL of DSO_ACTIVATE_PERSISTED	It is normal to see a significant cumulated runtime, because it is a central procedure call for all DSO activations. This procedure is the HANA server side implementation of DSO activation in BW environments. During this activation data is moved between three involved tables (/BIC/A*40, /BIC/A*00 and /BIC/B000*). It is much more efficient than the previous, SAP application server based approach, because moving a high amount from the database to the application and back is no longer required. If the DSO activation in distributed environments takes longer than expected, you should check if the partitioning of the /BIC/A*40 and /BIC/A*00 tables is consistent, i.e. same partitioning and same hosts for the related partitions. You can check this DSO consistency via SQL: “HANA_BW_InconsistentDSOTables” (SAP Note 1969700). For SAP HANA optimized DSOs you can check SAP Note 1646723 for DSO activation parameters. Apart from this you can also apply optimizations on BW side, e.g. smaller requests or smaller keys.
bb45c65f7cc79e50dbdf6bbb3c1bf67e b0f95b51bcece71350ba40ce18832179	SELECT on M_CONNECTIONS	This SELECT is executed when a SAP ABAP work process connects to SAP HANA. Implement a sufficiently new DBSL patch level according to SAP Note 2207349 in order to replace this query with a more efficient approach based on session variables.
fcdf8f8383886aaf02c3a45e27fbd5f2	SELECT on M_CONNECTIONS and M_ACTIVE_STATEMENTS	This SELECT is executed if performance monitoring is scheduled via transaction /SDF/MON and the checkbox “SQL statements” is flagged. Disable this checkbox if you want to eliminate the load introduced by this statement hash.
09214fa9f6a8b5322d329b156c86313b 28996bd0243d3b4649fcb713f43a45d7 7439e3c53e84b9f849c61d672da8cf79 84e1f3afbcb91b8e02b80546ee57c537 9ce26ae22be3174ceaffcfeee3fdd9b7f32de4a673809ad96393ac60dfc41347	SELECT on M_STATISTICS_LASTVALUES UPDATE on STATISTICS_LASTVALUES	This SELECT is executed by the Solution Manager in order to read history data from the statistics server. It is particularly critical if the standalone statistics server is used. The UPDATE is executed by the standalone statistics server in order to update statistical information. Implement SAP Note 2147247 (“How can the memory requirements of the statistics server be minimized?”), so that the collection and processing of statistical data is optimized. A switch to the embedded statistics server is typically already sufficient to resolve this issue.
0ad1a4c1c1a5844d01595f5b3cdc2977	SELECT on M_TRACEFILE_CONTENTS	This SELECT is regularly issued by the backup console in SAP HANA Studio. In order to minimize the impact on the system you should open the backup console only when required and not permanently.
6b1d10732401fe82992d93fa91f4ae86	SELECT FOR UPDATE on NRIV	Check if you can reduce the critical time frame between SELECT FOR UPDATE on NRIV and the next COMMIT. Identify the involved number range objects from application perspective and optimize their number range buffering. See SAP Note 1398444 for buffering RF_BELEG and SAP Note 1524325 for buffering RV_BELEG. Make sure that the table NRIV is located in row store, because the frequent UPDATE operations can be handled more efficiently in row store compared to column store. Be aware that bad performance for the SELECT FOR UPDATE on NRIV can also be a consequence of some underlying general issues, so if it happens occasionally and in combination with some other issues, it can be a symptom for another problem and not an issue itself.
a77c6081dd733bd4641d4f42205f6c84	SELECT FOR UPDATE on QIWKTAB	This SELECT FOR UPDATE can suffer from row store garbage collection activities if the QRFC scheduler issues a very high amount of updates on a few records of this table. This typically happens if there are STOP entries in transaction SMQ2 that never can be processed, but result in a looping scheduler check. Go to transaction SMQ2 and check if there are STOP entries in any client which can be removed. After cleanup the update frequency should significantly reduce and the row store garbage collection is able to keep up without problems. See SAP Note 2169283 for more information related to garbage collection. SAP Note 2125972 provides an application correction to reduce the amount of updates on QIWKTAB.
6662b470dc055adfdd4c70952de9d239 93db9a151f16022e99d6c1c7694a83b0	SELECT on RSDDSTATEVDATA	Consider reducing the execution frequency of the related Solution Manager extraction “WORKLOAD ANALYSIS (BI DATA)”. See SAP Note 706478 and delete / archive old records from RSDDSTATEVDATA. The minimum STARTTIME in table RSDDSTATINFO is from 30 days ago, so the actual retention time is 30 days. You could reduce it via parameter TCT_KEEP_OLAP_DM_DATA_N_DAYS (SAP Note891740).
0e30f2cd9cda54594a8c72afbb69d8fd a115fd6e8a4da78f0813cfe35ffc6d4200218f32b03b44529da647b530bf4e6d8a8ec2baa7873e835da66583aa0caba2b51046ad3685e1d45034c4ba78293fd8 ec91f8ecc5030996f1e15374f16749a8 f0a4785a6ada81a04e600dc2b06f0e494fe60bbfbfa2979b89e8da75f5b2aac7 ca8758b296bd2321306f4fee7335cce5 2aeb4f7ffd47da8917a03f15a57f411a	SELECT on RSICCONT SELECT on RSSELDONE SELECT on RSMONICDP SELECT on RSSTATMANPART SELECT on RSSTATMANSTATUS SELECT on TESTDATRNRPART0	If theses queries return a significant amount of records (> 100), it might be caused by a high number of existing requests. In this case you can check the following: Run SQL: “HANA_BW_DataTargets” (MIN_REQUESTS = 10000) available via SAP Note 1969700 or check table RSMDATASTATE_EXT manually for data targets with REQUESTS_ALL > 10000. See SAP Note 2037093 and reduce the request lists of data targets with more than 10,000 requests using programs like RSSM_AUTODEL_REQU_MASTER_TEXT and RSSM_REDUCE_REQUESTLIST.
8437943036a2a9fd82b290b2c6eafce7	SELECT on RSR_CACHE_FFB and RSR_CACHE_VARSH	See SAP Note 706478 and check if you can clean up old entries in RSR_CACHE tables.
e5332b10f3a1a4215728857efc0f8eda	SELECT on SOURCE_ALERT_65_BACKUP_CATALOG	This SELECT is linked to the statistics server action Alert_Backup_Long_Log_Backup. See SAP Note 2147247 (“How can the runtime and CPU requirements of the statistics server actions be analyzed and optimized?” -> “Alert_Backup_Long_Log_Backup”) for details about optimizations.
5ef81b3843efbe961b19fdd79c2bd86b a3bbe3e5447bc42eb3f0ece820585294	CALL of STATISTICS_PREPARE_CALL_TIMER UPDATE of STATISTICS_SCHEDULE	The UPDATE on STATISTICS_SCHEDULE is executed from within the procedure STATISTICS_PREPARE_CALL_TIMER. High runtimes in combination with record locks (ConditionalVariable Wait) on table STATISTICS_SCHEDULE can be caused by inefficient COMMIT handling. This problem is resolved as of Rev. 101.
ac08e80aa8512f9669eaf56dedc02202 c6c59150977220ea4fdea412cac7d1ce 0800928edd9d43764935a4e02abbfa15 16c226e204b54efc280091df267152fd 2b7fee2d2b95e792d3890051cbb97ec9 55bb62c4b9ff3f0b32de3a4df248e18c	SELECT on STATISTICS_CURRENT_ALERTS SELECT on STATISTICS_LAST_CHECKS	See SAP Notes 2147247 (“How can the runtime and CPU requirements of the statistics server actions be analyzed and optimized?” -> STATISTICS_ALERTS_BASE) and make sure that the size of the underlying table STATISTICS_ALERTS_BASE remains on a reasonable level.
dc571bf5eb7cad9c313c20de904ab709 d6fd6678833f9a2e25e7b53239c50e9a	CALL of STATISTICS_SCHEDULABLEWRAPPER	This procedure is a wrapper for all embedded statistics server actions like history collections and alert checks. See SAP Note 2147247 (“How can the runtime and CPU requirements of the statistics server actions be analyzed and optimized?”) for more information how to analyze and optimize the actions.
ba8161b6133633e2984828ce38aa669a 7f55e72c22694541b531e83d8bab8557 2b459e0d42037fe4d6880b238018a6f7 70efe3b4e470438543e6ecec418e4f02 905dbaa93a672b087c6f226bc283431d	CALL of ALERT_DEC_EXTRACTOR_STATUS CALL of COLLECTOR_GLOBAL_DEC_EXTRACTOR_STATUS SELECT on GLOBAL_DEC_EXTRACTOR_STATUS_BASE SELECT on TABLES	This CALL and SELECT is executed by the statistics server under the _SYS_STATISTICS user. It is linked to DXC (see M_EXTRACTORS) and looks for tables with names like ‘/BIC/A%AO’. Tables following this naming convention are technical tables to control the DXC DSO activation process. If the CATALOG READ privilege is not granted to _SYS_STATISTICS, the query can take quite long and return limited results. You can massively improve the runtime by granting CATALOG READ to _SYS_STATISTICS.
371d616387247f2101fde31ed537dec0 aaff34b83d10188d08109cb52a0069ae 3f96e3762412e8d4cf4c670f2993aa8a 51bffaafaddd0ec825ecb9f5bf1b5615 5d0b4a21b0c17c08a536bec04f2825cd a3f19325031503e9e4088a8e57515cd3 1cbbe08ef2bf075daecb9e383ae74deb a5539c73611c1d0ba9e4a5df719329b8 a382ffaeafac914c422752ab9c2f9eab 81d83c08828b792684d4fd4d2580038e 1ce978ccb4cfed10e1ef12dc554c2273 54c8e15427f41b9074b4f324fdb07ee9 da7ef0fee69db516f1e048217bca39e7 c197df197e4530b3eb0dcc1367e5ba4b	DELETE on TESTDATRNRPART0 DELETE on TESTDATRNRPART1 DELETE on TESTDATRNRPART2 DELETE on TESTDATRNRPART3 DELETE on TESTDATRNRPART4 DELETE on TESTDATRNRPART5 DELETE on TESTDATRNRPART6 INSERT into TESTDATRNRPART0 INSERT into TESTDATRNRPART1 INSERT into TESTDATRNRPART2	SAP Note 1964024 provides a correction that reduces the DML operations on the TESTDATRNRPART<id> tables for all types of databases. The optimization is available as of BW support packages SAPKW73012, SAPKW73112 and SAPKW74007. Also make sure that no data targets exist with a high number of requests. See SAP Note2037093 for more information.
e1cdd703df87fc61ce8163fa107162a9	CALL  SYS.TREXviaDBSL	TREXviaDBSL is used to execute queries that are not possible with plain SQL (e.g. BW queries with execution modes > 0). In the SAP HANA SQL cache both the content and the bind values are hidden, so a direct analysis and optimization is not possible. SAP Note 2125337 provides a coding correction that allows to trace bind values via an expensive statements trace. See “What are typical approaches to tune expensive SQL statements?” -> “Long runtime of TREXviaDBSL calls” for more information.

14. Is it required to create optimizer statistics in order to support optimal execution plans?

No, it is not necessary to create optimizer statistics. SAP HANA determines optimal execution plans by certain heuristics (e.g. based on unique indexes and constraints) and by ad-hoc sampling of data.

15. Are all database operations recorded in the SQL cache (M_SQL_PLAN_CACHE)?

Standard operations like SELECT, INSERT, UPDATE or DELETE are recorded, but some more specific DML (e.g. TRUNCATE) and DDL operations (e.g. ALTER) are not contained.
Starting with Revision 74 also accesses from stored procedures and SQLScript to temporary tables are no longer stored in the SQL cache (see SAP Note 2003736, “Changed the implementation of SQL queries…”).

16. Can sorting be supported by an appropriate index?

No, due to the technical structure it is not possible that a sort operation is supported by an index.

17. Is it possible to capture bind values of prepared SQL statements?

Often SQL statements are prepared with bind variables in order to avoid frequent reparses. Rather than literals you will then see question marks in the WHERE clause, e.g.:

SELECT
  *
FROM
  "A004"
WHERE
  "MANDT" = ? AND
  "KNUMH" = ? AND
  "KAPPL" = ?

In order to understand selectivities and correlation and to be able to reproduce a problem with a SQL statement it is important to know which actual bind values are used. This information can be determined based on specific traces (e.g. the ST05 SQL trace in ABAP environments).
On SAP HANA side the expensive statement trace captures bind values which can e.g. be evaluated viaSQL: “HANA_SQL_ExpensiveStatements_BindValues” (SAP Note 1969700).
Additionally SAP HANA is able to capture the bind values of critical SQL statements in the SQL plan cache per default as of SPS 08. This capturing is controlled by the following parameters:

The captured values are stored in view M_SQL_PLAN_CACHE_PARAMETERS and can be evaluated via SQL: “HANA_SQL_StatementHash_BindValues” (SAP Note 1969700).

18. How can the performance of INSERTs and data loads be tuned?

INSERTs and data loads write new data, while other operations like SELECT, UPDATE or DELETE have to work on existing data. Therefore typical performance factors are partially different. If you want to improve the performance of INSERTs and data loads, you can consider the following areas:

Typical INSERT throughputs are:

• global.ini
  [expensive_statement]
  use_in_memory_tracing = true

When information of expensive statements is stored in memory and M_EXPENSIVE_STATEMENTS monitoring view is searched with filter conditions (WHERE …) for one of following columns;

• CONNECTION_ID
• TRANSACTION_ID
• STATEMENT_ID
• DB_USER
• APP_USER
• START_TIME
• OBJECT_NAME

Then, memory allocated by “Pool/RowEngine/MonitorView” for M_EXPENSIVE_STATEMENTS monitoring view won’t be released due to programming error.
You can check the memory size allocated by Pool/RowEngine/MonitorView with following sql

• select exclusive_size_in_use from m_heap_memory where category = ‘Pool/RowEngine/MonitorView’

• alter system alter configuration (‘global.ini’, ‘system’) set (‘expensive_statement’, ‘use_in_memory_tracing’) = ‘false’;

Sap Note : 2193110

Please refer to the SAP HANA Revision and Maintenance Strategy document on SAP Service Marketplace for an overview regarding the SAP HANA revision and maintenance strategy.
For details about the SAP HANA revision and maintenance strategy and recommended upgrade paths between SAP HANA Revisions, Support Package Stacks, Maintenance Revisions and Datacenter Service Points, see “SAP Note  2021789: SAP HANA Revision and Maintenance Strategy“.

2233148 – SAP HANA SPS 11 Database Revision 110

2265765 – SAP HANA SPS 11 Database Revision 111

2257500 – SAP HANA SPS 10 Database Maintenance Revision 102.04

2242726 – SAP HANA SPS 10 Database Maintenance Revision 102.03

2220948 – SAP HANA SPS 10 Database Maintenance Revision 102.01

2220929 – SAP HANA SPS 09 Database Maintenance

Please refer also to the following SAP Notes:

• 2165826: SAP HANA Platform SPS 10 Release Note
  This is the central entry point for all information around SAP HANA Platform Support Package Stack (SPS 10), the comprised SAP HANA Revisions and subsequent SAP HANA Maintenance Revisions.
• Before downloading a SAP HANA Platform SPS 10 revision please check out SAP Note 2184635: SAP HANA SPS 10 – Download procedure for SAP HANA database component. 

Please note the following:

• If you upgrade to this Revision and you’re using SAP BW on HANA, please check the ABAP-related notes which can be found in the attachments of this note.

Installation/Upgrade

• Before you start the upgrade from Revision 64, 65, and 66. Please check out SAP Hot News Note 1918267.
• As part of the installation or the upgrade to Revision 101 or higher the master key of the secure store in the file system (SSFS) is changed from the initial default key to an installation specific individual key. Please checkout SAP Note 2183624. To change the master key of SSFS of the hdbuserstore please additional check out Note 2210637.
• Please check “SAP Note 1948334 : SAP HANA Database Update Paths for Maintenance Revisions” for the possible update paths from Maintenance Revisions to SPS Revisions.
• If you upgrade from a Revision prior to SPS 06, first upgrade your system to the latest SPS 06 Revision (Revision 69.07) before upgrading to this Revision.
• If you encounter a problem during the upgrade phase “Importing Delivery Units”, please check out SAP Note 1795885.
• If you are using SAP HANA live, please check Release Note 1778607 before you start upgrading to SPS 10.
• Before you start the upgrade to this Revision, please check out SAP Note 2159899 – Release Notes for SAP HANA Application Lifecycle Management for SAP HANA SPS 10.
• In order to run the SAP HANA Database Revision 80 (or higher) on SLES 11, additional operating system software packages are required.
  Before you start the upgrade or the installation of Revision 80 or higher, please check out SAP Note 2001528.
• If the SAP HANA installation or one of its AFL plugins fails, please check out SAP Note 2183500
• If you encounter the problem: HALM Process Engine: Data cannot be updated alert message, please check out SAP Note 2184376.
• If you get the issue that the Win8 HANA studio upgrade via update site failed, please check out SAP Note 2182779.
• Troubleshooting guide for the SAP HANA platform lifecycle management tool hdblcm. Please checkout  SAP Note 2078425.

Most frequently Used Commands For SAP HANA Administrators –Link

General

• With SAP HANA SPS 09, several inconsistencies in handling the data types double / float have been fixed. This leads to a change in the string representation of float / double data types. Please check out SAP Note 2092868.
• With SAP HANA SPS 09, several inconsistencies in handling the data types double / float have been fixed. This leads to a change in the string representation of float / double data types and may cause inconsistencies in concat attributes (such as primary keys, unique constraints) that contain float / double data type columns. Please check out SAP Note 2104798.
• As of Revision 93 the Embedded Statistics Server is the default setting. If you still running the old statistics server, the upgrade triggers the migration to the Embedded Statistics Server automatically. Please check out SAP Note 2091313 : HANA Statistics Server – changed standard setting of the statistics server as of Revision 94.
• Please note that when the Embedded Statistics Server is used, some program changes are required in the ABAP monitoring tools. See SAP Note 1925684 for details.
• If the recovery of data without using the backup catalog fails with incorrect syntax near “USING”, please check out SAP Note 2157184.
• If you are using SAP Web Dispatcher as the HTTP load balancer, additional configuration is required. Please see SAP Note 2146931 for details.
• If you have problems creating or modifying a user in the SAP HANA web-based development workbench, please check out SAP Note 2183760.
• If you are using the SAP HANA cockpit delivery unit “HANA_ADMIN Version 1.3.9”, the start, killing, and stopping of services do not work properly, even if successfully reported. Please check out SAP Note 2182831.
• Please note that the virtual table function is currently not supported on multitenant databases. Please check out SAP Note 2182597.
• The version of libnuma1 (library for Non-Uniform Memory Access) delivered with SLES 11 SP1 up to version libnuma1-2.0.3-0.4.3 contains a bug which causes the name server to crash. Please check out SAP Note 2132504.
• You can find information about SHINE (SAP HANA Interactive Education) demo content in SAP Note 1934114.
• You can find documentation corrections information for the SAP HANA option Advanced Data Processing in SAP Note 2183605.
• Introduced a new security feature to configure if the SYSTEM user is locked due to too many failed connect attempts.
  The new parameter “password_lock_for_system_user” in section [password_policy] of file indexserver.ini (or nameserver.ini for the system database of a multiple-container system) has value “true”, which means the SYSTEM user will be locked for <password_lock_time> after <maximum_invalid_connect_attempts> failed attempts. To keep the old, unsafe behaviour, set parameter “password_lock_for_system_user” to “false” (not recommended).
• Introduced a new feature to configure error messages for invalid connect attempts.
  The new parameter “detailed_error_on_connect” in section [password_policy] of file indexserver.ini (or nameserver.ini for the system database of a multiple-container system) has value “false”, which means only the information “authentication failed” will be returned in such a case. If set to “true” (not recommended), the specific reason for failed logon is returned.

NewDB, in-memory database, Hybrid database, update, installation, SPS 10

• Running the installation and the update is only supported on a validated SAP HANA appliance and SAP HANA Tailored Datacenter Integration setup.

If you upgrade from a lower SAP HANA SPS, it is recommended to update ALL other components (Studio, Modeler, DB Clients, DBSL, SLT, DS, …) to at least the minimal version of SAP HANA SPS 10.

Documentation

• See SAP Help Portal at http://help.sap.com/hana_platform for the complete SAP HANA product documentation set.

Installation and Update

• For the installation of the SAP HANA client on SUSE Linux Enterprise Server 9 and 10, use the package “Linux SUSE 9 on x86_64 64bit”.
• Fixed a problem with the Hardware Check Tool (HCCT) that could have caused VMware-virtualized systems to hang or report inconsistent data (hyperthreading was deactivated even if it had been activated).
  For more information, see SAP Note 2161344.

Issues solved with this revision

Backup & Recovery

• Fixed an issue that caused tenants to be recovered on an arbitrary host instead on the host they were created on.

BW/OLAP

• Fixed an issue in Epsilon Reaction in order to adapt the BW disaggregation behaviour.
• Fixed a bug which could lead to an indexserver crash during out of memory situations.
  In indexserver crashdump contained the following call stack:
  “[CRASH_STACK] Stacktrace of crash: (0000-00-00 00:00:00 000 Local)
  —-> Symbolic stack backtrace <—-
  0: Evaluator::StackVector<Evaluator::ExpressionTree::McpStackEntry, 64ul>::enlarge(unsigned long) + 0x5c
  1: Evaluator::ExpressionTree::mergeCommonParts() + 0xa05
  2: AttributeEngine::Evaluator::compile() + 0x349”.

Database Client

• Fixed an issue in the SQLDBC client which caused ABAP application servers to connect to the wrong host after a HANA master node restart or indexserver crash, leading to the error: Connect failed (no reachable host left).
• Fixed an issue on the HANA client when DEFERRED_LOB_WRITING were used, which could lead to a short dump on application side with the error message: “SQL code: -9300” occurred while accessing table <table_name>. Please refer to SAP Note 2205345 for details.
• Fixed an issue in HANA ODBC driver that when using ADO call “SQLGetData” with a 0-length buffer to determine the length, the driver did not return a truncation warning because there was no room in the buffer for the NULLCHAR.

• Fixed an issue in the HANA ADO.net driver that IListSource.ContainsListCollection did not match the MSDN documentation. After the fix the property will always returns false since the HanaDataReader does not return a collection of IList objects.

• Fixed an issue where connections failed to connect when using Kerberos SSO to authenticate users through the SAP HANA MDX driver.

Data Provisioning

• Fixed the table type of extended storage tables which could return CREATE ROW TABLE even if CREATE COLUMN TABLE <table_name> USING EXTENDED STORAGE was used.

Database Client

• Corrected a client bug that prevented a receive timeout after the configured CONNECTIONTIMEOUT threshold.

High Availability

• Fixed an issue where the takeover flag was not removed from the topolgy (/topology/datacenters/takeover/*), when a takeover was performed on a secondary system where not all tenants could be taken over (e.g. because they were not initialized yet).
• Fixed a crash that could occur in a secondary site of system replication in combination with Live Cache.
  The crash stack was as follows:
  “1: TransactionManager::TransactionControlBlockSPI::precommit
  2: DataAccess::ReplicationProtocolSecondaryHandler::createTCBforRestartSessions
  3: DataAccess::ReplicationProtocolSecondaryHandler::buildOpenSessionList
  4: DataAccess::ReplicationProtocolSecondaryHandler::preloadTables”.
• Fixed the issue that takeover to the standby node did not happen and the landscape was broken until a failed host was working again when a tenant catalog master was not located on the master node and a none master node failed in a MultiDB scenario.

Languages (SQL Script, R, River)

• Fixed an issue that prevented a table variable within a cursor to be passed directly.
• Fixed a regression bug in the SQLScript parser tht could occur an array index position was referenced with a variable value in the WHERE clause of a SQL statement, like:
  “lArray bigint array;
  v_index int;
  lArray[1]:=1;
  v_index :=1;
  select * from dummy where :lArray [:v_index]=1;”
  This caused the following error: “incorrect syntax near “)” “.

MDX

• Fixed an issue in SAP HANA MDX where the members could have unexpected results when they were not requested according to their hierarchy order.
• Fixed an issue in HANA MDX when filters on parent-child hierarchy for non-leaf members were used.

• Optimized the performance and memory consumption of HANA MDX for property lookups that could involve expensive join operations.
• Fixed a bug that caused an MDX query on an analytical view with hierarchies to fail with the following error:
  “SQL: feature not supported: not allowed over OLAP VIEW : search without aggregation, grouping by expression other than view column or user defined function with string type”.

Security

• Fixed a role performance issue for GRANT.

Supportability

• Fixed a bug where SAP HANA studio could not correctly display the thread overview and session overview monitor.
  This was caused by invalid characters in the monitoring view M_CONNECTIONS.
  Selecting this view resulted in the error message “invalid character encoding”.

Text search

• Fixed an issue where preprocessor threads would hang and never complete with the following call stack:
  “1: SAP::TextAnalysis::DocumentAnalysis::StructureAnalysis::NormalizationBuffer::addChar
  2: SAP::TextAnalysis::DocumentAnalysis::StructureAnalysis::XMLTextParser::insertBlankLine
  3: SAP::TextAnalysis::DocumentAnalysis::StructureAnalysis::XMLTextParser::startElement”.

XS Engine

• Fixed an issue where the XS engine caused continuous memory growth in Pool/SQLScript/Execution allocator.
• Fixed an issue, where it was not possible to add an Identity Provider via Internet Explorer or Firefox.
  Additional information is provided in SAP Note 2169923.

• Fixed an issue with the password recovery functionality using a profile to see the security questions.

General

• Fixed an issue that could cause an indexserver crash with null string handling, showing the following start to the callstack:
  “1: expr::(anonymous namespace)::LCodeArgumentWrapper::~LCodeArgumentWrapper()
  2: expr::Evaluator::Dispatch<46>()”.
• Fixed an indexserver crash. The error stack was: ptime::NBaseString:_clone.
• Fixed an issue that could cause a corruption leading to a crash with the following crashstack during table access:
  “exception 1: no.1000000
  Orphaned timestamp TS[tcbidx=2147483647,ssn=any]; $condition$=tcb
  1: TransactionManager::TransactionControlBlockFactory::getTimestampState
  2: TransactionManager::ConsistentView::isTransactionCommitted
  3: TransactionManager::ConsistentView::isTimestampRangeVisible
  4: DataContainer::FileIDMapping::isVisible”.
• Fixed a bug where the Table Consistency Check could consume too much memory and result in a OOM situation and a performance problem.
• Improved performance for inserts into global temporary column tables.
• Fixed an indexserver crash with the following call stack:
  “joinEvaluator::SearchAlgorithm::expand()”.
• Fixed an issue in NUMA awareness. The issue was visible with the following trace message, but did not harm the system:
  “libnuma: Error: mbind: Invalid argument”.
• Fixed an issue with delta merge handling, which could have resulted in high amount of no longer needed UDIV/MVCC data in the main memory of column store attributes not being released, even if the number of rows in the main-memory was not high.
• Fixed a crash by terminating the corresponding SQL statement instead of crashing the indexserver. The corresponding call stack was the following:
  “1:MemoryManager::BigBlockAllocator::addFreeBlock()”.
• Reduced compilation time for SQL statements with large/complex expression lists.
  Most of the time was spend in the check for duplicate aggregation using trex expression.
• Fixed insufficient performance for SELECT queries on SYS.GRANTED_PRIVILEGES.
• Fixed an out of memory situation that could occur when a primary key or a secondary index on existing, large column store tables was created. A typical scenario where this could have happened was a part of a data migration.
• Fixed an issue where an UPDATE statement would result in the following runtime error:
  “SAP DBTech JDBC: [3]: fatal error: ColDicVal (1000001,4) not found”.
• Fixed a crash that could occur when performing an UPDATE FROM. The crashdump contained:
  “1: ptime::Qc2QoConverter::make_rid_field()
  2: ptime::Qc2QoConverter::convert_relation_project_record()”.
• Fixed a bug which could lead to obsolete memory and cpu resource consumption baused by a query on the calculation model because a stacked qoPop was generated.
• Fixed the inconsistent status of the result view of procedures after an upgrade.
• Fixed an issue that original snapshots failed and inconsistencies were reported when the snapshot directory was cleared incorrectly after a  snapshot was opened for secondary.
• Reduced CPU usage on function calls like “JoinEvaluator jeReadIndex” or “SQL optimizer estimations (prefetchSampleData)”. Kernel Profiler traces revealed that a high amount of CPU time was spent on “generateOLAPBitmapMVCC”.
• Fixed an issue in the XS Job Dashboard that did not allow to add parameter values including a “:” to a schedule.
• Fixed an issue in the XS Job Dashboard that preveted show schedules for jobs that are referencing .hdbprocedure objects from being shown.
• Fixed a bug that allowed invalid date values to be inserted into HANA tables. These values could lead to the error
  “AttributeStoreFile error ‘TABLEattribute_204.bin’: attribute value is not a date or wrong syntax; failed with rc 6931”
  when loading the table subsequently.
• Fixed a crash that could occur when a query was run against a calcview.
  The crash stack was as follows:
  “—-> Symbolic stack backtrace <—-
  0: OlapEngine::BwDocids::prepareMdDocIdsForMain()
  1: OlapEngine::BwDocids::getDocids()
  2: OlapEngine::BwPopJoin12::executePop”.
• Fixed a crash with the following call stack:
  “[CRASH_STACK] stacktrace of crash: (0000-00-00 11:11:11 111 Local)
  —-> Pending exceptions (possible root cause) <—-
  exception 1: no.1000000 (Basis/Container/SafePointer.hpp:91)
  Assertion failed: (oldValue & RESET_BIT) == 0
  exception throw location:
  1: 0x00007fbb97499c38 in Container::SafePointerHolder<ptime::Statement>::reset()
  2: 0x00007fbb974fb53b in ptime::EntryStatementInfo::set
  3: 0x00007fbb974fb592 in ptime::Connection::setEntryStatement_
  4: 0x00007fbb97521bfa in ptime::EntryStatementScope::reset()
  5: 0x00007fbb97537dc1 in ptime::Statement::compile_”.
• Fixed an issue that caused an error during query execution when analytic views with join engine deployment were involved.
  The error was as follows:
  “column store error: search table error: [34051] Error during plan execution;Cannot find column DISCOUNT_AMOUNT$sum$ in input itab”.
• Fixed a performance issue caused by slow filtering on DDIC_NUMC fields due to non optimized search method was used.
• Fixed a bug which caused an indexserver crash when SQLScript procedures with DDL statements were called in parallel.
  The following assertion could be found in the crashdump:
  “Pure virtual function called, block=MemoryBlock “block”: Deallocated block …
  1:  __cxa_pure_virtual
  2: TRexCommonObjects::InternalTableBase::size() const
  3: ptime::Query::Plan::clear_temp_indexes()”.
• Fixed an indexserver crash that was triggered by a query on top of a calculation view. The crash stack contained the following entries:
  2ptime::qo_Exp::clone_subtree
  ptime::qo_Normalizer::getExpForPlaceholders
  TrexCalculationEngine::QueryEntryToQoTranslator::getExpFromQueryEntryConstVal
  TrexCalculationEngine::QueryEntryToQoTranslator::translateTerm
  TrexCalculationEngine::QueryEntryToQoTranslator::translateQueryEntry
  TrexCalculationEngine::QueryEntryToQoTranslator::translate
  TrexCalculationEngine::ceQOBuilder::buildPostFilter
  TrexCalculationEngine::ceQOBuilder::buildNode
  TrexCalculationEngine::ceQOBuilder::build
  TrexCalculationEngine::ceQOExecutor::execute
  TrexCalculationEngine::ceQoPop::executePopInternal
  TrexCalculationEngine::ceQoPop::executePop”.
• Fixed the crash caused by the query that used GROUPING SETS over UNION ALL on OLAP views.
• Fixed an out of memory issue when a prepared “like” filter was used.
• Fixed a bug that prevented query execution with an error such as:
  2qo_col_dic.cc(00550) : Error in the generated plan. DicVal(1000020,3) not found”.
• Fixed a bug in the modeler that caused the properties to be generated only for the first hierarchy defined
• Fixed a crash with the following call stack:
  “1: 0x00007fddaa81e6e9 in AttributeEngine::BTreeAttribute<TrexTypes::IntAttributeValue>::bwGetValueIdsFromValues()”.
• Fixed an issue in the area of data aging which could lead to incorrect results returned from a SELECT query with WHERE conditions on key attributes.
  Please refer to SAP Note 2206359 for details.
• Fixed a bug in the OLAP engine that could have resulted in the column store error:
  “search table error: [2620] executor: plan operation failed;GroupByColumnSetter skip,BwPopJoin1Inwards”.
• Improved tracing to analyze the error 2434:  “join index inconsistent; Invalid schema: Invalid table for index”.
• Introduced a proper error message when the default schema specified in the JDBC connection string does not exist.
• Fixed an indexserver crash with the following call stack:
  “[CRASH_STACK]  Stacktrace of crash: ()
  —-> Symbolic stack backtrace <—-
  0: qo3::OptimizerImpl::initializeInListNode()
  1: bool qo3::OptimizerImpl::initialTree<TRexCommonObjects::QueryEntry>()
  2: qo3::OptimizerImpl::prepare()
  3: qo3::Optimizer::prepare()”.
• Tables containing colums with string-like types (VARCHAR, NVARCHAR, VARBINARY), where all the data in these columns is of the same length, could take long to merge due to suboptimal coding. The coding has been improved and merges are now fast.
• Removed incorrect/ignorable trace entries related to metadata handling. These could have resulted in index server trace file entries during startup like:
  “catalog.cc(04301) : [OID] wrong oid is set from objectinfo – oid :72057594044083712”.
• Fixed the “fatal error: ColDicVal (0,0) not found” error, which was caused by wrong column information being generated for column aggregation during query plan generation.
• Improved the startup time of the index server service when many in-memory sequences needed to be initialized with new startup values.
  Runtime dumps showed that a lot of “time was spent on calls like:
  ptime::SequenceManager::getResetValue()
  ptime::SequenceManager::restart()
  ptime::SequenceManager::resetSequences()”.
• Fixed a bug which could have resulted in JobWorker threads hanging endlessly while executing thread method “HashDict worker” and waiting on “conditional variable” wait. The parent SQL Executer thread / connection could not be canceled. The call stack of the hang JobWorker threads looked like:
  “1: syscall+0x15 (libc.so.6)
  2: Synchronization::CondVariable::wait()
  3: TRexUtils::Parallel::__indexHash<IndexHash<TrexTypes::StringAttributeValue>…
  4: TRexUtils::Parallel::__indexHash<IndexHash<TrexTypes::StringAttributeValue>…
  5: TRexUtils::Parallel::JobBase::run()
  6: Execution::JobObjectImpl::run()
  This hang only happened when the corresponding SQL statement was running into an OOM before by running either into GAL or a user defined statement memory limit”.
• Crash in Execution::JobWorker::enterWait: Fix avoids false detection of sysWaiting worker threads when there’s lock contention
  between setting this flag and actually calling the run method, for example transaction handling.
• TrexViaDbsl: rethrow caught exceptions. An OLAP query leads to metadata inconsistency. If the TrexViaDbsl does not ignore
  the caught exception, commit will not be issued, and the metadata will not be corrupted.
  TrexViaDbsl continues to catch exceptions in order to write error messages in trace file, but throws them again now.
• Fixed a sporadic crash when using Smart Data Access and it attempts to create an attribute definition for a rowid column.  The crashstack will contain, “ptime::FederationQuery::convertCIStoITab”.

1.) If the key file exists on both sites and there is a difference, the SSFS key from primary site has to be copied to the secondary site.
2.) If there is no SSFS key available on primary, the key file on seconday site has to be deleted
When the problem has been resolved, it can re-appear only after the SSFS key has been changed again on primary site.
The programming error will be corrected in one of the upcoming revisions.