Changes From Hana 1 To 2.docx

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 : 301 (internal), 313 (SQL) and 314 (XS classic server) o SAP HANA Options: If you were running SAP HANA Options on your singlecontainer 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 313. 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-highavailability-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