Tuesday 31 March 2020

reason=DP_SHUTDOWN_LARGE_TIME_DIFF

ERROR: disp+work stopped after few seconds


*** DpRqNoWpHandle: SHUTDOWN request from W2 received (reason=DP_SHUTDOWN_LARGE_TIME_DIFF) ***
***

********** SERVER SNAPSHOT 1 (Reason: Shutdown) - begin **********

Reason: 


we may face this issue while starting SAP application after migration, implementation of DB or Application on the new host.

We observed that Dispatcher getting stopped.

Solution: 

1: Got to work directory of CI or DVEBMGS00
    F:\usr\sap\SID\DVEBMGS00\work   ( windows)

2: Check log of  "dev_disp" and " dev_w0

*** DpRqNoWpHandle: SHUTDOWN request from W2 received (reason=DP_SHUTDOWN_LARGE_TIME_DIFF) ***


Basically this issue we faced when Application and Database hosted on different OS. Hence check the date and time of both host and correct DB time as per Application or Application host time as per DB host time.

perform change when Application and DB are stopped. Once change done start Database and then application.

Your issue seems resolved.

https://launchpad.support.sap.com/#/notes/1913285

Rupesh Chavan

Sunday 29 March 2020

Memory Management in the Column Store


Main storage and delta storage.

As only data in memory is relevant, the load status of tables is significant. A table can have one of the following load statuses:

● Unloaded, that is, none of the data in the table is loaded to main memory
● Partly loaded, that is, some of the data in the table is loaded to main memory, for example, a few columns recently used in a query
● Fully loaded, that is, all the data in the table is loaded into main memory


Loading and Unloading of Data in the Column Store


The SAP HANA database aims to keep all relevant data in memory.
Standard row tables are loaded into memory when the database is started and remain there as long as it is running. They are not unloaded.
Column tables, on the other hand, are loaded on demand, column by column when they are first accessed.
This is sometimes called lazy loading. This means that columns that are never used are not loaded and memory waste is avoided.


Note This is the default behavior of column tables.
In the metadata of the table, it is possible to specify that individual columns or the entire table are loaded into memory when the database is started


Load/Unload a Column Table into/from Memory


Under normal circumstances, the SAP HANA database manages the loading and unloading of tables into and from memory independently,
the aim being to keep all relevant data in memory. However, you can manually load and unload individual tables, as well as load table columns if necessary.

Privilege
● System privilege TABLE ADMIN
● SQL object privilege UPDATE for the table or the schema in which the table is located


Load and Unload a Table Using SQL


Open the SQL console and execute the required statement:

LOAD <table_name>
UNLOAD <table_nam

LOAD <table_name> (<column_name>, ...)

Results

The entire column is loaded into main memory. Its load status is TRUE. The table's load status is PARTIALLY.


Managing Memory by Object Usage

The time-based parameter unused_retention_period. is available for this in the global.ini file.
To use this feature change the default value (initially set to 0) to a number of seconds, for example 7200 (2 hours). Objects which are not used within this time period are flagged as being eligible to unload.

Objects which have exceeded the retention period are not immediately unloaded from memory, an additional checking process which runs at a pre-defined interval initiates the unload. The frequency of the check is controlled by the unused_retention_period_check_interval configuration parameter. This is set by default to 7200 seconds (2 hours).

Retention Times and Priorities for Objects

In addition to the general configuration parameter you can apply a retention period and an unload priority value to the table or partition definition itself (see the SAP HANA SQL and System Views Reference for details). The following example applies an unload retention period of 60 seconds to table myTable.

ALTER TABLE "myTable" WITH PARAMETERS('UNUSED_RETENTION_PERIOD'='60')

 The unload priority value is a number from 0 to 9 where 0 means the object can never be automatically unloaded and 9 means the earliest unload. Note that retention period values can only be applied to tables if a configuration value has been set for unused_retention_period in the global.ini file

Thursday 26 March 2020

Check usage of HANA DB


CHECK USAGE OF HANA DB



Note: while installing HANA DB same as SANDOX, DEV, QAS or PRD. We need to select System usage the same currently running DB as shown below.


ANSWER 

As to install same DB with version, usage, and data. It's important to select the same usage while doing the installation. we can same in below screen.




Question comes in a mind when we reach the screen where we have to select usage of DB. If we are installing the same DB for sandbox  then we need to select option “2” that is Test and its production then it will be production

We can get some information by going to HANA studio à Overview  --> General Information 











Tuesday 17 March 2020

Change HANA DATA and LOG backup location without downtime

Change HANA DATA and LOG backup location without downtime


We are going to see, How can we change HANA Data and LOG backup location without affecting system functionality.

Note: Change HANA Backup location is on fly


Reasons :

1: We observed that HANA DB size increasing, hence we failed to keep the last two COMPLETE DATA BACKUP. because it may lead to   /Backup FS full situation and it will affect the system. Once backup FS full then log backup creation will stop.

2: We want to resize /Backup FS but as it's in use it difficult to resize FS. In a few cases, it asks for the restart of OS. which is not possible in the Production System.

Procedure: 

1: Add a disk to the respective server. 

2: Create FS and make the directory as   "backunew"  ( below are command for OS admin). you can ask you os team to mount fs then start with point  "3"

--> mkfs -t ext4 /dev/nvmexxxx     
--> mkdir -p /backupnew
--> mkdir Data 
--> mkdir Log
--> Chown /Data /Log  

3: Change parameter as shown below

global.in --> persistence 

basepath_databackup --> /backupnew/HDB/data

basepath_logbackup --> /backupnew/HDB/log












4: Now run test configuration by running COMPLETE DATA Backup. Once we start backup we can see log backup started at new location 


Thanks 
Rupesh Chavan

Monday 2 March 2020

Statistics Server disabled in System Overview HANA

The Hana Studio shows the following alert "Statistical server has been disabled; data may be out of date"








The Statistics Server is showing green in the "Services" tab but no statistical data is being collected. 



Resolution

1: Open Sap Hana Studio --> open SYSTEM DB 
2: Go to "Administration Console" -> "Configuration" -> "Statisticsserver.ini" -> "Statisticsserver_general" -> "active".

3: Set the parameter "active" to "true".













4: Alternatively execute the SQL command : alter system alter configuration('nameserver.ini','SYSTEM') SET ('statisticsserver','active') = 'true' with reconfigure





Now we there is no alert at overview tab in HANA Studio 






Thanks 

Sunday 1 March 2020

SAP HANA support SQL


SQL Language Elements can be divided into three categories



Why and when, we require HANA database security management?

Why and when, we require HANA database security management?


The following main SAP HANA Security Perspective scenarios are possible:

● SAP HANA as a data mart for reporting and analytics
● SAP HANA in a classic three-tier architecture as the primary database. For example, in
SAP BW/4HANA or SAP S/4HANA installations.
● SAP HANA as a platform for providing database and application services to native SAP
HANA based applications

Data Mart Scenario (which we also called “side car”)

Note:
data marts à
With SAP HANA, operational data marts offer real-time analytics and reporting on data replicated from a transactional system's database. The raw tables themselves are copied (structure and data) from the transactional system's database into SAP HANA.



In a data mart scenario, data is replicated from a source system (ECC, No-SAP Database etc.) into the SAP HANA database. Reporting is then carried out on the data in SAP HANA (for
Example, using read-only views, dashboards, and so on). Some end users usually have direct access to SAP HANA. Therefore, user and role management in SAP HANA is required for these end-users, as well as for technical users and administrators.


SAP HANA in a Classic Three-Tier Architecture

You can use SAP HANA as a relational database in a classic three-tier architecture (client,
application server, and database). Security-related features are located and are enforced in
the application server layer. These security features include authentication, authorization,
encryption, and auditing. The database is used as a data store only.

The classic three-tier architecture has the following features:


The same security model for user access applies as for other databases.
 End users do not have direct access to either the database itself or the database server on
which it is running.
 Security in the database layer is mainly focused on securing administrative access to the
database.
 Specific SAP HANA security features are needed to control access of administrators to the database.

SAP HANA as a Platform



SAP HANA includes SAP HANA extended application services. SAP HANA extended
application services embed a full-featured application server, Web server, and development
the environment within SAP HANA. Applications can be deployed directly on SAP HANA extended application services. It exposes these applications to end users through a web interface.