Changes from HANA 1.0 SPS12 to HANA 2.

0 SPS03

- SAP HANA Cockpit 2.0 (Installed on a new server with min 16 GB ram )
- During update to SAP HANA 2.0 SPS01 or greater, all single container systems are converted
to support tenant databases.
- Configuration Perspective :
o Database Configuration : Parameters, which were changed are stored with the
tenant database and become database-specific
o User Administration: Users on single-container database are now present in the
tenant database. During the update, you are asked to provide a new password for
the system user of the system database.
o Ports and Url’s : Ports and URL’s do not change after the update
 Tenant database retains the port numbers of the original single-container
 The port number of the system database are fixed : 3<instance number>01
(internal), 3<instance number>13 (SQL) and 3<instance number>14 (XS
classic server)
o SAP HANA Options: If you were running SAP HANA Options on your single-
container system, no configuration changes are required after the update. SAP
HANA options hosts or host roles can be automatically provisioned to a system that
is installed with a single tenant.
o XS advanced runtime: A Separate xsengine process is created and the internal web
dispatcher of the SAP HANA system routes by default to the single tenant.
- Security Perspective:
o User administration: You need to set up new users for administration (at least for
recovery) in the system database.
o Network Security: The system database uses additional ports. These ports that
might be firewalled for security reasons in the system. If this the case, you need to
open these ports so that the system database can be accessed from the SAP HANA
cockpit on other hosts. The system database is accessible via SQL port
3<instance_no>13.
o Database Isolation: The default system isolation level is low. It is possible to change
the isolation level (from low to high or from high to low) at any time after the
update. Once high isolation has been configured, a dedicated OS user and group
must exist for every tenant database. Otherwise, it's not possible to create or start
a tenant database.
o TLS/SSL Configuration for external communication: If TLS/SSL is enabled for both
the system database and tenant database, the in-database certificate collection
containing the certificates used for trust validation is available only in the tenant
database. If you want to use the same certificates, you will need import them into
the certificate store of the system database and add them to a certificate collection
there.
o Auditing: Existing audit policies are available in the tenant database only. You need
to create new audit policies for administration tasks in the system database.
- Backup and Recovery:
 o System Database: If you do not change your backup configuration, a backup of the
tenant database is created by default. It can be restored into any existing tenant
database. The system database has to be backed up separately.
o Third Party Tools: If your backup strategy is based on storage snapshots taken by a
third-party tool, we recommend that you get in touch with your snapshot tool
vendor to check if the tool supports snapshots of SAP HANA tenant database
systems. If you use a script that is based on the documented SQL statements, refer
to the documentation to adapt it for use with tenant databases.
o Storage Snapshots: Storage snapshots are only supported on single-tenant
systems.
o Retention Policy: Without adjusting your backup retention policy, only the tenant
database backups are maintained. As a consequence, the system database backup
catalog grows unchecked, consumes main memory, and prolongs backup times.
Furthermore, system database data and log backups will eat up your backup space.
o Backup History: The migration from single-container mode to tenant databases
does not break the backup history. Single database data and log backups can be
used to recover a tenant database system.
o Disaster recovery: In the event of a disaster, you first have to recover the system
database in operational mode offline and then the tenant database using the
system database connectivity. The system database requires to be in operational
state online while recovering the tenant database.
- Landscape:
o Host addition and removal: After the update, hosts can be added to or removed
from a single-host or multiple-host SAP HANA system using the SAP HANA
database lifecycle manager (HDBLCM).
o Scale out: To scale out a tenant database or distribute it across multiple hosts, you
can add further server components, for example, an additional index server or a
separate XS server. You add a service to a tenant database using the ALTER
DATABASE statement. The statement is executed on the system database for a
specific tenant database.
o Add or remove service: Add or remove service statements are executed on the
system database for a specific tenant database.
- Administration:
o SAP HANA Cockpit 2: A new tool for administration of HANA need to install on a
separate server. Generally we can use one server for all non-prod servers and one
server for prod-servers.
o High Availability : Multi target System Replication and Invisible Takeover
 https://blogs.sap.com/2018/04/20/sap-hana-2.0-sps-03-whats-new-high-
availability-by-the-sap-hana-academy/
o Tenant Database management:
 Persistent Data Storage
 Support (non-volatile RAM, also referred to as Storage Class
Memory)
 2101244 - FAQ: SAP HANA Multitenant Database Containers (MDC)
o System Administration: From system administration perspective there are minor
changes in administration and monitoring due to tenant database for the
following activities
 Starting and Stopping Systems
 Licenses
 Monitoring
 Troubleshooting
 Backup and Recovery
 System Replication
 Configuring SAP HANA System Properties
 Security and Administration
 Availability and Scalability
 Trouble shooting
 Managing Tenant Database