User Types in SAP HANA Database | Techrelam

 

User Types in SAP HANA Database

There are two types of User in SAP HANA database.

1. Standard User
2. Restricted User

Standard users can create objects in their own schema and read data in system views. The PUBLIC role grants read access to system views, and this is granted to every standard user. Restricted users initially have no privileges. 

Restricted users are for users who access SAP HANA through client applications and who do not have full SQL access through an SQL console. If the privileges that they need to use the application are included within an application-specific role, then you only have to grant the user this role. In this way, you can ensure that users only have those privileges that are essential to their work.

Limitations of Restricted Users 

Compared to standard database users, restricted users are initially limited in the following ways:

They cannot create objects in the database because they are not authorized to create objects in their own database schema. 

They cannot view any data in the database because they are not granted (and cannot be granted) the standard PUBLIC role. 

They are only able to connect to the database using HTTP/HTTPS. 

To enable a restricted user to use an application, grant the required application-specific roles. Initially, restricted users can only connect to the database using HTTP or HTTPS.

To allow restricted users to connect through ODBC or JDBC, enable ODBC or JDBC access explicitly. 

Types Of Delta Merge in SAP HANA Database | Techrelam

 

Types Of Delta Merge in SAP HANA Database.

There are Four types of delta Merge Operation in SAP HANA Database.

1. Auto Merge
2. Smart Merge
3. Hard and Forced Merges
4. Critical Merge 

Auto Merge:

 

The standard method for initiating a merge in SAP HANA is the auto merge. A system process called mergedog periodically checks the column store tables that are loaded locally. For each individual table or single partition of a split table, it determines whether or not a merge is necessary based on certain criteria (for example, size of delta storage, available memory, time since last merge, and others). If the active parameter in the mergedog section of the indexserver.ini file is set to yes, auto merge is active. 

Note: You can activate or deactivate auto merge for an individual table in the TABLES (SYS) system view. Change the value in the AUTO_MERGE_ON column to TRUE or FALSE. 

Smart Merge:

SAP HANA provides a function that allows the system to check whether or not a delta merge makes sense. This function is called smart merge. For example, if an application starts loading relatively large data volumes, a delta merge during the load can have a negative impact both on the load performance and on other system users. Therefore, the application can disable the auto merge for those tables being loaded and send a hint to the database to merge once the load has completed. When the application issues a smart merge hint to the database to trigger a merge, the database evaluates the criteria that determine whether or not a merge is necessary. If the criteria are met, the merge is executed. If the criteria are not met, the database takes no further action. Only a subsequent hint from the application triggers another evaluation of the criteria.

If the active parameter in the smart_merge_enabled section of the indexserver.ini file is set to yes, smart merge is active. Caution: For tables that you want to merge with the smart merge, disable the auto merge. Otherwise, the auto merge and smart merge may interfere with each other. 

Hard and Forced Merges:

     You can trigger the delta merge operation for a table manually by executing the SQL statement MERGE DELTA OF "" . This is called a hard merge. It causes the database to execute the delta merge for the table either immediately if sufficient system resources are available, or as soon as sufficient system resources become available. The hard merge is therefore subject to the merge token control mechanism. If you want the merge to take place immediately regardless of system resource availability, you can pass an optional parameter. A forced merge may be useful in a situation where there is a heavy system load, but a small table needs to be merged. It is also useful if a missed merge of a certain table negatively impacts system performance. To execute a forced merge, execute the SQL statement MERGE DELTA OF '' WITH PARAMETERS ('FORCED_MERGE' = 'ON') .

Critical Merge:

  To keep the system stable, the database can trigger a critical merge. For example, when auto merge is disabled and no smart merge hints are sent to the system, the size of the delta storage can grow too large for a successful delta merge to occur. The system initiates a critical merge automatically when a certain threshold is passed.

Error "Logon failed for RESTful Web Services. Contact system administrator." while logging into Fiori BI Launchpad

Error while Logging into Fiori BI Launchpad getting below.

Error "Logon failed for RESTful Web Services. Contact system administrator." 

Solution:

1. Navigate to Applications.

2. Right click on 'RESTful Web Service' and go to its Properties.

3. Change the Access URL pointing to an externally accessible IP or hostname. For ex, for VMware vCloud Director appliances, change the URL as "http://<External IP of vApp>:<port#>/biprws".This URL needs to be working from machine where the client browser is.

4. Click on 'Save & Close'.

Also check the following:

1.Ensure Restful web service is installed on the system, either on WACS or on any other supported webapp server

2. Ensure WACS is running without errors (not stopped or disabled) in the BI server environment, if restful is deployed on WACS, if it is deployed on supported webappserver, ensure the restful webapp is runing.

3. In case when restful is deployed on WACS - ensure the WACS port is accessible from the machine where the browser is being run (The call to Restful web service is made directly from the browser).Test from browser client machine:telnet <BISERVERHOSTNAME> <WACSPORT>

 

SAP HANA Types of Technical Deployment Options | Techrelam

 SAP HANA Types of Technical Deployment Options.

Types of SAP HANA Deployment Options.

• Multi tenant Database Container (MDC) 
• Multiple Components on one Database (MCOD) 
• Multiple Components on one System (MCOS) 
• SAP HANA with Virtualization 
• Technical Co-Deployment 

Multi tenant Database Container (MDC) :

SAP HANA multitenant database containers establish a foundation for providing multitenancy in SAP HANA. As of SAP HANA 2.0 SPS01 an SAP HANA system is installed in multiple-container mode. It can contain more than one multitenant database container. A multiple-container system always has exactly one system database, which is used for central system administration. It also has any number of multitenant database containers (including zero), called tenant databases. An SAP HANA system installed in multiplecontainer mode is identified by a single system ID (SID). Databases are identified by a SID and a database name. From the administration perspective, there is a distinction between tasks performed at system level and those performed at database level. Database clients, such as the SAP HANAcockpit, connect to specific databases. All the databases in a multiple-container system share the same installation of database system software, the same computing resources, and the same system administration 

Multiple Components on One Database 

Multiple applications on one SAP HANA system are also known as Multiple Components on One Database (MCOD).

The technical deployment type MCOD refers to the scenario where more than one application, scenario, or component runs on one SAP HANA system. This deployment type is available, with restrictions, for production SAP HANA systems. For production systems, there are white lists that specify supported scenarios explicitly

Multiple Components on One System Multiple 

SAP HANA systems on one host are also known as Multiple Components on One System (MCOS). SAP does support running multiple SAP HANA systems (SIDs) on a single production SAP HANA host. This is restricted to single-host or scale-up scenarios only. Multiple components on one system requires significant attention to various detailed tasks related to system administration and performance management.  

Virtualization 

SAP HANA supports many popular virtualization supervisors, such as VMware vSphere 5.1 or newer, Hitachi LPAR, Huawei FusionSphere, IBM PowerVM, or others for nonproductive environments.You can choose virtualization for a wide variety of configurations, for single and multiple virtual machines, in single- or multinode configurations, for appliances of SAP HANA and SAP HANA tailored data center integration delivery methods. The technical deployment type, SAP HANA with virtualization, refers to the scenario where one or more SAP HANA database SIDs are deployed on one or more virtual machines running on SAP HANA server hardware. One benefit of virtualization is that you can assign dedicated CPU and memory resources to specific databases and increase the flexibility of hardware usage.

Technical Co-Deployment 

Technical co-deployment is an additional alternative that can be used to combine several applications. This is available for SRM and SCM. It is provided as an SAP ERP add-on and can be used productively. 

Refer from HA200

SAP HANA Database restart/startup sequence

 SAP HANA system restart/startup sequence.

When the SAP HANA system restart sequence restores the system to a fully operational state quickly.

 1.The data volume of each service is accessed in order to read and load the restart record.

 2. The list of open transactions is read into memory.

 3. The row tables are loaded into memory. 

4. Open transactions are processed using the redo log, as follows: 

1. Write transactions that were open when the database was stopped are rolled back.
2.  Changes of committed transactions that were not written to the data area are rolled forward. The first column tables are reloaded into memory because they are accessed for roll forward. 
3. After this step, the database is technically available and logon is possible. 

5. Aborted transactions are determined and rolled back. 

6. A save point is performed with the restored consistent state of the database. At this point the database is restored from the persistence layer’s point of view. The column store can now load the tables marked for preload into memory. 

7. Column tables, which are marked for preload, and their attributes are asynchronously loaded in the background, if they have not already been loaded as part of log replay.

The preload parameter is configured in the metadata of the table. This feature makes certain tables and columns that were used by important business processes available more quickly. 

8. Column tables that were loaded before restart, and their attributes, start reloading asynchronously in the background, if they have not already been loaded as part of log replay or because they are marked for preload. During normal operation, the system tracks the tables currently in use. This list is used as basis for reloading tables after a restart. 

 

Note : When SAP HANA  system restart, by default, not all tables are loaded into the main memory immediately. 

Content reference from HA200 Study materiel.

SAP HANA Services Simple Overview | Techrelam

 SAP HANA Services Simple Overview.

List of SAP HANA Services

• SAP Start Service
• Daemon
• Nameserver
• Preprocessor
• SAP Web dispatcher
• Compile Server.
• Index Server.
• Xsengine

 SAP Start Service.

• Responsible for starting and stopping the other service in SAP HANA Database.

Daemon

•  Start all other process and keeps them running.If anyone server not running you will get error while HANA db Start error Daemon not start.
  

Name Server

• Store database system landscape and data distribution information.

Index Server

• The main database process, Data loads, queries, calculations, and so on, also provides the embedded statistics service.

Preprocessor

• Feeds unstructured data  into SAP HANA.

Compileserver

• Preforms the complication of stored procedures and programs.

XS engine

• Web service component.

SAP Web Dispatcher  

• Entry point for HTTP(S) request and Depricated services.