Adding a Host to a Scale-Out System

Business Example

As an SAP HANA database administrator, you need to understand how to extend an SAP HANA multi-host system with additional hosts. To better understand this feature, you add a new worker node to the existing SAP HANA scale-out system.

Adding Hosts to an SAP HANA System

You can add hosts to an SAP HANA system using the SAP HANA database lifecycle manager (HDBLCM) resident program or the SAP HANA database lifecycle manager web user interface.

If you want to configure a new multiple-host (distributed) system during installation, see the multiple-host system installation information in the SAP HANA Server Installation and Update Guide.

Before adding a host to an SAP HANA system, you need to consider the following information:

If you are adding hosts from a host that is already integrated in the SAP HANA system.
If the system is a single-host or multiple-host system.
The number of hosts you want to add to the system at one time.

If you are adding a host to a single-host system, the listen interface is automatically configured to global during the host addition. After the host is added to the system, the internal network address can be defined and the inter-service communication can be reconfigured to a different setting, if required.

The different user interfaces options for hdblcm (browser, GUI and ASCII based in a terminal).

Add Hosts Using the Graphical User Interface or the Command-line Interface

You can add hosts to an SAP HANA system using the SAP HANA database lifecycle manager resident program in the graphical user interface.

Prerequisites

The SAP HANA system has been installed with its server software on a shared file system (export options: rw, no_root_squash).
The host has access to the installation directories <sapmnt> and <sapmnt>/<SID>.
The SAP HANA system has been installed with the SAP HANA database lifecycle manager.
The SAP HANA database server is up and running.
You are logged on as root user or as the system administrator user <sid>adm.
The difference between the system time set on the installation host and the additional host is not greater than 180 seconds.
The operating system administrator (<sid>adm) user may exist on the additional host. Ensure that you have the password of the existing <sid>adm user, and that the user attributes and group assignments are correct. The SAP HANA database lifecycle manager resident program does not modify the properties of any existing user or group.

Add Hosts Using the Web User Interface

You can add hosts to an SAP HANA system using the SAP HANA database lifecycle manager web user interface.

Prerequisites

On the host that is to be added, the SAP Host Agent is installed with SSL configured. The SAP Host Agent creates the <sapsys> group, if it does not exist prior to installation. Ensure that the group ID of the <sapsys> group is the same on all hosts.
The difference between the system time set on the installation host and the additional host is not greater than 180 seconds.
The operating system administrator (<SID>adm) user may exist on the additional host. Ensure that you have the password of the existing <SID>adm user, and that the user attributes and group assignments are correct. The SAP HANA database lifecycle manager (HDBLCM) does not modify the properties of any existing user or group.
The SAP HANA system has been installed with its server software on a shared file system (export options: rw, no_root_squash).
The host has access to the installation directories <sapmnt> and <sapmnt>/<SID>.
The SAP HANA system has been installed with the SAP HANA database lifecycle manager (HDBLCM).
The SAP HANA database server is up and running.
Communication port 1129 is open.
Port 1129 is required for the SSL communication with the SAP Host Agent in a standalone browser using HTTPS.

Web Browser Prerequisites

On Microsoft Windows:

Internet Explorer - Version 9 or higher
If you are running Internet Explorer version 9, ensure that your browser is not running in compatibility mode with your SAP HANA host. You can check this in your browser by choosing Tools → Compatibility → View Settings.
Microsoft Edge
Mozilla Firefox - Latest version and Extended Support Release
Google Chrome - Latest version

On SUSE Linux:

Mozilla Firefox with XULRunner 10.0.4 ESR

On Mac OS:

Safari 5.1 or higher

Note

For more information about supported web browsers for the SAP HANA database lifecycle manager web interface, see the browser support for the sap.m library in the SAPUI5 Developer Guide.

Redistribute Tables After Adding a Host

After you have added a new worker host to your SAP HANA system, you need to redistribute the tables in the system to balance the memory footprint of the tables and to improve performance (load balancing).

You can run table redistribution from the command line. This approach offers additional functionality including the option to modify, at runtime, some of the configuration parameters that control redistribution.

The SQL statements for the redistribution of the data after adding a host to the scale-out system.

Table redistribution is based on the table placement rules defined in the table TABLE_PLACEMENT. These determine, for example, table sizes, partitioning threshold values, and preferred partition locations. Redistribution is a two-stage process: the first is to generate the plan, and the second is to execute the plan. Separate commands are used for each stage:

The plan generation command is a multi-purpose tool that requires an algorithm number as a parameter to determine which actions are executed. Depending on the algorithm selected, additional optional parameter values may also be available to give more control over the execution.
The plan execution command takes a single parameter which is the numeric plan ID value. You can retrieve this value (REORG_ID) from the REORG_OVERVIEW system view. Refer to the System Views section following.

The syntax for these commands is:

CALL REORG_GENERATE(< algorithm integer>, < optional parameter string>);
CALL REORG_EXECUTE(< plan_id>)

Resource admin privilege is required to call REORG_GENERATE(). The command only operates on tables and partitions that the executing user is allowed to see as catalog objects.

Generating the Plan: Algorithms and Options

The following table gives an overview of the most commonly-required algorithms and a summary of the options available for each one. See the examples and details of the options that follow.

Algorithm Number	Algorithm Name	Description
6	Balance landscape	This function checks if tables in the landscape are placed on invalid severs according to the table placement rules, and checks if a split or merge is necessary to achieve optimal positions for the partitions and tables and to evenly distribute tables across the index server hosts. Options: SCHEMA_NAME \| TABLE_NAME \| GROUP_NAME \| GROUP_TYPE \| GROUP_SUBTYPE \| RECALC \| NO_PLAN \| NO_SPLIT \| SCOPE
1	Add server	Run this check after adding one or more index servers to the landscape. If new partitions can be created, a plan is generated to split the tables and move the new partitions to the newly added index servers. Options: SCHEMA_NAME \| TABLE_NAME \| GROUP_NAME \| GROUP_TYPE \| GROUP_SUBTYPE \| RECALC \| NO_PLAN
4	Save	Save the current landscape setup. No optional parameters.
5	Restore	Restore a saved landscape setup. Enter the plan ID value as the optional parameter value.
7	Check number of partitions	This function checks if partitioned tables need to be re-partitioned and creates a plan to split tables if the partitions exceed a configured row count threshold. No optional parameters.
14	Check table placement	Check the current landscape against table placement rules and (if necessary) provide a plan to move tables and partitions to the correct hosts. Options: LEAVE_UNCHANGED_UNTOUCHED \| KEEP_VALID \| NO_SPLIT
15	Rerun plan	Rerun failed items from previously executed plans. Option: RERUN_ALL
16	Housekeeping	Perform housekeeping tasks. Additional privileges may be required for specific actions. Options: OPTIMIZE_COMPRESSION \| DEFRAG \| LOAD_TABLE \| MERGE_DELTA \| ALL

Optional Parameters

The following table gives more details of the optional parameters that are available.

Option	Type	Detail
SCHEMA_NAME	String	Restrict redistribution to the named schema(s) - comma-separated list.
TABLE_NAME	String	Restrict redistribution to the named table(s) - comma-separated list.
GROUP_NAME	String	Restrict redistribution to the named group(s) - comma-separated list.
GROUP_TYPE	String	Restrict redistribution to the named group types(s) - comma-separated list.
GROUP_SUBTYPE	String	Restrict redistribution to the named group sub types(s) - comma-separated list.
RECALC	True / False	If true, recalculate the landscape data of the last REORG_GENERATE run. This option works only if REORG_GENERATE has been called previously within the same connection session. This parameter can be used to speed up plan generation with different parameters.
NO_PLAN	True / False	If true, the planning stage of generating the plan is skipped. This can be used with external tools when landscape data needs to be collected and a distribution must be calculated, but may be modified.
SCOPE	Keyword	Scope the redistribution to include only the named items specified by the following keywords. The default value is 'ALL' so that all tables visible to the user are included in the redistribution. LOADED - Tables that are loaded or partially loaded UNLOADED - Tables that are not loaded FILLED - Tables with a record count greater than 10 EMPTY - Tables with a record count less than or equal to 10 USED - Tables with a total execution count greater than 10 UNUSED - Tables with a total execution count of less than or equal to 10 LOB - Tables with LOB columns NOLOB - Tables without LOB columns

Examples

Add server (algorithm 1):

With this algorithm, you can use the optional filter parameters to, for example, restrict redistribution to specified schemas, tables, table groups, and so on. The following example uses the SCHEMA_NAME option to generate a plan for all tables in schema SAPBWP:

Code Snippet

1
CALL REORG_GENERATE(1, 'SCHEMA_NAME => SAPBWP')

Balance Landscape / Table (algorithm 6):

The following examples show the usage of optional parameters with this balancing algorithm.

If the options parameter string is left blank, a plan is generated for all visible tables:

Code Snippet

1
CALL REORG_GENERATE(6,'');

This example uses the GROUP_NAME option to generate a plan for all tables in the three specified groups:

Code Snippet

1
CALL REORG_GENERATE(6,'GROUP_NAME=>TABLEGROUP1, TABLEGROUP2, TABLEGROUP3');

This example uses the SCHEMA_NAME option to generate a plan for all tables in the schema SAPBWP:

Code Snippet

1
CALL REORG_GENERATE(6,'SCHEMA_NAME => SAPBWP');

This example shows usage of the SCOPE option. The plan is restricted to only tables with a record count greater than 10 and that have no LOB columns:

Code Snippet

1
CALL REORG_GENERATE(6, 'SCOPE=>FILLED,NOLOB');

System Views

The following system views show details of table redistribution. The last two views in the list show information about the most recent distribution operation. The details are deleted when the current connection to the database is closed.

REORG_OVERVIEW – Provides an overview of landscape redistributions.
REORG_STEPS – Shows details of the individual steps (items) of each plan.
REORG_PLAN – Contains details of the last table redistribution plan generated with this database connection.
REORG_PLAN_INFOS – Shows details (as key-value pairs) of the last executed redistribution (algorithm value and parameters used).