Friday, 4 September 2020

SAP HANA DB restore fails with backup file not found error

 



Hi All,


During the SAP HANA Tenant database restore getting below error.

HANA DB restore from a data backup fails with the following error in backup.log 

2020-08-07  T00:40:59-05:00 P082693 15fd2cb49f5 ERROR RECOVERY RECOVER DATA finished with error: [448] recovery could not be completed, volume 0, reached log position 0, [2000004] Cannot open file ""<root>/COMPLETE_DATA_BACKUP_databackup_databackup_0_1" ((closed, mode= R, access= rw-r-----, flags= DIRECT|MUST_EXIST| MULTI_WRITERS| UNALIGNED_SIZE),  factory= (root="/hana/data/<sid>/backup/" (access= rw-r-----, flags= AUTOCREATE_PATH|DISKFULL_ERROR, usage=DATA_BACKUP, fs= xfs, config=(async_write_submit_active=on,async_write_submit_blocks=all,async_read_submit=on,num_submit_queues=1,num_completion_queues=1,size_kernel_io_queue=512,max_parallel_io_requests=64,min_submit_batch_size=16,max_submit_batch_size=64))",rc=2: No such file or directory


Solution:

As in this case, the prefix/<databackup-name> was COMPLETE_DATA_BACKUP; the data backup name COMPLETE_DATA_BACKUP should be specified in recovery and not COMPLETE_DATA_BACKUP_databackup. Recovery was completed successfully with the following command.

RECOVER DATA USING FILE ('/hana/data/<sid>/backup/COMPLETE_DATA_BACKUP') CLEAR LOG



Wednesday, 2 September 2020

SAP HANA reset the SYSTEM User Password of a Tenant Database

 


If the password of the SYSTEM user in a tenant database is forgot or lost , you as the system administrator can reset it from the system database.

Steps to change the Password:

Stop the tenant database, for example by executing the following statement:

ALTER SYSTEM STOP DATABASE <database_name>

ex: ALTER SYSTEM STOP DATABASE HDB

Create a new password for the SYSTEM user by executing the following statement:

ALTER DATABASE <database_name> SYSTEM USER PASSWORD <new_password>

ex : ALTER DATABASE HDB SYSTEM USER PASSWORD Admin#123


Note: 
The password for the SYSTEM user is reset and the tenant database is started.


Wednesday, 26 August 2020

SAP HANA Replication Modes between Sites

 


Hi all,

We are going to see what are all the Replication Modes between Sites in the SAP HANA Replication setup.

Three Types Of Replication Modes:

  • Synchronous (SYNC)
  • Asynchronous (ASYNC)
  • Synchronous in-memory (SYNCMEM)

Synchronous (SYNC) : The secondary system sends an acknowledgment back to the primary system as soon as the data is received and persisted to the log volumes on disk.
 
When the connection to the secondary system is lost, the primary system continues the transaction processing and writes the changes only to the local disk.

Asynchronous (ASYNC): Asynchronous replication, the primary does not wait until the secondary sends an acknowledgement.

When the connection to the secondary system is lost, the primary system continues the transaction processing and writes the changes only to the local disk. No data loss occurs in this scenario as long as the secondary system is connected. Data loss can occur, when a takeover is executed while the secondary system is disconnected.

Synchronous in-memory (SYNCMEM):The secondary system sends an acknowledgment back to the primary system as soon as the data is received in memory. This option provides better performance because it is not necessary to wait for log I/O on the secondary system. Database consistency across all services on the secondary system is guaranteed. 

Replication Mode have some distance limit to log shipping.

            Replication Mode:                     Distance limit
  • SYNC,SYNCMEM                      < 100 KM
  • ASYNC                                          > 100 KM

For HANA HA setup – SYNC or SYNCMEM SAP HANA Replication Modes. we can use  between primary and secondary site within the Data-Center

For HANA DR setup–  ASYNC SAP HANA Replication Modes we can use between DC to DR location.


Tuesday, 4 August 2020

Unlock & Reset SAP* and other User Password in Oracle




Unlock & Reset SAP User Password in Oracle

Step 1:
Take Remote Desktop (Windows) / Telnet (Unix/Linux) to OS level and connect to the sql using the command prompt.

C:\Documents and Settings\<SID>adm>sqlplus"/as sysdba"

Step 2:
View the User table.

SQL> select UFLAG, BNAME, MANDT from SAPSR3.USR02 where BNAME='USERNAME';

Step 3:
Unlock the User(failed attempt lock).

SQL> update SAPSR3.USR02 set UFLAG=0 where BNAME='USERNAME' and MANDT=CLIENT No;

Now User has been unlocked!!!


Reset SAP* user Password

Step 1:
Take Remote Desktop (Windows) / Telnet (Unix/Linux) to OS level and connect to the sql using the command prompt.

C:\Documents and Settings\<SID>adm>sqlplus"/as sysdba"

Step 2:
View the User table.

SQL> select UFLAG, BNAME, MANDT from SAPSR3.USR02 where BNAME='SAP*';

Step 3:
Unlock the User(failed attempt lock).

SQL> update SAPSR3.USR02 set UFLAG=0 where BNAME='SAP*' and MANDT=000;

Reset the SAP* password
Step 4:

SQL>delete from SAPSR3.USR02 where BNAME='SAP*' and MANDT=000;

Step 5: 

Set the parameter login/no_automatic_user_sapstar is set to 0. You also can check in RZ11. You need to reboot the SAP once the parameter is change.

login/no_automatic_user_sapstar=0

Friday, 10 July 2020

SPAM Error: IMPORT_PROPER TP_STEP_FAILURE


SPAM Error:


During the Patch upgrade Error.

IMPORT_PROPER TP_STEP_FAILURE, Return code : 0008

Solution:

A tp step could not be executed. You can find the details log from /usr/sap/trans/log (DIR_TRANS).
Find the below log.

tp  P<YY><MM><DD>.<SID>

1. Go to OS directory and find the appropriate log file. and open the log file
more P200610.SID

2WETP000 17:15:00: Retcode 1: error in DDL statement for "xxxx " - repeat
2EETP345 17:30:00: Retcode 1: SQL-error "959-ORA-00959
tablespace 'xxxx' does not exist" in DDL
2EETP334 18:24:00: error in DDL, nametab for "xxxx" not activated

2. The error is stated that,
SQL-error "959-ORA-00959: tablespace 'xxxx' does not exist"

3. Increase the tablespace size and then repeat upgrade.


 


Thursday, 9 July 2020

What is SAP Buffer?



SAP Buffer?
             
             Each SAP instance (application server) has its own buffers. These buffers are also known as client caches because they are implemented on the client, that is, the application server. SAP buffers occupy memory areas that are local to the work process, and in individual shared memory segments that can be accessed by all work processes. These memory areas are executed for the application server.

      SAP Buffer stores frequently accessed business objects and data.When a new set of data is requested by a work process, it is not only fetched from the database and provided to the work process but also stored in the SAP Buffer so that the next time when the same set of data is requested, it is provided from the buffer itself, reducing database access thus reducing the load on the database server and network traffic, thereby improving overall system performance.If the required information is not available in the buffer, it must be paged into the buffer before it can be used, resulting in slower performance.If the SAP Buffer is too small, it cannot hold all of the required information. This shortage of space results in the information being swapped out of the buffers. If the SAP Buffer is too large, the native operating system will start paging because too much memory is taken away and given to SAP, database, or other applications. 

SAP buffers
  1. Program Buffer
  2. Generic Buffer
  3. Screen Buffer
  4. Roll Area
Program Buffer:

      This buffer occupies a whole shared memory segment.This buffer occupies a whole shared memory segment.

Generic Buffer & Screen Buffer:

    These buffers are held in a shared memory pool. All work processes can access this pool.

Roll Area:

   Local work process buffers. Only one work process can access these buffers at a time.