HANA BACKUP AND RECOVERY

SAP HANA database is data in-memory.It uses persistent storage to provide a fallback in case of failure.During normal database operation, data is automatically saved from memory to disk at regular save points. All data changes are recorded in the redo log. The redo log is saved from memory to disk with each committed database transaction.Hana PersistenceAfter a power failure ,you can restart the database as with any disk-based database. It then returns to its last consistent state by replaying the redo log since the last save point. Although save points and log writing protect your data against power failures, save points do not help if the persistent storage itself is damaged. To protect against data loss because of disk failures, backups are required. Backups save the payload (the actual data) of the data area and log area to different locations. Unused space in the database is not backed up.The data backup includes all the data structures that are required to restore the database.This includes user data, information models, topology information, and the secure storage filesystem (SSFS). A data backup does not include customer-specific configuration.
BACKUPOverview Of BackUp&Recovery
Backups are performed while the database is running. The impact of backups on system
performance is negligible, and users can continue to work while the backup is running.
The data area is backed up in parallel for each of the SAP HANA services. If SAP HANA is
running on multiple hosts, a data backup includes all the service-specific backup parts for all the hosts.
While a data backup is running, some data integrity checks are performed. If these checks are successful, the data is written to the backup destination.
Data backups save the content of the data area to a different location in the file system.
Depending on the scenario, this includes the replicated business data from SAP ERP and all the modeling data.The properties of an SAP HANA system are defined in the parameters of its configuration files. These files are not backed up as part of the database backup. If you want to back up configuration files that contain customer-specific changes, you can do so manually. In a recovery situation, configuration files can help to identify and restore the customer specific changes. The configuration files are not essential to perform a recovery. If you want to use a customer-specific configuration, reconfigure the recovered system using the SAP HANA studio.
OverviewBACKUP TYPES:
  1. DATA BACKUP
  2. LOG BACKUP
Performing Backups
Backups are performed with the following considerations:
Backup destinations:
  1. Files
  2. Third-party backup toolsDestination For Backups
Data backups carried out manually:
  1. SAP HANA cockpit
  2. SAP HANA studio
  3. DBA Cockpit
  4. SQL commands (command line)
Scheduling:
  1. Backup scheduler in SAP HANA cockpit
  2. Planning calendar in DBA Cockpit
  3. Using scripts (via the SQL interface)
NOTE:
  • Data and logs can only be backed up when the SAP HANA database is online, and when all configured services are running.
  • Backup supports both files as backup media and BACKINT SDK for SAP HANA.
  • While backups and log backups are being created, the impact on system performance is negligible.
  • Only the database payload is backed up; unused space in the database is not backed up.
  • Backup and recovery always applies to the whole database. You cannot back up and recover individual database objects.
  • The content of a data backup is consistent at the start time of the backup.
  • Data backups and log backups are created independently of each other.
  • The configuration path for data and log backup must be valid throughout the whole system, and not only for specific hosts.
  • To recover the database, you need at least one data backup.
SAP Notes
– SAP Note 1642148: FAQ: SAP HANA database backup and recovery
– SAP Note 1730932: Using backup tools with BACKINT
– SAP Note 1812980: Changes to the backup catalog as of revision 45
– For further notes on backup and recovery, see BC-DB-HDB-BAC

Comments

Post a Comment

Popular posts from this blog

SPOOL WORK PROCESS

Spool Process: It is the Only Process that is used to output the documents to a Printer, fax, email etc.. Spool Work Processes are created by using parameter risp/wp_no_spo=1 it is possible to configure more than one spool work process based on available resources. Spool Process Work Flow: User Submits the request to print a Document. The Dialog Process handles the request and print directly or schedules to print in the background.The Print requests are stored in the TemSe(Temporary Sequential Files) Temporary Sequential Files are stored either at File System or at database Level which is defined by parameter rspo/store_location. rspo/store_location=”G” or ‘DB’ G means global directory stores the TEMSE in /usr/sap/SID/SYS/global db mean the Tables TST01 and TST03.(TST01 Contains Print Attributes and TST03 Contains the Spool Data to be Printed) Due to Spool in DB the DB Size Increases, as a Result, the backup time increases and Tapes may not fit with the data for S...
Read more

ENQUEUE WORK PROCESS

It is used to lock and unlock the Objects during an update.These locks are displayed in SM12 and Held for longer hours until the transaction is committed or rollback.These locks are issued from a lock table which resides in the main memory of the instance where enqueue process is created/located. Enque Processes are configured by parameter rdisp/wp_no_enq=1. Generally One Enque Process for instance is sufficient,more then one is required in a massive update system. The Lock table size on the memory ranges between 4mb to 100 MB(200 MB in the Net weaver 7.3 Systems ) It is defined by parameter enque/table_size=4 to 200 MB. For 4mb of enqueue table size, the Number of lock/owners/objects/arguments can be restricted up to 3715. Enqueue Flow: User submits the Request for an Update. The Dialog or Background Process Handles the Request Dia or BTC Processes communicates with Enqueue Process and obtains a lock on the record so that no other user has to write access to that r...
Read more

DIALOG PROCESS

Dialog Process: It is the only process that is used to communicate with end users Interactively using Classic GUI or Through RFC or through Http Protocol. The Average Response Time for each dialog step is 600 ms.it is displayed through ST03n Each Process can execute up to a maximum runtime of 600 seconds.if any process goes beyond this time an additional time of 60 seconds is given and the process is timed out.(ST22)(it is not mandatory to allocate additional 60 seconds Each Process Serves 5-10 users.(Calculated based on ST07) Each Process Requires 75mb to 300 mb Memory Each Process can Handle the requests that are initiated for background, spool & update and update them in temporary tables. Dialog Process is not restricted to a User and Users are not restricted to a process which is referred as process multiplexing Parameters to configure dialog processes is rdisp/wp_no_dia There should be at least minimum two dialog processes and maximum up to 100 processes. The ...
Read more