SAP HANA XSCONTROLLER service does not start | Techrelam

 

 

 

 

SAP HANA XSCONTROLLER service does not start

If you have an issue in the startup or runtime of the SAP HANA Extended Application Services Advanced Model (XSA), How to troubleshoot it. Let's see

If your are using the XSA 1.0.86 or higher we need to follow the steps.

Run the following command in the XSA host:

> XSA collect-traces -o <zip file>

Example: XSA collect-traces -o techrelam.zip

Note: To use the XSA command, you must log on as the operating-system user <SID>adm.

If you are using lower versions of XSA:

Collect the logs manually:

    The relevant traces are (for all versions):

1. xscontroller_<n>.log
2. xscontroller.out
3. xsexeagent*.log
4. xsexeagent.out
5. xsuaaserver.out
6. uaa.log

      Starting with XSA 1.0.71 there is also:    

1. xsuaaserver_*.log
   

    Starting with HANA SPS 03 there is also:

1. xshanabroker_*.log
2. xsinstancemanager_*.log

Those files can be retrieved from:

    /usr/sap/<SID>/HDB00/<hostname>/trace

    or

    /hana/shared/<SID>/xs/controller_data/controller/tracing/log

SAP ABAP RFC backup Export and Import using R3trans | Techrelam

 

 

SAP ABAP system and you want to export and import ABAP RFC .

Export and Import the RFC at Operating System level using R3trans. 

Steps

1. Create export script with following commands , we named this script as "rfc_backup".

export

file '/<dir>/rfc_data'

select * from RFCATTRIB

select * from RFCDES

select * from RFCSYSACL

select * from RSECACHK

select * from RSECACTB

select * from RSECTAB

2. Create import/restore script with following commands ,we named it as "rfc_restore"

import

file='/<dir>/rfc_data'

Before export the SAP RFC check the Script as below screen shot. Once we execute the export script using R3trans, it will export the RFC in the output file named "rfc_data".

3.   Run following command at OS level : " R3trans rfc_backup"

4. Run following command at OS level : " R3trans rfc_restore"

5. After executing the R3trans  RFC export/import script Check the trans.log - Log file will be created in current directory. One can verify the steps executed in trans.log.

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